| 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: 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 |
|
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 |
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 |
|
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? 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 |
|
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/Output.pm |
| 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 Output.pm |
| 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 Output.pm, but have no answer yet |
| 15:12 |
|
kf |
normalization for search would be next then |
| 15:29 |
|
kf |
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 |
|
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 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 |
|
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 |
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 |
|
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 |
http://acpl.kohalibrary.com/cg[…]?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 kohadocs.org? |
| 18:22 |
|
nengard |
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 |
|
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 |
http://git.koha.org/cgi-bin/gi[…]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 |
