Localization Bugs: Overlocalization, #1
"Overlocalization" happens when you translate something that should not have been translated. Overlocalization can give all kinds of interesting symptoms and often causes problems that are tricky to diagnose.
Ideally, anything I see in my databases when I localize should be localizable, and anything that should be localizable is visible to me in my databases. That's not always the case though, and that's one reason why stuff might be broken or show up in English.
One example of where I sometimes have the opportunity to overlocalize is in INFs or INIs used to install something. These are just text files, but they contain both code and localizable data. The localizable part is in a section called [Strings]. This can look something like this (I'm using Remote Desktop Web Connection as an example):
[Strings]
InstallPrompt=Do you want to install the Remote Desktop Web Connection package?
DisplayLicense=.\eula.txt
FinishMessage=was completed successfully.
TargetName=.\tswebsetup.exe
FriendlyName=Remote Desktop Web Connection Setup
AppLaunched=setup.inf
PostInstallCmd=<None>
9x_Error="This program is not intended to be used with your version of Windows."
When I localize this, I need to be careful. Four of these resources are clearly intended to be shown to the user. Two of them - TargetName and AppLaunched - I would never dream of translating. DisplayLicense is tougher though, I might be supposed to translate it since the EULA filename might be translated inside the package. If I do the wrong thing here, the EULA can probably not be displayed and that clearly won't do.
So far so good; most strings are easy to handle, and some strings stand out enough that I know to investigate. There's one left though - PostInstallCmd.
PostInstallCmd is used to set a command that should be executed at the end of the installation. If no command should be run, it's given the magic string "<None>". As a localizer, I'm probably not editing this text file in notepad. Instead, I'm working inside an actual localization tool. If so, there's a risk that I overlook the context of the string, or that I auto-translate blindly, and end up with a translated PostInstallCmd:
[Strings]
PostInstallCmd=<Inget>
What happens at runtime if I do this? Probably nothing tremendously exciting - there might be a bogus error in the setup log or a weird error message might be displayed to the user. Less than ideal, but at least nothing is horribly broken.
Lesson learned: Beware of <None>.
By the way, why wouldn't the developer just exclude PostInstallCmd if it's not needed? Beats me, but I'm sure there's a healthy reason.