[sldev] Handling open source translations

Felix Duesenburg kfa at gmx.net
Mon Apr 7 15:07:23 PDT 2008

Soft 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:
> * 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?

There isn't really an alternative to peer review by persons with the 
relevant knowledge, in that case Latvian speaking SL users. Machine 
translation is not suitable to deal with adages and such. It gets worse 
with languages that often use a lot more metaphoric expressions than 
most European ones, e.g. Arabic. You have no chance of handling that 
in-house unless you have speakers of that language among your staff and 
can dedicate their time to the task.

> * 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.

Gee, right! I didn't even think of that. Shivering at the thought that a 
virus could do that as well, just rewrite the XML files. In light of 
this, I have to pick up a thought that I had just days ago when I got 
started poking at the SL source: Is there a good reason that all the 
floaters and widgets get loaded only at runtime from XML rather than 
being hard coded into the application? These things are not dynamic and 
change only during development. It should increase performance if we 
didn't have to do that, at the expense of only a slightly bigger binary. 
Look at how Trolltech's Qt toolkit works - it handles UI definitions in 
XML files, but then takes them into the code by a specially designed 
preprocessor. If we did that, it should also be much harder to 
manipulate the SL viewer. It could be automatically compiled into one 
binary per language and this way totally eliminate the need for external 
text resources.

> * 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?

Been in a similar situation before, not for an open source but for a 
commercial project. Translation of the user interface turned out to be 
quite an effort, we tried to be cheap and it didn't work. If your 
business depends on it, you ultimately get what you pay for. In the 
context of SL, I'd reply with the question first, is it really that 
urgent? To whip up volunteers, a little bit of active lobbying might be 
in order. There are SL groups dedicated to most countries and languages, 
maybe they'd be happy to hear from a Linden?

> 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?

I would suggest, create a JIRA per language pack offered, and invite 
people to proofread it. If found ok, they should cast a vote (since it's 
not anonymous, abuse should be sufficiently discouraged). If errors are 
detected, corrections are to be posted in the comments section. Accept a 
package into the official viewer when a number of votes is reached that 
you feel comfortable with.


More information about the SLDev mailing list