Teams routinely discover — after paying a translation vendor — that string concatenation\ncan't express another language's word order, pluralization breaks outside English's\none/other split, or RTL layouts mirror visually but not functionally. Fixing these after\ntranslation means re-engineering already-translated strings, re-running the vendor\npipeline, and eating the schedule slip. This skill audits pluralization architecture\n(ICU MessageFormat / CLDR plural categories), Intl-based formatting, lang/dir\nattribute propagation, and RTL-safe layout so the codebase is structurally\ntranslation-ready before any string reaches a translator. It does not translate\nanything itself.
Use this skill when the user asks to:
\nIntl API usage vs manual string-building,\"You have \" + count + \" items\" cannot be\ncorrectly localized without ICU MessageFormat ({count, plural, ...}) or an\nequivalent, because plural-category counts and word order both vary by locale.Intl.DateTimeFormat,\nIntl.NumberFormat, or Intl.PluralRules (or a library wrapping them, e.g.\nFormatJS/react-intl, next-intl, i18next with ICU) rather than manual string\nbuilding, hardcoded separators, or naive Math.round/string concatenation for\ncurrency.dir attribute (and lang) actually reach the rendered document root\n(<html lang dir>) and stay in sync with the active locale, and that layout uses CSS\nlogical properties (margin-inline-start, padding-inline-end, inset-inline-start)\ninstead of physical properties (margin-left, padding-right, left) wherever an\nRTL-market launch is on the roadmap, even if RTL isn't shipped yet — retrofitting\nphysical properties across a whole codebase later is expensive.i18next/next-intl\ndependency, or a locales/ translation-file structure as proof of readiness — a\nlibrary being installed does not mean it is used correctly everywhere. Verify the\nunderlying formatting/pluralization/layout mechanics independently, file by file.Before making any claim about ICU MessageFormat syntax, Intl API behavior, or a\nspecific i18n library's plural/formatting API, ground it via Context7:
resolve-library-id for the library in scope (e.g., formatjs, next-intl,\nreact-intl, i18next) or the runtime spec area (ECMA-402/Intl).query-docs for the specific syntax or API behavior before citing it (plural\ncategory names, selectordinal syntax, Intl.PluralRules options, locale-matching\nbehavior).Intl, Unicode CLDR)\nover memory — plural rule sets and Intl option names are locale- and\nspec-version-sensitive.documentation-based (uncertain — no Context7 coverage).Intl constructor options, or CLDR plural-category names.\nVerified from Context7 (FormatJS docs) for this skill: the canonical CLDR plural\ncategories are zero, one, two, few, many, other (not every language uses\nevery category — e.g. English uses only one/other; Arabic uses all six), and ICU\nMessageFormat also supports exact-value matches via =N (e.g. =0 {No items})\nlayered alongside category matches.Load these only when needed:
\nIntl.PluralRules usage.Intl API usage.lang/dir attribute propagation, CSS logical properties,\nor directional-iconography readiness for RTL markets.Return, at minimum:
\nlang/dir propagation status,