Game Strings — How Game Text Is Structured, Stored, and Localized

A game string is a discrete unit of localizable text in a video game — a line of dialogue, a UI label, a menu item, an error message, or a tutorial hint. Game strings are stored in string files (.po, .xliff, .json, .csv), referenced by unique string IDs, and extracted by localization teams for translation into target languages.

What Makes a Good Game String

A well-structured game string has a unique ID that identifies it across all language files, a source text that is unambiguous without visual context, and optional metadata — translator notes, context flags, character limit constraints. Strings that are too short (“OK”, “Yes”) are ambiguous without context; strings that concatenate at runtime (“You have ” + count + ” items”) break in languages where word order differs. The best game strings are complete sentences or complete UI units that can be translated as standalone units without referencing adjacent strings.

String Files and Formats

Game strings live in string files — structured text files that pair each string ID with its translated value per locale. Common formats: .po (GNU gettext — native to Godot, Unreal export format), .xliff (Unity Localization Package, custom engines), .json (web-based and cross-platform games), .resx (Unity/.NET projects), custom XML or CSV (proprietary engines). The string file for each target language is a complete translation of all source strings in that format — one file per locale per string table.

String ID Design

String IDs are the keys that link source text to its translated version across all language files. Common patterns: sequential integers (“1001”, “1002”), semantic names (“ui.mainmenu.newgame”, “dialogue.npc_guard.line_01”), or UUIDs. Semantic IDs are preferable for localization — they give translators context about where a string appears without needing a reference screenshot. Integer IDs are compact but require translator notes or screenshots to be meaningful. The choice of ID scheme is a localization-critical engineering decision made before the first string is exported.

String Extraction and the Localization Pipeline

String extraction is the process of pulling all localizable text from the game’s source — scenes, scripts, UI assets, and dialogue systems — into string files. Extraction tools vary by engine: Godot’s built-in pot generator scans scenes and scripts for translate() calls; Unreal’s Localization Dashboard scans StringTable assets and LOCTEXT macros; Unity’s Localization Package tracks strings referenced in String Tables. Extraction must be complete before translation begins — strings added after translation starts require a delta export and re-translation of new content, which adds cost and timeline.

SandVox and Game String

SandVox handles the full game string workflow — from string file export in your engine’s native format, through translation with Translation Memory that maximizes leverage on repeated strings, to QA checks that catch missing translations, mismatched placeholders, and string ID errors before they reach your LocQA build. We return translated string files in the same format you send — no conversion or manual import required.

Frequently Asked Questions

What is the difference between a string and a string ID?

A string is the actual text content — ‘New Game’, ‘Settings’, ‘You have died.’ A string ID is the key that identifies that string in the string file — ‘ui.menu.new_game’, ‘SETTINGS_LABEL’, or simply ‘1047’. The string ID stays constant across all language files; the string value changes per locale.

How many strings does a typical game have?

Range is wide. A hyper-casual mobile game might have 100–300 strings. A mid-size indie RPG typically has 5,000–15,000 strings. A AAA narrative RPG can exceed 100,000 strings, plus voice-over scripts. Word count rather than string count is the standard unit for localization quoting — strings vary widely in length.

What happens if a string is missing in a translated file?

Behavior depends on engine and locale fallback configuration. In most engines, a missing translated string falls back to the source language (English) and displays the source text. This fallback is usually better than crashing, but it creates visible untranslated text in shipped builds — a quality failure that should be caught at LocQA.

What are runtime-concatenated strings and why are they a problem?

Runtime-concatenated strings are built by joining multiple string fragments at runtime — ‘You have ‘ + item_count + ‘ items remaining.’ This approach breaks in languages where word order, pluralization rules, and noun case change the required position of the number. The correct approach is a single string with a format placeholder: ‘You have {count} items remaining.’ — which gives translators control over where the variable appears in the sentence.

Need Expert Game Localization?

SandVox provides end-to-end game localization including game string — for narrative games, mobile titles, webtoons, and interactive fiction.

GET A FREE QUOTE