Current status
The most serious effort at adding templating to Mailman is Ethan Fremen's SoC 2006 project.
The initial goals are described on Google Summer of Code 2006.
The last-known status is described on his August 2006 summary.
As a first step, we'll work on using CSS in the existing 2.1 codebase.
Questions
The templating toolkit used is Genshi: valid-XML templates, with attributes and elements
as the markers for special behaviour and $var for variables. Worth revisiting this decision?
What about Werkzeug and jinja2?
Comments
Regarding the comment "we need to have markup to indicate translatable strings". I would like to comment that we have developed a technique that is able to extract messages from a XHTML file without any specific markup. To make it happen it makes a difference between block and inline elements.
It is also able to segment a text, so if a paragraph has several sentences it will extract them as different message ids.
You can give it a try, just download latest itoolsitools. Once installed the script try:
$ igettext-extract SOMEFILE.xhtml.en > fr.po
It will produce a PO file. Then you can translate this PO file and type:
$ igettext-build SOMEFILE.xhtml.en fr.po > SOMEFILE.xhtml.fr
This command will produce a new XHTML file that is the translation of the source file.
This technique produces good quality messages for the translator, and is a bless for the developer.
I wouldn't mind sticking to Genshi (there is the basics of an i18n approach in the Genshi wiki). I think to start the low-hanging fruit is to change styling over to stylesheets and then deal with the templating issue.
I agree with Ethan, since Barry is working on disruptive parts of the trunk, it would be best to start with the more basic task of getting everything styled by CSS. It might also inform us about problems that will come up when moving to the template engine. I have no experience with any of the Python engines, so I'll follow the lead of others on that.
I would like to suggest that we make sure when code is edited to move styling out, that a comment is inserted so we can find those changes easily later (since all that code will one day have to be removed). If we only removing styling information, that wont find all the code by any stretch, but it would be a starting place.
Lazily copied from my email to the list for reference
Can I request that if the templates are being re-written some attention should
be paid to the idea of making Mailman embeddable within a parent site's HTML
framework and styles. For example, I run a system called HepForge where several
types of web technology are hidden behind Apache and the page headers and
footers, including CSS imports, are added by Apache output filters. A
significant amount of work is required to edit Trac and Mailman templates to
make them work with this sort of system - see
http://trac.edgewall.org/ticket/4264 for a bit more detail on the issues with Trac.
In particular, it would be really nice if
the bits of the template which define <head>, <body> etc. are defined in one
pair of header and footer files, so they can be turned off easily.the proposed Mailman CSS files "namespace" everything by placing all Mailman
content within a div, e.g. <div id="mailman">...</div> and then prefix all CSS
rules with "#mailman" - this stops the Mailman styles from leaking out into the
parent page elements.
Sorry to dwell on implementation specifics at this stage, but it's an issue
that's often ignored but is actually pretty important. I can add this to the
wiki if it's relevant?
Genshi has been mentioned a few times. My impression was that it insists on
producing valid XML output, which is nice, but doesn't necessarily play well
with ideas like factorisable head/foot portions. Also, can it be used for
templating the automated email messages, i.e. plain text? I'm not speaking from
exceptional familiarity with Genshi here, but these suspicions made me use
Cheetah in place of Genshi for one of our projects... can anyone confirm/refute?
Certainly, nothing's set in stone yet, but I have a couple of strong preferences:
Must be i18n-friendly, which basically means (I think), we need to have markup to indicate translatable strings, we need a script to extract those strings into gettext format, and we need to be able to do translation as we generate the final html.
I like $-strings because I think they're the easiest for translators to deal with. I'm not fond of %-strings, and PEP 3101 strings probably aren't feasible.