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.