Giving translators context: the highest-leverage QA input you control

Most localization quality problems that show up late — a line that reads like it was aimed at the wrong character, a button label that is grammatically a sentence, a warning that sounds calm because nobody knew it was an error message — trace back to the same root cause. The translator never saw what you saw when you wrote the source text. A spreadsheet of strings is not the game; it is the game with everything except the words removed.

Fixing this is not a translation-quality problem you solve by hiring better translators. It is a context problem, and it is the one lever squarely in the hands of whoever prepares the handoff.

What a string table strips away

A row in a spreadsheet or a key in a JSON file carries the text and, if you are lucky, a key name. Everything else about the string's life inside the game is implicit to you and invisible to the translator: who is speaking, in what emotional register, on what screen, next to what other text, with how much room to render, and what any placeholder actually resolves to at runtime.

None of this is optional information — it is information the source-language writer already had, consciously or not, when the line was written. Translation without it is not a shortcut; it is a guess.

What to provide, concretely

The goal is not to document every string exhaustively — that cost rarely pays for itself. The goal is to attach the context that changes the translation, and skip the context that does not.

• Speaker and scene notes — who says this line, to whom, and in what tone (a drill sergeant barking an order translates very differently from the same words said gently)
• Screenshots or short clips showing the string in its actual UI position
• Character or byte limits, stated per string or per UI slot, not left for the translator to discover after localization fails to fit
• What each placeholder expands to and its grammatical role — a player name is not the same problem as a percentage or an item count for languages with number-dependent grammar
• Whether a string is a UI label, a button, or a full sentence — a button reads as an imperative or a noun phrase in most languages, and guessing wrong produces a UI that reads like a command in one language and a description in another

A concrete example

Consider a placeholder-only string like the one below. Out of context it is unsolvable.

"key": "ui.button.craft_item",
"source": "Craft {0}",
"note": "{0} = item display name (noun). This is a button label, not a sentence."

A working Q&A channel beats a perfect handoff

No handoff document anticipates every question, and trying to make one that does usually means it goes unread. What actually prevents rework is a live channel — a shared thread, ticket, or chat — where a translator can ask what a specific placeholder resolves to and get an answer within the working day, not at the next milestone.

Teams that skip this channel do not get fewer questions; they get fewer questions asked and more assumptions made silently. The assumptions surface later, in review, as a pile of strings that all need to be revisited — which is strictly more expensive than answering the question once, up front.

The cost of guessing

When a translator has no context, they still have to produce something — deadlines do not wait for context. What they produce is a plausible guess: grammatically correct, tonally reasonable, and sometimes simply wrong for the scene it ends up in. That guess passes through translation and often through a first review, because a reviewer working from the same spreadsheet has no more context than the translator did.

The error is caught, if it is caught at all, by someone playing the actual build — at which point fixing it means finding the string again, re-translating it, and re-running whatever review step it already passed. Context supplied once at handoff time replaces an unbounded number of these late catches with a translator getting it right the first time.