Template::Toolkit, look-and-feel and internationalization

[ruoso]

hi,

Which would be a good way of using Template::Toolkit together with:

• Supporting look-and-feel, having different sets of templates that can inherit from each other, like, the theme A has all the templates, the theme B modifies some templates of the theme A and theme C modifies some templates of the Theme B.
• Supporting inline gettext or any other way of translating the text inside the templates, I mean, I don't want to have the complete set of themes for all the languages, but I do want to have a simple gettext-like infra-structure to translate the application, but I want that integrated with TT.

So, what do you say?

Update: For the gettext question, I've already found a good way to do it using a FILTER (thanks davidrw and deliria) (BTW, this example presumes a i18n filter that translates and sprintf the string):

[%"Text to be translated"|i18n%]
[%"You gained %d experience points"|i18n($xpdelta)%]

or

[% | i18n %]A Long Text that is better to stay out[% END %]

[davidrw]

We set up the language translation recently with TT -- here's how we did it (I'm not by any means claiming this is _THE_ way to do it.. not good or bad, just A way) (also, this wasn't too exciting because it was just for english-US vs english-UK):
• Went through all the templates and wrapped all the text in a FILTER tag. So from: <div>Hello</div> to: <div>[% FILTER localize %]Hello[% END %]</div>
• localize is setup in our custom TT modules. It bascially takes the text and treats it as a primary key. It gets the current locale from httpd.conf. Now, if it can find in a database table a value for that pk for that locale, it uses that. Otherwise it just returns the original text.
• Had to populate these new locale tables with some translations.
I'm sure there's lots of pros and cons to be gleaned from the above, but keep in mind it was made for our more limited case..

[lachoy]

How does the FILTER usage work when you've got to pass parameters?

I've implemented something similar to this in OpenInteract2 -- you just call:

[% MSG( 'somekey', param1, param2, ... ) %]

...and that call gets replaced by the relevant lookup and replacement. Behind the scenes it's using Locale::Maketext, but that detail is irrelevant to the template creator.

[davidrw]

It's built to handle things like [% FILTER repeat(3) %]blah [% END %] -- Two starting points (with some good examples) are the FILTER directive and the Template::Filters docs.

[jhourcle]

For look and feel issues, if you're using this for a web page, you might be better off using CSS, and trying to keep the content and layout completely seperate.

I've never had to deal with writing programs to support internationalization, so I can't help you there.

[deliria]

In our app we take the language preferences of a user from his settings, cookie or guess it based on his browser headings or failing all, guess his language by his IP. In the head of .tt's we PROCESS the proper language template which holds the translations by key:

The template inclusion is done via a:

[%- PROCESS "locale/${user.lang}/lang.tt"; %]


The language files look like:

[%
lang.label.status         = "Status";
....
lang.phrase.sure            = "Are you sure";
%]


and a tag is simply called using:

[% lang.label.status %]


This method also allows you to send the collection of language templates to a translator without you having to import anything to a database or whatnot.

Regarding custom skins, have a looksee at Plesk and see how much they do with stylesheets. It's very nifty.

Hth,
Deliria.