Guide

Game localization and i18n explained

Roughly half of Steam revenue comes from non-English markets, yet many indie and mid-size titles still ship with hard-coded English strings and fixed-width UI boxes. Internationalization (i18n) is the engineering discipline that separates translatable text from code; localization (l10n) is the translation, cultural adaptation, and quality assurance that makes each locale feel native. This guide walks through string externalization, plural and gender grammar, right-to-left layout, dialogue pipeline hooks, font and audio localization, pseudo-localization for early QA, and the production checklist teams use before cert on PlayStation, Xbox, Nintendo, and mobile stores.

i18n vs l10n vs LQA

These terms get conflated. Keep them distinct because they involve different teams and schedules:

i18n (internationalization) — code and data structures that support any language: externalized strings, locale-aware formatting, RTL layout hooks, font stacks that cover CJK glyphs. Done by engineers during feature development.
l10n (localization) — translating strings, adapting images and marketing, recording localized voice-over, adjusting culturally sensitive content. Done by translators, audio studios, and loc vendors near ship or in live-service cadence.
LQA (localization quality assurance) — native speakers play the build in each target language, logging truncation, wrong context, untranslated keys, and narrative inconsistencies. Catches what machine translation and spreadsheet review miss.

The expensive mistake is treating localization as a final-week paste job. Retrofitting i18n into a shipped game means re-touching every UI prefab, every cutscene subtitle track, and every achievement string — often more work than building the pipeline correctly from prototype onward.

String externalization fundamentals

Every player-visible string should live in a resource file keyed by a stable identifier — never embedded in source as a literal. The runtime looks up UI_INVENTORY_FULL and returns the locale-appropriate text.

Key naming and context

Keys should be semantic, not English copies. Translators need context comments — "button label, max 12 chars" vs "tooltip, multi-line OK" — because the word "Play" in English might mean start a match, play an instrument, or play a video depending on screen.

Namespace keys by feature: quest.main_03.objective, hud.health.low_warning.
Never concatenate translated fragments with variables in the middle — word order differs across languages.
Use positional or named placeholders: You collected {count} {item} with ICU MessageFormat so translators can reorder tokens.

Plural, gender, and select rules

English has two plural forms (one, other). Polish has four. Arabic has six plural categories. Hard-coding if (count === 1) breaks the moment you add French or Japanese. Use ICU MessageFormat or engine-native plural APIs:

{count, plural,
  =0 {No items remaining}
  one {# item remaining}
  other {# items remaining}
}

Gendered languages need similar select blocks for NPC pronouns in narrative text. If your dialogue system branches on gender, externalize each variant rather than runtime string surgery.

What not to externalize

Debug logs and internal analytics event names (keep English).
Proper nouns that are brand identities — though some markets transliterate them (e.g. Pokémon stays Pokémon).
Cheats and developer console commands.

UI layout: expansion, truncation, and RTL

German averages 30% longer than English for the same UI label. Finnish can run longer still. Fixed-width buttons truncate "Settings" into "Settin…" in ways that look broken, not stylized.

Design for expansion

Prefer flexible layouts — auto-sizing text boxes, wrapping labels, scrollable panels over fixed pixel widths.
Set max line counts with ellipsis only as a last resort; LQA should flag every ellipsis as a layout defect unless intentional.
Test longest-locale strings early: German, Brazilian Portuguese, and Russian are common stress languages for width.

Right-to-left (RTL) languages

Arabic and Hebrew read right-to-left. Mirroring is not just text direction — entire HUD layouts may flip. Health bars on the left in LTR often move to the right in RTL. Back-arrow icons must point the culturally correct direction. Unity and Unreal provide RTL text components; web games can set dir="rtl" on containers and use logical CSS properties (margin-inline-start instead of margin-left).

Numbers, Latin brand names, and mixed-script lines need bidirectional (bidi) handling. A line like "HP: 100/100" in Arabic must render digits in the order players expect. Test RTL on real devices — emulators miss font shaping edge cases.

Fonts and glyph coverage

A Latin-only font fails silently in Japanese — tofu boxes (□) appear wherever glyphs are missing. Ship font fallbacks or subsetted Noto families that cover your target scripts. CJK fonts are large (10–20 MB per weight); subset to the characters in your string table or use dynamic font loading per locale pack. Line height and baseline shift between scripts — centering Chinese in a button sized for English cap height looks vertically off.

Dialogue, audio, and subtitles

Text localization is only the start when your game has voiced dialogue. Each locale multiplies asset count and production cost.

Subtitle pipeline

Store subtitles as timed cues (SRT, VTT, or engine-native) separate from audio files so text-only locales ship without VO.
Respect reading speed guidelines — Netflix caps around 17 characters per second for adults; games with fast combat may need shorter lines or split cues.
Speaker labels, color coding, and name tags must localize independently of the line text.

Voice-over localization

Full dubbing requires script adaptation (lip-sync timing, idiom replacement), casting, recording, and re-integration. Many AA titles ship English VO with localized subtitles in Tier 2 markets to control budget. Live-service games batch VO loc with content drops — plan pipeline capacity so translators receive locked English scripts before voice actors record, not after.

Text-to-speech and generative VO

AI voice synthesis can fill barks and ambient lines cheaply, but platform holders and players increasingly scrutinize disclosure. Steam now requires AI content labels for some asset categories. If you use synthetic VO, budget human LQA to catch mispronounced proper nouns and emotional flatness in story-critical scenes.

Pseudo-localization and early testing

Pseudo-localization replaces English strings with an accented, lengthened variant ([Ţĥíš íš ã ţéšţ]) while keeping them readable to English-speaking devs. Enable it in dev builds to surface:

Hard-coded literals that never hit the string table.
Truncation and overflow before translators deliver real text.
Missing font glyphs if you pseudo-localize with extended Latin.
Layout breaks from 30% length expansion (auto-append padding).

Run pseudo-loc on every milestone build. Pair it with a locale switcher in debug menus so designers can flip languages without recompiling. Automated tests can assert no raw English keys appear when locale=ja-JP.

Translation workflow and tools

Spreadsheets work for jam games; production titles need TMS (translation management systems) like Crowdin, Lokalise, or POEditor integrated with source control.

Engine and framework options

Unity Localization package — string tables, asset localization (textures, audio), locale selectors, Google Sheets sync.
Unreal Localization Dashboard — gather text, export PO files, import translations, compile per-culture packages.
Godot — CSV translation files, tr() function, locale fallbacks via TranslationServer.
Web / custom engines — i18next, FormatJS, or gettext PO/MO files loaded at runtime; lazy-fetch locale JSON bundles.

Vendor handoff checklist

Freeze string freeze date; changes after lock incur change-order fees.
Export with context, max length hints, and screenshots per key where meaning is ambiguous.
Provide glossary (character names, made-up terms, "do not translate" list for abilities and brands).
Return translations in the same file format — manual paste into code is error-prone.
Plan round-trip: import, build, LQA, fix, re-export only changed keys.

Cultural adaptation beyond translation

Localization is not word substitution. Some content must change or be removed per territory:

Regulatory — loot box odds disclosure (Japan, China), gore filters (Germany, Australia), gambling imagery restrictions.
Cultural sensitivity — color symbolism, religious imagery, historical references. A harmless gesture in one culture may offend in another.
Humor and idioms — puns rarely translate; writers should author "intent notes" so loc teams can substitute equivalent jokes.
Date, time, and currency — use Intl.DateTimeFormat and locale-aware number formatting; never hard-code MM/DD/YYYY or USD symbols in player-facing UI.

Platform certification (Sony TRCs, Xbox XR, Nintendo guidelines) includes loc-specific requirements — missing translations in system dialogs, incorrect rating board text, or unlocalized PSN/Xbox overlay strings fail cert.

Live-service and patch localization

Games-as-a-service ship weekly strings — event banners, battle pass tiers, patch notes. Without pipeline discipline, English-only hotfixes ship while loc lags by a week, fragmenting the player base.

Treat new strings like API contracts — version keys, deprecate rather than rename in place.
Ship English first only if your audience accepts it; otherwise delay the feature until Tier 1 locales are ready.
Store per-locale asset bundles so players download only their language pack — critical on mobile storage budgets.
Track untranslated-key metrics in production telemetry; alert when fallback locale rate spikes after a deploy.

Accessibility overlap

Localization and accessibility intersect: subtitles need size and contrast options independent of language; dyslexia-friendly fonts may differ per script; screen readers need localized alt text on HUD icons. Ship a unified "text and language" settings screen — subtitle language, audio language, and UI language are three separate player choices in many AAA titles.

Production checklist

Externalize all player-facing strings from day one; ban string literals in UI code review.
Use ICU MessageFormat (or equivalent) for plurals, gender, and select — no manual if/else.
Enable pseudo-localization on CI builds; fail builds that introduce hard-coded English.
Design flexible UI; stress-test German and Russian string lengths before art lock.
Implement RTL mirroring with logical layout properties; test Arabic on device.
Ship font stacks with glyph coverage for every target script; measure download size per locale pack.
Separate subtitle, audio, and UI language settings; store timed cue files per locale.
Maintain glossary and context screenshots for translators; integrate TMS with git.
Run native-speaker LQA on release candidates — play through, not just read spreadsheets.
Verify platform cert loc requirements (ratings text, system dialogs, store metadata).
Monitor fallback-locale rates in live builds; hotfix missing keys within 24 hours.

Key takeaways

i18n is engineering; l10n is content — build the pipeline before you need translations.
Never concatenate translated strings — use placeholders and ICU rules for grammar.
Layout is half the battle — expansion, fonts, and RTL break games that only tested English.
Pseudo-loc catches bugs cheaply — run it every milestone, not the week before ship.
LQA is gameplay testing in each language — spreadsheets cannot replace native speakers playing the build.