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.

Localizing Graphics - The Last Thing Anybody Thinks About

Now, then. A word or two about localization and graphics. If localization is the last thing anybody in an organization thinks about, where does that leave localized graphics? The last thing after the last thing.

Screenshots are taken for granted. If you're localizing from English into Russian, and the documentation contains 50 screenshots, you naturally steamroll right over the English ones by running the Russian version of the software, taking the same screenshots as in the English doc and replacing them (same size, same bit depth, same filename, etc.). The original En screenshots may even be in the doc project, but you know you're not going to use them, so you don't give them much thought.

But good writing usually requires good graphics, and writers funnel graphics from sources all over the building into their books. Engineers convince the writers to include flowcharts, Visio diagrams, spreadsheet charts, schedules, timelines, Gantt charts and other pictures in the docs, and they often include translatable text. NOBODY ever knows where the source file is.

"We need to translate labels in the flowchart on page 73. Where did it come from?"

"Bill in Engineering gave it to me, but he's left the company."

"Do you have the source file?"

"Oh, sure. Bill sent it to me in this PowerPoint presentation."

Well, yes, it's in there, but it's just a .jpg file pasted in from someplace else. I get engineers crawling through source code and around long abandoned hard drives on a quest for the source files, to find out that somebody cobbled it together using Microsoft Word Art in a .doc file. That's if I'm lucky.

Most of the time it's a .gif or .jpg that came from Marketing, or from some designer who did it in Adobe Illustrator or Photoshop. "Can you get me the .psd for this?" "No. Work with what you have."

So we do. It's not impossible to hack an existing graphic file, but it's not a very clean process, and if it's of any size, the mismatched text will be pretty obvious.