Validation of locale param in page components in addition to root layout

[abarani]

Hey everyone,

a quick question since I cannot come up with this reading the docs and the examples.

Is the locale parameter in page components supposed to be validated by the validation code in the root layout?
From the docs of setRequestLocale I read that "locale should be validated (e.g. in your root layout)".
So I was expecting that was the case but digging a bit further I found out that, despite the validation being present on the root layout and correctly returning a 404 page to the user, Next.js is still rendering the page in the background with an invalid locale.

I've setup a reproduction sandbox here:
https://codesandbox.io/p/devbox/zen-burnell-3t5n8g

If you change the URL to an invalid locale you can clearly see the error on the page being thrown on the console although the user is presented with a 404 page.

Is this the expected behaviour from next-intl?
If I must ensure that locale is valid on the page components should I validate it on every page the same way it is done on the root layout?

I tested this with Next.js 15.1.7 and next-intl 3.26.3.

[amannn]

That's a great question!

The docs currently suggest validation in the root layout, because it works for both static as well as dynamically rendered apps. What Next.js does though, is it renders relevant layouts and pages in parallel, therefore while you're waiting for your root layout to interrupt the render, a page might render as well.

If you check out e.g. example-app-router, in a page we're enabling static rendering by calling setRequestLocale based on a received locale:

next-intl/examples/example-app-router/src/app/[locale]/page.tsx

Lines 10 to 11 in a881e62

	// Enable static rendering
	setRequestLocale(locale);

Now, the locale isn't used directly though, but automatically considered when you're calling useTranslations:

next-intl/examples/example-app-router/src/app/[locale]/page.tsx

Line 13 in a881e62

const t = useTranslations('IndexPage');

Behind the scenes, i18n/request.ts is consulted, which makes sue that any locale used in next-intl is valid:

next-intl/examples/example-app-router/src/i18n/request.ts

Lines 9 to 11 in a881e62

	if (!locale || !routing.locales.includes(locale as any)) {
	locale = routing.defaultLocale;
	}

So what this means is that the call to useTranslations in your page will always use a valid locale, regardless of if the render will be interrupted in your root layout. If you want to use the locale for something else, you can always get it from useLocale() / await getLocale() in your component (which also considers a fallback from i18n/request.ts).

Now, this is some back and forth that is currently necessary in order to support validation of locales both for static as well as dynamically rendered pages. If you're using static rendering, you should be able to replace the locale validation with export const dynamicParams = false. With this, you can early abort the render for unknown locales even before a layout or page renders.

The reason why this isn't advocated for in the docs, is because it doesn't work with dynamic pages—therefore for the time being I'm suggesting something that works consistently for either case.

That being said, rootParams is on the horizon, which will finally help to get rid of setRequestLocale and support static rendering without issues. Based on the currently available information, it should also allow to combine statically known params in a layout with dynamic pages. So once this is the case, dynamicParams = false will be the clear recommendation in the docs! I think this should help to avoid any confusion as you've outlined it above in the first place!

Hope this helps!

[abarani]

Thank you for the detailed response, it definitely clears my mind, I appreciate it!

I think dynamicParams = false works well for my use case for now, waiting for rootParams to be available.