Collaborative Translation: Future of Web App Translation?

Before I wrote my last post on collaborative translation, TechCrunch had covered Facebook translation.

As described in these articles, Facebook and MySpace have taken different ways to tackle localization of theirs social networking sites. Facebook are having the users translate the whole site using online tool. They have only three languages available besides English now, but that can quickly change after they open up invitation-only translation tool to more users. MySpace has been placing local offices in several countries – 23 of them so far.

I’m not just counting numbers here. It’s still early to decide which one of these method proves to be more effective since Facebook just got stared on their effort to add more languages to their site.

I want to point out though, you can’t compare these two services simply by the number of languages available. Because there’s more to localizing an application besides simply adding languages. Some of those additional tweaks include:

  • The site/service needs to integrate with more popular services in that language group (for example, more Japanese users use Hatena bookmark than del.icio.us or digg).
  • Support needs to be provided in each language.
  • FAQ and instruction pages may need rewriting or reorganization (different cultures = different way of thinking & doing things).
  • Some icons and colors have different meanings.
  • UI may need to be updated, for the same reason for #3 + the length of word or phrase can vary.
  • Best text treatment (this means CSS styles in many cases) for each language’s default font are different.

So, is collaborative translation the best possible way for all projects? Maybe not. It has advantages (cost, speed, having actual users’ input, etc.) but there’s a good chance users are not aware of these fine points. I believe this situation can be improved by bringing in a few experts to manage & control the localization process. I also think web application developers should start thinking about standardizing UI labels and messages for easier translation. For example, if one app says “post” where another says “send” meaning the same thing and so on, translators can’t make the best use of available translation memory (TM).

Using a set of UI language convention as a base for translation project will cut down required effort by volunteer/paid translators. Do you want more flexibility in labels and messages so it can be “fun” and “targeted toward XX or YY”? Well, you can easily have that as a “translated version” of the original standardized language.

Translating Web Service Online: Who does it the Best?

Lately I’ve been seeing many good examples of web services done in interactive/collaborative ways. On these sites, there is no check-out or check-in of language files. Just text fields for you to inputting translation text data.

To name a few:

So far the most successful and complete translation system of all is LibraryThing, I think.

  • Page-by-page translation as well as “untranslated” list
  • Instead of throwing the whole site’s strings into a pile, priorities are set (for example, they don’t want to have “About” section translated yet)
  • Vote system for each translated string
  • Language zeitgeist and translation page (has a honor roll too) to encourage participation
  • Untranslated text is marked with yellow background color

According to their About Translation page (which has a nice guideline for translators), their translation feature was inspired by BookMooch, Remember The Milk and Google in your Language. I’ve participated in WordPress.com, BookMooch, and LibraryThing online translation, but LibraryThing has the best overall system so far.

LibraryThing Translation for Japanese (screenshot in 2011)

I especially like the page-by-page translation. Much easier than searching for the line # of the original text and guessing what the context is. It will be even better or almost perfect if you can use a link from each available string to see which page it is used.

Having a quick vote system for something that need help from people’s common sense (“Which one sounds right?”) is a pretty good idea. It only takes a second to click “yes” or “no” — much easier than debating over who is right.

But in terms of completeness/quality of the project, Remember The Milk is the best. But it’s not quite fair to compare with others, since RTM now has a Japanese team.

I hope soon we will see non-English sites that have this kind of features too (probably there are some already, I guess I need to wait for them to get translated it into Japanese or English?).

translate.wordpress.com sums it up all together (yeah I know I’m partial):

The world is too big a place for WordPress to be English-centric.

Put your service’s name into “WordPress” – do you agree?

Multiblogs in two languages

I occasionally get email asking how I set up two blogs for my site (detlog.org and blog.detlog.org).
There are now several multiblogging solutions out there, but I still keep good ol’ “two separate installs” here.

It’s not that I have anything against those alternative multiblog hacks -I just didn’t know any other way at the time I started! I’ve never even tried those hacks to find out how they are… (I want to hear how you like those multiblog hacks!)

Another reason why I keep them this way is that my web host, DreamHost, has a nice & easy 1-click WordPress installation feature. It’s so easy that I’m spoiled now…

One downside of having two installs is I have to install all plugins twice. Although most of plugins are pretty simple and all you need to do is upload files/activate them, it could be pain if you are really into using a large number of plugins for both your blogs.

As for encording, I use UTF-8 for both English/Japanese blogs. I started out using EUC-JP but recently switched to UTF (finally…). I recommend using the same encording if possible, because it helps you manage themes/plugins with much less work.