In this article you’ll finish examining the features that ASP.NET provides to help you build fully localized Web applications. In particular you’ll see how .NET manages dates, numbers, and currencies, and how can localize them. Finally, you’ll see a brief wrap-up of localization that consolidates the information in Part 1 and Part 2.

Localizing Dates
As long as you store dates in a DateTime object, they are pretty easy to localize, which is good because, to give you an idea of the problem that needs solving, just look at how differently French and UK English dates are usually displayed:

• UK: 20 August 2001
• French : lundi 20 ao?t 2001

It’s easy to see that the language for long-format dates is different, but short-format dates are different as well. For example, the order of the month and day differs between UK and US dates. In the UK August 20, 2001 is 20/8/01, but in the States it’s 8/20/01. Clearly, such differences are critical to communicating information correctly.

In ASP.NET, to display a date in a different culture, you use the Thread object to change the current thread culture, and then use one of the DateTime class display methods to display the date. For example, the following fragment displays a date in long format determined by the French (fr-FR) culture setting.

   CultureInfo culture =       CultureInfo.CreateSpecificCulture("fr-FR");   System.Threading.Thread.CurrentThread.CurrentCulture =      culture;   string date = DateTime.Now.ToLongDateString();   Response.Write(date);

Localizing Numbers and Currencies
Currencies and numbers vary in much the same way as dates?and .NET handles them just as neatly. As with dates, after you set the culture for the current thread, the framework handles formatting. For example, the French/France locale uses commas in numbers where English cultures generally use periods. To make the change, you first set the culture and then display the formatted string. For example, to display the value 5.5 in French as “5,5”, you can write:

   CultureInfo culture =       CultureInfo.CreateSpecificCulture("fr-FR");   System.Threading.Thread.CurrentThread.CurrentCulture =       culture;   Label1.Text = (5.5).ToString();

Currencies work similarly, but you need to specify explicitly that you want a value displayed as a currency. For example, to display the Japanese price ?100 (100 Yen), you can write:

   CultureInfo culture =       CultureInfo.CreateSpecificCulture("ja-JP");   System.Threading.Thread.CurrentThread.CurrentCulture =       culture;   Label1.Text = String.Format("{0:c}",100);

The preceding code uses the String format specifier “c”, which displays the value as a currency using the thread’s culture setting.

The Internet was originally an English-speaking world, but the percentage of English speakers is retreating as the breadth and variety of languages increases. With huge populations in Asian countries coming online and European countries needing to work more closely together, the need for Web sites that cater to visitors from different cultures is growing. This is clearly a good thing, but it creates new challenges for Web site developers.

The .NET Framework includes a variety of features to help you create truly international Web sites, many of which apply to all types of application whether they’re Windows Forms, console or ASP.NET applications.

Language and Culture Considerations
In analyzing the features that must look and function differently for each culture and language in a localized Web site, a few core areas appear:

• Database and File Content. Larger pieces of information such as news stories, articles, product descriptions, etc. This type of data is often located in a database, although many Web sites store it in HTML files.
• Graphics. Virtually every site uses graphic images. Although many won’t be affected by changes in language, some will, specifically mages that contains text or that contain symbols that have meanings which differ across cultures.
• Text resources. These are those little bits of text that appear with a site, and include such things as the corporate switchboard number, fax number, single-line copyright statement and the front page welcome message. The majority of Web sites will store this type of information in the page files itself, whether it’s an aspx file or a flat HTML file, but you will need to identify them and move them to resource files or database tables.
• Dates, Numbers, and Currencies. Different cultures display their dates, numbers, and currencies differently. Displaying information in a format optimized for the viewer is crucial if you want the reader to be comfortable with the site and have access to accurate information.

In addition to these four areas, there are a few more that I haven’t discussed in this article, including string sorting and casing, and measurement systems (such as whether the culture uses Imperial (pounds and ounces) or metric (kilograms and grams) measurements.

The translation process is worth a mention briefly as it is often more significant in terms of operational planning than the technology itself. Here are some questions you may like to consider:

• Who will translate the content?
• What languages will the site support?
• When content is only available in a limited number of languages, does the site display the content in the default (wrong) language, or hide it from the user?
• What process will support the translation?
• Will there be parallel releases of content in different languages, or will each be released as and when it is complete?
• Which will be the primary language, the one that the site defaults to when errors occur or resources cannot be found?

After you build the site, the process will become the focus. Consider it early to avoid problems when the site goes live.

In this article, the process is going to be relatively trivial. I’ve used Altavista’s Babelfish to do translations to provide some sample content. The site will display the most appropriate content to our audience, but as you’ll see later there will be some restrictions in our test application.

Localizing Database Content
Custom databases can be designed to hold content for Web sites in a variety of different designs depending on the application requirements. Once you have a suitable database structure, you will need a way to ensure that the user of the Web site sees the right content and that performance issues are addressed successfully. ASP.NET provides this functionality so that the glue required to localize content in a database is relatively small. Much of this code is provided by the System.Globalization namespace that gives you information about the user’s locale and allows you to acquire more details about that locale (for example the currency).

Another important part of ASP.NET from the standpoint of database-located content is caching. It provides caching at the page level, but also at the user interface control and application levels. These features mean that you can create a Web site that delivers content from a database whilst being confident that most of the performance issues have already been solved for you.

Localizing Graphics
Internationalizing images on a Web site has the potential to be a huge task, however there are things you can do to reduce the burden. Most importantly is that you reduce the count of images need internationalizing. Consider recreating images that contain text, numbers, dates, currencies, measurements or icons that can be related to specific cultures (flags, maps, logos, etc) in a more international form.

After reducing the problem to a more manageable size, you can consider how to deal with images that do need different versions for different cultures. There are two approaches:

• Dynamic images. This technique means that each image is created on-the-fly dependent on the culture of the visitor. Although the ideal solution in many ways from a management point of view, performance issues provide some restrictions here.
• Static images. Often images for each culture are stored separately on disc, perhaps in separate folders. The Web site then ensures that the correct image is sent to the user in response to a Web request.

The features that ASP.NET provides for caching and managing cultures make both approaches relatively simple, and certainly much easier than with ASP 3.0.

As a final note, once you begin internationalizing your applications, you must ensure that an image exists in each culture folder for each localized image that your application needs. In many cases, that’s difficult. You may find that you want to default to using an image for a specific culture or a generic image. In that case you can check if the ideal image file exists, and if not, change the generated HTML to point to the default language version.

Localizing Text
Localizing small pieces of text is also much easier with ASP.NET. The framework includes a method for managing resources much like that in earlier Windows Development. Using resource files creates a broad range of options for your applications and also lets you manage those resources more easily. For example you can easily pass resources to a translation agency and put them back into the application without recompiling the entire application.

Managing Frequently Changing Resource Strings
In some applications, you may find it necessary to be able to edit text resources easily, without having to edit resource files. For example some sites might want to be able to change the welcome message on the site daily. To achieve this, you might like to consider an alternative approach where the resources are stored in a database. You can provide an interface on the site that allows site managers to make such changes. Storing these strings in a database is not as efficient as using resource files, and could cause serious performance problems, so if you take this route, you should look into caching these objects in an HttpCachePolicyObject (Page.Cache).

Don’t Overuse ResourceManager Objects
You’ll recall that in the sample code the SiteText server control that displays things like the Copyright message instantiates an object from the ResourceManager class. It uses that instance to gain access to the string resources for each culture. Microsoft recommends that for applications where performance is an issue, you should avoid constantly instantiating new objects from this class. A more scalable approach would be to create and store a single ResourceManager instance in the Application object and hook the SiteText class up to that stored copy rather than creating a new one for each request.

Improve Culture Matching
As you saw in Part 2, the sample code contains a global.asax file method that estimates the most appropriate culture for the visitor. As it currently is, if a visitor came from Belgium with a culture identifier of fr-BR, the string would not match the fr-FR identifier in the culture list and so the language would default to English rather than French (and that may or may not be appropriate). The code would benefit from being extended so that if there is no direct match, it checks to see if there is a match on the first part of the culture code. For example, if you were to extend the sample the improved version would check for a match against fr rather than the full fr-FR identifier after the exact check failed.

Caching and Performance
ASP.NET provides an extensive range of caching options that make it much easier to create applications that perform better not only from the users’ perspective, but also perform better on the Web site back-end, because you reduce database hits and formatting cycles by caching pre-created content.

ASP.NET lets you cache objects on a per-page and per control basis. But you can go beyond that by creating custom caching schemes where pages are cached on the basis of any value you choose?for example the users’ browser type and version.

When building a localized Web site, the need for caching and performance enhancement is no less of an issue. Using the features of ASP.NET, it is possible to build an application that not only provides good localization features, but also maintains the benefits of the caching that it provides.

However, make sure that you don’t run out of memory. The sample applies output caching to each news article. Although you can realize tremendous performance gains from caching, it’s important to understand that there’s a downside?the memory required to store the cached pages. In fact, if the site supports a large number of articles and cultures, the output cache requirements could be huge. If the cache exceeds the available RAM, the server will be forced to pull content from the database regularly, thereby negating the benefits of caching content. When caching, it’s extremely important to ensure that the cache is large enough to support the data being cached?in this case you would need to ensure the machine had enough RAM to hold all the cached pages.

Don’t Forget Content Management
Finally, despite the fact that this article focuses on content delivery, in a real application you also need to implement interfaces to add, edit, and delete or hide content located in a database. It’s important not to underestimate the amount of work involved; it’s common with content management systems for the back-end interfaces to take much longer to develop than the front-end, because the back-end often must do much more work with the data.