Building a Multilingual Website: hreflang, RTL+LTR and i18n Architecture Done Right

Choose the URL structure by operating model

Start with how the business will actually run each locale, not with a list of target countries. The deciding question is whether the localized versions share a product, codebase, editorial team and release process. A country appearing in a sales plan does not, on its own, justify a separate domain.

The subfolder, subdomain and ccTLD decision matrix

Take one company launching English for the UAE, Arabic for the UAE and French for France. If all three share the same offer, CMS and product team, the working structure is /en-ae/, /ar-ae/ and /fr-fr/. The operating boundary stays visible in the path without multiplying properties, and a single deployment covers every locale.

Move up a level only when the operating model forces it. Pick a subdomain when one regional team needs to deploy on its own schedule or run a separate stack, because the boundary is then real rather than cosmetic. Pick a country domain only when a market has its own commercial proposition, its own team and enough volume to justify securing, monitoring and maintaining a standalone property; most expansions never reach that bar. For a shared product the default answer is the subfolder, and the burden of proof sits on anyone arguing to split it. Teams weighing a separated content layer should first decide whether headless CMS architecture improves locale control enough to justify the extra moving parts.

Build the i18n locale model before you create pages

An i18n model should treat locale as required data, not as a flag or an optional translation field. Every public version needs a locale code, language, market, writing direction, path, fallback policy, reviewer, publication state and analytics segment.

Locale register for the worked launch

The central relationship is the equivalence set. Three translations of the same service page belong to one set. An Arabic service page and a French page offering different packages are not equivalent just because their titles share a service name. Do not connect two pages unless a reader switching locale would reasonably expect the same task and the same proposition.

Keep locale selection in the URL even when browser preferences drive the first choice, so a visitor can copy, revisit and share the exact version without a session. Store translation state separately from publication state, so an unfinished translation cannot go public merely because its English source is live.

How should hreflang connect Arabic and European pages?

Every published member of an equivalence set should list itself and all other published equivalents using the same complete hreflang set. Use x-default only for the genuine neutral fallback or locale selector, never as a catch-all for a language you have not translated.

A worked hreflang cluster with x-default

Assume one service has English UAE, Arabic UAE and French France versions plus a neutral selector. Place this identical block on each localized equivalent:

<link rel="alternate" hreflang="en-AE" href="https://example.com/en-ae/service/">
<link rel="alternate" hreflang="ar-AE" href="https://example.com/ar-ae/service/">
<link rel="alternate" hreflang="fr-FR" href="https://example.com/fr-fr/service/">
<link rel="alternate" hreflang="x-default" href="https://example.com/choose-region/">

The English page includes its own English self-reference; the Arabic and French pages publish the identical four destinations. Each localized page keeps a canonical that points to itself, not to the English version. The Arabic document also carries lang="ar-AE" and dir="rtl", while the other two use their own language values and dir="ltr".

Generate these annotations from the equivalence record rather than hand-maintaining lines on each page. A release check can then compare the stored cluster against rendered output and stop publication when it finds a missing self-reference, an unreturned pairing, an unpublished destination, a redirect or a locale mismatch. These are build controls; they do not promise indexing, ranking or search-result selection.

How can one design system support Arabic RTL and Latin LTR?

Make direction a document-level input to shared components. Use logical start and end properties, then document which icons and controls mirror, which stay fixed, and how mixed-direction content is tested.

One design system for Arabic RTL and Latin LTR: a checkout-component test

1. Set language and direction at the root. Components inherit the locale unless a contained value needs an explicit override.
2. Use logical layout rules. Express inline start and inline end instead of hard-coding left and right across the component library.
3. Decide each symbol individually. Directional arrows may mirror; brand marks, media controls, phone numbers and mathematical symbols each need an explicit call.
4. Test real mixed strings. Put English product names, URLs, email addresses, dates and numerals inside representative Arabic sentences.
5. Test realistic copy length. Navigation, tables, buttons and error messages must survive approved Arabic and European copy at supported widths.

Use a checkout row as the acceptance scenario: a product thumbnail, an Arabic description, a Latin stock code, a numeric price and quantity controls. In RTL the row follows Arabic reading order, yet the stock code and number stay readable, the plus and minus keep their meaning, focus moves in a usable sequence, and no icon mirrors just because its container flipped. One component exposes alignment, bidirectional text, icon behaviour, control order and content expansion at once, which is why it is a better gate than signing off a static homepage image. Record the expected LTR and RTL result beside the component so later releases repeat the same check.

How should content localization move from source to publication?

Use explicit states with named owners: source approved, translation active, language review, market review, release ready and live. A source edit should raise a tracked change for every affected locale, not silently overwrite localized content.

Localization ownership and change control

1. Approve the source meaning and flag product names or controlled terms that must not change.
2. Create localized records inside the correct equivalence set.
3. Localize structured fields, navigation, metadata, media text, validation messages and transactional copy, not only the body.
4. Assign language review to the approved reviewer for that locale. Do not describe raw machine output as reviewed.
5. Review market-dependent offers, contact routes, currencies, units and imagery, and remove any unsupported market claim.
6. Publish only after navigation, canonical behaviour, hreflang output and analytics configuration pass the locale release record.

Suppose the English service promise changes. The CMS records the source revision, the affected fields, the Arabic owner, the French owner and the review state. It does not paste the new English sentence into Arabic or mark every translation current. The team can keep the last approved localized copy while review runs, withdraw the affected page, or make an explicit editorial call. Localization is therefore wider than translation: it decides whether the proposition, examples, navigation and support route make sense for the represented reader. Wire that workflow to the canonical and indexing controls used in SEO-friendly web development.

How do you detect a failure affecting only one locale?

Segment release checks by locale, template, device class and delivery region. A passing English page cannot prove that Arabic fonts, longer German labels, localized assets or locale-only integrations behave correctly.

Per-locale performance monitoring so no locale silently fails Core Web Vitals

For three locales and three representative templates, test nine routes: the homepage, a service page and an article in English UAE, Arabic UAE and French France. This is a concrete release sample, not a universal coverage rule. WebStackRank's own published build process already treats hreflang verification as a fixed QA-phase gate for every bilingual site and checks rendering on real devices at seven widths from 320px up to 1920px before launch, according to the WebStackRank Website Development Process SOP (May 18, 2026). That same SOP sets a Lighthouse mobile performance floor of 90, measured on the live URL, as a contractual delivery criterion, so a workable rule is to hold every locale, not just English, to that documented baseline rather than to an invented universal threshold.

If only /ar-ae/service/ regresses, compare its fonts, images, third-party integrations and content against the last accepted Arabic release before touching the shared application. Change the differing dependency, not the whole stack.

Launch sequence and maintenance limits

Launch a complete, reviewable locale set rather than many half-translated routes. Every locale needs an owner, a stable URL, a complete equivalence record and a retained release result.

1. Approve the locale register and URL policy.
2. Define equivalence and canonical rules.
3. Build shared, direction-aware components.
4. Load reviewed content for the first complete route set.
5. Generate and compare every hreflang cluster.
6. Test navigation, mixed-direction text and keyboard order.
7. Run the nine-route sample and retain the results.
8. Verify the rendered staging page before named human approval.

This guide cannot validate a framework, translation platform or deployment because none was supplied, and it gives no country-specific legal advice. Revisit the architecture when a market is added, a regional team becomes operationally independent, domains change, the CMS is replaced, fallback behaviour changes, or one locale repeatedly misses its review and release controls.

Multilingual architecture FAQ

Is a subfolder or a ccTLD better for a multilingual website?

Neither is universally better. A subfolder keeps one operational property and is the sensible default for a shared product; a ccTLD earns its place only when a market has its own team, proposition and volume to run a full property. Choose by operating model, not by a ranking promise.

Should I machine-translate first and edit later?

You can draft with machine translation, but never publish it as reviewed. Every locale needs sign-off from an approved reviewer for that language before it goes live, and the CMS should not mark raw output as complete.

Does hreflang stop duplicate-content or cannibalisation problems?

hreflang signals which localized version suits which language or region, and reciprocal, self-referencing clusters reduce the risk of the wrong version competing. It is an implementation control, not a guarantee about indexing or rankings; correct canonicals and genuinely distinct locale content still matter.