On Wed, Jun 08 2022, Li Linchao via GitGitGadget wrote: > From: Cactusinhand <lilinchao@xxxxxxxxxx> > > Git server end's ability to accept Accept-Language header was introduced > in f18604bbf2(http: add Accept-Language header if possible), but this is > only used by very early phase of the transfer, that's HTTP GET request to > discover references. For other phases, like POST request in the smart HTTP > the server side don't know what language client speak. > > This patch teaches git client to learn end-user's preferred language and > throw accept-language header to server side. Once server get this header > it have ability to talk to end-user with language they understand, this > would be very helpful for many non-English speakers. I may be missing something, but this is just the "Accept-Language" part of this change, i.e. there is no "round-tripping" here of actually doing the work on the server of doing setlocale(), no? I think the end-goal of having the "remote: " messages translated, if possible, is very worthwhile, but I'd always imagined we'd do that with a protocol extension, because even if we do this with HTTP headers we won't get the same over ssh/git transports. But then again we don't have protocol v2 push yet :( So perfect certainly shouldn't be the enemy of the good here, I just wonder what the end-goal is and if there's a plan to get there.
