On Fri, Sep 14, 2012 at 7:11 AM, Jeff King <p...@peff.net> 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.
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

Reply via email to