On Thu, Dec 4, 2014 at 5:12 PM, Michael J Gruber <git@xxxxxxxxxxxxxxxxxxxx> wrote: > Ævar Arnfjörð Bjarmason schrieb am 04.12.2014 um 16:49: >> On Thu, Dec 4, 2014 at 10:55 AM, Jeff King <peff@xxxxxxxx> wrote: >>> On Thu, Dec 04, 2014 at 09:29:04AM +0100, Torsten Bögershausen wrote: >>> >>>> How about >>>> alias git='LANGUAGE=de_DE.UTF-8 git' >>>> in your ~/.profile ? >>>> (Of course you need to change de to the language you want ) >>> >>> Besides being awkward in scripts (which will not respect the alias and >>> use a different language!), that variable will also be inherited by >>> programs git spawns. So the editor, for example, may end up in the wrong >>> language. >>> >>> I think respecting core.locale would make sense (probably the change >>> would go into git_setup_gettext(), but you may have to fight with the >>> setup code over looking at config so early in the process). >> >> I think we should just stick to the standard *nix way of doing this: >> Tell people to set their locale in their environment. >> >> If someone's having this issue it's also happening for all the >> binutils, and any other command-line and GUI program they use, unless >> they override using the standard way of doing so, by setting the >> relevant LC_* environment variables. >> >> If you want Git in English then create an alias to override its locale >> to be C, if you want the editor it spawns to be in some other language >> alias that to something that explicitly sets LC_* for that editor. >> >> Maybe I'm being overzealous about this (especially with the "I >> implemented this" blinders on), but let's not have Git set the >> precedent for other *nix programs that they all should come up with >> some custom way to override locales, that's something to be done at >> the OS locale library level, which we use. >> >>> However, I think the original question is not one of localizing git, but >>> rather of having it _not_ localized (avoiding the German translations). >>> There is a hack you can do that for that, which is to set >>> GIT_TEXTDOMAINDIR to something nonsensical (like "/"), which will mean >>> git cannot find the .po files, and just uses the builtin messages. >> >> You can, but the fact that that works is an internal implementation >> detail we shouldn't document or support. >> > > The main issue at hand is really that we have localised git but not its > man pages. Even if you understand English, the man pages don't help you > at all if you can't connect the technical terms used there to their > localised counterparts in git's messages. (NO_GETTEXT=y is my solution.) > > That is one of the many reasons why I proposed to have a dictionary of > the main technical terms for each language before we even localise git > in that language. In an ideal word, we would provide a simple solution > for looking these terms up both ways. I don't think we're going to have > localised man pages any time soon, are we? I think that's a great idea, and one that's only blocked on someone (hint hint) sending patches for it. It would be neat-o to have something to make translating the docs easier, i.e. PO files for sections of the man pages. There's tools to help with that which we could use. But there's no reason for us not to have translated glossaries in the meantime. -- 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