Visual Studio and Localization
Visual Studio is a very productive development environment but with regards to localization if offers very little.
Drawbacks when localizing with Visual Studio
No support for a localization process. Software products have a live cycle and with each new release the localization has to be performed again. Without support from
a tool this can be a daunting task.
No change management for resource strings. In Visual Studio you don't know which string have been changed or added with each new release of your software. To prevent errors
all translations have to be verified with each release.
Localizing in Visual Studio is possible by creating resource files (.resX files) for the different target languages and then translating the Windows Forms (C# or .vb) or
ASP.NET pages (.aspx files). However, one ends up with lots and lots of .resX files that are hard to manage in Visual Studio and often make Visual Studio
become slow and instable.
- Outsourcing translations is cumbersome.
Advantages of using a localization tool
- Good localization tools support a localization process that becomes part of the general release cycle.
- The tool keeps track of the translation status of each string. When changing or adding new strings these will be clearly marked as to be reviewed and/or translated.
- Separation between coding and translating. Developers and translators can work independently from each other.
- Translations can be outsourced to several external translators in parallel.
- Support for automatic translations (Google Translator, MS Translator) and Translation Memory increase the consistency of the translation.
- Greater productivity when translating due to an environment tailored to translation.
Coding with localization in mind
Localizing a .NET application is actually not as complex as it is sometimes depicted.
Localization support is directly build into .NET Windows Forms, ASP.NET, WPF and all other .NET target plattforms. It can be activated with a few clicks in Visual Studio.
There are however a few things to consider when writing your application in order to simplify the localization process:
Never put any stings into your source code. ALL strings must be placed into resource files (resx) and referenced
in code by using the ResourceManager class. This rule also applies to formatting strings and constants to be displayed.
It is good practice to keep localization out of the data access and business logic layer. This
means that these layers will only raise exceptions in the invariant language. All unhandled exceptions raised in lower layers
need therefore be catched by the UI layer to display a localized error message.
Do not use concatenated strings built at run time. Concatenated strings are difficult to localize
because they often assume the grammatical order of the invariant language that does not apply to all languages.
- Avoid using images and icons that contain text or other content that may need to be localized. They are cumbersome and 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.
What if you have hard coded strings in your code?
While having hard coded strings should be avoided in the frist place, your application can still be prepared for localization. Just don't make the
error of doing it the wrong way. PUT SRTINGS INTO RESOURCES. Take the extra few days it will cost to extract all strings from code and put them into
resource files where they belong. You will more than regain the lost days during the localization process by using all the tools that support the .NET
Remember, you'll have to perform the localization process for every release of your application so you will save time with
Globalization and localisation best practices
Walkthrough: Localizing Windows Forms
Introduction to Localization in ASP.NET 2.0
Implicit vs Explicit localization in ASP.NET 2.0
A video showing how to add localization to an ASP.NET project
An extensive introduction of WPF localisation
Localizing WPF using a custom MarkupExtension