I don’t know about you, but I stopped believing them a long time ago.

Pseudo-translating the code is the definitive way of showing them the strings they’ve missed. It requires a bit of time and, frankly, some cooperation from the very engineers you’re about to embarrass, but it’s the sure way to find strings still embedded in code.

Many engineers overlook the installer, also. There is usually a script or value-pair file with custom strings, and it’s easy to forget to externalize strings to the file. It’s also easy to specify the wrong encoding for the file, such that all of the custom strings show up corrupted in the installer. We see that a lot with InstallShield projects.

Mind you, I’m never out to get the engineers – I need them too dearly – but they sometimes get to believing their own stuff and thinking that internationalization (I18n) is kaltes Kaffee, or yesterday’s news. It is yesterday’s news, but that doesn’t mean it’s unimportant.

Where do you find strings that engineers overlook?

Note: I’ve posted less frequently of late because I’m between projects (and setting up another blog). Once L1on activity resumes with a couple of clients, I’ll have more war stories again.

It took me several iterations, but I’ve successfully navigated the areas in the InstallShield UI that do and do not support wide characters. (I thought there was a time when I could put anything anywhere and have it display properly, but suddenly I was getting corrupted characters in some screens in Asian installers. So much for the ailing memory of the noble localization project manager…)

Your mileage may certainly vary, but I found that, anytime we used double-byte characters in the strings labeled “(ASCII only)”, they became corrupted. My hunch is that there’s some other variable or setting required to support such characters in those places, but I figured I could give the release engineers only so much grief before I suffered backlash.

If you’re a double-byte InstallShield expert, by all means reply with the better localization way.

• InstallShield does most of the hard work. Most of the strings are already translated into more languages than most companies know what to do with.
• Customized strings live in a single, text-based value.shl file, which the release engineers peel off and hand me for translation.
• By default it creates language-specific branches in source control, which prevents, say, your Russian release from getting pasted in as a mere revision to your original English release.

The value.shl file is very simple, and ours changes so infrequently that it’s easiest for me to update it myself (version numbers, copyright dates, URLs), without need to hand it off for translation.

Of course, it did drive the release engineers batty in the early days, especially when I wandered in asking for 3 Asian and 2 Western installers every few months. The hard part for them is seeing far enough down the road to build a maintainable structure in source control. It never occurred to them to start out with branches labeled /en/ or /0009-English/ because they never foresaw the need for other languages, so they painted themselves into corners but didn’t realize it until Chinese came along one day.

People in this industry write about introducing worldwide consciousness to the overall mindset of the organization, and evangelizing the gospel of localization; that’s the 50,000 foot-/16,129 meter-level. Must be nice. I spend most of my time crawling in a trench in source control somewhere, trying to soften periods into decimal separators without getting flamed.