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

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Jun 9, 2022, 07:30 UTC
Message-ID: <220609.86leu6thon.gmgdl@evledraar.gmail.com>
In-Reply-To: <pull.1251.git.1654678407365.gitgitgadget@gmail.com>

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

Show 12 quoted lines

> 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.