These failures rarely come from translation alone—they come from weak version control, unclear content status, inconsistent terminology, or missing regression testing. This companion to The Complete Game Localization Workflow lays out an update workflow that keeps localization consistent as the game grows.
How do you update a game without breaking its translations?
In this clip, Yana Tarasevich explains how glossaries and translation memory keep patches consistent. From her Level Design Lobby conversation with Max Pears.
Translating a game doesn’t end with translating what’s in it—we deal with updates, patches, and in-game information. After the main content is translated, we already have assets that keep everything consistent: for every game we have a glossary with the main terms—names of characters, items, achievements—and a translation memory that stores everything translated before. If even half of a new sentence has been translated already, we can find it and reuse it for consistency.
Localization becomes an ongoing production function
Traditional project thinking treats translation as a closed batch: deliver files, finish translation, close the project. That model does not match how modern games ship. Localization has to keep up with patches, DLC, seasonal events, store copy, and community messages.
For live-service games, localization is part of the release cycle. On every release, you need answers to four questions:
- What content is new?
- What content has changed?
- What approved language can be reused?
- What existing content might the update break?
Without that process, each release becomes a manual recovery exercise.
Why game updates create localization risk
A patch may contain only a few hundred new words, but its impact can extend far beyond them:
- New content depends on old terminology — a new quest feels broken if existing names are translated differently.
- Small source edits invalidate old translations — “Defeat the Guardian.” → “Defeat the Guardian before time runs out.” cannot be imported blindly.
- Technical updates affect unchanged strings — a UI redesign can change space, mapping, or variables.
- Old files overwrite new corrections when complete language packs are exchanged manually.
- New builds expose hidden source text — hard-coded or never-exported strings.
Build a single source of truth
You need one authoritative place for current source and translated content—a TMS, CMS, repo, or connected combo. Know which text is current, which translation is approved, which build contains it, and what changed. When several spreadsheets and email attachments all look “final,” mistakes are hard to avoid.
Also name owners for export, terminology, import, LQA, and release approval. A localization manager or producer can coordinate even when the work is distributed.
Track the status of every string
Each string should have a clear status—draft, approved for localization, in translation, implemented, in LQA, approved for release, deprecated. Labels stop unfinished content from shipping unnoticed. Filenames like strings_final_v2_revised_REAL.xlsx are a warning sign; manage versions in the platform or repo instead.
Use stable string IDs
Stable IDs are essential for updates. Keep the ID when wording changes, unless meaning or function changed enough to treat it as a new string. If inventory_item_upgrade_confirm keeps identifying the same confirmation across releases, its previous translation stays connected; if the ID changes unnecessarily, the system treats it as brand new. More in how to avoid expensive game localization rework.
Separate new, modified, unchanged, and deleted strings
Do not resend the entire game database as an undifferentiated job after every update. A strong workflow classifies content:
- New strings require translation and review, with context, screenshots, feature information, character notes, variables, and space restrictions.
- Modified strings need the previous source, the new source, what changed and why, and the previous translation. A punctuation fix may not require retranslation; a changed quest objective probably does.
- Unchanged strings should remain protected and not be reopened unless terminology changed, a QA issue was found, the implementation changed, or new context affects them.
- Deleted strings should be marked inactive rather than silently removed—historical data helps translation memory, older builds, DLC, remasters, platform variants, and bug investigation.
- Reused strings (existing language appearing in a new screen) should be verified to confirm the old translation also fits the new context.
Maintain a game glossary
Resolve new core terms before they spread across dialogue, UI, quests, store copy, and patch notes. A glossary needs more than a source/target pair—definition, screenshot, and usage notes are enough to start. Document intentional renames too (old term, new term, reason, what must update), so language teams do not treat a deliberate change as an inconsistency.
Use translation memory correctly
Translation memory stores approved source/target pairs and surfaces them when similar text returns—so you reuse approved language and review only what changed.
An exact match works when source and context are the same. A fuzzy match (“Inventory full.” vs. “Your inventory is full.”) is a starting point that still needs human review. And context matters: “Charge” could be a combat action, battery level, payment, or ability resource. TM should not override context—keep string ID, screen, and content type with the match.
Keep the translation memory clean
Translation memory gets noisy when it holds drafts, rejected wording, old terms, or unreviewed machine output. After each release, store final approved translations, update changed terminology, and mark obsolete entries. A clean TM improves the next patch; a noisy one reprints old mistakes.
Preserve the style guide across releases
A glossary controls terminology; a style guide controls tone, UI conventions, and character voice. Updates are often localized by different translators under tighter deadlines, so record decisions once (title case for abilities, how the player is addressed, which words stay in English) and stop reopening the same debate every release.
Give new content enough context
Speed does not make context optional. For a new string, say where it appears, who is speaking, what the player is doing, which existing terms it uses, and any limits or variables. Before a major update, send a short feature brief—what it does, new terms, and whether old terms are changing. Full handoff: what game translators need from developers.
Connect localization to release planning
Put localization on the same release calendar as development and QA—export, translation, implementation, LQA, and release approval all need dates. When localization is bolted on after the schedule is fixed, language teams get incomplete content and compressed testing.
You may need separate cutoffs for narrative, UI, store copy, and emergency fixes. Define an exception path for hotfixes: who can request, who approves, which languages must ship, and how the change is tracked. An exception process beats pretending exceptions never happen.
Automate repetitive transfers—and validate before import
As update frequency grows, manual export/import becomes a risk. Automation can detect changed strings, move approved content, validate placeholders, and notify on status—without hiding the workflow. You still need visibility into what moved, which version, and whether validation passed.
Pre-import checks should catch missing translations, broken placeholders, duplicate IDs, and encoding problems before they enter a build.
Protect variables and version translations alongside builds
Dynamic strings such as {player_name} earned {reward_count} {reward_name}. need documented variables (meaning, plural/gender behavior, protected markup). A linguistically perfect translation is unusable if a placeholder is damaged.
Connect every delivery to a specific source version and build number so you can answer: “Is the correction in this build?” and “Did the hotfix overwrite approved text?” Without traceability, teams lose hours to version mismatches.
Run localization QA on every meaningful update
An update can break localization even when little text changed. Test new content and run regression on core menus, terminology, language selection, and reused UI. Framework: why native-speaker testing matters in game localization.
Use risk-based regression testing
You cannot retest the whole game after every small patch. Focus on what changed—reused UI, modified terminology, new variables, business-critical journeys. A UI framework change may need broad visual regression; a corrected dialogue line may need only a targeted check. Test representative languages (RTL, expansion-heavy, CJK, complex plurals) to catch structural problems—more in the trickiest languages in game localization.
Include patch notes and player communications
Updates are not only in-game strings. Patch notes, store pages, and community posts should use the same approved terminology. If a patch introduces a feature name, that name should match across UI, quests, store copy, and help content.
Plan for voice-over and subtitle updates
Voiced changes are more expensive than text-only ones—script, recording, lip-sync, subtitles, QA. Identify what will be recorded and apply stricter change control. When a change is unavoidable, decide whether to re-record, edit audio, change subtitles only, or delay. Scope help: game voice-over.
Handle platform and regional variants carefully
PC, console, and mobile may share most strings but differ on certification or store terminology. Document shared vs platform-specific strings so a global update does not overwrite an intentional variant.
Don’t let speed destroy consistency
Live-service teams often need to publish fast—hotfixes, exploit fixes, event announcements. Speed matters, but repeated inconsistency damages trust. Keep approved terminology, TM, clear review rules, and lightweight QA even under pressure. The goal is a scaled process, not the full launch workflow for every two-line notice.
Create update tiers
- Tier 1 — Critical hotfix (server issue, progression blocker, security problem): immediate translation, essential review, targeted implementation check, follow-up polish where needed.
- Tier 2 — Routine patch (balance updates, bug fixes, small features, patch notes): normal translation, linguistic review, targeted QA, regression of affected systems.
- Tier 3 — Major content update (new season, expansion, DLC, major questline, new mode): full context package, glossary updates, narrative review, voice-over, broad LQA, marketing localization, full regression planning.
The tier determines effort without removing quality control entirely.
Analyze recurring localization problems
Every update teaches you something. Recurring terminology corrections point to glossary gaps; missing strings to export problems; truncation to rigid UI; build confusion to weak version tracking. LQA is not only a release gate—it is feedback on the production system.
A practical game-update localization workflow
- Finalize the update scope: new features, changed systems, new and revised content, removed content, affected platforms, target languages.
- Prepare source content: approve strings, assign stable IDs, document variables, attach context, mark status, identify terminology decisions.
- Update language assets: add new glossary terms, record renames, refresh style guidance, provide previous translations, clean translation memory.
- Export only relevant content: separate new, modified, unchanged, and deleted strings.
- Translate and review: use the appropriate workflow for UI, narrative, marketing, patch notes, voice-over, and emergency content.
- Validate the delivery: completeness, placeholders, tags, encoding, terminology, file structure.
- Implement into a tracked build: connect the delivery to a specific build number.
- Run targeted LQA: new content, changed systems, high-risk journeys, representative languages.
- Fix and retest: confirm every correction in the intended build.
- Update the project assets: store final translations, QA corrections, new glossary entries, style decisions, build notes, and known issues.
The goal is continuity
Players experience one connected world. They do not separate launch from patch or DLC—they expect the same names, voices, and terminology across every update. Glossaries, TM, stable IDs, context, and native-speaker testing protect that continuity.
The more a game evolves, the more valuable these systems become. Without them, every release risks reopening decisions that have already been made. With them, localization becomes faster, more consistent, and easier to scale.
For the complete end-to-end process, see The Complete Game Localization Workflow: From Source Strings to In-Game QA.
Yana Tarasevich leads localization teams at Alconost, coordinating game translation, terminology management, and multilingual QA. The video clip in this guide is from her conversation with Max Pears on the Level Design Lobby podcast. Read more from Yana on localizing video games.
