Syncing Accept-Language with Cookie without path-based router

[kieranm]

Hello!

We are moving away from path-based routing in favour of using the user's account preference. We need to store the locale on the server too in order to know what format to send emails in etc. Our Vite desktop app is an SPA without a router, so we can't take full advantage of path-based routing now anyway.

In our NextJS web app, we would still like to rely on the Accept-Language header + Cookie combination for users who aren't logged in. That way they can still change the language before they sign up, and the language they choose can be used to create the account.

As far as I can tell looking at the source code, next-intl only updates the cookie when using path-based routing - is this correct?

Would you recommend we maintain our own cookie, or perhaps a cookie with the same name as the one used in next-into so that the middleware picks it up automatically?

Thanks in advance!

[amannn]

next-intl only updates the cookie when using path-based routing - is this correct?

The next-intl middleware is generally only required when you're using a setup with i18n routing (see the callout at the top of the middleware page). It might still work to some extent with localePrefix: 'never' set, but esp. if the source of truth moves from the cookie to the user profile as part of the sign up, I'd recommend not using the next-intl middleware in your case.

Instead, you can set up your own middleware that negotiates the locale (inspiration) and then uses the result to set a cookie. Later, after signup, this part can be skipped.

Just note that if you set a cookie on the response, then Server Components will not be able to read it via cookies() as part of the same request. You can however also set the cookie on the request, allowing you to read it where relevant (see also vercel/next.js#50374).

The result can then be used to initialize next-intl:

// i18n/request.ts
import {getRequestConfig} from 'next-intl/server';
 
export default getRequestConfig(async () => {
  const locale = getLocaleFromUserProfile() || cookies().get('NEXT_LOCALE');
 
  return {
    locale,
    messages: (await import(`../../messages/${locale}.json`)).default
  };
});

Let me know if this helps!

[kieranm]

Thanks @amannn much appreciated! I will give this approach a go.

I'm not totally clear how I can implement getLocaleFromUserProfile() here without making another round-trip to our API to get the user profile. I could "lift up" the API call to here but I'm not sure how I would pass the API response back down to my app to be re-used there.

Apparently cookies set in middleware are now accessible in the request by default after this release:
https://github.com/vercel/next.js/releases/tag/v14.2.8

[kieranm]

Having thought about it a bit more I don't think I actually need to get the user's information in getRequestConfig.

I can configure the defaults for users who are not logged in in the getRequestConfig function and provide these to a Root <NextIntlClientProvider>. Then deeper in the application I can configure a second NextIntlClientProvider which overwrites the root one if the user is logged in.

I only really need access to translations in client components so this approach would probably work OK! Will experiment with it

[amannn]

Apparently cookies set in middleware are now accessible in the request by default after this release: https://github.com/vercel/next.js/releases/tag/v14.2.8

Oh, right! I thought I read something somewhere, thanks for the link!

how I can implement getLocaleFromUserProfile() here without making another round-trip to our API to get the user profile

Would it be an issue to read it here additionally? cache should help to de-duplicate calls if you have multiple of those.

I can configure the defaults for users who are not logged in in the getRequestConfig function and provide these to a Root . Then deeper in the application I can configure a second NextIntlClientProvider which overwrites the root one if the user is logged in.

If you manage all translation functionality exclusively in Client Components, this will likely work—yes. Just be careful if you ever introduce any calls that run on the server (e.g. Server Actions, Route Handlers, …) that these will be initialized from getRequestConfig. Due to this, I'd generally recommend ensuring you have the final config returned from getRequestConfig, but you definitely know your app best!