-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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. > > - The messages on trunk evolve much more quickly than on 0.12-stable, > and may be added and removed many times over. > > - Merging message catalogs and translations probably becomes very > tedious very quickly.
I don't argue against this statements at all, just add that many software developers are quite fine with just English like Trac did all the time before 0.12dev. Still there may evolve some applications that heavily depend on i18n. In fact, one of my Trac applications is almost worthless without (German) translations, since it is highly end-user orientated. Some feature testing/bug resolutions might strictly require both, code and translations, as well. > 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. This might very well go like this, for the main repository. The Trac SVN repo has seen a significant number of message catalog updates by now, let alone any related merging work. IMHO, what still holds off real clutter from the repo is the obviously successful work of the developers and language coordinators, that sometimes do merge a dozen patches into a single changeset. However I suggest to have a dedicated i18n repo at least for trunk. There is another chance with this separation. We would be able to test direct commits from Transifex to Trac_trunk. BTW, wasn't a dedicated i18n repo suggested some time before? I think so. I was looking forward to see this happen, and I may even do a branch dedicated to trac/locale on my own, as soon as I feel the need for myself and no one has stepped up before. [...] > My apologies if I have just stated the obvious, but I haven't seen this > documented anywhere, so I wanted to make sure we were all on the same page. Oh, I think there's plenty much room for discussion as outlined above. There is an additional note dedicated to translator -> "core" developer communication: While there is coordination and discussion up to some degree among translators, today the "uplink" to code development is weak if existent at all. Sure there are exceptions, but mostly because the translators involved are contributors to Trac plugins or Trac code itself as well. I'd love to see others commenting on this subject, especially if someone could think of any improvement. As far as I experience, joining trac-dev is not what a lot of translators are interested in. Still I hesitate to strongly suggest yet another list, like trac-i18n, since there might be not enough man power to actively support and maintain it. Steffen Hoffmann (hasienda) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkxk+A8ACgkQ31DJeiZFuHewZwCfVtax5qVs6q/k336LnOFZLti/ lDUAoOfW/ziZ3E//fgpzRK8hngOwR3Y2 =BNqi -----END PGP SIGNATURE----- -- You received this message because you are subscribed to the Google Groups "Trac Development" group. To post to this group, send email to trac-...@googlegroups.com. To unsubscribe from this group, send email to trac-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en.
