-
-
Notifications
You must be signed in to change notification settings - Fork 4.8k
lib/api: Correct ordering of Accept-Language codes by weight (fixes #9670) #9671
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
Conversation
The preference for languages in the Accept-Language header field should not be deduced from the listed order, but from the passed "quality values", according to the HTTP specification: https://httpwg.org/specs/rfc9110.html#field.accept-language This implements the parsing of q=values and ordering within the API backend, to not complicate things further in the GUI code. Entries with invalid (unparseable) quality values are discarded completely.
Can't we let a library handle the matching and pass the selected result back to the UI? e.g https://pkg.go.dev/golang.org/x/text/language#hdr-Matching_preferred_against_supported_languages |
Nice idea, if there is already library support for it. The problem I see is that our list of valid languages is currently thrown into a JS snippet for consumption by the GUI only. Would need to change that to generate a Go version first. In general it will complicate things here, since more of the logic is moved to the backend and things like user preference in local browser storage must live in the frontend. |
The hacky solution would be passing header and available locales to the backend for selection. |
There are also client-side libraries available to do elaborate matching, e.g.: https://www.npmjs.com/package/accept-language I'm not really a proficient JavaScript user though, so adding that dependency is not something I'm confident with. In this case, the backend code would just need to reflect back the |
c9f1e99
to
8f82463
Compare
* main: gui, man, authors: Update docs, translations, and contributors gui: Actually filter scope ID out of IPv6 address when using Remote GUI (ref syncthing#8084) (syncthing#9688) Revert "lib/fs: Put the caseFS as the outermost layer (syncthing#9648)" lib/api: Correct ordering of Accept-Language codes by weight (fixes syncthing#9670) (syncthing#9671) gui, man, authors: Update docs, translations, and contributors gui: Fix incorrect UI language auto detection (fixes syncthing#9668) (syncthing#9669) lib/model, lib/protocol: Index sending/receiving debugging (syncthing#9657) lib/upgrade: Send OS version header to upgrade server (syncthing#9663) lib/upgrade: Send OS version header to upgrade server (syncthing#9663) gui, man, authors: Update docs, translations, and contributors
Purpose
The preference for languages in the Accept-Language header field should not be deduced from the listed order, but from the passed "quality values", according to the HTTP specification: https://httpwg.org/specs/rfc9110.html#field.accept-language
This implements the parsing of q=values and ordering within the API backend, to not complicate things further in the GUI code. Entries with invalid (unparseable) quality values are discarded completely.
Testing
Example based on the RFC, modify to taste: