Arabic Is a Second Layout, Not a Translated File

There is a line in almost every bilingual brief that reaches us, and it is some version of the site should also be in Arabic. It reads like a content task. It is priced like a content task. Then somebody opens the Arabic homepage on a phone, sees the navigation still anchored to the left, the breadcrumb arrows pointing the wrong way and a price rendered as AED ٤٥٠٫٠٠ inside a container built for AED 450.00, and the project acquires a second half nobody quoted for.

We keep an archive of public project briefs, currently 27,057 of them. 263 mention Arabic. 30 mention right-to-left or RTL. Translation gets specified roughly six times more often than direction does. That single gap accounts for most of what goes wrong on bilingual UAE builds.

What actually changes when you add Arabic?

Arabic is not English written backwards. What flips is the layout axis: reading order, alignment, the side the navigation and sidebar sit on, the direction of anything that implies forward motion. What does not flip is a longer list than people expect.

A build that mirrors everything is as broken as a build that mirrors nothing. It just breaks in less obvious places, which is worse, because it survives the demo.

Which parts of a build actually cost more?

Not the homepage. Every brief remembers the homepage. Reading through the briefs in our archive that do specify RTL, the requirement is consistently described as covering the system, not the marketing site. One asks for Arabic support "for both the UI and data". One specifies "RTL-safe UI" across three separate user roles. One lists it beside VAT invoicing and payment gateways in the same requirements block.

That is the honest scope. The surfaces that quietly need a second pass:

• Forms and validation. Field alignment, placeholder direction, the position of the error message, and any input that must stay LTR inside an RTL page: email, phone, IBAN, TRN, card number, OTP.
• Tax invoices. A UAE tax invoice carries a TRN and 5% VAT. If it can be issued in Arabic, the template is a second document, not a translated string, and the number formatting has to be decided deliberately.
• Transactional email and SMS. Order confirmations, password resets, WhatsApp templates. These sit outside the theme, so they are the most commonly missed surface of all.
• PDFs and downloads. Quotes, invoices, certificates. PDF renderers frequently need explicit Arabic font embedding and shaping support.
• The admin panel. If Arabic-speaking staff run the store, the back office is in scope. That is often a bigger surface than the storefront.
• Third-party widgets. Chat, reviews, booking, instalment plans. Each one either supports RTL or does not, and you find out one at a time.
• Search. Arabic has definite articles, diacritics and multiple orthographic variants. A search box that only does exact matching will feel broken to Arabic users while testing perfectly in English.

What about fonts?

The most common visible defect on a bilingual UAE site is not layout at all. It is typography.

Arabic script needs its own family. A Latin webfont has no Arabic glyphs, so the browser falls back to whatever the device supplies, which is why the same page looks considered in English and generic in Arabic. Three practical rules:

1. Choose an Arabic family deliberately and pair it with the Latin one, rather than letting fallback decide. Cairo, Almarai, IBM Plex Sans Arabic and Noto Naskh Arabic are all reasonable starting points.
2. Give Arabic more vertical space. Arabic sits on a different baseline with taller ascenders and lower descenders. Reusing the Latin line-height produces clipped text and cramped headings.
3. Do not fake bold or italic. Arabic has no italic form, and synthesised bold degrades the letterforms. Use real weights from the Arabic family or use another emphasis device.

How do the platforms handle it?

Naming the tool in the brief also tells you something about who has actually thought this through. Across the whole archive, WPML is named in 37 briefs, Polylang in 9 and Shopify Markets in 3, against 181 briefs that just say "translation".

That last row is the whole argument for deciding this early. Building with logical CSS properties from day one, margin-inline-start rather than margin-left, costs approximately nothing. Retrofitting them across a finished stylesheet costs real money, and page-builder sites are the worst case because the left and right values live inside content, not inside a stylesheet you can refactor.

How do you check a bilingual site in ten minutes?

You do not need Arabic to catch most of it. Switch the site to Arabic and check:

1. The page element carries dir="rtl", not just a translated body of text.
2. Navigation, logo and language switcher have moved to the correct side, and the switcher does not lose the page you were on.
3. Arrows, chevrons and any "next" control point the other way.
4. A price, a phone number and an email address each still read correctly and are not reversed.
5. Headings are not clipped and paragraphs are not cramped, which means the Arabic font has a line-height of its own.
6. Submit a form with a deliberate error and confirm the error message is aligned and legible.
7. Complete a test order, then open the confirmation email and the invoice PDF.
8. Open the site on a phone. Drawers, sticky bars and off-canvas menus are where mirroring is most often forgotten.

If items 6, 7 and 8 pass, the build was scoped properly. In our experience they are also the three most likely to fail.

What to put in the brief

The reason quotes for bilingual sites vary so wildly is that each agency is silently guessing at a different scope. Remove the guess:

• State dir is required, not just Arabic content. Use the words right-to-left.
• List which surfaces are bilingual: storefront only, or checkout, emails, invoices, admin and PDFs too.
• Say who supplies the Arabic copy, and whether it is a translation of the English or written natively. Native Arabic copy is usually shorter and always sits differently in the layout.
• Name the Arabic font, or ask the agency to propose one and price it.
• Say whether the site must be indexed in both languages, which means hreflang, separate URLs and both versions in the sitemap.
• Confirm the admin language for the people who will run it.

None of that makes the project cheaper. It makes the number real. The expensive version of a bilingual site is not the one that was quoted properly. It is the one that was quoted as a translation and rebuilt as a layout.