Most engineering guidance treats internationalization as 'wrap every string in a translation function' and stops there — but React Native's layout system has an entire orthogonal problem: whether the UI's structure itself reads left-to-right or right-to-left. An app translated into Arabic or Urdu with the layout untouched isn't a partially-localized app, it's a broken one — buttons in the wrong reading position, back arrows pointing the wrong direction, and a text flow that fights the language it's supposedly written in.
This lesson treats i18n text and RTL layout as two separate problems, because a team can nail translated strings and still ship a UI unusable for a right-to-left reader, or flip layout direction correctly while shipping poorly pluralized, badly formatted strings elsewhere.
Getting this right matters commercially, not just ethically: RTL languages cover a real, sizable share of the world's mobile users, and an app that visibly fights its own reading direction reads as untrustworthy or unfinished to exactly the audience it's trying to reach — this is not a nice-to-have layered on after a market launch, it's core UX for that market.
Analogy🏏Cricket
🏏 Think of it like cricket: When a broadcaster produces both an English-language feed and an Urdu-language feed of the same India-Pakistan match, translating the commentary is only half the job — the on-screen scoreboard graphic itself has a reading order, and a graphics team that swaps English words for Urdu words but leaves the run-rate, overs, and required-rate boxes arranged left-to-right has produced something an Urdu reader has to fight, because Urdu script itself reads right-to-left and viewers expect the surrounding layout to match that flow. Getting the words right and getting the layout right are genuinely separate production tasks handled by separate teams — a translator swaps the language track, a graphics engineer restructures where each box sits on screen — and a broadcast that nails one while skipping the other looks unmistakably unfinished to the audience it was made for. Just as translating commentary without restructuring the scoreboard graphic leaves a mismatched broadcast, translating an app's strings without mirroring its layout leaves a mismatched UI. Just as the scoreboard's box order has to flip for a right-to-left audience while the actual data inside each box stays correct either way, a screen's flexDirection and text alignment have to flip for RTL locales while the underlying logic stays identical. The insight is that internationalization has two independent axes — what the words say, and which direction the whole frame reads — and a product is only actually localized when both are handled, not when either one is.
🏏 Showing the Cricket analogy — a Cricket version isn’t available for this concept yet.