On Mon, May 17, 2010 at 14:32, Thomas Rast <trast@xxxxxxxxxxxxxxx> wrote: > Ævar Arnfjörð Bjarmason wrote: >> On Sun, May 16, 2010 at 16:08, Jan Hudec <bulb@xxxxxx> 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. -- 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