Translations not showing on Next Link click using 'en' locale (i18next loses instance) only on Vercel

[miguel-sg-dev]

Verify canary release

• [x] I verified that the issue exists in the latest Next.js canary release

Provide environment information

Operating System:
      Platform: win32
      Arch: x64
      Version: Windows 10 Home
Binaries:
      Node: 18.8.0
      npm: N/A
      Yarn: N/A
      pnpm: N/A
Relevant packages:
      next: 13.4.1
      eslint-config-next: N/A
      react: 18.2.0
      react-dom: 18.2.0

Which area(s) of Next.js are affected? (leave empty if unsure)

Internationalization (i18n), Middleware / Edge (API routes, runtime)

Link to the code that reproduces this issue

https://github.com/miguel-sg-dev/next-app

To Reproduce

Go to https://next-app-delta-azure.vercel.app/en and click on the FAQ link. The new page does not load the translations

Describe the Bug

When I'm on the en locale (https://next-app-delta-azure.vercel.app/en) and click on the FAQ link, it should load the faq page with the translated title but instead it shows the key "faq.title".

The only message I get in the console after I click on the link is this warning:

Couldn't try on canary version because it conflicts with the next-i18next dependency.

This issue just happens on Vercel. When I run the build and start the production server locally it works fine.

Expected Behavior

When clicking on the Link, the page should load with the translations, as it does when you click from https://next-app-delta-azure.vercel.app/ or https://next-app-delta-azure.vercel.app/es

Which browser are you using? (if relevant)

No response

How are you deploying your application? (if relevant)

Vercel

[JesseKoldewijn]

Hey man, I'm not sure where you got the "ns" key in the next config from (since I've never seen this specific setup before. But what I can see is that i18n is getting confused in your project probably because of the "default" locale. As far as I know all entries in locale are supposed to be existing locales. So in your case to achieve this setup you got you should go for the following.

Set either "en" or "es" as default language (enable language detection if you want). And remove "default" from locales and defaultLocale in your setup. This should work from what I remember from my last couple of projects using i18n.

If docs are needed you can check: https://nextjs.org/docs/pages/building-your-application/routing/internationalization

[miguel-sg-dev]

Hey @JesseKoldewijn thank you for answering.

I'm using the default prefix locale, I can't do what you suggested because if I went to https://next-app-delta-azure.vercel.app/preguntas-frecuentes (without the "/es") it wouldn't modify the url and add the es locale as it does right now.

[JesseKoldewijn]

Hey @JesseKoldewijn thank you for answering.

I'm using the default prefix locale, I can't do what you suggested because if I went to https://next-app-delta-azure.vercel.app/preguntas-frecuentes (without the "/es") it wouldn't modify the url and add the es locale as it does right now.

Ah gotcha, wouldn't the auto detection handle that rewrite?

[JesseKoldewijn]

if not, the only other way I would see is creating a middleware that checks for static route paths and matches + rewites all the requests to the correct locale if the route is found.

[miguel-sg-dev]

Hey @JesseKoldewijn thank you for answering. I'm using the default prefix locale, I can't do what you suggested because if I went to https://next-app-delta-azure.vercel.app/preguntas-frecuentes (without the "/es") it wouldn't modify the url and add the es locale as it does right now.

Ah gotcha, wouldn't the auto detection handle that rewrite?

It doesn't :/

[miguel-sg-dev]

if not, the only other way I would see is creating a middleware that checks for static route paths and matches + rewites all the requests to the correct locale if the route is found.

Yeah but it's weird because it just happens on Vercel, when I do the build and start the server locally it works fine.

[JesseKoldewijn]

if not, the only other way I would see is creating a middleware that checks for static route paths and matches + rewites all the requests to the correct locale if the route is found.

Yeah but it's weird because it just happens on Vercel, when I do the build and start the server it works fine.

funny enough when I visit "https://next-app-delta-azure.vercel.app/preguntas-frecuentes" I do get redirected to "https://next-app-delta-azure.vercel.app/es/preguntas-frecuentes"

[JesseKoldewijn]

But that's probably because the default locale uses spanish for me while my system and browser locale is en-US

[JesseKoldewijn]

and if I go to "https://next-app-delta-azure.vercel.app/en/faq" it does show the locale for me but not on initial route. it shows it after a refresh weirdly enough.

[JesseKoldewijn]

I think if you replace your current middleware with the one shown in the docs it should work fine (and you can replace the fallback "en" to "es" if you want)

[JesseKoldewijn]

Alright, from what I could muster it seems like it has something to do with the combination of your rewrites in the next config and your middleware next to it.

[JesseKoldewijn]

it seems to lose the i18n client when going through a soft route. Maybe a good idea to specify this or something simular in the issue title? 👍

[miguel-sg-dev]

The issue still persists after removing redirects (thought maybe that could be conflicting) and updating the middleware as the documentation one.

[Linus-Boehm]

Any idea how to reproduce that locally? We have the same issue and to investigate which part of our setup is causing there trouble, it would be helpful to be able to debug that locally. When I use yarn build and yarn start the issues seems not to be there. Can anybody help me understand why this is only broken, when the app gets deployed to vercel?

[JesseKoldewijn]

As far as I've noticed when previously reproducing this it seemed like it happens both on local and deployed when having the combination of i18n and middleware. Haven't looked into this recently so not sure if this is still an issue on the latest canary release.

[Linus-Boehm]

TY @JesseKoldewijn I try to get a minimal reproduction up and running, to make sure this is actually the same issue

[aleehedl]

Any updates on this? The issue still persists with the latest version of Next.js and next-i18next.