Localization Project Management Log

Are you getting to the point where you need to consider decentralizing your localization project management efforts? That decision point usually comes with growth (more languages, more products, shorter lag-times). Here are some things to consider in distributed vs. centralized localization management models:

• Trying to plant and cultivate this expertise in each group (QA, product teams, release engineering, sustaining engineering) is pretty tough. One prospect appeared to manage things in a decentralized manner like this, telling me that “the car drives itself,” but I have my doubts. I’ve never seen any organization that did it well and robustly without a lightning rod or “localization czar” that ran around pestering people company-wide.
• Frankly, I think decentralization is difficult because, for all but the largest, best funded firms, it’s just plain hard to find and keep that many individuals interested in driving international products. I suppose it could be built into the company’s incentive structure, so that managers understood it was part of their charter to localize, but that wouldn’t guarantee that they would actually care about it, and caring is at the heart of long-term localization management.
• Until somebody really cares about it, most internationalization/localization projects have an out-of-band feel to them. It takes a long time before they feel familiar, and the sooner everybody knows that there’s somebody (besides them) responsible for putting out the Japanese version of the product or Web site, the sooner everybody can get back to work.

For these reasons – and a few others – I counsel companies to dedicate a single project manager , preferably with domain expertise, to as many localization projects as practical, rather than to expect each project manager to handle the localization aspects of his/her own projects.

That model will last a good while in most companies.

Maybe you read this and became encouraged to have your products and Web pages translated over the Internet by college students in other countries:

“In April and May 2007, Palex held an English translation contest for Microsoft software and documentation. It is the second translation contest organized by the company with the purpose of stimulating interest in translation and freelance work and selecting new full-time and freelance employees. With more than a hundred applications submitted, over 70 participants – most of them students and young professionals – completed the off-site translation assignment. Those who delivered the 20 best translations participated in the final stage.

“For the final assignment, the competitors had to translate an HTML page and correct 11 localization errors in a dialog box. Although translation quality was of the highest priority, the technical background of the participants – such as the ability to handle HTML correctly and the number of localization errors found – earned additional points.

“Andrey Cherkovsky, a freelance translator, was selected the winner. The second prize was awarded to Sergey Plotnikov, a chief specialist at Tomsk Regional Energy Commission, and Rostislav Romanovsky, a third-year student at the Chemical & Chemistry Engineering Department at Tomsk Polytechnic University. Neither has ever been a professional translator. Mark Lesun, a newcomer to freelance translation, ranked third. [emphasis mine]“

So, they got lucky. Don’t forget, though, that out of 70, only 20 qualified as “good,” and out of those 20, only 3 took prizes, and one of them was already a freelance translator. Can you find the 3 out of 70 that won’t embarrass you?

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.

Do you know the difference between localizing and internationalizing? Most people can go their entire lives without knowing it, but there is a useful distinction.

You localize your product when you customize it to the needs of a particular market, usually on geographic and linguistic bounds. So if you’re Toyota, and you want to sell cars in California, you need to equip them with the more robust emission control systems required by law there. Or, if you want to sell them in UK, you need to build them with the steering wheel on the right-hand side.

What you soon discover, though, is that it’s prohibitively expensive to create and maintain separate production lines for California, UK and other foreign markets, not to mention your domestic market. The challenge then becomes to properly internationalize your product so that the changes needed for each market cause as little disruption as possible to your production process. You design your cars so that there is some irreducible core that is the same, no matter where the car will be sold.

This is easier said than done, but in a technology company, where production lines move extremely fast – because it’s all just software – it’s important to bite the internationalization bullet early and often. The alternatives are multiple, straggler code lines; separate Web sites; and unintegrated, unwieldy sets of documentation.

So, when all about you are losing their heads over localization (L10n), you can be the calm voice of reason, asking whether the product is really ready for localization yet, or whether your colleagues should pause and think internationalization (I18n) first.

(Note: The term g l o b a l i z a t i o n is also used to describe the overall process of creating products for worldwide markets. The problem, in our search-engine-optimized day and age, is that the same term applies to the assimilation of national character and identity into the worldwide market, with undesirable ramifications to the disenfranchised. It’s not wrong to talk about g l o b a l i z i n g your product, but if you go searching for information on localization, don’t use the g-word.)

Most of the time, when you’re a U.S.-based company, you run the localization show. It’s a matter of simple history: You created the product in the U.S. and pushed it out to other regions, so your domestic needs get met first. You may factor in their requirements so that they have a respectably localized product to sell, but by and large, you call the shots.

Not only that, but assume that your domestic sales (i.e., the sales for which you don’t need to perform any localization) contribute 75% of your profit, and sales to regions requiring localization contribute the remaining 25%. This means you have both history and profitability in favor of your running the show.

Suppose, however that the tail wags the dog. Suppose that your product is developed in Egypt or Liechtenstein or Hungary, where it has 95% of the market without really trying, and that the developers are insensitive to the need for a properly run localization effort. The product is receiving strong uptake in the U.S., where sales will soon overtake those in the home market, but it desperately needs some localization (into proper English), on which Engineering refuses to place much priority. You have profitability on your side, but the mothership has history, not to mention ownership of development.

How do you build a localization strategy around that?

Like any global business problem, the usual bromides of communication, onsite visits in both directions and strongly backed business cases go a long way towards solving this. If they were selling a U.S.-created product into their regions, they’d defer to U.S. preferences, but it’s not that simple when the scheme is suddenly inverted like this.

You feel as though you’re the dog, and the other guys are the tail wagging you, and the other guys think they’re the dog, and you’re the tail trying to wag them.

The real winners? Your competitors.

Again I ask: How far will you go to improve your localization process? If a big improvement didn’t save any obvious money, would your organization go for it?

I selected a sample of 180 files. In one set, I left all of the HTML tags and line-wrapping as they have been; in the other set, I pulled out raw, unwrapped text without HTML tags. My assumption was that the translation memory tools would find more matches in the raw, unwrapped text than in the formatted text.

I cannot yet figure out how or why – let alone what to do about it – but the matching rate dropped as a result of this experiment.

This is, as they say in American comedy, a revoltin’ development. It means that the anticipated savings in translation costs won’t be there – though I suspect that the translators themselves will spend more time aligning and copy-pasting than they will translating – and that I’ll have to demonstrate process improvement elsewhere. If I can find an elsewhere.

True, the localization vendor will probably spend less time in engineering and file preparation, but I think I need to demonstrate to my client an internal improvement – less work, less time, less annoyance – rather than an external one.