Localization Project Management Log

Unfortunately, there’s been another architecture change besides the move to .NET: Engineering has split the resource DLL into two pieces.

This is not bad news in itself, but there is a tricky dimension to putting the the two DLLs together at run time, and the engineers have handled it in a way that assumes a little too much.

The main menu contains the usual entries (File, Edit, View, Tools, Windows, Help), each of which contains a submenu. The localization hiccup is that some of the submenu items live in one DLL, and the others live in the other DLL. What brings them together at run-time? The software depends on the presence of the string “&Edit” in each one. What happens when “&Edit” gets translated? “Oh, well, I guess we didn’t think of that…”

The pseudo-translated string reads “&ßéüdßéüt”. The sets of submenu items don’t find one another in the DLLs at run-time, so they simply don’t show up in the menus. Another triumph for the farsightedness of internationalization testing, and back to the drawing board for the developers.

I probably shouldn’t enjoy this stuff so much, but I’m a gearhead at heart, so I get a lot of gratification from climbing around inside resource files.

One of the unsung virtues of localization consulting is pseudo-translation and subsequent QA. The goal is to replace the source (in this case, English) strings with well thought-out gibberish, in an effort to make the software barf. This can take a number of forms, such as:

• truncated strings
• corrupted characters
• hard-coded strings
• expanses of blank space where strings should be; and
• crashes (my favorite)

I’m not really all that happy that I’ve caused the software to crash, but at least it vindicates the function of localization project management in general and pseudo-translation in particular in a way that even the most jaded developer cannot ignore.