Many systems reach Arabic-speaking users after only their text has been translated: the words are Arabic, but the menu is still where it was, the arrows point the wrong way, and numbers and Latin-script product names jump around inside sentences. Users feel the system wasn’t made for them, and they hesitate before every click.
A translated interface isn’t an Arabic interface. An Arabic interface is designed from the start on the understanding that reading begins on the right, that Arabic text will be mixed with Latin-script text and numbers, and that Arabic words have lengths and shapes that differ from English ones. In this article, we bring together the details we review in every Arabic interface we build.
Mirror the whole layout, not just the text
When a page runs right to left, the layout must mirror with it: the sidebar moves to the right, the column order starts from the right, and the “Next” button sits on the left, because reading moves toward the left. The same goes for the step indicator in long forms: the first step is at the far right.
On the web, this starts with setting the direction in the page content itself: the dir attribute with the value rtl on the root element, together with the language attribute. The World Wide Web Consortium’s guidelines recommend setting direction in the HTML markup rather than in CSS, because it’s part of the content’s meaning, so it stays correct even if the styles don’t load.
Then come CSS logical properties, which describe margins and positions in terms of start and end instead of right and left. A margin at the start of the line falls on the right on an Arabic page and on the left on an English page, with the same rule. Android apps follow the same principle: start and end instead of left and right.
Icons that indicate direction
Not every icon is mirrored. Icons that indicate movement or direction, such as back and forward arrows, are mirrored with the page direction. An icon whose meaning changes when it’s flipped, such as a logo, stays as it is or needs a version of its own.
Android can mirror simple icons automatically, and it notes that a complex icon, or one whose meaning changes when mirrored, needs manual handling. The same rule works on any platform: a written decision for each icon, not blanket mirroring of every image.
Mixed text and numbers inside an Arabic sentence
A sentence in a business system is rarely pure Arabic. It contains a product name in Latin letters, an item code, a phone number, and an email address. The browser orders these pieces using the Unicode Bidirectional Algorithm: Arabic letters run right to left, while Latin letters and numbers run left to right.
The problem shows up at the boundaries between the two directions, especially with spaces and punctuation marks, which have no direction of their own. A period, a comma, or the plus sign in a phone number can move to the wrong end, so the number or code appears out of order. Android’s guidelines list text that begins with a number or a punctuation mark, such as an international phone number, among the cases that need handling.
The solution that the same consortium’s guidelines recommend is to wrap each run of opposite-direction text in an element that sets its direction. When the direction of the text isn’t known in advance, such as a name a user types or a value from the database, the bdi element or the auto value of the dir attribute is used, and the browser works out the direction from the first character with a clear direction. In practice, we apply this as follows:
- Phone numbers are always displayed left to right, inside an element with a set direction.
- Email addresses, links, and item codes are isolated in a left-to-right run.
- Customer and product names that users enter are displayed in a direction inferred from their content.
- No text inserted into a translated message is left without its direction isolated.
Users don’t notice a good Arabic interface, because nothing in it makes them stop at a reversed arrow or a scattered number.
Numbers and dates: decisions written down in advance
Numbers in an Arabic interface need an explicit decision: are they shown in Western digits or in Eastern Arabic digits, and what are the thousands separator and the decimal separator? This isn’t a technical detail; it’s a choice that depends on the system’s audience and their reading habits.
In JavaScript, Intl.NumberFormat picks the default numbering system based on the language and lets you set it explicitly. Intl.DateTimeFormat orders the day, month, and year based on the language and region, and lets you choose the calendar, Gregorian or Hijri (the Islamic calendar). That’s why we set these options in one place in the system and don’t leave them to each device’s default settings.
Suppose a system shows dates in an order that varies from one screen to another. An employee will read a date as day then month when it’s month then day, and get a delivery date or an invoice due date wrong. One written decision prevents this error across all screens and reports.
Fonts, line height, and text length
Arabic type isn’t a copy of Latin type. The letters connect, some of them drop below the line, and the dots and vowel marks need space above and below the letters. That’s why we choose a typeface designed for Arabic, give it a line height with room for all this, and test it in the weights we’ll actually use.
A common mistake is applying letter spacing to Arabic text, copying a style designed for English headings. MDN points out that Arabic script expects its letters to stay connected, and that letter spacing can make the text look broken.
Text length also changes after translation: a button with room for a short English word may be too narrow for its Arabic equivalent. Microsoft recommends not fixing widths and heights in the interface, and letting elements grow with their content.
Forms, tables, and reports
Forms
In an Arabic form, the label sits on the right and input starts from the right. But some fields are Latin by nature: email, phone number, and account number. We display these fields left to right so users see what they type in the correct order.
Free-text fields, such as notes and names, take the auto value, so their direction follows what the user types. The dirname attribute can send the text’s direction to the server along with its value, so it’s displayed later as it was written. Validation messages are written in clear Arabic that says what’s needed, not as a technical error code.
Tables and reports
An Arabic table starts from the right: the first column is the identifier or the name, and reading moves toward the left. Numeric columns are aligned in one consistent way so values are easy to compare. Printed or exported reports need the same testing, because they’re often produced by a different tool from the one that renders the interface.
Testing with real Arabic content
Latin dummy text doesn’t reveal the problems of an Arabic interface. That’s why we test with long Arabic names, headings that run to two lines, sentences containing Latin names and phone numbers, large monetary values, and complete error messages.
We also try the interface on a narrow mobile screen, where lines break and problems show up early. On Android, you can force the right-to-left direction from the developer options, to see the interface mirrored before its text is translated.
A checklist for an Arabic interface
- Direction is set in the code at page level, along with the content language.
- Margins and positions are written as start and end, not right and left.
- Icons that indicate direction are mirrored, and the rest stay as they are.
- Phone numbers, email addresses, and codes have their direction isolated and read correctly.
- The numbering system, date format, and calendar are one written decision.
- The typeface is designed for Arabic, the line height leaves room for dots and vowel marks, and there’s no letter spacing.
- Latin fields are displayed left to right, and free text follows what the user types.
- Validation messages are in clear Arabic.
- Testing was done with real Arabic content and on a narrow mobile screen.
An Arabic interface isn’t achieved through translation at the end of the project, but through decisions made from its start: direction, mixed text, numbers, and fonts. The later these decisions come, the more screens have to be revisited.
If you are planning a platform or system for Arabic-speaking users, you can discuss your situation with the ITS team, so that together we can review your current interface or plan an Arabic interface from the start.
Related serviceSaaS platforms