A price list with the wrong numbers
A retail client receives a translated price list in Spanish. Two prices have swapped digits, a percentage has a comma instead of a full stop in the wrong place, and a product code is missing its last character. The translator was careful, the reviewer checked the language, and the PM was busy with four other deadlines. Nobody ran a number check. The client found the errors in their own proofing, and now wants to know what else you might have missed.
Almost every agency has a QA tool. The problem is that running it depends on someone remembering at the most pressured point of the job.
Why QA gets skipped
- QA is a manual step, run by the PM or reviewer, at the end of the job.
- QA reports are long and full of false positives, so people learn to skim them.
- Client-specific settings, such as number formats and forbidden terms, are not saved, so checks are generic.
- There is no record of whether QA was run on a job.
- Nothing stops a file being delivered without QA.
What it costs
Errors that are easy to catch automatically reach clients, and they are the kind of errors clients find most annoying because they look careless. Complaints and rework. Clients who start doing their own checks and question your fees. And in technical, legal or medical work, errors in numbers, units or references can matter far beyond embarrassment.
| Check | What it catches | Set per client |
|---|---|---|
| Numbers and units | Swapped digits, wrong separators, missing units | Number format for the target locale |
| Tags and placeholders | Broken formatting and variables | Tag handling for the file type |
| Terminology | Approved terms not used, forbidden terms used | Client termbase |
| Consistency | Same source translated differently | Scope of the check |
| Length | Text too long for UI or layout | Character limits where known |
How we build automatic QA
- Each client has a QA profile: number and date formats for each target locale, termbase, forbidden terms, length limits and any special rules.
- When a translator or reviewer marks their task complete, QA runs automatically, using your QA tool such as Xbench or Verifika, or the QA checks in your CAT tool, with the client's profile.
- Known false positives, such as product names that should not be translated, are suppressed using a list maintained per client.
- Remaining issues go back to the translator or reviewer to fix or mark as acceptable with a short reason.
- The PM sees a QA status per file: clear, issues resolved, or issues outstanding.
- Delivery is blocked until QA is clear or the PM signs off outstanding items, and the QA record is kept with the job.
- Recurring issues by translator or client are reported, so feedback and profile adjustments can be made.
QA tools catch mechanical errors. They do not judge meaning or style, which remains the reviewer's job.
What changes
Mechanical errors are caught before delivery, every time, without anyone having to remember. QA reports become shorter and more relevant because false positives are filtered. PMs can see at a glance which files are ready. Clients stop finding errors that a check would have caught, and when they ask how you check quality, you have a clear answer and a record for each job.
The per-translator view is useful beyond individual jobs. If one translator's files keep coming back with number format issues for a particular locale, a short word with them fixes it at the source rather than at every delivery.
Could this be happening to you?
- QA is run when someone remembers.
- Clients have found number or tag errors in delivered files.
- QA reports are long and mostly ignored.
- Client-specific settings are not saved.
- You cannot say whether QA was run on a given job.