Export the resolveLocale functions for use in the getRequestConfig no routing locale resolution

[stanleyk]

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

I am working on an internal app that does not require having the locale in the URL. Therefore I opted for the without i18n routing variant of the next-intl use. According to the documentation the locale resolution should happen in the i18n/request.ts using the getRequestConfig function.

All I want to do here is to do the same locale resolution as what the routing variant does, only skip the first route resolution. I want to check the NEXT_LOCALE cookie, read the accept-language header if it is not present and fallback to the default locale when nothing else matched. But all that logic already exists in resolveLocale. It seems unreasonable that I have to reimplement a piece of logic the library already has just to pass it back to it.

Describe the solution you'd like

Honestly the best solution would be something similar to what was proposed in #1369, where I could simply omit the detectFromUrl piece from the locale resolution chain and let the library do its work.

If for any reason you would not want to make it too complex, just exporting the getAcceptLanguageLocale and getLocaleFromCookie helper functions for use in the getRequestConfig function might be enough.

Describe alternatives you've considered

An alternative is already described in the docs:

// Provide a static locale, fetch a user setting,
// read from cookies(), headers(), etc.

Yes, it is doable, but as I wrote above, it seems awkward to have to reimplement some logic that is already there.

Thank you for considering this issue.

[amannn]

I understand your request, but at the current point I'd prefer not to export resolveLocale.

The reasons are:

1. Adding new public API needs careful consideration and takes maintenance effort over time
2. Next.js is currently working on middleware improvements and I don't want to bring too many changes affecting that area in currently, to avoid having to change it again in case Next.js asks for changes
3. A refactor of the middleware that makes locale detection more granular is quite large and will likely require a different API than what was proposed in Locale detection could be more flexible #1369.
4. Some users will always ask for exceptions, requiring to add more configuration/overloads/etc.
5. It's really only a few lines to implement this yourself (see App Router setup without i18n routing #1081 (reply in thread))

Due to this, for the time being I'd suggest to copy-paste the lines from the snippet mentioned above—hope that works for you!

[stanleyk]

Hi, thanks for all the reasons to not add the export, I respect it. Let's see what the Next.js middleware improvements will be.

So I have copied the logic and implemented the logic myself and yes, it is doable and it is not as much code. But there are some drawbacks:

1. I had to explicitly declare negotiator and @formatjs/intl-localematcher as my project dependencies. So there is a good chance I will end up with multiple versions of those libraries after a while.
2. I had to explicitly hardcode the NEXT_LOCALE cookie name in the code. I know you have to do it too, because Next does not expose the cookie name either. But I don't like it.