{"thread":{"id":"23816","subject":"Has anyone looked at Gettext support for Git itself?","startedAt":"2010-05-15T22:10:09Z","lastAt":"2010-05-22T11:01:58Z","messageCount":20,"participants":["Ævar Arnfjörð Bjarmason","Jakub Narebski","Dmitry Potapov","Jan Hudec","Thomas Singer","Thomas Rast","Marc Weber","Will Palmer","Peter Krefting","Michael J Gruber","demerphq"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"141747","messageId":"AANLkTinlDF-aKDjwvgZEqtUgzW7MCIuElQ_RfJn_RkZp@mail.gmail.com","threadId":"23816","inReplyTo":null,"subject":"Has anyone looked at Gettext support for Git itself?","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2010-05-15T22:10:09Z","receivedAt":"2010-05-15T22:10:09Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"I couldn't find anything about this in the list archives. Have there\nbeen any discussions of adding internationalization support to Git\nitself? I.e. the interface messages that the core Git utilities emit.\n\nI tried to get started with integrating GNU Gettext, but gnuish\nassumptions it makes about building make it a bit hard.\n\nIs there perhaps another gettext implementation that would be more\nsuitable for Git?\n\nI'd be interested in submitting patches to make the existing strings\ntranslatable if someone could get the tool + build skeleton going.\n"},{"id":"141750","messageId":"m3pr0wd880.fsf@localhost.localdomain","threadId":"23816","inReplyTo":"AANLkTinlDF-aKDjwvgZEqtUgzW7MCIuElQ_RfJn_RkZp@mail.gmail.com","subject":"Re: Has anyone looked at Gettext support for Git itself?","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2010-05-16T00:03:15Z","receivedAt":"2010-05-16T00:03:15Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Ævar Arnfjörð Bjarmason writes:\n\n> I couldn't find anything about this in the list archives. Have there\n> been any discussions of adding internationalization support to Git\n> itself? I.e. the interface messages that the core Git utilities emit.\n> \n> I tried to get started with integrating GNU Gettext, but gnuish\n> assumptions it makes about building make it a bit hard.\n> \n> Is there perhaps another gettext implementation that would be more\n> suitable for Git?\n> \n> I'd be interested in submitting patches to make the existing strings\n> translatable if someone could get the tool + build skeleton going.\n\nFirst, git uses multiple programming languages: you would need a\nsolution that would work for programs in C (gettext), for Perl\n(Locale::Maketext or less known Data::Localize), probably for Python,\nand what would probably give most problems for shell scripts.\n\nSecond, you would need to take care that changing locale wouldn't\nbreak git. It can be done either via setting LC_ALL=C in\ngit-sh-setup, or by translation only porcelain, and leaving plumbing\nunchanged.\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"141753","messageId":"AANLkTikgs3d1YagU5lRCkEM9uwWe9dmifbHvIjhsk_wF@mail.gmail.com","threadId":"23816","inReplyTo":"m3pr0wd880.fsf@localhost.localdomain","subject":"Re: Has anyone looked at Gettext support for Git itself?","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2010-05-16T01:12:20Z","receivedAt":"2010-05-16T01:12:20Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Sun, May 16, 2010 at 00:03, Jakub Narebski wrote:\n> Ævar Arnfjörð Bjarmason writes:\n>\n>> I couldn't find anything about this in the list archives. Have there\n>> been any discussions of adding internationalization support to Git\n>> itself? I.e. the interface messages that the core Git utilities emit.\n>>\n>> I tried to get started with integrating GNU Gettext, but gnuish\n>> assumptions it makes about building make it a bit hard.\n>>\n>> Is there perhaps another gettext implementation that would be more\n>> suitable for Git?\n>>\n>> I'd be interested in submitting patches to make the existing strings\n>> translatable if someone could get the tool + build skeleton going.\n>\n> First, git uses multiple programming languages: you would need a\n> solution that would work for programs in C (gettext), for Perl\n> (Locale::Maketext or less known Data::Localize), probably for Python,\n> and what would probably give most problems for shell scripts.\n\nAll of these languages can read gettext, but you'd need some glue for\neach so that they could get to the files.\n\nIt would probably make the most sense to have distinct message files\nfor each program, e.g.:\n\n /usr/share/locale/*/LC_MESSAGES/git-bisect.mo\n\nThat way they could be translated incrementally, and the programs\nwould load only the small subset of messages they need.\n\nFor e.g. shellscripts this can be done as (adapted from a localized\nscript in my /usr/bin/):\n\n export TEXTDOMAIN=git-bisect\n export TEXTDOMAINDIR=/usr/share/locale/\n GETTEXT=`which gettext 2> /dev/null`\n if [ -z $GETTEXT ] ; then GETTEXT='echo -n'; fi\n\nAnd then just:\n\n - echo \"We are not bisecting.\"\n + $GETTEXT \"We are not bisecting.\"\n\n> Second, you would need to take care that changing locale wouldn't\n> break git.  It can be done either via setting LC_ALL=C in\n> git-sh-setup, or by translation only porcelain, and leaving plumbing\n> unchanged.\n\nI think it would be fine to break it if that means that Git would\nsuddenly start speaking your language, you can always just set LC_ALL\nif you have some scripts that break as a result of parsing the current\noutput in English.\n"},{"id":"141757","messageId":"20100516053651.GB17200@dpotapov.dyndns.org","threadId":"23816","inReplyTo":"AANLkTikgs3d1YagU5lRCkEM9uwWe9dmifbHvIjhsk_wF@mail.gmail.com","subject":"Re: Has anyone looked at Gettext support for Git itself?","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2010-05-16T05:36:51Z","receivedAt":"2010-05-16T05:36:51Z","isPatch":false,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"On Sun, May 16, 2010 at 01:12:20AM +0000, Ævar Arnfjörð Bjarmason wrote:\n> \n> GETTEXT=`which gettext 2> /dev/null`\n> if [ -z $GETTEXT ] ; then GETTEXT='echo -n'; fi\n\n'echo -n' is not portable, and it is not used in git for this reason.\n\nDmitry\n\n> And then just:\n> \n> - echo \"We are not bisecting.\"\n> + $GETTEXT \"We are not bisecting.\"\n\nIf gettext does not add the trailing newline to the message then it is\nclearly not equivalent replacement.\n\n\nDmitry\n"},{"id":"141769","messageId":"AANLkTilWXqXUtDU-r6j6DwBJWK3JoQNwGnnQPHQWhIUF@mail.gmail.com","threadId":"23816","inReplyTo":"20100516053651.GB17200@dpotapov.dyndns.org","subject":"Re: Has anyone looked at Gettext support for Git itself?","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2010-05-16T13:12:55Z","receivedAt":"2010-05-16T13:12:55Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Sun, May 16, 2010 at 05:36, Dmitry Potapov wrote:\n> 'echo -n' is not portable, and it is not used in git for this reason.\n\n> If gettext does not add the trailing newline to the message then it is\n> clearly not equivalent replacement.\n\nThat was just meant to be a non-working example of how we could read\ngettext from .sh too. I didn't actually try to run it. Obviously a\nreal implementation wouldn't use 'echo -n' and wouldn't suffer from\nnewline issues.\n\nI just wanted to show that regardless of whether the program is in C,\nPerl or Shell a gettext implementation can degrade gracefully. That's\nall.\n"},{"id":"141774","messageId":"20100516160800.GB22447@efreet.light.src","threadId":"23816","inReplyTo":"AANLkTikgs3d1YagU5lRCkEM9uwWe9dmifbHvIjhsk_wF@mail.gmail.com","subject":"Re: Has anyone looked at Gettext support for Git itself?","fromName":"Jan Hudec","fromEmail":"bulb@ucw.cz","sentAt":"2010-05-16T16:08:00Z","receivedAt":"2010-05-16T16:08:00Z","isPatch":false,"sender":{"key":"bulb@ucw.cz","avatar":null},"body":"On Sun, May 16, 2010 at 01:12:20 +0000, Ævar Arnfjörð Bjarmason wrote:\n> On Sun, May 16, 2010 at 00:03, Jakub Narebski wrote:\n> > Ævar Arnfjörð Bjarmason writes:\n> >\n> >> I couldn't find anything about this in the list archives. Have there\n> >> been any discussions of adding internationalization support to Git\n> >> itself? I.e. the interface messages that the core Git utilities emit.\n> >>\n> >> I tried to get started with integrating GNU Gettext, but gnuish\n> >> assumptions it makes about building make it a bit hard.\n> >>\n> >> Is there perhaps another gettext implementation that would be more\n> >> suitable for Git?\n\nGettext iself does not make any assumptions about building. It's only it's\nmanual that gives more space to setting up gettext use with autotools than\nmanually. But doing it manually is really not too hard.\n\nBasically one just needs to set up scripts or makefile targets to:\n - Re-generate the translation template (.pot)\n All this takes is invoking xgettext with correct parameters on the right\n list of files. It might be necessary to invoke it with different arguments\n for sources in different languages if git needed to use non-default\n options, but I think the defaults would be ok.\n - Update the translations with new strings from the template.\n All this takes is invoking msgmerge for each .po file with the appropriate\n template.\n\nThan makefile targets are needed to generate and install the .mc files, but\nthat's just trivial.\n\nI don't think the automake support saves any work there. It saves you from\nlearning the tool invocations, but you have to learn automake instead.\nThe hardest part is makring all the translatable strings in the code and\nthe gnuish infrastructure just isn't much help there anyway.\n\n> >> I'd be interested in submitting patches to make the existing strings\n> >> translatable if someone could get the tool + build skeleton going.\n> >\n> > First, git uses multiple programming languages: you would need a\n> > solution that would work for programs in C (gettext), for Perl\n> > (Locale::Maketext or less known Data::Localize), probably for Python,\n> > and what would probably give most problems for shell scripts.\n> \n> All of these languages can read gettext, but you'd need some glue for\n> each so that they could get to the files.\n> \n> It would probably make the most sense to have distinct message files\n> for each program, e.g.:\n> \n> /usr/share/locale/*/LC_MESSAGES/git-bisect.mo\n> \n> That way they could be translated incrementally, and the programs\n> would load only the small subset of messages they need.\n\nI think it would make things more complicated and not really help anything,\nsince many messages may in fact be shared or come from common parts so it\nwould need to be loaded by many commands anyway. On the other hand the .mc\nfile is an external hash, so the access even to a large .mc will be quite\nfast.\n\n> > Second, you would need to take care that changing locale wouldn't\n> > break git.  It can be done either via setting LC_ALL=C in\n> > git-sh-setup, or by translation only porcelain, and leaving plumbing\n> > unchanged.\n> \n> I think it would be fine to break it if that means that Git would\n> suddenly start speaking your language, you can always just set LC_ALL\n> if you have some scripts that break as a result of parsing the current\n> output in English.\n\nIt would definitely not be fine to break *git*. You need to make sure no\npart of git itself or anything distributed with it (gitk, git gui, gitweb,\nthings in contrib) is looking for any string that might be broken by\ntranslating.\n\n-- \n\t\t\t\t\t\t Jan 'Bulb' Hudec \n"},{"id":"141775","messageId":"4BF022F8.6080805@syntevo.com","threadId":"23816","inReplyTo":"AANLkTinlDF-aKDjwvgZEqtUgzW7MCIuElQ_RfJn_RkZp@mail.gmail.com","subject":"Re: Has anyone looked at Gettext support for Git itself?","fromName":"Thomas Singer","fromEmail":"thomas.singer@syntevo.com","sentAt":"2010-05-16T16:53:12Z","receivedAt":"2010-05-16T16:53:12Z","isPatch":false,"sender":{"key":"thomas.singer@syntevo.com","avatar":null},"body":"> Have there\n> been any discussions of adding internationalization support to Git\n> itself? I.e. the interface messages that the core Git utilities emit.\n\n>From me perspective of a developer who is invoking the Git executable from\nour application: ensure that there is a way to tell Git to output text in a\nfixed language, so other applications (e.g. ours) can parse the output.(1)\n\n-- \nBest regards,\nThomas Singer\n=============\nsyntevo GmbH\nhttp://www.syntevo.com\nhttp://blog.syntevo.com\n\n(1) Yes, I know that this is not 100% safe, because messages can be\ndifferent in different Git version.\n"},{"id":"141778","messageId":"AANLkTinGSBRMRyaD0w2p9PQELLA6ThvKFdi6hcNWBTxr@mail.gmail.com","threadId":"23816","inReplyTo":"20100516160800.GB22447@efreet.light.src","subject":"Re: Has anyone looked at Gettext support for Git itself?","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2010-05-16T17:37:34Z","receivedAt":"2010-05-16T17:37:34Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Sun, May 16, 2010 at 16:08, Jan Hudec wrote:\n> On Sun, May 16, 2010 at 01:12:20 +0000, Ævar Arnfjörð Bjarmason wrote:\n>> On Sun, May 16, 2010 at 00:03, Jakub Narebski wrote:\n>> > Ævar Arnfjörð Bjarmason writes:\n>> >\n>> >> I couldn't find anything about this in the list archives. Have there\n>> >> been any discussions of adding internationalization support to Git\n>> >> itself? I.e. the interface messages that the core Git utilities emit.\n>> >>\n>> >> I tried to get started with integrating GNU Gettext, but gnuish\n>> >> assumptions it makes about building make it a bit hard.\n>> >>\n>> >> Is there perhaps another gettext implementation that would be more\n>> >> suitable for Git?\n>\n> Gettext iself does not make any assumptions about building. It's only it's\n> manual that gives more space to setting up gettext use with autotools than\n> manually. But doing it manually is really not too hard.\n>\n> Basically one just needs to set up scripts or makefile targets to:\n>  - Re-generate the translation template (.pot)\n>   All this takes is invoking xgettext with correct parameters on the right\n>   list of files. It might be necessary to invoke it with different arguments\n>   for sources in different languages if git needed to use non-default\n>   options, but I think the defaults would be ok.\n>  - Update the translations with new strings from the template.\n>   All this takes is invoking msgmerge for each .po file with the appropriate\n>   template.\n>\n> Than makefile targets are needed to generate and install the .mc files, but\n> that's just trivial.\n>\n> I don't think the automake support saves any work there. It saves you from\n> learning the tool invocations, but you have to learn automake instead.\n> The hardest part is makring all the translatable strings in the code and\n> the gnuish infrastructure just isn't much help there anyway.\n\nRight, someone has to come up with all the makefile / build magic one\nway or another.\n\nI'm just really not familiar with that side of things, which was why I\nasked if someone had tried it already.\n\nIs someone on-list familiar with a non-GNU program that does all its\ngettext support manually, i.e. not with the gnu autotools?\n\nI'm not, examples would help :)\n\n>> All of these languages can read gettext, but you'd need some glue for\n>> each so that they could get to the files.\n>>\n>> It would probably make the most sense to have distinct message files\n>> for each program, e.g.:\n>>\n>>     /usr/share/locale/*/LC_MESSAGES/git-bisect.mo\n>>\n>> That way they could be translated incrementally, and the programs\n>> would load only the small subset of messages they need.\n>\n> I think it would make things more complicated and not really help anything,\n> since many messages may in fact be shared or come from common parts so it\n> would need to be loaded by many commands anyway. On the other hand the .mc\n> file is an external hash, so the access even to a large .mc will be quite\n> fast.\n\nRight, squashing them all into one .mo file may be the best thing,\nparticularly, as you mention, for the case of displaying messages from\nmore than one tool.\n\nThat might mean message collisions, but that can be solved these days\nwith gettext's msgctxt.\n\n> It would definitely not be fine to break *git*. You need to make sure no\n> part of git itself or anything distributed with it (gitk, git gui, gitweb,\n> things in contrib) is looking for any string that might be broken by\n> translating.\n\nOf course internal breakage, i.e. git-foo parsing the output from\ngit-bar breaking under non-English is unacceptable. I meant that\nexternal tools now running under some non-English locale may start\nbreaking if they're parsing the output and assuming English. The\nremedy for that is easy though, just prefix the calls to git with\nLC_ALL=C.\n"},{"id":"141822","messageId":"201005171632.48253.trast@student.ethz.ch","threadId":"23816","inReplyTo":"AANLkTinGSBRMRyaD0w2p9PQELLA6ThvKFdi6hcNWBTxr@mail.gmail.com","subject":"Re: Has anyone looked at Gettext support for Git itself?","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2010-05-17T14:32:47Z","receivedAt":"2010-05-17T14:32:47Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Ævar Arnfjörð Bjarmason wrote:\n> On Sun, May 16, 2010 at 16:08, Jan Hudec wrote:\n> > It would definitely not be fine to break *git*. You need to make sure no\n> > part of git itself or anything distributed with it (gitk, git gui, gitweb,\n> > things in contrib) is looking for any string that might be broken by\n> > translating.\n> \n> Of course internal breakage, i.e. git-foo parsing the output from\n> git-bar breaking under non-English is unacceptable. I meant that\n> external tools now running under some non-English locale may start\n> breaking if they're parsing the output and assuming English. The\n> remedy for that is easy though, just prefix the calls to git with\n> LC_ALL=C.\n\nAnd how exactly do you expect us to go back in history and prefix all\ninvocations of git in all scripts with LC_ALL=C?\n\nPorcelain such as git-status could be changed, but then there's not\nthat much of it anyway. IMHO a set of standard documentation in each\nlanguage would be more useful.\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"141823","messageId":"AANLkTil0iESsCpHm-X3iiMZC3sEzCqYvXjsZiIHvFz3n@mail.gmail.com","threadId":"23816","inReplyTo":"201005171632.48253.trast@student.ethz.ch","subject":"Re: Has anyone looked at Gettext support for Git itself?","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2010-05-17T14:53:16Z","receivedAt":"2010-05-17T14:53:16Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Mon, May 17, 2010 at 14:32, Thomas Rast wrote:\n> Ævar Arnfjörð Bjarmason wrote:\n>> On Sun, May 16, 2010 at 16:08, Jan Hudec wrote:\n>> > It would definitely not be fine to break *git*. You need to make sure no\n>> > part of git itself or anything distributed with it (gitk, git gui, gitweb,\n>> > things in contrib) is looking for any string that might be broken by\n>> > translating.\n>>\n>> Of course internal breakage, i.e. git-foo parsing the output from\n>> git-bar breaking under non-English is unacceptable. I meant that\n>> external tools now running under some non-English locale may start\n>> breaking if they're parsing the output and assuming English. The\n>> remedy for that is easy though, just prefix the calls to git with\n>> LC_ALL=C.\n>\n> And how exactly do you expect us to go back in history and prefix all\n> invocations of git in all scripts with LC_ALL=C?\n\nI don't expect you to. I just don't think it's unreasonable that if\nGit were to be internationalized that it behave like every other *nix\nprogram. If you have a Chinese locale and rely on the output of some\nprogram being in English your scripts will break if the OS\nsubsequently upgrades to a new version of the program that has been\ntranslated to Chinese.\n\nThe right way to handle that is to call programs like that with\nLC_ALL=C.\n\nThe alternative would be to do introduce a variable like\nGIT_YES_REALLY_FOLLOW_LC_VARIABLES=1.\n\n> Porcelain such as git-status could be changed, but then there's not\n> that much of it anyway.  IMHO a set of standard documentation in each\n> language would be more useful.\n\nThe output of the utilities is what people see when using Git, having\nthat in your native language is more valuable than some howto being\ntranslated.\n"},{"id":"141824","messageId":"1274108567-sup-1380@nixos","threadId":"23816","inReplyTo":"AANLkTinlDF-aKDjwvgZEqtUgzW7MCIuElQ_RfJn_RkZp@mail.gmail.com","subject":"Re: Has anyone looked at Gettext support for Git itself?","fromName":"Marc Weber","fromEmail":"marco-oweber@gmx.de","sentAt":"2010-05-17T15:04:56Z","receivedAt":"2010-05-17T15:04:56Z","isPatch":false,"sender":{"key":"marco-oweber@gmx.de","avatar":null},"body":"Excerpts from Ævar Arnfjörð Bjarmason's message of Sun May 16 00:10:09 +0200 2010:\n> I couldn't find anything about this in the list archives. Have there\n> been any discussions of adding internationalization support to Git\n> itself? I.e. the interface messages that the core Git utilities emit.\n> \n> I tried to get started with integrating GNU Gettext, but gnuish\n> assumptions it makes about building make it a bit hard.\n> \n> Is there perhaps another gettext implementation that would be more\n> suitable for Git?\n> \n> I'd be interested in submitting patches to make the existing strings\n> translatable if someone could get the tool + build skeleton going.\n\nIt may sound silly and stupid: My coworker has had much trouble because\nhe doesn't know English at all.\nYou could help those people very much by creating a git-translator.org\npage where you can copy paste failures which are translated only.\n\nIn the end you must have seen any failure multiple times to cope with\nit - no matter which language this message was written in. However\nhaving an understandable text may help.\n\nMarc Weber\n"},{"id":"141825","messageId":"201005171712.22763.trast@student.ethz.ch","threadId":"23816","inReplyTo":"AANLkTil0iESsCpHm-X3iiMZC3sEzCqYvXjsZiIHvFz3n@mail.gmail.com","subject":"Re: Has anyone looked at Gettext support for Git itself?","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2010-05-17T15:12:22Z","receivedAt":"2010-05-17T15:12:22Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Ævar Arnfjörð Bjarmason wrote:\n> On Mon, May 17, 2010 at 14:32, Thomas Rast wrote:\n> > Ævar Arnfjörð Bjarmason wrote:\n> >>\n> >> just prefix the calls to git with LC_ALL=C.\n> >\n> > And how exactly do you expect us to go back in history and prefix all\n> > invocations of git in all scripts with LC_ALL=C?\n> \n> I don't expect you to. I just don't think it's unreasonable that if\n> Git were to be internationalized that it behave like every other *nix\n> program. If you have a Chinese locale and rely on the output of some\n> program being in English your scripts will break if the OS\n> subsequently upgrades to a new version of the program that has been\n> translated to Chinese.\n\nI've bumped against these hysterical raisins in the past too, so you\nhave my sympathy. But git's API is the set of its plumbing commands,\nI/O, arguments and all.\n\nWe do not give a similar promise for porcelain commands, which\nincludes most of the frequently used commands that also have a bunch\nof translatable output like status, clone, fetch, branch, etc. You\ncould start by translating the helpful comments in status, commit and\nrebase -i.\n\nHowever, I'm just trying to point out that your suggested solution\n\n> The right way to handle that is to call programs like that with\n> LC_ALL=C.\n\nwill never fly, and that git will, e.g., never be able to consistently\ncall a commit a \"Version\" [de] because for-each-ref must forever fill\nthe %(type) field with \"commit\".\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"141829","messageId":"20100517175939.GA3575@efreet.light.src","threadId":"23816","inReplyTo":"201005171712.22763.trast@student.ethz.ch","subject":"Re: Has anyone looked at Gettext support for Git itself?","fromName":"Jan Hudec","fromEmail":"bulb@ucw.cz","sentAt":"2010-05-17T17:59:40Z","receivedAt":"2010-05-17T17:59:40Z","isPatch":false,"sender":{"key":"bulb@ucw.cz","avatar":null},"body":"On Mon, May 17, 2010 at 17:12:22 +0200, Thomas Rast wrote:\n> Ævar Arnfjörð Bjarmason wrote:\n> > On Mon, May 17, 2010 at 14:32, Thomas Rast wrote:\n> > > Ævar Arnfjörð Bjarmason wrote:\n> > >>\n> > >> just prefix the calls to git with LC_ALL=C.\n> > >\n> > > And how exactly do you expect us to go back in history and prefix all\n> > > invocations of git in all scripts with LC_ALL=C?\n> > \n> > I don't expect you to. I just don't think it's unreasonable that if\n> > Git were to be internationalized that it behave like every other *nix\n> > program. If you have a Chinese locale and rely on the output of some\n> > program being in English your scripts will break if the OS\n> > subsequently upgrades to a new version of the program that has been\n> > translated to Chinese.\n> \n> I've bumped against these hysterical raisins in the past too, so you\n> have my sympathy. But git's API is the set of its plumbing commands,\n> I/O, arguments and all.\n\nThe plumbing commands' output, obviously, may not become locale dependent\nsince it is indeed part of the API. It may sometimes print localized error\nmessages though where one can't really do anything besides relying them to\nthe user anyway.\n\nThere are cases though, where somebody calls *porcelain* commands in their\nscripts and there they occasionally may need this LC_ALL=C thing. I suppose\nhaving a global option to turn off localization might be useful for such\nusers.\n\n> We do not give a similar promise for porcelain commands, which\n> includes most of the frequently used commands that also have a bunch\n> of translatable output like status, clone, fetch, branch, etc. You\n> could start by translating the helpful comments in status, commit and\n> rebase -i.\n> \n> However, I'm just trying to point out that your suggested solution\n> \n> > The right way to handle that is to call programs like that with\n> > LC_ALL=C.\n> \n> will never fly, and that git will, e.g., never be able to consistently\n> call a commit a \"Version\" [de] because for-each-ref must forever fill\n> the %(type) field with \"commit\".\n\nI would personally consider it too obvious that \"programs like that\" means\nporcelain to mention it.\n\nMost error messages may be translated even in plumbing though, just like they\nare translated in standard unix commands.\n\n-- \n\t\t\t\t\t\t Jan 'Bulb' Hudec \n"},{"id":"141831","messageId":"1274122619.4780.36.camel@dreddbeard","threadId":"23816","inReplyTo":"20100517175939.GA3575@efreet.light.src","subject":"Re: Has anyone looked at Gettext support for Git itself?","fromName":"Will Palmer","fromEmail":"wmpalmer@gmail.com","sentAt":"2010-05-17T18:56:59Z","receivedAt":"2010-05-17T18:56:59Z","isPatch":false,"sender":{"key":"wmpalmer@gmail.com","avatar":"https://avatars.githubusercontent.com/u/357044?v=4"},"body":"On Mon, 2010-05-17 at 19:59 +0200, Jan Hudec wrote:\n> On Mon, May 17, 2010 at 17:12:22 +0200, Thomas Rast wrote:\n> > Ævar Arnfjörð Bjarmason wrote:\n> > > On Mon, May 17, 2010 at 14:32, Thomas Rast wrote:\n> > > > Ævar Arnfjörð Bjarmason wrote:\n> \n> There are cases though, where somebody calls *porcelain* commands in their\n> scripts and there they occasionally may need this LC_ALL=C thing. I suppose\n> having a global option to turn off localization might be useful for such\n> users.\n\nWould it be that bad to define something like GIT_PLUMBING=1 to mean \"I\nam using this as plumbing\"? It seems that this is the way things are\nheaded with --porcelain, even if the name is backwards.\n\nI agree that error messages should be localised either way- if you're\ntrying to parse an error message, something's always gone wrong.\n\nDoes anyone know how large of a non-english-speaking community git\ncurrently has? Would this effort include adding localised git command\nnames or arguments?\n\nIt may also be worth mentioning that a git \"commit\", for example,\ndoesn't have anything (other than historical reasons) to do with the\nEnglish word \"commit\". A git commit is a git commit, and perhaps such\nconceptual terms should best be left untranslated anyway. It would\ncertainly make it easier to answer questions in #git if people continued\nto use the same terms everywhere. Just as a weak anecdotal argument,\nwhen someone uses the term \"revision\" in #git, there's generally a lack\nof understanding about what a \"commit\" is. \"commit\" means something very\nspecific in git, and I would hesitate to try to translate that into\nanother language as if it's just a synonym for \"revision\" or\n\"checkpoint\", or \"transaction\", etc\n\n\n-- \n-- Will\n"},{"id":"141853","messageId":"alpine.DEB.2.00.1005180810440.27004@ds9.cixit.se","threadId":"23816","inReplyTo":"AANLkTinlDF-aKDjwvgZEqtUgzW7MCIuElQ_RfJn_RkZp@mail.gmail.com","subject":"Re: Has anyone looked at Gettext support for Git itself?","fromName":"Peter Krefting","fromEmail":"peter@softwolves.pp.se","sentAt":"2010-05-18T07:12:29Z","receivedAt":"2010-05-18T07:12:29Z","isPatch":false,"sender":{"key":"peter@softwolves.pp.se","avatar":"https://avatars.githubusercontent.com/u/990764?v=4"},"body":"Ævar Arnfjörð Bjarmason:\n\n> I couldn't find anything about this in the list archives. Have there been \n> any discussions of adding internationalization support to Git itself? I.e. \n> the interface messages that the core Git utilities emit.\n\nSo far, it seems that most people using it has been the kind of people who \nthing computers should speak only English.\n\nI'd be happy to help out with a gettextization of Git, including doing a \nSwedish translation. I've already translated gitk and git-gui to Swedish \n(and I use the translations in my day-to-day work), and would love to have \nthe rest of the command set speak the same language as me as well.\n\n-- \n\\\\// Peter - http://www.softwolves.pp.se/\n"},{"id":"141855","messageId":"4BF246ED.3040706@drmicha.warpmail.net","threadId":"23816","inReplyTo":"1274122619.4780.36.camel@dreddbeard","subject":"Re: Has anyone looked at Gettext support for Git itself?","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2010-05-18T07:51:09Z","receivedAt":"2010-05-18T07:51:09Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Will Palmer venit, vidit, dixit 17.05.2010 20:56:\n> On Mon, 2010-05-17 at 19:59 +0200, Jan Hudec wrote:\n>> On Mon, May 17, 2010 at 17:12:22 +0200, Thomas Rast wrote:\n>>> Ævar Arnfjörð Bjarmason wrote:\n>>>> On Mon, May 17, 2010 at 14:32, Thomas Rast wrote:\n>>>>> Ævar Arnfjörð Bjarmason wrote:\n>>\n>> There are cases though, where somebody calls *porcelain* commands in their\n>> scripts and there they occasionally may need this LC_ALL=C thing. I suppose\n>> having a global option to turn off localization might be useful for such\n>> users.\n> \n> Would it be that bad to define something like GIT_PLUMBING=1 to mean \"I\n> am using this as plumbing\"? It seems that this is the way things are\n> headed with --porcelain, even if the name is backwards.\n> \n> I agree that error messages should be localised either way- if you're\n> trying to parse an error message, something's always gone wrong.\n> \n> Does anyone know how large of a non-english-speaking community git\n> currently has? Would this effort include adding localised git command\n> names or arguments?\n\nNote that \"non-english-speaking\" here really means \"requiring or badly\nwanting translated git\". There are many non-native speakers here, and\nyour following reasoning\n\n> It may also be worth mentioning that a git \"commit\", for example,\n> doesn't have anything (other than historical reasons) to do with the\n> English word \"commit\". A git commit is a git commit, and perhaps such\n> conceptual terms should best be left untranslated anyway. It would\n> certainly make it easier to answer questions in #git if people continued\n> to use the same terms everywhere. Just as a weak anecdotal argument,\n> when someone uses the term \"revision\" in #git, there's generally a lack\n> of understanding about what a \"commit\" is. \"commit\" means something very\n> specific in git, and I would hesitate to try to translate that into\n> another language as if it's just a synonym for \"revision\" or\n> \"checkpoint\", or \"transaction\", etc\n\nexplains why many non-native speakers prefer an English git. When\nconfronted with the localised German git-gui for the first time, I\nreally did not understand the menu entries at all. And my German is\npretty good ;)\n\nMichael\n"},{"id":"141857","messageId":"4BF25F7C.10303@syntevo.com","threadId":"23816","inReplyTo":"4BF246ED.3040706@drmicha.warpmail.net","subject":"Re: Has anyone looked at Gettext support for Git itself?","fromName":"Thomas Singer","fromEmail":"thomas.singer@syntevo.com","sentAt":"2010-05-18T09:35:56Z","receivedAt":"2010-05-18T09:35:56Z","isPatch":false,"sender":{"key":"thomas.singer@syntevo.com","avatar":null},"body":"> Note that \"non-english-speaking\" here really means \"requiring or badly\n> wanting translated git\". There are many non-native speakers here, and\n> your following reasoning\n> \n>> It may also be worth mentioning that a git \"commit\", for example,\n>> doesn't have anything (other than historical reasons) to do with the\n>> English word \"commit\". A git commit is a git commit, and perhaps such\n>> conceptual terms should best be left untranslated anyway. It would\n>> certainly make it easier to answer questions in #git if people continued\n>> to use the same terms everywhere. Just as a weak anecdotal argument,\n>> when someone uses the term \"revision\" in #git, there's generally a lack\n>> of understanding about what a \"commit\" is. \"commit\" means something very\n>> specific in git, and I would hesitate to try to translate that into\n>> another language as if it's just a synonym for \"revision\" or\n>> \"checkpoint\", or \"transaction\", etc\n> \n> explains why many non-native speakers prefer an English git. When\n> confronted with the localised German git-gui for the first time, I\n> really did not understand the menu entries at all. And my German is\n> pretty good ;)\n\nI can second that. If I have the choice between a German (no matter whether\ngood or bad translated) and an English version of a software, I'll choose\nthe English one.\n\nAlso, the support aspect might be important. If a German would use a\nsoftware version which reports a German error, non-German speakers will most\nlikely not be able to help him/her and even worse, (s)he will most likely\nnot be able to find a solution by searching google for this error message.\n\n-- \nThomas\n"},{"id":"141862","messageId":"1274189611.1294.10.camel@wpalmer.simply-domain","threadId":"23816","inReplyTo":"4BF25F7C.10303@syntevo.com","subject":"Re: Has anyone looked at Gettext support for Git itself?","fromName":"Will Palmer","fromEmail":"wmpalmer@gmail.com","sentAt":"2010-05-18T13:33:31Z","receivedAt":"2010-05-18T13:33:31Z","isPatch":false,"sender":{"key":"wmpalmer@gmail.com","avatar":"https://avatars.githubusercontent.com/u/357044?v=4"},"body":"On Tue, 2010-05-18 at 11:35 +0200, Thomas Singer wrote:\n> ... and even worse, (s)he will most likely\n> not be able to find a solution by searching google for this error message.\n> \n\nOther software projects make this a non-issue by reporting an \"error\ncode\" or something along those lines, along with the message. The code\nis easily indexed, so that the message can be located by support staff\nand, nowadays, google. I assume any internationalization effort would\nrequire a message code of some sort be generated internally (if only to\nlook up which internationalized message to display), so doing something\nas simple as outputting the internally-used code (even if that is just a\nhash of the English version of the message) could solve this problem.\n\nHaving error messages pasted into #git in 14 different languages could\nbe annoying, but if those are 14 people who otherwise would not be using\ngit at all, then I expect we're looking at the wrong problem, and\ninternationalisation /should/ be a priority.\n\nBut what do I know? I speak English :)\n"},{"id":"141911","messageId":"AANLkTinyQnc9VLjRmFOh5c-aeESjvlIKnQ3go4r2xoPG@mail.gmail.com","threadId":"23816","inReplyTo":"AANLkTil0iESsCpHm-X3iiMZC3sEzCqYvXjsZiIHvFz3n@mail.gmail.com","subject":"Re: Has anyone looked at Gettext support for Git itself?","fromName":"demerphq","fromEmail":"demerphq@gmail.com","sentAt":"2010-05-19T15:43:50Z","receivedAt":"2010-05-19T15:43:50Z","isPatch":false,"sender":{"key":"demerphq@gmail.com","avatar":null},"body":"On 17 May 2010 16:53, Ævar Arnfjörð Bjarmason wrote:\n> On Mon, May 17, 2010 at 14:32, Thomas Rast wrote:\n>> Ævar Arnfjörð Bjarmason wrote:\n>>> On Sun, May 16, 2010 at 16:08, Jan Hudec wrote:\n>>> > It would definitely not be fine to break *git*. You need to make sure no\n>>> > part of git itself or anything distributed with it (gitk, git gui, gitweb,\n>>> > things in contrib) is looking for any string that might be broken by\n>>> > translating.\n>>>\n>>> Of course internal breakage, i.e. git-foo parsing the output from\n>>> git-bar breaking under non-English is unacceptable. I meant that\n>>> external tools now running under some non-English locale may start\n>>> breaking if they're parsing the output and assuming English. The\n>>> remedy for that is easy though, just prefix the calls to git with\n>>> LC_ALL=C.\n>>\n>> And how exactly do you expect us to go back in history and prefix all\n>> invocations of git in all scripts with LC_ALL=C?\n>\n> I don't expect you to. I just don't think it's unreasonable that if\n> Git were to be internationalized that it behave like every other *nix\n> program. If you have a Chinese locale and rely on the output of some\n> program being in English your scripts will break if the OS\n> subsequently upgrades to a new version of the program that has been\n> translated to Chinese.\n>\n> The right way to handle that is to call programs like that with\n> LC_ALL=C.\n>\n> The alternative would be to do introduce a variable like\n> GIT_YES_REALLY_FOLLOW_LC_VARIABLES=1.\n>\n>> Porcelain such as git-status could be changed, but then there's not\n>> that much of it anyway.  IMHO a set of standard documentation in each\n>> language would be more useful.\n>\n> The output of the utilities is what people see when using Git, having\n> that in your native language is more valuable than some howto being\n> translated.\n\nIf the language is determined not by the environment, but by the\nconfiguration of the repository, then it seems to me this would be\n\"opt-in\" only, and not have any negative impact on existing\ninstallations or toolsets.\n\ncheers,\nYves\n\n\n\n-- \nperl -Mre=debug -e \"/just|another|perl|hacker/\"\n"},{"id":"142087","messageId":"20100522110158.GA30035@efreet.light.src","threadId":"23816","inReplyTo":"1274189611.1294.10.camel@wpalmer.simply-domain","subject":"Re: Has anyone looked at Gettext support for Git itself?","fromName":"Jan Hudec","fromEmail":"bulb@ucw.cz","sentAt":"2010-05-22T11:01:58Z","receivedAt":"2010-05-22T11:01:58Z","isPatch":false,"sender":{"key":"bulb@ucw.cz","avatar":null},"body":"On Tue, May 18, 2010 at 14:33:31 +0100, Will Palmer wrote:\n> On Tue, 2010-05-18 at 11:35 +0200, Thomas Singer wrote:\n> > ... and even worse, (s)he will most likely\n> > not be able to find a solution by searching google for this error message.\n> \n> Other software projects make this a non-issue by reporting an \"error\n> code\" or something along those lines, along with the message. The code\n> is easily indexed, so that the message can be located by support staff\n> and, nowadays, google. I assume any internationalization effort would\n> require a message code of some sort be generated internally (if only to\n> look up which internationalized message to display), so doing something\n> as simple as outputting the internally-used code (even if that is just a\n> hash of the English version of the message) could solve this problem.\n\nGettext does not require any kind of internal ID. It uses the english string\nas a key. It should (as already suggested) be easy to have\na reverse-translation tool on the web somewhere for deciphering session logs\nfrom users with non-english locale.\n\nNon-English-speaking users won't be able to find a solution to problem by\nsearching google most of the time anyway, though, because the prevalent\nEnglish resources won't be understandable for them. Usually, however, they\nwill have somebody on their team who does and will be able to help them out\nif they get into deep trouble.\n\n> Having error messages pasted into #git in 14 different languages could\n> be annoying, but if those are 14 people who otherwise would not be using\n> git at all, then I expect we're looking at the wrong problem, and\n> internationalisation /should/ be a priority.\n> \n> But what do I know? I speak English :)\n\nIt is important for cases when somebody wants to use git in their team, but\nsome of their colleagues don't speak English. One has to expect having to\nhelp their colleagues occasionally in such cases, but than when you propose\nusing git in some team, you have to expect having to help your colleagues\nin any case.\n\n-- \n\t\t\t\t\t\t Jan 'Bulb' Hudec \n"}]}