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.

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?

Four Localization Answers, Just In Case They Ask

Sooner or later, someone may ask you, "We've got a new release coming up. Why don't you give us a presentation on what you'll need to localize it properly?"

After you've recovered from the shock, will you have a ready answer?

I received this request last week from one client, and turned it into an invitation to present at the regular meeting for all of the leads - software, Web, documentation, project management, QA, release - and some people in upper management. It's meant to be a very brief (10-15 minutes) presentation, which felt like a limitation at first, but which now strikes me as an advantage because it will help me focus better.

They've stapled me to a slide presentation, and I made the most of it.

• Slide 1: Hello! I'm the Localization Guy and I live to pester people. (Maybe I don't say it in quite that manner...)
• Slide 2: Scope of Work - These are the software, Web and documentation bits we'll need to localize, and the parts that are already in TM.
• Slide 3: Timing of Work - Let's hand off anything we can as soon as it's stable, even if the localized releases aren't for several months yet.
• Slide 4: Help Wanted - Here are areas of the project outside of my control, where a little localization-mindfulness will save some time, money and headaches. This includes tagging XML files for text that should not be translated, handing me early software builds for internationalization testing, and thinking about the stable files we can hand off ahead of product release.
  

I think this will suit their desire for information. They don't want to know the details of how I do what I do, but I want them to know what I need from them.

You too should have a presentation like this in your desk drawer or on your hard drive. Just in case they ask.

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?

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.

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.

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.

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

Localization Train slowing

We're seeing the localization juggernaut lose some steam.

In the early years, this client localized its flagship software package for developers in China, Japan and Korea (CJK), then added Brazil. It took small, reference applications into as many as 10 languages (including Hebrew and Thai) as those markets showed promise. The budget was pretty fat, the localized products were freshened frequently, and the developers were happy to have software and doc in their own language.

I suppose it was to be expected that this would peter out with time, because markets change, business cases wax and wane, and some regions never return the investment.

The new stressor on localization was less easy to anticipate: bulk. Each generation of improvements to the product brings several hundred more pages of documentation. All of this new documentation is, of course, "free" in English, but somebody has to pull out a checkbook to deal with it in other languages, and that checkbook comes out more slowly and with more misgivings these days.

Engineering and Product Management furrow their brow nowadays when I walk in with cost estimates. I've adapted to this change in attitude with a few techniques:

1. The Technical Reference is the fattest target and the source of most of the expansion. It lives in a compiled help file (CHM) that is no longer written by Tech Pubs, but generated by Perl scripts from header files written by the engineers. Our modus localizandi has been to hand off the finished help project, now comprising 3700 HTML files, and have the HTML translated. In an effort to lower cost, I'm attempting a proof-of-concept to localize the header files themselves, then tune the scripts to convert them into localized HTML. This should lower our localization engineering costs considerably.
2. I agitate for interim localization updates, peeling off documentation deltas every few weeks and handing them off for translation, even if there are no plans to release them yet. This reduces the sticker shock and time-to-market delay that comes of getting an estimate on a release only when necessary, which may be a 10- to 18-month interval. Product Management and Engineering, who only think about localization when it's absolutely unavoidable, find the tsunami of untranslated text depressing.
3. Although it's not a very clean way of doing things, I screen from the localization handoff those items that I know have little to be translated. Sometimes I go to the level of resource files, but more often I take documents to which only a few minor changes have been made from one En version to the next, hand off changed text, then place the translations myself. This is not for the faint of heart, nor for those who don't really know the languages involved, but it can save some money.
   
4. I try to keep global plates spinning, in the hope that more people will consider the global dimension of what we do, and the fact that localization is the necessary step for making your product acceptable to people whose use of your product will make you money, if you make it easy for them.
   
5. I never impart bad news on Friday.
   

Localized Binaries - The Plot Thickens

The engineer has demonstrated that it is no longer possible to build just the resource binaries; it is now necessary to build the entire blinking product.

"Why is that?" I ask.

"We've improved the makefile," he replies. The makefile is a script used by the make command to build binaries.

"That doesn't feel like an improvement to me," I venture. "Why can't I just build the two or three resource binaries I need? I don't need all of the executables and other rot."

"Yes, well, we've improved the makefile."

"But there was a small, localized makefile that lived in each of the directories of the resource binaries I wanted. What happened to them?"

"We improved the main makefile by rolling all of those lower-level makefiles into it."

That's a hint to me that they improved it for the purpose of creating all of the files that go into the installer, but that's far and away more files than I want. It also means that it's probably going to take me a half-hour now to build binaries that used to take about six seconds each.

Had they been following good I18n hygiene, they'd have asked themselves (or me, even) whether there were costs associated with consolidating all of the lower-level makefiles and eliminating the possibility of rebuilding except in this huge batch. The costs don't really affect them that much, though they'll slow me down somewhat.

It's an "improvement."

Translators - The Tech Writer's Best Friend/Worst Enemy

"Say, Jean, the translators found some problems with the original English documentation your team wrote. Do you want me to send you the corrections?"

"Sure, John. Do you want me to send you a nice cartridge of mustard gas?"

I never find that writers embrace the feedback from translators. It's not that the translators go out of their way to find errors; mostly it's that they don't understand the term/phrase/sentence/paragraph and cannot therefore translate it. This is the fundamental test of documentation usability - are you conveying your idea to the reader? - and most writers get grumpy when they don't pass it with flying colors.

It's also not the case that translators get snooty about the errors they find. In fact it's I, not the translators, who add a thin veneer of snootiness to the comments I send to the writers.

• Why are all of these Copy(1) and Copy(2) files in the RoboHelp project? Do we need them? Should we translate them?
• The FrameMaker files you gave us don't match the PDF you gave us. Which one is correct? (To their credit, most translators won't take for granted that the one with the later date stamp is the definitive source.)
• This training manual is for version 5.3. The last version of the software that we translated was 5.1. What has changed in the software? Do we need to translate the delta first, in order to translate the manual properly?
• We found 136 pages in the online help file with no content in them. Are they meant to be that way, or did something go wrong in the extraction process?
  

Writers don't often like to hear such feedback, but, if it's implemented, nobody can deny that it makes the books better.

Segmentation and Translation Memory

To get the broken sentences in the new files to find their equivalents (or even just fuzzy matches) in translation memory we have three options:

1. Modify the Perl scripts that extract the text from the header files into the HTML, so that the scripts no longer introduce the hard returns.
2. Massage the HTML files themselves and replace the hard returns with spaces.
3. Tune the segmentation rules in Trados such that it ignores the hard returns (but only the ones we want it to ignore) and doesn't consider the segment finished until it gets to a hard stop/period.

To go as far upstream as possible, I suppose we should opt for #1 and fix the problem at its source. This seems optimal, unless we subsequently break more things than we repair. Options #2 and #3 are neat hacks and good opportunities to exercise fun tools, but they burn up time and still don't fix the problem upstream.

Also, I don't want the tail to wag the dog. The money spent in translating false positives may be less than the time and money spent in fixing the problem.

Moving the Localization Carpet under the Source Text

Here's the mess I face.

The HTML files are filled with paragraphs formatted like this:

Currently, this function gets called for trust overrides and

client authentication. On client authentication, the supplied

interface contains the server's Certificate Authorities Distinguished

Names list (see references) and the negotiation handler

always gets called so as to give a chance to the client to supply

the correct client certificate based on the DN list.

At the end of each line are two hard returns. It wasn't always this way, so each complete sentence is sitting happily in translation memory. Unfortunately, Trados pulls in each of these six 80-character fragments and calls it low- or no-match because it can't find enough of a concordance. This is a classic case of false positives driving up translation costs.

I'm still exploring options. Meanwhile, there's no sense in starting the translation work.

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

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

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

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

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

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

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

The Lonely Localization Manager

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

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

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

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

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