Jeff King venit, vidit, dixit 13.09.2012 20:00: > 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 > The basic assumption is that we have people who are proficient in at least 2 languages. In fact, the initial i18n efforts were targeted at people who are much more comfortable in their $LANG than with LANG=C. For this category, being able to localize everything(*) is important. They will mostly work with $LANG projects. I don't think they're strawmen. For those proficient in 2 languages it's desirable to switch per project because it's likely they participate in projects with different $LANG preferences. Again, that means localizing everything(*). Additionally, setting core.i18n in global config is probably the better choice (compared to NO_GETTEXT=y) for those who are frustrated by git's translation in their usual $LANG. [git svn should pass that LANG to svn also etc.] The question is whether we have people who prefer to work with git in their $LANG even though project interaction requires a different language. They would probably run log/gitk/commit... in their $LANG but need format-patch and the like in project-lang. I do think we have people in this category here on the list, so they should speak up ;) Could they alias their format-patch to use "-c core.i18n=C" or such? Or have <command>.i18n on top? per-command config again ;) Michael -- 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