The base mailman code appears to support an extensive number of local languages. But, as far as I can see, all the dlist code is hard-coded to English so that we really do mean we want '+new' in the inbound address for any new dlist email, no matter what the language or charset of the sender.
If so, either fix submitted so far looks as if it will work for the systers-only version of the dlist code.
But if/when we merge into the base mailman distribution, we may be requested/required to support local language (or at least local charset) versions of '+new', in which case a better but substantially larger change would be required to supply both of the parts of the email to the local language template code. But then, of course, there's an equally big task to parse the language-varying +new when we get a message in.
Are the globalization/localization requirements for merging our dlist code with mailman well defined?
The base mailman code appears to support an extensive number of local languages. But, as far as I can see, all the dlist code is hard-coded to English so that we really do mean we want '+new' in the inbound address for any new dlist email, no matter what the language or charset of the sender.
If so, either fix submitted so far looks as if it will work for the systers-only version of the dlist code.
But if/when we merge into the base mailman distribution, we may be requested/required to support local language (or at least local charset) versions of '+new', in which case a better but substantially larger change would be required to supply both of the parts of the email to the local language template code. But then, of course, there's an equally big task to parse the language-varying +new when we get a message in.
Are the globalization/ localization requirements for merging our dlist code with mailman well defined?