Chris Withers wrote:
2.) Switch completely to unicode in CMF 2.0:
Sounds like a too big change, don't think we should try that.
I think we all know this is where we need to be eventually, 2.0 seems
the right time to do that, I'd actually prefer this, even though it'll
delay the 2.0 release...
Might make sense. But I'll not work on this on my own, so unless there
are other volunteers this is not really an option.
3.) Use encoded strings and unicode side by side:
This requires to know the encoding of the encoded strings.
'default_charset' should provide that information.
arrrgghhhhhhhh.... there be dragons...
I'm afraid we have to live with the dragons for a while.
3.1.) Encode unicode strings before passing them to page templates:
The unicode strings are only returned by newly added parts of the
code. So it might be easier to find all the places where a conversion
is necessary. On the other hand Message objects are also unicode, so
we would have to translate them before passing them to the templates.
Yeah, okay, it'll work, but it sucks long term as it's even mroe code
that needs to be "undone" when CMF goes fully unicode...
Thinking a bit more about it, I doubt this will work. The translations
returned by Five's translation service are unicode. And we can't change
them without monkey patching.
So I still tend to option 3.2.: Decode non-unicode strings before
passing them to page templates.
Zope-CMF maillist - Zope-CMF@lists.zope.org
See http://collector.zope.org/CMF for bug reports and feature requests