wxXXChoiceDialog documentation fixes

[wxWidgets.git] / docs / latex / wx / tnoneng.tex

diff --git a/docs/latex/wx/tnoneng.tex b/docs/latex/wx/tnoneng.tex
index d1c5d65249537959244fc2e36166ff7ee25b11c4..8855a73cad4387a17676907842f14a9ad515ae8c 100644 (file)
--- a/docs/latex/wx/tnoneng.tex
+++ b/docs/latex/wx/tnoneng.tex
@@ -6,7 +6,7 @@ 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 library provides mechanism that helps you avoid distributing many
+wxWidgets library provides 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 
@@ -44,7 +44,7 @@ msgstr ""
 "Content-Transfer-Encoding: ENCODING\n"
 \end{verbatim}
 
-Notice this particular line:
+Note this particular line:
 
 \begin{verbatim}
 "Content-Type: text/plain; charset=CHARSET\n"
@@ -75,46 +75,60 @@ msgstr ""
 
 (Make sure that the header is {\bf not} marked as {\it fuzzy}.)
 
-wxWindows is able to use this catalog under any supported platform
+wxWidgets is able to use this catalog under any supported platform
 (although iso8859-2 is a Unix encoding and is normally not understood by
 Windows).
 
 How is this done? When you tell the wxLocale class to load a message catalog that
-contains correct header, 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 
-\helpref{wxEncodingConverter::GetPlatformEquivalents}{wxencodingconvertergetplatformequivalents}
-to obtain an encoding that is more common on this platform and converts
-the message catalog to this encoding. Note that it does {\bf not} check
-for presence of fonts in the "platform" 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 {\it bConvertEncoding} to TRUE in 
-\helpref{wxLocale constructor}{wxlocaledefctor} in order to enable
-runtime encoding conversion.
+contains correct header, it checks the charset. The catalog is then converted
+to the charset used (see
+\helpref{wxLocale::GetSystemEncoding}{wxlocalegetsystemencoding} and
+\helpref{wxLocale::GetSystemEncodingName}{wxlocalegetsystemencodingname}) by
+user's operating system. This is default behaviour of the
+\helpref{wxLocale}{wxlocale} class; you can disable it by {\bf not} passing
+{\tt wxLOCALE\_CONV\_ENCODING} to \helpref{wxLocale::Init}{wxlocaleinit}.
+
+\wxheading{Non-English strings or 8-bit characters in the source code}
+
+By convention, you should only use characters without diacritics (i.e. 7-bit
+ASCII strings) for msgids in the source code and write them in English.
+
+If you port software to wxWindows, you may be confronted with legacy source
+code containing non-English string literals. Instead of translating the strings
+in the source code to English and putting the original strings into message
+catalog, you may configure wxWidgets to use non-English msgids and translate to
+English using message catalogs:
+
+\begin{enumerate}
+\item{If you use the program {\tt xgettext} to extract the strings from
+the source code, specify the option {\tt --from-code=<source code charset>}.}
+\item{Specify the source code language and charset as arguments to
+\helpref{wxLocale::AddCatalog}{wxlocaleaddcatalog}. For example:
+\begin{verbatim}
+locale.AddCatalog(_T("myapp"),
+                  wxLANGUAGE_GERMAN, _T("iso-8859-1"));
+\end{verbatim}
+}
+\end{enumerate}
 
 \wxheading{Font mapping}
 
-You can use \helpref{wxEncodingConverter}{wxencodingconverter} and 
+You can use \helpref{wxMBConv classes}{mbconvclasses} and 
 \helpref{wxFontMapper}{wxfontmapper} to display text:
 
 \begin{verbatim}
-if (!wxTheFontMapper->IsEncodingAvailable(enc, facename))
+if (!wxFontMapper::Get()->IsEncodingAvailable(enc, facename))
 {
    wxFontEncoding alternative;
-   if (wxTheFontMapper->GetAltForEncoding(enc, &alternative, 
-                                          facename, FALSE))
+   if (wxFontMapper::Get()->GetAltForEncoding(enc, &alternative,
+                                              facename, false))
    {
-       wxEncodingConverted encconv;
-       if (!encconv.Init(enc, alternative))
-           ...failure...
-       else
-           text = encconv.Convert(text);
+       wxCSConv convFrom(wxFontMapper::Get()->GetEncodingName(enc));
+       wxCSConv convTo(wxFontMapper::Get()->GetEncodingName(alternative));
+       text = wxString(text.mb_str(convFrom), convTo);
    }
    else
-       ...failure...
+       ...failure (or we may try iso8859-1/7bit ASCII)...
 }
 ...display text...
 \end{verbatim}
@@ -122,8 +136,10 @@ if (!wxTheFontMapper->IsEncodingAvailable(enc, facename))
 \wxheading{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 \helpref{wxEncodingConverter}{wxencodingconverter}.
+the same encoding, let's say {\tt utf-8}. You can use
+\helpref{wxCSConv}{wxcsconv} class to convert data to encoding used by the
+system your application is running on (see
+\helpref{wxLocale::GetSystemEncoding}{wxlocalegetsystemencoding}).
 
 \wxheading{Help files}