Support providing a locale in i18n.ts instead of reading it from the pathname (single-language workflow and prefix-less routing)

[amannn]

Is your feature request related to a problem? Please describe.

While handling multiple languages is the common case, next-intl is also expected to work well for apps that only support a single language. After all, if using internationalization right from the start is easier than hardcoding text and formatting, then this should be a common workflow. The Pages Router integration was already capable of this, but ideally we support this similarly for the App Router as well.

Additionally, some apps read the locale from user settings and don't require it to be available in the URL. This use case is closely related (see also #892 and #778).

Describe the solution you'd like

Maybe a locale could be returned in i18n.tsx:

import {getRequestConfig} from 'next-intl/server';

export default getRequestConfig(async () => ({
  messages: (await import(`../messages/en.json`)).default,

  // Statically set or read from user settings
  locale: 'en'
}));

The tricky part is that we currently attempt to fetch the locale before this function is called. Maybe it could be lazily evaluated if locale is read from the params passed to the function.

Describe alternatives you've considered

This is already possible by supporting only a single language and setting localePrefix to never. However, the [locale] segment is still required.

For reading a locale from the db, this can be used as a workaround: #892 (comment)

With built-in support, no middleware should be required at all.

[smozely]

Interested in this as well, though our use case is slightly different, we want the option for the locale to be determined from our DB at runtime, as our customers data will be in a particular language. So we want everything in the same language as the customer (yes we have to figure out how to handle the pages before login)

... but the setup at the moment very tied in to routing, when thats not what (we think) we need

[amannn]

@smozely Yep, that's closely related I think. I've updated the issue description above and would aim to support this use case as well with the proposed feature.

[amannn]

@smozely I've had time to look into a proof-of-concept and I think the approach outlined above works remarkably well!

Docs need to be written and adapted yet, but I think generally this is a significantly better approach to localePrefix: 'never' in case you don't require to have the locale present in the pathname.

Please see #1017 for more information and a pre-release. I'd be really happy if you could help to try out the pre-release to make sure this works as expected for you!

[ScreamZ]

Very interested in this

[amannn]

@ScreamZ Feel free to try out the pre-release and let me know if this works well for you!

[branislavbrincko]

I am looking for answer to this question #892 (comment) - I also want to take locale from user settings.

AND I have the pages router. The solution to set it in getRequestConfig is only relevant for app router, correct? (I am quite new to next-intl so sorry if my question is out of place.)

So how to do this in pages router?
Why passing my locale (which i would take from db) to NextIntlClientProvider doesn’t work?

Thanks ✌️✌️

[amannn]

@branislavbrincko In the Pages Router you should be able to assign the locale prop of NextIntlClientProvider in _app.tsx (see the getting started docs). And yes, i18n.ts/getRequestConfig is only relevant for the App Router.

[smozely]

@amannn We've had a quick play and its behaving how we want. Thanks!