docs/latex/wx/tnoneng.tex

   1 \section{Writing non-English applications}\label{nonenglishoverview}
   2
   3 This article describes how to write applications that communicate with
   4 user in language other than English. Unfortunately many languages use
   5 different charsets under Unix and Windows (and other platforms, to make
   6 situation even more complicated). These charsets usually differ in so
   7 many characters it is impossible to use same texts under all platforms.
   8 wxWindows provide mechanism that helps you avoid distributing many
   9 identical, only differently encoded, packages with your application
  10 (e.g. help files and menu items in iso8859-13 and windows-1257). Thanks
  11 to this mechanism you can, for example, distribute only iso8859-13 data
  12 and it will be handled transparently under all systems.
  13
  14 Please read \helpref{Internationalization}{internationalization} which
  15 describes the locales concept.
  16
  17 In the following text, wherever {\it iso8859-2} and {\it windows-1250} are
  18 used, any encodings are meant and any encodings may be substituted there.
  19
  20 \wxheading{Locales}
  21
  22 The best way to ensure correctly displayed texts in a GUI across platforms
  23 is to use locales. Write your in-code messages in English or without
  24 diacritics and put real messages into the message catalog (see
  25 \helpref{Internationalization}{internationalization}).
  26
  27 A standard .po file begins with a header like this:
  28
  29 \begin{verbatim}
  30 # SOME DESCRIPTIVE TITLE.
  31 # Copyright (C) YEAR Free Software Foundation, Inc.
  32 # FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
  33 #
  34 #, fuzzy
  35 msgid ""
  36 msgstr ""
  37 "Project-Id-Version: PACKAGE VERSION\n"
  38 "POT-Creation-Date: 1999-02-19 16:03+0100\n"
  39 "PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
  40 "Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
  41 "Language-Team: LANGUAGE <LL@li.org>\n"
  42 "MIME-Version: 1.0\n"
  43 "Content-Type: text/plain; charset=CHARSET\n"
  44 "Content-Transfer-Encoding: ENCODING\n"
  45 \end{verbatim}
  46
  47 Notice these two lines:
  48
  49 \begin{verbatim}
  50 #, fuzzy
  51 "Content-Type: text/plain; charset=CHARSET\n"
  52 \end{verbatim}
  53
  54 The first tells the {\it msgfmt} compiler not to include "" (the empty string)
  55 in compiled .mo catalog. The second one specifies the charset used to write
  56 translated messages.
  57
  58 You have to do two things: fill in proper charset information and delete
  59 the {\tt fuzzy} line. Your .po file may look like this after doing so:
  60
  61 \begin{verbatim}
  62 # SOME DESCRIPTIVE TITLE.
  63 # Copyright (C) YEAR Free Software Foundation, Inc.
  64 # FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
  65 #
  66 msgid ""
  67 msgstr ""
  68 "Project-Id-Version: PACKAGE VERSION\n"
  69 "POT-Creation-Date: 1999-02-19 16:03+0100\n"
  70 "PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
  71 "Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
  72 "Language-Team: LANGUAGE <LL@li.org>\n"
  73 "MIME-Version: 1.0\n"
  74 "Content-Type: text/plain; charset=iso8859-2\n"
  75 "Content-Transfer-Encoding: ENCODING\n"
  76 \end{verbatim}
  77
  78 wxWindows is able to use this catalog under any supported platform
  79 (although iso8859-2 is a Unix encoding and is not understood by Windows).
  80
  81 How is this done? When you tell the wxLocale class to load a message catalog that
  82 contains the header (msgid ""; normal .mo catalogs do {\bf not} contain it,
  83 you must remove the line with {\it fuzzy}!), it checks the charset. If the
  84 charset is "alien" on the platform the program is currently running (e.g.
  85 any of ISO encodings under Windows or CP12XX under Unix) it uses
  86 \helpref{wxEncodingConverter::GetPlatformEquivalents}{wxencodingconvertergetplatformequivalents}
  87 to obtain an encoding that is more common on this platform and converts
  88 the message catalog to this encoding. Note that it does {\bf not} check
  89 for presence of this encoding! It only assumes that it is always better to
  90 have strings in platform native encoding than in an encoding that is rarely
  91 (if ever) used.
  92
  93 The behaviour described above is disabled by default.
  94 You must set {\it bConvertEncoding} to TRUE in
  95 \helpref{wxLocale constructor}{wxlocaledefctor} in order to enable
  96 runtime encoding conversion.
  97
  98 \wxheading{Font mapping}
  99
 100 You can use \helpref{wxEncodingConverter}{wxencodingconverter} and
 101 \helpref{wxFontMapper}{wxfontmapper} to display text:
 102
 103 \begin{verbatim}
 104 if (!wxTheFontMapper->IsEncodingAvailable(enc, facename))
 105 {
 106    wxFontEncoding alternative;
 107    if (wxTheFontMapper->GetAltForEncoding(enc, &alternative,
 108                                           facename, FALSE))
 109    {
 110        wxEncodingConverted encconv;
 111        if (!encconv.Init(enc, alternative))
 112            ...failure...
 113        else
 114            text = encconv.Convert(text);
 115    }
 116    else
 117        ...failure...
 118 }
 119 ...display text...
 120 \end{verbatim}
 121
 122 \wxheading{Converting data}
 123
 124 You may want to store all program data (created documents etc.) in
 125 the same encoding, let's say windows1250. Obviously, the best way would
 126 be to use \helpref{wxEncodingConverter}{wxencodingconverter}.
 127
 128 \wxheading{Help files}
 129
 130 If you're using \helpref{wxHtmlHelpController}{wxhtmlhelpcontroller} there is
 131 no problem at all. You must only make sure that all the HTML files contain
 132 the META tag, e.g.
 133
 134 \begin{verbatim}
 135 <meta http-equiv="Content-Type" content="text/html; charset=iso8859-2">
 136 \end{verbatim}
 137
 138 and that the hhp project file contains one additional line in the {\tt OPTIONS}
 139 section:
 140
 141 \begin{verbatim}
 142 Charset=iso8859-2
 143 \end{verbatim}
 144
 145 This additional entry tells the HTML help controller what encoding is used
 146 in contents and index tables.
 147