Some Handlers get translation of language unsupposed
Bug #1643215 reported by
Yasuhito FUTATSUKI at POEM
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
GNU Mailman |
Invalid
|
Undecided
|
Unassigned |
Bug Description
Take a look at Mailman/
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.
Related branches
Changed in mailman: | |
status: | Incomplete → Invalid |
To post a comment you must log in.
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.)