i18n

# 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.