Using AI to translate your game: a workflow for solo developers

You have a finished game, no localization budget, and a slowly growing list of players asking for their language. AI translation is the only option you can actually afford, and you have probably already pasted a few lines into a chat window to see what came back. It looked fine.

That is exactly the problem. AI translation output looks finished whether or not it is correct, and a developer who cannot read the target language has no moment where the mistake announces itself. The line that reads as a polite greeting to you might be addressing an adult NPC like a small child. You will not find out until a review says so.

This is not an argument for avoiding it. Plenty of small games ship with AI-assisted translation and their players are fine with it. What separates those from the ones that get picked apart in reviews is rarely the model — it is the workflow around it: what you decide before you start, what you refuse to let the model touch, and what you verify on every single line before it ships. Here is that workflow, in the order the steps actually have to happen.

Decide what AI translates, and what it never touches

Your text is not one thing. Before translating a single line, sort it by how expensive a mistake would be, because that decides where your limited attention and money go later.

Menu labels, system messages, item names, and settings screens are the safest category. They repeat, they rarely depend on who is speaking, and a wrong word is usually obvious in context. Their real risk is length rather than meaning: a button that fits in your language may not fit once translated.

Story text is the opposite. Dialogue, character banter, jokes, and anything where a relationship between two characters is being expressed is where AI produces its most convincing failures — grammatically clean sentences that quietly flatten a character into a generic voice, or invert who is deferring to whom. This is the category worth reserving your human review budget for.

Then there is text that is not really prose at all, and should not be sent to a model in the first place if you can avoid it:

• Placeholder tokens and variables — anything of the form {name}, %s, or [count] must survive byte for byte
• Markup and rich-text tags used by your engine for color, size, or ruby text
• Key columns and identifiers — these are addresses, not content, and a rewritten key silently drops the line from your build
• Legal or store-facing text that carries a commitment: refund wording, age-rating content descriptions, anything about payment

Write the glossary before the first prompt

The single highest-return thing you can do before translating is to write down the terms whose translation must never vary. Character names, place names, item and skill names, invented words specific to your world, and system vocabulary such as stamina, save slot, or party. Add a short note on what each one is, because a name with no explanation is exactly as ambiguous to a model as it would be to a human translator.

This has to happen first, not later. A model translating a long file will drift: the same skill name gets three different renderings across a few thousand lines, and none of them is wrong on its own. If you decide the vocabulary afterwards, you are not applying a glossary, you are doing a retrofit search-and-replace across text you cannot read.

Keep the glossary in a small file next to your text, in a format you can paste into a prompt and also grep later. A plain CSV is enough:

source,target,type,note
Ember,Ember,character,protagonist - teenage girl - speaks casually
Hollow Reach,Hollow Reach,place,the ruined city in chapter 3 - do not translate
Soulbind,Soulbind,skill,player skill that links two party members
Stamina,Stamina,system,resource bar shown under HP

Give the model the context a translator would ask for

A bare string is ambiguous in ways you stop noticing after years inside your own project. Fire is a noun, a verb, and an order to shoot. Close could be a button or an adjective. Save could mean rescuing someone. A model has to guess, and it guesses fluently.

The fix is cheap: add context columns to whatever you export, and send them along with the text. Speaker, the screen or scene the line appears on, the maximum length it can occupy, and a one-line note where the meaning is not obvious. If your export format has nowhere to put this, that is worth fixing before you translate, because the same columns are what a human translator would ask you for anyway.

Give the model a short project brief once at the start of each session as well: genre, tone, who the player is assumed to be, how formally the game addresses the player, and any language-specific decision you have already made — such as whether the game speaks to the player politely or casually, which is a decision you have to make consciously in Japanese, Korean, German, French, and many other languages.

key,source,speaker,screen,max_chars,note
ui.btn.close,Close,-,settings,8,button label
ch01.ember.012,Fire!,Ember,battle intro,40,shouted order to attack
item.086.desc,A cracked lens.,-,inventory,60,flavor text - slightly wistful

Keep the round trip mechanical

The bugs that actually reach players in AI-assisted localization are usually not translation-quality bugs. They are round-trip bugs: rows lost, rows merged, rows reordered, keys rewritten, quotes escaped differently, a trailing space removed that your engine needed. None of these require the translation itself to be wrong.

So treat the exchange with the model as a data transformation, not a conversation. Send the key with every line and require the key back unchanged. Translate in batches small enough that you can verify the row count of the reply against the row count you sent, and reject any batch where they differ instead of trying to patch it by hand. Ask for the output in the same machine-readable shape you sent, and never assemble the final file by copying out of a chat window line by line.

Also watch for the model being helpful in ways you did not ask for. It will sometimes correct typos in your source, convert straight quotes to typographic ones, normalize your placeholder syntax to something it considers more standard, or add a closing tag you never opened. Each of these is silent until it reaches a build.

Instructions to include in every batch:
- Return exactly the same number of rows, in the same order.
- Copy the key column unchanged.
- Leave anything inside { } or < > exactly as it appears, including spacing.
- Do not add, merge, split, or reorder rows.
- Do not correct or rewrite the source column.
- If a line cannot be translated, return it unchanged and flag it in a notes column.

The four failure categories that cost the most

Not all AI mistakes are equally expensive. Four categories account for most of the damage in a small game, and each one has a specific mechanism worth knowing.

Placeholders and variables break when the model translates them, reorders them, or changes their spacing. The line still reads fine in a spreadsheet, and then displays a literal {playerName} to every player who reaches it, or crashes a string-formatting call at runtime.

Proper nouns break when the model translates a name it did not recognize as a name. Your protagonist keeps her name in ninety-five percent of lines and becomes a common noun in the rest, which reads to a player as sloppiness rather than as a bug.

Length breaks quietly. Translations into German or Russian commonly run longer than English, and a label that fit in your layout now overflows, truncates, or pushes a button off screen. Nothing in the text file indicates a problem.

Register breaks in languages that encode social relationships grammatically. In Japanese or Korean, the model has to choose a politeness level for every line, and with no context it defaults to something neutral — which turns a menacing villain into a customer-service representative, uniformly, across the whole script.

Check every line, then spend review where it counts

One property of AI output makes the traditional approach fail: it is not uniform. A human translator who is good is consistently good, so reading a sample tells you something about the rest. A model can produce two hundred excellent lines and one that dropped a variable, with no signal distinguishing them. A clean sample no longer certifies the file.

Fortunately, most of the mechanical failures above are checkable by machine on every line, and a script you can write in an afternoon covers a surprising amount of it. Compare the set of placeholders in source and target for each row. Check that tags open and close in matching pairs. Flag rows where the target is byte-identical to the source, which usually means untranslated passthrough. Flag rows longer than the max_chars you recorded. Confirm every key in the source file exists in the translated file, and that no extra keys appeared.

That leaves the judgment calls, which is exactly where you should spend whatever money or favors you have. Prioritize in this order: the store page, because it is short and it is the only text most people will ever read; the first thirty minutes of play, because that is where reviews are formed; anything involving your characters' voices; and error, purchase, or save-data messages, where a misunderstanding costs the player something real.

When you do get a native speaker involved, have them play the game rather than read a spreadsheet. Half of the mistakes in this list are invisible in a cell and obvious on screen. And once you ship, give players a clear, low-friction way to report a bad line — a channel, a form, a pinned post. A game that fixes reported lines in the next patch is treated very differently from one that leaves them there.