> 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.
> > 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
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