Re: Status of the sarge branch?

[Christian Perrier <bubulle@debian.org>]

Quoting Frans Pop (aragorn@tiscali.nl):

> > In that case the individual PO files coming from trunk are newer than
> > the sarge ones...but would be replaced by those from the outdated
> > master file.
> >
> > So, my conclusion is that we should keep the sarge master files synced
> > with the trunk ones.
> >
> > What I imagine is a scheme where translators only commit to trunk
> > master files. The changes are then merged to the sarge files by a
> > script run from gluck and l10n-sync is run on sarge branch.
> 
> Automatically? Without anyone looking at the content of the changes? What 
> happens when new strings are added or existing strings are changed or 
> dropped in trunk?
> Sounds like a bad idea to me...

Hmm, let's try a demonstration. Hang on.

What may happen is that strings are in trunk but not in sarge
because they are:

-new English strings
-modified English strings

Let's assume we merge the PO from trunk and the PO from sarge the
following way:

msgcat --use-first trunk.po sarge.po >new.po
msgmerge -U new.po template-sarge.pot

- If an English string is in trunk but not in sarge, it will go in
  new.po in first step, then be marked "obsolete" in the second step
  (because it is not in the POT) but will still be in the PO

-If an English string has been removed from trunk but is still in
 sarge, it will go in new.po in the first step, coming from sarge.po,
 and will stay here in the second step because it is also in the POT

-If an English string has been *modified* in trunk, the result is
 similar to the case of a new string. It will remain in the obsoleted
 entries


Now, what about modifications to translations?

-If translators modify, in trunk, the translation of a string which is
 the same in sarge and trunk, the translation from trunk will go to
 sarge


And, now the final, tricky case of a modified string which finally
goes to sarge because we have a good reason for that:

When that string was un trunk, translatos updated their translations
for it. So the trunk version had the translations...and it went to
sarge translations as an "obsolete" entry. When the string is added to
sarge, the obsolete entry is automagically resurrected when the PO
file containing it is msgmerged with the POT file.


The important point here is that we give priority to trunk over sarge
for strings which have identical English versions in both. "sarge
only" strings remain as they were when sarge was released. And "trunk
only" strings go in the sarge PO fils as "obsolete" entries.

So, well, I still see no harm in keeping the sarge packages/po files.

The only problem we have is that we need to start with complete sarge
files....which is not the case currently (running l10n-sync on sarge
triggers 8 fuzzies).