Re: [Mailman-i18n] [Mailman-Developers] translation of mail templates
On Aug 21, 2012, at 01:04 PM, Stephen J. Turnbull wrote:
Patrick Ben Koetter writes:
They have free accounts for open source projects. It might be a nice way to organize a translation community.
It's likely that we don't have to organize one, we already have one. Barry, why don't you try to get in touch with that Vietnamese lady and see what she thinks?
Right, that would be Clytie, CC'd here. However, it's been a while since we've heard from her.
There are also active translation communities at Debian and Launchpad, and I would assume at Red Hat/Fedora. Both Deb and Ubuntu are happy Mailman users, and I would guess Red Hat/Fedora, too. All probably would find some of the MM3 features very attractive for their own use.
Definitely, and I've looked at all of the various translation services, mostly from the point of view of a project manager non-translator. E.g. how would I push updates into the service, how would I pull updates from the service, etc. I think I have a fairly good sense of what will work and what will cause headaches. I think I've posted to mailman-i18n@ before about my thoughts there. I'm CC'ing that list here too. But in some sense, it's more important for the translators to feel comfortable and welcome in whatever system we chose. Most are non-technical, so I think it's easier for us to make project workflow conform to a great translation system's quirks (and there *will* be quirks ;) than for them to work around pain in a translation system that easily integrates with our workflow. One question I have, and Steve, you're probably a great person to weigh in on this: what requirements does the GPLv3+ and being a GNU project place on us? Cheers, -Barry
G'day all :) On 22/08/2012, at 9:17 AM, Barry Warsaw <barry@list.org> wrote:
On Aug 21, 2012, at 01:04 PM, Stephen J. Turnbull wrote:
Patrick Ben Koetter writes:
They have free accounts for open source projects. It might be a nice way to organize a translation community.
It's likely that we don't have to organize one, we already have one. Barry, why don't you try to get in touch with that Vietnamese lady and see what she thinks?
Right, that would be Clytie, CC'd here. However, it's been a while since we've heard from her.
Unfortunately, I've become too ill to participate usefully (I've had to unsub from or go nomail on my lists). However, I can offer an opinion on the days when I can answer CC'd or direct mail.
There are also active translation communities at Debian and Launchpad, and I would assume at Red Hat/Fedora. Both Deb and Ubuntu are happy Mailman users, and I would guess Red Hat/Fedora, too. All probably would find some of the MM3 features very attractive for their own use.
Definitely, and I've looked at all of the various translation services, mostly from the point of view of a project manager non-translator. E.g. how would I push updates into the service, how would I pull updates from the service, etc. I think I have a fairly good sense of what will work and what will cause headaches. I think I've posted to mailman-i18n@ before about my thoughts there. I'm CC'ing that list here too.
But in some sense, it's more important for the translators to feel comfortable and welcome in whatever system we chose. Most are non-technical, so I think it's easier for us to make project workflow conform to a great translation system's quirks (and there *will* be quirks ;) than for them to work around pain in a translation system that easily integrates with our workflow.
One question I have, and Steve, you're probably a great person to weigh in on this: what requirements does the GPLv3+ and being a GNU project place on us?
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. 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. 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. 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. 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. You could also look at working with the Translation Project (GNU and others) 's email robot input-and-error-notification process. 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. Think about it. from Clytie Clytie Siddall Renmark, in the Riverland of South Australia
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
participants (3)
-
Barry Warsaw -
Clytie Siddall -
Federico Leva (Nemo)