Building Bilingual Arabic–English Software: What Most Teams Get Wrong
Arabic is not a translation of your English interface. It is a second design that happens to share your product’s logic. Teams that treat it as a late-stage string swap ship something that technically displays Arabic while feeling unmistakably second-hand to the people using it — and in Oman and the Gulf, those are usually the majority of your users. The differences are specific and fixable, but almost all of them are cheaper to handle before the first screen is built.
Key Takeaways
- Arabic support is a design decision, not a translation task. Retrofitting it costs several times more than planning for it.
- Not everything mirrors in right-to-left layout. Directional icons and progress flip; logos, media controls and charts with a time axis usually do not.
- Arabic needs its own typographic scale — larger effective size and more line height. Never synthesise bold or italic for Arabic.
- Search breaks unless you normalise alef variants, taa marbuta and diacritics. This is the most common invisible bug.
- Give each language its own URL and declare hreflang. A single URL that swaps language is invisible to search engines in one of your two markets.
Mistake 1: Treating Arabic as a late-stage string swap
The usual sequence is to build in English, extract the strings, translate them, and enable a right-to-left stylesheet. The result mostly works and consistently feels wrong.
Arabic text does not occupy the same space as English. Depending on the content it can run noticeably shorter in character count while needing more vertical room to stay readable. Layouts designed around English word lengths break in both directions: buttons that fitted “Submit” now hold a word that is too short to look deliberate, and headings tuned to a two-line English maximum spill to three.
Designing both languages from the start costs little. Retrofitting means revisiting every layout decision under constraints you did not have when you made them.
Mistake 2: Mirroring everything
Right-to-left layout is not a global horizontal flip. Some things mirror and some emphatically do not, and getting this wrong is the fastest way to look careless.
Mirror: page structure and reading order, navigation position, directional icons like back and forward arrows, progress indicators, and anything expressing sequence.
Do not mirror: your logo, photographs, media playback controls (play still points right by universal convention), clock faces, and most charts where the horizontal axis represents time. Mirroring a photograph of a storefront produces a backwards sign, and nobody thanks you for it.
Modern CSS makes the mechanical part far easier than it used to be — logical properties such as margin-inline-start replace left-and-right pairs, so one stylesheet serves both directions. The judgement calls remain yours.
Mistake 3: Typography borrowed from the Latin design
Arabic script has different proportions. At the same nominal font size it reads smaller, its letterforms connect, and it carries meaning below the baseline that cramped line spacing destroys.
Three rules cover most of it. Give Arabic a slightly larger effective size and noticeably more line height than the equivalent Latin text. Choose a typeface actually designed for Arabic rather than a Latin family with a bolted-on Arabic range. And never synthesise bold or italic — Arabic has no italic tradition, and browser-faked slanting looks broken rather than emphatic. Use a genuine heavier weight, colour, or size for emphasis.
Mistake 4: Getting numerals and dates wrong
Two numeral systems are in use: Western digits (0–9) and Arabic-Indic digits (٠–٩). Which is correct depends on audience and context, not on a universal rule. In much of the Gulf, Western digits are entirely normal in business software, and forcing Arabic-Indic digits on a finance screen can actively hinder people who read figures all day.
Decide deliberately, apply consistently, and make it configurable if your audience spans regions. Dates deserve the same care: some contexts expect Gregorian, some Hijri, some both. Store everything in a single unambiguous format and convert at display time — never store what the user happened to see.
Mistake 5: Ignoring mixed-direction text
Real Arabic business text contains English. Product names, model numbers, URLs, email addresses and phone numbers all appear inside Arabic sentences, and this is where bidirectional text quietly breaks.
The classic symptom is a phone number or a code rendering with its parts in the wrong order — visually scrambled although the stored data is perfectly correct. Users report it as “the number is wrong,” which sends developers hunting in the database for a display bug.
The fix is to mark the direction of embedded runs explicitly rather than hoping the algorithm infers it, and to test with realistic mixed content. Pure Arabic test data hides this class of bug completely.
Mistake 6: Search and sorting that quietly fail
This is the most common invisible defect in Arabic products, because nothing looks broken — results are simply missing.
Arabic has several forms of alef (أ, إ, آ, ا) that users type interchangeably. Taa marbuta (ة) and haa (ه) are frequently substituted at the end of words. Optional diacritics may or may not be present. Search for a customer typed one way and stored another, and you get nothing back.
Normalising text on both sides — unifying alef forms, stripping diacritics, handling taa marbuta — before indexing and before comparing solves most of it. Sorting needs the same attention: sorting Arabic with a default byte comparison produces an order no Arabic speaker recognises. Use a proper locale-aware collation.
Mistake 7: One URL for two languages
If your Arabic and English versions share a single URL and swap content with a toggle, search engines index one of them. You have effectively made your product invisible in one of your two markets.
Give each language its own address — /en/... and /ar/... is a clear, conventional pattern — and declare the relationship with hreflang so search engines serve the right version to the right user. Translate the parts that matter for discovery, not just the visible interface: page titles, meta descriptions, image alt text, and structured data. An Arabic page with English metadata competes for nothing.
A testing checklist worth running before launch
Test with real content, not placeholder text — long Arabic product names, Arabic addresses containing Latin building numbers, mixed-language customer notes. Check every form: input fields, validation messages, placeholder alignment, and date pickers are where right-to-left bugs concentrate. Verify search with the alef and taa marbuta variants a real user would type. Print or export a document from the Arabic interface, because PDF generation frequently has its own separate right-to-left problems. And have a native Arabic speaker complete an actual task rather than proofreading screenshots — awkward machine-flavoured phrasing is invisible in review and obvious in use.
Frequently asked questions
Can we launch English first and add Arabic later? You can, and it will cost more overall. If the timeline forces it, at least build with logical CSS properties, externalised strings, and per-language URLs from day one. Those three choices make the later addition an ordinary project rather than a rebuild.
Is machine translation good enough? For a first draft of long-form content, sometimes. For interface labels, error messages, and anything legal or financial, no — interface language is dense, context-dependent, and unforgiving. The cost of review is far lower than the cost of sounding foreign in your own market.
Does Arabic support hurt performance? Not meaningfully, if you load only the fonts each locale needs. The common mistake is shipping both full font families to every user regardless of language.
How do we handle users who mix both languages? Let them. Store user language preference separately from content language, allow content in either script in the same field, and never validate input as “Arabic only.”
The next step
If you are planning a bilingual product, decide three things before design begins: which numeral system your audience expects, how your URLs will separate the two languages, and who will review the Arabic as a user rather than a proofreader. Those three decisions prevent most of the expensive rework.
Building for an audience that reads both languages? ZAWAT builds genuinely bilingual products — this site included, along with client work like Al Jazeera Jewellery and the Specially4U learning platform. Request a call or explore our web development work.