← Previous day | Today | Next day → | Search | Index
All times shown according to UTC.
| Time | Nick | Message |
|---|---|---|
| 11:20 | hdl_laptop | kf: it is all é à .... |
| 11:20 | kf | ah, thx hdl |
| 11:20 | it seems there is a perl package to do normalization: http://www.mail-archive.com/pe[…]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 | seems, that this could be solve your problem too | |
| 11:32 | 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 | But When ? | |
| 11:58 | kf | hi amit |
| 11:59 | hdl: you mean 3.0 or 3.2 ? | |
| 12:00 | sorry, will be back in 30 minutes | |
| 12:37 | back | |
| 13:16 | gmcharlt | kf: won't be hard to add NFC for output normalization |
| 13:19 | kf | hi galen |
| 13:19 | output normalization - just for display? | |
| 13:20 | gmcharlt | as a start |
| 13:20 | 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 | 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 | 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 | http://fr.wikipedia.org/wiki/N[…]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 | ah sorry, im repeating myself | |
| 13:34 | i think there are three problems: display, search and mix of both forms in the database | |
| 13:35 | 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 | Meaning, the login form is on our library's home page and submits to the OPAC | |
| 13:39 | 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 | 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 | i cant present an opac, which cant display german umlauts :( | |
| 13:54 | display seems to be correct with NFC, NFKC and FCD? http://demo.icu-project.org/ic[…]C3%BCller&s=&uv=0 | |
| 13:56 | gmcharlt | actually, all forms look OK to me (FireFox 3 on OS X 10.5) |
| 13:56 | what browser are you using | |
| 13:57 | kf | firefox |
| 13:58 | gmcharlt | on Windows? |
| 13:58 | kf | yes |
| 13:58 | windows xp, firefox 3.0.5 | |
| 13:59 | the .. in displays in your browser correctly? | |
| 13:59 | which font is configured in your browser? standard is times new roman | |
| 14:00 | 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 | arial unicode ms is ok too | |
| 14:11 | 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 | 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/Output.pm |
| 14:19 | kf | thx galen |
| 14:19 | do you think there will be normalization for import in the future? | |
| 14:20 | 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 | 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 | It looks quite good now. | |
| 14:32 | gmcharlt | cool |
| 14:33 | kf | hm |
| 14:34 | i have no perl programmers here, but perhaps I can try and change Output.pm | |
| 14:38 | gmcharlt | brb |
| 15:02 | back | |
| 15:03 | hdl_laptop | kf : as far as I am concerned, i wouldnot go editing Output only, |
| 15:03 | but have rather normalized data in database. | |
| 15:03 | kf | i would really prefer that |
| 15:03 | im also concerned about performance | |
| 15:04 | but i think one place wont be enough to secure normalized data in the database | |
| 15:05 | 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 | and afaik mysql doesn't do anything to enforce a particular NF | |
| 15:07 | meaning that a lot of code would have to be checked to enforce NFC in the database | |
| 15:08 | 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 | hm | |
| 15:11 | 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:12 | normalization for search would be next then | |
| 15:29 | we will try to change Output.pm - 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 | i.e., biblio table is 1:1 with biblioitems table? | |
| 15:39 | also, is there a schema being maintained anywhere? the links to koha-fr.org 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 | so if you have more than one items of a biblio, the biblioitemnumber will differ | |
| 15:44 | at leas thtat's how i understand it | |
| 15:45 | sedwards | hmm. the 'items' table has an 'itemnumber', 'biblionumber', and 'biblioitemnumber'. |
| 15:45 | in the sample DBs i have seen, biblionumber always equals biblioitemnumber. | |
| 15:46 | HARE9 | hmmm, my db is different |
| 15:46 | 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 | 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 | 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 | ) | |
| 15:51 | sedwards | paul_p: no kidding. |
| 15:51 | 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 | (my job) | |
| 15:53 | the MARC=OFF syspref was still working in 2.x, and you still can have 1/M/P | |
| 15:53 | but since 3.x, MARC=OFF doesn't exist anymore, and you are stick with 2 levels only. | |
| 15:53 | 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 | www.frbr.org | |
| 15:54 | sedwards | ok. |
| 15:54 | paul_p | www.ifla.org/VII/s13/frbr/frbr.htm |
| 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 | 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 | so have one title, linked with more than 1 biblioitems : | |
| 16:04 | Harry Potter 1 | |
| 16:04 | - Film | |
| 16:04 | - Book edition1 | |
| 16:04 | -Book edition2 | |
| 16:04 | .... | |
| 16:05 | But MARC support somewhat broke that "FRBRization". | |
| 16:05 | 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 | Gotcha. | |
| 16:08 | paul_p | gotch too ;-) |
| 16:08 | 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 | i'm trying to find my way around as i implement some HCL additions for next release. | |
| 16:10 | without blowing anything up. | |
| 16:11 | fyi, in reserves stuff, to allow multiple hold requests at once from search page. | |
| 16:12 | vestiges of pre-MARC stuff was very confusing, but now everything can be much cleaner, i think. | |
| 16:13 | 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 | <<branches.branchname>> | |
| 16:16 | <<branches.branchaddress1>> | |
| 16:16 | <<branches.branchaddress3>> | |
| 16:16 | <<branches.branchphone>> | |
| 16:16 | instead of the information? | |
| 16:17 | 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 | ... 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 | http://acpl.kohalibrary.com/cg[…]?q=ccl=onorder:-1 | |
| 16:25 | 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 kohadocs.org? |
| 18:22 | I'm getting a 503 error | |
| 18:31 | atz | dunno |
| 18:31 | gmcharlt | www.kohadocs.org works, but not http://kohadocs.org |
| 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 | hi gm mason | |
| 07:50 | kf | good morning |
| 07:52 | hdl_laptop | hi |
| 07:54 | chris | hi hdl and kf |
| 07:55 | hdl_laptop: i have some files for ukranian and russian, unimarc and other sql stuff (like the en and french ones) | |
| 07:56 | from | |
| 07:56 | Serhij Dubyk | |
| 07:56 | shall i commit them and push them up | |
| 07:57 | ? | |
| 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 | why ? | |
| 08:25 | 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 | http://git.koha.org/cgi-bin/gi[…]8973caca2e1f90a33 | |
| 08:31 | hi paul | |
| 08:32 | paul_p | hi chris |
| 09:07 | Amit | hi paul_p |
| 10:15 | chris | evening nicomo |
| 10:19 | nicomo | evening chris |
← Previous day | Today | Next day → | Search | Index