The Automated Game Localization QA Checklist: Variables, Placeholders, Truncation, Line Breaks, and RTL

The most embarrassing localization bugs in games usually aren't about bad translation. They're {player_name} showing up as literal source text, a button label truncated mid-word, or an entire Arabic UI mirrored the wrong way. None of these have anything to do with translation quality—they're engineering and formatting issues. And precisely because of that, most of them can be checked by a machine, one item at a time.

Human LQA should spend its energy on tone, terminology, and emotion—things a machine can't judge. But the "right or wrong, no ambiguity" class of issues below can be handed off to automation and run on every build. This is a bookmarkable, game-focused automated QA checklist.

Variables and Placeholders: The Highest-Priority Machine Checks

Placeholder errors are among the most common post-launch issues, and also the easiest to catch automatically. Put them first on the list.

• Matching placeholder counts: if the source string has three {count}, %s, or %1$s tokens, the translation must have exactly the same number—no more, no fewer. Drop one and you get a blank hole or a broken line in-game.
• Matching placeholder names/indexes: a named placeholder {player} must not be "translated" into {玩家}; positional arguments like %1$s %2$s must not have their indexes swapped.
• Intact format specifiers: format tokens like %d, %.2f, or {0:N0} must not have their internal characters altered or spaces inserted.
• Complete plural and gender variants: when using ICU MessageFormat plural/select, every branch required by the target language (e.g. Russian's one/few/many/other) must be present.
• Paired HTML/rich-text tags: tags like <b>…</b> or <color=#fff>…</color> must be paired and correctly nested. Their order can shift to follow grammar, but no tag may be lost.

All of these rules can be expressed as regexes or syntax-tree assertions and run against the full string set in CI. For how to layer these hard checks against the softer question of "is the translation any good," see our breakdown of the AI LQA scoring framework.

Truncation and Overflow: Only Exposed at Real Fonts and Resolutions

Text length is the nemesis of game UI. German, Finnish, and Russian commonly run longer than English—often +30% or more on short strings—though the exact expansion varies by language and string length (a rule of thumb, not a fixed figure), while Chinese, Japanese, and Korean have a much higher per-character information density. Machine-checkable items include:

• Length caps: for keys with a maxLength constraint, flag any translation that exceeds it.
• Pixel-width estimation: using the target font's metrics, estimate whether the rendered width overflows the control. This is more accurate than raw character counts, especially for CJK and monospaced digits.
• Critical UI element allowlist: separately mark positions that must never wrap or truncate—buttons, tabs, currency figures—and apply stricter thresholds.
• Number and unit formatting: thousands separators, decimal points, and currency symbol placement vary by locale, and so does length; fold that into the estimate.

Manually checking every language on every resolution, screen by screen, isn't realistic. Automation can surface the high-risk items first, so humans can focus their review where it matters.

Line Breaks, Spaces, and Escaping: Invisible but Dangerous

This class of issue often "looks fine" on the test device and falls apart on another device or in another language.

Check	Typical problem	Machine rule
Line breaks	Translation silently adds/removes \n, breaking multi-line layout	Compare count and positional semantics of breaks in source vs. translation
Non-breaking spaces	A is replaced by a normal space in CJK or RTL	Detect whether specific Unicode spaces are preserved
Escape sequences	\", \\, \t are wrongly escaped or unescaped	Validate that escapes are legal in the target format
Leading/trailing whitespace	Extra spaces at the start/end break concatenation	Compare after trimming, flag suspicious diffs
Control characters	Zero-width characters, BOM, or control codes appear	Scan for invisible characters and warn

This matters most when strings are concatenated (assembled at runtime from fragments). Inconsistent leading/trailing whitespace or line breaks will almost always cause display problems there, so it's worth making a hard blocker.

Font Fallback and Character Coverage: Don't Let Players See Tofu

When adding a new language, the easiest thing to overlook is whether your font actually has glyphs for those characters. When a glyph is missing, the engine renders a box (the infamous "tofu"), and in bad cases an entire sentence becomes unreadable.

• Character set coverage: for every code point in every translation, verify the target font (including its fallback chain) provides a glyph.
• Fallback chain validation: confirm that languages needing dedicated fonts—CJK, Arabic, Thai, Devanagari—have a corresponding font in the fallback chain.
• Combining characters and ligatures: Thai, Hindi, and others require correct glyph shaping. Confirm the render pipeline supports it, not merely that the code points exist.
• Emoji and symbols: check whether emoji and special symbols in event copy are defined in the chosen font.

This step kills the "ship it, then discover a screen full of boxes" risk before packaging.

RTL and Bidirectional Text: The Arabic and Hebrew Minefield

Right-to-left (RTL) languages aren't just "text reversed." The machine-checkable items are relatively focused, but missing one is glaringly obvious:

• Directional marks: when mixing LTR and RTL (e.g. an English ID or number embedded in an Arabic sentence), check whether directional controls like ‎/‏ are needed to avoid reordering.
• Placeholder position in bidirectional text: verify the visual order is correct when numbers or {var} are embedded in RTL text.
• Mirroring friendliness: a translation can't decide UI mirroring on its own, but you can flag high-risk combinations—RTL characters placed into an un-mirrored UI—and prompt human review.
• Punctuation direction: confirm brackets and quotation marks open and close in the correct direction under RTL.

Wire the Checklist into the Pipeline, Not at the Last Minute

The value of these checks lies in running them early and every time. We recommend:

1. As a CI gate: trigger full validation on every string change or build, with the hard items above set as blocking and the suspicious ones as warnings.
2. Layered handling: let the machine handle format and consistency first, catching the unambiguous errors; then let humans and AI LQA focus on tone, terminology, and cultural adaptation.
3. Combine with a runtime safety net: even so, some overflow or misalignment only shows up on real devices. When that happens, you don't have to wait for the next build—see in-game realtime string fixing to locate and fix problem strings at runtime.

Loxily's approach is to connect this machine-checkable checklist with game-context-aware AI LQA and runtime realtime fixing into a single line: let rules catch formatting issues, let a model that understands games handle context and quality, and let realtime fixing clean up whatever slips through.

Conclusion

Most localization "disasters" in games are engineering and formatting problems, not translation-quality problems—which means most of them can be caught by automation, one item at a time. Turn variables, placeholders, truncation, line breaks, escaping, font fallback, and RTL into a checklist that runs on every build, and you'll eliminate the vast majority of dumb errors before launch—freeing your precious human effort for the things a machine can't judge.