[Zope-dev] Zope 2.6.0 ZMI Problem for CJK(Collector 623) patch.

[Toby Dickenson]

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 wee=
k.

I propose:

1. Currently you can set a management_page_charset property to override t=
he=20
global assumption that legacy ZMI pages are latin1. This is a hack that=20
happens to mostly work by accident, provided your ZMI pages do not encoun=
ter=20
a unicode object. I propose promoting this to a standard documented featu=
re.

Is there anyone who actually uses this feature who can contribute some=20
documentation?

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


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


3. I propose changing the encoding used by the standard 'Properties' ZMI =
page.=20
Currently it uses UTF8 always, and assumes that 8bit string properties ar=
e=20
latin1. I propose that this policy is used only if a unicode property has=
=20
already been defined on this object. If it has not, it uses the same enco=
ding=20
policy as every other ZMI page - that is the value of the=20
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=20
non-latin-1 initial value when creating the first unicode property. I thi=
nk=20
this is just about acceptable.