Prizes & Awards
My Profile
Active Members
TodayLast 7 Days
more...
|
Resources » Articles » .NET Framework »
Globalization of Web Applications using ASP.NET
|
) Introduction
Globalization includes the process of first internationalizing the application code, followed by localizing the application to other languages and cultures. The internationalization process makes it possible to translate, store, retrieve, and present application content for any locale, preferably using the same application code base. Locale is the combination of both language and cultural environment, including the format of dates, times, currencies, telephone numbers, and so on. This implies isolating locale-dependent from locale-independent content and also preparing code to dynamically format that content according to locale. The end result of application internationalization supports its localization. Localization means adapting application to other locales by translating and formatting content according to culture.
2) Steps involved in Globalization
2.1) Globalization
Globalization is the process of designing and developing a software product/Application that functions in multiple cultures/locales. This process involves:
• Identifying the culture/locale that must be supported
• Designing features which support identified cultures/locales
• Writing code that functions well in any of the supported cultures/locales
In other words, globalization adds support for input, display, and output of a defined set of language scripts that relate to specific geographic areas. The most efficient way to globalize these functions is to use the concept of cultures/locales. A culture/locale is a set of rules and a set of data that are specific to a given language and geographic area. These rules and data include information on:
• Character classification
• Date and time formatting
• Numeric, currency, weight, and measure conventions
• Sorting rules
2.2) Localizability
An intermediate step prior to localization is a process known as localizability. Localizability is about ensuring we have enabled a globalized application for localization by separating the resources requiring localization from the rest of the application. Proper localizability results in source code will not have to modify during localization.
2.3) Localization
The final step, localization, is the process of customizing application for a given culture/locale. Localization consists primarily of translating the user interface.
3) .NET and Globalization
Microsoft .NET Framework simplifies localization tasks substantially by making its formatting, date/time, sorting, and other classes culturally aware. Using classes from the System.Globalization namespace can set application’s current culture, and much of the work is done for us automatically!
3.1) Encoding Support
ASP.NET internally uses Unicode. In addition, ASP.NET utilizes the String class of the .NET Framework class library and the related utility functions, which are also internally Unicode. When interfacing with the outside world, ASP.NET can be configured in several ways to use a defined encoding, which includes the encoding of .aspx files, request data, and response data. For example, it is possible to store .aspx files with Unicode encoding and convert the HTML output of a page to an ANSI code page like ISO-8859-1.
3.2) Localization Support
Properties of a locale are accessible through the CultureInfo class. Additionally, ASP.NET tracks two properties of a default culture per thread and request: CurrentCulture for the default of locale-dependent functions and CurrentUICulture for locale-specific lookup of resource data.
The following code displays the culture values on the Web server.
<%@Import Namespace="System.Globalization"%>
...
<%=CultureInfo.CurrentCulture.NativeName %>
<%=CultureInfo.CurrentUICulture.NativeName %>
The result is as follows:
English (United States)
English (United States)
For locale-dependent data like date/time formats or currency, ASP.NET leverages the support of the .NET Framework class library in the common language runtime. Code on ASP.NET pages can use locale-dependent formatting routines like DateTime.Format.
For example, the following code displays the current date in a long format: the first line according to the system locale, the second one according to the German ("de") locale:
<%=DateTime.Now.ToString ("f")%>
<%=DateTime.Now.ToString ("f", new System.Globalization.CultureInfo ("de-DE")) %>
The result is as follows:
Thursday, March25, 20041:40AM
Donnerstag, 25. März 2004 01:40
3.3 Configuration Settings
When creating ASP.NET pages or code-behind modules, developers can use the .NET Framework class library to provide features necessary for a globalized environment or to localize the application. ASP.NET also provides configuration settings to ease development and administration of ASP.NET applications.
ASP.NET utilizes configuration files to provide directory settings that are usually also inherited by subdirectories. Each file can contain a Globalization section in which we can specify default encodings and cultures. Values are valid if they are accepted by the related classes Encoding and CultureInfo
Within the Globalization section, the value of fileEncoding determines the way in which ASP.NET encodes .aspx files; the values of requestEncoding and responseEncoding determine the way in which request data and response data are encoded, respectively.
The attributes of the Globalization section in the Web.config file can also be specified on the Page directive (with the exception of fileEncoding, because it applies to the file itself). These settings are only valid for a specific page and override the settings of the Web.config file. The following sample directive specifies that the page should use French culture settings and UTF-8 encoding for the response:
<%@Page Culture="fr-FR" UICulture="fr-FR" ResponseEncoding="utf-8"%>
4) Ways to make world ready web applications using ASP.NET
There are several different approaches to creating Web applications that support multiple cultures. Each approach is based on the globalization tools that the .NET Framework provides. Choose a single approach or a combination of approaches based on applications needs.
We have three best approaches depend on detecting the user’s culture at run time and then forming a response based on that information.
4.1) Detect and Redirect
Create a separate Web application for each supported culture, and then detect the user’s culture and redirect the request to the appropriate application.
Maintaining content separately is best suited for Web applications that present large amounts of content that must be translated or otherwise changed for other cultures.
Both the Request object’s User Languages array and the CultureInfo class’s Name property return culture information in two parts: the first two letters are the language code; the last two letters contain a region code. For example, English US (en-US) and English United Kingdom (en-GB) both use English, but they display different currencies and date order.
To redirect requests based on language alone, follow these steps:
1. Get the user’s preferred language or CurrentCulture.
2. Get the first two letters of the returned value.
3. Compare those letters to the list of language codes.
For example, the following code detects the user’s language and then redirects the user to one of several different language-specific Web sites:
Visual Basic .NET
Private Sub Page_Load(ByVal sender As System.Object, _
ByVal e As System.EventArgs) Handles MyBase.Load
Dim sLang As String
sLang = Request.UserLanguages (0)
sLang = sLang.Substring(0, 2)
Select Case sLang
Case "en"
Response.Redirect("http://www.yourdomain.com/usa")
Case "es"
Response.Redirect("http://www. yourdomain.com/es")
Case "de"
Response.Redirect("http://www. yourdomain.com/de")
Case "zh"
Response.Redirect("http://www. yourdomain.com/zh")
Case Else
Response.Redirect("http://www. yourdomain.com/usa")
End Select
End Sub
Visual C#
private void Page_Load(object sender, System.EventArgs e)
{
string sLang = Request.UserLanguages[0];
sLang = sLang.Substring(0, 2);
switch (sLang)
{
case "en":
Response.Redirect("http://www. yourdomain.com/usa");
break;
case "es":
Response.Redirect("http://www. yourdomain.com/es");
break;
case "de":
Response.Redirect("http://www. yourdomain.com/de");
break;
case "zh":
Response.Redirect("http://www. yourdomain.com/zh");
break;
default:
Response.Redirect("http://www. yourdomain.com/usa");
break;
}
}
}
Advantages
• Content is maintained separately, so this approach allows the different applications to present very different information, if needed.
• Users can be automatically directed to sites that are likely to be geographically close, and so can better meet their needs.
• Content files (Web forms and HTML pages, for example) can be authored in the appropriate natural language without the complexity of including resource strings.
Disadvantages
• Localization often referred to a process that began after an application developer compiled the source files in the original language. Another team then began the process of reworking the source files for use in another language. The original language, for example, might be English, and the second language might be German. That approach, however, is prohibitively expensive and results in inconsistencies among versions. It has even caused some customers to purchase the original-language version instead of waiting months for the localized version.
• Using this approach requires that the executable portion of the Web application be compiled and deployed separately to each culture-specific Web site. This requires more effort to maintain consistency and to debug problems across Web sites.
4.2) Run – Time adjustment
By default, Web applications run on the server using a neutral culture. Neutral cultures represent general languages, such as English or Spanish, rather than a specific language and region. When we set the culture attribute for a Web application in Web.config, ASP.NET assigns that culture to all the threads running for that Web application. Threads are the basic unit to which the server allocates processor time—ASP.NET maintains multiple threads for a Web application within the aspnet_wp.exe worker process.
Using Web.config to set the culture creates a static association between the application and a specific culture. Alternatively, we can set the culture dynamically at run time using the Thread class’s CurrentCulture property, as shown here:
Visual Basic .NET
Imports System.Globalization
Imports System.Threading
Private Sub Page_Load(ByVal sender As System.Object, _
ByVal e As System.EventArgs) Handles MyBase.Load
Dim sLang As String
sLang = Request.UserLanguages(0)
Thread.CurrentThread.CurrentCulture = New CultureInfo(sLang)
End Sub
Visual C#
using System.Globalization;
using System.Threading;
private void Page_Load(object sender, System.EventArgs e)
{
sLang = Request.UserLanguages[0];
Thread.CurrentThread.CurrentCulture = new CultureInfo(sLang);
}
The preceding code detects the user’s culture and then sets the culture of the current thread to match. ASP.NET will then format date, currency, and numeric strings using the user’s culture.
Advantages
• All cultures share the same application code, so the application doesn’t have to be compiled and deployed for each culture.
• The application resides at a single Web address—we don’t need to redirect users to other Web applications.
• The user can choose from a full array of available cultures.
Disadvantages
• Setting the culture dynamically is best suited for simple Web applications that don’t contain large amounts of text that must be translated into different languages.
4.3) Satellite Assemblies
Satellite assemblies allow storing the translated strings for each culture in a separate, resource-only assembly file that can load automatically based on the setting of the CurrentUICulture property. Using satellite assemblies provides the same advantages as adjusting to the culture at run time, plus satellite assemblies simplify displaying content from multiple translated sources.
Satellite assemblies are assembly files (.dll) that contain localized resources for an application. Each satellite assembly file contains the resources for one culture. An application can have many satellite assemblies, depending on how many cultures the application supports.
Web application projects use satellite assemblies to store the translated strings, graphics, and other culture-dependent aspects of an application’s user interface. To create the assemblies themselves, we use the Resource Manager. At run time, the Web application loads the translated strings into the Web form based on the current thread’s CurrentUICulture property.
To use satellite assemblies, follow these steps:
1. Set the id and runat attributes for all of the user-interface elements of application that require translation. Server controls have these attributes by default, but we will need to add them to HTML elements such as heading, paragraph, and span so that we can load translated strings into those elements.
2. Create a fallback resource file containing the default strings to display in the user interface if the user’s culture is not specified or not recognized. Name the fallback resource file filename.resx—for example, strings.resx.
3. Create resource files containing the translated strings to display for each general language that Web application supports. Name the translated resource files filename.languagecode.resx—for example, strings.es.resx.
4. Optionally, create resource files containing the translated strings to display for each specific culture that Web application supports. Name the resource file filename.languagecode-regioncode.resx—for example, strings.ex-MX.resx.
5. Write code to load the resources for the Web form using the ResourceManager class.
6. Write code to detect the user’s culture and set the Thread class’s CurrentCulture and CurrentUICulture properties to match. ASP.NET uses the CurrentCulture property to determine formatting for dates, currency, and numbers; ASP.NET uses the CurrentUICulture property to determine which satellite assembly is used when loading translated strings.
7. Write code to get strings from the resource files and display them in elements on the Web form.
Advantages
• Efficiency developing a new international version of the application only involves creating a new international resource file because each version has the same code block. This streamlines the creation of multiple language versions of application.
• Greater security whether we decide to localize application in-house or to use an external company, we will not need to access source code to develop international versions of application.
• Less testing this approach dramatically reduces the amount of testing required to ensure the quality of application's international version.
• Better localization by placing all relevant string resources in one file, ensure a more efficient localization process and reduce the chance of leaving some strings un-localized.
5. Globalization Issues
5.1) Sorting and Comparing Strings
Sorting and string comparison we perform using the .NET Framework classes give the correct result based on the current culture. We need to worry about globalization issues only when implementing our own techniques for those tasks, such as when we are implementing custom sorting procedures. In those cases, use the System.Globalization namespace’s CompareInfo class to perform culturally aware string comparisons.
5.2) Custom Validation Controls
ASP.NET server controls acquire specific properties based on the current culture. This includes the validation controls. We do need to consider globalization issues when creating custom validation controls.
5.3) Building Strings
Because some languages read from right to left, and because some words change meaning when in proximity to other words, it’s difficult to build strings using concatenation in a way that works for all cultures. Instead, we store completed strings in a resource file and retrieve the strings as needed by using the Resource Manager.
5.4) Getting Substrings
In some languages, character symbols are composed of two characters. In those cases, we might need to adjust how we get substrings. For example, getting the first character of a user’s response would be meaningless in those cases.
5.5) Character Encoding
Characters within strings can be represented many different ways within a computer. These different ways of representing characters are called character encodings because they encode characters into numbers that the computer can understand.
The common language runtime (CLR) uses the UTF-16 character encoding, which maps characters to 16-bit numbers. These 16-bit numbers provide enough room to accommodate the characters for almost all written languages. Unfortunately, that’s about double the size that other character encoding schemes use, which makes the UTF-16 character encoding less than optimal for transmitting text over the Internet.
Therefore, ASP.NET uses the UTF-8 character encoding by default when interpreting requests and composing responses. UTF-8 is optimized for the lower 127 ASCII characters, which means it provides an efficient way to encode languages that use the Latin alphabet. UTF-8 is also backward-compatible with the ASCII character encoding, meaning that UTF- 8 readers can interpret ASCII files.
The CLR handles the conversion between encodings by using classes from the System.Text namespace. We usually don’t need to be aware that any of this is going on.
6) Successful development approach in Globalization of Web applications
An application prepared for localization has two conceptual blocks, a data block and a code block. The data block exclusively contains all the user-interface string resources. The code block exclusively contains only the application code applicable for all cultures/locales.
The code block for all cultures/locales should be the same. The combination of the data block with the code block produces a localized version of application. The keys to successful world-ready software design and subsequent localization success are:
• Separation of the code block from the data block (Use code behind pages)
• Application's ability to accurately read data regardless of the culture/locale
7) Recommendations of best Practices
Developers can reduce their development time on almost any international application by considering the following issues prior to the start of the development cycle:
• Use Unicode as character encoding to represent text. If we cannot use Unicode, we will need to implement DBCS (double-byte character set) enabling, bi-directional (BiDi) enabling, code page switching, text tagging, and so on.
• Consider implementing a multilingual user interface. If we design the user interface to open in the default UI language and offer the option to change to other languages, users of the same machine who speak different languages reduce down time related to software configuration. This may be a particularly useful strategy in regions such as Belgium with more than one culture/locale and official language.
• Watch for Windows messages that indicate changes in the input language, and use that information for spell checking, font selection, and so on.
• If we are developing for Windows 2000, test application on all language variants of Windows 2000, using all possible cultures/locales.
• Avoid slang expressions, colloquialisms, and obscure phrasing in all text. At best, they are difficult to translate; at worst, they are offensive.
• Avoid images in bitmaps and icons that are ethnocentric or offensive in other cultures/locales.
• Avoid maps that include controversial regional or national boundaries. They are a notorious source of political offense.
• Isolate all user interface elements from the program source code. Put them in resource files, message files, or a private database.
• Use the same resource identifiers throughout the life of the project. Changing identifiers makes it difficult to update localized resources from one build to another.
• Only place strings requiring localization in resources. Leave non-localized strings as string constants in the source code.
• Allocate text buffers dynamically since text size may expand when translated. If we must use static buffers, make them extra large to accommodate localized strings.
• Keep in mind that dialog boxes may expand due to localization. For example, a large dialog box that occupies the entire screen in low-resolution mode may require resizing to an unusable size when localized.
• Avoid text in bitmaps and icons, as these are difficult to localize.
• Do not create a text message dynamically at run time, either by concatenating multiple strings or by removing characters from static text. Word order varies by language, so dynamic composition of text in this manner requires code changes to localize to some languages.
• Similarly, avoid composing text using multiple insertion parameters in a format string because the insertion order of the arguments changes when translated to some languages.
• If localizing to a Middle Eastern language, such as Arabic or Hebrew, use the right-to-left layout APIs to lay out application right-to-left.
• Test localized applications on all language variants of Windows 2000. If application uses Unicode, as recommended, it should run fine with no modifications. If it uses a Windows code page, we will need to set the culture/locale to the appropriate value for localized application and reboot before testing.
8) Conclusions
If we address globalization, localizability, and localization requirements during the design phase, we will maximize the quality of the localized applications and minimize the amount of required time and money. On the other hand, retrofitting existing applications for localization typically results in inferior localized versions, increased cost, and increased time to market.
Localization process should be relatively painless for the development team if internationalization was part of the initial development cycle.
Even though we have couple of ways to achieve Globalization of web application, it is suggested to use resource files & satellite assemblies to achieve the following:
We can launch application onto the market more rapidly. No additional development is necessary to localize an application once the initial version is complete.
We use resources more efficiently. Implementing world-readiness as part of the original development process requires fewer development and testing resources than if we add the support after the initial development work starts. Furthermore, if we add world-readiness to finished application, we might make it less stable, compounding problems that we could have resolved earlier.
Application is easier to maintain. If we build the localized version of application from the same set of sources as the original version, only isolated modules need localization. Consequently, it is easier and less expensive to maintain code while including world-readiness. The key to this aspect of designing software rests in using resource files for the localized versions of the application.
|
Responses
|
| Author: Prathap Reddy 19 Dec 2005 | Member Level: Gold Points : 0 | Hi..
Actually for this concept I searched some sites.I am not yet get proper result, which was in good understanding.
But this article i understood very clearly.This is nice article about globalization.
ThanQ
bye
|
|