Debian Bug report logs -
#114461
gettext: there is no way to control where message catalogs are found at run time
Reply or subscribe to this bug.
Toggle useless messages
Report forwarded to debian-bugs-dist@lists.debian.org, Santiago Vila <sanvila@debian.org>:
Bug#114461; Package gettext.
(full text, mbox, link).
Acknowledgement sent to Zack Weinberg <zack@codesourcery.com>:
New Bug report received and forwarded. Copy sent to Santiago Vila <sanvila@debian.org>.
(full text, mbox, link).
Message #5 received at submit@bugs.debian.org (full text, mbox, reply):
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.
-- System Information
Debian Release: testing/unstable
Kernel Version: Linux taltos 2.2.20-pre3-pipefix #1 Wed Aug 1 14:05:04 PDT 2001 i686 unknown
Versions of the packages gettext depends on:
ii gettext-base 0.10.40-1 GNU Internationalization utilities for the b
ii libc6 2.2.4-2 GNU C Library: Shared libraries and Timezone
Reply sent to Santiago Vila <sanvila@unex.es>:
You have marked Bug as forwarded.
(full text, mbox, link).
Message #8 received at 114461-forwarded@bugs.debian.org (full text, mbox, reply):
[ Please, disregard the previous message ].
Hello.
I received this from the Debian Bug System.
---------- Forwarded message ----------
Date: Thu, 04 Oct 2001 09:43:33 -0700
From: Zack Weinberg <zack@codesourcery.com>
To: submit@bugs.debian.org
Subject: #114461: gettext: there is no way to control where message
catalogs are found at run time
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.
-- System Information
Debian Release: testing/unstable
Kernel Version: Linux taltos 2.2.20-pre3-pipefix #1 Wed Aug 1 14:05:04 PDT 2001 i686 unknown
Versions of the packages gettext depends on:
ii gettext-base 0.10.40-1 GNU Internationalization utilities for the b
ii libc6 2.2.4-2 GNU C Library: Shared libraries and Timezone
Message #9 received at 114461-forwarded@bugs.debian.org (full text, mbox, reply):
Zack Weinberg wrote:
> 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.
It is for practical reasons: Most people rarely install locales, but
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
Message #10 received at 114461-forwarded@bugs.debian.org (full text, mbox, reply):
On Tue, Jun 11, 2002 at 09:18:29PM +0200, Bruno Haible wrote:
> Zack Weinberg wrote:
> > 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.
>
> It is for practical reasons: Most people rarely install locales, but
> 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.
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
Message #11 received at 114461-forwarded@bugs.debian.org (full text, mbox, reply):
> From: Zack Weinberg <zack@codesourcery.com>
> Date: Tue, 11 Jun 2002 12:33:59 -0700
>
> On Tue, Jun 11, 2002 at 09:18:29PM +0200, Bruno Haible wrote:
>
> > It is for practical reasons: Most people rarely install locales, but
> > 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.
>
> 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.
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?
Message #12 received at 114461-forwarded@bugs.debian.org (full text, mbox, reply):
Zack Weinberg wrote:
> 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.
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
Message #13 received at 114461-forwarded@bugs.debian.org (full text, mbox, reply):
Paul Eggert wrote:
> 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?
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
Tags added: upstream
Request was from Santiago Vila <sanvila@unex.es>
to control@bugs.debian.org.
(full text, mbox, link).
Message #16 received at 114461-forwarded@bugs.debian.org (full text, mbox, reply):
On Fri, Jun 14, 2002 at 01:34:26PM +0200, Bruno Haible wrote:
> Zack Weinberg wrote:
> > 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.
>
> 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
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
Send a report that this bug log contains spam.
Debian bug tracking system administrator <owner@bugs.debian.org>.
Last modified:
Sat Jan 6 19:55:14 2018;
Machine Name:
buxtehude
Debian Bug tracking system
Debbugs is free software and licensed under the terms of the GNU
Public License version 2. The current version can be obtained
from https://bugs.debian.org/debbugs-source/.
Copyright © 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson,
2005-2017 Don Armstrong, and many other contributors.