A localization smoke test you can run before every release
A full localization pass — reading every screen in every language — does not fit before most releases. A smoke test does: a short, fixed sequence of checks run once per language, designed to surface the failures that are both common and severe, so a build with a broken language does not go out the door. This is not a replacement for deeper review; it is the net that catches what deeper review would have found anyway, just faster and closer to release.
The value of a smoke test comes from repeatability, not depth. The same script, run the same way, every time, means a regression is caught the first time it appears rather than discovered by a player. Below is a script written as steps a tester can actually follow, one language at a time.
Boot in each language
Start from a clean state with the target language selected, either through a system language setting or an in-game switch, and confirm the game actually boots into that language rather than falling back to a default. A language that silently falls back — often because a locale code is missing or misspelled somewhere in the build config — is a failure a full playtest can miss entirely if the tester never notices the fallback happened.
The first-run and first-hour screens
These are the highest-traffic screens in the entire game and the ones a new player forms an impression from. Walk through the title screen, any consent or account-creation flow, the tutorial, and the first few minutes of actual gameplay. Look specifically for truncated buttons, overlapping text, and any screen where a longer translation pushes UI elements off their intended position — these languages tend to expand relative to a Latin-alphabet source, and the first-run flow is usually the least battle-tested part of the UI because it changes less often than gameplay screens.
A screen with dynamic values
Find a screen that inserts a runtime value into a string — a damage number, a player name, a currency amount, an item count — and confirm the value actually appears, in the right position, with the right formatting for that value's type.
// what to look for on screen, not in the file
"You dealt {damage} damage!" → "You dealt 240 damage!"
// not: "You dealt {damage} damage!" (placeholder never substituted)
// not: "You dealt undefined damage!" (wrong variable bound)A long-string screen
Pick the screen most likely to contain your longest strings — an item description, a quest log entry, a settings explanation — and check it renders without being cut off, without the text overflowing its container, and without the text overlapping an adjacent element. This is a deliberate stress test: most screens will look fine in every language, and the value of checking is finding the one that does not.
Language switching
Switch the in-game language setting mid-session, without restarting, and confirm every visible screen updates to the new language — including menus that were already open, cached UI elements, and anything rendered from a value set earlier in the session. A language switch that requires a restart to fully apply is a common and easy-to-miss failure, because the tester who set the language once at boot never exercises the switch path at all.
- Boot in language A, switch to language B mid-session — every screen updates
- Switch back to language A — no leftover text from language B anywhere
- Any screen open at the moment of switching also updates, not just newly opened ones
Saving and reloading
Save progress while in a non-default language, close and relaunch the game, and load that save. Confirm the language persists correctly and that no save-related text (a save slot name, a timestamp, a save description) is garbled or shows the wrong language. Save data is a common place for a locale setting to get lost or overwritten silently, especially across an update that changes the save format.
Store text matching in-game terms
Finally, compare the store page description and any marketing screenshots against the actual in-game text, in the same language. A mismatch here — a feature name on the store page that does not match the in-game term, or a screenshot showing text from an older build — does not break gameplay, but it is the first thing a player in that language sees, and it undermines trust before the game is even launched.