Pulling the rug out from under the Localization Manager

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.

If you meet the Localization Manager on the road, kill him!

[With apologies to the sage who said, "If you meet the Buddha on the road, kill him!"]

Hope I didn't startle you with that title, but it came to me as I asked myself how my clients would deliver localized products if I were hit by a bus, or if someone met me on the road and killed me.

The cemeteries are, as deGaulle mentioned, filled with indispensable people, which means that in time my clients would appoint somebody to pick up in the middle and finish the project. That applies to every one of the employees in every one of my clients' companies. My replacement might even do a better job than I did, such that outside of the improvement (and the sudden drop in total irony in the building), nobody would notice the difference.

I suppose it's a backhanded way of telling myself I do a comprehensive, one-stop-shopping job of localization project management: "Really, now: If I shuffled off the mortal coil, how would you guys get this work done?" The people who create the domestic product are accustomed to leaving all of the thought and toil to me, and they're in a variety of departments, focused squarely on anything but the localization process. Absent the localization manager (who, in this case, has no staff), the process would probably devolve back to those individual departments. Within no time, they would have had enough and begin to clamor for a replacement.

It's not so important to be indispensable as it is to fill in the dozens of unanticipated cracks in the process of turning domestic products into localized ones.

It's also a good idea to keep a wary eye on people you meet on the road.