Posts Tagged ‘language

I’m now convinced that .NET’s support for localization is very poorly designed indeed. While on the surface, the concept of localization (also referred to as internationalization) is a noble effort to enhance or make possible the use of computers by speakers of foreign languages, if it gets in the way of development it can be a very disruptive and problematic tool.

Take the following error an early beta tester of OrangeNote supplied me with:

System.Windows.Markup.XamlParseException: Verdien System.Windows.Data.BindingExpression kan ikke tilordnes egenskapen Opacity for objektet System.Windows.Controls.Border. Invalid real literal ‘1.0’  Feil på objektet System.Windows.Data.Binding i kodefilen OrangeNote;component/viewers/debugterminal.xaml, linje 122, posisjon 5.

Now the first and most obvious problem is that the error is not in English! While it’s true that error messages presented to the user should most certainly be translated to their native language whenever possible, exception messages are not oriented towards end users. The purpose of an exception is to convey information back to the programmer that a particular problem has arisen in the code of a program, with the intention of providing useful information to addressing and correcting the problem.

For example, when translated, the above reads roughly like this:

System.Windows.Markup.XamlParseException: Value of System.Windows.Data.BindingExpression can not be assigned to attribute Opacity for object System.Windows.Controls.Border. Invalid real literal ‘1.0’ Error in object System.Windows.Data.Binding in file OrangeNote;component/viewers/debugterminal.xaml, line 122, position 5.

Is this really something the end user needs to know? If not, why go through the trouble of translating it in the first place? Perhaps Microsoft expects my users to fix my bugs for me. Furthermore, the platform doesn’t even appear to provide any way to explicitly obtain an English version of an exception, further increasing the absurdity of the matter.

But this is only the beginning.

If you take a closer look at the problem the exception is describing you might notice something strange: .NET is complaining that “1.0” is not a valid value for the Opacity property of a System.Windows.Controls.Border (which is a Double). Come again? 1.0 is a perfectly valid value for Opacity, unless you’re running your program on a locale that represents decimal values differently. That’s right, we can’t even program our app in English anymore! When simply changing the locale of your system affects what applications you can run on it, this is a clear indicator of a serious design problem.

Granted, this issue arises in some atypical scenarios involving dynamic parsing of lambda expressions, but the fact that it arises at all is the problem. What started out as a means to make applications more user friendly to foreign language speakers turned into a roadblock that can actually interfere with applications running at all.

In closing, my recommendations to Microsoft are as follows: First and foremost, eliminate the ridiculous and useless translating of exceptions into local dialects, and second, provide a more intuitive programming environment that takes into account programmer locale when running an application, not just user locale. These two things combined will make for a much more pleasant experience both for programmers and end users in multilingual scenarios.

See you next time.


Adventures in theoretical computer science, with your host, chaiguy1337

What I’m Running

Software tracking

OrangeNote™ Users

Top Clicks

  • None

RSS DotNetKicks

  • An error has occurred; the feed is probably down. Try again later.

RSS The Code Project

  • An error has occurred; the feed is probably down. Try again later.

Blog Stats

  • 25,736 hits