Re: {bindtextdomain} needs an environment variable override

[Bruno Haible]

Nelson Henry Eric wrote:
> Since {bindtextdomain} is hard-coded, the end user is totally at the mercy
> of the person who compiled/installed the binary of any program which uses
> gettext().  It means that binaries cannot be copied to other machines
> unless their file systems are exactly the same as far as the
> {bindtextdomain} prefix.  It definitely prevents individual users from
> installing and using specific translations (*.mo) in their own account
> space that either are not available or out-of-date in the default
> /usr/local.  It also means that a person cannot use/test their own
> translation although they may find it more comfortable than the one
> installed systemwide.
>
> If the user could set some environment variable to override the default
> compiled into the binary it would make gettext functionality much superior.

Hi,

Thanks for the suggestion.

The situation is not as bad as you describe: Users can install packages
from source by configuring them with --prefix=$HOME. Then they can use
their own translation or modified source code too.

For most users, the .mo files are an integral part of an application,
just like other kinds of data files.

Do we need a mechanism that lets users choose particular translations on a
per-package basis? I don't think so: Most users are satisfied with global
language settings (LANG, LANGUAGE), and the advanced ones can make shell
script wrappers like

    #!/bin/sh
    exec env LANGUAGE=pt_BR /usr/bin/foobar

Even assuming a mechanism for choosing translations on a per-package
basis were desired, the environment variable approach is the wrong one.
Environment variables are inherited through fork/exec, i.e. when a
program invokes another one, the second one would try to locate the
message catalogs in the directory where one the catalogs for the first
program can be found.

Bruno