[Dropping bug-texinfo and bug-gettext from CC]
Gavin Smith wrote:
> > In this case, the package should ship no *.po files in this directory
> > at all — since there is nothing to translate.
>
> This is possible but it is more work to remove the gettext infrastructure
> for this Gnulib import. It would be possible that that Gnulib modules
> we use could use translated strings in the future or that we use other
> modules that do.
>
> It should be harmless to have empty translations files as they do
> not use much disk space and only occupy space on a directory listing.
>
> Users of Gnulib translations in this situation are likely to miss that
> the .pot file are not being updated and continue distributing irrelevant
> and out-of-date translations.
>
> > > I found that xgettext needs the --force-po option to output an empty
> > > file (which then becomes a .pot file with Makefile rules).
> > >
> > > Hence, I suggest the following change to use this option for Gnulib's
> > > runs of xgettext:
> >
> > That's not an appropriate fix, since it means that the translators will
> > be notified to translate a file with no contents; this is useless noise
> > for them.
>
> My understanding is that packages do not provide these files to translators
> and that the translations are updated from Gnulib translations by
> gnulib-import.
>
> For these reasons, a new method was designed and is now recommended.
> If you pass the ‘--po-base=DIRECTORY’ and ‘--po-domain=DOMAIN’ options
> to ‘gnulib-tool’, then ‘gnulib-tool’ will create a separate directory
> with its own ‘POTFILES.in’, and fetch current translations directly from
> the Translation Project (using ‘rsync’ or ‘wget’, whichever is
> available).
>
> (Info node (gnulib)Localization.)
>
> Admittedly, I don't know how these Gnulib translations are updated, so it
> is possible there is some knock-on effect. It depends if the Gnulib
> project uses gnulib-tool somehow in providing strings to translators.
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.
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.
In order to make progress, let me ask and tentatively answer some questions:
1) At the TP site, should there be one gnulib domain, or one per package?
Answer: In order to avoid redundant translator work, there should only
be one. Like it is now.
2) Who is responsible for submitting the POT file to the TP? And when
should this happen?
Answer: Since the latest submission from Akim is more than 5 years old,
it's probably a good idea if the Gnulib maintainers do this.
Regarding the frequency: Gnulib doesn't have releases, but has stable
branches. We could submit one POT file per stable branch, that is, every
6 months.
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.
(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.
It implies that there will be a package 'gnulib-l10n', distributed
through ftp.gnu.org and included in the distros, that contain only
the gnulib localizations.
Additionally, we'll need some gnulib-tool magic for turning the
_(msgid) calls to dgettext ("gnulib", msgid) inside gnulib-imported
directories.
And gnulib-tool's --po-base and --po-domain option that were meant
for approach (b) can then be deprecated.
Opinions? Comments?
Bruno
[1] https://lists.gnu.org/archive/html/bug-gnulib/2008-01/msg00010.html
[2] https://www.gnu.org/software/gnulib/manual/html_node/Localization.html
[3] https://codesearch.debian.net/search?q=bindtextdomain.*gnulib%22&literal=0
[4] https://translationproject.org/POT-files/
[5] https://translationproject.org/domain/gnulib.html
[6] https://alpha.gnu.org/gnu/bison/
[7] https://lists.gnu.org/archive/html/bug-gnulib/2022-07/msg00053.html
[8] https://packages.debian.org/bookworm/bison
