Most modern Shopify themes already handle Arabic. Set the store language to Arabic, publish it through Shopify Markets, and the theme flips: text right-aligns, the header mirrors, the cart drawer slides in from the other side. So when a client asks whether their Shopify RTL Arabic theme will "work", the honest answer is that the theme will. What breaks is everything bolted onto it — custom sections, the slider you paid for, the review widget, the size chart, the price block on the product card, and about a third of the form fields. Those are the defects we fix on every Arabic build, in roughly the same order, so here they are.
The one-line fix that prevents half the problems
Your <html> tag needs a real dir attribute driven by the locale, not a CSS class. In theme.liquid:
<html lang="{{ request.locale.iso_code }}" dir="{% if request.locale.iso_code == 'ar' %}rtl{% else %}ltr{% endif %}">
With dir="rtl" set properly, the browser's bidirectional algorithm does most of the work for free. Then stop writing physical directions in your CSS. margin-left becomes margin-inline-start. padding-right becomes padding-inline-end. text-align: left becomes text-align: start. left: 20px becomes inset-inline-start: 20px. Logical properties have been safe in every browser we support for years now, and they remove the need for a second stylesheet full of [dir="rtl"] overrides that someone will forget to update six months later.
The theme's own CSS is usually already written this way. Your custom sections are not. That's the split.
Icons: flip the arrows, leave the clock alone
A blanket transform: scaleX(-1) on every SVG is the fastest way to ship a storefront that looks broken to an Arabic reader. Direction-carrying icons mirror. Objects don't.
- Mirror: chevrons, back and next arrows, breadcrumb separators, the "reply" arrow, progress arrows in a cart bar, the slide-out direction of the cart drawer and the mobile menu.
- Don't mirror: checkmarks, the play triangle on a video, clocks, padlocks, star ratings, brand logos, credit-card marks, anything with Latin text baked into the artwork.
- Argue about: the magnifier. We mirror it. Nobody has ever complained either way.
The quantity stepper catches people out. In LTR it reads minus, count, plus. Flip the container with flexbox and it reads plus, count, minus, which is correct for RTL and looks wrong to the English-speaking founder reviewing staging. It isn't wrong. Leave it.
The other one: a hamburger or filter icon with unequal line lengths mirrors, or it looks lopsided against the new alignment. Small thing, five minutes, and it's the kind of detail an Arabic-first shopper registers without being able to name it.
Sliders break because someone did arithmetic on scrollLeft
This is the single most reliable defect on Arabic builds. Dawn-derived themes implement the product media carousel and the multi-column slider with a scroll-snap container, and the JavaScript works out which slide you're on by measuring scrollLeft against slide width. In RTL, scrollLeft counts down from zero into negative numbers. The maths still runs. It just produces nonsense: the dots highlight the wrong slide, the next button scrolls backwards, and on a three-up collection carousel the last slide is unreachable.
Fix it by taking the absolute value before you compare, and by using scrollBy({ left: -slideWidth }) with the sign inverted when document.dir === 'rtl'. Don't try to patch it with CSS.
Third-party slider libraries need their own flag rather than inheriting the document direction — Swiper takes rtl: true, Splide takes a direction option, Flickity has its own. If a paid section's slider is minified inside the app's asset bundle and exposes no direction setting, you're either rebuilding that section or dropping it. We usually rebuild. It's four hours and the store stops looking like a translation.
Forms, phone numbers and the bidi algorithm
Arabic text mixed with Latin characters and digits gets reordered by the browser's bidi algorithm, and it is technically correct every time it makes a mess. Type a UAE phone number into a right-aligned input and the + jumps to the wrong end: you see 971501234567+. Order number #1042 renders as 1042#. A tracking ID with a hyphen in it splits into two chunks in the wrong sequence.
Two fixes, both cheap. On inputs that hold Latin data — email, phone, coupon codes, card fields in a custom form — set dir="ltr" on the input itself while keeping the label right-aligned. For Latin strings printed inside Arabic sentences, wrap them in <bdi> or add a left-to-right mark. Order confirmation lines and shipping-status text are where this bites hardest, because that's where the numbers live.
The rest of the form checklist, from builds in the Gulf:
- Floating labels animate on a hard-coded
leftvalue and end up sitting outside the field. Every single time. - Validation errors and required-field asterisks stay pinned left unless you convert them to logical properties.
- Checkbox and radio inputs keep their left margin, so the box sits a few pixels off the text baseline on the wrong side.
- Address forms: the UAE has no postcode, Saudi has a five-digit one plus a four-digit extension, and "State" means emirate or region. Shopify's checkout handles this once the country is right. Your custom address block in the account area probably doesn't.
Shopify's hosted checkout itself is fine in Arabic — it's the one part you don't have to touch. Checkout UI extensions are not; they inherit direction from the checkout container but any inline styling you wrote will need auditing.
Price alignment: the sale price ends up in the wrong place
A price block with a compare-at price is a flex row: struck-through original, then the sale price. Flip the container and the visual order flips too, so the discounted price now sits where a shopper expects the original. Most Arabic shoppers read it correctly anyway, but the badge, the currency code and the "From" prefix rarely all cooperate.
Decide three things explicitly rather than letting the browser decide for you:
- Currency placement.
AED 250or250 د.إ. Shopify's currency format setting is per-market, and the Arabic abbreviation renders as a single RTL glyph cluster, which sits differently from the three Latin letters. Pick one and set it in the market's currency formatting, don't hard-code it into a snippet. - Numerals. Western digits (250) or Arabic-Indic (٢٥٠). Gulf eCommerce overwhelmingly uses Western digits, and so do the payment providers, so mixing them on a product page for the sake of authenticity just makes price comparison harder.
- Decimals. A price of 250.00 written RTL with a comma-decimal locale setting can display in a way that reads as a different number entirely. Test with a three-digit price and a decimal, not with 99.
Discount badges anchored with position: absolute; right: 10px stay on the right in RTL and cover the wishlist icon that just moved there. Convert to inset-inline-end.
Filters and search behave worse than the layout suggests
Layout problems in a filter drawer are obvious: the range slider handles reverse, the min input holds the max value, the "clear all" link sits on the wrong side. Twenty minutes of CSS.
The search behaviour underneath is the real issue and it survives the CSS fix. Arabic has multiple written forms of the same word. أحذية and احذية differ by one hamza. Taa marbuta (ة) and haa (ه) get typed interchangeably at the end of a word. Optional diacritics may or may not be present in your product titles. Shopify's native search does not normalise any of this, so a shopper typing the form they use at home gets zero results for a product you definitely stock, and you never hear about it because a zero-result search is a silent bounce.
You can partly patch it by stuffing spelling variants into product tags or a search-keywords metafield, which is fine for a catalogue of 200 SKUs and unmaintainable at 2,000. Above that, use a search app that normalises Arabic input and lets you author synonyms. FilterPro is ours, and the reason we built the synonym layer the way we did is precisely this problem. Any tool that handles Arabic normalisation properly will do the job.
Arabic webfonts are heavier than you think
An Arabic font file carries initial, medial, final and isolated forms of every letter plus a large set of ligatures. A subset Arabic weight lands around 120–150KB where the Latin equivalent is 20–30KB, and designers routinely specify three weights.
Three weights at 140KB is 420KB of font. Cut to two weights at 95KB each after proper subsetting and you're at 190KB — 230KB saved. On a throttled connection at 1.6 Mbps, 230KB is 1.84 megabits, which is about 1.1 seconds of transfer sitting directly in front of your first text paint. That's the whole gap between a product page that feels instant and one that doesn't.
Practical rules: two weights maximum, subset to the Arabic and Latin ranges you actually use, self-host as WOFF2, preload the weight used in the H1, and set font-display: swap with a metric-matched fallback so the layout doesn't jump. Tajawal, Cairo, Almarai and the IBM Plex and Noto Arabic families all render cleanly at small sizes. Also raise your base line-height — Arabic diacritics and descenders need more vertical room than Latin, and 1.4 that looked fine in English feels cramped in Arabic. More on the wider picture in our notes on Shopify speed optimization.
The translations nobody checks
Shopify's Translate & Adapt covers theme strings, products, collections and most metafields. It does not cover content that lives inside third-party apps, and that's where Arabic storefronts leak English. Review widgets, size charts, subscription selectors, upsell blocks, shipping-rate labels, back-in-stock forms, and every automated email and SMS your marketing stack sends. Order confirmation in Arabic and shipping notification in English is a bad look in a market where COD is still a large share of orders and the delivery message is the one people actually read.
Check your Arabic app inventory before you commit to a design. If a critical app is English-only and has no translation fields, you either replace it or accept a bilingual storefront and make that decision consciously.
The pass we run before handover
Switch the locale, then work through the store on an actual phone rather than a resized desktop window:
- Home page: every slider, in both directions, to the last slide and back.
- Collection: filter drawer open, price range slider, applied-filter chips, sort dropdown, pagination arrows.
- Product: media gallery swipe, variant swatches, quantity stepper, sticky add-to-cart, tabs and accordions, review widget.
- Cart drawer: slide direction, remove icon position, note field, discount code input with a Latin code typed into it.
- Account: address form, order history, order number rendering, phone number rendering.
- Emails: order confirmation, shipping, abandoned cart.
Budget it as its own line item. On a theme that wasn't built RTL-first, the fixes above run somewhere between three and six working days depending on how many paid sections are involved — separate from translation, separate from the Markets setup. Teams that fold it into "add a language" always run over.
If you're planning an Arabic storefront for the UAE or Saudi and want to know which of these will actually bite on your current theme, our Dubai team runs a free audit against a staging locale and sends back the defect list with the fix time next to each item. Fix the sliders and the forms first. The icons can wait a week.