Localizability: Unnecessary dynamic behaviour

The evidence is overwhelming: if your localizers do not have enough context when they localize, odds are that they will not get it right. Lack of context leads to unnecessary bugs and lower quality overall, both of which can be very costly.

One way for developers to help localization is to avoid UI changes at runtime whenever possible. That is, don't use the same dialog for more than one purpose, don't swap text in and out if you can avoid it, and make sure to keep controls static if there's no need for dynamic behaviour.

Here's an example of what not to do. I have a dialog in Vista that in my favourite localiztion tool looks like this:

I can guess that all text will be taken from the string table at runtime, but I have no way of knowing what piece of text will go in which controls, which means that I don't know what it will look like at runtime and our checks will not be able to find duplicate hotkeys, clippings etc.

Today, I received a bug with this screen shot:

Great, finally I know what it may actually look like at runtime, so I can size the dialog correctly. Only, I still don't know for sure that this is the only possible state of this dialog box so I can't be ceratin if I fix it right, I still can't use our checks to detect clippings or hotkeys, and if the developer ever changes the dialog, it's more than likely that I re-introduce the same or similar problems again. How many man hours did this cost? Any for how many languages does this need to be tested, fixed and regressed?

Comments

• Anonymous
  July 31, 2006
  The comment has been removed
• Anonymous
  March 16, 2009
  Localization bugs are often classified into these symptom buckets: Build/BVT (1) breaks This kind of