agentsclimarketplace
Sign in

I18n l10n readiness review

Skill Raishin/vanguard-frontier-agentic/skills/frontend/i18n-l10n-readiness-review

Audit frontend code for internationalization readiness — externalized ICU MessageFormat strings, Intl-based date/number/currency/plural formatting, correct lang/dir attribute propagation, and RTL-safe CSS logical properties — before translation vendor engagement, with CLDR plural-rule detail loaded only when auditing countable strings.From its SKILL.md

Install
npx -y skills add Raishin/vanguard-frontier-agentic --skill i18n-l10n-readiness-review

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 20 stars20 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

6.9 KB, ~1.5k tokens by cl100k_base, as published. Nobody here has run it

i18n/l10n Readiness Review

Purpose

Teams routinely discover — after paying a translation vendor — that string concatenation can't express another language's word order, pluralization breaks outside English's one/other split, or RTL layouts mirror visually but not functionally. Fixing these after translation means re-engineering already-translated strings, re-running the vendor pipeline, and eating the schedule slip. This skill audits pluralization architecture (ICU MessageFormat / CLDR plural categories), Intl-based formatting, lang/dir attribute propagation, and RTL-safe layout so the codebase is structurally translation-ready before any string reaches a translator. It does not translate anything itself.

When to use

Use this skill when the user asks to:

  • audit a codebase for hardcoded/non-externalized user-facing strings,
  • review pluralization logic against CLDR plural categories for target locales,
  • review date/number/currency formatting for Intl API usage vs manual string-building,
  • review layout/CSS for RTL-market readiness,
  • assess overall i18n/l10n readiness before a new-market launch or vendor engagement.

Lean operating rules

  • First establish the target locale list, including at least one locale with more than two CLDR plural categories (e.g., Arabic: 6, Polish: 4, Russian: 4) if any countable strings exist — English's one/other split hides most pluralization bugs. If the user has not named target locales, ask; do not assume English-only is sufficient for a "readiness" review.
  • Flag string concatenation for user-facing countable/orderable/gendered content as a structural defect, not a style nit — "You have " + count + " items" cannot be correctly localized without ICU MessageFormat ({count, plural, ...}) or an equivalent, because plural-category counts and word order both vary by locale.
  • Verify date/number/currency/plural values use Intl.DateTimeFormat, Intl.NumberFormat, or Intl.PluralRules (or a library wrapping them, e.g. FormatJS/react-intl, next-intl, i18next with ICU) rather than manual string building, hardcoded separators, or naive Math.round/string concatenation for currency.
  • Check that the dir attribute (and lang) actually reach the rendered document root (<html lang dir>) and stay in sync with the active locale, and that layout uses CSS logical properties (margin-inline-start, padding-inline-end, inset-inline-start) instead of physical properties (margin-left, padding-right, left) wherever an RTL-market launch is on the roadmap, even if RTL isn't shipped yet — retrofitting physical properties across a whole codebase later is expensive.
  • Do not treat the presence of a language switcher, an i18next/next-intl dependency, or a locales/ translation-file structure as proof of readiness — a library being installed does not mean it is used correctly everywhere. Verify the underlying formatting/pluralization/layout mechanics independently, file by file.
  • Never author, insert, or "helpfully" translate actual copy into another language; that is the translation vendor's job. Only flag strings for extraction and hand off the inventory to whoever owns translation.
  • Verify icons/imagery conveying directionality (arrows, forward/back/next controls, progress indicators) have a documented RTL-mirroring plan when RTL is in scope — logical CSS properties fix layout flow but do not auto-flip iconography.
  • Treat ICU plural-category coverage as version/library-sensitive: verify the exact syntax and category set against current FormatJS/ECMA-402/CLDR references rather than assuming a fixed one/few/many split applies to every language.

Context7 Documentation Protocol

Before making any claim about ICU MessageFormat syntax, Intl API behavior, or a specific i18n library's plural/formatting API, ground it via Context7:

  1. Call resolve-library-id for the library in scope (e.g., formatjs, next-intl, react-intl, i18next) or the runtime spec area (ECMA-402/Intl).
  2. Call query-docs for the specific syntax or API behavior before citing it (plural category names, selectordinal syntax, Intl.PluralRules options, locale-matching behavior).
  3. Prefer official docs (FormatJS docs, TC39 ECMA-402 spec, MDN Intl, Unicode CLDR) over memory — plural rule sets and Intl option names are locale- and spec-version-sensitive.
  4. If Context7 has no coverage for a library in scope, fall back to the official docs listed below and mark the claim documentation-based (uncertain — no Context7 coverage).
  5. Never invent ICU syntax, Intl constructor options, or CLDR plural-category names. Verified from Context7 (FormatJS docs) for this skill: the canonical CLDR plural categories are zero, one, two, few, many, other (not every language uses every category — e.g. English uses only one/other; Arabic uses all six), and ICU MessageFormat also supports exact-value matches via =N (e.g. =0 {No items}) layered alongside category matches.

References

Load these only when needed:

  • Pluralization and ICU MessageFormat audit — use only when auditing countable/orderable strings against CLDR plural categories or reviewing ICU MessageFormat/Intl.PluralRules usage.
  • Intl formatting audit — use only when reviewing date, number, currency, or list formatting for manual-string-building defects vs correct Intl API usage.
  • RTL and logical-property layout audit — use only when reviewing lang/dir attribute propagation, CSS logical properties, or directional-iconography readiness for RTL markets.

Response minimum

Return, at minimum:

  • the target locale list driving the review (including any RTL or multi-plural-category locale considered),
  • hardcoded-string inventory with file:line for user-facing countable/orderable/ concatenated content,
  • pluralization audit against the actual CLDR categories required for the target locale(s), not just one/other,
  • RTL/logical-CSS-property findings if RTL is in scope or roadmapped, including lang/dir propagation status,
  • explicit statement that translation itself was not performed by this skill and that findings are a structural-readiness audit, not a translation deliverable.

What ships with it: 4 files

20.5 KB alongside SKILL.md

references/

Keep looking

Skills are one crate of 325,949. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.