Is Your Localization Expertise Really Vertical?

Your prospect says, "How do I know that you can really do a good job localizing my product?"

Well, how are you going to convince him?

I'm writing a paper for a small localization vendor right now, and we're coming up against that issue. The vendor has identified a prospect in a specific vertical industry - real estate development - that needs to get its translation act together, but the prospect is new to translation. And when humans don't know very much about a new product or service they need to buy, they tend to look for high-level things in common with vendors: common friends, common industries, common schools, common playgroups.

So the prospect will be comfortable if it can see the names of some big, flashy players in the real estate vertical for whom the vendor has done work. Unfortunately, the vendor does not have those names on its client list.

The vendor does, however, have a long track record of solving exactly the kinds of workflow and translation quality problems that afflict this particular prospect. Still, the prospect wants the warm fuzzies that come from knowing somebody else in its industry has been through this with this vendor before.

We're hoping that the paper will - in plain language - distract the prospect from the name-game and get it to focus on the fact that its hair is on fire, and demonstrate that the vendor has the workflow, the technology and the global reach it will take to fix the prospect's translation problems. (It also has the translation expertise, and we're going to mention that as well, even though we in the industry know that just about every vendor can reach just about every translator.)

Think about your sales presentations, your marketing collateral and the content on your Web site. Do you bother to tell a different story from one industry to the next? How do they differ? Do prospects accept it, or are you still losing projects because you don't have the names?

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.