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