Mailman 3 November 2000 - Mailman-i18n

Japanese characters in Mailman archive
by Venkatesh Raghavan 17 May '01

17 May '01

Hi all, 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. Venkatesh Raghavan Osaka City University Japan

3 4

Marking the code
by Vizi Szilard 30 Nov '00

30 Nov '00

Hello! 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 LogStdErr("error", "private") 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. Opinion, suggestion? Szilard Vizi ------------- mailto:vizisz@freemail.hu UIN:10676592

3 2

How to begin with localization for Mailman
by Fernando Maior 28 Nov '00

28 Nov '00

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... Thanks! -- Bye, Fernando Maior Etica Tecnologia Linux Training

1 0

French "templates" for Mailman 2.0
by Matthias Saou 23 Nov '00

23 Nov '00

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. -- Hi all, 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 :-) Matthias PS: http://www.python.org/mailman/listinfo : 403 Forbidden :-( -- Matthias Saou matthias(a)accelance.fr

1 0

Re: [Mailman-Developers] Towards 2.1
by Nigel Metheringham 23 Nov '00

23 Nov '00

darrell(a)grumblesmurf.net said: > 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   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. See https://sourceforge.net/patch/?func=detailpatch&patch_id=102422&group_ id=103 or if that doesn't work, Patch 102422 Nigel. -- [ - 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 ]

1 0

Re: [Mailman-Developers] Towards 2.1
by Dan Mick 23 Nov '00

23 Nov '00

> 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. :-}

1 0

Re: [Mailman-Developers] Towards 2.1
by Darrell Fuhriman 22 Nov '00

22 Nov '00

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   tags. That is, of course, a rather obscure feature. :) Darrell

1 0

Towards 2.1
by barry＠digicool.com 22 Nov '00

22 Nov '00

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 duplicate deliveries. - 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 list. - 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 password reminders. - Provide an email interface to all administrative commands - Add -join and -remove addresses for easy subscription, unsubscription - 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: http://www.zope.org/Members/bwarsaw/MailmanDesignNotes/MailmanTwoDotOne Feel free to contribute. -Barry [*] 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.

1 0

i18n version of mailman?
by A. Königsdorfer 21 Nov '00

21 Nov '00

Hi folks! 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. Kind regards, Armin

1 0

a Finnish translation?
by Antti Siiskonen 20 Nov '00

20 Nov '00

Greetings. 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. -- //Antti

2 1