This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Supporting multiple gettext directories


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

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



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.

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).

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

(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 Pitt     
Ubuntu Developer
Debian Developer

Attachment: signature.asc
Description: Digital signature

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]