Windows Vista Multilingual User Interface

Have you started localization testing on Vista yet? They've taken the fun out of it.

Windows 2000 was easy. The OS is relatively small, and you could even maintain multiple native systems (Win 2000 Ja, Win 2000 Ko, Win 2000 Es) on separate partitions or virtual machines. If your testing wasn't that rigorous and you just wanted the localized UI, you could slap the Multilingual User Interface (MUI) onto an English version of Windows without much headache.

XP required a bit more work, not to mention disk space, but it was still manageable, especially with drives as large as they are.

Vista feels like another order of magnitude in complexity. Actually, the process of building the testbenches is not that formidable, but the space requirements are. Just to reduce overhead, one of my clients has asked that we plan to test on MUI instead of native OSes from now on. Not the optimal vision, but we'll work with it.

MUI is not air-tight. The font and locale support is good, but it leaks English all over the place. (Apparently you can install MUI only on top of an English base OS.) It's not great for screenshots because you cannot always rely on perfectly localized UI, but it's a fair gauge of how your app will work in the target market.

There's an intimidating procedure on Microsoft's localization Technet for configuring MUI under Vista. I couldn't believe it was really this difficult - it need not be - so I poked around some more and found a different, simpler way.

1) Upgrade to Vista Ultimate or Enterprise. Vista MUI won't work with Home or even Business Editions, so plan to spend the money on the upgrade. From Windows Anytime Upgrade (WAU) you can pay US$139-159 for a license key to Vista Ultimate. If your company manages such things, you can find out whether it already has a site license for either of these.
2) Depending on the media you received with your machine, you may need to order (US$8) the WAU DVD also. The MUI files are not on it, but the files needed to upgrade the OS are.
3) After installing the upgrade, be sure to activate it.

Congratulations! You now have Windows Ultimate (and several fewer GB of disk space).

4) Go to Windows Update, which is where the language packs live. Microsoft used to make these available via MSDN - perhaps they still do - but now they're available as optional Windows updates.
5) Your upgrade to Ultimate/Enterprise may entail a few required updates. Install those first and get them out of the way, or else your request for the language pack may not take.
6) Select the language packs you need, start the download and go on vacation. The Japanese language pack is about 800MB in size, so you may do well to install one, play with it for a few days, then install others.
7) Go to the Regional and Language Options control panel. On the Keyboards and Languages tab, choose the display language. Windows requires only a logoff (not a restart) and at login you'll see something like this:

(Click image for expanded view.)

Explorer's menu is localized, but Wordpad's is not. Most of the Windows-specific titles are localized, but the date on the clock is not. It's a hodgepodge, and MUI may not meet all your needs.

Our resulting testbench comprises Vista Business, the upgrade to Ultimate, the Ja language pack and McAfee VirusScan. Call me a dinosaur, and many other people have complained about Vista's disk usage more eloquently than I can, but I'm up to 12GB (2GB of which is the hibernation file that won't go away), which strikes me as quite a bit. So, if you plan to create several localized Vista testbenches, get a fat drive.

By the way, we experimented with localized virtual machines based on Vista. Even devoting 1 of the 2 GB of physical RAM to it, the VM ran so poorly that it was just plain not worth it.

If you liked this article, you may enjoy another related article, "Localization Testbenches - Part I."

Virtual machines as localization testbenches

What are you doing for localized testbenches? Are you still partitioning hard drives or, worse yet, dedicating entire machines to one language-platform? Lab getting a bit crowded and hot, is it? Consider using virtual machines, or VMs.

Microsoft's Virtual PC 2007 is free and uncrippled, so you can create, run and administer your own VMs. It's not bad software, and you can be sure that if there are any "special" tricks a VM should know about the Windows-version hosting it, this product will know them. VMWare's product is not free, but features a VM player, so if somebody in your department has the full product and can create VMs for you, you can use them as you would a normal drive.

A VM is just a huge file (around 1GB for Windows 2000, 3GB for Windows XP, 6GB for Vista) that you mount and run as a "guest" session in its own window. It's like having a computer inside a computer, although it takes away drive space, RAM and processor cycles that the "host" system - the one your computer runs normally - used to use. You can start and stop the VMs as you need them, and you can install almost any OS or language to run as a guest inside the VM; however, you do need to procure a legal copy of that OS/language combination.

Tiring of so much ancient kit lying around the lab, we've begun to migrate to VMs. They're not a panacea, but they make things like remote testing a good deal easier, they require less hardware, and they make dual-boot configurations irrelevant. There's quite a performance hit, unfortunately, and we're finding that VMWare VMs are a bit more responsive than Microsoft's.
However, most localization testing is focused on UI and functionality rather than on performance, so this may not affect your lab unduly.

Creating one is not that difficult. Here's an example for Microsoft's Virtual PC 2007:

1. Obtain a machine with about 2GB of RAM and at least 80GB of drive space, running, say Windows XP English.
2. Download and install MS Virtual PC 2007.
3. Create a virtual machine, specifying Windows XP. For installation, give the VM 1GB of RAM; you can reduce that amount later if need be.
4. Obtain the installation disk for the desired OS (e.g., Windows XP Japanese) and place it in the drive.
5. Start the VM. As it opens in its new window, specify that you want to capture the CD drive (or the image file on the host machine, if you're mounting a .img).
6. Installation will then take place as normal, with disk checking, file copying, and all the configuration and rebooting you would expect of an installation on a physical drive.
7. A few GB later, you have a WinXP Japanese VM running as a guest on your Win XP English host. Install the Virtual Disk Additions to enable features like host-to-guest drag-and-drop.

Of note:

1. Your VMs don't inherit domain information from the host machine, so if you want the VMs on the domain for things like advertised programs and SMS pushes, you'll need to arrange that separately with the network administrator.
2. They just get bigger. There is a feature to "compact" the VMs, but the resulting file takes no less space on disk.
3. Migrating from existing physical drives into a VM is a crapshoot. Our most wildly successful experimentation has resulted in Blue Screen of Death, so don't expect to take an existing testbench and copy it into a new VM, any more than you would expect it to work going from a desktop to a laptop physical machine.
4. There's an emulation layer between the VM and the hardware, so peripherals (USB devices, dongles) may not run the same way as they do on a physical drive.
5. VMs are portable, so if you can get one to run on your desktop, you should be able to copy it to other computers and use it on them. For that matter, VMWare VMs can be hosted on servers and run remotely.

Market Requirements for Localization

What good is all the market research if your product doesn't support the locale, and if Engineering can't get it to support the locale?

As product manager, you're pleased with your product's global reach. You've successfully localized for the low-hanging fruit (other Latin-based character sets like Spanish, German, even Nordic), and your product and Web site makes customers happy all over the Western world. You have established robust processes for:

• researching the needs of each foreign market
• making those needs an integral part of the product requirements
• working with Engineering on timetables for support of the needs
• working with QA to ensure the engineering work can be adequately tested
• releasing in foreign markets and enjoying success in them

Now talk turns to Asian markets, and multibyte enabling of your product and Web presence. You meet with Engineering and, as they've done for the European languages, they assure you that their code is, or will be, clean, and that you'll replicate in Asia the success you've had in Europe. Everybody nods, and it's just like Euro-success again.

But what if it isn't?

As product manager, you want to do your usual, excellent job of identifying market requirements and writing up the intelligence so that Engineering knows what the product needs to support. You'd better scratch a little harder, though.

1. How is Engineering going to validate the product for multibyte? Peer review of code? Bring in an internationalization engineer? Pseudo-translation? You can't just take their word for it; you have too much at stake.
   
2. Can your Web team create a staging environment and test cases close enough to what the production environment will be like?
   
3. Has QA done a good job in flushing out bugs in your other localized products? Look back at the bug reports from German or Finnish; did they really find many problems? Did they all get fixed? Do you know for sure that they're testing under production-caliber conditions and on production-caliber testbenches?
   
4. Do you really need to launch in Japanese, Korean and two versions of Chinese at the same time? Can you adopt a phased approach? Which market can give you the best support as you're enabling your product? (Hint: It's often Japan.)
   

This is the localization-equivalent of getting your ducks in a row. After you've done all the work of finding out what the market requires, you'd better be sure that the product you want to sell them really will perform as you claim.

Engineering, this is not business as usual. This is Asia.

Localization Testbenches, Part III (Web sites)

What are you using to test your localized products? If you're handing them to your domestic QA team and expecting that they'll intuitively test them with correct language locale settings, you may be in for an unpleasant surprise.

2) Web sites
Performing QA on localized Web sites requires less overhead. Most browsers nowadays accommodate multi-byte characters automatically and without installing language packs. So, if you send e-mail pointing your executive staff to your newly unveiled Chinese site, you can be sure that most of them will see a page free of corrupted characters.

Dumb HTML pages, however, are not where the biggest problems lie. You need to ensure that your forms, auto-responders, search pages, search result pages, search indexing and databases all support the target languages.

This can in fact be more complex than localizing software; while localizing software requires plugging a lot of holes, they're all your holes. Localizing an entire Web presence and user experience can require plugging holes among different products and platforms: Web server, Web application, database, reporting utility, e-mail software, shopping cart. To do right by the visitors to your Web site, you need to test everything all along this click-path.

It's rare that you will need to build a new app server based on the Hebrew versions of Linux, Apache, etc. to support these languages and users. But if characters and messages are not surviving all the way through your e-path, you may need to enable the support in several places, order some language packs and research the locale's computing needs. This is hard to do on a testbench in a lab, so you may end up testing your own international-stage instances on production servers throughout the organization.

Localization Testbenches, Part II (Software)

What are you using to test your localized products? If you're handing them to your domestic QA team and expecting that they'll intuitively test them with correct language locale settings, you may be in for an unpleasant surprise.

1) Software
This will probably take you the most time to get right, because you need to go to more pains to emulate the real-world scenario of your customers. They've bought computers running Windows XP/Japanese or Linux/Russian or MacOS/Arabic. The hardware nowadays isn't different (except for the keyboards), so you don't need to outfit your lab with machines from all over the planet.

However, if you install your Korean product under US-English Windows XP, you'll probably be in for lots of corrupted characters on screen. This is because characters in Korean (and Japanese, Chinese, Arabic and a few other languages) take up two bytes, whereas characters in English (and other Western languages) take up only one byte. An English operating system tries to interpret the Korean characters one byte at a time, and the result is usually illegible.

Modern operating systems include the fonts and locale support for these multi-byte languages, though it usually needs to be enabled. This is a good half-measure for testing your localized products, but it's still not exactly what your in-country customers will see, so you should consider native-language testbenches, onto which you freshly install the native operating system.

This can get clunky and hardware-intensive - even if you're partitioning the disk and dual-booting - so you may also consider virtualization products like VMWare and Virtual Disk. You can host dozens of different native-language systems on a single hard drive, and run several of them at a time, if your machine is sufficiently endowed.

Of course, almost any solution will spook your testers, who will consult their job descriptions and inform you that they contain no mention of "putting up with weird languages." This is not an insurmountable problem, though it is a topic for another post.

Note: Believe it or not, some people think it's pretty slick to see MacOS in Portuguese or Russian RedHat. They are hypnotized by how similar the interface is, and struck by the differences. A neat show-stopper for your evangelization sessions.

Localization Testbenches, Part I

What are you using to test your localized products? If you're handing them to your domestic QA team and expecting that they'll intuitively test them with correct language locale settings, you may be in for an unpleasant surprise.

Of course, your testers need to have some tolerance for the extraordinary circumstance of not being able to read what they're testing. Testers with this level of tolerance have not been that easy to hire in single-language countries - which is one explanation for the success of globalization - but they do not take quite so much umbrage at it now that the writing is on the wall and the tools are more handy.

Also, there are two levels of testing: linguistic and functional. You do not need (or want) your domestic QA team to review the Italian translation; you want the translators to review it, and by the time you're handing your product to your QA team, linguistic review should be long since ended. In most cases, your QA team will know how to perform functional testing much more efficiently than the translators will, even though the UI is foreign. Encourage them to overcome the "How can I test this when I can't read it?" obstacle, either with your own evangelization, or with gentle, paycheck-indexed prodding from above. They have more value to add to the localization QA process than they suspect.

In this series, you'll read about testing 1) Software; 2) Web sites; and 3) Help files.