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

npl zh_TW language files
by long_sam.tw 31 May '06

31 May '06

Hi,Koha core develop team attached files are npl zh_TW language files。please commite them into koha。 thank you laxendion ___________________________________________________ 最新版 Yahoo!奇摩即時通訊 7.0，免費網路電話任你打！ http://messenger.yahoo.com.tw/

1 0

Koha Developer's IRC Meeting
by Joshua Ferraro 30 May '06

30 May '06

Hi folks, Now that the dust has settled, and we're (hopefully) all caught up from being away, it's probably a good time to schedule another Koha developers's meeting on IRC. Do Mondays around 20:00 GMT still work for everyone? Unless I hear otherwise, lets schedule our next meeting for Monday May 29 at 20:00 GMT. Here's the time in your area: http://tinyurl.com/jdbk7 Cheers, -- Joshua Ferraro VENDOR SERVICES FOR OPEN-SOURCE SOFTWARE President, Technology migration, training, maintenance, support LibLime Featuring Koha Open-Source ILS jmf(a)liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS

7 6

Re: New to KOHA
by Deniz Köllhofer 29 May '06

29 May '06

G'day. I was just curious when the 2.2.6 version, including the amazon features and bugfixes, is going to be available. I found a posting by Paul in the archives that said something about end of march... > koha-2.2.5.tar.gz 09-Jan-2006 15:43 2.4M Thanks for you help, Deniz From: Paul POULAIN <paul.poulain@...> Subject: Re: New to KOHA Newsgroups: gmane.comp.misc.koha Date: 2006-02-27 20:43:07 GMT (12 weeks, 6 days, 16 hours and 34 minutes ago) [...] Hello Marie, in fact, henri Damien already developped such a script, it's in CVS, it will be available in *2.2.6* (end of march) -- *Paul* *POULAIN* Consultant indépendant en logiciels libres responsable francophone de koha (SIGB libre http://www.koha-fr.org)

1 0

Re: More Fun With MARC::File::XML: Solutions
by Joshua Ferraro 28 May '06

28 May '06

Hi everyone, Just providing an update on this issue. As you may recall, I've been putting the MARC::Record suite, specifically MARC::File::XML and MARC::Charset, through some fairly rigourous tests, including a 'roundtrip' test, which converts the binary MARC-8 records to MARCXML / UTF-8 and then back to binary MARC but encoded as UTF-8. This test is available here: http://liblime.com/public/roundtrip.pl I discovered a number of bugs or issues, not in the MARC::* stuff, but in the back-end SAX parsers. I'll just summarize my discoveries here for posterity: 1. MARC::File::XML, if it encounteres unmapped encoding in a MARC-8 encoded binary MARC file (in as_xml()) will drop the entire subfield where the improper encoding exists. The simple solution is to always use: MARC::Charset->ignore_errors(1); if you expect your data will have improper encoding. 2. the XML::SAX::PurePerl parser cannot properly handle combining characters. I've reported this bug here: http://rt.cpan.org/Public/Bug/Display.html?id=19543 At the suggestion of several, I tried replacing my default system parser with expat, which cause another problem: 3. handing valid UTF-8 encoded XML to new_from_xml() sometimes causes the entire record to be destroyed when using XML::SAX::Expat as the parser (with PurePerl these seem to work). It fails with the error: not well-formed (invalid token) at line 23, column 43, byte 937 at /usr/lib/perl5/XML/Parser.pm line 187 I haven't been able to track the cause of this bug, I eventually found a workaround that didn't result in the above error, but instead, silently mangled the resulting binary MARC record on the way out: 4. Using incompatible version of XML::SAX::LibXML and libxml2 will cause binary MARC records to be mangled when passed through new_from_xml() in some cases. The solution here is to make sure you're running compatible versions of XML::SAX::LibXML and libxml2. I run Debian Sarge and when I just used the package maintainer's versions it fixed the bug. It's unclear to me why the binary MARC would be mangled, this may indicate a problem with MARC::* but I haven't had time to track it down and since installing compatible versions of the parser back-end solves the problem I can only assume it's the fault of the incompatible parsers. Issues #3 and #4 above can be replicated following batch of records through the roundtrip.pl script above: http://liblime.com/public/several.mrc If you want to test #2, try running this record through roundtrip.pl: http://liblime.com/public/combiningchar.mrc BTW: you can change your default SAX parser by editing the .ini file ... mine is located in /usr/local/share/perl/5.8.4/XML/SAX/ParserDetails.ini So the bottom line is, if you want to use MARC::File::XML in any serious application, you've got to use compatible versions of the libxml2 parser and XML::SAX::LibXML. Check the README in the perl package for documentation on which are compatible... Maybe a note somewhere in the MARC::File::XML documentation to point these issues out would be useful. Also, it wouldn't be too bad to have a few tests to make sure that the system's default SAX parser is capable of handling these cases. Just my two cents. Cheers, -- Joshua Ferraro VENDOR SERVICES FOR OPEN-SOURCE SOFTWARE President, Technology migration, training, maintenance, support LibLime Featuring Koha Open-Source ILS jmf(a)liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS

1 0

Serials Improvements
by Henri-Damien LAURENT 26 May '06

26 May '06

Hi, Chris and Russel, I am working a bit on serials. I have been asked to add a publisheddate to serial table that would store the date the issue was issued. Indeed, when dealing with serials, there are two important dates : - When did we receive it (planneddate) ? - When was it published (Now, no field planned publisheddate)? But then, I think that the more important date for OPAC and users is not the planned and reception date but more the publication date. So that would change a bit the templates. I read on wiki you were working on that as well and you designed some good new stuff ? Would it be a pain to get this new facility work into your system ? -- Henri-Damien LAURENT

1 0

Biblio.pm Choices IMPORTANT
by Joshua Ferraro 24 May '06

24 May '06

Hi folks, I've been looking at merging Biblio.pm from dev-week and HEAD and it looks like there are a few choices that need to be made ... I'd like to get your feedback on these. (BTW: Tumer, go ahead and commit all the Biblio.pm stuff you've got to HEAD, we'll deal with the conflicts after the fact ...) 1. in HEAD we have 'z3859_extended_services', a routine capable of handling all the Z3859 extended services offered by Zebra, as well as 'set_service_options', which sets the service options before calling z3859_extended_services. But in dev_week, it looks like that's handled with 'zebraop' and when zebraop fails it falls back on zebraopfiles ... So which of these routes shall we take, perhaps a combo of both approaches? 2. in HEAD we have no more bibid, is that going to cause any strange conflicts in dev_week code (didn't spot anything specific). 3. in HEAD we have 3 types of subs, REALXXX, NEWXXX, something_elseXXX ... can't we just have one type of sub? Any reason we can't just completely clean up this API once and for all? 4. char_decode (you knew it was coming :-). Tumer, can you check the mail I sent earlier about encoding and see if installing XML::SAX::Expat solves your problems with MARC::File::XML's handling of encoding? If we have to stick with char_decode, then so be it, but I'd really like to have a more standards-compliant way to handle encoding in both MARC21 and UNIMARC. What this means is that in addition to managing the proper encodings (to and from MARC-8 in MARC21, and to and from the appropriate encodings in UNIMARC), Koha should also handle the leader (for MARC21) and tag 100 (for UNIMARC), and properly set the encoding when all is said and done. Internally, I vote that we store everything as UTF-8 in all circumstances. That's all for now .. Cheers, -- Joshua Ferraro VENDOR SERVICES FOR OPEN-SOURCE SOFTWARE President, Technology migration, training, maintenance, support LibLime Featuring Koha Open-Source ILS jmf(a)liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS

3 3

Navigation links in prog templates
by Chris Cormack 24 May '06

24 May '06

Hi All Bruno and I were talking and we were wondering if it is ok to add a general menu, maybe as an include, into the top of the prog templates. With just links to the main sections in koha, and a link back to the mainpage. Its quite easy to get a few pages into a section, and then have to hit the back button lots of times to get back to the main page so you can go somewhere else. Good idea, bad idea, no one cares? :) Chris -- Chris Cormack Programmer 027 4500 789 Katipo Communications Ltd chris(a)katipo.co.nz www.katipo.co.nz

5 4

Fixing my mistakes
by Chris Cormack 24 May '06

24 May '06

Hi all Just a quick thank you to Bruno for fixing my syntax errors that I snuck in when merging and adding version strings to some of the modules. Thanks Bruno, Ill try not to do it again :) Chris -- Chris Cormack Programmer 027 4500 789 Katipo Communications Ltd chris(a)katipo.co.nz www.katipo.co.nz

1 0

New Feature: Export in MARCXML
by Joshua Ferraro 23 May '06

23 May '06

Hi all, I've just committed a new command-line script for exporting bibliographic data from Koha to an ISO2709 _or_ MARCXML file. It currently handles MARC21 records correctly (leader management) and allows the user to specify the desired encoding of the resulting dump file (MARC-8 or UTF-8) as well as the export format (MARC or MARCXML). It needs some work to fully support UNIMARC, as soon as I have a spare moment I'll work on that ... OPTIONS: -format <format> MARC, MARCXML [MARC] -e <encoding> MARC-8 or UTF-8 [UTF-8] -ignoreerrors Ignore encoding errors -assumeunicode Assume Unicode when unsure of encoding -file <filename> Filename to store dump [koha.mrc] -h This file EXAMPLES: \$ ./export.pl --format=MARCXML --encoding=UTF-8 -file=2005-05-23-koha.mrc --ignoreerrors So now we can all boast about Koha's MARCXML export abilities :-) Cheers, -- Joshua Ferraro VENDOR SERVICES FOR OPEN-SOURCE SOFTWARE President, Technology migration, training, maintenance, support LibLime Featuring Koha Open-Source ILS jmf(a)liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS

1 0

(no subject)
by paul.poulain＠free.fr 22 May '06

22 May '06

Hello all, we all agree that prog templates are for programmers basically. On devWeek, we investigated the possibility to have /includes/ directory as a system preference. That still sounds a good idea to me, i'll investigate it a little bit more later. For now, I would like to suggest a minor css property for 2 cases : - a message has to be clearly identified on the screen (like "the member card expire in 15 days", or "this book is reserved" in a book list, or many informations that we want the patron not to miss. - a message to warn the librarian that a problem has occured and the operation was impossible or failed for any reason (like "this barcode is unknown" or "this barcode already affected" in item adding, or "this book is reserved & can't be reserved again", or "this member is suspended or gna" ...) If programmers don't put a specific tag here, template designers will miss them for sure ! That's why I suggest to have 2 new properties : - warning - problem They will be useable in any tag (<div class="warning"> or <p class="problem"> ... Waiting for your comments -- Paul

3 2