Matthieu's approach is certainly one way of doing things. Just bear in mind that having multiple systems for storing catalog data can complicate the work process for catalog authoring.
Another approach would indeed be to allow storage of multi-lingual strings as part of the catalog authoring, as mentioned by Matthieu in his former approach. I had created a draft proposal for this approach for the Open API design guidelines, but it has not become mainstream.
------------------------------
Jonathan Goldberg
Amdocs Management Limited
Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.
------------------------------
Original Message:
Sent: Dec 01, 2023 09:50
From: Myagaa Nm
Subject: Language choice in product catalog
I got it. Thanks Matthieu.
------------------------------
Myagaa Nm
MOBICOM CORPORATION LLC
Original Message:
Sent: Dec 01, 2023 09:22
From: Matthieu Hattab
Subject: Language choice in product catalog
We had this discussion in the forum on the same topic.
It's debatable. I used to want to have new entities to provide translation but we have adopted another approach which I think align better with ODA and from I've learnt from other experts in content management and user experience.
with ODA, we have a separation between core commerce block and engagement block and decoupling between components.
when you want content and data in different languages, we prefer to decouple and store translation in a CMS.
the product catalogue uses English for convenience but it's never displayed to end users.
a component in charge of showing content, typicallu a front end, but it could a component generating an invoice or an order confirmation makes an API call that will will use the product catalogue entity's id from the product catalogue, i.e. product offering Id, Price Id... and get the translation from the CMS (where the entity id is also mapped).
This approach has multiple advantages:
your CMS is decoupled form the product catalogue, you can manage any languages in isolation of the catalogue
A CMS is very flexible, you can define any translation, but also front-end specific content or any other criteria, context (invoice, order..., user preference, legal name)
Example:
the product name or the price name could be longer on a webpage, shorter on a mobile device, or even shorter or totally different on the invoice line or order confirmation email.
------------------------------
Kind regards,
Matthieu Hattab
Lyse Platform
Original Message:
Sent: Dec 01, 2023 07:42
From: Myagaa Nm
Subject: Language choice in product catalog
Product catalog's data. Domestic customers use their own language. Foreign customers can use english language. Product offers in the catalog can be chosen by domestic or foreign customers. So, I think the catalog should provide same offer in different language based on language parameter in request.
------------------------------
Myagaa Nm
MOBICOM CORPORATION LLC
Original Message:
Sent: Dec 01, 2023 06:20
From: Matthieu Hattab
Subject: Language choice in product catalog
What do you mean by language choice? do you want to see catalogue entity names in another language or its data (product name, description...)?
------------------------------
Kind regards,
Matthieu Hattab
Lyse Platform
Original Message:
Sent: Nov 30, 2023 18:48
From: Myagaa Nm
Subject: Language choice in product catalog
Hello,
I think language choices should be in product catalog. So, product catalog's data model is for one language. Should the data model be extended? What alternative solutions can be?
------------------------------
Myagaa Nm
MOBICOM CORPORATION LLC
------------------------------