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

On Thu, 2004-08-26 at 15:34 +0100, Marcus Bointon wrote: > 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 The only reason we use Gettext is to enable translators to put their translations into .po files, and merging them with the main .pot from time to time. This is our current model is like this: * In the templates folder, out html designer (and english translator ;)) makes the templates, putting strings in {t}string here {$var}{/t} * He then runs a script called generate-po-files, which makes a .pot file with all strings found in the templates * The .pot files are merged with any existing .po files * After the .po files have been translated, the designer runs a script called compile-templates, this makes a subdir in a templates_t (not the analogy with templates_c) with the name of the language (en, fr, nl) and translates the raw template (with the {t} tags) according to the appropriate .po file. So basically, we end up with a copy of each template in the language's subdir in templates_t * According the the language, the right template gets used This is not the ideal way of doing it, but it allows translators to use all the nice tools for modifying po files, and it nicely marks fuzzy translations. This also doesn't solve your problem, but it might be of help to anybody who might require it. Any comments would be appreciated Regards, Ruben -- Ruben Vermeersch http://www.Lambda1.be/