On Fri, Sep 14, 2012 at 7:11 AM, Jeff King <peff@xxxxxxxx> wrote: > On Thu, Sep 13, 2012 at 02:47:09PM -0700, Junio C Hamano wrote: > >> > 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? > > Yes. But you cannot please both sides without creating a third category, > as you noted. If you do not translate diffstat, then Klingon-only projects are > unhappy. If you do translate, then projects run in LANG=C will either > get public Klingon, or the project members will turn off all translation > and lose all benefit of i18n. I agree with Jeff on this. And "everything in $projectlang" is just like "everything in C", the problem remains. Suppose Chinese becomes a very popular language (if it has not been so), projects with dominant Chinese people would prefer Chinese. But large enough projects will involve non-Chinese people who prefer their native non-Chinese language as UI. I'm not pushing "do not translate" side. I just postpone it until a proper approach is found (preferably by Klingon teams who are upset about this "do not translate" patch). Supporting two non-C languages at the same time could be done (not very elegantly) by forking a process with the second language, which serves as gettext source for first process via pipes. The problem is drawing a line between team strings and local strings without butchering git source code. We're going through sort of the same process already, separating machine-readable strings and translatable strings. Maybe we can learn something before deciding whether to add the team string class. > So for the time being, I would rather choose LANG=C as a lingua franca > and err on the side of interoperability with other people and not > translating. And then if and when somebody feels like putting the effort > into doing i18n.projectlang by splitting out a third category, they are > welcome to. I just do not see much point in doing i18n.projectlang any > other way. -- Duy -- 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