Hi Simon,
> Is it safe to pull these changes into a project and do a release
> today, and the translation team will automatically figure things out?
> Or do I as maintainer of a package that uses translations and gnulib
> have to do anything extra, like informing the translation team about
> something? If so, what to say exactly?
The timeline of steps of various actors, in their regular pace, should
be as follows:
1) Today, we expect to publish a snapshot tarball for the Translation Project
(that corrects our first attempt from yesterday).
2) The TP coordinator then passes the gnulib.pot file to the translation
teams.
3) Two weeks later, we collect the updated translations of the "gnulib"
domain and publish them at ftp.gnu.org:gnu/gnulib/gnulib-l10n-DATE.tar.gz.
4) Then I notify the various distros of this new package and ask
them to include it in their distros.
5) Many of the distros will hopefully do this.
6) Then it's time for the packages that use gnulib to add to their
DEPENDENCIES (or INSTALL) file the mention of 'gnulib-l10n' as a
runtime dependency.
7) At the next release of such a package, it will be useful to ask
the distros to add a dependency link from that package to 'gnulib-l10n'.
You can thus make a release today, with the current gnulib sources
(otherwise I would not have committed the patches). But it is pointless
to do steps 6 and 7 already now, since
- step 6 will raise questions (since a package 'gnulib-l10n' does not
yet exist),
- step 7 makes no sense before step 5.
Even if you don't make a new release of your package within five years,
we expect that the 'gnulib-l10n' binary packages will land on the users'
disk (via coreutils, gettext, and a few other widely used packages),
and your package will use these localizations, assuming you have added
the necessary
bindtextdomain ("gnulib", GNULIB_LOCALEDIR);
or
bindtextdomain ("gnulib", relocate (GNULIB_LOCALEDIR));
line in each program's main() function.
You don't have to communicate with the translation teams or with
the Translation Project (other than the regular notification to
the TP coordinator when you have a prerelease that contains a .pot
file). The next time you create a POT file for your package, it should
not contain messages from gnulib source code any more (e.g. [1]).
The translators will simply notice that your POT file has shrunk,
and the translation tools will discard then-obsolete message translations.
Bruno
[1]
https://git.savannah.gnu.org/gitweb/?p=gettext.git;a=commitdiff;h=adce2d596fcf5a3ecb5c67c4dc8730d3042ef67c
