- we only support UTF8 as the charset, as any other charset in simply insufficient (Google does this too). UTF8 is OK.
- 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.
- 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.
- 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"? I think CVS does this job too.
- right-to-left text is also easily supported This is primary a point of coding. The correct formatting of such text can be controlled better by one template per language.
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? What about upgrades?
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.
PS. Some languages, particularily Asian languages, contain many pen-strokes within a glyph. Often these languages need the text point-size to be slightly larger than European languages... this is just a tidbit that I have found through experience, particularily if a single template is to be used for every language. got it.
Dorian