]> git.saurik.com Git - wxWidgets.git/blobdiff - docs/latex/wx/tnoneng.tex
Avoid missing ref
[wxWidgets.git] / docs / latex / wx / tnoneng.tex
index 1ea38c589a4b8ea762f27e7b832993c709214fa7..56e9147833d6789ef6cbf51dc910c727a7084538 100644 (file)
 \section{Writing non-English applications}\label{nonenglishoverview}
 
 This article describes how to write applications that communicate with
 \section{Writing non-English applications}\label{nonenglishoverview}
 
 This article describes how to write applications that communicate with
-user in language other than English. Unfortunately many languages use
+the user in a language other than English. Unfortunately many languages use
 different charsets under Unix and Windows (and other platforms, to make
 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
+the situation even more complicated). These charsets usually differ in so
+many characters that it is impossible to use the same texts under all
+platforms.
+
+The wxWidgets library provides a 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
 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 distribute only let's say iso8859-13 data 
+to this mechanism you can, for example, distribute only iso8859-13 data 
 and it will be handled transparently under all systems.
 
 and it will be handled transparently under all systems.
 
-Please read \helpref{Internationalization}\label{internationalization} which
-describes locales concept.
+Please read \helpref{Internationalization}{internationalization} which
+describes the locales concept.
 
 
-Whereever in the following text {\it iso8859-2} and {\it windows-1250} are
+In the following text, wherever {\it iso8859-2} and {\it windows-1250} are
 used, any encodings are meant and any encodings may be substituted there.
 
 used, any encodings are meant and any encodings may be substituted there.
 
-
 \wxheading{Locales}
 
 \wxheading{Locales}
 
-TODO
+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 
+\helpref{Internationalization}{internationalization}).
 
 
-\wxheading{Converting data}
+A standard .po file begins with a header like this:
+
+\begin{verbatim}
+# 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=CHARSET\n"
+"Content-Transfer-Encoding: ENCODING\n"
+\end{verbatim}
 
 
-before storing / after loading
+Note this particular line:
 
 
-TODO
+\begin{verbatim}
+"Content-Type: text/plain; charset=CHARSET\n"
+\end{verbatim}
+
+It specifies the charset used by the catalog. All strings in the catalog
+are encoded using this charset.
+
+You have to fill in proper charset information. Your .po file may look like this
+after doing so: 
+
+\begin{verbatim}
+# 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: 8bit\n"
+\end{verbatim}
+
+(Make sure that the header is {\bf not} marked as {\it fuzzy}.)
+
+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 a 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
+the user's operating system. This is the 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}
 
 
 \wxheading{Font mapping}
 
-TODO
+You can use \helpref{wxMBConv classes}{mbconvclasses} and 
+\helpref{wxFontMapper}{wxfontmapper} to display text:
+
+\begin{verbatim}
+if (!wxFontMapper::Get()->IsEncodingAvailable(enc, facename))
+{
+   wxFontEncoding alternative;
+   if (wxFontMapper::Get()->GetAltForEncoding(enc, &alternative,
+                                              facename, false))
+   {
+       wxCSConv convFrom(wxFontMapper::Get()->GetEncodingName(enc));
+       wxCSConv convTo(wxFontMapper::Get()->GetEncodingName(alternative));
+       text = wxString(text.mb_str(convFrom), convTo);
+   }
+   else
+       ...failure (or we may try iso8859-1/7bit ASCII)...
+}
+...display text...
+\end{verbatim}
+
+\wxheading{Converting data}
+
+You may want to store all program data (created documents etc.) in
+the same encoding, let's say {\tt utf-8}. You can use
+\helpref{wxCSConv}{wxcsconv} class to convert data to the encoding used by the
+system your application is running on (see
+\helpref{wxLocale::GetSystemEncoding}{wxlocalegetsystemencoding}).
 
 \wxheading{Help files}
 
 If you're using \helpref{wxHtmlHelpController}{wxhtmlhelpcontroller} there is
 
 \wxheading{Help files}
 
 If you're using \helpref{wxHtmlHelpController}{wxhtmlhelpcontroller} there is
-no problem at all. You must only make sure that all HTML files contain
-META tag, e.g.
+no problem at all. You only need to make sure that all the HTML files contain
+the META tag, e.g.
 
 \begin{verbatim}
 
 \begin{verbatim}
-<meta http-equiv="Content-Type" content="iso8859-2">
+<meta http-equiv="Content-Type" content="text/html; charset=iso8859-2">
 \end{verbatim}
 
 \end{verbatim}
 
-and that hhp project file contains one additional line in {\tt OPTIONS}
+and that the hhp project file contains one additional line in the {\tt OPTIONS}
 section:
 
 \begin{verbatim}
 Charset=iso8859-2
 \end{verbatim}
 
 section:
 
 \begin{verbatim}
 Charset=iso8859-2
 \end{verbatim}
 
-This additional entry tells HTML help controller what encoding is used
+This additional entry tells the HTML help controller what encoding is used
 in contents and index tables.
 in contents and index tables.
+