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 is Like a RipStik

 

I'm on vacation this week in Santa Rosa (Northern California), and I've dared myself to get acquainted with my nephew's RipStik.

Naturally, since I needed a pretext to post to this blog in the middle of my vacation, the RipStik reminded me of localization. Specifically, simultaneous shipment (simship) localization, in which a company releases the same product in multiple languages "simultaneously," a term that is, fortunately, loaded with shades of meaning and exactitude.

It Works, But It Looks As Though It Shouldn't

The RipStik has only two wheels. Both are 360-degree casters, slightly pitched. Once your feet are on the decks and you give yourself a small push, you move your legs - particularly the back leg, according to my nephew - to propel yourself. Having done this for only a single day now, I have no idea how I keep my balance, but I assume that it has something to do with divine intervention.

Simship shouldn't work, either, should it? You're artificially constraining something (usually the source-language product) and propelling something else (the target-language products). Yet once you're underway, management will wonder at how natural the process seems.

Don't Do It If You're In a Hurry to Get Somewhere

Yesterday I sweated and gasped for half an hour to get about 50m and back. This morning I resolved to get to the end of the street and back, which also took a half-hour. I probably couldn't get to the corner and back on a RipStik if I really needed to get to the corner.

Don't bet the quarter's international revenue on your first simship attempt unless upper management has agreed to flog anybody in the company necessary to meet the goal. You'll need a few release cycles to build up to this.

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.

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.

Putting More "Sim" in your "SimShip"

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.

I Don't Want to Localize That, And You Can't Make Me

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?

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"

Localizing the bad breath indicator

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

Right hand and left hand in localization

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.

Localization Management: One Big Bag, or Several Smaller Ones?

Are you getting to the point where you need to consider decentralizing your localization project management efforts? That decision point usually comes with growth (more languages, more products, shorter lag-times). Here are some things to consider in distributed vs. centralized localization management models:

• Trying to plant and cultivate this expertise in each group (QA, product teams, release engineering, sustaining engineering) is pretty tough. One prospect appeared to manage things in a decentralized manner like this, telling me that "the car drives itself," but I have my doubts. I've never seen any organization that did it well and robustly without a lightning rod or "localization czar" that ran around pestering people company-wide.
• Frankly, I think decentralization is difficult because, for all but the largest, best funded firms, it's just plain hard to find and keep that many individuals interested in driving international products. I suppose it could be built into the company's incentive structure, so that managers understood it was part of their charter to localize, but that wouldn't guarantee that they would actually care about it, and caring is at the heart of long-term localization management.
• Until somebody really cares about it, most internationalization/localization projects have an out-of-band feel to them. It takes a long time before they feel familiar, and the sooner everybody knows that there's somebody (besides them) responsible for putting out the Japanese version of the product or Web site, the sooner everybody can get back to work.

For these reasons - and a few others - I counsel companies to dedicate a single project manager , preferably with domain expertise, to as many localization projects as practical, rather than to expect each project manager to handle the localization aspects of his/her own projects.

That model will last a good while in most companies.

Localization on the Cheap - Get Students to Do It

Maybe you read this and became encouraged to have your products and Web pages translated over the Internet by college students in other countries:

"In April and May 2007, Palex held an English translation contest for Microsoft software and documentation. It is the second translation contest organized by the company with the purpose of stimulating interest in translation and freelance work and selecting new full-time and freelance employees. With more than a hundred applications submitted, over 70 participants - most of them students and young professionals - completed the off-site translation assignment. Those who delivered the 20 best translations participated in the final stage.

"For the final assignment, the competitors had to translate an HTML page and correct 11 localization errors in a dialog box. Although translation quality was of the highest priority, the technical background of the participants - such as the ability to handle HTML correctly and the number of localization errors found - earned additional points.

"Andrey Cherkovsky, a freelance translator, was selected the winner. The second prize was awarded to Sergey Plotnikov, a chief specialist at Tomsk Regional Energy Commission, and Rostislav Romanovsky, a third-year student at the Chemical & Chemistry Engineering Department at Tomsk Polytechnic University. Neither has ever been a professional translator. Mark Lesun, a newcomer to freelance translation, ranked third. [emphasis mine]"

So, they got lucky. Don't forget, though, that out of 70, only 20 qualified as "good," and out of those 20, only 3 took prizes, and one of them was already a freelance translator. Can you find the 3 out of 70 that won't embarrass you?

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 versus Internationalization

Do you know the difference between localizing and internationalizing? Most people can go their entire lives without knowing it, but there is a useful distinction.

You localize your product when you customize it to the needs of a particular market, usually on geographic and linguistic bounds. So if you're Toyota, and you want to sell cars in California, you need to equip them with the more robust emission control systems required by law there. Or, if you want to sell them in UK, you need to build them with the steering wheel on the right-hand side.

What you soon discover, though, is that it's prohibitively expensive to create and maintain separate production lines for California, UK and other foreign markets, not to mention your domestic market. The challenge then becomes to properly internationalize your product so that the changes needed for each market cause as little disruption as possible to your production process. You design your cars so that there is some irreducible core that is the same, no matter where the car will be sold.

This is easier said than done, but in a technology company, where production lines move extremely fast - because it's all just software - it's important to bite the internationalization bullet early and often. The alternatives are multiple, straggler code lines; separate Web sites; and unintegrated, unwieldy sets of documentation.

So, when all about you are losing their heads over localization (L10n), you can be the calm voice of reason, asking whether the product is really ready for localization yet, or whether your colleagues should pause and think internationalization (I18n) first.

(Note: The term g l o b a l i z a t i o n is also used to describe the overall process of creating products for worldwide markets. The problem, in our search-engine-optimized day and age, is that the same term applies to the assimilation of national character and identity into the worldwide market, with undesirable ramifications to the disenfranchised. It's not wrong to talk about g l o b a l i z i n g your product, but if you go searching for information on localization, don't use the g-word.)

Localization tail wags dog

Most of the time, when you're a U.S.-based company, you run the localization show. It's a matter of simple history: You created the product in the U.S. and pushed it out to other regions, so your domestic needs get met first. You may factor in their requirements so that they have a respectably localized product to sell, but by and large, you call the shots.

Not only that, but assume that your domestic sales (i.e., the sales for which you don't need to perform any localization) contribute 75% of your profit, and sales to regions requiring localization contribute the remaining 25%. This means you have both history and profitability in favor of your running the show.

Suppose, however that the tail wags the dog. Suppose that your product is developed in Egypt or Liechtenstein or Hungary, where it has 95% of the market without really trying, and that the developers are insensitive to the need for a properly run localization effort. The product is receiving strong uptake in the U.S., where sales will soon overtake those in the home market, but it desperately needs some localization (into proper English), on which Engineering refuses to place much priority. You have profitability on your side, but the mothership has history, not to mention ownership of development.

How do you build a localization strategy around that?

Like any global business problem, the usual bromides of communication, onsite visits in both directions and strongly backed business cases go a long way towards solving this. If they were selling a U.S.-created product into their regions, they'd defer to U.S. preferences, but it's not that simple when the scheme is suddenly inverted like this.

You feel as though you're the dog, and the other guys are the tail wagging you, and the other guys think they're the dog, and you're the tail trying to wag them.

The real winners? Your competitors.

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.