Translation non-savings, Part I

How far will you go to improve your localization process?

Because of how localization is viewed in many companies, the best improvements are the ones that lower cost. Low cost helps keep localization inconspicuous, which is how most companies want it.

But if a big improvement didn't save any obvious money, would your organization go for it?

Elsewhere in this blog I relate the saga of the compiled help file with 3500+ HTML pages in it. These pages come from a series of Perl scripts that we run on the header files to extract all of the information about the product's API and wrap it up in a single, indexed, searchable CHM. In a variety of experiments, we've sought to move the focus of translation from the final HTML files to a point further upstream, at or near the header files themselves. If the raw content were translated, we believe, all downstream changes in the Perl scripts, which get revised quite often, would be imposed automatically on the localized CHM.

One of the biggest cost items - we have suspected - is due to changes in line wrapping and other HTML variations that confuse TM tools into thinking that matches are fuzzier than they really are. The false positives look like untranslated words when analyzed, so the wordcounts rise, and not in our favor.

"If we work with raw text, before HTML formatting," our thinking goes, "the match rate will rise."

Not.

I'll describe my experiment shortly.

Why Localize At All?

This question seems more dangerous than it really is.

You should be asking it at the beginning of your localization lifecycle, because you need to convince yourself and others in the organization that the effort will pay off, or at least that the gamble is worth it. The decision to go global ripples to every department in the company, and some companies in certain vulnerable points in their life are not ready for it.

But you'll transform the question from, "We shouldn't localize at all," to "We shouldn't localize right now." So you engage in healthy waiting.

Later in life, after a few rounds of localization, somebody will pose the question again. "The extra revenue isn't worth it. We're spreading ourselves too thin. Why localize at all?" This too is healthy questioning. (There's usually a "Why don't they all just learn English?" from somebody on executive staff. It's best to just smile and steer the conversation away from such ratholes of hopeless ethnocentrism.)

At this point in company history, you'll likely rephrase the question to "Are we really localizing as smart as we could be? How can we do it more efficiently and only for the most profitable regions?" You'll introduce more efficiency and raise the profile of localization.

Go ahead and keep asking "Why localize at all?" It's good for you and for your organization. Start worrying when nobody poses the question any more.

Localization in the Flat World

You need to understand the localization process - even if you're in denial about it - because the world is flat (apologies to Thomas L. Friedman) and the sooner you see how the process goes, the sooner you join the ever-flattening world.

Do you see your company in the following scenario?

We're bringing a prospective new client into the flat world. Up to now, they've dealt with translations, in which somebody overseas says, "We need to be able to read this document in our own language." Recently, though, the folks overseas are saying, "We need to be able to use your product in a way that makes sense to us." The unspoken rest of the sentence, of course, goes, "...or we'll find a different one and use it."

They are on the road to localization. What's next?

1. Demystify the process. What's really involved in creating a localized product? How much will it affect this organization?
2. Identify and talk to all stakeholders. Inform them of what's coming and what will be required of them.
3. Figure out exactly what needs to be localized: software strings, documentation, help, Web pages, installer strings, sample files, etc.
   
4. Create a project plan. Much of it will be wrong the first time out, but as long as you know it's a living document, it will serve its purpose.
5. Appoint or find a project manager. The localization project needs a champion (some might say a lightning rod), because it won't all happen on its own.
   

Rights to the Localized Product

You need to keep an eye out for TRM ("translation management rights," a term I've just coined), because they may not be enforced just for hopeful thinking.

If you're creating software, documentation or a Web site in English, who owns it? Your company, of course. True, the words that went into the product came out of your brain and fingers, and not those of your company, but it's work you've done for hire, so your company owns it. This is probably spelled out in your employment agreement.

Most of the time, this will apply to the localized version of your product as well, but it's worth being clear about it with your vendor. True, the translated words came out of the brain and fingers of the translators, but you wouldn't want the translators to own it even if they were in your employ, let alone when they're outside contractors, which they usually are.

I hadn't thought about this for ages until a recent project took me to the site of Association of
Finnish Translation Companies - SKTOL. Since a prospective vendor referred to them in his estimate, I took the time to read their General Terms and Conditions and found the following among them:

7. COPYRIGHT

The company holds the copyright as referred to in the Copyright Act (404/1961) to the translated text unless otherwise agreed. The company assigns the right of use to the translated text in the extent and for the purpose required by the commission.

Unless otherwise agreed, the company holds all rights to the translation memories generated in conjunction with the work it carries out.

This struck me as odd, and either stunningly progressive or hopelessly out of date. Of course, they don't claim "exclusive copyright" or "exclusive rights to translation memories," so they wouldn't likely withhold either from the client, but these struck me as singular rights for a contractor to try and claim.

None of my clients would have any part of this. Would your company?

Not Really Localization

What do you know about interpreters? It's not the same as localization; not even the same as translation.

I've had clients ask me to help them source interpreting projects, but it's a different kettle of koi. Some observations:

1. Unless you've got idle resources at your beck and call, this is not something to be cobbled together at 4:30 on the afternoon before you need interpreting.
2. As in translation, there are fields of expertise. An interpreter well versed in legal proceedings may not be the best candidate to interpret technical discussions at a life sciences conference.
3. Interpreters appreciate - and do much better with - any subject materials you can offer, preferably in both source and target languages. Brochures, datasheets, documentation, terminology lists, Web pages and similar publications help set the interpreter's brain in the direction needed to do the best job.
   
4. Interpreting is exhausting. (Try it sometime.) These people conk out after 30-45 minutes and need a break. They often travel in pairs for this reason, to spell each other.
5. Simultaneous interpreting is different from sequential interpreting. An example of the former is what goes on at the U.N, usually with headphones and isolation booths. If you don't have that kind of infrastructure, you're probably faced with sequential interpreting, in which a bilateral meeting becomes a trilateral one, as the interpreters become a third party to the meeting, slowing things down to interpret everything in both directions.
   
6. A good translator does not necessarily a good interpreter make. Don't assume you have the latter because you have the former.
   
7. Nobody can believe it's as expensive as it is.