11

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.

Orion Adrian
  • 19,053
  • 13
  • 51
  • 67

4 Answers4

36

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.

strager
  • 88,763
  • 26
  • 134
  • 176
Jon Skeet
  • 1,421,763
  • 867
  • 9,128
  • 9,194
  • +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... – Tim Frey Jan 23 '09 at 21:07
  • @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 Jan 23 '09 at 21:18
  • @Jon Skeet Ok, now what if I am developing an free library that may be used by various developers from different countries and has no UI parts? Is it worth to globalize the exception messages? Is it worth to ask this a separate question even if people will say it is duplicate? Ah... too much Philosophy. – Theraot Oct 20 '11 at 20:11
  • @Theraot: It's your choice - personally I'm not doing so for Noda Time, but it's up to you really. – Jon Skeet Oct 20 '11 at 20:18
  • @JonSkeet Globalization of exception messages seems to cause trouble: http://stackoverflow.com/questions/209133/c-sharp-exception-messages-in-english so I'll use english, and concatenation (to avoid CA1305, I prefer to avoid suppressions when I can). Also +1 – Theraot Oct 20 '11 at 20:39
  • @JonSkeet then how would you set exceptions to be logged to just one language? If you get something unexpected from the framework it is localized. Unexpected things should go to a log, so somebody can see what happened. Getting russian or chinese things in a log because .net uses the CultureInfo (or something internal? even if setteing CultureInfo and UIInfo some messages seem to get in system language). So how would you make life easier for support? – Offler Apr 10 '13 at 07:32
  • @Offler: That's definitely tricky. I imagine the exceptions are localized at the point when they're thrown rather than when they're logged, which is annoying. I guess one approach is to set the thread's current culture to "whatever culture you're happy to read logs in" and make sure that you explicitly specify a culture anywhere you want it to be in the *user's* culture. That could cause other problems though, depending on the type of app you're writing. It's all a mess, to be honest. It should be designed to store a message ID and parameters, so the exception can be rendered in any culture. – Jon Skeet Apr 10 '13 at 08:16
  • @Jonskeet " I guess one approach is to set the thread's current culture to "whatever culture you're happy to read logs in"" - nope, does not work for all exceptions. I tried it and get a mix of 2 different languages (seems to depend on exception type). For example: I get FileException in english, SocketExceptions in German – Offler Apr 10 '13 at 14:05
10

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
  • 43,259
  • 14
  • 84
  • 117
0

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
  • 19,041
  • 10
  • 63
  • 122
0

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
  • 7,874
  • 3
  • 29
  • 38