← Previous day | Today | Next day → | Search | Index
All times shown according to UTC.
| Time | 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 | just wondering why | |
| 12:08 | nahuel | hmmm when ? |
| 12:08 | gmcharlt | about 3 hours ago |
| 12:08 | nahuel | ahaha :) |
| 12:08 | 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 | 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 | 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 | that in particular looks like it may have been using 3 combining characters to represent 1 unicode character | |
| 18:06 | it makes sense that you would see it in MARC21 since it lacks the encoding brains of UNIMARC | |
| 18:18 | most of the time i see that in z3950-imported records | |
| 18:19 | and there is some question about whether the remote system has their representation correct or not | |
| 18:19 | 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 | This mess is concentrated on 952 classification subfields. All other fields are properly UTF8 encoded. | |
| 18:22 | 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 | 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 | 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 | where can i do that? and how? | |
| 18:33 | 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 | 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 | we have a new listing on the koha users page | |
| 18:39 | for a library in jerusalem | |
| 18:40 | 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 | cool ill do that then | |
| 18:46 | 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 | 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 | take something like: $hash = ( foo =>1, bar=>2, tre=> {foo=>100; bar=>200}}; | |
| 18:53 | er, missing a ), but you get the idea | |
| 18:56 | 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 | 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 | 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 | 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 | 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 | 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 | 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 |
← Previous day | Today | Next day → | Search | Index