On Thursday 05 December 2002 9:36 pm, Toby Dickenson wrote:
> On Thursday 05 December 2002 8:41 pm, Heiichiro NAKAMURA wrote:
> > Does anyone have any other idea for the Collector 623 issue?
> > I hope better ideas will be posted..
> Yes, I have an idea. I hope to find time to flesh it out early next week.

I propose:

1. Currently you can set a management_page_charset property to override the 
global assumption that legacy ZMI pages are latin1. This is a hack that 
happens to mostly work by accident, provided your ZMI pages do not encounter 
a unicode object. I propose promoting this to a standard documented feature.

Is there anyone who actually uses this feature who can contribute some 

(Note that feature will never work with pages that do encounter unicode 
objects. This means Zope should try to avoid gratuitous unicode usage, but I 
suggest that compatability with this feature should not hold back any future 
enhancements to the ZMI which rely on using unicode)

2. The documented way of setting a ZMI-page-specific encoding is 
REQUEST.set('management_page_charset','UTF-8'). Currently 
management_page_charset as a global property will override this page specific 
setting. This is a bug that needs to be fixed. 

3. I propose changing the encoding used by the standard 'Properties' ZMI page. 
Currently it uses UTF8 always, and assumes that 8bit string properties are 
latin1. I propose that this policy is used only if a unicode property has 
already been defined on this object. If it has not, it uses the same encoding 
policy as every other ZMI page - that is the value of the 
management_page_charset property, or latin-1 if it has not been set.

A disadvantage of this change is that it will not be possible to set a 
non-latin-1 initial value when creating the first unicode property. I think 
this is just about acceptable.

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists -
 http://lists.zope.org/mailman/listinfo/zope )

Reply via email to