From barry at python.org Mon Dec 5 22:44:11 2005 From: barry at python.org (Barry Warsaw) Date: Mon, 05 Dec 2005 16:44:11 -0500 Subject: [Mailman-i18n] Registered at Rosetta Message-ID: <1133819051.18934.100.camel@geddy.wooz.org> So, we've gone ahead and registered the Mailman project at Ubuntu's Launchpad Rosetta. We should start migrating all i18n development to that site. Currently I'm still working with the Launchpad folks to get the Mailman project set up correctly, but in the meantime, anybody who still wants to work on Mailman i18n (and I hope that's you! :), should register with Launchpad and the GNU Translators group. You'll need to sign and submit a disclaimer form in order to join that group, but once you do, you'll be able to translate Mailman or any other GNU project registered at Launchpad. I think these are good links to start with: https://launchpad.net/rosetta/groups/gnu-translators/ https://launchpad.net/rosetta The Mailman pot and po files aren't yet uploaded, but I'll announce here when they are. Cheers, -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/mailman-i18n/attachments/20051205/01d73a67/attachment.pgp From tkikuchi at is.kochi-u.ac.jp Tue Dec 6 02:25:56 2005 From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi) Date: Tue, 06 Dec 2005 10:25:56 +0900 Subject: [Mailman-i18n] Registered at Rosetta In-Reply-To: <1133819051.18934.100.camel@geddy.wooz.org> References: <1133819051.18934.100.camel@geddy.wooz.org> Message-ID: <4394E8A4.9090205@is.kochi-u.ac.jp> Hi Barry, Barry Warsaw wrote: > So, we've gone ahead and registered the Mailman project at Ubuntu's > Launchpad Rosetta. We should start migrating all i18n development to > that site. Currently I'm still working with the Launchpad folks to get > the Mailman project set up correctly, but in the meantime, anybody who > still wants to work on Mailman i18n (and I hope that's you! :), should > register with Launchpad and the GNU Translators group. You'll need to > sign and submit a disclaimer form in order to join that group, but once > you do, you'll be able to translate Mailman or any other GNU project > registered at Launchpad. Should we all need to sign the paper? GPL article 5 states: ........................................... Therefore, by modifying or distributing the Program (or any work based on the Program), you indicate your acceptance of this License to do so, ... It looks like publishing translation equals acceptance and need no signing. To us, who are not native english speaker, it is a pain to read these kind of paper. > > I think these are good links to start with: > > https://launchpad.net/rosetta/groups/gnu-translators/ > https://launchpad.net/rosetta > > The Mailman pot and po files aren't yet uploaded, but I'll announce here > when they are. I'm working on the mailman.pot file which include templates and will be checking in soon. I think this should be a starting point of 2.2 tree and will not commit in the 2.1-maint. -- Tokio Kikuchi, tkikuchi@ is.kochi-u.ac.jp http://weather.is.kochi-u.ac.jp/ From martin at v.loewis.de Tue Dec 6 03:07:25 2005 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Tue, 06 Dec 2005 03:07:25 +0100 Subject: [Mailman-i18n] Registered at Rosetta In-Reply-To: <4394E8A4.9090205@is.kochi-u.ac.jp> References: <1133819051.18934.100.camel@geddy.wooz.org> <4394E8A4.9090205@is.kochi-u.ac.jp> Message-ID: <4394F25D.3050606@v.loewis.de> Tokio Kikuchi wrote: > Should we all need to sign the paper? I think the FSF is asking for papers of all contributors to the GNU project, see http://www.gnu.org/licenses/why-assign.html Regards, Martin From tkikuchi at is.kochi-u.ac.jp Tue Dec 6 03:28:39 2005 From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi) Date: Tue, 06 Dec 2005 11:28:39 +0900 Subject: [Mailman-i18n] Registered at Rosetta In-Reply-To: <4394F25D.3050606@v.loewis.de> References: <1133819051.18934.100.camel@geddy.wooz.org> <4394E8A4.9090205@is.kochi-u.ac.jp> <4394F25D.3050606@v.loewis.de> Message-ID: <4394F757.1040400@is.kochi-u.ac.jp> Martin v. L?wis wrote: > Tokio Kikuchi wrote: > >>Should we all need to sign the paper? > > > I think the FSF is asking for papers of all contributors > to the GNU project, see > > http://www.gnu.org/licenses/why-assign.html > Yeah, but we are separating translations from the main developement. We can release mailman-2.2 without translations indicating the user to download from other sites (or in separate packages). Translation is a kind of `modification' and the article 5 indicates the act of modification and distribution itself implies acceptance of the GPL. -- Tokio Kikuchi, tkikuchi@ is.kochi-u.ac.jp http://weather.is.kochi-u.ac.jp/ From martin at v.loewis.de Tue Dec 6 05:03:21 2005 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Tue, 06 Dec 2005 05:03:21 +0100 Subject: [Mailman-i18n] Registered at Rosetta In-Reply-To: <4394F757.1040400@is.kochi-u.ac.jp> References: <1133819051.18934.100.camel@geddy.wooz.org> <4394E8A4.9090205@is.kochi-u.ac.jp> <4394F25D.3050606@v.loewis.de> <4394F757.1040400@is.kochi-u.ac.jp> Message-ID: <43950D89.1010206@v.loewis.de> Tokio Kikuchi wrote: > Yeah, but we are separating translations from the main developement. We > can release mailman-2.2 without translations indicating the user to > download from other sites (or in separate packages). Translation is a > kind of `modification' and the article 5 indicates the act of > modification and distribution itself implies acceptance of the GPL. That's not the point: any contributor already has accepted the GPL. The issue is whether the FSF could ever defend the GPL in court: if there are many authors of the software (and translators *are* authors), the court might think that the FSF is just one of the many authors, and can't speak for all of them. So they try to reduce the number of authors of the software. Regards, Martin From bernd at firmix.at Tue Dec 6 09:45:46 2005 From: bernd at firmix.at (Bernd Petrovitsch) Date: Tue, 06 Dec 2005 09:45:46 +0100 Subject: [Mailman-i18n] Registered at Rosetta In-Reply-To: <43950D89.1010206@v.loewis.de> References: <1133819051.18934.100.camel@geddy.wooz.org> <4394E8A4.9090205@is.kochi-u.ac.jp> <4394F25D.3050606@v.loewis.de> <4394F757.1040400@is.kochi-u.ac.jp> <43950D89.1010206@v.loewis.de> Message-ID: <1133858746.10158.10.camel@tara.firmix.at> On Tue, 2005-12-06 at 05:03 +0100, "Martin v. L?wis" wrote: > Tokio Kikuchi wrote: > > Yeah, but we are separating translations from the main developement. We > > can release mailman-2.2 without translations indicating the user to > > download from other sites (or in separate packages). Translation is a > > kind of `modification' and the article 5 indicates the act of > > modification and distribution itself implies acceptance of the GPL. > > That's not the point: any contributor already has accepted the GPL. > The issue is whether the FSF could ever defend the GPL in court: > if there are many authors of the software (and translators *are* > authors), the court might think that the FSF is just one of the many So the GPL also holds for none-software in the US since translations are pure text as such (i.e. the simple translation of a .po file partly into another language) and not software in the sense of Austrian author's rights law (at least)? And BTW it is not possible to give away your author's right in continental European law (at least in .at and AFAIK .de) - you may just grant all rights to use (exclusively or non-exclusively) of your "work". Which is IMHO (sorry, IANAL) more than enough for all practical reasons regarding GPL etc.) > authors, and can't speak for all of them. Is it necessary to have *all* author's (i.e. 100% of them) in court or is it enough to have the contributors of the majority of content (say > 50% or so) or some (in whatever way defined) "core team"? > So they try to reduce the number of authors of the software. Yes, obviously. The question is this is desirable. Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services From barry at python.org Tue Dec 6 18:31:32 2005 From: barry at python.org (Barry Warsaw) Date: Tue, 06 Dec 2005 12:31:32 -0500 Subject: [Mailman-i18n] Registered at Rosetta In-Reply-To: <4394E8A4.9090205@is.kochi-u.ac.jp> References: <1133819051.18934.100.camel@geddy.wooz.org> <4394E8A4.9090205@is.kochi-u.ac.jp> Message-ID: <1133890292.15748.43.camel@geddy.wooz.org> On Tue, 2005-12-06 at 10:25 +0900, Tokio Kikuchi wrote: > Should we all need to sign the paper? There was some debate about this over on rosetta-users. It's definitely true that translations are already covered by the GPL, but the FSF imposes the additional requirement of copyright assignment, as Martin says, to reduce the number of authors. The FSF believes (although I don't know whether this have ever been tested in practice) that this helps them defend the GPL, should that ever become necessary. Tokio and others have already assigned or disclaimed for the Mailman project, so technically you wouldn't need to do anything to continue to contribute translations to Mailman. The thought was that by signing the disclaimer on Rosetta, you could then contribute translations to any of the GNU projects hosted there. I'm definitely open to suggestions. My primary goal is first, to make Mailman easier to contribute to, and second, to make it easier to maintain. Mailman 2 is a GNU project so I think we should continue to support the procedures the FSF requests of GNU projects as much as possible, for now at least. But if people think the requirements are too onerous, please let us know! -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/mailman-i18n/attachments/20051206/9c5891a1/attachment.pgp From martin at v.loewis.de Tue Dec 6 22:40:04 2005 From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=) Date: Tue, 06 Dec 2005 22:40:04 +0100 Subject: [Mailman-i18n] Registered at Rosetta In-Reply-To: <1133858746.10158.10.camel@tara.firmix.at> References: <1133819051.18934.100.camel@geddy.wooz.org> <4394E8A4.9090205@is.kochi-u.ac.jp> <4394F25D.3050606@v.loewis.de> <4394F757.1040400@is.kochi-u.ac.jp> <43950D89.1010206@v.loewis.de> <1133858746.10158.10.camel@tara.firmix.at> Message-ID: <43960534.4090602@v.loewis.de> Bernd Petrovitsch wrote: > So the GPL also holds for none-software in the US since translations are > pure text as such (i.e. the simple translation of a .po file partly into > another language) and not software in the sense of Austrian author's > rights law (at least)? The GPL applies to the "Program", which is defined as "any program or other work which contains a notice placed by the copyright holder saying it may be distributed under the terms of this General Public License." (clause 0 of the GPL) > Yes, obviously. The question is this is desirable. I'm not trying do defend the FSF policy. I'm merely pointing out what the FSF policy *is* (or, rather, what I think the FSF policy is - I don't speak for the FSF). If that really is the FSF policy, then mailman can only call itself "GNU mailman" if it complies with the FSF policy - this is the game in the GNU project. Whether or not to enforce FSF policy in the mailman project is up to the mailman maintainers (for which I don't speak, either). And if GNU mailman implements FSF policy, whether or not translators want to work with the mailman project, is their choice - I don't speak for the translators, obviously. But *if* they decide to cooperate with the project, and *if* the project agrees to implement FSF policy, *then* translators will have to sign papers. Regards, Martin From martin at v.loewis.de Tue Dec 6 22:53:00 2005 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Tue, 06 Dec 2005 22:53:00 +0100 Subject: [Mailman-i18n] Registered at Rosetta In-Reply-To: <1133890292.15748.43.camel@geddy.wooz.org> References: <1133819051.18934.100.camel@geddy.wooz.org> <4394E8A4.9090205@is.kochi-u.ac.jp> <1133890292.15748.43.camel@geddy.wooz.org> Message-ID: <4396083C.4090502@v.loewis.de> Barry Warsaw wrote: > I'm definitely open to suggestions. My primary goal is first, to make > Mailman easier to contribute to, and second, to make it easier to > maintain. Mailman 2 is a GNU project so I think we should continue to > support the procedures the FSF requests of GNU projects as much as > possible, for now at least. But if people think the requirements are > too onerous, please let us know! Speaking for the Translation Project: The contribution procedures are really simple if you tell translators: this is the document which you have to print out and sign, and this is the address you have to send it to. this is the set of strings that you have to fill into the form. People are slightly bothered, but generally willing to sign a form if all they have to do is to print a sheet of paper, put some well-known text into it, and put it into an envolope with a stamp on it. People are much more bothered if they actually have to think about this, e.g. when being given options to do either a) or b). Only occasionally, people complain that mailing to the U.S. is too costly; we then found a way to collect letters in the country, and have them batch-mailed into the U.S. If that would ever arise with mailman, we could happily coordinate with the team leader of the local team (they would normally be willing to pay the overseas stamp out of their pockets). Of course, you should make really sure in advance that you never have to go back and change the procedures, in case the translators signed the wrong document. So it should be certain that mailman is covered by whatever they sign. Also, if that procedure is in place, you should actively encourage translators to sign the papers ASAP, i.e. before they start translating. The entire snail mail game will take some time, and formally, you cannot accept their work until the papers have been received. Regards, Martin From barry at python.org Wed Dec 7 00:07:49 2005 From: barry at python.org (Barry Warsaw) Date: Tue, 06 Dec 2005 18:07:49 -0500 Subject: [Mailman-i18n] [Mailman-Developers] A better way of doing templates? In-Reply-To: <43851AF3.7060303@is.kochi-u.ac.jp> References: <1132786513.20488.153.camel@geddy.wooz.org> <43851AF3.7060303@is.kochi-u.ac.jp> Message-ID: <1133910469.15748.60.camel@geddy.wooz.org> On Thu, 2005-11-24 at 10:44 +0900, Tokio Kikuchi wrote: > How about adding current templates into pot/po and pickup and generate > language templates during "make install." I don't know if it could be > done at all but I will look at it this weekend. I see that this is checked in, which I guess means that the idea is working well for you. Cool! If we're going to generate all the template files at build time, I suppose we should remove all those files (and the directories?) from CVS. It's generally not a good idea to check in files that are generated during the build process. What do you think? > As regards the whole translation process, I've already submitted a patch > to select languages when configuring. This should help separating the > translations from the main developement code base. > http://sourceforge.net/tracker/index.php?func=detail&aid=1298355&group_id=103&atid=300103 Very cool. I've also heard requests to reduce the tarball size by separating the languages out into separate downloads. Does anybody think that's worth doing? -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/mailman-i18n/attachments/20051206/a557ace7/attachment.pgp From tkikuchi at is.kochi-u.ac.jp Wed Dec 7 01:28:15 2005 From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi) Date: Wed, 07 Dec 2005 09:28:15 +0900 Subject: [Mailman-i18n] Registered at Rosetta In-Reply-To: <4396083C.4090502@v.loewis.de> References: <1133819051.18934.100.camel@geddy.wooz.org> <4394E8A4.9090205@is.kochi-u.ac.jp> <1133890292.15748.43.camel@geddy.wooz.org> <4396083C.4090502@v.loewis.de> Message-ID: <43962C9F.60703@is.kochi-u.ac.jp> Martin v. L?wis wrote: > Speaking for the Translation Project: The contribution procedures are > really simple if you tell translators: > > this is the document which you have to print out and sign, and this > is the address you have to send it to. this is the set of strings > that you have to fill into the form. Well, it is simple if I am not employed. My employer (a Japanese University) refused to compose and sign a disclaimer and only expressed their "indifference" on my work to _me_ (not to FSF). It took three month to reach this conclusion. They wanted to do things in Japanese (or bureaucratic?) way. :-( OK. I understand the points and go this way. Official translations should be covered by the GNU Public License and the translators should sign the paper. -- Tokio Kikuchi, tkikuchi@ is.kochi-u.ac.jp http://weather.is.kochi-u.ac.jp/ From tkikuchi at is.kochi-u.ac.jp Wed Dec 7 01:36:20 2005 From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi) Date: Wed, 07 Dec 2005 09:36:20 +0900 Subject: [Mailman-i18n] [Mailman-Developers] A better way of doing templates? In-Reply-To: <1133910469.15748.60.camel@geddy.wooz.org> References: <1132786513.20488.153.camel@geddy.wooz.org> <43851AF3.7060303@is.kochi-u.ac.jp> <1133910469.15748.60.camel@geddy.wooz.org> Message-ID: <43962E84.30804@is.kochi-u.ac.jp> Barry Warsaw wrote: > On Thu, 2005-11-24 at 10:44 +0900, Tokio Kikuchi wrote: > > >>How about adding current templates into pot/po and pickup and generate >>language templates during "make install." I don't know if it could be >>done at all but I will look at it this weekend. > > > I see that this is checked in, which I guess means that the idea is > working well for you. Cool! Yeah! ;^) > If we're going to generate all the > template files at build time, I suppose we should remove all those files > (and the directories?) from CVS. It's generally not a good idea to > check in files that are generated during the build process. What do you > think? I'm going to do this as a next step soon. >>As regards the whole translation process, I've already submitted a patch >> to select languages when configuring. This should help separating the >>translations from the main developement code base. >>http://sourceforge.net/tracker/index.php?func=detail&aid=1298355&group_id=103&atid=300103 > > > Very cool. I've also heard requests to reduce the tarball size by > separating the languages out into separate downloads. Does anybody > think that's worth doing? This has also been checked in. I'm going to try hack the release script to separate the languages from the main tarball. Cheers, -- Tokio Kikuchi, tkikuchi@ is.kochi-u.ac.jp http://weather.is.kochi-u.ac.jp/ From brad at stop.mail-abuse.org Wed Dec 7 15:39:19 2005 From: brad at stop.mail-abuse.org (Brad Knowles) Date: Wed, 7 Dec 2005 15:39:19 +0100 Subject: [Mailman-i18n] [Mailman-Developers] A better way of doing templates? In-Reply-To: References: <1132786513.20488.153.camel@geddy.wooz.org> <43851AF3.7060303@is.kochi-u.ac.jp> <1133910469.15748.60.camel@geddy.wooz.org> <43962E84.30804@is.kochi-u.ac.jp> <20051207082005.GB15456@rezo.net> Message-ID: At 1:08 PM +0100 2005-12-07, =?utf-8?Q?Bj=C3=B8rn_Vermo?= wrote: > May I suggest a zero-lingual base version? The only way to make software > truly language independent is to avoid the concept of a "default language". > If everybody has to get a language file, developers will be forced to > think about localization issues. You have to use some sort of tag to translate the message into, and that tag is going to have to exist in some language. And the programmers are going to have to think in some language while writing the code which will handle the tag. Or do you propose that all the programmers are going to have to forget all the native languages they know and instead use randomly generated gibberish tags? How do you propose to maintain that code? When you go talking to other people in the world, do you work in a zero-language manner internally, so that you can make sure that you never have to translate from some native language into another native language? When you can do that for all your native language discussions, you can come back here and share with us how that works and how you would modify that to work with programming languages and i18n. -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 LOPSA member since December 2005. See . From barry at python.org Wed Dec 7 17:28:15 2005 From: barry at python.org (Barry Warsaw) Date: Wed, 07 Dec 2005 11:28:15 -0500 Subject: [Mailman-i18n] Registered at Rosetta In-Reply-To: <43960534.4090602@v.loewis.de> References: <1133819051.18934.100.camel@geddy.wooz.org> <4394E8A4.9090205@is.kochi-u.ac.jp> <4394F25D.3050606@v.loewis.de> <4394F757.1040400@is.kochi-u.ac.jp> <43950D89.1010206@v.loewis.de> <1133858746.10158.10.camel@tara.firmix.at> <43960534.4090602@v.loewis.de> Message-ID: <1133972895.14917.6.camel@geddy.wooz.org> On Tue, 2005-12-06 at 22:40 +0100, "Martin v. L?wis" wrote: > If that really is the FSF policy, then mailman can only call itself > "GNU mailman" if it complies with the FSF policy - this is the game > in the GNU project. Whether or not to enforce FSF policy in the > mailman project is up to the mailman maintainers (for which I don't > speak, either). I think we're obliged to, as long as we call ourselves GNU Mailman. Note that this applies regardless of whether we coordinate translations through Rosetta or not. Sadly, I've been lax at enforcing this requirement, so the only thing that Rosetta adds is easier management and stricter enforcement of a policy we should have had all along. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/mailman-i18n/attachments/20051207/eaa500c8/attachment.pgp From barry at python.org Wed Dec 7 18:18:29 2005 From: barry at python.org (Barry Warsaw) Date: Wed, 07 Dec 2005 12:18:29 -0500 Subject: [Mailman-i18n] Registered at Rosetta In-Reply-To: <43962C9F.60703@is.kochi-u.ac.jp> References: <1133819051.18934.100.camel@geddy.wooz.org> <4394E8A4.9090205@is.kochi-u.ac.jp> <1133890292.15748.43.camel@geddy.wooz.org> <4396083C.4090502@v.loewis.de> <43962C9F.60703@is.kochi-u.ac.jp> Message-ID: <1133975909.14918.8.camel@geddy.wooz.org> On Wed, 2005-12-07 at 09:28 +0900, Tokio Kikuchi wrote: > Well, it is simple if I am not employed. My employer (a Japanese > University) refused to compose and sign a disclaimer and only expressed > their "indifference" on my work to _me_ (not to FSF). It took three > month to reach this conclusion. They wanted to do things in Japanese > (or bureaucratic?) way. :-( It may be possible to use your existing paperwork to add you to the GNU Translators group. I don't remember the exact wording of what you signed. That would probably go for anyone else who has already signed translation papers. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/mailman-i18n/attachments/20051207/e851dbf5/attachment.pgp From tkikuchi at is.kochi-u.ac.jp Tue Dec 13 04:11:44 2005 From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi) Date: Tue, 13 Dec 2005 12:11:44 +0900 Subject: [Mailman-i18n] Released: Mailman 2.1.7a1 Message-ID: <439E3BF0.7090906@is.kochi-u.ac.jp> Hi Developers and i18ners, Mailman 2.1.7a1 was released for alpha test and i18n translations. Here is excerpts from NEWS file. I thank Mark Sapiro for significant contributions in bug-fixes and document/message brushups. Please fetch it from SF download sites or from http://mm.tkikuchi.net/mailman-2.1.7a1.tgz Cheers, Tokio --------------------------------------------------- Here is a history of user visible changes to Mailman. 2.1.7a1 (13-Dec-2005) Security - The fix for CAN-2005-0202 has been enhanced to issue an appropriate message instead of just quietly dropping ./ and ../ from URLs. - A note on CVE-2005-3573: Although the RFC2231 bug example in the CVE has been solved in mailman-2.1.6, there may be more cases where ToDigest.send_digests() can block regular delivery. We put the send_digests() calling part in try - except clause and leave a message in the error log if something happened in send_digests(). Daily call of cron/senddigests will notify more detail to the site administrator. - List administrators can no longer change the user's option/subscription globally. Site admin can change these only if mm_cfg.ALLOW_SITE_ADMIN_COOKIES is set to Yes. - Script tag is disallowd in edithtml script. - Since probe message for the disabled users may reach unexpected persons, the password was excluded from sendProbe() and probe.txt. Note that the default value of VERP_PROBE has been set to `No' from 2.1.6., thus this change doesn't change the default behavior. New Features - Always remove DomainKey (and similar) headers (1287546) from messages sent to the list. - List owners can customize content filter behavior as not to collapse multipart/alternative to its first content. This allows HTML part to pass through after other content filtering is done. Internationalization - New language: Interlingua. Bug fixes and other patches - Fix MTA/Postfix.py to check aliases group permission in check_perms and fix mailman-install document on this matter (1378270). - Fix private.py to go to the original URL after authorization (1080943). - Fix bounce log score messages to be more consistent. - Fix bin/remove_members to accept no arguments when both --fromall and --file= options are specified. - Change cgi-bin and mail wrapper "group not found" error message to be more descriptive of the actual problem. - Apply the list's ban_list to address changes and admin mass subscribe and invite and to confirmations/approvals of address changes, subscriptions and invitations. - Decode quoted-printable and base64 encoded parts before passing to HTML_TO_PLAIN_TEXT_COMMAND (1367783). - Remove Approve: header from post - treat as Approved: (1355707). - Stop removing line following Approve(d): line in body of post (1318883). - Log post in post log with true sender, not listname-bounces (1287921). - Correctly initialize and remember the list's default_member_moderation attribute in the web list creation page (1263213). - Add PEP263 charset in config_list output (1343100). - header_filter_rules get lost if accessed directly and needed authenti- cation by login page (1230865). - Obscure email when the poster doesn't set full name in 'From:' header. - Take preambles and epilogues into account when calculating message sizes for holding purposes (Mark Sapiro). - Logging/Logger.py unicode transform option (1235567). - bin/update crashes with bogus files (949117). - Bugs and patches: 1212066/1301983 (Date header in create/remove notice) -- Tokio Kikuchi, tkikuchi@ is.kochi-u.ac.jp http://weather.is.kochi-u.ac.jp/ From tkikuchi at is.kochi-u.ac.jp Tue Dec 20 04:27:32 2005 From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi) Date: Tue, 20 Dec 2005 12:27:32 +0900 Subject: [Mailman-i18n] Released: Mailman 2.1.7b1 Message-ID: <43A77A24.7000309@is.kochi-u.ac.jp> Hi all, I've just released Mailman 2.1.7b1 for beta test and i18n translations. I'm tempted to jump into RC because the 2.1-maint branch is so stable and 2.1.7 is mainly for bug fixes, but we need more translations before the final release. Please download it from SF or: http://mm.tkikuchi.net/mailman-2.1.7b1.tgz Cheers, Tokio ------------------------------------------------------- Here is a history of user visible changes to Mailman. 2.1.7b1 (20-Dec-2005) Security - The fix for CAN-2005-0202 has been enhanced to issue an appropriate message instead of just quietly dropping ./ and ../ from URLs. - A note on CVE-2005-3573: Although the RFC2231 bug example in the CVE has been solved in mailman-2.1.6, there may be more cases where ToDigest.send_digests() can block regular delivery. We put the send_digests() calling part in try - except clause and leave a message in the error log if something happened in send_digests(). Daily call of cron/senddigests will notify more detail to the site administrator. - List administrators can no longer change the user's option/subscription globally. Site admin can change these only if mm_cfg.ALLOW_SITE_ADMIN_COOKIES is set to Yes. - Script tag is disallowd in edithtml script. - Since probe message for the disabled users may reach unexpected persons, the password was excluded from sendProbe() and probe.txt. Note that the default value of VERP_PROBE has been set to `No' from 2.1.6., thus this change doesn't change the default behavior. New Features - Always remove DomainKey (and similar) headers (1287546) from messages sent to the list. - List owners can customize content filter behavior as not to collapse multipart/alternative to its first content. This allows HTML part to pass through after other content filtering is done. Internationalization - New language: Interlingua. Bug fixes and other patches - Fix Scrubber.py mungs quoted-printable bug with introducing 'X-Mailman-Scrubbed' header for marking that the payload is scrubber-munged. The flag is referenced in ToDigest.py, ToArchive.py, Decorate.py and Archiver. Similar problem in ToDigest.py where the plain digest is generated is also fixed. - Fix Syslog.py to write quopri encoded message when it fail to write 8-bit characters. - Fix MTA/Postfix.py to check aliases group permission in check_perms and fix mailman-install document on this matter (1378270). - Fix private.py to go to the original URL after authorization (1080943). - Fix bounce log score messages to be more consistent. - Fix bin/remove_members to accept no arguments when both --fromall and --file= options are specified. - Change cgi-bin and mail wrapper "group not found" error message to be more descriptive of the actual problem. - Apply the list's ban_list to address changes and admin mass subscribe and invite and to confirmations/approvals of address changes, subscriptions and invitations. - Decode quoted-printable and base64 encoded parts before passing to HTML_TO_PLAIN_TEXT_COMMAND (1367783). - Remove Approve: header from post - treat as Approved: (1355707). - Stop removing line following Approve(d): line in body of post (1318883). - Log post in post log with true sender, not listname-bounces (1287921). - Correctly initialize and remember the list's default_member_moderation attribute in the web list creation page (1263213). - Add PEP263 charset in config_list output (1343100). - header_filter_rules get lost if accessed directly and needed authenti- cation by login page (1230865). - Obscure email when the poster doesn't set full name in 'From:' header. - Take preambles and epilogues into account when calculating message sizes for holding purposes (Mark Sapiro). - Logging/Logger.py unicode transform option (1235567). - bin/update crashes with bogus files (949117). - Bugs and patches: 1212066/1301983 (Date header in create/remove notice) From tkikuchi at is.kochi-u.ac.jp Sat Dec 24 08:30:36 2005 From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi) Date: Sat, 24 Dec 2005 16:30:36 +0900 Subject: [Mailman-i18n] [Mailman-Users] Released: Mailman 2.1.7b1 Message-ID: <43ACF91C.50801@is.kochi-u.ac.jp> Hi all, I've just released Mailman 2.1.7rc1 Release Candidate. I'm sorry for the violation of file name extension convention because I made a small mistake when tagging the release number. I will be releasing 2.1.7 final by December 31 if there is no problem. Please download it from SF or: http://mm.tkikuchi.net/mailman-2.1.7rc1.tar.gz Cheers, Tokio ------------------------------------------------------- 2.1.7rc1 (24-Dec-2005) Security - The fix for CAN-2005-0202 has been enhanced to issue an appropriate message instead of just quietly dropping ./ and ../ from URLs. - A note on CVE-2005-3573: Although the RFC2231 bug example in the CVE has been solved in mailman-2.1.6, there may be more cases where ToDigest.send_digests() can block regular delivery. We put the send_digests() calling part in try - except clause and leave a message in the error log if something happened in send_digests(). Daily call of cron/senddigests will notify more detail to the site administrator. - List administrators can no longer change the user's option/subscription globally. Site admin can change these only if mm_cfg.ALLOW_SITE_ADMIN_COOKIES is set to Yes. - Script tag is disallowd in edithtml script. - Since probe message for the disabled users may reach unexpected persons, the password was excluded from sendProbe() and probe.txt. Note that the default value of VERP_PROBE has been set to `No' from 2.1.6., thus this change doesn't change the default behavior. New Features - Always remove DomainKey (and similar) headers (1287546) from messages sent to the list. - List owners can customize content filter behavior as not to collapse multipart/alternative to its first content. This allows HTML part to pass through after other content filtering is done. Internationalization - New language: Interlingua. Bug fixes and other patches - Defaults.py.in: SCRUBBER_DONT_USE_ATTACHMENT_FILENAME is set to True for safer operation. - Fix Scrubber.py mungs quoted-printable bug with introducing 'X-Mailman-Scrubbed' header for marking that the payload is scrubber-munged. The flag is referenced in ToDigest.py, ToArchive.py, Decorate.py and Archiver. Similar problem in ToDigest.py where the plain digest is generated is also fixed. - Fix Syslog.py to write quopri encoded message when it fail to write 8-bit characters. - Fix MTA/Postfix.py to check aliases group permission in check_perms and fix mailman-install document on this matter (1378270). - Fix private.py to go to the original URL after authorization (1080943). - Fix bounce log score messages to be more consistent. - Fix bin/remove_members to accept no arguments when both --fromall and --file= options are specified. - Change cgi-bin and mail wrapper "group not found" error message to be more descriptive of the actual problem. - Apply the list's ban_list to address changes and admin mass subscribe and invite and to confirmations/approvals of address changes, subscriptions and invitations. - Decode quoted-printable and base64 encoded parts before passing to HTML_TO_PLAIN_TEXT_COMMAND (1367783). - Remove Approve: header from post - treat as Approved: (1355707). - Stop removing line following Approve(d): line in body of post (1318883). - Remove Approve(d): from all text/* parts in addition the initial text/plain part. It still must be the first non-blank line in the first text/plain part or it won't be found or removed at all (1181161). - Log post in post log with true sender, not listname-bounces (1287921). - Correctly initialize and remember the list's default_member_moderation attribute in the web list creation page (1263213). - Add PEP263 charset in config_list output (1343100). - header_filter_rules get lost if accessed directly and needed authenti- cation by login page (1230865). - Obscure email when the poster doesn't set full name in 'From:' header. - Take preambles and epilogues into account when calculating message sizes for holding purposes (Mark Sapiro). - Logging/Logger.py unicode transform option (1235567). - bin/update crashes with bogus files (949117). - Bugs and patches: 1212066/1301983 (Date header in create/remove notice) From tkikuchi at is.kochi-u.ac.jp Sat Dec 24 08:35:43 2005 From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi) Date: Sat, 24 Dec 2005 16:35:43 +0900 Subject: [Mailman-i18n] Mailman 2.1.7rc1 (was Re: [Mailman-Users] Released: Mailman 2.1.7b1) In-Reply-To: <43ACF91C.50801@is.kochi-u.ac.jp> References: <43ACF91C.50801@is.kochi-u.ac.jp> Message-ID: <43ACFA4F.3010803@is.kochi-u.ac.jp> Oops, Sorry for the typo in the message title. I mean Released: Mailman 2.1.7rc1 Release Candidate Tokio Kikuchi wrote: > Hi all, > > I've just released Mailman 2.1.7rc1 Release Candidate. I'm sorry for > the violation of file name extension convention because I made a small > mistake when tagging the release number. I will be releasing 2.1.7 > final by December 31 if there is no problem. > > Please download it from SF or: > http://mm.tkikuchi.net/mailman-2.1.7rc1.tar.gz > > Cheers, -- Tokio Kikuchi, tkikuchi@ is.kochi-u.ac.jp http://weather.is.kochi-u.ac.jp/ From fil at rezo.net Wed Dec 7 09:20:47 2005 From: fil at rezo.net (Fil) Date: Wed, 07 Dec 2005 08:20:47 -0000 Subject: [Mailman-i18n] [Mailman-Developers] A better way of doing templates? In-Reply-To: <43962E84.30804@is.kochi-u.ac.jp> References: <1132786513.20488.153.camel@geddy.wooz.org> <43851AF3.7060303@is.kochi-u.ac.jp> <1133910469.15748.60.camel@geddy.wooz.org> <43962E84.30804@is.kochi-u.ac.jp> Message-ID: <20051207082005.GB15456@rezo.net> > > Very cool. I've also heard requests to reduce the tarball size by > > separating the languages out into separate downloads. Does anybody > > think that's worth doing? > > This has also been checked in. I'm going to try hack the release script > to separate the languages from the main tarball. I personnally dissent from this idea; one great strength of free software is its internationalization open to everyone both in participating to translations and using them. Making them "optional" is making the software weaker. If the need for smaller tarballs is real (which I doubt, given the bandwidth and diskspace you need to run Mailman :-) ), one option could be, on the contrary, to have a seperate download link for people who *want* a mono-lingual (supposedly US-English?) Mailman. -- Fil From bv at opera.com Wed Dec 7 13:27:47 2005 From: bv at opera.com (=?utf-8?Q?Bj=C3=B8rn_Vermo?=) Date: Wed, 07 Dec 2005 12:27:47 -0000 Subject: [Mailman-i18n] [Mailman-Developers] A better way of doing templates? In-Reply-To: <20051207082005.GB15456@rezo.net> References: <1132786513.20488.153.camel@geddy.wooz.org> <43851AF3.7060303@is.kochi-u.ac.jp> <1133910469.15748.60.camel@geddy.wooz.org> <43962E84.30804@is.kochi-u.ac.jp> <20051207082005.GB15456@rezo.net> Message-ID: On Wed, 07 Dec 2005 09:20:06 +0100, Fil wrote: >> > Very cool. I've also heard requests to reduce the tarball size by >> > separating the languages out into separate downloads. Does anybody >> > think that's worth doing? >> >> This has also been checked in. I'm going to try hack the release script >> to separate the languages from the main tarball. > > I personnally dissent from this idea; one great strength of free > software is > its internationalization open to everyone both in participating to > translations and using them. Making them "optional" is making the > software > weaker. > > If the need for smaller tarballs is real (which I doubt, given the > bandwidth > and diskspace you need to run Mailman :-) ), one option could be, on the > contrary, to have a seperate download link for people who > *want* a mono-lingual (supposedly US-English?) Mailman. > May I suggest a zero-lingual base version? The only way to make software truly language independent is to avoid the concept of a "default language". If everybody has to get a language file, developers will be forced to think about localization issues. -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/ From munzirtaha at gmail.com Sun Dec 25 16:30:33 2005 From: munzirtaha at gmail.com (Munzir Taha) Date: Sun, 25 Dec 2005 18:30:33 +0300 Subject: [Mailman-i18n] Mailman Arabic translation Message-ID: <200512251830.38792.munzirtaha@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Sirs, Is there an Arabic translation on the work for mailman? If not, then I can volunteer to maintain it. Can you point me to the proper procedure or any relavent doc, please? - -- Munzir Taha Telecommunications and Electronics Engineer Maintainer of Fedora Arabic Translation Project https://listman.redhat.com/mailman/listinfo/fedora-trans-ar Maintainer of the OpenBugs project page at http://www.arabic-fedora.org/munzir/OpenBugs.html Master CIW Designer, ICDL, MOUS, Linux+, LPI 101 New Horizons CLC, Riyadh, SA -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFDrrseOBlicvBnGCERAnK/AKCaOh4+jvc/M/qNZq5YSn1qUYx7iwCeLgir Y0miEPdtuc2BuYUF5dt5QLE= =OAT0 -----END PGP SIGNATURE-----