App Router setup without i18n routing

[lynn1286]

App Router setup without i18n routing ，How to do get the language set by the user ？

import {NextIntlClientProvider} from 'next-intl';
import {getRequestConfig} from 'next-intl/server';
 
export default getRequestConfig(async () => {
  // This can either be defined statically if only a single locale
  // is supported, or alternatively read from the user settings
  const locale = 'en'; // -> How to get the language set by the user
 
  return {
    locale,
    messages: (await import(`../messages/${locale}.json`)).default
  };
});

[amannn]

It's entirely up to you in this case to store and retrieve the locale. Some options would be a user setting in your database, a custom cookie, a request header, etc. Is there anything that would work for your app?

[theoludwig]

Oh actually, I might be misunderstanding, and it's actually working/it is supported?

I'm checking the examples, and tried example-app-router, I've only changed export const localePrefix = undefined; to export const localePrefix = 'never' as const; in src/navigation.ts. With this, does that mean, pages are still static, without i18n routing, but still dynamic lang with cookie?

Edit: From my experimentation, it should indeed work, thank you so much for making this library.

[amannn]

does that mean, pages are still static, without i18n routing, but still dynamic lang with cookie?

Yep, exactly! Internally you have separate routes as defined by the [locale] segment and the middleware will rewrite incoming requests accordingly to pick the correct (statically) rendered page.

I think I should add this to the localePrefix: 'never' docs, it's actually a good reason to pick this strategy.

[askjervold]

How are you storing your locale? In a cookie, like in the example above? You could try to invoke a Server Action that updates your cookie and then calls revalidatePath('/'). Theoretically, that should return updated markup for the page without a reload.

There's a bit of a delay, but this worked! Thanks for the help! 🤩

[askjervold]

A bit of change in requirements has introduced a new conundrum in my use-case. When the user has not explicitly set their preferred language (and also possibly if their preferred language is not available), we want to make an API call based on a dynamic route segment to determine the default and available languages and use this to set the locale. Is this possible to do from the getRequestConfig call, or would I need to introduce a middleware to perform this check and set a cookie that I can read from in getRequestConfig? Also, if I understand correctly, the config is cached – but is it cached per request path, so that a request to a different path would check the appropriate data based on the new dynamic segment and possibly return a new locale?

[amannn]

Hmm, yes, sounds like a job for a middleware as cookies can not be set during the RSC render.

Note however that if you set a cookie on the response in the middleware, you will not be able to read it from a request header during the RSC render. A workaround is to attach the value as an additional request header in the middleware that can be read during the RSC render.

You could have a look at the localePrefix: 'never' too in case this is a good fit for your requirements. The middleware can be composed to dynamically assign the locales.

the config is cached – but is it cached per request path, so that a request to a different path would check the appropriate data based on the new dynamic segment and possibly return a new locale?

See i18n.ts in the docs—the cache rules from React's cache apply here (i.e. the cache is request-scoped, requests for the same path will call this code again—at least if you're using dynamic rendering, e.g. caused by reading headers).