views:

12758

answers:

5

I've been looking into making applications suitable for multiple languages in C# since I need to work on a small project where this is the case. I have found basically two ways to do this:

Set a form's Localizable property to true, set the Language property, fill all the labels and such, and you're 'done'. The major drawback I see in this is: how to make other stuff which is not part of a form ready for multiple languages (e.g. pop-up windows, log files or windows, etc).

Create a resource file, for example 'Lang.en-us.resx' and one for every language, for example 'Lang.nl-nl.resx' and fill it up with Strings. The IDE seems to generate a class for me automatically, so in the code I can just use Lang.SomeText. The biggest drawback I see in this is: for every form I need to set all the labels and other captions myself in the code (and it doesn't seem data binding works with these resources).

I'm sure, however, that there are other methods to do this as well.

So, what is the best practice? What's the easiest for small applications (a few forms, database connection etc) and what scales best for larger applications?

+4  A: 

I have always used resource files for multi-language applications.
The are many articles on the web explaining how to use them.

I have used two different ways:

  • A resource file per form
  • A global resource file

The resource file / form, is easier to implement, you only need to enter the values in the resource file, but I find this approach harder to maintain, since the labels are dispersed throughout the application.

The global resource file allows you to centralise all the labels (images etc.) in one file (per language), but it means manually setting the labels in the form load. This file can also be used for error messages etc.

A question of taste...

One last point, I write programs in English and French, I use "en" and "fr" and not "en-US" and "fr-FR". Do not complicate things, the different dilelects of English (American, English, Australian etc) have few enough differences to use only one (the same goes for French).

ThatBloke
You have to worry about dialects sometimes. For instance the Chinese characters are completely different in Traditional Chinese (Taiwan) versus Simplified Chinese (mainland China).
MarkJ
+2  A: 

I recently wrote a program with both German and English language support. I was surprised to find out that if I simply named my english resources LanguageResources.resx and my German resources LanguageResources.de.resx, it automatically selected the correct language. The ResXFileCodeGenerator took care of it all for me.

Note that the fields in the two files were the same and any not yet entered German fields would show up in the application as English as the most non specific file language wise is the default file. When looking for a string it goes from most specific (ex .de-DE.resx) to most specific (ex. .resx).

To get at your strings use the ResourceManager.GetString or ResourceManager.GetObject calls. The application should give you the ResourceManager for free.

Rick Minerich
+1  A: 

See following for step by step implementation of localization for windows app:

http://www.techbrij.com/191/windows-form-localization-in-net

Brij
A: 

At the moment I am using this simple approach (it is not thread-safe, but it shows the basic idea). To get "Hello" in the current language, call Translations.Hello(). Other terms can be added to the class in the same way.

public class Translations
{
    private static string _es;
    private static string _en;

    public enum Languages
    {
        English,
        Español
    }

    public static Languages Language = Languages.English;

    public static string Hello()
    {
        _en = "Hello"; _es = "Hola";
        return Text();
    }

    private static string Text()
    {
        if (Language == Languages.English && !String.IsNullOrEmpty(_en))
            return _en;

        if (Language == Languages.Español && !String.IsNullOrEmpty(_es))
            return _es;

        return "No translation";
    }
}
Maarten Nieber
Wow, that would definitively become really fast a huge nightmare to manage. Moreover, there is all the concept of resources in .Net that are build for that, why reinvent the wheel?
Gimly