Re: gettext: rebuilding .po files too often?

[Bruno Haible]

Paul D. Smith writes:

> I've finished updating the GNU make source tree to all the latest
> autotools, including the latest Gettext (with "external").  I like it!

Thank you :-)

> However, there is one kind of annoying thing.  Whenever I get a new
> version of my source from CVS and make it the first time, it rebuilds
> all my .po files.  I have two problems with this:
> 
>  1) It's slow.  There's nothing _I_, as a maintainer, can do about these
>     changes to the .po files, so why should I have to do this each time?

This problem occurs only because after cvs checkout, the timestamp of
po/make.pot is younger than the timestamp of the po/*.po. This is a
well-known problem between cvs and make: make looks at timestamps and
cvs doesn't preserve them.

The problem will go away quickly: As soon as you modify some of your
source files in such a way that make.pot changes, its timestamp will
become newer and "msgmerge --update" will not be called any more,
except during "make dist" or "make update-po".

In a previous version of Makefile.in.in, each PO file was touched
after "msgmerge --update", to avoid the above effect. But this had the
consequence that the PO files were also touched during "make dist",
and Jim Meyering and Alexandre Duret-Lutz objected...

> I saw some code in Makefile.in.in which seemed to be trying to update
> the .po files at dist creation time: to me that is exactly right

Yes this is how Makefile.in.in usually behaves.

>  2) It causes lots of unnecessary updates in my CVS files.

I cannot see how this is possible. If you see multiple "msgmerge
--update" runs on each file, the Makefile is in "release mode" and the
PO files don't change. After that, once the PO files have changed,
"msgmerge --update" will not be called any more until "make dist", and
you should have no further updates in CVS for a long time.

>     Whenever I
>     run "cvs commit" from the top of my try it's trying to check in
>     newer versions of all my .po files.

With regard to CVS you can deal with the PO files and the make.pot
file like with other autogenerated files like 'configure', '*/Makefile',
'doc/*.info*', 'doc/*.html' etc. The three usual approaches
are all reasonable:

  a) Put them into CVS and commit them each time they change.
  b) Put them into CVS and commit them only when you make a release.
  c) Don't put them into CVS, and also never commit a non-empty
     po/LINGUAS file (keep it empty forever in CVS).

Each of these approaches has its little drawback:
  a) The CVS repository grows in size quickly.
  b) You cannot use a global "cvs commit".
  c) Your collaborators only use and test the non-localized version.

> the _only_ way I should be checking in changes to
> .po files is when the translating team notifies me that they have a new
> version and I download it.

Even this is unnecessary - the PO file that you downloaded continues
to be available from the Translation Project's website - so why put it
into CVS?

> In that case the scenario would go: I make my changes, over time.  None
> of these results in new .po files being created.  When I'm ready to
> release I do a "make dist" and the new .po files and .pot file are
> created and put into the distribution tarballs.

That's how it works for me all the time.

> I _don't_ check those into CVS.

Sure. You shouldn't have a problem with that.

Bruno