If your product is launching in Saudi Arabia or the wider Gulf, an Arabic version usually ends up on someone's task list as "send the strings to the translator". From the translator's side of the table, most delays and most bad Arabic UI text come from a handful of engineering decisions made before the first string was sent.

Here is what makes Arabic localization go smoothly, written from the translation side but aimed at developers.

1. Plurals: Arabic has six forms, not two

English has one and other. Arabic, according to the Unicode CLDR plural rules, uses six categories: zero, one, two, few, many and other. If your code builds sentences like count + " files", there is no correct Arabic translation for it.

Use ICU MessageFormat (or your framework's equivalent) and let the translator fill in every category:

{count, plural, zero {لا توجد ملفات} one {ملف واحد} two {ملفان} few {# ملفات} many {# ملفًا} other {# ملف} }

In JavaScript you can see which category the runtime picks for a given number:

const pr = new Intl.PluralRules('ar'); [0, 1, 2, 3, 11, 100].map(n => `${n}: ${pr.select(n)}`); // "0: zero", "1: one", "2: two", "3: few", "11: many", "100: other"

2. Never concatenate translated fragments

"Welcome, " + name + "! You have " + n + " new messages" forces the translator to translate three disconnected pieces and hope the word order works. Arabic word order and gender agreement often need the whole sentence. Send complete messages with named placeholders ({name}, {count}) and keep them together.

3. Give every string context

"Open" can be a button (a verb: افتح), a status (an adjective: مفتوح) or a shop's opening time. "Save" can be a button or "save 20%". A key like btn.open plus a one-line comment or a screenshot saves a round of questions and prevents the wrong form shipping. Gender matters too: if a string addresses the user directly, tell the translator whether a neutral form is required.

4. Right-to-left is a layout problem, not a translation problem

The translator delivers Arabic text. Whether it reads correctly depends on your markup and CSS:

  • Set dir="rtl" and lang="ar" on the root (or the relevant container), not just text-align: right.
  • Use logical CSS properties (margin-inline-start, padding-inline-end, inset-inline-start) instead of left/right, so the same stylesheet works in both directions.
  • Mirror directional icons (back/forward arrows, progress chevrons), but not icons that represent real objects or brands.
  • Wrap user-generated or mixed-direction values (names, emails, order numbers, Latin product names) in <bdi> or use unicode-bidi: isolate, so a phone number or an English product name inside an Arabic sentence does not scramble the punctuation around it.

5. Let text grow and use a real Arabic font

Arabic UI strings are often similar in length to English but can be noticeably taller and sometimes longer, especially in short labels. Avoid fixed-width buttons and truncated labels. Choose a font with proper Arabic glyphs and test diacritics and line height. Fallback system fonts can look very different on Android, iOS and Windows.

6. Dates, numbers and currency: format with Intl, don't translate

Do not put formatted dates or prices in translation files. Format them at runtime:

new Intl.DateTimeFormat('ar-SA-u-ca-islamic-umalqura', { dateStyle: 'long' }).format(new Date()); // Hijri (Umm al-Qura), e.g. "١٨ جمادى الأولى ١٤٤٨ هـ" new Intl.DateTimeFormat('ar-SA-u-ca-gregory', { dateStyle: 'long' }).format(new Date()); // Gregorian with Arabic month names, e.g. "٢٩ أكتوبر ٢٠٢٦" new Intl.NumberFormat('ar-SA', { style: 'currency', currency: 'SAR' }).format(1250);

Set the calendar explicitly with the -u-ca- extension: the default calendar for plain ar-SA is not the same in every browser and runtime version. Decide deliberately which calendar and which digits (Arabic-Indic ٠١٢٣ or Western 0123) your product shows, and apply that consistently. Official and financial documents in Saudi Arabia often carry both Hijri and Gregorian dates.

7. Send files the translator can work with

A structured export (JSON, XLIFF, .po, .strings, or a CSV with key, source, context and max-length columns) is far better than screenshots or a PDF of the UI. Lock placeholders and HTML tags so they cannot be translated by mistake, and include a glossary of product terms that must stay consistent across the app, the website and the help center.

8. Review in the running product

Translation in a spreadsheet is only half the job. Arabic must be reviewed in context: truncation, line breaks, mirrored layouts, and whether the tone fits a Saudi audience. Plan a short in-app review round before launch.

If you need the Arabic side handled professionally, this is the kind of work our website and app localization service covers (page in Arabic).

Disclosure: I work at Googan, a certified translation office in Riyadh (ISO 17100). This post is general guidance, not legal or regulatory advice.