- all translations are stored within a database table, then have the template lookup any static text (text generated from within Perl, can be translated before being sent to the templates. I think this is not a good idea. Read why:
- since templates lookup their own translations, you dont need a template-per-language.
I'd prefer a template per language. Often the syntax is different in different languages. With one template per language you can build phrases, which mix static text with database generated text correctly for every language.
you could mix static text and database text, but why have seperate places for the text storage?
- since translations are stored within a database, you can update the translations at run-time, without needing to restart / reload your updated translations
We don't have to restart/reload right now.
Most language translations are based on using .po files, such that when the file modification stamp is modified, the file gets reloaded. The problem with that is that each Apache instance will load a seperate copy of the translations, unless there is a mechanism to use a global map.
- web access to the database translations allow multiple people to localise the translations, at the same time.
What do you mean with "localise the translations"?
When you give a template in one language, to the person do the translation, they are said to "localise the template to their langauge" which includes variations due to region, ie en_AU, en_US, en_GB, vs. jsut creating translations in the en language.
I think CVS does this job too.
I'm suggesting that you can get a translator to translate the text strings, a) without them needing to understand how to use html, b) so that they use the same tool - the web browser - to update the text strings.
- right-to-left text is also easily supported
This is primary a point of coding.
Not only. If you use an arabic website, the menu's are on the RHS side of the page - no primary within unicode, allows you to format you menus on the RHS of the browser.
The correct formatting of such text can be controlled better by one template per language.
Having done it both ways (we origonally had seperate templates per language), and now with a single template, we have seen exactly zero cases where a language specific template was needed. That said, we have need some variations with CSS styles.
To do some of these, we modified HTML::Template to suport custom TMPL_xxx tags, so that we could implement a tag for the static text lookup. ie: our templates look like:
You modified the original module?
yes
What about upgrades?
We merge the changes, then we put the new release on the website. I have email Sam Tregar a few times - most of the changes that we have developed, he is simply not interested in. For example, we enabled support for TMPL_ELSIF simply because we often use: <TMPL_IF ...> ... <TMPL_ELSE> <TMPL_IF ... ... <TMPL_ELSE> <TMPL_IF ... .... <TMPL_ELSE> ... </TMPL_IF> </TMPL_IF> </TMPL_IF> we can now do: <TMPL_IF ...> ... <TMPL_ELSIF ...> ... <TMPL_ELSIF ...> ... <TMPL_ELSE> </TMPL_IF> which is just so much cleaner - and the ELSIF's can be EXPR's too.
We combine H::T with the Locale::MakePhrase module so that the output can handle singular / plural / etc based on the string/numeric value of some_var.
This could be interesting for some words or phrases, but it can't provide the flexibility of a template.
Can I ask, did you have read through the Locale::MakePhrase documentation, and the documentation that it references? Sure, a template gives you ultimate flexibility. It also gives you the ability for templates to get out of sync, which is what our biggest problem was -> each time we made an enhancement, the templates needed to re-synced with the master, thus everly language other then english (our master languge) always lagged. cheers, Mathew