Some Handlers get translation of language unsupposed

[Yasuhito FUTATSUKI at POEM]

Take a look at Mailman/Handlers/*.py, some of handlers seems to get translation of server language
when mail list preferred language or user preferred language context is needed, for lack of
set_language() (or set_translation). (Some handlers like Hold.py seems to switch language context
correctly.)

I found it in CookHeaders.py at first, while I try to fix bug #1643210 (and patch for fix
 attached there).

I cannot determine which of those is correct and is incorrect, so I report it incompletely, sorry.

[Mark Sapiro (msapiro)]

Whenever there is a list context, IncomingRunner (actually Runner of which IncomingRunner is a sub-class) sets the i18n language to the message sender's preferred language for the list or the list's preferred language if the sender doesn't have one before processing the message through the handler pipeline.

Hold is special in this regard because it can send notices to the list admin in the list's preferred language and to the message sender in the sender's preferred language and these may be different.

So I'm not sure that there is any issue here. If you think there is an issue, please provide more detail as to how and in what Handler it arises.

(I have questions about your patch in https://bugs.launchpad.net/bugs/1643210 too - I will comment there when I finish reviewing it.)

[Yasuhito FUTATSUKI at POEM (futatuki)]

I'm sorry I had misunderstood about this mechanism.(My test case was server's lang = sender's lang...)

This affects only when sender's preferred language and list's one is deffer and some of headers
to be encoded with RFC 2047 manner. In this case, the translation is sender's preferred language
and is encoded to list language. So this seems to affect only CookHeaders.py. (And if list
language's charset/encoding is UTF-8, this may not be a problem except few case the header string
contains character which don't have Unicode mapping.)

[Yasuhito FUTATSUKI at POEM (futatuki)]

The only handler seems to be affected by this, CookeHeaders.py, had been fixed with Bug #1643210.