#114461 gettext: there is no way to control where message catalogs are found at run time

Package:
gettext
Source:
gettext
Description:
GNU Internationalization utilities
Submitter:
Zack Weinberg
Date:
2005-07-18 03:43:56 UTC
Severity:
normal
#114461#5
Date:
2001-10-04 16:43:33 UTC
From:
To:
Unlike all other aspects of locale information, message catalogs are
found only in the location compiled into the binary.  Environment
variables such as LOCPATH do not affect the search.

The gettext command honors a TEXTDOMAINDIR environment variable, but
nothing else does.  It would be best, in my opinion, if LOCPATH worked
as it does for other locale information.
#114461#8
Date:
2001-10-06 12:45:45 UTC
From:
To:
[ Please, disregard the previous message ].

Hello.

I received this from the Debian Bug System.


Package: gettext
Version: 0.10.40-1
Severity: normal

Unlike all other aspects of locale information, message catalogs are
found only in the location compiled into the binary.  Environment
variables such as LOCPATH do not affect the search.

The gettext command honors a TEXTDOMAINDIR environment variable, but
nothing else does.  It would be best, in my opinion, if LOCPATH worked
as it does for other locale information.
#114461#9
Date:
2002-06-11 19:18:29 UTC
From:
To:
Zack Weinberg wrote:
sometimes install new packages. They would tend to set the LOCPATH
environment variables to include all the directories where they have
installed packages, like /usr/local, /opt/kde, etc. Since LOCPATH
applies affects the startup time of all programs, in would quite
significantly affect the performance of the system. For these reasons,
it's better to keep LOCPATH and TEXTDOMAINDIR separate.

Bruno
#114461#10
Date:
2002-06-11 19:33:59 UTC
From:
To:
Okay, but then TEXTDOMAINDIR should be honored by all libgettext-using
programs, not just the gettext command.  Right now, there is *no way*
to override the compiled-in path in most libgettext-using programs.

zw
#114461#11
Date:
2002-06-12 01:16:43 UTC
From:
To:
POSIX 1003.1-2001 specifies an NLSPATH environment variable for this
purpose.  POSIX requires only only the catopen family of functions,
but it's natural for the gettext family to use NLSPATH too, and that
is how Solaris gettext(3c) does things.  Shouldn't the GNU gettext
function family support NLSPATH?
#114461#12
Date:
2002-06-14 11:34:26 UTC
From:
To:
Zack Weinberg wrote:

This is not true. Assuming you as a user or translator have your private
Italian translations in $HOME/my-translations/it, then you can cause
gettext to use your translations in preferrence of / in addition to the
preinstalled Italian ones by setting the environment variable

  $ export LANGUAGE=../../../../../../$HOME/my-translations/it:it

This works because the elements of the LANGUAGE specifications can be
relative pathnames.

In gettext 0.11.3, and maybe also glibc 2.3, you'll be able to use
absolute pathnames inside LANGUAGE, so that you can write

  $ export LANGUAGE=$HOME/my-translations/it:it

Bruno
#114461#13
Date:
2002-06-14 11:35:15 UTC
From:
To:
Paul Eggert wrote:

I don't think this is possible without major hassles. NLSPATH (see its
description in susv3/basedefs/xbd_chap08.html) contains filename
templates, usually ending in ".cat". If we were to add ".mo" file
templates there as well, it's likely that catopen attempts to open
a .mo file, or that gettext attempts to open a .cat file. Furthermore
NLSPATH usually points into $prefix/lib, whereas .mo files are located
in $prefix/share.

Bruno
#114461#16
Date:
2002-08-31 05:53:56 UTC
From:
To:
Is this documented anywhere?

And, speaking as a user, I find TEXTDOMAINDIR dramatically easier to
comprehend than this - this looks like an ugly hack, frankly.

zw