Op ma 5 feb 2024 om 22:14 schreef Dirk Hohndel via subsurface <
[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
> [image: 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.



>
> 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]
> 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

Reply via email to