Templates internationalisation
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 :) Thanks Jerome and Michel
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)
paul POULAIN <paul.poulain@free.fr> wrote:
What i don't find nice :
There were absolutely no documentation of the code, so us mere mortals find it hard to follow and nearly impossible to give useful comments. There were no tests. Sorry to be a downer. -- MJR/slef My Opinion Only and possibly not of any group I know. http://mjr.towers.org.uk/ jabber://slef@jabber.at Creative copyleft computing services via http://www.ttllp.co.uk/ Thought: "Changeset algebra is really difficult."
MJ Ray wrote:
paul POULAIN <paul.poulain@free.fr> wrote:
What i don't find nice :
There were absolutely no documentation of the code, so us mere mortals find it hard to follow and nearly impossible to give useful comments.
There were no tests. Sorry to be a downer.
Sorry, but I don't understand this mail ? -- Paul POULAIN Consultant indépendant en logiciels libres responsable francophone de koha (SIGB libre http://www.koha-fr.org)
participants (3)
-
Jerome Vizcaino -
MJ Ray -
paul POULAIN