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

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 1, 2017, 17:38 UTC
Message-ID: <xmqq1stcvxih.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <20170401081256.fupby6oo5yf7wqdz@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 12 quoted lines

> On Thu, Mar 30, 2017 at 05:18:59PM +0200, Michael J Gruber wrote:
>
>> I read back the whole thread, and I'm still not sure if there's
>> consensus and how to go forward. Should we let the topic die? I don't
>> care too much personally, I just thought the mixed tranlations look
>> "unprofessional".
>
> I don't have a strong preference either way. I also don't care
> personally about the output (as I do not localize at all). My main
> concern was keeping the code simple for developers. But if consistent
> translation is important for people in other languages, I'm OK with
> whatever we need to do.

 (0) I do not mind the status quo, and I do not mind telling an end
     user who comes here with a translated message from die() to try
     running it again in C locale, either.

 (1) I do not think messages (including prefix) from die(),
     warning(), and error() are sacred, even when they are given by
     plumbing commands.  If the list concensus is that we want to
     see all translated in the ideal endgame, I think it is OK not
     to special case the plumbing.

 (2) I found your

         vreportf(_("fatal: "), err, params);

     a reasonable approach, if the we all agree with (1) as our
     goal, and want a way to gradually get us closer to the
     "everything translated" endgame.

I do not know what is professional and what is not in this context, though ;-).

Michael, thanks for pinging the thread.