Your Unique Value Proposition

You're a localization project manager. What makes you any different from other localization project managers?

Marketing people devote careers to answering this question, and because they're in Marketing and we don't know what they do, we assume that it doesn't apply to us. But stop and think about your next salary review, and come up with a few things to mention to your boss that make you different from other project managers:

• Are you learning new technologies that the company will care about in the near future?
• Are you specializing in projects, customers or terminology of strategic value to the company?
• Can you point to a sum of money you've saved the company by doing something new?
• Have you asked your clients to recommend you on LinkedIn, so that you can show your profile to your boss? (What could be easier than that?) (You are on LinkedIn, aren't you?)
  
• Do you have an idea of what you want to do beyond managing localization projects, and have you discussed it with your boss?

These help you formulate your unique value proposition (UVP), as those inscrutable people in Marketing call it; the combination of talents and drive that makes you different. If you're not different - or are different, but you don't show it - you'll stay where you are. If you're different - and show it - you'll stand out in your boss' mind.

Common Sense Advisory has posted a Quick Take for its subscribers called "The Makings of an Innovative LSP." They look at every vendor's eternal quest for something above commodity status and describe the characteristics of vendors who have succeeded in differentiating themselves from their competitors.

This company-level perspective applies to those of us in the trenches as well. Are you learning another language? Have you taken a class to learn sales techniques to close more business? Do you have the skills to train incoming project managers? Are you learning about search engine marketing or other ways to generate leads? Can you put together a paper and present it at ATA?

Start working on your UVP. And see whether your marketing manager knows what that stands for.

Summer localization slowdown

Things are quiet on our localization front at the moment.

The nature of managing localization projects as a consultant is that, if there's work to do, I do it. If there isn't, I go into down-time mode and focus on interim activities like these:

• Analyzing return-on-investment. This is, in part, how I eventually grew into the role of international product manager. My quest for data on the language-by-language profitability of our localized products takes me to more far-flung corners of the company than I'd anticipated, and it isn't always embraced by everybody in the organization, but I learn a lot. The Accounting department has some vague numbers on revenue from localized products - the overseas sales offices have more accurate data - but it's hard to allocate costs accurately because a localized product costs more than just the amount paid for translation, and companies treat this differently.
  
• Evangelizing. I spend some time getting my ducks in a row with Engineering, Marketing and Production, "educating" them on what goes into a localization project and how much more internationalization we can afford for the next version. I work at keeping people's eyes on the goal of simultaneous shipment ("sim-ship").
• Working things out with the vendors. Some projects merit a post-mortem - which I have always preferred to label "post-partum" - meeting to review what went well and what needs to go differently in the future. It's common for some action items to come out of such a meeting, and so I often spend time with the vendor putting process improvements in place for the next round.
  
• Tinkering with the machine. Every project brings up several internationalization issues (embedded strings, rogue controls, bits of unruly not-invented-here software), so I take advantage of down-time to find out how to deal with them, then pleasantly surprise the engineers with the research I've done.
• Finding beta testers. It's helpful to spend time in between projects mining our registration lists for new beta testers for the localized versions. I find new prospects, weed out the people who haven't helped on the previous round of testing and - very important - handily reward those testers that have stepped up and done a good job for me.
• Talking to the Sales teams. The salespeople in the overseas offices know best what sells and what local customers think of the products, and down-time is an opportune moment to collect formal and informal data and requirements from them.

What about you? Do you ever have down-time between localization projects? How do you spend it? Post a comment and let us know.

Localization is Like a RipStik

 

I'm on vacation this week in Santa Rosa (Northern California), and I've dared myself to get acquainted with my nephew's RipStik.

Naturally, since I needed a pretext to post to this blog in the middle of my vacation, the RipStik reminded me of localization. Specifically, simultaneous shipment (simship) localization, in which a company releases the same product in multiple languages "simultaneously," a term that is, fortunately, loaded with shades of meaning and exactitude.

It Works, But It Looks As Though It Shouldn't

The RipStik has only two wheels. Both are 360-degree casters, slightly pitched. Once your feet are on the decks and you give yourself a small push, you move your legs - particularly the back leg, according to my nephew - to propel yourself. Having done this for only a single day now, I have no idea how I keep my balance, but I assume that it has something to do with divine intervention.

Simship shouldn't work, either, should it? You're artificially constraining something (usually the source-language product) and propelling something else (the target-language products). Yet once you're underway, management will wonder at how natural the process seems.

Don't Do It If You're In a Hurry to Get Somewhere

Yesterday I sweated and gasped for half an hour to get about 50m and back. This morning I resolved to get to the end of the street and back, which also took a half-hour. I probably couldn't get to the corner and back on a RipStik if I really needed to get to the corner.

Don't bet the quarter's international revenue on your first simship attempt unless upper management has agreed to flog anybody in the company necessary to meet the goal. You'll need a few release cycles to build up to this.

It Helps to Have a Buddy
In the RipStik How-to-Ride video, the narrator recommends having a friend help you steady yourself when first you mount. This I would gladly have done, but my sons and nephews were too busy laughing at how ridiculous I looked to stop and help me.

Talk to localization professionals in other companies about their experience in simship. If you don't know any, find some on LinkedIn, or lob a question about simship into Multilingual Communications (see "Blogos" link to the right). Don't rely on your vendor for this; they're in the back seat and you're the one behind the wheel.

You Won't Truly Know Whether Your Organization Is Up To It Until You Commit
I have no idea what possessed me to ask my nephew whether I could try his RipStik, but as I stood over it wondering how to operate it, I realized it wasn't going to reveal its secrets until I'd made the first move...and the second and the third and so on.

You may be able to gauge your company's commitment to simship by asking people, but you don't know whether the process is truly possible until you've been through it. You, as localization manager, will of course shoulder most of the burden, but there are plenty of things you'll need from other people, and only by doing it can you see how close to or far from the goal you've landed.

Quantify Your Goals
I challenged myself to get to the corner and back on the RipStik, but I forgot to specify the amount of time I was willing to spend on it. Not much of a goal.

When you launch the project, specify "simultaneous:" source plus 15 days, source plus 30 days, same day for source plus two languages then 30 days for the remaining languages, etc. It makes success appear more probable to all of the other players whose support you'll need.


So, hop onto your RipStik and give simship a try, but keep in mind one important dissimilarity between these two endeavors: I've realized that, like many activities that involve balance, it's best if you keep your head up and focus on your progress, but not on how you're making your progress. In simship, that's a luxury reserved for upper management. You need to keep tabs on everything all the time.

"I certainly get tired of localization."

Have you said this lately? Have you thought it lately? Do you wish you'd joined the Rolling Stones when they invited you?

What do you plan to do after localization? What will you do next in your career?

Look at the localization people around you. How did they get into this business? How has their job changed since they did what you're now doing? At least two prominent figures in our industry started out as professionals (attorney and tax consultant), then started small translation companies that grew very large. Neither of them translates anything or manages projects anymore, but both have used the industry as a springboard to broader career paths.

On the vendor-side, translators become project managers, who become leads, who become salespeople, who ultimately run the company, or start their own. On the client-side, localization managers become product managers, who become directors of product marketing. On either side, your company could easily be purchased and you might have to start over from scratch. Will you be ready?

I've visited high school and college classes to describe to language students how they can use their talents to enter several industries, including translation/localization. It hasn't occurred to me to address the question, "After that, what?"

Of course, you don't need to wait until you've grown tired of localization to start planning your own outplay. If you don't have another marketable talent in your back pocket right now, then you must not be reading the newspapers. Years ago I had a very discerning boss who asked me in confidence, "In how many completely different ways can you earn a living? You should always be accumulating multiple talents you could apply to make money, if you had to."

So, during the day you're a localization manager, and at night you offer bookkeeping services to small businesses. Or, Monday through Friday you run translation projects, and on Saturdays you do search engine optimization for friends' Web sites.

Yes, it's more work, but when the localization train reaches the last station and you get off (or are pushed off), you'll have more options in picking the train to board next.

Giant Localization Leap Backwards

"All of the strings are embedded in the code."

There was a time when I welcomed - or at least was not very much surprised by - sentences like this one. They came from engineers in response to my questions about the readiness of their software strings to be localized. Strings embedded in code, of course, are more or less inaccessible to localization techniques, since nobody wants to hand off an entire code base to a translator, and no translator wants to wade through an entire code base trying to find strings to translate.

So, when one of my client's engineers said it to me yesterday in reference to an application in a larger product we plan to localize, I briefly welcomed it. It means more work.

But then I realized that combing all of the strings out of the code and into separate, accessible files will require a great deal of time and effort (not mine). Engineers don't usually enjoy working on this kind of task, so it will fall to the bottom of the priority stack, and the product manager won't go to bat for it, and so this particular application will stick out like a sore thumb as a non-localized component in an otherwise localized product suite.

"Is there a phased approach we could take to enabling this app for localization?" the engineer asked.

I appreciated his attempt to save the game, but a partially localized product is rather ugly. We could enable and translate the menu and dialog strings for this release, and go back for the error messages in the next release, but the mongrel product is not very appealing to users in the meantime.

This is disappointing, because we've made such long localization-strides elsewhere in the product suite, and dealing with this newly acquired app feels like such a giant leap backwards. I guess I'll work up some estimates on the time required to enable the application, then make my case to the product manager and development lead to generate some interest and start the process from the beginning.

Isn't that why we localization project managers and international product managers were sent here?

What do you do in your company when engineers tell you that all the strings are embedded in the code?

Localization Risk, As Time Goes By

In 1999 I created a presentation on minimizing the risk in localization projects. It offered several scenarios with possible decision-paths and ways to keep risk low. I've dusted off the presentation and offer a sample from it today.

1. Your company decides to localize its product, and assigns the project to the Technical Publications Manager. Unfortunately, that is you. Do you:

• rebel, because it’s not why you hired on?
• rebel, because it’s not a Tech Pubs function?
• rebel, and do it anyway?

The Risk - Entrusting the project to someone who doesn’t want it or cannot manage projects. To minimize the risk, pick someone with project management expertise over linguistic/writing/engineering/product expertise.

2. Your CEO tells you he wants to localize into 5 Western languages and 2 Asian languages first time out. He offers you an extra 5,000 stock options if you complete the project successfully. Do you:

• say, “Piece of cake!” and take the challenge?
• ask, “Am I being set up for failure?”
• counter, “I'll do that if you do the press tours”?

The Risk - Biting off more than you can chew, especially the first time out. To minimize the risk,
schedule a scaled-down “pilot project” rather than picking a fight you may not win.

3. You explain to your QA Manager that she will soon have the opportunity to test French and Portuguese versions of the product. She replies, “Oh, we’ll have no part of that.” Do you:

• laugh?
• cry?
• pretend you didn’t hear her and say, “Right. I'm glad we understand each other”?

The Risk - Intimidating or alienating co-workers with the localization process. To minimize this risk, educate first, then start mustering resources. Also effective is an evangelization effort to boost your project's visibility everywhere in the organization.


In short, it's not very exciting to go home at the end of the day and tell your spouse that you spent most of your day minimizing localization risk, but it is quite important. The risk lives in lots of narrow corners, and it's your job to find it before it finds you.

Four Localization Answers, Just In Case They Ask

Sooner or later, someone may ask you, "We've got a new release coming up. Why don't you give us a presentation on what you'll need to localize it properly?"

After you've recovered from the shock, will you have a ready answer?

I received this request last week from one client, and turned it into an invitation to present at the regular meeting for all of the leads - software, Web, documentation, project management, QA, release - and some people in upper management. It's meant to be a very brief (10-15 minutes) presentation, which felt like a limitation at first, but which now strikes me as an advantage because it will help me focus better.

They've stapled me to a slide presentation, and I made the most of it.

• Slide 1: Hello! I'm the Localization Guy and I live to pester people. (Maybe I don't say it in quite that manner...)
• Slide 2: Scope of Work - These are the software, Web and documentation bits we'll need to localize, and the parts that are already in TM.
• Slide 3: Timing of Work - Let's hand off anything we can as soon as it's stable, even if the localized releases aren't for several months yet.
• Slide 4: Help Wanted - Here are areas of the project outside of my control, where a little localization-mindfulness will save some time, money and headaches. This includes tagging XML files for text that should not be translated, handing me early software builds for internationalization testing, and thinking about the stable files we can hand off ahead of product release.
  

I think this will suit their desire for information. They don't want to know the details of how I do what I do, but I want them to know what I need from them.

You too should have a presentation like this in your desk drawer or on your hard drive. Just in case they ask.

Changing Your Vendor - Not as Easy as Changing Your Shirt

"Say, a salesman from a translation company has been after me for the last few months, and he wants some business from us. Shall we look into changing vendors?"

What's your first answer to this question?

When I'm not in the market to change vendors and I observe that it's not appropriate to go into the matter too deeply, I usually pull one of several quick answers out of my drawer and use it:

• "No."
• "Sure, we can include the vendor in the next request for proposal."
• "Forward him to me and I'll find out more."

I have nothing to fear by looking into a new vendor, of course, except that things that aren't broken now, could get broken with a different vendor, and who wants to trade the devil you know for the devil you don't know?

Last week one of my clients asked me the question about changing vendors. Sensing there was time for a little bit of education, I let her be the expert by suggesting a short true-or-false quiz:

True or False:

1. You're convinced that your current vendor is much too expensive. ("much" is an important word here.)
2. Our engineers and your other service providers, like the Web team, cannot work with the current vendor.
3. Your in-country offices are complaining loudly about the current translation work.
4. Your customers overseas are complaining about the current translation work.
5. You hate the vendor for some other reason, and dread working with it.
6. You're not inclined to let me to fix the problem.
   

I recommended that, if she scores 2 or more True, we can look into peeling off one of the languages and trying the new vendor. If she scores 1 True, we should have a chat with the current vendor and work something out.

If she scores 0 True, she is in the localization minority and should count her blessings early and often.

I also mentioned that a switch of almost any magnitude will involve a lot of re-plumbing and education. In my experience, the current vendor is charging a fair price for good, steady, reliable work, and is making my client look good (or at least, not embarrassing her). OTOH, if she really wants to make a switch, we should select a time of relatively low volume and a project/language of relatively low risk to do so.

What do you think about changing vendors? I often see problems in the chemistry with project managers. That's an easy change to make, probably easier than most people realize. But don't discard the vendor just because you don't get along with the project manager; they have others, and if they want to keep your business, they'll help you switch.

I Don't Want to Localize That, And You Can't Make Me

Ever hear your children make similar utterances, except with different predicates ("go to bed," "clean my room," "do my chores")?

One of our clients is staffed with people too polite to say things quite so bluntly (but not too polite to dig in their heels similarly). The upside is that I enjoy working with almost everybody I've ever encountered there; the downside is that there are some places where their global-readiness is stuck.

Web presence
I bend over backwards to uphold a simple rule of Web navigation: Localize everything along the click-path to a visitor's goal. So, if a visitor starts on a Russian home page, and decides she wants to download a Russian version of the trial product, I believe in ensuring that she doesn't have to put up with English on her way through the site, unless she wants to do so. Or, if we need to push her to an English page, I try to make it apparent with "English only" next to the link.

We've made a lot of progress in combing out the remnants of English that dot many localized sites (that makes my skin crawl - how about you?), so that each page is linguistically pure to several levels. That was expensive and it took a lot of time.

The problem now is that this client's site relies on a lot of plumbing for verifying that the visitor is not from an axis-of-evil country, or hacking the site, or trying to perform unsupported operations, and the UI for all of this infrastructure is in English. Much of it is just background code, but several pages (login, registration) are in English, and the infrastructure team is not interested in localizing any of it, despite my polite persistence.

License agreement
This is a hot one. When you download trial software from Germany or Finland, do you click "I accept" to a license agreement in that language? Granted, German and Finnish are not the lingua franca that English is, but how much more does it say about the relationship you want to have with your customers when you make some effort to inform them of your business terms in their language?

"We don't translate anything legal, and it's not hurting sales," I keep hearing. This is a battle I know I'll never win, so I look for victories elsewhere.

Site logic
There was a sudden need some months ago to place a terms and conditions page in the click-path to a particular download. Naturally, the terms and conditions were in English only, and I could have lived with that. The problem is that the code behind the page sent the visitor to a particular next page, without regard for where the visitor was going when he landed on the terms and conditions page.

So, visitors on the way to download the Korean/Japanese/Chinese/Spanish... version of the product sailed along the click-path in their own language until reaching the terms and conditions page. Then they agreed to text they almost certainly did not read, then they landed on a completely irrelevant page of English, with no reasonable way of getting back to their intended destination.

This is related to the inflexible plumbing I mentioned above. It's great infrastructure; it's just monolingual and it doesn't really need to be.


Anyway, these bits of stubbornness amount to a small downside in a client that is not stingy about localization in general and that has a strong global presence. They're correct when they say, "I don't want to localize that, and you can't make me," so it's easier to roll with the punches and enjoy other victories.

Besides, if I'm around long enough, they'll move on and I can take the matter up with their successors.

What things have people told you they're not going to localize, and you can't make them?

Acceptance criteria for Localization

Have you ever gone to the extent of developing acceptance criteria for a localization vendor's deliverables? Beyond that, have you ever sent a vendor an acceptance letter summarizing these criteria, and grading the vendor on each point?

After years of my simple handshake-and-phone-call approach to acceptance, one of my enterprise clients asked me to develop and communicate these criteria formally. It didn't require too much effort, since I knew what I had liked and disliked about the vendor's performance all along. Here are the points I drafted:

PERFORMANCE

• Responsiveness: You attended all conference calls and apprised me in a timely manner if you were unable to attend. You responded to e-mail very quickly.
• Delays, schedule: You reported only a couple of delays on the project, none of which was more than two workdays in length. In the main, you maintained your schedule day to day and week to week.
• Weekly reports: Your weekly reports were punctual and informative. They helped me to communicate accurately the status of the project to other members of the team at BigCorp.
• Issues, questions: Your process for moving the translators' questions and my answers back and forth was simple but adequate.

TRANSLATION

• Quality: Preliminary reports show that our customers were satisfied by the translation work.
• Bug fixes: You incorporated feedback from the reviewers and me as we requested.

DELIVERABLES

• On-time delivery: You delivered all files to us in a timely manner. You delivered the final files 2-4 calendar days ahead of the final deadline.
• Project files: After giving us the main deliverables on time, you performed housekeeping on the supporting files and delivered them to us.

Frankly, I left out a few things, like the fact that conference calls were arduous because of their phone system, and the rather attention-getting directory that appeared on our FTP site one morning labeled "Trados_crack". But the point of the message is to convey acceptance, and it serves that purpose well.

Did I leave anything out? Let me know.

Is your new localization vendor working out?

Changing localization vendors can be stressful. It's an entire "getting to know you" process you would rather avoid, but sometimes you have no choice. Like having wisdom teeth removed.

Here are some points for evaluating the fit of your new vendor.

On the downside:

1. Are there truncated strings in the software they send you? They should have reviewed these and should not send you software with such an easy problem to resolve.
2. Do they speak and write good English? Conference calls with people who don't (or won't) speak English are frustrating and unproductive.
   
3. Are there any "oops" moments early in the project? One new vendor focused on my detailed description of the changes in a document, and assumed that they were the only difference in the new version. They had overlooked 8,000 words in new files I had handed off in the localization kit. Oops.
4. Are you customers (internal or external) satisfied with the quality of the translation from the new vendor? If not, you need to address this in a hurry. I pointedly asked our Korean office what they thought of the quality of the new translations compared to the old, and they replied, "The quality seems to be about the same as before." Perhaps a bit less than eloquent praise, but it was important for me to know.
   

On the upside:

1. Are they finding mistakes in the original English version and sending them to you? Sometimes these take the form of "This sentence seems corrupted, please explain." If you have the bandwidth and patience for it, you'll see that these are actually prefabricated bug reports that cost you almost nothing to submit, with the benefit of improving your product (especially the documentation, which is where most such problems lie).
2. Are they helping you think about long-term improvements to your international product process? Vendors are in a position to suggest internationalization (I18n) techniques for your product that will prevent you from maintaining several code bases, for example. Does the new vendor have the perspective and degree of experience to tell you, "You know, if you make each of the control labels the size of your largest language, you can use the same dimensions universally, and we don't have to charge you so much for resizing them each time."
   
3. Are they cleaning up pre-existing messes? Old messes die hard, and you can be sure that your translation memory databases have plenty of them. A new vendor comes to them with a fresh perspective and can help you clean them up, especially if it helps them to do their work better.
   

The more experience you have with new vendors, the bigger your own list of evaluation points will be. The sooner you deal with them, the less trouble your project will be for you and for the vendor.

Like wisdom teeth.

Localization - Top 5 Web searches

What is your most frequently used Web search regarding localization? Are there search phrases you check every now and again to see what new results they yield?

Over the last couple of years, I've tuned the keywords on this blog and on our Web site, www.1-for-all.com, for both pay-per-click and search engine optimization. I have a pretty good idea of which search topics bring people to this blog, and here are the top five topics, with my comments:

1. Localization of HTML help projects (Robohelp, CHM, etc.). I can't tell whether people have trouble with this, or whether they're poking around to find out whether they are going to have trouble with it once they undertake it. My hunch is that Robohelp, the dominant product for creating HTML help, either doesn't do a good job creating localized help systems or doesn't do a good job in explaining how to create them. Our experience has been that double-byte localization requires a specifically enabled, separate version of Robohelp, which strikes me as silly, but perhaps Adobe has addressed this by now.
2. How much to charge/pay for translation. Everybody wants to know this. Responding to the frequency of these queries, I wrote an article called "Going Global Without Going Broke" to help people who want a few benchmark figures from which to cobble together a budget. If you're any further along than that, you should just contact a vendor, push your files to him and get an estimate. If you're a translator or want to become one, phone a localization company, tell them what you can do and find out what they'll pay you.
3. Localization project manager/management. I would guess that about half of these are vendors (a.k.a localization service providers, or LSPs) and half are companies with localization needs to fill.
   
4. Localization jobs. Most of these queries come from Ireland. There's a relatively high concentration of localization talent in that country, and perhaps a high rate of turnover as well.
5. What is localization? Again, the frequency of these queries prompted me to write articles called "Opening the Black Box." I'm glad to see people asking this question, because it demonstrates continuing and continuing interest in this specialty. At the same time, however, I notice that some of these queries come from China and India, suggesting to me that the IT shop which has just promised you it can localize your software for one-seventh the price you've gotten from other vendors, is now trying to figure out what's involved in fulfilling that promise.
   

At the other end of this list are the searches we're not seeing: questions we believe people should be asking but aren't.

Getting along with your (vendor-side) Project Manager

Have you ever called time-out in the middle of a project and asked for a different project manager?

You should consider this your inalienable right as a customer.

Vendor-side project managers are, of course, people too, subject to the same grinding, erosive workplace influences that all of us are. Probably more, really, because they serve so many masters and spend a lot of their time currying favor with QA staff, translators, editors, desktop publishers and their own managers, not to mention multiple customers at a time. So if they are grumpy on the phone or unresponsive or slip deadlines occasionally - the key word is "occasionally" - it's just part of life.

Sometimes, though, the chemistry is just not right. You're the manager on your side and they're your primary point of contact, and these are gears that need to mesh smoothly. How long do you want to work with somebody you don't enjoy working with?

• The first necessity is to meet the person who will be your project manager before you award the project to the vendor. A face-to-face meeting is preferable, but if phone is the best you can do, that's better than nothing. No sensible vendor would decline your request for this.
• Once the project is underway, teach your project manager how you want to be treated. Do you want to exchange cell phone numbers or even home phone numbers? Do you want to set up IM or Skype? Do you want weekly reports? On which day? What information do you want in them? Do you prefer to handle as much as possible via e-mail, with phone calls only when necessary? Do you want regular project status calls? The manager, to some extent, is in business to make you happy, and teaching him/her how you want to be treated as a client is a small investment in what could become a long-term relationship.
• Gauge the project manager's competence. Beyond an introductory training session on your product, if you're holding the manager's hand a lot, that represents time and work you shouldn't have to expend. Is the manager a localization newbie? Some newbies are lower-maintenance than others, and if you have to take one, that's the kind you want.
• Most of all, is the project manager delivering on promises? Any manager has a lot of upstream influences and a change in any one of them could blow a delivery to you, but if it happens repeatedly, then you have the wrong person running your project.
• Finally, what kind of end-of-project etiquette does the manager exhibit? Is there a post-partum meeting to review how the project went? Do you just get an invoice and no handshake? Does it appear that the manager has the business sense to cultivate the relationship with you for future projects (assuming you haven't been a bear to work with)?

If you're losing sleep over issues like this, you need to call the account manager and suggest a change of project manager. It's up to you whether you want to cite chapter and verse on why it's not working out, but a simple "I need a different project manager because this one is not working out for me" will do. Any clear-thinking account manager with future commissions breathing down his neck will happily accommodate you.

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.

Switching Localization Vendors--Take this Quiz

Take this short True-or-False quiz:

1) You think your localization company is much too expensive.
2) Your other contractors or in-house teams cannot work with your localization company.
3) Your in-country offices are complaining about the translation.
4) Your overseas customers are complaining about the translation.

If you scored 2 or more True, you might look into peeling off a language and trying a new vendor out. If you scored 1 True, you should have a chat with your vendor and work out the problem. If you scored 0 True, you are in the localization minority and should count your blessings.

Making a vendor switch involves a lot of re-plumbing and re-education. If your vendor is charging a fair price for good, steady, reliable work, and they're making you look good (or at least, they're not embarrassing you), there's plenty to be said for that.

Keep in mind also that this is a relationship. The vendor won't necessarily get it right the first time--neither will you--but if they show improvement, and they're willing to work with you on making things better, you have the beginning of a beautiful friendship.

Localization in the Flat World

You need to understand the localization process - even if you're in denial about it - because the world is flat (apologies to Thomas L. Friedman) and the sooner you see how the process goes, the sooner you join the ever-flattening world.

Do you see your company in the following scenario?

We're bringing a prospective new client into the flat world. Up to now, they've dealt with translations, in which somebody overseas says, "We need to be able to read this document in our own language." Recently, though, the folks overseas are saying, "We need to be able to use your product in a way that makes sense to us." The unspoken rest of the sentence, of course, goes, "...or we'll find a different one and use it."

They are on the road to localization. What's next?

1. Demystify the process. What's really involved in creating a localized product? How much will it affect this organization?
2. Identify and talk to all stakeholders. Inform them of what's coming and what will be required of them.
3. Figure out exactly what needs to be localized: software strings, documentation, help, Web pages, installer strings, sample files, etc.
   
4. Create a project plan. Much of it will be wrong the first time out, but as long as you know it's a living document, it will serve its purpose.
5. Appoint or find a project manager. The localization project needs a champion (some might say a lightning rod), because it won't all happen on its own.
   

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.