html-template-users Mailing List for HTML::Template (Page 42)

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Solved: because PerlSendHeader is on, I needed to send at least a
content-type header. Sorry to waste the list's time, and thanks very
much to those who responded.

-fred

On Wed, 1 Sep 2004 22:36:26 -0400 (EDT), Sam Tregar <sa...@tr...> wrote:
> On Wed, 1 Sep 2004, Fred Condo wrote:
> 
> > I've attached the simple test template and script to this message.
> 
> I tried your test with Perl 5.8.3 and HTML::Template 2.7.  The first
> line was printed in the output.  What version of HTML::Template are
> you using?

2.7 from the FreeBSD ports. I'm starting to think that Karen Cravens
is right: something is eating the line.

As a test, I ran the script from the command line, and the first line
shows up. Running under mod_perl, the first line vanishes. This is
also the first time I've worked in the mod_perl environment. Am I
making an incredibly boneheaded gaffe in the code?

On Thu, 2 Sep 2004 11:54:42 -0500, Karen Cravens
<kar...@gm...> wrote:
> On Wed, 1 Sep 2004 19:10:49 -0700, Fred Condo <fre...@gm...> wrote:
> > I probably should have mentioned platform info:
> 
> Possibly even more important:  what are you using to *read* the
> output?  That is, are you sure that your script isn't sending it only
> to have it eaten by something else?

Safari at first, but the same thing happens with wget and with Mozilla
1.7.2. However--I noticed when looking at the file with Mozilla and
wget that the MIME type Apache is sending is text/plain.

> 
> What happens if you put the DOCTYPE declaration all on one line?

It vanishes. The first line, regardless of content, goes away unconditionally.

On Wed, 1 Sep 2004, Fred Condo wrote:

> I've attached the simple test template and script to this message.

I tried your test with Perl 5.8.3 and HTML::Template 2.7.  The first
line was printed in the output.  What version of HTML::Template are
you using?

-sam

On Wed, 1 Sep 2004 02:22:45 -0500, Charles K. Clarkson
<ccl...@ht...> wrote:
> From: htm...@li... <> wrote:
> 
> : I've just begun using HTML::Template, and have run into
> 
> 
> : the issue that the first line of the simplest template
> : gets unconditionally deleted. I noticed this when my
> : DOCTYPE got mangled in the output. Adding a newline at
> : the top of the file, naturally, fixes this.
> :
> : Is this a known bug? I searched the mailing list archive,
> : the buglist, and the discussions, but saw no mention of
> : it. I'm hoping someone will go "aha, it's that..."
> 
>     You'll probably need to show us your code. If we can
> reproduce the error we might be able to tell you the
> problem.

I've attached the simple test template and script to this message.

I probably should have mentioned platform info:

FreeBSD 4.10-RELEASE-p2
Perl 5.8.5
Apache from the ports: apache+mod_ssl-1.3.31+2.8.19
add'l Apache modules: mod_perl-1.29, mod_auth_mysql-2.20_3, mod_gzip-1.3.26.1a

Thanks for the response!

Fred Condo wrote:
> I've just begun using HTML::Template, and have run into the issue that
> the first line of the simplest template gets unconditionally deleted.
> I noticed this when my DOCTYPE got mangled in the output. Adding a
> newline at the top of the file, naturally, fixes this.
> 
> Is this a known bug? I searched the mailing list archive, the buglist,
> and the discussions, but saw no mention of it. I'm hoping someone will
> go "aha, it's that..."
> 
> Thanks.
> 

Is it possible that line is composed of a variable that isn't defined in 
your Perl file?
In HTML::Template, if you use a variable and that variable is then not 
defined in the Perl file, your output file will simply have a blank 
where that variable was. This is a feature, not a bug :-)
Look for a typo or something similiar...

-- 
Offer Kaye

Martin Sarfy wrote:

>Hi folks,
>
>I lack multiple language support in HTML::Template.=20
> =20
>
Hi,
(back from holidays, hence the late answer)

The Koha project (www.koha.org) uses HTML::Template.
and has several languages (english, french, polish, chinese, others to co=
me)

To do this, we wrote a script that create a .po file and create the
translated templates from this po & the english templates.
works quite fine.
(look on sourceforge.net, projet koha, the script is hidden on
koha/misc/translator/tmpl_process3.pl)

--=20
Paul POULAIN
Consultant ind=E9pendant en logiciels libres
responsable francophone de koha (SIGB libre http://www.koha-fr.org)

From: htm...@li... <> wrote:

: I've just begun using HTML::Template, and have run into
: the issue that the first line of the simplest template
: gets unconditionally deleted. I noticed this when my
: DOCTYPE got mangled in the output. Adding a newline at
: the top of the file, naturally, fixes this. 
: 
: Is this a known bug? I searched the mailing list archive,
: the buglist, and the discussions, but saw no mention of
: it. I'm hoping someone will go "aha, it's that..." 

    You'll probably need to show us your code. If we can
reproduce the error we might be able to tell you the
problem.

HTH,

Charles K. Clarkson
-- 
Mobile Homes Specialist
254 968-8328

Sometime on Aug 31, Fred Condo assembled some asciibets to say:

> I've just begun using HTML::Template, and have run into the issue that
> the first line of the simplest template gets unconditionally deleted.
> I noticed this when my DOCTYPE got mangled in the output. Adding a

Doesn't happen for me.

-- 
'I'll tell you this!' shouted Rincewind. 'I'd rather trust me than history! Oh, shit, did I just say that?'
(Interesting Times)

I've just begun using HTML::Template, and have run into the issue that
the first line of the simplest template gets unconditionally deleted.
I noticed this when my DOCTYPE got mangled in the output. Adding a
newline at the top of the file, naturally, fixes this.

Is this a known bug? I searched the mailing list archive, the buglist,
and the discussions, but saw no mention of it. I'm hoping someone will
go "aha, it's that..."

Thanks.

Markus Spring wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Martin Sarfy wrote:
> | Hi folks,
> |
> | I lack multiple language support in HTML::Template.
..SNIP..
> 3 is done by subclassing HTML::Template to recognize filter arguments as 
> a part
> of the cache key (idea and code from Cees Hek), so that localization of the
> templates is done once before caching.

Hi Markus,

Since Sam has now pulled out the cache key generation into it's own
function, much of the patch that I wrote 2 years ago is no longer really
needed.  You can override the _cache_key in your subclass and have it
include the filter args in the generation of the cache key.

The only part that would still be needed is the filter args support
(which was a very small part of the patch).

For those interested in the thread discussing this stuff:

http://www.mail-archive.com/htm...@li.../msg00661.html

Mind you that was over 2 years ago, so I wouldn't recommend using that
patch since it is against 2.5 (or 2.4, I can't remember).  Adding the
filter ags support would be trivial to 2.7 with the availability of the
new _cache_key method.

> If there is interest for this solution, I could pack up the code but it 
> might
> take some days as I am in holidays.

I no longer need support for this, but feel free to strip the old patch
and make it work with 2.7.  It should be much simpler, and maybe a
worthwhile addition to HTML::Template in the next version.

Cheers,

Cees

ps I originally sent this earlier today, but from the wrong account, so 
the original message is sitting in the moderator queue.  Not knowing how 
long it will sit there, I thought I would resend it.  Hopefully the 
duplicate will be denied by the moderator.

On Fri, Aug 27, 2004 at 03:33:23PM +0200, Markus Spring wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Martin Sarfy wrote:
> | Hi folks,
> |
> | I lack multiple language support in HTML::Template.
> 
> My way to do it is as following:
> 
> 1 Have Templates in one basic language
> 2 Use Locale::Maketext as basic functionality to retrieve localized text 
> strings
> 3 Use template filters during load_tmpl to localize text between tags as 
> well as
> text in certain tag attributes, especially alt="" and title="". Replacement
> strings come from Locale::Maketext
> 4 localize your variable values from inside your program before submitting 
> those
> as template variables
> 
> 3 is done by subclassing HTML::Template to recognize filter arguments as a 
> part
> of the cache key (idea and code from Cees Hek), so that localization of the
> templates is done once before caching.
> 
> If there is interest for this solution, I could pack up the code but it 
> might
> take some days as I am in holidays.

Thanks, I'll do it this way.

Happy holidays

Martin

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Martin Sarfy wrote:
| Hi folks,
|
| I lack multiple language support in HTML::Template.

My way to do it is as following:

1 Have Templates in one basic language
2 Use Locale::Maketext as basic functionality to retrieve localized text strings
3 Use template filters during load_tmpl to localize text between tags as well as
text in certain tag attributes, especially alt="" and title="". Replacement
strings come from Locale::Maketext
4 localize your variable values from inside your program before submitting those
as template variables

3 is done by subclassing HTML::Template to recognize filter arguments as a part
of the cache key (idea and code from Cees Hek), so that localization of the
templates is done once before caching.

If there is interest for this solution, I could pack up the code but it might
take some days as I am in holidays.

Kind regards

Markus Spring
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBLzgjxxUzQSse11ARAgPeAJwKUz/4IVcvGB1++tfrQlyozqUQpgCgjKki
XLiJfJdKBow3zrpDNsP3oqQ=
=I11g
-----END PGP SIGNATURE-----

* Martin Sarfy <sa...@ic...> [August 24 2004, 23:23]:
> > > Using <TMPL_IF lang=""> construct isn't appropriate for several reasons:
> > >   -- $lang is not accessible in <TMPL_LOOP> context
> > Use global_vars and it will be.
> It's good that global_vars is not set by default, clean namespace in 
> <TMPL_LOOP> is advantage and I don't want to turn it on only because
> translations.

  And global_vars slow down processing by a factor of 4. I once was
very surprised with a profile where HTML::Template::output took more
than 40% of execution time.

-- 
Alex Kapranoff.

> On Tue, 24 Aug 2004, Martin Sarfy wrote:
>=20
> Using <TMPL_IF lang=3D""> construct isn't appropriate for several =
reasons:
>=20
>   -- $lang is not accessible in <TMPL_LOOP> context
>   -- it's too clumsy for manual writting
>   -- <TMPL_IF> is not 'system' solution, it cannot handle e.g.
>      substitution of similar languages or so.

Hi Martin.

You seem to be attacking your project with a sledgehammer.

There is always an elegant solution hiding somewhere,
but you have to slow down enough to look for it.

Have you heard that tale of 2 programmers?
They have an idea and one starts coding=20
The other sits down and thinks and plans and when the first is halfway =
through,=20
the second starts coding and finishes first. His program works, is =
extensible=20
and scalable and first one is reminiscent of spaghetti with a huge =
dollop of lard in it.

Alan.

Here's the solution I applied to this program in a project of mine.

In my templates, I prefix my tokens with lang_. 
e.g.: <TMPL_VAR lang_address>, <TMPL_VAR lang_real_name>, etc...

Then, I overloaded HTML::Template and used my own new method to which, on
top of the usual HTML::Template parameters, I pass the language I want to
use.

In there, I loop through each template parameter, and if it starts with
lang_, I look up the proper value in a dictionary system of my own.

I also use the same functionality for capitalizing tokens. In that case, I
suffix the tokens with _caps.

That way, I can have only one template, and the graphic people can't really
mess it up :)

Hope that helps,

Fred Hurtubise

-----Message d'origine-----
I can't imagine how to use it, how to enclose string in template file
and how to call gettext() function (this has to be called from within 
HTML::Template code).

I think ability to write templates in several languages is common
requirement, so common that built-in support in templating engine should 
be considered. 

On Tue, Aug 24, 2004 at 12:07:32PM -0400, Sam Tregar wrote:
> On Tue, 24 Aug 2004, Martin Sarfy wrote:
> 
> > Using <TMPL_IF lang=""> construct isn't appropriate for several reasons:
> > 
> >   -- $lang is not accessible in <TMPL_LOOP> context
> 
> Use global_vars and it will be.

It's good that global_vars is not set by default, clean namespace in 
<TMPL_LOOP> is advantage and I don't want to turn it on only because
translations.

> >   -- it's too clumsy for manual writting
> 
> I don't understand what you mean by this.  If you consider
> HTML::Template's syntax to be too clumsy then why are you using it?

Syntax is perfect because many designers are able to learn it
and work of programmer and designer can be splitted, now I'm talking
about work of translator, who needs some easy to understand/use syntax, 
he cannot write <TMPL_IF VAR="lang"> logic for every label he
wants to translate.

> >   -- <TMPL_IF> is not 'system' solution, it cannot handle e.g.
> >      substitution of similar languages or so.
> 
> You can handle that in your code.  I'm certainly not going to add an
> exhaustive list of languages and their synonyms to HTML::Template!
> 
> > Or should I use GNU gettext in some way?
> 
> Possibly.  I've seen it used in similar situations, but I've never
> used it myself.

I can't imagine how to use it, how to enclose string in template file
and how to call gettext() function (this has to be called from within 
HTML::Template code).

I think ability to write templates in several languages is common
requirement, so common that built-in support in templating engine should 
be considered. 

-- 
Martin Sarfy

Mark, first of all, thank you for a wonderful piece of expirience!
Your way of separating things definitely worth attention. I'm going to
try it for my next i18n-enabled project.

One little thing I'd like to mention. Let us all use full locale names
instead of ISO language codes.

de_DE.ISO8859-1 or en_US.ASCII may seem a little too verbose, but in
addition to language code they contain country code (which may or may
not be useful) and charset name (which is VERY useful). So that one
could create and use, e.g. both ru_RU.KOI8-R and ru_RU.CP1251 set of
internationalized items. Alas, the world is more complex with CJK
encodings and customers over there will appreciate it even more than
russians.

* Mark A. Fuller <mar...@ea...> [August 24 2004, 21:43]:
> I understand what he's saying. When initially facing the chore of
> international language support, it's perplexing how to balance
> between language specific templates, replaceable text, and some
> replaceable text which is pull-down values you'd more naturally
> consider to be part of the template.

[skip]

-- 
Alex Kapranoff.

From: Sam Tregar <sa...@tr...>
>>   -- it's too clumsy for manual writting
>
>I don't understand what you mean by this.  If you consider
>HTML::Template's syntax to be too clumsy then why are you using it?

I understand what he's saying. When initially facing the chore of international language support, it's perplexing how to balance between language specific templates, replaceable text, and some replaceable text which is pull-down values you'd more naturally consider to be part of the template.

I remember I went through this same discussion on this forum a year ago. I eventually chose to:

1. Create templates within a directory structure reflecting language differences (/en, /es, etc.). The templates will contain absolutely static text (such as the title of the page, headings, etc.). 

2. Create MySQL tables for form option/select lists. The columns are identified by a numeric identifier. They are grouped by a key named "language." Therefore, using the user's language and choice-number, the text to be displayed in the option/select list can be retrieved (and/or set to "selected.") A select and a template "LOOP" populates the option/select lists before display.

I chose to put option/select list text (identified by number within language) in tables because they tended to be relational to the user's transactions. For example, if "blue" (or "azul" in Spanish), which are both code "1" in the color table, are attributes of the color of a product that they purchase, then "1" is stored as part of the purchase in the "purchase" table's "color" column. I can join purchase to "color" to get the color.  The text of the color is just a matter of which language is in use. For me, reviewing customer orders, it would be "en". But, for customers it would be their language preference as stored in their profile.

To me, this made more sense because of the relational traits. If I had the pull-down lists hard-coded in each language specific template, it would not be available to master records in the database.

3. For everything else (not static and not option/select) I used the Perl Locale::Maketext module. [1] It is similar to "gettext" but more flexible. An article [2] describes why this is important. Things like error messages and month names go into the Maketext language files.

Using those three divisions of language (templates for static text, tables for relational text, Maktext for dynamic text), all I have to do is determine the visitor's language upon initial entry into the system. I use that language code to load the template (from the correct directory), select option/select values from the correct rows, and translate dynamic values using the correct Maketext "language handle."  The visitor's language can be stored with their profile which is obtained using their last session-id (contained in a cookie). Or, if there is no cookie, the Perl tool I18N::AcceptLanguage [3] is helpful to guess a default for the visitor.

For me, this seeemed like the best way to balance different kinds of text without excessively using tables. Or, excessively duplicating information in templates. 

Hope this helps.

[1] http://search.cpan.org/~sburke/Locale-Maketext-1.09/lib/Locale/Maketext.pod
[2] http://search.cpan.org/~sburke/Locale-Maketext-1.09/lib/Locale/Maketext/TPJ13.pod
[3] http://search.cpan.org/~cgilmore/I18N-AcceptLanguage-1.02/

On Tue, 24 Aug 2004, Martin Sarfy wrote:

> Using <TMPL_IF lang=""> construct isn't appropriate for several reasons:
> 
>   -- $lang is not accessible in <TMPL_LOOP> context

Use global_vars and it will be.

>   -- it's too clumsy for manual writting

I don't understand what you mean by this.  If you consider
HTML::Template's syntax to be too clumsy then why are you using it?

>   -- <TMPL_IF> is not 'system' solution, it cannot handle e.g.
>      substitution of similar languages or so.

You can handle that in your code.  I'm certainly not going to add an
exhaustive list of languages and their synonyms to HTML::Template!

> Or should I use GNU gettext in some way?

Possibly.  I've seen it used in similar situations, but I've never
used it myself.

-sam

An alternative that I use:

In the template file, use a simple VAR tag,
<TMPL_VAR name="hello">

Store all the different language's text in a database or text files.

In the CGI, load the appropriate language based on input parameters or
cookie value,
my $lang = $cgi->param('lang') || 'en';
my $gui = load_gui ($lang);

Then load the text into the template,
$tmpl->param (hello => $gui->{hello});

You'll obviously have to write the load_gui sub yourself, depending on
how you store the data.

Carl

>>> Martin Sarfy <sa...@ic...> 24/08/2004 12:09:41 >>>

Hi folks,

I lack multiple language support in HTML::Template. 

My idea is that I wrote complete HTML page with tons of design
included
and then wrap pieces of text using e.g. 

	<TMPL_LANG lang="eng">Hello</TMPL_LANG>
	<TMPL_LANG lang="spa">Ciao</TMPL_LANG>
	<TMPL_LANG lang="cze">Ahoj</TMPL_LANG>

How do you solve this problem? 

Using <TMPL_IF lang=""> construct isn't appropriate for several
reasons:

  -- $lang is not accessible in <TMPL_LOOP> context

  -- it's too clumsy for manual writting

  -- <TMPL_IF> is not 'system' solution, it cannot handle e.g.
     substitution of similar languages or so.

Creating another copy of template file with translation is not 
maintainable because of changes in design.

Or should I use GNU gettext in some way?

Thanks a lot for advice

-- 
Martin Sarfy

-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 
_______________________________________________
Html-template-users mailing list
Htm...@li... 
https://lists.sourceforge.net/lists/listinfo/html-template-users

Hi folks,

I lack multiple language support in HTML::Template. 

My idea is that I wrote complete HTML page with tons of design included
and then wrap pieces of text using e.g. 

	<TMPL_LANG lang="eng">Hello</TMPL_LANG>
	<TMPL_LANG lang="spa">Ciao</TMPL_LANG>
	<TMPL_LANG lang="cze">Ahoj</TMPL_LANG>

How do you solve this problem? 

Using <TMPL_IF lang=""> construct isn't appropriate for several reasons:

  -- $lang is not accessible in <TMPL_LOOP> context

  -- it's too clumsy for manual writting

  -- <TMPL_IF> is not 'system' solution, it cannot handle e.g.
     substitution of similar languages or so.

Creating another copy of template file with translation is not 
maintainable because of changes in design.

Or should I use GNU gettext in some way?

Thanks a lot for advice

-- 
Martin Sarfy

On Aug 11, 2004, at 11:13 PM, Sam Tregar wrote:

> True.  I didn't mean to imply that they always became NULL.  In the
> case of the member table it's more common that the proper rows just
> cease to exist.  Like a category will lose its category group member
> link (or whatever that thing is that all categories need one of or
> they stop working).

Sounds a bit mystical to me. ;-)

Regards,

David

On Wed, 11 Aug 2004, David Wheeler wrote:

> None of Kineticode's customers have reported this problem including
> PIRT. And there are several hundred thousand documents behind that,
> excluding PIRT. I guess you didn't report it because you couldn't
> replicate it. I remember you mentioning it, though.

Yeah, I usually don't bother reporting bugs I can't replicate.  That
doesn't make them less real though!

> This often isn't possible, because the FK columns are NOT NULL. And again,
> I've only heard about this from you in email threads like this; no other
> Kineticode customer has ever reported a problem.

True.  I didn't mean to imply that they always became NULL.  In the
case of the member table it's more common that the proper rows just
cease to exist.  Like a category will lose its category group member
link (or whatever that thing is that all categories need one of or
they stop working).

-sam

On Aug 11, 2004, at 10:51 PM, Sam Tregar wrote:

> You must be blessed.  There's a whole class of data-loss bugs that I
> know I reported but neither of us could replicate.  Once we decided
> that 1.4.6 was our last upgrade it seemed like a waste of your time to
> keep bugging you.  A good example would be stories that can no longer
> be edited or published because they've got NULL element__id pointers.
> How did they get NULL element__ids?  I have no idea.  I've never been
> able to make it happen on my own.  But I know it happens because I've
> had to go in and nuke them every so often to get the system publishing
> again.

None of Kineticode's customers have reported this problem including 
PIRT. And there are several hundred thousand documents behind that, 
excluding PIRT. I guess you didn't report it because you couldn't 
replicate it. I remember you mentioning it, though.

> Similar bugs occur with less frequency in the media and category
> systems.  Seemingly for no reason at all an object will lose a
> critical ID, often in the morass of the member table.  Generally the
> only thing to do is to delete it and ask the user to re-enter the
> data.  Sometimes it's possible to intuit the missing ID, but that's
> definitely not the average case.

This often isn't possible, because the FK columns are NOT NULL. And 
again, I've only heard about this from you in email threads like this; 
no other Kineticode customer has ever reported a problem.

> My point wasn't to slander Bricolage, just to provide a case where
> transactions didn't do much to protect critical data.  In my
> experience they're just a tool which can help in unusual
> circumstances.  They're no replacement for careful coding and testing.

Yes, well, transactions are no protection from buggy code, regardless 
of your database choice. So we're in agreement. But I've found having 
each Apache request constituting a transaction extremely helpful in 
minimizing data integrity problems.

> Yeah, you got me.  I'm a developer.  I've never even met a DBA that I
> would trust to work on my data (but I haven't met many)!  Maybe
> someday when I do I'll have to use the database he likes to work on.
> Until then, I choose!  Would it make sense to have it any other way?

Yes, it makes sense to become a DBA, to a certain degree.

Okay, no more OT missives from me! I need some sleep.

Regards,

David

2002	Jan	Feb	Mar	Apr	May	Jun (42)	Jul (80)	Aug (77)	Sep (97)	Oct (65)	Nov (80)	Dec (39)
2003	Jan (63)	Feb (47)	Mar (45)	Apr (63)	May (67)	Jun (51)	Jul (78)	Aug (37)	Sep (45)	Oct (59)	Nov (50)	Dec (70)
2004	Jan (23)	Feb (90)	Mar (37)	Apr (53)	May (111)	Jun (71)	Jul (35)	Aug (58)	Sep (35)	Oct (35)	Nov (35)	Dec (20)
2005	Jan (51)	Feb (19)	Mar (20)	Apr (8)	May (26)	Jun (14)	Jul (49)	Aug (24)	Sep (20)	Oct (49)	Nov (17)	Dec (53)
2006	Jan (12)	Feb (26)	Mar (45)	Apr (19)	May (19)	Jun (13)	Jul (11)	Aug (9)	Sep (10)	Oct (16)	Nov (17)	Dec (13)
2007	Jan (9)	Feb (12)	Mar (28)	Apr (33)	May (12)	Jun (12)	Jul (19)	Aug (4)	Sep (4)	Oct (5)	Nov (5)	Dec (13)
2008	Jan (6)	Feb (7)	Mar (14)	Apr (16)	May (3)	Jun (1)	Jul (12)	Aug (1)	Sep	Oct	Nov	Dec (9)
2009	Jan (9)	Feb	Mar (10)	Apr (1)	May	Jun (6)	Jul (5)	Aug (3)	Sep (7)	Oct (1)	Nov (15)	Dec (1)
2010	Jan	Feb	Mar	Apr (9)	May	Jun	Jul (5)	Aug	Sep (2)	Oct	Nov	Dec
2011	Jan	Feb (3)	Mar	Apr (28)	May	Jun	Jul (3)	Aug (4)	Sep (3)	Oct	Nov (8)	Dec
2012	Jan	Feb	Mar	Apr	May (2)	Jun	Jul	Aug	Sep	Oct	Nov	Dec
2013	Jan (2)	Feb (1)	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec
2014	Jan (1)	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec
2015	Jan	Feb	Mar	Apr	May (1)	Jun	Jul	Aug	Sep	Oct	Nov (2)	Dec
2016	Jan	Feb (1)	Mar	Apr	May (1)	Jun	Jul	Aug	Sep	Oct	Nov (1)	Dec

html-template-users Mailing List for HTML::Template (Page 42)

html-template-users — Discussion of HTML::Template and related modules