Middleware cause prefetch for dynamic pages fail when changing locale

[VincentDugard]

Link to the code that reproduces this issue or a replay of the bug

https://github.com/VincentDugard/next-i18-next-bug

To Reproduce

1. npm i
2. npm run dev
3. navigate to /something
4. navigate to "de" locale using link "change locale to de"

Current vs. Expected behavior

Following previous steps you should navigate to /de url, but this doesn't change page content. The client seems to send prefetch query as expected but the server messes with locale parameter. If you look at server console, localization debug prints only "en" locale but never "de".

If you remove middleware.ts, everything works as expected (middleware is empty, so it do nothing)

There seems to be a conflict between middleware and localized dynamic route with prefetch request.

Verify canary release

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

Provide environment information

Operating System:
      Platform: linux
      Arch: x64
      Version: #1 SMP Debian 5.10.158-2 (2022-12-13)
    Binaries:
      Node: 19.1.0
      npm: 8.19.3
      Yarn: 3.3.0
      pnpm: 8.7.1
    Relevant Packages:
      next: 13.4.20-canary.16
      eslint-config-next: 13.4.19
      react: 18.2.0
      react-dom: 18.2.0
      typescript: 5.2.2
    Next.js Config:
      output: N/A

Which area(s) are affected? (Select all that apply)

Middleware / Edge (API routes, runtime)

Additional context

I was trying to prefix default locale as explained in the offcial next.js doc but could'nt get this working because of this bug.

[vegahar]

I'm also experiencing something on localhost with the default localized dynamic route using middleware. I end up in a endless redirect loop when trying to navigate, but when visiting the url directly it works.

Removing the middleware is also fixing the issue for me so it must be something with the development server.

Luckily this works on a deployed project in vercel

[raRaRa]

Same as https://github.com/vercel/next.js/issues/54217 I believe

[vinnycodes]

Our team is experiencing similar issues causing breaks all throughout our site. The following solution resolved it for us

https://github.com/vercel/next.js/issues/53988#issuecomment-1680201847

[abumostafa]

Faced the same issue and tracked it down. apparently, the query.__nextLocale variable is always set to the default locale unless overwritten during the request handling.

In my case the fix was to set the __nextLocale variable in line next/src/server/lib/router-utils/resolve-routes.ts#L256 by localeResult.locale value and it worked.

Here is how my fix looks like

@@ -158,6 +158,7 @@ function getResolveRoutes(fsChecker, config, opts, renderWorkers, renderWorkerOp
                 curPathname = (curPathname == null ? void 0 : curPathname.substring(config.basePath.length)) || "/";
             }
             const localeResult = fsChecker.handleLocale(curPathname || "");
+            if (localeResult) parsedUrl.query.__nextLocale = localeResult.locale
             for (const route of dynamicRoutes){

P.S I do not know the consequences but this was a quick fix until an actual fix takes place P.S I am not sure this is relevant but I am using the pages router

[kjxbyz]

same issue

https://github.com/kjxbyz/next-pages-dynamic-route-i18next-issue

[kjxbyz]

"next": "13.4.12",
"eslint-config-next": "13.4.12"

It works for me.