Sorry, I mistakenly sent the reply email to you yesterday, I should click "Reply all" button :( > >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? Yes, here Git just holds this header message, and the actual work depends on the git service providers, like Github, Gitlab, or Gitee. > >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. As for ssh transport, can we use ssh environment to reach our goal? > >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. Thanks.
