Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve language selection #613

Open
lukasrad02 opened this issue Aug 12, 2024 · 3 comments
Open

Improve language selection #613

lukasrad02 opened this issue Aug 12, 2024 · 3 comments

Comments

@lukasrad02
Copy link
Contributor

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 the Accept-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:

  • Would it make sense to allow users to set a default language on their account?
  • Should this language override language identifiers from URLs (so that Alice, who prefers German, will always be served the German content by default, even if Bob, who prefers English, sends her a link starting with /en/), or only override the HTTP header if no language was specified in the URL?
  • Should the preferred language of an account automatically change if the user switches language on any page, or should it only be changeable on a dedicated settings page?
@frcroth
Copy link
Contributor

frcroth commented Aug 12, 2024

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:

  • Not account but session via cookie, easier
  • If you go to a URL with the specific language it should not redirect you and also not set the cookie
  • Changes when the language is changed

@lukasrad02
Copy link
Contributor Author

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?

@frcroth
Copy link
Contributor

frcroth commented Aug 12, 2024

I would have expected that the cookie stays indefinitely. Without, this is pretty useless. hmm

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

2 participants