Open rk-for-zulip opened 4 years ago
The fix is probably to ensure that the
locale
value is available in theAuth
object, so thatapiFetch
(or one of its callees) will have it on hand to construct an appropriateAccept-Language
header.
Hmm. Yeah, something like this makes sense.
What's the appropriate way to construct an Accept-Language
header? We'll want to make sure we get the language/locale name into the right form for that.
In theory, something along the lines of Accept-Language: xx[-YY]
(case-insensitive). There are reasonably-full docs here, including a multilingual selection feature we probably have neither a use for nor any concern about.
In practice, of course, the appropriate way is "whatever the Zulip server expects", which seems to be "whatever Django expects"; this is documented to include at least xx
and xx-yy
.
The Zulip server attempts to localize error messages using the language sent in the HTTP
Accept-Language
header. Unfortunately, we don't send that when making API calls.The fix is probably to ensure that the
locale
value is available in theAuth
object, so thatapiFetch
(or one of its callees) will have it on hand to construct an appropriateAccept-Language
header.