Actually, the problem is both simpler and more wide spread than you report. The underlying issue is the Content-Type: text/plain header sent with the POST request. It doesn't matter what if anything the data is. 'language' is a red herring. It only appears in the tracebacks from the subscribe CGI because that is what's being requested in the subscribe CGI's first call to the getvalue method of the cgi.FieldStorage instance.
The way the Python cgi module works, the FieldStorage instance has different properties depending on the Content-Type: header in the POST. If the content type is application/x-www-form-urlencoded as would be the case in a normal POST from a browser the FieldStorage instance is a dictionary-like mapping of key, value pairs that can be retrieved via the getvalue method. If the content type is text/plain, the FieldStorage instance just has a string value and the getvalue method throws TypeError.
This actually affects every one of Mailman's CGIs, not just subscribe, and without knowing how the error was triggered, I probably wouldn't have determined the cause.
In the spirit of not throwing uncaught exceptions, even when people, web crawlers, etc. unwittingly or maliciously craft defective requests, I have committed http://bazaar.launchpad.net/%7Emailman- coders/mailman/2.1/revision/1663 to return an error document with a 400 status for such requests.
** Changed in: mailman Importance: Undecided => Low
** Changed in: mailman Status: Incomplete => Fix Committed
** Changed in: mailman Milestone: None => 2.1.23