Unify frontend and backend language preference using shared cookie

[virgile-dev]

Bug Report

Problematic behavior
Here you can see "Doc private" appears in English but the user interface is in French.
https://github.com/user-attachments/assets/0ae0e457-15f7-423c-b4bc-c1c5fc9d48bc

Same when I'm loading a doc I don't have access to. The message only is available in French even if I sent the interface in English and reload.

[rvveber]

This seems to be an issue with the backend not beeing communicated the current language to.

Here is how Django determines the current language:
https://docs.djangoproject.com/en/5.1/topics/i18n/translation/#how-django-discovers-language-preference

First, it looks for the language prefix in the requested URL. This is only performed when you are using the i18n_patterns function in your root URLconf. See Internationalization: in URL patterns for more information about the language prefix and how to internationalize URL patterns.

Failing that, it looks for a cookie.
The name of the cookie used is set by the LANGUAGE_COOKIE_NAME setting. (The default name is django_language.)

Failing that, it looks at the Accept-Language HTTP header. This header is sent by your browser and tells the server which language(s) you prefer, in order by priority. Django tries each language in the header until it finds one with available translations.

Failing that, it uses the global LANGUAGE_CODE setting.

For me the message is always english, which means that Django determines it by
Accept-Language HTTP header.

We currently dont use language patterns e.g./fr in the url

So the best option, would be to set a cookie with the language code when switching the language in the frontend. The default name of the cookie is django_language but the name is configurable via the django configuration option LANGUAGE_COOKIE_NAME

Next.JS accepts a special cookie which needs to be called NEXT_LOCALE
https://nextjs.org/docs/pages/building-your-application/routing/internationalization#leveraging-the-next_locale-cookie
We could set the cookie NEXT_LOCALE on language change and configure django to use that same cookie name to determine its preferred language.

We would have only one cookie for frontend and backend language.
Both respecting the value.
This is the solution i'd like to implement.

(Currently, we have no cookie for this, and we save the language in local storage.)
@AntoLC can i refactor to use this cookie instead?

[rvveber]

The NEXT_LOCALE cookie seems to be ignored currently and only relevant for url based routing.
It is not necessary and i have decided to name it impress_language instead.