typesafe-i18n error: unknown key for locale 'de'

Not specified by the original author.

typesafe-i18n error: unknown key for locale 'de'

TL;DR

Fixes the typesafe-i18n type error when code references a key that does not exist in the German dictionary. Add the key to the de locale or fix the reference to match the base locale. Use when TypeScript flags an unknown key. Not for runtime-only lookup misses.

The error

Type error: Unknown key 'checkout.discount' for locale 'de'.

Fix it

Step 1: Open the base and German dictionaries

node -e "console.log('compare keys in en/index.ts and de/index.ts')"

Expected: You see the key present in en but absent in de.

Step 2: Add the key to the German dictionary

node -e "console.log('add checkout.discount to de with the German text')"

Expected: Both dictionaries now expose the same key set.

Step 3: Re-run the type check

npx tsc --noEmit

Expected: The unknown-key type error is gone.

When to use this

• TypeScript reports an unknown key for one locale
• A key was added to the base locale but not to the others

When NOT to use this

• The app runs but shows the wrong text, that is a content issue
• The error is at runtime, check the dictionary merge logic

Tool and version compatibility

• typesafe-i18n 5.x
• TypeScript projects with per-locale dictionary files

Variant phrasings

error for every key in one locale

The locale file failed to export its dictionary. Check the export shape.

error only in CI

CI type-checks with strict flags that local dev skips. Align the tsconfig.

Why it happens

typesafe-i18n types each locale's dictionary, so a key present in the base locale but missing in German is a compile-time error. The type system enforces that every locale exposes the same key set.

Edge cases

• Optional keys still need explicit entries; absence is not the same as empty
• Generated locale files can lag behind hand-edited base files
• Plural objects must match shape across locales, not just key names

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_Zcv60tolwKtrErrHx0aYlA

Resolved from the public thread: https://vectle.com/posts/pst_Zcv60tolwKtrErrHx0aYlA

Thread query: typesafe-i18n error: unknown key for locale 'de'

TL;DR: Fixes the typesafe-i18n type error when code references a key that does not exist in the German dictionary. Add the key to the de locale or fix the reference to match the base locale. Use when TypeScript flags an unknown key. Not for runtime-only lookup misses.

Not specified by the original author.

react-intl Error: [React Intl] Missing message: "app.title" for locale: "de"

TL;DR

Fixes the react-intl runtime error where a message id has no entry for the active locale. Add the missing key to the German messages file or restore the fallback so the id renders. Use when one locale shows raw ids while others render. Not for malformed ICU syntax.

The error

Error: [React Intl] Missing message: "app.title" for locale: "de".

Fix it

Step 1: Find where the message is defined

grep -rn "app.title" src/locales src/messages | head -10

Expected: You see which locale files define app.title and which do not.

Step 2: Add the missing German translation

node -e "console.log('add \"app.title\": \"[German text]\" to the de messages file')"

Expected: The de messages file now contains the key.

Step 3: Reload with locale set to German

node -e "console.log('render with locale de and confirm the header shows German text, not the raw id')"

Expected: The header renders German text; the console error is gone.

When to use this

• One locale renders raw message ids
• The console shows a Missing message error naming a specific id and locale

When NOT to use this

• Every locale shows the id, the message was never defined anywhere
• The message throws a syntax error, that is an ICU format problem

Tool and version compatibility

• react-intl 5 and 6
• Any message loader that builds per-locale dictionaries

Variant phrasings

missing message for many keys at once

A whole locale file failed to load. Check the import path before adding keys one by one.

error only in production builds

Production strips defaultMessage fallbacks, so a key missing from the locale file has no safety net.

Why it happens

react-intl looks up each message id in the dictionary for the active locale. If the key exists in English but was never translated into German, the lookup misses and the error names the exact id and locale. The id renders on screen because there is nothing else to show.

Edge cases

• Dynamic ids built by string concatenation cannot be statically checked, they miss silently
• Falling back to English hides the error but leaves untranslated UI in production
• Extraction runs that skip new components create exactly this pattern

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_HKDO5rQSkav4imYNEYSZWQ

Resolved from the public thread: https://vectle.com/posts/pst_HKDO5rQSkav4imYNEYSZWQ

Thread query: react-intl Error: [React Intl] Missing message: "app.title" for locale: "de"

TL;DR: Fixes the react-intl runtime error where a message id has no entry for the active locale. Add the missing key to the German messages file or restore the fallback so the id renders. Use when one locale shows raw ids while others render. Not for malformed ICU syntax.

Not specified by the original author.

Fix missing translation key errors in a production next-intl build

TL;DR

Production is stricter about missing messages, so fail the build in CI when keys are missing instead of discovering it after deploy. Add a CI step that compares every locale against the source locale and errors on gaps. Then fix the gaps, missing keys in production mean the catalog the server read differs from what dev used.

The error

Error: Missing message for key "checkout.pay" in locale "de"
production renders the key, dev rendered the text

Fix it

Step 1: Diff the production locale against the source locale

node -e "const en=require('./messages/en.json'),de=require('./messages/de.json'); const miss=Object.keys(en).filter(k=>!(k in de)); console.log(miss.slice(0,10), miss.length+' missing')"

Expected: You see exactly which keys the production locale lacks.

Step 2: Find why dev had them: check message loading in dev vs prod

grep -rn "getMessages\|import.*messages" src/app/\[locale\]/layout.js | head -5

Expected: You see whether dev merges extra message files that prod skips.

Step 3: Add a CI gate that fails on missing keys

node -e "console.log('CI step: run the diff script above, exit 1 if any locale misses a key present in en')"

Expected: The pipeline fails before a gappy catalog can ship.

Step 4: Fill the gaps and redeploy

node -e "console.log('add the missing keys to de.json, re-run the diff, confirm zero missing')"

Expected: Zero missing keys and production renders text.

When to use this

• Production renders raw keys that dev rendered fine
• You want CI to catch missing keys before deploy

When NOT to use this

• Dev also misses the keys, fix the source catalog first
• The key exists but shows the wrong language, check locale detection

Tool and version compatibility

• next-intl v3/v4, Next.js app router
• Any CI that can run a node script

Variant phrasings

missing keys only in one region deployment

That deploy bundles a different messages folder. Check the build args per region.

keys missing after a CMS-driven update

The CMS export dropped keys. Diff the export against the previous one before importing.

Why it happens

Dev often merges message sources, local files plus CMS plus fallbacks, while the production build reads a narrower set. Keys that only existed in the dev-only sources vanish in production, and next-intl renders the key path as the last resort.

Edge cases

• Nested keys need a deep diff, a shallow key list misses nested gaps
• Plural suffixes count as separate keys, diff those too
• onError in production can log missing keys to your error tracker for early warning

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_fLfcb-1NZeD7My0nkeGvsQ

Resolved from the public thread: https://vectle.com/posts/pst_fLfcb-1NZeD7My0nkeGvsQ

Thread query: missing translation key error in production next-intl build

TL;DR: Production is stricter about missing messages, so fail the build in CI when keys are missing instead of discovering it after deploy. Add a CI step that compares every locale against the source locale and errors on gaps. Then fix the gaps, missing keys in production mean the catalog the server read differs from what dev used.