Automating Localization Testing


the ID of the Tools-Options OK button in Microsoft Word:


In most automation programs, it is not enough to say, "Hey, click the button ID (3), please." You have to pass the whole string as a parameter of your command, such as

WbuttonClick (_id (=132820.Options{dialog}.#3.))

The number "#3" will be the same for all languages, but the string "Options{dialog)" will not work in the localized software, as it is English text. We will have to create a whole function to capture during run-time the equivalent localized strings, and then create a string variable for the ID.

That number 132820 is the "handle," a unique number identification for the session opened in the software, and it is different each time you launch Word. But we can isolate that number easily, so we shouldn't worry a lot about it.

To summarize, using IDs will require much more programming than using ordinal positions, but sometimes we will need to use them.

c) Keyboard Events

There is one more thing we can use that will work in the US/English machines and the localized machines: keyboard events . The philosophy is more or less the same as for the ordinal positions: Within the program, clicking Tab, Arrow keys and Enter can lead to the same screens in any environment, when the objects are placed in the same positions. When we are talking about menus, it will be better to use the ord parameter. But when we talk about trees, list boxes, combo boxes, check boxes, or radio buttons, if they are not alphabetically sorted, it will be a good idea to simplify our script by writing things like:

Play "{TAB}"

Play "{DOWN}"

Play "{ENTER}"

This is especially useful if we need to click on a button or any other object we know that has the "focus." For example, you can launch a Wizard, and you know the default button is "Finish." If you type "Play "{ENTER}"," the wizard will start working, in any language.

d) Resource Files

There is finally a more professional approach to the whole picture: creating resource files for each language. The process for this approach would be as follows:

  1. We first create and record the scripts against the original software.
  2. Then we make our scripts "international" by changing all the software strings and other literals to constants, stored in a resource file.
  3. Finally, we create the proper resource files for the languages we want to test, by assigning the localized terms to the constants created in the previous steps.

Once we have done this, we can forget about ordinal positions, IDs, and keyboard events-we can simply call the constant in the proper resource file and the script will work fine.

But there are some requirements to performing this approach:

  • Using translation software is a must. If you don't have an application that can create memories and glossaries of your translations, the creation of localized resource files will take too long.
  • Usually, localization testing starts as soon as the translation files are delivered and built, or implemented in some server. If you want to create localized resource files, you will need a longer time frame between the translation and the testing phases. So you will need your management team to plan this from the very beginning of the project.
  • Even if you are using a software like Trados, which will offer you glossaries and translation memories, you need time and a lot of care when building the resource files. In most languages, the same English word can be, and will be, translated in different ways. This can break any script, so

About the author

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, is the place to go for what is happening in software development and delivery.  Join the conversation now!