Skip to content

Localization string table template

A string table that translators can work from: one row per key, with its context, its length limit, the English source and four translations, plus a glossary and a style guide for each language. Download it as a .zip: the table is a CSV file (UTF-8, comma-separated), the rest is Markdown, and the whole set imports into Nodary, where the CSV becomes a sheet you can use as a string table.

4 files in a .zip (Markdown and CSV), 5 kB

Free, no account, no email. Use it, change it, share it.

Read every file before you download

The overview explains the columns, how to name keys, placeholders and translation states. The table holds 13 sample strings from Saltmarrow, the sample game this site uses everywhere; two cells are wrong on purpose, to show what the checks catch.

Documents

File Localization string table template/Localization string table.md

Localization string table

How to use this template: italic lines are guidance. Replace them with your own words, then delete them. Values in square brackets are yours to fill in. The table itself is the CSV file next to this page.

The files

  • Strings: the table itself, one row per string, one column per language
  • Glossary: the words translated the same way everywhere, and the names never translated
  • Style guide: how the game speaks in each language

Columns

ColumnWhat it holds
keyA unique name for the string, never shown to players
contextWhere the text appears and who says it: what a translator cannot guess
max_lengthThe most characters the text may take on screen
enThe source text
fr, de, es, plOne column per language, named with its code

Naming keys

Name keys by where the text lives, from the general to the particular, so related strings sort together.

  • Pattern: [screen].[element].[detail], such as menu.play or hud.tide.warning
  • Lowercase, with dots between the parts and no spaces
  • Never reuse a key for a different text: add a new one

Placeholders and markup

Values the game fills in stay in braces, such as {count}; every translation keeps every placeholder of its source. Markup tags, such as the bold tag in item.crystal.desc, stay around the words they mark.

Translation states

  • MissingDraft
  • DraftReviewed
  • ReviewedFinal
  • FinalOutdated
  • OutdatedDraft
A translation’s state: a changed source makes it outdated, to be checked againA Mermaid diagram in the file: Nodary, GitHub and Obsidian draw it.
Mermaid
flowchart LR
  n0["Missing"]
  n1["Draft"]
  n2["Reviewed"]
  n3["Final"]
  n4["Outdated"]
  n0 --> n1
  n1 --> n2
  n2 --> n3
  n3 --> n4
  n4 --> n1

Example (Saltmarrow, a sample game): Two cells of the sample are wrong on purpose. menu.settings in German, Einstellungen, has 13 characters where the button holds 10, so the length check flags it; the Archivist’s greeting has no Polish yet, so it counts as missing.

This template is free to use, change and share. It comes from Nodary, where these files import as a map of linked documents and the CSV as a sheet.

Download the template4 files in a .zip (Markdown and CSV), 5 kB

How to use it

  1. Replace the sample strings

    Keep the columns and the key naming, and put your own strings in. Give every string a context and a length limit before it goes to a translator.

  2. Write the glossary early

    Add each term the first time a translator asks about it, with its translation in every language. A word translated two ways confuses players and doubles support questions.

  3. Agree on the style per language

    Decide how each language addresses the player and its typography rules before translation starts. Changing it later means rereading every string.

  4. Freeze the source before you send it

    Send strings for translation once their English is final. When a source changes afterwards, its translations need checking again.

Import it into Nodary and use it as a string table

Nodary is an AI-native workspace where a team’s documents link instead of piling up. Import the .zip and the CSV arrives as a sheet under the overview, with the glossary and the style guide beside it. On the sheet, String table reads the roles from the headers (key, context, max_length and one column per language), then checks every translation for length and placeholders, gives each one a state, marks a translation outdated when its source changes, and exports files for Unity, Unreal and Godot: CSV, JSON, gettext .po and XLIFF.

  1. Open a project’s map and choose Import.
  2. Choose the Folder or ZIP tab, then Choose a ZIP, pick the file and import.
  3. Open Strings, choose String table, check the roles read from the headers, then Use as a string table.

The Free plan holds ten documents per workspace, the project’s own page included: the template’s four fit with room to spare. The source column is English: if your game is written in another language, make that column the source when Nodary shows the roles.

How Nodary handles game localization
Saltmarrow’s string table in Nodary: keys, context and maximum lengths with English, French, German, Japanese and Brazilian Portuguese columns, the progress of each language, and warnings on a German string that is too long and one that lost its {seconds} placeholder.

Keeping a string table translators can work from

A string table fails when translators have to guess what a line means or how much room it has, or when text changes after it was translated and nobody notices. These habits prevent all three.

Give every string a context

Who says it, where it appears, what it answers. “Open” is a verb on a door and an adjective on a shop: only the context tells.

Set the length from the screen

Measure how many characters the button, the line or the bubble can hold, and write that limit, not the length of the English.

Never build sentences from pieces

Joining “You found” and “3 crystals” in code breaks word order and grammar in most languages. Give each sentence its own key, with placeholders.

Keep placeholders whole

Every translation keeps every {placeholder} and every tag of its source. A lost {count} shows players a blank, or crashes the game.

One key, one meaning

Never reuse a key for a different text. Add a new key; remove the old one once nothing uses it.

Freeze the source before you send it

Translate text that is final. When a source changes anyway, mark its translations as outdated so they are checked again.

Questions about localization string tables

What is a localization string table?

A string table holds every piece of text a game shows, one row per string: a key the code uses, the source text, notes for translators, a length limit, and one column per language. The game loads the text by key in the player’s language, so text can change and be translated without touching the code.

Which columns should a string table have?

At least a key and the source text, then one column per language. A context column and a maximum length column save most of the questions translators would otherwise ask. This template has all five kinds, with English as the source and French, German, Spanish and Polish.

How should I name string keys?

By where the text lives, from the general to the particular, such as menu.play or hud.tide.warning: lowercase, with dots between the parts. Related strings then sort together, and a key says where to look in the game.

How do I handle plurals?

Languages count differently: Polish has three plural forms where English has two. Either put the number after a label, such as “Salt: {count}”, or use your engine’s plural system with one text per form.

How do I open the CSV in Excel?

Google Sheets, LibreOffice Calc, Numbers and Nodary open it as is. Excel opens it with a double-click only where the computer’s list separator is a comma; where it is a semicolon, as in French, German, Spanish or Polish settings, each row lands in one column. Then import it instead: on the Data tab, choose From Text/CSV, pick the file, set the file origin to UTF-8 and the delimiter to Comma, and load it.

Will Unity, Unreal or Godot read this CSV?

The template’s CSV is made for spreadsheets and for Nodary’s import. Engines each read their own format: from the same table, Nodary’s string table exports CSV for Godot and Unity, gettext .po for Unreal and Godot, JSON for most engines and XLIFF for translation tools.

Can I add languages?

Yes. Add a column named with the language’s code, such as ja or pt-BR. Nodary recognizes codes and language names in the headers, and its string table can add a column for a language too.

Keep the game’s text where the team works.

Import the template into Nodary and the string table sits on the same map as the design and the dialogue, with every translation’s state in view. Free with two members, one project and ten documents, no card needed.