GNOME Bugzilla – Bug 308769
glib-gettextize: No support for po/Makevars or XGETTEXT_OPTIONS
Last modified: 2017-10-06 10:54:49 UTC
Version details: 2.6.4 Distribution/Version: Debian sarge GNU gettext allows options for gettext to be put in $(XGETTEXT_OPTIONS) in po/Makevars, which is merged into the generated Makefile.in (from Makefile.in.in). glib-gettextize supports neither po/Makevars nor XGETTEXT_OPTIONS. It's not terribly clear why glib has diverged so much from the original gettext implementation, but the differences mean that xgettext can't parse UTF-8 C source when using glib-gettext, whereas with GNU gettext XGETTEXT_OPTIONS = --from-code=UTF-8 in po/Makevars would be sufficient. This completely breaks "make dist", since xgettext chokes on UTF-8 strings in the source. It's fixable by manually editing the Makefile.in.in, but obviously this gets overwritten by glib-gettextize, so needs fixing there. This bug is present in both 2.6 and the current mainline. I can look at adding it if you like, but would appreciate some pointers to the differences with GNU gettext if I need to hack on the m4 macros (necessary for po/Makevars). I can add an argument to AM_GLIB_GNU_GETTEXT, or implement it in the same way as GNU gettext. Which do you prefer? Regards, Roger
I checked the ChangeLogs, but it's not clear which version of GNU gettext the Makefile was forked from. I don't know the history or reasons behind glib-gettextize, but it might be simplest to simply import the current GNU gettext files. It does quite a bit of new stuff. Now gettext has autopoint, is glib-gettextize really needed? Could glib-gettexize simply wrap autopoint? (I know that gettextize was evil from my own experience, and had serious complaints about that with the author.). Regards, Roger
Maybe we just want to drop glib-gettexttize. Any reason to keep it around ?
I can't see that glib-gettextize offers anything that autopoint does not. If anything, glib-gettextize is several years out of date, and now autopoint has replaced the original gettextize (it's functionally equivalent to glib-gettextize), there's no reason not to use it.
If you would like, I can write wrappers for AM_GLIB_GNU_GETTEXT and glib-gettextize to ease the transition.
See "Note" at http://www.gnome.org/~malcolm/i18n/autogen-changes.html for why glib-gettextize is needed, that is still true. But glib's Makefile.in.in could indeed use some stuff from gettext (glib's one breaks with AC_CONFIG_AUX_DIR, so I found this bug), if someone can understand where it's actually coming from, looks like glib's Makefile.in.in is a closer relative of intltool's one.
It's not still needed; autopoint does the job. It's been available since gettext 0.11.3 (July *2002*, *five* *years* ago), so since we are (I am) now using gettext 0.16.1, it's high time to up the minimum version required! There's no point (not) maintaining (inferior) tools just for the sake of it. The upstream tools are now far superior, and actually maintained, unlike the glib ones! Why is the minimum requirement so ancient and obsolete? This was true two years ago when I filed the report, and it's even more so today. (This trivial bug has no reply in nearly *two years*! Had there been an answer to my question, I would have written the wrappers in a few minutes two years back.) As it is, glib-gettextise has bitrotted for many many years and needs scrapping in favour of the modern tools that actually work properly. As I stated in an earlier post, this could be easily transitioned using simple wrappers to replace the current cruft. And then in new code, the unneeded wrappers can simply be dropped if desired. Regards, Roger
Looks like it's really a philosophical issue; last time when I tried autopoint, it didn't do the job, it instead wanted me to hardcode my current gettext version into the project, and it copied lot of junk into the project. glib-gettextize could indeed be made a wrapper around gettext instead of maintaining its own files, but the main point is what exactly it does, and autopoint/gettextize do not do exactly that. I.e. it maintains old files, which are not working well - a bug; it exists - a nice feature for glib users.
Note that the version autopoint requires (AM_GNU_GETTEXT_VERSION) allows any version back to 0.10.35. You just specify the oldest version you want to support. It doesn't need to be the latest-and-greatest version you have installed on your own machine. This means that all developers use the same version of the gettext files, which is advantageous for consistency and reproducibility. This is also an advantage of using glib-gettextize, but it fails on the count of actually being maintained. It does copy some "junk" files such as en@quot etc., but you don't need to distribute them. It would be nice if it were configurable (file a bug?), but the advantages of using the current tools far outweigh the need to remove a few files from the po/ directory. Personally, I just leave them in; a user might find them useful. Due to glib forking, rather than fixing, the gettext tools, none of the new features are available to glib users; for me UTF-8-encoded source was a prerequisite. And because glib-gettextize isn't being updated or a wrapper, they still aren't available. Regards, Roger
glib-gettext has definitely been dropped in favour of upstream gettext now.