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

Reply via email to