An Arabic RTL storefront is not a storefront with a stylesheet flipped. The layout is the easy half. The hard half is that an order contains Arabic, Latin and digits in the same string, and the rules for which direction each part runs are decided by the Unicode Bidirectional Algorithm, not by your CSS.
Teams usually find this out at the same point: the product pages look right, and then a customer address comes back with the building number at the wrong end.
What RTL support actually covers on an Arabic RTL storefront
Four separate pieces of work hide behind the phrase RTL support, and they fail independently.
Direction. Setting dir=”rtl” and lang=”ar” on the document, then replacing directional CSS with logical properties: margin-inline-start instead of margin-left, padding-inline, inset-inline, border-inline-start. A component library written with physical properties will not mirror, however you set the document direction.
Typography. Arabic letterforms are contextual. The same letter is shaped differently at the start, middle and end of a word, and joins to its neighbours. A font without proper Arabic coverage and shaping renders disconnected glyphs. Arabic also sits differently on the line and usually needs more vertical space than the Latin equivalent, so fixed-height components built around English strings clip.
Content. Two sets of product names, descriptions, category labels, meta titles, alt text and email templates, with a rule for what appears when a translation is missing.
Data. The part nobody scopes. Order data is mixed-direction by nature and does not obey the document setting. This is what separates a real Arabic RTL storefront from a translated one.
The parts that mirror, and the parts that must not
Mirroring on an Arabic RTL storefront is not global. The layout mirrors. Several things inside it must not.
| Mirrors | Stays as it is |
|---|---|
| Page layout, navigation, sidebars | Numbers, in every script |
| Breadcrumbs and pagination order | Latin brand names, SKUs, model codes |
| Directional icons: back, forward, next step | Logos and wordmarks |
| Progress indicators through a checkout | Phone numbers and IBANs |
| Text alignment and list markers | Clock faces, and most product photography |
The failure here is quiet. A mirrored logo or a reversed SKU does not throw an error. It reaches production on an otherwise finished Arabic RTL storefront and a customer notices.
Bidirectional text in real order data
This is where the work on an Arabic RTL storefront is.
A shipping address in Dubai commonly contains an Arabic street name, a Latin building name and Western digits, inside one field. The Unicode Bidirectional Algorithm resolves each run by script, and characters with no direction of their own, such as spaces, commas, hyphens, slashes and brackets, take their direction from what surrounds them. That is how a house number ends up rendered at the wrong end of the line, or a hyphenated order reference comes out reversed.
The fixes are specific, not stylistic.
- Wrap any user-supplied or mixed string in an element with dir=”auto”, or in a bdi element, so the algorithm resolves it in isolation rather than inheriting from the paragraph
- Use the Unicode isolate characters, first-strong isolate and its pop, where markup is not available, such as inside a plain-text email
- Never build a display string by concatenating a label, a colon and a value in a template and hoping it renders. Isolate the value
- Store the data as the customer entered it, and solve direction at render time
Order references deserve their own note. A reference like AE-2026-00417 contains Latin letters, digits and hyphens, and the hyphens are neutral. Rendered inside an Arabic paragraph without isolation, the segments can reorder. The customer then reads a reference back to support that does not exist in your database.
Numerals, currency and dates
Arabic is written with two sets of digits: Arabic-Indic and the Western digits used in English. Which one a locale expects is a per-market decision, not a per-language one, and it needs to be settled deliberately rather than inherited from whichever library loaded first.
Whatever is chosen has to hold everywhere: prices on the product page, the cart total, the invoice, the confirmation email, and the tax fields going to the Federal Tax Authority. An Arabic RTL storefront that shows Arabic-Indic digits in the cart and Western digits on the invoice is a support ticket.
Intl.NumberFormat with an explicit locale and numbering system makes this a setting rather than an accident. The same applies to the currency symbol position, which differs between locales, and to dates, where the Gregorian calendar with Arabic month names is usually expected for commerce rather than the Hijri calendar.
Where headless helps an Arabic RTL storefront, and where it adds work
Headless is an advantage here, with one condition: the content model has to treat Arabic as a first-class locale rather than a translation layer bolted on afterwards.
What helps. One backend, one catalogue, one order pipeline, with the storefront deciding presentation. Direction, digits and formatting become a rendering concern. Adding a third locale later costs a fraction of the first one. This is the argument for custom ecommerce development over a hosted theme when Arabic is in scope.
What it adds. You now own decisions a hosted platform would have made for you.
- One storefront serving both directions, or two builds. One build keeps the logic in one place and makes every component carry direction awareness. Two builds are simpler per component and double the surface that can drift.
- URL strategy and hreflang. Both locales need to be reachable, declared to each other and to x-default, and stable. Changing this after launch costs rankings.
- Fallback rules. What renders when a product has an English description and no Arabic one, and whether a half-translated page should be indexed at all.
- Search. Arabic search needs its own analyzer. Arabic text is often written without short vowel marks, the same word appears with and without them, and several letters have variant forms that customers type interchangeably. A default analyzer returns nothing for queries that look correct to the customer.
Transactional email, invoices and PDFs
This is the part that gets scoped last and breaks first, because it sits outside the Arabic RTL storefront codebase.
Email clients vary in how much they respect direction, and the safest approach is explicit dir attributes on the container and isolation around mixed values rather than relying on inherited direction.
PDFs are worse. Rendering Arabic correctly requires complex-script shaping, which means joining the letters and applying contextual forms, and a font embedded with that coverage. Generators without shaping support produce Arabic as disconnected letters in reverse order. The document looks like text. It is not readable.
This matters beyond customer experience. UAE e-invoicing requirements call for structured data with specific mandatory fields, and a buyer registered legal name may be in Arabic. If your invoice pipeline cannot carry and render Arabic correctly, that is a compliance problem, not a design problem.
The hard part: Reviewing a language your team does not read
Every failure described above is silent. Nothing throws. An Arabic RTL storefront with reversed digits and a mirrored logo renders with a green build.
What we would put in place before writing Arabic components.
- Screenshot tests on both directions for every component, so a physical CSS property added later shows up as a visual diff
- A fixed set of test orders holding deliberately nasty data: Arabic street with Latin building name, hyphenated reference, mixed-script product title, phone number inside an Arabic sentence
- A rendering check that covers the invoice and the confirmation email, not only the storefront
- A named Arabic reader signing off before launch, with the specific strings they must check written down in advance
The last one is not a formality. A developer who does not read Arabic cannot tell correct text from correctly-shaped nonsense, and a reviewer given a whole site will confirm it looks fine.
How KVY approaches it
We treat direction, numerals and mixed-script data as architecture decisions, settled in the first weeks alongside currency and tax handling. Bolting them on is how commerce builds fall apart in month six. It is the same discipline we describe in how we work across markets.
In practice that means the data model carries locale from the start, display strings are isolated by default rather than by exception, and the invoice and email templates are built against the same locale rules as the Arabic RTL storefront instead of being treated as downstream artefacts.
We build the system and the tests that hold it in place. Arabic copywriting and translation quality sit with a native speaker, and we would rather agree who that is during scoping than after launch.
Frequently asked questions
Is RTL support just flipping the CSS?
No. Flipping the layout handles direction. It does not handle contextual Arabic letterforms, mixed-direction order data, digit systems, search, or Arabic rendering in emails and PDFs. An Arabic RTL storefront fails on the data long before it fails on the layout.
Should an Arabic RTL storefront use Arabic-Indic or Western digits?
Both appear in Arabic-language markets, so it is a per-market decision rather than a per-language one. What matters technically is that one choice is applied consistently across storefront, invoice and email, and set explicitly in the formatting layer rather than inherited by default.
Do I need two storefronts for Arabic and English?
Either works. One build keeps the logic in one place and requires every component to be direction-aware. Two builds simplify each component and double the surface that can drift apart.
Why does my Arabic PDF invoice show disconnected letters?
The generator is not doing complex-script shaping, or the embedded font lacks Arabic coverage. Arabic letters join and change form by position, and a generator that draws glyphs individually produces unreadable output.
What does Arabic support have to do with UAE e-invoicing?
E-invoices carry the buyer registered legal name, which may be in Arabic, inside structured fields. An invoice pipeline that cannot carry Arabic correctly becomes a compliance problem as the 2027 deadlines approach.
Send us your product data model and a few real orders. We will tell you what breaks on an Arabic RTL storefront.