Who owns this Localization Project?

It's almost time to ship. Do you know who's running your localization project?

Recently I met with a technology company whose Web-based service is already in seven languages. Non-US revenues are a high percentage of their total, and even though their product is available in both free and paid versions, most customers overseas pay. They take their overseas markets seriously, to the extent that they have an International Product Manager (IPM).

They contacted me about an upcoming push into Asia, and had me attend their weekly engineering meeting. Everyone in the room and on the conference bridge (probably 25 people in total) introduced him/herself, and after the last introduction I paused and said, "Nice to meet you all. Now, where is the localization manager?"

They don't have one, of course, though the IPM performs most of those duties. I rubbed my hands mentally and thought I heard a cash register ringing, until I remembered that they were live in seven languages and doing quite well without a localization manager, thank you very much.

How do they do it?

A lot of the localization expertise resides in the teams, so they told me. Documentation, Web team, Engineering, QA, and Release Engineering all have rather deep, in-group experience that shows in the localized products. That, however, doesn't explain how it all comes together at showtime.

Can you do it without a localization project manager? If so, does that mean that you've done things so masterfully that localization is completely mainstreamed in your organization?

Must be nice...

From Pseudo-translation to Pseudo-localization

Do you like having teenagers handle your medical insurance problems?

Why would you have college students localizing your product?

I've posted several articles on pseudo-translation, which is a science. Pseudo-localization, or the practice of pretending you have good localization processes in place when you're really having exchange students review or--ack!--translate your product and Web presence is not science. It's short-sighted.

I can't say for sure, but I think it has to do with what most people perceive as a black box around foreign languages, especially in the U.S. We're not xenophobes, but we are by and large linguaphobes, and most of us freeze like a deer in the headlights when the prospect of dealing with a foreign language arises.

Frankly, though, it's easy to fall into the practice of pseudo-localization, especially in technology companies. Young employees for whom English is a second or third language are becoming the norm, and while their cultural diversity and mental models are a boon for product development and global reach, are they really suited to translating?

No.

Inside that black box is what people have to do to become accredited translators, and to build and maintain their reputation. They're not fussing about Web-based translation portals and fast, cheap, young translators because they want to cling to their jobs. They're fussing about it because the product quality is lousy, and most Americans don't care.

You're an American localization project manager: Have you ever been in a company for more than three months without hearing, "Why don't they all just learn English and save us this headache? Har, har, har."

Better-cheaper-faster is a triangle, and you can't cover all three corners with the same solution.

So, by all means hire that French exchange student or that Chinese H-1B to work on your localization project. But make sure you get at least one other pair of accredited eyes to review it.

Localizing RoboHelp projects

Is it time for you to localize you RoboHelp projects? What's involved?

"RoboHelp project" is shorthand for "compiled help system." When this lives on a Windows client computer it is usually HTML Help (CHM) files. There are other variations like Web Help, which are also compiled HTML, but which do not run on the client.

The projects are a set of HTML files, authored in a tool such as--but not limited to--RoboHelp, then compiled into a binary form that allows for indexing, hierarchy and table of contents. Other platforms (Mac OS, Linux, Java) require a different compiler, but the theory is the same.

If you've done localization before, you'll find that RoboHelp projects are relatively easy, compared to a software project. RoboHelp (or whatever your authoring/compilation environment may be) creates a directory structure and file set that is easy to archive and hand off. It includes a main project file, table of contents file and index file. In fact, it's even possible in a pinch to simply hand off the compiled file, and have the localizers decompile it; the files they need will fall into place as a result of the decompilation.

Although you may think of the project as a single entity for localization purposes, each HTML page is a separate component. There may be large numbers of these pages that don't change from one version of your product to the next; nevertheless, you need to hand them off with the project, and you'll likely be charged for a certain amount of "touching" that the localizer's engineers will need to do. You may be able to save them some work and yourself some money by analyzing the project and determining which pages have no translatable changes, but by and large you should consider the costs for touching unchanged pages an unavoidable expense.

The biggest problem with these projects is in-country review. There's no easy way for an in-country reviewer to make changes or post comments in the compiled localized version. We've found that MS Excel is the worst way of doing this (except for all the others), so we've learned to live with it.

In theory, the translators are not mucking about with any tags, so the compiled localized version should work the same as the original. Yeah, right. All the links need to be checked--they do break sometimes--and the index and table of contents should be validated. And, don't forget to try a few searches to make sure they work; your customers surely will, and you want to spare them any unpleasant surprises.

Remember:

• If you've included graphics in your help project, you'll need to obtain the original source files. These are not GIFs or JPEGs; they will be the application files from which the GIFs and JPEGs were generated. You'll need to hand off files from applications like Adobe Illustrator, or Flash or even PowerPoint, so that the translators can properly edit the text in them. Engineers often do quick mock-ups in Microsoft Word's Word Art that end up in the final product, and it takes a while to track them down.
• Encoding can be thorny. Some compilers behave oddly if you try to impose the same encoding on both the HTML pages and the table of contents, especially in Japanese, in our experience.
  

Switching Localization Vendors--Take this Quiz

Take this short True-or-False quiz:

1) You think your localization company is much too expensive.
2) Your other contractors or in-house teams cannot work with your localization company.
3) Your in-country offices are complaining about the translation.
4) Your overseas customers are complaining about the translation.

If you scored 2 or more True, you might look into peeling off a language and trying a new vendor out. If you scored 1 True, you should have a chat with your vendor and work out the problem. If you scored 0 True, you are in the localization minority and should count your blessings.

Making a vendor switch involves a lot of re-plumbing and re-education. If your vendor is charging a fair price for good, steady, reliable work, and they're making you look good (or at least, they're not embarrassing you), there's plenty to be said for that.

Keep in mind also that this is a relationship. The vendor won't necessarily get it right the first time--neither will you--but if they show improvement, and they're willing to work with you on making things better, you have the beginning of a beautiful friendship.