On Sun, May 16, 2010 at 16:08, Jan Hudec <bulb@xxxxxx> 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@xxxxxxxxx> wrote: >> > Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> 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. -- 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