Across the GCC and the wider Arab world, an app or website often needs to speak to customers in English and Arabic, and in Lebanon sometimes French as well. Adding Arabic is not just translating strings. Arabic reads right to left, so the whole interface has to mirror, and a lot of small details decide whether the result feels native or feels like an English app with Arabic pasted in.
I built Pro Clean+ to work in English or Arabic, and these are the lessons I apply to every bilingual project.
Decide on day one
The most expensive way to add Arabic is after launch. Retrofitting right-to-left (RTL) support means revisiting every screen, every margin, every icon and every component that assumed text flows left to right. If there is any chance you will need Arabic, design and build for both directions from the start, even if Arabic content ships later.
Use logical layout, not left and right
The foundation of RTL support is to stop thinking in left and right and start thinking in start and end.
On the web, CSS logical properties do this for you: margin-inline-start instead of margin-left, padding-inline-end instead of padding-right, inset-inline-start instead of left, text-align: start instead of text-align: left. Set dir="rtl" and lang="ar" on the html element for Arabic pages, and Flexbox and Grid follow the direction automatically. Tailwind supports logical utilities and rtl: variants for the few cases that need explicit overrides.
In React Native, I18nManager controls the direction, and styles using start and end (marginStart, paddingEnd) flip correctly. Switching direction at runtime requires an app reload, so plan the language switch flow around that. Many apps ask for the language once at onboarding and allow changing it in settings with a restart.
Hard-coded left and right values are the most common source of broken Arabic layouts. A quick search for left and right in a codebase tells you how much work a retrofit will be.
Mirror the right things, and only those
When the layout mirrors, some things should flip and others must not.
Flip: back and forward arrows, chevrons in lists, progress direction, sliders, the position of navigation drawers, icons that imply direction like "reply" or "send".
Do not flip: logos, media playback controls (play is a universal symbol), clocks, checkmarks, phone and charts with a time axis unless you have thought it through, and any icon that represents a real-world object which does not have a direction.
Go through your icon set once and mark each icon as "mirror" or "keep". Then it is a mechanical rule, not a judgment call on every screen.
Choose Arabic fonts deliberately
Your English brand font almost certainly has no Arabic glyphs, so the system falls back to a default font that may clash with the design. Pick an Arabic typeface that pairs with your Latin font in weight and feel, and load it explicitly.
Arabic text usually needs a slightly larger size or more line height than Latin text at the same nominal size to stay readable, because of its shapes and the dots and marks above and below letters. Test real paragraphs, not single words, and check that tall characters are not clipped in buttons and inputs with fixed heights.
Numbers, dates and currency
Decide which digits you show. Many apps in the region use Western digits (0 to 9) in both languages, because customers are used to them for prices and phone numbers. Others prefer Arabic-Indic digits in Arabic mode. Either can be right; consistency is what matters. Use the platform's internationalization APIs (Intl in JavaScript) to format numbers, dates and currencies rather than building strings by hand.
Dates need care. Month names, the order of day and month, and relative phrases ("in 2 hours") all change between languages. Prices may be shown in the local currency, US dollars or both, depending on the business and the market. Make the currency explicit everywhere, in both languages.
Mixed-direction text
Real content mixes directions constantly: an Arabic sentence containing a brand name in English, an email address, a phone number or a price. The Unicode bidirectional algorithm handles most cases, but punctuation and numbers at the edges of a string can end up in surprising places.
Practical rules:
- Wrap user-generated or mixed content in elements with
dir="auto"on the web so the browser detects the direction from the content. - Keep phone numbers, emails and codes in left-to-right containers, even inside Arabic text.
- Use Unicode isolation (
<bdi>on the web) for values you insert into a translated sentence, such as names. - Test forms: input fields for emails and phone numbers should stay left to right while the label is in Arabic.
Translation is content work, not developer work
Arabic copy should be written or reviewed by someone who writes Arabic well for your audience. Literal translation of English UI text often reads oddly. Short buttons, friendly error messages and clear labels matter more than perfect formality.
Keep all strings in translation files, never in the code. Use keys that describe meaning (booking.confirmButton) rather than the English text. Handle plurals with the internationalization library, because Arabic has more plural forms than English, and a hand-rolled "if count is 1" will be wrong.
Give translators context: a screenshot or a note on where the string appears and how long it can be.
Layouts must tolerate different text lengths
The same message can be noticeably shorter or longer in Arabic than in English. Buttons, tabs, cards and table headers must handle both without truncating or overflowing. Avoid fixed widths on anything containing text, and test the longest strings in both languages.
SEO for bilingual websites
For websites, each language should have its own URL (for example /en/ and /ar/), with hreflang tags linking the versions and a correct lang and dir on each page. Do not switch language only through JavaScript on a single URL, because search engines will index only one version. Translate titles and meta descriptions too, not just the body. There is more on this in SEO basics for local businesses.
Testing checklist
Before release, go through every screen in Arabic and check:
- Layout mirrored, nothing stuck to the wrong side.
- Directional icons flipped, others untouched.
- No clipped or overlapping text.
- Numbers, dates and prices formatted consistently.
- Forms: email, phone and code fields left to right.
- Notifications, emails and SMS messages also translated.
- Error messages from the server translated, not only the app's own text.
That last one is often forgotten. If your backend returns error text, it needs to know the user's language too, or return codes the app translates.
The payoff
A properly bilingual product feels respectful to users. For many customers, from Beirut to Riyadh and Dubai, being able to use an app in Arabic, or switch freely between Arabic and English, is the difference between trusting it and abandoning it. Done from the start, it is a manageable amount of extra work.
If you are planning a bilingual app or website, have a look at my work and get in touch.