missing-key: missing translation keys
error — fails the build
A key that exists in your source language file is absent from a translation. The most common i18n defect there is: someone added a string on Friday and nobody translated it. Depending on your i18n library, the user sees the raw key, the English fallback, or nothing.
What triggers it
// en.json
{ "cart": "Your cart", "checkout": "Check out" }
// es.json
{ "cart": "Tu carrito" } // "checkout" is missingFixed
// es.json
{ "cart": "Tu carrito", "checkout": "Finalizar compra" }Why it matters
Missing keys are invisible in code review — the source file looks complete — and they ship silently because nothing type-checks locale JSON.
How to fix it
Add the missing key to the translation, or let the same engine fill exactly the failing keys: shipi18n translate fills only what is missing when run with --incremental.
How to silence it
Silence a deliberately-untranslated key with --ignore-keys 'path.to.key' (supports * globs and ns:path form).
Check for this in CI
npx @shipi18n/cli check ./locales -s en
# SARIF for inline PR annotations:
npx @shipi18n/cli check ./locales -s en -r sarif -o shipi18n.sarifThe structural checks need no API key. Findings of this rule link back to this page from the SARIF helpUri.
Related rules
- orphan-key — translation keys that no longer exist in the source
- untranslated — untranslated strings identical to the source
- empty-value — empty translation values