Game Localization · All Services
Internationalization vs. Localization — i18n vs. L10n for Game Developers
Native translators. Translation Memory. In-build LocQA. Get a free quote →
Internationalization (i18n) and localization (L10n) are related but distinct processes. Internationalization is engineering work: designing and building a game so that it can be localized. Localization is adaptation work: actually translating and adapting the game for a specific market. You internationalize once and localize many times. A game that skips internationalization will be significantly harder and more expensive to localize.
What Internationalization (i18n) Means
Internationalization is the process of engineering a game to support localization — the ’18’ in i18n counts the letters between ‘i’ and ‘n.’ Key internationalization tasks: string externalization — all translatable text stored in external resource files (JSON, XLIFF, CSV) rather than hardcoded in scripts; Unicode support — UTF-8 or UTF-16 encoding for non-ASCII characters (required for CJK, Arabic, Hebrew, Cyrillic scripts); flexible UI design — text containers accommodate text expansion (German/Russian translations are typically 20–30% longer than English); date, time, number, and currency formatting using locale-aware systems; right-to-left (RTL) support for Arabic and Hebrew markets; and font loading for all required writing systems. Internationalization is engineering work done by developers — it has nothing to do with the translation itself.
What Localization (L10n) Means
Localization is the process of adapting a game for a specific target market — the ’10’ in L10n counts the letters between ‘L’ and ‘n.’ Key localization tasks: translation by professional translators; cultural adaptation of references, humor, and idiom; localization QA (LocQA) — testing translated content in the running game; glossary and terminology management for consistent translation; and platform compliance for age ratings and certification in the target market. Localization requires professional linguists and testers — it is not engineering work.
Why i18n Must Come First
Internationalization designed from the start of development is significantly cheaper than retrofitting it. Common i18n failures that become expensive localization problems: hardcoded strings in code (requires developer changes for every string), fixed-width text containers (requires UI rework for longer translations), string concatenation to build sentences (grammatically incorrect in many languages), and hardcoded font paths (requires code changes for different scripts). Each of these requires developer time during localization — adding cost and delay.
Practical i18n Steps for Game Developers
Practical internationalization for indie developers: (1) Store all player-visible text in external files — never hardcode UI strings, dialogue, or tutorial text in scripts. (2) Use unique string keys — ‘MENU_PLAY_BUTTON’ not ‘Play’ as a key. (3) Design UI with 30% expansion headroom. (4) Use Unicode-capable fonts from development start. (5) Test your string export/import pipeline before localization begins. (6) Avoid string concatenation — ‘Welcome, ‘ + name + ‘!’ is correct English but broken in many other languages with different word order.
Frequently Asked Questions
What game engines have good internationalization support?
Unity has a built-in Localization Package with string tables, asset tables, and plural forms. Unreal Engine has a Localization Dashboard with FText. Godot uses a gettext-based PO system. GameMaker has no built-in i18n — developers implement custom CSV or JSON systems. RPG Maker MV/MZ stores strings in JSON by default. Ren’Py has a built-in translation system. SandVox handles all of these pipeline types.
How do I test if my game is properly internationalized?
A practical test: export all text strings to a flat file, translate one sample string to a target language, re-import, and run the game. If the translated string appears correctly without code changes, your basic i18n pipeline works. Edge cases to test: strings with accented characters, very long strings (simulate German expansion), CJK characters, and RTL text if targeting Arabic or Hebrew markets.
Can SandVox review my game’s internationalization before localization starts?
Yes. Before starting a localization project, we perform a string extraction audit — reviewing your game’s string files and i18n pipeline for issues that will cause problems during localization. We identify hardcoded strings, pipeline issues, and UI design problems before translation begins, when they are cheapest to fix.
Start Your Internationalization vs. Localization Project
Tell us your word count, target languages, and platform. We return translated files ready for import — with Translation Memory and terminology glossary included. Free quote in one business day.