If the application is internationalized and localized in many languages, then using the same exception to log and show on the UI will not be that easy. Getting the locale, that the message needs to be localized in, to the business layer would also be cumbersome. It can be done however using Filters and ThreadLocals. A filter can pull up the locale from the user profile or the request headers and insert that Locale in to a ThreadLocal for later the business layer can use it, but for reasons others already mentioned, I think it will be better to just use English text in exceptions and log them and have some exception mapping facility, typically available in the MVCs now-a-days, to show the localized message in the UI.

Struts, and I think I have seen some other Apache projects, uses LocalStrings.properties and localizes messages based on the System default locale.

@Hamlet: This implies that I can localize in the appender somehow. If I’m using log4j for example, I would need to actually log a localization key, then have appenders that would know how to look up a localized message to go to one log and a hard-coded message to go to another. I don’t think such a thing exists, although it wouldn’t be too hard to write one. I actually went down a path similar to this years ago and found it to be a big mistake. It made logging and exception handling way more complicated.

@Stefan: I think I’ve generally come to the same conclusion that localizing log messages is not worth the effort. I can envision a system where some specialized kinds of logs (audit logs) may be useful to localize but in general it seems like more trouble than its worth.

@Laurie: Good points. I think I’d be willing to say at this point that the log’s value is only for support and thus should not be localized. I think it’s also worth noting on your l10n/i18n comment that even localizing code has a big impact on your code base. Localizing makes code harder to read (as you have message keys, not messages in it), harder to maintain (refactoring often requires being sensitive to the location of messages in various bundles), and localizing when you don’t need to can make the process of i18n much more complicated for your translators as they need to know what messages do and do not need to be i18n’ed. So, there is much value in NOT localizing stuff that doesn’t need to be.

@Devil’sAdvocate: Good points all. I’d say that even though your point about message content is generally true, it would still be a lot more difficult to understand what’s happening in a log written in a different language, particularly if the variables being filled in are also in the other language.

@Per: On the last point, there is a certain class of exception whose purpose is to notify the user of a problem in user input and in that case, the exception message should be created for the purpose of display to a user. But I agree that that is hopefully a small subset of the total number of exception messages in a product. The rest are probably “unexpected” error conditions. However, all exception messages have a way of “bubbling up” to the top of the app and getting seen by a user. My general experience has been that the state of the practice in this area is far from the ideal, for the underestandable reason that it’s a lot harder to manage than any sane person would expect.

Another thing: It makes it harder to write tools that searches logs for stuff, when the messages are (can be) localized in different installations.

About exception messages being presented to the user: Isn’t that a bad idea? I believe in catching exception in code and then — if the user is to be notified — showing a translated/localized message from some resource bundle.