Decide what is translated and what is shared
List every field of every content type and give each one a treatment. That list, not the tool, is your multilingual content model. It also shows why localization is wider than translation: some values change by market, not by language.
| Treatment | Fields it fits | Why |
|---|---|---|
| Translated | Titles, body text, button labels, alt text, search titles | Each language needs its own value |
| Shared | Dates, product codes, measurements, references to other entries | Stored once, so languages cannot drift apart |
| Per market | Legal text, contact details, availability, currency display | Changes by country, not only by language |
The list then points to the unit of translation. We compare field-level and document-level translation in a separate article. Mixed models are normal: field-level for structured records such as products, document-level for editorial pages that the Arabic writer may restructure.
Two more rules. Make references point to the entry itself, not to one language's version, so links follow the reader's language. And treat languages as data, with standard codes such as ar and en, and decide early whether you need regional variants.
Write the fallback rule once and keep it visible
The article above gives the rule for each content type. These points cover where the rule lives and how it behaves.
- One place. Implement it in the layer that fetches content, so every page behaves alike.
- A chain, not one default. A regional variant falls back to its main language, and that to the source language only where acceptable.
- Marked fallback. Flag fallback content so the front end can label it and the editor can see it. Silent mixing breaks direction and trust.
- A search rule. An Arabic address that shows English text is a near-copy of the English page. Do not publish it until it is translated, or send the reader to the English page, and keep it out of the hreflang set below.
Right-to-left editing and preview
Editor support for right-to-left is separate from site support, and the same article lists the basic checks. These decisions go further.
- Direction follows the language, not the user. An Arabic field is right-to-left whoever is logged in.
- Source beside translation. Translators work better with the original visible, read-only, next to the field they fill.
- Mixed runs. Latin names, product codes and numbers inside Arabic text need directional handling that an editor can fix without code.
- A preview per language that opens your real front end at the Arabic address with draft content, at phone and desktop widths.
- The editor's own interface. Whether menus can be shown in Arabic is a separate question from content fields.
Front-end rules are in our guide to bilingual Arabic and English products and our page on Arabic and RTL design.
Translation workflow and review roles
A workflow answers four questions: who writes the source, who translates, who checks and who publishes. Write them as roles, then check that the CMS can enforce them.
- Source author: owns the original. Editing it after translation starts has consequences, covered below.
- Translator: in-house, at an agency or freelance. Machine translation can draft, but someone who reads the language must review it. Legal or safety text needs a qualified writer.
- Reviewer: a native reader who knows the subject, checking meaning, tone, terms and how the page looks right-to-left.
- Publisher: releases a language, and ideally does not approve their own edits.
Give each language its own status: not started, in translation, in review, approved, published, out of date. Arabic can then go live when it is ready.
Keep a shared glossary and style note: preferred product terms, names that stay in Latin letters, date and number formats, tone. If an agency translates, check that the CMS can export and import a standard exchange format such as XLIFF.
Slugs and URLs for each language
Pick the structure first. A language prefix such as /ar/ keeps everything on one domain and is simplest to run. A subdomain or domain per language gives more separation, at the price of more to host, secure and measure.
- Shared Latin slug or translated slug? Arabic slugs read naturally but can appear encoded when copied into some apps. Test the links you share most, then apply one rule to all content.
- Unique within a language, not across all of them.
- Editable, with a redirect required whenever a published slug changes, and a history of old slugs.
What the CMS must output for hreflang
The hreflang annotation tells search engines that one page is the version of another in a different language. The CMS rarely writes the tags itself, but it must hold the data, and your templates must output them.
- A counterpart relation. Every page knows its other-language versions, stored as links between entries, not guessed from addresses.
- Each version lists all versions, itself included, and the links are reciprocal, because search engines may ignore a one-way annotation.
- Absolute URLs and valid codes, such as ar and en, with a region like ar-AE only if you really target one.
- Published pages only. A draft, untranslated or redirected version stays out of the set.
- A self-referencing canonical, so each language version names itself, not the English page.
- An optional x-default for the page shown when no language matches, such as a language chooser.
Output the tags in one place only: the page head, the HTTP headers or the XML sitemap. Then they cannot disagree. Also set lang and dir on the html element for each language. The same counterpart relation drives the language switcher, which should land on the matching page, not the home page.
Media that contains language
Text inside an image does not translate with the page.
- Images with text (banners, diagrams, screenshots, share images): store one version per language, linked as a set, so the Arabic page picks up the Arabic image. Better, keep the text out of the image and draw it as live text.
- Alt text and captions are translated fields.
- Video and audio: captions and a transcript per language, and a separate audio track if dubbed.
- Downloads such as PDFs: one file per language, linked from its own page.
- Directional graphics: arrows, progress bars and icons that imply direction may need a mirrored version on right-to-left pages. Logos are not mirrored.
The media library should show which assets lack an Arabic version, so a reviewer finds the gap, not a reader.
Keeping the languages in step
Launch is the easy part. Over time the source changes and translations age.
- Record what each translation was based on. When the source changes after approval, mark the translation out of date and show what changed.
- Separate small fixes from changes of meaning. A typo fix should not send many pages back to translation. The editor decides, and it is recorded.
- Release by rule. Time-sensitive and legal changes go out in both languages together. Routine posts need not wait.
- Report on gaps. A weekly list of missing and out-of-date entries per language, each with an owner.
How to test a multilingual setup
Test in staging with real Arabic content. If you are still choosing a tool, our comparison of Strapi, Sanity and Contentful shows how each handles languages.
- Publish a page in English only. Does the Arabic address follow your fallback rule, with no hreflang pointing to it?
- Publish the Arabic version. Does each page's source list both versions with absolute addresses and name itself as canonical?
- Change the English text after the Arabic is approved. Does the Arabic entry become out of date?
- Change a published slug. Does the old address redirect, and do the hreflang tags update?
- Preview an Arabic draft at phone width with a long title, a number and a Latin product name.
- Use the language switcher on a deep page. Does it land on the counterpart?
- Log in as the Arabic reviewer. Can they approve Arabic content and nothing else?
A rule of thumb for done: an editor can see at a glance which languages of a page are live, missing or out of date. These decisions apply to any headless CMS, and our CMS service covers the build.