Re: [PATCH] remote-curl: send Accept-Language header to server

["Ævar Arnfjörð Bjarmason" <avarab@gmail.com>]

On Wed, Jun 08 2022, Li Linchao via GitGitGadget wrote:

> From: Cactusinhand <lilinchao@oschina.cn>
>
> 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.