]> git.saurik.com Git - wxWidgets.git/blob - docs/doxygen/overviews/nonenglish.h
For wxGTK2, link with X11 explicitly, since we use many X11 functions directly.
[wxWidgets.git] / docs / doxygen / overviews / nonenglish.h
1 /////////////////////////////////////////////////////////////////////////////
2 // Name: nonenglish.h
3 // Purpose: topic overview
4 // Author: wxWidgets team
5 // RCS-ID: $Id$
6 // Licence: wxWindows licence
7 /////////////////////////////////////////////////////////////////////////////
8
9 /**
10
11 @page overview_nonenglish Writing Non-English Applications
12
13
14 @li @ref overview_nonenglish_locales
15 @li @ref overview_nonenglish_strings
16 @li @ref overview_nonenglish_fontmapping
17 @li @ref overview_nonenglish_converting
18 @li @ref overview_nonenglish_help
19
20
21 <hr>
22
23
24 This article describes how to write applications that communicate with the user
25 in a language other than English. Unfortunately many languages use different
26 charsets under Unix and Windows (and other platforms, to make the situation
27 even more complicated). These charsets usually differ in so many characters
28 that it is impossible to use the same texts under all platforms.
29
30 The wxWidgets library provides a mechanism that helps you avoid distributing
31 many identical, only differently encoded, packages with your application (e.g.
32 help files and menu items in iso8859-13 and windows-1257). Thanks to this
33 mechanism you can, for example, distribute only iso8859-13 data and it will be
34 handled transparently under all systems.
35
36 Please read the @ref overview_i18n which describes the locales concept.
37
38 In the following text, wherever @e iso8859-2 and @e windows-1250 are used, any
39 encodings are meant and any encodings may be substituted there.
40
41
42 @section overview_nonenglish_locales Locales
43
44 The best way to ensure correctly displayed texts in a GUI across platforms is
45 to use locales. Write your in-code messages in English or without diacritics
46 and put real messages into the message catalog (see @ref overview_i18n).
47
48 A standard .po file begins with a header like this:
49
50 @code
51 # SOME DESCRIPTIVE TITLE.
52 # Copyright (C) YEAR Free Software Foundation, Inc.
53 # FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
54 #
55 msgid ""
56 msgstr ""
57 "Project-Id-Version: PACKAGE VERSION\n"
58 "POT-Creation-Date: 1999-02-19 16:03+0100\n"
59 "PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
60 "Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
61 "Language-Team: LANGUAGE <LL@li.org>\n"
62 "MIME-Version: 1.0\n"
63 "Content-Type: text/plain; charset=CHARSET\n"
64 "Content-Transfer-Encoding: ENCODING\n"
65 @endcode
66
67 Note this particular line:
68
69 @code
70 "Content-Type: text/plain; charset=CHARSET\n"
71 @endcode
72
73 It specifies the charset used by the catalog. All strings in the catalog are
74 encoded using this charset.
75
76 You have to fill in proper charset information. Your .po file may look like
77 this after doing so:
78
79 @code
80 # SOME DESCRIPTIVE TITLE.
81 # Copyright (C) YEAR Free Software Foundation, Inc.
82 # FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
83 #
84 msgid ""
85 msgstr ""
86 "Project-Id-Version: PACKAGE VERSION\n"
87 "POT-Creation-Date: 1999-02-19 16:03+0100\n"
88 "PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
89 "Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
90 "Language-Team: LANGUAGE <LL@li.org>\n"
91 "MIME-Version: 1.0\n"
92 "Content-Type: text/plain; charset=iso8859-2\n"
93 "Content-Transfer-Encoding: 8bit\n"
94 @endcode
95
96 (Make sure that the header is @b not marked as @e fuzzy.)
97
98 wxWidgets is able to use this catalog under any supported platform
99 (although iso8859-2 is a Unix encoding and is normally not understood by
100 Windows).
101
102 How is this done? When you tell the wxLocale class to load a message catalog
103 that contains a correct header, it checks the charset. The catalog is then
104 converted to the charset used (see wxLocale::GetSystemEncoding and
105 wxLocale::GetSystemEncodingName) by the user's operating system.
106
107
108 @section overview_nonenglish_strings Non-English Strings or 8-bit Characters in Source
109
110 By convention, you should only use characters without diacritics (i.e. 7-bit
111 ASCII strings) for msgids in the source code and write them in English.
112
113 If you port software to wxWindows, you may be confronted with legacy source
114 code containing non-English string literals. Instead of translating the strings
115 in the source code to English and putting the original strings into message
116 catalog, you may configure wxWidgets to use non-English msgids and translate to
117 English using message catalogs:
118
119 @li If you use the program @c xgettext to extract the strings from the source
120 code, specify the option <tt>--from-code=@<source code charset@></tt>.
121 @li Specify the source code language and charset as arguments to
122 wxLocale::AddCatalog. For example:
123 @code
124 locale.AddCatalog(wxT("myapp"), wxLANGUAGE_GERMAN, wxT("iso-8859-1"));
125 @endcode
126
127
128 @section overview_nonenglish_fontmapping Font Mapping
129
130 You can use @ref overview_mbconv and wxFontMapper to display text:
131
132 @code
133 if (!wxFontMapper::Get()->IsEncodingAvailable(enc, facename))
134 {
135 wxFontEncoding alternative;
136 if (wxFontMapper::Get()->GetAltForEncoding(enc, &alternative,
137 facename, false))
138 {
139 wxCSConv convFrom(wxFontMapper::Get()->GetEncodingName(enc));
140 wxCSConv convTo(wxFontMapper::Get()->GetEncodingName(alternative));
141 text = wxString(text.mb_str(convFrom), convTo);
142 }
143 else
144 ...failure (or we may try iso8859-1/7bit ASCII)...
145 }
146 ...display text...
147 @endcode
148
149
150 @section overview_nonenglish_converting Converting Data
151
152 You may want to store all program data (created documents etc.) in the same
153 encoding, let's say @c utf-8. You can use wxCSConv to convert data to the
154 encoding used by the system your application is running on (see
155 wxLocale::GetSystemEncoding).
156
157
158 @section overview_nonenglish_help Help Files
159
160 If you're using wxHtmlHelpController there is no problem at all. You only need
161 to make sure that all the HTML files contain the META tag:
162
163 @code
164 <meta http-equiv="Content-Type" content="text/html; charset=iso8859-2">
165 @endcode
166
167 Also, the hhp project file needs one additional line in the @c OPTIONS section:
168
169 @code
170 Charset=iso8859-2
171 @endcode
172
173 This additional entry tells the HTML help controller what encoding is used in
174 contents and index tables.
175
176 */
177