Localizing a Unity game: an orientation

Unity has an official localization package built around the concepts every engine eventually needs: a list of locales your game supports, tables that map a key to a translated string per locale, and a way to swap the active locale at runtime so UI and dialogue update immediately. If you have not used it yet, its own documentation is the right place to learn the exact setup, component names, and import steps — those details change between versions and are not worth memorizing secondhand.

What is worth understanding up front, and what stays true no matter which tool you end up using, is the shape of the problem: text has to leave your scenes and scripts, live somewhere translators can work with it, and come back into the game through a lookup rather than a hardcoded value. This article focuses on that part.

Get text out of scenes and scripts first

The single most common mistake in a first localization pass is text typed directly into a UI Text or TextMeshPro component in the scene, or a string literal buried in a script. Both are invisible to a translator and easy to miss during an audit. Before anything else, every player-facing string needs a stable key and a single home — a string table, a CSV, a JSON file, whatever your pipeline uses — so there is exactly one place to find and change it.

A key is not the English text. Using the source string as its own key (a common shortcut) breaks the moment you need to edit the English copy, because the key changes and silently orphans every existing translation. Pick short, stable identifiers instead, grouped by screen or system, for example:

menu.settings.title
dialogue.chapter1.guard_01.line_03
item.potion_health.name

Placeholders and formatting

Almost every game has strings built from parts — a player name, an item count, a damage number. Whatever formatting mechanism your engine or library uses for this, treat the placeholder syntax as sacred: a translator can and should reorder placeholders to match their language's grammar, but must never rename, delete, or duplicate one. A dropped or mistyped placeholder is a runtime error at best and a silently broken string at worst, and it is exactly the kind of thing that is easy to catch with an automated check and easy to miss by eye across thousands of lines.

Numbers and dates deserve the same caution. Plural forms differ across languages far more than English's simple singular/plural split, and a translator working from a flat string cannot fix a plural rule that your key structure does not support.

Fonts and glyph coverage

This is where localization work stops being purely a text problem. A font asset only renders the glyphs baked or referenced in it. If you add Japanese, Korean, Chinese, or any script your default font does not cover, missing glyphs render as blank boxes or tofu squares — not an error, just silence, which makes it easy to ship without noticing in a screen you did not personally check.

Plan for this early: identify which languages you are targeting, confirm your font (or font fallback chain) actually covers the character sets those languages need, and budget time to test rendering in-game, not just in a font preview tool. CJK fonts in particular are large; if your build size matters, look into subsetting or dynamic font loading rather than discovering the problem at the end.

Text expansion and UI layout

English is often the shortest version of a given piece of UI copy. German and Finnish are commonly cited as languages whose translations run noticeably longer for the same meaning; Japanese and Chinese can be shorter in character count but wider per character. A button sized exactly to fit its English label will clip, wrap awkwardly, or overflow the moment it is translated.

Build UI with room to breathe from the start: auto-sizing text elements, containers that can grow, and truncation or scaling rules you have actually decided on rather than ones that happen by accident. Testing with a deliberately long placeholder string in every supported language's approximate length, before real translations arrive, catches most of these problems early.

Testing language switching in-game

A locale switch that only updates on scene reload is a common early bug — dialogue already on screen, tooltips, or cached strings can be left showing the old language. Test switching languages mid-session, not just at a title screen, and check every screen a player can reach: pause menus, settings, tutorials, and any text embedded in textures or video rather than as real strings (which cannot be localized through your string system at all and needs its own plan).

• Every player-facing string has a key and lives in one place, not scattered across scenes and code
• Placeholders are checked automatically, not just read over by eye
• Fonts are verified in-game for every target script, not just previewed
• UI has been stress-tested with long strings before real translations exist
• Language switching is tested mid-session, across every reachable screen

Before you ship

None of the above depends on Unity specifically — it is the same checklist for any engine with a string-table style localization system, and it is where most real localization bugs live. Treat Unity's own localization documentation as the source of truth for setup mechanics, and treat this list as the source of truth for what to verify before you consider a language done.