SilkTest Automation

Localization Testing

My current job has an application that is available in four languages. A previous employer had applications that were available in even more languages. We have created an easy method of dealing with localized interfaces.

Basically, the various text strings used in the program are stored in an INI file. I use the IniFileGetValue and IniFileSetValue calls to move these strings to and from the INI file.

To start with, record all your window definitions with ID numbers, text, and index numbers enabled. Then edit that window definition to remove most text. I keep the window tag text (i.e., from the title bar) and augment it with the tags for the other supported languages. The window tag is the only location that keeps the text - all other control declarations use the index (# tag) or ID number ($ tag). You'll need to record the window declaration in each language to assemble all of the tags.

All other tags come from the INI file. I started this process by writing a routine (which I call ValidateUIString), which is passed a "key" and a language identifier, and returns a text string. The key is a text value which indicates where the string in question is located. Example keys may be "BUTTONADD" for the Add button, or "MENUFILE" for the File menu. The language identifiers are EN, SP, DE, and FR, which are the identifiers Windows uses for the different languages. These map to English, Spanish, German (Deutsch) and French. We have a routine that can (by opening the Help/About dialog) detect which language we are running in. We can also detect the language at the time we login to the application.

The ValidateUIString routine does two things. If there is a string matching the key and language, it returns it. If there is no matching string, it creates one in the INI file. Therefore, the first pass thru any test would store the strings in the file, while all subsequent passes compare the string against the value in the file. This offloads the actual "file creation" task to the code, which is a much better solution than forcing a human to enter all the strings. Alternately, it may be possible to write a program that grabs the strings from a resource file (i.e., software source code) and creates the INI file from that.

This routine can detect several possible errors. The obvious one is that the strings do not match - this is logged as an Error. Another possibility is that the string is not there - in this case the string is written to the file and a Warning is logged. One other possibility is that the returned string is truncated - this error happens due to a bug in SilkTest. It's routine allows me to write a long string to the file, but when reading it back, it only returns the first 256 characters. So, I make sure to check for this condition and log it as a Warning.

The next task is to write a test case, or (in my case) a sequence of test cases, that bring up all possible dialogs and check their text. What do I check? Well, all static text fields, all button text, list headers (which are often sort buttons as well), and the contents of most drop-down lists and popup lists.

When these test cases are first run, all text is added to the INI file. You'll need to run these cases on all of your supported languages to get the correct text strings. All subsequent runs will check the text against this "baseline" and inform you if anything changes.

At first glance, you might wonder just how this would help your testing. Yes, at some point, you have to trust the translators and their results. But many errors can easily be detected. One type of error happens when buttons have a typo in their captions. For instance, the button saying "Add..." may be correct in most dialogs, but you might find one where it's spelled Add with no dots after it. Since all Add buttons should say the same thing, this one is pretty easy to find and fix.

Another area where you might find errors is in the length of the strings. For instance, if any string that consists of one word in English is found to consist of multiple words in any other language, you should verify that translation.

A lot of these errors could be found just by eyeballing the INI file. For instance, if a multi-word entry in English looks like a "valid sentance", with a leading uppercase letter and an ending period, then chances are good that all other languages should also have a leading uppercase and trailing period. Of course, this can vary by language too, so it helps to have a feel for the languages you support.

This subject requires some depth, so in future entries here I'll give specifics about the construction of the INI file and how to use and maintain it. This is one of the areas where SilkTest's versatility makes it my automation tool of choice.