The mobile site was for the Japanese subsidiary of a major European brand/fashion corporation. The company had changed the site from a cutesy, plastered-with-cartoon-animals design to a clean, stylish design inspired by the iPhone, and in fact designed specifically for compatibility with the iPhone. As an example, the page background was changed from white to a wood-inspired, shaded brown. The amount of text on each page was pared down considerably as well.

The company hired to evaluate the site did a focus group-style study with the target audience, and found that the subjects almost universally preferred the old, "busy" site, and found the new site 殺風景 ("drab").

Part of this dreariness may have been an attempt to appeal less to young women, who give lots of eyeballs but not much revenue, and more to older women, who might actually buy some of that overpriced stuff. But the study showed that even women in their 30s and 40s liked the old site design better, cutesy cartoon kittens and all.

On the one had, the company wants to maintain a consistent international image (one remark was that the new site design conforms the the global brand image). But I saw this as another proof that you need to design websites for your audience, not necessarily according to what looks good to you — especially when marketing in different cultures.

I recently discovered a site that makes this a lot easier: http://screenshots.modemhelp.net/. This site has screen shots for Windows and Mac operating systems, as well as popular software, all organized and labeled.

Say, for example, you need to get the names of Control Panel icons from Windows 2000, or the menu items on the context menu for the Recycle bin in Windows Vista, or the System Preferences icons for Mac OS X. Yep, it's all there.

Unfortunately, the site doesn't appear to have screen shots for Windows 7 yet, but at least those are substantially similar to Vista's.

I booked my flight to Australia online via Jetstar. Using amazing high-tech IP-geolocation techniques, Jetstar figured out that I was in Japan and decided to treat me to its Japanese-language site. Fair enough; but if you're going to foist off your localized site, you ought to make sure you get it right.

And Jetstar didn't quite. The most egregious example was their confirmation email, which started like this:

Imagining for a moment that I am Japanese (Jetstar did, so why can't you?), the use of my first name followed by the Hiragana "sama" is really out of place. As a customer, I'd expect my last name (Ginstrom) to be properly written in Japanese characters (ジンストロム), followed by the Kanji character for "sama" (様).

Although the use of the first name is fairly widespread in the English-speaking world, it's a big no-no with customer communication in Japanese.

A word about templates

The problem stems from the use of templates for emails and dynamic Web pages. I imagine that the original email template went something like this:

Where "$name" will be replaced dynamically from the database with the first name.

The site developers must have just passed off this template to be translated. The translator has no control over what gets written for the "$name" value, which the computer is going to fill in with "Ryan," or more normally, "Hanako" or "Taro." The translator, faced with a no-win situation, probably opted for the hiragana "sama" (さま) because it looks less strange with a first name in Roman characters than the Kanji "sama" (様) would.

Localization isn't (just) translation

What they needed to do was modify the template so that the last name of the customer would be entered in Kanji. This would have made it possible to create a proper Japanese-language email template. Whether Jetstar failed to do this out of ignorance or cheapness (not wanting to incur the development costs), it's still a localization fail.

Since I translate (and localize) Japanese to English, this is a problem that really strikes home with me. Here's a simple example of this problem in Japanese:

%s件のコメントを削除しました

Japanese lacks a plural marker, so this would be translated as "Deleted 1 comment" or "Deleted n comments," depending on the value assigned to the variable "%s" — the Japanese is the same for both the singular and plural cases.

There's an obvious conundrum here: we have to make a distinction in the translation that doesn't exist in the source text. How can you localize this text without changing the source code of the software (often not feasible) and teaching the developers enough English to code for these differences (even less likely to happen)?

The article's proposed solution

The authors propose a solution to this problem in the form of a rules-based system. (One example is "You have [quant,_1,piece] of new mail."). I see two big problems with this system: (1) you're hard-coding your rules into your code, and relatedly (2) you'll likely have to modify the actual code (or at least page template) every time you add a new language.

Getting all the possible rules for any language would pretty much mean writing a machine translation system, and we all know how successful they are.

This is actually a pretty common beginner's solution. You realize that simple string substitution doesn't work for translating sentences, so you think: I know, I'll add some rules. In the end, though, this never works — with every new sentence and language you'll be adding new rules. And languages tend to vary along different axes, so your rule system grows increasingly complex.

Look at Google Translate.  That's based on Systran, a rule-based system developed in the late 1960s. You can probably guess that in the 40-odd years since, they still haven't got the rules right.

If you only have a fixed number of sentences in a fixed number of languages to translate, the rules approach could work. But the problem that the authors are trying to address is arbitrarily many languages — and I'd add the probability that you'll have more text to translate later.

My solution

I propose that instead of hard-coding rules, we produce concrete translations for the exceptions. This follows a general principle of moving vectors of change out of the code whenever possible.

Then we write an "improved" gettext that first fills in the variable and sees if there's a matching translation, if not using the translation with the placement. Here's how a Python version might look:

Notice that the code is fault tolerant — if a translation isn't found, it will just return the source text. In real life, we could (and probably should) log any source text with no translations.

Our output:

Yay, it works! Here's how. We have a dictionary of 3 terms:
スパム : spam
1件のコメントを削除しました : Deleted 1 comment
%s件のコメントを削除しました : Deleted %s comments

We call gettext with msgid スパム. There are no variables, so we do a straight lookup and get "spam."

Next, we call it with msgid %s件のコメントを削除しました and a variable of 1. We fill in the string, and get 1件のコメントを削除しました.

get_translation finds the translation of 1件のコメントを削除しました , and returns the translation "Deleted 1 comment."

Next, we call it with msgid %s件のコメントを削除しました and a variable of 2. We fill in the string, and get 2件のコメントを削除しました.

get_translation doesn't find the translation of 2件のコメントを削除しました , so we look it up without the variable filled in.

get_translation finds the translation of %s件のコメントを削除しました, and returns the translation "Deleted %s comments."

We then supply the variable 2 to Deleted %s comments, and get Deleted 2 comments — Simple!

Finally, we call gettext with msgid ハム. We don't find a translation, so we just return ハム back.

Potential complication

One potential problem with this approach is a rule that would produce infinitely many "concrete" (filled-in) translations. The Russian example given in the article seems to fall into this category. Even so, however, it should be possible to give translations for up to some reasonable number — say, 10,000 directories. The localizer should be able to generate them for us automatically, and it shouldn't hurt lookup times too much or take too much disk space — as long as the number of such sentences isn't very large… At any rate, I think this still beats hard-coding exception rules for each new language.

If you are going to add some rule systems, though, I'd add a different one for each language, and add a different rule for each sentence. The localizer engine for each language could load its specific rule set along with its dictionary. The localizer engine would check for matches with rules, then go through the above sequence if no rules are found. So for Russian, I'd have a rule for the equivalent of "Deleted %s comments," and generate translations for just that sentence.

Conclusion

The beauty of this approach is that as we add localized languages, we only have to add more localized dictionaries — there's no need to change the code or our existing localized dictionaries.

Note that this example only works when you have one variable at most. And I think that as a rule of thumb, you should stick to no more than one variable per sentence.

With two or more variables, you'd have to use a dict (with **kwargs instead of *args) with named placements, since the order is likely to change. So the sentence above would be, for example, %(num_comments)s件のコメントを削除しました. Other languages do a "{1}", "{2}" type placement, which works the same way.

Edit: More explanation on why a rule-based approach isn't a good idea, and fleshed out when and how rules could be added for outliers.