Localizing a game that is still changing: an early access approach

Early access games change constantly by design — that is the point of the format. But full localization assumes text that is close to final, and translating a script that gets rewritten next week means paying to translate the same idea twice. Treating early access localization the same way you would a finished game's launch localization is a common way to waste both money and translator goodwill.

The alternative is to treat localization as an ongoing process that tracks the game's own instability, rather than a one-time project that assumes the text is done.

Why an unstable script makes full translation wasteful

Translating a line is not free even when the line is short — it takes a translator's attention, and often review time on top of it. If that line gets cut, rewritten, or replaced in the next update, that work is lost, and worse, the translated file now has to be reconciled against a source that no longer matches it.

The more a system, mechanic, or piece of narrative is still being redesigned, the higher the odds its text changes again soon. Translating that text early is a bet that it will not — a bet you lose disproportionately often in early access, where redesigns based on player feedback are the whole point.

What to localize first

Not all text carries the same risk of changing. A practical way to prioritize:

• UI and menu text tends to stabilize early, since interface conventions settle before content does — a safe early target
• Core systems that define the game's identity and are unlikely to be cut entirely, even if details are tuned
• Onboarding and tutorial text, since new players hit it first and it shapes their whole impression of the language quality
• Content still being actively redesigned or that might be cut — worth leaving for last, or leaving out of this pass entirely

Treat each build as a delta, not a whole

Instead of asking a translator to translate the entire current script every update, hand over only what changed since the last translated version — new lines, edited lines, and lines that were removed. This is both cheaper and safer: a translator working on a delta reviews a small, focused set of changes instead of re-reading a whole script and risking inconsistent edits to lines that did not need to change.

This only works if you can reliably identify what changed. That means keeping a stable identifier for each line of text that survives edits to the line's content, so a change in wording is tracked as an edit to an existing line rather than showing up as an unrelated new line with no history.

Keep a baseline so translators only see what changed

A baseline is the last version of the text that was fully translated and reviewed. Every future delta is compared against that baseline, not against the version before it, so changes do not silently accumulate untracked between translation passes.

Keeping a clear baseline also protects the translator's context: they can see exactly which lines are new versus edited versus untouched, rather than having to guess by re-reading everything. Without it, small changes get buried in noise and are easy to miss during review.

Communicate the state of each language honestly

Because different languages may be caught up to different points in an evolving script, players deserve to know what they are actually getting. A store page or in-game language selector that implies full parity between languages, when one language is several updates behind, sets an expectation the game does not meet.

Simple, honest signals — a note on which languages are current as of the latest update, or which sections of the game are known to still be in the original language — cost little and prevent the kind of review backlash that comes from players discovering untranslated text they were not warned about.