Re: [SMARTY-DEV] Parsing smarty tags inside plugins

on 26/8/04 13:45, Ruben Vermeersch at [email protected] wrote:

> When encountering the same questions, we had to take a totally different
> solution in the project I'm currently in. All translatable strings are
> put in {t}...{/t} tags, which are then being given to gettext. Anyway,
> we couldn't implement this as a block function, since smarty returns
> it's data parsed to the block function (making it impossible to embed
> smarty syntax). We are now using a system that precompiles the templates
> for each language (not the most ideal way), but the only simple way to
> do it.

Ok, that's the kind of thing I was concerned about.

I'm trying to avoid gettext as it's not a good solution for situations where
there is no default language (or it's not programmer-readable), and it has
no means of dealing with ambiguous 100% matches, for example the word
"platform" in English might be used to describe a computer type or where a
train arrives, but in French they are quite different words. Plus it's just
ugly.

I don't see a problem (other than inefficiency) with firing up a local
smarty instance to interpret the translation contents, as long as I can
transfer all embedded variables from the host template to the new instance,
which as far as I can see I should be able to do with get_template_vars. The
big downer here is that because the templates are obtained and interpreted
on the fly, they will not be cached.

I'm using ADOdb to do my translation lookups, and it's caching them already,
so it's not all bad.

The only other major issue I'm bothered about is that you don't really want
translators having to handle Smarty markup within templates anyway.

Thoughts?

Marcus
-- 
Marcus Bointon
Synchromedia Limited: Putting you in the picture
[email protected] | http://www.synchromedia.co.uk