## Writing non-English applications

This article describes how to write applications that communicate with user in language other than English. Unfortunately many languages use different charsets under Unix and Windows (and other platforms, to make situation even more complicated). These charsets usually differ in so many characters it is impossible to use same texts under all platforms. wxWindows provide mechanism that helps you avoid distributing many identical, only differently encoded, packages with your application (e.g. help files and menu items in iso8859-13 and windows-1257). Thanks to this mechanism you can, for example, distribute only iso8859-13 data and it will be handled transparently under all systems.

Please read Internationalization which describes the locales concept.

In the following text, wherever iso8859-2 and windows-1250 are used, any encodings are meant and any encodings may be substituted there.

Locales

The best way to ensure correctly displayed texts in a GUI across platforms is to use locales. Write your in-code messages in English or without diacritics and put real messages into the message catalog (see Internationalization).

A standard .po file begins with a header like this:

    # SOME DESCRIPTIVE TITLE.
    # Copyright (C) YEAR Free Software Foundation, Inc.
    # FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
    #
    #, fuzzy
    msgid ""
    msgstr ""
    "Project-Id-Version: PACKAGE VERSION\n"
    "POT-Creation-Date: 1999-02-19 16:03+0100\n"
    "PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
    "Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
    "Language-Team: LANGUAGE <LL@li.org>\n"
    "MIME-Version: 1.0\n"
    "Content-Type: text/plain; charset=CHARSET\n"
    "Content-Transfer-Encoding: ENCODING\n"

Notice these two lines:

    #, fuzzy
    "Content-Type: text/plain; charset=CHARSET\n"

The first tells the msgfmt compiler not to include "" (the empty string) in compiled .mo catalog. The second one specifies the charset used to write translated messages.

You have to do two things: fill in proper charset information and delete the `fuzzy` line. Your .po file may look like this after doing so:

    # SOME DESCRIPTIVE TITLE.
    # Copyright (C) YEAR Free Software Foundation, Inc.
    # FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
    #
    msgid ""
    msgstr ""
    "Project-Id-Version: PACKAGE VERSION\n"
    "POT-Creation-Date: 1999-02-19 16:03+0100\n"
    "PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
    "Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
    "Language-Team: LANGUAGE <LL@li.org>\n"
    "MIME-Version: 1.0\n"
    "Content-Type: text/plain; charset=iso8859-2\n"
    "Content-Transfer-Encoding: ENCODING\n"

wxWindows is able to use this catalog under any supported platform (although iso8859-2 is a Unix encoding and is not understood by Windows).

How is this done? When you tell the wxLocale class to load a message catalog that contains the header (msgid ""; normal .mo catalogs do not contain it, you must remove the line with fuzzy!), it checks the charset. If the charset is "alien" on the platform the program is currently running (e.g. any of ISO encodings under Windows or CP12XX under Unix) it uses wxEncodingConverter::GetPlatformEquivalents to obtain an encoding that is more common on this platform and converts the message catalog to this encoding. Note that it does not check for presence of this encoding! It only assumes that it is always better to have strings in platform native encoding than in an encoding that is rarely (if ever) used.

The behaviour described above is disabled by default. You must set bConvertEncoding to TRUE in wxLocale constructor in order to enable runtime encoding conversion.

Font mapping

You can use wxEncodingConverter and wxFontMapper to display text:

    if (!wxTheFontMapper->IsEncodingAvailable(enc, facename))
    {
       wxFontEncoding alternative;
       if (wxTheFontMapper->GetAltForEncoding(enc, &alternative,
                                              facename, FALSE))
       {
           wxEncodingConverted encconv;
           if (!encconv.Init(enc, alternative))
               ...failure...
           else
               text = encconv.Convert(text);
       }
       else
           ...failure...
    }
    ...display text...

Converting data

You may want to store all program data (created documents etc.) in the same encoding, let's say windows1250. Obviously, the best way would be to use wxEncodingConverter.

Help files

If you're using wxHtmlHelpController there is no problem at all. You must only make sure that all the HTML files contain the META tag, e.g.

    <meta http-equiv="Content-Type" content="iso8859-2">

and that the hhp project file contains one additional line in the `OPTIONS` section:

    Charset=iso8859-2

This additional entry tells the HTML help controller what encoding is used in contents and index tables.