Hello,

I missed this topic in August, and since I recently took some actions not completely matching what Remy proposed here, he asked me to expose my reasons in the present discussion, in order to inform the other translators.

On 8/12/2010 5:35 PM, Remy Blank wrote:
I have been thinking a bit about how the i18n workflow interacts with
our standard merging procedure from 0.12-stable to trunk. Considering
the following:

  - We will be making regular releases from 0.12-stable, whereas trunk
will stay unreleased for some time.

True, however I think we will make less and less changes on 0.12-stable. 0.12.1 will probably be the "bigger" of them.

  - The messages on trunk evolve much more quickly than on 0.12-stable,
and may be added and removed many times over.

But doing the i18n work in an incremental way has also its advantages, as we don't risk to get problematic untranslatable constructs, or miss translation markers. L10N work (i.e. the translations themselves) can certainly wait for the stabilization periods, but maintaining at last one language in sync (e.g. fr?) ensures that we always have a good i18n status.

  - Merging message catalogs and translations probably becomes very
tedious very quickly.

I don't expect this to happen often. Once translators have finished to translate the new messages in 0.12-stable for 0.12.1, we will merge that automatically to trunk and update it there. Come to think about it, we could just restrict the changes to happen on 0.12-stable, so we can continue to do the automatic merge on trunk, until we're in a stabilization period on trunk.

I would suggest that we only ever extract the message catalog on
0.12-stable, and that translators work exclusively on that branch. The
message catalog and translations on trunk should only ever be updated by
(trivial) merges from 0.12-stable.

Ok, so here we agree.

This means that trunk will be largely untranslated for quite some time.
When 0.13b becomes close to being released, we can update the catalog on
trunk and update the translations on trunk.

... except for that part, I think regular catalog extraction and the translation of at least one "sample" language is needed for keeping up a good i18n status on trunk. But you're right, we should make sure this doesn't cause any trouble or additional work to our translators.

   From that point, all merges
to the catalog and translations from 0.12-stable should be blocked.
Therefore, translation work will start being duplicated, but at the same
time, work on 0.12-stable should have slowed down considerably, so this
shouldn't have too much impact on translators.

If everyone agrees, I would kindly ask our translators to switch their
working copies to 0.12-stable, and work from there. I will merge the few
translation changes that have already happened on trunk back to 0.12-stable.

Therefore I've now changed the authz policy, so that no one commits on trunk by accident. Sorry for the inconvenience but it's for your own good ;-) If you were about to commit some pending changes, it's not a big deal, just "svn switch" to ^/branches/0.12-stable, the .po files should still have the same base content on both sides. If someone nevertheless prefers to work more closely on trunk, with the additional burden of doing the merge yourself and manually, feel free to contact me directly, and I'll change it back.

-- Christian

--
You received this message because you are subscribed to the Google Groups "Trac 
Development" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/trac-dev?hl=en.

Reply via email to