Your first game localization: a roadmap from decision to launch

You have decided your game is going to exist in more than one language. That decision is the easy part. What follows is a sequence of smaller decisions, and the reason first attempts go badly is almost never the translation itself — it is that the steps get done in the wrong order, so work has to be thrown away and redone.

The most expensive mistake is starting at the translation. Someone sends a spreadsheet of sentences to a translator, gets it back, and only then discovers that half the text in the game is not in that spreadsheet, that the translated lines do not fit the buttons, and that there is no mechanism for getting the file into the build at all.

This is the route in the order that actually works: decide the scope, make the text extractable, translate, reintegrate and check it in context, ship it alongside the store page, and keep it alive after release. Each phase below explains what you are deciding, what the realistic option is for a first project, and what happens if you skip it.

Decide how far you are going before you start

Two questions come first, and both are business decisions rather than technical ones: which languages, and how much of the game.

On languages, resist the urge to add several at once on your first pass. Every language you add multiplies not just translation cost but everything downstream — the UI has to fit in all of them, the fonts have to cover all of them, every future patch has to be translated into all of them, and every bug report arrives in a language you may not read. One additional language, done properly and kept updated, is worth more than four done once and abandoned. Pick the one where you already have evidence of demand: a region showing up in your wishlist or traffic data, players asking in comments, a streamer in that language.

On scope, understand that 'localized' is not all-or-nothing. Translating only the store page is a legitimate and very cheap starting point that lets players in that language decide whether to buy. Translating the UI but not the narrative works for games where the story is optional. Full text translation is the obvious target but not the mandatory first step. The one rule that matters is consistency: a player will forgive a game that is only partly available in their language if the boundary is clear and the store page did not promise more. They will not forgive a menu in their language and a tutorial they cannot read.

Write both decisions down before you touch anything. Everything below is shaped by them.

Get the text out of the code

This phase determines whether the rest is easy or miserable, and it is entirely engineering work with no translator involved. The goal is that every sentence a player can see lives in a file you can export, and the code refers to it by a stable key instead of containing the words.

Practically, that means going through the game and moving every visible string into a resource file — the format matters far less than the discipline, and CSV or JSON are both fine for a first project. Each row gets an identifier that describes where the text is used, not what it says, so the key survives a rewrite of the sentence. Four things reliably surface while you do this, and all of them are cheaper to fix now than after a translation has been delivered:

• Sentences assembled from fragments. Code that glues 'You found ' plus an item name plus '!' cannot be translated, because word order and the grammar around the item differ by language. Replace concatenation with one string containing a placeholder the translator can move
• Text baked into images. Any sign, logo, tutorial diagram, or button with letters drawn into the artwork is not in your file and nobody will translate it. Either produce a version per language or draw the text on top at runtime
• Fonts that do not cover the target language. A missing glyph renders as a blank box, and no amount of correct translation fixes it. Check coverage before you commission a single word — this bites hardest going into Japanese, Chinese, and Korean
• UI with no room to grow. Translations run longer than the original, noticeably so in German, Russian, and French. Boxes that wrap, expand, or shrink their font are the cheapest insurance you can build at this stage

key,en,ja
menu.settings.title,Settings,設定
shop.notEnoughGold,Not enough gold.,ゴールドが足りません。
quest.forest.accept,I'll look into it.,調べてみるよ。

Choose how it gets translated

Now, and only now, does anyone translate anything. You have a file, a word count, and a list of what is in scope, which is exactly what every option below needs in order to give you an answer.

Before picking a route, know that what you hand over matters as much as who you hand it to. A translator working blind produces literal, flat, occasionally wrong text — not because they are careless, but because 'Fire' is a spell, a command, an element, and a verb, and nothing in the spreadsheet says which. Send a context note per row for anything ambiguous, a character list with each speaker's tone, a glossary of proper nouns and their fixed translations, character limits for anything that must fit a fixed space, and if you possibly can, a build or a video so they can see the game. That package improves the result on every one of these routes:

• A professional game translator — the highest quality and the highest cost, and the only option that reliably handles tone, character voice, and cultural references. Worth prioritizing for narrative text and your store page even when the budget is small
• A bilingual acquaintance — extremely common for a first game, and workable if you treat it as a real job with a defined scope and have someone review the result. Being fluent in two languages is not the same skill as writing game text in one of them
• Machine or AI translation with a human review pass — viable for repetitive UI strings, dangerous for anything with wordplay, tone, or proper nouns. It will never tell you when it is wrong, so the review pass is not optional
• Community or volunteer translation — real goodwill exists, but it needs structure: agreed scope, credit, a glossary, and someone with final say on what ships

Put it back, then read it inside the game

Reintegrate early, with even a partial file, rather than waiting for the finished delivery. Putting the returned file into the project is where you discover that a translator's spreadsheet software changed your encoding, quoted your commas differently, or reordered your rows. Finding that on the first partial delivery is a small problem; finding it the night before launch is not.

Once the game runs in the new language, play it and look at the actual rendering, because a translation that is correct in a cell can still be broken on screen. Watch for text that runs past its box or gets cut off, lines that wrap in the wrong place, placeholders showing as literal symbols because a variable name got translated, missing glyphs as blank boxes, and strings still in the original language because they were never in the file.

Then check the states a normal playthrough never reaches: error messages, the quit confirmation, the out-of-storage warning, the credits, achievement popups, anything shown only on a first launch. These ship untranslated every single time, because nobody walks into them by accident.

You do not need to read the language to do most of this. Layout breakage, empty boxes, literal placeholders, and untranslated leftovers are all visible to someone who cannot read a word of the target language, and finding them yourself is far cheaper than paying a reviewer to find them for you.

Ship the build and the store page as one thing

A translated game behind an untranslated store page is a strange and self-defeating combination: the players you did the work for cannot read the page that would tell them the work exists. The store listing — title, short description, long description, and any text inside your screenshots — should be translated in the same pass, and it deserves your best translator rather than the leftover budget, because it is the only text a prospective buyer reads before deciding.

Set the supported-language flags on your store page to match what you actually shipped, and only what you actually shipped. Claiming a language you have only partly done, or have done with unreviewed machine output, produces exactly the review you do not want, and those reviews stay attached to the game long after you have fixed the text.

After launch, and what a realistic first pass looks like

Localization is not a task that finishes. Every patch adds strings, and each one goes through the same route: new rows appear in the file, they get translated, they get checked in context. Build a small habit rather than a big process — when you add a string, add it to the file with a status marking it untranslated, so the next translation round has a ready-made list. Players will also report mistakes, and having somewhere for them to report to, plus a record of what you changed, turns a stream of complaints into a maintainable backlog.

For a first project, a realistic and genuinely good outcome looks like this: one additional language, chosen because you saw demand for it; all text extracted into files, with fragment concatenation and baked-in image text dealt with; a translation you paid a person for on the narrative and store page, with machine assistance and human review on repetitive UI; a full playthrough in the new language plus a sweep of the screens nobody visits; store page and build shipped together with honest language flags; and a way for players to tell you what you got wrong.

That is a lot less than a full multi-language localization, and far more than most first attempts achieve — because it was done in an order that did not force anything to be redone.