Players are reporting translation mistakes. Now what?

A player comments that the German in your shop menu is wrong. Another says a line in the tutorial means the opposite of what it should. A review in a language you do not read gets a lot of upvotes, and the machine translation of it says something about the translation being bad.

The first reaction is usually a mix of embarrassment and helplessness, because the problem is real and you cannot see it. You cannot verify the claim, you do not know whether it is one bad line or a symptom of a bad batch, and you have no idea whether the person telling you is right, half right, or just expressing a preference.

That state is fixable, and not by learning the language. What makes translation reports manageable is a receiving process: a place for them to land, a small set of information you always ask for, a way of sorting them, and a record that stops the same error coming back three patches later. This article walks through each of those.

Give reports somewhere to land

Most translation errors are noticed by players who never tell you, because at the moment they notice it there is nowhere obvious to say so. The single highest-yield change you can make is to create a visible, low-effort channel and mention it where players already are: a pinned post, a line in the patch notes, and ideally an entry in the game's own menu.

The channel itself matters less than the friction. A short form is better than an email address, because a form can ask for the things you need; a dedicated chat channel works well if you already run a community server, because reporting there is nearly free for the player and other speakers of the language will often weigh in on whether they agree. What does not work is a general feedback address where translation reports arrive mixed in with crash reports and feature requests, since they need completely different handling.

Separately, set up a habit of reading store reviews by language rather than only in aggregate. Reviews are where translation complaints go when there is no other channel, and a cluster of them in one language is a much stronger signal than any individual message — it usually means the problem is systematic rather than a single unlucky line.

Ask for the three things that make a report usable

Nearly every unusable report is missing the same information. You can prevent that by shaping the form rather than by asking follow-up questions after the fact, which in practice means most reporters never reply a second time.

The three essentials are: where it appears (a screenshot is worth more than any description, because it also captures truncation and layout problems), what it currently says, and what the player expected instead. That third one is the one people skip and the one that turns a complaint into a fix — without it, you know something is wrong but not what right would look like.

Keep the form short enough that a mildly annoyed player will actually finish it. Everything beyond those three fields is optional, and language plus game version are worth including as pre-filled or dropdown fields because typing them is exactly the kind of friction that loses reports.

Translation report form — keep it this short

1. Language you are playing in:            [dropdown]
2. Screenshot of where you saw it:         [upload]
3. What it says now:                       [text]
4. What it should say (or what it means
   in your language right now):            [text]
5. Game version (found in Settings):       [pre-filled]
6. Anything else? (optional)

Triage before you fix anything

Reports that all arrive as 'the translation is wrong' are actually four different problems with four different owners, and mixing them up is how developers end up making a text worse by editing it directly.

• An actual mistranslation — the target text says something the source does not, or misses a meaning that matters. This is the only category where the text itself must change, and it needs a translator, not you.
• A preference or register disagreement — the meaning is right but the reporter would have phrased it differently, or finds it too formal, too casual, or not how a character like that would speak. Sometimes worth acting on, especially when several speakers agree, but a single strong opinion is not evidence.
• An implementation bug wearing translation clothes — a placeholder shown literally, text cut off by a button, the wrong string appearing in the wrong slot, a fallback line in the wrong language, mojibake from an encoding problem. The translation is fine; your build is not. These are yours to fix and are usually the fastest wins.
• A cultural or contextual objection — a term, name, symbol, or joke that reads badly in that region even though it is translated accurately. This needs a conversation with someone from that market rather than a dictionary.

Judging a report in a language you cannot read

The tempting shortcut is to paste the reporter's suggested wording straight into your text file and ship it. Resist that. You are accepting a change to your product from a stranger whose skill you cannot assess, in a channel where nobody else on your side can review it. Most people who do this are trying to help and many of their suggestions are good, but a small number are worse than what you had, and a very small number are deliberately offensive text that will sit in your game for months.

A workable rule is that every reported line gets confirmed by a second, independent speaker before the change ships. If you already work with a translator, batch the reports and send them once a month — this is cheap, because you are asking for a verdict on twenty short lines, not for new translation. If you have no translator, a paid review of a small batch is still one of the least expensive things you can buy in this whole process.

Machine translation is useful here for exactly one job: telling you which bucket a report belongs to. Running the current line and the suggested line through it will usually show you whether you are looking at a real meaning difference or a stylistic quibble, which is enough to prioritise. It is not enough to decide the final wording, because the differences that matter in a good translation are precisely the ones machine translation flattens.

One more signal worth weighting heavily: agreement. When three unconnected players in the same language report the same line, you can treat it as confirmed. When one player reports twenty lines, you may be looking at a genuinely bad translation batch, or at one person with strong opinions, and the way to tell them apart is to have a small sample of that batch reviewed rather than to accept or dismiss the whole list.

Fix it once, and record it so it stays fixed

A translation fix that lives only in the patch that shipped it is a fix waiting to be reverted. It happens the same way every time: the text file gets regenerated from an export, a translator delivers an updated batch from an older base, or someone restores a backup, and the corrected line quietly returns to its previous state. Nobody notices, because nobody is watching that line any more.

The defence is a plain record. One row per fix, with the string key, the language, the old text, the new text, who confirmed it, and the date. It does not need to be a database — a spreadsheet or a text file in the repository is fine, as long as it is the same one every time and it lives with your project rather than in someone's messages.

Two things become possible once that record exists. You can check the fixed lines again after any bulk text update, which catches regressions before players do. And you can feed the recurring cases back into your glossary: if the same term keeps being translated inconsistently, the fix is a glossary entry, not another individual correction. That is the difference between handling reports and reducing them.

fix-log.csv — one row per confirmed fix

key,lang,old,new,reported_by,confirmed_by,date,note
shop.buy_button,de,Kaufen Sie,Kaufen,player#4471,translator,2026-08-18,imperative not polite form
tutorial.step_03,fr,...,...,3 reports,translator,2026-08-18,meaning reversed
item.potion_desc,de,...,...,player#1180,pending,2026-08-18,glossary: potion term

Close the loop with the person who reported it

Reporting a translation error costs a player time and gains them nothing. Whether they ever do it again — and whether anyone else in that language bothers — depends almost entirely on what happens next. Acknowledge the report quickly even if the fix is weeks away, say plainly that you are having it checked, and come back when it ships. A line in the patch notes saying that several German lines were corrected thanks to player reports does more for the health of that language community than the fixes themselves.

Credit is cheap and unusually effective here. A short thanks list in the patch notes or the credits screen turns a one-off reporter into someone who keeps an eye out, and those people become the closest thing a small team has to native-speaking QA.

You will also have to say no sometimes, and it is better to say it than to leave the report open forever. When a suggestion is a preference rather than an error, or when a change is technically impractical right now, say so briefly and honestly: the meaning is correct here, this is a style choice we are keeping, or this text is baked into an image and we will change it in the next art pass. Reporters overwhelmingly accept a clear no. What they do not forgive is silence, because silence reads as the thing they were afraid of — that nobody on your side cares about their language.