Brief Overview of Globalization

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/brief_overview_of_globalization.htm]

It is becoming more and more common to globalize a web applications, and fortunately .Net provides the features to easily do this.

Developing Web Applications With MS VB and C# explains of three main strategies (quoted from pg. 680):

Approach	Description	Best for
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.	Application with lots of test content that requires translation and few executable components.
Run-time adjustment	Create a single Web application that detects the user's culture and adjusts output at run time using format specifies and other tools.	Simple applications that present limited amounts of content.
Satellite assemblies	Create a single Web application that stores culture-dependent strings in resource files that are compiled into satellite assemblies. At run time, detect the user's culture and load strings from the appropriate assembly.	Applications that generate content at run time or that have large executable components.

I personally have used the resource files. While there are a lot of online tutorials already out there and reference, I have found a couple useful techniques not popularly discussed:

One of the problems with globalization is the Left-To-Right or Right-To-Left direction of text. This can complicate string concatenation. For example the expression: "Hello" + strYourName + " There" assumes a LTR direction that's fine for English, but not Arabic. Therefore I found it useful to create a GlobalUtilities.Concat method that takes an array of variables and the neutral culture (like "en" or "de"), and concatenates those variables in the correct direction.

Another problem is performing complex business logic, such as concatenating variables to create an output message to the user, or formatting DateTimes. This requires knowing the culture so that you can carry out the logic, or even get resources from the resource file. I have found it convenient to pass in the culture as a parameter into the object's constructor. I can then easily test those error-prone globalization methods.

Another tip I'm finding useful is applying FxCop's Globalization rules:

• Avoid duplicate accelerators
• Do not hardcode locale specific strings
• Do not pass literals as localized parameters
• Set locale for data types
• Specify CultureInfo
• Specify IFormatProvider
• Specify MessageBoxOptions