Game Interface and Text Localization

Game Interface and Text Localization

Localization is not translating strings to table. It's systematic work with text, fonts, formatting, declension rules, and UI element sizes for each language. Game that's "translated" but not localized looks like machine translation: text overflows buttons, numbers display without locale awareness, Arabic text goes left to right.

Technical Localization Pipeline in Unity

Standard for Unity projects now—Unity Localization package (com.unity.localization). Works via StringTable and AssetTable: StringTable stores text strings with keys, AssetTable—localized assets (textures, audio, fonts). Tables export to CSV/XLIFF for translators and import back.

Key principle: code and Prefabs contain only keys, no hardcoded strings. LocalizedString on TextMeshProUGUI component with StringTable binding—mandatory architecture. Breaking this rule means adding new language requires manually finding all text strings across scene—hundreds of objects.

Plural Rules—separate pain. Russian has three number forms: "1 item," "2 items," "5 items." English—two. Arabic—six. Unity Localization supports Plural via Smart String with {count:plural:item|items|items} format, but rules for each language must be explicitly set via Plural Rule Provider or use ready rules from CLDR (Common Locale Data Repository).

Dates and numbers: 1,234.56 (EN) vs 1.234,56 (DE) vs 1 234,56 (RU). Without explicit CultureInfo use when formatting in C#, numbers display in system locale device—unpredictable. All numbers, currencies, dates must format via string.Format(CultureInfo.GetCultureInfo(currentLocale), ...) or Smart String with format {value:C} with explicit locale binding.

Fonts for Different Languages: Most Underestimated Problem

CJK (Chinese/Japanese/Korean) font for TextMeshPro—Font Asset with tens of thousands of glyphs. Full CJK Font Asset in SDF can weigh 15–30 MB just for texture atlas. For mobile project with memory budget, unacceptable.

Solution: Dynamic Font Asset with Population Mode → Dynamic. Atlas fills only with actually used glyphs. On first launch, memory holds only hundreds of used characters. Minus—possible microfreezes (0.5–2 ms) on first render of new glyph. For most games acceptable.

For Arabic and Hebrew, RTL (right-to-left) support mandatory. TextMeshPro has built-in RTL mode, activated via TMP_Text.isRightToLeftText = true. But flag alone insufficient: UI elements must mirror too (Back button moves from left edge to right, list reads right to left). Requires special logic in Layout Manager or switchable RTL-layout Prefabs.

Case Study: Cyrillic and Word Wrapping

Project supporting Russian, English, German encountered German compound words (Geschwindigkeitsbegrenzung—"speed limit") not wrapping in TextMeshPro by default, just overflowing or jumping to new line whole. Broke dialogs: fixed container size, text went below edge.

Solution: Hyphenation via TMP_Settings → Enable Word Wrapping + connecting German hyphenation dictionary via custom TMP_HyphenationDictionary. Dictionary format compatible with LibreOffice standard (TeX hyphenation patterns). After connecting, German text correctly wrapped by rules, dialog container stopped overflowing.

Tools and Translator Integration

Translators don't work in Unity. Standard workflow: Unity Localization → export StringTable to XLIFF 1.2 or CSV → send to CAT tool (Phrase, memoQ, SDL Trados) → receive translated XLIFF → import back to Unity. Cycle must be automated via Editor script, else manual import 15 languages × 20 tables = hours per string update.

Formatted strings (Smart String with placeholders {name} or {count}) must have translator instructions: placeholder meaning, phrase part where it can move. In German {count} Gegenstände gefunden—placeholder at start, normal. In Japanese word order different, placeholder end. CAT tools support placeholder protection from accidental translation.

Localization Testing

Pseudolocalization—running UI with test strings of increased length and random characters. Unity Localization has built-in Pseudo Locale with string extension option 30–40% (typical for German and Finnish vs English). Run pseudo-locale before real translations arrive—text overflow problems visible immediately.

Missing Translation check: Unity Localization logs missing keys to Console with warning, but in production must output fallback value, not empty string. Configured via Localization Settings → Missing Translation Behavior.

Cost calculated individually after analyzing string volume and supported languages.