Internationalizing Desktop App within a couple years… What should we do now?

Question

So we are sure that we will be taking our product internationally and will eventually need to internationalize it. How much internationalizing would you recommend we do as w

Answer 1

Prepare it now, before you write all the strings in the codebase itself.

Everything after now will be too late. It's now or never!

It's true that it is a bit of extra effort to prepare well now, but not doing it will end up being a lot more expensive.

If you won't follow all the guidelines in the links below, at least heed points 1,2 and 7 of the summary which are very cheap to do now and which cause the most pain afterwards in my experience.

Check these guidelines and see for yourself why it's better to start now and get everything prepared.

1. Developing world ready applications

2. Best practices for developing world ready applications

Little extract:

1. 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. (Moving the resources to a DLL afterwards will be a pain)
2. Do not hardcode strings or user interface resources. (If you don't prepare, you know you will hardcode strings)
3. Do not put nonlocalizable resources into the resource-only DLLs. This causes confusion for translators.
4. 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. (After the interface design, changing phrases gets harder)
5. Avoid ambiguous constructs such as "Empty Folder" where the strings can be translated differently depending on the grammatical roles of the strings' components. For example, "empty" can be either a verb or an adjective, and this can lead to different translations in languages such as Italian or French. (Same issue)
6. Avoid using images and icons that contain text in your application. They are expensive to localize. (Use text rendered over the image)
7. 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. (Same issue, if you don't plan for it now, redesign is more expensive)
8. Use the System.Resources.ResourceManager class to retrieve resources based on culture.
9. Use Microsoft Visual Studio .NET to create Windows Forms dialog boxes, so they can be localized using the Windows Forms Resource Editor (Winres.exe). Do not code Windows Forms dialog boxes by hand.

Answer 2

Internationalization will let your product be usable in other countries, it's easy and should be done from the start (this way English speaking people all over the world can use your software), those 3 rules will get you most of the way there:

1. Support international characters - use only Unicode data types in files and databases.
2. Support international date, time and number formats - use CultureInfo.InvariantCulture when storing data to file or computer readable storage, use CultureInfo.CurrentCulture when displaying data or parsing user input, never do your own parsing, never use any other culture objects.
3. textual data entered by the user should be considered a black box, don't try to break it up into words or letters, especially when displaying it to the user - different languages have diffract rules and the OS knows how to display left-to-right text, you don't.

Localization is translating the software into different languages, this is difficult and expensive, a good start is to never hard code strings and never build sentences out of smaller strings.

Answer 3

You could use NGettext.Wpf (it can be installed from NuGet, and yes I am the author, but I made it out of the frustrations listed in the other answers).

It is hosted this github repository, and here is the getting started section at the time of writing:

NGettext.Wpf is intended to work with dependency injection. You need to call the following at the entry point of your application:

NGettext.Wpf.CompositionRoot.Compose("ExampleDomainName");

The "ExampleDomainName" string is the domain name. This means that when the current culture is set to "da-DK" translations will be loaded from "Locale\da-DK\LC_MESSAGES\ExampleDomainName.mo" relative to where your WPF app is running (You must include the .mo files in your application and make sure they are copied to the output directory).

Now you can do something like this in XAML:

<Button CommandParameter="en-US" 
        Command="{StaticResource ChangeCultureCommand}" 
        Content="{wpf:Gettext English}" />

Which demonstrates two features of this library. The most important is the Gettext markup extension which will make sure the Content is set to the translation of "English" with respect to the current culture, and update it when the current culture is changed. The other feature it demonstrates is the ChangeCultureCommand which changes the current culture to the given culture, in this case "en-US".

I also highly recommend reading Preparing Strings from the gettext utilities manual.

Answer 4

If you use test data, use non-English (e.g.: Russian, Polish, Norwegian etc) strings. Encoding peeks it's little ugly head at every corner. If not in your own libraries, then in external ones.

I personally favor Russian because although I don't speak a word Russian (despite my name's origin) it has foreign chars in it and it takes way more space then English and therefor tests your spacing too.
Don't know if that is something language specific, or just because our Russian translator likes verbose strings.

Answer 5

I will add to store and manipulate string data as Unicode (NVARCHAR in MS SQL).

Answer 6

Some questions to think about…

How match can you afford to delay the shipment of the English version of your application to save a bit of cost internationalize later?

Will you still be trading if you don’t get the cash flow from shipping the English version quickly?

How will you get the UI right, if you don’t get feedback quickly from some customers about it?

How often will you rewrite the UI before you have to internationalize it?

Do you English customers wish to be able to customize strings in the UI, e.g. not everyone calls a “shipping note” the same think.

As a large part of the pain of internationalize is making sure you don’t break the English version, is automated system testing of the UI a better investment?

The only thing I think I will always do is: “Do not use composite strings that are built at run time from concatenated phrases” and if you do so, don’t spread the code that builds up the a single string over lots of methods.

Having your UI automatically resize (and layout) to cope with length of labels etc will save you lots of time over the years if you can do it cheaply. There a lots of 3rd party control sets for Windows Forms that lets you label text boxes etc without having to put the labels on as separate controls.

I just starting to internationalize a WinForms application, we hope to mostly be able to use the “name” of each control as the lookup key, without having to move lots into resource files etc. It is not always as hard as you think at first….