[D-I] Proposal for handling l10n in sarge branch of D-I
I'm afraid this message is a bit long. I tried to make it as clear as
possible, but this is indeed a quite complicated topic, so please hang
on. Don't hesitate asking questions if something is not clear...(and I
think the some things will be)
After the release of Debian Installer RC3, the separation between the
sarge branch and the "trunk" branch is becoming clearer.
>From a discussion with Joey Hess, I understood that all development
for D-I releases targeted at sarge will be done in the sarge branch.
This means that all packages which will be included will be released
from the code present in the sarge branch of D-I SVN repository.
In some rare cases, packages may be bringed from the trunk branch but
the sarge branch will then be updated with these as soon as they are
released.
When it comes to translations, my intent is to make things as simple
as possible for translators so that they have to focus on translations
rather than complicated details of packages handling.
This was the idea behind the "master files", ie the single files
containing all translations for all packages. This is also the idea
which drawn my proposal below:
All translations modifications will have to be handled in the trunk
branch. The only exception are languages which do NOT use the master
files.
In order to get changes made in trunk go to sarge and thus be released
when we will releases post-sarge updates of the installer, the
following scheme will be used:
-the synchronisation script (l10n-sync) will be run 4 times per day in
trunk, at 03:37, 09:27 and 15:27 (quick runs without debconf-updatepo
in individual packages) plus one "long" run at 22:27 (including
debconf-updatepo runs...in order to be sure that everything is synced)
-one time per day, I will run a merge between the trunk master files
and the sarge master files. This merge will give priority to
translations from trunk. This means that if both translations of the
same string differ, the one from trunk will be kept and will replace
the one from sarge
This merged file will then be merged with the template file from
sarge.
The resulting file will contain:
- for strings common to sarge and trunk : the translation from trunk
- for strings only present in sarge (because they have been removed
or changed in trunk) : the translation from sarge
- for strings only present in trunk (new packages or new templates)
: the translation from trunk
but marked "obsolete"
Then l10n-sync will be run so that all these translations are spread
out to individual packages, allowing them to incorporate these
changes when they are released
This scheme allows translators to focus on trunk only and mostly
forget about sarge, with few exceptions:
- languages not using master files-->you will need to update both
branches but, well, that's your choice, fellows...:-)
- needed changes for strings in sarge which are no more in trunk.
These will be mostly typo corrections and are very likely to be
very rare. Anyway, the scheme does not prevent specific updates in
sarge in such cases.
I have made intensive tests on the current sarge branch and I managed
to build the appropriate starting PO files, all being 100% translated
(for already complete languages of course).
So, my intent is to commit these files and start the process, possibly
on Monday April 11th. This will probably trigger a huge commit on PO
files in sarge but, indeed, very few files will have their
PO-Revision-Date changed, so Joey's scripts will be able to
distinguish the really changed packages in sarge for later builds.
For "prospective" languages, I need to discuss with Joey about
"opening the gates" and leave them go around in packages for the trunk
branch. This certainly needs discussion and maybe is not likely to
occur now, while we still could need to release stuff from trunk. So,
translators for these languages, you're not forgotten...:-)
--
Reply to: