Localization for live-service updates

A game with a single release date localizes once, under pressure, and then mostly maintains what already exists. A live-service game never gets that stability: every event, season, and content drop is its own small localization project, on its own deadline, often overlapping with the one before it. The process that works for a one-time launch does not survive contact with a recurring release calendar — it needs to be designed for repetition from the start.

String freeze windows, and what happens when they slip

A string freeze is the point before release where text stops changing so translation has a stable target. For a live-service title, that freeze has to happen before every content drop, not just the big launches, which means the team has to actually hold to a calendar rather than treating the freeze as a suggestion.

Text still changes after the freeze sometimes — a bug fix rewords a line, design tweaks a name late. When that happens, the honest options are limited: hold the string in source language only until the next translation pass, expedite a small correction batch through the translator if the deadline allows it, or accept a short window where that one string ships untranslated. What does not work is silently changing the text and assuming the translation will still match it.

Partial translation states are a real production state, not a failure

On a live-service cadence, it is normal — not exceptional — for some content to reach production before its translation is fully reviewed, or for a language to still be in progress when a build has to ship. Treating this as an emergency every time burns out the team; treating it as a known, designed-for state means you can decide deliberately what a partial state should look like rather than reacting to it after the fact.

Versioning localization alongside the release

Localization files drift from game content the moment either one changes without the other. Tying a localization file's version to the same release or build identifier the game code uses makes it possible to answer a basic but critical question during an incident: which translation is actually live right now, and does it match this build.

release-2026.08.1/
  strings.en.json
  strings.ja.json
  strings.ko.json   # partial — event names only, tracked in the same version

Avoiding an event that launches in mixed languages

The failure mode that live-service teams see most often is an event going live with some UI translated and some not — a banner in English, item names still untranslated, because different pieces of the same event were exported, translated, and imported on different schedules. The fix is procedural, not technical:

• Treat all text for one event as a single batch with one deadline, not several files trickling in separately
• Define, before the freeze, which languages are launching with the event and which are intentionally deferred — and communicate that decision, don't let it be discovered on release day
• Verify the actual build in each shipping language before release, not just the exported text file
• If a language cannot make the deadline, decide explicitly whether it ships in the source language for that event or is held back entirely — a visible, chosen gap reads very differently to players than an accidental one

Designing for the calendar you actually have

None of this is about working faster under pressure. It's about accepting that a live-service game's localization workload repeats indefinitely and building a process — freeze dates on the calendar, a known answer for late changes, versioned files, an explicit per-language launch decision per event — that survives being run every few weeks instead of once.