[Mailman-i18n] i18n tools/infrastructure/community for mailman

[Barry Warsaw]

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