RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


Localize Your .NET Windows Forms Apps

It's a small world. For the price of a nice pair of shoes, you can get on a plane, have dinner, watch a movie, sleep a few hours, and wake up on another continent. Your software can travel even more easily. When it gets there, will it be ready to go to work?

ou never know when your software might be used by people who speak different languages. In a multinational company, branch offices need to share database applications. By localizing your product, you can enormously increase its potential market. In addition, letting people work in the language in which they're most comfortable increases productivity, reduces errors, and shows respect for their culture.

But how do you make it so? The .NET documentation recommends that you use resource files. Behind each form, there's a .res file that can be used to store the strings that appear on the form, where you can put corresponding translations into other languages. The following excerpt from the .NET documentation describes how you use them:

"You can localize your application's resources for specific cultures. This allows you to build localized (translated) versions of your applications. An application loads the appropriate localized resources based on the value of the CultureInfo.CurrentUI-Culture property. This value is set either explicitly in the application's code or by the common language runtime based on the locale for the current user on the local computer."
In a nutshell, Microsoft recommends that you create satellite assemblies of resource files, one per culture. Setting or changing the CurrentUICulture setting changes the satellite assembly, and your translations appear.

Unfortunately, that's not always the best way to do it. Resource files make more sense in ASP.NET. But in the case of Windows Forms applications, if you use resource files, you have to make any required changes to them, which means that:

  • You're responsible for the translations; if your users don't like your choice of terms, it's a technical support issue;
  • Different countries that speak the same language use different words for the same thing; computadora, ordenador and PC are three Spanish translations for "computer";
  • Users have to wait for a new res file in order to get their screens fixed.
I appreciate Microsoft's efforts; especially since localization has been one of my favorite topics for many years (I speak five languages, and worked my way through grad school as a simultaneous interpreter.) However, the res file approach doesn't really put responsibility for the maintenance of the translated captions in the hands of the users, where it belongs.

This article will demonstrate a simpler mechanism for creating localized apps. I'll show you how to build a class that stores all translatable captions from screen and menu objects in a collection within each screen. When the user changes the screen language using a "Language" combobox on a screen, the SelectedIndexChanged event code looks up and replaces the original captions with their translations. Finally, I'll show you how to provide a Translation Table Manager to let users provide translations for all captions harvested from the screens in the application. The examples in this article are in Visual Basic .NET, but the downloadable source code is available in C# as well.

Close Icon
Thanks for your registration, follow us on our social networks to keep up-to-date