Mostafa Mohsen Abdelaziz examines four silent defects that undermine bilingual clinic booking forms for Arabic-speaking patients: reversed opening-hours ranges caused by Unicode bidirectional rendering, phone numbers lost to ASCII-only sanitisation, name validation that rejects Arabic script, and untranslated error messages. He sets out the technical causes and fixes, and a ten-minute test clinics can run on their own booking pages.
A patient asks an assistant for a paediatric dermatology appointment in Dubai on a Thursday evening. The assistant answers, names a clinic, and hands over a link. Getting to that point is what the structured-data and public-information work is for. What happens on the page that opens decides whether the clinic gets a booking, and for bilingual providers there is a class of fault living there that has no equivalent in the English flow.
These faults share a property that makes them expensive. They do not raise an error. Nothing appears in the application log and no support ticket is filed, because the patient who hits one does not know they have hit one. They see hours that make no sense, or a form that clears a field they filled in, and they leave. The clinic sees traffic and no conversion, and puts it down to price, or to the competitor two streets away.
Four are worth describing, because each has a specific cause and a specific fix.
The opening-hours range that reads backwards
An Arabic page sets its base direction to right-to-left. Inside that paragraph, a time range such as 09:00 to 17:00 is two runs of digits with a separator between them. The Unicode Bidirectional Algorithm resolves that separator according to the surrounding paragraph direction, so in a right-to-left paragraph the two numeric runs are laid out right to left. The visual result is 17:00 – 09:00. Neither number has changed in the database. Only the order in which they are painted has.
The separator decides it, and the detail is worth knowing, because it determines whether your own page is affected. A hyphen with a space on each side reverses the range, as does an en dash, as does the Arabic word إلى. A hyphen with no spaces does not, because the algorithm treats a separator sitting directly between two digits as part of a single number. The same reversal moves the Arabic morning and afternoon markers, so 9:00 ص to 5:00 م is painted with the afternoon time on the left.
An Arabic-reading patient sees a clinic that opens at five in the afternoon and closes at nine in the morning. Some read it as a mistake and try anyway. Others assume the clinic is shut and go elsewhere.
The fix is to isolate the range from its surroundings, not to reformat the string. Wrapping it in a bdi element, applying unicode-bidi: isolate with dir=”ltr”, or bracketing it with the Unicode isolate characters U+2066 and U+2069 all force the range to be laid out on its own terms. Reversing the string by hand appears to work on the page you tested it on, and breaks the moment a translator changes the separator.
The phone number that saves as nothing
Arabic keyboards on iOS and Android produce Arabic-Indic digits, U+0660 to U+0669. Persian and Urdu layouts produce the extended set at U+06F0 to U+06F9. To a reader these are digits. To most sanitising code they are not.
A very common line of cleanup strips anything that is not an ASCII digit before the number is stored. What that does next depends on the language the form is written in, and the two outcomes fail differently.
In JavaScript, \d means ASCII zero to nine and nothing else, so \D matches every Arabic-Indic digit and removes it. A patient who types ٠٧٩٥٠٦٣٣٢٦ submits ten digits and stores an empty string. In Python 3, \d is Unicode-aware and matches Arabic-Indic digits, so the same \D pattern leaves them untouched and the number is stored in a form the dialler and the SMS gateway cannot use. A character class written as [^0-9] empties the field in both languages.
Whether any of this is visible depends on the order of operations. If validation runs before sanitisation, the number passes validation and then disappears. If the column is nullable, the row saves anyway. The confirmation page says the appointment is booked. The clinic now has a booking with no way to reach the patient, and later records a no-show.
The fix has two halves. Normalise Arabic-Indic and extended Arabic-Indic digits to ASCII on input, before any validation or storage, and then validate the normalised value and reject an empty result loudly. Normalisation without the second half converts one silent data loss into another.
The name field that rejects Arabic
Name validation written against a Latin alphabet, /^[a-zA-Z\s’-]+$/ or something close to it, rejects every Arabic name presented to it. On a page whose error text is also missing an Arabic string, the patient is shown an English validation message under an Arabic label, telling them their own name is invalid.
A related failure is quieter. A maxlength chosen for a Western given name and surname truncates an Arabic full name, which conventionally carries the given name, the father’s name, the grandfather’s name and the family name. The record saves wrong, and the error only surfaces when a nurse cannot match the patient to their file.
Validate names by what you actually need to reject, not by an alphabet. If a length limit exists, it should be generous, and it should be tested against a real four-part name.
Error messages that fall back to English
Missing translation keys do not fail. Most internationalisation libraries return the key itself, or the English source string, when the Arabic value is absent. The page renders, the layout holds, and the only signal is a language switch in the middle of the form, usually on the exact strings that appear when something has already gone wrong.
This one compounds the other three. The patient is confused, and the sentence explaining why is in a language they may not read.
Why quality assurance does not catch any of this
An automated suite asserts on values, not on painted order, so the reversed hours range passes. A submission test that posts ASCII digits passes the phone case, because the fixture was written by someone typing on a Latin keyboard. A name fixture reading Test User passes the third. Translation coverage is usually measured as the percentage of keys holding a value, which counts a key holding an English string as covered.
All four are invisible to the machine and obvious to the person the page was built for.
A ten-minute test for your own booking page
You do not need your vendor for this. Use a phone rather than a desktop browser, with the site set to Arabic.
- Add an Arabic keyboard to the phone, then look at the opening hours block. Read the range out loud. If the closing time comes first, you have the bidirectional defect. If it reads correctly, check whether the separator has spaces around it before recording a pass: a tight hyphen hides the fault rather than fixing it, and the next translator to touch that string can expose it.
- Type the phone number using the Arabic keyboard, so the digits appear as ٠٧٩ and so on. Submit the form. Then find the record in your admin panel and look at the phone column. An empty value and a value still in Arabic-Indic digits are both failures. If you find either, assume you have been losing bookings for as long as the form has been live.
- Type a real four-part Arabic name into the name field and submit. Check whether it was rejected, and separately check whether it was truncated in storage.
- Submit the form with a required field left empty and read the error message. If it is in English, the key is missing.
- Repeat step two, and one other, against the confirmation email and any SMS the system sends. The same string handling runs there, and it is almost always a separate code path.
Ten minutes gets you a yes or a no on each. A yes on the phone field is worth escalating the same day.
The wider point
Discovery work assumes the destination holds. Publishing structured opening hours so an assistant can answer a patient’s question correctly is undone if those hours reverse themselves for the patient who follows the link. The integrity of a bilingual booking flow is a testable property of the page, and testing it costs less than explaining to a clinic manager why an Arabic-speaking market that found them did not book.
About Scaanme
Scaanme builds bilingual public-facing web systems for organisations in Jordan and the Gulf, including digital profiles, booking flows and Arabic and English patient-facing pages. www.scaanme.com
About the author
Mostafa Mohsen Abdelaziz is co-founder of Scaanme and is based in Amman. He works on Arabic and English booking and patient-facing web systems, and on the text handling, bidirectional layout and data-integrity problems that appear when the same form has to serve both languages.
