Arabic-First Learning Platforms: Past the Interface

Translating menus and buttons is a bounded piece of work that a vendor can complete without changing anything structural. The places where a platform reveals whether Arabic was designed in are all downstream of the interface: the question bank, the marking, the generated documents, and what a parent receives.

The generic engineering — encoding, mirrored layout, mixed-script text — is a subject of its own and applies to any bilingual system. What follows is specific to teaching.

The question bank is where it starts

A bilingual institution does not want two separate banks — it wants one question that exists in two languages, so a teacher can maintain the pair and a student sits it in their language of instruction. That is a data model decision, and a platform that only has one text field per question forces you into duplicate banks that drift apart within a term.

The consequences of getting it wrong show up in the reporting rather than the sitting. If the Arabic and English versions of a question are separate records, then item analysis, difficulty statistics and any attempt to compare cohorts treat them as different questions — and a teacher asking "did students struggle with this concept" gets two half-answers.

There is also a genuine pedagogical wrinkle worth naming: for some subjects the terminology is taught in English even when instruction is in Arabic. A question bank has to permit an Arabic question with an English technical term inside it, and marking has to accept an answer written in either. A system that enforces one language per attempt is imposing a rule the classroom does not follow.

Marking and feedback, which is where students notice

Feedback is the part of assessment that changes behaviour, and it is almost always free text written by a teacher under time pressure. That makes it the most demanding Arabic surface in the platform: a teacher typing a comment in Arabic must have it arrive intact in the student's view, in the parent's report, in the exported grade file and in whatever the platform prints.

Two failures recur. Rubrics and criterion descriptors are often configured once, in English, by an administrator — so a student marked against them sees Arabic feedback attached to English criteria. And automated feedback strings, the platform's own "correct" and "review this topic" messages, are frequently the last thing translated, which produces a report that is Arabic where a human wrote it and English where the system did.

Generated documents are where it breaks visibly

Hall tickets, transcripts, certificates, attendance letters and fee receipts are all produced by the platform rather than typed by a person, and they are the artefacts that leave the institution. A PDF pipeline that renders Arabic as boxes, or reverses a name, or breaks a ligature, produces a document a family keeps.

This is worth testing directly and early, because document generation is a separate code path from the web interface and it is routinely the last thing anyone checks. Generate a certificate for a student with a long Arabic name, print it, and look at it on paper — the same records a registrar has to defend are the ones that have to render correctly.

The parent is a different user with different needs

A parent may not share the student's language of instruction, and often reads Arabic where the child is taught partly in English. So the language of a progress report is not a property of the course — it is a property of the recipient, and a platform that ties report language to course language gets it wrong for a predictable share of families.

The related design point is register. A report written for a teacher's colleague, translated, produces Arabic that is technically accurate and unreadable to a parent — grade descriptors, attainment bands and pedagogical terminology that mean nothing outside the staff room. A report for a parent needs writing for a parent in both languages, which is a content decision rather than a translation task.