The Localization Manager's Team - If You're Lucky

How many of you out there in L10n-Blog land get support from other internal groups?

A long time ago my boss told me why it's important to be a complete zealot about localization, especially in an organization that is new to the process.

"For people in general and engineers in particular," he observed, "localization is interesting only once: The first time. After that, they're just humoring you."

I've kept that in mind as I take off like a street fighter with most clients, eager to ride the wave of novelty that accompanies the prospect of going global. Product managers brief me up one side and down the other, in-country partners promise to devote legions of in-house staff to testing the product the minute it's ready, and QA resources jump at the chance to configure localized test benches.

At the water-cooler level, employees want to connect me with their cousins who are studying French and would love to proofread the manuals, or with their former co-workers in Japan who would make excellent beta testers. Naturally, I diplomatically avoid these golden opportunities, but I appreciate how high spirits can run at the outset.

In time, though, product managers stop returning phone calls, in-country partners run out of time, and QA leads are unexpectedly besieged by other priorities. (In one memorable instance, after I had explained to the QA manager the relatively paltry need for a few machines and 10 person-hours of testing per week for 4 weeks, she replied, "Oh, we'll have no part of that," and walked away.)

It's not so tiresome when my task is simply to get a localized product out the door; in that case, I work things out on my own to achieve that goal, since I know the process from end to end. But if clients hire me to build teams and to put procedures in place for localization, the expectation is different, and people know it's an edict from above. I need stick and carrot for engagements like that. That's more like a, well, a job.

Localizing Graphics - The Last Thing Anybody Thinks About

Now, then. A word or two about localization and graphics. If localization is the last thing anybody in an organization thinks about, where does that leave localized graphics? The last thing after the last thing.

Screenshots are taken for granted. If you're localizing from English into Russian, and the documentation contains 50 screenshots, you naturally steamroll right over the English ones by running the Russian version of the software, taking the same screenshots as in the English doc and replacing them (same size, same bit depth, same filename, etc.). The original En screenshots may even be in the doc project, but you know you're not going to use them, so you don't give them much thought.

But good writing usually requires good graphics, and writers funnel graphics from sources all over the building into their books. Engineers convince the writers to include flowcharts, Visio diagrams, spreadsheet charts, schedules, timelines, Gantt charts and other pictures in the docs, and they often include translatable text. NOBODY ever knows where the source file is.

"We need to translate labels in the flowchart on page 73. Where did it come from?"

"Bill in Engineering gave it to me, but he's left the company."

"Do you have the source file?"

"Oh, sure. Bill sent it to me in this PowerPoint presentation."

Well, yes, it's in there, but it's just a .jpg file pasted in from someplace else. I get engineers crawling through source code and around long abandoned hard drives on a quest for the source files, to find out that somebody cobbled it together using Microsoft Word Art in a .doc file. That's if I'm lucky.

Most of the time it's a .gif or .jpg that came from Marketing, or from some designer who did it in Adobe Illustrator or Photoshop. "Can you get me the .psd for this?" "No. Work with what you have."

So we do. It's not impossible to hack an existing graphic file, but it's not a very clean process, and if it's of any size, the mismatched text will be pretty obvious.

Localization and the Perl Script

After some cajoling, I've prevailed on our tech-writer-who-doesn't-do-any-writing to modify his Perl scripts. The changes will remove the thousands of CRLF (hard returns) in the 3700 extracted HTML files, and result in better Trados matching between the new files and translation memory.

Then, of course, it will take a few hours' perusal to see what breaks as a result of that fix.

It seems to be an unsung inconvenience of localization that
a
sentence
put
together
with
these
words
and
looking
like
this

separated by hard returns in the raw HTML file (which you can see by viewing source in a browser) becomes

a sentence put together with these words and looking like this

when viewed in a browser. The translation memory tools, of course, see the hard returns and try in vain to match accordingly, but they can result in a fair bit of head-scratching to those viewing the files only through a browser.

Translators - The Tech Writer's Best Friend/Worst Enemy

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