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

Bug Description

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 seems to switch language context

I found it in 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

Revision history for this message
Mark Sapiro (msapiro) wrote :

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 too - I will comment there when I finish reviewing it.)

Changed in mailman:
status: New → Incomplete
Revision history for this message
Yasuhito FUTATSUKI at POEM (futatuki) wrote :

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 (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.)

Revision history for this message
Yasuhito FUTATSUKI at POEM (futatuki) wrote :

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

Mark Sapiro (msapiro)
Changed in mailman:
status: Incomplete → Invalid
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers