I've more or less given up on it, mostly because there are a few use
cases where text needs translated that's not easily passed through
c->loc, for example dynamically generated descriptions and such things.
They *could* be put through c->loc but that ties some logic too tight to
the whole web app for it to be worthwhile.
One thing I tend to do is just separate things to a ridiculous degree;
instead of going [% c.loc('hi there') %], I'll in fact name it [%
c.loc('index_tt2_hi_there') %] - which means that I need to translate
for en_us as well (or at least put the text in). Inside perl modules,
text that needs translated (e.g. modules that aren't tied to Catalyst),
they all use another module I wrote that makes you "register" all
different text identifiers, and will cache them; if you don't register
it, you can't use it (error shows up), and once it's registered, another
script will yank the cached entries and will merge them into an existing
.po file if they need to be there.
There's also the issue that I'm dealing with now where I have a web shop
that I need to build that needs to be fully bilingual. Including product
descriptions and names - this makes things interesting because I18N is
absolutely useless for it, so I'm building a set of modules that attempt
to solve the whole problem gracefully; perhaps something to stick on
CPAN at some point.
Cosimo Streppone wrote:
On Mon, 02 Aug 2010 07:08:04 +0200, Julien Sobrier
<jul...@sobrier.net> wrote:
Also, writing [% c.loc(foo) %] does not create an entry in messages.po
when running xgettext.pl, like [% c.loc('foo') %] does.
To make that work, I think you'd have to actually *run*
your templates for all possible cases, and then collect all
the strings that were passed as arguments to c.loc().
In other words, I'm not saying it's impossible, but
xgettext.pl will probably never be able to do that.
A slightly different approach, that works for me,
is to create your .PO files in different stages.
First step parses the templates with xgettext.pl and generates
the .PO files.
A second step can, for example, parse the actual source
code, for stuff like '$c->loc("foo")'.
xgettext.pl can do that with a bit of trickery.
The new messages will be merged together in the same .PO files.
In your case, you could pull the messages you want to be translated
directly from the database, and write some on-the-fly
fake templates (or text files for that matter),
and feed them to xgettext.pl.
--
Ben van Staveren
phone: +62 81 70777529
email: benvanstave...@gmail.com
_______________________________________________
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/
