A school in Casablanca teaches in French and Arabic, reports to parents who may prefer either, and files with authorities in Arabic. A school in Dubai runs a British curriculum in English with Arabic as a core subject, and its parent body speaks a dozen languages between them. For both, "does your software support Arabic?" is the wrong question, because the answer is almost always yes, and the answer is almost always insufficient.
The useful question is what happens after the interface is translated, and that is where products built for a single language quietly fall apart.
Right-to-left is not a text direction setting. In a properly mirrored interface, the entire layout reflects: navigation moves to the right, tables read right to left, progress indicators run the other way, icons that imply direction flip, and the sidebar changes side. Products that treat RTL as a font-rendering concern produce screens where the text is Arabic and the layout is still English — technically readable, and immediately identifiable to an Arabic-speaking user as an afterthought. It undermines confidence in the entire product, fairly.
Mixed content within a single field is the next thing that breaks. A student name in Arabic, a class code in Latin characters, a date, a phone number with a plus sign. Each fragment has its own directional behaviour, and getting the sequence right requires the software to handle bidirectional text properly rather than assume a single direction per field. When it is wrong, the phone number displays with the plus sign in the wrong place and the parent cannot tell whether it is their number.
Then there is data that exists in two scripts simultaneously. A student has a legal name in Arabic for official documents and a transliterated name in Latin script for the English-medium report card. These are the same student and both names are correct. Software that provides one name field forces the school to choose, and the choice will be wrong for one of the two required outputs. Search compounds it: staff will look for the student by either name, and both need to find them.
Language preference belongs to the family, not the interface. This is the point most products miss entirely. A school might operate in English internally while one parent wants messages in Arabic and another in French — and they are parents at the same school, sometimes of the same child. The preference has to live on the guardian record and drive every outbound message automatically. If sending a bilingual parent body an absence notification requires an administrator to split the list and write two versions, the automation is not real and staff will fall back to sending everything in one language.
Documents are where it gets genuinely demanding. Report cards, invoices and transcripts often need to exist in more than one language, sometimes in the same document, with correct typography in both and a layout that does not break when Arabic text is longer or shorter than the English it replaces. A PDF generator that only lays out left-to-right will produce documents that are subtly wrong in ways parents notice and schools are embarrassed by.
Two smaller things that cause real problems. Dates: a school may need Gregorian and Hijri, and formats differ by locale. And sorting: alphabetical order in Arabic is not the Latin alphabet with different characters, so a class list sorted by an English-language collation is not sorted at all from an Arabic reader’s perspective.
The reason so few products handle this well is architectural rather than lazy. Adding a second language to software that assumed one is genuinely hard — the layout assumptions, the string handling, the document generation and the data model all have to change together. It is much easier to build for multiple languages from the beginning than to retrofit, which is why the products that do it properly tend to be the ones that had to from day one.
For schools evaluating, three questions cut through quickly. Ask to see the interface in Arabic on a screen with a table and a sidebar, and look at whether the layout mirrored or only the text changed. Ask how a parent’s language preference is set and whether outbound messages use it automatically. And ask to see a report card generated in Arabic — not a mockup, a real generated document. That last one fails more often than any other.
Skoolia was built across English, French and Arabic from the start rather than translated afterwards: full RTL layout mirroring, language preference held on the guardian record so communications go out in each family’s language automatically, and document generation that lays out correctly in all three. It is one of the harder parts of the platform to maintain, and it is the reason schools across North Africa, the Gulf and Europe can run on the same system.
Translating the interface is the visible ten percent of the work. The other ninety is what a parent notices when the message arrives in the wrong language, or the report card renders wrongly, or their own child’s name appears in a script they cannot read.