Track a resource pair, not just two URLs
Assign the shared resource a stable identifier and record both published addresses, their editorial revision identifiers and the responsible language reviewers. The identifiers are internal records, not a requirement to display a version number to readers. Keep enough information to determine which source revision each translation reflects.
When one edition changes, open a paired-review item containing the changed passages and their purpose. Do not assume that updating the English page means the Arabic page must be copied word for word. The task is to preserve accurate, equivalent guidance while allowing each language to use natural explanations and relevant examples.
Classify the effect before commissioning a translation
Separate spelling corrections and local wording from changes to facts, prerequisites, links or instructions. A repaired Arabic typo may need no English edit. A removed product feature or a changed setup requirement can make the counterpart misleading even if its sentences remain grammatical. Record a no-change decision with a reason instead of silently closing the review.
For material changes, identify dependent headings, examples, screenshots and downloadable files. Specify the evidence the reviewer must consult and the affected language editions. Avoid assigning the whole article for translation when only one verified procedure changed, but do not restrict the review to that paragraph if its assumptions appear elsewhere.
Define how the publication gap is handled
Choose a release treatment based on the consequence of stale guidance. A minor clarification may allow the counterpart to remain live during review. If an outdated instruction would cause a reader to take the wrong action, correct or qualify the affected passage promptly, or hold the coordinated release where appropriate. Record the decision and owner.
Do not update the counterpart’s visible modification date merely because another language changed. Google’s people-first guidance cautions against changing dates to make unchanged content appear fresh. Keep internal check dates separate from actual content updates and describe a translation as reviewed only after the relevant checks occurred.
Illustrative example: a changed export instruction
Imagine a fictional guide says that every report can be exported from its overview screen. A verified product change moves one export option into a report-specific menu. The English editor changes the procedure and records the affected instruction, screenshot and example. The Arabic reviewer checks those same dependencies against the actual interface.
The Arabic edition may explain the menu label differently, but it must preserve which report supports the option and where to find it. The release record stores each edition’s revised text and check outcome. No review is marked complete just because a translation file was generated. This scenario illustrates the workflow and does not assert a feature change in a real product.
Close the item with evidence from both editions
Open both published pages after release and compare the specific changed facts, destinations and supporting resources with the accepted revisions. Save the checked addresses and time. Confirm that the pair still addresses the same resource; Google’s language annotations describe alternate versions, not a substitute for editorial equivalence.
Recheck reciprocal language references when addresses or availability change. For wording-only edits, focus verification on the changed content rather than claiming a full technical retest. Close the paired item when each required edition is verified or an explicit exception remains assigned. Your content inventory can hold this evidence alongside audit findings without treating an audit score as proof that the translation is current.