Designing a translation review workflow that actually closes the loop

Most teams have translation review in some form — a second pair of eyes on the text before it ships. Far fewer teams could describe their review process in a sentence: who looks at what, in what order, and what happens once a problem is found. Without that clarity, review tends to either duplicate effort (three people silently checking the same thing) or leave gaps (nobody checking the thing that actually breaks).

A workflow that closes the loop needs four things: a clear split of who reviews what, a decision about context versus spreadsheet review, a place to record decisions so they do not get re-litigated, and a guarantee that an accepted fix lands in the actual file.

Splitting linguistic review from functional and format review

These are different skills and different failure modes, and conflating them wastes the reviewer who can do the rare thing on work anyone could do. Linguistic review — does this read naturally, is the tone right, is this the correct term — needs a native or highly fluent reader of the target language. Functional and format review — does the placeholder survive, does the line fit the UI, does the string appear where it is supposed to appear in the actual screen — needs someone who can run the build, and does not need to read the language at all.

Assigning both to the same person, usually the translator, means format problems get caught late (translators rarely see the in-game rendering) and linguistic problems get caught by whoever happens to glance at the file, which is inconsistent. Splitting them lets format checks run early and often — on every export, even automatically — while linguistic review is scheduled as a distinct pass with a real native reader.

Review in context versus review in a spreadsheet

A spreadsheet or export file review is fast and cheap: a translator or reviewer can go through hundreds of rows in an afternoon, and it is the only practical way to review a large batch. But a string reviewed in isolation, without seeing the screen it appears on, misses a whole category of problem — a formal register on a casual character, a line that reads fine alone but awkward next to the line before it, a translation that is technically correct but does not fit the emotional beat of the scene.

In-context review — playing the build, or at minimum viewing a screenshot or a UI mockup with the real string in place — catches those, but it is slow and only realistic for a sample. The practical pattern is spreadsheet review for volume and consistency, in-context review for new content, cutscenes, and anything flagged as high-visibility, with the two feeding into each other: a line that reads oddly in a spreadsheet is exactly the kind of line worth checking in context.

• New or heavily rewritten dialogue: in-context review before ship
• Bulk UI strings and item/ability names: spreadsheet review for consistency
• Anything the spreadsheet pass flagged as uncertain: escalate to in-context
• Tutorial and first-hour screens: always in-context, regardless of volume

Recording decisions instead of re-arguing them

The same question comes up more than once in any long-running project: should this term be translated or kept in the source language, should this character address the player formally or casually, is this idiom acceptable or does it need to be replaced. If the answer only lives in someone's memory or an old chat message, the next reviewer re-opens the debate from zero, and the answer can quietly drift.

A short, searchable record — a glossary entry, a style-guide note, a comment attached to the string itself — turns a one-time decision into a standing rule. It does not need to be elaborate: a single line naming the term, the chosen translation, and the reasoning is usually enough to stop the same conversation from happening a third time.

# style-guide.md excerpt
term: "Guild"
ja: "ギルド" (kept as loanword, not translated —
      matches genre convention, decided 2026-03)

Closing the loop: from accepted fix to the actual file

A review that ends with an approved comment in a spreadsheet or a ticket marked resolved has not actually fixed anything until that text change lands in the file the build reads from. This sounds obvious, but it is the step that most often breaks: a fix gets agreed in a review tool, someone forgets to apply it to the source file, and the next export silently reintroduces the original problem.

The safest pattern is treating an accepted review comment the same way you would treat an approved change in a pull request — the change to the file and the record of the decision happen in the same action, not as two separate steps that depend on someone remembering the second one. Whatever tool the review happens in, the workflow should make 'approved' and 'applied to the file' effectively the same event, or close enough that a fix cannot silently fall through the gap between them.