5 min read · Oct 2026
A Bilingual Design System Takes More Than Mirroring
Arabic and English interfaces need shared rules that accommodate direction, text, and content differences. Learn how to separate language from direction, use logical layout properties, review mixed content, and test realistic component examples before treating translation as a completed design task.
Imagine an Arabic and English supplier registration portal. Moving navigation to the opposite side seems sufficient until an email address appears inside an Arabic heading, an organization name wraps, or a continuation action shifts unexpectedly. A bilingual design system needs decisions about meaning and content, not simply a mirrored screenshot.
01-Separate language from direction
W3C guidance explains that declaring a page's language does not automatically set its direction; HTML establishes base direction through dir. An implementation agreement therefore needs two explicit decisions: the content language and its display direction, including areas containing differently directed content.
For our illustrative portal, treat company names, email addresses, and reference numbers as distinct content cases. Combine Arabic, English, and punctuation in examples, then inspect display, copying, and entry. Changing field alignment alone may hide one symptom while leaving another content combination broken.
02-Design around start and end
MDN describes CSS logical properties as expressing layout relative to writing direction rather than only physical sides. Using the beginning and end of a line helps capture intent when a component must work in both directions.
Agree, for example, that a field icon sits at its start and spacing follows that relationship. Then decide what should actually mirror. A navigation arrow may follow the journey's direction, while a logo or document image should not be flipped merely because the language changes. Document exceptions according to function, not appearance alone.
03-Localize more than headings
Do not assume translation preserves length or visual rhythm. Try a long supplier name, a detailed error, and a multiword action label. Review typeface, line height, and available space. Decide when wrapping is appropriate and when shortening would conceal information that someone needs to complete the task.
For the hypothetical portal, establish separate rules for dates, numbers, currencies, and organization names. Ask product owners about expected conventions rather than deriving them solely from interface language. Give errors, instructions, and status names the same translation attention as main navigation and page titles.
04-Test the complete bilingual task
Create Arabic and English examples of each component, then review the full registration journey: entering details, encountering errors, correcting them, and checking the summary. Include mixed content, narrow screens, and enlarged text so review does not stop at an ideal presentation sample.
Assign ownership for terminology, icon direction, and focus order. Record intentional differences between versions. Whenever a shared component changes, review both language examples together. This makes localization part of the component's quality criteria instead of treating Arabic as a later adjustment for another team.
Your next step
Start with the task's meaning, then align language, direction, layout, and content around it. A bilingual system succeeds when people can complete their work clearly in both versions, even when some visual details intentionally differ.