Exécutez n'importe quel Skill dans Manus
en un clic

Exécutez n'importe quel Skill dans Manus en un clic

i18n-l10n-readiness-review

Étoiles16

Forks3

Mis à jour2 juillet 2026 à 23:30

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.

Installation

Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.

Exécuter dans Manus

Source

Raishin

Raishin/vanguard-frontier-agentic

Ouvrir le dépôt GitHub Voir les dépôts du créateur

Téléchargement

Exécuter dans Manus

Explorateur de fichiers

5 fichiers

SKILL.md

readonly

name	i18n-l10n-readiness-review
description	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.
allowed-tools	Read Grep Glob
metadata	{"author":"github: Raishin","version":"0.1.0","updated":"2026-07-02","category":"compliance"}

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:

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).
Call query-docs for the specific syntax or API behavior before citing it (plural category names, selectordinal syntax, Intl.PluralRules options, locale-matching behavior).
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.
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).
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.

Plus depuis ce dépôt

même dépôt

frontend-dom-xss-csp-review

Raishin/vanguard-frontier-agentic

Review frontend source for DOM XSS sinks (innerHTML, dangerouslySetInnerHTML, v-html, document.write, eval-class APIs), verify actual attacker-reachable taint flow, and audit Content-Security-Policy and Trusted Types enforcement for real bypasses rather than header-presence checks, with framework-specific sink guidance loaded progressively.

2026-07-0316

monorepo-package-governance-review

Raishin/vanguard-frontier-agentic

Reviews monorepo task-graph configuration (Turborepo tasks/caching, Nx task pipelines) alongside dependency and lockfile governance (pnpm catalogs, npm overrides, lifecycle-script risk) to prevent false-green CI from stale cache reuse and unpinned supply-chain exposure.

2026-07-0316

nextjs-server-security-review

Raishin/vanguard-frontier-agentic

Statically review Next.js middleware, Server Actions, next.config.js, and environment-variable files for four documented server-side defect classes -- middleware matcher exclusions that silently skip auth on Server Functions, Server Actions missing allowedOrigins CSRF protection, secrets leaked via NEXT_PUBLIC_ prefixes, and SSRF/open-redirect via dangerouslyAllowLocalIP or unvalidated rewrite destinations.

2026-07-0316

product-analytics-experimentation-review

Raishin/vanguard-frontier-agentic

Review frontend analytics instrumentation and A/B or multivariate experiment configurations for event-schema correctness, sample-ratio-mismatch risk, statistically valid stopping rules, and consent-gated privacy compliance before shipping a tracking or experiment change.

2026-07-0316

angular-template-sanitizer-security-review

Raishin/vanguard-frontier-agentic

Statically review Angular templates and components for injection via DomSanitizer bypass calls (bypassSecurityTrustHtml, bypassSecurityTrustUrl, bypassSecurityTrustResourceUrl), unsanitized [innerHTML] bindings, and dynamically bound iframe security attributes such as [attr.sandbox], grounded in Angular's own sanitizer and NG0910 documentation.

2026-07-0316

edge-cache-data-bleed-review

Raishin/vanguard-frontier-agentic

Statically review Next.js App Router caching surfaces -- route-level revalidate exports, cache-boundary directives on server functions reading cookies(), generateStaticParams on personalized routes, and Cache-Control/Vary response headers -- for defects that let one user's authenticated response be cached and served back to a different user.

2026-07-0316

name	i18n-l10n-readiness-review
description	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.
allowed-tools	Read Grep Glob
metadata	{"author":"github: Raishin","version":"0.1.0","updated":"2026-07-02","category":"compliance"}

i18n/l10n Readiness Review

Purpose

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:

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).
Call query-docs for the specific syntax or API behavior before citing it (plural category names, selectordinal syntax, Intl.PluralRules options, locale-matching behavior).
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.
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).
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.