[Bug 779751] [NEW] admindb fail to find message charset
Public bug reported: admindb.py displays held message excerpt but fails to get proper message charset, leading unreadable text excerpts especially for languages using multi-byte code. Attached patch solves this problem by finding the first charset in multipart message, which is used in Decorate.py etc. ** Affects: mailman Importance: Undecided Status: New -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/779751 Title: admindb fail to find message charset
** Patch added: "admindb.py.msgcset-patch.txt" https://bugs.launchpad.net/bugs/779751/+attachment/2120743/+files/admindb.py... -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/779751 Title: admindb fail to find message charset
Tokio, I'm glad you are having time to work on Mailman again. Welcome back. Your help is valuable, especially with non-western character sets. Regarding this issue, I see the problem and I see what your patch does, but I wonder if it would be better if rather than looking at the first part with a charset, if we looked at the first main type text part. If it has a charset, the result will be the same either way, but if not, maybe we should use us-ascii rather than the charset of some later part. I.e. + # We get it from the first text part + for part in msg.walk(): + if part.get_content_maintype() == 'text': + mcset = part.get_content_charset('us-ascii') + break + else: + mcset = 'us-ascii' I am thinking of the possibility of a message with an undeclared us-ascii body and an attachment encoded in some other character set. Of course, if the other character set is a superset of us-ascii, it would still be OK to use it, and even in a, hopefully rare, case where it didn't, the moderator could always forward the message to himself to see it, so maybe it doesn't matter much. What do you think? -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/779751 Title: admindb fail to find message charset
Indentation is lost in comment 2. It should be +....# We get it from the first text part +....for part in msg.walk(): +........if part.get_content_maintype() == 'text': +............mcset = part.get_content_charset('us-ascii') +............break +....else: +........mcset = 'us-ascii' -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/779751 Title: admindb fail to find message charset
Hi, Mark. Your modification to the patch looks reasonable. I should have used get_content_charset() instead of get_param(), at the least. -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/779751 Title: admindb fail to find message charset
I made one additional change to the patch. Instead of "mcset = part.get_content_charset('us-ascii')", I do "mcset = part.get_content_charset() or 'us-ascii'" as in Decorate.py to allow for charset= with no value. ** Changed in: mailman Importance: Undecided => Medium ** Changed in: mailman Status: New => Fix Committed ** Changed in: mailman Milestone: None => 2.1.15 ** Changed in: mailman Assignee: (unassigned) => Mark Sapiro (msapiro) -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/779751 Title: admindb fail to find message charset
** Changed in: mailman Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/779751 Title: admindb fail to find message charset To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/779751/+subscriptions
participants (2)
-
Mark Sapiro
-
Tokio Kikuchi