Facilitating Translation - The Translator's Point of View

Facilitated by Tomasz Finc and Ariel Glenn from the Wikimedia Foundation

If you are a translator, what do you want programmers and providers of content for translation to know?

If you are a developer or a content provider, what are your blind spots that make a translator's life more difficult?

We invite people involved in localization from any of these perspectives to come and share their experiences. We'll talk briefly about some of the challenges we face at Wikimedia (264 Wikipedias, each in their own language, edited without central coordination); the rest of the discussion will be up to you!

Facilitating Translation - The Translator's Point of View/Facilitators' notes

The translation process from the translator's point of view

Who we are:

Tomasz, Ariel from the Wikimedia Foundation, the coordinating team for Wikipedia and the various other wiki* projects, we're both relatively new on the job there, developers from a team of about 7 tech folks.

What this seminar is about:

There was a conference about translation last year, run by Aspiration, meant to bring together developers and those providing content for translation. The missing element: only a few translators in attendence. (Shameless plug, they are working on one for next year to be held overseas in the summer probably, which *will* be targetted to getting translators in attendence.)

We want to know:

• If you are a translator, what would you want developers and content providers to know? What tools do you want? What's broken about the process?
• If you're a developer or content provider listening to this list of needs, what tools do we have to meet those needs? What workflow changes do we need, what solutions have you found?

Some challenges particular to us at Wikimedia:

• We have Wikipedia alone in 246 languages, (plus many other projects). So we have to be very very multilingual.
• Translations are by and large done "the wiki way" which means, by volunteers, without central coordination, without formal review mechanisms, changes to many things go live immediately.
• Since the work is done in the context of the MediaWiki software framework, we have home grown code for facilitating translations, and there are three different methods for getting translations in, none of which use any existing toolset or libraries that are out there.

Basic Lessons (for developers/content providers)

A few of the most basic things we have learned:

• Once the text has been translated, don't touch it unless you know the language. Well. (A single replacement of a project name, Wikipedia to Wikimedia, can mean that all of your text is grammatically wrong!)
• Show the text to be translated, in the context in which it will be displayed, so that translators see how it is used and (even better!) know exactly what is meant. (Translating isolated text strings correctly can be impossible without this: is that string "other" really a modifer for this noun phrase displayed earlier on the page? Oops, that means our initial translation was wrong.)
• Reuse as much as possible. Translation is hard work, and most folks doing it for these projects aren't doing it because they find every minute to be a pleasure. In a world where translator-hours are scarce compared to the amount of content, translating the same or similar text from scratch is a waste of resources (and a disincentive to translators).

What tools can we use, what changes in workflow can we implement in order to make sure we follow these rules? Are these even good rules, basic rules, or are there other things we should be doing in addition/instead/first?

Other things we could bring up but won't unless we are asked

• Have a mechanism for review of translations. Even expert/professional translators can make mistakes; in an all-volunteer setting with no vetting, incomprehensible or plain misleading translations can easily creep in, which has an effect on how your project is viewed as well as making your project hard for users to use.