A major goal of CMF 2.0 is to make it easier to use Zope3/Five features
in CMF. One issue that is not resolved so far is the fact that the CMF
uses encoded strings while Zope3/Five uses unicode strings. That calls
for trouble, especially in page templates because they can't handle
non-ascii encoded strings mixed with unicode.
One source of unicode strings are Message objects and translations. Both
Localizer and Placeless Translation Service monkey patch page templates
to work around the unicode problem. All unicode strings are encoded with
the page encoding before joining them with other strings. This seems to
work quite well, but it's nasty because of the monkey patching.
1.) All skin templates that have to deal with non-ascii content don't
access the content objects directly. As it is already the case for most
forms they should get their content from a skin script instead.
2.) The return value of all those scripts is converted using
CMFDefault.utils.toUnicode and the 'default_charset' of the site.
This is a sledgehammer method and customized skins have to be changed in
the same way. But after that we should be out of the woods:
- We can start to convert step by step other parts of the CMF to unicode
and to use Zope3/Five components that return unicode.
- We should be prepared for the upcoming page template changes.
I know this has drawbacks, but I don't see a better solution. If there
are no objections I'd like to work on this before the CMF 2.0 beta.
Zope-CMF maillist - Zope-CMF@lists.zope.org
See http://collector.zope.org/CMF for bug reports and feature requests