koha-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Koha-devel] Templates internationalisation


From: paul POULAIN
Subject: Re: [Koha-devel] Templates internationalisation
Date: Fri Jun 6 05:58:05 2003
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3.1) Gecko/20030425

Jerome Vizcaino wrote:

Hi

This mail contains a modification we made to make Koha template
translation a lot more easier.
Here is the idea :
We created a table in Koha named opac_text containing three field - id : the identifier of the text
        - lang : corresponding language
        - label : the text to be used

Using the Label.pm, we use a gettexttemplate to get the label
corresponding to the requested id. This way, with only one .tmpl file,
unlimited languages are available without any changes in the .tmpl file.

To prove this trick is usable and not so hard to implement we've
attached 4 files : Label.pm, opac-detail.pl, opac-detail.tmpl and
opac_text.sql.

Here is how to test it :

1 - Create the table containing the labels : mysql -u root -p < opac_text.sql

2 - Copy the Label.pm in the C4 module directory

3 - Copy opac-detail.pl to the opac/ cgi-bin directory

4 - Copy opac-detail.tmpl to the opac/htdocs/opac-tmpl/default/en
directory. Make a link to this file in the
opac/htdocs/opac-tmpl/default/fr so that no physical duplication is
needed. This way changing the opaclanguages preference will still use
the generic template.

Now try and search a book and click on one of the result to show the
details. If you're using either 'en' or 'fr' opaclanguages option.
Changing the preference will change the language in the display.

For sure, it requires a little more cpu to display the page but with a
PII 350 (our test machine) no noticable slow down was reported.

Using a system like the authorised value builder, creation of new
languages would be made easier.

We need some feedback on this please :)
2 coders remarks :
* the replace should be done IN the gettemplate_and_user sub.
* the replace should use a loop and not a loonnggg list of tmpl->param("TEXT_*" => somevalue)

What i think nice :
* 100% compatible with present templates. If the table is empty, no diff, and no perf problem.

What i don't find nice :
* the idea of generic template only is to risky, imho. For many reasons. But what is nice is that the gettemplate_and_user auto selects the en template if the prefered language does not exists. So, for templates that can stay 100% language independant, no need for a link => just don't create a fr copy of the template.

Questions :
* does the table be theme independant ? I think yes. This reinforce my opinion to use this trick only for generic texts, like "logged in as" or "subtitle".

conclusion : this is a nice proposal, if we keep it only for "standard" words/expressions. Otherwise, the table will be too hard to maintain, and the problem with templates will be splitted in 1 pl script, 1 tmpl file, 1 DB table. Too much imho to be maintainable.

PS : in label.pm, it's better to return "unknown label id $id" than "unknown label id".

--
Paul POULAIN
Consultant indépendant en logiciels libres
responsable francophone de koha (SIGB libre http://www.koha-fr.org)





reply via email to

[Prev in Thread] Current Thread [Next in Thread]