[z3-five] unicodes and strings in Zope 2.9's ZPT with Zope 3's i18n

[Chris Withers]

Philipp von Weitershausen wrote:
> Yes. In an ideal case (read: Zope 3), the application returns text as
> unicode and never has to bother with strings. The publisher will
> negotiate the best encoding with the browser and send 8 bits over the wire.

Indeed.

>> In my case, I was inserting the utf-8 encoded title of a document into a 
>> generated navigator...
> 
> I see. When in doubt, just make sure that anything ending up in a ZPT is
> unicode. Of course, ideally, those document titles would be stored not
> in UTF-8 but in unicode...

Hurm, I see a world of pain for Zope 2 going forward :-/

There are a _lot_ of apps that store encoded strings in attributes in 
Zope 2 :-/

Now authors of those apps will either have to:

- do a massive and fine-toothed-comb data migration turning all encoded 
strings into unicode

- change all their templates to have horrific stuff like:
   <div 
tal:content="python:obj.getProperty('something','').decode('utf-8')"/>
   ...rather than:
   <div tal:content="obj/something|default"/>

- suffer frequent but not necessarilly reproducible, content-dependent 
unicode errors

All of these suck a lot. Can we really do nothing better?

Could the zpublisher-default-encoding be leverages somewhere in the mix 
to say "if it's a string, decode it like this"?

cheers,

Chris

-- 
Simplistix - Content Management, Zope & Python Consulting
            - http://www.simplistix.co.uk