Op ma 5 feb 2024 om 22:14 schreef Dirk Hohndel via subsurface <[email protected] <mailto:[email protected]> >:
On Feb 5, 2024, at 12:08, Peter Zaal wrote: In the end it is not so much on the OS, as it is on what headers a specific browser sends, and how the website interprets and responds to that. But I think (and hope) I figured out the problem. Both Edge and Chrome (on my Windows) did not open the local language pages (cookies deleted etc). But when I started the browser in In-Private/Incognito modus, then it did show the local pages! There is a difference in the Accept-Language header! In in-private/incogito mode it is: "Accept-Language: nl", and in normal mode it is "Accept-Language: nl,en;q=0.9,en-US;q=0.8,nl-NL;q=0.7" (Chrome) and "Accept-Language: nl,en;q=0.9,en-GB;q=0.8,en-US;q=0.7" (Edge). So it looks like the quality (q) value is messing up things and not handled correctly server-side. My understanding of the standard is that what you send is "I take Dutch and English as my preference" - but the order does NOT imply preference. See https://www.rfc-editor.org/rfc/rfc9110#field.accept-language It appears that the Flask backend that I am using treats the standard more literally: In other words, according to the standard as written in the RFC you are getting what you are asking for "either Dutch or English, whichever you want to give me -- but I prefer en_US (with quality 0.8) over nl_NL (quality 0.7)". Yes, and nl (with quality 1, since no value) should be preferred over en with quality 0.9. I misread this myself at first, but the values are comma separated, and the q value is after the language code. Even when only having 2 languages set in the browser, dutch and english, this results in an "Accept-Language: nl,en;q=0.9". These are 2 items: "nl" and "en;q=0.9". nl has a quality of 1 and should be preferred, but still the “en” pages are chosen. Another small thing is that the local pages are using the 'full' language-region code, so e.g. /nl_NL/...That is probably because that's how the languages are declared in the languages array in server.py. But that might be ok, in that way multiple regions are supported as well. Manually entering and using only the language code also works. The language code now sticks, I don't know why it didn't before... We use the full language code because we have in the past had translations for both de_DE and de_CH as well as pt_PT and pt_BR. To keep the door open for other such situations, we simply always use the full qualifier. Of course, if you request 'nl' you will get the 'nl_NL' translation... /D _______________________________________________ subsurface mailing list [email protected] <mailto:[email protected]> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
_______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
