> As I understand it, you dont want to do anything in unicode. You store, 
> manipulate, process, and output strings as 8-bit pre-encoded strings. You  
> are making an assumption that these 8-bit strings use some specific character 
> encoding. The scope of this assumption is quite broad. It has to cover:
> 1. All strings stored by your ZODB
> 2. All strings stored by your RDB.
> 3. All processing performed by Zope products. (must follow your assumptions, 
> or be encoding neutral)
> Anything that beaks these assumptions will need special treatment.
> Am I right so far?
why I don't want to use ustring, because there are two problems for me.

1. the original encoding is not clear anymore.

   It does not know that it will change at once. there is no encoding
   which raise unicode error other than utf-8. but utf-8 is not common
   encoding in japanese. almost all PDAs or cellular phones are not
   supporting utf-8.

   Probably, automatic encoding detection will be required in order to
   become practical.

2. ustring can not join or replace to 8-bit strings other than ascii.

   I have an same experience in Plone i18n with Localizer and TranslationService.

> Zope's approach is that your application (excluding the ZMI for now) should 
> work as in 2.5, provided you dont use any unicode values. Can you confirm 
> that this is working OK?
If I input values by  PythonScript without using property tab, it works well.

> Zope 2.5 left ZMI character encoding down to browser autodetection, and as a 
> result most ZMI-controlled properties are encoding-neutral. For compatability 
> with unicode pages, which are seen as the long term future, the ZMI has to 
> specify *some* character encoding. By default in 2.6 this is latin-1, a 
> change which I think was announced mid-way through the 2.5 development cycle. 
> I understand that some users are very happy overriding this with a 
> management_page_charset property on their root folder. Ive never used this, 
> and it wasnt designed to work this way, but it looks like it works due to 
> happy coincidence. Note that this doesnt work for management pages which 
> explicitly set their own character encoding, or management pages which 
> 'accidentally' encounter a unicode string.
I think management_page_charset is very useful, if it function correctly.

> One area where this went wrong for you is the properties page, which is 
> explicitly set to utf8 to allow unicode properties to be set. Im not yet sure 
> on the best way to fix this for you, but I agree it needs fixing.

I made monkey patch for myself, when management_page_charset is not
"UTF-8", this patch remove ":utf8:" from non unicode type input field.
because if input values are not latin-1, then unicode error raised.

I think that every encoding can be used it satisfactory:-)

Please consider whether it can merge into Zope2.6.1.

Thank you

Yusei Tahara                    "So it goes"

Attachment: properties.dtml
Description: Binary data

Reply via email to