CalmUI
Unreal Engine

Localization

Supply compiled Unreal translations without letting Studio change the game language.

Start with Translate Your UI for the Studio workflow, required defaults and Languages panel.

Unreal owns translations

$loc('GameUI::MainMenu.Continue', 'Kontynuuj') resolves a registered String Table ID and entry. Keys without ::, such as Hud.Health, address the CalmUI text namespace.

Compile the game's localization target and stage its required cultures. String Tables must be loaded/registered before their entries can be inspected. Compiled project resources are read from Unreal's configured game localization paths. Source hashes are checked against registered String Table source text, so a stale resource is not reported as a current translation.

Culture lookup distinguishes exact translation, parent-culture translation, source text and missing data. Display-string equality is never used to decide whether a translation exists. Missing data uses the authored default.

Studio is read-only

A compatible plugin exposes the project culture catalog and batch lookup. The Studio selector does not call global culture setters or modify translation assets. It only changes the Studio canvas. The Unreal-rendered preview continues to show the actual game language.

Changing language through your own Unreal game logic refreshes open CalmUI screens and their layout. Component identities and compatible state remain. Include fonts that cover the translated text.

Advanced: dynamic text providers

Compiled resources and String Tables do not require CalmUI gameplay C++. If your project deliberately registers dynamic polyglot texts in C++, register them through FCalmUiLocalization::RegisterPolyglotText. This forwards to Unreal's text manager and retains explicit per-culture presence for read-only inspection. It belongs to the CalmUiRenderer integration module.

Unreal's global display-string API does not expose arbitrary-culture presence for third-party dynamic providers. Such providers need an explicit adapter; a fallback string cannot safely be treated as a found translation.

Shipping loads key/default expressions from the compiled package. Studio, component sources and the development protocol are not required by that path.

Script-side loc()

A component script (<script lang="ts">) calls the same lookup through loc(key, fallback, params?). It resolves through the identical host culture resolver as template $loc() expressions, so a key with ::, such as Sandbox::Script.LastSave, splits into a String Table ID and entry the same way, and a bare key addresses the CalmUI text namespace the same way. A result a script cached in a computed/watch re-resolves the next time the host applies a culture change, right before it refreshes the view's template-side localized text, so script and template text never disagree about which culture is showing. This works with component sources absent, the same Shipping-package path described above.

On this page