On Thu, Sep 13, 2012 at 10:30:52AM -0700, Junio C Hamano wrote:
> > 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.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html