After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 169274 - Gimp uses two different install locations for translations
Gimp uses two different install locations for translations
Status: VERIFIED FIXED
Product: GIMP
Classification: Other
Component: Internationalisation
2.2.x
Other All
: Normal minor
: 2.2
Assigned To: GIMP Bugs
GIMP Bugs
Depends on:
Blocks:
 
 
Reported: 2005-03-05 08:02 UTC by Ambrose LI
Modified: 2009-08-15 18:40 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Ambrose LI 2005-03-05 08:02:21 UTC
Please describe the problem:
Gimp behaves very strangely if it has been configured with a datadir that does
not end with a "share" component.

For example, configure --prefix=/software/gimp --datadir=/software/gimp/data
causes this (let's assume we are using the language "foo" and that "foo" has a
reasonably complete translation):

- Translations for gimp proper installed in
/software/gimp/data/locale/foo/LC_MESSAGES/

- Translations for other parts (viz., libgimp, script-fu, and the plug-in's) in
/software/gimp/share/locale/foo/LC_MESSAGES/

- At runtime, under a "foo" locale, gimp will only look into
/software/gimp/share/locale/foo/LC_MESSAGES/ but not
/software/gimp/data/locale/foo/LC_MESSAGES/

- As a result almost everything is in English even though the translation is
reasonably complete

The behaviour can be worked around by setting GIMP2_LOCALEDIR

Steps to reproduce:
1. configure gimp with a datadir that does not end with "/share"
2. install gimp
3. run gimp in a locale with a known-reasonably-complete translation


Actual results:
Gimp appears in English

Expected results:
Gimp should appear in the translated language

Does this happen every time?
Yes

Other information:
I think this is mostly a consistency problem. 

If gimp should install things to $PREFIX/share/locale (which I think it should
not, because that means the locale directory would not be configurable at
compile time) it should install everything to $PREFIX/share/locale.

Similarly, if it should install things to $DATADIR/locale (which I think is the
more correct behaviour) it should install everything to $DATADIR/locale.

It should not install some things to $PREFIX/share/locale and other things to
$DATADIR/locale and then get confused by its own inconsistency at runtime.
Comment 1 Sven Neumann 2005-03-05 11:58:38 UTC
Your analysis of the problem is incorrect. GIMP uses
'${prefix}/${DATADIRNAME}/locale' for localedir. Unfortunately, it seems that
the behaviour of gettextize changed and it does install into $(datadir)/locale
now. We better adapt to that change.
Comment 2 Sven Neumann 2005-03-05 12:09:10 UTC
Updating the Makefiles in the po-* subdirs will fix this problem.
Comment 3 Sven Neumann 2005-03-05 16:46:45 UTC
Fixed in both branches:

2005-03-05  Sven Neumann  <sven@gimp.org>

	Fix for bug #169274:

	* configure.in: updated definition of localedir.

	* po/Makefile.in.in: updated.

	* po-libgimp/Makefile.in.in
	* po-plug-ins/Makefile.in.in
	* po-script-fu/Makefile.in.in: synchronized with po/Makefile.in.in.
Comment 4 Tor Lillqvist 2005-04-03 23:21:53 UTC
Hmm, on Win32 the message catalogs get installed in $prefix/lib/locale, not
share/locale. (Somehow this is related to whether the message catalogs are
called *.gmo or *.mo. They are installed as *.mo on Win32.) The unconditional
assignment of localedir in configure.in breaks i18n on Win32 then.

(Could somebody explain the logic behind using .gmo vs. .mo, and share/locale
vs. lib/locale?)
Comment 5 Sven Neumann 2005-04-03 23:30:23 UTC
Tor, do we need to reopen this report and improve the fix for 2.2.5 ?
Comment 6 Tor Lillqvist 2005-04-04 07:05:00 UTC
I think so, yes. Unfortunately I don't understand very well how the
po*/Makefile(.in(.in)) and (glib-)gettextize mess works and why this needs to be
so complex. I just know, that at least for me, the Makefile in the po*
directories creates *.mo files, and that the "make install" because of this uses
lib/locale, not share/locale. So a trivial fix would be to do somethig like:

if test x"$os_win32" = xyes -a "$CATOBJEXT" = ".mo"; then
	localedir="$libdir/locale"
fi

in configure.in, but this is just fixing the symptom, not the cause... 
Comment 7 Sven Neumann 2005-04-04 22:32:31 UTC
I don't think we need to special-case win32 here. The test for $CATOBJEXT seems
to be right thing to do. po/Makefile.in.in selects localedir based on this setting.
Comment 8 Sven Neumann 2005-04-04 22:53:35 UTC
I've added a check that looks at DATADIRNAME (to both branches):

2005-04-05  Sven Neumann  <sven@gimp.org>

	* configure.in: select localedir according to the format of the
	gettext message catalogs. Closes bug #169274 again.
Comment 9 Sven Neumann 2005-04-04 23:07:15 UTC
Related change, but only applied to HEAD:

2005-04-05  Sven Neumann  <sven@gimp.org>

	* configure.in: renamed localedir to gimplocaledir.

	* libgimpbase/Makefile.am (AM_CPPFLAGS)
	* tools/Makefile.am (AM_CPPFLAGS): changed accordingly.

	* gimp.pc.in: added gimplocaledir to the pkg-config file to give
	plug-ins a chance to get gimp_locale_directory() at compile time.