Localization Project Management Log

It’s a thrill for the gearhead in me to build my own localized binaries.

Most projects in the wide world don’t require this of the localization manager, of course. A staff engineer, or at least a release engineer, is usually tasked with building the binaries that house the localized software resources. There’s some delay involved in that, though, since the engineers don’t often place very high priority on building these infernal things, let alone building them as often as the localization QA cycles require.

The localizers are able to preview the localized resources in their localization environment (Alchemy, Visual Studio, etc.), but our engineers have an arcane build environment and procedure that I don’t care to impose on even my least liked localization vendor, simply because it’s an open invitation to failure. Instead, I persuaded the engineer who created the entire scheme to spend three hours duplicating the environment with me so that I could document it and reproduce it on a quick turnaround.

“Why are you going to all this trouble?” the engineer asked me.

“I’m trying to drive you crazy this one time so that I don’t drive you crazy eight or nine times over the next few weeks. The translators will find new things to change as they continue localizing the rest of the product, and they’ll change the resource files. If I have to bug you with each one of these changes, you may come to view localization as something, well, inconvenient.”

“Good. Thanks for sparing me that.”

That was for version 2.0.0 of this software. I was able to save precious days by doing my own builds and turning the binaries around to the localizers promptly. I also saved myself all of the credibility and Brownie points I’d have had to mortgage by running to the engineers all the time.

Now that we’re localizing version 2.0.1, however, the procedure is changed. The engineers have pulled the rug out from under me, and nothing that used to work, works. Time to bug the engineer again and get the updated Rosetta Stone so that I can build these things.

After a few hours hunched over Beyond Compare, I’ve sorted the deltas between version 3.9 and version 4 into several buckets:

1. New Content, based on filenames appearing for the first time in this version – 718 files
2. Content Unchanged, except for the datestamp at the bottom of the page – 727 files
3. Content Changed, but with changes that do not require translation (HTML tags, formatting) – 1517 files
4. Other, including content with translatable changes and anything else – 319 files

My hope is that the vendor can hand off to the Japanese translators only those pages in which there is real translation work, then internally take care of #2 and #3 with search-and-replace and other engineering techniques to bring the 3.9 pages into parity with the 4.0 pages. For that matter, I could probably do the engineering myself, except that: 1) it’s boring work; and 2) the vendor needs to update translation memory with the results.

We’ll see how this goes. It doesn’t help that the original English files have a lot of formatting errors in them, and that errors in the Perl scripts wipe out the content on several dozen pages and toss them into the CHM blank.

Sometimes I know too much about this process.

Or, maybe I’m just too nice a guy.

To make things easier for the vendor (and cheaper for me) I’ve resolved to carve the 3200 HTML files in the API Reference CHM into different buckets, depending on whether and how much they require translation vs. engineering. Naturally, the ultimate arbiter is the Trados or SDLX analysis that the vendor will perform, but I’ve already mentioned my concern about false positives and need write no more on the topic here.

My tool of choice is the extremely capable Beyond Compare which, at US$30, is worth it just to see how well thought-out a software package it is. I compare version 3.9 files against version 4 files, tuning the comparison rules to groom the file buckets as accurately as possible.

The distribution is not perfect, if for no other reason than because its first level of triage is the filename and not the file contents, but it’s better than guessing, and it’s much better than thousands of false positives.

Once I’ve gone through the files, I’ll have a better idea of how to label the buckets in a way that meets both my needs and those of the vendor.

At least, I think I’m being too nice a guy. Maybe this is just a big pain for the vendor, and they’re too polite to inform me of that.