Localization Overview

Globalization is the first step in the process of creating a world-ready application. In this step, the application's executable code is written. A truly global application should be culture-neutral and language-neutral. Therefore, you should focus attention on creating an application that will be able to support localized user interfaces and regional data for all users. Note that although a globalized application has this flexibility, the globalization process itself does not involve translating the user interface. Instead, you should strive to create an application with functionality that works equally well for users from all cultures and regions your application supports.

For each localized version of your application, add a new satellite assembly that contains the localized user interface block translated into the appropriate language for the target culture. The code block for all cultures should remain the same. The combination of a localized version of the user interface block with the code block produces a localized version of your application.

Kinds of Resources in the Hierarchy

• At the top of the hierarchy sit the fallback resources for your default culture, for example English ("en"). These are the only resources that do not have their own file; they are stored in the main assembly.
• Below the fallback resources are the resources for any neutral cultures. A neutral culture is associated with a language but not a region. For example, French ("fr") is a neutral culture. (Note that the fallback resources are also for a neutral culture, but a special one.)
• Below those are the resources for any specific cultures. A specific culture is associated with a language and a region. For example, French Canadian ("fr-CA") is a specific culture.

Localization Best Practices

• Move all localizable resources to separate resource-only DLLs. Localizable resources include user interface elements, such as strings, error messages, dialog boxes, menus, and embedded object resources.
• Do not hardcode strings or user interface resources.
• Do not put nonlocalizable resources into the resource-only DLLs. This causes confusion for translators.
• Do not use composite strings that are built at run time from concatenated phrases. Composite strings are difficult to localize because they often assume an English grammatical order that does not apply to all languages.
• Avoid ambiguous constructs such as "Empty Folder" where the strings can be translated differently depending on the grammatical roles of the string components. For example, "empty" can be either a verb or an adjective, which can lead to different translations in languages such as Italian or French.
• Avoid using images and icons that contain text in your application. They are expensive to localize.
• Allow plenty of room for the length of strings to expand in the user interface. In some languages, phrases can require 50-75 percent more space than they need in other languages.
• Use the System.Resources..::.ResourceManager class to retrieve resources based on culture.
• Use Visual Studio 2008 to create Windows Forms dialog boxes, so that they can be localized using the Windows Forms Resource Editor (Winres.exe). Do not code Windows Forms dialog boxes by hand.
• Arrange for professional localization (translation).

From DataGrid to Gridview Web Server Controls

The GridView control is the successor to the DataGrid control. Like the DataGrid control, the GridView control was designed to display data in an HTML table. When bound to a data source, the DataGrid and GridView controls each display a row from a DataSource as a row in an output table.

Differences between the GridView control and the DataGrid control include:

• Different custom-paging support.
• Different event models.

Both the DataGrid and GridView controls are derived from the WebControl class. Although it has a similar object model to that of the DataGrid control, the GridView control also has a number of new features and advantages over the DataGrid control, which include:
Richer design-time capabilities.

• Improved data source binding capabilities.
• Automatic handling of sorting, paging, updates, and deletes.
• Additional column types and design-time column operations.
• A Customized pager user interface (UI) with the PagerTemplate property.

Improved Design-Time Capabilities

Sorting, paging, and in-place editing of data requires additional coding when using the DataGrid control. The GridView control enables you to add sorting, paging, and editing capabilities without writing any code. Instead, you can automate these tasks, along with other common tasks such as data binding to a data source, by setting properties on the control.

If you are working in a designer, such as Microsoft Visual Studio, you can take advantage of designer features built into the GridView control. The GridView control includes support for a smart tag panel that provides a convenient interface for performing common tasks, such as setting properties and launching template editing.


Typically a DataSet control, a DbDataReader control, or a collection, such as an Array, an ArrayList, or some other class in the System.Collections namespace, is assigned to the DataSource property of either the DataGrid control or the GridView control. The DataGrid control and the GridView control can bind any object that implements the IEnumerable or IListSource interface.

While the DataGrid control can declaratively bind a DataSourceControl control, it can do so only for data selection. Sorting, paging, updates, and deletions must be coded manually. The GridView control supports a DataSourceID property that takes any object that implements the IDataSource interface and can, therefore, take advantage of the data source control's sorting, paging, updating, and deleting capabilities, for example, the SqlDataSource control.
Additional Column Types

The GridView control supports the following column types: BoundField, HyperLinkField, ButtonField, CommandField ImageField, and CheckBoxField.
Built-In and Custom Paging Support

The DataGrid control requires additional coding for paging. The GridView control automatically supports paging by setting the PagerSettings property. The PagerSettings property supports four modes: Numeric (default), NextPrevious, NumericFirstLast, and NextPreviousFirstLast. The Numeric mode displays numbered page links instead of "next/prev" links, and the NumericFirstLast option adds first and last page links. The GridView control's PagerStyle property can be used to set styles and the position of the pager.

Additionally, you can customize the pager buttons for the GridView control using a PagerTemplate.

Custom paging support in the GridView is supplied by the bound data source control as opposed to the AllowCustomPaging mechanism supplied by the DataGrid control.
Expanded Event Model

The DataGrid and the GridView controls have different event models.

The DataGrid control raises single events for operations, while the GridView control is capable of both pre-operation and post-operation events. The GridView control supports the Sorting event that occurs when a field is sorted. Note that this sorting event occurs before the GridView control automatically handles the sort operation, giving you the opportunity to examine or change the SortExpression property, or cancel this operation by setting the Cancel property to true on the passed event arguments.

The GridView control supports the Sorted event that occurs after the GridView control completes the sort operation, giving you the opportunity to change or format the result of the sort operation. In comparison, the DataGrid control supports the SortCommand event that occurs when a column is sorted. Similarly, the GridView control supports RowUpdating and RowUpdated events that occur before and after the GridView control has automatically handled the update operation. In comparison, the DataGrid control supports the UpdateCommand event that occurs when the Update button is clicked for an item in the grid.

How Web Resources work

Web Resources rely on a special handler that is named WebResource.axd, which is designed to retrieve assembly resources and serve them to the Web browser. The handler type for WebResource.axd is AssemblyResourceLoader.

When a request comes in from the client for WebResource.axd, the handler looks for the Web Resource identifier in the QueryString method of the Request object. Based on the value of the Web Resource identifier, the handler then tries to load the assembly that contains this resource. If this operation is successful, the handler will then look for the assembly attribute and load the resource stream from the assembly. Finally, the handler will grab the data from the resource stream and send it to the client together with the content type that you specify in the assembly attribute.

The URL for WebResource.axd looks like the following:
WebResource.axd?d=SbXSD3uTnhYsK4gMD8fL84_mHPC5jJ7lfdnr1_WtsftZiUOZ6IXYG8QCXW86UizF0&t=632768953157700078

The format of this URL is WebResource.axd?d=encrypted identifier&t=time stamp value. The "d" stands for the requested Web Resource. The "t" is the timestamp for the requested assembly, which can help in determining if there have been any changes to the resource.
Delving into the code
In my example, I have developed a COM control that is consumed by an ASP.NET Web application to demonstrate this new feature.
COM control for the Web Resource
For creating and embedding a Web Resource, I have developed a COM control (SimpleControl). It has the following embedded resources:

* Two image files that are named smallFail.gif and smallSuccess.gif. These image files are used for rollover effects in the control and are consumed within the control code.
* An HTML file that is named Help.htm. This file does not contain much text and is just for demonstration.
* One JavaScript file that is named MyScript.js. This file contains some JavaScript code which also demonstrates the substitution feature to get a reference to another embedded resource within the same assembly.
* One .css file that is named MyStyleSheet.css. This style sheet is then consumed directly from the ASP.NET Web application.

In this article, I will discuss the parts that are required for Web Resources.
Embedding the Web Resources
First, you have to make sure that all the static files that are added to the Web Control Library project in Microsoft Visual Studio 2005 are embedded resources. To embed these resources, all that you have to do is add these files to Visual Studio and then modify the properties of these files so that the build action is set to Embedded Resource.

After you have done this, you also have to make sure that these resources have been referenced by the WebResource assembly attribute in the AssemblyInfo.cs
he WebResource assembly attribute has three parameters as follows:

* Web Resource: The name of the resource that is embedded in the assembly
* ContentType: The MIME file type for the resource
* PerformSubstitution: A Boolean value that determines whether other Web Resource URLs that are referenced in this resource are parsed and replaced with the full path of the resource

Fetching the Web Resources
For getting the Web Resource, I have used the GetWebResourceUrl method, which is a method of the ClientScriptManager class that is typically used for managing client-side scripts. This method returns a URL reference to the server-side resource that is embedded in an assembly. The GetWebResourceUrl method accepts the following two parameters:

* Type: The type of the server-side resource
* Resource Name: The name of the server-side resource

To use this method, first you have to create an instance of the ClientScriptManager class and get the type of the class as shown below.
ClientScriptManager cs = Page.ClientScript;
Type rsType = this.GetType();

ASP.NET MapPath

MapPath is used to resolve virtual paths and physical paths. You run the ASP.NET development server on your local machine, but the paths on it are not the same as they are on your server. Here we use MapPath to find physical paths and file locations, using the C# programming language.

What is MapPath?
First, in ASP.NET the ~ tilde indicates the root of a virtual path. We need the tilde because otherwise ASP.NET can't figure out if a path is absolute or relative. Let's look at some virtual paths and what they might map to.

Virtual paths: ~/App_Data/test.xml
~/
~/Mapfile.txt

Physical paths: C:\Website\Files\test.xml
C:\Website\Default.aspx
C:\Website\Mapfile.txt
Virtual hosts security

Here we note that if you are using a virtual shared host, there may be problems in your code related to file permissions and security checks. The problem may not be MapPath at all. In fact, MapPath is very simple and unless you have a typo in the argument, it won't cause you any problems

Difference of Server.MapPath and Page.MapPath

both map a virtual path to a physical one..

Page.MapPath: -

Retrieves the physical path that a virtual path, either absolute or relative, or an application-relative path maps to..

Server.MapPath: -

Each file on a Web server has two ways of being accessed - through a virtual path and through a physical path. The virtual path is the path one would enter into their browser's Address bar, for example:

http://www.yourserver.com/someDirectory/someFile.asp

The bold part of the URL above is referred to as the virtual path. The physical path is the actual drive, directory, and filename of a particular file on the Web server. For example, on your computer, if you run Windows 9X, your Win.ini file's physical path is C:\WINDOWS\WIN.INI (assuming you installed Windows on your C: drive).