WWMSD?

"What would Microsoft do?" What do you do when you need to translate according to the terms Microsoft uses?

Microsoft has a long, storied past of localization, and a correspondingly colossal corpus of translated material. Until a couple of years ago, they made just about every string in dozens of their products available in .csv files via FTP for free download, subject to copyright. No doubt that became laborious for them - it certainly was for those of us who tried to keep up with them - so they've since switched from making all of the strings available to making 12,000 key terms available in up to 59 languages in a single, 10MB spreadsheet. The file is at www.microsoft.com/globaldev/tools/MILSGlossary.mspx

The winners in this simplified approach are those linguists creating a term list, or translation glossary, for a specific project that must adhere to Microsoft terminology; e.g., how Microsoft translates "Cross Array Link" in Korean. The losers are linguists who need to know, for instance, how "Completing the Hardware Wizard" or "Windows Security - Verify Publisher" is rendered in Slovak or Pashto.

The term list also takes aim at a long-standing problem with localization at Microsoft (or any large organization); namely, that there was inconsistency in translation among products. While not all translators will agree that these terms are ideal in a given language, at least this is a move in the direction of consistency, and sometimes it's better to be consistent than to be right. It's generally easier, anyway.

If you enjoyed this article, you may like another called "Where Do Your Glossaries Live?"

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.