Localization Project Management Log

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

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 experts, who can easily modify it. It’s a bit more work for the translator, who would rather have a flat-file document, but overall it serves linguistic interests well. It’s tried-and-true technology built in to most computer-aided translation tools.

What are you doing with your glossaries?

Have you ever stumbled onto something in the course of localizing a product that was private, or maybe even a bit compromising? Here’s a news item from telecoms.com that falls into that category:

This time round, Apple is supposedly prepping its iPhone to be a portable gaming machine, wading into a market already dominated by the likes of Nintendo and, to a lesser degree, Sony.

Although the ‘official’ iPhone applications market is noticeably void of any games at the moment – mainly due to the fact that Apple has banned third party apps from running natively on the device – some hackers claim to have found tell tale signs that games are indeed on the way.

Apparently, the iTunes localisation code makes some reference to a string asking the user if they want to remove the games in question. Naturally, this gave way to rumours that Apple has had a games developer partner lined up for some time and plans to offer gaming products via iTunes. [emphasis mine]

Some alert hacker (or maybe even a translator) must have lobbed a note about this string into the blogosphere, or otherwise publicly asked the question, “Why would they want to remove games?”

Who says there’s nothing proprietary or confidential in software resource files?

Maybe you read this and became encouraged to have your products and Web pages translated over the Internet by college students in other countries:

“In April and May 2007, Palex held an English translation contest for Microsoft software and documentation. It is the second translation contest organized by the company with the purpose of stimulating interest in translation and freelance work and selecting new full-time and freelance employees. With more than a hundred applications submitted, over 70 participants – most of them students and young professionals – completed the off-site translation assignment. Those who delivered the 20 best translations participated in the final stage.

“For the final assignment, the competitors had to translate an HTML page and correct 11 localization errors in a dialog box. Although translation quality was of the highest priority, the technical background of the participants – such as the ability to handle HTML correctly and the number of localization errors found – earned additional points.

“Andrey Cherkovsky, a freelance translator, was selected the winner. The second prize was awarded to Sergey Plotnikov, a chief specialist at Tomsk Regional Energy Commission, and Rostislav Romanovsky, a third-year student at the Chemical & Chemistry Engineering Department at Tomsk Polytechnic University. Neither has ever been a professional translator. Mark Lesun, a newcomer to freelance translation, ranked third. [emphasis mine]“

So, they got lucky. Don’t forget, though, that out of 70, only 20 qualified as “good,” and out of those 20, only 3 took prizes, and one of them was already a freelance translator. Can you find the 3 out of 70 that won’t embarrass you?

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.

Does your documentation contain Declarations of Conformity with European Community standards? If it does, here is some due diligence you should undertake before having the docs translated.

The EC has promulgated a long series of directives on a variety of industries ranging from aerospace to toys. Some of these directives describe industrial policy and consumer protection. If your product falls into the category of those covered by a set of directives, then 1) the product must conform to the directives; and 2) you must declare that it conforms and list the directives with which it conforms.

This second requirement leads to some of the driest text with which you’ll ever fill pages in a user guide; for instance:

Protection requirements concerning electromagnetic compatibility to Article 3(1)(b)

Harmonised standards applied:

EN 301-489-1, V1.4.1 (2002-08); Electromagnetic compatibility and Radio spectrum Matters (ERM); Electromagnetic Compatibility (EMC) Standard for Radio Equipment and Service. Part 1: Common technical requirements

ETSI EN 301 489-25 V2.2.1 (2003-05)

Fascinating reading. And, it makes for even more fascinating translation work.

If you’re localizing your U.S. product for sale in Germany, the translation of the names of these standards with which you’re declaring conformity should match the German names acknowledged by the EC. You could hand off the English text to a German translator, who could trip through several technical dictionaries creating his own translation. The numbers of the directives would be correct (because not translated), but strictly speaking, the titles would not be correct, unless your translator was extremely lucky.

Fortunately, the EC has made this easy. Depending on the industry, they offer accepted translations of the titles and text of the directives in as many as twenty languages on their Web site. With a bit of digging, your translators can find and re-use approved text. This will not only save them (and you) time, but will ensure you of a better fit for your localized documentation.

“Say, Jean, the translators found some problems with the original English documentation your team wrote. Do you want me to send you the corrections?”

“Sure, John. Do you want me to send you a nice cartridge of mustard gas?”

I never find that writers embrace the feedback from translators. It’s not that the translators go out of their way to find errors; mostly it’s that they don’t understand the term/phrase/sentence/paragraph and cannot therefore translate it. This is the fundamental test of documentation usability – are you conveying your idea to the reader? – and most writers get grumpy when they don’t pass it with flying colors.

It’s also not the case that translators get snooty about the errors they find. In fact it’s I, not the translators, who add a thin veneer of snootiness to the comments I send to the writers.

• Why are all of these Copy(1) and Copy(2) files in the RoboHelp project? Do we need them? Should we translate them?
• The FrameMaker files you gave us don’t match the PDF you gave us. Which one is correct? (To their credit, most translators won’t take for granted that the one with the later date stamp is the definitive source.)
• This training manual is for version 5.3. The last version of the software that we translated was 5.1. What has changed in the software? Do we need to translate the delta first, in order to translate the manual properly?
• We found 136 pages in the online help file with no content in them. Are they meant to be that way, or did something go wrong in the extraction process?

Writers don’t often like to hear such feedback, but, if it’s implemented, nobody can deny that it makes the books better.