Forty thousand words by Monday
A client needs a tender document translated into French by Monday. One translator cannot do it in time, so your PM splits it across four. Each gets a chunk, a copy of the TM and the client's glossary. On Monday morning the chunks come back. The same technical phrase has been translated three different ways. One translator used formal address, another did not. A defined term in chapter one is translated differently in chapter six. The reviser spends the whole morning harmonising instead of revising.
The deadline is met, just. The client's reviewer still spots the inconsistencies.
Why split jobs come back uneven
- Translators work on separate copies of the TM, so they cannot see each other's choices.
- Decisions made mid-job, such as how to render a new term, stay with the translator who made them.
- Queries about the source are sent separately by each translator, and answered separately.
- Style decisions, such as formal or informal address, are not agreed at the start.
- The first time anyone sees the whole document is at revision, when it is too late to fix cheaply.
What it costs
Revisers spend their time harmonising rather than checking accuracy, which is not what they are for. Deadlines are put at risk by a harmonisation pass nobody planned. Client reviewers find inconsistencies, and a tender or legal document with inconsistent defined terms is a real problem, not a cosmetic one. Translators get blamed for choices that were reasonable in isolation.
| Split-job problem | Usual cause | What the build does |
|---|---|---|
| Same phrase, different translations | Separate TMs | Shared live TM for all translators |
| New terms rendered differently | No way to share decisions | Term decisions circulated as made |
| Duplicate queries | Asked separately | One query log for the job |
| Style clashes | Not agreed up front | Short style sheet issued with the job |
| Found at revision | Nobody sees the whole | Consistency check before revision |
How we build split-job handling
- The PM chooses how to split the job, by file, chapter or balanced word count, and the system keeps related sections, such as definitions and the chapters that use them, together where possible.
- All translators work against a shared live TM and termbase on your CAT server or cloud tool, such as Phrase, memoQ server, XTM or Trados GroupShare, so each confirmed segment is visible to the others straight away.
- A short style sheet goes out with the job: address form, number formats, how to handle defined terms, and any client preferences.
- When a translator settles a new term, they add it through a quick form. It goes into the job termbase and all translators are notified.
- Source queries go to one shared log. Once the PM or client answers, the answer is visible to everyone, which avoids the same question being asked four times.
- Before revision, a consistency check runs across the whole document: the same source translated differently, terms used inconsistently, number formats and address forms. The reviser starts with that list.
Desktop-only CAT setups make a shared live TM harder. Where that is your situation, we look at moving split jobs to a shared server or cloud project rather than forcing a workaround.
What changes
Split jobs come back reading more like one document. Revisers start with a list of inconsistencies to resolve rather than discovering them line by line, and can spend their time on accuracy. Queries are answered once. Your agency can take on large urgent jobs with more confidence, which is often where the best margins and the most grateful clients are.
It also helps the translators. Seeing colleagues' decisions as they are made is reassuring on a tight deadline, and it means nobody is later told they did it 'wrong' when they simply did it differently.
Is this how split jobs go?
- Split jobs come back with inconsistent terminology and style.
- Revisers spend their time harmonising.
- Translators ask the same query separately.
- Translators on the same job work from separate TM copies.
- You avoid large urgent jobs because of the consistency risk.