Re: [RFC PATCH 0/5] Localise error headers

[Jeff King <peff@peff.net>]

On Tue, Jan 10, 2017 at 10:28:42AM -0800, Stefan Beller wrote:

> > And then presumably that mix would gradually move to 100% consistency as
> > more messages are translated. But the implicit question is: are there
> > die() messages that should never be translated? I'm not sure.
> 
> I would assume any plumbing command is not localizing?
> Because in plumbing land, (easily scriptable) you may find
> a grep on the output/stderr for a certain condition?

That's the assumption I'm challenging. Certainly the behavior and
certain aspects of the output of a plumbing command should remain the
same over time. But error messages to stderr?

It seems like they should be translated, because plumbing invoked on
behalf of porcelain scripts is going to send its stderr directly to the
user.

> To find a good example, "git grep die" giving me some food of though:
> 
> die_errno(..) should always take a string marked up for translation,
> because the errno string is translated?

Yes, I would think die_errno() is a no-brainer for translation, since
the strerror() will be translated.

>     apply.c:                die(_("internal error"));
> 
> That is funny, too. I think we should substitute that with
> 
>     die("BUG: untranslated, but what went wrong instead")

Yep. We did not consistently use "BUG:" in the early days. I would say
that "BUG" lines do not need to be translated. The point is that nobody
should ever see them, so it seems like there is little point in giving
extra work to translators.

-Peff