Re: [PATCH RFC 0/2] Mixing English and a local language

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 13, 2012, 17:52 UTC
Message-ID: <7vr4q595fb.fsf@alter.siamese.dyndns.org>
In-Reply-To: <7v4nn1akz7.fsf@alter.siamese.dyndns.org>

Junio C Hamano <gitster@pobox.com> writes:

Show 20 quoted lines

>>      But it should not be per-command, but per-message, and
>>      should include all output that is not diagnostic and is not
>>      machine-parseable (e.g., what I mentioned above, request-pull
>>      output, etc). If it is the project's language, then the team
>>      members will need to know it anyway, so it should not be too big a
>>      burden to have a potentially different language there than in the
>>      diagnostic messages.
>
> No matter what the project languages is, machine parseable part will
> not be localized but fixed to "C" anyway, so I do not think it comes
> into the picture.
>
> My take on this is, if there is the project language, it should
> apply to _everything_.  Please do not introduce any per-command,
> per-message, per-anything mess.  Just set LANG/LC_ALL up and be done
> with it.
>
> And I think you justified why that is the right thing to do very
> well in the second sentence in the above paragraph I quoted from
> you.

You seem to be saying that diagnostic does not have to be in project language, but I do not think it is the right thing to do. The first response to "Frotz does not work" is often "What do you exactly mean? How did you run Frotz? What error message are you getting from it?", and you do not want to get back the diagnostics in Klingon.