Multilingual UI

Six locale translations for the ODD Platform UI shell — loaded at SPA bootstrap, switched via the toolbar, persisted per browser in localStorage. Operator-authored content stays verbatim.

The ODD Platform UI ships with six locale translations loaded at SPA bootstrap. Users switch the active locale from the user-account menu in the top-right of the toolbar; the choice persists per browser device in localStorage. The platform's API surface remains English-only — the localisation applies to the UI shell (toolbar labels, page titles, button captions, form field labels, error messages); operator-authored content (entity descriptions, glossary terms, custom-metadata field names, namespaces, tag names) is rendered verbatim regardless of the active locale.

Supported locales

The platform's translation table currently includes six entries, sourced from odd-platform-ui/src/locales/translations/:

Code	Language
en	English (default)
es	Spanish
ch	Chinese
fr	French
ua	Ukrainian
hy	Armenian

The default is en — a fresh browser session with no prior locale selection lands on English.

How users switch

The active locale is changed from the user-account menu in the top-right of the toolbar — the area showing your username next to a dropdown arrow. Click it to open the account dropdown (the same menu that holds Logout), then click the Select language entry — it shows the current language and a chevron. That opens a Select language dialog with one searchable entry per supported locale. Picking a locale takes effect immediately on the current page; subsequent SPA navigation continues in the chosen locale.

Persistence model — per-device, not per-user-account

The chosen locale is stored in the browser's localStorage under the key i18nextLng. The implications operators should know:

• Per browser device. The locale preference is bound to the browser profile, not to the user's catalog account — signing in from a different browser, a different machine, or an incognito session starts from the default (en) until the user picks again.

• Survives logout and re-login. The localStorage value is not cleared by sign-out; the next sign-in from the same browser resumes the prior locale choice.

• No server-side propagation. The platform does not record the user's locale preference on the server, does not honour an Accept-Language HTTP header, and does not push the choice to other devices the same user is signed in on.

If the deployment serves a user population that uses multiple devices and expects a single, account-bound locale choice — for example a company-managed account propagating across the user's laptop and phone — this is a known absence; the per-device localStorage model is the only persistence path today.

Known caveat — missing translations fall through to English

Each locale's translation table is a snapshot, and the platform has added UI surfaces over time. The keys use the English text itself as the lookup key (for example "Activity": "Activity"), and when a key a component asks for is missing the renderer falls through to that key string — the raw English label, shown with no warning and no visible marker. This affects a substantial set of strings: about 70 code-referenced keys are absent from the translation tables (a June 2026 sweep of the UI source's translation lookups counted 70 keys with no catalog entry), so a non-English locale shows English text in those spots.

The sharpest instance of this gap is fixed: the three top-level navigation tabs — Data Quality, Data Modelling, and Master Data — were absent from all six bundles, English included, so every non-English locale rendered them as raw English beside six translated sibling tabs. odd-platform#1748 added the three keys to every bundle — all nine toolbar tabs (Catalog, Directory, Data Quality, Data Modelling, Master Data, Management, Dictionary, Alerts, Activity) now translate. On releases that predate that fix, those three tabs always render in English regardless of the chosen locale.

One consequence worth calling out for completeness audits: because the missing keys are the English label itself, an English-locale UI looks fully translated even where a string never passes through the translation table. Operators evaluating localisation completeness for a particular locale should treat the translation-table JSON files as the source of truth, not the running English UI. Contributors filling in missing keys are welcome (see How to contribute a new locale below — adding missing keys to an existing locale is the same workflow as adding a new locale, applied to the JSON file that already exists).

How to contribute a new locale

Adding a seventh locale (or any subsequent locale) is a contributor-facing workflow on the UI repository (odd-platform). The shape:

1. Create a new translation file at odd-platform-ui/src/locales/translations/{code}.json (where {code} is the locale code — typically the 2-letter ISO 639-1 code, or the project's own short code such as ch for Chinese). The file mirrors the structure of the existing translation files; the simplest start is to copy en.json and translate each value.

2. Register the locale in the bootstrap module at odd-platform-ui/src/locales/i18n.ts — add the import and add the entry to the resources map (and, to keep it consistent with the others, add the code to the fallbackLng array). The resources map is what populates the picker, so this step is what makes the locale selectable.

3. Add the new code to both maps in odd-platform-ui/src/lib/constants.ts — LANGUAGES_MAP (code → display name, shown in the picker) and LANG_TO_COUNTRY_CODE_MAP (code → flag country code). These are required: the Select language dialog renders each row by looking the code up in these maps, and a code that is missing from LANGUAGES_MAP will break the picker. The Lang type is derived from LANGUAGES_MAP, so adding the key here is also what makes the rest of the code recognise the new locale.

4. Open a pull request against the UI repository. The contribution does not require platform-API changes, and the Select language dialog needs no edits — it builds its list from the registered locales automatically.

The build-and-run workflow for the platform (including the frontend UI) is documented at Build and run ODD Platform.

Where to next

• Management — the operator surface inside the platform UI; the localisation applies to the Management section's tab labels and form controls.

• Main Concepts → Terms & Aliases — the alias registry where "Multilingual UI", "i18n", "internationalisation", and "locale switching" point at this page.