Changing locale and then going back negates locale change nextjs 14

[mp3por]

Description

When I change locale via the LocaleSwitcher from the example I see the page in German.

However when I click back in the browser I see the page in English again.

My use case is a nextjs app which is embedded in a react-native-web-view and has a dedicated page for changing the language. When the user changes the language there is a back button to navigate away which uses the normal router.back command. Due to the described behaviour when the user navigates back the locale change is overridden.

As a workaround for now I will have a local copy of the history so that I am able to go back by pushing a new url and not via the router.back.

PS: I was not able to fork the bug template in CodeSandbox. Please check permissions or something.

Mandatory reproduction URL (CodeSandbox or GitHub repository)

https://codesandbox.io/p/sandbox/next-intl-bug-template-app-forked-zcymvq

Reproduction description

Steps to reproduce:

1. Open reproduction
2. Click on "Show in German"
3. Click on browser back button

Result: Content is in English
Expected Result: Content is in German

Expected behaviour

I would expect that when I change the language and go back it will keep the new language. I understand that the URL has precedence over the next-intl cookie however I don't think this is the correct behaviour. If I have already selected my language for the site (and thus have my next-intl cookie set) I should be able to open any link (regardless of the locale) and automatically see the site in my selected locale. Therefore the precedence should be the cookie. When the URL changes the library should monitor the locale parameters and sync it with the cookie via router.replace to ensure consistency with the desired locale and back - forward movement works.

[amannn]

I see your point, but changing the locale in next-intl is really about changing the locale segment in the URL—i.e. changing the locale means changing the URL. In case of localized pathnames this can go as far as /en/about vs. /de/ueber-uns therefore patching the browser history is not really an option. I'd also question how often the user really changes the locale and runs into a case where a browser back will lead to a locale change.

If your use case doesn't require a locale prefix, you can disable it via localePrefix: 'never'.

I'll move this to a discussion since this seems to be a usage question and not a bug report.

[mp3por]

Hello, thank you for responding.

"I'd also question how often the user really changes the locale and runs into a case where a browser back will lead to a locale change" -> with the current implementation and "mental model" you described ("is really about changing the locale segment in the URL") the locale will always be reset when the user does a "browser back" since the browser will go to an url where the locale segment is the previous locale. If this happens a lot due to UX design is another question.

I will check the provided documentation and get back to you.

In my head this library is about translating the content of a web page to my desired language. Therefore I should be able to synchronize it with a language that comes from the BE and show the content in that locale even if it means overriding the url segment. On the other hand I also would like to be able to have URLs with predefined locale. So I think there has to be a way to define for which takes precedence - the url segment or the cookie. In my opinion the cookie should be the top priority and if you want to override the cookie with the url segment then you can add a "urlLocale" url parameter which will do that. This way the user will have full control. Given that you use router.replace the browser back should also work as I expect since it will go back to the previous url '/en/about/' and see that the cookie says de and replace the url with /de/ueber-uns. Going back again will result again in this behaiviour thus showing the previous previous page in the de language. If I want to give a link and ensure it will be opened in the locale I have specified and not the user desired locale then I can do /en/about?urlLocale=true which will stop the library from going to the de language for this link only.