Contents 1 Automagic Site Translation 1.1 Owner 1.2 Summary 1.2.1 Example 1.3 Use Case/User Story/Scenario 1.3.1 User story 1: User choosing site translations 1.3.2 User story 2: Webmaster enabling site translations 1.4 Description and Constraints 1.5 Extra Credit 1.6 Design Ideas 1.7 Similar projects and Resources 1.8 What next and Sustainability 1.9 Current State and Solutions

[edit] Automagic Site Translation

[edit] Owner

Proposed by: google.org

Contact (name, email, phone, skype): Pablo Mayrgundter <pmy@google.com>, Steve Hakusa <shakusa@google.com>

Best way and times to contact during RHoK 2.0 Dec 4/5 2010: email

[edit] Summary

Enable quick and dirty translation support for arbitrary websites with minimal changes/dependencies on the site templating system.

[edit] Example

Person Finder internationalization for Haitian Kreyol. PF developers mostly didn't speak Haitian Kreyol but many users of the application did.

[edit] Use Case/User Story/Scenario

[edit] User story 1: User choosing site translations

Joe user should see a pull-down in page headers to choose their language once, and then all pages on the site are automagically translated into Joe's language.

[edit] User story 2: Webmaster enabling site translations

A webmaster should be able to copy-paste a JavaScript API into their page headers and push this change as a new site version.

[edit] Description and Constraints

There are many existing systems for supporting i18n of message catalogues within site templating systems. However, there is no standard site templating system and even if there were, translations are often needed for a target language which may not be spoken or easy to support by the site maintainers.

The user community probably has a mix of language capabilities that can bootstrap support for their local language by collaboratively editing the site with translations for site messages.

Spam/political abuse should be expected and guarded against.

[edit] Extra Credit

Feedback translations to translations service to help create or improve the machine translation model for that language.

[edit] Design Ideas

Under the hood, the page’s DOM text nodes are batched up and sent to a translation service, e.g. Google Translate, and then replaced with the translation. A cookie is set to trigger for all pages. Since translations may be poor, an edit functionality is added to translated text to allow users to suggest improvements, that are then moderated and reflected back out to user community.

To prevent simple abuse of the open editing, community moderation could be optionally supported to vote on translation correctness, e.g. with the Google Moderator approach:

 http://www.google.com/support/moderator/bin/topic.py?topic=28744

[edit] Similar projects and Resources

Code: http://code.google.com/p/datawiki/source/browse/trunk/js/Translate.js

Other translation resources:

• http://crowdin.net/
• http://translate.sourceforge.net/wiki/pootle/index
• http://translations.launchpad.net
• http://translate.google.com/toolkit

[edit] What next and Sustainability

[edit] Current State and Solutions

The translation functionality in DataWiki is ongoing and could be spun out into a dedicated library or standardized with other approaches.

If using the DataWiki translate component, two improvements are needed:

• Incremental updates to keep under rate-limiting from translate.
• Alternatively, a proxy servlet in the app which can handle interaction with the translation service and store results locally, potentially inserting them into the local templates on the original response.
• A web serivce like wikitrans.appspot.com for users of the library who cannot install such a proxy servlet.