G'day all :)

On 22/08/2012, at 9:17 AM, Barry Warsaw <[email protected]> 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
_______________________________________________
Mailman-Developers mailing list
[email protected]
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Reply via email to