From: Sam Tregar <[EMAIL PROTECTED]> >> -- it's too clumsy for manual writting > >I don't understand what you mean by this. If you consider >HTML::Template's syntax to be too clumsy then why are you using it?
I understand what he's saying. When initially facing the chore of international language support, it's perplexing how to balance between language specific templates, replaceable text, and some replaceable text which is pull-down values you'd more naturally consider to be part of the template. I remember I went through this same discussion on this forum a year ago. I eventually chose to: 1. Create templates within a directory structure reflecting language differences (/en, /es, etc.). The templates will contain absolutely static text (such as the title of the page, headings, etc.). 2. Create MySQL tables for form option/select lists. The columns are identified by a numeric identifier. They are grouped by a key named "language." Therefore, using the user's language and choice-number, the text to be displayed in the option/select list can be retrieved (and/or set to "selected.") A select and a template "LOOP" populates the option/select lists before display. I chose to put option/select list text (identified by number within language) in tables because they tended to be relational to the user's transactions. For example, if "blue" (or "azul" in Spanish), which are both code "1" in the color table, are attributes of the color of a product that they purchase, then "1" is stored as part of the purchase in the "purchase" table's "color" column. I can join purchase to "color" to get the color. The text of the color is just a matter of which language is in use. For me, reviewing customer orders, it would be "en". But, for customers it would be their language preference as stored in their profile. To me, this made more sense because of the relational traits. If I had the pull-down lists hard-coded in each language specific template, it would not be available to master records in the database. 3. For everything else (not static and not option/select) I used the Perl Locale::Maketext module. [1] It is similar to "gettext" but more flexible. An article [2] describes why this is important. Things like error messages and month names go into the Maketext language files. Using those three divisions of language (templates for static text, tables for relational text, Maktext for dynamic text), all I have to do is determine the visitor's language upon initial entry into the system. I use that language code to load the template (from the correct directory), select option/select values from the correct rows, and translate dynamic values using the correct Maketext "language handle." The visitor's language can be stored with their profile which is obtained using their last session-id (contained in a cookie). Or, if there is no cookie, the Perl tool I18N::AcceptLanguage [3] is helpful to guess a default for the visitor. For me, this seeemed like the best way to balance different kinds of text without excessively using tables. Or, excessively duplicating information in templates. Hope this helps. [1] http://search.cpan.org/~sburke/Locale-Maketext-1.09/lib/Locale/Maketext.pod [2] http://search.cpan.org/~sburke/Locale-Maketext-1.09/lib/Locale/Maketext/TPJ13.pod [3] http://search.cpan.org/~cgilmore/I18N-AcceptLanguage-1.02/ ------------------------------------------------------- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 _______________________________________________ Html-template-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/html-template-users
