Process & operationsこの記事を日本語で読む

The release-day localization checklist

Most localization bugs are caught during development. The ones that ship are usually the ones nobody thought to check in the final week, because attention has already shifted to build stability and store submission. This is a checklist for that last pass — specific items, and the reason each one earns a place on the list.

Build and boot

These are pass/fail checks, not judgment calls, which makes them the cheapest ones to catch late — but only if someone actually launches each locale rather than trusting that 'it built' means 'it runs.'

  • Every supported language builds and launches on every target platform — a language-specific asset or font that fails to load can crash the build in one locale only, and that locale is easy to skip if testing time is short
  • The correct language loads based on the platform's declared locale setting, not just from an in-game menu — players who never open settings should still see their system language on first launch

The first hour

The first hour of play is disproportionately visible: it is what streamers show, what review copies are judged on, and what a player uses to decide whether to keep playing. Untranslated or placeholder text anywhere in the opening sequence, tutorial, or first-area dialogue is far more damaging than the same issue twenty hours in.

  • No literal placeholder strings (lorem ipsum, TODO, debug keys like ui.button.confirm) visible anywhere in the opening flow
  • Tutorial prompts and onboarding text fully translated — this is the text with the highest read rate in the entire game

Consistency with the outside world

A player's experience of your game does not start at the title screen. It starts at the store listing, and inconsistency between what the store promises and what the game delivers reads as carelessness even when both are individually correct.

  • Store page terminology (item names, feature names, mode names) matches what actually appears in-game — a renamed feature that shipped after the store copy was written is a common source of mismatch
  • Marketing screenshots and trailers reflect the shipped translation, not an earlier draft

Rendering and formatting

These are the class of bug that is invisible if you only test in your own language, because your language's formatting conventions look correct to you by default.

  • Fonts render every character used by every supported language, including punctuation and any special glyphs — missing-glyph boxes ('tofu') are one of the most visible localization failures possible
  • Date, time, and number formats follow each locale's convention (day/month order, decimal versus thousands separators) rather than a single hardcoded format
  • UI layouts survive the longest string in every language without truncation or overlap — German and Finnish text commonly runs longer than English for the same meaning

Mechanics that touch localization

Beyond the text itself, a few game systems interact with localization and deserve their own check:

  • In-game language switching (if offered) works without requiring a restart, or is clearly communicated if a restart is required
  • Save data, cloud saves, and any user-generated text handle every supported character set without corruption

Credit and plan for what comes after

Two items are easy to skip because they are not bugs — they are process, and process has no failing test to catch its absence.

No release ships with zero text issues. The teams that recover quickly are the ones who decided, before launch, who owns the fix and how it goes out — not the ones who scramble to figure that out after the first bug report arrives.

  • Translators are credited — a basic professional courtesy, and often a contractual one
  • A concrete plan exists for post-launch text fixes: who reviews player-reported localization bugs, how a hotfix for text gets built and shipped without a full patch cycle, and who owns translating new content added after launch

Related articles