Glenn Linderman writes: > On approximately 10/9/2009 3:08 PM, came the following characters from > the keyboard of Tokio Kikuchi:
> > Your suggestions 1)-4) are not accesptable to Japanese users at > > all. > If a message with an encoded header arrives (like your number 2 sample) > but it cannot be decoded, what action _is_ acceptable to Japanese > users? And what action is implemented in Mailman (if different)? I know a fair bit about Japanese (both the language and the users), and I'm having difficulty understanding what Tokio means, given your list of hypotheses. I suspect he's basically rejecting the hypothesis that it can't be decoded -- if it can't be decoded, then learn how to do so! > I can think of a 5th technique... don't modify the header, and send > it through unchanged. Now I think I've covered the gamut of > possibilities, I agree. However, I think we're way out of bounds here. We already know how to decode anything that RFC 2047 can throw at us in charsets that Python can handle. Anything that can't be decoded then is seriously malformed from the point of view of the mailing list users. So why are we discussing this? We don't even know what our mainline APIs are going to look like, why are we discussing forcibly operating on broken input? [[ Aside: > with an appropriate translation for "Re: "). "Re" is a Latin abbreviation; there is no appropriate translation. ;-) ]] > MUAs or mailing list handlers that attempt to retain what was sent > (idempotency or invertibility), would be more likely to do what I > describe, and are more robust when faced with new character sets > that they don't understand how to decode. Maybe they are, but the email module doesn't know or care about what they do. Let's stick within what the email module is supposed to handle. _______________________________________________ Email-SIG mailing list Email-SIG@python.org Your options: http://mail.python.org/mailman/options/email-sig/archive%40mail-archive.com
