i18n (binding of translatable attributes in the App Designer)
The App Designer integrates the internationalization (i18n) framework for the translation of application label elements as a built-in layer of the design environment. The framework treats text and translation models as standard design artifacts, allowing you to work with localized content directly within application configurations.
Each i18n model defines translatable text attributes as structured key–value pairs enriched with metadata such as field type, length, and description.
By embedding i18n into the App Designer, applications maintain a clear separation between user interface elements and their textual content, ensuring that text resources remain consistent, reusable, and centrally maintained.
Model creation
When you activate an application, the App Designer automatically creates an app-specific local i18n model associated with that application. This model holds text and translation data specific to the app. You can also create and connect the application to global i18n models stored in the i18n Text & Translation tool of the Cockpit.
If you enhance a local or global i18n model, the App Designer tracks the enhancement as part of the same design structure, ensuring the correct hierarchy and relationships between models.
Translation and fallback behavior
When i18n locales are added to a local/global model, the system follows specific rules for handling untranslated entries and fallback values for attributes. These rules determine whether empty strings or fallback text are displayed on the end-user interface:
-
Untranslated entries in an i18n locale render as empty strings
If you add an i18n locale to a local/global model for an attribute but do not provide all translations for it, the system records original technical attribute names or empty strings for the untranslated entries. These empty strings are treated as valid values, so the fallback locale entries are not used.
To ensure proper display of labels, provide translations for all entries of all i18n locales of attributes that you want to appear as labels on the end-user interface. -
Fallback mechanism occurs only when an i18n locale is not configured
The system reverts to entries made in the Fallback Locale column only if you did not add a certain i18n locale at all to the local/global model that is selected for display on the end-user interface. Once an i18n locale exists, its presence takes precedence (even for partially untranslated entries), so entries made in the Fallback Locale column do not apply.
To ensure the fallback mechanism works as expected, only rely on fallback for any i18n locales you do not intentionally add to the local/global model. -
Fallback Locale column must be properly filled
You must fill the Fallback Locale column to provide values when reverting to fallback. If this column is incomplete or contains empty strings, untranslated entries revert to original technical attribute names. If you create a new attribute, the text from the Base Text column is automatically added to the Fallback Language column. If you edit an existing attribute, you can select the checkbox Also update fallback language translation, that lets you decide whether to add it to the Fallback Language column.
To avoid blank labels or labels that show original technical attribute names, make sure every entry in the Fallback Locale column contains text.