IRC log for #koha, 2009-02-11

All times shown according to UTC.

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

| Channels | #koha index | Today | | Search | Google Search | Plain-Text | plain, newest first | summary