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.

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

Ever hear your children make similar utterances, except with different predicates ("go to bed," "clean my room," "do my chores")?

One of our clients is staffed with people too polite to say things quite so bluntly (but not too polite to dig in their heels similarly). The upside is that I enjoy working with almost everybody I've ever encountered there; the downside is that there are some places where their global-readiness is stuck.

Web presence
I bend over backwards to uphold a simple rule of Web navigation: Localize everything along the click-path to a visitor's goal. So, if a visitor starts on a Russian home page, and decides she wants to download a Russian version of the trial product, I believe in ensuring that she doesn't have to put up with English on her way through the site, unless she wants to do so. Or, if we need to push her to an English page, I try to make it apparent with "English only" next to the link.

We've made a lot of progress in combing out the remnants of English that dot many localized sites (that makes my skin crawl - how about you?), so that each page is linguistically pure to several levels. That was expensive and it took a lot of time.

The problem now is that this client's site relies on a lot of plumbing for verifying that the visitor is not from an axis-of-evil country, or hacking the site, or trying to perform unsupported operations, and the UI for all of this infrastructure is in English. Much of it is just background code, but several pages (login, registration) are in English, and the infrastructure team is not interested in localizing any of it, despite my polite persistence.

License agreement
This is a hot one. When you download trial software from Germany or Finland, do you click "I accept" to a license agreement in that language? Granted, German and Finnish are not the lingua franca that English is, but how much more does it say about the relationship you want to have with your customers when you make some effort to inform them of your business terms in their language?

"We don't translate anything legal, and it's not hurting sales," I keep hearing. This is a battle I know I'll never win, so I look for victories elsewhere.

Site logic
There was a sudden need some months ago to place a terms and conditions page in the click-path to a particular download. Naturally, the terms and conditions were in English only, and I could have lived with that. The problem is that the code behind the page sent the visitor to a particular next page, without regard for where the visitor was going when he landed on the terms and conditions page.

So, visitors on the way to download the Korean/Japanese/Chinese/Spanish... version of the product sailed along the click-path in their own language until reaching the terms and conditions page. Then they agreed to text they almost certainly did not read, then they landed on a completely irrelevant page of English, with no reasonable way of getting back to their intended destination.

This is related to the inflexible plumbing I mentioned above. It's great infrastructure; it's just monolingual and it doesn't really need to be.


Anyway, these bits of stubbornness amount to a small downside in a client that is not stingy about localization in general and that has a strong global presence. They're correct when they say, "I don't want to localize that, and you can't make me," so it's easier to roll with the punches and enjoy other victories.

Besides, if I'm around long enough, they'll move on and I can take the matter up with their successors.

What things have people told you they're not going to localize, and you can't make them?

Localizing multimedia (Flash, QuickTime) - Part 4

Oops! What about the broadcasters?

Sometimes you're localizing a commercial or a product demo intended for viewing over broadcast (think Home Shopping Network) or at the point of sale (think sports equipment demo). The localized Flash or QuickTime files that you poured into .flv or .swf format are of no help here, because someone has the intention of pushing a tape into a machine in a broadcast operations center or sliding a DVD into a player in a department store.

As usual, your client may take for granted that you understand this, and be dismayed when the right physical media doesn't show up. One client had no clear directions for us in this regard, and we've since learned that the question we need to ask is, "How will the localized multimedia be viewed?" or "Do you want a playable DVD for this?"

The project was rushed, and it was all we could do to determine ahead of time the proper specifications for the Web-based deliverable (described in the Part 3 post). They instructed us in the easy matters - "We need Italian, Spanish and German" - but we never did get a solid answer about physical media, so at the end of localization I asked the studio to bundle up these assets:

• the original, uncompressed audio/video footage (about 7GB)
• .mov files with each of the localized subtitles only (no audio/video; about 400MB each)
  
• the translated scripts
• the .flv files we'd used as previews for publishing over the Web

We didn't really know exactly what the client's in-country partners and customers would need - and were convinced it would take the client a long time to tell us - so we gave them a set of data files that would not paint them into a corner. That seemed better than our guessing at the ultimate use for these, and getting it wrong.

Sure enough, two weeks later they phoned. "Why doesn't the Italian version play when I put in the DVD?" the client wanted to know. I explained that the client would first have to determine exactly the format in which each country wanted the DVD, then have a studio build a playable DVD from the files we'd handed off. This last step would not require a studio with localization expertise and could probably be executed less expensively by the people who had created the original English-language media.

There was also some confusion about regional codes, which ended up relating only to piracy prevention. Since nobody was worried about illicit duplication of the media, that issue went away.

The moral: Ask all the questions ahead of time. Then ask at least one more.

Do you have that "one more question" you wish you'd asked ahead of time? Post it in a comment.

Windows Vista Multilingual User Interface

Have you started localization testing on Vista yet? They've taken the fun out of it.

Windows 2000 was easy. The OS is relatively small, and you could even maintain multiple native systems (Win 2000 Ja, Win 2000 Ko, Win 2000 Es) on separate partitions or virtual machines. If your testing wasn't that rigorous and you just wanted the localized UI, you could slap the Multilingual User Interface (MUI) onto an English version of Windows without much headache.

XP required a bit more work, not to mention disk space, but it was still manageable, especially with drives as large as they are.

Vista feels like another order of magnitude in complexity. Actually, the process of building the testbenches is not that formidable, but the space requirements are. Just to reduce overhead, one of my clients has asked that we plan to test on MUI instead of native OSes from now on. Not the optimal vision, but we'll work with it.

MUI is not air-tight. The font and locale support is good, but it leaks English all over the place. (Apparently you can install MUI only on top of an English base OS.) It's not great for screenshots because you cannot always rely on perfectly localized UI, but it's a fair gauge of how your app will work in the target market.

There's an intimidating procedure on Microsoft's localization Technet for configuring MUI under Vista. I couldn't believe it was really this difficult - it need not be - so I poked around some more and found a different, simpler way.

1) Upgrade to Vista Ultimate or Enterprise. Vista MUI won't work with Home or even Business Editions, so plan to spend the money on the upgrade. From Windows Anytime Upgrade (WAU) you can pay US$139-159 for a license key to Vista Ultimate. If your company manages such things, you can find out whether it already has a site license for either of these.
2) Depending on the media you received with your machine, you may need to order (US$8) the WAU DVD also. The MUI files are not on it, but the files needed to upgrade the OS are.
3) After installing the upgrade, be sure to activate it.

Congratulations! You now have Windows Ultimate (and several fewer GB of disk space).

4) Go to Windows Update, which is where the language packs live. Microsoft used to make these available via MSDN - perhaps they still do - but now they're available as optional Windows updates.
5) Your upgrade to Ultimate/Enterprise may entail a few required updates. Install those first and get them out of the way, or else your request for the language pack may not take.
6) Select the language packs you need, start the download and go on vacation. The Japanese language pack is about 800MB in size, so you may do well to install one, play with it for a few days, then install others.
7) Go to the Regional and Language Options control panel. On the Keyboards and Languages tab, choose the display language. Windows requires only a logoff (not a restart) and at login you'll see something like this:

(Click image for expanded view.)

Explorer's menu is localized, but Wordpad's is not. Most of the Windows-specific titles are localized, but the date on the clock is not. It's a hodgepodge, and MUI may not meet all your needs.

Our resulting testbench comprises Vista Business, the upgrade to Ultimate, the Ja language pack and McAfee VirusScan. Call me a dinosaur, and many other people have complained about Vista's disk usage more eloquently than I can, but I'm up to 12GB (2GB of which is the hibernation file that won't go away), which strikes me as quite a bit. So, if you plan to create several localized Vista testbenches, get a fat drive.

By the way, we experimented with localized virtual machines based on Vista. Even devoting 1 of the 2 GB of physical RAM to it, the VM ran so poorly that it was just plain not worth it.

If you liked this article, you may enjoy another related article, "Localization Testbenches - Part I."

Localization, Globalization - What's in a word?

I repeat the title: "Localization, Globalization - What's in a word?" Plenty, if you want people to find you on the Web.

If you're a language provider trying to get noticed among search engine results, you know that it's important to choose your words carefully. In my post Top 5 Web searches I outlined several keyword combinations people frequently use to reach this blog and our Web site. Two of the most important terms in our industry deserve some attention.

Globalization/Globalisation. Many vendors use this term, and many of us in the industry apply it to our job titles: "Globalization Consultant," or "Sr. Globalization Manager." There was a time when I used it as a keyword for Web pages, pay-per-click campaigns and even my business card.

I stopped after a while, though. "Globalization" is often associated with rioting by farmers in developing countries, and multinational companies that behave like sovereign states. Yes, I do riot and behave imperiously from time to time, but those are not the services I'm advertising, so the use of that word brought me erroneous visits from people doing research on the World Trade Organization and coffee prices.

If you qualify it with "software globalization" or "Web globalization," the search engine delivers more accurately, but it's still a prickly bit of jargon. Try telling your uncle or somebody you're cold-calling that you're in globalization; they'll think you're talking about leftist politics. The word just gets in the way.

Localization/Localisation. This term is different. As with "globalization," most uncles and persons you cold-call don't know the term; however, it's unlikely that they'll confuse it with something else, because it's unique.

Or so I thought.

I replaced occurrences of "globalization" with "localization" among my keywords and I now receive far fewer mis-visits as a result of search engine results, but I think the mis-visits will increase before long. The English word "localize" means "to fix or assign to a particular place," but it's not a very common term in English. The term is a bit muddy now (because of French), and will get muddier in the future (because of cellular telephony).

Early on, I received queries from France, Italy and Canada using "localisation" in combination with words that suggested "how to locate something" or "where somebody is right now." These people land on my site or blog by mistake; they're trying to find a device for locating merchandise in a warehouse, or want to know how to restrict malaria to a particular region. This is just a case of mistaken (keyword) identity.

With cellular communications, however, come location-based services equipped to help your favorite people (and favorite retailers, it goes without saying) "localize" you. For example:

About Krillion - Krillion is a premier provider of local shopping search information, serving today's ready-to-buy consumers who research products online for purchase from retailers in their area...The powerful combination of our patent-pending Krillion Localization Engine, localized search results covering over 10,000 products in 40,000 U.S. locations, and unique, real-time StockCheck(TM) tool enables consumers to speed their research-to-purchase process and take advantage of in-store pickup services offered by many retailers near them.
(I have no financial interest in Krillion.)

We've all dreamed of the day when businesses would begin to talk more about localization, because we could spend less time educating and more time improving the process. If the term gets muddied, however, we'll spend time explaining which "localization" we offer (language, not global position).

Translators and instructions - hit or miss

What do you do when it seems that the translator is ignoring your instructions?

I have boundless respect for translators. I couldn't do their job as intensely as they do. But sometimes the intensity creeps into artistic license, and we worker bees get burned.

We had a high-pressure rush job last week. The Taipei office had a 30-page report translated from English into Chinese for Taiwan, and wanted a sanity check on the translation. The document was ready after close of business Friday in Taipei, and the reviewed version had to arrive before start of business Monday in Taipei.

We scoped the work as follows: The translator's job would be to "review the Chinese document for grammar, usage, punctuation, and to ensure that the English meaning is preserved in the Chinese version. All modifications should appear as tracked changes to make them easy to find." That seemed as clear as I could be about what we expected, and the translator's manager acknowledged the request.

The translator returned the document on Saturday, one day early, having modified almost every sentence in the entire document. As I looked through it, only a few possibilities occurred to me:

• The original translation had been a train wreck, and the reviewer had to clean up text everywhere.
• Something had gone wrong with change tracking in the document.
  
• The translator had not received my instructions and had introduced stylistic changes.
• The translator had ignored my instructions and had introduced stylistic changes.
  

Somewhat tentatively, we delivered the reviewed Chinese document to Taipei on time, mentioning the extensive changes proposed by the translator. Meanwhile, I told the translator's manager that I felt he had ignored the instructions. The translator replied, "There was a room to improve the readability of original translation. Although some mistranslation existed, the translation generally was still good."

The translation generally was still good?

Now, I appreciate a thorough job as much as the next person - even if I can't read Chinese - but this was not the time for it, and my instructions had been quite specific. Nobody in Taipei had the time to go through and accept or reject each change. That's part of the "rush" in "rush job." There's no easy way to go through 30 pages of changes and separate the instances of mistranslation and loss of original meaning from stylistic changes intended to make the document a better read.

How do you get your instructions across to translators?

If you enjoyed this post, have a look at this related article: Instructions to In-country Reviewers

Offshoring Localization and On-shoring the Communication

You're offshoring your localization or development work to China and saving lots of money. Upper management is delighted. Your localization dollars are going further than ever. The offshore partner's project managers are professional and responsive. It's everything you'd hoped it would be.

Almost.

There's a little something that feels strange on your conference calls and status meetings. The work is getting done - mostly - and the schedules met - mostly - but there are gaps here and there in the relationship. It feels as though, when there are misunderstandings, they seem to get resolved, but not in quite the way you expect. Sometimes their approach to solving a problem seems off the mark to you, even if it works out in the long run.

In short, you feel as though the communication could somehow be better. You can't quite describe what's amiss, but it nags at you.

Believe it or not, your partners in China may have the same impression.

This week I met with one of the U.S. representatives of a large Chinese offshore development company that offers, among other services, localization. Besides finding new customers, he's tasked with acting as the on-shore presence for existing customers.

"There are subtle ways in which our managers and developers don't quite connect with some clients," he told me, "and it's not just because of the language barrier. I look at it as two layers of cultural difference: first, there's the east-west difference, then there's the cultural shift the client undergoes when product structure changes to the offshore model. In other words, it's strange enough that an outsider is now responsible for large portions of your product or service, and even stranger because that outsider is somebody with a completely different kind of life and world-view from yours."

This is a novel role. He's not the project manager, moving files back and forth and matching jobs to translators. Nor is he the account manager, working out contract details and managing payment schedules. He's the communication manager, or the relationship manager, helping to fill in the almost undefinable gaps that sometimes prevent clients from really clicking with their offshore partner. In fact, the company hired him to place his localization expertise and customer skills on this side of the Pacific, within a couple of time zones of its key clients.

"So I spend a lot of my time just listening, "he continued. "I'm on conference calls, I'm visiting client sites, and I'm getting face-time with our clients and our staff, picking up on the subtle things that we can deal with now, so that they don't blow up later on."

Whether they choose to believe it or not, most people who are offshoring work to China (and India and Romania and Lebanon and...) know that those countries will get it right sooner or later. In fact, it will take fewer years for them to get it right than it did for us to get it right.

A client-side relationship manager will play an important role in getting it right, and the position will become mainstream before long. The opportunity for both vendor and client is ripe, and the benefits are long-lasting.

If you learned something from this post, have a look this related one: "Making Sense of Outsourcing"

Localizing multimedia (Flash, QuickTime) - Part 3

Part 1 of this series described the background education many companies (especially upper management) require when they want to have their multimedia files localized. Part 2 described what you, as localization project manager, need to know.

This post describes more production details, including the output and deliverable formats in which clients want to receive these localized assets.

Linguistic Review - An important issue in production has to do with linguistic review. What happens when the client's in-country reviewer plays the localized video and wants to change a few words in a subtitle or - much worse yet - a sentence of voiceover? This is not as simple as opening a Turkish MS Word document, modifying a few lines and saving the file back out. In this case, the subtitles and voiceover are separate video/audio assets, and it will be necessary to re-create them, to replace them in the main video project, and to output the final as a single, uncompressed file.

It's a lot of work to clean up a few typo's or update a term.

For that reason, it's best to perform in-country review before production starts. Don't wait until the video is ready; send the source and translated subtitles or script in a side-by-side table for review. That way, you can accommodate the reviewer's comments because the project is still young and time is still cheap.

File specifications - Assuming that the localized video will end up on the Web, you need to obtain information about:

• codec used (e.g., Sorensen Spark Pro codec, 1 pass CVR)
• screen area/resolution (e.g., 240x180 pixels)
• output file format (e.g., .flv Flash video, .swf Shockwave Flash, .qt QuickTime video)
  
• target file size in megabytes (mostly as a sanity check that the localized files is of similar quality to the original).

These down-in-the-weeds specifications usually come from the video technician or webmaster. Note that, to play a multimedia file over the Web, the Web server must support the delivery of the format so that visitors can simply click on a link, and let a browser plug-in do the hard work. However, if you need to play the file on a computer without the Web server plumbing, you'll need a standalone player for the specific type of video file. This may be Apple's QuickTime Player, Windows Media Player or Moyea's FLV Player. (These players are handy for quick previews for upper management, who don't want to wait for them to be posted to the Web site.)

Deliverable format - What to give back to the client? If you're lucky, the output file is all they want. If not, you can give them all of the project files, but only their own media studio will be able to work with them, and they won't have the linguistic expertise of your localization vendor, so the files could end up amounting to a few DVDs of data nobody will ever use. On the other hand, that describes about 75% of everything anyway, so it's cheap insurance against the day they change vendors or come up with some other wild reason to use them.

If the localized video is meant for broadcast, you'll also need to output it to a tape master, at which point formats like PAL and NTSC come into play, depending on the target country.


In summary, multimedia is not as tractable as documentation, Web content or even software when it comes to localization. This is due mostly to fixed costs for studio time and voiceover talent, and to the non-text-based nature of audio/visual.

Localizing multimedia (Flash, QuickTime) - Part 2

Part 1 described the background education many companies (especially upper management) require when they want to have their multimedia files localized. This part describes what you, as localization project manager, need to know. This information is important for you to request and deliver the right things, but it's not very likely that upper management will be interested in it.

Assume content like a 60-second product introduction, with actors speaking on screen and graphical text in need of translation and layout.

1. As usual, you should plan for a glossary or terminology list. It's always important to ensure you use a properly current term for "pain relief" or "outfielder's glove," but the cost of opening up an already localized complete project to tweak a couple of words - particularly spoken words - can be prohibitive. If your in-country partner has approved of your terminology ahead of time, you'll save yourself headaches in the long run.
2. Pare down your cast for the localized version. If your commercial includes one female and two male actors, do you really want to pay voiceover fees for all three of them? Consider using the same voice for both males, and subtitling the female. When your budget gets bigger, you can spring for all three linguists.
3. Files are huge, so don't count on moving them over the Internet. You'll want the translation studio to work as far upstream as possible, so plan to give them the original video footage, not a compressed QuickTime or Shockwave Flash (.swf) file. These can be several GB in size for only a few minutes of video, so plan on moving DVDs or thumbdrives.
4. If the commercial was created as a digital studio file (e.g., Final Cut Pro), hand off the entire project, just as you would hand off all the surrounding files needed for a software localization project. This enables the localizers to open graphics, replace text and drop in the voiceover, then output localized versions on par in quality with the source version.
5. Studio time is not very flexible. Even though your movie has only 60 seconds of voiceover, you may need to book half- or even full-day linguistic talent in multiple languages. This can be a rude surprise when it seems to you that the original voice talent was nearly free (or so you thought). And, as stated above, opening and closing these projects to make apparently minor changes can run into major money for engineering time.
   

Clients are not always specific about the output and deliverable formats they want for these localized assets, so it may take a while to find somebody who will give you more details beyond, "We need the video in Japanese, and quickly." Part 3 will cover that.

A localization lesson from North Korea

You never know how your next lesson in localization will reach you. What if you were to learn something from a digital trailblazer like North Korea?

The International Herald Tribune reports that North Korea is offering overseas shoppers the chance to buy hundreds of its goods through the Internet. Offered items include boxing gloves, bicycles, commemorative stamps, roller skates and uniforms for Taekwondo. While the site is obliging enough to accept credit cards, it has not yet reached the level of capitalistic level of revealing prices.

But the most forward-thinking aspect of the site is that, right out of the gate, it is localized into Korean, English, Chinese, Russian and Japanese. How many of us are that enterprising and globally inclined? Show this post to your boss and say, "See? Even lowly North Korea can develop and implement a localization strategy. Why can't we?"

The hitch: The site has been live since 31 Dec 07, but it spends a lot of time off line. Try your luck: www.dprk-economy.com/en/Shop/index.php

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

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

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

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

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

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

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

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

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

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

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

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

Making Sense out of Outsourcing Localization to China - Part 1

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

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

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

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

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

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

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

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

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

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

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

Instructions to in-country reviewers

"The best translation of any sentence is the one that the customer likes the best." -Me

Did you learn this the hard way, as I did? Back in the old days, I would marshal the translators' dictionaries and sources against the dictionaries and sources of my in-country reviewers to prove a point. Ultimately, of course, that never paid off, and I came to realize that regardless of who had which references, it's the in-country reviewer who should generally prevail, for a couple of reasons:

• The reviewer, not the translator, has to live with the translation and can eventually be convinced that it's important work.
• The reviewer, assuming I've selected him/her properly, is as close as I can get to the consumer of the translation (the real customer), and whether a linguist or not, best understands the terminology that will make sense to that consumer.
• Even when the task of review falls to a completely mismatched person, like a salesperson reviewing a user manual, there is still more value in having him/her review it than in sending it to another translator. I generally get less feedback from a non-technical reviewer, but it's a better sign-off.

Sometimes, though, the in-country reviewers really are linguists (or want to be), and they introduce considerable changes in the course of their review. It's important to give them guidelines for the reviews they perform so that they understand what we want and don't want from them. Among those guidelines:

• First and foremost, look for areas in which the translators have completely missed the point of the source text. Customers will overlook small, stylistic differences between source and translation, but they will become angry if the translated content is just plain wrong.
• If the source text is wrong (e.g., incorrect procedure or misstated information), take it up with the writer of the source text. Our job is to translate the source, not define it. If you make your suggestions in English, we can forward them to the writers, but we cannot in good conscience put out a translated document that does not match the source.
• Be specific about the changes you propose. In reviewing a word processing document, enable change tracking so that we can easily find your modifications. In a PDF, annotate the document with your comments. For HTML pages, use a spreadsheet or table-formatted list. The easier it is to identify your changes, the easier it is to implement them correctly.
• While you're welcome to review every sentence on every page, we don't expect you to do so. You'll know after a few paragraphs whether the translation is atrocious, and that's the most important thing we want to establish.
• We'll incorporate as many of your changes as possible. Some of them may have to wait for the next version of the product.
  
• In the case of long documents and detailed review, rate your comments by severity so that we can address the most urgent ones first.
  
• In order for us to keep to our schedule and deliver the finished product so that you can begin selling it, we need your comments back by [give a specific, reasonable deadline].

Frankly, the last point is the most important. Without a deadline, reviewers will often procrastinate the work mercilessly, and you'll end up waiting a long time only to get nothing.

Localizing multimedia (Flash, QuickTime) - Part 1

Localizing multimedia such as Flash files and QuickTime movies is a different pond of koi from localizing documentation, HTML and even software. Advertisements, videos and clips abound on the Web, mostly because they tell a story in a much more compelling way than does mere text. Also, it's becoming easier for content owners to record footage and to host it on their Web site.

It's a brave, new content world. And they want to localize it.

The first hurdle is that the media is not very well internationalized. The movie file on the Web is usually greatly compressed, with several layers crunched into one or two, and billions of bits discarded. Nobody needs all of that detail to see the clip, but you need it to localize it properly.

The second issue is that site owners rarely understand how the original was put together, let alone what it will take to localize it. They may know about superless splits, B-rolls, dub houses, producers and BetaSP, but you trying to get files - extremely large ones - from them, with all of the video, audio, graphics and effects to localize.

Finally, in the same way that most companies regard a software project in its original language, the content owners view the multimedia as core work product that is already behind them, and wonder why there's so much work/time/money involved in preparing it for an overseas audience.

Despite these hurdles, content owners do indeed want to go down this path. In Part 2, we'll explore a typical project in more detail.

SDL TMS or Idiom WorldServer?

Question from one of the subscribers to this blog:

"We are in the process of bringing on a workflow tool. In general, for software, DITA/XML, and Frame files, do you prefer working with the SDL Translation Management System, or Idiom WorldServer, or another program? I have my own ideas, but I'm always curious to hear the opinions of other localization professionals."

I recommended asking pointed questions to ensure the chosen vendor/solution:

• doesn't lock you in to a particular LSP, or out of freelance translators who won't have the tool
• manages the native file formats, without conversion
• allows you to talk to internal technical leads (not just salespeople)
• offers integration with your version control system, so that you're not manually moving files to and from your engineering repository.

Those of you with experience using these tools, kindly comment.

WWMSD?

"What would Microsoft do?" What do you do when you need to translate according to the terms Microsoft uses?

Microsoft has a long, storied past of localization, and a correspondingly colossal corpus of translated material. Until a couple of years ago, they made just about every string in dozens of their products available in .csv files via FTP for free download, subject to copyright. No doubt that became laborious for them - it certainly was for those of us who tried to keep up with them - so they've since switched from making all of the strings available to making 12,000 key terms available in up to 59 languages in a single, 10MB spreadsheet. The file is at www.microsoft.com/globaldev/tools/MILSGlossary.mspx

The winners in this simplified approach are those linguists creating a term list, or translation glossary, for a specific project that must adhere to Microsoft terminology; e.g., how Microsoft translates "Cross Array Link" in Korean. The losers are linguists who need to know, for instance, how "Completing the Hardware Wizard" or "Windows Security - Verify Publisher" is rendered in Slovak or Pashto.

The term list also takes aim at a long-standing problem with localization at Microsoft (or any large organization); namely, that there was inconsistency in translation among products. While not all translators will agree that these terms are ideal in a given language, at least this is a move in the direction of consistency, and sometimes it's better to be consistent than to be right. It's generally easier, anyway.

If you enjoyed this article, you may like another called "Where Do Your Glossaries Live?"

Low Quotation - Four Questions to Ask

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

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

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

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

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

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

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

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

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

Let me know how it goes."

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

Your thoughts?

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

Localization - Investment or Expense?

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

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

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

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

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

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

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

We all [heart] PDFs!

Any good localization manager (vendor- or client-side) knows that there's very little you can do with a PDF as a source file. Yet time and again, we confront the best intentions of our customers and co-workers who say, "It's not a very large file, so it shouldn't cost much to translate. I'll send it to you." They send us a PDF.

This has happened to me with two new clients this week. We'd all like more translation business, and it's convenient that it exists as a lingua-franca format for us, but PDF is something of a double-edged sword.

PDFs contain everything we need to view a file, but not everything we need to extract the text, formatting, callouts, frames, tags, etc. from it. Creating a localization estimate on a PDF is asking for trouble, because it smooths over a multitude of different issues that we'll encounter once we have the source files, most of which concern text that we know requires translation, but which is not "live" in the PDF and may not be live in the source file from which the PDF came. It's the equivalent of hard-coded strings in software, or localizing a binary without the .properties or resource files.

There are, of course, utilities for converting PDF to RTF to capture the live text and formatting, and that's better than nothing, but it's probably still a far cry from the Quark or InDesign or even MS Word file from which you started. I've sent one of my new clients back to the drawing board several times this week already:

1. He gave me a PDF and I asked for the source file.
2. He found the source file (Quark) and I asked for the Photoshop files from which the text-bearing graphics had originated.
3. There were tables in the Quark file that were Illustrator objects, because these looked much better than Quark's native tables.
4. Another PDF of a Word document contains eight graphs created by engineers all over the building. He said he'd try to obtain the original artwork (probably PowerPoint, every engineer's favorite Etch-a-Sketch), but I'll be surprised if he can find it.

So, folks, we love to localize your pieces, but try to keep tabs on all the bits that you drop into them. We can do things so much better-cheaper-faster when you do.

Keeping an eye on Catalyst

In localization, "Catalyst" is a tool from Alchemy Software. Among other things, it allows you to localize UI elements within software resource files, sometimes without the need to rebuild the software manually into binary format.

Since software binaries come from text files, part of Catalyst's value lies in straddling the divide between allowing the translator to change strings in the these text files (say, from English to Japanese) and displaying them in the binary, run-time format in which the user will see them on screen.

Last month a vendor returned some resource files to me which we had them localize from English to Japanese. I rebuilt the binaries (language-resource DLLs) and ran them. Unfortunately, a number of items were suddenly missing from the Japanese menus, so I had to troubleshoot the problem.

My first thought was that either a person or a tool (or a person using a tool) had modified something that should not be affected by the localization process. I had handed off a resource file containing these lines:

32777 MENU DISCARDABLE
BEGIN
POPUP "&Tools"
BEGIN
MENUITEM "Serial P&ort Settings...", ID_TOOLS_SERIALPORTSETTINGS
MENUITEM "&Network Settings...", ID_TOOLS_NETWORK
MENUITEM "&Battery Settings...", ID_TOOLS_BATTERYSETTINGS
END
END

32779 MENU DISCARDABLE
BEGIN
POPUP "&File"
END


They returned to me a resource file containing these strings:

9 MENU DISCARDABLE
BEGIN
POPUP "ツール(&T)"
BEGIN
MENUITEM "シリアルポートの設定(&O)...", ID_TOOLS_SERIALPORTSETTINGS
MENUITEM "ネットワーク設定(&N)...", ID_TOOLS_NETWORK
MENUITEM "バッテリの設定(&B)...", ID_TOOLS_BATTERYSETTINGS
END
END

11 MENU DISCARDABLE
BEGIN
POPUP "ファイル(&F)"
END

There was nothing wrong with the translation, and the string IDs were intact. The product has long been "double-byte clean," so I knew that the software was not gagging on the Japanese characters.

The problem lay in the menu ID numbers, which are 32777 and 32779 in the English, but which came back in the Japanese files as 9 and 11. The vendor believes that Catalyst changed them, since they had used it to for resizing and QA.

Normally, this renumbering has no effect on how the binary functions. In this case, however, it has a profound effect on how the binary functions, because there is code somewhere in the software that is looking for "32777" and "32779" and when it doesn't find those ID's, it cannot complete the menu. This is poor internationalization in the code base which I have discussed with Engineering, to no avail, so I need to police the resource files in each round of localization.

How is Catalyst working for you? Have you seen similar problems?

Interested in this topic? You might enjoy another article I've written called "Localized Binaries - The Plot Thickens"

Have you cleaned behind your glossaries?

Don't take this question too personally. After all, I'm not asking whether you've cleaned behind your ears, or behind your couch. But last week I asked the digital question, "Where do your glossaries live?" and this week I'm asking about the state of their hygiene.

One of my client-companies is quite proud (and justifiably so) of the considerable work they did a couple of years ago in building out a 600+ entry glossary in ten languages. They (or their language vendor, really) have hosted it on the Web, with read-only access to any translator who does work for them.

This model of glossary has the inestimable benefits of being universal, up-to-date and centralized - there is only one glossary - instead of being a patchwork of spreadsheets and tables on several different hard drives in several states of accuracy. It's set up for alpha-listed browsing and search, although the search function is not fuzzy unless you use wildcards, so some translators will not derive full benefit from it and may in fact miss terms.

While managing a sample translation for the client, I wanted to export the glossary to review it all at a glance, so I mentioned that. "Nope. That's not possible," the client told me, with more than a hint of pride. "We designed it so that there would be only one glossary in one format in one place. We don't want it exported or circulated unnecessarily."

Now, I'm in business to see my clients succeed, but that kind of mindset is just a tempting challenge to me, and as I managed the sample translation I deliberately looked for reasons why a hermetically sealed glossary like this was a bad idea. Naturally, I found one: The client had not cleaned very well behind their glossary.

Several industry-specific terms occur in the sample, and I knew the translators would be obliged to use the glossary. For instance, terms like "drive" occur in various combinations ("link drive," "offset drive," "drive mechanics," "rack-mount drive," etc.) in the glossary, and as I poked from one entry to another I noticed inconsistencies and contradictions in how "drive" was translated, notably in German. One entry gave "Laufwerk" as the translation, and another entry bore the note that "'Laufwerk' is obsolete."

The online model for hosting this glossary is a good one for several reasons, but it's not amenable to the healthy, periodic scrub that such databases should undergo. If the glossary were exportable, or at least visible in row-and-column format, these inconsistencies would be easier for translators to spot and address.

Interested in this topic? You might enjoy another article I've written called "Where do your glossaries live?"

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 expert