Plan for localization before you build your game

You are planning a game. Maybe there is a design document, maybe there is a prototype, maybe there is only an idea and a folder. Translation feels like a problem for a future version of you, possibly one that never arrives — plenty of games ship in one language and do fine. That is a perfectly reasonable position, and this article does not argue against it.

The catch is that the decisions which make translation cheap or ruinously expensive are made now, at design time, by people who are not thinking about translation at all. They are decisions about where text lives, what your UI assumes about text length, which font you fall in love with, and whether words end up inside your art files. Almost all of them cost nothing to make in the localization-friendly direction, and a serious refactor to reverse.

So this is not a request to commit budget or pick languages. It is a list of doors to leave open. A project built with these habits can add a language in weeks; a project built without them may need work touching every scene before the first word is translated.

Decide that text leaves the code — even for one language

This is the single highest-value decision on the list, and it is a habit rather than a system: player-facing text is never typed directly where it is used. It lives in a table or a resource file under a stable key, and the code asks for it by key. Adopt this on day one and it costs a few extra seconds per string. Adopt it after twenty thousand lines of code and it becomes an archaeology project with no reliable finishing point, because nothing in your codebase distinguishes a player-facing sentence from a log message or a debug label.

The benefits arrive long before any translation does. You can fix a typo without hunting through source files. You can see every message the game shows, in one place, and notice that you have written the same warning three slightly different ways. You can produce a word count on demand, which is the first thing anyone will ask you for if you ever request a translation quote. And your writer, if that is a different person from your programmer, can work without touching code.

The format matters far less than the discipline. Comma-separated values, JSON, an engine's own string table — any of them work, and you can migrate between them later far more easily than you can extract strings from code. What matters is that from the first commit, there is exactly one place a player-facing sentence can be, and that debug and log text stays out of it.

Pick provisional languages as constraints, not commitments

You do not need to know that you will ship Chinese. You need to know whether you might. The list you write down at design time is not a budget line; it is a set of technical constraints that quietly determine several other decisions, and writing it down costs one paragraph in a document.

Three properties of that list actually matter early. First, character coverage: if any candidate language uses Chinese, Japanese or Korean characters, your font requirements change by orders of magnitude and so does your rendering setup. Second, text expansion: translations from a compact source language into German or Russian tend to run visibly longer, while Japanese often runs much shorter, so your UI has to tolerate both directions. Third, writing direction: Arabic and Hebrew are written right to left and require the interface itself to mirror, which is the most expensive property to retrofit of anything in this article.

So write the honest version: which languages are plausible, which are unlikely, and which are explicitly out of scope. Saying 'right-to-left languages are out of scope for this project' at design time is a legitimate, defensible decision. Discovering the same thing two months before launch because a publisher asks is not.

Fonts are a pipeline decision, not a styling one

Choosing a display font late is normal when you only ship one language. It stops being normal the moment another script is possible. A font covering basic Latin characters and a font covering Japanese differ enormously in file size, in licensing terms, and in whether they can be embedded or subset for distribution. A beautiful hand-lettered display face may simply not exist in a version that can render a Cyrillic or CJK string at all.

Three questions are worth answering while the UI is still sketches. Does the interface font need to cover the scripts on your provisional language list, or will you swap fonts per language? What happens when a glyph is missing — do you have a fallback chain, or does the player see empty boxes? And does the font's licence permit embedding it in a commercial game and, if relevant, subsetting it to keep the build small?

Pixel and other highly stylised fonts deserve a specific warning, because they are so common in indie games and so often have narrow character coverage. A pixel face designed for English usually has no Japanese characters at all, and the ones that do exist have a minimum legible size that may be larger than your UI assumes. If a pixel aesthetic is core to your game, resolve this early rather than treating it as a text problem to solve after the art is locked.

Build UI that stretches, and keep words out of your art

Assume every string can arrive substantially longer or shorter than the one you designed around. That means labels that size themselves rather than sitting in fixed-width boxes, text areas that can wrap to another line without covering something, and layouts that do not depend on a specific number of characters fitting on a specific row. This is ordinary responsive-layout discipline; it just tends to be skipped when there is only one language and every string is known.

You can test this before any translation exists. Fill your interface with padded placeholder text — the same message with extra characters and a few accented letters — and walk through every screen looking for clipping and overlap. This technique is called pseudolocalization, and its whole point is that it finds layout failures at design time, using no translator and no budget.

Text baked into image assets is the other half of this. A logo, a signpost, a tutorial diagram, a button with the word painted on it — each one becomes a re-export per language, done by whoever owns the source art file, which is a very different cost from editing a row in a table. Decide per asset, as you make it: is this text that a player reads and would need translated, or is it decoration that happens to look like letters? Text that is really text should be drawn by the engine over the image, not painted into it.

Name your keys once, on purpose

A key naming scheme takes five minutes to choose at the start and is genuinely painful to change later, because every rename has to be applied in every language file at once or translations silently detach from their strings. Choosing badly is not fatal, but choosing accidentally usually is annoying forever.

Two rules cover most of it. Make keys hierarchical, so related strings sort together and you can see at a glance which screen a key belongs to. And make them semantic rather than derived from the source wording, because a key generated from an English sentence has to be renamed the moment you edit that sentence — and renaming keys is exactly the operation you want to avoid.

Alongside the naming scheme, decide the file layout: one file per language with all keys, or one folder per language split by feature. Either works. What causes trouble is having no rule, so that six months in you have three files with overlapping contents and no way to tell which is authoritative.

# Stable, hierarchical, semantic — survives copy edits
ui.shop.button.buy
ui.shop.error.insufficient_gold
dialogue.ch01.mira.greeting_first

# Derived from the English wording — has to be renamed
# every time a writer changes the sentence
buy_this_item_now
not_enough_gold_error

What deferring all of this actually costs

It is worth being concrete about the difference, because 'we will handle it later' sounds like deferring a task when it is really trading a habit for a project. Done from the start, all of the above is a set of small conventions the team follows while building normally. Done afterwards, it becomes a sequence of jobs with an uncertain end: finding every literal string in the codebase, discovering the places where sentences are assembled from fragments and redesigning them, re-authoring UI that assumed the source language's text length, re-exporting art with words in it, and then re-testing every screen because you touched all of them.

The scheduling problem is worse than the work. Retrofitting almost never happens in a calm month. It happens when there is a release date, or a translator waiting to start, or a publisher who has already announced the languages — which means the least reversible engineering work in the project gets done under the most time pressure.

None of this is an argument that you must localize. It is an argument that the cost of keeping the option open, at design time, is close to zero — and that this is the only period in a project where that is true.

So if you write nothing else into the design document, write the list below. It fits on one page, and every item on it is a decision you can make today without knowing whether your game will ever have a second language.

• All player-facing text lives in an external table or resource file, keyed, from the first commit
• Debug, log and developer text is deliberately kept out of that file
• A provisional language list exists: plausible, unlikely, and explicitly out of scope
• Font choice accounts for the scripts on that list, with a stated fallback for missing glyphs
• Font licences permit embedding in a commercial build
• No UI element assumes a fixed character count; every label can wrap or resize
• Words a player must read are rendered as text, not painted into image assets
• A key naming scheme and file layout are written down before the second person joins
• Sentences are never assembled from fragments at runtime; variables use named placeholders