On Thu, Sep 13, 2012 at 10:30:52AM -0700, Junio C Hamano wrote:
quoted
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.
But there are parts that are neither machine-parseable nor diagnostics.
The diffstat is one, but I mentioned others. Are those going to be
forever fixed to LANG=C?
That does not bother me, but for a project whose team works entirely in
Japanese (both individually, and when sharing code), they will still be
stuck with these English-language snippets, and no way to localize them.
Even though they may not speak a word of it.
I have no idea if such a team is a strawman or not; that is why I
separated points 1 and 2. We can wait on point 2 until such a team shows
up and complains (of course, they would have to come here and complain
in English, so...).
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.
But isn't that arguing for localizing diffstat? It is not
machine-parseable, so an all-Japanese team would want to localize it
along with their diagnostics.
-Peff