A practical game localisation release checklist

A filled translation cell can still hide a release problem. Before handing strings back to your engine, check the table itself, compare it with your previous release, and test the result in game.

1. Keep stable keys

Use one unique key for each string and keep it stable between releases. Check for duplicate or blank keys, an empty source column and missing target cells. A wide table starts with headers such as key,en,fr,de. Save UTF-8 text and quote fields containing commas or line breaks.

Download a blank CSV and synthetic QA example. The example intentionally contains issues; it is practice data, not a translation glossary.

2. Check placeholder names and counts

If the source says Hello {player}, a translated line must preserve the recognised {player} token. Named placeholders can move with the sentence, but their names and occurrence counts matter. Repeated tokens need repeated occurrences.

Unnumbered printf placeholders also need their order checked. ICU plural/select and nested messages need a specialised message-format checker and the engine’s own tests.

3. Compare source edits between releases

The target is filled, so a missing-cell check passes. The source changed and the target stayed the same: put this row in the review queue. That is a signal for a translator to inspect, not proof that the translation is wrong. An unchanged short menu label may be intentional.

Also review newly added keys and confirm that removed keys are really obsolete. Keep a baseline copy of each released table so the next comparison has a reliable starting point.

4. Test real screens in your engine

Structural checks cannot judge the quality of a translation or measure its rendered width. Test menu buttons, subtitles and narrow labels with long strings; check font coverage and the engine’s plural and layout behaviour. Pseudolocalisation can help exercise expansion, but it does not replace a real translated build.

5. Share a review report safely

Give each finding its key, target language, reason and review decision. QA exports can contain your original project text, so keep confidential reports private. Send a small synthetic example when asking a tool vendor for help.