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.

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?

Putting More "Sim" in your "SimShip"

How are you doing on your simultaneous shipment ("simship")? This is a common term in the industry that refers to releasing your domestic and localized products at the same time. Is your organization getting closer to simship? It shouldn't be getting further from it.

What measures have you put in place to reduce your time to market for localized versions? It's never easy to pry finalized content from writers and engineers in time to have it translated, but that's the dragon that most of us have to slay, so we focus on it a lot. How can we peel off content and get the translation process started sooner?

In the same way that eating lightly 5 times a day keeps you from getting really hungry and eating voraciously 3 times a day, we've found that handing off smaller bits of content even before they're finished keeps us from having to panic when somebody calls for a localized version.

We manage projects for a client who has the advantages of lots of sub-releases (3.1.2, 3.1.3, 3.1.5) between main releases (3.1, 3.2), and few overseas customers who want the sub-releases. (They also have the disadvantage of lacking a content management system that would make this much easier.) Even if your situation is not an exact match, you'll find that some principles apply anyway.

• The biggest nut in the product is a 3500-page API reference guide in HTML. (Most products have a big, fat component that dwarfs all of the others.)
• One month before each release, we assume that any new pages are about 95% final, so we hand them off for translation.
• By the release date, we know whether we need to release a localized version of the entire product or not. If so, we proceed to hand off all of the rest of the product for translation, knowing that there will be some re-work of the new pages handed off a month before; if not, we hand off only the changed pages.
• Thus, we almost always have pages from the API reference guide in translation. If we need them for a release, we have a lot of momentum already; if we don't need them for a release, we put the translations into our back pocket and wait until it's time for the next localized version.
  

This costs some more money than normal because of the inevitable re-translation that goes on, not to mention the hours refreshing the localization kit, and preparing files for translators. But this cost is acceptably low compared to the look of anguish on the international product manager's face when we have to say, "It will take about three months to finish the Korean version because of all of the change since we last localized it."

We also need to assume that, sooner or later, there will be a request for the product in certain languages. If business conditions change and the new translations never see release, then the effort has been wasted for those languages, but that's a normal business risk.

Right hand and left hand in localization

When was the last time upper management was more enthusiastic about localization than you were ready for? Would you like to have that problem? Are you sure?

A colleague at a very large IT company wrote me that he started as localization manager four months ago, with the direction-from-above of taking his division's products into 5-7 languages this year and twice as many in the next couple of years. Who wouldn't want a charter like that? Most of us would sell our souls to Voldemort for it.

He's discovering to his dismay that most of the software hasn't been internationalized - lots of UI still embedded in code - which will drag out the timeline quite a bit. Instead of managing localization process, he'll spend the foreseeable future managing architecture, internationalization and product. He was ready to jump on the localization horse and ride it into the sunset, but is now finding out that the horse hasn't been born yet. It's parents have barely met, for that matter.

That's the result of the right hand not knowing what the left hand is doing: the right hand promises, and the left hand has to deliver. It's not uncommon in most organizations, but in this case it's overseas offices and customers who will suffer, as if they weren't already marginalized enough.

My colleague laments, "This isn't the 9-to-5 job I was expecting."

As if.

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.

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

Localization tail wags dog

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.