How to Find Missing i18n Keys Across All Your Locale Files

Every internationalized app has the same problem at scale: translation files drift out of sync. A developer adds a new feature with English copy, forgets to update the Japanese locale, and three weeks later a bug report comes in: "The Japanese version shows English text in the checkout flow."

Missing translation keys are one of the most common and most embarrassing localization bugs. They're also entirely preventable with the right tooling.

Why Locale Files Fall Out of Sync

In most development workflows, the English locale file is the source of truth. Developers add new keys there, and translators eventually add the equivalents in other languages. The gap between "developer adds key" and "translator fills it in" is where bugs live.

Common failure modes:

• New feature shipped without translation — The English copy is added and deployed; the PR description says "will translate later." It never gets translated.
• Key renamed during refactor — A developer renames auth.login_button to auth.signin_cta. The old key is deleted. Three translated locale files still reference the old key name.
• New language added mid-product — You add Thai support six months into development. Hundreds of existing keys are missing from the Thai locale.
• Merge conflict resolution — A bad merge conflict resolution accidentally deletes a block of keys from one locale file.

What "Missing Keys" Actually Means

There are two distinct problems worth detecting separately:

• Missing keys — A key exists in the reference locale (usually English) but is completely absent from another locale file. At runtime, the i18n library falls back to the key name or the reference locale, which is usually visible to the user.
• Untranslated keys — A key exists in the target locale but has the exact same value as the reference locale. This often means it was copied as a placeholder and never actually translated.

Both types need to be caught, but they require different actions: a missing key needs to be added, while an untranslated key needs a translator to review it.

How to Check i18n Coverage in CI

For teams with CI pipelines, adding an i18n key coverage check to your PR process prevents missing translations from reaching production. You can run a comparison script that loads all locale files and reports any keys present in the reference locale but absent in any other locale.

A simple check in your CI config might look like:

- name: Check i18n coverage
  run: node scripts/check-i18n.js --reference en.json --locales locales/

If the script exits with a non-zero code, the PR is blocked until the missing keys are filled in or explicitly acknowledged.

Checking Coverage Without Writing Scripts

Not every project has the bandwidth to set up a CI check. For ad-hoc audits — before a release, after a big feature merge, or when adding a new language — you want a tool that lets you upload all your locale files at once and get an immediate report.

A good i18n checker should show you:

• Coverage percentage per language
• Exact keys missing from each locale
• Keys that exist but haven't been translated
• An exportable report (CSV or JSON) to share with your translation team

Detecting Language from Filenames

Most locale files follow naming conventions: en.json, zh-TW.json, ja.yaml, de.json. A good i18n checker auto-detects the language from the filename so you don't have to manually label each file before the analysis.

Check Your i18n Files — Free

Glot's i18n Checker lets you drag and drop all your locale files at once — JSON or YAML — and immediately see a language-by-language coverage breakdown. It auto-detects languages from filenames, shows you exactly which keys are missing or untranslated in each locale, and lets you export the full report as CSV or JSON to send to your translation team.

Everything runs in your browser. Your locale files never leave your machine. It works for any i18n framework: vue-i18n, react-intl, next-i18next, Rails i18n, Flutter ARB, or any other format that uses flat or nested JSON/YAML locale files.

Missing translation keys are a quality problem that compounds over time. The earlier you catch them in the development cycle, the cheaper they are to fix. A five-minute audit before release is far better than a bug report from users in production.