Treat every source revision as a named change to a named document. Record the earlier version, the replacement, the person approving the change and the translated outputs that may be affected. This gives the legal reviewer a way to establish what the translation actually represents.
“Please use the latest file” is difficult to audit when several people are circulating drafts. A practical version system does not need to be elaborate. It needs to distinguish the controlling source from proposed amendments, translation comments and superseded outputs.
Maintain three separate work streams
Keep the approved source, proposed source changes and translation review comments in distinct locations or clearly labelled files. A comment suggesting a different translated term is not the same as a new source clause. A proposed amendment is not automatically part of the approved source.
The contract owner should identify who can authorise a replacement. If several teams comment, agree who will consolidate their instructions. The translator should not have to decide which legal or commercial position takes priority.
Use a revision ledger
Here is an illustrative ledger for an invented agreement:
| Revision | Source status | Change identified | Translation action |
|---|---|---|---|
| R1 | Approved for initial translation | Starting source and schedules recorded | Translate agreed scope |
| R2 proposed | Awaiting owner confirmation | New definition and revised clause 7 | Assess impact; do not treat as approved |
| R2 approved | Replaces R1 on recorded date | Owner confirms controlling text | Update affected passages and references |
| Target R2 review | Under language review | Reviewer queries terminology | Resolve through agreed decision owner |
The ledger records decisions. It does not determine whether a proposed amendment should be accepted.
Compare more than the highlighted sentence
A new definition can affect occurrences throughout the agreement. Renumbering one clause can change references in several schedules. A revised table may alter labels that recur in the main text. Ask for an impact review that considers these connections.
Comparison files are useful, but their output needs interpretation. Formatting changes can create noise, and content in images or embedded objects may need separate attention. Identify which source files and attachments were compared, rather than assuming a redline covers the complete pack.
If no reliable change list exists, ask the provider how it proposes to compare the versions and what additional review is required. Confirm any effect on scope, price or delivery before proceeding.
Give every delivered file a clear status
A filename should help distinguish a draft for review from an approved deliverable. Record its source revision and delivery date in the project index. Avoid leaving several different files named “final” without an accompanying explanation.
Keep superseded files separate from the current set so that they remain available for authorised comparison without being mistaken for the version to use. Agree retention and access arrangements with the relevant parties rather than deleting working evidence impulsively.
Close the revision explicitly
Before release, check that the translated output uses the approved source revision, incorporates resolved terminology decisions and preserves updated cross-references. Open the final PDF and inspect tables, page breaks and annexure labels after export.
Ask the reviewer to identify any outstanding decision instead of treating silence as approval. Record the version delivered and the person responsible for the next review stage. If another amendment arrives later, begin a new ledger entry.
For a translation brief, supply the controlling agreement, its schedules, the available comparison file and the approval workflow. That makes the version question answerable before the team invests time in the wrong draft.
Request a quotation with your document type, language pair and written requirements.