June 2003 - Koha-devel - lists.koha-community.org

Templates internationalisation
by Jerome Vizcaino 14 Jun '03

14 Jun '03

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

3 4

inflexible field types for call numbers
by robweir＠alum.drexel.edu 12 Jun '03

12 Jun '03

Hi all, I'd like to address an issue that I think could limit Koha's acceptance as a viable solution in certain parts of the world - specifically the current database fields available for storing call number information. Since call numbers are so vital for a library and because there are so many different systems for assigning call numbers, I think it would be to our advantage to to make Koha as flexible as possible to work as many call number systems as possible. I think what I'm proposing might only involve changing a couple field types or adding a field or two. Since we need to write conversion scripts to move data from V1.2.3 to V2.0, wouldn't this be the best time to tweak the database fields? The issue I'm confronting is that almost every library I'm familiar with here in the USA uses call number labels on the spines of their books with four or even sometimes five lines of call number information. The second line is usually all numbers, but not always. So basically there is a need to store four or five fields worth of alpha-numeric call number information with each field containing up to 8 or 10 characters. In looking at the current fields available for call numbers in the biblioitems table, I find several are not flexible enough to store this kind of data because of their field type or length. Specifically, itemtype is varchar(4), dewey is double(8,6), subclass is char(3), and publicationyear is smallint(6). So none of those fields is suitable for storing up 8 to 10 digits of alpha-numeric call number information. Did I miss some other possible fields, or what is a library with four fields of call number information supposed to do? Ideally, I think Koha should have five fields possibly of type varchar(10) available for storing call number information. If dewey and subclass were converted to varchar, that would provide two. Would making that conversion break anything in the existing code? (I do see a number of FIXME comments already in Search.pm about dewey being a string and not a floating point number). Are there any other existing fields that could be adapted for this purpose, or would it hurt to add a couple field to the biblioitems table? What is the classification field for? Once these fields are available for storing the data, individual libraries could develope their own templates for displaying the call number information in a format that matches the spine labels on their books. I would be interested to hear if anyone else has confronted this problem and how they solved it. What is Nelsonville Library doing for their call numbers? What call number systems are used in other parts of the world and would this idea work for them? Thanks, Rob

2 1

Perl variables appearing in acquisitions page
by Buchan Milne 11 Jun '03

11 Jun '03

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 We are testing koha for internal use in tracking publications in our company. The other admin (who is out for the day, and on holiday for a week from tomorrow) set koha up, so I'm left to see if I can solve the admin staff's problems. I am not too familiar with how koha works, but the same behaviour appears on the demo setup: http://hlt.katipo.co.nz/cgi-bin/koha/acqui.simple/additem-nomarc.pl?biblion… You will see the drop-down boxes aren't filled correctly. I am not too familiar with HTML::Template, so haven't been able to track down the reason for this. Note, we don't intend to use MARC records. Any hints on how to go about fixing this? Also, we have migrated all authentication systems to use LDAP (including windows machines via Samba with LDAP support), so we would also be interested in support for LDAP authentication (preferably using a normal unix username instead of a card number). We are running 1.9.3 on apache 1.3.22 (with patches of course) with MySQL 3.23.41 and Perl 5.6.1 Regards, Buchan - -- |--------------Another happy Mandrake Club member--------------| Buchan Milne Mechanical Engineer, Network Manager Cellphone * Work +27 82 472 2231 * +27 21 8828820x202 Stellenbosch Automotive Engineering http://www.cae.co.za GPG Key http://ranger.dnsalias.com/bgmilne.asc 1024D/60D204A7 2919 E232 5610 A038 87B1 72D6 AC92 BA50 60D2 04A7 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE+5y6vrJK6UGDSBKcRAjl4AJ46zvOHDiWtT75ERmGOYJwFTcKwpACdFvkd uhuF5pVHgCD2uPpeQoBBoVc= =/gq0 -----END PGP SIGNATURE----- ****************************************************************** Please click on http://www.cae.co.za/disclaimer.htm to read our e-mail disclaimer or send an e-mail to info(a)cae.co.za for a copy. ******************************************************************

1 0

2.0 release meeting
by Pat Eyler 10 Jun '03

10 Jun '03

Hello everyone, With a 2.0.0 release rapidly approaching, and a bunch of bugs needing to be found, reported, prioritized, and fixed, we're going to institute a weekly irc meeting to help handle the load. We'll meet every Wednesday at 1900 UTC in the #koha channel at irc.katipo.co.nz -- Anyone is welcome to attend, please bring your bug reports. If you can't make it this week (short notice, I know), please drop in to any of the meetings you can make. (Here are a couple of conversions follow) UTC France Seattle New Zealand Wed 19:00 Wed 21:00 Wed 12:00 Thu 07:00 (Please feel free to translate and/or forward this message to other mailing lists as appropriate.) -pate Pat Eyler Kaitiaki/manager migrant Linux sys admin the Koha project ruby, shell, and perl geek http://www.koha.org http://pate.eylerfamily.org

1 0

2.0 release meeting
by Pat Eyler 09 Jun '03

09 Jun '03

Hello everyone, With a 2.0.0 release rapidly approaching, and a bunch of bugs needing to be found, reported, prioritized, and fixed, we're going to institute a weekly irc meeting to help handle the load. We'll meet every Wednesday at 1900 UTC in the #koha channel at irc.katipo.co.nz -- Anyone is welcome to attend, please bring your bug reports. If you can't make it this week (short notice, I know), please drop in to any of the meetings you can make. (Here are a couple of conversions follow) UTC France Seattle New Zealand Wed 19:00 Wed 21:00 Wed 12:00 Thu 07:00 (Please feel free to translate and/or forward this message to other mailing lists as appropriate.) -pate Pat Eyler Kaitiaki/manager migrant Linux sys admin the Koha project ruby, shell, and perl geek http://www.koha.org http://pate.eylerfamily.org

2 2

Re: [Koha] Barcode scanner - keyboard wedge or not
by paul POULAIN 06 Jun '03

06 Jun '03

Waylon Robertson wrote: >16/05/03 01:54:03, paul POULAIN <paul.poulain(a)free.fr> wrote: >Well.. incidently.. I know nothing about the template system.... and I know only english. Just want it in pre-template perl? > > Fairly simple : the templates are stored in a specific file & path, and looks like : /<HTML> <TMPL_VAR NAME=startmenuissue> <p> Each box needs to be filled in with fine,time to start charging,charging cycle<br> eg 1,7,7 = $1 fine, after 7 days, every 7 days.<p> <table> <tr bgcolor="white"> <TMPL_LOOP NAME=firstrowloop> <td><TMPL_VAR NAME=description></td> </TMPL_LOOP> </tr> <form action=/cgi-bin/koha/updatecharges.pl method=post> <TMPL_LOOP NAME=tablebodyloop> <tr bgcolor="whitw"> <td><TMPL_VAR NAME=description></td> <TMPL_LOOP NAME=rowloop> <td><input type=text name="<TMPL_VAR NAME=name>" value="<TMPL_VAR NAME=value>" size=6></td> </TMPL_LOOP> </tr> </TMPL_LOOP> </table> <input type=submit> </form> <TMPL_VAR NAME=endmenuissue> </body> </HTML>/ It's a mix of true HTML and H::T variables. The H::T are replaced during execution by "true" value. The templates are managed by specific koha-subs, that looks which one to use and check for auth : /use strict; use CGI; use C4::Auth; use C4::Output; use C4::Interface::CGI::Output; use C4::Database; use HTML::Template; my $query = new CGI; my ($template, $loggedinuser, $cookie) = get_template_and_user({template_name => "parameters/admin-home.tmpl", query => $query, type => "intranet", authnotrequired => 0, flagsrequired => {parameters => 1}, debug => 1, }); output_html_with_http_headers $query, $cookie, $template->output; / Look at : http://html-template.sourceforge.net/html_template.html#tutorial for a tutorial and some explanations. HTH -- Paul POULAIN Consultant indépendant en logiciels libres responsable francophone de koha (SIGB libre http://www.koha-fr.org)

4 6

template names
by Tonnesen Steve 05 Jun '03

05 Jun '03

Wiping egg off my face. :) Okay, so there are separate templates for the opac and intranet sides now. I forgot. So now I've added a couple of subroutines to Search.pm that will grab a list of themes or languages available in the opac or intranet sides, and the systempreferences edit page will display this list and allow you to specify your preferred order. So there will be "intranettheme", an "opactheme", and "languageorder" settings. The last appears to be garnered from web browser settings if available, otherwise falls back on the system preference setting. Steve.

1 0

Re: [Koha-devel] Bug #35: Enhancing system parameters
by Owen Leonard 05 Jun '03

05 Jun '03

> You can take a look at the systempreferences page > at: > > http://142.28.224.19/cgi- > bin/koha/admin/systempreferences.pl Not related to your question, but: I wonder if it would be possible or practical to have system preferences check for available themes and display an appropriate list? -- Owen

3 2

Bug #35: Enhancing system parameters
by Tonnesen Steve 05 Jun '03

05 Jun '03

I'm working on bug #35. I'd like to combine some of the different "styles" of boolean questions so that they are all "yes/no" type questions. Right now we have three different styles: yes/no 1/0 on/off I've done a search of all .pl and .pm files and found the following list of locations that use preferences. Some of these will have to be changed (notably, 'marc', 'autoMemberNum', and 'autoBarcode') to reflect the change to a "yes/no" value. If nobody objects to any of this, I'll carry on. You can take a look at the systempreferences page at: http://142.28.224.19/cgi-bin/koha/admin/systempreferences.pl ./cgi-bin/acqui/acquire.pl: autoBarcode ./cgi-bin/acqui/newbiblio.pl: autoBarcode ./cgi-bin/admin/thesaurus.pl: authoritysep ./cgi-bin/value_builder/unimarc_field_210c.pl: authoritysep ./cgi-bin/value_builder/unimarc_field_225a.pl: authoritysep ./cgi-bin/loadmodules.pl: acquisitions ./cgi-bin/loadmodules.pl: marc ./cgi-bin/mainpage.pl: marc ./cgi-bin/search.pl: marc ./cgi-bin/acqui.simple/addbooks.pl: marc ./cgi-bin/acqui.simple/isbnsearch.pl: marc ./modules/C4/Circulation/Circ2.pm: noissuescharge ./modules/C4/Auth.pm: timeout ./modules/C4/Auth.pm: insecure ./modules/C4/Authorities.pm: authoritysep ./modules/C4/Boolean.pm: insecure ./modules/C4/Breeding.pm: marcflavour ./modules/C4/Date.pm: dateformat ./modules/C4/Input.pm: checkdigit ./modules/C4/Members.pm: autoMemberNum ./modules/C4/Output.pm: opaclanguages ./modules/C4/Output.pm: opaclanguages ./modules/C4/Output.pm: template ./modules/C4/Output.pm: opacthemes ./modules/C4/Output.pm: theme ./modules/C4/Output.pm: allowthemeoverride ./modules/C4/Output.pm: languageorder ./modules/C4/Print.pm: printcirculationslips ./modules/C4/Print.pm: printreserveslips ./modules/C4/Print.pm: printcirculationslips

1 0

Authorised values
by Jerome Vizcaino 05 Jun '03

05 Jun '03

Hi I've modified the authorised_values.pl file so that empty lib field is now inserted as a NULL value in the database. This way, values inserted without the lib field are now displayed correctly. The modified file is attached. Can anyone check my work and supply it to CVS ? I've modified lines 113-116. Thanks. Jerome

1 0