i18n: admin/mod environment vs. user environment
Hi!
Today, I've run across a curious issue with Mailman and its i18n.
The story goes like this:
We have a list where you can choose between 3 languages: A, B and C
The list is configured to use language A as default, and has a max_message_size = 10kB
One subscriber uses language B and sends a message bigger than 10kB, so it gets held (and gets a notice translated to language B)
Moderator gets a notice in language A (the default of the list, as I said), but the reason is translated into language B (user's default). This reason is also in language B in the Web interface (admindb).
Is that how it should work? Shouldn't be all the information (including the reason) for the moderator in the default language of the list (in this case, in language A)?
Thank you.
Regards, Alvaro.
Alvaro Uría wrote:
Today, I've run across a curious issue with Mailman and its i18n.
The story goes like this:
We have a list where you can choose between 3 languages: A, B and C
The list is configured to use language A as default, and has a max_message_size = 10kB
One subscriber uses language B and sends a message bigger than 10kB, so it gets held (and gets a notice translated to language B)
Moderator gets a notice in language A (the default of the list, as I said), but the reason is translated into language B (user's default). This reason is also in language B in the Web interface (admindb).
Is that how it should work? Shouldn't be all the information (including the reason) for the moderator in the default language of the list (in this case, in language A)?
Yes. This appears to be a bug. The code looks like it's trying to do the right thing, but it fails. I'll see if I can fix it.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Hi again,
El 05/28/09 19:28, Mark Sapiro wrote:
Yes. This appears to be a bug. The code looks like it's trying to do the right thing, but it fails. I'll see if I can fix it.
Do you want me to open a bug report at: https://bugs.launchpad.net/mailman/
Best regards, Alvaro.
Alvaro Uría wrote:
El 05/28/09 19:28, Mark Sapiro wrote:
Yes. This appears to be a bug. The code looks like it's trying to do the right thing, but it fails. I'll see if I can fix it.
Do you want me to open a bug report at: https://bugs.launchpad.net/mailman/
Yes, that would be good.
I have already worked up a preliminary patch, but doing this completely correctly and consistently is tricky without a major refactoring of the code.
Every exception has two associated messages - the "hold reason" and the default "reject reason". I have ensured that the hold reason, which is displayed in the admindb interface and in the emails to the admin are in the list's language and the hold reason in the message sent to the user is in the user's language. The default reject reason will display in the admindb detail interface in the user's language because there's no way with the current design to get it sent to the user in the user's language in all cases.
The other issue is if the user follows the "cancel" link in the user notice, the reason displayed on the confirmation page is in the list's language. Again, the current design doesn't allow this to be in a language different from what's displayed on the admindb pages and in the summary notices mailed to the admin.
I hope this partial solution will be acceptable. It is not perfect, but I think it addresses the most common issues.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
participants (2)
-
Alvaro Uría -
Mark Sapiro