Getting wrong param when consuming locale prop from layout

[DawnMD]

It started happening recently, I saw that when I use the locale param in root layout, sometimes mostly in dev I'm getting _next as locale instead of the mentioned locales! I double-checked the implementation with an example and everything seems normal. But during production build or some few refreshes it works as expected! Immediately after the last one above^

[i18nexus]

That's interesting. Can you try adding this to the top of your RootLayout component:

import {notFound} from 'next/navigation';
...
if (!i18nConfig.locales.includes(locale)) {
  notFound();
}

I'm thinking your problem may be related to issue #55 where the solution is to do the above.

[DawnMD]

Is it because I'm serving a file from the public directory? 🤔 Coz this recently started happening, I don't remember I've seen this error before!

[i18nexus]

It's really hard to say. Next seems to be trying to render a page at your-site.com/_next/... But usually this should go to the _next config directory. It shouldn't be trying to render you site at that route. Something may be misconfigured.

Regardless, I would still add the code I sent above. We're going to be adding that snippet to our example projects.

[DawnMD]

Alright, I added the code. It seems like the error is not coming anymore. Do you know if there are any downsides to this workaround? PS: I do have redirects added to the next config!

[i18nexus]

It's not really a "workaround". It really should be there in everyone's projects, which is why we're going to update our example projects with it.

Let me try to explain in more detail what's going on:

The first segment of the pathname is a dynamic segment ([locale]), so Next treats any value at the start of the pathname as a valid value. The next-i18n-router middleware, however, DOES validate if it's a valid locale. If the first segment in the pathname is not a supported locale, the middleware will trigger a 404. That's why if you put an unsupported locale or "asdfg" as the first segment of the pathname, you will get a 404. The next-i18n-router middleware is handling this.

HOWEVER, if a request bypasses the middleware due to the middleware's matcher config, then obviously no 404 is triggered. If you look at the regex in our matcher config, it is set to bypass the middleware if the first segment in the pathname is "_next". Since the middleware is not handling 404's for these requests, we need to handle this within our layout.

Long story short, Next is expecting a 404 for any "_next" prefixed pathnames. Hope that makes sense 🙂

[DawnMD]

Okay, now I understand why I'm seeing that issue! Makes sense! Thank you for pointing it out 😊

[DawnMD]

Also, I can open up a PR for adding this snippet to the example dir! Let me know if you want me to!

[i18nexus]

Please do 🙂 We said we were going to do this in issue #55 but it seems to have fallen between the cracks