Re: [PATCH] Revert diffstat back to English

On Fri, Sep 14, 2012 at 7:11 AM, Jeff King [off-list ref] wrote:

On Thu, Sep 13, 2012 at 02:47:09PM -0700, Junio C Hamano wrote:

quoted

quoted

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