Technical Localization of Mobile Games: Full Cycle

Why mobile game localization breaks at release

Mobile game localization almost never breaks at the translation stage — it breaks at the build stage, when strings have already scattered across screens, and the tester sees not the original layout but a distorted version of it.

German text is a third longer than English, Arabic flips the layout right-to-left, and Chinese gets by without spaces — and where the layout had a neat button, the release shows a truncated "Conti…".

This is not cosmetic: every such button is a lost onboarding step, and onboarding decides whether the player stays or deletes the app on the first screen.

Game localization problems are rarely limited to string length. Date, number, and currency formats are assembled from system templates, and if the string "12/03" reads as December in one market and as March in another, the player sees the wrong event date.

Multiple plural forms in Slavic languages require not two variants but three, and hardcoded "one/many" logic produces "5 crystals" where the language expects a third form.

Interface translation errors are secondary here — what comes first is the string architecture, which did not anticipate variability.

A separate category of failures is lost strings. Texts live in tables, some are pulled from server configs, some are hardcoded, some come from the app store.

When a game is launched in a new market, these sources are synchronized manually, and any desync produces empty placeholders, English stubs in the middle of a localized screen, or a crash on a missing key. The player does not report this to support — they simply leave.

The cost of an error is measured not in edits but in conversion: a truncated first screen, an unreadable price in the in-game store, or a broken date format in the daily reward reduce the share of players reaching their first payment far more than any release delay.

Let's break down how this is closed at the process level, rather than through heroic edits before publishing.

What technical localization of a mobile game delivers

Technical localization of apps does not start with translation, but with how strings get into the build. If texts sit directly in the code or in scattered spreadsheets, every language turns into a separate branch that has to be merged with the main one by hand.

A properly built localization pipeline removes that manual work: strings are moved into resource files, keys are stable, and translations are pulled in at the build stage.

Moving strings out and managing keys

As long as text is hardcoded into the interface, any copy edit requires a developer's involvement.

Managing translation strings through a single catalog with keys like screen.button.confirm separates text from logic: editing copy does not touch the code, and a new string lands in all languages at once.

A side effect is that the build stops breaking because of an unclosed quotation mark in a translation.

Automatic integrity checks

A script compares the set of keys across languages and fails the build if a language is missing a string or still has an untranslated placeholder. This catches fragments like {count} items in an Arabic interface before release, not in reviews. The share of such defects reaching the user drops to zero.

Pseudolocalization and layout checks

Running the interface through an "elongated" pseudo-language shows where a button cannot fit German text or where a string runs off the edge. The layout is fixed once during development, not after every new language.

Context for the translator

A screenshot of the screen and a comment on the key remove guesswork: the translator sees that Post is a publish button, not mail. Rework requests over meaning are cut severalfold.

We build such a pipeline based on industry standards for translation exchange — XLIFF remains a neutral format that both platforms and translation teams understand.

Stages of implementing localization into a game's development cycle

Localization doesn't start with translation — it starts with taking inventory of what's already in the project.

Strings are often scattered across code, screen markup, server responses, and store descriptions; some are baked into graphics, some are assembled dynamically from fragments.

Until this picture is assembled, any translation runs into truncated text, broken buttons, and strings that no one can find in the source. Below is how we build the implementation of localization so that it becomes part of the build rather than a separate crunch before release.

1. Audit of strings and resources. We go through the code, markup, and server responses, gather all text resources into a single catalog, and flag "dead" and duplicate strings. The output is a map: where each string lives and who owns it.
2. Designing the localization scheme. We define keys, the exchange file format, rules for pluralization and declensions, and separation by languages and regions. We establish what is translated automatically and what requires an editor's involvement.
3. Setting up the pipeline. We connect the translation management system to the repository: new and changed strings go out for translation, and completed ones come back into the project as a separate branch. The build automatically picks up the current language files.
4. Testing on real builds. We run the application in every language: string lengths in buttons and menus, line breaks, fonts, date and number formats, word order. We catch overflows before release, not in reviews.
5. Automated checks in the build. We add controls: untranslated keys, forgotten strings, discrepancies between languages. The build fails if a language lags behind the main version.
6. Handover to the team. We formalize the process: how to add a string, how to request an edit, who is responsible for proofreading. The team works with localization by the same rules as with the rest of the code.
7. Post-release support. New languages and text edits go into the same pipeline — without rebuilding the process from scratch.

This sequence eliminates manual string transfer and keeps all languages in sync: adding a new language comes down to connecting one more set of files rather than a separate project.

Describe your task — we'll come back with an estimate and an implementation plan for your stack and release cycle.

How is mobile game localization different from regular translation?

Translation treats text as a stream of characters: take a string, replace it with another, put it back into the file.

Mobile game localization treats text as part of executable logic — a string lives inside resources, gets substituted into templates, is inflected by numbers and cases, and is rendered by a specific font on a specific screen.

That is why localization vs translation is not about "translating better" but about a different class of task: the translator hands over text, the localizer is responsible for the game not breaking in that locale.

Game interface localization starts with string inventory. We break down resources by type: static button and menu labels, lines with variable substitution, texts with pluralization and gender forms, strings assembled at runtime from fragments.

The last category is the main source of bugs: the translator sees "You received 3 coins," but in the code it is three separate strings glued together by concatenation, and in a language with a different word order or a different numeral system, such assembly produces garbage.

Dynamic strings require the translator to work not with a finished sentence but with a template and its variables. We tag every placeholder, fix the allowed substitution types, and verify that after substituting the maximum value the string does not overflow the container.

Data formatting is handled separately: dates, times, digit separators, number and currency formats, units of measurement — all of this is tied to the device locale, not to the interface language, and with incorrect settings the player sees a date in a foreign format.

Fonts and layout close the loop. Not every font contains the required glyphs, and extended Cyrillic, Arabic script, or hieroglyphs change text metrics: a label that occupied one line in the source locale breaks the button in the target one.

We run localized screens through overflow and truncation checks rather than relying on the assumption that "the translation is short."

The bottom line: regular translation delivers a file with strings, mobile game localization delivers a working build in the target locale — with verified substitutions, correct formats, and layout that does not fall apart.

Case study: how localization accelerated the game's entry into new markets

There was a project on an engine with separate string tables per language: each new locale was added manually, and updating a single language took up to three weeks.

Texts lived in tables, layout lived in a separate branch, and any edit to a source string broke already translated screens. By release, 12% of UI strings were truncated, and there were constant discrepancies between versions.

What was changed

A unified pipeline was built: source strings are exported into a common format, translators work in the same format, and the language pack build is triggered automatically by tag.

Keys stopped being duplicated across screens, and a string-length check was added for each layout — truncation is caught before the build, not on the device. For Arabic and Hebrew, layout mirroring was enabled at the style level rather than through manual layout edits.

Metrics before and after

Faster language releases delivered more than just shorter timelines: the team began adding locales in parallel with feature development rather than afterward.

The results of localization became visible in retention — players in new markets reached key mechanics more often because the interface stopped "breaking" in their language.

Unity Localization and similar string management systems cover part of the tasks, but they do not eliminate the need for manual context and length checks — which is why the pipeline retained a native-speaker translation review stage before the build.

Doubts before starting: compatibility, migration, rollback

Localization compatibility almost never hinges on the engine — it hinges on how strings are tied to logic.

If text is hardcoded or collected into a single flat file, adding a language breaks the build: keys get duplicated, some strings remain untranslated, and format placeholders like %1$s and {count} drift out of position.

That is why our first step is to separate content from code: strings are moved into tables with stable keys, and translations are connected as separate sets rather than by editing the source.

What if the project already has localization in a different format? String migration goes through an intermediate mapping table: old keys are matched to new ones, conflicts and "orphaned" strings go into a separate report instead of being silently lost.

After the transfer, we run the build in all languages — a mismatch in the number of keys between the source and target sets is visible immediately.

How is an unsuccessful language rolled back? Rolling back localization means reverting the previous string set, not rebuilding the app: sets are versioned separately from the code, so a problematic language is removed by switching a reference, without a new store release.

Pseudolocalization (substituting lengthened strings) shows in advance where the layout will not survive German or Finnish text.

The team hands over:

• build configurations by language and platform;
• a key schema with naming rules and scopes;
• a versioning policy for string sets and the rollback procedure;
• a migration report: mapping of old and new keys, list of conflicts;
• localization documentation — the procedure for adding a language and editing text;
• a set of checks for key and placeholder mismatches in the build;
• pseudolocalization instructions for layout verification.

Describe your task — we will come back with an estimate and a plan: we will show which steps your project specifically needs and what of that is already covered in the current pipeline.