Game Localization · Glossary
Localization Strings — Game Text Structure, File Formats, and Best Practices
Localization strings are the individual pieces of text in a game — UI labels, dialogue lines, system messages, item descriptions, achievement text — stored in dedicated files (string tables) separate from the game’s source code. Externalizing strings into dedicated localization files is a prerequisite for professional game localization.
What Counts as a Localization String
Any player-visible text that may need to differ by language: button labels, menu text, dialogue lines, character names (in some locales), item names and descriptions, achievement and trophy text, error messages, loading screen tips, tutorial instructions, HUD labels, subtitle text, and NPC speech. Voice-over scripts are handled in separate source documents from text strings. Images with embedded text (baked-in UI) are not strings — they require separate image assets per language and are significantly more expensive to localize.
Common String File Formats
The most common formats in game localization: .po / .pot (GNU gettext) — standard in web-based games and open-source engines. .xliff (XML Localization Interchange File Format) — the industry interchange standard, supported by all major CAT tools. .json / .yaml — common in web-based games, React Native apps, and Electron-based tools. .strings — iOS/macOS format. .resx — Unity/.NET resource format. Custom XML and CSV formats are also widely used. SandVox accepts most formats and returns translated files in the same format, ready for direct engine import.
String Structure Best Practices
High-quality string files include: unique string IDs (not sequential row numbers), context metadata per string (where it appears in the game, character limit, emotional tone), separation of voice scripts from UI text strings, no hard-coded concatenation (dynamic string assembly breaks in languages with different word order), and no inline code or unescaped HTML in player-visible text. Strings with contextual metadata generate fewer translator queries, fewer revision cycles, and ultimately a more accurate localization.
SandVox and Localization Strings
SandVox returns localized strings in whatever format your pipeline accepts — .po, .xliff, .json, custom CSV, or engine-native formats. During scoping, we flag strings that lack context metadata or contain hard-coded concatenation. Finding these issues at string export costs nothing; finding them after translation requires re-translation of every affected string.
Related terms: String Externalization · Localization Kit · Translation Memory · Cat Tool
Frequently Asked Questions
What is string externalization and do I need it before localization?
String externalization is the process of moving hard-coded text out of your game’s source code into separate, translatable files. Yes, it is required before professional localization — translators cannot work directly in source code. Most modern game engines (Unity, Unreal, Godot) have built-in string externalization support.
How do I send my strings to SandVox?
Export your string table in your engine’s native format (.po, .xliff, .json, custom CSV, etc.) and send it directly. We return translated strings in the same format, ready to import into your build.
What if my strings contain variables like player names or item counts?
Variables must be preserved exactly in the translated strings (e.g., {player_name} or %s). SandVox translators are trained to preserve all string variables and report any variables that create grammatical problems in the target language — for example, languages where word order changes around a variable require the variable to move position in the translated string.
Need Expert Game Localization?
SandVox provides end-to-end game localization including localization strings — for narrative games, mobile titles, webtoons, and interactive fiction.