views:

371

answers:

5

I'm working on a project and I'm just starting to do all the work necessary to globalize the application. One thing that comes up quite often is whether to globalize the exception messages, but ensuring that string.Format uses CultureInfo.CurrentCulture instead of CultureInfo.InvariantCulture. Additionally this would mean that exception messages would be stored in resource files that can be marked as culture-specific.

So the question is, should exception messages be globalized or should be be left in either the InvariantCulture or the author's country; in my case en-US.

A: 

If you are going to be the one to deal with the exceptions, then either leave them in a language you can understand, or give them codes so you can look them up in your native language.

StingyJack
A: 

IDEs should be able to help you externalize those strings.

I'm a Java programmer, so I'm used to IntelliJ helping me create resource bundles for I18N of messages, labels, etc. Is there something analogous in .NET?

duffymo
+7  A: 

typically, I don't.

Globalize strings that may be seen by a user, and you don't let your exception messages percolate up to the UI, right?

Right? :)

Greg D
Yes Elliot (http://riiight.net/)
StingyJack
+1 for having to go up against Jon :)
Harry Steinhilber
+1 for saying the same as Jon S, but briefly
MarkJ
+15  A: 

Exception messages should rarely be displayed directly to the user. You need to think of the consumer for each string. Obviously pieces of text in the user interface need internationalizing, but if an exception message is only going to be seen by support (or is going to be visible to the user and then emailed to support when they click a button) then where's the benefit of translating it?

If you go too far, you could not only waste time and effort (and i18n can take a lot of effort) but you'll also make your support life harder as well. You really don't want to have to read log files written in a foreign language and translate them back to your native tongue.

It makes sense for Microsoft to internationalize their exception messages, because they will be read by developers from all over the world - but unless you're multinational with developers in multiple countries who don't share a common language, I wouldn't translate message which are really meant for dev/support.

Jon Skeet
+1 Much more practical approach I think.
Andrew Hare
+1 but one 'reason' I've heard from a former employer is that a similar exception can be thrown by multiple methods. If they ever wanted to change the wording of an exception, they just need to edit the resource bundle in one spot. I thought it was stupid...
Outlaw Programmer
@Outlaw: Yup, that's stupid - because it means if you need to change the wording for one site but not the other (which seems pretty likely to me) you've got much more work to do.
Jon Skeet
A: 

I assume by globalize, you mean i18n compliant which is usually called internationalize. Yes, internationalize all visible parts of the GUI, including diagnostic messages. The log file, which is where developers should go to get the real information such as the stack trace, should not be internationalized.

Glenn
In .Net, the namespaces are called "Globalization". We are stuck with whatever jargon MS imposes. =/
StingyJack