
Localization Design
- 619 installs
- 2k repo stars
- Updated June 14, 2026
- owl-listener/designer-skills
Localization Design is a Claude skill that designs interfaces adapting to multiple languages, writing directions, and cultural contexts for developers who need i18n-ready layouts without per-locale redesigns.
About
Localization Design is a designer-skills module from owl-listener for building UI that survives translation, script changes, and cultural convention differences. The skill addresses text expansion—English-compact copy stretching in German or Brazilian Portuguese—plus bidirectional layouts, iconography pitfalls, and color associations that vary by locale. Developers invoke it when adding i18n to React, mobile, or design-system components and need flexible containers, truncation rules, and RTL mirroring patterns upfront. The workflow maps locale expansion tables, component constraints, and cultural UI checks so engineering avoids emergency layout patches after translators deliver longer strings.
- localization-design
Localization Design by the numbers
- 619 all-time installs (skills.sh)
- +65 installs in the week ending Aug 4, 2026 (Skillselion tracking)
- Ranked #627 of 4,347 Backend & APIs skills by installs in the Skillselion catalog
- Data as of Aug 5, 2026 (Skillselion catalog sync)
npx skills add https://github.com/owl-listener/designer-skills --skill localization-designAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 619 |
|---|---|
| repo stars | ★ 2k |
| Last updated | June 14, 2026 |
| Repository | owl-listener/designer-skills ↗ |
How do you design UI for text expansion in i18n?
Use localization-design for development tasks
Who is it for?
Frontend developers and designers shipping multilingual SaaS or mobile apps who need layouts that absorb longer translations and RTL scripts without breaking.
Skip if: Translation management platforms, ICU message file authoring alone, or backend locale detection logic without UI layout implications.
When should I use this skill?
A developer asks to design for i18n, handle text expansion, support RTL layouts, or adapt UI for multiple languages and cultural contexts.
What you get
Localization-ready layout specs, expansion-tolerant components, and locale adaptation checklist for RTL and cultural UI differences.
- i18n layout specifications
- Component expansion guidelines
- Locale adaptation checklist
Files
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-startinstead ofmargin-left;padding-block-endinstead ofpadding-bottom— these flip automatically withdir="rtl" - Text alignment: use
text-align: startnottext-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
Related skills
How it compares
Use Localization Design for layout and component i18n readiness; use translation tooling separately for string extraction and locale file management.
FAQ
What is the main localization failure Localization Design addresses?
Localization Design focuses on text expansion—the common failure where English-compact UI breaks when translations run longer in German, French, or other locales. The skill sizes containers and components to absorb typical expansion without clipping or overflow.
Does Localization Design cover RTL languages?
Localization Design covers bidirectional writing directions and RTL layout mirroring alongside cultural differences in icons and color. Developers receive patterns so components adapt without a separate redesign per script.