I am writing some custom mailman pages top fit the theme of my site. I am stumped on setting up a custom confirm.html page. Please advise how I do this.
On 05/30/2013 08:55 PM, Janice Boothe wrote:
I am writing some custom mailman pages top fit the theme of my site. I am stumped on setting up a custom confirm.html page. Please advise how I do this.
I'm not sure what you mean by confirm.html. If you mean the results of going to a URL like <http://www.example.com/mailman/confirm/list_name/some_string>, those results are all built on the fly by the Mailman/Cgi/confirm.py script.
There is a very limited control of color. See the section "Web UI defaults" in Mailman/Defaults.py for documentation. Beyond that any customization has to be done in the confirm.py module itself or in methods in Mailman/htmlformat.py.
Note that it is fairly simple to add a reference to a css style sheet to the Document.Format() method. See <http://mail.python.org/pipermail/mailman-users/2008-March/060881.html>.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Yes I do mean that. I used confirm.html since that is the naming convention used to create custom pages for much of the other IO of Mailman.
It seems rather odd and extremely limiting that Mailman functiuons as you describe in regards to confirm. Most of the other pages are customizable (listinfo, etc), why in the world would the programmers make such a choice to not allow site owners to customize the confirm page? Is this something that can be fixed in future releases as it should not be very hard to do? While I do like very much the functionality of Mailman, the default interface leaves a whole lot to be desired and lead to a very unprofessional look and feel when added to a site.
--- On Thu, 5/30/13, Mark Sapiro <mark@msapiro.net> wrote:
From: Mark Sapiro <mark@msapiro.net> Subject: Re: [Mailman-Users] Custom Pages To: "Janice Boothe" <nursejanice@yahoo.com> Cc: mailman-users@python.org Date: Thursday, May 30, 2013, 11:36 PM
On 05/30/2013 08:55 PM, Janice Boothe wrote:
I am writing some custom mailman pages top fit the theme of my site. I am stumped on setting up a custom confirm.html page. Please advise how I do this.
I'm not sure what you mean by confirm.html. If you mean the results of going to a URL like <http://www.example.com/mailman/confirm/list_name/some_string>, those results are all built on the fly by the Mailman/Cgi/confirm.py script.
There is a very limited control of color. See the section "Web UI defaults" in Mailman/Defaults.py for documentation. Beyond that any customization has to be done in the confirm.py module itself or in methods in Mailman/htmlformat.py.
Note that it is fairly simple to add a reference to a css style sheet to the Document.Format() method. See <http://mail.python.org/pipermail/mailman-users/2008-March/060881.html>.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 05/31/2013 01:26 PM, Janice Boothe wrote:
Some of Mailman's GUI web pages are built from templates such as listinfo.html, options.html and subscribe.html. Many others including the entire web admin interface and much of the admindb interface are not.
This wasn't as much of an issue when Mailman 2 was designed.
Is this something that can be fixed in future releases as it should not be very hard to do?
Well, I don't know about 'hard' but it won't happen in Mailman 2.1 for several reasons having mostly to do with i18n considerations and the fact that were it to be done, I'm the one who would do it with whatever help I could scrounge from the community.
On the other hand, Mailman 3 is a different story. In MM 3 the core mailing list functions communicate with the outside via a REST API. Anyone is free to develop whatever web UI they want to communicate with the core. The web UI that will ship with MM 3 is Postorius <https://launchpad.net/postorius> and I think you'll find it much more template driven than the MM 2 UI.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
--- On Fri, 5/31/13, Mark Sapiro <mark@msapiro.net> wrote:
:> Yes I do mean that. I used confirm.html since that is the naming :> convention used to create custom pages for much of the other IO of: :> Mailman. : :Some of Mailman's GUI web pages are built from templates such as :listinfo.html, options.html and subscribe.html. Many others including :the entire web admin interface and much of the admindb interface are not.
I understand this. It is the basis for teh discussion! :)
:> It seems rather odd and extremely limiting that Mailman functiuons as :> you describe in regards to confirm. Most of the other pages are :> customizable (listinfo, etc), why in the world would the programmers :> make such a choice to not allow site owners to customize the confirm :> page? : :This wasn't as much of an issue when Mailman 2 was designed.
OK
:> Is this something that can be fixed in future releases as it :> should not be very hard to do? : :Well, I don't know about 'hard' but it won't happen in Mailman 2.1 for :several reasons having mostly to do with i18n considerations and the :fact that were it to be done, I'm the one who would do it with whatever :help I could scrounge from the community.
Maybe because I am not fully aware of il8n but I fail to see how that is an issue. I know fo other software that uses end user selectable language sets and is highly customizable. Also the fact that a lot of the rest of MM uses templates kind of points to the possibility that the rest ought to be able to as well.
:On the other hand, Mailman 3 is a different story. In MM 3 the core :mailing list functions communicate with the outside via a REST API. :Anyone is free to develop whatever web UI they want to communicate with :the core. The web UI that will ship with MM 3 is Postorius :<https://launchpad.net/postorius> and I think you'll find it much more :template driven than the MM 2 UI.
I'll have to wit until the good folks at cpanel add MM3 before I can start using that.. :(
BTW thank for the work on this. I am not trying to kick your cat here at all, merely sending in feedback on how to improve the product.
On Jun 2, 2013, at 11:23 AM, Janice Boothe <nursejanice@yahoo.com> wrote:
Maybe because I am not fully aware of il8n but I fail to see how that is an issue. I know fo other software that uses end user selectable language sets and is highly customizable. Also the fact that a lot of the rest of MM uses templates kind of points to the possibility that the rest ought to be able to as well.
It's open-source software; grab a copy, and start working!
On 06/02/2013 08:23 AM, Janice Boothe wrote:
Maybe because I am not fully aware of il8n but I fail to see how that is an issue.
Mailman 2.1.15 supports 37 non-English translations. Mailman 2.1.16 will add Farsi to the list. Even assuming that switching to a template doesn't add or change any strings in the message catalog, any new template needs to be translated into 38 other languages. The users of a language for which the template has not been translated see a page built from the English template.
Thus, switching to a new template breaks that page for those users who prefer one of the 38 non-English languages until the template is translated into their language.
My experience tells me that this translation will happen in timely fashion for at most 5 of the 38 languages leaving users of the other 33 or more languages with a page they may not be able to read.
This may not be an issue for you, but it is for me.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
--- On Sun, 6/2/13, Mark Sapiro <mark@msapiro.net> wrote:
From: Mark Sapiro <mark@msapiro.net> Subject: Re: [Mailman-Users] Custom Pages To: "Janice Boothe" <nursejanice@yahoo.com> Cc: "Mailman Users" <mailman-users@python.org> Date: Sunday, June 2, 2013, 10:55 AM
On 06/02/2013 08:23 AM, Janice Boothe wrote:
Maybe because I am not fully aware of il8n but I fail to see how that is an issue.
:Mailman 2.1.15 supports 37 non-English translations. Mailman 2.1.16 will :add Farsi to the list. Even assuming that switching to a template :doesn't add or change any strings in the message catalog, any new :template needs to be translated into 38 other languages. The users of a :language for which the template has not been translated see a page built :from the English template.
:Thus, switching to a new template breaks that page for those users who :prefer one of the 38 non-English languages until the template is :translated into their language.
You are assuming that a list owner is allowing/offering more than his native language. Even if he were, it is on him to code his custom pages with the capabilities to #include the appropriate language set. That all can be done with language files with the translations of any given language for each translatable word/ phrase and parameters that call in the specific phrase form the users chosen language. If you have the dynamic ability to build a page based on the specific users chosen language, then you already have the capability to have custom pages do the same.
:My experience tells me that this translation will happen in timely :fashion for at most 5 of the 38 languages leaving users of the other 33 :or more languages with a page they may not be able to read.
:This may not be an issue for you, but it is for me.
Perhaps you are adding in additinal languages that have such little use just to be able to say you offer a huge number of languages? If there was a real use for all of the others, then someone soudl; translate. Then again, you seem to already have the multi-languages built into the software so adding a template to the software would not be an issue. It is on the list owner to design the pages to fit his audience. This is not necessarily a replacement of what you have but rather an addition to which would make MM a lot better. Have MM look for the template in the appropriate location and itf it exists use it, if not use the dynamic page that currently exists. Heck simply adding that one IF statement to thr code would satisfy the objective.
--
Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 06/03/2013 05:06 AM, Janice Boothe wrote:
You are assuming that a list owner is allowing/offering more than his native language.
No, I am not. I am saying that if his list's language is one whose new template is untranslated in the new release, that page is broken for his list.
Even if he were, it is on him to code his custom pages with the capabilities to #include the appropriate language set.
You are ignoring the majority of sites/admins/list owners who do not customize their Mailman web UI.
The various strings that are used to build the page dynamically are translated in that language's message catalog. I suppose I could figure out how to pull them together to make a translated template, but it's way more work than I am willing to do, and I'm sure the result would be less than desirable.
As has been pointed out, this is an open source project. Please feel free to submit your implementation for consideration in a future Mailman 2.1 release. As far as Mailman 3/Postorius is concerned, I think this issue is already being addressed.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
--- On Mon, 6/3/13, Mark Sapiro <mark@msapiro.net> wrote:
On 06/03/2013 05:06 AM, Janice Boothe wrote:
You are assuming that a list owner is allowing/offering more than his native language.
:No, I am not. I am saying that if his list's language is one whose new :template is untranslated in the new release, that page is broken for his :list.
First thank you for continuing to discuss this with me. As I either have siad or intended to, this is not a personal attack on you or anyone else, it is feedback...
The templates should not have a thing to do with translations (IMHO) and even if they did it would be the list owner who elects to have custom pages to design his pages for all languages he offers. You are mistakenly thinking I am asking you to do much more than what I am.
Even if he were, it is on him to code his custom pages with the capabilities to #include the appropriate language set.
:You are ignoring the majority of sites/admins/list owners who do not :customize their Mailman web UI.
It is irrelevant discussion to those who chose to use the vanilla MM pages.
:The various strings that are used to build the page dynamically are :translated in that language's message catalog. I suppose I could figure :out how to pull them together to make a translated template, but it's :way more work than I am willing to do, and I'm sure the result would be :less than desirable.
I'm not sure what method you use to pull them together already in the vanilla version of the MM pages, but it seems that you ought to be able to use that exact same method for custom pages. But it all goes back to the fact that if someone wants custom pages they are the one responsible for writing them so that their languages are addressed. The whole thing can be addressed by simply adding some sort of IF loop around the body of code that generates the dynamic pages that have no template customization. Simply test for the presence of the appropriate file name in the appropriate location. If it exists use that and if not proceed with the dynamic build. I'd do it myself but to dig through the huge mass of code that the programmers already know and could easily modify would take someone such as myself (who knows nohting about what coding conventions are used etc) and extraordinary amount of time.
:As has been pointed out, this is an open source project. Please feel :free to submit your implementation for consideration in a future Mailman :2.1 release. As far as Mailman 3/Postorius is concerned, I think this :issue is already being addressed.
Does not my posts here seem to be recommendations?
I'd enjoy looking into MM3 but the link I was provided is at the very least obscure and extremely difficult to figure anything about the project. I looked there and absolutely have no idea in hell what is going on with the project, the status, the ETA, who is involved, who to contact about questions suggestions etc. If there is a link that is a little more user friendly I would love to get it and get on board.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 06/03/2013 04:12 PM, Janice Boothe wrote:
You seem to be looking at this from the point of view of a list/site admin who wants to make custom templates for her list/site.
My position however is that of a software developer/distributor who distributes a package that the majority of users expect to work "out of the box", regardless of which of the supported languages they use.
Even if he were, it is on him to code his custom pages with the capabilities to #include the appropriate language set.
No. He expects the package to work out of the box without requiring him to translate new templates into his language which is supposedly supported.
No. It is exactly the point of the discussion. Vanilla pages should work in all supported languages. Introducing new templates at this point breaks those pages until they are translated.
But it all goes back to the fact that if someone wants custom pages they are the one responsible for writing them so that their languages are addressed. The whole thing can be addressed by simply adding some sort of IF loop around the body of code that generates the dynamic pages that have no template customization.
I'm not concerned about the users who will make their own customized, translated pages. I'm concerned about those who don't want to.
Simply test for the presence of the appropriate file name in the appropriate location. If it exists use that and if not proceed with the dynamic build. I'd do it myself but to dig through the huge mass of code that the programmers already know and could easily modify would take someone such as myself (who knows nohting about what coding conventions are used etc) and extraordinary amount of time.
And for someone such as me who has been said to know the Mailman 2.1 code base better than anyone else, it is way more work than I am willing to do. I suppose I could make a template in which all the actual text was simply replacements from the current dynamically generated text. Then you couldn't customize the text, at least not directly, which semi-defeats the purpose of a template, but you could customize the HTML tags which might satisfy your requirement, but as I said, it's more than I (we're all unpaid volunteers, and I don't even have a day job) am willing to do.
The Mailman 2.1 branch is not the future of Mailman. I'm just the rear guard holding things together until Mailman 3 is ready for prime time
I'd enjoy looking into MM3 but the link I was provided is at the very least obscure and extremely difficult to figure anything about the project. I looked there and absolutely have no idea in hell what is going on with the project, the status, the ETA, who is involved, who to contact about questions suggestions etc. If there is a link that is a little more user friendly I would love to get it and get on board.
Try the wiki. Start here <http://wiki.list.org/display/DEV/Web+Interface> and here <http://wiki.list.org/display/DEV/Mailman+3.0>
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
--- On Wed, 6/5/13, Mark Sapiro <mark@msapiro.net> wrote:
From: Mark Sapiro <mark@msapiro.net> Subject: Re: [Mailman-Users] Custom Pages To: "Janice Boothe" <nursejanice@yahoo.com> Cc: "Mailman Users" <mailman-users@python.org> Date: Wednesday, June 5, 2013, 6:27 PM
On 06/03/2013 04:12 PM, Janice Boothe wrote:
:You seem to be looking at this from the point of view of a list/site :admin who wants to make custom templates for her list/site.
:My position however is that of a software developer/distributor who :distributes a package that the majority of users expect to work "out of :the box", regardless of which of the supported languages they use.
True to some extent. However as a developer (IMHO) one ought to code so that the software is usable by all. My coding convention is to allow end users to use the software without locking them into things like look and feel set to the way I personally like them. Working out of the box and being able to customize the look and feel are absolutely not mutually exclusive.
Even if he were, it is on him to code his custom pages with the capabilities to #include the appropriate language set.
:No. He expects the package to work out of the box without requiring him :to translate new templates into his language which is supposedly supported.
Both of these should be present. Simply allowing a template or custom page does not preclude the use of a dynamic page. I personally do not know how to do it in python, but it can be programmed so that after a test for a custom page is made, either the custom page (if it is present) is used or the default dynamic page is used if no custom page is present..
:No. It is exactly the point of the discussion. Vanilla pages should work :in all supported languages. Introducing new templates at this point :breaks those pages until they are translated.
Again you are thinking that allowing for a custom page precludes the use of a dynamic vanilla page. It does not have to be an either/or situation.
But it all goes back to the fact that if someone wants custom pages they are the one responsible for writing them so that their languages are addressed. The whole thing can be addressed by simply adding some sort of IF loop around the body of code that generates the dynamic pages that have no template customization.
:I'm not concerned about the users who will make their own customized, :translated pages. I'm concerned about those who don't want to.
Therein is the rub. This is (close to) the big issue that many have with Microsoft. Their nazi programming practices boil down to 'you will use our software the way we think it should look and you will like it" in that they offer very little customization (think IE v. FF). As programmers we ought to not be unconcerned with any of our end users.
Simply test for the presence of the appropriate file name in the appropriate location. If it exists use that and if not proceed with the dynamic build. I'd do it myself but to dig through the huge mass of code that the programmers already know and could easily modify would take someone such as myself (who knows nohting about what coding conventions are used etc) and extraordinary amount of time.
:And for someone such as me who has been said to know the Mailman 2.1 :code base better than anyone else, it is way more work than I am willing :to do. I suppose I could make a template in which all the actual text :was simply replacements from the current dynamically generated text. :Then you couldn't customize the text, at least not directly, which :semi-defeats the purpose of a template, but you could customize the HTML :tags which might satisfy your requirement, but as I said, it's more than :I (we're all unpaid volunteers, and I don't even have a day job) am :willing to do.
:The Mailman 2.1 branch is not the future of Mailman. I'm just the rear :guard holding things together until Mailman 3 is ready for prime time
I'd enjoy looking into MM3 but the link I was provided is at the very least obscure and extremely difficult to figure anything about the project. I looked there and absolutely have no idea in hell what is going on with the project, the status, the ETA, who is involved, who to contact about questions suggestions etc. If there is a link that is a little more user friendly I would love to get it and get on board.
Try the wiki. Start here <http://wiki.list.org/display/DEV/Web+Interface> and here <http://wiki.list.org/display/DEV/Mailman+3.0>
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 06/05/2013 07:49 PM, Janice Boothe wrote:
The difference is it's open source, not Microsoft proprietary. If you want a feature that's not supported, you have the code and the right to modify it in any way you wish or to pay someone else to do it for you, and if you wish, contribute your code back to the project.
Also, my attitude would be much different if we were talking about something that was not already at the end of its life cycle.
If you peruse the archives of this list, you'll see that comparing the Mailman project's support and concern for users of our software even peripherally to Microsoft does us a great disservice. If I gave the impression that I was telling you that your issue was not important, I apologize. I have only been trying to explain why I'm not interested in doing this thing in this case.
Of course, it would be much better if Mailman's entire web UI was much more easily customizable by end users. It is a worthwhile design goal that I think is embodied in Mailman 3, but when Mailman 2 was developed, just having a web UI at all was a major improvement over software like Majordomo, and much of the end user interface is template driven, just not all.
As far as the subscribe results page goes, as I pointed out earlier in this thread <http://mail.python.org/pipermail/mailman-users/2013-May/075202.html>, it is fairly easy to add a style sheet to this page.
Also, you could do what some others have done and create your own subscribe CGI, submit data from it to Mailman's subscribe CGI, receive the result from Mailman and parse it and present it to your user any way you like.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Guys,
Also, my attitude would be much different if we were talking about something that was not already at the end of its life cycle.
This brings me to a question I keep asking myself once every year for quite some time now:
What's up with MM3? Is there any indication on when it will be ready?
I really don't want to complain at people who donate spare time for good, please don't take this as offensive, but is there any indication of a release date or a mayor pre-release or, well, let's be honest: is there any progress at all?
I mean, the main wiki page http://wiki.list.org/display/DEV/Mailman+3.0 has been last updated 3 years ago. Still, their list of work to be done looks good - but that's probably only the tip of the work to be done. On the other hand the frontend works don't even seem to have begun properly (no templating engine chosen, only mockups)...
I really don't want to be impolite and I know that you aren't in charge, but: Do you know anything more than us? Is there any work going on? Is it dead?
I have been living with mailman limitations for so many years now and still it is one very reliable and great work of code - but still there's so much more this could be and let's face it: mailing lists aren't currently gaining ground as the web develops. I believe many people could have great use for a modern state of the art mailing engine with the features that are currently up to date.
Regards, jan
On Jun 06, 2013, at 02:52 PM, Jan Lausch wrote:
What's up with MM3? Is there any indication on when it will be ready?
Yes, although most of the conversation happens on mailman-developers these days. I expect we'll see a lot of great progress on Postorius (the new web ui) during this year's Google Summer of Code, which should bring that component much closer to release. We'll do a join release of the core + ui after that.
-Barry
On 06/06/2013 05:52 AM, Jan Lausch wrote:
I really don't want to complain at people who donate spare time for good, please don't take this as offensive, but is there any indication of a release date or a mayor pre-release or, well, let's be honest: is there any progress at all?
To add a bit to Barry's reply, there have been a few beta releases of the core. At least one site is using it in production.
Postorius is still alpha, but much is going on.
Look at the commits at <https://code.launchpad.net/~mailman-coders/mailman/3.0> and <https://code.launchpad.net/~mailman-coders/postorius/trunk> and the bug trackers and you'll see much is being done and many are involved.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Jan Lausch writes:
Yeah, this is a problem. There's been a lot of water flowed under that bridge since then, but you can only see it if you look at the source trees (I mean the NEWS files, not the .py files :-).
It would be nice if somebody would take a look at the state of the world and update the front page of the wiki and maybe ghost-write a blog entry for Barry.
I personally might be in a position to do it at reasonable personal cost around mid-summer (I'm mentoring a GSoC student so will need to get back up to speed on the state of the art), but not before then.
Steve
Dear all, Stephen J. Turnbull wrote:
Thanks for getting me up to speed. I am looking forward to the final thing and I think I just might give the beta a try this summer on a staging machine... And thank you for putting your free time into MM! You guys are great!
Best regards, Jan
Janice Boothe writes:
It seems rather odd and extremely limiting that Mailman functiuons as you describe in regards to confirm.
Yes, it's limiting, and the limitation was probably deliberate. Because the confirmation page is viewable by just about anybody, providing a customizable template would require non-trivial thought about its security.
Feel free to contribute styling. Functionality we do well. But we aren't designers ourselves, and we can't afford to hire good ones out of the revenue we receive from Mailman ($0).
If you lack the time (or perhaps skills) to contribute directly, you can definitely help by telling us more about your requirements. This probably won't help Mailman 2 much (for the reasons Mark gave), but would be very useful for Mailman 3.
There are some students being funded by Google Summer of Code to do work on Mailman 3 UI. If you would like to discuss your requirements with them (at any level of formality), let me know and I'll put you in touch with them.[1]
Steve
Footnotes: [1] I'm uncomfortable posting more detailed information because Google is quite sticky about privacy, and because their projects are not being directly supervised by Mailman. We're just consulting on the Mailman side of their things. They'd be doing us a favor outside of their Google internships.
On 05/30/2013 08:55 PM, Janice Boothe wrote:
I am writing some custom mailman pages top fit the theme of my site. I am stumped on setting up a custom confirm.html page. Please advise how I do this.
I'm not sure what you mean by confirm.html. If you mean the results of going to a URL like <http://www.example.com/mailman/confirm/list_name/some_string>, those results are all built on the fly by the Mailman/Cgi/confirm.py script.
There is a very limited control of color. See the section "Web UI defaults" in Mailman/Defaults.py for documentation. Beyond that any customization has to be done in the confirm.py module itself or in methods in Mailman/htmlformat.py.
Note that it is fairly simple to add a reference to a css style sheet to the Document.Format() method. See <http://mail.python.org/pipermail/mailman-users/2008-March/060881.html>.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Yes I do mean that. I used confirm.html since that is the naming convention used to create custom pages for much of the other IO of Mailman.
It seems rather odd and extremely limiting that Mailman functiuons as you describe in regards to confirm. Most of the other pages are customizable (listinfo, etc), why in the world would the programmers make such a choice to not allow site owners to customize the confirm page? Is this something that can be fixed in future releases as it should not be very hard to do? While I do like very much the functionality of Mailman, the default interface leaves a whole lot to be desired and lead to a very unprofessional look and feel when added to a site.
--- On Thu, 5/30/13, Mark Sapiro <mark@msapiro.net> wrote:
From: Mark Sapiro <mark@msapiro.net> Subject: Re: [Mailman-Users] Custom Pages To: "Janice Boothe" <nursejanice@yahoo.com> Cc: mailman-users@python.org Date: Thursday, May 30, 2013, 11:36 PM
On 05/30/2013 08:55 PM, Janice Boothe wrote:
I am writing some custom mailman pages top fit the theme of my site. I am stumped on setting up a custom confirm.html page. Please advise how I do this.
I'm not sure what you mean by confirm.html. If you mean the results of going to a URL like <http://www.example.com/mailman/confirm/list_name/some_string>, those results are all built on the fly by the Mailman/Cgi/confirm.py script.
There is a very limited control of color. See the section "Web UI defaults" in Mailman/Defaults.py for documentation. Beyond that any customization has to be done in the confirm.py module itself or in methods in Mailman/htmlformat.py.
Note that it is fairly simple to add a reference to a css style sheet to the Document.Format() method. See <http://mail.python.org/pipermail/mailman-users/2008-March/060881.html>.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 05/31/2013 01:26 PM, Janice Boothe wrote:
Some of Mailman's GUI web pages are built from templates such as listinfo.html, options.html and subscribe.html. Many others including the entire web admin interface and much of the admindb interface are not.
This wasn't as much of an issue when Mailman 2 was designed.
Is this something that can be fixed in future releases as it should not be very hard to do?
Well, I don't know about 'hard' but it won't happen in Mailman 2.1 for several reasons having mostly to do with i18n considerations and the fact that were it to be done, I'm the one who would do it with whatever help I could scrounge from the community.
On the other hand, Mailman 3 is a different story. In MM 3 the core mailing list functions communicate with the outside via a REST API. Anyone is free to develop whatever web UI they want to communicate with the core. The web UI that will ship with MM 3 is Postorius <https://launchpad.net/postorius> and I think you'll find it much more template driven than the MM 2 UI.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
--- On Fri, 5/31/13, Mark Sapiro <mark@msapiro.net> wrote:
:> Yes I do mean that. I used confirm.html since that is the naming :> convention used to create custom pages for much of the other IO of: :> Mailman. : :Some of Mailman's GUI web pages are built from templates such as :listinfo.html, options.html and subscribe.html. Many others including :the entire web admin interface and much of the admindb interface are not.
I understand this. It is the basis for teh discussion! :)
:> It seems rather odd and extremely limiting that Mailman functiuons as :> you describe in regards to confirm. Most of the other pages are :> customizable (listinfo, etc), why in the world would the programmers :> make such a choice to not allow site owners to customize the confirm :> page? : :This wasn't as much of an issue when Mailman 2 was designed.
OK
:> Is this something that can be fixed in future releases as it :> should not be very hard to do? : :Well, I don't know about 'hard' but it won't happen in Mailman 2.1 for :several reasons having mostly to do with i18n considerations and the :fact that were it to be done, I'm the one who would do it with whatever :help I could scrounge from the community.
Maybe because I am not fully aware of il8n but I fail to see how that is an issue. I know fo other software that uses end user selectable language sets and is highly customizable. Also the fact that a lot of the rest of MM uses templates kind of points to the possibility that the rest ought to be able to as well.
:On the other hand, Mailman 3 is a different story. In MM 3 the core :mailing list functions communicate with the outside via a REST API. :Anyone is free to develop whatever web UI they want to communicate with :the core. The web UI that will ship with MM 3 is Postorius :<https://launchpad.net/postorius> and I think you'll find it much more :template driven than the MM 2 UI.
I'll have to wit until the good folks at cpanel add MM3 before I can start using that.. :(
BTW thank for the work on this. I am not trying to kick your cat here at all, merely sending in feedback on how to improve the product.
On Jun 2, 2013, at 11:23 AM, Janice Boothe <nursejanice@yahoo.com> wrote:
Maybe because I am not fully aware of il8n but I fail to see how that is an issue. I know fo other software that uses end user selectable language sets and is highly customizable. Also the fact that a lot of the rest of MM uses templates kind of points to the possibility that the rest ought to be able to as well.
It's open-source software; grab a copy, and start working!
On 06/02/2013 08:23 AM, Janice Boothe wrote:
Maybe because I am not fully aware of il8n but I fail to see how that is an issue.
Mailman 2.1.15 supports 37 non-English translations. Mailman 2.1.16 will add Farsi to the list. Even assuming that switching to a template doesn't add or change any strings in the message catalog, any new template needs to be translated into 38 other languages. The users of a language for which the template has not been translated see a page built from the English template.
Thus, switching to a new template breaks that page for those users who prefer one of the 38 non-English languages until the template is translated into their language.
My experience tells me that this translation will happen in timely fashion for at most 5 of the 38 languages leaving users of the other 33 or more languages with a page they may not be able to read.
This may not be an issue for you, but it is for me.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
--- On Sun, 6/2/13, Mark Sapiro <mark@msapiro.net> wrote:
From: Mark Sapiro <mark@msapiro.net> Subject: Re: [Mailman-Users] Custom Pages To: "Janice Boothe" <nursejanice@yahoo.com> Cc: "Mailman Users" <mailman-users@python.org> Date: Sunday, June 2, 2013, 10:55 AM
On 06/02/2013 08:23 AM, Janice Boothe wrote:
Maybe because I am not fully aware of il8n but I fail to see how that is an issue.
:Mailman 2.1.15 supports 37 non-English translations. Mailman 2.1.16 will :add Farsi to the list. Even assuming that switching to a template :doesn't add or change any strings in the message catalog, any new :template needs to be translated into 38 other languages. The users of a :language for which the template has not been translated see a page built :from the English template.
:Thus, switching to a new template breaks that page for those users who :prefer one of the 38 non-English languages until the template is :translated into their language.
You are assuming that a list owner is allowing/offering more than his native language. Even if he were, it is on him to code his custom pages with the capabilities to #include the appropriate language set. That all can be done with language files with the translations of any given language for each translatable word/ phrase and parameters that call in the specific phrase form the users chosen language. If you have the dynamic ability to build a page based on the specific users chosen language, then you already have the capability to have custom pages do the same.
:My experience tells me that this translation will happen in timely :fashion for at most 5 of the 38 languages leaving users of the other 33 :or more languages with a page they may not be able to read.
:This may not be an issue for you, but it is for me.
Perhaps you are adding in additinal languages that have such little use just to be able to say you offer a huge number of languages? If there was a real use for all of the others, then someone soudl; translate. Then again, you seem to already have the multi-languages built into the software so adding a template to the software would not be an issue. It is on the list owner to design the pages to fit his audience. This is not necessarily a replacement of what you have but rather an addition to which would make MM a lot better. Have MM look for the template in the appropriate location and itf it exists use it, if not use the dynamic page that currently exists. Heck simply adding that one IF statement to thr code would satisfy the objective.
--
Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 06/03/2013 05:06 AM, Janice Boothe wrote:
You are assuming that a list owner is allowing/offering more than his native language.
No, I am not. I am saying that if his list's language is one whose new template is untranslated in the new release, that page is broken for his list.
Even if he were, it is on him to code his custom pages with the capabilities to #include the appropriate language set.
You are ignoring the majority of sites/admins/list owners who do not customize their Mailman web UI.
The various strings that are used to build the page dynamically are translated in that language's message catalog. I suppose I could figure out how to pull them together to make a translated template, but it's way more work than I am willing to do, and I'm sure the result would be less than desirable.
As has been pointed out, this is an open source project. Please feel free to submit your implementation for consideration in a future Mailman 2.1 release. As far as Mailman 3/Postorius is concerned, I think this issue is already being addressed.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
--- On Mon, 6/3/13, Mark Sapiro <mark@msapiro.net> wrote:
On 06/03/2013 05:06 AM, Janice Boothe wrote:
You are assuming that a list owner is allowing/offering more than his native language.
:No, I am not. I am saying that if his list's language is one whose new :template is untranslated in the new release, that page is broken for his :list.
First thank you for continuing to discuss this with me. As I either have siad or intended to, this is not a personal attack on you or anyone else, it is feedback...
The templates should not have a thing to do with translations (IMHO) and even if they did it would be the list owner who elects to have custom pages to design his pages for all languages he offers. You are mistakenly thinking I am asking you to do much more than what I am.
Even if he were, it is on him to code his custom pages with the capabilities to #include the appropriate language set.
:You are ignoring the majority of sites/admins/list owners who do not :customize their Mailman web UI.
It is irrelevant discussion to those who chose to use the vanilla MM pages.
:The various strings that are used to build the page dynamically are :translated in that language's message catalog. I suppose I could figure :out how to pull them together to make a translated template, but it's :way more work than I am willing to do, and I'm sure the result would be :less than desirable.
I'm not sure what method you use to pull them together already in the vanilla version of the MM pages, but it seems that you ought to be able to use that exact same method for custom pages. But it all goes back to the fact that if someone wants custom pages they are the one responsible for writing them so that their languages are addressed. The whole thing can be addressed by simply adding some sort of IF loop around the body of code that generates the dynamic pages that have no template customization. Simply test for the presence of the appropriate file name in the appropriate location. If it exists use that and if not proceed with the dynamic build. I'd do it myself but to dig through the huge mass of code that the programmers already know and could easily modify would take someone such as myself (who knows nohting about what coding conventions are used etc) and extraordinary amount of time.
:As has been pointed out, this is an open source project. Please feel :free to submit your implementation for consideration in a future Mailman :2.1 release. As far as Mailman 3/Postorius is concerned, I think this :issue is already being addressed.
Does not my posts here seem to be recommendations?
I'd enjoy looking into MM3 but the link I was provided is at the very least obscure and extremely difficult to figure anything about the project. I looked there and absolutely have no idea in hell what is going on with the project, the status, the ETA, who is involved, who to contact about questions suggestions etc. If there is a link that is a little more user friendly I would love to get it and get on board.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 06/03/2013 04:12 PM, Janice Boothe wrote:
You seem to be looking at this from the point of view of a list/site admin who wants to make custom templates for her list/site.
My position however is that of a software developer/distributor who distributes a package that the majority of users expect to work "out of the box", regardless of which of the supported languages they use.
Even if he were, it is on him to code his custom pages with the capabilities to #include the appropriate language set.
No. He expects the package to work out of the box without requiring him to translate new templates into his language which is supposedly supported.
No. It is exactly the point of the discussion. Vanilla pages should work in all supported languages. Introducing new templates at this point breaks those pages until they are translated.
But it all goes back to the fact that if someone wants custom pages they are the one responsible for writing them so that their languages are addressed. The whole thing can be addressed by simply adding some sort of IF loop around the body of code that generates the dynamic pages that have no template customization.
I'm not concerned about the users who will make their own customized, translated pages. I'm concerned about those who don't want to.
Simply test for the presence of the appropriate file name in the appropriate location. If it exists use that and if not proceed with the dynamic build. I'd do it myself but to dig through the huge mass of code that the programmers already know and could easily modify would take someone such as myself (who knows nohting about what coding conventions are used etc) and extraordinary amount of time.
And for someone such as me who has been said to know the Mailman 2.1 code base better than anyone else, it is way more work than I am willing to do. I suppose I could make a template in which all the actual text was simply replacements from the current dynamically generated text. Then you couldn't customize the text, at least not directly, which semi-defeats the purpose of a template, but you could customize the HTML tags which might satisfy your requirement, but as I said, it's more than I (we're all unpaid volunteers, and I don't even have a day job) am willing to do.
The Mailman 2.1 branch is not the future of Mailman. I'm just the rear guard holding things together until Mailman 3 is ready for prime time
I'd enjoy looking into MM3 but the link I was provided is at the very least obscure and extremely difficult to figure anything about the project. I looked there and absolutely have no idea in hell what is going on with the project, the status, the ETA, who is involved, who to contact about questions suggestions etc. If there is a link that is a little more user friendly I would love to get it and get on board.
Try the wiki. Start here <http://wiki.list.org/display/DEV/Web+Interface> and here <http://wiki.list.org/display/DEV/Mailman+3.0>
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
--- On Wed, 6/5/13, Mark Sapiro <mark@msapiro.net> wrote:
From: Mark Sapiro <mark@msapiro.net> Subject: Re: [Mailman-Users] Custom Pages To: "Janice Boothe" <nursejanice@yahoo.com> Cc: "Mailman Users" <mailman-users@python.org> Date: Wednesday, June 5, 2013, 6:27 PM
On 06/03/2013 04:12 PM, Janice Boothe wrote:
:You seem to be looking at this from the point of view of a list/site :admin who wants to make custom templates for her list/site.
:My position however is that of a software developer/distributor who :distributes a package that the majority of users expect to work "out of :the box", regardless of which of the supported languages they use.
True to some extent. However as a developer (IMHO) one ought to code so that the software is usable by all. My coding convention is to allow end users to use the software without locking them into things like look and feel set to the way I personally like them. Working out of the box and being able to customize the look and feel are absolutely not mutually exclusive.
Even if he were, it is on him to code his custom pages with the capabilities to #include the appropriate language set.
:No. He expects the package to work out of the box without requiring him :to translate new templates into his language which is supposedly supported.
Both of these should be present. Simply allowing a template or custom page does not preclude the use of a dynamic page. I personally do not know how to do it in python, but it can be programmed so that after a test for a custom page is made, either the custom page (if it is present) is used or the default dynamic page is used if no custom page is present..
:No. It is exactly the point of the discussion. Vanilla pages should work :in all supported languages. Introducing new templates at this point :breaks those pages until they are translated.
Again you are thinking that allowing for a custom page precludes the use of a dynamic vanilla page. It does not have to be an either/or situation.
But it all goes back to the fact that if someone wants custom pages they are the one responsible for writing them so that their languages are addressed. The whole thing can be addressed by simply adding some sort of IF loop around the body of code that generates the dynamic pages that have no template customization.
:I'm not concerned about the users who will make their own customized, :translated pages. I'm concerned about those who don't want to.
Therein is the rub. This is (close to) the big issue that many have with Microsoft. Their nazi programming practices boil down to 'you will use our software the way we think it should look and you will like it" in that they offer very little customization (think IE v. FF). As programmers we ought to not be unconcerned with any of our end users.
Simply test for the presence of the appropriate file name in the appropriate location. If it exists use that and if not proceed with the dynamic build. I'd do it myself but to dig through the huge mass of code that the programmers already know and could easily modify would take someone such as myself (who knows nohting about what coding conventions are used etc) and extraordinary amount of time.
:And for someone such as me who has been said to know the Mailman 2.1 :code base better than anyone else, it is way more work than I am willing :to do. I suppose I could make a template in which all the actual text :was simply replacements from the current dynamically generated text. :Then you couldn't customize the text, at least not directly, which :semi-defeats the purpose of a template, but you could customize the HTML :tags which might satisfy your requirement, but as I said, it's more than :I (we're all unpaid volunteers, and I don't even have a day job) am :willing to do.
:The Mailman 2.1 branch is not the future of Mailman. I'm just the rear :guard holding things together until Mailman 3 is ready for prime time
I'd enjoy looking into MM3 but the link I was provided is at the very least obscure and extremely difficult to figure anything about the project. I looked there and absolutely have no idea in hell what is going on with the project, the status, the ETA, who is involved, who to contact about questions suggestions etc. If there is a link that is a little more user friendly I would love to get it and get on board.
Try the wiki. Start here <http://wiki.list.org/display/DEV/Web+Interface> and here <http://wiki.list.org/display/DEV/Mailman+3.0>
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 06/05/2013 07:49 PM, Janice Boothe wrote:
The difference is it's open source, not Microsoft proprietary. If you want a feature that's not supported, you have the code and the right to modify it in any way you wish or to pay someone else to do it for you, and if you wish, contribute your code back to the project.
Also, my attitude would be much different if we were talking about something that was not already at the end of its life cycle.
If you peruse the archives of this list, you'll see that comparing the Mailman project's support and concern for users of our software even peripherally to Microsoft does us a great disservice. If I gave the impression that I was telling you that your issue was not important, I apologize. I have only been trying to explain why I'm not interested in doing this thing in this case.
Of course, it would be much better if Mailman's entire web UI was much more easily customizable by end users. It is a worthwhile design goal that I think is embodied in Mailman 3, but when Mailman 2 was developed, just having a web UI at all was a major improvement over software like Majordomo, and much of the end user interface is template driven, just not all.
As far as the subscribe results page goes, as I pointed out earlier in this thread <http://mail.python.org/pipermail/mailman-users/2013-May/075202.html>, it is fairly easy to add a style sheet to this page.
Also, you could do what some others have done and create your own subscribe CGI, submit data from it to Mailman's subscribe CGI, receive the result from Mailman and parse it and present it to your user any way you like.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Guys,
Also, my attitude would be much different if we were talking about something that was not already at the end of its life cycle.
This brings me to a question I keep asking myself once every year for quite some time now:
What's up with MM3? Is there any indication on when it will be ready?
I really don't want to complain at people who donate spare time for good, please don't take this as offensive, but is there any indication of a release date or a mayor pre-release or, well, let's be honest: is there any progress at all?
I mean, the main wiki page http://wiki.list.org/display/DEV/Mailman+3.0 has been last updated 3 years ago. Still, their list of work to be done looks good - but that's probably only the tip of the work to be done. On the other hand the frontend works don't even seem to have begun properly (no templating engine chosen, only mockups)...
I really don't want to be impolite and I know that you aren't in charge, but: Do you know anything more than us? Is there any work going on? Is it dead?
I have been living with mailman limitations for so many years now and still it is one very reliable and great work of code - but still there's so much more this could be and let's face it: mailing lists aren't currently gaining ground as the web develops. I believe many people could have great use for a modern state of the art mailing engine with the features that are currently up to date.
Regards, jan
On Jun 06, 2013, at 02:52 PM, Jan Lausch wrote:
What's up with MM3? Is there any indication on when it will be ready?
Yes, although most of the conversation happens on mailman-developers these days. I expect we'll see a lot of great progress on Postorius (the new web ui) during this year's Google Summer of Code, which should bring that component much closer to release. We'll do a join release of the core + ui after that.
-Barry
On 06/06/2013 05:52 AM, Jan Lausch wrote:
I really don't want to complain at people who donate spare time for good, please don't take this as offensive, but is there any indication of a release date or a mayor pre-release or, well, let's be honest: is there any progress at all?
To add a bit to Barry's reply, there have been a few beta releases of the core. At least one site is using it in production.
Postorius is still alpha, but much is going on.
Look at the commits at <https://code.launchpad.net/~mailman-coders/mailman/3.0> and <https://code.launchpad.net/~mailman-coders/postorius/trunk> and the bug trackers and you'll see much is being done and many are involved.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Jan Lausch writes:
Yeah, this is a problem. There's been a lot of water flowed under that bridge since then, but you can only see it if you look at the source trees (I mean the NEWS files, not the .py files :-).
It would be nice if somebody would take a look at the state of the world and update the front page of the wiki and maybe ghost-write a blog entry for Barry.
I personally might be in a position to do it at reasonable personal cost around mid-summer (I'm mentoring a GSoC student so will need to get back up to speed on the state of the art), but not before then.
Steve
Dear all, Stephen J. Turnbull wrote:
Thanks for getting me up to speed. I am looking forward to the final thing and I think I just might give the beta a try this summer on a staging machine... And thank you for putting your free time into MM! You guys are great!
Best regards, Jan
Janice Boothe writes:
It seems rather odd and extremely limiting that Mailman functiuons as you describe in regards to confirm.
Yes, it's limiting, and the limitation was probably deliberate. Because the confirmation page is viewable by just about anybody, providing a customizable template would require non-trivial thought about its security.
Feel free to contribute styling. Functionality we do well. But we aren't designers ourselves, and we can't afford to hire good ones out of the revenue we receive from Mailman ($0).
If you lack the time (or perhaps skills) to contribute directly, you can definitely help by telling us more about your requirements. This probably won't help Mailman 2 much (for the reasons Mark gave), but would be very useful for Mailman 3.
There are some students being funded by Google Summer of Code to do work on Mailman 3 UI. If you would like to discuss your requirements with them (at any level of formality), let me know and I'll put you in touch with them.[1]
Steve
Footnotes: [1] I'm uncomfortable posting more detailed information because Google is quite sticky about privacy, and because their projects are not being directly supervised by Mailman. We're just consulting on the Mailman side of their things. They'd be doing us a favor outside of their Google internships.
participants (6)
-
Barry Warsaw -
Jan Lausch -
Janice Boothe -
Mark Sapiro -
Stephen J. Turnbull -
Steve Burling