Clytie Siddall, 27/08/2012 10:07:
G'day all :)
Good morning and thank you for your interesting email.
Barry, you are spot on with your statement that an effective translation workflow needs to suit the needs and backgrounds of the localizers, not the quirks of the software dev. system.
I'm only a lurker on this mailing list but this encouraged me to briefly mention my experience as translator on translatewiki.net (https://translatewiki.net/wiki/User:Nemo_bis).
The word "quirks" fits some systems quite well, the egregious example being OpenOffice.org, which has a labyrinthine and migraine-inducing endurance crawl thinly disguised as localization. When I started at OOo, there was no basic howto on how to get through this maze of requirements, so I wrote one. The need for one seemed to come as a surprise to the project hierarchy.
The thing to remember is that localizers usually don't read English with any degree of comfort. You need a simple, step-by-step description of how to get from an unlocalized package to a localized release. Diagrams (e.g. flow charts) are good. Make it a checklist, so they can check off each step.
The good thing of translatewiki.net is that there isn't any step after registration: you only translate, not waste time on process and bureaucracy as on most translation projects. Niklas explains it here for instance: https://www.youtube.com/watch?v=tqS3YSKfJqU&t=29m1s Even for registering there's a wizard https://translatewiki.net/wiki/Special:FirstSteps
Have a single login to access all the processes needed for localization. OOo required a huge number of separate logins, each with its own cumbersome procedure. I've often seen localizers shy away from reporting bugs or joining a tracker to submit translations as an issue, because it's one more thing they have to understand and do in a second language.
Translatewiki.net has a single login for all projects.
Login access should also show translation stats, both software and docs (see GNOME's platform for localization), and you should be able to submit translations there. GNOME have done a lot of work on this, so they're good people to ask.
Translate has plenty of live statistics. https://www.mediawiki.org/wiki/Help:Extension:Translate/Statistics_and_repor...
Without more info, I'm assuming from this email that you're looking at integrating Mailman with the main translation projects. In my cross-project experience, Debian i18n have the best record for innovation and quality: see Christian Perrier (CC'd). Debian does use email for submitting localizations and for notifications about them, both actions I assume would be part of your integration. Packages can also use an automatic email localization-update-request process.
I don't know what you mean exactly with "email integration" and notifications are usually not needed on translatewiki.net to get stuff translated (because translating is easier and there are more translators), anyway https://www.mediawiki.org/wiki/Extension:TranslationNotifications#Special_pa... exists and proved very effective on meta.wikimedia.org.
You could also look at working with the Translation Project (GNU and others) 's email robot input-and-error-notification process.
Again, I don't know what a "input-and-error-notification process" but translators on translatewiki.net don't usually have to care about such things (the web interface is reliable enough) and for the few failures there are automatic warnings and aids. https://www.mediawiki.org/wiki/Help:Extension:Translate#Features
When I last used it, (free-software localization interface) Pootle didn't have email integration (although it was one of the features I think I requested ;) ). I think you'd find the Pootle project quite interested in working with you. I found them innovative, flexible and focussed on improving access to localization. (CC'd to their list, in the hope that I went nomail there rather than unsubbed.)
Launchpad used to be insecure and of low quality, but that was a while back. I hear they've improved. They do integrate mailing lists associated with the localization, if supplied.
I could be quite off-base in my response, since I'm not sure from your text what you want to do. ;)
However, when considering localization projects and workflow, for those of you who speak a second language, imagine what would help _you_ if people wanted to encourage you to code for a project where all info and communication is in that second language.
And finally, the best feature of translatewiki.net is that its main developers/managers are among the most active translators to their language and this helps a lot, I found.
Federico aka Nemo