String representation in Thuban

[Bernhard Herzog]

Hi all,

As you may have seen I've checked in a bunch of changes in the way
Thuban handles strings.  So far, Thuban more or less assumed it was
running in a locale with latin-1 as the string encoding.  With the
changes it uses the string encoding of the user's locale.  This should
take care of bugs like RT2980 and RT2258 in most cases.

I've tested the new code with a non-unicode build wxPython/wxGTK 2.4/gtk
1.2 and a unicode build of wxPython/wxGTK 2.5.5/gtk 2.4.  In both cases
the locale used latin 1.  That worked fine.  A UTF8 locale might still
make some problems, but hopefully not in the about box :).  If you have
a non-latin-1 locale, please test the new code and report any problems
you have.

The test suite now runs explicitly with latin 1 as the string encoding,
but you can run it with other encodings using the new
--internal-encoding parameter of runtests.py.  Note that with an
encoding != latin 1 two tests will fail because there is no way in
Thuban yet to properly deal with DBF files that contain non-ascii
characters.

An overview of the new way string encoding is handled in Thuban and how
we can get to unicode as the string representation is in the new
technote string_representation.txt.


  Bernhard

-- 
Intevation GmbH                                 http://intevation.de/
Skencil                                           http://skencil.org/
Thuban                                  http://thuban.intevation.org/