nestonexDesigning bilingual products for Arabic and English without doubling the cost
A second language is usually estimated as translation and delivered as a rebuild. The gap is right-to-left layout, which touches the design system rather than the copy, and which is dramatically cheaper to build in than to add.
Build direction-awareness into the layout system from the start: logical properties instead of left and right, mirrored icons and navigation, a font stack that carries both scripts, and content that expands. Translation is the cheap part. The expensive part is an interface that assumed one direction in a thousand small places.
What right-to-left actually mirrors
The whole interface, not just the text. Reading order, navigation position, the direction of back and forward, progress bars, carousels, sliders, breadcrumbs, and the side a drawer opens from. A right-to-left user reading a left-to-right layout is doing constant translation work.
What does not mirror: numbers, which stay left to right, and media controls, which follow the timeline rather than the reading direction. Getting these backwards is the most common mistake in a retrofit, and it looks broken rather than merely unfamiliar.
Icons are a category of their own. Directional ones flip, literal ones do not. An arrow flips; a clock does not; a magnifying glass does not; a reply arrow does. There is no rule that decides them all, which is why they need auditing once rather than guessing every time.
Mixed content is where it gets genuinely hard. An Arabic sentence containing a Latin brand name or a URL needs bidirectional handling, and browsers do most of it correctly only if you have not fought them with manual alignment.
- Layout, navigation and directional controls mirror
- Numbers and media timelines do not
- Directional icons flip; literal ones do not
- Mixed-script text needs bidirectional handling, not manual alignment
What makes it cheap
Logical properties. Write margin-inline-start rather than margin-left, and the layout mirrors when the document direction changes. This single habit removes most of the retrofit cost, and it costs nothing to adopt on day one.
One direction attribute at the root, with everything downstream deriving from it. Direction as a per-component prop is a source of permanent bugs, because somebody will forget one.
A design system that expresses spacing and alignment in tokens rather than in hard-coded sides. If a component encodes left and right directly, every instance of it is a place to fix later.
And type that carries both scripts. Arabic needs different line height and often a different family, so a font stack chosen only for Latin will look wrong at best and be hard to read at worst.
Content is not the same length
Translated text expands and contracts, often by twenty to thirty percent in either direction, and interfaces designed around a fixed English string break in both. Buttons that were sized to their label, tabs that fit exactly, and single-line headings are the usual casualties.
Dates, numbers, currencies and pluralisation follow locale rules rather than translation. A locale library handles this; hand-written formatting becomes a permanent source of small wrongnesses.
Pluralisation in particular does not map. Arabic has more plural forms than English, so a component built on a singular-or-plural assumption produces text that is simply incorrect.
And translation needs context. A string extracted without knowing whether it is a button, a heading or an error message gets translated as one of the other two.
Testing both directions properly
Both directions belong in review from the first component, not at the end. A layout bug found in the second language after the interface is built is a structural fix; found during the build it is a one-line change.
Pseudo-localisation helps before real translations arrive: render strings expanded and reversed to surface fixed-width assumptions and hard-coded alignment early.
Native review is not optional for anything customer-facing. Machine translation produces text that is grammatically plausible and culturally wrong, and in a product that handles money the difference matters.
And test the mixed cases specifically: an Arabic interface with a Latin brand name, a phone number, a URL, and a currency amount in the same sentence.
How this looked on a real product
One Click is a match-day travel product for Saudi Arabia, bundling match tickets, flights, transfers and hotels into a single checkout priced in SAR. It was designed bilingual from the start, with right-to-left-aware layouts, swappable visual themes and OTP authentication rather than passwords.
Designing for both directions from the beginning is what made the second language a configuration rather than a project. The design system carried direction; individual screens did not have to know about it.
The phone number is worth noting as a design decision rather than a field. For a travel product, it is not an account detail — it is how someone gets reached when a booking changes, which is why verification runs through it.
Questions people also ask
How much does adding Arabic cost?
If direction-awareness was built in, it is translation, font work, review and testing. If it was not, it is a layout rework touching most components, and that is routinely several times the translation cost. The decision that sets the price is made at the start of the build, not when the second language is requested.
Do you need separate designs for each direction?
No. One design system that expresses spacing and alignment logically produces both. What you need separately is review of both directions and a decision about which icons mirror, which is an audit rather than a second design.
Does right-to-left affect SEO?
It affects internationalisation markup rather than layout. Each language version needs its own indexable URL with the correct language attribute and reciprocal alternate links. A language toggle that swaps content without changing the URL gives search engines one page where you meant to have two.
Can machine translation be used?
For internal tooling and first drafts, reasonably. For anything customer-facing in a product that handles money, native review is necessary — machine output is grammatically plausible and culturally wrong often enough to cost you trust at exactly the wrong moment.