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. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html