Arabic, English, and everything in between

A clinic inbox in Cairo, Riyadh or Dubai contains at least four registers, often within a single thread: Modern Standard Arabic, dialect, English, and Franco-Arabic — Arabic typed in Latin characters with digits standing in for sounds that have no Latin letter, as in “3ayza a3rf el s3r”. Patients move between them without noticing, and expect the clinic to keep up.

Most automated messaging handles this badly in ways that are obvious to the patient and invisible on a dashboard. Here is where it breaks.

Detect per message, not per conversation

The common implementation detects language once, on the first message, and uses it for the thread. Real conversations do not behave that way. A patient opens in English because your bio is in English, switches to Arabic once they are asking something they care about, and drops back into English for the treatment name.

Detect on every inbound message and mirror it. If the patient wrote in Arabic, reply in Arabic. If they wrote Franco-Arabic, reply in Arabic script — that is what the convention expects, and replying in Franco reads as mockery.

The terminology problem

This is the failure that costs bookings and is hardest to see from inside. Patients do not use clinical terms, and they do not use the same non-clinical terms in both languages.

A knowledge card that describes “fractional CO₂ laser resurfacing” retrieves poorly against a patient asking about “الليزر الكربوني” or “co2” or the brand name their friend mentioned. The card is correct and useless. Retrieval matches on the words that are present, and the words patients type are not the words your marketing team wrote.

• Each treatment card lists the terms patients actually use — Arabic, English, transliterations, brand names and common misspellings.
• Harvest those terms from your own inbox rather than inventing them; three months of DMs contains the real vocabulary.
• Include dialect variants for the markets you serve; Egyptian and Gulf patients do not use identical words for the same treatment.
• Review this list quarterly. Patient vocabulary follows whatever went viral, and it moves.

Do not machine-translate clinical content at answer time

The tempting architecture is one set of English cards, translated to Arabic on the fly. It is cheaper and it is wrong for aftercare and preparation instructions, for a reason that has nothing to do with translation quality: nobody reviewed the Arabic.

A translated aftercare instruction is a clinical document your clinicians have never read, generated fresh for each patient, unreproducible. If a patient later says they were told to do something, you cannot show what was sent without pulling the exact message — and even then, no clinician approved that wording in advance.

Write the Arabic card as a card. Have a clinician read it. Treat both language versions as first-class content with the same review cycle — see building a knowledge base an AI can actually answer from.

Voice notes and dialect

A significant share of WhatsApp enquiries in the region arrive as voice notes, in dialect, often recorded in a noisy place. Transcription of Gulf and Egyptian dialects is meaningfully harder than of Modern Standard Arabic, and the errors are not random — treatment names, numbers and negations are among the most fragile.

Three defences, in order of importance:

1. 01Treat a low-confidence transcript as an escalation trigger, not as text to answer. A misheard negation reverses the meaning of an aftercare question.
2. 02Never act on a transcript for anything transactional. Booking, cancelling or confirming from a voice note should be read back in text and confirmed before it takes effect.
3. 03Keep the original audio attached to the conversation. When staff pick up an escalation, they should be able to listen rather than trust the transcription.

Right-to-left is not only a text direction

If your staff dashboard renders Arabic threads in a left-to-right layout, your team reads them slowly and misreads numbers. Mixed-direction text — an Arabic sentence containing an English treatment name and a Latin-digit price — is where rendering breaks most visibly, and where a misread price becomes a wrong quote.

Check this on real messages before launch, not on sample text: the direction of mixed strings, the placement of punctuation, and whether Arabic-Indic and Latin digits both display correctly in the same line.

What good looks like

A patient should not be able to tell which language the system “prefers”. They write how they write, the reply comes back in the same register, the treatment they named is the treatment that was priced, and if a voice note was unclear a person picks it up rather than software guessing. None of that is achieved by a language setting. It is achieved by per-message detection, a bilingual knowledge base, and an escalation rule that treats uncertainty as uncertainty.