Localization Project Management Log

…but we don’t.

At a recent trade show, I was trying to come up with new kinds of content for an industry colleague who wants to attract more attention, but it occurred to me that most (not all) customers today want the same things they wanted from translation vendors in the 16th century: higher quality, lower prices and shorter turnaround. Vendors have always wanted to raise the game by becoming strategic business partners, but that’s like pushing a rope because Most People Want Localization to Go Away.

Maybe every industry faces the same demands, but it’s not very fertile ground for 21st-century social media campaigns, is it?

What are you going to offer that’s different from what your competitors are offering? How are you building the unique relationship with your “following” that successful social media requires? Are you even trying to exploit social media to get deeper customer engagement; something beyond the traditional exchange of translated words for money?

Sure, localization is a necessary evil in many organizations, but how do you engage with:

• your current customers to keep them as interested in you as you are in them?
• prospects, so that they remember you fondly when the time comes to spend localization money?
• your competitors’ customers, and get them to remember you when they’re ready for a switch?

What does it take for them to not want you to go away? For them to be glad to hear from you, to miss you when you’re away?

Would you do business with a language service provider (LSP) that didn’t use translation memory?

Let me ask this a different way: HOW would you do business with an LSP that didn’t use TM? Even in the 21st century, this could happen to you. It happened to me.

One client acquired a smaller firm with a narrow, vertical technology. After the dust had settled, we started going through the localized assets with the team from the acquired firm:

• Source and target software strings – check
• Source and target documentation files – check
• Source and target Web files – check
• Glossaries – a bit weak, but check
• Bilingual (.ttx) files – “Why would we have those?”
• TM databases – “We don’t have those. You’ll have to ask the vendor.”

So I did.

“We don’t use translation memory,” came the answer.

This was not a one-person storefront in downtown Bogotá. This was a company with offices in multiple countries, and it really should have known better. I picked the phone back up off the floor and continued the conversation.

“How do you been performing leverage and analysis from one version to the next all these years?” I asked.

“We use some text diffing tools. We find it’s faster, and we don’t have to deal with the learning curve of TM tools.”

“What about bilingual files?”

“We don’t have those. We translate right over the original text.”

“I can’t believe that, in this day and age, you’re not using TM,” I said.

“It all works out,” they chirped. “Now, shall we talk about our next project with you?”

Naturally, I was not keen to pursue this relationship. I would not work with an LSP that doesn’t use TM, but unfortunately, I had to. Because they had been translating deeply technical content for years and new the terminology inside out, any advantage I’d have gained by switching to a vendor who at least knew how to spell “TM” would have been wiped out by the risk of lost translation quality. I didn’t want to die on that hill, so I figured out a way to live with the vendor.

So, how would you do business with an LSP that didn’t use TM? Here’s what we did:

• We made sure that we had electronic versions of source and destination text for all projects they’d done.
• We asked the LSP to send us anything we discovered we didn’t have in electronic format.
• While the LSP finished up their final project for us, we started looking for another provider accomplished in the art of aligning files, with a good reputation for project management and translation quality. We explained the situation – didn’t name any names – and figured the new provider would learn plenty about the product, technology and terminology by doing the alignment.

This is still a work in progress, but we’re putting as many words as possible between us and the vendor who doesn’t use translation memory.

Just remember: they’re out there.

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.

Have you had to localize mobile applications yet? What’s your favorite part?

They’re a breed apart, these mobile app developers. The familiar model of handing off pure resource files, localizing them, then building them back into the executable doesn’t appeal to them somehow, at least not in my experience.

They are fond of pulling the strings out of resource files, placing them in a spreadsheet with copious comments, and asking us to put the translations in Column B. It doesn’t matter much to the localizers, but I think it results in more work for the developers.

These projects put the translators at something of a disadvantage in other ways:

• In the ancient days of static, 80-character line lengths, translators often had to ensure that their strings contained no more characters than the original text. Mobile applications are similarly starved for UI real estate, but this time, length is measured more often in pixels than in characters, a metric difficult for most translators to work with.
• There is still no context for a translator working on a batch of UI strings. What’s worse now is that the text in many mobile apps is sparse to begin with, and it’s rare that the translator can run the app to get the context for strings like “Up” and “Done”. We pester our clients to provide screenshots, functionality descriptions, requirements documents, and anything else to help the translators.
• The studio isn’t easy to work with yet. With PC-based applications, localizers figured out how to build and test resource DLLs themselves to shorten the L10n QA cycle, instead of bugging clients’ engineering teams all the time. It will be a while before localizers adopt the studios and toolkits used by mobile app developers, because there are lots of them.
• Phones and mobile devices are in scant supply, and the localization process is at the bottom of the food chain. How can the localizer perform proper L10n testing on the device, when the client only has one phone – or none at all – and everybody else needs to use it? (Shameless plug: Our client NSTL performs L10n testing for situations like these.)

We’ve done several mobile app projects for a couple of clients since 2002. They’re rather labor-intensive – especially before and after the localizer gets involved – and it always feels like making a watch: lots of small parts, small tolerances and high demands.

How do you get along with mobile app localization?

If you’re working client-side, how many words have you paid for that translators didn’t even need to touch?

I posted a couple of weeks ago on translatable words that vendors may miss in analyzing files. Alert reader arithmandar commented that slide decks can be even worse, if there is a lot of verbiage on the master slide that does not get easily captured (although Trados finds these words, according to him/her). Flash is another story altogether, and arithmandar’s recommendation is that a Flash engineer should probably perform the analysis.

The other side of the coin is also unpleasant, but for the other party: Clients can hand off vast expanses of words that nobody will translate, artificially inflating the wordcount and estimate.

• Code samples – If your documentation contains examples of code used in your product (e.g., in an API reference), there is no point in having that included in the wordcount, because nobody translates code.
• XML/HTML/DITA/Doxygen tags – I hope your vendor is parsing these files to ignore text (especially href text) in the tags. Otherwise, not only will you get back pages that won’t work worth a darn, but you’ll also be charged for the words.
• Legal language – Some companies want their license agreements, trademark/copyright statements, and other legal pages left untranslated. (Usually these are American companies.)
• Directives – Certain directives and warnings apply to certain countries only. The documentation for computer monitors and medical devices often contains a few pages of such directives, which appear in the language of the country requiring them. There is usually set language for these directives, so free translation is not appreciated; have your colleagues in Compliance obtain the language for you, paste it in yourself, and point it out to your vendor.

Mind you, there are costs associated with finding and removing all of these words: Do you want to spend time extracting the words? Do you want to hire somebody to find and extract them? Will your savings offset those costs?

If the words to be ignored add up to enough money – as they often do for a couple of our clients – pull them all into a text file and send them to your vendor with instructions to align them against themselves for all languages in the translation memory database. That way, when the vendor analyzes your files, the untranslatable words will fall out at 100% matches.

Do you have ideas on how to handle such text?

What’s more fun than having to rush your work? Rushing your work in multiple languages, of course!

This week, one client needed a couple of mid-length documents (totaling 5,000 words) translated from Spanish to English. Once they had read them and prepared answers, those answers (about 9,000 words) needed to be translated from English to Spanish. The turnaround was 5 workdays from first handoff to final approval, with plenty of text changes in the mix.

Are you familiar with the better-cheaper-faster triangle? Any kind of work puts you in the middle of that triangle, and the closer you get to any corner, the further you drift from the others. You can even figure out a way to get two of these qualities, but you can’t have all three at the same time. (No, really; you can’t.)

We spent a lot of time on that triangle this week, but we were the only ones who saw the “better” corner. The client was thinking only in terms of “cheaper” and “faster,” so we had the privilege of thinking “better” for them. I proofread the translations as they were handed off, and they were a long way from “better.”

Mind you, they weren’t awful – well, actually, one of them read like the English instruction manual to 1967 Datsun – but it was obvious that they hadn’t had a good scrub by a translation editor. Still, if you’re after cheaper-faster, or even just cheaper, there’s not much room for an editor.

The vendor’s project manager explained that they had had to break the job into pieces – certainly among translators and maybe even among sub-vendors – to meet the deadline, and that that might explain some terminology differences. It did indeed explain them, but I’m the one my client would have barbecued if we hadn’t introduced a bit more “better” to the mix.

Of course there were rush charges, and the clients understood why. That didn’t prevent them from sprinkling in text changes all along; it probably encouraged them, since they wanted to get their money’s worth.

So, what would you have done? Would you have delivered the translation with a caveat emptor concerning translation quality, given the time-squeeze? Have you ever done that? How did the client accept it? Which is your favorite: better, cheaper or faster?

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?

“There are still a zillion people who don’t know about localization,” the sales representative of the localization company told me. “Can you believe it? After all these years?”

Yes, I suppose I can. We can make sales calls and deliver presentations on the most efficient ways to localize until we’re all ready to retire, and there will still be executives, companies and entire industries that haven’t gotten the memo.

It’s refreshing in some ways, and it keeps us from getting lazy. It reminds me of the ISDN craze around Internet access back in the mid-1990′s, before cable and DSL made our choices simple (at least in the USA).

ISDN, or Integrated Services Digital Network, was a high-speed alternative to dial-up, but the phone companies were not very successful in taking the service from the early adopters to the early majority. The acronym became redefined as “I still don’t know,” because most people couldn’t understand the service well enough (or afford it, for that matter) to see how it would benefit them.

The upside: There are still, and will be for a long time, opportunities to sell translation and localization services. As soon as all of our customers know about localizing products and how to do it efficiently, they’ll turn to The Next Thing, such as John Yunker’s Web Globalization Report Card threshold of localizing the Web site into 20 languages. We won’t run out of work, provided we stay a few steps ahead of our customers’ requests.

The downside: We may spend a little less time educating new clients, but we’re not completely out of the hand-holding business yet. Salespeople will still need to update their presentations and drag an engineer or project manager to that second-round meeting with the prospective client.

Just be sure to stay on top of localization developments and techniques so that you don’t have to answer a prospect’s question with “ISDN” (I still don’t know).

“Why don’t we have our Web site localized?” my business partner asked. “We’re in the business, and a localized site would show that we’re willing to put our money where our mouth is.”

Excellent question. Why not get our site, or at least the pages that pertain to localization, localized? So I looked into it.

It was going to cost about US$2000 per language, when all was said and done, so I asked my partner if he’d be willing to split the cost with me. Perhaps you can guess his answer.

It was an interesting issue, though. Assume that a prospective customer, who doesn’t know much about the industry, goes shopping for a vendor. She finds a vendor whose site is in only one language, and another whose site is in eight languages. Which vendor has more credibility, especially to somebody who doesn’t know (or even want to know) a lot about localization?

Mind you, I’m not completely representative of the entire industry. I’m not a “language service provider,” so that bit of credibility is of no great advantage to me. Still, it brings up the old chestnut about the cobbler’s children running barefoot: Isn’t it odd to be in localization, yet not have a localized Web presence?

My rationale, aside from the expense, is that almost nobody who would want our services would want to read about them in any other language besides English. That’s probably the case for almost everyone in the American localization industry, where the dominant language conveniently matches the world’s current lingua franca. Other languages just confuse most Americans anyway, so one could argue that it would be a needless distraction in the sales cycle.

What do you think your customers and prospects want to see? Can you get by with your marketing presence (Web, collateral, datasheets) in one language?

If you enjoyed this article, have a look at “Why Localize at All?“

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