Offshoring Localization and On-shoring the Communication

You're offshoring your localization or development work to China and saving lots of money. Upper management is delighted. Your localization dollars are going further than ever. The offshore partner's project managers are professional and responsive. It's everything you'd hoped it would be.

Almost.

There's a little something that feels strange on your conference calls and status meetings. The work is getting done - mostly - and the schedules met - mostly - but there are gaps here and there in the relationship. It feels as though, when there are misunderstandings, they seem to get resolved, but not in quite the way you expect. Sometimes their approach to solving a problem seems off the mark to you, even if it works out in the long run.

In short, you feel as though the communication could somehow be better. You can't quite describe what's amiss, but it nags at you.

Believe it or not, your partners in China may have the same impression.

This week I met with one of the U.S. representatives of a large Chinese offshore development company that offers, among other services, localization. Besides finding new customers, he's tasked with acting as the on-shore presence for existing customers.

"There are subtle ways in which our managers and developers don't quite connect with some clients," he told me, "and it's not just because of the language barrier. I look at it as two layers of cultural difference: first, there's the east-west difference, then there's the cultural shift the client undergoes when product structure changes to the offshore model. In other words, it's strange enough that an outsider is now responsible for large portions of your product or service, and even stranger because that outsider is somebody with a completely different kind of life and world-view from yours."

This is a novel role. He's not the project manager, moving files back and forth and matching jobs to translators. Nor is he the account manager, working out contract details and managing payment schedules. He's the communication manager, or the relationship manager, helping to fill in the almost undefinable gaps that sometimes prevent clients from really clicking with their offshore partner. In fact, the company hired him to place his localization expertise and customer skills on this side of the Pacific, within a couple of time zones of its key clients.

"So I spend a lot of my time just listening, "he continued. "I'm on conference calls, I'm visiting client sites, and I'm getting face-time with our clients and our staff, picking up on the subtle things that we can deal with now, so that they don't blow up later on."

Whether they choose to believe it or not, most people who are offshoring work to China (and India and Romania and Lebanon and...) know that those countries will get it right sooner or later. In fact, it will take fewer years for them to get it right than it did for us to get it right.

A client-side relationship manager will play an important role in getting it right, and the position will become mainstream before long. The opportunity for both vendor and client is ripe, and the benefits are long-lasting.

If you learned something from this post, have a look this related one: "Making Sense of Outsourcing"

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

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.

The Localization Manager's Team - If You're Lucky

How many of you out there in L10n-Blog land get support from other internal groups?

A long time ago my boss told me why it's important to be a complete zealot about localization, especially in an organization that is new to the process.

"For people in general and engineers in particular," he observed, "localization is interesting only once: The first time. After that, they're just humoring you."

I've kept that in mind as I take off like a street fighter with most clients, eager to ride the wave of novelty that accompanies the prospect of going global. Product managers brief me up one side and down the other, in-country partners promise to devote legions of in-house staff to testing the product the minute it's ready, and QA resources jump at the chance to configure localized test benches.

At the water-cooler level, employees want to connect me with their cousins who are studying French and would love to proofread the manuals, or with their former co-workers in Japan who would make excellent beta testers. Naturally, I diplomatically avoid these golden opportunities, but I appreciate how high spirits can run at the outset.

In time, though, product managers stop returning phone calls, in-country partners run out of time, and QA leads are unexpectedly besieged by other priorities. (In one memorable instance, after I had explained to the QA manager the relatively paltry need for a few machines and 10 person-hours of testing per week for 4 weeks, she replied, "Oh, we'll have no part of that," and walked away.)

It's not so tiresome when my task is simply to get a localized product out the door; in that case, I work things out on my own to achieve that goal, since I know the process from end to end. But if clients hire me to build teams and to put procedures in place for localization, the expectation is different, and people know it's an edict from above. I need stick and carrot for engagements like that. That's more like a, well, a job.