Revision 1 as of 2006-04-20 22:48:24

Clear message

Managing Translations

Until now, translations have been managed in a bit of a haphazard way, with me Barry often as the bottleneck. Sometimes people email diffs or tarballs, sometimes they post patches on the SourceForge trackers, and some translators have write access to the source repository. There are other problems with the current structure of i18n management, and I would like to improve the situation. This page attempts first to collect requirements, options, and discussions about how to better management translations, both for the core software developers and for the translators.

What I do not want to do is dictate a particular solution. As the lead developer, I need certain things, but I am not a translator (I'm a typical monolinguistic American, despite years of high school Spanish :)). I want to choose a solution that makes translators lives easier, while still meeting a certain minimum of requirements on the software development side.

Software development requirements

Here, in no particular order are my requirements:

  • More separation between the software development schedule and the translation schedule. By this I mean, I would like a system whereby I can upload new mailman.pot files whenever we have a bunch of new strings in the code. Then I would like to be able to push a button just before a new release to get all the latest translated mailman.po files.

  • One clearly documented mechanism for providing new languages and updates. Let's figure out what we're going to do and then get everyone on the same page.

  • Translations independent of Mailman version. I want to be able to have a single mailman.po file that contains the union of all strings from say, Mailman 2.1 and 2.2, so that translators can just work on texts without regard to which version it will go in. This will make it easier for me to integrate updates into whatever version is getting released next.

  • Management of legal issues. Mailman is GPL'd software with copyrights owned by the FSF. As such, we need certain legal issues to be addressed by anyone who wants to donate translations. Maybe you will need to sign a copyright assignment or disclaimer. I would like some external process to manage this so I don't have to. E.g. Rosetta has a GNU Translators Team which requires the proper paperwork before donations can be accepted. This ensures that projects availing themselves of such translations don't have to worry about getting the paperwork signed before they can accept the translation.

  • One contact person per language. While I sincerely hope to encourage lots of participation (and plan on acknowledging all those who contribute, if possible), I would like one leader, or champion to whom I can go to for questions, issues, or problems. I often get patches or bug reports sent to me directly from users, and often there's little I can do about it, because I do not speak the language. I would like to have one person per language who will lead the effort.

  • More community involvement. Rather that have just people who are interested in Mailman, I would love to tap into the large resource of people who are translating open source in general. I think we can get more languages supported if we broaden our horizons.

Note that one other thing I would really like is an overall Translation Czar. This would be one person who would help coordinate all the individual languages, be Mailman's official interface to whatever translation organization we choose, help recruit new translators and languages, and help to socialize the policies and mechanisms we will use to translate Mailman. Are you that person? Email me.

Translators requirements

Here's where you fill in your thoughts. I'm not a translator so I don't know much about what you need to be more effective.

Translation projects

Here are the list of open source translation projects that I know about. If you know about others, please add them here. If you have experience with them and can provide pros and cons, please do so, as comments on this page.