Walk into any café, clinic or retail shop in the UAE and you will hear the same thing within five minutes: English and Arabic, often in the same sentence. Your customers live in two languages. Your staff often do too. Yet a surprising number of business apps built for this market ship in English only — or worse, with an Arabic mode that was bolted on at the end and visibly broken.
We build software in and for this market, and our own product — MidaOne, a café and restaurant management platform — ships with a full English/Arabic interface, right-to-left layout included. That experience taught us that "add Arabic" is never a checkbox. It touches design, engineering, fonts, numbers, even which documents stay in English on purpose.
This guide covers what bilingual really involves, where projects typically go wrong, and how to commission and test a bilingual app properly — written for business owners, not developers.
Why bilingual is a revenue issue, not a nice-to-have
In the UAE and wider GCC, Arabic is the official language and English is the working lingua franca. Which one a given user prefers depends on who they are: a barista from Manila, a cashier from Sharjah, an owner reviewing reports from Riyadh. If your app only speaks one language, some portion of the people who are supposed to use it every day will use it slowly, reluctantly, or not at all.
That shows up in the numbers, not just in goodwill:
- Staff-facing tools: a POS or back-office screen that a team member can't read confidently means slower service, more mistakes, and more training time. In hospitality, seconds per order add up.
- Customer-facing apps: checkout and registration flows are where hesitation kills conversion. A customer who hits a wall of unfamiliar language at the payment step often just abandons.
- Government and enterprise buyers: across the GCC, Arabic support is frequently a hard requirement in tenders and procurement, not a preference. English-only can disqualify you before pricing is even discussed.
- Trust: a properly localised Arabic interface signals that you built for this market rather than importing something generic. That perception matters in a region where relationships drive business.
RTL is much more than translation
The single biggest misconception we encounter: that bilingual means "send the text to a translator." Arabic is written right-to-left (RTL), and that changes the entire geometry of your app.
Layout mirroring
In an RTL interface, the whole screen flips. Navigation menus move to the right, back arrows point the other way, progress bars fill right-to-left, and the visual hierarchy your designer carefully built for English readers has to work in reverse. But it's not a blind mirror either — some elements deliberately stay put. Phone number fields, media player controls and clock faces don't flip. Deciding what mirrors and what doesn't is design judgement, and it's exactly where cheap localisation falls apart.
Mixed-direction text (the "bidi" problem)
Real Arabic sentences in a business app are rarely pure Arabic. They contain Latin brand names, email addresses, product codes, URLs and English loan words. When left-to-right fragments sit inside right-to-left sentences, the text engine has to resolve the direction of every run — and if the app doesn't handle this "bidirectional" (bidi) text explicitly, fragments visually scramble. A domain name can render with its parts flipped around the dots; a punctuation mark can jump to the wrong end of the line, producing sentences that end with an exclamation mark at the start. Users can't articulate what's wrong — it just reads as broken and unprofessional.
Numerals
Arabic text can use either Western digits (123) or Arabic-Indic digits (١٢٣), and the right choice depends on audience and context — UAE business documents commonly use Western digits even inside Arabic text. Either way, numbers read left-to-right even inside right-to-left sentences, which is another place naive implementations break. Prices, quantities and VAT amounts are the last things you want rendering ambiguously.
Fonts and text expansion
Arabic script is cursive by nature — letters connect and change shape by position — so it needs fonts designed for it, sized and spaced differently from Latin type. Arabic strings are also often longer or taller than their English equivalents, so buttons, table columns and labels that fit perfectly in English can overflow or truncate in Arabic. Good bilingual design budgets space for both from day one.
Common failure modes we see in the market
- Machine-translated UI. Raw machine translation of interface strings produces Arabic that native speakers instantly clock as foreign — wrong register, wrong terminology, sometimes outright nonsense on short labels like "Save" or "Clear," which are ambiguous without context.
- Alignment-only "RTL." Text is right-aligned but the layout still flows left-to-right: icons on the wrong side, forms reading backwards. It looks translated rather than designed.
- Broken bidi strings. Reference codes, package identifiers and URLs flipping mid-string, as described above. Especially painful on receipts, order numbers and support screens where users read values back over the phone.
- Numbers rendering wrong on printed output. Thermal receipt printers and PDF generators have their own text engines; totals that look fine on screen can come out reversed or garbled on paper. Printed output needs its own testing pass.
- Half-translated products. The main screens are Arabic but error messages, emails and notifications arrive in English. Inconsistency erodes trust faster than honest English-only.
Why receipts often stay English while the UI goes bilingual
Here's a nuance many owners don't expect: full bilingualism doesn't mean every artefact should be bilingual. In MidaOne, the staff interface is fully switchable between English and Arabic — but printed receipts stay English by default. That's a deliberate choice, and it's common across the market for practical reasons: thermal printers handle Latin text far more reliably than shaped Arabic script; receipts are tax documents where a single canonical rendering of amounts and VAT lines reduces FTA-compliance risk; and a mixed customer base is broadly comfortable reading an English receipt. The lesson: decide artefact by artefact. UI, notifications, marketing — bilingual. Legal and fiscal documents — often one canonical language, chosen deliberately.
A practical checklist for commissioning a bilingual app
- Say "bilingual with RTL" in the brief, on day one. Retrofitting RTL into a finished English app typically costs meaningfully more than building for it from the start.
- Ask to see previous Arabic work. Not mockups — a live product you can flip into Arabic and poke at. Check the back arrows, the forms, a screen with a mix of Arabic text and Latin codes.
- Insist on human review by a native speaker for all UI strings, especially short labels and error messages. Machine translation can draft; it cannot sign off.
- Specify numeral policy (Western vs Arabic-Indic digits) and where each applies — screens, reports, receipts.
- Decide the language policy per artefact: UI, emails, SMS/WhatsApp notifications, invoices, receipts, contracts. Bilingual customer messaging matters in a market where WhatsApp is the dominant business channel.
- Require every new feature to ship bilingual, not just the launch version — otherwise the Arabic side quietly rots with each release.
- Put printed output in the test plan explicitly — receipts, labels, PDF invoices.
This is also one of the stronger arguments in the custom vs off-the-shelf software decision: much imported off-the-shelf software treats Arabic as an afterthought, while software built for this region treats it as a first-class requirement.
How to test Arabic UX properly
Don't just glance at the Arabic mode — work in it. Have a native Arabic speaker complete real end-to-end tasks: place an order, issue a refund, read a report, recover from an error. Watch for truncated labels, icons on the wrong side, and any string containing an email address, code or brand name. Switch languages mid-session and confirm nothing resets or breaks. Print the receipts. Test on real devices, not just a designer's screen — font rendering differs across Android, iOS and thermal printers. And treat Arabic QA as a permanent line item, not a launch-week task.
Bilingual done properly is invisible: Arabic-preferring users simply feel the product was made for them. If you're planning an app for the UAE or wider GCC and want a team that has shipped full EN/AR with RTL in production, talk to us at HAANK — this is home turf for us.
FAQ
How much more does a bilingual Arabic/English app cost than English-only?
When planned from the start, the premium is typically modest — roughly 15–30% more in our experience, covering RTL design, translation, and bilingual QA. Retrofitting Arabic into a finished English-only app costs considerably more, because layouts, components and text handling all need rework. The cheapest path is simply to say "bilingual with RTL" in the original brief.
Can I just use machine translation for the Arabic interface?
Machine translation is a reasonable first draft, but it should never ship without native-speaker review. Short UI labels like "Save" or "Clear" are ambiguous without context, and raw machine output reads as foreign to Arabic users — which undermines the trust the Arabic mode was meant to build. Budget for a human review pass of every user-facing string.
Should my receipts and invoices be in Arabic too?
Not necessarily. Many UAE businesses run a bilingual interface but keep printed receipts and tax invoices in one canonical language, often English, because thermal printers handle Latin text more reliably and a single rendering of VAT lines simplifies FTA compliance. Decide deliberately per document type rather than assuming everything must be bilingual.
What is RTL and why does it matter beyond translation?
RTL means right-to-left — the direction Arabic is written. Supporting it properly means mirroring the entire layout (menus, arrows, forms, progress indicators), handling mixed-direction text like Latin brand names inside Arabic sentences, choosing a numeral style, and using fonts designed for Arabic script. Translation alone, without RTL work, produces an interface that visibly reads as broken to Arabic users.