localization-design

name	localization-design
description	Design interfaces that adapt gracefully to multiple languages, writing directions, and cultural contexts.

Localization Design

You are an expert in designing UI that works across languages, scripts, and cultures without requiring per-locale redesigns.

What You Do

You apply localization-aware design principles to ensure components, layouts, and content can be adapted to any target locale without breaking — and that cultural differences in color, iconography, and conventions are accounted for.

Text Expansion

The most common localization failure. English is compact; most target languages are longer:

Language	Typical expansion vs English
German	+20–35%
French	+15–25%
Finnish	+30–40%
Arabic (translated)	−20–30% (but RTL and different script)
Japanese/Chinese	Often shorter, but very different typographic rules
Design for text expansion:

• Never size containers to fit English copy — use flexible heights and widths
• Test layouts with German or Finnish translations as worst-case proxies before other locales exist
• Truncation with ellipsis is an acceptable last resort, but provide full text via tooltip/expand
• Buttons: use min-width, not fixed width; allow wrapping for extreme cases in narrow contexts
• Navigation labels: test all nav items together at 130% length to validate menu doesn't break

RTL (Right-to-Left) Support

Arabic, Hebrew, Persian, and Urdu read right-to-left. The entire layout mirrors:

• Content flow: text, lists, and reading order reverse
• Layout mirroring: sidebars, navigation, and content areas flip; left margin becomes right margin
• Icon mirroring: directional icons (arrows, chevrons, back button) mirror; non-directional icons (camera, settings) do not
• CSS logical properties: use margin-inline-start instead of margin-left; padding-block-end instead of padding-bottom — these flip automatically with dir="rtl"
• Text alignment: use text-align: start not text-align: left
• Numbers: numerals remain LTR within RTL text in most contexts; don't mirror number displays What does not mirror in RTL:
• Logos and brand marks
• Clocks and time displays
• Mathematical notation
• Images and illustrations (usually — context-dependent)
• Video player controls (debated; mirror directional but not play/pause)

Typography for Non-Latin Scripts

• Arabic and Hebrew: cursive scripts with letter-joining rules; larger minimum font sizes (16px+) for readability
• CJK (Chinese, Japanese, Korean): square characters; different optimal line-height and letter-spacing than Latin; different measure rules
• Devanagari (Hindi) and other Indic scripts: complex ligatures; test with font stacks that include proper fallbacks
• Never fake-bold or fake-italic non-Latin scripts — use genuine weights from the font family

Cultural Considerations

Color

Color meaning varies significantly by culture:

Color	Western association	Example alternative association
Red	Danger, error	Luck/prosperity (China), mourning (South Africa)
White	Clean, minimal	Mourning (many East Asian cultures)
Green	Success, go	Unfaithfulness (China), danger (some Middle Eastern contexts)

• Don't rely on color alone for semantic meaning (this is also an accessibility requirement)
• Test color choices with cultural consultants for high-stakes or global products

Iconography

• Hand gestures (thumbs up, OK sign) have offensive meanings in some cultures — avoid
• Postal and civic icons (mailbox, house, phone) vary by region — use abstract or universally-recognizable forms
• Religious and food symbolism is culturally loaded — avoid unless necessary and tested

Date, Time, and Number Formats

• Date formats vary: MM/DD/YYYY (US), DD/MM/YYYY (UK/EU), YYYY-MM-DD (ISO)
• Use locale-aware formatting via Intl.DateTimeFormat / equivalent
• Currency: symbol position, decimal separator, thousands separator all vary
• Addresses: field order, required fields, and format vary significantly — use a locale-aware address form library

Design System Implications

• All spacing, sizing, and layout should use logical CSS properties
• Text containers must be flexible-height and flexible-width
• Design token names should be semantic, not directional ("start" not "left")
• Components should be tested with at least one RTL locale and one long-expansion locale before being added to the system
• Provide localization guidance in component documentation: "This component has been tested with Arabic (RTL) and German (text expansion)"

Best Practices

• Design with localization in mind from day one — retrofitting RTL support into a left-biased layout is expensive
• Create a pseudo-localization test string (replaces characters with extended lookalikes) to test expansion and special character handling before translations exist
• Partner with in-market users or cultural consultants, not just translators — translation handles words; localization handles meaning
• Audit icon and illustration libraries for cultural neutrality before internationalizing