i18n-parity

Detects missing, orphaned, and hardcoded translation strings across locale files.

15|22|Updated May 5, 2024
One-click install
npx skills add https://github.com/brayandiazc/project-starter-template-es-ai --skill i18n-parity-brayandiazc
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: i18n-parity
Source: https://github.com/brayandiazc/project-starter-template-es-ai/tree/main/.claude/skills/i18n-parity
Command: npx skills add https://github.com/brayandiazc/project-starter-template-es-ai --skill i18n-parity-brayandiazc

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes scripts (resource) components.

What problem does it solve? Translation files drift out of sync as products evolve: some languages miss keys, others contain orphaned keys, and developers hardcode user-facing strings directly in the UI. This Skill audits internationalization parity so every locale stays consistent with the reference language. ## Core Features & Use Cases - Key Parity Comparison: Compares each locale against the reference language and reports missing keys, orphaned keys, and empty or untranslated values. - Hardcoded String Detection: Scans UI source code for user-facing strings that bypass the i18n system, listing each with file and line number. - Convention-Driven: Reads the project's docs/conventions/i18n.md to respect the actual locale file format, directory layout, and translation rules. - Use Case: Before a release, ask for an i18n audit to confirm Spanish and French locales contain every key present in the English reference and that no hardcoded labels slipped into new components. ## Quick Start Ask the assistant to review the project's translations and check whether all languages are synchronized with the reference locale.

Frequently Asked Questions about i18n-parity

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I check for missing translation keys across languages?▼

Treat one locale as the reference source of truth, then compare the key set of every other locale against it. Keys present in the reference but absent elsewhere are reported as missing; keys absent from the reference are reported as orphaned.

How to find hardcoded strings that should be translated?▼

Scan the UI source code for user-facing string literals that bypass the i18n system, following the project's translation rules. Each occurrence is listed with its file and line number so a developer can route it through the translation layer.

Does this i18n check work with JSON, YAML, or .po locale files?▼

The audit adapts to whatever format the project uses by reading the i18n conventions document first. The bundled check.sh helper is a stub that must be adapted to the actual format, such as JSON, YAML, .po, .arb, or .properties.

Can the tool automatically translate missing keys?▼

No. It deliberately does not auto-translate or invent translation text. It reports gaps so a human translator can fill them, avoiding low-quality machine-generated copy in production locales.

Why does the i18n parity script exit successfully without checking anything?▼

The included check.sh is a placeholder stub that prints a notice and exits with code zero. You must implement the comparison logic for your locale format and directory structure before relying on its output.