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

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

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

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