Skip to end of metadata
Go to start of metadata

Current status

The most serious effort at adding templating to Mailman is Ethan Fremen's SoC 2006 project.

The initial goals are described on Summer of Code.

The last-known status is described on Summer of Code 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?

Labels
  • None
  1. Apr 23, 2007

    Certainly, nothing's set in stone yet, but I have a couple of strong preferences:

    • One templating system to rule them all. IOW, we use the same templating system for the web u/i as we do for the archiver
    • 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.
  2. Apr 24, 2007

    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.

  3. May 01, 2007

    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.

  4. May 01, 2007

    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.

  5. May 03, 2007

    Lazily copied from my email to the list for reference (smile)

    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?