Your multilingual software can drive your business into new markets.
Software localization can be a daunting task. Software globalization testing detects potential problems in application code or design before you begin localization. (Read our top-10 tips on software localization.)
If done correctly, testing can ease the localization process enormously — saving you time and money in the long run.
Here is our top-10 list of tips to keep in mind to help you avoid some common globalization testing pitfalls when gearing up to take your software multilingual:
- Develop a comprehensive internationalization test plan. When applications arrive at the localization stage, often basic, important areas are not tested and fixed beforehand. These include: date/time/number formatting, file/folder accessibility, data input/output, multi-byte support and text searching/parsing.
- Conduct a locale awareness test. Create or extract areas in test plans that involve input or display of numbers, date/time, weights and measures, calendar, currency, names and titles, telephone number, addresses and postal codes. All of these should change automatically based on locale selected.
- Test for file paths with a variety of Latin characters. All of these test plans should include folders and files with a variety of Latin characters (e.g., French, German and Czech diacritics) and non-Latin characters such as Japanese kana or Cyrillic. Installer paths should also be tested with non-default, non-ASCII characters.
- Use keyboard input of non-ASCII characters. Don’t rely on “cut and paste” methods to conduct language tests. Direct keyboard input might not work in certain fields, especially for “dead” key combinations (for diacritics) and when using input method editors (for East Asian character languages).
- Use a “fake” language. 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 can reveal a number of potentially critical localization issues early in the test cycle before they get replicated across every language.
- Smoke testing. It’s best to run a smoke test of your “pseudo-localized” build on a corresponding OS test machine early on. This can bring critical “blocking” or “showstopper” bugs to light before proceeding with other globalization tests.
- GUI testing of priority languages. Do a thorough visual pass of all dialogs, dropdowns, list controls, buttons, menus and more. Look for string rendering issues, aesthetic issues, and “hardcoded” strings.
- Set up the right testing systems. It’s best to test on the target market, fully localized operating system. Consider setting up a virtual lab (e.g., using VMware, Sun Virtual Box, Microsoft Hyper-V, etc) to maintain all the locale-specific language configurations of your application and OS. In most cases, virtualization is an efficient way to manage your multilingual test environments.
- Third-Party Software. Don’t forget native language versions of third-party software such as Flash or Firefox for Japanese, especially if the application is dependent on these technologies.
- Add time for post-translation testing to any release schedule. Even though you may resolve many issues through globalization testing before localization, always plan time and budget for at least one test cycle after translation to resolve linguistic issues and bugs from development changes during the localization cycle.
Globalization testing can be the key to successfully localizing your software and driving your business into new language markets. Arm yourself with a localization partner that knows how to navigate the cultural and technological challenges of taking your project multilingual. Find out more about our software globalization testing services.