Jeff King <peff@xxxxxxxx> writes: > On Thu, Sep 13, 2012 at 02:26:55PM -0700, Junio C Hamano wrote: > >> Jeff King <peff@xxxxxxxx> writes: >> >> > I do not think they are incompatible if you separate it into three >> > categories: machine readable (must never be translated), for the current >> > user right now (current i18n), and for sharing with other humans >> > (i18n.projectlang). >> >> Anything you see as a user is potentially useful to other project >> participants, so I do not think there is a bright line that >> delineates the latter two classes. The output of format-patch is >> obviously meant as the latter, but how about the output from show or >> log? Is it worth trying to define the bright line somewhere, only >> to annoy users who may want to draw the line differently? > > I agree that the line is not bright. I do not know if it is worthwhile > or not. I think it will solve some practical problems, but it may also > introduce others. But basically having a per-repo LANG setting (which > is what the projectlang you are talking about would do) also does not > seem like a solution that people will use, because they will not get any > localization benefit at all. > > So again, I'd rather err on the side of pushing those things that are > near the line into the "do not translate" side, letting people use LANG > to localize the rest, and accepting that occasionally people are going > to accidentally show you output in a language you don't understand. But > hopefully that keeps it to "occasionally" and not "every time you send > out a patch". I am confused asto what you really want. In a Klingon-only project, I think it is perfectly fine to localize the diffstat summary line to Klingon. It is not machine readble, and it is not personal, but it is to be shared with project members, who all speak Klingon. Pushing more things to "do not translate" side of the line means robbing the benefit of i18n from people, no? -- 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