Op ma 5 feb 2024 om 23:08 schreef Dirk Hohndel <[email protected]>: > > Hi Peter! > > On Feb 5, 2024, at 13:32, Peter wrote: > > >> 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 >> <Screenshot 2024-02-05 at 12.27.22.png> >> >> 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. > > > I read the standard differently - but that might be my mistake; the term > language-range is confusing as used here. > > > Accept-Language: nl,en;q=0.9,en-US;q=0.8,nl-NL;q=0.7 >> >> > I read this as > > nl,en - both with q=0.9 > en-US with quality 0.8 > nl-NL with quality 0.7 > > But I think you are right, having re-read the RFC. This should be > > nl (with implicit q=1.0) > en with q=0.9 > etc. > > Now, having said all that - I of course don't implement my own parsing, > I'm using a python-werkzeug function to determine the best match. > And re-reading THAT documentation, I think I know why we fail: > > For a website that offers languages = ["en","de_DE","es_ES","nl_NL"] your > listing has a rather unintended effect: > "nl" isn't offered. but "en" is ahead of "nl-NL" in quality. So it picks > "en". > I'll need to play with this to see what settings on my end could improve > the outcome. Maybe in the language list we don't include the country spec. > Thankfully I can use curl to pretend to be your browser. > > So yes, that works. But now someone with "Accept-Language: nl-NL,en;q=0.9" > will get the wrong language. Which means I need to include both variations. > Weird looking, but it seems to work. > > Please try again, I just deployed that fix to the website. > And thanks for your persistence to make sure I get what was wrong. I > misread how to apply the standard to the header you quoted and wasn't > looking at the right spot for the issue. > > /D >
Can't blame you, as said I misinterpreted it myself also at first. Just tested it with all sorts of combinations, and it is working great now! Thanks so much for being persistent as well ;). Peter
_______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
