November 2013 - Koha-devel - lists.koha-community.org

Koha 3.12.x and VIAF
by Partha Mukhopadhyay 29 Nov '13

29 Nov '13

2 1

November 2013 Koha Community Newsletter has been published
by Daniel Grobani 28 Nov '13

28 Nov '13

Hi, The November 2013 edition of the Koha Community Newsletter has been posted to http://koha-community.org/koha-community-newsletter-november-2013/. Cheers, Daniel Grobani Koha Community Newsletter Editor

1 0

Some thoughts about "any" index
by Mathieu Saby 28 Nov '13

28 Nov '13

Hello I've written a patch for making the "an" index more precise with DOM indexing. Bug 11291 But the more I think of it, the less I am sure of my solution ;-) The question is : is it good or not to have a way to find information anywhere in a record, really anywhere, whatever the field or subfield? If you think so, my patch is not a good idea, because it will make DOM indexing behave like GRS-1 on that point ("any" indexes all fields already indexed in a specific index). In fact it raises a second question: even if it is usefull for staff to have a broad (on all specific indexes) or even a broader (on all fields of the record) index, it is a good thing that this index is used in OPAC simple search ? I believe not. Because some data are not made to be searched by an average user, and can even make a precise search on a subject more difficult. For example, in UNIMARC, the $2 subfield in Subjects 6XX fields contains the code of the thesaurus used (like LCSH, or RAMEAU in France). It's really only a librarian-centric information. You will never search in an OPAC all records indexed with all LCSH subject. Idem for the birthdate of an author. Nobodoy search a book by typing the birdthdate's author. Birthdate are entered to disambiguate authors. Idem for most notes, for the city of publication, for the country and language code, etc etc. So, for that, I wrote last year a patch 8962, whose aim is to index in "any" ony some specific indexes, and rename the current "any" index into "anywhere". This "anywhere" index will be usable for Staff. Of course, as the "any" indexed is specified in config file for each field which need it, it will be easy to add or remove new field to this index if a library want it. I made it for GRS1 only for the moment, but I need to make it DOM compliant. As it will require 1 or 2 days of work, I would like to know if someone object this logic. If you think it is a good idea, I can propose you 2 options for the behavior of "anywhere" index for DOM : 1 - ALL fields of the record indexed in it. Like current DOM "any" index. 2 - Only fields of the record already indexed in a specific index. Option 2 will require something like patch 11291. PS : I'm leaving my position the 6th of december, and I won't work anymore on Koha in 2014:-( . So I will probably "un-assign" soon the bugs I am currently responsible for in Bugzilla. Regards, M. Saby -- Mathieu Saby Service d'Informatique Documentaire Service Commun de Documentation Université Rennes 2 Téléphone : 02 99 14 12 65 Courriel : mathieu.saby(a)univ-rennes2.fr

3 4

Re: [Koha-devel] An idea for revamping the issuing rules
by David Cook 26 Nov '13

26 Nov '13

I don't actually have anything substantive to add to this conversation. Just +1 for a revamped circulation rules editor. -----Original Message----- Message: 2 Date: Mon, 25 Nov 2013 11:44:12 -0500 From: Kyle Hall <kyle.m.hall(a)gmail.com> To: Galen Charlton <gmc(a)esilibrary.com> Cc: Koha Devel <koha-devel(a)lists.koha-community.org> Subject: Re: [Koha-devel] An idea for revamping the issuing rules system Message-ID: <CACpVHfzdmP0tiR6Vr2Y2ApF7trOCV23odOE9N1AAj_foPckt9w(a)mail.gmail.com> Content-Type: text/plain; charset="iso-8859-1" > > As Jonathan has mentioned, I've expressed my concerns about a similar > proposal to drop the FK relationships in the discussion in bug 8369, and I > also think that any scheme to refactor the storage of the circ rules must > provide a concrete, user-visible improvement. Just reducing the number of > table involved is not an adequate reason. > Yes, I would assume a revamped circulation rules editor would be sufficient? > > That said, the FKs are only one consideration. Being able to set a > general rule for one part of the circ policy (in your example, the loan > length) that more specific rules that cover another part (in your example, > the maximum number of loans) can fall back on is a change that I *would* > see being beneficial: it would allow for circulation policies to be > expressed more concisely. > Agreed! > A rule_name/rule_value approach to this, however, may have a > maintainability problem: how do you deal with adding a new rule type in the > future? I'd suggest, instead, a scheme where a NULL value in a column such > as issuelength signals that the next more general rule should be consulted. > Do you mean type is in "maxholds" or "issuelength"? In that case, it would be as simple as create one or more rules with that "rule_name". A fully optional rule can simply be left to non-existence. In my mind, I instead of having rules with a NULL value, they simply would not exist. Does that make sense? Or is it that you mean ccode/branchcode should use NULL instead of * with full key constraints? I think that is an absolute must. > > Any scheme to do a major refactoring of the circ rules must, in my view, > cover all of the following bases: > * a well-defined upgrade path that guarantees that there is no change to > effective circulation policy > Agreed, I don't think this would be a difficult one to cover, though it would not simply the rules for those upgrading. They would have to trim their rules by hand, but it would at least mean no change in behavior. > * as always, adequate unit test coverage > Absolutely! > * attention to the user interface for defining circ policy -- if the point > of a refactoring is to make it easier to manage circ policies, the UI > *must* reflect that > Indeed, this is almost the crux of the issue. I foresee a new for a new paradigm in how to visually represent the circulation policies. Maybe instead of the rules being branch-centric as they are now, they should be rule-centric? Perhaps even a tabbed interface with a tab for each rule? > * ideally, some prototyping of that UI first to check any assumptions that > the new version is actually easier to manage > Agreed. I think at least some drawings of a general design would be a good start. Kyle

1 0

An idea for revamping the issuing rules system
by Kyle Hall 25 Nov '13

25 Nov '13

Hey all, this is something I've been thinking about for a while now, and I should probably throw it out there to see if it's just a terrible idea ; ) Right now we have 5 tables dealing with circulation rules. I think we can add much greater flexibility *and* simplicity to how we store and select rules. Instead of having the assortment of branch/patron/item, and then the columns for the rules themselves. what if we had just one table with the following schema: branchcode categorycode itemtype rule_name rule_value For example, if every rule right now has a checkout length of 14, but have different max issue quantities, we need to set the checkout length to 14 for each and every combination. With this schema we could have just: *, *, *, issuelength, 14 *,*, BOOK, maxissueqty, 20 *,*,DVD, maxissueqty, 5 *,*,CD, maxissueqty, 10 What does everyone think of this idea? Kyle http://www.kylehall.info ByWater Solutions ( http://bywatersolutions.com ) Meadville Public Library ( http://www.meadvillelibrary.org ) Crawford County Federated Library System ( http://www.ccfls.org ) Mill Run Technology Solutions ( http://millruntech.com )

3 3

Re: [Koha-devel] [Koha-translate] Problems with translating Card into Spanish
by Paul Poulain 22 Nov '13

22 Nov '13

Le 21/11/2013 21:10, Josef Moravec a écrit : > Hello all, > just saying, that we have the same problem with these words ("term" and > "card") also in czech language. We've tried to do some "creative" > translation, but sometimes it looks really strange. In fact, things are pretty simple: if the same english word is used for 2 different things, you can be sure there is at least one language, where there are translation problems. So, if someone sees another word that is disambiguated, please add it to bug 11285 ( http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11285 ) -- Paul POULAIN - BibLibre http://www.biblibre.com Free & Open Source Softwares for libraries Koha, Drupal, Piwik, Jasper

4 4

About the term "term"
by Paul Poulain 20 Nov '13

20 Nov '13

Hello, Translating Koha to french, Mathieu (Saby) discovered that the word "term" is now used in 2 context: * a term (terminology) * a term (course reserve) The translation to french of "term" is different : "terme" and "session" (which is also how we would translate the english "session" ;-) ) We had this problem with "issue" a long time ago : item checkout / serial issue. We changed "issue" to "checkout" to fix the problem. How could we change one of the 2 "terms" to have different words, and correct translations ? -- Paul POULAIN - BibLibre http://www.biblibre.com Free & Open Source Softwares for libraries Koha, Drupal, Piwik, Jasper

3 3

CSS and translation
by Fridolin SOMERS 19 Nov '13

19 Nov '13

Hie, There are in CCSR theme some translatable strings in mobile.css. Like : body#opac-detail #holdingst td.itype:before {content: "Item type : ";} But this text is not present in PO file. Are in fact the css files translatable with PO files ? Best regards, PS : you may notice I changed from Fridolyn to Fridolin, it his may original first name. -- Fridolin SOMERS Biblibre - Pôle support fridolin.somers(a)biblibre.com

3 4

Setting up QA Test Tools
by Mark Tompsett 19 Nov '13

19 Nov '13

Greetings, The QA test tool is handy to have set up. You can check your own work, before posting to bugzilla. It helps to eliminate those FAILED QAs that could have been avoided due to some simple stylistic issue. After helping dpk get it set up, I figured a wiki page was in order. http://wiki.koha-community.org/wiki/QA_Test_Tools I was wondering if Test::Perl::Critic::Progressive could be hosted, so the instructions could be simplified. Feedback, tweaks, et cetera appreciated. GPML, Mark Tompsett

2 1

Share Koha 3.10 for windows with community
by Ajmal Khan 19 Nov '13

19 Nov '13

paklag (www.paklag.org) has compiled Koha 3.10 for windows version like live CD Just copy on zip file , unzip and run. Is there any copyright issue? Koha for windows' versions upto 2.9 normally user download appache, mysql, perl and koha code from their separate websites. we are ready to share with koha community. Please guide what to do. Best Regards Muhammad Ajmal Khan Secretary General

3 2