The common localization bugs checklist: what to look for and why it happens

Most localization bugs are not exotic. Across projects and language pairs, the same small set of defect types keeps showing up, introduced by the same handful of causes: a spreadsheet edit, a merge, a source-text change that nobody re-flagged for translation. This is a working checklist of the ones worth actively watching for, what each looks like when a player hits it, how it tends to get introduced, and whether it is something a script can catch or something that needs a person reading for meaning.

Untranslated or source-identical strings

In game, this looks like English (or whatever the source language is) appearing inside an otherwise localized screen — a button, a tooltip, sometimes an entire line of dialogue. It gets introduced when a string is added after the translation pass already ran, or when a translator skips a line and it silently falls back to source text.

• In game: source-language text mixed into a localized screen
• Introduced by: new strings added after translation, or a skipped row that falls back silently
• Detectable mechanically: yes — target identical to source is a strong, cheap signal (with some legitimate exceptions, like proper nouns)

Placeholder mismatches

This looks like a literal `%s` or `{playerName}` printed on screen instead of the value it was supposed to hold, or — worse — a value substituted into the wrong place in the sentence because the placeholder order changed between languages without the code accounting for it. It is introduced when a translator retypes or drops a placeholder token, or reorders placeholders in a language where the natural word order differs from the source.

• In game: a raw token like `{count}` shown to the player, or the wrong value in the wrong slot
• Introduced by: retyped, dropped, or reordered placeholder tokens during translation
• Detectable mechanically: yes — compare the placeholder set between source and target per entry

Broken or unbalanced tags

Rich text tags — bold, color, line breaks embedded as markup — look, when broken, like formatting bleeding into the rest of the screen: an entire paragraph rendered bold because a closing tag was deleted, or literal tag text printed instead of being interpreted. This is introduced the same way placeholder mismatches are: a translator edits around the tag and drops or duplicates part of it.

• In game: formatting leaking past where it should stop, or raw tag text on screen
• Introduced by: tags edited, dropped, or reordered during translation
• Detectable mechanically: yes — tags can be counted and matched between source and target

Text overflow

This is a translated string that is technically correct but does not fit its UI container — text clipped, wrapped in an ugly place, or overlapping a neighboring element. Some languages are reliably longer than others for equivalent meaning, and a layout built for a shorter language exposes overflow the moment longer text is dropped in. Overflow is only partly mechanical: a length or character-count check can flag suspiciously long strings, but whether a given string actually breaks a specific layout usually requires looking at the rendered screen.

Encoding corruption

This shows up as garbled characters, replacement boxes, or question marks where accented letters or non-Latin scripts should be. It is introduced when a file passes through a step that assumes the wrong character encoding — a spreadsheet export, a copy-paste between tools, a script that reads a file without declaring UTF-8. It is straightforward to detect mechanically: scan for replacement characters and malformed byte sequences on import.

Duplicate keys

Two entries in the same file claim the same key, so whichever one the loader reads last silently wins and the other is discarded — with no error, no crash, just a string that quietly went missing. This is usually introduced by spreadsheet copy-paste, a merge of two branches that both added the same key, or an export process that concatenated files without checking for collisions. It is mechanically detectable: scan every file for repeated keys at import time.

Missing keys

The reverse of a duplicate: a key exists in the source file but has no corresponding entry in a target language, so the game either falls back to source text at runtime or, in a worse case, shows a blank or a key name on screen. This is introduced whenever a new key is added to the source file and the update never reaches every target language file. It is trivially mechanical to detect — diff the key sets between source and each target.

Stale translations after the source line changed

This is the quietest bug on this list: the key still exists, the translation still exists, and nothing looks broken — but the source text was edited after translation (a design change, a bug fix in the wording) and the translation was never updated to match. The result is a target string that is fluent, grammatically correct, and simply describes something the game no longer does. Whether the wording has drifted is a judgment call for a person, but the fact that the source changed after the last translation timestamp is a mechanical fact worth tracking per entry, so stale entries can at least be surfaced for review instead of going unnoticed.