Mailing List Archive

Hi Duncan,

You should use Plugin here:
http://search.cpan.org/dist/Catalyst-Plugin-I18N/lib/Catalyst/Plugin/I18N.pm

Check at configuration section if you want to specify directory for .po files or elsr.

Regards,
Chakkit

On Oct 6, 2011, at 7:39 PM, Duncan Garland <Duncan.Garland@motortrak.com> wrote:

> Hi,
>
>
>
> Has any anybody got a working example of the use of Locale::Maketext with Locale::Maketext::Lexicon? I think I’ve missed something simple. My example code is:
>
>
>
> { package Lexicon;
>
>
>
> use base 'Locale::Maketext';
>
> use Locale::Maketext::Lexicon {
>
> fr => ['Gettext' => "hello_fr2.po" ],
>
> };
>
>
>
> sub fr::xxx { print "Hello!"; return "hello"; }
>
>
>
> 1;
>
>
>
> }
>
>
>
> my $l = Lexicon->get_handle( 'fr' );
>
>
>
> print $l->maketext( "Hello" ) . "\n";
>
>
>
> print $l->maketext( "Nuts ~[xxx~]" ) . "\n";
>
>
>
> The hello_fr2.po contains:
>
>
>
> msgid "Hello"
>
> msgstr "Bonjour"
>
>
>
> msgid "Goodbye"
>
> msgstr "Au revoir"
>
>
>
> msgid "Your search matched [quant,_1,book]"
>
> msgstr "Vous trouvez [ quant, _1, livre ]"
>
>
>
> msgid "You are my [ord,_1] something."
>
>
>
> msgid "[numf,_1]"
>
> msgstr "[numf,_1]"
>
>
>
> msgid "Nuts [xxx]"
>
> msgstr "Bolts [xxx]"
>
>
>
> The output is:
>
>
>
> Bonjour
>
> Bolts [xxx]
>
>
>
> So the simple substitutions work but I can’t get it to call the function. Furthermore, it puts tilde before each bracket, so I can’t get a match for anything with a function unless I put tildes in there. I’ve missed something simple. Any ideas?
>
>
>
> Thanks
>
>
>
> Duncan
>
>
>
>
>
> _______________________________________________
> List: Catalyst@lists.scsys.co.uk
> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
> Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
> Dev site: http://dev.catalyst.perl.org/

Hi Chakkit,

Thanks for your reply.

We do have a medium sized Catalyst application which we may well want to internationalise at some point, but at the moment I’m looking for a solution which can be applied to some other non-Catalyst applications.

I posted my question here because I got the idea of using Locale::Maketext and Locale::Maketext::Lexicon from the articles referenced on the Catalyst localisation man page. Specifically, there is an article by Audrey Tang which gives an example which seems to do exactly what we want. (Multiple .po files per language which are searched in order and the ability to include some functions.) I also got the impression that these modules are commonly used within the Catalyst community.

Unfortunately, I can’t make the example code work and I can’t find a better example.

I’ve had the debugger on the code for a while since I made my first post.

The problems are:


1) The square brackets are escaped with a tilde to become ~[ or ~] when they are read in. That applies to both the msgid and the msgstr.

2) The code which compiles the subroutine does recognise ~ but treats it as escaping the bracket. Thus the in_group flag is never set and it never constructs or executes the function. If I use the debugger to remove the tildes, the function is built and executed.

3) The article implies that you declare a function as fr::xxx and call it as xxx. In fact, if it is declared as fr::xxx it must be called as fr::xxx.

I’ve run out of ideas.

All the best.

Duncan
From: Chakkit Ngamsom [mailto:chakkit@ibiz.co.th]
Sent: 06 October 2011 15:06
To: The elegant MVC web framework
Subject: Re: [Catalyst] Localisation

Hi Duncan,

You should use Plugin here:
http://search.cpan.org/dist/Catalyst-Plugin-I18N/lib/Catalyst/Plugin/I18N.pm

Check at configuration section if you want to specify directory for .po files or elsr.

Regards,
Chakkit

On Oct 6, 2011, at 7:39 PM, Duncan Garland <Duncan.Garland@motortrak.com<mailto:Duncan.Garland@motortrak.com>> wrote:
Hi,

Has any anybody got a working example of the use of Locale::Maketext with Locale::Maketext::Lexicon? I think I’ve missed something simple. My example code is:

{ package Lexicon;

use base 'Locale::Maketext';
use Locale::Maketext::Lexicon {
fr => ['Gettext' => "hello_fr2.po" ],
};

sub fr::xxx { print "Hello!"; return "hello"; }

1;

}

my $l = Lexicon->get_handle( 'fr' );

print $l->maketext( "Hello" ) . "\n";

print $l->maketext( "Nuts ~[xxx~]" ) . "\n";

The hello_fr2.po contains:

msgid "Hello"
msgstr "Bonjour"

msgid "Goodbye"
msgstr "Au revoir"

msgid "Your search matched [quant,_1,book]"
msgstr "Vous trouvez [ quant, _1, livre ]"

msgid "You are my [ord,_1] something."

msgid "[numf,_1]"
msgstr "[numf,_1]"

msgid "Nuts [xxx]"
msgstr "Bolts [xxx]"

The output is:

Bonjour
Bolts [xxx]

So the simple substitutions work but I can’t get it to call the function. Furthermore, it puts tilde before each bracket, so I can’t get a match for anything with a function unless I put tildes in there. I’ve missed something simple. Any ideas?

Thanks

Duncan


_______________________________________________
List: Catalyst@lists.scsys.co.uk<mailto:Catalyst@lists.scsys.co.uk>
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

There is some pod buried deep in Locale::Maketext::Lexicon::Gettext. You have to use different syntax in the .po file. If anybody’s interested, the following simple example does work:

{ package Lexicon;

use base 'Locale::Maketext';
use Locale::Maketext::Lexicon {
fr => ['Gettext' => "hello_fr2.po" ],
};

sub xxx { print "Hello!"; return "hello"; }

1;

}

my $l = Lexicon->get_handle( 'fr' );

print $l->maketext( "Hello" ) . "\n";

print $l->maketext( "Nuts" ) . "\n";

The .po file:

msgid "Hello"
msgstr "Bonjour"

msgid "Goodbye"
msgstr "Au revoir"

msgid "Nuts"
msgstr "Bolts %xxx()"

Output:

Bonjour
Hello!Bolts hello

Regards

Duncan
From: Duncan Garland [mailto:Duncan.Garland@motortrak.com]
Sent: 06 October 2011 16:09
To: The elegant MVC web framework
Subject: RE: [Catalyst] Localisation

Hi Chakkit,

Thanks for your reply.

We do have a medium sized Catalyst application which we may well want to internationalise at some point, but at the moment I’m looking for a solution which can be applied to some other non-Catalyst applications.

I posted my question here because I got the idea of using Locale::Maketext and Locale::Maketext::Lexicon from the articles referenced on the Catalyst localisation man page. Specifically, there is an article by Audrey Tang which gives an example which seems to do exactly what we want. (Multiple .po files per language which are searched in order and the ability to include some functions.) I also got the impression that these modules are commonly used within the Catalyst community.

Unfortunately, I can’t make the example code work and I can’t find a better example.

I’ve had the debugger on the code for a while since I made my first post.

The problems are:


1) The square brackets are escaped with a tilde to become ~[ or ~] when they are read in. That applies to both the msgid and the msgstr.

2) The code which compiles the subroutine does recognise ~ but treats it as escaping the bracket. Thus the in_group flag is never set and it never constructs or executes the function. If I use the debugger to remove the tildes, the function is built and executed.

3) The article implies that you declare a function as fr::xxx and call it as xxx. In fact, if it is declared as fr::xxx it must be called as fr::xxx.

I’ve run out of ideas.

All the best.

Duncan
From: Chakkit Ngamsom [mailto:chakkit@ibiz.co.th]
Sent: 06 October 2011 15:06
To: The elegant MVC web framework
Subject: Re: [Catalyst] Localisation

Hi Duncan,

You should use Plugin here:
http://search.cpan.org/dist/Catalyst-Plugin-I18N/lib/Catalyst/Plugin/I18N.pm

Check at configuration section if you want to specify directory for .po files or elsr.

Regards,
Chakkit

On Oct 6, 2011, at 7:39 PM, Duncan Garland <Duncan.Garland@motortrak.com<mailto:Duncan.Garland@motortrak.com>> wrote:
Hi,

Has any anybody got a working example of the use of Locale::Maketext with Locale::Maketext::Lexicon? I think I’ve missed something simple. My example code is:

{ package Lexicon;

use base 'Locale::Maketext';
use Locale::Maketext::Lexicon {
fr => ['Gettext' => "hello_fr2.po" ],
};

sub fr::xxx { print "Hello!"; return "hello"; }

1;

}

my $l = Lexicon->get_handle( 'fr' );

print $l->maketext( "Hello" ) . "\n";

print $l->maketext( "Nuts ~[xxx~]" ) . "\n";

The hello_fr2.po contains:

msgid "Hello"
msgstr "Bonjour"

msgid "Goodbye"
msgstr "Au revoir"

msgid "Your search matched [quant,_1,book]"
msgstr "Vous trouvez [ quant, _1, livre ]"

msgid "You are my [ord,_1] something."

msgid "[numf,_1]"
msgstr "[numf,_1]"

msgid "Nuts [xxx]"
msgstr "Bolts [xxx]"

The output is:

Bonjour
Bolts [xxx]

So the simple substitutions work but I can’t get it to call the function. Furthermore, it puts tilde before each bracket, so I can’t get a match for anything with a function unless I put tildes in there. I’ve missed something simple. Any ideas?

Thanks

Duncan


_______________________________________________
List: Catalyst@lists.scsys.co.uk<mailto:Catalyst@lists.scsys.co.uk>
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

I don't know if it helps, but I've been researching a little about
localization recently, and I came across this article:
http://rassie.org/archives/247

In summary, it states Locale::Maketext shouldn't be used — we should be
using Locale::TextDomain instead. I'm considering it for my current needs.

Any thoughts?

Regards,
André

_______________________________________________
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Hi,

I hadn't seen this and I've only just had a quick glance through it. However, it contains some obvious errors. The most glaring is that Maketext does allow the word order to be swopped in the output although I think the parameter order has to be the same.

Msgid "[xxx, 1, 2]"
Msgstr "[xxx, 1, 2]"

The function which outputs the translation for xxx can easily be made to return "1,2" or "2,1".

I'm not sure what he means by Voodoo but I thought simple functions such as quant were pre-implemented in many languages. I also find it hard to believe that there aren't some pre-written lexicons available. The perl community is very good at that.

Not sure about the rest. I only started looking at this a couple of days ago and I've only just extricated myself from that knot I got into with the syntax.

All the best.

Duncan

-----Original Message-----
From: André Walker [mailto:andre@andrewalker.net]
Sent: 06 October 2011 17:07
To: The elegant MVC web framework
Subject: Re: [Catalyst] Localisation

I don't know if it helps, but I've been researching a little about
localization recently, and I came across this article:
http://rassie.org/archives/247

In summary, it states Locale::Maketext shouldn't be used - we should be
using Locale::TextDomain instead. I'm considering it for my current needs.

Any thoughts?

Regards,
André

_______________________________________________
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

_______________________________________________
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

On Thu, Oct 6, 2011 at 11:06 AM, André Walker <andre@andrewalker.net> wrote:

> I don't know if it helps, but I've been researching a little about
> localization recently, and I came across this article:
> http://rassie.org/archives/247
>
> In summary, it states Locale::Maketext shouldn't be used — we should be
> using Locale::TextDomain instead. I'm considering it for my current needs.
>
> Any thoughts?
>

The article is rather biased -- it points out the speck in Maketext's eye
while ignoring gettext's planks. The author of the article is so bent on
how gettext does things that he fails to recognize that at least some of
what Maketext does is actually an improvement. It reads a lot more like
"gettext is The One True Way; Maketext is different; therefore, Maketext is
Considered Harmful".

gettext was very much built for translating locally-running applications,
and makes a lot of assumptions that simply aren't true in a web
environment. One thing about gettext that makes it untenable for web
applications is its reliance on POSIX setlocale() and environment variables
to set itself up, a design flaw that Locale::TextDomain tragically
reproduced to perfection, gauging from the documentation. Take a look at
these hoops PHP developers jump through to utilize gettext:

http://fplanque.net/Blog/devblog/2003/08/20/internationalizing_web_applications_usin

It should induce pain in any sane developer. Hint: if you are having to set
environment variables halfway through your application to configure
something, your design is beyond broken. Now, PHP has Zend_Translate to
rescue them from this horror, but almost no one will utilize it because the
above kind of cargo-cult hackery is par for the course in PHP.

Perl has already been rescued from this, hint hint.

The other thing that really irks me is that Locale::TextDomain hasn't had an
update since 2009. Open bugs on rt.cpan from 2 years ago. Not a fan of
such a crucial underlying library being abandonware. Maketext, for all its
warts, at least still appears to have a maintainer.

Plus, there are still untapped regions of the l10n universe --
gender-specific verb endings in Russian, anyone? This is a realm that
gettext doesn't even begin to address. I have some betting money on which
system will address it first.

Now, the article has some valid points about how Maketext does it wrong
(like not being able to handle a verbatim gettext PO), so let's fix
Maketext. gettext is a step backwards in the modern Perl world.

--
Stephen Clouse <stephenclouse@gmail.com>

>>> Now, the article has some valid points about how Maketext does it wrong (like not being able to handle a verbatim gettext PO), so let's fix Maketext.

Maketext does handle PO files. I know it won’t handle the plurals construct. Is there anything else it trips up on?

From: Stephen Clouse [mailto:stephenclouse@gmail.com]
Sent: 06 October 2011 20:59
To: The elegant MVC web framework
Subject: Re: [Catalyst] Localisation

On Thu, Oct 6, 2011 at 11:06 AM, André Walker <andre@andrewalker.net<mailto:andre@andrewalker.net>> wrote:
I don't know if it helps, but I've been researching a little about localization recently, and I came across this article: http://rassie.org/archives/247

In summary, it states Locale::Maketext shouldn't be used — we should be using Locale::TextDomain instead. I'm considering it for my current needs.

Any thoughts?

The article is rather biased -- it points out the speck in Maketext's eye while ignoring gettext's planks. The author of the article is so bent on how gettext does things that he fails to recognize that at least some of what Maketext does is actually an improvement. It reads a lot more like "gettext is The One True Way; Maketext is different; therefore, Maketext is Considered Harmful".

gettext was very much built for translating locally-running applications, and makes a lot of assumptions that simply aren't true in a web environment. One thing about gettext that makes it untenable for web applications is its reliance on POSIX setlocale() and environment variables to set itself up, a design flaw that Locale::TextDomain tragically reproduced to perfection, gauging from the documentation. Take a look at these hoops PHP developers jump through to utilize gettext:

http://fplanque.net/Blog/devblog/2003/08/20/internationalizing_web_applications_usin

It should induce pain in any sane developer. Hint: if you are having to set environment variables halfway through your application to configure something, your design is beyond broken. Now, PHP has Zend_Translate to rescue them from this horror, but almost no one will utilize it because the above kind of cargo-cult hackery is par for the course in PHP.

Perl has already been rescued from this, hint hint.

The other thing that really irks me is that Locale::TextDomain hasn't had an update since 2009. Open bugs on rt.cpan from 2 years ago. Not a fan of such a crucial underlying library being abandonware. Maketext, for all its warts, at least still appears to have a maintainer.
Plus, there are still untapped regions of the l10n universe -- gender-specific verb endings in Russian, anyone? This is a realm that gettext doesn't even begin to address. I have some betting money on which system will address it first.

Now, the article has some valid points about how Maketext does it wrong (like not being able to handle a verbatim gettext PO), so let's fix Maketext. gettext is a step backwards in the modern Perl world.

--
Stephen Clouse <stephenclouse@gmail.com<mailto:stephenclouse@gmail.com>>

On 12 October 2011 14:20, Duncan Garland <Duncan.Garland@motortrak.com>wrote:

> >>> Now, the article has some valid points about how Maketext does it wrong
> (like not being able to handle a verbatim gettext PO), so let's fix
> Maketext.****
>
> ** **
>
> Maketext does handle PO files. I know it won’t handle the plurals
> construct. Is there anything else it trips up on?****
>
> ** **
>
> *From:* Stephen Clouse [mailto:stephenclouse@gmail.com]
>
> **
>
> On Thu, Oct 6, 2011 at 11:06 AM, André Walker <andre@andrewalker.net>
> wrote:****
>
> I don't know if it helps, but I've been researching a little about
> localization recently, and I came across this article:
> http://rassie.org/archives/247
>
> In summary, it states Locale::Maketext shouldn't be used — we should be
> using Locale::TextDomain instead. I'm considering it for my current needs.
>
> Any thoughts?****
>
>
> The article is rather biased -- it points out the speck in Maketext's eye
> while ignoring gettext's planks.
>

Indeed. I used Locale::Maketext
https://metacpan.org/search?q=locale%3A%3Amaketext
to handle the translations for 25 different language sites no problem

e.g.

search
http://www.bbc.co.uk/arabic/search/?scope=arabic&q=%D8%A3%D9%88%D8%A8%D8%A7%D9%85%D8%A7

weather http://www.bbc.co.uk/portuguese/tempo/

The scenario the author describes about getting your translators to fill out
the .po file was realistic, although now it is more a case of email around a
spreadsheet and when it comes back cut and paste the phrases into a .po
file. It worked well, apart from when I found Myanmar (Burmese) wouldn't
copy and paste reliably into vi.

Regards, Peter

On Wed, Oct 12, 2011 at 8:20 AM, Duncan Garland <
Duncan.Garland@motortrak.com> wrote:

> >>> Now, the article has some valid points about how Maketext does it wrong
> (like not being able to handle a verbatim gettext PO), so let's fix
> Maketext.****
>
> ** **
>
> Maketext does handle PO files. I know it won’t handle the plurals
> construct. Is there anything else it trips up on?
>

That is mainly what I was referring to, and it is something that Maketext
needs to do. quant is pretty much useless for its intended purpose, for the
reasons cited in the article.

--
Stephen Clouse <stephenclouse@gmail.com>

>>> That is mainly what I was referring to, and it is something that Maketext needs to do.
Agreed. Definitely. The good news is that it doesn’t look like is should be too difficult.

From: Stephen Clouse [mailto:stephenclouse@gmail.com]
Sent: 12 October 2011 22:37
To: The elegant MVC web framework
Subject: Re: [Catalyst] Localisation

On Wed, Oct 12, 2011 at 8:20 AM, Duncan Garland <Duncan.Garland@motortrak.com<mailto:Duncan.Garland@motortrak.com>> wrote:
>>> Now, the article has some valid points about how Maketext does it wrong (like not being able to handle a verbatim gettext PO), so let's fix Maketext.

Maketext does handle PO files. I know it won’t handle the plurals construct. Is there anything else it trips up on?

That is mainly what I was referring to, and it is something that Maketext needs to do. quant is pretty much useless for its intended purpose, for the reasons cited in the article.

--
Stephen Clouse <stephenclouse@gmail.com<mailto:stephenclouse@gmail.com>>

I’ve exchanged emails with Clinton Gormley (Locale::Maketext) and Guido Flohr (Locale::TextDomain). Both are definitely still maintained.

From: Duncan Garland [mailto:Duncan.Garland@motortrak.com]
Sent: 13 October 2011 09:36
To: The elegant MVC web framework
Subject: RE: [Catalyst] Localisation

>>> That is mainly what I was referring to, and it is something that Maketext needs to do.
Agreed. Definitely. The good news is that it doesn’t look like is should be too difficult.

From: Stephen Clouse [mailto:stephenclouse@gmail.com]
Sent: 12 October 2011 22:37
To: The elegant MVC web framework
Subject: Re: [Catalyst] Localisation

On Wed, Oct 12, 2011 at 8:20 AM, Duncan Garland <Duncan.Garland@motortrak.com<mailto:Duncan.Garland@motortrak.com>> wrote:
>>> Now, the article has some valid points about how Maketext does it wrong (like not being able to handle a verbatim gettext PO), so let's fix Maketext.

Maketext does handle PO files. I know it won’t handle the plurals construct. Is there anything else it trips up on?

That is mainly what I was referring to, and it is something that Maketext needs to do. quant is pretty much useless for its intended purpose, for the reasons cited in the article.

--
Stephen Clouse <stephenclouse@gmail.com<mailto:stephenclouse@gmail.com>>

Hi,

Duncan Garland pointed me to this discussion. Please don't flame me if
I missed some obvious points from the previous discussion. Pipermail
messed up all mails encoded in base64. See for example
http://lists.scsys.co.uk/pipermail/catalyst/2011-October/027720.html

I didn't bother to decode them, sorry.

I am the author of libintl-perl aka Locale::TextDomain, and of the Perl
backend of GNU gettext. 3-4 years ago I have experimented with
Catalyst, always with - it's my hobbyhorse, after all - i18n/l10n in
mind. I haven't touched Catalyst since then; if I missed any recent
developments, sorry again, and correct me.

For obvious reasons I used GNU gettext for localisation for these
experiments, with minimal pain. For the Perl side (model and
controllers) I just used libintl-perl, and it is a piece of cake, it
just works. For the views I wrote a plug-in for Template Toolkit which
exported the gettext API into TT templates. If anybody volunteers to
maintain that plug-in, drop me a line. I didn't upload it to CPAN
because I felt that I'm not good enough with TT and Catalyst. But it
basically works.

When you endeavour to internationalize a web project nowadays, the
runtime-aspect is negligible. It doesn't matter how you look up
translations for messages, even with a gettext implementation without
contexts or the ngettext plural API, even with catgets. In reality, you
can always workaround those run-time problems.

The real problems are:

1) You must be able to create translation files that are accepted by
professional translators. Most professional translators for software
expect formats used by applications for MS-DOS/Windows. More and more
translators accept PO files. In that other world, where unicorns
excrete rainbows, sunshine and butterflies, they will also happily
subclass from your localization handle.

2) Except for one-shot projects, your translation files should be
mergeable (mergable?). Portable object (PO) files are pretty much
mergeable. Some proprietary frameworks maybe offer similiar
functionality. But I'm only positive for PO files.

3) In an MVC environment, every translatable message in a model or
controller is a potential bug or flaw, at least according to yours
truly. Views are nowadays template based. The challenge is to extract
messages from your templates. With Perl (Python, Ruby, ...) this is
actually easy-going because you can usually (ab)use your template
processor for extracting messages, dump it into a .pot file, (msg)merge
it with your old po file, and your translators are happy, see 1).

4) At run-time: GNU gettext selects translations based on the currently
selected locale, on “the currently selected locale”. That makes sense
for desktop applications but not for client-server applications, leave
alone threaded applications. Switching locale is never thread-safe and
potentially slow.

I hope that I will be able to improve the situation a little bit with
libintl-perl 2.x.

As far as 4) is concerned, I plan to provide functions that look up
translations without switching locale. Instead, you can provide the
name of a language or even the name of a file containing translations.

The show stoppers are modules/libraries/external applications that use
the native gettext framework, most notably the system libc. They will
still select the translation based on the user locale, resulting in ugly
language mixes, and even uglier charset mixes. Actually, in a web
application you should strive to hide such messages from the user, for
usability or merchantability. Yet, this is an open issue.

For 2), with libintl-perl 2.x you will have functions that can read,
filter, and write PO (and also MO) files. If you want to gettextize
your proprietary best-template-system-in-the-world-format files, just
write an extractor for that format, feed it into
Locale::Catalog::Format::PO, write a .pot file, and msgmerge it with the
other .pot files from your project.

You can follow the progress here:

git://git.guido-flohr.net/perl/libintl-perl.git
git://git.guido-flohr.net/perl/pgettext-tools.git

Check out the POD of lib/Locale/Catalog/Format/PO.pm,
lib/Locale/Catalog/Format/MO.pm and lib/Locale/Catalog.pm as starters.

Please don't expect any production code from the above sources before
the end of the year.

Guido
--
Империя ООД | Imperia OOD
ул. „Княз-Борис-I“ № 86, София 1000 | ul. "Knyaz-Boris-I" № 86, Sofia
http://www.imperia.bg/


_______________________________________________
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/