Re: [PATCH] http: Add Accept-Language header if possible
- From
Jeff King <peff@peff.net>
- Date
- Jul 10, 2014, 20:10 UTC
- Message-ID
- <20140710201034.GB15615@sigill.intra.peff.net>
- In-Reply-To
- <alpine.DEB.2.00.1407091142030.22132@ds9.cixit.se>
On Wed, Jul 09, 2014 at 11:46:14AM +0100, Peter Krefting wrote:
Show 10 quoted lines
> Jeff King:
>
> >I did some digging, and I think the public API is setlocale with a NULL
> >parameter, like:
> >
> > printf("%s\n", setlocale(LC_MESSAGES, NULL));
> >
> >That still will end up like "en_US.UTF-8", though;
>
> And it only yields the highest-priority language, I think.I wasn't clear on whether POSIX locale variables actually supported multiple languages with priorities. I have never seen that, though the original commit message indicated that LANGUAGE=x:y was a thing (I wasn't sure if that was a made-up thing, or something that libc actually supported).
> Debian's website has a nice writeup on the subject: > http://www.debian.org/intro/cn#howtoset
That seems to be about language settings in browsers, which are a much richer set of preferences than POSIX locales (I think).
It would not be wrong to have that level of configuration for git's http requests, but I do not know if it is worth the effort. Mapping the user's gettext locale into an accept-language header seems like a straightforward way to communicate to the other side what the client is using to show errors (so that errors coming from the server can match).
If that is the case, though, I wonder if we should actually be adding it as a git-protocol header so that all transports can benefit (i.e., we could be localizing human-readable error messages in upload-pack, receive-pack, etc).
-Peff