Stages in your company's localization-life

"So, where are we on this localization-thingee?"

Do you get questions like that from upper management? The question demonstrates complete cluelessness about the work involved in creating international versions of your company's products. Secretly, of course, you're gratified that it's on upper management's radar.

Here are typical steps in a company's localization-evolution:

1. No Clue - These companies find out the hard way, often by ignoring in-country requests, bulldozing the project through Engineering, shipping poorly localized product, and not figuring out in advance how to support it. The biggest shame here is the lost opportunity to get Engineering on board properly from the start; unfortunately, localization is going to interest engineers only once - the first time - so missing this chance is costly in the long run.
   
2. Some Clue - Companies with Some Clue designate a localization manager to act as champion (or at least as lightning rod) of the process. A wise investment at this level is in somebody who does in fact know something about localization (or global requirements and differences, anyway); such a person will help the company avoid most of the in-country problems faced by No-Clue companies.
   
3. More Clue - In time, the localization champion evangelizes internationalization/localization thinking to others in the company. People reflexively contact him/her whenever the word "international" is uttered because they correctly perceive that person as the hub in the international-product wheel.
   
4. Advanced Clue - This is the Great Engineering Leap. Along with all of the other fires that Engineering and QA put out, they now know it to be a priority to design their products and processes from the ground up for worldwide versions.
   
5. Total Clue - A company with Total Clue ships multiple languages simultaneously, has happy overseas offices and customers, and probably derives much of its profit from overseas sales. Things do not run on auto-pilot by any means, and the localization team must still crack the whip and pester people, but the entire organization lives with the charter of seeing beyond the home country's borders: the corporate version of the State Department.
   

It's common, by the way, for Sales and Marketing to drive this evolution, since they're closest to the pain caused by not evolving.

So, tell me: Where is your company on the localization-thingee, where does it want to be, and what do you have to do to help take it there?

Interested in this topic? You might enjoy another article I've written called "Whaddya know? They asked me first this time!"

Who owns this Localization Project?

It's almost time to ship. Do you know who's running your localization project?

Recently I met with a technology company whose Web-based service is already in seven languages. Non-US revenues are a high percentage of their total, and even though their product is available in both free and paid versions, most customers overseas pay. They take their overseas markets seriously, to the extent that they have an International Product Manager (IPM).

They contacted me about an upcoming push into Asia, and had me attend their weekly engineering meeting. Everyone in the room and on the conference bridge (probably 25 people in total) introduced him/herself, and after the last introduction I paused and said, "Nice to meet you all. Now, where is the localization manager?"

They don't have one, of course, though the IPM performs most of those duties. I rubbed my hands mentally and thought I heard a cash register ringing, until I remembered that they were live in seven languages and doing quite well without a localization manager, thank you very much.

How do they do it?

A lot of the localization expertise resides in the teams, so they told me. Documentation, Web team, Engineering, QA, and Release Engineering all have rather deep, in-group experience that shows in the localized products. That, however, doesn't explain how it all comes together at showtime.

Can you do it without a localization project manager? If so, does that mean that you've done things so masterfully that localization is completely mainstreamed in your organization?

Must be nice...

From Pseudo-translation to Pseudo-localization

Do you like having teenagers handle your medical insurance problems?

Why would you have college students localizing your product?

I've posted several articles on pseudo-translation, which is a science. Pseudo-localization, or the practice of pretending you have good localization processes in place when you're really having exchange students review or--ack!--translate your product and Web presence is not science. It's short-sighted.

I can't say for sure, but I think it has to do with what most people perceive as a black box around foreign languages, especially in the U.S. We're not xenophobes, but we are by and large linguaphobes, and most of us freeze like a deer in the headlights when the prospect of dealing with a foreign language arises.

Frankly, though, it's easy to fall into the practice of pseudo-localization, especially in technology companies. Young employees for whom English is a second or third language are becoming the norm, and while their cultural diversity and mental models are a boon for product development and global reach, are they really suited to translating?

No.

Inside that black box is what people have to do to become accredited translators, and to build and maintain their reputation. They're not fussing about Web-based translation portals and fast, cheap, young translators because they want to cling to their jobs. They're fussing about it because the product quality is lousy, and most Americans don't care.

You're an American localization project manager: Have you ever been in a company for more than three months without hearing, "Why don't they all just learn English and save us this headache? Har, har, har."

Better-cheaper-faster is a triangle, and you can't cover all three corners with the same solution.

So, by all means hire that French exchange student or that Chinese H-1B to work on your localization project. But make sure you get at least one other pair of accredited eyes to review it.

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 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.

If you meet the Localization Manager on the road, kill him!

[With apologies to the sage who said, "If you meet the Buddha on the road, kill him!"]

Hope I didn't startle you with that title, but it came to me as I asked myself how my clients would deliver localized products if I were hit by a bus, or if someone met me on the road and killed me.

The cemeteries are, as deGaulle mentioned, filled with indispensable people, which means that in time my clients would appoint somebody to pick up in the middle and finish the project. That applies to every one of the employees in every one of my clients' companies. My replacement might even do a better job than I did, such that outside of the improvement (and the sudden drop in total irony in the building), nobody would notice the difference.

I suppose it's a backhanded way of telling myself I do a comprehensive, one-stop-shopping job of localization project management: "Really, now: If I shuffled off the mortal coil, how would you guys get this work done?" The people who create the domestic product are accustomed to leaving all of the thought and toil to me, and they're in a variety of departments, focused squarely on anything but the localization process. Absent the localization manager (who, in this case, has no staff), the process would probably devolve back to those individual departments. Within no time, they would have had enough and begin to clamor for a replacement.

It's not so important to be indispensable as it is to fill in the dozens of unanticipated cracks in the process of turning domestic products into localized ones.

It's also a good idea to keep a wary eye on people you meet on the road.