[Mailman-Developers] suggestions for i18n

[Barry A. Warsaw]

>>>>> "JR" == John Read <john.read@newnet-marketing.de> writes:

    JR> I have a suggestion how this can be done very easily. If the
    JR> function maketext (in Utils) had an addition parameter "list",
    JR> it could first try to open the text file in
    JR> mailman/list/"listname"/"lang". If the file is not there, then
    JR> it could continue to take it from /mailman/templates/"lang" as
    JR> you have coded it. This would mean that if the list manager
    JR> wanted to put special messages in a list he can create them in
    JR> the list/"listname"/"lang"/....... directory. The normal list
    JR> manager would not notice any difference.

That sounds like a good idea.

    JR> I have another question. In the v2.1 expected functions, you
    JR> have listed the function to enter the full name. This leads
    JR> onto a completely new set of possibilities with links into
    JR> databases, and personalised mailings, etc. I can imagine that
    JR> all these possibilities are too complex to fit into one
    JR> program (mailman), but what about an simple API where the
    JR> completed email (with associated data) could be presented to
    JR> another application for further processing, eg filling fields
    JR> in the email from a db. Applications could then designed
    JR> separately by other groups, and slotted in required by the
    JR> list managers.

Here's how I would envision that.  Let's say you had a list for which
you wanted to do some extra prep work on messages before they were
sent out.  You would write a module for the Handlers directory which
performed this prep work.  This module would hid all the communication
with the external service.

Next, you'd figure out where in the normal message pipeline you want
your special module to go.  Now you have two choices:

- you can add your module to the global pipeline, and only perform the
  work when you see a message destined for one of your special lists
  (the MailList object gets passed as a parameter to your module's
  process() function).

- you can specialize your list's pipeline to include your new module.
  In 2.1 the main processing qrunner (IncomingRunner) looks in three
  places for a pipeline to process the message on: the message's
  metadata (used primarily for requeued messages), the MailList
  object's `pipeline' attribute, then the global pipeline.

  There probably won't be a convenient API for setting the list's
  pipeline at first, but it would be trivial to write a withlist
  script to add it.

Make sense?

-Barry