GNOME Bugzilla – Bug 301364
intltool-update incompatible with Solaris xgettext
Last modified: 2007-08-02 23:52:03 UTC
Version details: 0.31.3 Distribution/Version: 10 intltool-update requires GNU xgettext and won't work with other Unix xgettext versions that don't support GNU's long option extensions. % intltool-update --version intltool-update (intltool) 0.31.3 Written by Kenneth Christiansen, Maciej Stachowiak, and Darin Adler. Copyright (C) 2000-2003 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. % uname -rs SunOS 5.10 %intltool-update --gettext-package xscreensaver --pot WARNING: This version of gettext does not support extracting non-ASCII strings. That means you should install a version of gettext that supports non-ASCII strings (such as GNU gettext >= 0.12), or have to let non-ASCII strings untranslated. (If there is any) /usr/bin/xgettext: illegal option -- add-comments /usr/bin/xgettext: illegal option -- directory=.. /usr/bin/xgettext: illegal option -- output=xscreensaver.pot /usr/bin/xgettext: illegal option -- files-from=./POTFILES.in.temp /usr/bin/xgettext: illegal option -- keyword=_ /usr/bin/xgettext: illegal option -- keyword=N_ /usr/bin/xgettext: illegal option -- keyword=U_ Usage: xgettext [-a [-x exclude-file]] [-jns][-c comment-tag] [-d default-domain] [-m prefix] [-M suffix] [-p pathname] files ... xgettext -h ERROR: xgettext failed to generate PO template file. Please consult error message above if there is any.
What are the options to Sun's xgettext then? I'm confused as to how this could have worked earlier, as we've fixed a few things in intltool to work on Solaris already. I guess those were for GNU gettext on Solaris. Perhaps we should just require GNU gettext, and fail in a more efficient manner otherwise.
The native xgettext on Solaris doesn't support any options that start with two dashes. The Solaris 10 version of the man page can be found at: http://docs.sun.com/app/docs/doc/816-5165/6mbb0ma1k?a=view
It also doesn't support all of the options we're passing. I think it's best if we just require GNU gettext then.
Danilo? What do you think about just requiring GNU gettext for intltool given these issues?
Hum, the big thing missing here is the --keyword argument: without that, intltool pretty much makes no sense (and entire Gnome is going to fail having correct translations, since _(), N_(), Q_() are used throughout, fwiw). Yes, we should probably require GNU gettext if this manpage for xgettext is complete (but this is very strange, since the manual also mentions things like dcgettext, ngettext, ...: how are those extracted by Solaris gettext?). And there's more: Solaris xgettext doesn't seem to support all the languages GNU gettext supports, so lets just require GNU gettext until Solaris one actually gets useful.
I have GNU gettext installed in /opt/csw/bin, but to avoid conflicts with the solaris gettext all programs are installed with g prefixed to them. So /usr/bin/xgettext is found instead of /opt/csw/bin/gxgettext causing failures like: http://jhbuild.bxlug.be/builds/2006-04-27-0002/logs/system-tools-backends/#check Will this be fixed or will I just have to suck it and symlink /opt/csw/bin/gxgettext to xgettext in my PATH before /usr/bin/xgettext? (from bug 339923)
Have you tried setting the XGETTEXT variable?
You'll have to suck it up and either install it properly with the correct naming, or set the environment variables for the gettext tools appropriately.
Setting XGETTEXT doesn't work, seems to be bug 116308. The binaries come pre-packaged from blastwave.org, so I'll just stick in a symlink.
Fixed in SVN. intltool-update and intltool-merge now check that the tools they're using are GNU gettext tools, and GNU iconv.