'Small updates, can you just use this one instead?'
A client sends a 20,000-word annual report for translation into four languages. Halfway through, they send a new version: 'small updates, please use this one instead'. Your PM now has to work out what changed, across a long document, while four translators continue working on the old version. Some of the changes are small. Others are rewritten paragraphs. One section has moved.
The PM tells translators to stop, tries to compare the files, re-creates the project, and asks the client whether they will pay for the extra work. The client says the changes are minor and should be included.
Why changes are hard to handle
- Clients rarely say exactly what changed.
- Comparing documents by eye, or with basic tools, misses moved and reworded content.
- Work already done on the old version has to be carried across manually.
- Translators continue on the old version until someone tells them to stop.
- Without numbers, the conversation about extra charges becomes a disagreement.
What it costs
Wasted translation on content that has since changed. PM time rebuilding projects. Rework and inconsistency when changes are carried across by hand. Deadlines squeezed. And margin lost, because extra work is absorbed rather than charged, since there was no clear way to show the client what it involved.
| Question | Without comparison | With comparison |
|---|---|---|
| What changed? | Ask the client or compare by eye | Changed, added, removed and moved content listed |
| What work carries over? | Copy by hand | Pre-translated from current work |
| What will it cost? | Negotiated on impressions | Change quote from the actual differences |
| What do translators do? | Wait for instructions | Updated tasks showing only changes |
How we build source change handling
- When a client uploads a new version, through the portal or by email to intake, it is recorded as a new version of the same source file.
- The new version is compared with the version in translation at segment level, identifying unchanged, changed, added, removed and moved content.
- Translators working on the job are notified straight away that a new version is coming, so they can pause on sections affected by changes.
- The new version is pre-translated from the translators' current work, including confirmed segments not yet in the master TM, so unchanged content carries across.
- A change quote is produced from the actual differences using your rules, and sent to the client for approval with the comparison attached.
- Once approved, translators' tasks are updated to show only the changed and new content, and deadlines are adjusted if agreed.
Whether and how you charge for changes is your decision and your terms with the client. The build gives you the facts to have that conversation.
What changes
Timing matters as much as the comparison. The sooner translators know a new version exists, the less work goes into content that is about to change, so notification happens when the file arrives, before the PM has finished looking at it. Translators can keep working on sections the comparison shows as unchanged while the change quote is agreed.
Mid-project changes stop being a crisis. PMs can see what changed from a list rather than comparing documents by eye. Translators stop working on content that has changed, and do not redo work that has not. Clients receive a clear, evidence-based change quote, which is much easier to accept than a vague request for more money. And your terms about changes can actually be applied.
Does this happen to you?
- Clients send new source versions mid-project.
- Comparing versions is done by eye.
- Translators continue on old versions until told to stop.
- Carrying work across to the new version is manual.
- Extra work from changes is usually absorbed.