Lesson 28 of 30

Layout for RTL & Multi-Language UX

Q: How would you make an existing component library RTL-safe, and what would you specifically check for beyond just flipping text direction?

A strong answer covers: Names CSS logical properties (inline-start/inline-end) as the systemic fix over physical left/right properties; Distinguishes directional icons (should mirror) from non-directional icons (should not mirror), with a reasoning test rather than a blanket rule; Raises text expansion as a layout risk, not just a translation-file concern; Mentions a concrete verification method (pseudo-localization, testing with a real RTL language, or a specific component audit).

This platform's own i18n lesson covers the technical machinery — pluralization, Intl, translation files. This one covers what happens to the layout itself once a translated string doesn't fit, or the whole page needs to read right-to-left.

12 min read

Check your understanding

Every option explains itself — why the right one is right, and why each wrong one is wrong. Miss one and it comes back later on a spaced-repetition schedule.

Question 1 of 3

In an RTL (right-to-left) layout, which of these icons should mirror, and which shouldn't: a 'forward' arrow, and a settings gear?

The forward arrow should mirror; the settings gear should notBoth should mirror, since all icons flip automatically in a proper RTL implementationNeither should mirror — only text direction changes in RTL, not icons

Stuck? Ask the AI tutor

Hints without spoilers, and a plain explanation of why a wrong answer was wrong — answered only from this lesson. Free account, no card.

Interview questions on Layout for RTL & Multi-Language UX

What interviewers actually ask about this, and what a strong answer has to cover.

How would you make an existing component library RTL-safe, and what would you specifically check for beyond just flipping text direction?

A strong answer covers

Names CSS logical properties (inline-start/inline-end) as the systemic fix over physical left/right properties
Distinguishes directional icons (should mirror) from non-directional icons (should not mirror), with a reasoning test rather than a blanket rule
Raises text expansion as a layout risk, not just a translation-file concern
Mentions a concrete verification method (pseudo-localization, testing with a real RTL language, or a specific component audit)

Likely follow-ups

You find a carousel component with swipe logic hardcoded to advance on a left-to-right swipe. Walk me through what breaks in RTL and how you'd fix it.
The design team says translated buttons can just truncate with an ellipsis if they run long. What's the risk with that as a blanket policy, and when might it actually be the right call?

Practice these with the AI interviewer →

The plain-language idea

Supporting Arabic, Hebrew, and other RTL (right-to-left) languages is not "flip the text direction and ship it." Two layout consequences get missed even by teams that handle the translation strings correctly:

Mirroring is selective, not global. Icons that convey a spatial or directional meaning — a "forward" arrow, a "back" chevron, a progress indicator moving left-to-right — need to mirror in RTL, because their meaning is relative to reading direction. Icons with no directional meaning — a settings gear, a trash can, a magnifying glass, a play button — should not mirror; flipping a gear icon just makes it look wrong, since gears don't have a "direction."
Text expansion breaks layouts sized for English. Translated strings are commonly 30-100% longer than their English source, and German and Finnish are frequent, well-known offenders for this. A button labeled "Save" (4 characters) fits comfortably; its German equivalent, "Speichern" (9 characters), can silently wrap, truncate, or overflow a container that was sized by eyeballing the English text rather than reserving real room for expansion.

The fix that makes both of these largely automatic rather than something a developer hand-maintains per component is CSS logical properties: margin-inline-start instead of margin-left, padding-inline-end instead of padding-right, inset-inline-start instead of left. Logical properties are defined relative to text direction, not a fixed physical side — set dir="rtl" on the document and every logical-property value flips automatically, with zero component-level RTL-specific code. A codebase built on physical properties (margin-left everywhere) needs a parallel RTL override for nearly every one of those declarations, hand-maintained and easy to let drift out of sync as the product grows.

See it in a real thing: one card, mirrored correctly (and incorrectly)

A product card with a "favorite" heart icon in the top corner, a directional "view details →" link, and a non-directional trash icon in an admin overflow menu: in RTL, the card's whole layout mirrors (the heart icon moves to the opposite corner, since that corner is now the start of reading direction), the arrow flips to point left (still "forward" relative to RTL reading direction), and the trash icon stays exactly as drawn, because deleting something has no directional meaning to preserve. A team that mirrors everything indiscriminately ships a flipped trash icon that reads as a rendering bug, not a localization feature — and a team that mirrors nothing ships an arrow that visually points the wrong way for the reading direction it's meant to guide.

What people usually miss

Watch out

RTL support built on physical CSS properties (left/right, margin-left) requires a hand-maintained parallel set of RTL overrides. Logical properties (inline-start/inline-end) get RTL correctness for free from dir="rtl", with no per-component override needed — this is a real, current CSS feature, not a future aspiration.
Not every icon should mirror, and mirroring the wrong ones reads as broken, not localized. The test isn't "does this icon look directional" — it's "does its meaning depend on reading direction." A play button (▶) is sometimes debated but is generally treated as non-directional since it represents "playback," not spatial motion.
Text expansion isn't a translation-team problem to catch after the fact — it's a layout problem to design for up front. A button or label sized to fit the English string exactly, with no slack, will break the moment it's translated; designing with realistic buffer room (or wrapping/truncation strategies) up front avoids a late, painful bug hunt.
RTL bugs concentrate in places layout logic hardcodes a direction: absolute positioning with left, text-align: left, custom carousel/swipe logic assuming left-to-right motion, and icon fonts that don't ship mirrored variants are the recurring offenders.

Why this matters in interviews

"How would you make this component RTL-safe?" is testing whether a candidate reaches for logical properties as the systemic fix (versus a per-component dir === "rtl" ? ... : ... conditional scattered everywhere) and can correctly reason about which specific icons need mirroring — both are concrete, checkable signals of someone who's actually shipped a product outside a single-language, LTR-only market.