Route group + [...rest] populating locale with non-locale values

[MichalMoravik]

Description

Hey!

When you use route group (...) folder in Next app router + [...rest] to serve not found pages, it will start populating locale with values that are not locale. When you run the repro repo code, you'll probably see something like this:

*****************
WebLayout locale: en
*****************
*****************
WebLayout locale: .well-known
*****************

This is only repro, it can get very out of the hand, for example these logs are from my prod:

> next start -p 3001

 

   ▲ Next.js 15.3.2

   - Local:        http://localhost:3001/

   - Network:      http://10.250.18.70:3001/

 

 ✓ Starting...

 ✓ Ready in 869ms

Locale .well-known is not supported. Defaulting to 'sk'

Locale .well-known is not supported. Defaulting to 'sk'

Locale .well-known is not supported. Defaulting to 'sk'

Locale _next is not supported. Defaulting to 'sk'

Locale _next is not supported. Defaulting to 'sk'

Locale _next is not supported. Defaulting to 'sk'

Locale _next is not supported. Defaulting to 'sk'

Locale _next is not supported. Defaulting to 'sk'

Locale _next is not supported. Defaulting to 'sk'

Locale apple-touch-icon-precomposed.png is not supported. Defaulting to 'sk'

Locale apple-touch-icon-precomposed.png is not supported. Defaulting to 'sk'

Locale apple-touch-icon-precomposed.png is not supported. Defaulting to 'sk'

Locale apple-touch-icon.png is not supported. Defaulting to 'sk'

Locale apple-touch-icon.png is not supported. Defaulting to 'sk'

Locale apple-touch-icon.png is not supported. Defaulting to 'sk'

Locale _next is not supported. Defaulting to 'sk'

Locale _next is not supported. Defaulting to 'sk'

Locale _next is not supported. Defaulting to 'sk'

Locale _next is not supported. Defaulting to 'sk'

Locale _next is not supported. Defaulting to 'sk'

Locale _next is not supported. Defaulting to 'sk'

Verifications

• I've verified that the problem I'm experiencing isn't covered in the docs.
• I've searched for similar, existing issues on GitHub and Stack Overflow.
• I've compared my app to a working example to look for differences.

Mandatory reproduction URL

https://github.com/MichalMoravik/next-intl-bug

Reproduction description

Steps to reproduce:

1. Open reproduction
2. npm run dev OR npm run build and then npm run start
3. Navigate to localhost:3008/en and you'll see the incorrect locale in the server console logs

Note: if you do not see that, try removing browser cache and then refresh again

Expected behaviour

Well I expect the locale to either be "en" or "sk" (in my prod), not other values such as apple-touch-icon.png or .well-known.

This is causing a flood of error logs in my production. It seems to NOT affect the web functioning, at least not something users can see. Maybe it causes issues in the background, too many re-renders or something similar, I don't know about that part.

Thank you for taking your time to look at this!! 🙏

[MichalMoravik]

Alright, when I move the [...rest] folder with the not-found file one level up (where LocaleLayout is), the bug seems to disappear.

But the problem is, that I want this "catch all not found" mechanism to work underneath (web) route group as the layout.tsx inside (web) has the styling and additional components (skeleton) I need.

Any idea what is happening? This is interesting.

[amannn]

Your browser can request files like /.well-known/appspecific/com.chrome.devtools.json automatically (source). In this case, if you don't support this file, you should return a 404 (which is what you're doing).

You'll see this value in your logs because you're only validating the received locale in [locale]/layout.tsx. Layouts and pages render in parallel, therefore your log entry in (web)/layout.tsx might see an invalid [locale] value before the validation triggers notFound().

If you need the locale in other places in your app, I'd suggest to read from getLocale.

More information on parallel rendering of layouts and pages in Next.js and validation: #1722

I'll move this to a discussion since it's a usage question.

[MichalMoravik]

Hey @amannn, thanks for the answer.

I've added the com.chrome.devtools.json file locally and that solved the 404 I saw locally, thanks a lot for adding the link.

I'm not sure I fully understand the second part of your answer - locale. It's unclear to me when I should grab locale from the params and when I should call getLocale.

More context:

Until recently, I was grabbing the locale from params only in the LocaleLayout ([locale]/layout.tsx) and in metadata of pages, e.g.:

export const generateMetadata = async ({
  params,
}: {
  params: Promise<{ locale: string }>;
}): Promise<Metadata> => {
  const { locale } = await params;

  const tm = await getTranslations({ locale, namespace: 'Metadata' });

  return {
    title: tm('checkout'),
  };
};

My pages and other components used (and still use) await getLocale (for async) and useLocale (for client and non-async).

As I'm growing and adding this new route group (in the example it's (web)), I made another locale inside this route group where I just grab the locale from the params, like I do in the LocaleLayout, mostly because I copied some of its parts to this new locale.

---

Are you saying that I should use await getLocale in the WebLocale instead (and remove the line that grabs it from params)?

If so, what's the difference? When should one use the locale from params vs from the function/s? Looking at the next-intl example, even the page grabs the locale from params, which makes me a slightly more confused.

Thanks a lot, I appreciate the insights :)

[amannn]

Yep, it's unfortunately a bit hard to grasp—I agree! This is at least the situation until rootParams becomes available in Next.js (as mentioned in #1722 (comment)), this will make this setup simpler—I hope to have more to share on this soon!

Here are the differences:

1. locale from params: This is the actual value that reaches the [locale] segment in your Next.js app. You can use this for validating the value e.g. to call notFound() in a layout for unknown values. Also, if your app uses static rendering, you can use this value to use APIs like getTranslations without having to call setRequestLocale first (mentioned in the docs).
2. useLocale() / getLocale(): Returns the value of your locale that you're returning in i18n/request.ts (typically after normalizing it).

So currently, both have their place. It's a bit a stopgap solution though.

With rootParams, the future suggestion will be:

1. Use useLocale() / getLocale() everywhere
2. Use export const dynamicParams = false for validating the [locale] segment

This will be much easier. Hope we can get there soon!

[MichalMoravik]

Alright, it is a bit clearer now. I actually wanted to look at making bunch of the pages static but it looks like it's a good idea to wait for rootParams instead. Thanks a lot!

[MichalMoravik]

Hi @amannn, could you help me out in my answer above please? 🙏 I couldn't find info on that topic in the docs. Thanks a lot :)