[sldev] Handling open source translations

[Edward Cherlin]

On Mon, Apr 7, 2008 at 1:35 PM, Soft <soft at lindenlab.com> wrote:
> I'm curious - how do other projects handle volunteer-submitted
>  translations? As I understand it, these come with a few liabilities
>  that need to be resolved:

For the One Laptop Per Child approach, see

http://wiki.laptop.org/go/Localization
http://dev.laptop.org/translate

The various Free/Open Source Software projects within the
GNU/Linux/BSD community all do something similar. Everybody has some
plan for having localizations tested by members of the target user
group before general distribution.

Also, contributions are logged so that each string can be traced back
to its author. Localizers have to register and log in each time.
Anyone found to be messing with the localizations can be banned. As
with Wikipedia, there are further levels of security possible if the
problem arises. Since it rarely does, given the current safeguards,
those measures can be kept in reserve without imposing any burden on
the community when they are not needed.

I administer the Haitian Creole French (Kreyól Ayisyen) and
Khmer/Cambodia localizations for OLPC. That means that I recruit
people and help them get started, and occasionally request a new
feature or project for the Pootle localization server, not that I do
localization myself.

Historical examples of the problems you cite are well-known in the
community. I am thinking in particular of a missionary in North
America who got himself some scurrilous language informants who
thought there was nothing funnier than getting him to put the vilest
obscenities into his sermons.

>  * They could be loaded down with obscenities or rudeness. If none of
>  us speak, say, Latvian, we'd never know the harm of telling someone to
>  "go pick mushrooms" (a death threat) even if we use machine
>  translation to verify translations back to English. How do we prevent
>  that?

That happens at the UN and generally in international communication,
apparently all the time. Khrushchev's "We will bury you" is not a
threat, but a prediction that We will outlive You.

>  * They could contain misleading translations. A fraudster could have a
>  field day by reversing LSL debit permission payment accept/reject
>  buttons and singling out users in that language community. How do we
>  protect users? We can't simply say the translation is "unsupported."
>  Not only would we leave people open to harm this way, but we'd create
>  inventive for submitting these types of translations.

Recruit testing volunteers as well as a localization volunteers.

>  * Open source developers don't deliver on a schedule. We can pay for
>  1-day turn around from contractors where a language has many users.
>  But when we get to languages with only a few hundred users, it's tough
>  to make a case for commercial translation services to do the updates.
>  We can't hold back shipping while we wait for every last language to
>  be brought to parity by volunteers. How do we make contributions
>  timely, or how do we eliminate the need for timely translations?

You convince the community that the work is valuable, and is either
the most important or the most fun work they could be doing right now.
You make sure that volunteers come into the project from different
sectors of the community. At worst, you hire the professionals to
review the work rather than do it all.

>  It would be great if we were taking in the new translations that are
>  often offered. But the initial translation work is only a small
>  fraction of the overall resources that language support consumes. How
>  do we make user-submitted translations work? How do other projects
>  handle these problems?

-- 
Edward Cherlin
End Poverty at a Profit by teaching children business
http://www.EarthTreasury.org/
"The best way to predict the future is to invent it."--Alan Kay