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

[Toby Dickenson]

On Monday 09 December 2002 2:20 am, Heiichiro NAKAMURA wrote:
> On Sun, 8 Dec 2002 21:58:16 +0000
>
> Toby Dickenson <tdickenson@geminidataloggers.com> wrote:
> > On Thursday 05 December 2002 9:36 pm, Toby Dickenson wrote:
> > > Yes, I have an idea. I hope to find time to flesh it out early next
> > > week.
> >
> > I propose:
>
> Here is my understanding of your proposal:
>
>
>
> 1. "management_page_charset" property for non-Latin-1
> -----------------------------------------------------------------------=
-
>     Affected application: ZMI only
>     Limitation:
>        - Standard Objects in Zope (such as "title" property) must be
>          Non-Unicode.

Yes, if using management_page_charset.=20

>        - All objects must be Non-Unicode in order to work in ZMI.

To be precise, all objects rendered on the management page must be plain =
8bit=20
strings.

>        - If there is even one Unicode object there, all data will be
>          assumed as 'Latin-1' and non-Latin-1 data cannot be used in
>          any object.

yes

>        - REQUEST.set('management_page_charset','UTF-8') does not work
>          when 'management_page_charset' is set as global property.

That is the current, broken behaviour. I propose that REQUEST.set overrid=
es=20
the global property. Note that no standard ZMI page will do so, except th=
e=20
'properties' tab explained below.

>     Homework (new issues):
>        - define the safe steps of implementation of Unicode Support

>        - find a way of smooth migration of MBCS-to-Unicode

Yes. There is nothing zope-specific about this being hard ;-)

> -----------------------------------------------------------------------=
-
>
>
> 2. Behaviour of handling of text in ZMI

Not all of ZMI - this is just the 'Properties' tab.

> -----------------------------------------------------------------------=
-
> When UnicodeType Properties are contained:

>      - internal representation: 'UCS-2/UTF-16' if UnicodeType(ex. ustri=
ng)
>                                 'Latin-1' if not UnicodeType(ex. string=
)
>      - encoding of output data: 'Latin-1'

No, output over http will be utf8.

>      - encoding of input data: 'Latin-1'

If you mean input from the browser when a property changes, no. it will u=
se=20
utf8.

> When UnicodeType Properties are NOT contained:
>      - encoding of input data: any

yes, the same as all other ZMI pages. latin-1 by default, and can be over=
idden=20
by management_page_charset.

>      - internal representation: same as input (no conversion)
>      - encoding of output data: same as internal (no conversion)
>
>     Limitation:
>      - Non-Latin-1 value cannot be used when creating the first Unicode
>        Property.
> -----------------------------------------------------------------------=
-
>
> (Any correction is welcomed)
>
> I'll ask power users of Japan-Zope-User-Group-ML about opinions
> regarding to the proposal.
>
> > but I
> > suggest that compatability with this feature should not hold back any
> > future enhancements to the ZMI which rely on using unicode)
>
> I guess this statement is somewhat ambiguous. Probably we could say
> something like that? :
> -----------------------------------------------------------------------=
-
>   1. Any future enhancements to the ZMI which rely on using unicode
>   should be carefully defined, examined, evaluated and feasibility-test=
ed
>   so that all issues/limitations can be clarified and the consequent
>   impact of these issues/limitation can be evaluated in order to
>   avoid hassle implementation integrated into the official version.

yes

>   2. Any experimental enhancements to the ZMI which rely on using unico=
de
>   must be integrated into the official version in the manner that
>   it doesn't affect the behaviour of 'legacy' applications,=20

I disagree. I dont want to block a good new feature from Zope 2.x (x>=3D7=
)=20
simply because it uses unicode in a way that is incompatible with the=20
management_page_charset property. Thats what 'legacy' means.

> until
>   the Unicode Support gets matured enough to handle Unicode object
>   with all languages/encodings.

Yes. There are several places in the ZMI that could benefit from=20
'unicodization'. At the moment I suspect it will be difficult to implemen=
t=20
these improvements while retaining support for management_page_charset.=20