Re: [Zope] How to convert Zope instance charset?
Sunday, April 24, 2005, 6:05:42 PM, Andreas Jung wrote:
--On Sonntag, 24. April 2005 17:45 Uhr +0200 Daniel Dekany <ddekany@freemail.hu> wrote:
Sunday, April 24, 2005, 4:22:10 PM, Andreas Jung wrote: First of all, in this thread I don't care whose mistake it is. My concern is if I can use Zope with UTF-8 (in fact, Plone) in reality or not. Assume that I'm using a few non-US-ASCII characters, and I want sometimes show things alphabetically sorted...
You're not getting the point. As long as you handle with Python string and not with unicode strings then there is no way in Zope deal correctly with different kind of encodings...As I said...it is an application side problem. Zope and Python provide you the tools to deal with UTF8 but you need to solve such problems on in your application. That's my last comment on this issue :-)
Maybe *you* don't get the point. Python has a "virtual machine level" setting that specifies the locale and encoding (the charset). You can set it for example like: locale.setlocale('hu_HU', 'ISO-8859-2'). And although there is no charset information attached to strings, locale.strcoll and such will assume that the string is in the encoding specified globally like above, right? All the strings (which is not an unicode string) is assumed to use that encoding. It seems to me that it works like that until I specify 'UTF-8' in the locale, in which case it goes mad. And, to Max M., regarding patching sequence.sort: a) There is no guarantee that everything uses for sequence.sort. Some code may calls locale.strcoll directly and such, which can result in all sort of inconsistency. The fix could be done at the root of the problem, which is I belive strcoll. b) If the problem is in Zope (that I doubt) then it should be patched in Zope itself, not by everybody individually. That is, for Andreas Jung, if the locale.getlocale(locale.LC_COLLATE) indicates that the default charset is UTF-8, then it should be sorted like that. But again, I think it should be actually fixed in Python level (in locale.strcoll), and not on the Zope level. Anyway, I have already accepted earlier that while Zope will certainly work with ISO-8859-2 (that locale.strcoll handles correctly), it will not work with UTF-8. Hence, Zope doesn't work well with UTF-8, while it works with "older" charsets (it does without any extra effort, right?). So I just asked how to switch over ISO-8859-2, and then some start to tell that it works with UTF-8, and that it should be solved on application level(!!!)...
-aj
-- Best regards, Daniel Dekany
--On Sonntag, 24. April 2005 18:34 Uhr +0200 Daniel Dekany <ddekany@freemail.hu> wrote:
Maybe *you* don't get the point. Python has a "virtual machine level" setting that specifies the locale and encoding (the charset). You can set it for example like: locale.setlocale('hu_HU', 'ISO-8859-2'). And although there is no charset information attached to strings, locale.strcoll and such will assume that the string is in the encoding specified globally like above, right? All the strings (which is not an unicode string) is assumed to use that encoding. It seems to me that it works like that until I specify 'UTF-8' in the locale, in which case it goes mad.
I am very much aware of the issue (btw. it was me who integrated sequence.sort()). And if you look carefully at the API of sequence.sort() then you will see that there is already built-in support locale-aware comparisons. -aj
participants (2)
-
Andreas Jung -
Daniel Dekany