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?

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?

Low Quotation - Four Questions to Ask

Have you figured out how to add value, even when you don't get the job?

A client asked us to look into quotations on taking some marketing materials in MS Word and Adobe InDesign into Traditional Chinese. Our preliminary word count was around 15,000 total, and we spent time educating the client on how to deal with all of the graphics that had embedded text. Since they were marketing materials for an upcoming trade show, we put on our best neckties and helped the client think through the project as far as possible.

As we were preparing to analyze the files for a proper quotation and statement of work, I received this message:

"I wanted to let you know our Taiwan office has located a local translator that has quoted us $1800 for this job. Do you think your quote will be a lot higher? If so, there's no need for you to proceed. Just didn't want you to spin your wheels."

We suspected our quotation would be 3-4 times higher than that. What would you do? Would you:

1. Doggedly pursue the business, refusing as a matter of principle to be low-balled?
2. Upbraid the prospect for falling for such a low price?
3. Do nothing, considering it beneath your dignity to reply?

You'd have good reasons for any of these responses, I suppose. I gave it a good, long think over last weekend and replied Monday:

"That is quite low. If price is your paramount criterion, then you'd better go with that quote. In any event, you should make sure it includes:

• second set of eyes (besides those of your in-country reviewer)
• translation memory
• glossary (terminology list)
• desktop publishing + PDFs

Let me know how it goes."

We in the industry stand to gain nothing by scaring prospects, but since power in the Web 2.0 age seems to come from a delicate balance between giving everything away and keeping your families fed, perhaps our real value-add lies in helping prospects ask the right questions.

Your thoughts?

If you've enjoyed this article, you might like another one I wrote called "Why Are You Charging Me For That?"

Localization - Investment or Expense?

Would you rather expend or invest? Would your company rather expend or invest?

You walk into a pastry shop, buy a slice of cake and eat it. That's an expense because it doesn't last long and you can't use it to make anything else. You walk into a bank, buy a certificate of deposit and reap interest a few months later. That's an investment because it has some durability and you use it to make something else (more money).

A new client is testing the waters in Europe and Japan. To appear serious to prospects there, they asked me for a proposal on some multimedia projects they've hosted from their Web site. It took lots of phone calls and e-mail to ascertain exactly what they expected back, then lots of phone calls and e-mail to ensure that they had sent us everything we needed to estimate costs for a full, end-to-end solution.

They're a small company with solid domestic revenues and negligible overseas sales to date, so they felt sticker shock at the $3-4000 per language that this was going to cost. One of their executives tried to think nimbly: "See whether they can just do the voiceovers and give them to us. We can have our in-house editors replace that layer in the media files."

I don't mind nimble thinking, and I appreciate her attempts to save money, so I won't go into the many technical and quality-related concerns that this approach violates, but when I sent an adjusted quote, I wrote, "I understand that you had $1500/language in mind, but the original English media probably cost a good deal more than that, and you've likely forgotten what you spent on them because of how many prospects have clicked on them. I encourage my first-time clients to regard this is an investment, not an expense. If you choose your overseas markets and partners carefully, and handle translation and localization correctly from the start, your ROI will not be long in coming."

Do you agree? Have you spent time trying to convince your company's executives that good localization practices are an investment, not an expense? What's your favorite argument?

If you enjoyed this article, you may enjoy another one called "Why Localize at All?"

Where do your glossaries live?

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?

Localization - Top 5 Web searches

What is your most frequently used Web search regarding localization? Are there search phrases you check every now and again to see what new results they yield?

Over the last couple of years, I've tuned the keywords on this blog and on our Web site, www.1-for-all.com, for both pay-per-click and search engine optimization. I have a pretty good idea of which search topics bring people to this blog, and here are the top five topics, with my comments:

1. Localization of HTML help projects (Robohelp, CHM, etc.). I can't tell whether people have trouble with this, or whether they're poking around to find out whether they are going to have trouble with it once they undertake it. My hunch is that Robohelp, the dominant product for creating HTML help, either doesn't do a good job creating localized help systems or doesn't do a good job in explaining how to create them. Our experience has been that double-byte localization requires a specifically enabled, separate version of Robohelp, which strikes me as silly, but perhaps Adobe has addressed this by now.
2. How much to charge/pay for translation. Everybody wants to know this. Responding to the frequency of these queries, I wrote an article called "Going Global Without Going Broke" to help people who want a few benchmark figures from which to cobble together a budget. If you're any further along than that, you should just contact a vendor, push your files to him and get an estimate. If you're a translator or want to become one, phone a localization company, tell them what you can do and find out what they'll pay you.
3. Localization project manager/management. I would guess that about half of these are vendors (a.k.a localization service providers, or LSPs) and half are companies with localization needs to fill.
   
4. Localization jobs. Most of these queries come from Ireland. There's a relatively high concentration of localization talent in that country, and perhaps a high rate of turnover as well.
5. What is localization? Again, the frequency of these queries prompted me to write articles called "Opening the Black Box." I'm glad to see people asking this question, because it demonstrates continuing and continuing interest in this specialty. At the same time, however, I notice that some of these queries come from China and India, suggesting to me that the IT shop which has just promised you it can localize your software for one-seventh the price you've gotten from other vendors, is now trying to figure out what's involved in fulfilling that promise.
   

At the other end of this list are the searches we're not seeing: questions we believe people should be asking but aren't.

From Pseudo-translation to Pseudo-localization

Do you like having teenagers handle your medical insurance problems?

Why would you have college students localizing your product?

I've posted several articles on pseudo-translation, which is a science. Pseudo-localization, or the practice of pretending you have good localization processes in place when you're really having exchange students review or--ack!--translate your product and Web presence is not science. It's short-sighted.

I can't say for sure, but I think it has to do with what most people perceive as a black box around foreign languages, especially in the U.S. We're not xenophobes, but we are by and large linguaphobes, and most of us freeze like a deer in the headlights when the prospect of dealing with a foreign language arises.

Frankly, though, it's easy to fall into the practice of pseudo-localization, especially in technology companies. Young employees for whom English is a second or third language are becoming the norm, and while their cultural diversity and mental models are a boon for product development and global reach, are they really suited to translating?

No.

Inside that black box is what people have to do to become accredited translators, and to build and maintain their reputation. They're not fussing about Web-based translation portals and fast, cheap, young translators because they want to cling to their jobs. They're fussing about it because the product quality is lousy, and most Americans don't care.

You're an American localization project manager: Have you ever been in a company for more than three months without hearing, "Why don't they all just learn English and save us this headache? Har, har, har."

Better-cheaper-faster is a triangle, and you can't cover all three corners with the same solution.

So, by all means hire that French exchange student or that Chinese H-1B to work on your localization project. But make sure you get at least one other pair of accredited eyes to review it.

Localization in the Flat World

You need to understand the localization process - even if you're in denial about it - because the world is flat (apologies to Thomas L. Friedman) and the sooner you see how the process goes, the sooner you join the ever-flattening world.

Do you see your company in the following scenario?

We're bringing a prospective new client into the flat world. Up to now, they've dealt with translations, in which somebody overseas says, "We need to be able to read this document in our own language." Recently, though, the folks overseas are saying, "We need to be able to use your product in a way that makes sense to us." The unspoken rest of the sentence, of course, goes, "...or we'll find a different one and use it."

They are on the road to localization. What's next?

1. Demystify the process. What's really involved in creating a localized product? How much will it affect this organization?
2. Identify and talk to all stakeholders. Inform them of what's coming and what will be required of them.
3. Figure out exactly what needs to be localized: software strings, documentation, help, Web pages, installer strings, sample files, etc.
   
4. Create a project plan. Much of it will be wrong the first time out, but as long as you know it's a living document, it will serve its purpose.
5. Appoint or find a project manager. The localization project needs a champion (some might say a lightning rod), because it won't all happen on its own.