Design Systems for Arabic and English Products: Tokens, Mirroring and Governance

A design system for Arabic and English products needs three things a single-language system does not: direction-aware tokens, components that mirror by rule rather than by hand, and governance that treats Arabic as a first-class language instead of a translation pass. Build those in from the beginning and a bilingual product stops being two products to maintain. This is how we structure a bilingual design system for teams in Saudi Arabia, the UAE, Lebanon and the wider GCC.

Why a bilingual design system is different

Most design systems are built in English and then made to work in Arabic. The result is familiar to anyone who has used a Gulf banking app or a government portal in Arabic: icons pointing the wrong way, truncated labels, numerals drifting out of order, and typography that looks like an afterthought because it was one.

The root cause is structural. If left and right are hard-coded into the components, every Arabic screen becomes a manual exception. If type scales are tuned for Latin letterforms, Arabic will be either too small to read or too large for the layout. If the documentation shows only English examples, designers and developers will build for English and discover the Arabic problems in QA, where they are expensive.

A bilingual design system reverses that order. Direction, language and script become inputs to the system, not variations bolted onto it.

RTL design tokens: build direction into the foundations

Tokens are where bilingual support either succeeds or fails. The principle is simple: no token should name a physical side.

• Spacing and layout. Replace left and right with start and end. Logical properties such as padding-inline-start and margin-inline-end resolve correctly in both directions without overrides; grid and flex definitions should use them throughout.
• Iconography. Mark each icon with a direction flag. Arrows, chevrons, back buttons, progress indicators and anything implying reading order are mirrored; icons depicting real objects, such as a clock or a phone, and brand marks are not. Store that flag as a token so mirroring is applied once, in code, not screen by screen.
• Typography tokens. Define separate font-family, size, line-height and letter-spacing tokens for Arabic and Latin scripts, and alias them under one semantic name so a component asks for heading-lg and receives the right values for the active language. Arabic generally needs a larger size and more line-height at the same visual weight, and letter-spacing should stay at its default because connected letterforms break when tracked.
• Numerals and dates. Decide once whether the product uses Western or Eastern Arabic numerals and whether dates follow the Gregorian or Hijri calendar, then encode the decision as a token so it is not re-litigated on every screen.
• Motion. Transitions that imply direction, such as a page sliding in from one side, should be defined relative to the reading direction so navigation feels like moving forward in both languages.

When we designed Al Thaqafiya’s bilingual editorial platform and design system, the token layer carried most of the system’s value. Editorial templates were built once and rendered correctly in either direction because direction was never written into the component.

What mirrors, what does not

Right-to-left is not a mirror image of left-to-right, and a design system Arabic users trust gets the exceptions right.

Mirrored: navigation order, breadcrumbs, progress steppers, back and forward controls, sliders, tabs, form label alignment, table column order, and the placement of primary and secondary actions.

Not mirrored: numerals, phone numbers, card and account numbers, IBANs, email addresses, URLs, code, media controls such as play and pause, timelines where time conventionally runs left-to-right, and most brand logos. Text within a line follows the Unicode bidirectional algorithm, which means mixed Arabic and Latin content, common in product names and addresses, needs explicit isolation to stop punctuation jumping to the wrong end.

Writing these rules into the design system, with examples, saves every new designer and developer from rediscovering them, and saves Arabic users the uncanny feeling of seeing something flip that should not have.

Typography for an Arabic design system

Typography carries more of the brand in Arabic than in English, because there are fewer typefaces to choose from and the script is more expressive. Choosing an Arabic typeface and a Latin companion that share rhythm and weight is a design decision that deserves time.

The system also has to handle Arabic’s practical demands: vertical metrics that leave room for marks above and below the baseline, no synthetic bold or italic, careful control of line length because Arabic words are often longer, and a fallback stack that degrades gracefully on the older Android devices still common across the region.

When we designed an Arabic-first streaming platform across mobile, TV and web, the typographic system had to work at reading distance on a television and at thumb distance on a phone, in both scripts. That only works when type tokens are defined per script and platform, and tested on real screens rather than in a design file.

Components and documentation that work in both directions

Every component in a bilingual design system should be documented with Arabic and English examples side by side, not behind a toggle, so the differences are visible at a glance. Component specs should state which parts mirror, how the component behaves with longer Arabic strings, and how it handles mixed-direction content.

The build process should include automated visual regression in both directions. Most RTL bugs are regressions introduced by a developer who tested in one language, and catching them in a pipeline is far cheaper than catching them in app store reviews.

Finally, design files should be structured so that the Arabic and English variants of a component are generated from the same source, not drawn separately. Separate drawings drift. Generated variants stay in sync.

Governance: keeping Arabic first-class

The technical work is the smaller half. The larger half is governance: who decides, who reviews, and what done means for a bilingual component.

• Make Arabic review a release gate, not a courtesy. No component ships until it has been checked in Arabic by someone who reads Arabic.
• Write the documentation in the language your team actually works in, with Arabic examples regardless. Teams in Saudi Arabia and the UAE often work in English internally while serving an Arabic-first audience, and the documentation has to bridge that.
• Keep one backlog. Arabic issues filed in a separate tracker are deprioritised issues.
• Assign ownership. A design system without a named owner for each language decays into whichever language the loudest team uses.
• Version the tokens, and treat a change to a direction or typography token as a breaking change with a migration note.

Governance is also where regional requirements enter the system. Accessibility expectations and government digital standards across the GCC change over time, and a system with clear ownership absorbs those changes once rather than product by product.

Our design systems work usually starts here, with the operating model, before a single token is written. A beautifully tokenised system that nobody governs is a very expensive component library.

Frequently asked questions

What makes a design system Arabic-ready?

Logical rather than physical spacing tokens, per-script typography tokens, icons flagged for mirroring, a documented list of what does and does not flip, and governance that requires Arabic review before release. Without the last item, the technical foundations erode within a few releases.

Should a bilingual design system have separate Arabic and English components?

No. Components should be built once with direction and language as inputs, so a change to a button or a card applies to both languages at the same time. Separate component sets inevitably drift and double the maintenance burden.

How do RTL design tokens differ from standard design tokens?

They avoid naming physical sides, using start and end instead of left and right, and they carry script-specific values for typography, numerals and directional motion under shared semantic names. The component asks for a semantic token and the system resolves the correct value for the active language.

If you are building or rebuilding a product for Arabic and English audiences, talk to us about structuring a design system that serves both from the first component.