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
_______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
