UI strings and i18n

UI strings are separate from product content translations. Product content lives with authored records such as tours, tiles, and events. Application chrome, including buttons, navigation, and errors, ships as keyed translations resolved at runtime.

Runtime loading

Locale JSON files are grouped by namespace (for example shared chrome, dashboard-only strings, guest-app strings). Loaders fetch the relevant bundle for the active locale and merge legacy aliases where deployments still map older locale codes.

If a bundle fails to load, the UI falls back to displaying keys visibly so missing translations surface during QA rather than crashing pages.

Namespaces

Namespaces keep payloads small:

• Shared fundamentals reused everywhere.
• Dashboard-specific copy.
• Guest-app-specific copy.
• Marketing or landing-specific bundles where split packaging helps performance.

Adding copy

Declare stable keys and resolve them through your surface’s translation helper, for example t("settings.section.label") in localized React apps. Avoid dynamic key construction so static extraction can find strings.

Guidelines teams follow internally:

• Avoid constructing keys dynamically—static analysis needs to see literal keys.
• Prefer interpolation placeholders instead of concatenating translated fragments.
• Keep gender-neutral wording.
• For German copy, avoid informal direct address so tone stays neutral across audiences.

Workspace automation scans repositories, proposes missing keys, and syncs locale bundles—details belong to engineering onboarding, not this public reference.

UI copy versus product content

• Operator-authored values guests read on a published page → product translation workflow.
• Labels belonging to the application itself → UI string workflow with explicit keys.
• Mixed sentences should keep fixed grammar in UI translations and pass authored names or numbers as variables.

Related concepts: How translations work, Automatic translation, Languages and localization.