Steffen Hoffmann wrote: > 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.
Understood. But if this is a production server, shouldn't you be using 0.12-stable anyway? Even though trunk has always been quite stable, I wouldn't recommend using it in production, except for very special cases. > 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. Actually, "polluting" the SVN log wasn't one of my concerns. The main issue was to avoid duplicating the translators' work, by having them translate the same strings on both 0.12-stable and trunk. Indeed, if we allow the message catalogs from the branch and trunk to diverge, merging will become increasingly difficult, as the diff context of the strings includes the line numbers, which will certainly be different between 0.12-stable and trunk. Therefore, automatic merging will often fail (i.e. generate conflicts). Whereas if we keep the catalogs identical, merging translated strings will be trivial. Then, at the point where we want to start getting trunk ready for release (say, 1 - 2 months before the release), we update the catalog on trunk and stop merging. My hope is that the "fuzzy" updater will do a good job of "relocating" messages that haven't changed too much, so the only work needed will be to check the fuzzy messages, and translate all the new ones. > 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. That's a good point. > 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. Yes, that's correct. Christian started setting it up, but the whole conversion thing to Mercurial slowed that down. I'm not exactly sure what workflow he imagined, so I'll let him comment on that. > 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. You mean the communication of desired code changes to improve translations, or missing message tags? > 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. I'm open to all suggestions. It's true that the current communication medium between translators (the ticket for each language and the wiki page) is far from ideal, so a dedicated mailing list could work well for that case. OTOH, I don't see how this would improve the "uplink". -- Remy
signature.asc
Description: OpenPGP digital signature
