--On 13. Januar 2006 13:25:19 +0100 Martijn Faassen <faassen@infrae.com> wrote:
Andreas Jung wrote:
Thoughts?
All these changes seem to be the right thing. This will make unicode life in Zope a lot easier.
I worry about backward compatibility though.
Some code (such as PlacelessTranslationService) is doing wild things like monkeypatching the ZPT engine so that incoming unicode is encoded into UTF-8 during page template execution. I.e. the principle is quite different from that of Zope 2 itself, where the publisher takes care of translating things into an encoded string upon output. Since Silva doesn't use PTS anymore I don't worry about this, but Plone developers might.
Changing the default encoding of Zope to UTF-8 might break a lot of assumptions in people's code.
What about input? If I have an input form, browsers tend to submit in the encoding that the form as in, for instance UTF-8. This means I get UTF-8 strings into my request.
Now, if I have code that takes something from that request and displays it in a unicode page template, you'd have a problem, as you'd be mixing UTF-8 with unicode there. Again this might result in a lot of broken code.
I share your worries (meanwhile :-)). Enforcing unicode is too strict. I think to relax the wrapper code so it can handle both unicode and non-unicode (for backward compabitlity)...possibly using some 'strict' flag that enforces the use of unicode...I just don't know yet how to add this in a same way. Andreas