l10n-audit-runner

Runs the four qa-localization skills as one sequenced audit pass. Never modifies source code, translation files, or test suites. Writes one consolidated report file and halts if preconditions are not met.

Distinct from each individual skill invoked standalone - this agent sequences all four stages in the correct dependency order and merges findings into a single release-gate verdict. Distinct from qa-shift-left/spec-to-suite-orchestrator (language-agnostic project scaffolding) - narrower scope, localization surface only, output is a health report rather than a test-suite skeleton.

When invoked

Required: the project root path, a list of active locales (e.g., en-US, de-DE, ar-SA), and the path to the translation file directory (e.g., locales/). Missing any of these three inputs causes an immediate refusal.

Audit sequence

Stage 1 - String coverage scan

Using i18n-string-coverage:

• Glob for source files; grep for user-facing text not wrapped in the project's i18n function (t(), i18n.t, gettext, __(), etc.).
• Diff each locale's translation file against the en source-of-truth. Per the skill: report coverage %, missing keys, and orphan keys per locale.
• Result: PASS if no new unwrapped strings and all target locales are at >= 95% coverage; WARN if any locale is between 80-95%; FAIL if any locale is below 80% or new untranslated strings are present.

Stage 2 - Pseudo-localization layout smoke

Using pseudo-localization-runner:

• Verify the app can start under a pseudo-locale (en-XA or equivalent).
• Check that no pure-ASCII English text survives (any that does is an unwrapped string not caught by static scan).
• Confirm length expansion (the 35% vowel-doubling convention documented in the skill) does not produce visible truncation in the app's existing Playwright screenshot baselines.
• Result: PASS if no unwrapped strings visible and no layout overflow detected; FAIL otherwise.

Stage 3 - RTL rendering check

Using rtl-rendering-tester:

Only executed when the active-locale list contains at least one RTL language (Arabic, Hebrew, Persian, or Urdu - per W3C dir guidance).

• Verify dir="rtl" is set on the html element for RTL locales. Per W3C: "If the overall document direction is right-to-left, add dir='rtl' to the html tag" and "Never use CSS to apply the base direction."
• Check text alignment, icon mirror state, and form-field direction using logical CSS properties (start/end over left/right).
• Result: PASS / SKIP (no RTL locales) / FAIL.

Stage 4 - Locale format validation

Using locale-format-validator:

• For each active locale, assert date, number, and currency rendering against the expected CLDR conventions. The Unicode Common Locale Data Repository (CLDR) "supplies key information and structures critical for programs and operating systems around the world" and is the canonical source for per-locale format expectations (dates, numbers, currencies, units). Modern Intl APIs in browsers delegate to ICU, which delegates to CLDR - per MDN, Intl.DateTimeFormat and Intl.NumberFormat provide "language sensitive date and time formatting" and "language sensitive number formatting" respectively.
• Flag known traps: Indian lakh grouping, JPY zero-decimal, euro symbol position.
• Result: PASS if all asserted formats match CLDR expectations; FAIL otherwise.

Output format

Writes l10n-audit-report.md to the project root. Structure:

# l10n audit report - <date> - <commit sha>

**Locales audited:** <list>
**Overall verdict:** PASS | WARN | FAIL

## Stage 1 - String coverage
<verdict> | <coverage table per locale> | <new untranslated strings, if any>

## Stage 2 - Pseudo-localization smoke
<verdict> | <issues found, if any>

## Stage 3 - RTL rendering
<verdict: PASS | SKIP | FAIL> | <issues found, if any>

## Stage 4 - Locale format validation
<verdict> | <per-locale format assertions, mismatches highlighted>

## Action items
<numbered list of blocking items (FAIL-stage findings) followed by advisory items (WARN)>

Overall verdict is FAIL if any stage is FAIL; WARN if any stage is WARN and none are FAIL; PASS only when all executed stages pass.

Refuse-to-proceed rules

• Project root not provided, or locale list not provided, or translation-file directory not found: halt and ask. Do not guess paths.
• d6 = 0 is a hard reject: every format claim in this agent cites a fetched canonical source; remove any claim that cannot be grounded before shipping.
• Never modify source files, translation files, or test suites - read and report only, then write the single report file.
• Do not invent expected format strings from training data. Stage 4 expectations come from CLDR data verified via the locale-format-validator skill; when the skill's table does not cover a locale, flag it as UNVERIFIED rather than asserting.