Software and Game Localisation 5 August 2026
What Is a String ID? The Context Key of Game Text
Game text arrives as strings with no context attached. The string ID may be the only clue that carries that context. This article looks at how the ID is built, what belongs in the kit and which columns the table needs.
The complaint heard most often in game translation is the lack of context. The translator ends up with a table hundreds of rows long and no way of knowing where in the game each row appears. The string ID is usually the only clue left in that darkness.
Contents
The book defines the concept clearly: string IDs are the unique labels of every piece of text that makes up a game, and they can carry contextual information (Jiménez-Crespo 2024, p. 217). The word “can” matters here; whether they do carry it depends on the developer’s naming preferences.
In this article we look at how a string ID should be constructed, what a localisation kit should contain and which columns a translation table should have. For related topics you can consult our knowledge centre.
What is a string ID for?
Technically, the ID is the address at which the code calls the text. When a developer wants to put wording on the screen, they write the ID rather than the text, and the system fetches the right equivalent for the selected language. This structure is the foundation of separating text from code.
On the localisation side, the ID is a map. The same ID points to the same row in every language, so what has changed can be tracked across updates. If the IDs are inconsistent, there is no telling which row in a new release is new and which is old.
The third function is context, and that is essentially our subject here. In the example the book gives, the text under the ID “start_quest_button” is “start”. That ID tells the translator that the row is a button which starts a quest (Mangiron 2021c, as cited in Jiménez-Crespo 2024, pp. 217–218).
The information changes the translation directly. The book explains that in Spanish this has to be rendered with a form that expresses an action rather than a noun. Turkish makes the same distinction: “Başlangıç” and “Başlat” are different things, and without the ID there is no way of knowing which one is right.
The same logic applies to a great many other short strings. Whether the answer is “Sıfırla” or “Sıfırlama”, “Kaydet” or “Kayıt” depends on whether the text sits on a button or in a heading. If the ID carries that information, the translator has no need to guess.
What does a good ID tell you?
A good ID gives at least three pieces of information: the type of the text, the screen it sits on and its function. “btn_settings_apply” does that. “str_00417” says nothing at all and forces the translator to guess.
The naming convention should be settled at the start of the project and used by the whole team. Changing IDs afterwards breaks the matching of the existing translations, and the memory then has to be realigned. That turns a few hours’ convenience into work that can run for weeks.
The ID is used in quality testing as well. When a defect is reported in a test report with its string ID, whoever is to make the fix finds the text within seconds. There is no need to stare at a screenshot and hunt for the wording.
The ID structure also makes the repetition problem visible. The same text repeated dozens of times under different IDs bloats the file needlessly and creates a risk of inconsistency. Conversely, tying two texts from different contexts to a single ID forces the translator into a bland rendering that has to suit both places.
What should a localisation kit contain?
The ID on its own is not enough. The book states that an ideal localisation kit consists of three components (Jiménez-Crespo 2024, p. 217). Those three components are the basic way of closing the context gap.
- Instructions and guides: the style guide, technical instructions and legacy files; the most detailed description of the game mechanics that can be given; the narrative structure, the characters and information about the saga. If the translator has no access to the game, screenshots are especially valuable.
- Translatable assets: text files in formats such as Excel, XLIFF or XML, together with instructions on length constraints. Graphic assets, video files and, where needed, the game code also belong to this group.
- Translation and game technology: earlier translation memories and termbases; explanations of the variables, placeholders, tags and string IDs.
The item most often skipped on this list is the first one. The text file is sent, the guide is not. The translator then chooses the right words but strikes the wrong tone, and the fault comes back at the testing stage as a question of register.
It should be added that the kit is not a document you prepare once and then leave alone. As the game develops, mechanics change, characters are added and terms settle. If the kit is not updated, before long it becomes a guide that contradicts the game itself, and the translator cannot tell which of the two to trust.
Which columns should the translation table have?
The book says that the files worked on during the core localisation phase should ideally contain detailed contextual information: the string ID, the character, the location, the marker, the trigger and the maximum number of characters (Jiménez-Crespo 2024, p. 217).
| Column | What it is for | What happens if it is missing |
|---|---|---|
| String ID | Context and traceability | Translation based on guesswork |
| Source text | The content to be translated | – |
| Character | Who is speaking | Wrong form of address and tone |
| Location/scene | Where it appears | Context error |
| Maximum length | Space constraint | Text overflow |
| Asset type | Screen text or audio | Wrong register |
| Notes | Explanation of variables and tags | Broken string |
The maximum length column is widespread in the industry. The book reports that in some productions there is a column called “MaxLength” for each row, showing the maximum number of characters (Pettini 2022, as cited in Jiménez-Crespo 2024, p. 214).
Variables, placeholders and conditional tags
Some strings are not fixed text. They contain variables that are filled in at run time. The examples in the book take the form “You have %d lives left” and “You have %d gold coins” (Jiménez-Crespo 2024, p. 210). These markers are never translated.
Conditional tags are more delicate still. The example given in the book runs as follows: “Why, hello there <IF_MALE>handsome boy<ELSE>pretty girl<ENDIF>!” (IGDA 2021, as cited in p. 218). If the order or the spelling of the tags is disturbed, the text appears wrongly or does not appear at all.
Explanations of these structures belong to the third component of the kit. What each variable brings in has to be set down in writing. The single line “%s here is the player name” prevents dozens of errors.
Pluralisation falls under this heading too. The book states that the internationalisation of plural forms is carried out at the development stage. If that work is left until later, the translator is left with a single pattern and unnatural phrasing becomes unavoidable.
ID structure in audio assets
On the audio side the ID matters even more. The book states that scripts are kept in spreadsheets, with each audio item in a separate segment and under its own string ID. The table also carries the name of the actor who is to make the recording (Jiménez-Crespo 2024, p. 215).
This structure is what makes studio planning possible. All the lines belonging to one voice actor are filtered by ID and recorded in a single session. If the ID system is disorderly, several sessions are needed for the same actor, and that is a cost, directly.
The ID also keeps subtitle and audio matched. As the book notes, audio strings in games are often used both in the subtitles and in the recording. Tying the two layers to the same ID makes it easier to carry a correction made in one of them over to the other.
Audio strings can arrive mixed in with other text. The book states that voice-over scripts are often held in the same spreadsheet but are flagged as audio or voice-over assets. If that flag column is missing, the translator cannot tell which line will be spoken and which will be printed on screen, and the register slips.
What do game engines offer?
You do not have to build ID and asset management by hand. The book states that some game engines include localisation features which set up the parallel structure and extract the localisable strings; CryEngine, Godot and Unreal are given as examples (Toftedahl 2021, as cited in Jiménez-Crespo 2024, p. 218).
The book also contains an example of an interface table in Excel format taken from the localisation component of one engine. Ready-made structures of this kind speed up the preparation of the kit and reduce formatting errors.
Even so, the tool the engine provides is no substitute for the guide. The engine extracts the strings, but it does not write down who the character is, where the scene takes place or what the tone should be. Context is still added by a person.
The output format matters in the choice of tool as well. The book states that localisers mostly work with files in Excel, Word or XML format (Jiménez-Crespo 2024, p. 217). If the file the engine produces can be taken straight into translation tools, the process is shorter; if it cannot, a manual conversion burden arises at every round.
The Türkiye context
In translation into Turkish the value of the string ID is higher still, because of the structure of the language. In English a single word can be both a noun and a verb; in Turkish that ambiguity does not exist and you are obliged to choose. Without knowing whether a “Save” row is a button or a heading, the right rendering cannot be given.
The second point is suffix agreement. In a string containing a variable, which suffix is needed depends on the word the variable will bring in. If the notes column carries the information “%s here is the item name”, the translator builds the structure accordingly; if it does not, the sentence turns into a pattern that will not hold in every case.
The third is length. Turkish renderings are generally longer than the source. If the maximum length column has not been filled in, the translator has no way of knowing, and the overflow is only seen at the testing stage. Filling that column in is a few hours’ work on the developer’s side; leaving it empty is a cost spread across rounds of testing.
What does this mean for you?
Most of the quality of a localisation is settled in the file prepared before translation begins. The sequence below sets out the steps for making your file readable to a translator.
- Settle on a meaningful string ID convention: let it carry the type, the screen and the function.
- Do not change IDs in the middle of a project; if you must, produce a mapping table.
- Add character, location, asset type and maximum length columns to the table.
- Explain in the notes column what the variables and the conditional tags bring in.
- Prepare a localisation kit containing the guide, screenshots and character information.
- Deliver the translation memory and the termbase as part of the kit, and update them for later releases.
These steps take string IDs and kit preparation out of the realm of formality and turn them into a quality tool. If you would like to discuss your file structure and the scope, you can use our quotation form and look over the fields we work in on our services page.
Frequently asked questions
What is a string ID?
It is the unique label given to every piece of text that makes up a game. On the code side it serves to call the text; on the localisation side it serves to work out which text appears where.
How does a string ID affect the translation?
It carries context. The ID start_quest_button, for example, says that the text is a button which starts a quest; that information lets the translator choose a rendering that expresses an action rather than a noun.
What should a localisation kit contain?
Three groups: instructions and style guides, translatable assets, and technology files. The description of the game mechanics, character information, screenshots, length constraints and the translation memory are spread across those groups.
Do game engines offer tools for localisation?
Some of them do. Engines such as CryEngine, Godot and Unreal have components that extract localisable strings and set up the parallel structure. These tools speed up the preparation of the kit.
Sources
- Jiménez-Crespo, M. A. (2024). Localization in Translation. Routledge, pp. 210–218.
- IGDA Localization SIG (2021). Best Practices for Game Localization.
- CryEngine Documentation, UI Localization, docs.cryengine.com.