April 2008 - Koha-devel - lists.koha-community.org

RFC : Subscription management : Getting a more scalable way to manage numberings
by Henri-Damien LAURENT 14 Apr '08

14 Apr '08

Hi, I am planning to adapt subscription-add.pl in order to get rid of bugs that makes subscription-add quite a burden to use. 1st : one cannot add a new numbering method friendly 2nd : One HAS to click on irregularities and re enter irregularities any time one edits the subscription. 3rd : Nonnumerical method is strange to me. To accomplish 1st and 3rd, I propose to add those tables : ***frequency table :*** id label : short description Unit : day/week/month/year frequency (integer defaulted to 1, would record the count of days for a bi-weekly for instance.) issuesperunit expectedissuesperyear ***numberingpattern table :*** id label : tinytext(256) description : text add1 numbering1 every1 whenmorethan1 setto1 basedonpublisheddate1 add2 numbering2 every2 whenmorethan2 setto2 basedonpublisheddate2 add3 numbering3 every3 whenmorethan3 setto3 basedonpublisheddate3 basedonpublisheddate : This field would allow people to begin a subscription in the middle of the year without having to edit the numbering table to edit lastvalues and innercounters. ***nonnumericalnumbering table :*** code number labeltodisplay Example : season 0 Spring season 1 Summer season 2 Fall season 3 Winter day 0 Sunday day 1 Monday day 2 Tuesday day 3 Wednesday .... daytime 0 morning daytime 1 noon (would it be useful ?) daytime 2 evening month 0 January .... But this solution would not solve : - roman numeration for more than ten elements, unless the table would get huge. Moreover, I couldnot get a PERL module managing numbers to roman numbers conversion. But I cannot think it has not already been done. - period from date to date displaying (i.e. From 2. to 9. February, for a weekly issue) And add those fields to subscription table : numbering1, numbering2, numbering3 : If not NULL, then is filled with a Code from nonnumericalnumbering table and will be used in GetNextSeq. countperunit : records the count of issues per day/week/month so that it could be recorded (Date::Calc donot allow floats date adding. For instance, say : I receive a subscription twice a day, I have to count how many times I have received this subscription before adding a new day) then we would pass the tables in Js and use them to create our numbering. fixedissuedates : If a subscription is irregular BUT has fixed dates for release, will store figures like irregularities receive on 1 and 3rd day of week, 1st and 3rd day of month, .... depending on frequency. Irregularities would be optional and display in a window the expected issues periods based on frequency and one could check the periods an issue is not published. -- Henri-Damien LAURENT

1 0

locale dependencies and perl
by Ignacio Javier 14 Apr '08

14 Apr '08

Hi developers, just a thing I thought could be very interesting, please read this in a latin1 capable e-mail agent: Aparently marc8 records with latin1 extensions are being correctly stored in database, when marc8 is specified as source encoding, for z3950 records that come in that format. *** Well..., not so. *** Internet Explorer renders correctly the not so correct marc8 to utf8 transformation where chars from latin1 character repertoire are recognized in the transformation. What is really doing koha, when doing marc8 decoding/MARC21, is to store in database a sequence of: base character + unicode form of (tilde|cute|grave...etc) ...that is: a´, a`,n~, etc... ...with ` or ´ or etc... in UTF-8 (using 3 native bytes instead of 2 native bytes) Instead of: á, à, etc... (2 native bytes) Internet Explorer, not surprisingly for me, renders a´ as á, etc... but no other tools do it this way, for example firefox renders í as i with an upper to the dot acute. Ignacio Javier Gómez Rodríguez Analista - Programador Tfno: 902905590 - Fax: 981571425 ignacio.gomez(a)coremain.com www.coremain.com _______________________________________________ Koha-devel mailing list Koha-devel(a)nongnu.org http://lists.nongnu.org/mailman/listinfo/koha-devel

2 2

Koha 3 Beta 2 - Second step of Web Installer returns blank page for Portuguese language (pt-PT)
by Ricardo Dias Marques 14 Apr '08

14 Apr '08

Hi list, I'm finishing my installation of Koha 3 ("Beta 2"), in a virtual machine - that I created from scratch (again) - running Linux (openSUSE 10.3). I'm using the "default" Apache (2.2.4) and the "default" MySQL (5.0.45). After I managed to: 1- run perl makefile.PL 2 - install all the required package dependencies (Perl packages - mostly from CPAN - and RPM packages) 3 - create the koha (MySQL) database and the kohaadmin user and the koha system user 4 - run make test and make install 5 - ... I finally reached the first step of the Web Installer, available at: http://hostname:8080/cgi-bin/koha/installer/install.pl That took me to a login screen. I logged in with my kohaadmin username and password (using Mozilla Firefox). That worked and took me to the "Web Installer > Step 1" page (the URL remained the same), to choose a language from a dropdown list. I gladly saw that "famfamfam" is NO longer available as a language - see http://lists.koha.org/pipermail/koha-devel/2008-April/007395.html - and that, now, a long list of languages appear, including pt-PT (for Portuguese), which appears in second place in the list! :) HOWEVER, if I select that "pt-PT" language and then click the on the "Next >>" button, I get a BLANK page. The URL stays the same. If I view the HTML source of that page, I also get no output. Then, I checked the Koha error log, located at: /var/log/koha/koha-error_log I saw the following output: _________________ [Wed Apr 09 20:15:16 2008] [error] [client 191.112.105.34] [Wed Apr 9 20:15:16 2008] install.pl: DBD::mysql::st execute failed: Table 'koha.language_descriptions' doesn't exist at /usr/share/koha/lib/C4/Languages.pm line 324. [Wed Apr 09 20:15:16 2008] [error] [client 191.112.105.34] [Wed Apr 9 20:15:16 2008] install.pl: DBD::mysql::st fetchrow_hashref failed: fetch() without execute() at /usr/share/koha/lib/C4/Languages.pm line 325. [Wed Apr 09 20:15:16 2008] [error] [client 191.112.105.34] [Wed Apr 9 20:15:16 2008] install.pl: Use of uninitialized value in string eq at /usr/share/koha/lib/C4/Languages.pm line 297. [Wed Apr 09 20:15:16 2008] [error] [client 191.112.105.34] [Wed Apr 9 20:15:16 2008] install.pl: DBD::mysql::st execute failed: Table 'koha.language_descriptions' doesn't exist at /usr/share/koha/lib/C4/Languages.pm line 318. [Wed Apr 09 20:15:16 2008] [error] [client 191.112.105.34] [Wed Apr 9 20:15:16 2008] install.pl: DBD::mysql::st fetchrow_hashref failed: fetch() without execute() at /usr/share/koha/lib/C4/Languages.pm line 319. [Wed Apr 09 20:15:16 2008] [error] [client 191.112.105.34] [Wed Apr 9 20:15:16 2008] install.pl: DBD::mysql::st execute failed: Table 'koha.language_descriptions' doesn't exist at /usr/share/koha/lib/C4/Languages.pm line 324. [Wed Apr 09 20:15:16 2008] [error] [client 191.112.105.34] [Wed Apr 9 20:15:16 2008] install.pl: DBD::mysql::st fetchrow_hashref failed: fetch() without execute() at /usr/share/koha/lib/C4/Languages.pm line 325. [Wed Apr 09 20:15:16 2008] [error] [client 191.112.105.34] [Wed Apr 9 20:15:16 2008] install.pl: Use of uninitialized value in string eq at /usr/share/koha/lib/C4/Languages.pm line 297. [Wed Apr 09 20:15:16 2008] [error] [client 191.112.105.34] [Wed Apr 9 20:15:16 2008] install.pl: DBD::mysql::st execute failed: Table 'koha.systempreferences' doesn't exist at /usr/share/koha/intranet/cgi-bin/installer/install.pl line 705. [Wed Apr 09 20:15:16 2008] [error] [client 191.112.105.34] [Wed Apr 9 20:15:16 2008] install.pl: HTML::Template::Pro:template /usr/share/koha/intranet/htdocs/intranet-tmpl/prog/pt-PT/modules/installer/step1.tmpl not found! at /usr/share/koha/intranet/cgi-bin/installer/install.pl line 714 ________________ That last line of the output made me think that maybe there was a missing folder for "pt-PT" under /usr/share/koha/intranet/htdocs/intranet-tmpl/prog In fact, by doing a "ls -1 /usr/share/koha/intranet/htdocs/intranet-tmpl/prog/" (-1 stands for single column output), I get the following output: de-DE el-GR en es-ES es-VE fr-FR hu-HU hy-Armn img kn-Knda lo-Laoo nb-NO nl-NL nn-NO pl-PL ru-RU sr-Cyrl sv-SE tr-TR uk-UA zh-Hans-CN zh-Hans-TW So, I think there should be a "pt-PT" directory there, but it seems to be missing. Am I right? Thanks in advance! Best wishes, Ricardo Dias Marques lists AT ricmarques DOT net

4 8

Koha 3.00Beta, language template provided (to joshua)
by paul POULAIN 13 Apr '08

13 Apr '08

Hello Joshua, I just see that in the 3.00beta package, the templates are not provided in the different languages. Thus, to get Koha 3.00beta in French, you have to use tmpl_process3.pl and generate the french templates. This is not explained in the install notes, unless i'm mistaken Have I missed something ? why didn't you generate localized templates before releasing ? I think, at least for a stable version, we should provide localized templates, even at the prize of a .tar.gz growth cheers -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : 04 91 31 45 19

2 1

changing the language files localy
by Axel Bojer 12 Apr '08

12 Apr '08

Hi! We have successfully installed Koha beta2, and are proof reading it now. What would be nice were if we could change the language files manually on our installation, just to check our translation before we submit it toy you. Is this possible? For other programs there are *.mo-files in /usr/share/locale-langpack/ but there are no koha/staff/opac-files there. All I find is tmp-files with some localised language-strings, like: nb-NO/modules/installer/auth.tmpl I suppose this mean the answer to my question is now, then? So, if not: Will the language files be updated for the RC-versions? If yes, when is then the last day we can send new language files for RC1? Best regards Axel Bojer

2 2

FW: [Koha] Fines for Short Loan Items
by Bernard Shiundu 12 Apr '08

12 Apr '08

Bumped into the mail below on the general list, just cross-posting with a small comment/question I had this same issue and solved it in rel2_2 (which I'm currently running in production) by porting the reserve circulation code from koha neu. The way it worked/works is that items circulating on the hour are issued in a separate circulation module (similar to the 'normal' one) with the data being stored in reserve circulation table and overdue fines being calculated on the fly and posted to accountlines when the item is returned rather than as a cron job. Before I start working on porting it to Koha 3 and submitting my code, is anybody working on this for Koha 3? Don't want to re-invent the wheel ;) ====================== Bernard Shiundu Systems Librarian, Strathmore University ________________________________ From: Ayoku Ojedokun [mailto:aaojedokun2003@yahoo.co.uk] Sent: Friday, April 11, 2008 11:35 AM To: Koha Mailing List Subject: Re: [Koha] Fines for Short Loan Items If this is the case, I suggest that the issue be looked into. Jesse <pianohacker(a)gmail.com> wrote: I'm afraid not; all of the fining and checkout code in Koha works in days. -- Jesse _______________________________________________ Koha mailing list Koha(a)lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha ________________________________ Yahoo! for Good helps you make a difference<http://us.rd.yahoo.com/mailuk/taglines/isp/control/*http:/us.rd.yahoo.com/e…>

2 2

NZ English Translation
by Joshua Ferraro 11 Apr '08

11 Apr '08

On Wed, Apr 2, 2008 at 7:17 PM, <russ(a)russandsarah.gen.nz> wrote: > Hi everyone, > > Please forgive the re posting, but I think I managed to time my original > for when HDL was moving the lists. > > Anyway here is my request again. > > I would like to do a Koha Translation into NZ English. This way we can > manage some of the terms in the interface that those of us in this part of > the world don't use. Things like zipcode -> postcode, state -> region etc. > > Can a en-NZ language code be setup please? If we're going to start getting picky about English in the official releases, and having multiple variants, I'd suggest we first clean up the existing English to a specific variant so that we have something to work from, rather than the hodge podge that's currently in /prog/en (it's currently a mixture of en-NZ/GB, en-FR and en-US). The best way to do that would be to have some kind of official language dictionary for library terms ... Fortunately, there's a free Dictionary for Library and Information Science that we can avail ourselves of: http://lu.com/odlis/. Would anyone be interested in 'cleaning up' the English language strings in accordance with ODLIS? Also, w/respect to en-NZ, isn't that the same or nearly the same as en-GB? Cheers, -- Joshua Ferraro SUPPORT FOR OPEN-SOURCE SOFTWARE CEO migration, training, maintenance, support LibLime Featuring Koha Open-Source ILS jmf(a)liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS

6 8

IndependantBranches & editing items
by Paul POULAIN 11 Apr '08

11 Apr '08

Hello, I have an open question for a use case we don't handle correctly atm. Suppose a library consortia with IndependantBranches=ON Items can be modified only by the Homebranch. That's logic. but I have a library that is IndependantBranche=ON, but books come from 2 sources : - self-acquired - issued by a third (region wide) library, dedicated to issue books to small library. We have one "BDP" (Bibliothèque Départementale de Prêt) in each department in France, and we have 98 departments... The books issued by the BDP are issued for a long period (3months => 1year). They are stored in a shelf in the holding library as self-acquired books. So, the holdinglibrary sometimes want... to change the itemcallnumber or location And with IndependantBranches=ON, only the homebranch can edit the item, and we have a problem... The easiest solution would be to let holdingbranch edit the items. Could it be OK for everybody ? Not sure. Your opinion welcomed. The other easiest solution could be to say "ok, it's only for superlibrarian". The library could accept this, but, obviously, it's not the best from a user point of view. Another solution could be to have a new syspref, but i'm against adding syspref & syspref & syspref... Does anyone have another solution or idea ? -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : 04 91 31 45 19

3 2

Re: [Koha-devel] [Koha] NZ English Translation
by BWS Johnson 11 Apr '08

11 Apr '08

Salvete! Sorry about the ccing and such, but I want to make sure the proper folks get this, so I just replied all to the last post. I've been thinking for a little while about the nature of the project. To a certain extent, we are all victims of the project's success, which I believe to be a happy problem. The _surface_ problem is that of translation or diction used. (Arguably there isn't even a standard within a given country thanks to trends - some folks prefer Patrons, some customers, some users, et cetera.) I think the deeper problem is that there is one out of the box programme. I truly believe that we're well past the point that that even comes close to working nicely anymore. Well do I also know how very much time dedicated developers like you all put into this, for free. In the end, I think it would save user time to either have a drop down install or different purpose based packages. For the States (I apologise here again, it's been about a decade since I lived in Ireland, and even that was short term, so I hesitate touching someone else's stuff.) I would propose a breakdown based on volume size and Library purpose. For instance small Public, large Academic, School, Consortial, et cetera. If the switches are already flipped for the most part, there will be a lot less hassle at the end of the day for a bunch of effort up front. I bet that a users' group would have good insights into how they would want their package to look by default. All the functionality would remain for each package of course, it would just be a nicer initial Out of the Box flavour for different Library types in different regions. Time could be managed that way, et cetera. (Or maybe not, since I'm not a technical person, but I remember installers for other stuff prompting for time zone and such...) Not in the face, Brooke

1 0

Re: [Koha-devel] [Koha] Notes on patches
by Nicole Engard 10 Apr '08

10 Apr '08

This is a good example - but in some cases I'll take any note at all :) If I can track you down and ask you to tell me what that means it's not a big deal. Nicole On Thu, Apr 10, 2008 at 2:16 PM, Jesse <pianohacker(a)gmail.com> wrote: > Nicole: Do you mean something like: > "Added new Alternate Issuing Rules page under Administration" > Rather than: > "Added smart rules page" > ? > > -- > Jesse > _______________________________________________ > Koha mailing list > Koha(a)lists.katipo.co.nz > http://lists.katipo.co.nz/mailman/listinfo/koha > > -- Nicole C. Engard Open Source Evangelist, LibLime (888) Koha ILS (564-2457) ext. 714 nce(a)liblime.com AIM/Y!/Skype: nengard http://liblime.com

1 0