Re: [PATCH RFC 0/2] Mixing English and a local language

From: Nguyen Thai Ngoc Duy <pclouds@gmail.com>
Date: Sep 14, 2012, 11:35 UTC
Message-ID: <CACsJy8DKUdn-eY1P1d6vFz34SvEbUBm07ZR3xy5xLaKxE+Wnqg@mail.gmail.com>
In-Reply-To: <505309EC.8040400@drmicha.warpmail.net>

On Fri, Sep 14, 2012 at 5:41 PM, Michael J Gruber <git@drmicha.warpmail.net> wrote:

Show 8 quoted lines

> For those proficient in 2 languages it's desirable to switch per project
> because it's likely they participate in projects with different $LANG
> preferences. Again, that means localizing everything(*). Additionally,
> setting core.i18n in global config is probably the better choice
> (compared to NO_GETTEXT=y) for those who are frustrated by git's
> translation in their usual $LANG.
>
> [git svn should pass that LANG to svn also etc.]

We should honor LINGUAS variable on installation. Only languages listed in that variable are installed. Many if not most of projects do that already. That's probably better than yet another switch.

Show 9 quoted lines

> The question is whether we have people who prefer to work with git in
> their $LANG even though project interaction requires a different
> language. They would probably run log/gitk/commit... in their $LANG but
> need format-patch and the like in project-lang.
>
> I do think we have people in this category here on the list, so they
> should speak up ;) Could they alias their format-patch to use "-c
> core.i18n=C" or such? Or have <command>.i18n on top? per-command config
> again ;)

Probably not needed, but probably won't hurt repeating: I do :) And things should just work, at least most of the time. When I set LANG, I prefer to have everything in $LANG unless required otherwise (sending to English speaking teams is one of them). But the exceptions should be limited.

On Fri, Sep 14, 2012 at 12:52 AM, Junio C Hamano <gitster@pobox.com> wrote:

Show 6 quoted lines

> You seem to be saying that diagnostic does not have to be in project
> language, but I do not think it is the right thing to do.  The first
> response to "Frotz does not work" is often "What do you exactly
> mean?  How did you run Frotz?  What error message are you getting
> from it?", and you do not want to get back the diagnostics ints
> Klingon.

Whether you like it or not, all localized software has this problem. Perhaps the only difference with commercial software is that they have support line that also understands Klingon. I don't see any problems with asking the reporter to translate error messages back to English, assume that they report in English so they do know English. Given a specific context, Klingon illiterates can even manually revert Klingon text back to English because we have the all the translations. But it's probably faster to just ask the reporter.

-- 
Duy