i18next language detector failed to detect locale from path

Not specified by the original author.

i18next language detector failed to detect locale from path

TL;DR

Fixes i18next-browser-languagedetector returning no locale from the URL path. Configure the path detector order and the lookup pattern, or fix the route prefix. Use when the detector falls back to default instead of reading the path. Not for cookie or navigator detection issues.

The error

i18next: languageDetector: failed to detect language from path '/app/home', falling back to 'en'.

Fix it

Step 1: Inspect the detector order

node -e "console.log('check the order array: path should come before navigator')"

Expected: You see which detectors run and in what order.

Step 2: Check the path lookup pattern

node -e "console.log('lookup pattern must match /:lng/... route prefixes')"

Expected: You confirm the route prefix shape the detector expects.

Step 3: Fix the order or the route prefix and reload

node -e "console.log('visit /de/app/home and confirm the detector picks de')"

Expected: The detector reads the locale from the path.

When to use this

• The detector ignores the locale in the URL path
• Deep links always land in the default language

When NOT to use this

• Detection from cookies fails, check the cookie name config
• The browser language is picked instead, reorder the detectors

Tool and version compatibility

• i18next-browser-languagedetector 7
• i18next 22 and 23

Variant phrasings

detector picks the path but the app ignores it

The app reads locale from state, not from i18next. Sync them on route change.

works locally but not in production

The production server strips the locale prefix before the app sees it.

Why it happens

The path detector matches the URL against a lookup pattern. If your routes use a prefix the pattern does not expect, or another detector runs first and wins, detection from the path never happens and the fallback language is used.

Edge cases

• Hash-based routing hides the path from the detector entirely
• Trailing slashes can break strict pattern matches
• Subdomain detection and path detection conflict when both are enabled

Provenance

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

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

Thread query: i18next language detector failed to detect locale from path

TL;DR: Fixes i18next-browser-languagedetector returning no locale from the URL path. Configure the path detector order and the lookup pattern, or fix the route prefix. Use when the detector falls back to default instead of reading the path. Not for cookie or navigator detection issues.

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.