What's in Your Localization Kit?

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?

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.

Changing Your Vendor - Not as Easy as Changing Your Shirt

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

"Why are you charging me for that?" - Part 2

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"

Who's in trouble: the Localization Vendor or me?

The localization estimate has come back on the HTML files in the API Reference, and it's as ghastly high as I'd feared.

The vendor's project manager does something clever with these thousands of files: she uses SDLX Glue to glue them together into six or seven batches of several hundred files each. That way she avoids carpet-bombing the translator with jillions of files; this also keeps the translator in the translation business and out of the file management business. After translation, the project manager un-glues them using SDLX Glue and hands them off internally for engineering, QA, etc.

The downside to this technique is that the TM analysis comprises only the six or seven files. I can't see down to the level of granularity I want unless I ask for a special analysis down to the file. They don't mind doing it for me, but it's not in their regular workflow and I have to wait for it.

Anyway, the count of unmatched words is preposterously high, and I'm pretty sure it's due to changes in the scripts that extract the HTML from the header files. Sentences and segments in version 4.0 don't match those in the last version because of things like double line-feeds and mucked up HTML tags.

I need to have a deeper look at the original English HTML files and bucket them for handoff. BeyondCompare shows me that the text in some files hasn't changed at all, and I'll need to spoon-feed these to the vendor.

Either that or get shot down when I take this estimate up to the third floor for approval...

The Lonely Localization Manager

It's a bit strange, the way in which I get my work done.

Naturally, I play the role of localization manager and primary contact at developer meetings, and I manage budget and schedule for several projects at once. I've become the lightning rod for issues ranging from character sets to encodings to what-do-these-Chinese-characters-say. All in all, most localization issues are pretty well in hand because I've been able to manage them in a way that conforms to best practices, with a bit of experimentation thrown in to see how much better we can make things.

I suspect, though, that most localization managers who might read this have teams and staff and reporting structures. I would bet they also spend more time scrapping internally with development managers, QA and upper management, struggling to make localization conspicuous and wildly successful. I just make it work.

As localization manager for a software company in the early 1990's I went through that. I get a lot more done this way, and I enjoy it more.

There was that exception last year. I had a client that drove me bonkers because their entire corporate culture was geared to nothing more than tolerating localization, and that with a clothespin on their nose. Wish I'd been blogging during that engagement; it was a wild ride.