Re: [Mailman-Developers] suggestions for i18n
"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.
That's exactly what my "per-list template" patch, which I've been reworking for every version since 2.0beta1, does. I figure the I18N stuff will completely make the patch invalid, but "first look in the list directory" is the easy poor-man's 'list-specific' hack. The only problem you had with it, Barry, as I remember, was the minor ugliness of "passing the list around to maketext". I ended up passing list._full_name just to keep *some* of the data abstraction in place, but was never really satisfied with the solution. Maybe there should be a "get list directory" method.
"DM" == Dan Mick dmick@utopia.west.sun.com writes:
DM> That's exactly what my "per-list template" patch, which I've
DM> been reworking for every version since 2.0beta1, does. I
DM> figure the I18N stuff will completely make the patch invalid,
DM> but "first look in the list directory" is the easy poor-man's
DM> 'list-specific' hack. The only problem you had with it,
DM> Barry, as I remember, was the minor ugliness of "passing the
DM> list around to maketext". I ended up passing list._full_name
DM> just to keep *some* of the data abstraction in place, but was
DM> never really satisfied with the solution. Maybe there should
DM> be a "get list directory" method.Ah, good, thanks for the reminder Dan. Okay, once the language stuff is solidified I'll look at your patch and work it in.
-Barry
participants (2)
-
barry＠digicool.com -
Dan Mick