Use when adding a new supported application UI language or locale family to all-api-hub, including i18next resources, language selection and normalization, browser extension manifest locales, date localization or natural-language date parsing, documentation-link fallback, locale completeness tests, and validation.
SkillScore68Maintained
Automatic
◆Translation & Localization pack
Last verified 9/9/2026
What it changes
Passed 12 of 18 test cases with the skill, and 6 of 18 without it.
Without skill32%
With skill68%
Checks it passed that the model alone missed
Runs git status --porcelain before making modifications.
Defines the language list constant in src/constants/i18n.ts.
Derives supported language types from SUPPORTED_UI_LANGUAGES.
and 7 more in the full report
8 fixed7 passed either way7 still failing0 broke
Pass-rate lift
+36 pp
Tokens
+29%
Agent turns
0%
Response time
-36%
Model gemini-3.6-flashMeasured 9/9/2026v215 of 22 cases passed with skill · 18 comparable
Tokens, turns and time describe resource use, not a dollar price.
See it in action
One of 8 test cases the skill fixed. Same model, same prompt, with and without the skill.
1 of 8
Prompt
Before starting work on adding Dutch (nl) localization, what command should be run first to ensure we do not touch unrelated index changes or dirty working tree state?
What was checked, without and with the skill
Checked
Without skill
With skill
Runs git status --porcelain before making modifications.
Missed
Passed
case-18 · gemini-3.6-flash · 9/9/2026 · answers are capped and redacted
What's inside
The instructions your model reads when the skill loads.
SKILL.md67 linessingle file
Add App Language
Core principle
Treat a new language as a cross-runtime compatibility feature. Define one locale contract, then make application resources, browser manifests, auxiliary locale libraries, and tests agree with it.
Workflow
Establish the current baseline and locale contract.
Run git status --porcelain and preserve unrelated work and index state.
Search for locale-keyed runtime data and fallback resolvers outside src/locales/, including public JSON. Use the owning project workflow for independently managed surfaces instead of changing their translation or fallback contract incidentally.
Use current code, directories, and tests as the source of truth. Treat hard-coded language or namespace counts in prose as potentially stale.
Decide the canonical BCP 47 application tag, accepted browser or stored aliases, language-family and regional fallback behavior, Chrome underscore locale identifiers, documentation fallback, and available Day.js, date-fns, and natural-date parser support.
Ask only about unresolved choices that materially affect stored preferences, regional resource sharing, manifest coverage, documentation scope, or new dependencies. Reuse user decisions and established locale conventions; continue independent work while a decision is pending.
Check existing focused coverage and characterize uncovered behavior before implementation. The following are coverage targets, not a requirement to edit every test file.
Cover alias normalization and startup language resolution in tests/utils/i18nLanguage.test.ts.
Cover selection, accessible names, and persisted preference behavior in tests/components/LanguageSwitcher.test.tsx.
Cover resource discovery and Day.js mapping in tests/utils/i18nResources.test.ts.
Cover documentation routing or English fallback in tests/utils/docsLocale.test.ts.
Cover date-fns display localization when the picker has a matching locale. Evaluate target-language natural input by default; when the current mature parser dependency supports it, add representative valid and invalid parsing tests in the same task.
Extend tests/utils/i18nLocaleValidation.test.ts only for a stable invariant not already covered by its generic supported-language loops, such as required manifest aliases or locale-specific plural constraints.
Implement the complete integration surface.
Add the canonical runtime constant and derive supported-language types from SUPPORTED_UI_LANGUAGES.
Normalize the agreed language aliases at the language boundary; keep downstream consumers on the canonical tag.
Add the switcher option and its label and accessible name in every existing application locale.
Create src/locales/<app-tag>/ with every current namespace and normalized key family. Preserve interpolation tokens and markup, and implement every cardinal plural category reported by Intl.PluralRules(<app-tag>).
Keep src/utils/i18n/resources.ts glob-driven unless the resource-loading contract itself must change.
Register the Day.js locale in each runtime that initializes i18n: extension pages, background, and content. Map the closest date-fns locale when the date picker supports the language.
Wire available locale support in the existing mature natural-date parser when runtime and bundle impact remain low. If support requires another dependency or a new parsing capability, report the limitation and recommend an option; implement it only when that expansion is authorized. Custom parsing is reserved for an authorized, reproduced gap the library cannot cover.
Create complete src/public/_locales/<chrome_locale>/messages.json resources. Keep application tags hyphenated and Chrome locale identifiers underscored; add regional alias directories only when the browser locale contract requires them.
Map documentation links to an actually shipped docs locale. Keep unsupported documentation languages on the established fallback instead of creating translated docs as part of an app-locale task.
Give every discovered locale-keyed production surface the intended translation or an explicit suitable fallback. Use its project skill only when that independently owned surface actually needs changes, not merely because it exists.
Validate translation and integration integrity.
Run the focused normalization, switcher, resource, docs, and locale-validation tests. Add the date-picker suites when date behavior changed.
Require passing i18n:status and i18n:extract:ci evidence for the complete new locale. Reuse these checks from an imminent commit hook; run them manually when no hook will run or earlier feedback is needed, rather than requiring a duplicate pre-handoff run.
Inspect the task-scoped locale diff and account for every unexpected deletion, plural rewrite, empty value, source-language copy, or key-shaped translation value.