Skip to content

Conversation

acolomb
Copy link
Member

@acolomb acolomb commented Sep 1, 2024

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:

curl -X GET -H "Accept-Language: da, en-GB;q=1.8, en;q=1.0" http://localhost:8384/rest/svc/lang

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.
@acolomb acolomb linked an issue Sep 1, 2024 that may be closed by this pull request
@bt90
Copy link
Contributor

bt90 commented Sep 1, 2024

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

@acolomb
Copy link
Member Author

acolomb commented Sep 1, 2024

Can't we let a library handle the matching and pass the selected result back to the UI?

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.

@bt90
Copy link
Contributor

bt90 commented Sep 1, 2024

The hacky solution would be passing header and available locales to the backend for selection.

@acolomb
Copy link
Member Author

acolomb commented Sep 1, 2024

There are also client-side libraries available to do elaborate matching, e.g.:

https://www.npmjs.com/package/accept-language
https://www.npmjs.com/package/resolve-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 Accept-Language header verbatim, or we could try getting it from the browser directly.

@acolomb acolomb force-pushed the accept-language-order branch from c9f1e99 to 8f82463 Compare September 1, 2024 15:33
@acolomb acolomb merged commit cb24638 into syncthing:main Sep 2, 2024
21 checks passed
@acolomb acolomb deleted the accept-language-order branch September 2, 2024 08:15
calmh added a commit to calmh/syncthing that referenced this pull request Sep 11, 2024
* 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
@calmh calmh added this to the v1.27.13 milestone Sep 11, 2024
@st-review st-review added the frozen-due-to-age Issues closed and untouched for a long time, together with being locked for discussion label Sep 2, 2025
@syncthing syncthing locked and limited conversation to collaborators Sep 2, 2025
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
frozen-due-to-age Issues closed and untouched for a long time, together with being locked for discussion
Projects
None yet
Development

Successfully merging this pull request may close these issues.

lib/api: /svc/lang disregards the passed quality values
4 participants