Friday, December 10, 2010

PL2: It's good to be resourceful

Another aspect of software internationalization that pseudo-localization can test is whether all relevant resources have been made localizable.

Now, I understand that in order for this test to work, everything that is shown to the user must be visually inspected. This means the entire fixed user interface must be made to display, including windows that come up when various menu options are selected, pop-up windows, help messages, alternate text, user messages, and, that most difficult of entities to bring to view, error messages.

It's funny, when I tell people pseudo-localization can test 9 aspects of internationalization (actually I started with 5 and found more as time went on), this is the test they claim is not valid. And yet, at the same time, this aspect is the primary one that people claim they are testing when they pseudo-localize their product. Go figure. Personally I'm not confident that you can verify the entire user interface has been properly externalized this way, only a good portion of it, and therefore likely all of it. The key word is likely.

So run your pseudo-localization tool, bring up the product (hopefully it picks up the pseudo-localized resources - see the previous post), and have a good look. Try to create some errors so you can at least check that some error messages are being picked up correctly. In case you're wondering, you're checking for text that is still in the source language, without the additional characters or character transformations that the pseudo-l10n creates.

And then, move on to the next test.

PL1: A loose l10n is an easy pick-up

The first in my series of the 9 coding areas pseudo-localization can test.
Note: localization is often abbreviated l10n, because there are 10 letters between the l and the n. Sometimes people will capitalize the L to distinguish it from the 1. (PL1 is Pseudo-Localization 1, not Programming Language 1, for those of you old enough to remember that.)

Providing the pseudo-l10n is configured as a real localization will be, it tests whether or not the product will pick up the translated resources.

Once you run your resource files through a pseudo-translator tool, set them up as being for some locale other than the source locale. For example, if your code is typically written in the US and run on environments set to the en-US language/locale, then treat your pseudo-localized files as if they were the Japanese translation for Japan, that is, ja-JP. That typically means appending "ja-JP" to the file names, but may mean they should be stored in a ja-JP directory or database. This exercise also provides familiarity with the localization structure of the product - where the resources reside and what the naming conventions are.

Next, continuing with the example, the environment needs to look like a typical Japanese customer's. Whether that means the system settings are set to ja-JP, or the software itself is set to Japanese, or just the session, make it so. Maybe any of those settings are supposed to make your software switch to Japanese - all environments should then be tested. A side benefit of this is learning how other language/locale environments are set, and how the product is supposed to behave (yes, many folks don't know what the expected behavior should be in some cases).

Now, run your software. Is it picking up the pseudo-Japanese files in all areas of the product? Is it displaying date, numeric, and other dynamically determined formats according to the Japanese locale preferences? Did it do this without requiring a rebuild?

If not, you've got some work to do.