Re: gnulib localizations

[Gavin Smith]

> You are right. And still, the problem with the nonexistent/empty POT file
> is only the smallest problem in the current state of gnulib localizations.
> 
> The current state is a failure. Documentation was added on 2008-01-03 [1][2],
> but nevertheless
> 
>   * Among the > 100 packages that use gnulib, more than 90% don't use
>     localizations for its messages.
> 
>   * 5 packages use the documented approach [2]: bison, man-db, wget, a2ps,
>     freedink.[3] Now also maybe texinfo.
> 
>   * Although the stated goal in [1] was
>       "particularly to save translation teams from translating
>        the same strings multiple times (if they don't use translation
>        memory)"
>     4 packages incorporate gnulib source files in their POTFILES.in and
>     thus ask the translators to do repeated work: coreutils, gettext, wget,
>     wget2.[4]
> 
>   * The latest gnulib POT file is more than 5 years old. [5][6]
> 
> Additionally
> 
>   * The gnulib-tool options --po-base and --po-domain predate the split
>     between "autopull" and "autogen", that has several reasons [7].
>     gnulib-tool is part of the "autogen" phase. Therefore gnulib-tool
>     ought to not fetch translations, and these two options ought to be
>     deprecated.
> 
> We need to rethink the entire process and system of gnulib localizations.

I am just speaking as a user of gnulib and gettext, but generally I
feel like I don't have a great understanding of gettext.  If I can set
up the project that uses gettext to work I don't want to mess with it
too much.  (The switch to gnulib translations was made by another
contributor to Texinfo.)  I use gettext, and indeed gnulib, with a small
number of routine recipes, and don't go looking to see what possibilities
they afford.  Hence I had not been aware of the new system for gnulib
translations.  (Part of the issue may be the broader complexity of the
GNU Build System and confusing interactions among gnulib, gettext, automake
etc. leading to a general psychological aversion - not that much can be
done here.)

If possible, gnulib translations should be made without much adaptation
by the developers of the package using gnulib.  The main requirement
for developers is to add the bindtextdomain call with the directory
name of LOCALEDIR, which is usually $(datadir)/locale.

The Gnulib build system installs the translation files, so it should
be able to provide the location of the translation files to Gnulib
code automatically.  Could gnulib infrastructure provide the value of
LOCALEDIR using the "datadir" configure value, calling "bindtextdomain"
automatically as required?

> For comparison, the way the localizations of bison-generated parsers are
> distributed is right:
>   - It uses a domain "bison-runtime". The POT file is updated with each
>     bison release.
>   - The translations for this domain are installed once.
>   - There is a Gnulib module 'bison-i18n' that helps the developer of
>     packages that use bison.
> The only problem I see is that in Debian, the bison-runtime.mo files are
> in the package 'bison' [8] but should better be in a package 'bison-runtime'
> that would be among the dependencies of all packages that include a bison
> parser.

I think the problem with requiring extra packages to be installed is
that it seems to against the gnulib philosophy that it is not a separate
library and does not have to be installed separately from packages that
use it.  You could make exactly the same argument about duplication and
wasted disk space about gnulib code that is used by multiple packages.

Another issue is that the translated strings may depend on the point of
time the package took its code from gnulib.  Some packages may reference
strings that do not exist in newer versions of gnulib.  So it makes
sense for the gnulib code import and the gnulib translations import to be
close in time together, assuming the gnulib translations are up-to-date.

If it was required for operating systems to install a separate package
containing translations for all of the gnulib translations, it is likely
that it would often not be installed.


>   3) How do the translations of this domain integrate back into the packages?
> 
>      Answer: There are three possibilities.
>      (a) Each translation is installed as
>          /usr/share/locale/$lang/LC_MESSAGES/gnulib.mo.
>          The package uses a variable GNULIB_LOCALEDIR (similar to the
>          BISON_LOCALEDIR provided by bison-i18n.m4).
>      (b) No gnulib.mo files are installed. Instead, packages have a po/
>          directory specifically for the part of gnulib that they use. They
>          fetch the translations from their TP, msgmerge them with their
>          PACKAGE-gnulib.pot file (expected to be smaller than gnulib.pot)
>          and install the resulting .mo files as
>          /usr/share/locale/$lang/LC_MESSAGES/PACKAGE-gnulib.mo.

AFAIK this is the current system.

>      (c) No gnulib.mo files are installed. Instead, packages retrieve the
>          translations for PACKAGE and for gnulib and merge the two together
>          into a single .mo file per language (using msgcat).
> 
>      Approaches (b) and (c) have two drawbacks:
>        - When N packages use it, the translations appear N times on the
>          users' disk.
>        - It is a significant added complexity for the package maintainer.
>          This reduces the likelihood that many packages will adopt this.
>      Approach (c) additionally causes confusion between the PACKAGE.pot
>      and the translations which are for PACKAGE.pot + gnulib.pot.
> 
>     So, for me, approach (a) looks like the best one.

Perhaps the number of translated strings from gnulib is not very large
for some packages and so the amount of disk space used is not great.