Arabic from day one is not the same as Arabic on day 90
Why we wrote every component with CSS Logical Properties and never owned a single LTR-flip stylesheet.
Most software in the GCC ships English first, then “adds Arabic later”. The result is well-documented: a separate AR stylesheet, mirror-flipped components that break in clever ways, and a long tail of “this dialog overflows in RTL” tickets that nobody ever closes.
Reqdesk decided to ship bilingual on day one. Not because we are particularly noble, but because we knew what the alternative would cost.
What that meant in practice
Every margin became margin-inline-start. Every left: became inset-inline-start:. Every flex direction became logical, not physical. The CSS specification has the right primitives — they have just been ignored by the SaaS world for fifteen years.
What we got back
- One stylesheet, two locales. Switching to AR flips the entire app natively. No second build, no second QA pass, no surprise icon mirrors.
- A single design system. The brand tokens have one set of spacing values, not “left padding” and “right padding”. Designers think in terms of “start” and “end”, which matches the way they were already designing for both.
- No LTR-only assumptions in JS. Code that calculates positions reads from the same logical-property values the CSS does. There is no
if (locale === 'ar') { /* mirror */ }anywhere.
What it cost
Mostly attention. The browser support is excellent (every shipping browser since 2022). The hard part was unlearning fifteen years of margin-left: 16px muscle memory.
The lesson, if there is one
Bilingual support is a build-time decision, not a runtime feature. Make it on day one or pay it back ten times in v2.