3 ways product teams get Arabic localization wrong

Let me say something that will make a lot of product managers uncomfortable: most "Arabic" products aren't Arabic products. They're English products wearing a costume.

I've seen what it looks like when it's done right, at Careem, where we built dialect-level localization across a dozen MENA markets, and at talabat, where we ran separate copy decks with localized CTAs per market cluster. 

I've also seen, repeatedly, what the industry does instead. 

The pattern is depressingly consistent. A team ships an Arabic version of their product. The UI flips right-to-left. The strings get translated. Leadership checks the box. And then the Arabic retention numbers come in, and nobody can explain why they're lagging behind English.

I can explain why. And in this article, I will.

Mistake #1: Treating RTL as a feature, not a foundation

The first and most common sin is treating right-to-left (RTL) layout as a late-stage feature, something you bolt on after the product is built. A sprint, a flag, a CSS property. Done.

This is not localization. This is a mirage.

When you build a product in a left-to-right mental model and then mirror it, you don't get an Arabic product. You get a reflected English product. The information hierarchy is wrong. The visual flow fights the user's instincts. The reading pattern – which for Arabic speakers starts top-right and moves left – collides with UI patterns that were designed for the opposite. Buttons feel off. Navigation feels backwards. Cognitive load goes up. Engagement goes down.

This shows up in driver onboarding drop-off, in checkout abandonment, in support ticket spikes that your English-market benchmarks can't explain. The steps make sense in English. In Arabic, the logical sequence feels disjointed, because the visual grammar of the interface is still Western, even if the words aren't.

At Careem, the answer wasn't a better translator. It was rebuilding the Arabic experience from the information architecture level up. That means:

• Wireframes start RTL. Not mirrored after the fact, designed RTL from the first sketch.
• Navigation hierarchies reflect Arabic reading patterns. Primary actions live on the right. Supporting actions live on the left. This is not arbitrary; it maps to how Arabic speakers scan a page.
• Typography is treated as a design constraint, not a style choice. Arabic script is more vertically compact and horizontally expansive than Latin script. Line heights, padding, and component sizing need to be rebuilt around Arabic type metrics, not retrofitted.
• Numbers are a deliberate decision. Arabic-Indic numerals (٣، ٢، ١) versus Western Arabic numerals (1, 2, 3) is not a minor detail. In some markets, the wrong choice signals immediately that this product was not built for you.

RTL is not a feature. It's a foundation. If you didn't start there, you're not building an Arabic product; you're building a translation.

Mistake #2: Treating "Arabic users" as a single market

Here’s where the real blind spot lives, and where even teams who get the RTL foundation right still fail.

"Arabic speakers" is not a user segment. It is a language family covering 22 countries, 400 million people, and a dialect spectrum so wide that a Moroccan and a Kuwaiti watching the same video in their respective dialects may understand as little as 40% of each other's speech.

The Arabic that your Egyptian users read is not the Arabic your Saudi users read, not in register, not in idiom, not in cultural reference. Modern Standard Arabic (MSA), the formal written language used in news and official documentation, is understood across the region. But it’s not how people speak. It’s not how people feel. And when your product speaks to users in MSA, it’s the linguistic equivalent of a consumer app writing its microcopy in Shakespearean English – technically correct, emotionally distant.

At Careem, we went further than most. We built dialect-level localization per market, not MSA broadcast across the board, but Khaleeji Arabic in the Gulf, Egyptian colloquial in Cairo, Levantine in Amman. The difference in engagement was not subtle. When users feel spoken to rather than translated at, the product relationship changes entirely.

At talabat, operating across Kuwait, Qatar, UAE, Bahrain, Jordan, Iraq, Egypt, and Oman simultaneously, we ran separate copy decks with localized CTAs by market cluster. A promotion label that converted in Kuwait was tested and rewritten for Egypt – same offer, different language, different result. 

This wasn't accidental. It was a deliberate product decision that showed up in the numbers. "اطلب الآن" as a button label carries different urgency and social weight depending on where it appears. You test by market, not by language.

This matters for product in specific, concrete ways:

• Push notifications are culturally loaded. The directness that drives opens in the Gulf can feel aggressive in the Levant. Notification copy written for one Arabic market and blasted across all of them is a common and costly mistake. Segmented notification strategies by market – not just by language – consistently outperform unified Arabic pushes.
• Trust signals differ by market. In Saudi Arabia, brand authority and official-sounding language drive trust. In Egypt, social proof and community language drive trust. In Jordan, warmth and personal tone drive trust. A single Arabic brand voice cannot optimize for all three simultaneously. You need a tone-by-market framework, not a tone-by-language framework.
• Imagery and cultural context are not universal. Food photography that performs in the UAE – plated, aspirational, international – often underperforms in Egypt, where familiarity, portion size, and value signals matter more. The Arabic language on your product is only one layer. The cultural layer underneath it is where retention lives.

Mistake #3: Hiring a translator instead of an Arabic product thinker

This is the structural mistake that underlies both of the above.

Most companies building for Arabic markets hire a translator, someone who converts English strings into Arabic strings. Sometimes they hire a localization agency. Occasionally they hire a bilingual designer who can catch the most obvious RTL errors.

What they almost never hire is an Arabic product thinker: someone who understands user psychology in Arabic-speaking markets, can read behavioral data through a cultural lens, and can push back on product decisions that are structurally wrong for the region, not just linguistically wrong.

The teams that build most effectively for Arabic markets aren't the ones with the best translators. They're the ones where a product manager or designer who has grown up navigating both worlds can say: "This flow makes sense in English but will confuse our Egyptian users because the decision sequence assumes a level of upfront trust that isn't there yet." That kind of cultural product intuition cannot be outsourced to a localization vendor.

What this looks like in practice:

• Arabic-market PMs in the room during discovery, not during QA. By the time a feature reaches QA, the structural decisions are made. If your Arabic market feedback loop starts at translation review, you are already too late.
• User research conducted in dialect, not in MSA. If your research interviews are conducted in formal Arabic, you’re getting formal answers. You’re not getting how users actually think about your product. Research in the user's natural register – Egyptian colloquial for Egyptian users, Khaleeji Arabic for Gulf users – surfaces entirely different insights.
• Separate OKRs for Arabic market retention. If your Arabic experience is bundled into a single global retention metric, the signal is invisible. Segment your Arabic retention by market. Make it someone's explicit job to own those numbers.

What actually moves the needle in Arabic localization

Based on what performs  (across food delivery, ride-hailing, and consumer tech), here’s the hierarchy of what actually matters:

Level 1: RTL architecture (table stakes) 

Built from the ground up, not mirrored. This is the floor. If you don't have this, nothing else matters.

Level 2: Market-specific microcopy (high leverage) 

Build separate copy decks for each market cluster – Gulf, Levant, and Egypt/North Africa – managed and tested by people on the ground in those markets. Tested with real users in those markets. talabat's localized CTA strategy is the benchmark here – same product, different language decisions per market, measurably different outcomes.

Level 3: Cultural UX adaptation (often skipped, always felt) 

Imagery, tone, trust signals, and information hierarchy should be adapted per market cluster. This is where the gap between "we have an Arabic product" and "Arabic users love this product" actually lives.

Level 4: Dialect-level localization (the ceiling, and Careem's edge) 

Not MSA. Not a regional approximation. The actual way people speak in the markets you serve. This is hard, expensive, and worth it. Careem's dialect-level work across the region set a standard that most MENA products still haven't reached.

Level 5: Behavioral data segmented by market (the unlock) 

Your Arabic users are not one cohort. The moment you start reading Egyptian user behavior separately from Saudi user behavior, you will see patterns you couldn't see before – and you will understand why your blended Arabic metrics have been lying to you.

The honest truth

The Arabic-first product mistake isn’t really a localization mistake. It's a prioritization mistake. It happens when Arabic markets are treated as an adaptation of a Western product rather than as a primary design context in their own right.

The companies that get this right – Careem and talabat are two of the clearest examples in the region – don't think about Arabic localization. They think about Arabic product design. The language comes first, the culture comes with it, and the market follows.

Every other approach is just a translation.