On Fri, 2003-10-10 at 15:52, Simone Piunno wrote:
On Friday 10 October 2003 21:05, Barry Warsaw wrote:
One of the biggest pains for me lately has been managing the .po file catalogs across the HEAD and the 2.1-maint branch.
Personally I wouldn't have problems managing HEAD and 2.1-maint for italian as two different file sets, tracked separately, and in fact I'm already doing this since at least 2.1.1 (you should have noted I always commit changes to the right branch or to both).
Yep, and thanks! But not everyone is as comfortable with cvs as you are, so I wonder how big a burden the current arrangement is on translators.
If you leave us this burden you won't have to backport anymore, but I don't know if other translators would feel like it.
That's what I want to know. It's going to be basically impossible for me to backport any more, so if the current arrangement means that one or the other translation gets neglected, I'd like to find a better solution.
We had talked before about moving Mailman's i18n work to the Translation Project[1], and I think now's the perfect time to revisit that. I don't have any direct experience with TP, so first, I'm wondering who out there has, and what you think about it.
I have no experience with TP (even if I'm enlisted in their site) and I'm neutral on this. I even signed their disclaimer.
http://www.iro.umontreal.ca/~gnutra/HTML/disclaim.html
The alternative for going to TP would be for me to pull the messages subdir out of the top-level directory, and manage that outside of any CVS branches.
Where's the difference between this option and just stopping backports, letting us track branches as different trees?
The difference is that, if we pulled messages out and de-branched them, I'd make sure mailman.pot was the union of all the head and maint branch texts, so you'd only have one .po file to translate.
The other i18n change I'm planning is to adopt ZPT for the templates. I think we don't have to wait for MM3.0 for that, and it will have many great advantages. For i18n, the major advantages is that it means you will no longer have to translate whole templates -- we can mark translatable strings in the ZPT, and extract them to the .pot file, so there's only one set of texts you need to translate.
I have experience with ZPT-i18n only through plone+localizer. In my experience, translating a full text (as a full template) is way easier than translating small pieces (like in .po), even when the full text is intermixed with tags.
Definitely. One lesson I've learned is that in some languages, it's impossible to accurately translate sentence fragments. If I do ZPT the u/i, I'll try my hardest to make sure the sentence is the smallest unit of translation.
Furthermore, AFAIK marking in ZPT is tricky and error prone. On the plus side, separating template structure from strings is good for stability, cause then you're free to change the english template and the new structure will be immediatly available for other languages.
Exactly. Another big goal of mine is to get rid of all the crufty u/i generation from Python code, i.e. the admin interface. Moving to ZPT would allow us to greatly improve the usability and look of the u/i, and at the same time, make it much easier for others to change the default look to match a site they're integrating with. -Barry