A utility billing portal's component library used left and right spacing everywhere and must now launch in Arabic and Hebrew; how do you retrofit it for right-to-left?
answer
- inventory every physical direction
- start and end instead of left and right
- direction inherited from the root
- directional flags on icons
- a guard so it never comes back
basics
~20 sInventory every physical left/right use, convert spacing, alignment, radii, offsets and motion to logical start/end, take direction from the app's root, flag directional icons, then add a lint guard and both-direction checks so physical values cannot return.
solid answer
~40 sStart with an **inventory**: every place an element uses a physical side — spacing, alignment, positioning, borders, one-sided corner radii, shadow offsets, slide-in motion, icon placement. Convert each to **logical start and end**, which follow the content's direction, so one definition serves both directions; for left-to-right consumers this renders identically, because start maps to left. Make **direction come from the app's root** and inherit, isolate embedded left-to-right values, and add a **directional flag** to icons so only the right ones mirror. Then stop regressions: a **lint rule** that rejects physical sides in library code, examples and visual checks in both directions, and a written list of the few intentional physical exceptions. Finally, warn consumers whose own overrides used physical sides, since those can now conflict with the library's logical ones.
go deeper
Recall that start and end follow reading direction while left and right do not, and that the library should use start and end everywhere.
Explain the conversion: what kinds of physical values exist beyond spacing — radii, offsets, motion, positioning — and why direction should be inherited from the root.
Run the retrofit end to end: inventory, conversion, icon classification, isolation of embedded values, a lint guard, both-direction checks, and a rollout that handles consumers' own physical overrides.
Make logical layout a day-one library rule, since the audit, icon classification and consumer migration costs of a later retrofit grow with every element and product.
## Why a left/right library breaks in right-to-left A **component library** that says "12 units of space on the left of the icon" is describing a **physical** side. In a **right-to-left (RTL)** language the icon moves to the other end of the row, but the space stays on the left — now between the icon and the edge instead of between the icon and the text. Multiply that across every element in a utility billing portal — bill cards, meter-reading forms, the usage chart's legend, the payment-plan stepper — and an Arabic launch looks subtly broken everywhere. The fix is to describe layout in **logical** terms: **start** is the side where reading begins and **end** is where it finishes. In left-to-right text start is the left; in RTL it is the right. The web expresses this with its `inline-start` and `inline-end` family of style properties; native mobile toolkits express the same idea as leading and trailing (or start and end) edges and constraints. ## Step 1: inventory every physical direction - **Spacing** on one side of a part. - **Alignment** of text and actions. - **Positioning** of badges, close actions and floating parts. - **Borders and corner radii** on one side only, such as a card with an accent stripe. - **Shadow and offset values** that assume light from one side. - **Motion** that slides in from a physical edge. - **Icon placement** before or after labels. A search of the library's styles for physical side keywords finds most of these; a pass through the workshop with direction switched to RTL finds the rest. ## Step 2: convert, then let direction flow from the root 1. **Convert** every inventoried value to start or end. Spacing tokens keep their values; what changes is the side they are applied to. 2. **Set direction once**, at the app's root, from its locale, and let elements inherit it. Elements must not carry their own direction option. 3. **Isolate embedded left-to-right values** such as email addresses, account numbers and meter serials so they keep their internal order inside RTL sentences. 4. **Add a directional flag** to every icon in the icon set; the icon element mirrors only flagged icons. ## Step 3: keep it from coming back | Guard | What it stops | |---|---| | Lint rule rejecting physical sides in library styles | New left/right values in new or changed elements | | Workshop examples in both directions | Reviewers never seeing the RTL rendering | | Visual checks in both directions | Silent regressions in existing elements | | Written list of intentional physical exceptions | The same exception being debated again | Intentional exceptions exist: a phone-number field that is always entered left to right, or a brand element fixed to one corner. Record each one with its reason, so the lint rule can allow it explicitly. ## Step 4: roll it out to consumers For left-to-right products the conversion renders the same, because start maps to left. The risk is in **consumer overrides**: an app that added its own left spacing to a library element may now get both its physical value and the library's logical one, or override the wrong side. Tell consumers what changed, show how to convert their overrides, and release the change as a version they can plan for. ## What a retrofit costs, and why early is cheaper The conversion itself is mostly mechanical. The expensive parts are the **audit**, the **icon classification** and the **consumer overrides**, and all three grow with every element and every product added. A library that uses start and end from its first element never pays them, which is why logical layout is a day-one rule even for products that do not yet plan an RTL market.
- Do spacing tokens themselves need to change when a library adopts logical start and end?Usually not. A spacing token is a value, such as a medium gap, with no side attached. What changes is where elements apply it: the start or end side instead of the left or right. Tokens only change if they encoded a side in their name, such as a left inset, which should become a start inset.
- Why should an element never carry its own direction option?Because direction belongs to the content, and the content's language is set by the app. A per-element option lets one element render left to right inside an RTL page, producing half-mirrored screens. The element should inherit direction from its context; the only local change should be isolating an embedded fragment whose own direction differs.
Giving directions as 'turn toward the exit' rather than 'turn left': the instruction stays correct whichever door you came in by, just as start and end stay correct whichever way the text runs.
saying these in an interview costs you the question
- Converting left and right to start and end changes left-to-right layouts.
- Right-to-left support means shipping a mirrored copy of each element.
- Each element should take its own direction option from the consumer.
- Flipping the whole page with a mirror transform is an adequate retrofit.
- Once converted, no lint guard is needed because developers will remember.