Localization Project Management Log

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.

A localization kit – as I’ve come to use the term – is the 5-kilo bag of items you hand off to a vendor for localization. When properly assembled and used, the kit contains everything needed to localize and test software/documentation/Web site/etc.

The quality of the loc kit is a barometer of the client’s sophistication in and regard for the localization process.

The Best
Have you ever received or sent a loc kit of which you were proud? What did you put into it? How long did it take you to put it together?

• Software – resource files/bundles, object code, source graphics, installer scripts, start menu items and all libraries in the correct file structure required to build binaries
• Documentation – source files for text, source files for graphics in text, build structure for online help systems, list of preferred tools and authoring applications
• Web – files in correct structure, access to stage site to test translation (especially for .php/.jsp/.asp/.do- based Web content), clear guidelines about how far to translate and what to do about references to untranslated content
• Sales/marketing materials – source files (InDesign, Quark, Creative Suite), access to the printing company for proper preparation
• Multimedia – source files for Flash and movies, scripts, uncompressed QuickTime files
• Glossaries and existing TMs – assets from previous translation efforts, or at least previously translated materials (even sales collateral) whether authorized or not
• Instructions – what to translate, what not to translate, how to build the product, encodings to use, special notes for translators
• Request for Proposal/Quotation (RFP/RFQ) – target languages, timelines, expectations for the quotation

…and all of it properly internationalized.

The Worst
If a client sends a vendor a handful of PDFs and asks for the translations “as soon as possible” (most people’s favorite deadline), they probably don’t have much regard for the work involved. Most vendors can do the job from PDFs, of course, but they’re a pain in the neck (the PDFs, not the vendors) because it’s very hard to do a good job from PDFs. Without the source files from which the PDFs were made, the vendor has to create from scratch most of the things the client takes for granted in the PDFs: formatting, spacing, layout, typeface, page setup, headers, footers, margins…

Wiggle Room
Of course, perfection is not in human nature. The handful-of-PDF’ers aren’t being malicious; they’re just doing as they’re told. Over time, the patient vendor may build a relationship with these people such that their interest in localization rises and their kits improve.

And even the best of loc kits does not answer every question. We’ve been running projects from the client-side with the same vendor for years, and questions still arise. I look forward to the questions, because we can improve the loc kit based on them. In fact, I get nervous when there are no questions: I suspect that somebody is doing something wrong and is afraid to check with me.

What have I left out? Do you have a secret weapon that you put into your loc kits?

 

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.

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.

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.

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?

The experienced project manager with your localization/translation vendor approaches a new client/project by asking you, “Has this ever been translated before?” Her big goal is to discover whether there’s a translation memory database floating around, to help her translators do their work more quickly and keep your costs low, and her background goal is to find existing documents with key terms already translated and approved.

Smart companies maintain these key terms in a “glossary” or terminology list. Glossaries are far less comprehensive than translation memory because they serve a slightly different purpose: Instead of proposing a fuzzy-match translation for an entire sentence, they serve as a reference for the translators. Good translators know how to find translations for generally accepted terms like “closed-loop servomechanism” and “high-definition multimedia interface,” but if the sales manager in your Shanghai office has already told you how he likes to see the word translated, everybody will be happier if that preference is observed.

So where do your glossaries live?

“Live” is the important word, because glossaries change and grow with time. Most glossaries I’ve seen are in a spreadsheet or word processing document. While that’s better than nothing, it can suffer from decentralization, since updates don’t always make it to everybody involved in the project, and some translators run the risk of using old terminology.

One of my more localization-savvy clients makes its glossary available on its partner portal, requiring a login and password. The php-based application, which is actually hosted by a translation vendor, allows searching in multiple languages. My client deliberately does not make the glossary available for download or export; this ensures that everybody is using the same version with all updates.

I like this model. The assets reside on the client/owner’s site, and the terminology “lives” with the linguistic experts, who can easily modify it. It’s a bit more work for the translator, who would rather have a flat-file document, but overall it serves linguistic interests well. It’s tried-and-true technology built in to most computer-aided translation tools.

What are you doing with your glossaries?

Do you have manuals, resource files, help projects or entire Web sites that you’ve been localizing for several years and through several versions? Have you thought about the “permafrost” in those files; i.e., the sentences, paragraphs, pages and chapters that haven’t changed in ages?

Are you being charged for them in your localization efforts?

In my experience, vendor pricing includes discounts for segments (usually entire sentences or bits of text surrounded by paragraph markers) with high match rates to text that has already been translated. So, a new 30-word sentence at $.25/word may cost $7.50, but a 30-word sentence that does not change at all from one version to the next may cost $.03/word, or $.75.

But why are you charging me for that?

Vendors have different rationales (and they are welcome to post them here) which often boil down to the necessity to “touch” the words in one way or the other: either in engineering unchanged paragraphs into the new manual, or in translation memory maintenance, or in the human editing pass when eyes land upon them. These words are the spare tire of localization, in that they haven’t changed, but they’re still along for the ride, and moving their weight requires some modicum of additional gasoline.

As a localization manager, try explaining that to your boss.

So, if I don’t want them to charge me for the words, or for any words that don’t require translation, what should I do?

• Perform your own triage. Pull out code samples, for instance, which will never need to be translated, and hand them to your vendor in a text file. Ask that they be aligned to themselves in TM so that the words fall out as 100% matched. The translators won’t touch them and you won’t (shouldn’t) be charged for them.
• Move to a CMS. Deploying a content management system is a long-haul solution; but if this is a long-haul problem for you, look into it. With a CMS in place and an interface between your vendor and the system, it becomes easier for you and your vendor to separate matched from non-matched segments. That which is easier, should cost less.
• Give instructions, not words. If you suspect that there have been only a few changes to a 40-page manual, use a diffing tool to find them, write up the changes, and hand them off to the vendor with instructions to charge you hourly for the spot-changes. If the vendor knows exactly what to change where, it eliminates the guess work, the TM analysis, the file preparation and the engineering. This lowers your costs of localizing the book.

You should be able to have a calm discussion with your vendor about these jillions of unchanging words, and arrive at one or more methods for eliminating unnecessary work. Try to go beyond “Why are you charging me for that?” to “What can we do so that you don’t have to charge me for that?”

Interested in this topic? You might enjoy another article I’ve written called “Why are you charging me for that? – Part 1“

You know you’ve been in this line of work too long when you look at every innovation and wonder, “How are they going to localize that?”

China and India may have the growing numbers of cellular subscribers, but Japan and Korea are winning the race for edgy wireless applications, as the Associated Press/NewsEdge article cited below underscores. Still, I wonder how they’ll localize it…

DoCoMo’s prototype phone gives users fitness check
It can take your pulse, check your body fat, time your jogs and tell you if you have bad breath. It even assesses stress levels and inspires you with a pep talk. Meet your new personal trainer: your mobile phone.

The prototype Wellness mobile phone from Japan’s NTT DoCoMo targets users with busy lives who want a hassle-free way of keeping track of their health, according to company spokesman Noriaki Tobita.

I applaud this novel use of mobile technology. Life sciences and telephones are snuggling up together in many other ways, and this strikes me as a good next step in the evolution.

But how do you localize the bad breath sensor?

I don’t think they’ll be able to do it correctly from Japan; it will require a lot of in-country research. What constitutes bad breath in Japan may be a breath of fresh air in Idaho, and vice versa, and it would be hard to get it right working only from the source country.

Can Trados handle that? What extension does a bad breath profile have: .bbp? How do you qualify translators for it?

“It’s with you wherever you go, like a portable personal trainer,” Tobita said.

Does every country have personal trainers? Do they do the same thing in every country? Will I be able to tell them to go away in my own language, and have them obey me?

The Wellness phone, developed by NTT DoCoMo and Mitsubishi Electric, also asks questions to assess stress levels, and offers advice.

Now that’s nice. Are the questions the same in every country? I would bet that the definition of “stress” varies widely from culture to culture. I’ve wandered into markets in other countries that were so boisterous and nerve-wracking that I didn’t even want to buy – let alone sell – there, but what struck me as panic was just day-in-the-life commerce for those people.

DoCoMo, Japan’s biggest mobile phone carrier, has not set a release date or price for the Wellness phone and has no immediate plans to sell it overseas.

That’s just as well; we localizers need a little more time to think this one through.

Full article http://www.telecomasia.net/article.php?id_article=5956

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.