On Wed, Sep 12, 2012 at 11:18:06AM -0700, Junio C Hamano wrote: > I am so far taking the silence in the thread to mean they do not mind > seeing the diffstat summary untranslated and they do not mind seeing > it in Klingon, as long as the three numbers are there with (+) and (-) > markings.
Actually, I have found the "Klingon" appearing in the diffstat of recent messages to the list to be mildly annoying. I can decipher it, of course, but in some cases I do not even have the glyphs in my font to render the string, and it is quite ugly. I think in an ideal world each repo could specify a "project language" and, and diffstat, Signed-off-by, and [PATCH] would all be in that language. Practically speaking, I'm not sure how much effort that is worth; it seems like non-English speakers adapt to a few English phrases (for example, email headers and date formats are all in English; I imagine many clients localize them behind the scenes, but certainly the "git format-patch && $EDITOR && git send-email" workflow does not and should not). I think I'd prefer: 1. Revert diffstat to always be in English/C locale for now. For all commands. People too frequently end up showing the output of things besides format-patch. It means they will have to read the English when they are just running locally, but since format-patch is generating it, it is something that they would need to understand anyway. 2. If people on non-English projects find that too cumbersome, then we can switch the "English/C" above for `i18n.projectlang` or something. 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. But take my opinion with a grain of salt. English is my first language, so I have zero first-hand experience with these issues. For most open source projects that operate in English, I think just (1) will be fine. The real test for needing (2) would not be a project like git, but a project conducted solely in another language, where some of the participants do not speak English at all. -Peff -- 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