Any contractor who has worked with a government authority or a local owner while also running an international consultant on the same job knows the problem: the bill of quantities gets requested in Arabic for the authority, in English for the consultant, and sometimes in both for a third party. The usual fix is one spreadsheet in one language and a second one translated by hand — and the two start drifting apart from the first edit that never makes it into the other copy. "Arabic support" in most construction software means a translated menu sitting on top of the same English core: the buttons read Arabic, but the data you actually type stays in whichever single language you happened to choose the moment you typed it.
Key takeaways
- Arabic and English are two separate, real fields on every line — not one field machine- or manually-translated afterwards.
- Right-to-left is built into the interface design itself, not a mirroring layer bolted onto an English layout.
- Reading direction is a per-user, per-session choice — one teammate can browse in Arabic while another browses in English, on the exact same data, at the same moment.
- Numerals, direction and borders follow "start/end" logic rather than fixed "left/right", so the same rule renders correctly both ways.
- The bill of quantities is where the difference shows up most clearly: one line, read by the local owner and the international consultant, each in their own language, with no parallel copy.
A translated menu is not bilingual software
A simple test exposes the difference: open a cost line a colleague entered in Arabic, then try reading it from an English-set account. In software that is "Arabic-supported" in the common sense, the settings menu and buttons are in English, but the line's own name is still Arabic-only — because the field it was typed into is a single field, in a single language, whichever one the author chose.
- A bill of quantities re-typed by hand into a second language drifts out of sync with the original the moment one edit does not get carried across.
- A bilingual team ends up with two files per document — a working copy in one language, a presentation copy in the other — and one of them is always going stale.
- An international consultant opens a "translated" report and finds an English interface wrapped around field notes that are entirely in Arabic, with no way to read them.
- A government authority requests an official Arabic document, and it gets manually rebuilt from an English original — repeated work on every revision.
What a "bilingual data model" actually means
The alternative is not a better translation — it is a different data structure. Every user-facing entity carries two real fields, not one: a name in Arabic and a name in English, a description in Arabic and a description in English — both stored, neither derived from the other automatically.
| Entity | Fields stored |
|---|---|
| Project name | Name in Arabic + name in English |
| Bill of quantities line | Description in Arabic + description in English, per line |
| Document title | Title in Arabic + title in English |
| Material name | Name in Arabic + name in English |
| Quality or safety checklist item | Item text in Arabic + item text in English |
Whoever enters this data — typically during project setup or when the bill of quantities is uploaded — fills both fields at once. The result is one record that reads correctly from any account, in either language, with no translation step afterwards and no second copy to keep updated by hand.
Right-to-left is not just a mirrored layout
Many products "support" Arabic by flipping an English layout horizontally: whatever sat on the left moves to the right. That works for plain text, but it breaks details nobody notices until they render wrong: a "next" arrow that should point left in Arabic instead of right, a phone number whose digits must never reverse order even though the sentence around it reads the other way, or a table border that stays in its old physical position instead of following the new start of the line.
| Common failure point | What native support requires |
|---|---|
| Directional icons (arrows, "next" chevrons) | Actually flip with reading direction — a "next" arrow points right in English and left in Arabic |
| Numerals inside an Arabic sentence | Stay left-to-right within the surrounding right-to-left text, with digit order never reversed |
| Spacing and side borders | Defined by "start/end" logic rather than fixed left/right, so one rule produces the correct side in both directions |
| A table's first, label-style column | Sits at the reading start automatically — the near edge in Arabic, the far edge in English |
One project, a team working in two languages at once
Interface language is a choice that belongs to each user, each session — not one setting for the whole project. One teammate can browse the project in Arabic while another browses it in English, at the same moment, on the exact same data — not two parallel copies, but two interfaces rendering one record.
This applies to structured data — line names, document titles, material names — because it is designed with two fields from the start. Free text — a note on a daily report, an RFI description — is written once, in whichever language its author uses, the same way a note between two colleagues would be. The difference is that everything around that note — labels, statuses, dates, numbers — renders in the reader's own language, so the only thing left to read across is the free text itself, not an entire interface layered on top of it.
Where the difference shows up most: the bill of quantities
The bill of quantities is the one document that puts the most language-diverse parties on a single page: a government authority or local owner reading Arabic, an international consultancy or contractor reading English, and both needing to agree on the exact same line, quantity and price with no ambiguity.
When every line carries an Arabic description and an English one from the moment it is entered, progress billing by percent complete, actual-versus-planned reconciliation, and exporting the schedule for external review all read the same line regardless of the language of whoever opens it. There is no "Arabic copy for submission" and "English copy for working" drifting apart over time — one record.
How this works in muqawil
Arabic and English in muqawil are both first-class citizens, not a base language with a translation layered on top. Every bill-of-quantities line, document and report carries its Arabic and English fields together, and the entire interface flips direction in one tap — lists, borders, spacing and directional icons, not text alone.
- Real Arabic and English fields on every user-facing entity — no machine translation applied afterwards.
- Right-to-left built into the interface design, not a mirrored layer on top of it.
- Every user picks their own language per session, on the same project, at the same moment.
- Runs as a progressive web app on any Android phone, in either language, with no app-store install.
Frequently asked questions
Is this an English product with a translated interface, or genuinely bilingual?
Genuinely bilingual. Every user-facing entity — a bill-of-quantities line, a document, a material — carries separate Arabic and English name/description fields, not one field that gets translated.
Can two teammates work in different languages at the same time?
Yes. Interface language is a per-user, per-session choice, so one can browse in Arabic and the other in English, on the same data, at the same moment.
Is the Arabic interface just flipped, or actually designed for it?
Actually designed for it. Directional icons genuinely flip with reading direction, while numerals and brand marks do not, and spacing and borders follow start/end logic rather than fixed left/right.
What about a note written in only one language, like a daily report entry?
Free text — a daily report note or an RFI description — is written once, in whichever language its author uses, the same as any note between colleagues. What changes is that everything around it — labels, statuses, dates, numbers — renders in the reader's own language, leaving only the free text itself as single-language.
Does this work for a subcontractor who only reads English inside a project run in Arabic?
Yes. Each teammate's invitation language is chosen individually, and they can browse the project in English while your team runs it in Arabic, on the same underlying record.
Try the one-tap switch
Open any project in muqawil in Arabic, then switch to English from the same account — and see every line, date and number stay correct in both directions.