GNOME Bugzilla – Bug 342500
intltool po/LINGUAS approach doesn't check for LINGUAS env var
Last modified: 2007-01-08 21:18:36 UTC
I am passing the LINGUAS environment variable to configure through gentoo portage as to have the package only install the listed LINGUAS. This technique worked fine with the ALL_LINGUAS approach, and only my listed translations got installed, but the po/LINGUAS approach seems to completely ignore my LINGUAS env var - I'm getting ALL translations compiled/installed since whenever a package converts over to the po/LINGUAS approach.
Note that it wasn't actually working completely before. It worked only for installing MO files: all the .desktop, .xml, .schemas and similar "merged" stuff still contained all the translations. The complete solution is to go on with the language-pack support implementation.
Ping. LINGUAS env var not having an affect is a regression from GNOME-2.14... Also confirming the bug based on developer comment.
Just committed a fix for this in CVS. Using LINGUAS now works again with make install. This restores the behavior to the <= 0.34 behavior, and all languages are still merged into the desktop/xml/etc files that need it.
I don't think it works as before 0.35.0: make[2]: Entering directory `/var/tmp/portage/x11-libs/gtksourceview-1.8.2/work/gtksourceview-1.8.2/po' file=`echo et | sed 's,.*/,,'`.gmo \ && rm -f $file && /usr/bin/gmsgfmt -o $file et.po make[2]: *** No rule to make target `et_EE.gmo', needed by `all-yes'. Stop. make[2]: *** Waiting for unfinished jobs.... make[2]: Leaving directory `/var/tmp/portage/x11-libs/gtksourceview-1.8.2/work/gtksourceview-1.8.2/po' Effectively all tarballs generated with 0.35.1 intltoolize are now unusable with LINGUAS env variable that defines languages that the tarball doesn't ship. Setting it for each package is not an option really - I have LINGUAS="et et_EE" in my environment to cope with packages that have the translation as et_EE for some reason (some non-GNOME stuff do). Others might have LINGUAS for languages that don't have translations for every package, and it seems they will fail the build then... If the translation for something listed in LINGUAS doesn't exist, it should just ignore it and honor the ones that do - so I would get et.po handled still, while the et_EE in my LINGUAS is simply ignored if et_EE.po doesn't exist (isn't listed in po/LINGUAS or configure.in).
Actually, this change was made in CVS after the 0.35.1 release. I've just committed a fix for this issue as well. I did forget to test that case. Thanks. Also, the latest commit could use testing against a module that still uses ALL_LINGUAS in configure.{in,ac} instead of the po/LINGUAS file.
There is still a small bug in the committed fix, it assumes that the language is available if an entry in the LINGUAS file _starts_ with an entry in the LINGUAS variable, e.g. if "en" is in the LINGUAS environment variable and "en_GB" (but not "en") is in the LINGUAS file, intltool tries to build "en" which results in a broken build. The problem is just a missing $ at the end of the grep pattern to make sure that the whole line matches.
Created attachment 78979 [details] [review] Proposed fix Ok to commit?
Patch looks good, please commit.
Committed to trunk.
*** Bug 384396 has been marked as a duplicate of this bug. ***