localization
Design internationalization (i18n) and localization (l10n) — string management, locale handling, RTL support, cultural adaptation — so the product works across languages and regions.
Goals
- Externalize all user-facing strings from code
- Support locale-aware formatting (dates, numbers, currencies)
- Handle RTL layouts and bidirectional text
- Integrate translation workflow with the development process
Contract
Input
A product or feature to localize: supported locales, content volume, RTL requirements.
Output
A localization specification with:
- String extraction and management strategy
- Locale formatting rules
- RTL adaptation plan
- Translation workflow integration
i18n vs. l10n
| Concern |
i18n (internationalization) |
l10n (localization) |
| What |
Code structure |
Cultural adaptation |
| Who |
Developers |
Translators, local teams |
| When |
Before shipping |
Per locale |
| Examples |
String IDs, ICU, format APIs |
Translation, dates, currency |
Steps
- Audit user-facing strings — extract from code, templates, DB
- Choose a framework — ICU MessageFormat, gettext, Fluent
- Define locale hierarchy — en → en-GB → en-AU
- Handle formatting — dates (Intl.DateTimeFormat), numbers, currencies
- Adapt UI — text expansion (±30%), RTL layout, icons
- Integrate translations — TMS integration, glossary, placeholders
- Test — pseudolocalization, native speaker review
References
../cms-architecture/SKILL.md — content localization
../../frontend/frontend-design/SKILL.md — RTL design
../../accessibility/accessibility/SKILL.md — language in a11y
1---2name: localization3description: Design internationalization (i18n) and localization (l10n) — string management, locale handling, RTL support, cultural adaptation — so the product works across languages and regions.4---56# localization78Design internationalization (i18n) and localization (l10n) — string management, locale handling, RTL support, cultural adaptation — so the product works across languages and regions.910## Goals11- Externalize all user-facing strings from code12- Support locale-aware formatting (dates, numbers, currencies)13- Handle RTL layouts and bidirectional text14- Integrate translation workflow with the development process1516## Contract1718### Input19A product or feature to localize: supported locales, content volume, RTL requirements.2021### Output22A localization specification with:23- String extraction and management strategy24- Locale formatting rules25- RTL adaptation plan26- Translation workflow integration2728## i18n vs. l10n2930| Concern | i18n (internationalization) | l10n (localization) |31|---|---|---|32| What | Code structure | Cultural adaptation |33| Who | Developers | Translators, local teams |34| When | Before shipping | Per locale |35| Examples | String IDs, ICU, format APIs | Translation, dates, currency |3637## Steps38391. **Audit user-facing strings** — extract from code, templates, DB402. **Choose a framework** — ICU MessageFormat, gettext, Fluent413. **Define locale hierarchy** — en → en-GB → en-AU424. **Handle formatting** — dates (Intl.DateTimeFormat), numbers, currencies435. **Adapt UI** — text expansion (±30%), RTL layout, icons446. **Integrate translations** — TMS integration, glossary, placeholders457. **Test** — pseudolocalization, native speaker review4647## References48- `../cms-architecture/SKILL.md` — content localization49- `../../frontend/frontend-design/SKILL.md` — RTL design50- `../../accessibility/accessibility/SKILL.md` — language in a11y