Should I localize exception messages?

Question

It is probably related to "Who should read Exception.Message if at all" and similar questions asked on this site, but I don't see how it is possible to always generate a custom message while avoiding exception messages.

Also in .NET all exception messages are localized by default. Does it make sense or is it just a bad design? Moreover it is mentioned in guidelines on how to handle exceptions:

Include a localized description string in every exception. When the user sees an error message, it is derived from the description string of the exception that was thrown, rather than from the exception class.

In most cases it is pretty easy to catch and show an exception message to user instead of trying to analyze the exception type and then generating a proper user message depending on the exception details. Especially when the result turns out to be not really different from the original exception message. Also it may be a tedious work to analyze all possible cases, take a hypothetical example: you need to connect to some server over HTTP and read some XML message. There are tons of things that could go wrong, starting from port/host being unreachable, or not having access rights or malformed XML etc. Going over each case is a lot of work, while simply displaying the exception message is easy and it is very likely that it contains a user-friendly string.

So should I localize exception messages and display them to the end user as is, especially when generating a custom message may take some more unnecessary work? Or should I still do this work?

Answer 1

I believe that logs and exceptions are for developers, therefore they should be in the best language to suit the development team. This may be their native language, however it may be (and judging from the comments often is) English. This allows developers to work in a language they are familiar with and not have to translate from French, Spanish, or Chinese to work a problem.

However, your users may not all be English speakers.

To give the best user experience you may well want to localise any error messages you feel you need to display to the user.

You could do that in a number of ways:

public class LocalisedException : Exception
{
   public string LocalErrorMessage {get; protected set;}
   public LocalisedException(string localErrorMessage, string englishMessage)
     :base(englishMessage)
   {
      this.LocalErrorMessage = localErrorMessage
   }       
}

Or (and probably the way I'd do it):

try
{
  DoSomethingExceptional();
}
catch(Exception ex)
{
  _log.Error("There was an error", ex);
  this.DisplayErrorMessage(LanguageResourceFile.ThereWasAnError);
}

My suspicion is that the author of the article you linked assumes you're going to be displaying ex.ErrorMessage directly to end users. I wouldn't do this, ex.ErrorMessage often contains technical (and sometimes even sensitive) details and should therefore not be shown. It also makes you THINK about what you are presenting to the user. Catching, logging, and apologising gets you into that habit.

In summary. I'd make sure your exceptions and logs are as easy and accessible for your developers as possible. But make sure that your website (and error messages displayed) as as clear for your users as possible.

Answer 2

By my opinion the exception message should not be translated.

• if developer can reproduce the exceptional situation at their development environment, the message is not needed at all, they could just attach a debugger and set it up to break at throwing the exception. Exception messages mostly make sense for non-reproducible failures which happen only at production environment

• in most cases, showing them to end user does not make sense. They are too technical for that. They should rather be logged, and users should get application specific description of what has failed.

• for international environment, the localized messages from third party libraries are much harder to investigate. Even when I have the message text, automated translation provides only approximate information. Moreover, some people like to send a screenshot instead of text, which is close to useless for some Japanese or Arabic text.

Answer 3

No, you should localise Error Messages. Your users should never see an Exception Message. That is for your logs only.

Exceptions should never happen if you app is working. If you want to open a file for example, check that it exists and then open it. Don't try opening and throw an exception if it fails.

Of course that doesn't mean you can't tell the user the file doesn't exist! It just means they get a localised and user friendly Error Message, not an Exception Message

This way any exceptions can be treated as a crash, and a simple "Something bad happened!" message can be presented to the user, while your operations team gets the exception message with the detail on what went wrong.

*Of course if you are creating custom Exception classes in a multinational library, they will need localised messages for consumption by the developers of products that use the library.