Comment 35 for bug 992047

> Here's a patch based on the advice at the above link.
> Would you mind seeing if this helps?

It doesn't address the issue at all as far as I can tell (and possibly breaks i18n-related code elsewhere in Inkscape - at least it likely would require additional changes e.g. for (python-based) extensions in 'share/extensions/inkex.py', and possibly in the packaging scripts too).

1) The problem:
On some platforms, the locale files get installed into the wrong path (based on "wrong" DATADIRNAME from intltool macros (?))

2) revision r12159 (without your patch):
| Chillida:mp-quartz-autotools-2 su_v$ grep locale build/config.h
| #define PACKAGE_LOCALE_DIR "/Volumes/magenta/src/inkscape/inkscape-repo/mp-quartz-autotools-2/inst/share/locale"
and:
| Making install in po
| installing am.gmo as /Volumes/magenta/src/inkscape/inkscape-repo/mp-quartz-autotools-2/inst/lib/locale/am/LC_MESSAGES/inkscape.mo
The paths do not match, and it results in Inkscape not being able to find locale files at runtime.

3) revision r12159 + fix-locale-path.patch:
| Chillida:mp-quartz-autotools-2 su_v$ grep locale build/config.h
| Chillida:mp-quartz-autotools-2 su_v$
and
| Making install in po
| installing am.gmo as /Volumes/magenta/src/inkscape/inkscape-repo/mp-quartz-autotools-2/inst/lib/locale/am/LC_MESSAGES/inkscape.mo
With your patch, the locale dir is no longer defined in config.h, the files are still installed into the wrong path, and Inkscape still cannot find the locale files at runtime (assuming an unchanged shell environment without any variables set specifically for Inkscape trunk).

4) Known workarounds
4a) Manually linking '$prefix/lib/locale' to '$prefix/share/locale' after 'make install' allows Inkscape to find the translation files, but this is a hack, and should not be used as 'fix' for this problem (IMHO).
4b) define $INKSCAPE_LOCALEDIR (set it to the incorrect installation path '$prefix/lib/locale') before launching inkscape from the shell (this should not be required: the binary is supposed to find the locale resources without having to resort to the built-in feature to allow _overriding_ the built-in path at runtime e.g. for full relocatable OS X application bundles)

5) Possibly fixes
5a) ship a patched intltool macro (I would not know how to prevent it from getting replaced when running autogen.sh)
5b) patch 'po/Makefile.in.in' (but isn't that an autogenerated file, too?)
5c) revert to Glib's gettext for now, until this is fixed upstream (?)

AFAICT the problem I'm trying to describe here matches the description in bug #398571 for intltool (Note: I don't know if it's exactly the same underlying issue): it seems to be a bug in intltool's macros (on non-Gnome platforms?), which does not occur when using Glib's gettext version.