What is a localization string table?
A localization string table stores every text of a game or app under a key, with one column per language.
How it works
The code asks for a key such as menu.start, and the table answers with the text in the player’s language. Engines read tables as files: Unity’s Localization package has string tables, Godot reads CSV, and gettext .po and XLIFF are common exchange formats.
Each row usually carries context for the translator, a maximum length, placeholders that must survive translation, and the state of each translation.
An example
The key quest.lighthouse.title reads The Drowned Light in English. The German translation is too long for its 24-character slot, so the table flags it before a build, and the translator gets the context note.
Common mistakes
- Putting text straight in the code, so nothing can be translated without a build.
- No context, so translators guess what a word means.
- Breaking placeholders such as %s or %d in translation.
In Nodary
A Nodary sheet can be a string table: a state per translation, length and placeholder checks, a pseudo-language for testing, and exports for Unity, Unreal and Godot as CSV, JSON, gettext .po and XLIFF. A build can read it over HTTP with a read-only key.
What Nodary does not do: it is not a translation management system: there is no translation memory and no marketplace of translators.
Game localization tool · Localization string table template
Try it on your own documents. The Free plan needs no card.
Create a free workspace