When an accounting app's design system adds Arabic and Hebrew, which parts of the interface should mirror in right-to-left layouts, and which should not?
answer
- reading starts on the right
- order and flow flip
- arrows that mean back and forward
- digits keep their own direction
- logos and real objects stay put
basics
~20 sMirror whatever follows reading direction: layout order, alignment, navigation, back and forward arrows, steppers and progress. Do not mirror numbers and amounts, logos, checkmarks or icons of real objects; left-to-right runs keep their order inside right-to-left text.
solid answer
~50 sIn a right-to-left script, reading starts at the right edge, so anything whose meaning follows reading direction flips: the order of columns and navigation, text alignment (start becomes the right edge), the side an icon sits on relative to its label, back and forward arrows, progress bars, steppers and breadcrumbs. Things whose meaning does not depend on reading direction stay as they are: numbers and amounts (digits are still written left to right inside Arabic and Hebrew text), invoice codes and phone numbers, logos, checkmarks, and icons that depict real objects, such as a calculator or a printer. The design system should name positions as start and end rather than left and right in its specifications, and record per icon whether it mirrors. Mixed runs, like an English company name inside Arabic text, keep their own direction and must be isolated so punctuation lands correctly.
go deeper
Recall what mirrors, such as layout order, alignment, arrows and progress, and what does not, such as digits, amounts, logos, checkmarks and icons of real objects.
Explain why start and end naming makes one specification work in both directions, and how embedded left-to-right runs break punctuation unless isolated.
Show how you would audit an icon set and component library for right-to-left behaviour, add mirror flags and isolation by default, and involve native reviewers.
Weigh the cost of full right-to-left support across web and native against market priorities, and decide what the system guarantees versus what products own.
## Why direction is a design-language decision Arabic, Hebrew, Persian and Urdu are written **right to left**. An interface in those languages is not a translated left-to-right interface: the reader's eye starts at the top right, and everything that expresses order, progress or direction has to agree with that. The design system is the right place to decide what mirrors, because otherwise every product team makes the call again, differently, on every screen. Web and native platforms can both flip a layout automatically when the locale is right to left. Automatic flipping, however, only mirrors what it is told is directional; it cannot know that a calculator icon should stay put or that a custom arrow means back. The system's list of what mirrors is what makes the automatic behaviour correct. ## What mirrors - **Layout order**: navigation, columns, the sequence of fields in a row, the position of a sidebar. - **Alignment**: text and components aligned to the start edge, which is now the right. - **Icon position relative to a label**: a leading icon moves to the right of its label. - **Directional icons**: back and forward arrows, chevrons that point to the next item, the arrow on a list row that opens details. - **Progress and sequence**: progress bars fill from the right; steppers, breadcrumbs and pagination run right to left. - **Swipe and slide directions** that express next and previous. ## What does not mirror | Element | Mirror? | Why | |---|---|---| | Digits and amounts (such as 1,250.00) | No | Numbers are written left to right inside right-to-left text | | Invoice numbers, account codes, phone numbers | No | They are left-to-right strings embedded in the text | | Logos and brand marks | No | A mirrored logo is a different, wrong logo | | Checkmarks | No | The shape is a convention, not a direction | | Icons of real objects (calculator, printer, receipt) | No | They depict things, not a reading direction | | Clocks and circular refresh arrows | Usually no | Clocks turn the same way everywhere; decide once and document it | The hard cases are icons that combine an object with a direction, such as a document with an arrow pointing to the next page. The system should decide each one and store the decision with the icon. ## Bidirectional text inside one line Right-to-left text constantly contains left-to-right runs: amounts, invoice codes, a supplier's English company name, an email address. The platform's bidirectional algorithm orders these runs automatically, but it guesses at the boundaries using neutral characters like spaces and punctuation. Typical failures: 1. A period or closing parenthesis after an embedded English name lands on the wrong side. 2. A value inserted into a translated sentence at run time scrambles the surrounding word order. 3. A code such as INV-2041 with a hyphen splits into pieces displayed in the wrong order. The fix is to **isolate** inserted values as their own direction run and to set the base direction of each text block from its language, so neutral characters attach to the right run. The design system's text and message components should do this by default. ## Tables and figures in an accounting product - **Column order mirrors**, so the first column, usually the description, sits on the right. - **Digits inside each amount keep left-to-right order**; whether numeric columns align to the start or end edge in right-to-left locales should be decided once and checked with native readers. - **Currency placement and digit shapes** (Western or locale digits) come from locale formatting, not from mirroring. - **Charts**: whether a time axis runs right to left is a judgement call that varies by audience; decide it in the system rather than per chart. ## How the system encodes it 1. Specifications and spacing values use **start and end**, never left and right, so one specification serves both directions. 2. Every icon carries a **mirror flag** in the icon library's metadata. 3. Directional components (steppers, breadcrumbs, pagination) document their right-to-left behaviour. 4. Text components **isolate interpolated values** by default. 5. Right-to-left screens are reviewed by native readers before release. 6. The documentation shows key screens in both directions, so designers see the mirrored layout instead of imagining it.
- Why should design specifications say start and end instead of left and right?Because the same component must work in both directions. A padding or icon position written as start and end resolves to left in left-to-right locales and right in right-to-left ones, so one specification and one set of values serve every locale. Left and right force a second specification or a mirrored copy that drifts.
- An Arabic invoice screen shows the amount 1,250.00 as 00.052,1. What went wrong?The digits were reversed as if they were right-to-left text, probably by a manual mirroring step or a string reversal. Digits keep left-to-right order inside right-to-left text, and the platform's bidirectional handling does that correctly if the amount is treated as a number run rather than mirrored.
saying these in an interview costs you the question
- Right-to-left support means flipping the whole screen horizontally, icons and numbers included.
- Digits in Arabic and Hebrew text are written right to left like the letters.
- Logos should be mirrored in right-to-left locales for consistency.
- Translating the strings is enough; layout direction follows automatically everywhere.
- Left and right are fine in specs because right-to-left teams can mirror them later.