The Downside of Localization

The Xerces XML parser recently localized its error messages, which seems like a nice thing to do. However sometimes good actions have unintended consequences. It turns out the localized error messages are a lot harder to find with Google than the English ones. Paste an English exception message into Google, and you’ll probably find 10 people who have already had and solved your problem. But the same message in Greek or Croatian? Maybe not.

I suspect that error messages intended for programmers (as opposed to end users) should probably stick with English, though that’s only a feeling. It may well depend on the non-English native language of the programmers in question. For instance, I’ve noticed that Dutch programmers are somewhat more likely to prefer working in English than French programmers, who are themselves more likely to prefer English than Japanese programmers.

This is all just for programmers though. End-user-visible strings should always be localized. If you’re showing exception messages to end users without sanitizing them first, well, you’ve got bigger problems to deal with than localization.

6 Responses to “The Downside of Localization”

  1. sp Says:

    I’ve come across exactly that problem before. My native language is not English and consequently most of my software is not English. It’s always a nice exercise to try to guess the original English error message from the localized error message.

    Nevertheless the problem can easily be solved. Add a unique error code to your error messages. Visual Studio – for example – does that and I can just google for “c++ E5483” or whatever the error code of the error is.

    I think this is one of those issues that people working only with English software just don’t think about.

  2. roberthahn Says:

    sp says: “I think this is one of those issues that people working only with English software just don’t think about.”

    It would be a big help if non-English speakers could step up and help us out there, and frankly I haven’t seen that many good ideas like yours published and talked about.

  3. Brian Says:

    “It would be a big help if non-English speakers could step up and help us out there…”

    They probably are, but not in English.

  4. Eirik Says:

    As some large companies, like Oracle, have found out: Errors should have an universal error code (like ORA-04029) that is included at the start of the error message. If you paste that into Google you will get answers in both Japanese and Russian…

  5. Nicholas Sushkin Says:

    Java now has an Exception.getLocalizedMessage() method in addition to the usual Exception.getMessage(). Perhaps application reporting the exception can be configurable to use either or both localized and unlocalized message.

  6. Alexandre Rafalovitch Says:

    Message catalog with visible message IDs is the answer to many questions. I worked for BEA support and Weblogic had the IDs in most of the messages. Users liked it.

    It made my job easier as well, since I could easily grep for the error codes and not have to figure out the regular expression that ignored the variable part. That includes sometimes having to deal with log messages that were localised (s/z-pun intended).