Wiki Translation

From Ott09 Wiki
Jump to: navigation, search

Mediawiki

Localization: we have an extension called localization update which allows a push from svn to live

Translation: We don't translate. We read it, write the new article, it can be very different, it's not efficient but that's how it is You could do social conversion, cultural conversion in addition to the language conversion.

Medical information should be good because people's lives depend on it. people read wikipedia looking for medical info, they think it's gospel truth, so even though people shouldn't rely on it for serious issues they do. How do we deal with this?

The translate extension allows us to translate strings from the interface.

OmegaT for translating a specific article: you import a page, it's a translation memory-based system.

The Google translation system allows you to import a Wikipedia article, translate it, then export the translated page as a new article.

Tikiwiki

There is a drop down menu that allows you to choose which language the source page comes from (and to). It provides a bar which shows the percentage of the page currently translated. This is based on keeping track of new text as it is added to pages after translation is done.

If you have set your preferences to default of en but can read de es and el, then if the en page is not available, you will be offered a choice of one of the other pages if they exist.

How do you know which page is the source page? (When viewing two pages, one a translation of the other) Apparently new edits can be seen in a different color.

There is never a final version of a wiki text; TikiWiki provides an environment that helps balance the language text, and it gets away from the idea that there is a master language.

TikiWiki's percentage system is not perfect and if content is added in multiple languages, it may be impossible to get the numbers to 100%.

The translator wants to finish their work (get 100% done). TikiWiki is about what the reader wants to know, it's not targetting the traditional translator whic expects a completed text before translation begins.

People are using TikiWiki for sumo. They have an extension that shows how often a page is viewed in a given language. This allows translators to be smart in choosing the content they translate (choosing the more popular articles in one language for translation to another). Why not show the attempted views of a page that has not been translated into the user's requested language?

They look for missing documents by having people scraping the forum looking for the issues that get mentioned.

Other ideas

That no one owns the content, that the text isn't finished, is an interesting idea; what do readers think of this? How can a translator adapt to this framework?

If you see something out of date on a wiki, for example the name of a national park changes, you go change it. Then this essentially becomes a request for translation, although there is no automated mechanism for propogating the change to the translated pages.

There is a project associated with taking data from infoboxes (templates that provide basic information for a group of objects), Semantic MediaWiki pulls such data out and maps relationships between the data. When these templates are out of sync on the different language versions of Wikipedia, what are the consequences? How can we avoid this drift?

Go round: what do you want to get out of this session?

Wikis as tools for translations of finished source texts? A localization environment in the form of a wiki

We want localized versions of the toolkits we produce, we have a source language, we are thinking about various issues including whether to use MT.

I want to get the general picture of how translation takes place in the wiki envoronment.

I'm interested in building translation communities that would use the wiki for a central notification area.

I'm interested as a WP editor.

I want to think about using wikis for translation memories work.

I am thinking about better tools to empower translators so we can grow smaller language projects. (For example el pedia has only 40,000 articles; if we had better tools, could we have 400,000?)

Second round

We used wikis for a scratch pad, people could look at each other's translations, add corrections, use it as a diff engine (to see changes). We tell other groups to try it but they don't have the focus to keep a neat wiki and so they can't make it work for them. They may need more structure.

The localization infrastructure in MediaWiki is not great bu the Japanese localization team on our project fixed many things and did a lot of work. TikiWiki is getting there slowly as a tool our localizers like. TW's biggest problem is performance, it may sit for 10 secs while you ask it to translate a page and you don't know if it's working or hung. Second problem is getting the right diff (seeing the right set of changes of edits for an article).

TikiWiki has all the features you would ever desire, but perhaps it's feature bloat, there isn't a lot of consistency about how some features work across different areas. It's more organized and formatted than MediaWiki which is much moe loose and open.

Workflow issues: how do you manage workflow in a wiki-based translation system?

TikiWiki has a process for review and approval; the Italian community for example has one person who signs off before changes are pushed live.

For medium sized content strong ownership and good peers is doable.

You could set up your translator community to be peered, with different levels of trust. The EU does this; they have lots of in session documentation that needs to be translated within hours. So they use MT for the first round, 1500 translators on call who get an email telling them they have 30-60 minutes to check for factual errors. For different domains they have different lists of experts.

The Open Source commuity hasn't really worked into workflow as an important aspect of the translation process. SDL, Trados etc have workflow mechanism but we haven't incorporated similar things into our tools.

Not every workflow fits every person. If people want to deal with workflow issues over skype (for example) then they will, you can't really enforce a particular mechanism. We have had folks meet in groups of 20 to talk about how they work, so they can figure out how best to work together.