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

UTF-8
by Dorian Meid 03 Dec '07

03 Dec '07

Gentlemen, I have a problem using UTF-8 with Koha. If I import MARC-Data via z3950 special characters are treated differently ÄÜÖäüö works at some pages but not in all. ß dosn't work at any page. This is the ü I get from z3950 and this is the ü which is generated when I type it. These are two different characters. I'm using Koha 2.2.8, MySQL5 and Apache 1.3 on Mac OSX 10.4 with Firefox. I've read the notes on the Wiki and my server, Database and the tables are set to UTF-8. I also set the templates encoding variable and added the encoding to httpd.conf The z3950 server sends data UTF-8 encoded Did I miss something? Dorian Meid

3 5

Code Cleaning : Authorities.
by Henri-Damien LAURENT 13 Sep '07

13 Sep '07

Those first two are the main reason I am writing. Does anyone still use thesaurus.pl ? Considering that now frameworks allow to link Authorities with one another, I think we should drop linker down. One problem is : All linking and hierarchy code is UNIMARC and hardcoded. I would like to allow more versatility on this. But this would require those new system preferences : relation type subfield (UNIMARC 2) relation authnumber subfield (UNIMARC 3) relation authtype subfield (we should agree on using authtypes or authtypecode as value in those subfields) (UNIMARC 5) relation tag (UNIMARC 550) child flag (UNIMARC f) mother flag (UNIMARC "g") Plus would require some little modifications of auth_finder to enable relation Choice. Maybe it could interesting to enable multiple authority link for a field. This would only require to manage a list of authorities to search in. We reviewed the AuthoritiesMARC code with Paul. And thought that unification between Authorities.pm and Biblio.pm was not a worth the work. a) Authorities search is much different from biblio search. b) inner tables differs so that it would oblige us to make heavier functions. So Authorities Will stay as such. While Code cleaning it, some questions remains. GetSummary as well as Buildhererarchies is still quite customer dependant and used for display. But it Hardcodes some HTML preprinting. So that when people want This or that display, one has to modify a C4/AuthoritiesMARC. For instance : One wants that term list are displayed : /Heading/ BT /Broader Term/ NT /Narrower Term/ UF /Used For/ /Comments./ Another wants that term list are displayed : /Heading/ TG /Broader Term/ TS /Narrower Term/ EP /Used For/ Comments : /Comments/. Another wants only Heading$a -- Heading$b -- Heading$z And we have to make little changes to the code and then upgrading process is harder. Solution ? A) Using xslt ? B) using HTML::Template to "simulate xslt" Then ppl would only have to modify template for summary processing "mini" template on each record. C) keeping this as such. This would also be helpful in getting information for search resultlists in biblios more user adapted. Comments welcome. -- Henri-Damien LAURENT

3 2

copyright holder
by Paul POULAIN 06 Jul '07

06 Jul '07

Hi (again...) I realise that, for instance, the Koha copyright is given to katipo (and it's written in almost every script). Knowing that katipo has resigned from it's Koha engagment by selling it to libLime, I think we can put that point on an agenda to decide what to do with the copyright. Assign it to libLime ? to the french NPO that should rise (very) soon ? to someone/something else ? we don't care, stay with katipo ? -- Paul POULAIN et Henri Damien LAURENT Consultants indépendants en logiciels libres et bibliothéconomie (http://www.koha-fr.org) Tel : 04 91 31 45 19

8 13

zebra for multi-marc
by long_sam.tw 13 Jun '07

13 Jun '07

hi,programmers zebra support multi-marc ? i run koha for mysql can support coexistent marcs (marc21 & unimarc). marc21 http://lit145.lacc.fju.edu.tw/cgi-bin/koha/opac-MARCdetail.pl?bib=15 unimarc http://lit145.lacc.fju.edu.tw/cgi-bin/koha/opac-MARCdetail.pl?bib=17 laxendion ___________________________________________________ 您的生活即時通－溝通、娛樂、生活、工作一次搞定！ http://messenger.yahoo.com.tw/

5 4

bugzilla daily mail (for chris)
by Paul POULAIN 30 Apr '07

30 Apr '07

Hello chris, I recieve every day a mail with all my pending bugs on bugzilla. atm, the list is quite long, because it contains everything that is affected to me. So, I don't read the mail, & drop it to trash immediatly. Which is a shame, I agree. It would be much more usefull to have : - daily all BLO/CRI/MAJ/NOR bugs - weekly all bugs (including MIN/ENH) hope it's easy to do ;-) -- Paul POULAIN et Henri Damien LAURENT Consultants indépendants en logiciels libres et bibliothéconomie (http://www.koha-fr.org) Tel : 04 91 31 45 19

1 0

Roadmap [important]
by Paul POULAIN 28 Apr '07

28 Apr '07

Hello world, OK, i'll release 2.2.9 soon, based on rel_2_2_7 branch+some bugs ported from rel_2_2 (and only bugfixes) I've reviewed more than 100 commits on rel_2_2 branch, and am sure the stability of this branch is not that good enough to have a 2.2.9 release based on rel_2_2. On the other hand, 3-4 major bugfixes have been done, a release is needed. So i'll do it. But I want to speak of the next step. In the last weeks, we had : - HEAD : a lot of activity from hdl & me : code cleaning mainly. it should now be done. - dev_week : a lot of activity from ccfls (kyle & cindy) and some from libLime as well : some features backported from head (holidays) and a new feature ClubsAndServices, for some testing - rel_2_2 : a lot of activity from libLime : backported some features from head (holidays), and some new features (item level reserves, serials routing lists I think it is important that all commiters says what they are doing & when they think they will get enough stability to have a roadmap and a timeline. I also think it's important that all features added on 2.2 / dev_week were also added on head (or we could loose the features. That can be acceptable, but at least we will be aware of the fact, to avoid any bad surprise) Last but not least : I think we should speak of our organisation : it seems that rel_2_2 branch will become a new version with new features. I strongly think we should not call this version 2.2.10, but 2.4 or something like that, to point that it has new features & probably less stability. So we will need a 2.4RM. In the last 3 weeks, I could not get in touch with Joshua, or almost. I'm happy that business is going well for libLime, but, pls, try to find time to the community, we need everybody to work in the same direction, and know the direction we are going ;-) Our (hdl & me) position is clear : - I support 2.2.x branch as Release Maintainer - We work hard on head to achieve a 3.0 stable asap. code cleaning is done (although it's never done in fact. But all what had to be done is done), we plan to work on YUI asap, to have koha 3.0 stable for early Q3 Waiting for everybody thoughts, wishes & args ;-) -- Paul POULAIN et Henri Damien LAURENT Consultants indépendants en logiciels libres et bibliothéconomie (http://www.koha-fr.org) Tel : 04 91 31 45 19

3 2

items table
by Henri-Damien LAURENT 27 Apr '07

27 Apr '07

Hi, I am investigating in items table to see which data are used, useful and useless. I found that. Those information are meaningfull and useful : itemnumber biblionumber biblioitemnumber homebranch holdingbranch itemnotes location itemcallnumber itemlost notforloan timestamp reserves for reserve management dateaccessioned (boils down to creation date) If I understand correctly. The problem is that if MARC data is favoured, then we loose this value if not linked. wthdrawn is used in Circulation.pm to cancel an issue if set. renewals is used and updated in Circulation.pm. Maybe it could get into issues table. paidfor is used in FixAccountForLostAndReturned but usage is rather cryptic restricted (I cannot tell the difference with notforloan ?) itype ??? Those fields I propose to drop : binding (unknown use) onloan,issue_date are Already in issues + unknown use. issues (can be calculated from issues table) price,replacementprice (used in Overdues only for selection),replacementpricedate,booksellerid are account values which seem never to be used.

2 1

koha 2.2.9 roadmap
by Paul POULAIN 27 Apr '07

27 Apr '07

Hello all, The rel_2_2 CVS branch is still very active (from LibLime). A lot of new features have been added (some backported from head). Those new features are a problem for stability, and a few major problems have been solved in this branch. Thus, i've ported to the rel_2_2_7 branch all bugfixes & could release a 2.2.9 with them. Here is the list : * MAJOR bug in addbiblio and additem (Bug 1330). Previously, if you added a field to a biblio it would save it with the same tagorder as one of the items, and then editing an item would result in it being deleted. * fixed some SQL queries (mySQL5 errors. That does not mean koha 2.2.x is mySQL5 compliant, but that's some errors identified & fixed. Just expect koha 2.2.9 to work with fewer problem under mySQL5) * fixed a SQL typo in overdues fixing on return (database was not properly updated) * Solved a problem where a plugin value(fixed fields...) would be lost when editing a record * fixed a bug in expiry date calculation * ENH in z3950 search : adding a test in search to avoid a system error if the server returns an invalid error (can happend, depending on z3950 server) * ENH: Added finer ISBD parsing to allow subfield values to contain {}. * ENH: removed an extra (& useless although harmless) call to MARChtml2xml * ENH: if branch unknown from Koha, take it from userenv, instead of first-defined. This will set branch to users registration branch if not explicitly set. TRANSLATORS : i've translations for french, and spanish that are uptodate. The templates are the same as for 2.2.7/2.2.8 Let me know if you have other templates to add/update. what is the status of ukrainian translation (should be OK I think) -- Paul POULAIN et Henri Damien LAURENT Consultants indépendants en logiciels libres et bibliothéconomie (http://www.koha-fr.org) Tel : 04 91 31 45 19

1 0

(no subject)
by Chris Cormack 26 Apr '07

26 Apr '07

Hi All Paul Poulain reminded me on IRC the other night I hadn't done a post to the list about my recent change in work circumstances. For those of you who have been around Koha for a while you will know me as Chris from Katipo. Im now Chris from Liblime. Russel and Mason made the move with me as well. Heres the press release about it http://liblime.com/news-items/press-releases/liblime-to-acquire-katipo/ Just an explanation for any of you wondering who is this chris from liblime guy, I havent seen him on the lists before :) Chris -- Chris Cormack chris.cormack(a)liblime.com VP Research and Development www.liblime.com LibLime +64 21 542 131

1 0

Re: [Koha-cvs] koha/koha-tmpl/intranet-tmpl/npl/en/bull subscr... [rel_2_2]
by Paul POULAIN 26 Apr '07

26 Apr '07

Ryan Higgins a écrit : > CVSROOT: /sources/koha > Module name: koha > Branch: rel_2_2 > Changes by: Ryan Higgins <rych> 07/04/26 04:30:48 > > Modified files: > koha-tmpl/intranet-tmpl/npl/en/bull: subscription-detail.tmpl > serial-issues.tmpl > full-serial-issues.tmpl > > Log message: > small language changes >  > - Waited > + Waiting (cc: to koha-devel, anyone can give it's opinion) mmm... I won't argue on english quality, but : a "waited" serial means that it's not here, and is expected. A "waiting" item means (not serial) is here, but waiting for an event(being picked up by a patron, for a reserved item). Thus, in translations, it will be confusing to use "waiting" for 2 things. Could we choose a different word ? Is "expected" acceptable ? -- Paul POULAIN et Henri Damien LAURENT Consultants indépendants en logiciels libres et bibliothéconomie (http://www.koha-fr.org) Tel : 04 91 31 45 19

1 0