[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: gnulib-tool --po-base - allow empty message catalog
From: |
Gavin Smith |
Subject: |
Re: gnulib-tool --po-base - allow empty message catalog |
Date: |
Sat, 7 Dec 2024 09:26:24 +0000 |
On Sat, Dec 07, 2024 at 08:59:56AM +0100, Bruno Haible wrote:
> > This is likely to happen for other project too if they do not use
> > many Gnulib modules or remove modules.
> >
> > The effect of this means that the package will be distributed with the
> > Gnulib translation catalogs with extra translations in them that the
> > program does not use.
>
> 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.