GNOME Bugzilla – Bug 89339
po/Makefile.in outdated
Last modified: 2011-02-18 15:47:54 UTC
The version of po/Makefile.in is out of date with what is shipped with gettext 0.10.40 (and maybe even 0.10.38 and above). gettext now places the translations in $(datadir)/locale, not $(prefix)/share/locale. Patch available at: ftp://ftp.thewrittenword.com/outgoing/pub/glib-2.0.4-1.patch
Created attachment 10114 [details] [review] Patch as attachment
BTW, GTK+ needs the same fix.
Move bugs from earlier 2.0.x milestones to 2.0.8.
Fixed in HEAD and stable of glib and gtk+. Tue Dec 3 20:40:56 2002 Owen Taylor <otaylor@redhat.com> * Makefile.in.in: Use datadir, not $(prefix)/share. (#89339)
Turns out that this may have been a overhasty change -- the traditional scheme is: - Native format .mo files called .mo before installation, installed in libdir. - GNU format .mo files called .gmo before installation, installed in datadir. (The value of @DATADIR@ depends on what libintl is being used) I don't know if the native format gettext files are actually architecture dependent or the libdir installation is conventional, but it seems a little dangerous to start mixing the two. Something like: @POFILE_IN_DATADIR_TRUE@localedir = $(datadir)/locale @POFILE_IN_DATADIR_FALSE@localedir = $(libdir)/locale Should do the trick when combined with the appropriate glib-gettext.m4 changes.
Found another problem with the patch; GLib and GTK+ (and probably most other modules using AM_GLIB_GNU_GETTEXT) have things like: # AM_GLIB_GNU_GETTEXT above substs $DATADIRNAME # this is the directory where the *.{mo,gmo} files are installed gtklocaledir='${prefix}/${DATADIRNAME}/locale' AC_SUBST(gtklocaledir) On the other hand, nautilus has: -DGNOMELOCALEDIR=\""$(datadir)/locale"\" \ So currently if AM_GLIB_GNU_GETTEXT finds something other than GNU libintl, it will just not get any translations at all. (Since it installs for non-GNU libintl, into $(libdir)/locale...) Can I ask the original reporter what the actual problem they were trying to solve was so that I can get a better feel for the parameters of the problem? Wanting a datadir of something other than $(prefix)/share is pretty unusual...
Feel free to ignore the patch. We'll keep our modification local. We maintain freeware for various commercial organizations that don't want to do it themselves. We have a customer with a funky datadir. Because the stuff in datadir is meant to be platform-independent (for the most part), they share datadir among all of their platforms (HP-UX, Solaris, etc.). We configure their datadir as '$(prefix)/share/[some name]'.
But what is GLib installing in datadir that _isn't_ platform independent? That would be a bug. Or is this a question of: - We don't trust software to actually use datadir properly, so we make datadir something other than datadir?
The problem isn't that glib is installing something into datadir that is platform dependent. We just don't like glib using $(prefix)/share for intl files rather than $(datadir). When you upgrade to gettext 0.10.38+, then po/Makefile.in.in will satisfy us. We'll wait.
Actually, glib's po/Makefile.in.in is maintained independently of gettext; we needed a feature or two that gettext's one didn't have and didn't like some of the things that the standard gettextize did (like edit po/ChangeLog) I've tweaked things a bit now, and things should be fine for your usage, I think. What I have now is: datadir = @datadir@ libdir = @libdir@ localedir = $(libdir)/locale gnulocaledir = $(datadir)/locale gettextsrcdir = $(datadir)/glib-2.0/gettext/po
Looks good. Please close. Thanks.