Localizing an Unreal Engine game: an orientation

Unreal Engine's localization workflow is built around a gather-translate-compile cycle: the engine scans your project for user-facing text, collects it into translation files, translators work on those files, and the results are compiled back into a form the runtime loads per active culture. The exact commands, editor panels, and file layout for that pipeline are documented by Epic and change across engine versions, so treat their documentation as the source of truth for the mechanics.

What is more durable, and worth understanding regardless of which version or which project you inherit, is why that cycle exists in the first place and what has to be true of your text before it can flow through it cleanly. That is the focus here.

Text has to be gatherable in the first place

The gather step can only find text that is exposed as localizable text in the first place — not a raw string concatenated together in code, not text baked into a texture, not a debug string never meant to ship. Every studio using Unreal's system ends up with a convention for marking which strings are real, user-facing content versus internal-only, and that convention has to be applied consistently by everyone touching UI and dialogue systems, not just localization-aware engineers.

This is the same underlying discipline every engine needs, described in Unreal's own terms: a piece of text conceptually belongs to a namespace and has a key within it, so the same key can exist under different namespaces without colliding, and the same source text can be tracked and re-tracked across edits without losing its translation history. The exact API for declaring that is worth checking in Epic's documentation rather than guessing at, since it has evolved.

String tables and the shape of a localization file

Conceptually, a string table maps a key to text, the same idea as any string-table-based system in any engine. What differs project to project is how granular the keys are: too coarse (one giant block of dialogue per key) makes partial edits impossible to translate incrementally; too granular (a key per single word) strips translators of the context they need to produce a natural sentence. A reasonable middle ground is one key per complete line or complete UI string, grouped by the screen or scene it belongs to, with a comment or note field carrying context a translator cannot infer from the key alone.

• One key per complete, translatable unit — a full line, not a sentence fragment
• Keys grouped by screen, quest, or character so related text stays together
• Context notes attached wherever a string is ambiguous out of context
• No key ever reused for two different meanings, even if the English text happens to match

Compiled localization data per culture

After translation, Unreal compiles the source text and translations into localization data that ships alongside the build and is loaded for the active culture at runtime. The practical implication for planning purposes is that localization data is a build artifact, not just a set of loose files — which means a translation update generally requires a compile-and-package step before it is visible in a running build, and testing a language usually means testing an actual packaged or compiled state, not just editing a file and expecting an immediate live update everywhere.

Whatever your project's exact toolchain, budget time for that compile step in your update cadence — a translation fix that never gets recompiled into the shipped data is, for the player, no fix at all.

Placeholders, formatting, and plurals

Text built from parts (`Player {playerName} dealt {damage} damage`) needs a formatting mechanism that lets a translator reorder the parts to fit their language's grammar without ever renaming or dropping a placeholder token. Whatever your formatting system's exact syntax, this rule does not change: a placeholder is not prose, it is a contract between code and translation, and the two sides must always agree on the exact token.

Plural forms deserve their own attention beyond simple placeholder substitution — many languages have more grammatical plural categories than English's singular/plural pair, and a translator working from a single flat string with no plural support baked into the key structure has no way to express that correctly.

Fonts, glyph coverage, and text expansion

None of this is specific to Unreal: a font asset renders only the glyphs it contains, so any script your default font was not built for — CJK, Cyrillic, right-to-left scripts — needs a font that covers it, verified by looking at actual rendered text in-game, not a font preview panel. And UI built to fit English text exactly will clip or overflow once translated, since most languages run meaningfully longer or wider than English for the same meaning. Both problems are invisible until you actually put a real (or realistically long placeholder) string into the affected screen.

What to verify before calling a culture done

The gather-translate-compile cycle tells you the text made it through the pipeline; it does not tell you the result is correct. Before shipping a language, verify it directly:

• Every gathered string round-trips through translation without losing its key
• Placeholders in translated strings match the source exactly, just possibly reordered
• The compiled build renders every target script without missing glyphs
• UI holds up under the actual translated string lengths, not just English
• Switching the active culture at runtime updates every screen, including ones cached earlier in the session