your solution is one valid option. Bear in mind that very few companies use a PIM today, compared to CMS. PIM is tranforming to PXM.
but many companies use a CMS for any sorts of translation, not just products, it is therefore also a valid solution to keep translation in a simple place.
As long as translations are in the engagement ODA block I think they're both valid component for storing experience-related content.
Original Message:
Sent: May 04, 2023 10:12
From: Alexey Rusakov
Subject: Internationalisation of TMF OpenAPI
My point was specifically that I would prefer PIM to manage translations along with the original content (and expose them in API, not necessarily all at once), rather than rely on CMS to hold the translations - which may be a consequence of PIM not having the functionality to deal with translations. I don't think this is something the use case in IG1228 is even supposed to address, it's a rather low-level detail inside ProductSpecification after all.
------------------------------
Alexey Rusakov
Red Hat, Inc.
Original Message:
Sent: May 04, 2023 06:53
From: Matthieu Hattab
Subject: Internationalisation of TMF OpenAPI
Hello alexey,
the process of adding a new product in a product catalogue (as defined in TMFC001) is described in IG1228 (look up the list of use cases)
PIM is not a CMS but with the rise of PMX, the demarcation is indeed becoming blurier.
for our different business units we have different processes, we have a TMFC001 product catalogue for broadband but we manually update our CMS, which is ok, since updates are rarely needed.
for mobile product line, updates are frequent and big. We use a PIM and our mobile logistic partners has provided a dedicated API to automatically CRUD product offers in the PIM (including SKUs). Our partner acts as a proxy with all handsets manufacturer product catalogue.
In a good ODA implemenation, you would use APIs between different catalogue but still need to update each of them manually to populate information specific to that catalogue.
language is only a concern in PIM and CMS.
------------------------------
Kind regards,
Matthieu Hattab
Lyse Platform
Original Message:
Sent: Apr 21, 2023 06:02
From: Alexey Rusakov
Subject: Internationalisation of TMF OpenAPI
I wonder what the process of adding a new product looks like then. Enter data in the product catalog, then separately add product descriptions in the CMS? I would rather expect a PIM system that has it all in one place. As for translations, I don't expect all of them to end up in the same payload, only one that is the best match for the passed Accept-Language
header.
------------------------------
Alexey Rusakov
Red Hat, Inc.
Original Message:
Sent: Apr 20, 2023 04:10
From: Matthieu Hattab
Subject: Internationalisation of TMF OpenAPI
Hello,
Who needs these translations?
If it's for end-users (employees, customers), I recommend avoiding any sort of translation in a TMF API.
you should use a CMS, possibly a PIM/PXM, to manage your translations (name/description at Offering/ProdSpec/Char/CharValues level)
Imagine the size of your api payload if you work with tens of languages!
with a CMS you have limitless possibilities for translations per party, party role, sales channel, per device, country, local languages etc.
Even if you only work in a single language, a CMS would still be much better than attributes in the TMF API (a product description displayed on a website you visit from your computer is different than viewing it from a 5" mobile phone app)
Moreover, I think it's also what ODA recommends. ODA decouples engagement management (EM) domain from core commerce. EM has a dedicated component for content management.
We solve all our translation needs for EM with a (headless) CMS. API payload is very lean.
My 2 cents!
------------------------------
Kind regards,
Matthieu Hattab
Lyse Platform
Original Message:
Sent: Dec 17, 2019 03:46
From: Dan d'Albuquerque
Subject: Internationalisation of TMF OpenAPI
Hi All.
Currently there appears to be no support for Internationalisation within OpenAPI v2/3.0. I can see that there has been consideration to support multiple languages, e.g. within description fields, using the concept of overlays or a mechanism using JSON-LD langauge maps.
I am imagining that there would especially be a need within TMF620 Product Catalog Management to provide multiple languages for both the name and description fields within the ProductSpecification resource.
Any suggestions?
Thanks
Dan.
------------------------------
Dan d'Albuquerque
------------------------------