Five Tips for Software Globalization Testing
Your software has had off in the usa and you need to localize it for brand spanking new language markets. However, within the rush to have the product out in your own home, you may have written your code primarily to handle U.S. market and English language requirements. If your developers took “shortcuts”, these must be found and glued before continuing to move forward. To reduce the launch-delaying bottlenecks and charges related to localizing functions and strings which are not created for other markets, it’s best to conduct software globalization testing. This detects potential problems in application code or design before starting localization. If done properly, testing can alleviate the localization process enormously – helping you save time and expense in the end.
Listed below are our top five methods for software globalization testing:
1 Develop a comprehensive internationalization test plan. When applications get through the localization stage, often basic, important areas won’t be tested and fixed beforehand. For instance ,: date/time/number formatting, file/folder accessibility, data input/output, multi-byte support and text searching/parsing.
2 Conduct a locale awareness test. Create or extract areas in test plans that entail input or display of numbers, date/time, weights and measures, calendar, currency, names and titles, numbers, addresses and postal codes. Most of these should change automatically using the locale selected. By way of example, date formatting should automatically follow each country or region’s convention. You may notice 05/12/10 in the usa, you imagine May 12, 2010. In Europe, they see December 5, 2010, during Japan they interpret this date as December 10, 2005.
3 Test for file paths with a number of characters. These test plans includes folders and files using a selection of Latin characters (e.g. French, German and Czech diacritics, for example accents, umlauts, etc.) and non-Latin characters including Japanese kana or Cyrillic. Installer paths must also be tested with non-default, non-ASCII characters.
4 Use keyboard input for non-ASCII characters. Don’t depend on “cut and paste” solutions to conduct language tests. Direct keyboard input may well not work in certain fields, especially for “dead” key combination’s (for diacritics) so when using input method editors (for East Asian character languages).
5 Make use of a “fake” language. No, this is simply not Spanglish or Franglais, but rather an entirely composed language that combines various scripts from worldwide. Called “pseudo-localization,” this modifies the translation resources to reflect accented characters, non-Latin scripts, East Asian characters, special symbols/punctuation and text expansion modifiers. This could reveal several potentially critical localization issues at the start of the test cycle prior to replicated across every language.
Related posts:
