| Time |
S |
Nick |
Message |
| 12:06 |
|
gmcharlt |
nahuel: about? |
| 12:06 |
|
nahuel |
gmcharlt, yes ? |
| 12:07 |
|
gmcharlt |
nahuel: noticed that you had emailed a few applied patches (2868, 2799) back to me |
| 12:07 |
|
gmcharlt |
just wondering why |
| 12:08 |
|
nahuel |
hmmm when ? |
| 12:08 |
|
gmcharlt |
about 3 hours ago |
| 12:08 |
|
nahuel |
ahaha :) |
| 12:08 |
|
nahuel |
git-send-mail sends the patch to the commiter too... |
| 12:09 |
|
gmcharlt |
ah, OK |
| 12:09 |
|
nahuel |
I just made a git-format-patch too long, and sent all patches |
| 12:09 |
|
nahuel |
a little mistake, sorry |
| 12:09 |
|
gmcharlt |
no problem - just want to make sure you hadn't found something wrong in those patches that you wanted me to fix |
| 12:09 |
|
nahuel |
no no :) |
| 17:16 |
|
frederic |
Does anybody get a bug which corrupts MARC21 952 items classification subfields ($6 en $o)? |
| 17:18 |
|
frederic |
Both subfields are fulfilled with those kind of string: Ã<U+0083>Â<U+0083>Ã<U+0082>Â |
| 17:48 |
|
gmcharlt |
frederic: haven't see that one |
| 18:05 |
|
atz |
frederic: sounds like a unicode handling issue |
| 18:05 |
|
atz |
that in particular looks like it may have been using 3 combining characters to represent 1 unicode character |
| 18:06 |
|
atz |
it makes sense that you would see it in MARC21 since it lacks the encoding brains of UNIMARC |
| 18:18 |
|
atz |
most of the time i see that in z3950-imported records |
| 18:19 |
|
atz |
and there is some question about whether the remote system has their representation correct or not |
| 18:19 |
|
atz |
i see it less often with Koha-original catalogued items |
| 18:21 |
|
frederic |
atz: thanks. Not sure MARC21 brain is inferior than the UNIMARC one but... |
| 18:21 |
|
frederic |
This mess is concentrated on 952 classification subfields. All other fields are properly UTF8 encoded. |
| 18:22 |
|
frederic |
Is it possible that during import something get wrong because classification contains extended characters? é for example. I'm sure it has worked... |
| 18:22 |
|
atz |
interesting... so the local info was entered at a different time than the original biblio info |
| 18:24 |
|
frederic |
I have in phone a librarian in tears who don't believe in Christmas anymore... |
| 18:27 |
|
cait |
atz: is the right form for diacritics in koha one single unicode-character? we had a problem with german umlauts and i wondered whis is the right form |
| 18:30 |
|
ryan |
cait: the trend in the unicode world is to move to standardise on combining characters rather than using the composed (single-character) form. |
| 18:30 |
|
ryan |
I'm not sure which is more likely to cause problems in koha though. |
| 18:31 |
|
cait |
with german umlauts combined character breaks the search in opac |
| 18:31 |
|
cait |
you simply cant search for them, so we changed it to ü instead of u + .. |
| 18:33 |
|
gmcharlt |
cait: you're using Zebra, right? if so, it can be configured to ignore combining vs. noncombing character distinctions |
| 18:33 |
|
cait |
and the display is slightly wrong, the points are a litte bit out of alignment |
| 18:33 |
|
cait |
where can i do that? and how? |
| 18:33 |
|
cait |
and yes, we like the zebra :) |
| 18:34 |
|
gmcharlt |
cait: I'll work up an example for you in a day or two |
| 18:34 |
|
cait |
that would be great |
| 18:35 |
|
cait |
there is also a problem in acquisition - when an order is placed with a "fast add" and there is an umlaut in it, it breaks acquisition, but i think there is a bug report somewhere |
| 18:37 |
|
chris |
morning |
| 18:38 |
|
gmcharlt |
hi chris |
| 18:39 |
|
chris |
i have a question |
| 18:39 |
|
chris |
we have a new listing on the koha users page |
| 18:39 |
|
chris |
for a library in jerusalem |
| 18:40 |
|
chris |
its in the asia section at the moment, which isnt quite right :) do you reckon i should make a middle east section? |
| 18:40 |
|
gmcharlt |
chris: I'd say so - I think there are a couple other Koha users in the Middle East |
| 18:41 |
|
atz |
chris: yes, there are also known users in Saudi Arabia, and Iran |
| 18:41 |
|
chris |
yes, if we put the section there, maybe they will list in it :) |
| 18:41 |
|
chris |
cool ill do that then |
| 18:46 |
|
chris |
done |
| 18:48 |
|
gmcharlt |
cool |
| 18:49 |
|
atz |
gmcharlt: i'm surprised, but it seems this hasn't been done yet in Koha: write a hash-to-TMPL_LOOP converter. |
| 18:49 |
|
atz |
true? |
| 18:49 |
|
gmcharlt |
atz: not sure what you mean by that |
| 18:50 |
|
atz |
TMPL_LOOP is a reference to an array of hashrefs |
| 18:52 |
|
atz |
take something like: $hash = ( foo =>1, bar=>2, tre=> {foo=>100; bar=>200}}; |
| 18:53 |
|
atz |
er, missing a ), but you get the idea |
| 18:56 |
|
atz |
you'd want: $loop = [( {foo=>1, bar=>2, tre=>[({foo=>100, bar=>200})] } )]; |
| 19:07 |
|
chris |
http://xkcd.com/519/ for anyone who hasnt seen it yet :) |
| 21:10 |
|
acmoore |
areinmeyer: you ought to watch http://www.shadowcat.co.uk/arc[…]dbic-masterclass/ for some interesting stuff about how to artfully use DBIx::Class. |
| 21:11 |
|
areinmeyer |
acmoore: thanks I'll check that out |
| 21:11 |
|
areinmeyer |
been making good progress today on Members |
| 21:13 |
|
acmoore |
great. I haven't worked much on ImportBatch. I spent most of the morning putting together a patch that I sent over to the DBIx::Class guys. It makes Schema::Loader work a bit better. |
| 21:13 |
|
atz |
cool |
| 21:14 |
|
areinmeyer |
I was playing around with the DBIx::Class:ResultClass::HashRefInflator |
| 21:15 |
|
ryan |
HashRefInflator goes nicely with TMPL_LOOPs |
| 21:15 |
|
acmoore |
yes, it does. I thought I was probably going to ahve to write something to make that easier, but it looks like we can just use that. |
| 21:15 |
|
areinmeyer |
http://search.cpan.org/~ribasu[…]ashRefInflator.pm |
| 21:17 |
|
areinmeyer |
I started writing something as well, then figured someone smarter prb already did it |
| 21:55 |
|
acmoore |
gmcharlt: In my process of changing C4::ImportBatch to use DBIx::Class instead of direct SQL commands, I'm generating a lot of test cases for C4::ImportBatch. They're valid even if we never switch to DBIx::Class. They just test current functionality. If I package them up and submit them, you'll likely accept them, won't you? |
| 21:56 |
|
gmcharlt |
acmoore: sure |
| 21:56 |
|
acmoore |
OK, good. That might cut down on the patchbomb that we're going to have with DBIx::Class. thanks. |
| 21:56 |
|
acmoore |
areinmeyer: that may mean that you can submit C4::Members tests as you get them done, too. |
| 21:58 |
|
areinmeyer |
super. I had thought the same thing that they should be valid regardless |
| 22:03 |
|
gmcharlt |
acmoore++ # DBIx::Class::Schema::Loader |
| 22:06 |
|
acmoore |
thanks. those guys seemed pretty happy about it, too. |
| 22:06 |
|
acmoore |
I asked them if it were possible to have that functionality, and they said "sure, patch it". I asked for svn access and their reaction was "holy cow, the last 12 people just disappeared when we said that". |
| 22:07 |
|
acmoore |
so, now I have commit access to the DBIC repository. |
| 22:08 |
|
gmcharlt |
explains why you sent a svn link :) |
| 22:14 |
|
acmoore |
OK. I sent some test scripts for C4::ImportBatch. I have some for C4::ClassSource I can send after I split them apart from actual code changes. I guess I'll do that next Friday. |
| 22:17 |
|
ryan |
acmoore: DBIx::Class::Schema::Loader <-- what's that ? |
| 22:29 |
|
gmcharlt |
ryan: reads schema from DB and generates classes |
| 22:48 |
|
liz |
would it be welcome from the koha community if a paying customer paid to have a feature (such as the SIP functionality) both enhanced and then fully documented? |
| 22:48 |
|
liz |
i mean, does anybody do that? |
| 22:49 |
|
gmcharlt |
liz: sounds like a good idea - documentation is as worthy of support as is the code |
| 08:26 |
|
chris |
http://opac.koha.workbuffer.org/ now thats a lot of languages |
