Yesterday I showed how things that change in runtime can cause bugs. The wizard example isn’t that challenging, since it can be predicted fairly easily. Today, I’ll show something that’s just a little bit trickier.
Here’s a dialog in the Accessibility wizard as seen in my localization tool:
Here’s the same at runtime:
Quite the difference. Unlike the Welcome and Finish pages in wizards, this is a once-off thing – there’s no other place in Windows that works exactly like this one, so when the dialog was first introduced a good few languages saw truncations here. There are however some similarities with the Welcome and Finish pages: there are strings in the string table that affect the sizes used. Only there’s no clear mapping between those strings and the controls they’re used for. This is something we had to find out for ourselves.
Here’s another example, something we struggled with in SP2. A dialog looks like this in my localization tool:
But sometimes it looks like this in runtime:
Never mind that a couple of controls are overlapping right now – that’s a separate problem. What tripped me up here is simply that the text is made bold at runtime. This is something I had no way of predicting.
These two bugs are similar in that you can not prevent them until you have some knowledge you can only gather at runtime (unless the developer is kind enough to offer it beforehand). But once you know what will happen to which control, you can detect a problem just by looking at the localized resources. Which is why it makes sense to start localizing or testing a few languages early.
Next time – more dynamic fun.
This posting is provided “AS IS” with no warranties, and confers no rights.