What to check when content must live in English and Arabic: translation model, fallbacks, RTL preview, approvals and the API.
For a team that publishes in English and Arabic, choose a CMS that translates at the level your content needs (field or whole document), shows what is missing through clear fallbacks, previews right-to-left inside the editor, fits your roles and approvals, schedules publishing, and serves content through a fast, well-documented API. Then decide between headless and traditional by who owns the site day to day, not by what is fashionable.
Field-level or document-level translation
This is the first decision, because it shapes everything else. In **document-level** translation each language is its own full entry, linked to the others. In **field-level** translation one entry holds every language, and only the fields that need translating have a value per language.
| Approach | Strengths | Watch for |
|---|---|---|
| Document-level | Each language can differ in structure and length, publishes on its own schedule and can have its own reviewer | Shared data such as images, dates and prices is duplicated and can drift apart, and the links between versions must be kept |
| Field-level | Shared fields are stored once, the structure is identical in every language and gaps are easy to see | One language is hard to publish alone, and an Arabic page that needs different sections fights the model |
A rule of thumb: field-level fits structured content that must keep the same shape, such as products, listings, people and settings. Document-level fits editorial content, where the Arabic version is written for Arabic readers and may not follow the English paragraph by paragraph.
Tools differ here. As examples, Contentful localises individual fields, Strapi keeps a separate version of each entry per locale, Sanity lets you model it either way, and WordPress needs a plugin for multilingual content. Check each vendor's current documentation, because these features change. Our page on [Strapi, Sanity and Contentful](/services/cms/strapi-sanity-contentful) goes deeper.
Fallbacks: what happens when a translation is missing
Every bilingual site has gaps, so decide the rule before launch. The options are to show the other language, to hide the item or to show a notice. The right answer depends on the content type.
- **News and blog posts:** hide the item in the language where it does not exist, and tell the editor.
- **Product or service pages:** fall back only if a mixed-language page still makes sense, and mark it clearly.
- **Legal and safety text:** never fall back silently. A missing translation should block publishing.
A silent English fallback inside an Arabic page also breaks reading direction and spacing, so test it. Look for a translation status on every entry in the editor, so editors can see what is missing without opening each page.
Right-to-left preview and editing
Right-to-left support in the editor is separate from right-to-left support on your site. Check that text fields switch direction for Arabic, that mixed text with Latin names, numbers and punctuation behaves, and that lists and quotes in rich text align correctly. Then check the preview: it should render your real front end in Arabic, with the real layout, not a generic mock-up.
Draft preview matters most here, because layout bugs only appear with real Arabic text, which has a different length from the English beside it. For the design side, see our guide to [bilingual Arabic and English products](/guides/bilingual-arabic-english-products).
Roles, approvals and scheduled publishing
A CMS should make editors faster, not create a second job. Map the real workflow first: who writes, who translates, who reviews and who publishes. Then check that the tool can express it.
- Roles per language, so an Arabic reviewer can approve Arabic content without access to the English entry, and the other way round.
- A clear status flow, such as draft, in review, approved and published, with an audit history of who changed what.
- Scheduled publishing in an explicit time zone, with the option to release both languages together or each on its own.
- Rollback to an earlier version, because a wrong publish will happen at some point.
Plan schedules around the working weeks and public holidays of each audience. They differ across the Gulf, the United States and Europe.
A fast, documented delivery API
The delivery API is what your site and apps actually use, so test it as seriously as the editor. Ask whether you can request a locale, apply the fallback rules and fetch related entries in one call, whether results can be filtered and paginated, and whether a publish can trigger a webhook that refreshes the site. Check the quality of the documentation: examples, error messages and generated types if you use TypeScript.
Test with real Arabic content, including long titles and mixed Latin text, and measure response times from the regions where your readers are. Check the rate limits, the caching behaviour and how images are resized.
Headless or traditional: decide by who owns the site day to day
A [headless CMS](/glossary/headless-cms) stores content and serves it through an API, and your developers build the front end. A traditional CMS bundles content storage, templates and the front end together. Neither is better in general. The deciding question is who will own the site on a normal Tuesday.
| Who owns the site day to day | Lean toward |
|---|---|
| A marketing team that edits pages and layouts often, with no developer close by | Traditional, or a headless CMS with strong visual editing |
| Developers own the front end and editors write structured content | Headless |
| Content must feed a website, a mobile app and other channels | Headless |
| A small site with simple needs where a quick start matters most | Traditional |
Know the costs on each side. Headless means someone builds and maintains the front end and the preview, so there are more moving parts. Traditional systems usually need plugins for multilingual work, and updates, patches and plugin reviews become your job or your host's. Our [CMS service](/services/cms) works with Strapi, Sanity, Contentful and WordPress, and the choice follows the ownership question. Our [multilingual CMS service](/services/cms/multilingual-cms) focuses on the English and Arabic case.
A short evaluation checklist
Run this with real content and an Arabic-speaking reviewer before you sign anything. A day with a trial account tells you more than a demo.