Has anyone looked at Gettext support for Git itself?

Has anyone looked at Gettext support for Git itself?

[Ævar Arnfjörð Bjarmason]

I couldn't find anything about this in the list archives. Have there
been any discussions of adding internationalization support to Git
itself? I.e. the interface messages that the core Git utilities emit.

I tried to get started with integrating GNU Gettext, but gnuish
assumptions it makes about building make it a bit hard.

Is there perhaps another gettext implementation that would be more
suitable for Git?

I'd be interested in submitting patches to make the existing strings
translatable if someone could get the tool + build skeleton going.

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

[Jakub Narebski]

Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:

> I couldn't find anything about this in the list archives. Have there
> been any discussions of adding internationalization support to Git
> itself? I.e. the interface messages that the core Git utilities emit.
> 
> I tried to get started with integrating GNU Gettext, but gnuish
> assumptions it makes about building make it a bit hard.
> 
> Is there perhaps another gettext implementation that would be more
> suitable for Git?
> 
> I'd be interested in submitting patches to make the existing strings
> translatable if someone could get the tool + build skeleton going.

First, git uses multiple programming languages: you would need a
solution that would work for programs in C (gettext), for Perl
(Locale::Maketext or less known Data::Localize), probably for Python,
and what would probably give most problems for shell scripts.

Second, you would need to take care that changing locale wouldn't
break git.  It can be done either via setting LC_ALL=C in
git-sh-setup, or by translation only porcelain, and leaving plumbing
unchanged.

-- 
Jakub Narebski
Poland
ShadeHawk on #git

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

[Ævar Arnfjörð Bjarmason]

On Sun, May 16, 2010 at 00:03, Jakub Narebski <jnareb@gmail.com> wrote:
> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
>
>> I couldn't find anything about this in the list archives. Have there
>> been any discussions of adding internationalization support to Git
>> itself? I.e. the interface messages that the core Git utilities emit.
>>
>> I tried to get started with integrating GNU Gettext, but gnuish
>> assumptions it makes about building make it a bit hard.
>>
>> Is there perhaps another gettext implementation that would be more
>> suitable for Git?
>>
>> I'd be interested in submitting patches to make the existing strings
>> translatable if someone could get the tool + build skeleton going.
>
> First, git uses multiple programming languages: you would need a
> solution that would work for programs in C (gettext), for Perl
> (Locale::Maketext or less known Data::Localize), probably for Python,
> and what would probably give most problems for shell scripts.

All of these languages can read gettext, but you'd need some glue for
each so that they could get to the files.

It would probably make the most sense to have distinct message files
for each program, e.g.:

    /usr/share/locale/*/LC_MESSAGES/git-bisect.mo

That way they could be translated incrementally, and the programs
would load only the small subset of messages they need.

For e.g. shellscripts this can be done as (adapted from a localized
script in my /usr/bin/):

    export TEXTDOMAIN=git-bisect
    export TEXTDOMAINDIR=/usr/share/locale/
    GETTEXT=`which gettext 2> /dev/null`
    if [ -z $GETTEXT ] ; then GETTEXT='echo -n'; fi

And then just:

    - echo "We are not bisecting."
    + $GETTEXT "We are not bisecting."

> Second, you would need to take care that changing locale wouldn't
> break git.  It can be done either via setting LC_ALL=C in
> git-sh-setup, or by translation only porcelain, and leaving plumbing
> unchanged.

I think it would be fine to break it if that means that Git would
suddenly start speaking your language, you can always just set LC_ALL
if you have some scripts that break as a result of parsing the current
output in English.

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

[Dmitry Potapov]

On Sun, May 16, 2010 at 01:12:20AM +0000, Ævar Arnfjörð Bjarmason wrote:
> 
>     GETTEXT=`which gettext 2> /dev/null`
>     if [ -z $GETTEXT ] ; then GETTEXT='echo -n'; fi

'echo -n' is not portable, and it is not used in git for this reason.

Dmitry

> And then just:
> 
>     - echo "We are not bisecting."
>     + $GETTEXT "We are not bisecting."

If gettext does not add the trailing newline to the message then it is
clearly not equivalent replacement.


Dmitry

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

[Ævar Arnfjörð Bjarmason]

On Sun, May 16, 2010 at 05:36, Dmitry Potapov <dpotapov@gmail.com> wrote:
> 'echo -n' is not portable, and it is not used in git for this reason.

> If gettext does not add the trailing newline to the message then it is
> clearly not equivalent replacement.

That was just meant to be a non-working example of how we could read
gettext from .sh too. I didn't actually try to run it. Obviously a
real implementation wouldn't use 'echo -n' and wouldn't suffer from
newline issues.

I just wanted to show that regardless of whether the program is in C,
Perl or Shell a gettext implementation can degrade gracefully. That's
all.

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

[Jan Hudec]

On Sun, May 16, 2010 at 01:12:20 +0000, Ævar Arnfjörð Bjarmason wrote:
> On Sun, May 16, 2010 at 00:03, Jakub Narebski <jnareb@gmail.com> wrote:
> > Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
> >
> >> I couldn't find anything about this in the list archives. Have there
> >> been any discussions of adding internationalization support to Git
> >> itself? I.e. the interface messages that the core Git utilities emit.
> >>
> >> I tried to get started with integrating GNU Gettext, but gnuish
> >> assumptions it makes about building make it a bit hard.
> >>
> >> Is there perhaps another gettext implementation that would be more
> >> suitable for Git?

Gettext iself does not make any assumptions about building. It's only it's
manual that gives more space to setting up gettext use with autotools than
manually. But doing it manually is really not too hard.

Basically one just needs to set up scripts or makefile targets to:
 - Re-generate the translation template (.pot)
   All this takes is invoking xgettext with correct parameters on the right
   list of files. It might be necessary to invoke it with different arguments
   for sources in different languages if git needed to use non-default
   options, but I think the defaults would be ok.
 - Update the translations with new strings from the template.
   All this takes is invoking msgmerge for each .po file with the appropriate
   template.

Than makefile targets are needed to generate and install the .mc files, but
that's just trivial.

I don't think the automake support saves any work there. It saves you from
learning the tool invocations, but you have to learn automake instead.
The hardest part is makring all the translatable strings in the code and
the gnuish infrastructure just isn't much help there anyway.

> >> I'd be interested in submitting patches to make the existing strings
> >> translatable if someone could get the tool + build skeleton going.
> >
> > First, git uses multiple programming languages: you would need a
> > solution that would work for programs in C (gettext), for Perl
> > (Locale::Maketext or less known Data::Localize), probably for Python,
> > and what would probably give most problems for shell scripts.
> 
> All of these languages can read gettext, but you'd need some glue for
> each so that they could get to the files.
> 
> It would probably make the most sense to have distinct message files
> for each program, e.g.:
> 
>     /usr/share/locale/*/LC_MESSAGES/git-bisect.mo
> 
> That way they could be translated incrementally, and the programs
> would load only the small subset of messages they need.

I think it would make things more complicated and not really help anything,
since many messages may in fact be shared or come from common parts so it
would need to be loaded by many commands anyway. On the other hand the .mc
file is an external hash, so the access even to a large .mc will be quite
fast.

> > Second, you would need to take care that changing locale wouldn't
> > break git.  It can be done either via setting LC_ALL=C in
> > git-sh-setup, or by translation only porcelain, and leaving plumbing
> > unchanged.
> 
> I think it would be fine to break it if that means that Git would
> suddenly start speaking your language, you can always just set LC_ALL
> if you have some scripts that break as a result of parsing the current
> output in English.

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.

-- 
						 Jan 'Bulb' Hudec <bulb@ucw.cz>

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

[Ævar Arnfjörð Bjarmason]

On Sun, May 16, 2010 at 16:08, Jan Hudec <bulb@ucw.cz> wrote:
> On Sun, May 16, 2010 at 01:12:20 +0000, Ævar Arnfjörð Bjarmason wrote:
>> On Sun, May 16, 2010 at 00:03, Jakub Narebski <jnareb@gmail.com> wrote:
>> > Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
>> >
>> >> I couldn't find anything about this in the list archives. Have there
>> >> been any discussions of adding internationalization support to Git
>> >> itself? I.e. the interface messages that the core Git utilities emit.
>> >>
>> >> I tried to get started with integrating GNU Gettext, but gnuish
>> >> assumptions it makes about building make it a bit hard.
>> >>
>> >> Is there perhaps another gettext implementation that would be more
>> >> suitable for Git?
>
> Gettext iself does not make any assumptions about building. It's only it's
> manual that gives more space to setting up gettext use with autotools than
> manually. But doing it manually is really not too hard.
>
> Basically one just needs to set up scripts or makefile targets to:
>  - Re-generate the translation template (.pot)
>   All this takes is invoking xgettext with correct parameters on the right
>   list of files. It might be necessary to invoke it with different arguments
>   for sources in different languages if git needed to use non-default
>   options, but I think the defaults would be ok.
>  - Update the translations with new strings from the template.
>   All this takes is invoking msgmerge for each .po file with the appropriate
>   template.
>
> Than makefile targets are needed to generate and install the .mc files, but
> that's just trivial.
>
> I don't think the automake support saves any work there. It saves you from
> learning the tool invocations, but you have to learn automake instead.
> The hardest part is makring all the translatable strings in the code and
> the gnuish infrastructure just isn't much help there anyway.

Right, someone has to come up with all the makefile / build magic one
way or another.

I'm just really not familiar with that side of things, which was why I
asked if someone had tried it already.

Is someone on-list familiar with a non-GNU program that does all its
gettext support manually, i.e. not with the gnu autotools?

I'm not, examples would help :)

>> All of these languages can read gettext, but you'd need some glue for
>> each so that they could get to the files.
>>
>> It would probably make the most sense to have distinct message files
>> for each program, e.g.:
>>
>>     /usr/share/locale/*/LC_MESSAGES/git-bisect.mo
>>
>> That way they could be translated incrementally, and the programs
>> would load only the small subset of messages they need.
>
> I think it would make things more complicated and not really help anything,
> since many messages may in fact be shared or come from common parts so it
> would need to be loaded by many commands anyway. On the other hand the .mc
> file is an external hash, so the access even to a large .mc will be quite
> fast.

Right, squashing them all into one .mo file may be the best thing,
particularly, as you mention, for the case of displaying messages from
more than one tool.

That might mean message collisions, but that can be solved these days
with gettext's msgctxt.

> 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.

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

[Thomas Rast]

Æ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?

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.

-- 
Thomas Rast
trast@{inf,student}.ethz.ch

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

[Ævar Arnfjörð Bjarmason]

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.

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

[Thomas Rast]

Ævar Arnfjörð Bjarmason wrote:
> On Mon, May 17, 2010 at 14:32, Thomas Rast <trast@student.ethz.ch> wrote:
> > Ævar Arnfjörð Bjarmason wrote:
> >>
> >> 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.

I've bumped against these hysterical raisins in the past too, so you
have my sympathy.  But git's API is the set of its plumbing commands,
I/O, arguments and all.

We do not give a similar promise for porcelain commands, which
includes most of the frequently used commands that also have a bunch
of translatable output like status, clone, fetch, branch, etc.  You
could start by translating the helpful comments in status, commit and
rebase -i.

However, I'm just trying to point out that your suggested solution

> The right way to handle that is to call programs like that with
> LC_ALL=C.

will never fly, and that git will, e.g., never be able to consistently
call a commit a "Version" [de] because for-each-ref must forever fill
the %(type) field with "commit".

-- 
Thomas Rast
trast@{inf,student}.ethz.ch

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

[Jan Hudec]

On Mon, May 17, 2010 at 17:12:22 +0200, Thomas Rast wrote:
> Ævar Arnfjörð Bjarmason wrote:
> > On Mon, May 17, 2010 at 14:32, Thomas Rast <trast@student.ethz.ch> wrote:
> > > Ævar Arnfjörð Bjarmason wrote:
> > >>
> > >> 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.
> 
> I've bumped against these hysterical raisins in the past too, so you
> have my sympathy.  But git's API is the set of its plumbing commands,
> I/O, arguments and all.

The plumbing commands' output, obviously, may not become locale dependent
since it is indeed part of the API. It may sometimes print localized error
messages though where one can't really do anything besides relying them to
the user anyway.

There are cases though, where somebody calls *porcelain* commands in their
scripts and there they occasionally may need this LC_ALL=C thing. I suppose
having a global option to turn off localization might be useful for such
users.

> We do not give a similar promise for porcelain commands, which
> includes most of the frequently used commands that also have a bunch
> of translatable output like status, clone, fetch, branch, etc.  You
> could start by translating the helpful comments in status, commit and
> rebase -i.
> 
> However, I'm just trying to point out that your suggested solution
> 
> > The right way to handle that is to call programs like that with
> > LC_ALL=C.
> 
> will never fly, and that git will, e.g., never be able to consistently
> call a commit a "Version" [de] because for-each-ref must forever fill
> the %(type) field with "commit".

I would personally consider it too obvious that "programs like that" means
porcelain to mention it.

Most error messages may be translated even in plumbing though, just like they
are translated in standard unix commands.

-- 
						 Jan 'Bulb' Hudec <bulb@ucw.cz>

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

[Will Palmer]

On Mon, 2010-05-17 at 19:59 +0200, Jan Hudec wrote:
> On Mon, May 17, 2010 at 17:12:22 +0200, Thomas Rast wrote:
> > Ævar Arnfjörð Bjarmason wrote:
> > > On Mon, May 17, 2010 at 14:32, Thomas Rast <trast@student.ethz.ch> wrote:
> > > > Ævar Arnfjörð Bjarmason wrote:
> 
> There are cases though, where somebody calls *porcelain* commands in their
> scripts and there they occasionally may need this LC_ALL=C thing. I suppose
> having a global option to turn off localization might be useful for such
> users.

Would it be that bad to define something like GIT_PLUMBING=1 to mean "I
am using this as plumbing"? It seems that this is the way things are
headed with --porcelain, even if the name is backwards.

I agree that error messages should be localised either way- if you're
trying to parse an error message, something's always gone wrong.

Does anyone know how large of a non-english-speaking community git
currently has? Would this effort include adding localised git command
names or arguments?

It may also be worth mentioning that a git "commit", for example,
doesn't have anything (other than historical reasons) to do with the
English word "commit". A git commit is a git commit, and perhaps such
conceptual terms should best be left untranslated anyway. It would
certainly make it easier to answer questions in #git if people continued
to use the same terms everywhere. Just as a weak anecdotal argument,
when someone uses the term "revision" in #git, there's generally a lack
of understanding about what a "commit" is. "commit" means something very
specific in git, and I would hesitate to try to translate that into
another language as if it's just a synonym for "revision" or
"checkpoint", or "transaction", etc


-- 
-- Will

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

[Michael J Gruber]

Will Palmer venit, vidit, dixit 17.05.2010 20:56:
> On Mon, 2010-05-17 at 19:59 +0200, Jan Hudec wrote:
>> On Mon, May 17, 2010 at 17:12:22 +0200, Thomas Rast wrote:
>>> Ævar Arnfjörð Bjarmason wrote:
>>>> On Mon, May 17, 2010 at 14:32, Thomas Rast <trast@student.ethz.ch> wrote:
>>>>> Ævar Arnfjörð Bjarmason wrote:
>>
>> There are cases though, where somebody calls *porcelain* commands in their
>> scripts and there they occasionally may need this LC_ALL=C thing. I suppose
>> having a global option to turn off localization might be useful for such
>> users.
> 
> Would it be that bad to define something like GIT_PLUMBING=1 to mean "I
> am using this as plumbing"? It seems that this is the way things are
> headed with --porcelain, even if the name is backwards.
> 
> I agree that error messages should be localised either way- if you're
> trying to parse an error message, something's always gone wrong.
> 
> Does anyone know how large of a non-english-speaking community git
> currently has? Would this effort include adding localised git command
> names or arguments?

Note that "non-english-speaking" here really means "requiring or badly
wanting translated git". There are many non-native speakers here, and
your following reasoning

> It may also be worth mentioning that a git "commit", for example,
> doesn't have anything (other than historical reasons) to do with the
> English word "commit". A git commit is a git commit, and perhaps such
> conceptual terms should best be left untranslated anyway. It would
> certainly make it easier to answer questions in #git if people continued
> to use the same terms everywhere. Just as a weak anecdotal argument,
> when someone uses the term "revision" in #git, there's generally a lack
> of understanding about what a "commit" is. "commit" means something very
> specific in git, and I would hesitate to try to translate that into
> another language as if it's just a synonym for "revision" or
> "checkpoint", or "transaction", etc

explains why many non-native speakers prefer an English git. When
confronted with the localised German git-gui for the first time, I
really did not understand the menu entries at all. And my German is
pretty good ;)

Michael

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

[Thomas Singer]

> Note that "non-english-speaking" here really means "requiring or badly
> wanting translated git". There are many non-native speakers here, and
> your following reasoning
> 
>> It may also be worth mentioning that a git "commit", for example,
>> doesn't have anything (other than historical reasons) to do with the
>> English word "commit". A git commit is a git commit, and perhaps such
>> conceptual terms should best be left untranslated anyway. It would
>> certainly make it easier to answer questions in #git if people continued
>> to use the same terms everywhere. Just as a weak anecdotal argument,
>> when someone uses the term "revision" in #git, there's generally a lack
>> of understanding about what a "commit" is. "commit" means something very
>> specific in git, and I would hesitate to try to translate that into
>> another language as if it's just a synonym for "revision" or
>> "checkpoint", or "transaction", etc
> 
> explains why many non-native speakers prefer an English git. When
> confronted with the localised German git-gui for the first time, I
> really did not understand the menu entries at all. And my German is
> pretty good ;)

I can second that. If I have the choice between a German (no matter whether
good or bad translated) and an English version of a software, I'll choose
the English one.

Also, the support aspect might be important. If a German would use a
software version which reports a German error, non-German speakers will most
likely not be able to help him/her and even worse, (s)he will most likely
not be able to find a solution by searching google for this error message.

-- 
Thomas

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

[Will Palmer]

On Tue, 2010-05-18 at 11:35 +0200, Thomas Singer wrote:
> ... and even worse, (s)he will most likely
> not be able to find a solution by searching google for this error message.
> 

Other software projects make this a non-issue by reporting an "error
code" or something along those lines, along with the message. The code
is easily indexed, so that the message can be located by support staff
and, nowadays, google. I assume any internationalization effort would
require a message code of some sort be generated internally (if only to
look up which internationalized message to display), so doing something
as simple as outputting the internally-used code (even if that is just a
hash of the English version of the message) could solve this problem.

Having error messages pasted into #git in 14 different languages could
be annoying, but if those are 14 people who otherwise would not be using
git at all, then I expect we're looking at the wrong problem, and
internationalisation /should/ be a priority.

But what do I know? I speak English :)

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

[Jan Hudec]

On Tue, May 18, 2010 at 14:33:31 +0100, Will Palmer wrote:
> On Tue, 2010-05-18 at 11:35 +0200, Thomas Singer wrote:
> > ... and even worse, (s)he will most likely
> > not be able to find a solution by searching google for this error message.
> 
> Other software projects make this a non-issue by reporting an "error
> code" or something along those lines, along with the message. The code
> is easily indexed, so that the message can be located by support staff
> and, nowadays, google. I assume any internationalization effort would
> require a message code of some sort be generated internally (if only to
> look up which internationalized message to display), so doing something
> as simple as outputting the internally-used code (even if that is just a
> hash of the English version of the message) could solve this problem.

Gettext does not require any kind of internal ID. It uses the english string
as a key. It should (as already suggested) be easy to have
a reverse-translation tool on the web somewhere for deciphering session logs
from users with non-english locale.

Non-English-speaking users won't be able to find a solution to problem by
searching google most of the time anyway, though, because the prevalent
English resources won't be understandable for them. Usually, however, they
will have somebody on their team who does and will be able to help them out
if they get into deep trouble.

> Having error messages pasted into #git in 14 different languages could
> be annoying, but if those are 14 people who otherwise would not be using
> git at all, then I expect we're looking at the wrong problem, and
> internationalisation /should/ be a priority.
> 
> But what do I know? I speak English :)

It is important for cases when somebody wants to use git in their team, but
some of their colleagues don't speak English. One has to expect having to
help their colleagues occasionally in such cases, but than when you propose
using git in some team, you have to expect having to help your colleagues
in any case.

-- 
						 Jan 'Bulb' Hudec <bulb@ucw.cz>

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

[demerphq]

On 17 May 2010 16:53, Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:
> 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.

If the language is determined not by the environment, but by the
configuration of the repository, then it seems to me this would be
"opt-in" only, and not have any negative impact on existing
installations or toolsets.

cheers,
Yves



-- 
perl -Mre=debug -e "/just|another|perl|hacker/"

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

[Thomas Singer]

> Have there
> been any discussions of adding internationalization support to Git
> itself? I.e. the interface messages that the core Git utilities emit.

>From me perspective of a developer who is invoking the Git executable from
our application: ensure that there is a way to tell Git to output text in a
fixed language, so other applications (e.g. ours) can parse the output.(1)

-- 
Best regards,
Thomas Singer
=============
syntevo GmbH
http://www.syntevo.com
http://blog.syntevo.com

(1) Yes, I know that this is not 100% safe, because messages can be
different in different Git version.

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

[Marc Weber]

Excerpts from Ævar Arnfjörð Bjarmason's message of Sun May 16 00:10:09 +0200 2010:
> I couldn't find anything about this in the list archives. Have there
> been any discussions of adding internationalization support to Git
> itself? I.e. the interface messages that the core Git utilities emit.
> 
> I tried to get started with integrating GNU Gettext, but gnuish
> assumptions it makes about building make it a bit hard.
> 
> Is there perhaps another gettext implementation that would be more
> suitable for Git?
> 
> I'd be interested in submitting patches to make the existing strings
> translatable if someone could get the tool + build skeleton going.

It may sound silly and stupid: My coworker has had much trouble because
he doesn't know English at all.
You could help those people very much by creating a git-translator.org
page where you can copy paste failures which are translated only.

In the end you must have seen any failure multiple times to cope with
it - no matter which language this message was written in. However
having an understandable text may help.

Marc Weber

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

[Peter Krefting]

Ævar Arnfjörð Bjarmason:

> I couldn't find anything about this in the list archives. Have there been 
> any discussions of adding internationalization support to Git itself? I.e. 
> the interface messages that the core Git utilities emit.

So far, it seems that most people using it has been the kind of people who 
thing computers should speak only English.

I'd be happy to help out with a gettextization of Git, including doing a 
Swedish translation. I've already translated gitk and git-gui to Swedish 
(and I use the translations in my day-to-day work), and would love to have 
the rest of the command set speak the same language as me as well.

-- 
\\// Peter - http://www.softwolves.pp.se/