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.
Clytie : as a translator, I really appreciate your willingness to meet us half-way. We suffer a good deal from obstacles of different kinds to translation in different projects, so facilitating the process will make for more participation and better translations.
Here, in no particular order are my requirements:
mailman.potfiles 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
Note that one other thing I would really like is an overall Translation Coordinator. 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.
Clytie: if nobody else is really keen to do it, I'm willing to give it my best. But please, if you want to do it, don't let me discourage you. Your effort is very welcome, and I have plenty of other things to do! I just want to see Mailman i18n doing as well as its code does.
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.
Clytie: above all, we need a straightforward, effective system that is as simple as possible. As soon as we start adding expectations, we start losing translators. There are a great many linguistically-talented people who don't have added computing skills. This means that something like Pootle, which takes care of all the underlying process and simply provides strings to translate, is such a powerful choice. With your own configuration, it encourages translators to use even small amounts of time to do a few strings at a time. This approach has worked extremely well for the Distributed Proofreaders project, the text-production arm of Project Gutenberg: its slogan is "Every string helps!" (or similar), and the results have been staggering. Rosetta has seen some of that compound participation, but it doesn't yet have IMHO enough configuration power to setup individual projects well, so quality and management have been a problem.
Of the non-common-interface translation projects, the TP (Translation Project) is the simplest to use. Translators, once they are registered and have logged their disclaimer, simply download files, translate them, then submit them via email. A robot program runs checks over the submitted file, and sends it back with explanations if it is not entirely correct. Developers also submit their files to this robot program. The TP is the most efficient i18n project, IMHO, and if you simply want your files translated, you couldn't do better.
However, from the simplicity point of view, the TP may be the easiest to use, but it requires that you understand PO files, and can use gettext. These things may seem very simply to people who have been using them for some time, but we want to attract more translators: I only started translating Mailman quite recently, and in that time we have had at least three new translators arrive who have no previous experience with PO format. So, if we are going to continue PO-based, we need to build in some support for newish translators. Our howto helps, but there definitely needs to be a mentoring process. The dropout rate for new translators is high in OSS: if we want to keep our new translators, we need to look after them. I'd be interested to hear from some newer translators on this: I do remember that the projects to which I have contributed most, are those which welcomed me when I started, and offered me good support.
All other i18n projects add layers of complexity on the basic PO file translation process. Some use non-standard syntax, which is a nightmare; others require specific procedures which eat up a lot of time and effort, especially when one starts a new project. Again, those projects lose a lot of translators. Only the *translation team* has really kept translators in OSS, by building a language/culture-specific support structure, usually based around one or two team-leaders and a lot of personal effort. If we provide for the lanuage-team structure, even better, communicate with existing language teams and ask them to add Mailman to their list, we plugin to an established and successul support system. However, the real work in i18n, as in the rest of OSS, is done by a surprisingly small number of people. Every new translator we can attract and keep, is a great gain. The work we put into support now, will bring lasting and possibly compound results.
Projects like Gnome, KDE, Debian and Xfce, even other individual-program projects like Psi and Gaim, all build their own procedure on top of standard PO files (the suite projects Mozilla and OpenOffice.org make life difficult by using their own format), access via SVN (Gnome is moving from CVS to SVN as soon as they can get python sorted out on their server) and a system of status pages which are IMHO their greatest achievement in i18n. Please see the KDE status pages for interface files (they also have these for documentation). If we are restructuring the Mailman i18n process, I would strongly recommend having a status page that shows progress for each language (better still, for each file for each language). These pages are useful for everyone concerned, and they're extremely motivating. You can see exactly where you are, and get almost immediate feedback on your progress, when you submit files. These pages are updated at least once daily, usually three times.
(I've sent Barry some info on the current status of the status-pages software.)
We can also learn from the TP, who ask translators to register if they want to receive auto-update emails. These emails are sent out as soon as a file is updated. This may motivate translators who don't follow mailman-i18n as closely as they should. In any event, they work to keep in touch with each translator, and avoid people "falling off" the end of the process. If you don't have time to catch up with your mailing lists (I haven't got to mine today yet!), you do check your main Inbox (where I found the mail about this page), so you'll see the update mails. I do my email updates before I do any of my other tasks, and I think other translators would also give them priority in their workflow. It's efficient.
Debian is now following this process for debconf files, and has also started sending out a status email for each level of the debian-installer. It's in diff form, currently, which I think needs to be more people-readable. I've found this very handy already.
I like the translate-a-thon idea, also building more community, more communcation (forum? Jabber, IRC), having targets and goals we establish for ourselves. We can make this a lot more fun than it currently is (again, Distributed Proofreaders are a great example).
We definitely need an integrated system for getting and submitting translation files. We need to look at each stage of our i18n process and review what works now, and what needs improving, and how we can do it. There is a lot we can do to improve it, and first of all we need to hear what translators think of the current system, and what they would suggest we do. You've certainly heard from me, here, off the top of my head.
What do you think?
Here are the list of open source translation projects that we could use to manage Mailman's i18n. 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.
It depends on whether you want to plugin your files, or run your own project. I don't know of any project that does what the TP or Pootle do, as well as they do. There are pale imitations, but that's all. I'm uncomfortable with the present lack of configuration and quality assurance on Rosetta. Pootle is state-of-the-art in that technology, and it already provides a great deal more configurable control over the project and individual translations.