RTL is not a feature, it's a posture

Most 'RTL support' I see in production is a CSS direction: rtl rule and a prayer. The layout flips, the icons move, and the team checks the box. Then Arabic users show up, and the experience is subtly wrong: numbers read backwards, time formats ignore the locale, animations slide the wrong way, and the typography — even with the right font — feels like a translation rather than a native voice.

Real RTL support starts with typography. Arabic has its own rhythm — it's a connected script, not a sequence of letters. Most Latin fonts are designed for vertical rhythm; Arabic needs horizontal flow. The default line-height that works for Latin is too tight for Arabic. The default letter-spacing that's invisible in Latin breaks Arabic ligatures. If you're using the same typography rules for both, your Arabic is harder to read than it should be.

Then there are numbers. Arabic speakers use Western Arabic numerals (1, 2, 3) in most contexts, Eastern Arabic numerals (١, ٢, ٣) in others. The right choice depends on the dialect, the formality, and the audience. Hardcoding either is wrong. Use Intl.NumberFormat with the right locale and let the platform decide.

Dates and times are worse. Most apps default to US formats (MM/DD/YYYY, 12-hour clock) regardless of locale. Arabic-speaking users in Egypt expect DD/MM/YYYY and 24-hour clock. Users in Saudi Arabia might expect Hijri dates alongside Gregorian. The Intl API handles all of this — use it.

But the deepest issue is posture. If you're treating Arabic as an afterthought — added at the end, translated from English, designed by someone who doesn't read Arabic — your Arabic users will feel it. The interactions will feel Latin-first. The copy will feel translated. The whole experience will feel like a courtesy rather than a native home. RTL isn't a feature you ship. It's a posture you take — that Arabic users are first-class users, not an afterthought.