[Mailman-Developers] [ mailman-Patches-634303 ] Recode pipermail templates

noreply@sourceforge.net noreply@sourceforge.net
Wed Nov 27 16:16:18 2002

Patches item #634303, was opened at 2002-11-06 03:28
You can respond by visiting: 

Category: Pipermail
Group: Mailman 2.1
>Status: Closed
>Resolution: Rejected
Priority: 5
Submitted By: Martin v. Löwis (loewis)
Assigned to: Nobody/Anonymous (nobody)
Summary: Recode pipermail templates

Initial Comment:
This patch transparently recodes the pipermail
templates and messages if the article and index files
have a different encoding than the template language If
necessary, HTML character references are generate. If
recoding fails, it will proceed without exception, but
produce garbage.

For messages, this uses a method self._, which first
invokes _, then does the recoding. This makes it
necessary for _ to go back more than one frame, so the
number of frames is now an optional parameter
(defaulting to 1).


>Comment By: Barry A. Warsaw (bwarsaw)
Date: 2002-11-27 11:16

Logged In: YES 

That's a good point (not having the codec).  I'm happy with
producing an error if the message comes in a charset for
which there's no installed codec.  I'll make sure that happens.


Comment By: Martin v. Löwis (loewis)
Date: 2002-11-18 18:25

Logged In: YES 

My concern with this approach is that we might not have a
codec for the encoding of the message. That means we cannot
decode the message to unicode, which means we cannot htmlify
unsupported characters. OTOH, we do have codecs for the
preferred encodings of all supported languages.
[Sorry I didn't think of this issue when we were talking
about it recently]

If we consider this case unlikely to occur in real life, and
are prepared to produce some error message in the page if it
does happen, then the approach is fine.

As for PEP293: Yes, this is precisely the intention: it
simplifies generating html-escaped strings, and it is more
efficient than any other strategy (since the codec will call
the error handling only when an encoding error occurs).


Comment By: Barry A. Warsaw (bwarsaw)
Date: 2002-11-18 15:46

Logged In: YES 

Feel free to shoot holes in this, but I think it might not
be simpler to just get rid of the multiple _charsets stuff
in HyperArch.HyperArchive.  Say we always encode the indices
pages with the character set of the list's preferred
language, except that we also html-ify any bogus characters
outside that charset.  Seems to me we can chop a bunch of
code and still get the results we want, even if at the
expense of potentially bigger pages (which I don't care about).

I'm going to commit some changes and test them out on the
playground list.  This seem to work well here for my test lists.

Semi-related: would PEP 293 allow us to get rid of


You can respond by visiting: 

More information about the Mailman-Developers mailing list