Direct answer: Give every high-stakes fact one owner and one dated source record. When it changes, review the English and Arabic page pair together, have qualified reviewers approve both versions, test the customer action in each language, and publish with a recorded exception if one version must wait. A language switch and correct hreflang cannot repair two pages that make different promises.

Imagine that a service's eligibility rule changes on Monday. The English page is updated, but the Arabic page still invites a customer who no longer qualifies. Both pages may be technically valid and searchable. The failure is editorial ownership.

Keep a source record for facts that can hurt a decision

Start with facts such as price, service area, opening hours, eligibility, refund or cancellation terms, delivery availability, and contact route. For each, keep the approved value, effective date, decision owner, page pairs that use it, and evidence or policy source. The register is a work tool, not a new public page or a second place to invent policy.

One change ticket might read:

Fact: same-day service now closes at 3 p.m. local time. Effective: 12 November. Source owner: operations. Affected pages: English and Arabic service detail, booking confirmation, and help answer. Reviewers: service owner plus Arabic-language reviewer. Release condition: both booking paths show the same cutoff and the booking system rejects later slots.

This example is a proposed workflow, not an ARCHV client result. The final test checks the actual booking behavior as well as the translated sentence; a correct page beside an old calendar rule still misleads buyers.

Use four gates before publishing

  1. Scope the change. Search the paired pages and supporting messages for the old fact. Identify where the visitor will act, not only where they will read. Record if one language has no equivalent page and what the fallback should say.
  2. Approve meaning in each language. A subject owner confirms the business rule; a fluent reviewer confirms that the Arabic and English versions communicate the same decision without forcing identical wording. Keep numbers, dates, units, exclusions, and contact instructions aligned.
  3. Test the buyer path. Open each page, switch language from that page, and follow the CTA. Check the resulting form, booking, or checkout state in both versions. Test mixed-direction details such as phone numbers or product codes when they appear. W3C's bidi guidance explains why Latin strings and numbers inside right-to-left content need deliberate markup and review.
  4. Release and monitor. Publish both approved versions and linked messages together when possible. If one version must be delayed, record the owner, interim wording, date, and a visible route to current information. After release, re-open the pages and confirm the CMS did not restore an older translation.

Google's multilingual-site guidance recommends separate language URLs and accessible links for choosing a language. Its localized-version documentation requires reciprocal page annotations for hreflang to work. Those are discovery and navigation rules. They do not verify that both pages contain the current policy. The ARCHV URL and hreflang guide covers that architecture; this article covers the next year's edits.

Audit the changed fact, not every paragraph at once

For a monthly check, sample recent source-record changes and follow each to all listed language pages and actions. Log correct, stale, missing equivalent, or intentional difference with approval. An intentional difference may be legitimate if markets have different services; the source record should explain it so a future editor does not “fix” the wrong thing. The acceptance question is whether a visitor in either language can make the right decision from the current information.

This release process needs CMS fields, workflow, translation, and QA responsibilities sized to the real site. ARCHV's website scope can be reviewed for bilingual work, while ongoing translation and operations policy require explicit ownership in the proposal. Include one example page pair and one frequently changed fact in a website estimate.