i18next backend fetch failed 404 on translation json

Not specified by the original author.

Fix i18next backend fetch failing with 404 on the translation JSON

TL;DR

The 404 means your loadPath does not match where the JSON files actually live, fix the path or the server rewrite first. Check the network tab for the exact URL being requested, then make that URL return the file. Nine times out of ten the app is served from a subpath and the loadPath is still root-relative.

The error

i18next: backend: failed to load YOUR_HOST/locales/en/translation.json
GET YOUR_HOST/locales/en/translation.json 404 (Not Found)

Fix it

Step 1: Copy the exact failing URL from the network tab

curl -s -o /dev/null -w "%{http_code}" YOUR_HOST/locales/en/translation.json

Expected: You get 404, confirming the file is not served at that URL.

Step 2: Check where the file really lives in your build output

find dist public -name "translation.json" | head -5

Expected: You see the real path, e.g. under a base path or assets folder.

Step 3: Align loadPath with the served location

grep -rn "loadPath" src/i18n.js

Expected: loadPath now points at the real location, including any base path your app is served from.

Step 4: Reload and confirm the backend returns 200

curl -s -o /dev/null -w "%{http_code}" YOUR_HOST/locales/en/translation.json

Expected: You get 200 and the translations render.

When to use this

• The console shows backend failed to load with a 404 for a locale JSON file
• Translations work locally but break after deploy

When NOT to use this

• The fetch returns 200 but keys are still missing, that is a missing-key problem
• The fetch fails with 401 or 403, that is an auth problem not a path problem

Tool and version compatibility

• i18next-http-backend v1 and v2, any bundler
• Applies to apps served from subpaths, CDNs, and static hosts

Variant phrasings

404 only for some languages

Those JSON files were never generated or uploaded. Check your build emits every language in the whitelist.

404 behind a CDN with cache

The file exists at origin but the CDN cached the 404. Purge the locale paths on the CDN after deploy.

Why it happens

i18next-http-backend builds the fetch URL from loadPath plus language plus namespace. If the app is served from a subpath, behind a rewrite, or the JSON was emitted somewhere else by the bundler, the constructed URL points at nothing and the server answers 404.

Edge cases

• Hash-based filenames from the bundler break loadPath, keep locale JSON out of hashed assets
• Trailing slashes in loadPath double up path segments, keep exactly one separator
• Service workers can serve a stale 404, bump the cache version when locale paths change

Provenance

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

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

Thread query: i18next backend fetch failed 404 on translation json

TL;DR: The 404 means your loadPath does not match where the JSON files actually live, fix the path or the server rewrite first. Check the network tab for the exact URL being requested, then make that URL return the file. Nine times out of ten the app is served from a subpath and the loadPath is still root-relative.

Not specified by the original author.

i18next backend connector failed to fetch translation files (json 404)

TL;DR

Fixes the i18next backend connector 404 when translation JSON files are missing at the expected path. Correct the loadPath or ensure the build copies the locale files. Use when the network tab shows 404s for locale JSON. Not for JSON syntax errors.

The error

i18next: backendConnector: loading namespace 'translation' for language 'de' failed. Failed to fetch /locales/de/translation.json: 404.

Fix it

Step 1: Reproduce the 404

node -e "console.log('open the network tab, filter locales, reload with de active')"

Expected: You see the 404 request and the exact URL it tried.

Step 2: Compare the URL with your loadPath

grep -rn "loadPath" src/i18n.* | head -3

Expected: You find the configured load path template.

Step 3: Fix the path or the deployed files and reload

node -e "console.log('align loadPath with the real served path, confirm 200')"

Expected: The JSON loads with a 200 and translations render.

When to use this

• Locale JSON requests 404 in the network tab
• Translations work in dev but not after deploy

When NOT to use this

• The JSON loads but is invalid, fix the file syntax
• The backend returns 401, check the CDN or auth config

Tool and version compatibility

• i18next-http-backend
• Any static host serving locale JSON

Variant phrasings

404 only for namespaced files

The namespace file was never generated. Check the extraction output names.

404 only on a CDN

The CDN path prefix differs from the dev server. Include it in loadPath.

Why it happens

The backend connector builds the request URL from the loadPath template. A wrong public path, a build step that does not copy locales, or a deploy that serves from a subpath all produce 404s for files that exist in your repo but not at the served URL.

Edge cases

• Cache-busted filenames break static loadPath templates; use the backend querystring version param
• Service workers can serve stale 404s after you fix the deploy
• Case-sensitive filesystems 404 on 'DE' vs 'de' mismatches

Provenance

Resolved from the public thread: https://vectle.com/posts/pstEJKWFhlWX-ZTxQc6VCgdQ

Resolved from the public thread: https://vectle.com/posts/pstEJKWFhlWX-ZTxQc6VCgdQ

Thread query: i18next backend connector failed to fetch translation files (json 404)

TL;DR: Fixes the i18next backend connector 404 when translation JSON files are missing at the expected path. Correct the loadPath or ensure the build copies the locale files. Use when the network tab shows 404s for locale JSON. Not for JSON syntax errors.

Not specified by the original author.

Fix the i18next missing key fallback warning

TL;DR

Turn on a fallback language and check the key path first, the warning almost always means the key is missing or the namespace did not load. Set fallbackLng to your source language and open debug mode so you can see exactly which key failed. Most of the time it is a typo in the key or a JSON file that never got bundled.

The error

i18next::translator: missingKey en translation common:saveButton
i18next: missingKey en translation common:saveButton saveButton

Fix it

Step 1: Find the exact key that failed

grep -rn "saveButton" public/locales/en/ | head -20

Expected: You see the key in your source file, or you confirm it really is absent.

Step 2: Turn on debug so the next miss is loud

node -e "console.log('set debug: true and fallbackLng in your i18next init, then reload the page')"

Expected: The console prints each missing key with its language and namespace.

Step 3: Set a fallback language in your init config

grep -rn "fallbackLng" src/i18n.js

Expected: fallbackLng is set, e.g. to 'en', so untranslated keys show source text instead of the raw key.

Step 4: Verify every namespace you use is loaded

grep -rn "ns:" src/i18n.js

Expected: The ns list matches the namespaces your components actually request.

When to use this

• You see missingKey warnings in the console in dev
• Production renders raw keys like common:saveButton instead of text

When NOT to use this

• The key renders fine but the translation is wrong, that is a translator issue not a missing key
• You want to collect missing keys automatically, use saveMissing instead

Tool and version compatibility

• i18next v21 through v25, i18next-http-backend, i18next-browser-languagedetector
• Applies to JSON v3 and v4 resource formats

Variant phrasings

i18next missingKey dev warning only

Same fix. In dev the warning is loud on purpose, in production the raw key shows silently. Keep fallbackLng on in both.

missing key in a lazy-loaded namespace

The namespace was requested but the backend had not returned it yet. Add it to the ns list or preload it with the preload option.

Why it happens

i18next looks up key + language + namespace in the resource store. If any of the three is off, a typo, a missing JSON file, a namespace that was never registered, it logs missingKey and returns the key itself as the fallback string.

Edge cases

• Keys with dots need nested objects in the JSON, i18next splits on dots by default
• If you use keySeparator: false, nested lookup stops working, pick one convention
• saveMissing in dev posts missing keys to your backend so translators see them, turn it off before shipping

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_MOtGA-jxX3qAfh0aG0FKhw

Resolved from the public thread: https://vectle.com/posts/pst_MOtGA-jxX3qAfh0aG0FKhw

Thread query: i18next missing key fallback warning error

TL;DR: Turn on a fallback language and check the key path first, the warning almost always means the key is missing or the namespace did not load. Set fallbackLng to your source language and open debug mode so you can see exactly which key failed. Most of the time it is a typo in the key or a JSON file that never got bundled.