Your Unique Value Proposition

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.

The Watchmaker Localizes Mobile Applications

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?

Wordcount Woes - Part 2

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?

Better-Cheaper-Faster Localization

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?

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?

ISDN (I still don't know) about Localization

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

Web Localization and the Cobbler's Children

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

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.

Making Sense out of Outsourcing Localization to China - Part 2/2

[Continuation of last week's post, Part 1]

Since it was my charter to make this offshored localization project work, we built checkpoints into the project to detect problems as soon as they arose.

We scheduled bite-sized chunks of translation, engineering, layout and editing work early in the project, then handed them off for review in our client’s in-country offices. We established twice-per-week conference calls with the vendor’s team to reinforce the decisions we made in e-mail threads. To overcome low TM matches and shorten the project schedule, we sent source and target files from previous projects for realignment in TM. We agreed mutually on a format for weekly reports that would highlight project status without becoming onerous. In short, we followed every prescription for a successful localization project, and we followed them more carefully than normal.

Our client’s Korean office has expressed satisfaction with the final product. The decision-makers, pleased that nothing went awry – at least, nothing that required their intervention or remorse – asked for a post-partum on the project, in which I underscored these points:

· It was a pleasure dealing with the vendor. They were prompt, courteous, efficient and unequivocally determined to making us happy.

· Even with the short time allowed for the project, they brought to our attention errors in the source materials and they addressed what they considered pre-existing translation issues.

· Their end of the conference calls was noisy to the point of distracting. Several of them in a meeting room with poor acoustics talking into a cheap speakerphone made for frustrating encounters twice a week, regardless of whose bridge we used. The project succeeded in spite of it, but it struck me as a poor choice of places to save money.

· It became apparent that they were cutting corners in ways that experienced LSPs don’t bother trying to cut them (rogue copy of TM software; use of a shareware help compiler on a project that depended on features unique to RoboHelp; testing on Windows MUI instead of native localized OS). I can overlook some things like this, but I’d rather not have to.

Our client had already localized this product into Korean over several versions for a number of years, qualifying it as a sustaining effort. Vendors in China and India have done a brisk business in sustaining engineering, especially for large IT companies with legacy code bases. Naturally, they are turning the corner towards new product engineering, which, like localizing a product for the first time, demands more of the relationship between client and vendor.

Recommendation: If your team is sufficiently aware of what it takes to localize your product, and has a history of successful localization, then testing the waters with a Chinese or Indian vendor in 2008 should be among your options. If your organization is new to localization or must entrust the process to someone who is, this might prove rash. In no event, however, should you simply find the lowest price, lob your product over the partition and hope for the best.

If you enjoyed this post, please read the related article, "Offshoring and localization projects, Part I."

Making Sense out of Outsourcing Localization to China - Part 1

If you have not yet tested the waters of offshore LSPs, consider making 2008 the year in which you take the plunge. You know you are going to do it sooner or later, and if you don’t, your successor will, so you may as well learn the lesson for yourself.

In 2007, one of our clients embarked on a localization project with a Chinese vendor. This brought me, in my role as consulting localization project manager on the client’s side, onto the leading edge of the project. Misgivings? Yes, I had a few:

· The company had no visible qualifications as a localization vendor, though they had devoted lots of Web space and marketing to testing, data analysis, application development, sustaining engineering, payroll processing, helpdesk and data mining. How can you be very good at anything when you specialize in everything?

· Against the same request for proposal, the company’s bid on the project was about 25% lower than that of two other Western LSPs. It didn’t help that they misread the RFP and omitted a big chunk of work, but even if they’d included it, they would still have been 15-20% below the other vendors. What kind of quality would we get for a price that low?

· The target language was Korean, not Chinese, which meant that, as low a price per word as they were offering me, some vendor in Korea was almost certainly offering them an even lower one. What caliber of linguistic talent could we expect?

· Our client imposed a project deadline bordering on the preposterous, which annihilated precious time I wanted the vendor to devote to editing and QA. Midway through the project the deadline changed to allow some more time, but it had already introduced a great deal of stress.

· The lingua franca of the project was English (because I don’t speak Chinese). While the vendor’s efforts were valiant, their English was weak, and I foresaw this as a problem even before we had awarded the project.

· Replete as the Western news media were in 2007 with recalls on Chinese toothpaste, toys, cots, tires, medicine, pet food and other products, it was easy to tar this company/industry with the same brush and worry about their level of quality assurance.

Despite these carefully articulated misgivings, our client’s decision-makers had already made up their mind (and corporate direction) to award the project to the Chinese vendor. So, since it was my charter to make it work, we built checkpoints into the project to detect problems as soon as they arose.

I'll describe these checkpoints and the upshot of the project in next week's post.

If you enjoyed this post, please read the related article, "Offshoring and localization projects, Part I."

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

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?

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

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

Have you ever asked your localization vendor this question? Or, if you're a vendor, has any client ever asked it of you?

For a few clients, we manage large documentation projects, notably HTML Help and Robohelp localization. When the vendor translated 800 HTML pages for version 1.0 of the product, a particular client swallowed hard and paid for all non-matches, because it was the first time localizing the product.

By version 2.0, the Help had grown to 1400 pages. Many of the original 800 pages had no translatable changes, but Trados dutifully scooped up all of those words, dropped them into the "100%" or "95-99%" buckets, and the vendor charged us for them, even if at a greatly discounted rate.

"Why are you charging me for that?" I asked. I'll have more on this topic in an upcoming post, but for now:

If you're on the vendor-side, do you have a good answer for that question? If you're on the client-side, have you ever received an answer to that question that satisfied you?

Acceptance criteria for Localization

Have you ever gone to the extent of developing acceptance criteria for a localization vendor's deliverables? Beyond that, have you ever sent a vendor an acceptance letter summarizing these criteria, and grading the vendor on each point?

After years of my simple handshake-and-phone-call approach to acceptance, one of my enterprise clients asked me to develop and communicate these criteria formally. It didn't require too much effort, since I knew what I had liked and disliked about the vendor's performance all along. Here are the points I drafted:

PERFORMANCE

• Responsiveness: You attended all conference calls and apprised me in a timely manner if you were unable to attend. You responded to e-mail very quickly.
• Delays, schedule: You reported only a couple of delays on the project, none of which was more than two workdays in length. In the main, you maintained your schedule day to day and week to week.
• Weekly reports: Your weekly reports were punctual and informative. They helped me to communicate accurately the status of the project to other members of the team at BigCorp.
• Issues, questions: Your process for moving the translators' questions and my answers back and forth was simple but adequate.

TRANSLATION

• Quality: Preliminary reports show that our customers were satisfied by the translation work.
• Bug fixes: You incorporated feedback from the reviewers and me as we requested.

DELIVERABLES

• On-time delivery: You delivered all files to us in a timely manner. You delivered the final files 2-4 calendar days ahead of the final deadline.
• Project files: After giving us the main deliverables on time, you performed housekeeping on the supporting files and delivered them to us.

Frankly, I left out a few things, like the fact that conference calls were arduous because of their phone system, and the rather attention-getting directory that appeared on our FTP site one morning labeled "Trados_crack". But the point of the message is to convey acceptance, and it serves that purpose well.

Did I leave anything out? Let me know.

Offshored, outsourced localization blues

I don't quite need to eat crow over this, but let's put spin on it and say that I'm happy to be proved wrong.

Three months ago a new client insisted on pushing a Korean project to a one-stop-shopping Chinese offshore development house that does everything from running datacenters to debugging your Javascript. "We need to explore new partners," they told me. "Besides, they can do the work for much less money."

I raised the usual gamut of concerns, from the vendor's lack of linguistic credentials to the project manager's English skills, but I knew my client had already made up his mind, and just wanted me to nod and make it work. And, as I blogged a few weeks ago, I have no doubt that the offshore houses in China, India and elsewhere in the e-developing world will figure out how to make this model work after initial glitches. After all, we here in the West did.

Just to spice things up, my client leaned on the Chinese vendor to deliver about two weeks sooner than I thought prudent. I don't know why he insisted on this; there was no promise-date to our Korean customer, and I thought it was a recipe for slapdash QA and diminished translation quality. Nevertheless, the vendor agreed, and began logging weekend hours to meet the deadline.

The upshot of the project is that the vendor handed off final deliverables about 3 days ahead of the already ridiculous deadline. I am impressed, the client is pleased, the vendor's project manager is still recuperating, and everyone seems to have gotten what s/he wanted. The vendor was very responsive throughout the project, knowing full well that this was a litmus test for bigger projects to come. Our in-country reviewer claims that the translation is on par with previous Korean translation (read: We're not crazy about it, but we'll put up with it), which is an important criterion.

This vendor is part of a very large Chinese company, and that probably helped. They could marshal resources and expertise from elsewhere in the firm to meet the demands of this project. A smaller vendor might not have had that advantage, so this strikes me as an important point in evaluating an offshore vendor.

The experience reinforces my First Law of Project Management:

"Only those who demand the absurd can accomplish the impossible."

Is your new localization vendor working out?

Changing localization vendors can be stressful. It's an entire "getting to know you" process you would rather avoid, but sometimes you have no choice. Like having wisdom teeth removed.

Here are some points for evaluating the fit of your new vendor.

On the downside:

1. Are there truncated strings in the software they send you? They should have reviewed these and should not send you software with such an easy problem to resolve.
2. Do they speak and write good English? Conference calls with people who don't (or won't) speak English are frustrating and unproductive.
   
3. Are there any "oops" moments early in the project? One new vendor focused on my detailed description of the changes in a document, and assumed that they were the only difference in the new version. They had overlooked 8,000 words in new files I had handed off in the localization kit. Oops.
4. Are you customers (internal or external) satisfied with the quality of the translation from the new vendor? If not, you need to address this in a hurry. I pointedly asked our Korean office what they thought of the quality of the new translations compared to the old, and they replied, "The quality seems to be about the same as before." Perhaps a bit less than eloquent praise, but it was important for me to know.
   

On the upside:

1. Are they finding mistakes in the original English version and sending them to you? Sometimes these take the form of "This sentence seems corrupted, please explain." If you have the bandwidth and patience for it, you'll see that these are actually prefabricated bug reports that cost you almost nothing to submit, with the benefit of improving your product (especially the documentation, which is where most such problems lie).
2. Are they helping you think about long-term improvements to your international product process? Vendors are in a position to suggest internationalization (I18n) techniques for your product that will prevent you from maintaining several code bases, for example. Does the new vendor have the perspective and degree of experience to tell you, "You know, if you make each of the control labels the size of your largest language, you can use the same dimensions universally, and we don't have to charge you so much for resizing them each time."
   
3. Are they cleaning up pre-existing messes? Old messes die hard, and you can be sure that your translation memory databases have plenty of them. A new vendor comes to them with a fresh perspective and can help you clean them up, especially if it helps them to do their work better.
   

The more experience you have with new vendors, the bigger your own list of evaluation points will be. The sooner you deal with them, the less trouble your project will be for you and for the vendor.

Like wisdom teeth.

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.

Getting along with your (vendor-side) Project Manager

Have you ever called time-out in the middle of a project and asked for a different project manager?

You should consider this your inalienable right as a customer.

Vendor-side project managers are, of course, people too, subject to the same grinding, erosive workplace influences that all of us are. Probably more, really, because they serve so many masters and spend a lot of their time currying favor with QA staff, translators, editors, desktop publishers and their own managers, not to mention multiple customers at a time. So if they are grumpy on the phone or unresponsive or slip deadlines occasionally - the key word is "occasionally" - it's just part of life.

Sometimes, though, the chemistry is just not right. You're the manager on your side and they're your primary point of contact, and these are gears that need to mesh smoothly. How long do you want to work with somebody you don't enjoy working with?

• The first necessity is to meet the person who will be your project manager before you award the project to the vendor. A face-to-face meeting is preferable, but if phone is the best you can do, that's better than nothing. No sensible vendor would decline your request for this.
• Once the project is underway, teach your project manager how you want to be treated. Do you want to exchange cell phone numbers or even home phone numbers? Do you want to set up IM or Skype? Do you want weekly reports? On which day? What information do you want in them? Do you prefer to handle as much as possible via e-mail, with phone calls only when necessary? Do you want regular project status calls? The manager, to some extent, is in business to make you happy, and teaching him/her how you want to be treated as a client is a small investment in what could become a long-term relationship.
• Gauge the project manager's competence. Beyond an introductory training session on your product, if you're holding the manager's hand a lot, that represents time and work you shouldn't have to expend. Is the manager a localization newbie? Some newbies are lower-maintenance than others, and if you have to take one, that's the kind you want.
• Most of all, is the project manager delivering on promises? Any manager has a lot of upstream influences and a change in any one of them could blow a delivery to you, but if it happens repeatedly, then you have the wrong person running your project.
• Finally, what kind of end-of-project etiquette does the manager exhibit? Is there a post-partum meeting to review how the project went? Do you just get an invoice and no handshake? Does it appear that the manager has the business sense to cultivate the relationship with you for future projects (assuming you haven't been a bear to work with)?

If you're losing sleep over issues like this, you need to call the account manager and suggest a change of project manager. It's up to you whether you want to cite chapter and verse on why it's not working out, but a simple "I need a different project manager because this one is not working out for me" will do. Any clear-thinking account manager with future commissions breathing down his neck will happily accommodate you.

Offshoring and localization projects, Part IV

"We specialize in all cars, domestic and foreign."
-Sign over auto repair shop

What kind of specialization is that? Specializing in both foreign and domestic cars means, of course, that you don't really specialize in anything. Unfortunately, that also applies most of the time to offshore software development companies who have discovered that their technology clients need, among dozens of other things, localization.

I was in a meeting with a prospect last week when this came up. A project manager who has already got the religion of offshoring was pushing to award a localization project to an offshore development "partner" in China. His antagonist, a localization purist, was arguing against the award because of the partner's skimpy localization credentials. I was a fly on the wall, hoping to manage the project whichever way it went. Their respective arguments went as follows:

"We need to work with more partners in China because we can get more done for less money. I'm not worried about their lack of localization expertise, because you can put quality controls in place to make sure they deliver a good product. Every smart technology company is growing in this direction, and we need to get partner relationships in place as soon as possible."

"That country has let malamine into the pet food manufacturing process. It has put an antifreeze component into toothpaste. Its food and drug inspectors work under a conflict of interest between big pharma and the city governments that invest in big pharma. Does that inspire you with confidence?"

"Those are low-tech examples where quality problems are hard to identify. This is software, and we can keep problems like those from ruining the project. They may not get it right the first time on their own, but they're extremely adaptable and eager to keep the business no matter what. It's a relationship we should invest in."

"They're telling the world that they specialize in all cars, foreign and domestic. Look at their Web site. They're software developers, they run a data center, they write embedded software, they do datawarehousing, they run call centers and they do data entry. What else? Silk-screen t-shirts? They say they have the capability to do four dozen languages, but how many have they really done? And have they done them in our industry?"

Don't misunderstand and don't underestimate: These companies will get it right sooner or later, and it will take them less time than it took today's prominent, traditional language service providers (LSPs). They are clever, nimble and entrepreneurial enough to focus on landing the business first and then partnering with other people to figure out how to do the work second. And who could blame them? It's a simple matter of world-flattening progress.

Are you seeing these offshore companies in your projects? What do you think of the movement towards them?

Switching Localization Vendors--Take this Quiz

Take this short True-or-False quiz:

1) You think your localization company is much too expensive.
2) Your other contractors or in-house teams cannot work with your localization company.
3) Your in-country offices are complaining about the translation.
4) Your overseas customers are complaining about the translation.

If you scored 2 or more True, you might look into peeling off a language and trying a new vendor out. If you scored 1 True, you should have a chat with your vendor and work out the problem. If you scored 0 True, you are in the localization minority and should count your blessings.

Making a vendor switch involves a lot of re-plumbing and re-education. If your vendor is charging a fair price for good, steady, reliable work, and they're making you look good (or at least, they're not embarrassing you), there's plenty to be said for that.

Keep in mind also that this is a relationship. The vendor won't necessarily get it right the first time--neither will you--but if they show improvement, and they're willing to work with you on making things better, you have the beginning of a beautiful friendship.

Translation non-savings, Part II

Again I ask: How far will you go to improve your localization process? If a big improvement didn't save any obvious money, would your organization go for it?

I selected a sample of 180 files. In one set, I left all of the HTML tags and line-wrapping as they have been; in the other set, I pulled out raw, unwrapped text without HTML tags. My assumption was that the translation memory tools would find more matches in the raw, unwrapped text than in the formatted text.

I cannot yet figure out how or why - let alone what to do about it - but the matching rate dropped as a result of this experiment.

	Original HTML Formatting and Tags	Unwrapped, unformatted text
100% match and Repetitions	65%	51%
95-99% match	9%	14%
No match	9%	15%

This is, as they say in American comedy, a revoltin' development. It means that the anticipated savings in translation costs won't be there - though I suspect that the translators themselves will spend more time aligning and copy-pasting than they will translating - and that I'll have to demonstrate process improvement elsewhere. If I can find an elsewhere.


True, the localization vendor will probably spend less time in engineering and file preparation, but I think I need to demonstrate to my client an internal improvement - less work, less time, less annoyance - rather than an external one.

Rights to the Localized Product

You need to keep an eye out for TRM ("translation management rights," a term I've just coined), because they may not be enforced just for hopeful thinking.

If you're creating software, documentation or a Web site in English, who owns it? Your company, of course. True, the words that went into the product came out of your brain and fingers, and not those of your company, but it's work you've done for hire, so your company owns it. This is probably spelled out in your employment agreement.

Most of the time, this will apply to the localized version of your product as well, but it's worth being clear about it with your vendor. True, the translated words came out of the brain and fingers of the translators, but you wouldn't want the translators to own it even if they were in your employ, let alone when they're outside contractors, which they usually are.

I hadn't thought about this for ages until a recent project took me to the site of Association of
Finnish Translation Companies - SKTOL. Since a prospective vendor referred to them in his estimate, I took the time to read their General Terms and Conditions and found the following among them:

7. COPYRIGHT

The company holds the copyright as referred to in the Copyright Act (404/1961) to the translated text unless otherwise agreed. The company assigns the right of use to the translated text in the extent and for the purpose required by the commission.

Unless otherwise agreed, the company holds all rights to the translation memories generated in conjunction with the work it carries out.

This struck me as odd, and either stunningly progressive or hopelessly out of date. Of course, they don't claim "exclusive copyright" or "exclusive rights to translation memories," so they wouldn't likely withhold either from the client, but these struck me as singular rights for a contractor to try and claim.

None of my clients would have any part of this. Would your company?

The Localization Consultant Amid His Buckets

After a few hours hunched over Beyond Compare, I've sorted the deltas between version 3.9 and version 4 into several buckets:

1. New Content, based on filenames appearing for the first time in this version - 718 files
   
2. Content Unchanged, except for the datestamp at the bottom of the page - 727 files
   
3. Content Changed, but with changes that do not require translation (HTML tags, formatting) - 1517 files
   
4. Other, including content with translatable changes and anything else - 319 files
   

My hope is that the vendor can hand off to the Japanese translators only those pages in which there is real translation work, then internally take care of #2 and #3 with search-and-replace and other engineering techniques to bring the 3.9 pages into parity with the 4.0 pages. For that matter, I could probably do the engineering myself, except that: 1) it's boring work; and 2) the vendor needs to update translation memory with the results.

We'll see how this goes. It doesn't help that the original English files have a lot of formatting errors in them, and that errors in the Perl scripts wipe out the content on several dozen pages and toss them into the CHM blank.

Doing the Localization Vendor's Work?

Sometimes I know too much about this process.

Or, maybe I'm just too nice a guy.

To make things easier for the vendor (and cheaper for me) I've resolved to carve the 3200 HTML files in the API Reference CHM into different buckets, depending on whether and how much they require translation vs. engineering. Naturally, the ultimate arbiter is the Trados or SDLX analysis that the vendor will perform, but I've already mentioned my concern about false positives and need write no more on the topic here.

My tool of choice is the extremely capable Beyond Compare which, at US$30, is worth it just to see how well thought-out a software package it is. I compare version 3.9 files against version 4 files, tuning the comparison rules to groom the file buckets as accurately as possible.

The distribution is not perfect, if for no other reason than because its first level of triage is the filename and not the file contents, but it's better than guessing, and it's much better than thousands of false positives.

Once I've gone through the files, I'll have a better idea of how to label the buckets in a way that meets both my needs and those of the vendor.

At least, I think I'm being too nice a guy. Maybe this is just a big pain for the vendor, and they're too polite to inform me of that.