When to localize: launch day, after launch, or somewhere between
Localization timing gets treated as a single yes/no question — do we localize or not — when it is really a scheduling question with several reasonable answers. You can localize before launch, after launch, or in stages. Each choice trades risk, cost, and speed differently, and the right one depends on how your text was built, not just on how big your budget is.
Simultaneous launch (sim-ship)
Shipping all target languages on day one means every language gets the visibility of the launch window — store algorithms, press coverage, and early reviews all happen once, and a sim-ship lets every supported language benefit from it. It also avoids ever shipping a mixed-language build, which is the outcome players notice fastest and forgive slowest.
The cost is that translation has to happen against a text base that is still changing during development, which means either freezing text earlier than the team would otherwise want, or re-translating changed strings under time pressure right before release. It also means paying full translation cost for languages whose demand is still a guess.
Post-launch localization
Localizing after launch lets you spend translation budget on languages with evidence behind them — wishlist regions, community requests, reviews asking for a specific language — instead of guessing at launch. It also means translating a text base that has already stabilized, which is cheaper per word because there is less rework.
The tradeoff is that you launch without the languages you eventually add, so you miss the launch-window visibility for them, and you carry the cost of a second release cycle: QA, store listing updates, and community communication all repeat for the add-on language.
The retrofitting trap
The expensive version of post-launch localization is not the plan itself — it is discovering that your text was never structured to leave the codebase. Strings concatenated at runtime, text baked into image assets, dialogue hardcoded next to game logic, and UI that assumes short English words all turn a translation task into an engineering task first.
A short illustration: a hardcoded English sentence built at runtime from fragments is nearly impossible to translate correctly, because word order and grammar differ by language.
// Breaks in translation — word order is not universal
const message = "You found " + itemCount + " " + itemName + "s";
// Exportable — one placeholder-driven string per locale
const message = t("found_items", { count: itemCount, item: itemName });Signals it is time
A few concrete signals are more reliable than a fixed calendar date:
- Store page traffic or wishlist adds from a region whose language you do not support
- Repeated requests for a specific language in reviews or community channels
- Your update cadence has slowed enough that translating a stable text base is realistic
- You have counted your word volume and it fits a known, bounded budget
Middle roads
Sim-ship and post-launch are the two extremes, not the only options. Localizing the store page first is the cheapest possible test of demand — it costs a fraction of full in-game localization and gives you a real signal (wishlists, page views) before you commit further. Another common middle road is picking one priority language for the in-game text based on the strongest signal you already have, and expanding only once that language performs.
Whichever path you choose, the decision that actually determines your options later is made earlier: keep text out of code and in exportable files with stable keys from the first line you write. That choice is what makes 'localize after launch' a real option instead of a rewrite.