2 domains out of 4 don't have NEXT_LOCALE cookie set

[michalpulpan]

Description

Hi, first of all thank you for an amazing work on this project.
However, after updating to v4 (specifically beta and then 4.0.1, I have noticed a strange behavior.
We have 4 domains in total:

• example.cz for locale cs-CZ
• example.sk for locale sk-SK
• example.at for locale de-AT
• example.com for locales de-DE, en-GB, en-FR, etc.

For some reason, the example.at and example.com always have NEXT_LOCALE set. However, both example.cz and example.sk do not.

I honestly don't see why this does not work, the configuration is correct in my opinion:

export const routing = defineRouting({
	locales: [
		"cs-CZ",
		"en-BE",
		"en-BG",
		"en-CY",
		"en-DK",
		"de-DE",
		"en-EE",
		"en-FI",
		"en-FR",
		"en-GR",
		"en-HU",
		"en-HR",
		"en-IE",
		"en-IT",
		"en-LV",
		"en-LT",
		"en-LU",
		"en-MT",
		"en-NL",
		"en-PL",
		"en-PT",
		"en-RO",
		"en-SI",
		"sk-SK",
		"en-ES",
		"en-SE",
		"en-GB",
		"de-AT",
		"en-CH",
	],
	defaultLocale: "cs-CZ",
	localePrefix: {
		mode: "as-needed",
	},
	domains: [
		{
			domain: "example.cz",
			defaultLocale: "cs-CZ",
			locales: ["cs-CZ"],
		},
		{
			domain: "example.sk",
			defaultLocale: "sk-SK",
			locales: ["sk-SK"],
		},
		{
			domain: "example.at",
			defaultLocale: "de-AT",
			locales: ["de-AT"],
		},
		{
			domain: "example.com",
			defaultLocale: "en-GB",
			locales: [
				"de-DE",
				"en-FR",
				"en-GB",
				// etc...
			],
		},
	],
	pathnames: /*JUST A LIST OF PATNAMES*/,
});

And in the middleware:

export default async function middleware(request: NextRequest) {
// ....
	/** i18n routing */
	const handleI18nRouting = createMiddleware(routing);
	// Get the initial response from the i18n middleware
  let response = handleI18nRouting(request);
  
  // check the set cookies from the i18n middleware
  const i18nCookies = response.cookies;
  console.log("i18nCookies", i18nCookies); 
// ...
}

The i18nCookies is empty on CZ and SK domains, but on AT and COM it contains NEXT_LOCALE (after deletion).

Thank you in advance.

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://ecobamboo.cz, https://ecobamboo.sk, https://ecobamboo.at, https://ecobamboowear.com

Reproduction description

The configuration is written already in the issue incl. all domains that it does not work on.

Expected behaviour

Set the NEXT_LOCALE cookie on every domain.

[amannn]

Have you seen the section on GDPR compliance in the release notes? The cookie is only set when the user is on a locale that doesn't match their accept-language setting.

[michalpulpan]

Have you seen the section on GDPR compliance in the release notes? The cookie is only set when the user is on a locale that doesn't match their accept-language setting.

Yes, I've read that. But I don't think this is the case. If I add sk-SK to my example.com domain as a locale it then sets the cookie. It's like it does not work specifically on the two domains I listed (example.cz and example.sk).

Is there any way to force storing the cookie so that I can test it?

[michalpulpan]

The reason I need to read the cookie are multiple server methods which rely on the NEXT_LOCALE cookie.

[amannn]

You can observe the cookie being set or not set depending on the accept-language header you're passing to a request:

curl -I https://ecobamboowear.com/en-BE -H 'accept-language: en'
HTTP/2 200 
(...)
set-cookie: storefront-session=d3c0f0190e03c076; Path=/; Secure
set-cookie: uuid=2d85f5c3-1794-4933-b400-f5ea85c07aae; Path=/; Expires=Sun, 11 Mar 2035 09:24:14 GMT

curl -I https://ecobamboowear.com/en-BE -H 'accept-language: de'
HTTP/2 200 
set-cookie: storefront-session=355d2f15329775ce; Path=/; Secure
set-cookie: NEXT_LOCALE=en-BE; Path=/; SameSite=lax
set-cookie: uuid=f5a5d473-7334-47c6-b1d7-c423fcbdb9ef; Path=/; Expires=Sun, 11 Mar 2035 09:24:19 GMT

The locale cookie is only set when a user switches to a locale that doesn’t match the accept-language header.

If I add sk-SK to my example.com domain as a locale it then sets the cookie

It really depends on what accept-language header your browser sends.

The reason I need to read the cookie are multiple server methods which rely on the NEXT_LOCALE cookie.

Please see this section from the release notes:

Since the cookie is now only available after a locale switch, make sure to not rely on it always being present. E.g. if you need access to the user’s locale in a Route Handler, a reliable option is to provide the locale as a search param (e.g. /api/posts/12?locale=en).

As a side note, cookies are really not reliable to read as the source of truth for the locale. They can expire based on their configuration, may be removed if a user clears them manually, but they can also be removed during routine cleanup processes of a browser (e.g. if storage space is limited).

We can use them to help remember a user's locale choice, but there's never a guarantee that they're available.

[michalpulpan]

@amannn, thank you very much for your feedback and explanation.

I've changed the implementation to using getLocale method (it was mostly only about using injecting the locale to requests to other services) and it seems to do the trick.

However, after updating to the v4 I'm seeing some issues that href in the links are now prefixed with locale prefix even though I'm on default locale for a given domain (so the URL in browser is without the prefix). But that is probably for a different discussion.

Thank you!

[amannn]

I've changed the implementation to using getLocale method (it was mostly only about using injecting the locale to requests to other services) and it seems to do the trick.

Ok, sounds good!

However, after updating to the v4 I'm seeing some issues that href in the links are now prefixed with locale prefix even though I'm on default locale for a given domain (so the URL in browser is without the prefix). But that is probably for a different discussion.

Hmm, that sounds fishy to me. If you could provide a reproduction in a separate issue I can have a look!

I'll close this issue for the time being then.