.NET 2.0 Features Ease Internationalization

For most devs, software internationalization is an afterthought. .NET specialist Bill Hall says waiting has drawbacks. Hall lets IDN eavesdrop on one of his client consultations, where he outlines how the latest Microsoft .NET features let devs conduct internationalization right from the start. .NET System.Globalization features are highlighted.

Tags: Features, Internationalization, Strings, Developers, Hall, DateTimeFormatInfo, Austria,

For the vast majority of software projects internationalization is an afterthought, if it comes up at all. While that approach sounds logical, especially when 80%+ of users are in the U.S., internationalization specialist Bill Hall says waiting has drawbacks.

ESB-CON III -- Enabling Business Critical Integration and SOA -- March 1, 2007

Experts from ESB leaders BEA Systems, IBM, Progress Software and Oracle Corp. share their latest insights and news on tools, trends and F1000 Use Cases for deploying ESBs and SOA. This fast-paced event covers Feature Upgrades, Best Practices and Blueprints for using ESBs to deliver cost-efficient business-critical integration for your current assets, and for preparing for SOA. Click here for your complimentary ESB-CON III registration.

In a unique customer-centered view of the problem, Hall lets IDN eavesdrop on one of his client consultations, where he outlined how the latest Microsoft .NET features let devs support internationalization right from the start. Hall's conversation highlights .NET System.Globalization features including its support for Unicode.

Hall So how goes your new accounting package? You released it recently, didn't you?
Client:For this kind of software it is doing pretty well. It is fairly specialized so it does not always have a wide audience.

Hall Your previous versions were developed in Windows, but this time you decided to move to Microsoft .NET. The program models are rather different.
Client: Yes, but it was worth the effort. Once you catch on to the way .NET works, the programming is much more intuitive and the backend is easier to work with. The database stuff is especially good.

Hall I suppose you happily ignored my suggestion once again to add some internationalization and localization features this time.
Client: Well, our market is mainly in the U. S., and besides, we really don't have anyone on staff that can do this work.

Hall Teach your developers to do it. After all, they are the ones that can do this best as they are closest to the code. The concepts are not really all that hard to learn. If you bring in outsiders to 'fix up' the code, then they are the ones that learn, not your team, and you have to pay them over and over as your program evolves. Same thing applies to isolating the user strings. .NET resources are quite easy to handle now, especially in .NET 2.0 where a lot of work gets done for you.
Client: Yeah, I suppose so. I was pretty sure you were going to beat on me about finally getting world ready. But, coincidently, we recently received some queries from French speaking Canada if we could provide a version in French. We also have some complaints from users in England. We even got a peculiar observation from someone working in Austria who is using the software for an American company there.

Hall So, tell me more.
Client: Well, to start with, the English users are annoyed with the weekly planner feature. They said the first day of the week was wrong.

Hall I can guess why. Their week starts on Monday, not Sunday. Most likely the weekday names in your program are hard-coded and in U. S. order.

However, if your developers had looked around a bit into the group of classes contained in the System.Globalization namespace of .NET, they might have found the DateTimeFormatInfo class. That class contains a list of weekday names (properly translated of course) and the first day of the week for each supported world region. So, you could just throw out the hard-coded list and access that information instead to get the names and in the right order automatically. Why carry around stuff in your code that you don't need?
Client: How does the system know which list to select?

Hall It chooses the list according to the user's selected locale setting, which is inherited from the underlying Windows system. It is transparent to the user. Even so, you can provide an override of the default behavior quite easily and make it available to a savvy user.
Client: How do you access the DateTimeFormatInfo object?

Hall You can get it from the .NET equivalent of the Windows Locale setting.
Client: What is that?

Hall It is a class named CultureInfo. It is at the core of the system for many operations. You have a default instance that is part of the current thread. Once you have an instance of CultureInfo, you also have the corresponding DateTimeFormatInfo reference. You also have access to a lot of other objects as well.
Client: That is interesting. Makes me almost want to try this out!

Hall Well, that is a sign of progress, I guess. Tell me about the Austrian issue? That seems interesting.
Client: The person who sent the complaint said that the first month of the year had the wrong name. The only place it could possibly occur is in a third-party application we bought.

Hall Beware third-party applications. They can be really great and save your team from a lot of development but they have to be checked thoroughly, especially with regard to internationalization.
Client: What I don't understand is: how could the name of the first month of the year be wrong in the first place? He told me that the name he saw was 'Januar' but it should be 'Jänner' for Austria. How could that happen?

Hall Well, it looks as if his computer's locale setting was set for Germany.
Client: I asked, and he said it was set for Austria.

Hall In that case, he was right. There is a problem.
Client: But, don't they speak German there?

Hall It is the official language. But, the first month is really Jänner. Even when two countries share a common border and language, interesting differences arise.
Client: So what happened?

Hall It looks as if the third-party app is the problem. Possibly the developers thought that since they speak German in Austria it would be the same as in Germany. It is probably hard-coded somewhere.
Client: The Austrian dude also complained about the date and number formats.

Hall Most likely, your program also has hard-coded formats. Better to set the culture correctly and depend on the corresponding DateTimeFormatInfo and NumberFormatInfo objects to provide the right information automatically. You can even customize these values. In fact, in .NET 2.0, you can even create a replacement culture if you want. By the way, are you using version 1.1 or 2.0?
Client: It was late in our development cycle when 2.0 came out, so we are still using 1.1.

Hall Well, this is a good opportunity for you to move to .NET 2.0. Although you can reuse a lot of stuff from 1.1, you will not easily get some of the new .NET features. And, now is your chance to add in the internationalization and localization structure you need. It is surprisingly easy to use the basic classes, which would certainly enrich an already good application, even if you don't go international.
Client: Why should I do this extra work?

Hall You gain a great deal of modularity. You can control common formats, user strings are isolated and easy to change without having to jump back into the code, and if someone changes the locale settings, the results are consistent for the new setting.
Client: You really are into this, aren't you?

Hall Just trying to make your job easier! By the way, did you have any difficulties with the .NET string class? As you know, it is based entirely on Unicode, so you don't have to deal with crossing code page boundaries if you decide to dabble in other languages. Of course, I know that your issues are complex since you have to deal with accounting rules that are peculiar to each region that you plan to support. This is not an easy task.
Client: Well, it was a helluva lot easier to use Unicode than the older Windows TCHAR stuff. On the other hand, we treated Unicode largely as if it were ASCII.

Hall For a while you can probably get by. For your current direction, which will probably be mostly Western European for a while, Unicode is easy to use. Surprisingly, Unicode also provides a practically transparent path to Chinese, Japanese, and Korean, which are certainly very important today.
Client: Don't you have to deal with all that double-byte stuff?

Hall All that disappears with Unicode. The basic char type is 16-bits, enough to encode the most widely used Far East characters and you don't have to worry about all that CharNext and CharPrev stuff from the old days. But, it is not entirely neat and clean.
Client: What if I got really ambitious?

Hall In what way?
Client: Suppose I decided to take on Arabic or some Indian languages.

Hall If you consider complex scripts such as Indic or Arabic, then you will have to give up the idea of one glyph = one char (UTF-16 element). On the other hand, .NET provides a pair of classes, StringInfo and TextElementInfo, to help you. Think of them as comprising a really smart pointer that keeps you on the straight and narrow when you work with strings.
Client: That sounds a bit scary. But, I suppose we need to start thinking about all this.

Hall Yeah, every successful company eventually has to come to grips with these issues. If you can spare your developers for a day, I can come over and provide an overview of the internationalization features in .NET and help your team learn how to manage the classes, including other objects that are affected.
Client: And what would they be?

Hall They include just about all the .NET Value Types - integer, long, short, decimal, etc. as well as DateTime, TimeSpan, and of course the String class. Also affected is the Thread class, and you may have to deal with the Encoding and Decoding classes as well - especially if your app is talking to non-Unicode modules.
Client: What about localization?

Hall Did you localize your latest release?
Client: Well, no. We did not expect to have to translate anything.

Hall You might actually like the .NET localization model. Especially in .NET 2.0, it has some very nice features including access to key strings as if they were properties. You can almost load a string in your sleep now. Besides, you externalize the UI elements of your program and that makes it really easy to make modifications without breaking the code. I can spend some time on this subject as well.
Client: Sounds good. Thanks very much, Bill.

Hall My pleasure.

Bill Hall is an independent consultant and multifaceted internationalization specialist with expertise on the globalization features of Microsoft .NET. Hall is writing a series of monographs on .NET 1.1 for Multilingual Magazine and has recently finished a series of papers on the new globalization features of Microsoft .NET 2.0. He also holds regular seminars on Win32 and .NET internationalization and localization.