I am new to this list and trying to use Mailman
to administer a Japanese language ML.
I have recently installed Mailman. Mailman
no trouble with handling Japanese e-mail messages but
archive files (html) do not display Japanese
characters properly. The problem seems to do
with the html conversion by Mailman.
When Mailman encouters '>' it gets replaced with '>'. In the
case of Japanese (multibyte) messages, this '>' is generally
one byte of double-byte character (Japanese) and as a result
the characters get messed up in html files. Archive files in the
text format does not have this problem.
I am not sure how this problem can be sorted out.
Is there a way wherein the replacement of '>' by '>'
can be avoided. Or is there a way to generate text files
instead of html files.
Thanks in advance.
Osaka City University
My task is to mark the texts in the following files: private.py,
roster.py and subscribe.py
I've had problems marking texts in these files.
The biggest question for me is that in my files there are messages
to the syslog, like this
Must I mark these texts like the other translatable text?
And the other problem is connected with the form.has.key("something"),
something=UserOptions or Digest or Membership Management, etc.
The problem here is that the "something string" must be marked
and then translated in other files.
So I think I should mark it, but in the other way, it
is a variable (it tells something to form.has.key), and we must not
change any variable.
Is there a faq for working with i18n for Mailman?
That is the first time I am offering to help in a job in the Net, so I
do not know how to begin.
May be someone can help me with some guidance...
Bonjour à tous,
Je suis parti du contenu du dossier "templates" de la version 2.0
(finale) de Mailman, et en m'appuyant sur la traduction de Matthieu
Camus, j'ai refait tout le contenu de ce dossier en français.
Il est donc parfaitement adapté à Mailman 2.0, j'attends vos remarques,
critiques etc dessus si vous en avez.
I started off with the "templates" folder from the 2.0 (final) version
of Mailman, and using some work already done by Matthieu Camus, I re-did
the folder's entire content in french.
It should work fine with Mailman 2.0, but I'd appreciate feedback,
critics etc if you have any.
Cheers / Cordialement :-)
PS: http://www.python.org/mailman/listinfo : 403 Forbidden :-(
> 2) In pipermail, I'd like to be able to define HTML tags that can be
> wrapped around non-important parts of the particular message.
> Specifically, this is to enable you to exclude certain parts of the
> message from indexing, such as navigation information. (I'm thinking
> specifically of the <!--UdmComment--> <!--/UdmComment--> tags.
> That is, of course, a rather obscure feature. :)
There is already a patch to do this - its marked as being for htdig,
but all it actually does is inject definable indexer on/off statements
into the generated HTML.
It does assume that your indexer parses are utilises the indexer <META>
tags that already appear in pipermail HTML.
or if that doesn't work, Patch 102422
[ - Opinions expressed are personal and may not be shared by VData - ]
[ Nigel Metheringham Nigel.Metheringham(a)VData.co.uk ]
[ Phone: +44 1423 850000 Fax +44 1423 858866 ]
> barry(a)digicool.com (Barry A. Warsaw) writes:
> > >From the TODO list, things I can imagine tackling for 2.1 include:
> I would like to see a couple things added.
> 1) the patch I wrote to sort the list and break it up in chunks
> when passed to the mailer -- FWIW, I've been using it since I
> wrote it without problems, surely others have, too. Like I said
> earlier, at worst, it's an innocuous feature, but in general it
> does benefit delivery performance.
I've been using it, and I think I love it. I think it ought to
be optionally added, too.
A pleasant side-effect of the domain sorting is when Hotmail gets
screwed up (once or twice a week), all the hotmail mail bounces at
the same time. :-}
barry(a)digicool.com (Barry A. Warsaw) writes:
> >From the TODO list, things I can imagine tackling for 2.1 include:
I would like to see a couple things added.
1) the patch I wrote to sort the list and break it up in chunks
when passed to the mailer -- FWIW, I've been using it since I
wrote it without problems, surely others have, too. Like I said
earlier, at worst, it's an innocuous feature, but in general it
does benefit delivery performance.
2) In pipermail, I'd like to be able to define HTML tags that can
be wrapped around non-important parts of the particular message.
Specifically, this is to enable you to exclude certain parts of
the message from indexing, such as navigation information. (I'm
thinking specifically of the <!--UdmComment--> <!--/UdmComment-->
That is, of course, a rather obscure feature. :)
There have been lots of great discussion on mailman-developers about
the directions Mailman should be taking. This is all very cool stuff
(and I want it to continue), but I view it as being more for Mailman
3.0, for which I have no time frame at the moment.
Now that 2.0 final is imminent[*], I'd also like to open up some
discussion about what we want to see in 2.1. My hard commitment, long
overdue, is to integrate Juan Carlos's and Victoriano's I18N work.
Juan Carlos has sent me patches, which I intend to start unpacking and
looking at, probably after the US Thanksgiving holiday weekend. I'd
also like to start using some of the nicer Python 2.0 features to
clean up the code in places.
Other than that, I'd like to get people's feedback on the really
crucial stuff that needs to get fixed for 2.1. I want to keep to a
bare minimum anything that requires re-architecting, pushing that into
3.0 after more discussions. I'd like to try to get a 2.1 beta out by
the end of the year, with 2.1 final some time in January. I don't
know if that's realistic or not.
>From the TODO list, things I can imagine tackling for 2.1 include:
- Plain text digests should conform to RFC 1153.
- If a message has MIME parts and the header/footer is going to be
added, the message should be transformed into a mulitpart/mixed
with the header and footer added as text/plain parts.
(note that this will require improving Python's standard MIME
message handling. b.bum astutely <wink> observes that it
basically sucks right now and fixing this dovetails with work i
want to do for Python 2.1 as well).
- Allow "urgent" postings to all members by the list admin which
bypasses normal digest delivery.
- A button that will bundled and deliver a digest Right Now.
- Allow the list-admin to require approvals for unsubs
- Allow the user to be excluded from postings if they're getting
them in the to: or cc: headers. Be smarter about filtering out
- Allow users to subscribe without selecting a password and have
Mailman create a password for them.
- Allow the site admin to define list styles or themes, and list
admins to choose one of the canned styles to apply to their
- Full creation, deletion, renaming, etc. of lists through the web
(and email?), including fixing aliases file updates.
- add_members should have a switch to disable admin notifications
- Allow individuals to turn off password reminders
- Don't use the first public mailing list as the `originator' of
- Provide an email interface to all administrative commands
- Add -join and -remove addresses for easy subscription,
- For email subscribes, keep an audit of where requests are coming
from, and send the original request headers in the confirmation
message. Helps track down subscribe bombs.
- Support the `which' command.
- archive link should do *something* reasonable before the first
message has been posted to the list.
We should also do /something/ about qrunner, but again, I want to
keep radical changes to a minimum. Stability is crucial, but
performance counts too. Maybe Chuq's idea of splitting the queue
into 3 parts can be done without much disruption.
I don't think /everything/ can be done for 2.1, and maybe other people
have different priorities. I'm going to keep this list up-to-date on
the Mailman2.1 Wiki:
Feel free to contribute.
[*] The astute observer will notice the tarball on SourceForge
already. I'm waiting for the mirror sites to update, but will
announce tomorrow even if they don't.
I think there are efforts to build an internationalized version
of mailman (just because this mailinglist exists).
How far is this port? Does Python not have any i18n mechanism?
The strings in the sourcecode are not marked for translation, will
at least this be done?
Currently I'm working on a german translation. The templates were
easy but to translate all the strings in the source is terrible
slow and error prone. And with the next version of mailman I
will have to throw away most of my work.
This is a great piece of software. With support for i18n it
would be perfect. ;o)
BTW: I have to do the work anyway, so if I could help... Next week
I will start to teach myself Python.
I have interest in developing a Finnish version of Mailman is such
version does not yet exist. I'm of course willing to contribute the
translation to the Mailman project if I decide to do the translation.
It seems to me that the templates have to be translated first .. is
there much more to it? I've read the design notes at www.zope.org but
I still have no idea of the size of the actual operation.
Can Mailman do qp-decoding in 2.x versions when archiving messages?
The 1.x versions couldn't and I remember writing a short patch to fix
the code that generates the summary pages (the pages with scandinavian
characters looked terrible). If the bulk 2.x versions can't do it are
there any patches ready for 2.x versions?
Please cc any replies directly to me as I'm not on
this list .. at least for now.