Time Nick Message 10:19 nicomo evening chris 10:15 chris evening nicomo 09:07 Amit hi paul_p 08:32 paul_p hi chris 08:31 chris hi paul 08:30 chris http://git.koha.org/cgi-bin/gitweb.cgi?p=Koha;a=commitdiff;h=fda56015444261bea7883d18973caca2e1f90a33 08:28 chris hdl_laptop: yep, updated them last night 08:27 SelfishMan Koha doesn't compare 08:26 kf g 08:26 hdl_laptop thx for comparing koha to tables and chisel 08:26 SelfishMan I'm pretty sure that using stone tablets and a chisel would be an *upgrade* from Sagebrush Athena 08:25 hdl_laptop have you updated translation notes ? 08:25 mason to prepare to celebrate the athena -> koha change-over 08:25 chris hdl_laptop: done 08:25 hdl_laptop new comer ?or new contract ? or end of contract ? 08:24 hdl_laptop why ? 08:24 hdl_laptop mason ? 08:23 SelfishMan Sweet. 4 more days until I go live with Koha and dump Athena 08:23 mason bonjour all 08:19 hdl_laptop chris: i am ok with that. 08:00 kf hi chris 07:57 chris ? 07:56 chris shall i commit them and push them up 07:56 chris Serhij Dubyk 07:56 chris from 07:55 chris hdl_laptop: i have some files for ukranian and russian, unimarc and other sql stuff (like the en and french ones) 07:54 chris hi hdl and kf 07:52 hdl_laptop hi 07:50 kf good morning 03:26 Amit hi gm mason 03:26 Amit hi good morning 19:35 owen Hey, no remote image option for adding an icon to an authorized value? Bummer. 18:32 gmcharlt works for me now - looks like glitch was temporary 18:32 atz the latter works fine for me 18:31 gmcharlt www.kohadocs.org works, but not http://kohadocs.org 18:31 atz dunno 18:22 nengard I'm getting a 503 error 18:21 nengard anyone know what's up with kohadocs.org? 16:35 atz owen: not sure... would have to connect w/ yaz-client to be sure 16:25 owen Now it's not... Has the syntax changed, or do we probably just not have that indexed now? 16:24 owen http://acpl.kohalibrary.com/cgi-bin/koha/opac-search.pl?q=ccl=onorder:-1 16:24 owen Before our upgrade to 3.0 this search worked to find titles which were designated as "on order" (NOT_LOAN = -1) 16:22 danny ok thank you both 16:20 paul_p ... continued in april (KohaCon) 16:19 paul_p danny: in 2 weeks there will be some meeting between BibLibre & LL, we will speak of our repsectives devs & hopefully some timelines 16:17 gmcharlt danny: later than April - I need to take stock, but early summer seems to more likely 16:17 liz the other tags seem to be working, pulling the proper info 16:16 liz instead of the information? 16:16 liz <<branches.branchphone>> 16:16 liz <<branches.branchaddress3>> 16:16 liz <<branches.branchaddress1>> 16:16 liz <<branches.branchname>> 16:16 liz silly question of the day, can anybody tell me why our notices would be displaying 16:13 danny gmcharlt: I believe the last email I saw a while ago said expected release for 3.2 was early april 09? is this still accurate or is there a better estimated date? 16:13 sedwards sorry, from *search results* page. 16:12 sedwards vestiges of pre-MARC stuff was very confusing, but now everything can be much cleaner, i think. 16:11 sedwards fyi, in reserves stuff, to allow multiple hold requests at once from search page. 16:10 sedwards without blowing anything up. 16:09 sedwards i'm trying to find my way around as i implement some HCL additions for next release. 16:09 sedwards can't say i blame you. 16:09 paul_p facebook... yikes... you will never meet me on facebook ! 16:08 sedwards unfortunately, no, but i joined the faceboook group at least. 16:08 paul_p nice to meet you (& if you'll be at KohaCon, we will met in real life ;-) ) 16:08 paul_p gotch too ;-) 16:08 sedwards Gotcha. 16:07 sedwards sorry, Steve Edwards, doing some work for Howard County Library. 16:07 paul_p (I realise I don't know who is sedwards) 16:07 sedwards repetition is good for me. :) 16:06 hdl_laptop sorry, re saying what paul_p already said. 16:06 owen Not "somewhat broke", "completely broke" :) 16:06 sedwards i see. 16:05 hdl_laptop since MARC biblios have everything in one record. 16:05 hdl_laptop But MARC support somewhat broke that "FRBRization". 16:04 hdl_laptop .... 16:04 hdl_laptop -Book edition2 16:04 hdl_laptop - Book edition1 16:04 hdl_laptop - Film 16:04 hdl_laptop Harry Potter 1 16:04 hdl_laptop so have one title, linked with more than 1 biblioitems : 16:03 hdl_laptop sedwards: In fact, in 1999, koha was meant to FRBRize biblio display 15:58 HARE9 well, good evening all 15:56 sedwards thanks for the background, it's quite helpful. 15:55 sedwards i see. 15:55 paul_p (moving from 2level MARC to 3 level FRBR is really complex) 15:55 gmcharlt sedwards: eventually, would like to support FRBR 15:55 paul_p although no ILS has it yet 15:54 sedwards that is on the radar for a future release? 15:54 paul_p yep 15:54 HARE9 new standard for notices? 15:54 paul_p www.ifla.org/VII/s13/frbr/frbr.htm 15:54 sedwards ok. 15:54 paul_p www.frbr.org 15:54 paul_p FRBR: Functional Requirements for Bibliographic Records. 15:53 sedwards FRBR? 15:53 paul_p (even if the FRBR reintroduces the 3 levels...) 15:53 sedwards and the redundant perl scripts. 15:53 paul_p the next step being probably to clean the DB ! 15:53 paul_p but since 3.x, MARC=OFF doesn't exist anymore, and you are stick with 2 levels only. 15:53 paul_p the MARC=OFF syspref was still working in 2.x, and you still can have 1/M/P 15:52 paul_p (my job) 15:52 paul_p when MARC feature were added, we had to move to a 2 level (biblio/items) only. 15:52 sedwards i see. 15:52 paul_p but this does not exist in MARC 15:52 sedwards ah. 15:52 paul_p in koha 1.x, one could have 1 biblio / N biblioitems / P items 15:52 sedwards but also explains why lots of perl code still assumes there are multiple biblioitemnumers per biblionum. 15:51 paul_p history mode=ON 15:51 sedwards but that's what i was wondering, whether they are the same thing. looks like that is true. 15:51 sedwards paul_p: no kidding. 15:51 paul_p ) 15:51 paul_p however, it's what I call "deep koha", so noone tried to remove them until now (as it would mean merge biblio & biblioitems tables into 1, and that's "very deep koha" ! 15:50 HARE9 w00t, my first positive karma :-D 15:50 paul_p HARE9: ++ biblioitemnumber should be removed. 15:49 HARE9 but i'm really unsure, i don't know the rfcs implemented in 3.2 very well 15:49 sedwards that's what i'm trying to determine. 15:49 HARE9 so biblioitemnumber is a redundant column imho 15:47 sedwards i'm not living in the future. :) 15:47 sedwards sorry, yes. 15:47 paul_p sedwards: 3.2 ? you mean "git master" isn't it ? as 3.2 don't exist 15:47 sedwards i've seen some list messages that imply this, but it's not spelled out anywhere (that i can tell). makes me nervous. 15:47 HARE9 :-D 15:47 sedwards sorry. |p 15:47 HARE9 ok, sorry, i'm still at 3.0. 15:46 HARE9 ah 15:46 sedwards didn't mention, i'm looking at 3.2 15:46 HARE9 biblioitems has three fields, biblionumber, biblioitemnumber and volume 15:46 HARE9 hmmm, my db is different 15:45 sedwards in the sample DBs i have seen, biblionumber always equals biblioitemnumber. 15:45 sedwards hmm. the 'items' table has an 'itemnumber', 'biblionumber', and 'biblioitemnumber'. 15:44 HARE9 at leas thtat's how i understand it 15:44 HARE9 so if you have more than one items of a biblio, the biblioitemnumber will differ 15:44 HARE9 sedwards, i don't think so, biblioitemnumber is the item's number. the biblionumber in the biblioitems db is the biblionumber 15:39 kf have to go home now - bye #koha 15:39 sedwards also, is there a schema being maintained anywhere? the links to koha-fr.org in the wiki don't seem to work anymore. 15:36 sedwards i.e., biblio table is 1:1 with biblioitems table? 15:36 sedwards could someone please verify: biblionumber == biblioitemnumber, always? 15:30 hdl_laptop thx 15:29 kf we will try to change Output.pm - i will tell you about the results then 15:12 kf normalization for search would be next then 15:11 kf perhaps we can try on the fly - i can test and i asked my colleague if he can change Output.pm, but have no answer yet 15:10 kf hm 15:10 kf you have to check for normalization before every input and create statement - at first i only thought about z39.50, but to do it right its more complicated 15:08 gmcharlt doing it on the fly, assuming that isn't too slow, would save us a lot of trouble 15:07 gmcharlt meaning that a lot of code would have to be checked to enforce NFC in the database 15:07 gmcharlt and afaik mysql doesn't do anything to enforce a particular NF 15:06 gmcharlt the problem with that is that a lot of Koha databases have mixed Unicode normalization forms 15:05 kf we have a script for normalizing to NFC before batch-import 15:04 kf but i think one place wont be enough to secure normalized data in the database 15:03 kf im also concerned about performance 15:03 kf i would really prefer that 15:03 hdl_laptop but have rather normalized data in database. 15:03 hdl_laptop kf : as far as I am concerned, i wouldnot go editing Output only, 15:02 gmcharlt back 14:38 gmcharlt brb 14:34 kf i have no perl programmers here, but perhaps I can try and change Output.pm 14:33 kf hm 14:32 gmcharlt cool 14:24 hdl_laptop It looks quite good now. 14:24 hdl_laptop gmcharlt: we have made some work on icu configuration for zebra. 14:24 gmcharlt probably 14:23 kf icu? 14:22 gmcharlt I'd have to play around with it 14:22 gmcharlt search will need extra work, but not all that much - in fact, changing the Zebra config may be sufficient 14:20 kf or just display - which is not a solution for searching, that needs extra work, exspecially when different forms are to be expected in one database 14:19 kf do you think there will be normalization for import in the future? 14:19 kf thx galen 14:19 gmcharlt output_html_with_http_headers() in C4/Output.pm 14:18 kf ok, one place? where? 14:16 gmcharlt and testing to ensure that doing this doesn't impact performance too much 14:15 gmcharlt kf: not hard - it's just a matter of using a function from the Unicode::Normalize module in one place 14:11 kf galen - how difficult is it to use normalization for display and where to do that? im not a programmer 14:02 kf arial unicode ms is ok too 14:01 kf ok - i think this font displays right 14:01 gmcharlt using the Mac's Times font 14:00 kf display in IE is always correct 13:59 kf which font is configured in your browser? standard is times new roman 13:59 kf the .. in displays in your browser correctly? 13:58 kf windows xp, firefox 3.0.5 13:58 kf yes 13:58 gmcharlt on Windows? 13:57 kf firefox 13:56 gmcharlt what browser are you using 13:56 gmcharlt actually, all forms look OK to me (FireFox 3 on OS X 10.5) 13:54 kf display seems to be correct with NFC, NFKC and FCD? http://demo.icu-project.org/icu-bin/nbrowser?t=m%C3%BCller&s=&uv=0 13:47 kf i cant present an opac, which cant display german umlauts :( 13:46 kf galen: you said it could be done for display - perhaps its really a start 13:43 owen Yeah, that seems to have fixed it. Thanks gmcharlt 13:42 gmcharlt yes 13:41 owen So a hidden input name="koha_login_context" value="opac" ? 13:41 gmcharlt with value 'opac' 13:40 gmcharlt you probably need to add a koha_login_context parameter to your form submission 13:39 owen This was working before our Koha 3 upgrade 13:39 owen Meaning, the login form is on our library's home page and submits to the OPAC 13:39 owen Does anyone know if something changed in the OPAC which would prevent my users from logging in from another site? 13:38 gmcharlt hi owen 13:38 owen Hi kf and #koha 13:38 kf hi owen 13:35 gmcharlt hi hdl_laptop 13:35 hdl_laptop hi gmcharlt 13:35 kf for display and search NFC is propably the right choice 13:34 kf i think there are three problems: display, search and mix of both forms in the database 13:32 kf ah sorry, im repeating myself 13:29 kf koha is web-based, i think w3c recommendation is also nfc? 13:27 gmcharlt most web browsers work better with NFC 13:27 hdl_laptop http://fr.wikipedia.org/wiki/Normalisation_Unicode#NFC 13:27 kf but seems that w3c recommends nfc? just started reading about normalization today 13:27 hdl_laptop mmm... nfkd is here for compatibility 13:26 kf means the way it is now 13:25 gmcharlt normalization form canonical decomposed - opposite of NFC, basically 13:25 kf nfkd means... i have to look it up 13:23 kf so import via z39.50 and batch import is problematic 13:23 gmcharlt complicating matters, NFKD is technically preferred for UTF-8 encoded MARC21 13:23 kf keyboard input seems to be normalized 13:23 kf hello paul 13:23 paul_p hello world 13:22 gmcharlt that would be ideal, but difficult to achieve 13:22 kf i think it would be best to have only the normalized form in the database - so the data is consistent 13:21 hdl_laptop kf would not tough too. 13:20 kf what about adding it to z39.50 conversion? 13:20 gmcharlt possible also when sending records to Zebra to be indexed, in case it makes any difference 13:20 gmcharlt as a start 13:19 kf output normalization - just for display? 13:19 kf hi galen 13:16 gmcharlt kf: won't be hard to add NFC for output normalization 12:37 kf back 12:00 kf sorry, will be back in 30 minutes 11:59 kf hdl: you mean 3.0 or 3.2 ? 11:58 kf hi amit 11:56 hdl_laptop But When ? 11:55 hdl_laptop kf: I think we can make it. 11:54 Amit hi hdl 11:54 hdl_laptop hi Amit 11:54 Amit hi kf 11:32 kf I think we dont know koha well enough to add this feature, but perhaps liblime or biblibre can do 11:29 kf seems, that this could be solve your problem too 11:28 kf we would really like that - 3.2 or 3.0 11:28 hdl_laptop kf yes, and galen is RM for 3.2. This normalization could get into 3.0 but would add some new dependancies. 11:20 kf it seems there is a perl package to do normalization: http://www.mail-archive.com/perl4lib@perl.org/msg01337.html 11:20 kf ah, thx hdl 11:20 hdl_laptop kf: it is all é à ....