Re: Re[2]: [Koha-devel] Charsets: Moving to utf-8

[Mathew]

> - 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