Building Arabic-first, not Arabic-eventually

Most software that supports Arabic was built in English and mirrored afterwards. You can tell within about ten seconds of using it, and the tells are always the same: a back arrow pointing the wrong way, a chart whose axis reads backwards, a date field that only knows Gregorian, a phone number rendered right-to-left so the country code ends up at the wrong end.

None of those are translation problems. The words were translated fine. They are consequences of treating direction as a stylesheet rather than a property of the document.

Right-to-left is not a mirror

The intuitive model — flip everything — is wrong, and it is wrong in a way that produces confidently broken interfaces. Some things must flip. Some must not. Knowing which is most of the work.

The subtle one is mixed content. An Arabic sentence containing an English product name, or a price, or a file path, is the normal case rather than the exception — and getting it wrong produces text that is not merely ugly but genuinely ambiguous about where the number ends and the sentence resumes. The Unicode bidirectional algorithm handles most of it, but only if you let it: wrapping a number in a span with a hardcoded direction is how you break something that was working.

Dates are a product decision, not a format

Hijri dates are not a display preference. A Saudi HR system where leave is accrued by Hijri month and payroll runs on Gregorian is not doing conversion for decoration — the two calendars disagree about how many days are in a year, and that difference shows up in somebody's salary.

The rule that survives contact with reality: store one calendar, display both, and be explicit about which one any business rule uses. A field labelled just "date" in a system that serves both is a bug waiting for an audit to find it.

What changes when Arabic is first

The practical difference is where the burden falls. Build English-first and every Arabic screen is an exception someone has to remember to handle. Build Arabic-first and the harder case is the default, so the easier one is nearly free.

It also changes what you notice early. Arabic text runs roughly 20–25% shorter than English for the same meaning, then expands again in some UI strings. Layouts that were tuned to English labels break in both directions, and finding that in week one is considerably cheaper than finding it in the launch week.

Where CodeSky sits

Generated applications carry full RTL layouts rather than a mirroring stylesheet, with Hijri and Gregorian utilities and SAR formatting present from the first generation rather than added later. The enterprise templates assume it: Nafath-style identity, ZATCA-ready invoicing with 15% VAT, CR validation on vendor records.

That is not because those are hard to build. It is because they are easy to forget, and every one of them is discovered late by the same route — a customer asking why the invoice does not have what their accountant needs.

The test

Switch your product to Arabic and try to complete your most important flow — signup, checkout, whatever pays for the company. Not read it. Complete it.

If you hesitate anywhere, that hesitation is the gap between translated and built. Every Arabic-speaking user meets it on their first visit.