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

From: Jan Hudec <bulb@ucw.cz>
Date: May 16, 2010, 16:08 UTC
Message-ID: <20100516160800.GB22447@efreet.light.src>
In-Reply-To: <AANLkTikgs3d1YagU5lRCkEM9uwWe9dmifbHvIjhsk_wF@mail.gmail.com>

On Sun, May 16, 2010 at 01:12:20 +0000, Ævar Arnfjörð Bjarmason wrote:

Show 12 quoted lines

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

Show 18 quoted lines

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

Show 9 quoted lines

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