Last modified: 2014-08-31 03:19:29 UTC
Whenever non-ASCII characters are used in the subject line of messages sent through Mailman, for some reason the "subject prefix" (the bit of text that Mailman is supposed to add to the beginning of the subject line of the message) is removed. This is demonstrated here in two entries (http://lists.wikimedia.org/pipermail/daily-article-l/2013-February/date.html on Feb. 4 & Feb. 11) and in previous months of that archive. The "[daily article]" prefix should be present in all messages, as it is added by the Mailman software.
I changed Encode the subject prefix even when it consists of only ASCII characters? in <https://lists.wikimedia.org/mailman/admin/daily-article-l/language >from "Never" to "As needed" following the instructions at <https://www.gnu.org/software/mailman/mailman-admin/node16.html>. Hopefully this will fix it, can you keep an eye on it for the next message of this type?
It did not resolve the issue. See the subject line for the February 16th message (which was sent out a few hours after the above comment). http://lists.wikimedia.org/pipermail/daily-article-l/2013-February/002378.html (Removing Thehelpfulone as asignee - this does not appear to be a simple front-end list configuration change.)
(In reply to comment #0) > Whenever non-ASCII characters are used in the subject line of messages sent > through Mailman, for some reason the "subject prefix" (the bit of text that > Mailman is supposed to add to the beginning of the subject line of the > message) > is removed. Only in pipermail archives or also in actual emails to subscribers?
In the emails. Archives are just a duplicate copy (apparently).
(In reply to comment #4) > In the emails. Archives are just a duplicate copy (apparently). Not always, sometimes they add some bugs, like bug 25231. :)
This is still happening (ref: the March 9th entry at http://lists.wikimedia.org/pipermail/daily-article-l/2013-March/date.html ). And yes it was the same way in the actual email that was received in my inbox.
Just noting that the issue is still present. Should this be filed upstream or is there something on the back-end we can adjust? It does not appear that there is anything that a list admin can do to correct this.
