Source Change Detection Keeps Translation Reviews Honest

A translation can be correct and still be out of date.

That happens when an editor changes the source entry after translation begins. The localized draft still reflects the original snapshot, but the review screen may show the latest source. Unless the workflow marks the difference, a reviewer can approve two pieces of content that were never actually compared.

Source change detection keeps that quiet mismatch from reaching a release.

Translation starts from a snapshot

Every translation request has a source boundary: a set of fields, values, and rich-text structures at a particular moment.

That snapshot should be saved with the request. It explains what the model received, what the reviewer is evaluating, and why the target draft says what it says.

Re-fetching the source for display is useful, but it must not replace the historical snapshot. The workflow needs both:

• the source used to generate the draft
• the current source in the CMS

Without the first, the draft has no reliable provenance. Without the second, the team cannot see that the page has moved on.

Not every change invalidates everything

A timestamp alone can tell you that an entry changed, but not whether the translation is stale.

An editor might update an internal note, add an asset to a nonlocalized field, or correct a field that was not included in the request. Those changes should not necessarily block the localized draft.

Compare at the translated field level instead. If the source title changed, mark the title draft as stale. If only the body changed, keep the reviewed title intact and return the body to attention.

Narrow invalidation preserves finished work while making the remaining risk explicit.

Show reviewers the actual difference

"Source changed" is a warning, not a decision.

Reviewers need to see what changed between the original snapshot and the current value. For plain text, a word-level diff may be enough. For rich text, the comparison should also surface structural changes such as a removed link, a new list item, or a different embedded entry.

The useful question is not simply whether the strings differ. It is whether the approved target still represents the current source accurately.

Give the team deliberate choices

When a translated source field changes, the workflow can offer a small set of clear paths:

1. keep the current translation when the change does not affect meaning
2. edit the localized draft manually
3. regenerate only the affected field
4. return the request to translation when the change is broad

The choice and the reviewer should be recorded. A stale warning that can be dismissed without an audit trail is easy to ignore under release pressure.

Recheck before push

A review may begin with matching source content and end after another edit lands.

Run the source comparison again immediately before pushing to the CMS. This last check closes the gap between approval and delivery. It should use the same field-level rules as the review screen and stop only the affected writes.

For automated publishing, the check is even more important. Automation removes a human pause, so the system must be precise about which approved snapshot it is willing to publish.

The takeaway

Translation review is only trustworthy when the source being reviewed is the source that produced the draft.

Store the original snapshot, compare it with current CMS values, identify changes by field, and let reviewers resolve meaningful differences deliberately. Source change detection does not slow localization down. It prevents teams from confidently publishing yesterday's answer to today's content.