Arabic users decide whether a product was built for them within a few seconds, and they are rarely wrong. The signals are small and cumulative: an arrow pointing the wrong way, a phone number that jumps to the wrong side, a confirmation email in English. None of them is a bug report. All of them together are a conversion problem.
These are the nine I see most often, roughly in order of how much damage they do.
1. Mirroring the layout instead of designing for it
Flipping a left-to-right design produces predictable casualties: charts that read backwards, progress bars that fill in the wrong direction, and icons that now point away from the thing they refer to.
The rule: mirror layout and navigational direction. Do not mirror things whose direction carries independent meaning.
Mirror: page structure, navigation, back arrows, list indentation, drawer direction. Do not mirror: play buttons, clocks, most brand marks, and anything representing physical direction like a map or a vehicle.
Charts deserve their own thought. A time-series axis running right-to-left is correct in Arabic and confusing if you only flipped the container without relabelling.
2. Writing left and right in your CSS
Every margin-left, padding-right and text-align: left is a future RTL bug. Logical properties — margin-inline-start, padding-inline-end, text-align: start — do the right thing in both directions with no conditional code at all.
If you are on Tailwind, the ms-* / me-* / ps-* / pe-* / text-start utilities exist for exactly this. Converting a codebase later is mechanical but tedious; starting this way costs nothing.
3. Arabic search that cannot find Arabic
This one silently loses sales and produces no error.
Arabic has several forms of alef (ا أ إ آ), taa marbuta versus haa (ة/ه), yaa versus alef maqsura (ي/ى), and optional diacritics. A user searching احمد will not find أحمد unless you normalise both the index and the query.
Do this at indexing time, not display time. Users type quickly and without diacritics; your catalogue was entered carefully and with them. Without normalisation, they never meet, and your product looks like it has no stock.
4. Storing translatable content in a single column
If product.name is one field, bilingual content becomes a manual duplication problem, and one of the two languages is permanently out of date.
Model translatable content as translatable from the start, with an explicit fallback rule. Then adding or correcting a language is a content task rather than a database migration. This is a small design decision on day one and a large project on day four hundred.
5. Latin numerals, Arabic numerals, and picking neither
Both Western (123) and Eastern Arabic (١٢٣) numerals are used across the Arab world, with regional preference. What breaks trust is inconsistency — prices in one, quantities in the other, dates in a third.
Pick a convention per market, apply it everywhere including invoices and notifications, and be careful with mixed-direction strings. A phone number, an IBAN or an order reference inside Arabic text needs explicit direction handling or it will render in a visually scrambled order. This is the single most common "the site looks broken" report I receive on Arabic products.
6. Dates that assume one calendar
If your users are in Saudi Arabia, Hijri dates may matter. If they are in Egypt, Gregorian usually suffices. If your product serves both, decide deliberately rather than defaulting.
And format dates as text, not as numbers — 03/04 is ambiguous in every language.
7. Arabic typography treated as an afterthought
Latin-first fonts render Arabic poorly, and Arabic script needs more vertical breathing room than Latin at the same nominal size. Line height that looks tight-and-modern in English looks cramped and hard to read in Arabic.
Choose a typeface with genuine Arabic design work behind it, and tune line height per script rather than sharing one value. This is the cheapest single upgrade to how "native" an Arabic product feels.
8. Everything outside the app staying in English
The interface is beautifully Arabic. Then the order confirmation email, the SMS, the invoice PDF, the validation error and the password-reset message all arrive in English.
Those touchpoints carry a disproportionate share of trust, because they are the ones that arrive when something matters — a payment, a delivery, a failed login. Localising the interface but not the transactional layer is the most common way an otherwise good Arabic product feels foreign.
On Ajza, Arabic and English were carried from the data model through the API, web, mobile, email and SMS. That was a deliberate scoping decision, and it is the reason no market waited.
9. Machine-translated interface copy
Interface microcopy is the hardest text in a product to translate and the easiest to spot when it is wrong. Button labels, empty states, error messages and confirmations should be written in Arabic, not converted from English.
The tell is usually register: overly formal where the English was casual, or literally translated idiom that no Arabic speaker would use. Users cannot always name what is wrong, but they downgrade their trust in the product accordingly.
Clear Modern Standard Arabic travels well across Egypt, Saudi Arabia and the Gulf. Dialect is a deliberate choice for a specific market and tone — not a default.
The one that costs the most: doing this later
Every mistake above is cheap to avoid and expensive to correct, and they compound. Retrofitting RTL into a live product means touching the layout system, the data model, the search index, the notification templates and the PDF generation, all at once, on a system with real customer data in it.
Building both directions from the first screen costs a modest amount more than building one. I have never seen the retrofit come in cheaper.
Auditing what you already have
If you have a product and want to know which of these apply, the honest first step is an audit: how translatable content is stored, how the layout handles direction, and how much lives outside the app in emails, PDFs and notifications. That determines whether you are looking at a few weeks of work or a structural change.
The Arabic RTL software development page covers what that audit looks at and what proper bilingual work includes. Or send a link or a screenshot and book a free 15-minute call — I will tell you which category you are in before you commit to anything.