Localization Bugs: Hotkeys, #2

  • Article

The other day I showed a very simple bug. So simple, it simply shouldn't happen. If I ever check in files with that kind of bug, I don't have any defense. Today, I'll show you another bug that's slightly more interesting.

What made the last bug simple was that the entire dialog was self-contained. Everything I needed to know about it, I could see in my localization tool. Turns out, it's pretty common that this is not the case.

Look at these two dialog boxes, as shown in my localization tool:

and

These look good, hotkey-wise. However, if I'd hand off these files, you can bet that a tester would come back with these bugs:

and

Ok, that's not good. What happened here is that the dialog I saw in my localization tool was combined with some other gunk at runtime. In this particular case, the gunk comes from comctl32.dll - the file used for almost all properties dialog boxes and wizards in Windows.

Everything looked pretty in my localization tool and that static hotkey check, the one I mentioned yesterday, didn't report any problems. Still, I should have known that this would happen. All the information I needed was there:

  • Neither dialog has any button to "Close", "OK", "Cancel" -- if these dialogs were displayed by themselves, there wouldn't be any obvious way to get rid of them. Therefore, they must be part of something bigger.
  • The shape and size of the first dialog looks suspiciously like a properties dialog, and the shape and size of the second seriously resembles a Wizard. That's a good hint.
  • The title of the first dialog is "General". The dialog has controls that give me information about and lets me change properties of a certain object. Those are good indicators.
  • The title of the second dialog is "Accessibility Wizard". It lives in the file "accwiz.exe". The clue is in the name, as they say.
  • The dialogs don't live by themselves; in the first binary, I can find several other dialogs with the same shape and same type of controls. In the second binary, I can even find the dialogs "Welcome to the Accessibility Wizard"...

There are more hints, but this should really be enough. When I localize, I should be able to figure out how these dialogs are used. But -- if I'm still not careful, how can I detect duplicate hotkeys before runtime?

See, that's trickier. My localization tool can not know how these dialogs are used. Therefore, it can't figure out that #1 above is a property page, therefore it'll be merged with some other dialog in some other DLL (one that's not part of the localization project), and therefore it needs to check all hotkeys here with some hotkey somewhere else.

You could however build some check with logics that iterates through a project and makes a guess based on the hints I describe above. Or you could build and maintain a table of all dialogs in all files that are wizards or properties pages. Since the hotkeys for Apply, Back and Next are known and won't change, the check could fairly accurately find these duplicate hotkeys. It could be done.

But I haven't bothered.

Instead, I use a more... pragmatic approach. I simply never use the hotkeys for Apply, Back or Next anywhere but on those very buttons. This way, I'm sure never to introduce this type of hotkey bug. It might sound heavy handed, since there are plenty of dialog boxes where you could use those hotkeys without trouble. But from what I've seen, if you do that, next time you auto-translate that string with a hotkey on "&n" will spread to a wizard dialog, and you will have an unnecessary bug.

During Server 2003, I changed almost all strings that has the same hotkey as Apply, Back and Next, and I don't use those any more. Since then, I've only had a handful of these bugs.

This posting is provided "AS IS" with no warranties, and confers no rights.