[Mailman-i18n] [Mailman-Developers] translation of mail templates

Clytie Siddall clytie at riverland.net.au
Mon Aug 27 10:07:37 CEST 2012


G'day all :)

On 22/08/2012, at 9:17 AM, Barry Warsaw <barry at 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


More information about the Mailman-i18n mailing list