On Jan 18, 2012, at 05:29 AM, Jeremy Baron wrote:

However, given you seem to be unhappy with your current status quo for i18n on the v2 branch and v3 is (how far away from release? from beta? I have no idea) I thought you might be interested in hearing about a solution that could work with your current gettext files and other templates: https://translatewiki.net

Jeremy and I chatted on IRC a bit. I'll leave it to Mark to comment, but I think the status quo works reasonably well for mm2, where the changes and updates are fairly rare. For mm3 though, I definitely want something better. I had considered Launchpad translations, since the project is hosted there, but the last time I check, they had some strict requirements for file system layout of the project's branch that didn't work so well for us. So I think LP is not a great option (if it were the only one, then I might consider adopting its requirements, though I'd rather not).

gettext is supported but I'm still inquiring about your templates folder. (e.g. [1] vs. [2]). It could be that this requires some additional PHP development, but it's rarely more than a day of work[3].

The templates are always the big PITA here. It's more critical for the web-ui project, but if we had a good templating language that supported i18n, and were lightweight enough for the core (which has no web-ui), then it might be okay to switch. Otherwise, for the few text templates used by the core, I think we'll need to just wedge them into the normal gettext catalog framework.

You can host it yourself or you can use the hosted copy at translatewiki.net. If you use the hosted copy then you can take advantage of the existing community of experienced translators for many languages who are then able to seamlessly work on mailman strings in the same site they're familiar with from translating other projects like MediaWiki, OpenStreetMap, StatusNet, etc. As one translatewiki.net user just mentioned, "the biggest advantage of having localisations done at translatewiki is its community".

Mailman being a GNU project imposes some additional requirements on us. First, the software used to do the translations must be free software. My understanding in talking with Jeremy is that translatewiki, being based on mediawiki, is free software. We'd want to get some approval from the FSF for this though, to avoid the headaches we've had with using Confluence as our wiki engine. Second, we have to ensure that anybody who contributes translations has signed the appropriate paperwork with the FSF, either copyright assignments or disclaimers. Again, I would follow their lead here. Launchpad translations handles this by requiring membership in a "gnu translators" team. Once you've signed the right papers, you can be added to this team, and then you can translate for any GNU project on Launchpad. I don't know if translatewiki supports team membership and permissions that would allow for a similar arrangement, but something that guarantees only assigned translations are added to the Mailman project is a basic requirement. In further talking with Jeremy, it sounds like translatewiki pulls from our trunk branch periodically and requires pushing to the trunk branch to update translations. I'd much rather have translatewiki push to its own branch (i.e. not have write permissions to trunk), and then periodically submit merge proposals which one of the core devs could then manually merge to trunk. This should all be doable with the Launchpad API.

Looking forward to your opinions. We're a heavy user of mailman at Wikimedia, and we care a lot about language support. We have Wikipedias in ~280 languages and Wikimedia has mailman lists in at least ~67 languages.[4]

Excllent! GNU Mailman innovated many of the i18n facilities in Python, and I'm still proud of our language support. It's critical we maintain this for mm3. Cheers, -Barry