One of the biggest pains for me lately has been managing the .po file catalogs across the HEAD and the 2.1-maint branch. Don't get me wrong, you guys have done a superb job of managing the i18n stuff, and you have definitely helped make my life easier, but it seems that the po files, the templates, and cvs just don't mix well.
Things are going to get worse as the head diverges from the 2.1-maint branch. This is going to start happening soon as I start to work on Mailman 2.2. 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. My impressions from reading the site are that, while incomplete in some ways, it provides some useful facilities that will help separate the concerns of translators and Mailman developers. The major trade-off appears to be that you translators will lose a bit of independence, since you'll be working within the umbrella of TP language teams. What you gain for that is hopefully more help from other members of your language team. I'm pretty sure you can still concentrate your volunteer efforts on translating Mailman though.
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. It would take a little bit of cvs weaving to get a source build of Mailman from CVS, but I don't think that would be too painful. Note that I'm already planning on doing some CVS reorganization in preparation for 2.2 (more on that to the -developers list later).
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.
Thoughts? It seems relatively easy to register with TP, and start working with them, and if you all are generally in favor of this, I'd like to do it sooner rather than later.
-Barry
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).
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.
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 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. 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.
Regards, Simone
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
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
So you are lucky, I don't sign and send this disclaimer, so propably i'll have to wait more than month to be registered. I think that the most of Mailman translators are in the same situation.
TP is great, but especially for projects that don't have own i18n teams. They get chance to be translated into many languages. Mailman already has been translated, so i'm wondering if joining TP will make more mess that this is worth.
On other hand, Mailman translators can make TP stronger. Stronger language teams can translate more GNU software, and that sounds nice.
Conclusion: I think, that merging Mailman translations with TP is better for TP than for Mailman. Personally, Mailman is closer for me, so I'm neutral :)
BArtek
On Sat, 2003-10-11 at 05:52, Bartosz Sawicki wrote:
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
So you are lucky, I don't sign and send this disclaimer, so propably i'll have to wait more than month to be registered. I think that the most of Mailman translators are in the same situation.
I would try to arrange with Francois so that we could import all our existing po files, and allow a grace period on the disclaimer. Truth be told, I should be more diligent about getting translators to sign such disclaimers anyway. I definitely wouldn't want that to hold up progress, so I'd opt for a grace period of say 3 months.
TP is great, but especially for projects that don't have own i18n teams. They get chance to be translated into many languages. Mailman already has been translated, so i'm wondering if joining TP will make more mess that this is worth.
On other hand, Mailman translators can make TP stronger. Stronger language teams can translate more GNU software, and that sounds nice.
Conclusion: I think, that merging Mailman translations with TP is better for TP than for Mailman. Personally, Mailman is closer for me, so I'm neutral :)
Thanks for the feedback. So far, it sounds like a -0 for moving to TP.
-Barry
Barry Warsaw wrote:
I would try to arrange with Francois so that we could import all our existing po files, and allow a grace period on the disclaimer.
I'd like to clarify two things: first, François is no longer coordinating the TP; it is now Karl Eichwalder and myself. Second, submission of disclaimers should be independent of TP participation: copyright procedures for translators should be decided within the project - the TP can only offer to enforce the procedures, it cannot define them.
That said, projects that are part of the GNU project should have copyright assignments, translation disclaimers, and so on - atleast RMS tells us that this is how things should be within the GNU project.
Regards, Martin
On Sat, 2003-10-11 at 10:22, "Martin v. Löwis" wrote:
Barry Warsaw wrote:
I would try to arrange with Francois so that we could import all our existing po files, and allow a grace period on the disclaimer.
I'd like to clarify two things: first, François is no longer coordinating the TP; it is now Karl Eichwalder and myself.
Ah, good to know, thanks.
Second, submission of disclaimers should be independent of TP participation: copyright procedures for translators should be decided within the project - the TP can only offer to enforce the procedures, it cannot define them.
Good, then we could implement a grace period for getting disclaimers in. How easy is it to import our existing .po files?
That said, projects that are part of the GNU project should have copyright assignments, translation disclaimers, and so on - atleast RMS tells us that this is how things should be within the GNU project.
Definitely. Mailman's translators should read the disclaimer and expect to send them in to the FSF, regardless of whether we move to the TP or not. I've been lax about this, and I'd like to start getting these ducks in a row.
Besides that Martin, do you have any other input which might help us decide whether to move Mailman into the TP or not?
-Barry
Barry Warsaw wrote:
Good, then we could implement a grace period for getting disclaimers in. How easy is it to import our existing .po files?
Importing the PO files can be done very quickly - e.g. submitting the URL of a distribution file to translation@iro.umontreal.ca would be sufficient.
However, the mailman challenge might be incorporation of the HTML templates. For this, we have no precedence, yet. I would suggest to use similar procedures: email submission of new revisions of HTML template files by the translators; likewise email distribution of new versions of the English "master" documents to translators.
In PO files, both the Project-Id-Version and the POT-Creation-Date are used by the TP robot to establish consistency, allowing to determine whether a certain translation has been revised or not.
For HTML templates, I recommend a similar versioning scheme: define a constantly-increasing version of these files (either per file, or globally for all files), and put them into the template. In addition, put a time stamp into the template indicating when it was last changed. So a translated HTML file would contain a) the version number of the English file (project-id-version) b) the modification date of the English file (pot-creation-date) c) the modification date of the translation (po-revision-date)
This allows translators to find out what changes need to be done to what document, even if a translator leaves and a new one joins. It might also allow mailman to determine whether to display translated or English documents, e.g. if the translated document is of an "incompatible" version.
Besides that Martin, do you have any other input which might help us decide whether to move Mailman into the TP or not?
For quite some time now, the TP has the notion of "external" (to the TP) translations. This allows translators to submit their work directly to the maintainer (e.g. through CVS) if they wish so. On the TP pages, the status of these translations will be "external" - telling team members that they don't need to look into this translation (in the past, they would start working on a translation, only to find out it already exists).
Translators would need to "join" their teams, which basically means they need to introduce themselves to the team leader of their respective language, indicating that they do the mailman translation. Whether or not they join the team's mailing list, and whether or not they also look at the other work of the team is their choice. Joining the team mailing list is recommended, of course.
Regards, Martin
On Sat, 2003-10-11 at 17:46, "Martin v. Löwis" wrote:
Importing the PO files can be done very quickly - e.g. submitting the URL of a distribution file to translation@iro.umontreal.ca would be sufficient.
Cool.
However, the mailman challenge might be incorporation of the HTML templates.
I'm actually much less worried about these, since I plan to move to ZPT, which means that translators would not need to do whole-template translations any more. We can extract translatable strings from the ZPT and put them in the pot file.
For quite some time now, the TP has the notion of "external" (to the TP) translations. This allows translators to submit their work directly to the maintainer (e.g. through CVS) if they wish so. On the TP pages, the status of these translations will be "external" - telling team members that they don't need to look into this translation (in the past, they would start working on a translation, only to find out it already exists).
Translators would need to "join" their teams, which basically means they need to introduce themselves to the team leader of their respective language, indicating that they do the mailman translation. Whether or not they join the team's mailing list, and whether or not they also look at the other work of the team is their choice. Joining the team mailing list is recommended, of course.
Cool, thanks for the info. I still leave it up to the i18n folks to decide which way to go.
-Barry
Hi Barry,
Barry Warsaw wrote:
However, the mailman challenge might be incorporation of the HTML templates.
I'm actually much less worried about these, since I plan to move to ZPT, which means that translators would not need to do whole-template translations any more. We can extract translatable strings from the ZPT and put them in the pot file.
Can a list owner edit his template for customization ?
On Sun, 2003-10-12 at 08:19, Tokio Kikuchi wrote:
I'm actually much less worried about these, since I plan to move to ZPT, which means that translators would not need to do whole-template translations any more. We can extract translatable strings from the ZPT and put them in the pot file.
Can a list owner edit his template for customization ?
I think we can still allow that, but it will hopefully be less necessary. E.g. things like disabling the "you can post to the list via this address" text for announce-only lists should be handled by conditionals in the ZPT instead of having to edit the html.
-Barry
Hi!
On Sat, Oct 11, 2003 at 10:37:29AM -0400, Barry Warsaw wrote:
Besides that Martin, do you have any other input which might help us decide whether to move Mailman into the TP or not?
Speaking as a translator with experience at the TP and as module maintainer (for mailutils and nano at the TP), I think moving to the TP is a good idea, but having in mind one of the biggest drawbacks:
The TP works with translations "post-release". This means: if nano 1.2.3 is released and it contains 3 new strings, the POT will be sent to the TP after the release, and the translators will feed translations with the 3 new strings added, but these changes will be included in 1.2.4. In short, the TP, many times, works one step behind the upstream releases.
Of course, this can be easily solved sending a 1.2.3-pre1 tarball to the TP a week or so before the release, so translators can have a bit of time to update their translatiosn before the release. Not every module in the TP does that, though.
Jordi
On Mon, 2003-10-13 at 07:17, Jordi Mallach wrote:
Hi!
On Sat, Oct 11, 2003 at 10:37:29AM -0400, Barry Warsaw wrote:
Besides that Martin, do you have any other input which might help us decide whether to move Mailman into the TP or not?
Speaking as a translator with experience at the TP and as module maintainer (for mailutils and nano at the TP), I think moving to the TP is a good idea, but having in mind one of the biggest drawbacks:
The TP works with translations "post-release". This means: if nano 1.2.3 is released and it contains 3 new strings, the POT will be sent to the TP after the release, and the translators will feed translations with the 3 new strings added, but these changes will be included in 1.2.4. In short, the TP, many times, works one step behind the upstream releases.
Of course, this can be easily solved sending a 1.2.3-pre1 tarball to the TP a week or so before the release, so translators can have a bit of time to update their translatiosn before the release. Not every module in the TP does that, though.
Good to know! I already try to update the .po files before a point release and long before a final release. I can definitely keep up this tradition.
-Barry
participants (6)
-
"Martin v. Löwis" -
Barry Warsaw -
Bartosz Sawicki -
Jordi Mallach -
Simone Piunno -
Tokio Kikuchi