7 ms·

Even as a kid still going through that phase where English lessons at school consist of very simple descriptions of family life that add some new words each wee

by usrusr 3y ago

Even as a kid still going through that phase where English lessons at school consist of very simple descriptions of family life that add some new words each week, I felt betrayed by GW BASIC documention referring to some concept with the cryptic letters "E/A". When I realized that they were talking about "I/O", translated as Eingabe/Ausgabe, suddenly it all made sense. There really needs to be some way for language preferences to include quality in some way. No, I probably don't want an English dub of something Asian when there's also a German dub. But I certainly also don't want some machine or lowest bidder translation that only exists to serve people with no foreign language skill at all (or that's not even remotely as good as the company that commissioned the translation thinks.

maweki 3y ago
> There really needs to be some way for language preferences to include quality in some way. In theory, there is. It's called content negotiation. With your browser request you already send a list of preferred languages, like "Accept-Language: da, en-gb;q=0.8, en;q=0.7". RFC9110 states that such a quality/weight is assigned to different representations of a resource. So all the server needs to do is multiply their quality with your preference and return the one with the highest value. So the technology for that is already in place. It just isn't done. See: https://www.w3.org/International/questions/qa-lang-priorities https://www.w3.org/International/questions/qa-lang-prioritie...
- derefr 3y ago
  I think what the GP is describing isn't about client-server negotiation, though, but rather something that happens purely client-side for already-delivered resources, within e.g. the system for loading the right subtitle track embedded into a playing video. AFAIK, there's no standard for allowing client-side media-playback frameworks to probe language preferences with quality values out of the browser they're running in. The navigator.languages property (https://developer.mozilla.org/en-US/docs/Web/API/Navigator/languages https://developer.mozilla.org/en-US/docs/Web/API/Navigator/l...) doesn't expose qvalues for some reason. And even if there was, there's no way, in any media container format I know of, of annotating subtitle tracks with quality values — so there's no way of saying that a given track really sucks and should be deprioritized relative to the user's preference ordering, but still used if there's no other choice.

by usrusr 3y ago

maweki 3y ago

> There really needs to be some way for language preferences to include quality in some way. In theory, there is. It's called content negotiation. With your browser request you already send a list of preferred languages, like "Accept-Language: da, en-gb;q=0.8, en;q=0.7". RFC9110 states that such a quality/weight is assigned to different representations of a resource. So all the server needs to do is multiply their quality with your preference and return the one with the highest value. So the technology for that is already in place. It just isn't done. See: https://www.w3.org/International/questions/qa-lang-priorities https://www.w3.org/International/questions/qa-lang-prioritie...

derefr 3y ago
I think what the GP is describing isn't about client-server negotiation, though, but rather something that happens purely client-side for already-delivered resources, within e.g. the system for loading the right subtitle track embedded into a playing video. AFAIK, there's no standard for allowing client-side media-playback frameworks to probe language preferences with quality values out of the browser they're running in. The navigator.languages property (https://developer.mozilla.org/en-US/docs/Web/API/Navigator/languages https://developer.mozilla.org/en-US/docs/Web/API/Navigator/l...) doesn't expose qvalues for some reason. And even if there was, there's no way, in any media container format I know of, of annotating subtitle tracks with quality values — so there's no way of saying that a given track really sucks and should be deprioritized relative to the user's preference ordering, but still used if there's no other choice.