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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Sep 14, 2012 at 5:41 PM, Michael J Gruber
<git@xxxxxxxxxxxxxxxxxxxx> wrote:
> 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.

> 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@xxxxxxxxx> wrote:
> 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
--
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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]