Hi All, It's been a a while since I had a good rant on a Zope list, but this really takes the biscuit. Andreas, what on *earth* were you thinking with PreferredCharsetResolver?! I like the idea of IUnicodeEncodingConflictResolver, but PreferredCharsetResolver is in the realms of totally batshit crazy. Why? well, because what *on earth* have the character sets accepted by the user agent got to do with how strings are encoded in *my database*?! Nevermind the logic holes of the following: - reverting to management_page_charset *only* if there's no REQUEST (there's always a REQUEST, this is Zope 2, the world collapses if there isn't!) - returning the original text if the bizarre dance fails, violating the contract of IUnicodeEncodingConflictResolver to *return unicode* How about the *insane performance overhead* of doing two utility lookups *and* iterating over a load of encodings trying to find one that works for *every single string substituition* done by a ZPT?! Why has no-one noticed this? Well, my guess is because when browsers are explicitly supplying headers, as quite a few do (IE and Safari excepted, who are legitimately going "we can handle anything you can throw at us"), this moronic piece of code happily loops through them all, and no doubt gets a hit on either utf-8 or latin-1, or, if you're really lucky, ascii. To boot, when things go wrong, nobody suspects this miserable little turd because it's hides itself nicely by just returning the original text, leaving the bemused reader to wonder why some UA's fail and some succeed, pointing the finger in totally the wrong direction (hence Charlie's hacked up getPreferredCharsets and poor Vlad's desperate attempts). Thankfully, I guess I can register an override that doesn't bark at the moon and froth at the mouth... Here, have an invoice for the hours of my life you've needlessly wasted... Faaaaaaaaaaaaarq, Chris ;-) -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk