Best practices for internationalizing web applications?

Question

Internationalizing web apps always seems to be a chore. No matter how much you plan ahead for pluggable languages, there\'s always issues with encoding, funky phrasing that doe

Answer 1

Internationalization is hard, here's a few things I've learned from working with 2 websites that were in over 20 different languages:

• Use UTF-8 everywhere. No exceptions. HTML, server-side language (watch out for PHP especially), database, etc.
• No text in images unless you want a ton of work. Use CSS to put text over images if necessary.
• Separate configuration from localization. That way localizers can translate the text and you can deal with different configurations per locale (features, layout, etc). You don't want localizers to have the ability to mess with your app.
• Make sure your layouts can deal with text that is 2-3 times longer than English. And also 50% less than English (Japanese and Chinese are often shorter).
• Some languages need larger font sizes (Japanese, Chinese)
• Colors are locale-specific also. Red and green don't mean the same thing everywhere!
• Add a classname that is the locale name to the body tag of your documents. That way you can specify a specific locale's layout in your CSS file easily.
• Watch out for variable substitution. Don't split your strings. Leave them whole like this: "You have X new messages" and replace the 'X' with the #.
• Different languages have different pluralization. 0, 1, 2-4, 5-7, 7-infinity. Hard to deal with.
• Context is difficult. Sometimes localizers need to know where/how a string is used to make sure it's translated correctly.

Resources:

• http://interglacial.com/~sburke/tpj/as_html/tpj13.html
• http://www.ryandoherty.net/2008/05/26/quick-tips-for-localizing-web-apps/
• http://ed.agadak.net/2007/12/one-potato-two-potato-three-potato-four

Answer 2

As an English person living abroad I have become frustrated by many web application's approach to internationalization and have blogged about my frustrations.

My tips would be:

• think about how you show an international version of a page
• using geolocation might work for many users, but as my examples show for many it will not
• why not use the Accept-Language header for determining which language to serve
• if a user accesses a page via a search engine then don't redirect them somewhere else e.g. to a homepage in a different language
• it's extremely annoying to change language and have a different page reload - either serve the same page or warn the user that the current content is not available in a different language before redirecting them
• English is a very common language, so perhaps default to that
• But make sure the change language option is clear on the GUI (I like what Google Maps are doing, as shown in the post)

All I see on the Web is companies getting internalization wrong. Getting it right from a user's perspective is tricky indeed.

Answer 3

In my company all our strings are stored in *.properties files. Our build tools build a "test languange" copy of the properties files, which replace a string like this:

Click here

with something like this:

[~~ Çļïčк н∑ѓё ~~ ﾀｳ ~~]

Now, when we set the language to "test" in our config files, these properties files are used. (And of course we don't ship the test language files).

This allows us to:

1. Make sure that Unicode characters are displayed correctly, including Japanese/Chinese/Korean.
2. Make sure that the layout scales appropriately for languages with longer words (German in particular has longer words on average than English).
3. Spot any hard-coded strings (as they will be in plain-English).

As for the actual translation, this is done by professional translators, not developers.

Answer 4

I have a couple apps that are "bilingual" I used resource files in ASP.NET1.1

There is also something called the String Resource Tool Basically you put all your strings in a .RES file for both languages and then determine what file to read from based on Culture or whether someone clicked a Link for the language

The biggest gotcha is making sure the Translations are done correctly