Thread (1 message) 1 message, 1 author, 2020-08-07

Re: [PATCH] sideband: mark "remote error:" prefix for translation

From: Junio C Hamano <hidden>
Date: 2020-08-07 20:18:55

Jeff King [off-list ref] writes:
On Wed, Aug 05, 2020 at 09:28:42AM -0700, Junio C Hamano wrote:
quoted
Jeff King [off-list ref] writes:
quoted
By the way, grepping for "remote error:" shows that when we get an error
over sideband 3 we produce the same message but _don't_ translate it.
That seems inconsistent.
IOW

    die(_("remote error: %s"), buf + 1);

in sideband.c?  I think it makes sense.
Yes. Patch is below so we don't forget about it. I'm not sure if we
ought to be going further, though. The "remote:" prefix for sideband 2
isn't translated either. It would be easy to do so, but it's much more
lego-like. We don't have "remote: %s" ever as a string. We just have
"remote:", and then we maybe_colorize_sideband() the result.

Would that be annoying for translators, especially with RTL languages?
Do people actually want to see "remote:" (or "remote error:" for that
matter) translated, or does mixing translated and untranslated messages
on one line end up more confusing? I'm out of my element here, as I
wouldn't ever use the translations myself.
quoted
IIRC, the current thinking is to let the remote side localize their
message before sending them over the wire and we'll worry about how
we let the receiving end tell what l10n it wants later.  So "remote
error:" prefix may have to be translated on receiving end and the
remainder of the line, which is already localized, can just be
interpolated.
Yeah, that part makes sense. The local client shouldn't be translating
what it gets from the server (and won't, because it is filled in via the
%s). Adding a capability for preferred language would be easy, though I
imagine it might be irritating in practice.  As a server admin, I want
to see everything in the C locale; but what gets shown to users and what
might get dumped into server logs is not well specified in Git. I have a
feeling that just setting LANG based on the user's request would be a
bit broad.

Anyway, here's the patch. It doesn't seem to cause any test failures,
even with GETTEXT_POISON. :)
;-)  Thanks.  Queued.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help