Localization Issues

As mentioned previously, translation issues are only half the problem. Text can easily be translated and allowances made for different characters and lengths of strings. The difficulty occurs in changing the software so that it's appropriate for the foreign market.

REMINDER

Remember those terms from Chapter 3, "The Realitites of Software Testing": precision, accuracy, and reliability and quality?

Well translated and tested software is precise and reliable, but, if the programmers don't consider localization issues, it's probably not accurate or of high quality. It might look and feel great, read perfectly, and never crash, but to someone from another locale, it might just seem plainold wrong. Assuring that the product is correctly localized gets you to this next step.

Content

What would you think of a new software encyclopedia for the U.S. English market if it had the content shown in Figure 10.4?

Figure 10.4. These content samples would seem strange in an American English encyclopedia.

In the United States, a soccer ball isn't the same thing as a football! You don't drive on the left! These may not seem right to you, but in other countries they would be perfectly accurate. If you're testing a product that will be localized, you need to carefully examine the content to make sure it's appropriate to the area where it will be used.

Content is all the other "stuff" besides the code that goes into the product (see Chapter 2, "The Software Development Process"). The following list shows various types of content that you should carefully review for localization issues. Don't consider it a complete list; there can be many more examples depending on the product. Think about what other items in your software might be problematic if it was sent to another country.

Sample documents	Icons
Pictures	Sounds
Video	Help files
Maps with disputed boundaries	Marketing material
Packaging	Web links

A NOSE TOO LONG

In 1993, Microsoft released two products for kids called Creative Writer and Fine Artist. These products used a helper character named McZee to guide the kids through the software. A great deal of research went into the design of McZee to select his look, color, mannerisms, personality, and so on. He turned out to be a rather strange looking fellow with buck teeth, dark purple skin, and a big nose.

Unfortunately, after a great deal of work was done drawing the animations that would appear on the screen, a call came in from one of Microsoft's foreign offices. They had received a preliminary version of the software and after reviewing it said that it was unacceptable. The reason: McZee's nose was too long. In their culture, people with large noses weren't common and, right or wrong, they associated having a large nose with lots of negative stereotypes. They said that the product wouldn't sell if it was localized for their locale.

It would have been way too costly to create two different McZees, one for each market, so the artwork completely to that point was thrown out, and McZee had his first nose job.

The bottom line is that the content that goes with the software, whether it's text, graphics, sounds, or whatever, is especially prone to having localization issues. Test the content with an eye for these types of problems and, if you're not experienced with the culture of the locale that the software is destined for, be sure to call in someone who is.

Data Formats

Different locales use different formats for data units such as currency, time, and measurement. Just as with content, these are localization, not translation, issues. An American English publishing program that works with inches couldn't simply undergo a text translation to use centimeters. It would require code changes to alter the underlying formulas, gridlines, and so on.

Table 10.1 shows many of the different categories of units that you'll need to become familiar with if you're testing localized software.

Table 10.1. Data Format Considerations for Localized Software

Unit	Considerations
Measurements	Metric or English: meters vs. yards
Numbers	Comma, decimal, or space separators; how negatives are shown; # symbol for number; 1.200,00 vs. 1200.00 or 100 vs. (100)
Currency	Different symbols and where they're placed: 30? vs. ?30
Dates	Order of month, day, year; separators; leading zeros; long and short formats: dd/mm/yy vs. mm/dd/yy or May 5, 2005 vs. 15 de mayo 2005
Times	12-hour or 24-hour, separators 3:30pm vs. 15:30
Calendars	Different calendars and starting days: In some countries Sunday is not the first day of the week
Addresses	Order of lines; postal code used: 98072 vs. T2N 0E6
Telephone numbers	Parenthesis or dash separators: [phone] vs. 425-555-1212 vs. 425.555.1212
Paper sizes	Different paper and envelope sizes: US Letter vs. A4

Fortunately, most operating systems designed for use in multiple locales support these different units and their formats. Figure 10.5 shows an example from Windows. Having this built-in support makes it easier, but by no means foolproof, for programmers to write localized software.

Figure 10.5. The Windows Regional Settings options allow a user to select how numbers, currency, times, and dates will be displayed.

NOTE

How a unit is displayed isn't necessarily how it's treated internally by the software. For example, the Date tab on the Regional Settings program shows a short date style of m/d/yy. That doesn't imply that the operating system handles only a 2-digit year (and hence is a Y2K bug). In this case, the setting means only a 2-digit year is displayed. The operating system still supports a 4-digit year for computationsmore things to consider when testing.

If you're testing localized software, you'll need to become very familiar with the units of measure used by the target locale. To properly test the software, you'll need to create different equivalence partitions of test data from the ones you create for testing the original version of the software.