Localization · 9 min read · Updated 19 Aug 2026

Why Full Arabic RTL Support Matters for UAE Business Websites

Already have a website? Get a free technical audit:

Open the Arabic version of most UAE business sites and the tell arrives within seconds: a phone number whose plus sign has migrated to the wrong end, a button label clipped mid-word, a date picker still opening left-to-right while everything around it has flipped. Arabic support is claimed almost universally in this market. Engineering for it is rarer, and the difference shows up in exactly those details.

What bolted-on RTL actually looks like

A blanket direction: rtl flip that mirrors everything, including what must never mirror — phone numbers, Latin brand names, code samples, embedded Western numerals
Arabic set in a Latin webfont that happens to include Arabic glyphs, at a size tuned for Latin x-height, so the script reads cramped
Layouts that overflow because they were measured against English strings and Arabic runs to a different length
Forms, date pickers and currency fields that stay left-to-right while the page around them has flipped

Logical properties do most of the work

The highest-leverage change is to stop writing directional CSS at all. margin-left becomes margin-inline-start, padding-right becomes padding-inline-end, left: 0 becomes inset-inline-start: 0, and text-align: left becomes text-align: start. The browser resolves "start" against the element's own direction, so one component renders correctly in both language trees — no duplicated markup, and no mirrored stylesheet that drifts out of sync the first time someone edits only one copy.

CSS

/* directional — needs a mirrored copy for Arabic */
.card {
  margin-left: 24px;
  border-left: 2px solid;
  text-align: left;
}

/* logical — one rule, correct in both directions */
.card {
  margin-inline-start: 24px;
  border-inline-start: 2px solid;
  text-align: start;
}

The parts that must not flip

Some content is directionally neutral in the source but not in meaning. A phone number, an email address, a Latin product name or a price in Western digits sitting inside an Arabic sentence takes its direction from the surrounding text, which is how +971 4 123 4567 ends up rendering with the plus sign on the wrong side. The fix is an explicit island rather than a global rule, because the surrounding paragraph should stay right-to-left.

HTML

<!-- inside an RTL paragraph -->
<span dir="ltr">+971 4 123 4567</span>

The lang and dir attributes have to be real

A language switcher that swaps strings on the client leaves every Arabic page served as lang="en". Search engines read that attribute to decide which market a page belongs to, and screen readers pick pronunciation and voice from it, so a wrong value is both an SEO problem and an accessibility one. In the Next.js App Router this has an architectural consequence that catches people out: a single root layout can only ever emit one html element, so genuinely different lang and dir per language means two root layouts in parallel route groups — not a prop threaded through one shared layout.

Route structure

app/
  (en)/layout.tsx   ->  <html lang="en" dir="ltr">
  (ar)/layout.tsx   ->  <html lang="ar" dir="rtl">

Typography and numerals are separate decisions

Most Latin webfonts either lack Arabic entirely or ship a weak fallback face, so pick an Arabic family deliberately — Cairo, IBM Plex Sans Arabic and Noto Kufi Arabic are all solid starting points — and check it at the sizes you actually use, because Arabic needs more vertical room than Latin at the same nominal size. Then decide numerals on purpose: Arabic-Indic digits and Western digits are both correct Arabic, but UAE business contexts overwhelmingly use Western digits for prices, phone numbers and dates even in otherwise Arabic copy. Mixing the two inconsistently across a site is a common tell that nobody owned the decision.

Arabic is shorter in characters, not in meaning

Here is a trap that only appears once you measure. Translating the meta descriptions on this site, the Arabic carried the same meaning in roughly 15 to 20 percent fewer characters than the English. The English versions sat comfortably inside the 160-character limit; the Arabic ones came out short enough that an SEO auditor flagged them as too short and we had to lengthen them. Anywhere you enforce a character budget — meta tags, database columns, card summaries that truncate — a threshold tuned for one language is wrong for the other. Budget in both languages, or you will ship one of them broken.

The bug nobody warns you about: image generation has no bidi

This one is worth the whole article, because the site looks perfect and the damage happens off-site. Satori — the renderer behind Next.js ImageResponse and a good number of hosted OG-image services — does not implement the Unicode bidirectional algorithm. It shapes Arabic glyphs correctly and joins letters properly, then places whole words left to right. The result is an Arabic social card that reads backwards on every link shared to WhatsApp, LinkedIn or X, while the page it points to is flawless. Setting direction: rtl on the container changes nothing, because the property is not implemented in that layout engine at all.

The workaround is to reverse the token order before rendering, which cancels out the left-to-right placement and lets the source string in your code stay readable Arabic. Whatever you do, open the generated image and look at it: no test suite catches this, and neither does any amount of checking the page itself.

JavaScript

// cancels out Satori's left-to-right word placement
const rtlWords = (line) => line.split(' ').reverse().join(' ')

What to check before you launch

Every Arabic URL returns lang="ar" dir="rtl" in the served HTML, not after hydration — check with view-source or curl, not the devtools inspector, which shows the post-JavaScript state
Phone numbers, emails and Latin names inside Arabic copy carry an explicit dir="ltr"
The Arabic social card renders in the right order — open the actual image file rather than trusting that it generated
Forms accept and submit Arabic input, including names with diacritics, and the confirmation email is readable
Arabic pages appear in the sitemap with an hreflang cluster identical to the one in the markup — Google discards annotations that disagree between the two
Numerals are consistent site-wide, and the choice was made rather than inherited

Not sure whether your Arabic layer needs a retrofit or a rebuild? The free technical audit covers it specifically — send the URL and we will tell you which one it is.

Web development →