From: "Mathew Robertson" <[EMAIL PROTECTED]> > >provide a different template for each language
I initially went this way. But, I didn't like duplicating page structure. I found that I *really* like to keep everything in Locale::Maketext lexicons. But, the downsides are: 1. The Locale::Maketext is geared towards one large project. Not small pages. The more I moved constant/static text out of templates, the more the lexicon grew with text individual C::A modules would never need. That's a lot to load. 2. I have a lot of TMPL_VARs to replace with Locale::Maketext calls. Which leads me to want to perform an initialization of the template with replacement of text that would have more naturally been in the template if it were not for language differences. 3. As those one-time TMPL_VARs grow in number, they worry me that they add to the re-evaluation of the template. Even *if* I go through an initialization process to perform all the PARAMs only once, they'll still be re-evaluated with every "->output." (Steve's suggestion will eliminate that concern). 4. Paragraph text is a little clumsy in Locale::Maketext. I'm tempted to TMPL_INCLUDE the fragments. But, I have to get creative to specify language-specific fragments because TMPL_INCLUDE doesn't handle a variable filename. To get around #1, I use Locale::Maketext in a way not intended. Instead of putting all my language into one "en_us" file within a single directory, I've created individual subdirectories mirroring the structure of the pages. In the lowest level is the "sitewide" language file. It is loaded and applied used for all pages for the site. Language files for specific pages are in subdirectories for each page. Like: /L10N/lang/sitewide/en-us /"/"/page-a/dynamic/en-us /"/"/page-a/static/en-us /"/"/page-a/sub-page-1/dynamic/en-us /"/"/page-a/sub-page-1/static/en-us /"/"/page-b/dynamic/en-us /"/"/page-b/static/en-us In my CGI::App "prerun" I detect the page hasn't been loaded yet, load the Locale::Maketext for sitewide (if it's not loaded yet), and the page-specific "static" language file. I can apply the page-specific static translation and discard the handle. I load the dynamic language file and keep that handle in a hash for as long as I keep the partially-processed page in a hash. This works really well for me. I only load as much Locale::Maktext lexicon as I need for a page. I only keep as much as I need for display-by-display changes. The "static" lexicons are dropped immediately after first-time use. The "sitewide" handle can be dropped when it is determined all the pages for a CGI::App module have been loaded. Because of the nature of Locale::Maketext's lexicon objects, I can put common language structures subroutines that can be required by all the lexicons that need it. One problem is that Locale::Maketext expects language lexicons in a single directory and uses them for determining what languages are available. So, I do my own negotiation of which language to use and call L::M's "->new" method instead of "->get_handle." I'm happier keeping the negitiation of language outside of L::M. This works really good! It's just the three things I mentioned regarding H::T. 1. It would work better if H::T had a way to perform an "internal_output" and replace its internal template with whatever the result of the "output" was (without eliminating empty tags). 2. If evaluations of TMPL_VARs could re-evaluate (maybe based upon an attribute on the VAR) so that a VAR containing a VAR could be processed. 3. If TMPL_INCLUDE was capable of resolving a filename like "my_text.<TMPL_VAR NAME=LANG>". This would let a single template be used for all languages. A lot of heavy lifting could be done as part of the page initialization. The page could then be minimally processed for as long as it remains in the cache (either H::T's or the application's own hash of templates like I'm doing). Steve's suggestion (to run a template through, then regex some munged tags) might be a good way to get around these things. Mark ------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt _______________________________________________ Html-template-users mailing list Html-template-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/html-template-users
