Keeping English and Arabic Pages in Sync
Treat each language version as one page with two faces. Pair them, lock shared terms, and run a short pre-publish check so an update in English does not leave the Arabic page stale.
Pair every page from the start
Give each page a stable identifier that both language versions share. A service page about maintenance might be page id service-maintenance, with English at /en/services/maintenance and Arabic at /ar/services/maintenance. The identifier lives in your content system, not in the URL, so you can rename a slug without breaking the pair.
When someone edits the English page, the Arabic page should appear in the same editing view or at least in the same task. If your CMS cannot show both, keep a simple pairing table in your project tracker: page id, English URL, Arabic URL, owner, last review date. That table is the backbone of the whole process.
Lock terminology before translating
Build a short glossary of terms that must not drift: product names, service names, legal phrases, and words your audience searches for. Decide whether a term stays in English inside Arabic text, gets transliterated, or gets a full Arabic equivalent. Write the decision down with one example sentence for each term.
The glossary is not a dictionary. It is a list of choices your team has already made. When a new term appears, add it once and reuse it. This prevents the same English word from becoming three different Arabic words across three pages.
Run a pre-publish check on both pages
Before any update goes live, open both language versions side by side. Confirm that headings, calls to action, prices or dates, and contact details match. Check that images with embedded text have a language-appropriate version or a caption. Check that internal links point to the correct language page, not to the other language by accident.
A practical acceptance test: pick three sentences from the English page, find their Arabic counterparts, and read them aloud. If a sentence is missing, or if the Arabic version still describes an old offer, the update fails and goes back to the editor. This test takes a few minutes and catches the most common drift.
Set stale translation alerts
A translation becomes stale when the source page changes after the translation was made. Your system should flag that. If it cannot, use a shared spreadsheet with a last-modified column for each language. When the English date is newer than the Arabic date, the Arabic page is marked for review.
Not every change needs a full retranslation. A typo fix in English may need nothing in Arabic. A changed service description needs a full update. Agree on two or three categories, such as minor, content, and legal, and assign a review window to each. The goal is to make the decision visible, not to translate everything twice.
Give Arabic its own review step
Arabic review is not proofreading for grammar alone. A reviewer should check that the page reads naturally for a native speaker, that right-to-left layout does not break lists or numbers, and that the tone matches the English page without sounding like a literal translation. If your team does not have an Arabic reviewer, assign one person who owns that step and give them time to do it.
Suppose a company updates its English homepage to announce a new consultation offer. The Arabic page still shows the old offer. A visitor arriving from an Arabic search result sees outdated information. The fix is not a new tool. It is a paired update task that includes the Arabic reviewer before the change goes live.
Keep the process small enough to survive
A workflow that requires five approvals will be abandoned. Keep the minimum: one owner per page pair, one glossary, one pre-publish check, one stale alert. Review the process every few months and remove steps that no one uses.
If your site is built with proper language annotations and separate URLs for each language, the editorial workflow above is what keeps those pages useful over time. The technical setup makes both versions findable. The editorial process keeps them true.
Continue reading
A practical next step
Explore the related Devign work, then discuss your requirements before committing to a project scope.