Thread: [PyCS-devel] UTF-8 Patch for PyCS
Status: Alpha
Brought to you by:
myelin
|
From: Georg B. <gb...@mu...> - 2003-08-22 08:24:52
Attachments:
pycs.diff.gz
|
Hi! I just received an UTF-8 compatibility patch and japanese message file for PyCS from Yasushi Iwata. I am currently discussing it with him, but from a first look I would say it's a quite clean patch and we can pull it in. If somebody want's to look at it before it goes into CVS, I just attached it. After some questions are answered (for example I am currently not quite sure wether there would be a conversion step needed for existing data) I think I will integrate the attached patch into CVS. Phil: looks like you need to put another contributor on your PyCS pages ;-) (and it would be great if you could skim the patch, too). Oh, Yasushi Iwata will send a PyDS patch for UTF-8 support, too, so after integration of these we will have a fully UTF-8 capable blogging solution! bye, Georg |
|
From: Phillip P. <pp...@my...> - 2003-08-22 11:41:18
|
> I just received an UTF-8 compatibility patch and japanese message file for > PyCS from Yasushi Iwata. I am currently discussing it with him, but from a > first look I would say it's a quite clean patch and we can pull it in. If > somebody want's to look at it before it goes into CVS, I just attached it. > After some questions are answered (for example I am currently not quite > sure wether there would be a conversion step needed for existing data) I > think I will integrate the attached patch into CVS. We might want to think about what DefaultEncoding means -- the original point of the config var was for the xml rewriting (Radio compatibility) hack, but now it's being used to generate charset attributes on html / xml. Do we want that? It might make sense to separate the two -- assume one encoding, but always generate UTF-8, perhaps? > Phil: looks like you need to put another contributor on your PyCS pages > ;-) (and it would be great if you could skim the patch, too). > > Oh, Yasushi Iwata will send a PyDS patch for UTF-8 support, too, so after > integration of these we will have a fully UTF-8 capable blogging solution! That is _very_ cool :-) Cheers, Phil |
|
From: Georg B. <gb...@mu...> - 2003-08-22 17:43:32
|
Hi! > We might want to think about what DefaultEncoding means -- the original > point of the config var was for the xml rewriting (Radio compatibility) > hack, but now it's being used to generate charset attributes on html / > xml. > Do we want that? It might make sense to separate the two -- assume one > encoding, but always generate UTF-8, perhaps? Hmm. Actually I don't think both meanings overlap: Radio users won't ever be able to participate in an UTF-8 PyCS, because they barely can produce Latin1 ;-) But you are right we should clarify this. I asked Yasushi Iwata to join us here on the list. bye, Georg |
|
From: Phillip P. <pp...@my...> - 2003-08-22 20:19:24
|
> > We might want to think about what DefaultEncoding means -- the original > > point of the config var was for the xml rewriting (Radio compatibility) > > hack, but now it's being used to generate charset attributes on html / > > xml. > > Do we want that? It might make sense to separate the two -- assume one > > encoding, but always generate UTF-8, perhaps? > > Hmm. Actually I don't think both meanings overlap: Radio users won't ever be > able to participate in an UTF-8 PyCS, because they barely can produce Latin1 ;-) Yeah. Maybe we should get it so the xml rewriting hack occurs only for specific user agents (Radio + Frontier). > But you are right we should clarify this. I asked Yasushi Iwata to join us here > on the list. Cool! Looking forward to seeing him in. Yashushi- are you here now? Cheers, Phil |
|
From: Yasushi I. <ya...@lo...> - 2003-08-23 08:14:13
|
> Cool! Looking forward to seeing him in. Yashushi- are you here now? Yes, I'm here in Japan with thousands of Kanji characters ;-) > > > We might want to think about what DefaultEncoding means -- the original > > > point of the config var was for the xml rewriting (Radio compatibility) > > > hack, but now it's being used to generate charset attributes on html / > > > xml. Okay, I understood. I think a new config var should be used for encoding attribute to generate html/xml. |
|
From: Phillip P. <pp...@my...> - 2003-08-26 21:46:09
|
> > > Okay, I understood. I think a new config var should be used for > > > encoding attribute to generate html/xml. > > > > Sounds like a good idea to me! > > This is new patch. New config var is documentencoding. Cool. By the way the patch looks a little odd -- it looks like you have deleted or blanked out a lot of files (e.g. LICENSE, README, ...). Is your working directory OK? Also, trackbacks -- it looks like you are using DocumentEncoding to decode the fields in trackback pings. I think you might be better looking at the Content-Encoding (Character-Encoding? Content-Type?) header in the HTTP POST instead for that. Cheers, Phil :) |
|
From: Yasushi I. <ya...@lo...> - 2003-08-27 16:45:15
|
> By the way the patch looks a little odd -- it looks like you have > deleted or blanked out a lot of files (e.g. LICENSE, README, ...). Is > your working directory OK? Sorry, that's my mistake. > Also, trackbacks -- it looks like you are using DocumentEncoding to > decode the fields in trackback pings. I think you might be better > looking at the Content-Encoding (Character-Encoding? Content-Type?) > header in the HTTP POST instead for that. It's a good idea. I'll implement. |
|
From: Yasushi I. <ya...@lo...> - 2003-08-26 12:58:31
Attachments:
pycs.diff.gz
|
> > Okay, I understood. I think a new config var should be used for > > encoding attribute to generate html/xml. > > Sounds like a good idea to me! This is new patch. New config var is documentencoding. |
|
From: Yasushi I. <ya...@lo...> - 2003-09-06 09:46:34
|
Hi, On Wed, 27 Aug 2003 09:37:29 +1200 you wrote: > Also, trackbacks -- it looks like you are using DocumentEncoding to > decode the fields in trackback pings. I think you might be better > looking at the Content-Encoding (Character-Encoding? Content-Type?) > header in the HTTP POST instead for that. How about this patch? It looks at the Content-Type header to determine content encoding. http://lowlife.jp/yasusii/static/pycs.diff.gz |
|
From: Georg B. <gb...@mu...> - 2003-10-02 14:36:54
|
Hi! > How about this patch? It looks at the Content-Type header to determine > content encoding. I just pulled in this patch into CVS. I did a change, though: the Header() conversion in the mailto.py module is only done if the strings to be passed on contain special chars. This is to prevent unnecessary quoting of strings, as that quoting often leads to weird displays in clients that don't support this quoting (Outlook is one of those that often makes problems with header qpe). Another change I just commited is that users.py now returns a list of all users if you don't give a usernum. And if you give format=rss you get a rss feed of all users of your community server. This is just to monitor wether people log in and create new blogs. The stuff is installed at muensterland.org and so far there seems nothing to be broken. Yasushi: could you send me your more fully translated pycs-ja.msgs file, so I can put that into CVS, too? And you should try the CVS version on your server wether everything works as you expect. bye, Georg |
|
From: Phillip P. <pp...@my...> - 2003-10-02 23:01:37
|
On Thu, Oct 02, 2003 at 04:36:23PM +0200, Georg Bauer wrote: > I just pulled in this patch into CVS. I did a change, though: the Header() Thanks for that, Georg. My apologies for not taking care of it myself! I'll update pycs.net soon. Cheers, Phil :) |