[wxPython] Re: wxpython-users digest, Vol 1 #74 - 7 msgs

I am new to wxPython, and I would like to start building applications with

So am I

and I require the ability to display the GUI using various languages:

So do I

Does anyone have experience with using multiple languages with wxPython,

Don't think it is possible on win32 yet.

I will post a summary of responses to this list; please email me directly or

Seems evident

Here's a summary of what I found out after a weekend of "research".
I'll mainly focus on win32 here as this is where I tried out everything.
I hope someone does it for Unix too!?
I guess the picture is not complete.
I hope more knowledgable people will be so kind
to fill the gaps/correct my misunderstandings.
(these things I'm not sure of are marked with an astrix at the line start).

From Python 1.6 onwards there's the Unicode support.

Unicode allows you to represent special character in the source code.
There's the unicode type (a kind of string) build in and
easy to use conversion methods from this type to an ordinary string
and unicode string operation (even with ordinary strings as operand).
This conversion is done through codecs.
The standard codecs I know about are:
- ASCII: only characters representable through 7 bits are converted from the
unicode string
- Latin-1: only character representable through 8 bits are converted from
the unicode string
- UTF-8: a unicode character is represented through several bytes (from 1 to
?3? bytes)
e.g. u'\u304b' becomes '\xE3\x81\x8B'
- UTF-16: a unicode character is represented through 16 bits (there's an
endian issue here!)
e.g. u'\u304b' becomes '\x48\x30' or '\x30\x48' depending on endianess.
Some people made other codecs so you might find something for Hebrew, ...
e.g. I found and successfully used a Japanse codec from
http://pseudo.grad.sccs.chukyo-u.ac.jp/~kajiyama/python/
With I could read files I edited with emacs' MULE system.

On the win32 (m$ nt X.Y) the underlying string representation is unicode.
Note that win32s (m$ 9X/ Me ...) has only very, very limited support for
unicode.
E.g. Imagine one does a call to the CreateWindow(...) API.
Depending on the global macro's UNICODE and _UNICODE
this gets translated to an actual call to
- CreateWindowW(...): the real unicode version
(revealing the "special" characters depends on the font you use)
- CreateWindowA(...): the ascii version.
First all the "char*" parameters are converted to "unsigned short*" ones and
at the end CreateWindowW(...) is called.

ActiveState python 2.1 I tested does not seem to have
UNICODE and _UNICODE defined while compiling their binaries.
Logical otherwise it would not run on m$ win98 for instance.
It also means that you are not able to access the CreateWindowW()
through their win32 extentions even though
you specify the string parameters as unicode strings.
You are only able to show the ordinary ASCII characters correctly.

One is able to compile the wxWindows 2.2.5 library on win32 with Unicode
support.
Therefor you have to change the following macros in the msw\setup.h file:
- wxUSE_UNICODE: a wxChar type will be a wchar_t (otherwise it would be
just a char)
This wchar_t (a 16 bit type) supports win32's underlying UNICODE system
directly.
A wx program using this will only run on m$ nt (as explained higher) only.
- wxUSE_WCHAR_T: necessary for wxUSE_UNICODE
* According to a comment you can setup wxUSE_WCHAR_T
* only for limited unicode support.
* You program will run on win32s too.
* You are unable to display "special" characters however.
* Therefor this seems to be a useless option to me.
* I could be misunderstanding something here.

wxWindows uses the GTK widget set on Unix.
* I know not much about the underlying datatypes and techniques
* for showing special characters on this platform (there the pango thing
...).
* I think wchar_t* is never used here as the basic type, just char*.
* This in theory also allows to "encode" a special character but
* through multiple bytes (UTF-8 and UTF-16 as shown above).
I once made research on the autoconf/automake and gettext tools.
See http://gallery.uunet.be/Francis.Meyvis/
These combination of tools allow you to write a binary program
that is ready for translation to other languages on Unix.

Now at last wxPython.
The SWIG utility helps creating a wrapper around the wxWindow library.
This all is then presented as the wxPython module to the python.
I first got the sources (faster and this cheaper in downloading ;-).
These did not "setup.py" until Robin Dunn was so kind to
point me to a fixed my_distutils.py for 2.2.5. Thanks!
In the mean time I got the binary wxPython 2.2.5 modules.
for the python 2.1 used by ActiveState 2.1.
* With these I'm unable to use Unicode on win32 (hence the special
characters).
* I guess this is because the used wxWindow library is not compiled
* with the needed wxUSE_UNICODE support.
I then tried to get this to work from the sources.
I stumbled on type problems between the wxChar
(that is a wchar_t thus an unsigned short* when wxUSE_UNICODE is set)
and several python functions that require a char*.
I modified helper.cpp only to find out that the next file (wx.cpp)
that is compiled by the "setup.py" has even more problems.
This file is auto generated by SWIG.

I'm considering having to run wxPython in Unicode.
But my knowledge is very limited:
Don't know SWIG (and its 300+ pages users manual scares me off)
Don't know wxWindows at all
Don't know well how this python embedding thing works.
Don't know much on Unicode on unix/GTK (I'm not interested
on having it to work on win32 only)

Are there already people out there working on this?
Or perhaps I miss something and is is done already?

Thanks

Kind regards,
francis

Francis Meyvis:

wxWindows uses the GTK widget set on Unix.
* I know not much about the underlying datatypes and techniques
* for showing special characters on this platform (there the pango thing
...).
* I think wchar_t* is never used here as the basic type, just char*.
* This in theory also allows to "encode" a special character but
* through multiple bytes (UTF-8 and UTF-16 as shown above).

   GTK+ 1.x does not support Unicode but GTK+ 2.0 will through the use of
Pango. It is supposed to be possible to support DBCS on GTK+ 1.x although I
haven't seen any demonstrations. GTK+ 2.0 will use UTF-8 (char *) as the
underlying string type and a 32 bit character type when dealing with
individual characters.

   Neil

Hello again wxPython community and Francis,

A little over a year ago I posted a message to this newsgroup
regarding the use of wxPython on Windows in languages other than
English.

Francis was very kind to send me his notes on the subject. I dare
say that I found it rather discouraging. I wonder if the situation
has changed and if the internationalization issue has been dealt
with, probably by introducing Unicode support more decisively.

Please advise and be sure to send me a cc: even when replying to
the entire mailing list.

Thanks in advance and regards,
Victor Elkind

Francis Meyvis wrote:

···

> I am new to wxPython, and I would like to start building applications with
So am I
> and I require the ability to display the GUI using various languages:
So do I

> Does anyone have experience with using multiple languages with wxPython,
Don't think it is possible on win32 yet.

I will post a summary of responses to this list; please email me directly or
> Seems evident

Here's a summary of what I found out after a weekend of "research".
I'll mainly focus on win32 here as this is where I tried out everything.
I hope someone does it for Unix too!?
I guess the picture is not complete.
I hope more knowledgable people will be so kind
to fill the gaps/correct my misunderstandings.
(these things I'm not sure of are marked with an astrix at the line start).

>From Python 1.6 onwards there's the Unicode support.
Unicode allows you to represent special character in the source code.
There's the unicode type (a kind of string) build in and
easy to use conversion methods from this type to an ordinary string
and unicode string operation (even with ordinary strings as operand).
This conversion is done through codecs.
The standard codecs I know about are:
- ASCII: only characters representable through 7 bits are converted from the
unicode string
- Latin-1: only character representable through 8 bits are converted from
the unicode string
- UTF-8: a unicode character is represented through several bytes (from 1 to
?3? bytes)
e.g. u'\u304b' becomes '\xE3\x81\x8B'
- UTF-16: a unicode character is represented through 16 bits (there's an
endian issue here!)
e.g. u'\u304b' becomes '\x48\x30' or '\x30\x48' depending on endianess.
Some people made other codecs so you might find something for Hebrew, ...
e.g. I found and successfully used a Japanse codec from
http://pseudo.grad.sccs.chukyo-u.ac.jp/~kajiyama/python/
With I could read files I edited with emacs' MULE system.

On the win32 (m$ nt X.Y) the underlying string representation is unicode.
Note that win32s (m$ 9X/ Me ...) has only very, very limited support for
unicode.
E.g. Imagine one does a call to the CreateWindow(...) API.
Depending on the global macro's UNICODE and _UNICODE
this gets translated to an actual call to
- CreateWindowW(...): the real unicode version
(revealing the "special" characters depends on the font you use)
- CreateWindowA(...): the ascii version.
First all the "char*" parameters are converted to "unsigned short*" ones and
at the end CreateWindowW(...) is called.

ActiveState python 2.1 I tested does not seem to have
UNICODE and _UNICODE defined while compiling their binaries.
Logical otherwise it would not run on m$ win98 for instance.
It also means that you are not able to access the CreateWindowW()
through their win32 extentions even though
you specify the string parameters as unicode strings.
You are only able to show the ordinary ASCII characters correctly.

One is able to compile the wxWindows 2.2.5 library on win32 with Unicode
support.
Therefor you have to change the following macros in the msw\setup.h file:
- wxUSE_UNICODE: a wxChar type will be a wchar_t (otherwise it would be
just a char)
This wchar_t (a 16 bit type) supports win32's underlying UNICODE system
directly.
A wx program using this will only run on m$ nt (as explained higher) only.
- wxUSE_WCHAR_T: necessary for wxUSE_UNICODE
* According to a comment you can setup wxUSE_WCHAR_T
* only for limited unicode support.
* You program will run on win32s too.
* You are unable to display "special" characters however.
* Therefor this seems to be a useless option to me.
* I could be misunderstanding something here.

wxWindows uses the GTK widget set on Unix.
* I know not much about the underlying datatypes and techniques
* for showing special characters on this platform (there the pango thing
...).
* I think wchar_t* is never used here as the basic type, just char*.
* This in theory also allows to "encode" a special character but
* through multiple bytes (UTF-8 and UTF-16 as shown above).
I once made research on the autoconf/automake and gettext tools.
See http://gallery.uunet.be/Francis.Meyvis/
These combination of tools allow you to write a binary program
that is ready for translation to other languages on Unix.

Now at last wxPython.
The SWIG utility helps creating a wrapper around the wxWindow library.
This all is then presented as the wxPython module to the python.
I first got the sources (faster and this cheaper in downloading ;-).
These did not "setup.py" until Robin Dunn was so kind to
point me to a fixed my_distutils.py for 2.2.5. Thanks!
In the mean time I got the binary wxPython 2.2.5 modules.
for the python 2.1 used by ActiveState 2.1.
* With these I'm unable to use Unicode on win32 (hence the special
characters).
* I guess this is because the used wxWindow library is not compiled
* with the needed wxUSE_UNICODE support.
I then tried to get this to work from the sources.
I stumbled on type problems between the wxChar
(that is a wchar_t thus an unsigned short* when wxUSE_UNICODE is set)
and several python functions that require a char*.
I modified helper.cpp only to find out that the next file (wx.cpp)
that is compiled by the "setup.py" has even more problems.
This file is auto generated by SWIG.

I'm considering having to run wxPython in Unicode.
But my knowledge is very limited:
Don't know SWIG (and its 300+ pages users manual scares me off)
Don't know wxWindows at all
Don't know well how this python embedding thing works.
Don't know much on Unicode on unix/GTK (I'm not interested
on having it to work on win32 only)

Are there already people out there working on this?
Or perhaps I miss something and is is done already?

Thanks

Kind regards,
francis

Hello again wxPython community and Francis,

A little over a year ago I posted a message to this newsgroup
regarding the use of wxPython on Windows in languages other than
English.

Francis was very kind to send me his notes on the subject. I dare
say that I found it rather discouraging. I wonder if the situation
has changed and if the internationalization issue has been dealt
with, probably by introducing Unicode support more decisively.

There is a unicode build of wxPython for win32 which works fine on Win2k and
beyond, see the screenshot here: http://alldunn.com/wxPythonDemo-unicode.png

For Win9x/Me it uses Microsoft's MSLU library, but it's not as seemless as
MS would lead you to believe as some APIs/messages are apparently not fully
implemented or implemented correctly. Last I checked the wxPython demo
would "almost work" on win98 with the unicode build if you took out the code
that installs the wxTaskbarIcon.

Unicode builds are still not possible for wxGTK or wxMac, but I expect that
to change in the not too distant future.

For the non-unicode builds you should still be able to set and use fonts in
specific encodings and etc. Probably the best thing to do is to get the
latest wxPython (2.3.3 preview) and try things out to see if it will give
you what you need.

···

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!