We all [heart] PDFs!

Any good localization manager (vendor- or client-side) knows that there's very little you can do with a PDF as a source file. Yet time and again, we confront the best intentions of our customers and co-workers who say, "It's not a very large file, so it shouldn't cost much to translate. I'll send it to you." They send us a PDF.

This has happened to me with two new clients this week. We'd all like more translation business, and it's convenient that it exists as a lingua-franca format for us, but PDF is something of a double-edged sword.

PDFs contain everything we need to view a file, but not everything we need to extract the text, formatting, callouts, frames, tags, etc. from it. Creating a localization estimate on a PDF is asking for trouble, because it smooths over a multitude of different issues that we'll encounter once we have the source files, most of which concern text that we know requires translation, but which is not "live" in the PDF and may not be live in the source file from which the PDF came. It's the equivalent of hard-coded strings in software, or localizing a binary without the .properties or resource files.

There are, of course, utilities for converting PDF to RTF to capture the live text and formatting, and that's better than nothing, but it's probably still a far cry from the Quark or InDesign or even MS Word file from which you started. I've sent one of my new clients back to the drawing board several times this week already:

1. He gave me a PDF and I asked for the source file.
2. He found the source file (Quark) and I asked for the Photoshop files from which the text-bearing graphics had originated.
3. There were tables in the Quark file that were Illustrator objects, because these looked much better than Quark's native tables.
4. Another PDF of a Word document contains eight graphs created by engineers all over the building. He said he'd try to obtain the original artwork (probably PowerPoint, every engineer's favorite Etch-a-Sketch), but I'll be surprised if he can find it.

So, folks, we love to localize your pieces, but try to keep tabs on all the bits that you drop into them. We can do things so much better-cheaper-faster when you do.

User Interface and localization

"We are Marketing. We own the user interface."

An engineer with one of my clients told me, with some bitterness, that a previous regime had summarized its hegemony over the company's software product with those two sentences. I'll grant you that it sometimes help in a company to know which lines are not to be stepped over, but I'll also grant you that you catch more flies with honey than with vinegar.

Most of us don't mind if Marketing dictates the user interface, unless people with our global perspective tell them that something in the UI won't work well when the product is localized and they refuse to accept it.

In this case, the fuss is over an HTML-based UI and help system that lives in firmware in a networking device. The old Marketing guard wanted a tabbed look with labels on the tabs (Connections, Security, Setup, Help, etc.), and the tabs had to be graphics. The graphics are .gifs, nobody knows where the source files are, and we're trying to find an expeditious way to localize the product, including the text on those tabs. (If you're in localization and haven't already faced this situation, I can assure you that you don't have long to wait.)

I've floated some ideas by them that might result in a more flexible approach for future versions of the product. The current Marketing team is not so doctrinaire as their predecessors, but they're not very engaged in this process, either. I offered Ockham's razor: Let's remove the tabs and replace them with hyperlinked text near the top of the page, and the problem will go away. They have yet to reply to that.

I'll give them another week, then make my own arrangements. After all, "We are Localization. We own the rest of the world."

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.