When taking your application to an international market, the first thing that comes to mind is translation. You will need to provide a set of translations for all the strings your application presents in each foreign language that it supports. In wxWidgets, you do this by providing message catalogs and loading them through the wxLocale class. This technique may differ from how you are used to implementing translations if you currently use string tables. Instead of referring to each string by an identifier and switching tables, message catalogs work by translating a string using an appropriate catalog. (Alternatively, you can use your own system for handling translations if you prefer, but be aware that messages in the wxWidgets library itself rely on catalogs.)

Without message catalogs, the untranslated strings in the source code will be used to display text in menus, buttons, and so on. If your own language contains non-ASCII characters, such as accents, you will need a separate “translation” (message catalog) for it because source code should only contain ASCII.

Representing text in a different language can also involve different character encodings, which means that the same byte value might represent different characters when displayed on-screen. You need to make sure that your application can correctly set up the character encodings used by your GUI elements and in your data files. You need to be aware of the specific encoding used in each case and how to translate between encodings.

Another aspect of internationalization is formatting for numbers, date, and time. Note that formatting can be different even for the same language. For example, the number represented in English by 1,234.56 is represented as 1.234,56 in Germany and as 1'234.56 in the German-speaking part of Switzerland. In the USA, the 10th of November is represented as 11/10, whereas the same date for a reader in the UK means the 11th of October. We’ll see shortly how wxWidgets can help here.

Translated strings are longer than their English counterpart, which means that the window layout must adapt to different sizes. Sizers are best suited to solve this part and are explained in Chapter 7, “Window Layout Using Sizers.” Another layout problem is that for Western languages, the flow of reading goes from left to right, but other languages such as Arabic and Hebrew are read from right to left (called RTL), which means that the entire layout must change orientation. There is currently no specific mechanism for implementing RTL layout in wxWidgets.

The last group of elements to be adapted to a different language or culture consists of images and sounds. For example, if you are writing a phone directory application, you might have a feature that speaks the numbers, which will be language-dependent, and you might want to display different images depending on the country.

wxWidgets provides facilities for message translation using the wxLocale class and is itself fully translated into several languages. Please consult the wxWidgets home page for the most up-to-date translations.

The wxWidgets approach to internationalization closely follows the GNU gettext package. wxWidgets uses message catalogs, which are binary compatible with gettext catalogs allowing you to use all the gettext tools. No additional libraries are needed during runtime because wxWidgets is able to read message catalogs.

During program development, you will need the gettext package for working with message catalogs (or poEdit; see the next section). There are two kinds of message catalog: source catalogs, which are text files with extension .po, and binary catalog which are created from the source files with the msgfmt program (part of the gettext package) and have the extension .mo. Only the binary files are needed during program execution. For each language you support, you need one message catalog.

poEdit

You don’t have to use command-line tools for maintaining your message catalogs. Vaclav Slavik has written poEdit, a graphical front-end to the gettext package available from http://www.poedit.org. poEdit, shown in Figure 16-1, helps you to maintain message catalogs, generate .mo files, and merge in changes to strings in your application code as your application changes and grows.

Figure 16-1 poEdit

There are more characters around on Earth than can fit into the 256 possible byte values that the classical 8-bit character represents. In order to be able to display more than 256 different glyphs, another layer of indirection has been added: the character encoding or character set. (The “new and improved” solution, Unicode, will be presented later in this section.)

Thus, what is represented by the byte value 161 is determined by the character set. In the ISO 8859-1 (Latin-1) character set, this is ¡—an inverted exclamation mark. In ISO 8859-2 (Latin-2), it represents a ¥ (Aogonek).

When you are drawing text on a window, the system must know about the encoding used. This is called the “font encoding,” although it is just an indication of a character set. Creating a font without indicating the character set means “use the default encoding.” This is fine in most situations because the user is normally using the system in his or her language.

But if you know that something is in a different encoding, such as ISO 8859-2, then you need to create the appropriate font. For example:

Otherwise, it will not be displayed properly on a western system, such as ISO 8859-1.

Note that there may be situations where an optimal encoding is not available. In these cases, you can try to use an alternative encoding, and if one is available, you must convert the text into this encoding. The following snippet shows this sequence: a string text in the encoding enc should be shown in the font facename. The use of wxCSConv will be explained shortly.

The current locale is also used for formatting numbers and dates. The printf-based formatting in wxString takes care of this automatically. Consider this snippet:

Here, Format uses the correct decimal separator. And for date formatting:

Format presents the current date and time in the correct language and format. Have a look at the API documentation to see all the possibilities for passing a format description to the Format call—just don’t forget that you will probably have to translate this format string as well for using it in a different language because the sequence for different parts of the date can differ among languages.

If you want to add the correct thousands separator or just want to know the correct character for the decimal point, you can ask the locale object for the corresponding strings using the GetInfo method:

You can also load other data such as images and sounds depending on the locale. You can use the same mechanism as for text, for example:

This code will cause flag.png to appear on your list of strings to translate, so you just translate the string flag.png into the appropriate file name for your platform, for example de/flag.png. Make sure that the translated versions are also available as true files in your application, or you can load them from a compressed archive (refer to Chapter 14, “Files and Streams”).

To illustrate some of the concepts that we’ve covered, you can find a little sample in examples/chap16 on the CD-ROM. It shows some strings and a flag graphic for three languages: English, French, and German. You can change the language from the File menu, which will change the menu strings, the wxStaticText strings, and the flag graphic to suit the newly selected language. To demonstrate the different behavior of _( ) and wxT( ), the menu help in the status line remains in English.

Figure 16-2 The internationalization samples

The sample’s application class contains a wxLocale pointer and a function SelectLanguage that will re-create the locale object with the appropriate language. This is the application class declaration and implementation:

There are two functions of particular interest in the frame class: SetupStrings and OnChangeLanguage. SetupStrings sets the labels and re-creates the menu bar, using translations for all the strings apart from the menu help strings, as follows:

OnChangeLanguage is called when the user wants to specify a new language, and it maps the user’s selection into a locale identifier such as wxLANGUAGE_GERMAN. This identifier is passed to MyApp::SelectLanguage before SetupStrings is called to change the labels and flag bitmap. Here is the implementation of OnChangeLanguage:

We’ve discussed the variety of ways in which wxWidgets helps you handle translations as well as formatting issues related to time and date, currency, and so on. You should work with someone familiar with the target languages or locales who will be able to find differences that you might have missed.

For another example of a translated application, see samples/internat in your wxWidgets distribution. It demonstrates translation of strings in menu items and dialogs for ten languages.

Next, we’ll take a look at how you can make your applications perform several tasks at once with multithreading.