Localizing Game Interfaces and Text Blocks
German compound words break out of dialog windows? Arabic text flows left to right, breaking the layout? These are not translation bugs—they are technical localization problems. Localization is systematic work with text, fonts, formatting, inflection rules, and UI sizing for each language. A game that is "translated" but not localized looks like machine translation: text overflows buttons, numbers display without locale awareness, and RTL strings don't mirror.
Our team has over 10 years of experience in game development. We have built pipelines for projects with 15 languages, including Arabic, Hebrew, and Chinese. We use Unity Localization—the standard for Unity projects. It works through StringTable (text strings with keys) and AssetTable (localized assets). Tables are exported to XLIFF or CSV for translators.
The key principle: in code and prefabs—only keys, no hardcoded strings. The LocalizedString component on TextMeshProUGUI is mandatory architecture. Violating this means manually searching all text strings across scenes—hundreds of objects when adding a new language.
How Technical Localization Works
Technical localization starts with auditing: we check code for hardcoded strings and UI for inflexible layouts. Then we configure StringTable/AssetTable and link keys to elements. We export to XLIFF for translators, import back with verification. After that—pseudolocalization and testing. For CJK languages we attach Dynamic Font Asset, for RTL—UI mirroring.
Why Pseudolocalization Is Indispensable
Before receiving real translations, we run pseudolocalization: lengthen all strings by 30–40% and add random characters. This reveals container overflow in 2–3 days instead of discovering it during translation integration. Without pseudolocalization, you risk encountering bugs two weeks before release. Comparison: pseudolocalization is 3 times more effective at detecting overflow issues before strings are sent to translators, whereas real translations only catch them after import.
What Is Dynamic Font Asset and Why Do You Need It?
For Chinese, Japanese, and Korean, static font atlases weigh 15–30 MB. Dynamic Font Asset loads only glyphs encountered in text, reducing memory to a few hundred kilobytes. The downside is micro-stutters (0.5–2 ms) when first rendering a new glyph, but this is acceptable for mobile projects.
| Feature | Static Font Asset | Dynamic Font Asset |
|---|---|---|
| Memory | 15–30 MB | 0.5–2 MB (depends on text) |
| Micro-stutters | No | Yes (0.5–2 ms on new glyphs) |
| Setup complexity | Ready atlas | Requires Unicode range specification |
For Arabic and Hebrew, RTL support is mandatory. TextMeshPro has a built-in RTL mode (TMP_Text.isRightToLeftText = true), but one flag is not enough. UI elements must also mirror: the "Back" button moves from left to right, lists read from right to left. This requires special logic in Layout Manager or switchable prefabs with mirrored layout for RTL languages.
From our practice: on a project with Russian, English, and German, we encountered that German compound words (e.g., Geschwindigkeitsbegrenzung) do not hyphenate in TextMeshPro by default. Solution—Hyphenation via TMP_Settings + connecting a hyphenation dictionary for German. After configuration, text wraps correctly, the dialog container no longer overflows.
Estimated Timelines
| Scale | Timeline (excluding translation time) |
|---|---|
| Adding one language to existing pipeline | 3–7 days |
| Building a localization pipeline from scratch (1–2 languages) | 1–3 weeks |
| Full localization of project (5–10 languages, including RTL) | 4–10 weeks |
| Integration with external CAT tools + automation | 1–3 weeks |
Typical Mistakes in Localization
- Hardcoded strings in code and scenes—when adding a language, they must be found manually.
- Missing RTL UI mirroring—Arabic text flows left to right, breaking navigation.
- Ignoring plural forms—Russian has three numbers, English two, Arabic six.
- Not using pseudolocalization—overflow bugs are only discovered after translation integration.
What Our Work Includes
We provide a full localization cycle turnkey:
- Audit of current code and UI for localization readiness.
- Setup of Unity Localization pipeline (or equivalent for Unreal Engine).
- Creation of StringTable/AssetTable, integration with CAT tools.
- Development of Dynamic Font Asset for CJK and RTL languages.
- Pseudolocalization and UI overflow testing.
- Automation of translation import/export.
- Documentation on localization maintenance for the team.
Contact us for an audit of your project—we will find the optimal solution. Get a consultation from a localization engineer to avoid typical mistakes and reduce time to market for new regions.