I18n Text & Translation

The I18n Text & Translation tool integrates the internationalization (i18n) framework as a core part of its environment for creating, managing, and binding global i18n models. The framework treats global text and translation resources as standard platform artifacts, allowing you to maintain and reuse localized content consistently across multiple applications.

Each global i18n model defines translatable text attributes as structured key–value pairs enriched with metadata such as field type, length, and description. These models serve as centralized repositories for text definitions and translations, ensuring that shared terminology and corresponding translations remain synchronized across applications and environments.

By using the I18n Text & Translation tool, the platform maintains a clear separation between text resources and application-specific configurations. This separation ensures that translations remain consistent, reusable, and easily updated without requiring changes to individual applications.

Model creation and binding

When you create a new global i18n model in the I18n Text & Translation tool, you define its structure, supported locales, and translation entries directly within the tool. You can enhance existing global models to extend or override specific text attributes while preserving the original base model.

Once defined, you bind components from supported tools to these global i18n models, enabling applications to reference the same translation resources through consistent keys. The tool automatically manages model relationships, versioning, and locale availability, ensuring proper linkage between source text and translations during configuration, deployment, and runtime.

You can bind global i18n models to the components of the following tools to ensure centralized localization:

  • App Designer

  • Adaptive Designer

  • Documentation

  • Email Template

  • Launchpad

  • Tile

  • Tile Group

Global i18n model enhancement

When you enhance a global i18n model in the I18n Text & Translation tool, you create a derived version of an existing model that inherits all its text attributes and translations while allowing you to override specific entries without altering the original. The enhancement references the base model, preserving its metadata and structure, but lets you update selected text values or translations for certain locales.

This process is typically used to adapt wording for regional or contextual differences, introduce controlled customizations for specific projects, or test translation updates without impacting the shared base model. During deployment, applications automatically detect and use the enhanced values, ensuring that localized adjustments are applied, while maintaining consistency and traceability with the original global i18n model.

Translation and fallback behavior

When i18n locales are added to a 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:

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

  2. 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 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 global model.

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

Related topics