A game localization workflow is the sequence of steps that takes a game from English-only to localized and ready to ship in each target language. Understanding the workflow helps game developers prepare correctly, avoid common delays, and budget realistically for what localization actually involves. This guide explains each step in a professional game localization workflow, from initial handoff to final delivery.

Step 1 — Project Setup and Loc Kit Preparation

Before translation begins, the developer prepares a localization kit (loc kit): the complete package of materials the localization provider needs to start work. A loc kit includes: exportable string files in a standard format (XLIFF, JSON, CSV, or engine-native export), a reference build (playable version of the game for context and LocQA), a glossary of game-specific terms, character notes for dialogue-heavy games, and any existing Translation Memory from previous projects. The quality and completeness of the loc kit directly determines how quickly and accurately translation can begin. Missing elements — especially missing reference build or missing glossary — delay project start and reduce translation quality.

Step 2 — String Extraction and CAT Tool Setup

Strings are imported into the localization provider’s Computer-Assisted Translation (CAT) tool (typically memoQ or SDL Trados). The CAT tool: imports the string files in their original format, runs Translation Memory matching to identify strings already translated in previous projects, identifies segments requiring full translation vs. those reusing existing TM matches, and applies the project glossary to flag game-specific terms for consistent treatment. The CAT tool setup step also includes quality assurance configuration — setting up QA checks that will flag common errors (missing variables, punctuation inconsistencies, glossary violations) during translation.

Step 3 — Glossary Translation and Approval

Before bulk translation begins, the project glossary is translated into each target language by native translators who review the terms in the context of the game. Glossary terms are confirmed with the client where needed — especially for character names (to translate, transliterate, or keep as-is), key game system names, and ability names. An approved glossary must be in place before translation begins on main content. This step prevents the expensive scenario where translators make independent decisions about key terms, resulting in inconsistent translations that require retroactive correction passes.

Step 4 — Translation and LQA (Linguistic QA)

With the glossary approved, translators work through the string files in the CAT tool. The CAT tool enforces: TM suggestions for previously translated segments, glossary term highlighting when game-specific terms appear in source text, QA checks catching variable errors and formatting issues. After translation, Linguistic Quality Assurance (LQA) is performed by a second linguist — a proofreading pass that checks translation accuracy, terminology consistency, natural-sounding language, and tone appropriateness. LQA is distinct from LocQA: LQA focuses on linguistic quality; LocQA (the next step) tests the localization in the actual game.

Step 5 — LocQA (Localization Quality Assurance)

Localization QA (LocQA) is the testing of the translated game in the actual game build — not the text files, but the running game. LocQA testers work through the game in each target language, testing: text truncation and overflow (translated text cut off by UI containers), line breaks (text breaking awkwardly mid-word or at wrong positions), font rendering (all characters displaying correctly, no missing glyphs), placeholder behavior (variables substituting correctly), and gameplay issues introduced by localization (text affecting timing, clipping through UI elements). LocQA requires the reference build. Without a reference build, LocQA cannot be performed and text issues will only be discovered by players after release.

Frequently Asked Questions