// Purpose: topic overview
// Author: wxWidgets team
// RCS-ID: $Id$
-// Licence: wxWindows license
+// Licence: wxWindows licence
/////////////////////////////////////////////////////////////////////////////
-/*!
+/**
@page overview_nonenglish Writing Non-English Applications
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 wxLocale::GetSystemEncoding and
-wxLocale::GetSystemEncodingName) by the user's operating system. This is the
-default behaviour of the wxLocale class; you can disable it by @b not passing
-@c wxLOCALE_CONV_ENCODING to wxLocale::Init.
+wxLocale::GetSystemEncodingName) by the user's operating system.
@section overview_nonenglish_strings Non-English Strings or 8-bit Characters in Source
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
+If you port software to wxWidgets, 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
@li Specify the source code language and charset as arguments to
wxLocale::AddCatalog. For example:
@code
- locale.AddCatalog(_T("myapp"), wxLANGUAGE_GERMAN, _T("iso-8859-1"));
+ locale.AddCatalog(wxT("myapp"), wxLANGUAGE_GERMAN, wxT("iso-8859-1"));
@endcode