Re: Supporting multiple gettext directories

[Martin Pitt <martin at piware dot de>]

Hi!

Paul Eggert [2005-03-22 10:46 -0800]:
> > If a mo file is present in only one directory, it is used; if it is
> > present in both, the file with the newest modification time is used.
> 
> This sounds strange.  Would you want the shell to search through PATH
> looking for the most-recently modified executable?

Sorry, I was pretty unclear about this. I don't intend to proliferate
time stamp checking, this is just how we do it right now and I asked
for some help to optimize it. However, timestamp comparison is not
what I would like to see to be adopted upstream, but rather a
$PATH-like semantics.

So please let me reformulate myself into a longer, but more precise
specification.

Currently glibc only looks for mo files in one directory (usually
/usr/share/locales). However, I propose to extend this by supporting a
$PATH-alike search path, for example

  GETTEXT_PATH=/usr/local/share/locale:/usr/share/locale

Rationale
---------

1)
The FHS, and many distributions strictly separate a /usr and
/usr/local hierarchy; the former for files managed in packages, the
latter for files managed by the administrator (this is usually where
self-compiled applications are put into). However, it is currently not
possible to install translations for local applications into
/usr/locale/share/locale, because glibc does not look for mo files
there. This has the consequence that  locally compiled applications
usually put their translations into /usr/share/locale, which breaks
the separation and causes file clashes.

2)
A distribution might choose to ship translations
separately from the actual application packages (for various reasons;
ask me if you are interested). There is good reason to not put the mo
files from these "language packs" into /usr/share/locale since this
would mean that an user cannot install any packages from other
distributors any more (because this would file-clash).

3)
Users might want to install applications into $HOME/bin. It would be
nice if they could install the translations into their home directory,
too (e. g. $HOME/locale/).

Path specification
------------------

The format of a path specification is similar to $PATH, i. e. a list of
directories separated by ':'.

Ideally, the search path could be specified in several places (with
descending priority): environment variable (e. g. $GETTEXT_PATH),
$HOME/.gettextrc, /etc/gettextrc, hardcoded default (should be
/usr/local/share/locale:/usr/share/locale).

Behaviour
---------
(This applies if no path is given to bindtextdomain()):

Instead of just looking into the hardcoded default directory
(configured at build time), all directories in the search path are
checked. The first file that is found is used. (I. e. exactly the same
semantics as $PATH).

> > If glibc would support /usr/local/share/locale in addition to
> > /usr/share/locale, then this would complete this namespace
> > splitting.
> 
> glibc does support multiple directories, using bindtextdomain().

* How does this work? It is not documented in the manpage.

* Even if something like bindtextdomain ("mydomain",
    "/usr/local/share/locale:/usr/share/locale") would work (it
  doesn't at the moment) it would be impractical and inflexible to
  modify each and every piece of software.

* The rationale explains three system-level problems, so this should
  be solved at the system, not application level.

Thanks for considering and have a nice day,

Martin
-- 
Martin Pitt               http://www.piware.de
Ubuntu Developer    http://www.ubuntulinux.org
Debian Developer         http://www.debian.org

Attachment: signature.asc
Description: Digital signature