Skip to main content Skip to complementary content

Language

Availability-noteDeprecated
This section describes the Talend MDM language settings.

Requirements to use multiple languages with Talend MDM may be considered for:

  • The Talend MDM Web UI
  • The MDM models viewed with the Talend MDM Web UI
  • The master or reference data itself

Talend MDM Web UI

The Talend MDM Web UI comes with a number of built-in language translations.

The language is defaulted from the localization of the user's browser, or it can be set when configuring a user.

It is possible to add additional languages to the list, but this is out of scope for this document.

MDM models viewed with the Talend MDM Web UI

The MDM models viewed with the Talend MDM Web UI use the language settings defined above.

Labels, facet messages, descriptions, etc., can all be configured with multiple language translations.

Master or reference data

There are two approaches to set language settings with MDM modelling. The first is the built-in approach: to use the 'MULTI_LINGUAL' custom simple type supplied by Talend. Here is how it works:

The translation displayed to the user depends on the language selected for the Talend MDM Web UI. However, all translations are stored underneath, if the data is accessed using the integration layer.

<newEntity>
    <newEntityId>1</newEntityId>
    <multiLingualExample>[EN:cheese][ES:queso][FR:fromage]</multiLingualExample>
</newEntity>

Notice the use of the format [<LANG>:<DATA>]. In the integration layer, there are special functions supplied to help construct this format.

In the physical storage, a multilingual field is stored in a long text format, MySQL for example.

As before, Oracle is the exception to this with a limit of 4000 characters for all translations, including the characters needed to define each translation, the square brackets for example.

The second approach to mastering translations is to incorporate a data structure that is extensible by the user, or integration layer, at runtime.

In this example, you can see that the user can supply one to many translations of a given piece of data. As well as mastering languages using a foreign key, this particular example also links a translation to a given country. This is optional depending on your business logic. Some implementations will also incorporate other entities that may define rules as to what translations would be required in a given set of business circumstances. For example, a product sold in Poland must have English and Polish translations of the product descriptions. These types of rules are typically enforced by the integration layer.

Did this page help you?

If you find any issues with this page or its content – a typo, a missing step, or a technical error – let us know how we can improve!