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

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Jul 5, 2022, 10:15 UTC
Message-ID: <220705.86o7y3am2m.gmgdl@evledraar.gmail.com>
In-Reply-To: <202207051804341356418@oschina.cn>

On Tue, Jul 05 2022, lilinchao@oschina.cn wrote:

Show 17 quoted lines

>>"lilinchao@oschina.cn" <lilinchao@oschina.cn> writes:
>>
>>>>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?
>>
>>Not really.  Before forcing us to invent completely separate
>>mechanisms for different transports, it is a very good idea to
>>consider if we can use a single mechanism that can apply to all
>>transports.  Adding something at the protocol level would be a
>>step in the right direction.
> I wonder if we can use a new protocol-capability like local-lang or 
> something else, then Git client and server can tell each other's language
> ability in the negotiation stage.

It would make sense to call this protocol verb "setenv", and just give it support for setting arbitrary remote environment, which we'd then have a whitelist configuration variable for, similar to how sshd(1) does it.

Or maybe we can just add this as a "capability", which seems like a more natural fit, we could even stick it into "agent" I guess...

Then it becomes a very thin layer for emulating what we already get with the ssh and http(s) transport(s).

Anyway, while it definitely would be an improvement to pass this along, a much better way to go IMO (but also harder) is to extend the protocol so that we don't a emita human language at all, but emit defined error states for our various known errors.

I have some WIP incomplete patches in that direction somewhere (that I haven't dug up now), and part of it is currently stalled on there being no "push" support in protocol v2.

But if we can get to that point it would make for much better UX, even if you get e.g. "git push" errors in your language now your editor/IDE is probably needing to spew terminal "git push" output at you as-is, it would make for better UX if it could just render it as it prefers to.

This would also mean you'd get translations even if the server doesn't have the needed *.po files.

It *isn't* a full replacement, e.g. if you have a custom hook having the locale is still useful, but for anything that's git native...

FWIW I think the WIP patches I'm referencing were only to upload-pack.c, i.e. to make various parts where it calls die() send over ERR packet(s) instead, and either pick that up magically on the client-side, or add a new ERR_CODE packet or whatever (I can't remember...).