By launch, a hard-coded string isn’t a translation problem—it’s an engineering one. Late localization creates redesign, repeated exports, broken builds, and corrections that earlier planning would have prevented. The cheapest fix is not a lower per-word rate; it is a workflow that stops unnecessary work from being created. This companion to The Complete Game Localization Workflow covers the most common causes of rework—and how to catch them before production.
When should you start localizing your game?
In this clip, Yana Tarasevich explains why you should prepare the game for translation long before the first request. From her Level Design Lobby conversation with Max Pears.
It makes a lot of sense to think about localization even when you start, because localization gives you a lot of new users and players. To do it properly, you need to keep your game internationalized—your text strings stored in a separate file, not hard-coded anywhere in the game, so you can translate them into any language and put them back. That’s step one. After that, you can localize step by step, at any tempo you prefer.
Why late localization creates hidden costs
Localization rework is often treated as a translation problem. In practice, it usually begins elsewhere—in code, UI design, content structure, fonts, builds, or release schedules. These issues stay invisible while the game exists only in its source language. Once new languages arrive, the assumptions built into the product begin to break.
A button designed around a four-letter English word may not fit German. A string assembled from fragments may be impossible to translate naturally. A font may contain Latin characters but not Arabic, Japanese, or Polish diacritics. The later you discover these issues, the more expensive they are to fix. This is fundamentally an internationalization problem—see also how to prepare a game for localization.
Rework has more than one cost
Retranslation is only part of the bill. Rework can also burn developer time, force UI redesign, require new builds, and delay certification or release.
Changing one ambiguous English term may mean updating the source, sending it to every language team, revising the glossary, reimporting translations, rebuilding, and retesting the screen. Preventing the issue at the source is usually cheaper than fixing it at the end.
Build a repeatable content pipeline
Do not hard-code player-facing text
Hard-coded strings are one of the clearest sources of avoidable work. When text lives in code, every new language becomes a find-and-extract project—and missed strings keep reappearing. Store player-facing text in string tables or a localization platform, and reference it through stable IDs. Separating text from code lets you export, translate, update, and reimport without rewriting the game for every language.
Use stable and meaningful string IDs
Prefer meaningful, stable identifiers—menu_audio_volume_label, quest_024_mira_warning_02, inventory_use_health_potion—over string_001 or text_final_3. If IDs change whenever source text changes, previous translations disconnect. Good IDs improve context, bug reporting, and update tracking.
Avoid assembling sentences from fragments
Sentence fragments are hard to localize because languages use different word order and grammar. Assembling “You found” + {count} + {item_name} looks efficient in English but may break elsewhere. Store complete messages whenever possible, and use localization-aware plural/variable systems such as ICU MessageFormat—so translators control the full sentence instead of forcing every language into English structure.
Document variables and placeholders
Undocumented variables create both linguistic and technical errors. A translator who sees Defeat {target} before {limit} needs to know whether {target} is a person, creature, or object; whether {limit} is a time, level, or location; and whether the variable can change grammatical form. Document every variable, note its possible values and grammatical behavior, and configure tools to protect placeholders from accidental editing. The full context handoff is covered in what game translators need from developers.
Design the interface for other languages
Design UI for text expansion
A layout that works in English may break in translation—truncated buttons, overlapping labels, cut-off quest text, unreadable HUD elements. Asking translators to shorten everything is a workaround; if the UI only works when meaning is removed, the real problem is design rigidity. Build flexible layouts, and test with pseudo-localized builds early so insufficient space and hard-coded text show up before real translations exist.
Select fonts with target languages in mind
A font may look right for the game while lacking the characters localization needs—missing glyphs often stay invisible until translations are implemented. Before finalizing fonts, confirm support for target scripts, accents, and fallback behavior, especially for complex shaping.
Plan for right-to-left languages
Arabic and other RTL languages need more than translated text: reading order, mirrored layouts, shaping, and bidirectional mixed strings. Adding that support late can force substantial UI redesign. Test RTL during development—even if Arabic is planned later—because displaying Arabic characters is not the same as displaying Arabic correctly. More in the trickiest languages in game localization.
Control the source-content workflow
Don’t localize unfinished text without a change process
Source text changes during development—that is normal. The problem is untracked change: translators work on outdated versions while developers overwrite translated strings or resend entire files. Define status labels (draft, approved, updated, locked). When a string changes, the team should see what changed, which languages are affected, and whether the previous translation can be reused.
Establish a realistic string-freeze policy
A string freeze limits source changes after a point. Live-service and early-access games may never freeze completely, but you still need rules: what can change late, who approves it, how it is communicated, and whether release dates move. Without that structure, last-minute updates cascade into localization delays.
Give translators enough context from the start
Missing context creates rework because translators decide without seeing the game. Provide screenshots, character notes, dialogue trees, limits, and a contact who can answer questions. Preparing context usually costs less than correcting every affected language later. Full handoff: what game translators need from developers to do their best work.
Build language assets before terminology spreads
Create the glossary early
Correcting a term after it has spread across UI, dialogue, marketing, and patch notes is expensive. Build the glossary early—source term, meaning, screenshot, approved translation, and notes—and update it whenever new core concepts appear. Characters, items, skills, and mechanics need one agreed name before translators start making independent decisions.
Reuse approved translations through translation memory
Retranslating repeated content wastes time and increases inconsistency. Translation memory lets you reuse approved wording for UI labels, patch notes, tutorials, and seasonal content. Keep one controlled TM per language and project, aligned with the released build. Over time: how to update a game without breaking its translations.
Connect localization to builds and QA
Connect localization to version control and builds
Localization fails when language files and builds are out of sync—old strings, wrong imports, fixes missing from the build. Track source version, delivery, build number, and QA status, and connect every localization bug to a specific build. Even a simple naming convention and release log prevents a lot of confusion.
Validate file formats before production begins
Projects lose time on broken encoding, unprotected variables, duplicate IDs, or formats the tools cannot process. Run a small pilot before the full game: export, preserve context, protect variables, reimport, display in-game, and detect updates. Pipeline problems are cheaper to fix at small volume.
Include localization QA in the original plan
LQA is sometimes added only when problems become visible—when little time remains. A file can be linguistically correct while the live build shows truncation, wrong strings, broken variables, or layout issues. Plan native-speaker testing with time for fixes and retesting. See why native-speaker testing matters in game localization.
Use a clear localization bug process
“Translation is wrong” is not a bug report. Include language, build, location, string ID, screenshot, current vs expected text, category, and severity. Clear reports reduce back-and-forth and assign the right owner.
Coordinate people, reviews, and updates
Avoid unstructured internal review
Bilingual employees can help review, but unstructured feedback creates new problems—personal wording, ignored glossaries, late contradictory notes. Define who reviews, what they may change, and when review ends. Give reviewers the same glossary, style guide, and context as the localization team.
Plan updates before launch
Patches, DLC, and live-service content keep creating localization work. Before launch, define how you will handle new, modified, and deleted strings—using glossaries and translation memory to preserve continuity. Full workflow: how to update a game without breaking its translations.
Test difficult languages early
Some languages reveal weaknesses faster: Arabic (RTL/shaping), German (expansion), Japanese (fonts/line breaks), Slavic languages (plurals/cases). Choose a representative test set during development so architecture gaps show up before the final build. More in the trickiest languages in game localization.
Assign one internal localization owner
Rework rises when ownership is fragmented—engineering, narrative, and the vendor each assuming someone else owns the strings. One internal owner should coordinate readiness, terminology, builds, vendor communication, QA, and updates. They need visibility and authority, not to do every task themselves.
A localization-readiness checklist
Before sending the game for translation, confirm:
Code and content
- Player-facing text is not hard-coded and strings use stable IDs
- Complete sentences are used where possible and variables are documented
- Source files are version controlled; export and import have been tested
UI and technical support
- Layouts support text expansion and fonts support target languages
- Unicode is supported and right-to-left behavior is tested where relevant
- Plural and gender variants are supported; line breaks and wrapping are flexible
Source workflow and translator support
- Strings have clear status labels and content owners are assigned
- Late-change rules are defined and changes can be detected
- Screenshots, dialogue branches, character profiles, and string descriptions are available
- Tone and audience are defined and queries have a clear owner
Language assets, implementation, QA, and updates
- A glossary, style guide, and translation memory exist; naming rules are approved
- Build numbers are tracked, missing strings can be detected, variables are protected
- Native-speaker QA is scheduled with time reserved for fixes and retesting
- New and changed strings can be separated; patch localization is in the release plan
Early planning does not mean translating too early
You may avoid localization planning because the game is still changing—and translating unstable narrative too early does create rework. But planning and translation are not the same thing. You can externalize strings, design flexible UI, pick fonts, build stable IDs, and test import/export now, then translate when content is ready. The goal is not to freeze creative work early—it is to avoid decisions that make every future language more expensive. Shipping two languages early is one way to stress-test the architecture before scale.
The cheapest localization issue is the one prevented before implementation
Localization rework rarely comes from one dramatic failure. It usually comes from many small decisions:
- A hard-coded message or ambiguous string
- A narrow button or unsupported character
- An unexplained variable or outdated file
- A late source change or missing screenshot
Each seems minor in isolation. Across thousands of strings and multiple languages, they create significant cost.
A localization-ready game gives translators enough context, gives engineers a repeatable content pipeline, gives designers flexible interfaces, and gives QA enough time to test the final experience.
That preparation reduces retranslation, redesign, debugging, and release risk. 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.
