There is a familiar way to make a business system bilingual: design it in English, then add Arabic at the end as a translation file and a switch that flips the layout. It works, more or less. Then the details begin to show. A name that cannot be found because it was saved in the other script. An arrow that points backwards. A number that reads in the wrong order inside an Arabic sentence. A voice line that only answers in one language.
None of these is a translation problem. They are design decisions that were never made. Arabic-first, not translated means making them from the start.
Equal, not secondary
The first decision is that both languages are first-class. In DONOR 360, the charity CRM ConsultTik builds and implements, Arabic and English are supported equally, with full right-to-left design. That is a stronger commitment than “we have an Arabic version”.
Right-to-left design is more than reversing the screen. The layout mirrors: navigation starts on the right, columns read from right to left, progress moves toward the left, and icons that indicate direction, such as arrows and chevrons, turn around with it. Just as important is what does not mirror: logos, phone numbers, email addresses, numbers inside tables, clocks and media controls keep their own direction. Getting both lists right is what makes an interface feel native rather than flipped.
Records that hold both scripts
The most practical test of a bilingual system is not the menu. It is the record.
People in the GCC are often known by the Arabic spelling of their name in one context and a Latin transliteration in another, and transliterations vary. A system that stores only one version forces staff to guess how someone was entered, and creates duplicates when they guess wrong. The DONOR 360 donor record holds a donor’s details in both Arabic and Latin script, so both forms of a name live on one record instead of on two.
The same thinking applies to any CRM or ERP that serves customers, suppliers or employees across the region: decide which fields need both scripts, and design search, duplicate checks and correspondence around that decision.
Every channel, both languages
Bilingual design does not stop at the screen. People reach an organisation through email, SMS, WhatsApp Business, calls, live chat, the web, social channels and at a branch, all of which the DONOR 360 omnichannel inbox brings into one place.
If one of those channels works in only one language, the experience breaks there. That is why the DONOR 360 AI voice agent speaks Arabic and English, discloses that it is virtual, and hands over to a person on request. Language choice belongs to the person calling, not to the system.
The details that decide adoption
Adoption is won or lost in small moments. A few of the decisions we make deliberately in bilingual work:
- Typography. Arabic needs its own type choices: more generous line height, no letter-spacing, no artificial italics and emphasis through weight. A Latin font with Arabic glyphs added as an afterthought is hard to read over a full working day.
- Mixed text. Product names, codes, email addresses and phone numbers often stay in Latin script inside Arabic sentences. They must be isolated so that punctuation and numbers keep their order.
- Numerals and dates. Decide once which digits and which calendar the system uses, and apply the decision everywhere, from forms to exports.
- Writing, not translating. Interface text and messages should be written in natural Modern Standard Arabic, structured for Arabic rather than following the English sentence word for word.
Each of these is small. Together they decide whether people feel the system was built for them or adapted for them.
Delivered in two languages
A bilingual system also needs a bilingual project. ConsultTik delivers in Arabic and English, so workshops, configuration decisions and training can happen in the language each team works in. That matters most at the moment that decides adoption: when people first use the system for their own work.
Where to start
If you are planning a new system or reviewing an existing one, three questions are a useful starting point:
- Which records need to hold both scripts, and how will people search them?
- Which channels do people use to reach you, and does each one work in both languages?
- Who writes your Arabic interface text and messages, and are they writing or translating?
The answers show quickly whether Arabic was designed in or added on. Designing it in from the start is far easier than closing the gaps after go-live.