[sldev] Handling open source translations
kfa at gmx.net
Mon Apr 7 15:07:23 PDT 2008
> 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
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
> * 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