Re: Use the translation domain "gnulib"

[Bruno Haible]

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