Upcoming Course Announcement: Last chance to register for Software Quality Assurance presented through the University of British Columbia Continuing Studies on Nov. 9th and 16th, 2001.

Visit UBC at http://www.tech.ubc.ca/softeng/curric.html for a listing of the courses in the Software Engineering Certificate.

Localization Series

Testing

This second part of the localization paper is about testing. We will cover what can be done during the code phase as well as what areas you should focus your localization test effort on in order to be the most effective in finding problems.

Translating the application's resources and testing the code in parallel with development is often a good idea. This helps to uncover code and feature design problems early in the process, when it is easier to make changes.
 
This also helps in deciding when to "freeze" the user interface and feature design. The sooner you do it, the better. Imagine that every time the user interface changes, it has to be retranslated. Changes to the UI also involve other types of documentation that have to be updated - online help and tutorials.

Keep in mind that late changes cause significant, expensive costs and delays in the release of localized products.

With the following in mind during the localization process, a lot of time can be saved in later phases:

• Bitmaps - should be free of letters and punctuation, such as quotation marks since they change from place to place.
• Localizing dialog box - several languages require more space for messages and command names than English. A simple message with 30 characters in English may "grow" 40 to 60% during translation to another language. Text can overflow menus and dialog boxes. Abbreviations to make text fit might be unacceptable.
• Text strings might overflow internal storage, overwriting code or other data. Expanding menus may grow so wide that they can't all fit all on the screen.
• Features not supported in determined language should be omitted and not turned gray permanently because this confuses the user, as they might not understand why certain commands are never available.

Where to look for problems

It is very common to find source code that isn't properly designed for localization. The most extreme cases are hard-coded strings, constants, and characters present in the code. Files containing hard-coded elements that need to be localized are often very difficult to deal with. Translators cannot effectively translate the source code files being worked on by the developers, especially if the code is continually evolving. Most translators are not programmers and might delete important details, such as closing quotes or semicolons, or translate programming keywords as well as strings that leads to developers spending extra time to fix these sorts of problems.

One typical way to solve this issue it to separate all localizable items into one or more files which makes localization much easier to manage. For a Windows-based application, for example, the simplest way to do that is using what are termed "resource" files. They are easy to edit and you don't need to recompile the source code.

Also, all localizable files, whether they contain code or user interface elements, can be placed in a single directory, so translators need access only to the directory containing the native language files and the localized files for which they are responsible.

The elements that normally require localization and should be part of the localizable files are listed below.

• Messages
• Constants
• Prompts
• Dialogs
• Sounds
• Macro languages
• Status bars
• Menus
• Toolbars

Testing

It may look simple on the surface, but testing localized products requires attention to certain details for which not all the testing groups are prepared.

Localized products have a better chance of success if testing is started early in the product cycle. A common mistake is to concentrate all testing efforts on the domestic product in order to get it shipped quickly and then move on to the localized versions. Early testing of all editions can often uncover serious defects in the core code that impact localized editions.  This planning for early testing ensures that development is paying attention to international and localization issues throughout the project rather than treating those concerns as an afterthought.

When testing localized software, consider different levels of testing.

Initially, focus on testing that the program installs and un-installs on the local operating system; that text strings fit in dialog boxes; that correct currency, time, etc., formats are followed; and that all text strings are in the appropriate language. A key component of this test process is to ensure that the "final" localized product functions as required.

More advanced functionality testing would focus on correctness of spelling, grammar, sort order, etc.  Note that this type of testing often requires a native language speaker to perform the testing, as a certain level of linguistics is required.

A combination of the two levels would be the best option.

Another issue related to testing is being aware of the impact of deciding to fix or not fix a defect that only occurs on a localized version of the product. If the English version is close to shipping, it is tempting to postpone these types of defects until after the domestic product ships. The risk here is the accumulation of too many international defects, leaving unresolved a significant number of changes that will have to be merged with the next product release.

Localization Testing Checklist

Listed below are some of the areas that require a great deal of attention when localizing software.

Cosmetic

• Text translation
• Accented characters
• Dialog boxes
• Menus
• Different screen resolutions
• Different font sizes

Internationalization

• Dates and number formats
• Wizards and templates
• Sort
• Grammar and spell checkers
• Measurement units
• Accented characters impact on functionality (such as saving filenames)
• Printing

Hardware/Software scenarios

• Application works correctly on different types of hardware, particularly on hardware that is sold in the target market
• Application works correctly on localized editions of Windows, especially on the language edition of Windows that corresponds to the language edition of the application. English language applications work properly on all localized editions of Windows
• Documents created in this language edition can be opened successfully in other language editions, and vice versa

Online Help

• Keywords and topic titles are translated
• Translation of topic titles and page titles is consistent
• All links to web pages are working correctly

Printed Documentation

• Stylistic accuracy and consistency
• Correct use of, and consistency of, verbal form (direct/indirect)
• Correct use of grammar and spelling