Re: Has anyone looked at Gettext support for Git itself?

> On Mon, May 17, 2010 at 14:32, Thomas Rast <trast@student.ethz.ch> wrote:
>> Ævar Arnfjörð Bjarmason wrote:
>>> On Sun, May 16, 2010 at 16:08, Jan Hudec <bulb@ucw.cz> wrote:
>>> > It would definitely not be fine to break *git*. You need to make sure no
>>> > part of git itself or anything distributed with it (gitk, git gui, gitweb,
>>> > things in contrib) is looking for any string that might be broken by
>>> > translating.
>>>
>>> Of course internal breakage, i.e. git-foo parsing the output from
>>> git-bar breaking under non-English is unacceptable. I meant that
>>> external tools now running under some non-English locale may start
>>> breaking if they're parsing the output and assuming English. The
>>> remedy for that is easy though, just prefix the calls to git with
>>> LC_ALL=C.
>>
>> And how exactly do you expect us to go back in history and prefix all
>> invocations of git in all scripts with LC_ALL=C?
>
> I don't expect you to. I just don't think it's unreasonable that if
> Git were to be internationalized that it behave like every other *nix
> program. If you have a Chinese locale and rely on the output of some
> program being in English your scripts will break if the OS
> subsequently upgrades to a new version of the program that has been
> translated to Chinese.
>
> The right way to handle that is to call programs like that with
> LC_ALL=C.
>
> The alternative would be to do introduce a variable like
> GIT_YES_REALLY_FOLLOW_LC_VARIABLES=1.
>
>> Porcelain such as git-status could be changed, but then there's not
>> that much of it anyway.  IMHO a set of standard documentation in each
>> language would be more useful.
>
> The output of the utilities is what people see when using Git, having
> that in your native language is more valuable than some howto being
> translated.