A reviewer catches the wrong product term. The vendor corrects it. Two releases later, the same term comes back.
It is tempting to call that a translation failure. But if the correction never reached the glossary, the translation memory or the next assignment, the process has quietly arranged for the mistake to happen again.
Translation skill matters. So do source quality and subject expertise. Yet when the same issues survive several rounds of review, looking only at the translator misses the places where the team loses information.
Follow one issue all the way to release
Consider a fictional software team translating a billing screen. The source says “credit”. In this screen it means an amount applied to an invoice. Elsewhere in the product, the same word refers to a usage allowance.
The translator receives a spreadsheet with no screen reference and chooses the usage term. An automated terminology check flags a mismatch. A reviewer changes the target, but leaves only “wrong terminology” as a comment. The vendor disputes the change because it conflicts with an older glossary. A project manager accepts the reviewer’s edit to meet the deadline.
The screen ships correctly. The underlying problem remains. Nobody has recorded which sense of “credit” applies to which context, or who owns that decision. The next batch starts the argument again.
That single issue passed through four different jobs: detection, review, arbitration and implementation. Each needs a clear output.
Detection should produce a useful question
A flag is a request for investigation. It should identify the source and target span, the rule that fired, and the version of the content being checked. “Terminology issue in file 4” leaves too much reconstruction for the next person.
A better flag says that a particular segment uses a term outside the approved billing glossary, then links to the relevant entry. It still leaves room for the glossary to be wrong or incomplete.
Keep automatic flags separate from confirmed errors. Otherwise a noisy checker can inflate a vendor’s error count before anyone has reviewed the evidence.
Review needs the context that created the text
For a short interface string, the surrounding screen may explain more than a paragraph of instructions. For a support article, the preceding steps may determine whether a warning is accurate.
Give reviewers the source and target together, nearby content, the applicable glossary and style guide, and the intended audience. Preserve the translator’s query and any answer already given. A reviewer should not have to repeat a question that somebody settled yesterday.
The review record should explain the effect of the error. “Uses the allowance term on an invoice adjustment screen” is actionable. “Sounds wrong” is an invitation to another round of email.
Arbitration needs an owner and a reason
Some disagreements are legitimate. Two terms may be acceptable. The source may be ambiguous. The customer may have changed a preference after work began.
Set a route for these cases before the deadline. A language lead can settle language usage; a product owner may need to settle product meaning. Record the decision, the reason and its scope. One decision for a billing screen should not silently become a rule for every occurrence of the word.
Track whether a finding was accepted, rejected or reclassified. A rejected finding should remain visible as history without continuing to count against the vendor.
Close the loop in the working assets
Accepting a correction is not the same as applying it. Link the decision to the updated target, then check that the delivered file contains that revision. If the decision changes a reusable rule, update the glossary, guidance or translation memory through its normal approval process.
Before closing an issue, answer three questions:
- Did the correct revision reach the release?
- Did everyone working on affected content receive the decision?
- Is there an upstream asset or check that should change?
This is also where useful measurement starts. Track time waiting for a decision, issues reopened after closure, and recurrence after an agreed correction. Those measures help distinguish slow review from missing context or an unresolved ownership problem.
Start with the repeated argument
You do not need to replace every localization tool to improve this workflow. Take one issue that has appeared more than once and trace its history. Find the exact handoff where its explanation, owner or correction disappeared.
Then fix that handoff: attach the screen reference, name the decision owner, or make an accepted correction update the delivery task. Better translation can improve a sentence. A complete feedback loop prevents the same sentence from becoming next month’s problem.
