Short answer: record which source text produced each translation, compare it with the current saved source, and turn meaningful differences into a review queue. Prioritise high-traffic and high-risk pages, preserve intentional target-language edits, and publish updates through the normal editorial workflow.
Why do translations become stale?
Launching a language is the beginning of its maintenance cycle. Source editors continue to change product claims, links, prices, compliance wording and calls to action. Without change tracking, translated variants can remain fluent but factually out of date.
A page-level “translated” flag is not enough. One nested block may have changed while the rest of the target variant remains valid.
What should translation change tracking record?
- the source culture and target culture;
- the content and property involved;
- a stable identity for each nested text unit;
- the saved source text used for the last translation;
- the translated target text produced or accepted;
- the time and job responsible; and
- whether the target was later changed independently by an editor.
Distinguish the changes that matter
| Change | Likely action |
|---|---|
| Source wording changed | Review the difference and retranslate the affected unit |
| New source text added | Create a new target value |
| Source text removed | Confirm whether the corresponding target content should be removed |
| Target edited independently | Protect the editorial change and ask before replacing it |
| Structure changed but text did not | Validate the editor structure; do not spend tokens unnecessarily |
Prioritise the review queue
Not every difference has equal urgency. Start with:
- legal, safety, pricing and product-availability changes;
- high-traffic landing pages and conversion journeys;
- navigation, forms and Dictionary interface strings;
- campaign content with a fixed launch date; and
- lower-traffic editorial material.
Use content ownership and scheduled review dates alongside automated detection. A dashboard can identify differences, but only the organisation can decide their business importance.
Retranslate only what changed
Sending a complete page through AI again costs more and risks replacing good human edits. A selective preview should preselect the affected properties while allowing the editor to include or exclude related context. Save the result as a draft and compare it with both the latest source and current target.
Monitor coverage as the site grows
New pages and properties can create gaps even when no existing translation changed. Periodically scan important branches for missing variants, empty values, review states and unsupported-only content.
Keep an audit trail
Job history should record who requested a translation, which cultures and properties were included, when it ran, and any skipped or failed results. This helps editors investigate a surprising value and gives support teams the context needed to reproduce a failure.
Because only changed text is reprocessed, ongoing maintenance costs a fraction of the initial translation run — see estimating AI translation costs. Remember that translated titles and descriptions drift too; multilingual SEO covers what else needs reviewing.
Common questions
How often should translations be reviewed?
Review critical content whenever its source changes and schedule periodic checks for the rest. The appropriate interval depends on publishing frequency, traffic and risk.
Should a tiny source edit trigger complete retranslation?
No. Detect and select the affected text unit where possible, then let an editor decide whether related wording also needs context-sensitive revision.
Can translation coverage prove that a page is correct?
No. Coverage can show presence and workflow state; it cannot certify linguistic accuracy. Fluent review remains a separate responsibility.
Use Omni's maintenance tools
Explore Translation Coverage, Source Changes and job history, then follow the detailed translation management guide.