You can choose to *not* impose a "Non-English Tax" on your feature. Or you can be a jerk. Whichever....

by Michael S. Kaplan, published on 2011/05/17 07:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2011/05/17/10164632.aspx

Because English is the language I know best, even as I try to learn other languages.

If things like proper grammar and spelling and such count against English knowledge, then some might argue I don't even know English!

But anyway, it all relates to a comment somebody had the other day in one of those perpetual threads on the topic of whether to localize exception text:

Exception text shouldn’t be localized, nor should it be user-friendly.

The text of exceptions should always be in one language (most likely English, but generally the spoken language the main development team uses). This allows developers who use your API to search the internet for that text. It doesn’t help if a French developer hits the exception and gets his own translated message.

The exception text should be descriptive enough to help developers figure out the issue, but not too descriptive to give away details of your system. Exception text should never be displayed to the user (unless you are writing an API framework and your user is the developer who uses it).

This comment highlights the two assumptions I hate most about the Redmond-based development at Microsoft, especially lately in managed code with their de facto jargon-adding exception names:

People who espouse this complete and utter crap fail to understand that these assumptions help to not only perpetuate each other (e.g. the reason they reason they most commonly search the Internet is they can't even understand the English even if they are a native speaker!), but they are just not good development practice. Just like an iPhone application that pinched people in the hand would not make it easier to use an iPhone.

Note to developers: if they are searching the Internet for your exception text, it is probably because THEY DIDN'T UNDERSTAND IT, irregardless of the language it is in.

Now the world is full of developers, and lots of them were not born speaking English. Many of them learn English (some more successfully than others, especially with the bizarre dialect of English being used here!), but the number of people who struggle to learn English so they can learn another language -- like C# -- can find their job made a lot easier with a good localization effort so the info can be in French or Japanese or whatever.

And the world of people who started in English or learned to speak it are not going to lose the ability to get information in English -- and they are not qualified to judge those who have not yet, or cannot. So they should just frigging relax and support the effort to get more people involved.

These English speaking developers who create things in English only that most people can't understand even if they are fluent English speakers should momentarily consider how bad they are at communicating to their audience - and how easy a small change in attitude would help others, while not hurting anyone else.

Speaking English is great - in some countries it is a required first step to prosperity. But the reason for that is the number of places that do the same thing these developers are doing.

In the end, there is no harm to making anything more widely available and useful to people.

But at the same time, there is no shame in allowing people who don't speak English to understand and benefit from your efforts, and frankly there is more than a mere scosh of shame in requiring it of them, you know?

So perhaps if you are a developer who uses the .Net Framework that made so many issues in computer programming easier to deal with? You just might choose to not impose an English tax on your work....

The biggest irony of ths blog is of course that this blog, and this Blog, are all in English, and thus due to my own limitations, I impose an English text on my readers. But you can do better than me!

I'm not totally with you on this one.

for one, users are sometimes on the whim of lazy developers that just throw their API exceptions on the user face.

If i'm the user and I cannot debug the problem, I'll run to the most appropriate stack overflow site and query with the exception text on hints for going over it.

as an example, a vb6 application crashed on me yesterday with a quite cryptic italian message. not knowing what was wrong and being the only having that error, I tried to search for it. no results.

so I tried to guess what its original text was, after some effort I got a hint of being a text to integer conversion that was not getting correctly handled.

long story short, forcing the number format to English fixed the exception. but having a api message throw at the user internationalized and without any hint of the process was the reason of a very bad experience.

sure, the best way is not to throw random exception at the user.

but we have to live in the real world with lazy developers and such. if the api they're using contains internationalized messages, we the user are stuck in reporting them or searching autonomously for solutions.

I tend to agree that error messages intended for __developers__ should always be in English because that really makes it easier to find help on the internet. That is the single most important reason why we choose to use the English language version of Visual Studio.

Your argument that developers search for the text because they do not understand it is not completely wrong, though; but it’s not about understanding the literal meaning of the message but finding out why the error (usually) happens, what to do about it etc. – you cannot expect to convey all this information within the error message itself.

On the other hand having a really unique identifier for the error like Raymond Chen suggested would make searching for the error message obsolete – but this is usually not the case and searching for these infamous 80000023FB numbers does not help very often either.

Shades of social.msdn.microsoft.com/.../d9aa2bc0-78c3-412a-877c-19d81ec43e8a...

The underlying assumption that developers are the primary consumers of exception messages strikes me as highly ridiculous (even if one's product is an API and/or SDK). The single most important consumer of an exception messages is probably a user (be he admin or end user) who is attempting to troubleshoot a post-deployment problem based on information shown in a log or message box. He isn't using a debugger. Even in the case of an exception raised from managed code, he probably doesn't have the exception class name because the developer logging the exception used Exception.Message instead of Exception.ToString() (either due to ignorance or a deliberate exclusion of the stack trace). Are there really folks who would argue that he doesn't need an exception message that he has some hope of understanding? If so, is their intent to attempt to drive up support revenues?

The _reason_ for wanting exception text to always be in english is so developers can parse the exception to find exact cause.

Really, the only way to find out why you got IO exception in most cases is to either do reflection on non-public members (HResult) or parse the text. This becomes vitally important when there's a specific exception you're after for handling. In my case it was file exists (so I could generate a new file name).

I have to somewhat disagree with you here - I recently shipped a beta of a product I'd been working on for awhile written in c#. And all over the place I had sanity checks that did things like catch (Exception e) { Trace.WriteLine( e.Message ); Trace.WriteLine( e.StackTrace ); } blocks, with a trace listener that logged traces to a file. And of course there were a few issues that cropped up, this being a beta. But the user base was international, covered a dozen different countries and at least half a dozen languages, so when I'd get these logs emailed to me, the exception message text would be localized, so I'd have to go track down first what the exceptions were.

Arrgh, trying again to post after the engine discarded my comment without a word.

I can't agree with you here. I google error messages not to understand them, but to find out what to do about them. It wouldn't be reasonable to expect an error message to contain a recipe for fixing the problem as well.

But I share your disdain for the notion that error messages should be obscure to protect proprietary software. It's true that the operating system Multics (the conceptual ancestor of Unix) had one Latin error message, but it was for a "can't happen" situation eventually triggered by a hardware failure. When a disk controller only half-wrote a block, the B-tree representing virtual memory was trashed and seemed to have more than one root. So the recovery routine printed "HODIE NATUS EST RADICI FRATER" ("Today is born unto the root a brother", a parody of a Latin Christmas hymn) and crashed.

It is *not* true, as an urban legend once had it, that *all* Multics error messages were in Latin so that customers could not diagnose their own problems and would have to call in Honeywell at a high, high price.

I think enough people struggle to properly handle i18n for their users to have them worry about i18n for developers as well. This only really affects library developers, who (IMHO) shouldn't be doing any i18n (unless that's the purpose of the library).

Besides, what language do you use for a "resource not found" exception message?

> Note to developers: if they are searching the Internet for your exception text, it is probably because THEY DIDN'T UNDERSTAND IT, irregardless of the language it is in.

In my experience, the Chinese interpretation of error message containing words that I don't know can be found by including parts of error message in Enblish plus one of two related words in Chinese. It works most of time because lots of the forums (even forums orients towards Chinese users) almost always includes the whole error message in English.

On the other hand, search for Chinese based .NET error message usually returns <10 result (except those really common ones).

So yes, I'd agree keep developer oriented error message in English makes sense, while I'd also agree error messages be shown to customer should be localized.

@John Cowan: Same here, the blogs keep disposing my comments these day so I think it could be serverwide issue.

I have to fire up fiddler, reload the page with posting action, capture the response to extract the comments, then try posting again.

I totally disagree.

Localization of exception messages is a complete waste of developer time - heck, it's a waste of time of the users, since usually technical messages are much more understandable in english than in a badly translated italian.

In every company I worked, development was done using an english version of Visual Studio or other IDEs, and there were mandatory rules to have comments and symbol names in english.

So, I really think localizing API messages and even developer tools is a waste of time. As you can guess, I'm italian.