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

From: Michael J Gruber <git@drmicha.warpmail.net>
Date: Sep 14, 2012, 10:41 UTC
Message-ID: <505309EC.8040400@drmicha.warpmail.net>
In-Reply-To: <20120913180056.GA1696@sigill.intra.peff.net>

Jeff King venit, vidit, dixit 13.09.2012 20:00:

Show 39 quoted lines

> On Thu, Sep 13, 2012 at 10:30:52AM -0700, Junio C Hamano wrote:
> 
>>>      But it should not be per-command, but per-message, and
>>>      should include all output that is not diagnostic and is not
>>>      machine-parseable (e.g., what I mentioned above, request-pull
>>>      output, etc). If it is the project's language, then the team
>>>      members will need to know it anyway, so it should not be too big a
>>>      burden to have a potentially different language there than in the
>>>      diagnostic messages.
>>
>> No matter what the project languages is, machine parseable part will
>> not be localized but fixed to "C" anyway, so I do not think it comes
>> into the picture.
> 
> But there are parts that are neither machine-parseable nor diagnostics.
> The diffstat is one, but I mentioned others. Are those going to be
> forever fixed to LANG=C?
> 
> That does not bother me, but for a project whose team works entirely in
> Japanese (both individually, and when sharing code), they will still be
> stuck with these English-language snippets, and no way to localize them.
> Even though they may not speak a word of it.
> 
> I have no idea if such a team is a strawman or not; that is why I
> separated points 1 and 2. We can wait on point 2 until such a team shows
> up and complains (of course, they would have to come here and complain
> in English, so...).
> 
>> My take on this is, if there is the project language, it should
>> apply to _everything_.  Please do not introduce any per-command,
>> per-message, per-anything mess.  Just set LANG/LC_ALL up and be done
>> with it.
> 
> But isn't that arguing for localizing diffstat? It is not
> machine-parseable, so an all-Japanese team would want to localize it
> along with their diagnostics.
> 
> -Peff
>

The basic assumption is that we have people who are proficient in at least 2 languages. In fact, the initial i18n efforts were targeted at people who are much more comfortable in their $LANG than with LANG=C. For this category, being able to localize everything(*) is important. They will mostly work with $LANG projects. I don't think they're strawmen.

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.]

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 ;)

Michael