Internationalization (i18n) (Deep Workflow)#

i18n is engineering readiness for multiple languages: extractable strings, ICU messages, locale-aware formatting, and tests—before full localization (translator workflow).

When to Offer This Workflow#

Trigger conditions:

• Planning first non-English locales
• Hard-coded UI strings across the codebase
• Incorrect date/number formatting outside default locale

Initial offer:

Use six stages: (1) inventory & scope, (2) extraction pipeline, (3) ICU & placeholders, (4) formatting APIs, (5) layout & overflow, (6) QA hooks). Confirm framework (i18next, FormatJS, rails-i18n, etc.).

---

Stage 1: Inventory & Scope#

Goal: Which surfaces ship first; pilot locales; avoid translating everything on day one.

---

Stage 2: Extraction Pipeline#

Goal: Stable message keys; CI lint to block new user-visible literals where policy requires; namespaces per feature.

---

Stage 3: ICU & Placeholders#

Goal: Plural and select rules; named variables; no string concatenation across translated fragments.

---

Stage 4: Formatting APIs#

Goal: Intl (or platform equivalent) for dates, numbers, currency; explicit timezone policy (UTC vs user local).

---

Stage 5: Layout & Overflow#

Goal: Flexible layouts for longer translations; pseudolocale in CI to catch truncation (e.g., xx-ACME).

---

Stage 6: QA Hooks#

Goal: Easy locale switching in staging; optional screenshot/visual tests for critical screens.

---

Final Review Checklist#

• Scope and pilot locales defined
• Extraction and linting in place
• ICU for plurals; no unsafe concatenation
• Intl formatting for numbers/dates
• Pseudolocale or stress language in QA

Tips for Effective Guidance#

• Pair with localization skill for translator workflow and TMS integration.

Handling Deviations#

• Games or marketing-heavy UIs: context comments for translators are critical.