GNOME Bugzilla – Bug 70371
intltool-update hack to figure out package name fails for gconf
Last modified: 2004-12-22 21:47:04 UTC
intltool-update has a problem with the HEAD branch in gconf: ole:~/cvs/gconf/po$ intltool-update da -X Building the GConf$MAJOR_VERSION.pot... Wrote GConf$MAJOR_VERSION.pot Removing generated header (.h) files...done Merging da.po with GConf$MAJOR_VERSION.pot...error while opening "GConf$MAJOR_VERSION.pot" for reading: No such file or directory 359 translated messages. The problem is that configure.in for gconf contains dnl used to rename everything and support simultaneous installs. dnl not incremented for bugfix or unstable releases. MAJOR_VERSION=2 AC_SUBST(MAJOR_VERSION) GETTEXT_PACKAGE=GConf$MAJOR_VERSION so that intltool-update is working on a filename with a metacharacter. After execution a file named 'GConf$MAJOR_VERSION.po' (note the missing 't') is produced but da.po isn't updated. I've looked in the script and I think the culprit may be on line 394 where it says: my $gettext_test ="test \! -f $PACKAGE\.po \|\| \( rm -f \.\/$PACKAGE\.pot " ."&& mv $PACKAGE\.po \.\/$PACKAGE\.pot \)"; BTW ole:~/cvs/gconf/po$ perl --version This is perl, v5.6.1 built for i386-linux [...] and I've tried with the version of intltool-update Kenneth posted on gnome-i18n which gave the same response.
Suggestions on how to do the intltool-update hackery better, Havoc?
I don't understand this issue very well, but it appears that gconf expects GETTEXT_PACKAGE to be evaluated in a Makefile. I don't know where intltool gets this variable or in what context it evaluates it. I could always add a workaround to gconf to make GETTEXT_PACKAGE a constant expression.
The intltool-update tool, which is run as part of "make dist" and also by translators, needs to know the "gettext name" of a package. The tool tries to figure out the package name by reading the configure.in file; I guess it doesn't use a more-reliable method because translators want it to work even in packages that haven't been autogen'd yet. That's the part I am not sure of. Unfortunately, I am not an expert on exactly how this tool is used by translators. We could enhance the hack "just enough" so that we could handle this case, find some more reliable way to get the package name, or just dumb down the gconf configure.in. I'm not sure which we should do.
As a translator of a rather big bunch of Gnome translations I can assure you that most translators probably never run configure to get the makefiles, but instead relies on intltool-update or the small scripts that we used to have in the po subdirectories. :-) I think the problem *may* be that the name is passed to the shell for a short moment - the Perl part of intltool-update seems to do fine with name. Running perl -e '$name = "micro\$oft"; system("touch", "$name")' does produce a file named "micro$oft". So I think rewriting the two shell lines into Perl instead might fix problem. Unfortunately, my knowledge of Perl is close to zero...
Ultimately I'd like to see a reliable solution - perhaps require an intltool-specific line to appear in configure.in - but in the interests of expediency I can dumb down gconf for now if required. just let me know.
Well, I finally sat down with the Perl man pages (man, it is difficult to find anything in them) and worked out the Perl equivalent of the shell code: if (-e "$PACKAGE.po") { system ("rm", "-f", "$PACKAGE.pot"); move ("$PACKAGE.po", "$PACKAGE.pot"); } # system ($gettext_test); Inserting this after the call to xgettext fixes the problem. One still gets a weird name for the .pot file but everything works as expected, and the .po file is updated. So modifying GConf shouldn't be necessary. I do think the above code could use a few "|| die "aargh"", though - continuing as if nothing is wrong isn't terribly nice (that behaviour once fooled me for weeks in another connection).
Created attachment 6831 [details] [review] Patch against intltool-update 0.15 to fix the bug
Why don't you just add a command-line option to specify the package name to intltool-update? Also the current strategy of determining the package name only works from inside a directory called po. Why is that? It means that intltool-update will not be useable for other po directories. The GIMP for example has a couple of them and I'd really like to be able to get rid of the update.sh scripts in those directories.
Adding an option to specify the package name sounds fine. The reason that option wasn't there before was that the original author thought of intltool-update as a convenience script for translators; something they run many times a day on many different packages. So it tries to do everything automatically. The intent is to replace the old "update.sh" scripts -- so whatever it takes to make this work in directories other than "po" would be fine with me.
Applied the patch (or something like it), but I still don't see how this fixes the bug. Making it handle the strange package name properly doesn't seem like the real fix to me.
I found an older bug report about the same thing. *** This bug has been marked as a duplicate of 66155 ***