[Catalyst] I18N with variables

[Ben van Staveren]

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 
> <julien at 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: benvanstaveren at gmail.com