People searching track changes in CAT tools, translation review track changes, accept reject translation changes, reviewer changes in translation, translation editor change tracking, or how to compare translator and reviewer edits are trying to preserve one thing that ordinary final text hides: the path from one target version to the next.
Current CAT and TMS editors still expose change-tracking workflows because revision is not only about seeing the final answer. Translators, reviewers, project managers, and clients often need to know what changed, who changed it, and whether each change should be accepted or rejected. Modern editors may show tracked edits directly in the target segment, provide previous and next change navigation, let reviewers accept or reject individual changes, and export workflow comparisons showing the translator, reviewer, and final versions side by side.
This article has one dominant reader job: use tracked changes to review target-language edits quickly without rereading every unchanged word or destroying the audit trail. It is not a general guide to segment revision history, bilingual review packages, version diffing, or source-document tracked changes. The focus is target-side review: one translator produces a target, another person edits it, and the workflow needs to preserve the difference clearly enough to decide what to keep.
Quick answer
A fast tracked-changes workflow is:
- start from a clearly defined translator version;
- enable or preserve change tracking before reviewer edits begin;
- let the reviewer change only what needs changing;
- navigate change by change instead of rereading unchanged target text as if it were new;
- classify each change as correction, improvement, preference, terminology change, or accidental regression;
- accept or reject deliberately;
- escalate global changes such as terminology migrations before repeating them everywhere;
- update the style guide, termbase, or TM when a reviewer decision should become reusable policy;
- clear unresolved tracked changes before final release unless the deliverable explicitly requires visible markup;
- run QA on the final accepted target.
The speed principle is:
make the delta visible so human attention follows the delta.
Why final text hides useful evidence
Suppose a translator writes:
The system automatically restores the previous configuration.
The reviewer changes it to:
The system restores the previous configuration automatically.
If you see only the final sentence, you do not know:
- what the translator originally wrote;
- what the reviewer changed;
- whether the change fixed meaning;
- whether it was merely stylistic;
- whether similar sentences need the same adjustment.
Track changes preserves that evidence.
Review has two questions
Every review change asks:
- Is the final wording better or more correct?
- What does this change teach us about the project?
The first question fixes the segment.
The second can improve:
- terminology;
- style guide;
- translator training;
- translation memory;
- source clarification.
A change-tracking workflow supports both.
Step 1: decide which stage owns tracked edits
A project may have:
- translator;
- reviewer 1;
- reviewer 2;
- client reviewer;
- final proofreader.
If everyone edits freely without clear stages, the change history becomes hard to interpret.
Define:
- who is allowed to change target text;
- whose edits should be tracked;
- who can accept or reject;
- when markup is cleared.
This creates a readable revision chain.
Translator version should be stable before review starts
Do not begin formal tracked review while the translator is still making major uncontrolled edits in parallel.
Otherwise:
- reviewer comments become stale;
- change ownership becomes unclear;
- the target changes beneath the reviewer.
Freeze or hand off a defined translator version.
Then review.
Step 2: track the reviewer’s changes, not every keystroke forever
Change tracking is valuable when it reveals meaningful revision.
It becomes noisy if every exploratory edit remains visible.
A reviewer may:
- type;
- delete;
- retype;
- change mind;
- move punctuation.
If the tool records every micro-action, the final change display can become cluttered.
Use the editor’s intended review workflow.
Where possible, track meaningful differences between workflow stages rather than treating the change pane as a raw keystroke recorder.
Step 3: navigate changes instead of scrolling blindly
Modern review editors often allow:
- next change;
- previous change;
- show all changes;
- show final text;
- show my changes.
Use navigation.
The reviewer or approver should not have to manually search for red markup across thousands of segments.
Change navigation turns the project into a queue of decisions.
Worked example 1: one-word correction
Translator:
The valve may remain open during maintenance.
Reviewer:
The valve must remain open during maintenance.
This is not a style change.
It changes obligation.
Tracked changes makes the modal verb visible immediately.
The approver should not accept this casually.
Ask:
- did source say may or must?
- is reviewer correcting mistranslation?
- did reviewer introduce an error?
Small change.
Large meaning.
Step 4: classify changes
A useful review taxonomy is:
Meaning correction
Translator misunderstood source.
Terminology correction
Target term violates glossary or product usage.
Grammar correction
Target-language grammar or agreement was wrong.
Style improvement
Meaning is correct; phrasing improves readability or house style.
Preference change
Both forms acceptable; reviewer prefers one.
Factual correction
Number, name, date, code, unit, or reference corrected.
Structural correction
Tag, placeholder, punctuation, or formatting fixed.
Source-driven clarification
Change follows new source information or client answer.
Regression
Reviewer introduced a new error.
This classification helps decide what should feed back into project resources.
Why classification matters
If ten review changes are all terminology corrections, the problem may not be the translator.
Maybe the termbase was missing or stale.
If most changes are personal stylistic preferences, the review process may be over-editing.
If many changes are meaning corrections in one technical section, subject knowledge may be weak.
Tracked changes becomes diagnostic data.
Step 5: accept or reject based on evidence, not reviewer hierarchy
A reviewer is not automatically right.
A translator is not automatically right.
The source and project rules decide.
When evaluating a change, check:
- source meaning;
- current terminology;
- style guide;
- reference material;
- locale;
- context.
A strong workflow allows reviewer changes to be challenged.
That is quality control.
Worked example 2: reviewer introduces obsolete term
Translator uses current approved product term A.
Reviewer is familiar with previous release and changes it to old term B.
Termbase says A is current.
Reject the reviewer’s change.
Then tell the reviewer why.
The tracked history makes the conflict explicit.
Step 6: do not accept all changes before sampling
Some editors offer:
- Accept all changes;
- Reject all changes.
These commands are useful only when the change set is already trusted.
Do not use Accept All merely to clear visual clutter.
Before accepting all, sample:
- terminology changes;
- numbers;
- modal verbs;
- deletions;
- additions;
- high-risk sections.
Bulk actions are leverage.
Leverage magnifies mistakes.
When Accept All is reasonable
Examples:
- reviewer is authoritative and changes were already approved externally;
- automated formatting cleanup was validated;
- final legal review returned approved markup;
- change set is small and fully sampled.
Even then, run final QA.
Step 7: distinguish source tracked changes from target tracked changes
This is important.
A DOCX source can contain Word tracked changes.
A CAT editor can also track changes made to the target translation.
These are different layers.
Source tracked changes
Tell you how the source author changed the source document.
Target tracked changes
Tell you how the translation was edited during review.
Do not confuse them.
A project may have both.
Source-tracked-change import policy
Before importing a Word document with tracked changes, the project may need to choose:
- accept source changes before translation;
- reject source changes before translation;
- import source markup visibly.
That choice defines what source content exists in the translation project.
Target review tracking happens later.
Step 8: use the final-view mode when reading for flow
Tracked markup can make the target hard to read.
A sentence full of insertions and deletions is cognitively noisy.
Switch between:
Markup view
Use when deciding individual edits.
Final view
Use when reading fluency and coherence.
Both are necessary.
A change can be locally sensible but make the final paragraph awkward.
The review rhythm
A practical pattern:
- inspect tracked change;
- decide accept/reject;
- read final sentence;
- move to next change;
- after a section, read final paragraph or page.
This keeps local and global quality connected.
Step 9: group repeated reviewer changes
If the reviewer makes the same correction repeatedly, stop approving it one by one without asking why.
Example:
- “login” changed to “sign-in” in 40 places.
Ask:
- Is this now a global terminology decision?
- Should termbase change?
- Should old TM entries be updated?
- Should remaining occurrences be searched?
Turn repeated review into policy.
Reviewer change batching
Once a repeated decision is validated:
- accept representative change;
- search all occurrences;
- update governing terminology/style;
- apply safely;
- run QA.
This is faster than treating forty identical decisions as independent.
Step 10: preserve authorship of changes where useful
Some review tools record:
- user;
- role;
- timestamp.
This can answer:
- who introduced this change?
- at which stage?
- was it translator or reviewer?
- did final reviewer overwrite it later?
This is useful for:
- dispute resolution;
- training;
- audit;
- quality analysis.
Do not erase authorship too early in high-control projects.
Change ownership is not blame
The purpose is traceability.
A reviewer may make a wrong change.
A translator may make a strong correction during review.
Knowing who did what helps the team understand the process.
It should not become a scoreboard for stylistic preferences.
Step 11: export workflow changes when stakeholders need a summary
Some systems can export a comparison of:
- source;
- translation stage;
- revision stage;
- final review stage.
This can help:
- client review;
- translator feedback;
- quality meetings;
- audit.
A stage-by-stage table is often easier to discuss than screenshots of change markup.
But comparison exports are reference, not necessarily reimportable
A workflow-change report may be designed for review and analysis.
It may not be the correct file to import back into the CAT project.
Know the file’s purpose.
Do not confuse:
- change report;
- bilingual review file;
- return package;
- native target.
Different outputs serve different jobs.
Worked example 3: terminology migration discovered during review
Translator used old term because TM suggested it.
Reviewer changes twelve occurrences to new term.
Instead of accepting twelve and moving on:
- confirm new term is authoritative;
- update termbase;
- search remaining target;
- inspect locked or exact-match segments;
- correct working TM if allowed;
- rerun terminology QA.
Tracked changes exposed a system problem.
The team fixes the system.
Step 12: update translation memory carefully
A reviewed final target may deserve stronger reuse status than the translator’s draft.
Depending on the CAT workflow, confirmed reviewer segments may update:
- working TM;
- master TM;
- review TM.
Know which resource receives the final accepted target.
Otherwise the old draft may keep resurfacing next project.
Review should improve future leverage
Ideal loop:
translator draft → reviewer correction → accept → authoritative TM/termbase updated → next project retrieves corrected form.
Weak loop:
translator draft → reviewer correction → final file delivered → old TM remains → same error returns.
Track changes only creates value if the learning propagates.
Step 13: distinguish correction from preference
This is one of the most important review skills.
Translator:
The application closes automatically.
Reviewer:
The app automatically closes.
Both may be correct.
If house style allows both, the reviewer’s change may be preference.
Why care?
Because preference-heavy review can:
- waste time;
- create inconsistency;
- demoralize translators;
- inflate edit metrics.
Use style rules to turn recurring preference into explicit policy or stop changing it.
A preference test
Ask:
If the translator had written the reviewer version first, would the current version have been corrected back?
If yes, there is probably a rule.
If no, the difference may be preference.
This test is not perfect, but it is useful.
Step 14: measure review change rate carefully
Some workflows measure:
- edit distance;
- change percentage;
- post-editing distance;
- reviewer intervention.
These metrics can be useful.
But they do not automatically equal quality.
A high edit rate may mean:
- weak translator;
- overactive reviewer;
- major source ambiguity;
- new terminology;
- client preference.
A low edit rate may mean:
- excellent translation;
- superficial review.
Interpret changes in context.
Change quantity versus change importance
One corrected negation may matter more than fifty punctuation edits.
Do not reduce review quality to number of changes.
Severity matters.
Step 15: use tracked changes for translator feedback
A translator can learn from visible diffs faster than from a vague comment such as:
Please improve style.
Good feedback:
- shows original;
- shows revised;
- explains rule when necessary.
Tracked changes provides the comparison.
Reviewer note provides the reason.
Together they create learning.
Do not explain every obvious typo
Feedback should be proportional.
A misspelled word may not need an essay.
A repeated conceptual error may.
Use reviewer explanation where it changes future performance.
Step 16: use comments for unresolved changes
If a reviewer is uncertain, do not force a silent edit.
Leave:
- comment;
- query;
- proposed change.
Example:
Source says “service period” but product documentation says “maintenance interval.” Please confirm intended concept.
Tracked change can show proposal.
Comment explains uncertainty.
Track changes and comments work together
Tracked change answers:
What wording changed?
Comment answers:
Why?
The combination is especially useful for:
- legal;
- technical;
- regulated;
- disputed terminology.
Step 17: protect approved sections
If some segments are already legally or client approved, reviewers may not be allowed to rewrite them.
Use:
- locking;
- workflow permissions;
- explicit instruction.
Tracked changes is not a substitute for access control.
It records edits.
It does not necessarily prevent unauthorized edits.
Step 18: clear markup deliberately before release
Final published output usually should not contain unresolved review markup unless the deliverable requires it.
Before export, check:
- all intended changes accepted or rejected;
- comments resolved or intentionally retained;
- target displays final text;
- source markup handled according to policy.
Do not assume “looks final” means markup state is clean.
Export settings matter
Some CAT tools can export:
- final target with changes accepted;
- pre-change version;
- visible tracked markup.
Choose deliberately.
A client may want a clean final file.
Legal review may want markup.
The export mode is part of the deliverable.
Failure mode 1: reviewer edits with tracking off
Final text changes but audit trail disappears.
Prevention:
- enable project review settings before review.
Failure mode 2: accept all without inspection
Reviewer introduced a meaning error.
Prevention:
- sample and risk-check before bulk acceptance.
Failure mode 3: preference changes treated as corrections
Translator gets inconsistent feedback.
Prevention:
- classify changes;
- strengthen style guide.
Failure mode 4: source markup confused with target review markup
Wrong version translated or exported.
Prevention:
- define source import policy;
- distinguish target review layer.
Failure mode 5: tracked changes never cleared
Final DOCX contains visible deletions and insertions.
Prevention:
- explicit final-state check.
Failure mode 6: reviewer correction does not update resources
Same error returns next project.
Prevention:
- feedback loop to TM/termbase/style.
Failure mode 7: authorship lost too early
Team cannot identify which workflow stage introduced an issue.
Prevention:
- preserve change metadata until acceptance.
Failure mode 8: reviewer rewrites too broadly
Review becomes retranslation.
Prevention:
- role definition;
- change classification;
- sampling.
Failure mode 9: markup view becomes unreadable
Reviewer misses flow.
Prevention:
- alternate markup and final views.
Failure mode 10: comments and changes contradict
Comment asks question while change is already accepted as final.
Prevention:
- resolve comment before accepting global decision.
A risk-based review order
Start with tracked changes involving:
- numbers;
- negation;
- obligation;
- safety;
- legal terms;
- product names;
- technical terminology;
- placeholders;
- ordinary style.
This is not because style does not matter.
It is because high-consequence changes deserve first attention.
A change triage table
| Change | Risk | Likely action |
|---|---|---|
| comma moved | low | style check |
| term replaced | medium/high | check termbase |
| 30 → 60 | high | verify source |
| may → must | very high | verify meaning |
| sentence rewritten | medium | compare source |
| tag moved | technical | validate structure |
This gives reviewers a mental priority system.
Change clusters reveal project problems
If tracked changes cluster around:
- one term;
- one file;
- one translator;
- one source pattern;
- one product area;
investigate the root cause.
A cluster is data.
It may reveal:
- missing context;
- bad TM;
- unclear source;
- training gap.
Tracked changes and machine translation post-editing
Some systems can compare initial MT output with the final post-edited target.
This is related but not identical to human review tracking.
It can reveal:
- how much MT changed;
- recurring MT errors;
- terminology weaknesses.
Use such comparisons to improve MT strategy, not to judge every edit as waste.
A low edit rate is not always a goal
If MT output is wrong, editing it heavily is correct.
If reviewer fixes serious errors, a high change rate is good.
Metrics should serve quality.
Tracked changes and bilingual review packages
A bilingual review package can move review into Word or another external format.
Track changes inside the CAT editor keeps review inside the translation workflow.
Choose based on reviewer capability.
External client who has no CAT access:
- bilingual review package may be better.
Professional reviewer inside TMS:
- in-editor tracked changes may be better.
Tracked changes and segment revision history
Revision history stores earlier versions over time.
Tracked changes visually marks differences in an active review.
Revision history answers:
What versions existed?
Tracked changes answers:
What exactly changed between these versions?
They complement each other.
Tracked changes and version diffing
Version diffing compares old and new source versions to identify source changes.
Tracked changes compares target edits through review.
One manages source evolution.
One manages target revision.
Do not merge the jobs conceptually.
A reviewer operating routine
For each change:
- inspect source;
- inspect translator target;
- inspect proposed reviewer change;
- classify;
- accept/reject;
- note global implication;
- move next.
At section end:
- read final target continuously;
- run relevant QA.
This keeps review fast and evidence-based.
An approver operating routine
When approving reviewer work:
- filter or navigate tracked changes;
- sample low-risk changes;
- inspect every high-risk change;
- check terminology migrations globally;
- review unresolved comments;
- accept final set;
- update project resources;
- export clean final.
A translator feedback routine
After review:
- view rejected or changed segments;
- group by error class;
- identify repeat pattern;
- update personal checklist;
- ask questions on unclear corrections.
Do not reread every corrected segment equally.
Learn from patterns.
A review-change log for high-risk projects
For regulated work, create a compact log:
| Segment | Change | Reason | Approver |
|---|---|---|---|
| 182 | may → must | source obligation | Legal |
| 244 | term A → B | current glossary | Language lead |
| 390 | 5 mg → 0.5 mg | source correction | Medical reviewer |
Not every project needs this.
High-consequence projects benefit from explicit traceability.
When to reject a reviewer change
Reject when:
- it changes source meaning incorrectly;
- it violates current terminology;
- it uses wrong locale;
- it introduces grammar error;
- it breaks tag or placeholder;
- it contradicts approved style;
- it reintroduces obsolete product language.
Review is collaborative, not hierarchical truth.
When to accept a stylistic improvement
Accept when:
- it improves readability;
- remains faithful;
- fits style guide;
- does not create inconsistency;
- represents a useful project-wide pattern.
Then consider whether the style guide should capture it.
Reviewer calibration
Before a large project, have reviewers jointly evaluate a small sample.
Discuss:
- what deserves correction;
- what is preference;
- terminology authority;
- style boundaries;
- severity.
This can dramatically reduce reviewer divergence.
Why change tracking improves speed even when final review still reads everything
A reviewer may still need full reading.
Tracked changes accelerates the decision about:
- where prior reviewer edits occurred;
- what changed between stages;
- what needs approval.
It also prevents repeated re-review of unchanged wording during arbitration.
Change tracking as organizational memory
A stable record of translator → reviewer changes teaches the organization: