Half-Billion Dollars in U.S. Hispanic Advertising

Are you localizing for domestic buyers? When the locale or region for which you're locale-izing is actually your own, but with a demographic twist, it becomes a kind of internal localization.

This is a much-studied phenomenon (and economic driver) in the U.S., where estimates point to 46 million Hispanics with USD900 billion in spending power. Take both of those figures with a grain of salt, but there's a market there, and several industries - notably banks and wireless companies - are internally localizing their products and services for it.

Still, what's the point of localizing your product - toys, electronics, books, irrigation equipment, insurance policies - if your company is not spending money to promote it?

According to a study from the Association of Hispanic Advertising Agencies (AHAA), the top seven advertisers to U.S. Hispanics spent nearly USD500 million in 2007. However, a number of large companies well known for their ad budgets (Dell, Microsoft, Apple) are pretty stingy when it comes to promoting their products among Hispanics. More data here.

Does anybody bother with this internal localization besides U.S. companies? Do companies based in other countries need to think about internal localization, and how to promote global products internally? Does Michelin run Arabic-language commercials in France for its Algerian and Moroccan inhabitants? Does BMW run Turkish-language ads in German newspapers? Does China Mobile market its cellular service to English-language expatriates living there?

Companies like Verizon Wireless and Bank of America put in place the equivalent of an overseas office, by creating marketing, sales and product teams. They work inside the U.S., but in a different language and on different opportunities for different people from the main teams.

I don't think we're learning how to do this by watching companies in other countries. I think we're making it up as we go along. It's odd to think of localization without the international component to it, but it's part of our job as localizers.

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 Still Needs You - The Myth of the Global Brand

Will your job go away as the world gets flatter? Not likely, according to an article by Eric Pfanner in the International Herald Tribune (link below).

Nigel Hollis, chief global analyst at the market research firm Millward Brown, argues that instead of becoming more alike, people are more eager than ever to assert their differences. And marketers - at least those who want to create global brands - ignore this at their peril.

This approach, which marketers refer to as "global/local," has been around for a while, and Hollis has a vested interest in supporting it.

"The vast majority of people still live very local lives," Hollis said. "By all means go global, but the first thing you have to do is win on the ground," he added. "You have to go local."

As localization manager, of course, your job is to keep your company's eye on the local side of global/local.

Do your execs think that the only thing people want to personalize is the choice of music on their iPod? How about the language in which they deal with you and you deal with them?

One size still doesn't fit all. Nor does one language.

Here's the link to the Pfanner article. Happy reading and happy localizing.

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.

Localizing DITA Projects

Have you seen DITA projects land in your inbox yet? The full promise of XML is about to become your next headache.

If you don't know what DITA is, here's the thumbnail from the Open Toolkit's User Guide:

"DITA (Darwin Information Typing Architecture) is an XML-based, end-to-end architecture for authoring, producing, and delivering information (often called content) as discrete, typed topics."

In short, the source content you hand off for localization lives in XML files. If you get to the party soon enough, you can help your own cause by asking the authors to use specific XML tags in their authoring to make it easy for you to find text you need to translate and to ignore text you don't need to translate. The authors will surely fall all over themselves to make you happy with this new technology, so take advantage of it while it's still novel.

The problem with XML is that it's ugly and nobody can use it as documentation in that format, so it needs to be transformed into HTML, PDF, CHM, XHTML, or some other gestalt that people will use. The DITA Open Toolkit is an open-source means for performing this transformation, using scripts and languages to shape the content.

Your problem as a localization professional is not in the XML; it's in the transformation.

How do you know that the scripts your writers use for the source language (let's say, English) will work when you have to run them on XML files translated into Korean or Hebrew or Russian? (Well, they will run; the question is whether the result is good or garbage.)

With a kit like the Open Toolkit, things run as advertised when used right out of the box. The open-source project even devotes a chapter of its user guide to "Localizing (translating) your DITA content," and they are kind enough to provide pre-translated text like "Parent Topic," "Previous," "Next," which you can hook with the xml:lang attribute. The tricky part lies in the customization.

One Tech Pubs team engaged a team of script programmers to customize the toolkit. They've introduced strings like "Copyright Statement" and "Enter keyword" and placed a "Last updated" datestamp on every page in the help project. They've also implemented a search function (gulp!) so users can locate content in the help files. There's nothing wrong with this customization work, except that nobody was thinking of other languages while doing it. Now we're sorting out the location of the custom strings, the way to get the toolkit to format dates according to locale, and how to convince the search function that characters can take up more than one byte.

You will face the same problems. You'll need to internationalize your writers' customizations so that things work properly in your target language.

So when your writers tell you how much easier your life will be now that content is in XML, don't forget to look a bit further down the road at what they're using to transform that XML into something useful. That's where you'll put in the hours.

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 3

How about those engineers who are certain that all of the strings have been externalized from the code?

I don't know about you, but I stopped believing them a long time ago.

Pseudo-translating the code is the definitive way of showing them the strings they've missed. It requires a bit of time and, frankly, some cooperation from the very engineers you're about to embarrass, but it's the sure way to find strings still embedded in code.

Many engineers overlook the installer, also. There is usually a script or value-pair file with custom strings, and it's easy to forget to externalize strings to the file. It's also easy to specify the wrong encoding for the file, such that all of the custom strings show up corrupted in the installer. We see that a lot with InstallShield projects.

Mind you, I'm never out to get the engineers - I need them too dearly - but they sometimes get to believing their own stuff and thinking that internationalization (I18n) is kaltes Kaffee, or yesterday's news. It is yesterday's news, but that doesn't mean it's unimportant.

Where do you find strings that engineers overlook?

Note: I've posted less frequently of late because I'm between projects (and setting up another blog). Once L1on activity resumes with a couple of clients, I'll have more war stories again.

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?

Wordcount Woes - Part 1

Do you spend much time fretting about wordcount?

My hunch is that translators worry about it more than agencies do, because it's often the only metric by which translators earn their daily bread. Agencies have project management, layout, graphics, consulting, rush charges and other metrics to observe, but most translators have one line-item on their invoices: wordcount.

I suppose that we all live and die by it because everybody's calculations get down to wordcount - either source or target text - sooner or later, but no two tools define words the same way, so wordcount can vary considerably.

Still, the bigger issue with wordcount is "wordcount leakage." If you're working vendor-side, how many times have you quoted on a project, then realized that you had overlooked a chunk of text?

• Graphics are the biggest culprit. The document contains charts and diagrams that require translation, but TM tools don't find those words. Many vendors wisely exclude such text from wordcount and cover it in an hourly or per-graphic charge. (Nobody can ever find the source files for the graphics so that you can localize them properly, but that's a whole other talk show.)
  
• Bookmarked text is also slippery. It appears as text (sentences, paragraphs) in one place, and is referred into other places in the document. True, you only translate it in one place, but you need to deal with it - layout, formatting, page flow - in other places as well.
  
• Conditional text, a favorite of Framemaker professionals, can also cause you trouble. If you don't calculate wordcount with the conditions set to expose all of the text, you may miss it. The author should arrange for this before handoff.
  
• Embedded documents (spreadsheets, word processing, HTML, presentations) are very sneaky. We just saw this the other day with an MS Word document that contained several embedded spreadsheets visible only as 1cm square icons on the page; double-clicking the icons opened up the embedded files. The TM tools don't see those words, but the client certainly would have if they had come back untranslated. Fortunately, we caught this in time.
  

The Moral: Two pairs of eyes should review every file before the TM analysis, NOT one pair of eyes and a TM software package.

Summer localization slowdown

Things are quiet on our localization front at the moment.

The nature of managing localization projects as a consultant is that, if there's work to do, I do it. If there isn't, I go into down-time mode and focus on interim activities like these:

• Analyzing return-on-investment. This is, in part, how I eventually grew into the role of international product manager. My quest for data on the language-by-language profitability of our localized products takes me to more far-flung corners of the company than I'd anticipated, and it isn't always embraced by everybody in the organization, but I learn a lot. The Accounting department has some vague numbers on revenue from localized products - the overseas sales offices have more accurate data - but it's hard to allocate costs accurately because a localized product costs more than just the amount paid for translation, and companies treat this differently.
  
• Evangelizing. I spend some time getting my ducks in a row with Engineering, Marketing and Production, "educating" them on what goes into a localization project and how much more internationalization we can afford for the next version. I work at keeping people's eyes on the goal of simultaneous shipment ("sim-ship").
• Working things out with the vendors. Some projects merit a post-mortem - which I have always preferred to label "post-partum" - meeting to review what went well and what needs to go differently in the future. It's common for some action items to come out of such a meeting, and so I often spend time with the vendor putting process improvements in place for the next round.
  
• Tinkering with the machine. Every project brings up several internationalization issues (embedded strings, rogue controls, bits of unruly not-invented-here software), so I take advantage of down-time to find out how to deal with them, then pleasantly surprise the engineers with the research I've done.
• Finding beta testers. It's helpful to spend time in between projects mining our registration lists for new beta testers for the localized versions. I find new prospects, weed out the people who haven't helped on the previous round of testing and - very important - handily reward those testers that have stepped up and done a good job for me.
• Talking to the Sales teams. The salespeople in the overseas offices know best what sells and what local customers think of the products, and down-time is an opportune moment to collect formal and informal data and requirements from them.

What about you? Do you ever have down-time between localization projects? How do you spend it? Post a comment and let us know.

Localizing Code Snippets - Part II

Last week I posted on the dilemma of how to localize Code Snippets, the selected pieces of your documentation that you shoehorn into XML files so that Visual Studio can present them in tool-tip-like fashion to the user while s/he is writing code that depends on your documentation.

My goal was to ensure that the process of grabbing these bits of documentation (mostly one-sentence descriptions and usage tips) was internationalized, so that we could run it on translated documentation and save money. This has proved more difficult than anticipated.

Here is the lesson: If you think it's hard to get internal support for internationalizing your company's revenue-generating products, just try to get support for internationalizing the myriad hacks, scripts, macros and shortcuts your developers use to create those products.

In this client's case, it makes more sense to translate the documentation, then re-use that translation memory on all of the Code Snippet files derived from the documentation. It will cost more money (mostly for translation engineering and QA, rather than for new translation) in the short run, but less headache and delay in the long run. Not to mention fewer battles I need to fight.

Discretion is the better part of localization valor.

Localizing Code Snippets

"Why would I localize code snippets?" you ask. (Go ahead; ask.)

Everybody knows you don't translate snippets of code. Even if you found a translator brave enough to take on something like int IBACKLIGHT_GetBacklightInfo(IBacklight *p, AEEBacklightInfo * pBacklightInfo), the compiler would just laugh and spit out error messages.

However, if you're a developer (say, of Windows applications) working in an integrated development environment (say, Microsoft Visual Studio), you may want to refer very quickly to the correct syntax and description of a feature without searching for it in the reference manual. The Code Snippet enhancement to Visual Studio makes this possible with a small popup box that contains thumbnail documentation on the particular interface the developer wants to use. It's similar in concept and appearance to the "What's This?" contextual help offered by right-clicking on options in many Windows applications.

How does the thumbnail documentation get in there? It's a tortuous path, but the enhancement pulls text from XML-formatted .snippet files. You can fill the .snippet files with the information yourself, or you can populate them from your main documentation source using Perl scripts and XSL transformation. So while you're not really translating code snippets, you're translating Code Snippets.

And therein lies the problem.


One of our clients is implementing Code Snippets, but the Perl scripts and XSL transformation scripts they're using to extract the documentation, don't support Unicode. I found this out because I pseudo-translated some of the source documentation and ran the scripts on them. Much of the text didn't survive to the .snippet files, so we're on a quest to find the offending portions of the scripts and suggest internationalization changes.

We've determined that the translated documentation in the Code Snippets will display properly in Visual Studio; the perilous part of the journey is the process of extracting the desired subset of documentation and pouring it into the .snippet files. Don't expect that your developers will automatically enable the code for this; you'll probably have to politely persist to have it done right.

Alternatives:

• Wait until all of your documentation has been translated, then translate the .snippet files. It's more time-consuming and it will cost you more, but working this far downstream may be easier than getting your developers to clean up their scripts.
• Make your Japanese developers tolerate English documentation in the Code Snippets.

Neither one is really the Jedi way. Work with your developers on this.

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.

International Keyboard Frenzy

My wife is traveling through Europe, sending us e-mail from Internet cafés along the way. Here's one I received this morning:

thnks for the msgs.  i luv zou and miss zou 9sorrz i hav a bratixlava kezboard0. will trz longer message in a few dazs. 

love, hugs and kisses.

She's actually a pretty good typist, but she was flummoxed by the keyboard on the computer she used in Bratislava, Slovakia, because several of the keys are in different places from where here fingers expected them to be on a U.S.-English keyboard. The interface between fingers and keys is a fragile one in computing. 

Of course, my wife could have tinkered with the Regional Settings control panel (Windows) or International system preference (MacOS) to disregard the hardware keyboard and interpret the keystrokes according to any other supported keyboard layout (like U.S.-English), but machines in Internet cafés are probably not set up to allow that kind of modification without administrative permission.

Thosé of üs whö frequently wríte with çharacterß from othër langüages not natively supported by our hardware need keyboard tricks to do so.

DOS

• Are there any dinosaurs out there who remember how to do this besides me? To generate ü on a U.S.-English keyboard, for example, you had to hold down the left Alt key and enter 129 on the keypad. The left Alt key accessed the ASCII characters above 128.
• I don't think Latin-based operating systems supported non-Roman characters; you had to either buy that version of the OS or get special software to add the functionality. (Who cares? It's ancient history.)

WINDOWS

• U.S.-English users can use the U.S.-International keyboard layout to generate combined Latin characters like ëüöàñçß¿¡. I use it as my default mapping. It takes a bit of getting used to the change in how you use your quotation mark key -" ' - because you hit it before the key you want to accentuate. 
• You can also Insert Symbol in most Windows applications, but this is clunky. 
• For Asian and other non-Latin characters, or to map a different soft keyboard over your hardware keyboard, enable a different input language in the Regional Settings control panel. (This may require installing additional fonts in some exotic languages.)

MAC OS

• Right out of the box, you can use the same keyboard tricks that have been in place since System 7. Option + e tells the OS that you want an accent aigu over the next character, such as e or a; option + u generates the diaeresis or umlaut over the next character, and other option + combinations result in other common accented Roman characters.
• From the International system preference you can display a character palette in the desired language, then select the characters as you need them, or you can impose a software keyboard over your hardware keyboard. 
• There's also full support for Asian and other non-Latin input methods, but again, you may need to install fonts (e.g., for Indic languages) from your original installer discs.

I have no doubt that these functions are elegantly handled in Unix/Linux variants as well, but I have the disadvantage of never spending time on them. Post a comment if you have useful tips on this.

How do you handle multilingual character input in your daily work?

"I can quit smoking whenever I want to."

"...I just don't want to."

Have you heard that one before? I heard something similar last week from a director of engineering:

"All of our strings are embedded in source code. This is deliberate, and we planned it very carefully."

How would you have reacted?

At first, I figured he was pulling my leg ("taking the mickey," "having me on," etc.). Then he explained the process of localizing strings in the gnu gettext model, which can live peacefully without external resources.

A line of code reading

result = wx.MessageDialog(_("Welcome to my blog. Today is %s"), date.today)

uses the _ function in the English context as an identity function. In a localized context it will load the language pack built using the gnu gettext utilities and map the English strings to the localized equivalent:

"Welcome to my blog. Today is %s" -> "Bienvenido a mi blog. Hoy es %s"

To redeem what seems like shortsightedness in allowing developers to embed strings in code, these utilities also contain scripts that can pull out all the English strings from source code and make localization packages, which translators can work on without danger of touching the code. Other scripts can push the localized strings back into place.

Like .properties files in Java and .rc files in C++, these localization packages isolate non-code elements for easy localization. However, a programmer's coding mistake could still result in strings going undetected by the scripts, so I still plan to perform pseudo-translation and internationalization testing on this software as soon as possible.

Just in case the director of engineering can't quit smoking as easily as he thinks he can.

Getting Documentation Ready for Localization - The Audience Speaks

Don't you love it when the audience is listening? Even more when they write back?

Last week's post included a handful of considerations about preparing documentation for localization. An alert reader and industry veteran (who prefers obscurity to the onslaught of Web-fame that this post will undoubtedly unleash) sent me a table of resources she has compiled on the topic over several years' time:

Title	Publisher	Summary and Notes
25 Tactics to “Internationalize” your English	Intercom (STC magazine)	Hints on writing localization-friendly copy. (One example: choose words with one or few meanings).
Authoring and controlled language	TAUS (Translation Automation User Society)	A guide to how and why companies are starting to manage their writing and editing “upstream.”
Basic Tips for Loc Writing	Globalvision International	A brief overview from a translator’s perspective on how to simplify the work of the translator.
Color Connotations	Lionbridge	Guidelines on how different colors are perceived throughout the world.
Localizing Art	Globalvision International	Tips on how to improve graphics localization.
Reducing Localization Costs	Globalvision International	Tips on how to write text that is less expensive to localization – both new copy and updates.
Tech Writing for Localization	Client Side News Magazine – Tech Writer supplement	How culture and jargon impacts writing and localization. Tips on the purpose and benefits of standards and templates.
Terminology Management White Paper	Jonckers	Why consistent terminology is important to localization.
Writing for Translation	Multilingual Magazine	Tips on how to simplify text. Information on how DITA impacts localization.

The contributor comments, "Please note that some of this is proprietary to the publisher and not generally available."

Find what you can and help yourself!

Getting your Documentation Ready for Localization

Have you had to prepare your documentation for localization yet? My experience is that in almost all companies, writers have far too many other oppressive concerns gnawing at them to think about writing for localization.

A few days ago an industry colleague sent me a message asking, "Do you have experience making recommendations for how documentation can be authored for localization? I am looking to make our doc  process more efficient to reduce costs."

I replied that, given his stature and tenure in the industry, there was not likely anything I could suggest that he hadn't already considered. Nevertheless, I sent him a list of ideas, in increasing order of difficulty:

1. Make sure all the writers' computers are plugged in. (A bit of ironic humor I could not resist.)
2. Is it easy to get from the authoring tool(s) into TM, and back out into publishable format? This is my current headache with an API reference manual we localize for one client, because moving from source language to the translator tools and back to target format is a colossal headache. If you have similar problems, devote some cycles at the format-layer, even if it means writing an interface between your content management system and the translation tool.
3. There are "authoring memory" tools that can suggest and re-use already-xlated source text, so that writers don't say nearly the same thing multiple times and incur unnecessary TM penalties. Sajan has one, and SDLX contains one as well. I've never used either one, but I can imagine that success with the tools would require somebody with the documentation-familiarity of a technical writer and the global consciousness of a localization manager. Like you.
4. I've presented on localization to a variety of audiences, and have consistently found tech writers to be the most interested in it, vastly more so than developers. When you show writers how the TM tools work, tell them how they can save money and re-use content, and let them know that you care about the impact of their work on international products, they will smell the coffee and engage. This takes a bit of evangelism, but it's worth it if the writers change their own practices.
5. Convert everything to XML. Although Renato and Don of Common Sense Advisory joke that that will fix any L10n problem, it's nonetheless a good, long-term direction in which to move. It's easier to re-use text, and easier to mark text that should/should not be translated. That will save you money.
6. Start a program of controlled language authoring (dumbing down the sentences, always writing in a structure that machine translation will recognize, etc.). I guess that GM and Caterpillar are poster children for this kind of thing, but it puts the writers (and you, in the bargain) through the change of life, which is why I mention it last.

What about you? Have you faced this in your organization? How have you made document localization easier for the company, without driving your writers crazy?

If you liked this post, have a look at Getting Writers to Care about Localized Documents.

"I certainly get tired of localization."

Have you said this lately? Have you thought it lately? Do you wish you'd joined the Rolling Stones when they invited you?

What do you plan to do after localization? What will you do next in your career?

Look at the localization people around you. How did they get into this business? How has their job changed since they did what you're now doing? At least two prominent figures in our industry started out as professionals (attorney and tax consultant), then started small translation companies that grew very large. Neither of them translates anything or manages projects anymore, but both have used the industry as a springboard to broader career paths.

On the vendor-side, translators become project managers, who become leads, who become salespeople, who ultimately run the company, or start their own. On the client-side, localization managers become product managers, who become directors of product marketing. On either side, your company could easily be purchased and you might have to start over from scratch. Will you be ready?

I've visited high school and college classes to describe to language students how they can use their talents to enter several industries, including translation/localization. It hasn't occurred to me to address the question, "After that, what?"

Of course, you don't need to wait until you've grown tired of localization to start planning your own outplay. If you don't have another marketable talent in your back pocket right now, then you must not be reading the newspapers. Years ago I had a very discerning boss who asked me in confidence, "In how many completely different ways can you earn a living? You should always be accumulating multiple talents you could apply to make money, if you had to."

So, during the day you're a localization manager, and at night you offer bookkeeping services to small businesses. Or, Monday through Friday you run translation projects, and on Saturdays you do search engine optimization for friends' Web sites.

Yes, it's more work, but when the localization train reaches the last station and you get off (or are pushed off), you'll have more options in picking the train to board next.

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?

Giant Localization Leap Backwards

"All of the strings are embedded in the code."

There was a time when I welcomed - or at least was not very much surprised by - sentences like this one. They came from engineers in response to my questions about the readiness of their software strings to be localized. Strings embedded in code, of course, are more or less inaccessible to localization techniques, since nobody wants to hand off an entire code base to a translator, and no translator wants to wade through an entire code base trying to find strings to translate.

So, when one of my client's engineers said it to me yesterday in reference to an application in a larger product we plan to localize, I briefly welcomed it. It means more work.

But then I realized that combing all of the strings out of the code and into separate, accessible files will require a great deal of time and effort (not mine). Engineers don't usually enjoy working on this kind of task, so it will fall to the bottom of the priority stack, and the product manager won't go to bat for it, and so this particular application will stick out like a sore thumb as a non-localized component in an otherwise localized product suite.

"Is there a phased approach we could take to enabling this app for localization?" the engineer asked.

I appreciated his attempt to save the game, but a partially localized product is rather ugly. We could enable and translate the menu and dialog strings for this release, and go back for the error messages in the next release, but the mongrel product is not very appealing to users in the meantime.

This is disappointing, because we've made such long localization-strides elsewhere in the product suite, and dealing with this newly acquired app feels like such a giant leap backwards. I guess I'll work up some estimates on the time required to enable the application, then make my case to the product manager and development lead to generate some interest and start the process from the beginning.

Isn't that why we localization project managers and international product managers were sent here?

What do you do in your company when engineers tell you that all the strings are embedded in the code?

Localization Risk, As Time Goes By

In 1999 I created a presentation on minimizing the risk in localization projects. It offered several scenarios with possible decision-paths and ways to keep risk low. I've dusted off the presentation and offer a sample from it today.

1. Your company decides to localize its product, and assigns the project to the Technical Publications Manager. Unfortunately, that is you. Do you:

• rebel, because it’s not why you hired on?
• rebel, because it’s not a Tech Pubs function?
• rebel, and do it anyway?

The Risk - Entrusting the project to someone who doesn’t want it or cannot manage projects. To minimize the risk, pick someone with project management expertise over linguistic/writing/engineering/product expertise.

2. Your CEO tells you he wants to localize into 5 Western languages and 2 Asian languages first time out. He offers you an extra 5,000 stock options if you complete the project successfully. Do you:

• say, “Piece of cake!” and take the challenge?
• ask, “Am I being set up for failure?”
• counter, “I'll do that if you do the press tours”?

The Risk - Biting off more than you can chew, especially the first time out. To minimize the risk,
schedule a scaled-down “pilot project” rather than picking a fight you may not win.

3. You explain to your QA Manager that she will soon have the opportunity to test French and Portuguese versions of the product. She replies, “Oh, we’ll have no part of that.” Do you:

• laugh?
• cry?
• pretend you didn’t hear her and say, “Right. I'm glad we understand each other”?

The Risk - Intimidating or alienating co-workers with the localization process. To minimize this risk, educate first, then start mustering resources. Also effective is an evangelization effort to boost your project's visibility everywhere in the organization.


In short, it's not very exciting to go home at the end of the day and tell your spouse that you spent most of your day minimizing localization risk, but it is quite important. The risk lives in lots of narrow corners, and it's your job to find it before it finds you.

Four Localization Answers, Just In Case They Ask

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

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

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

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

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

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

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

Localizing Robohelp Files - The Basics

We get a lot of search engine queries like "localize Robohelp file" and "translate help project." I'm pretty sure that most of them come from technical writers who have used Robohelp to create help projects (Compiled HTML Help Format), and who have suddenly received the assignment to get the projects localized.

The short answer
Find a localization company who can demonstrate to your satisfaction that it has done this before, and hand off the entire English version of your project - .hpj, .hhc, .hhk, .htm/.html and, of course, the .chm. Then go back to your regularly scheduled crisis. You should give the final version a quick smoke test before releasing it, for your own edification as well as to see whether anything is conspicuously missing or wrong.

The medium answer
Maybe you don't have the inclination or budget to have this done professionally, and you want to localize the CHM in house. Or perhaps you're the in-country partner of a company whose product needs localizing, and you've convinced yourself that it cannot be that much harder than translating a text file, so why not try it?

You're partially right: it's not impossible. In fact, it's even possible to decompile all of the HTML pages out of the binary CHM and start work from there. But your best bet is to obtain the entire help project mentioned above and then use translation memory software to simplify the process. Once you've finished translating, you'll need to compile the localized CHM using Robohelp or another help-authoring product (even hhc.exe).

The long answer
This is the medium answer with a bit more detail and several warnings.

• There may be a way to translate inside the compiled help file, but I wouldn't trust it. Fundamentally, it's necessary to translate all of the HTML pages, then recompile the CHM; thus, it requires translation talent and some light engineering talent. If you don't have either one, then stop and go back to The Short Answer.
  
• hhc.exe is the Microsoft HTML Help compiler that comes with Windows. It's part of the HTML Help Workshop freely available from Microsoft. This workshop is not an authoring environment like Robohelp, but it offers the engineering muscle to create a CHM once you have created all of the HTML content. If you have to localize a CHM without recourse to the original project, you can use hhc.exe to decompile all of the HTML pages out of the CHM.
• Robohelp combines an authoring environment for creating the HTML pages and the hooks to the HTML Help compiler. As such, it is the one-stop shopping solution for creating a CHM. However, it is known to introduce formatting and features that confuse the standard compiler, such that some Robohelp projects need to be compiled in Robohelp.
• Robohelp was developed by BlueSky Software, which morphed into eHelp, which was acquired by Macromedia, which Adobe bought. Along the way it made some decisions about Asian languages that resulted in the need to compile Asian language projects with the Asian language version of Robohelp. This non-international approach was complicated by the fact that not all English versions of Robohelp were available for Asian languages. Perhaps Adobe has dealt with this by now, but if you're still authoring in early versions, be prepared for your localization vendor to tell you that it needs to use an even earlier Asian- language version.
• Because the hierarchical table of contents is not HTML, you may find that you need to assign to it a different encoding from that of the HTML pages for everything to show up properly in the localized CHM, especially in double-byte languages.
• The main value in a CHM lies in the links from one page to another. In a complex project, these links can get quite long. Translators should stay away from them, and the best way to accomplish that is with translation memory software such as Déjà Vu, SDL Trados, across or Wordfast. These tools insulate tags and other untouchable elements from even novice translators.

We've marveled at how many search engine queries there are about localizing these projects, and we think that Robohelp and the other authoring environments have done a poor job explaining what's involved.

If you liked this article have a look at "Localizing Robohelp Projects."

If it isn't broken...break it!

What's the most effective way to bump up your translation costs unnecessarily?

Probably by localizing something that nobody will ever want in a foreign language, of course. But nobody would ever approve an expense like that, so it wouldn't have the opportunity to affect your translation costs.

There's a much sneakier, more pernicious way of wasting translation money: Tinkering with the original text (for example, English).

Suppose you localized your product or documentation from 2002 through 2007. You'd have five years' worth of translation memory (TM) economies and glossary entries going for you, with thousands of exactly matched words that incurred no translation cost from one version to the next. Then suppose that someone decided in 2008 to go in and "clean up" the original English text to make it more "readable" or "user-friendly."

What do you think would happen the next time you handed off this content for TM analysis? Suddenly, non-matches would pop up where exact matches used to be. Among the causes:

• Combining short sentences together
  
• Breaking long sentences apart
• Making stylistic changes to common terms (e.g., changing "phone" to "telephone" or "handset")
• Standardizing disparate terms (e.g., selecting one of "Proceed as follows," "Perform the following steps," "Following is the required procedure" and propagating throughout the documentation)
• Typographical or grammatical corrections
  

You might tolerate these modifications in the interest of improving your product in all languages - not just English - but the sad truth is that you may find that they make no difference in the localized products. You'd pay for words that the translator did not need to touch. This is an unfortunate artifact of the way in which translation jobs are estimated, but the analysis software cannot predict that the changes will make no difference to the translation; only the translator sees that.

Note that re-organizing content should not cost you additional translation money; as long as the sentence is the same (i.e., an exact match), it doesn't matter where it's located in the product.

So, are you better off leaving errors and other undesirables in your original-language content? No. It would be a mistake to let concern for translation cost impede your product improvement effort, like having the tail wag the dog. Still, to the extent you can control it, you should try to avoid purely stylistic changes that make no difference in how your customers use your product. A good editor can make a hundred such changes per hour, not realizing the ramifications on translation costs.

If you learned something from this post, you might like to read Improved Docs through Localization or Getting the Writers to Care about Localized Documents.

Doxygen and localization

Are you localizing any documentation projects that use Doxygen? It's an open-source tool for documenting source code.

If your documentation set includes things like an API reference or extensive details in programming code, Doxygen allows you to embed tags in the original code or header files, then automatically create entire help systems organized around the tagged text. Doxygen does not compile anything, but takes the tagged bits of source files, turns them into HTML pages, then links them for viewing in a browser.

Like most tools, it's a breath of fresh air when it works properly, but it can require a lot of re-plumbing and retrofitting.

As far as localization goes, it can be a life-saver. In theory, you can have the header files themselves localized, then run them through Doxygen as you would the original English files. Working this far upstream can be a big advantage.

Some months ago a client embarked on a conversion of a help system to Doxygen. While it was still in the proof-of-concept stage, we pseudo-translated some header files and tested the tool for global-readiness.

The good news is that the developers of Doxygen have enabled it for multiple languages. It encodes pages in UTF-8 (or other character sets), so translated text displays properly in the browser. It's possible to set the OUTPUT_LANGUAGE parameter to your target language (e.g., Japanese, in our test scenario) so that the datestamp and other text supplied by Doxygen displays in Japanese, rather than in the default English.

There are some I18n problems with Doxygen, though.

• Each header file page begins with "Collaboration diagram for" followed by the page title. When the page title contains double-byte characters, the Japanese characters for "Collaboration diagram for" are corrupted. It appears that Doxygen is not pushing UTF-8 characters for this phrase, though it pushes UTF-8 characters in other places.
• Some hyperlinked words in body text will require translation. If so, it will be important to ensure that they are translated the same everywhere. Note, however, that Doxygen will not generate the necessary file if the hyperlink has double-byte characters in it (not even on a Japanese OS).
• Doxygen allows for generation of the .hhc, .hhp and .hhk files needed for Compiled HTML Help (CHM). It can also be configured to execute hhc.exe and compile the project. However, Doxygen outputs the .hhc file in UTF-8 format, which is incompatible with the table of contents pane in the Help viewer. To fix this, open the .hhc in Notepad (preferably on a Japanese OS) and save it back out as Shift-JIS ("ANSI" in Japanese Notepad). Then recompile the CHM by invoking hhc.exe from the command line and the contents will show up properly.
• Searches using single- or double-byte characters do not work in the resulting CHM.

These strike me as rather large, empty boxes on the checklist of global-readiness. Still, the source code is available, so if your organization has already started down the Doxygen path, you can clean up problems like these for your worldwide versions.

Interested in this topic? You might enjoy another article I've written called Localizing Robohelp Projects.

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.

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.