Three weeks waiting for Frankfurt
You deliver a German translation to a client. Their process requires review by someone in their Frankfurt office before publication. The reviewer is a sales manager doing it alongside their real job. Three weeks later the file comes back as a PDF with handwritten notes, many of them changes to wording your translator chose carefully and a few genuine corrections. The client asks you to 'implement the reviewer's changes' and publish by Friday.
Your translator is unhappy about some changes, which introduce inconsistencies with the termbase. The PM has to decide whether to argue or comply, with no time for either.
Why in-country review is difficult
- Reviewers are busy local staff, not linguists, and review in their spare time.
- Review happens in PDFs or Word files, detached from the source.
- Changes mix real errors with preferences, and nobody separates them.
- Reviewer preferences are not captured, so the same changes are made again next time.
- There is no deadline enforced, and no visibility for the client's project owner.
What it costs
Projects held up for weeks, so your agency looks slow even though the delay is on the client side. PM time implementing changes from PDFs by hand. Inconsistency when preferences contradict the termbase. Translators demoralised by being corrected on preference. And the same arguments on the next job because nothing was learned.
| Aspect | PDF review | Review portal |
|---|---|---|
| Context | Translation only | Source and translation side by side |
| Changes | Handwritten or tracked in Word | Made in the portal, per segment |
| Error or preference | Unclear | Categorised by the reviewer |
| Deadline | None visible | Shown, with reminders and escalation |
| Learning | Lost | Accepted preferences go to termbase and TM |
How we build in-country review
- When translation is complete, the client's reviewer receives a link to the review portal, with no software to install.
- Source and translation are shown side by side, segment by segment, with the client's approved terms highlighted.
- Reviewers edit the translation directly and pick a category for each change: error, terminology, preference or style guide. A short comment is optional.
- A review deadline agreed with the client is shown, with reminders to the reviewer and a notice to the client's project owner if it is missed.
- Your linguist sees each change and can accept it or respond, for example pointing out a conflict with the approved termbase. Disagreements go to the client's project owner to decide.
- Accepted changes are written back into the translation in the CAT tool, and accepted preferences are proposed for the termbase and style guide.
- Where your CAT platform includes a reviewer feature, such as Phrase or XTM, we configure that first and add only what is missing.
Final wording decisions belong to the client. The portal makes their review faster, keeps the discussion clear and stops lessons being lost.
What changes
The categories are what make the difference over time. Once a few jobs have been through the portal, you can show the client how many changes were errors and how many were preferences, and agree which preferences should become rules. That conversation is far easier with the record in front of everyone than with a stack of annotated PDFs.
Reviewers work in a clear, simple view, which makes review quicker to do and easier to fit into their week. The client's project owner can see where review has got to. Genuine errors are separated from preferences. Your linguists can respond, so terminology stays consistent. And preferences become part of the termbase, so the next job needs fewer changes and the reviewer feels listened to.
Is in-country review slowing you down?
- Client reviewers take weeks.
- Review comments arrive in PDFs or Word files.
- Preferences and genuine errors are mixed up.
- The same reviewer changes appear on every job.
- Your agency gets blamed for delays caused by client review.