Open lukasrad02 opened 2 months ago
See #559. I tried to implement this in #577 and it seemed to work in my local deployment, but apparently it does not work in production. The intended solution from that PR for your questions is:
Just checked it again and it did work as you described it. Must have missed that feature in the new release.
However, I would wish for the cookie to have a longer lifetime than the browser session. At least in my workflow, the session cookie does not help in most cases, as internal links always point to the current locale, so navigation within myHPI does not need the additional cookie and I restart my browser quite often, so the preference is not persisted across most of my visits.
On the first glance, I did not find any information about the cookie lifetime in the Django docs referenced by your PR. Do you know more about this?
I would have expected that the cookie stays indefinitely. Without, this is pretty useless. hmm
Most pages on myHPI are available in German and English. Currently, myHPI serves the language specified in the url (i.e., German for all paths starting with
/de/
and English for/en/
) and defaults to the the preferred language according to theAccept-Language
HTTP header, if the URL path does not contain a language identifier (such as the root page or any path with the language part stripped away). One can always switch to the other language using the link in the page footer.While this is, in my opinion, a sensible behavior for first-time visitors, it can be tedious for frequent visitors. For example, someone who generally prefers English content on the Internet (and thus sets
Accept-Language
to English in their browser) but also understands German and wants to read the original German minutes on myHPI always has to switch to German first. Having the link to the other language in the footer is an additional hurdle, especially on long pages and for editors who frequently switch languages to check the content in both English and German.I'd like to propose to move the language selection from the footer to the header, as the header contains most of the other relevant internal navigation features (menu, search). On mobile, one might combine design considerations with other elements that are currently located at the page bottom (see #609).
Additionally, I am interested in your opinions on the default language behavior. Some thoughts from my side are:
/en/
), or only override the HTTP header if no language was specified in the URL?