Myth #12 - More quality by the dozen

Continuing in the myth series, we address the scope of internationalization:

"My product works in Japanese, therefore it's internationalized."

Seems sort of logical doesn't it? I mean, if Japanese data gets processed and displayed correctly, surely that means the internationalization is correct? Alas, no. In fact, for a long time there was (and to some extent still is) a specialty called "Japanization". So many companies in the U.S. wanted to take advantage of the lucrative Japanese market that firms sprang up, offering this service. They would take the software and alter it to enable Japanese data processing and display on Japanese-capable machines. Sounds pretty good, huh? Except that it was expensive, time-consuming, and had to be repeated for each release. But we'll get into that myth later.

But let's say you didn't send it to a third party "Japanizer", and you really tried to do proper internationalization over the course of design and development. If you test using Japanese, then that must indicate everything is OK, right? Well, no. It's true that testing with Japanese can uncover some real internationalization problems, but not all of them. Arabic, Hindi, and French have different i18n issues from Japanese - even Chinese is different. What are these differences? These other languages often use different charsets, and in the case of Arabic and Hindi, different rendering capabilities. Beyond language, the Japan locale has its own data formats, which are not the same as France, or Brazil, or Russia, etc. And as a further area to test, Japan is within a single time zone, so you haven't tested a multiple time zone situation (a genuine problem for the U.S. with its 7 time zones).

But wait, there's more! Most customers require multilingual capabilities in their software, and that needs to be tested. For example, if you're working on server software, consider that companies will run the software on a server which is set to one language and locale (with the admin possibly using a different language for the console), but clients will be using lots of different languages and locales as they contact the server. This is a very common configuration nowadays. And it's not limited to servers. Just because someone is running the Italian localization of your email client doesn't mean that all their emails will be in Italian, or even Latin script. They may be emailing in Thai, and you need to verify that your product can handle these sorts of multilingual requirements.

For more information on testing the internationalization of software, see my article, Internationalizing Testing. And keep reading the myths!