Open APIs

 View Only
Expand all | Collapse all

Internationalisation of TMF OpenAPI

  • 1.  Internationalisation of TMF OpenAPI

    Posted Dec 17, 2019 08:44
    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

    ------------------------------


  • 2.  RE: Internationalisation of TMF OpenAPI

    TM Forum Member
    Posted Dec 17, 2019 10:56
    Hi Dan

    You are correct - the TMF Open API team is considering what the best approach to this is - we have an open JIRA issue for national language handling and it has been discussed in recent team meetings. Specifically regarding the catalog APIs (product, service, resource, entity) there will be a need to allow authoring for fields such as name and descriptions for all the relevant entities (not just product spec).

    When we have more news it will no doubt be reflected in updated specifications and guidelines.

    Hope it helps

    ------------------------------
    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.
    ------------------------------



  • 3.  RE: Internationalisation of TMF OpenAPI

    Posted Dec 17, 2019 20:48
    Thanks Jonathan.

    I couldn't find anything relating to language support within 5GC OpenAPI either, certainly nothing within the 3GPP TS 29.501 spec.

    ------------------------------
    Dan d'Albuquerque
    TO BE VERIFIED
    ------------------------------



  • 4.  RE: Internationalisation of TMF OpenAPI

    TM Forum Member
    Posted Mar 08, 2023 02:42

    Hi Jonathan

    Has there been any update on how to support multiple languages, e.g. English and Thai in the catalogs?

    Thanks!



    ------------------------------
    ROCHANA MACHAROEN
    ADVANCED INFO SERVICE PLC. (AIS)
    ------------------------------



  • 5.  RE: Internationalisation of TMF OpenAPI

    TM Forum Member
    Posted Apr 18, 2023 09:13

    We have published some general guidelines for multi-lingual behavior in the APIs as part of TMF630. However the handling for catalog data was not included in the first tranche of guidelines. I have a draft proposal but I have no idea when it will be brought forward, there are other priorities in the Open API time at the moment.



    ------------------------------
    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.
    ------------------------------



  • 6.  RE: Internationalisation of TMF OpenAPI

    TM Forum Member
    Posted Apr 18, 2023 21:34

    Thanks for the reply Jonathan.  Are those updates in the TMF630 v5.0.0 design guidelines?  I can only see v4.2.0 (part 1) which refers to the Accept-Language and Content-Language headers.



    ------------------------------
    ROCHANA MACHAROEN
    ADVANCED INFO SERVICE PLC. (AIS)
    ------------------------------



  • 7.  RE: Internationalisation of TMF OpenAPI

    TM Forum Member
    Posted Apr 19, 2023 06:59

    Yes, it's in v5.0.0, although to be fair the principles for multi-lingual support are really independent of the Open API version.



    ------------------------------
    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.
    ------------------------------



  • 8.  RE: Internationalisation of TMF OpenAPI

    TM Forum Member
    Posted Apr 20, 2023 04:11

    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
    ------------------------------



  • 9.  RE: Internationalisation of TMF OpenAPI

    TM Forum Member
    Posted Apr 21, 2023 06:02

    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.
    ------------------------------



  • 10.  RE: Internationalisation of TMF OpenAPI

    TM Forum Member
    Posted May 04, 2023 06:54

    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
    ------------------------------



  • 11.  RE: Internationalisation of TMF OpenAPI

    TM Forum Member
    Posted May 04, 2023 10:13

    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.
    ------------------------------



  • 12.  RE: Internationalisation of TMF OpenAPI

    TM Forum Member
    Posted May 04, 2023 10:45

    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.

    I quoted IG1228 (use case 12) only for your "I wonder what the process of adding a new product looks like then" question (e.g. product spec, product offering, price...) not for translation.



    ------------------------------
    Kind regards,

    Matthieu Hattab
    Lyse Platform
    ------------------------------