How to make an English version of your game: the whole process

At some point you decided your game should have an English version. Maybe a player left a comment asking for one, in a language you had to run through a translator yourself. Maybe you looked at where the traffic to your store page comes from and realised that most of the people who see it cannot read a word of it. Either way, the question in front of you now is a practical one: what do you actually have to do?

The short answer is that making an English version is a small project with five distinct stages, and translation is only one of them. The other four — deciding what gets translated, getting the text out of your game in a form a translator can work with, putting it back in, and checking the result in the running game — are where most of the work and nearly all of the mistakes live.

This article is the map rather than the deep dive. It names the stages, tells you what each one asks you to decide, and puts them in a sensible order. The word the industry uses for the whole thing is localization: translation plus everything around it that makes a game work for players in another language. The rest of the vocabulary you will meet as we go.

Count everything in your game that has words in it

Start with an inventory, not with translation. Almost everyone underestimates their own game here, because when you think about 'the text' you picture the dialogue and forget the dozens of other places words appear.

• Menus, settings, buttons, and confirmation prompts
• Dialogue, narration, and anything a character says out loud
• Item, skill, enemy, and location names, plus all their descriptions
• Tutorial text, hints, and tooltips
• Error and system messages, including the ones players almost never see
• Achievement names and descriptions, which are entered on the store side rather than in your project
• Credits, legal notices, and the title screen
• Text drawn into images: logos, signs, UI art, anything painted into a texture
• Your store page, your patch notes, and the posts you write about the game

Two of those deserve a warning. Text baked into images is invisible to every tool and to every word count, so it gets discovered late — usually when somebody plays the English build and finds a signpost in the middle of your world still written in the original language. And achievements live in the platform's back end rather than in your project files, which makes them the single most commonly forgotten piece of a first English version.

You do not have to translate all of it. You do have to know it all exists before you decide what to leave out, because a scope you chose on purpose reads completely differently to players than a scope that happened by accident.

Get the text out of your game

A translator cannot work inside your project, and you would not want them to. What they need is a file: one list of every line of text, in an order that makes some kind of sense, with an empty column beside it to fill in.

Whether producing that file takes you an afternoon or a fortnight comes down to a single question — was your text written directly into your code and scenes, or stored separately? Text typed straight into a function call or a dialogue node is called hardcoded, and hardcoded text cannot be exported, cannot be counted, and cannot be swapped out while the game runs. Getting it out is usually the largest single piece of engineering work in a first English version, and it is work you have to do before translation, not after.

The shape you are aiming for is simple: your code refers to a line by a short name, and a separate file holds what that name means in each language.

// Before — the words are welded to the code
showMessage("所持金が足りません。");

// After — the code names the line, the file holds the words
showMessage(t("shop.error.not_enough_gold"));

// strings.csv
key,ja,en
shop.error.not_enough_gold,"所持金が足りません。","You do not have enough gold."
ui.button.confirm,"決定","Confirm"

Every mainstream engine has some support for this, and using it beats inventing your own system. Unity ships a Localization package built around string tables, Unreal has String Tables and a localization pipeline built on its FText type, Godot can import translations from CSV or PO files, and RPG Maker MZ stores its database as JSON that external tools can read. Menu locations and button names move between versions, so read the localization chapter of your engine's own current documentation rather than trusting a tutorial from a few years ago.

While you are in there, fix one other habit: sentences assembled by gluing fragments together in code. Something like 'You found ' plus the item name plus '!' works in the language you wrote it in and breaks in most others, because word order is not universal and the fragments arrive at the translator as meaningless scraps. Write the whole sentence as a single line with a marked slot inside it, so the translator can see the sentence and move the slot to wherever their grammar needs it to go.

Decide who is going to translate it

There is no single right answer here, only a trade between money, time, and how much risk you can absorb. The honest version of each option looks like this:

• Yourself, if you are genuinely fluent. Cheap and fast, but you cannot hear your own accent — text that feels natural to you can read as slightly off to a native speaker in a way that is very hard to self-diagnose
• A machine translation or AI pass. Nearly free and instant, genuinely useful as a first draft, and it fails precisely where games are hardest: proper nouns it has never seen, lines with no surrounding context, jokes, and text that must fit a fixed width. Left unchecked it produces output that reads fine sentence by sentence and wrong as a whole
• A bilingual friend or family member. Better than a machine at judging whether something sounds natural, but being bilingual is not the same skill as translating — game text has conventions, and a friend has no way to tell you when a line needs rewriting rather than translating
• A freelance translator who works on games. The usual answer for a serious release: they know the conventions, they ask you questions, and they can hold a character's voice steady across thousands of lines
• An agency. Worth it when volume, multiple languages, or a deadline make coordination the actual problem rather than the translation itself

For a first English version the realistic answer is often a mix: a machine or AI first pass over the low-risk bulk, a human on the parts players read most — the opening hour, the store page, anything with personality in it — and a native speaker's eyes over the whole thing before release.

Whoever does the work, give them context. A spreadsheet of disconnected lines with no indication of who says them, where they appear, or how much room they have is the single biggest cause of bad translations that were nobody's fault. A character list, a handful of screenshots, a note about character limits, and a playable build are worth more to the result than a bigger budget with none of those things.

Put it back in, then actually play it

Getting the translated text back into the build is mechanically easy if you did the export stage properly — the file comes back with a filled-in column, and you import it. The stage after that is where the real work hides.

Reading a translation in a spreadsheet tells you almost nothing about how it behaves in your game. Playing the game in the new language and looking for the problems a text file cannot show you has a name — localization QA, usually shortened to LQA — and skipping it is the reason so many first English versions look rough even when the translation itself was fine.

• Text that runs past its box, gets clipped, or auto-shrinks to an unreadable size — English lines are frequently longer than the same content in Japanese, and UI laid out against the original text will not always accommodate that
• Lines still showing in the original language because they were hardcoded and got missed
• Slots showing up literally on screen, or filled with the wrong value because arguments ended up in a different order
• Line breaks landing in strange places, and characters rendering as empty boxes because the font does not include them
• Translations that are correct in isolation but wrong in place: a button labelled with a noun where the original was a verb, or a Yes and No pair that no longer matches the question above them

Do this pass yourself even if your English is weak — layout problems are visible without understanding a single word, and they are a large share of what goes wrong. Then get somebody who reads English comfortably to play at least the opening hour and the whole of any menu they can reach.

Translate the store page too, and probably first

The store page is the only text most people will ever read. Somebody who cannot read your page never reaches your game, no matter how well the game itself is translated, so a beautifully localized build sitting behind an untranslated store listing is a strange place to end up.

It is also the cheapest item on the whole list — a few hundred words covering the short description that appears in search results and recommendation panels, the longer description, any captions on your screenshots, and ideally screenshots showing the English interface rather than the original one.

Storefronts also ask you to declare which languages you support, usually separating the interface, the subtitles, and the audio. Be accurate. A language you claim but only machine-translated will be found out, and it gets found out in reviews, where it damages you more than the missing language ever would have.

There is a real strategy hiding in this section. Translating the store page alone, before you touch a single line of the game, is the cheapest way to find out whether English-speaking players want what you made. Wishlists, traffic, and follows from English-speaking regions after the page goes live are demand data you simply did not have before, and they are a far better basis for deciding whether to fund a full translation than your own guess.

What to do first, this week

The steps below are ordered so that each one is useful on its own, even if you stop there. Nothing here requires you to commit to a full English release before you know whether it is worth it.

• Spend one evening writing the inventory. Actually list the places text lives in your game, including the images and the achievements
• Find out whether you can export all your text today. If the answer is no, that is your first project, and it is worth doing whether or not you ever translate anything
• Translate and publish your store page. Then watch your regional numbers for a few weeks
• Clean up the source text before translating it: unglue assembled sentences, note the character limits, and write down anything a translator would have to ask you about
• Translate the game, starting with what players see first — the opening, the menus, the tutorial
• Book time for the play-through check, in both the language you wrote and the one you added. This is not optional polish; it is the step that decides how the result is received