Re: New PO Template file for `gcc'

["Joseph S. Myers" <jsm28 at cam dot ac dot uk>]

On Mon, 26 May 2003, Philipp Thomas wrote:

> I wanted to update de.po, da.po, es.po and tr.po for 3.3, but as there is no
> 3.3 branch yet, how am I going to update the po files? The only chance I
> currently see would be to update mainline and then update the respective
> 3.3.X branch if it ever gets created.

The 3.3 branch has been around since December.  The 3.3.1 release will in
due course be made from the 3.3 branch (date not announced, but probably
around 14 July); it is currently open for documentation (including .po
files) and regression patches.

(The .po files should be updated on mainline as well - including some
which Mark updated on the 3.3 branch only, just before the release.  It
may be time for another gcc.pot regeneration on mainline as well.)

It is desirable for new .po files to get checked in on mainline and the
appropriate release branch as soon as they are sent to gcc-patches; it
saves the Release Manager from needing to make such checkins at the last
minute, as well as meaning people using snapshots and prereleases get
better translations.

> And regarding 3.2.3, that branch is closed, so how would I go about updating
> files for it?

You don't - distributors can always add the 3.2.3 .po files to their
redistributions of GCC if they want, but they don't really correspond to
3.2.3 as the gcc.pot file on the 3.2 branch wasn't regenerated for 3.2.3
or even for a long time before then.

> This seems to always be a problem for gcc. To get distributed, the
> translations have to come in before the release, i.e. be done against a
> snapshot or prerelease version. Once a version has been released, there is
> no way to update that release version until an update branch is opened.

A release is a release - the file versions in it are fixed for eternity
once the release is made and form a stable basis for diffs towards the
next release; any other way (having more than one version of a file
purporting to be a particular release) lies madness and the impossibility
of using diffs reliably.  As soon as a release is made, the branch is
opened for the next point release (unless there are to be no more point
releases from that branch) and updated .po files can go in.

We now have the Release Manager regenerating gcc.pot and checking for new
.po files immediately before making a release, which is progress.  There
should not be many significant diagnostic changes on a release branch,
especially not after a release has been made from it, so if the
translators are active in updating translations when a snapshot from the
release branch is submitted (as was done early on the 3.3 branch) and then
after releases are made, the translations in 3.3.1 or 3.3.2 can be a very
close match to the messages in that version.

It would be possible to regenerate gcc.pot automatically before each
snapshot (Zack had a script to do this, but more work was needed).  But
we've been told that the Translation Project does not want automatic
weekly submission of new .pot files for snapshots, so for this to be
useful in keeping translations up to date, translators would need to
interact with GCC some other way.

-- 
Joseph S. Myers
jsm28@cam.ac.uk