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

Koha Community Newsletter: November 2014
by kohanews 06 Dec '14

06 Dec '14

Fellow Koha users: The Koha Community Newsletter for November 2014 is here: http://koha-community.org/koha-community-newsletter-november-2014/ Many thanks to the folks who submitted articles and news to this month's newsletter. Please feel free to email us with any corrections or suggestions. Thanks! Chad Roseburg Joanne Dillon Editors, Koha Community Newsletter

1 0

December 11th : day of tests and validation in Lyon
by BOUIS Sonia 05 Dec '14

05 Dec '14

Hi, You have planned a day of tests and validation next Thursday, December 11th, at the university Lyon3, in France. You can have a look at the patches that we have already selected on this Trello : https://trello.com/b/DjAPsqdf/tests-koha-du-11-12-2014 We'll test if they apply cleanly on a master branch next week. Best regards Sonia BOUIS Responsable du Système intégré de gestion des bibliothèques bIBLIOTHÈQUES UNIVERSITAIRES Université Jean Moulin Lyon 3 6 Cours Albert Thomas - B.P. 8242 - 69355 Lyon Cedex 08 ligne directe : +33 (0)4 78 78 79 03 | http://scd.univ-lyon3.fr<http://scd.univ-lyon3.fr/> L'Université Jean Moulin est membre fondateur de l'Université de Lyon

1 0

Big UTF-8 patch set on its way to master
by Tomas Cohen Arazi 04 Dec '14

04 Dec '14

Hi everyone, there has been a lot of work on having regression tests for UTF-8 encoding handling inside Koha, on bug 13264, thumbs up for Zeno and Paola. I encourage you to take a look at the tests and please provide followups or at least feedback on other possible tests so we have the broadest coverage we can. There will always be room for improvement, but I'm happy with the current tests and they way there are written and can be extended. I'm starting to set the jenkins nodes to run them along with the rest of the tests. This change in the jenkins nodes will help us set other kind of tests on the UI like using and OWASP jenkins plugin (or similar). Looking forward for your feedback! Tomas

1 0

Developer install zebra configuration broken by default?
by Robin Sheat 04 Dec '14

04 Dec '14

I'm setting up a new koha dev installation, and did make install and have the database set up and so on, and a rebuild does this: $ /mnt/catalyst/koha/misc/migration_tools/rebuild_zebra.pl -v -b -a -x Zebra configuration information ================================ Zebra biblio directory = /home/robin/koha-dev/var/lib/zebradb/biblios Zebra authorities directory = /home/robin/koha-dev/var/lib/zebradb/authorities Koha directory = /mnt/catalyst/koha Lockfile = /home/robin/koha-dev/var/lock/zebradb/rebuild/rebuild..LCK BIBLIONUMBER in : 999$c BIBLIOITEMNUMBER in : 999$d ================================ ==================== exporting authority ==================== 4301.................................................................................................... Records exported: 4363 ==================== REINDEXING zebra ==================== 15:32:22-04/12 zebraidx(3837) [warn] No such record type: dom./home/robin/koha-dev/etc/zebradb/authorities/etc/dom-config.xml ==================== exporting biblio ==================== it goes immediately from that warn to processing the biblios, so it's not actually indexing anything. I've removed the dom. from the start of the path, to no avail. Anyone know what's going on? I also note that rebuild_zebra has terrible error handling: it didn't even tell me anything was wrong when I'd forgotten to install zebraidx. -- Robin Sheat Catalyst IT Ltd. ✆ +64 4 803 2204 GPG: 5FA7 4B49 1E4D CAA4 4C38 8505 77F5 B724 F871 3BDF

1 0

Koha 3.18.0 released
by Tomas Cohen Arazi 01 Dec '14

01 Dec '14

It is with great pleasure that I announce the release of Koha 3.18.0, the latest major release of the Koha open source integrated library system. Koha is the first free and open source software library automation package (ILS). Development is sponsored by libraries of varying types and sizes, volunteers, and support companies from around the world. The Koha 3.18.0 tarball and install instructions can be found on the download page: http://koha-community.org/download-koha/ More install instructions and useful information can be found on the wiki ( http://wiki.koha-community.org/wiki/Installation_Documentation) and in the INSTALL files that come in the tarball Koha 3.18.0 is a major release, that comes with many new features. It includes 14 new features, 120 enhancements and 487 bugfixes. See the complete release announcement on the community site: http://koha-community.org/koha-3-18-0-released/ Kind regards, Tomás Cohen Arazi, Release Manager for Koha 3.18

2 1

Question about debian scripts
by Mark Tompsett 28 Nov '14

28 Nov '14

Greetings, After faking out my development environment (may have gotten the commands wrong, since ln trips me up sometimes): $ sudo ln -s ~/koha-dev/etc /etc/koha $ cd ~/koha-dev/etc $ mkdir sites $ mkdir library $ ln -s ~/koha-dev/etc/koha_conf.xml koha_conf.xml $ cd /usr/share $ sudo mkdir koha $ cd koha $ sudo ln -s ~/kohaclone/debian/scripts bin QUESTION: Is this too evil? I attempted to: $ git bz apply 13413 $ ./debian/scripts/koha-passwd library Now it worked, but... “Press any key to clear the screen...” wasn’t any key, it required enter/return. Currently it is a sh script. If we made it bash, the line: read anykey could become: read -N1 anykey And then it really would be any key. QUESTION: Do all the koha command scripts need to be only sh? GPML, Mark Tompsett

4 3

UTF-8 work on the 3.20 release cycle
by Tomas Cohen Arazi 27 Nov '14

27 Nov '14

First of all, I'd like to thank everyone involved on bug 11944. An specially people working hard on bug 13264 to have integration tests on the UTF-8 big rewrite. That said, it is too late for that to go into 3.18 for the release now. I'll try to add my bits on 13264 so we have all the 11944 pushed into master ASAP once 3.18.x is branched. For 3.18, please fill bugs on encoding problems, and also sign on those that are marked as 3.16 so they can be pushed to the stable branches. Thanks everyone, this work is really important and we are getting it ready for pushing ASAP.

2 3

Double encoding of query_cgi
by David Cook 26 Nov '14

26 Nov '14

Hey all: It looks like there's a problem with the double encoding of query_cgi (at least in the OPAC). It looks like Bug 9239 (commit a8f23264) was responsible for adding uri_escaping to query_cgi into C4::Search. Unfortunately, we also run query_cgi through "html" and "url" filters on almost every .tt template page it features upon. This means that we always have double-encoded query strings, which. isn't really a problem most of the time. Chrome and Firefox seem to be able to handle double encoded query strings just fine. There might be certain conditions where problems arise due to what's put in the query string. but I haven't tried a million test cases. I suppose the thing I'm wondering is. do we remove the filters from the templates or stop encoding in the module? David Cook Systems Librarian Prosentient Systems 72/330 Wattle St, Ultimo, NSW 2007

2 1

upcoming_digest?!
by Mark Tompsett 26 Nov '14

26 Nov '14

Greetings, I was reading misc/cronjobs/advance_notices.pl and was trying to make sense of where $upcoming_digest is set. I think there must be some side-effect obscuring the code. I was wondering if a second pair of eyes might find it. I was trying to determine how $digest->{email} gets set for the from_address call to C4::Letters::EnqueueLetter. GPML, Mark Tompsett

7 6

Fwd: Streamlining frontend development in Koha
by Jesse 25 Nov '14

25 Nov '14

I've been working on Rancor, a professional MARC editor for Koha sponsored by ByWater and DGI, for the past year or so. As Rancor has a lot more client-side complexity than many other parts of the staff interface, I've run into some major frustrations. I have a proposed solution for them, and would like feedback from both developers and translators: Let's rewrite Koha in GWT! But seriously. The issues come down to translation. Making cleanly translatable JavaScript frontend code using Koha's current system requires a lot of finagling and ugly syntax, especially for any complicated string. There are two problems. Problem One: For example, displaying "You have checked out X books, Y of which are on hold" is frustrating to impossible for either the developer or translator: _("You have checked out ") + X + _(" books, ") + Y + _(" of which are on hold") is easy for a developer to write, but gives the poor translator three separate strings to translate. The commonly given solution is to rewrite this as: _("Books checked out: ") + X + _("Books on hold") + Y which works, but is a bit less elegant, and not always realistic. An informal best practice that has some precedent in the OPAC and Datatables is to use named placeholders in the string: _("You have checked out __X__ books, __Y__ of which are on hold").replace("__X__", X).replace("__Y__", Y) This is good, but currently has to be rewritten for every translated string. I'd like to propose a syntax like the following: _$("You have checked out $1 books, $2 of which are on hold", X, Y) or _$("You have checked out $X books, $Y of which are on hold", {X: X, Y: Y}) with a slight preference for the former. Either approach allows translators to reorder substitutions as needed. The exact details of the syntax are up for debate, but something that can be implemented once, thrown into staff-global.js, and used everywhere is the goal. Either approach would be treated the same as: _("You have checked out $1 books, $2 of which are on hold") for the purposes of generating .po's and creating translated templates from existing .po's. Problem two: Currently, for JavaScript code to contain translated strings, it must be placed within a .tt or .inc. This is a historic limitation of the translation scripts (http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4503) The stated reasons for not fixing it, besides the hairiness of the translation scripts, are that a) most JavaScript code has been moved to non-language specific directories and b) there are property-based translation systems available for JavaScript (see the datatables-strings.inc file for an example of how the latter works). Here are my reasons for disagreeing with these two points: a) Keeping most JavaScript code non-language-specific is a very laudable goal, both in terms of separation of concerns and deduplication of files in multi-language installs. I believe that the translation system should allow for translation of strings in .js files, however. Despite factoring out many modules and pieces of UI infrastructure using Require.JS, Rancor is currently sitting at ~1200 lines of code that deal with showing error/informational messages to the user, all of which has to be in a .tt or .inc in the current system. This is untenable for any complex JS code. b) While this is more of a matter of taste, I do not like the properties-based translation system. For one thing, it punts the above problem to a solution like is used for datatables, with the translation strings in a .inc containing a single <script> and the rest of the code in a .js. Also, it introduces a layer of indirection that makes figuring out what is actually displayed to the user (and tracing where a given message came from) needlessly complicated. I believe that while the QA process should continue to encourage splitting out as much functionality as possible into non-language-specific JavaScript, _requiring_ it causes problems. I propose that the translation scripts be extended to process _() (and possibly _$()) directives in .js files in language-specific .../js/ directories. (Note: this is not a "I think this is a fantastic idea that someone else should work on" proposal. I am willing and in fact eager to make these changes. But it would affect many people, so I want your thoughts first.) -- Jesse Weaver

4 5