Why localized text has to be seen in the real UI

A translated string can be entirely correct in the file and still be wrong on screen. Fonts render differently than a spreadsheet cell suggests, text boxes have real pixel limits a translation memory tool knows nothing about, and line breaks that looked fine in one language can land in an awkward place in another. The only way to catch these is to actually look at the text where players will — in the running UI, on the real device, in the real font.

What differs between a spreadsheet and the running game

A few categories of problem are specific to on-device rendering and essentially invisible anywhere else:

• Overflow and truncation — a translated string longer than the source language overruns a fixed-width button or gets cut off mid-word
• Line breaks in the wrong place — automatic wrapping can break a word or a name awkwardly in a language with different spacing and character-width conventions than the source
• Font coverage — a font that renders the source language fine may be missing glyphs for another script entirely, showing blank boxes or fallback characters
• Input and interaction — on-screen keyboards, text input fields, and controller prompts can behave differently per language and per platform

A fast language-switch workflow for testers

The practical blocker to on-device testing is usually friction: if switching languages means restarting the game, navigating several menus, or waiting through a loading screen each time, testers check far fewer screens than they should. Investing in a fast way to switch the active language — a debug menu option, a command-line flag, a hotkey — pays for itself quickly, because it turns a slow, easy-to-skip check into something a tester can do dozens of times in a session.

Running a screenshot pass

A screenshot pass — systematically walking through the game's key screens in each language and capturing what's on screen — is a simple, low-tech way to catch overflow and truncation without needing every reviewer to be a native speaker of every language. A native speaker can review the screenshots for correctness later; the pass itself is checking that the layout holds up, which anyone on the team can do.

Which screens to prioritize

Not every screen carries equal risk. Static text that was reviewed once and never changes is comparatively low risk; the highest-value screens to check are the ones where the visible text is assembled at runtime and therefore was never actually seen as final text by anyone during translation:

• Screens with placeholders — item names, player names, or numbers inserted into a template string, since the combined length was never checked against the layout
• Number and quantity displays, especially where a language's number formatting or pluralization differs from the source
• Any screen where text length depends on player state — inventory counts, currency amounts, long player-chosen names
• Newly added screens for the current update, since they haven't been through a previous pass

Logging what a screenshot actually shows

A screenshot without metadata loses most of its value quickly. Tag each one with the build version and the language it was captured in before filing it anywhere — otherwise a bug report becomes 'this text looked wrong at some point,' which is difficult to reproduce or even to confirm is still an issue on the current build.

screenshot: shop-menu_ja_release-2026.08.1.png
  build: release-2026.08.1
  language: ja
  screen: shop menu, item description panel

The habit that matters more than the tooling

None of this requires elaborate tooling to start — a debug hotkey and a shared screenshot folder with a naming convention gets most teams most of the way there. What matters more is treating on-device review as a required step for any UI or text change, not an occasional spot-check, since the layout problems this process catches are invisible in every other stage of review.