i18n: Wrong locale on getServerSideProps when using next.config.js rewrite

[jpedroribeiro]

Verify canary release

• 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 PREEMPT_DYNAMIC Sun Aug  6 20:05:33 UTC 2023
    Binaries:
      Node: 18.14.2
      npm: 9.5.0
      Yarn: 1.22.19
      pnpm: N/A
    Relevant Packages:
      next: 13.4.14-canary.5
      eslint-config-next: 13.4.12
      react: 18.2.0
      react-dom: 18.2.0
      typescript: 5.0.4
    Next.js Config:
      output: N/A

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

Data fetching (gS(S)P, getInitialProps), Internationalization (i18n), Routing (next/router, next/navigation, next/link)

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

https://codesandbox.io/p/sandbox/routing-i18n-bug-gfc94t?file=%2Fnext.config.js%3A1%2C1

To Reproduce

If you click on "Link to Page1 PT" you will see that both props and router will output the correct locale, pt.

However, if you click on "Link to Pagina1 (Redirect to Page1) PT", props will be the defaultLocale (which is en), whereas router be the expected locale, pt.

The only difference between both links is that the second one works via a next.config.js rewrite property.

Describe the Bug

getServerSideProps is not getting the correct locale if the route was using a next.config.js rewrite.

This was working as expected up until and including version 13.2.5-canary.16. On version 13.2.5-canary.17 it has stopped working and has not being fixed yet (example on CodeSandbox is using the latest version 13.4.14-canary.5).

Expected Behavior

getServerSideProps should have the correct locale value regardless of the routing strategy.

Which browser are you using? (if relevant)

No response

How are you deploying your application? (if relevant)

No response

[iljamulders]

Same as:

#51923
#49883
#51695

This has been a bug for 4+ months, and everyone that uses i18n and rewrites/redirects is at a standstill...
13.2.4 is the last working version.

[pmcflepage]

Huge thanks to @iljamulders I finally solve it returning to 13.2.4!

For me, problem was getServerSideProps({locale}) was always returning my default locale and not my current one

[przemekga]

same as #50498

[vinnycodes]

Thank you @iljamulders
This is exactly what we needed.

[dejanstrancar]

@iljamulders thanks for the heads up. Looks like last working version for us is [email protected] and next@>=13.4.13 breaks it.

[jpedroribeiro]

I've updated my example to use the latest version 13.5.1 and it seems to have fixed the issue. https://codesandbox.io/p/sandbox/routing-i18n-bug-gfc94t?file=%2Fpackage.json%3A18%2C20

[raRaRa]

Still broken for me in 13.5.1 if middleware is being used, even though the middleware is not even triggered for the paths. It just needs to exist. Ref: #54217

[jpedroribeiro]

@raRaRa I had to remove matcher from Middleware and use Conditional Statement instead.

[raRaRa]

I see, that makes the middleware run for every URL even though it's not needed (more costly AFAIK). But either way this is still a bug.

[jpedroribeiro]

Yeah you're right @raRaRa, leaving out the matcher is not an optimal solution.

[albertodeago]

Have you tried on latest version? I think this is not happening anymore on next 14.1.0

[tcg]

I think I'm running into this on 14.2.4. Found this by searching.

I have a link like /fr/path/to/stuff or /de/path/to/stuff. When I visit it directly, the locale in the getServerSideProps context is fr or de, respectively.

But clicking a link on the page, whose destination is e.g., href="/fr/path/to/otherstuff", the locale provided to getServerSideProps is the default locale (en).

This seems to be the most relevant issue. So just pitching a vote here 😅

I just discovered this, so haven't yet had time to see if there are open PRs related to this.

UPDATE: As mentioned on related tickets, if I delete the middleware.ts file, the behavior seems to be resolved.

Wut.

[tcg]

I tried out #61561 with yarn patch, and it appears to resolve this issue.

I see there are some test failures there, but I'm new to Next internals, so don't know if that's flake or legit.

[tcg]

@raRaRa I had to remove matcher from Middleware and use Conditional Statement instead.

Removing matcher (actually, the whole config export, which only contained matcher) appears to resolve this issue for me as well!

Thankfully, we don't appear to require that. Our conditional check is pretty lightweight as-is.

[StokleyO]

Is there any resolution on this that doesn't require subbing out the matcher for Conditional Statements?

[StokleyO]

@raRaRa I had to remove matcher from Middleware and use Conditional Statement instead.

do you have an example of what it looks like to replace a matcher with a conditional statement?

[StokleyO]

Solution I found: add the route paths that use getServerSideProps (where the locale mismatch happens) to your config matcher array in middleware.js. This solved the problem for me and allowed me to continue using my config matchers