Localize

Pulls a custom string’s translated text into an expression. It’s the same text_* system that drives captions, choice text, and node titles, but callable anywhere an expression is: a Value (expression) field, a condition, a template, and so on.

Category: Localization Returns: string

Signature

Localize(key)

The argument is a custom-string ID: the writer-facing handle (text_greeting, text_alex_intro_letter), written without quotes. The runtime returns whichever translation matches the project’s currently active locale, falling back to the source text when no translation exists for that locale.

Examples

Localize(text_alex_intro_letter)        // translated body of the letter
Localize(text_greeting) + " " + Localize(text_player_name_suffix)
                                        // build a localized string from two parts
Localize(text_quest_blurb)              // current locale's version of the blurb

Notes

Typing a text_* id that doesn’t exist yet triggers a validation error telling you to create it in the Localization data view, so a typo gets caught while you’re writing, not after the game ships. If a stale or mistyped key ever does reach the runtime unchecked, Localize() doesn’t throw: it falls back to showing the raw key text (something like text_missing_line) in place of a translation, a visible sign that something is wrong.

Localize() is also safe to call when no localization has been loaded at all. Studios that don’t ship translated locale files still get correct output: the function returns the source text you originally wrote for that custom string.

The key is the custom-string ID (a text_* identifier), not a path or a translation key in the host engine’s localization system. Per-locale translations for custom strings are authored from the Localization data view, one set of translations per locale.