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

From: Jeff King <peff@peff.net>
Date: Jan 11, 2017, 11:37 UTC
Message-ID: <20170111113725.avl3wetwrfezdni2@sigill.intra.peff.net>
In-Reply-To: <CAGZ79kYVc0YQ4okrTHGiYQzPqfiVAm_f7orXdkhwgf5kMPXj-w@mail.gmail.com>

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

Show 7 quoted lines

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

Show 5 quoted lines

>     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