Time Nick Message 10:50 kf my colleague just sent me that link, seems NFC-normalization would be the right solution then: http://www.mail-archive.com/koha-devel@nongnu.org/msg00636.html 09:59 kf i just dont like the idea to have both versions in one database 09:58 kf is it only é or all? â 09:57 hdl_laptop But if you are getting biblios from SUDOC with utf-8 encoding, you will see that é is combined diacritics and not \xe9 09:56 hdl_laptop kf: we are facing same problem with é. 09:43 kf hdl: normalize to e? 08:38 kf i have a little proplem here atm, be back later 08:38 kf i saw in french catalogs only single character encoding - but thoght it must be the same problem with é 08:36 kf i asked you about that some time ago :) 08:35 kf i think i know how to do that 08:35 kf thx hdl 08:32 hdl_laptop kf: I can help you building up equivalence in zebra for thos chars. 08:23 hdl_laptop But display is then quite hard to fix. 08:19 hdl_laptop And normalize accents in order not to have problems with diacritics indexing. 08:19 hdl_laptop Solution we are considering is using yaz-icu 08:18 hdl_laptop Since é can be encoded two ways 08:18 hdl_laptop We also have the problem here with some french diacritics. 08:17 hdl_laptop This can explain the way taht MARC-8 to utf-8 chose to deal with encoding. 08:16 hdl_laptop kf : it seems that the international norm is tending to have combined diacritics signs and not one character for that. 08:14 kf i have to think about it, but i dont think its a good thing to use U+Umlaut, when its displayed wrong and cant be typed in by the user 08:13 kf or only french z39.50 with iso encoding 08:13 hdl_laptop chris: thanks 08:13 kf we would not have this problem i i could use UNIMARC 08:12 mc kf, the better afaik :( 08:12 kf its not a good solution i think 08:12 chris hdl_laptop: good morning, i pushed up the updated release notes 08:12 kf and zebra has to be configured, to do an equivalence search for all those characters 08:11 mc kf, my two cents: you can't expect to avoid that if you don't check the data sent by user on fly 08:11 hdl_laptop Elwell: it is me 08:10 mc (i have to test it) 08:10 mc i don't know about mac 08:10 mc kf, i use monospace under linux 08:10 kf but you will still have mixed unicode encoding in your database then 08:09 kf then you can display it right 08:09 mc i fixed some weird displays just switching to a better utf8 font 08:09 kf yes, but you cant force arial unicode ms i think, is it even avaliable on every system? 08:08 mc kf, isn't it just a font pb in firefox ? 08:08 paul_p kf : I confirm you ü can be represented differently in unicode (ü and U+UMLAUT) 08:08 kf dont can show that to a library user 08:08 mc outch 08:07 kf its not over the letter, but left of it 08:07 kf and its annoying, because its displayed wrong in firefox 08:07 mc kf, sure! that's utf8 :) 08:07 kf LOC is an example, they use diacritic version 08:07 mc ok: where the data came from ? 08:07 kf it seems there are two different ways to encode umlauts (as an example) you can use base character + diacritic or you can simple use the character ü 08:06 kf i think i dontk now how to explain it 08:05 mc (that's the point i missed, i think) 08:05 mc but is it a charset ? 08:05 mc i seen MARC8 08:05 mc you want to translate from utf8 to wich charset? 08:04 kf its no problem for translation, because when using the keyboard you always get it right 08:04 Elwell my plan is to learn it and do amlib.ch as a volunteer project 08:04 mc kf: so ... 08:03 paul_p Elwell: yep. WIPO asked me a RFP 3 years ago, but it was not unimarc, not french & I was too busy. So I suggested asking LL 08:03 kf mc: sure, im here 08:03 chris yep WIPO do .. and UNIDO in vienna 08:02 mc kf thx for it: i'll try when i will feel ready 08:02 chris someone might have run into something like this before 08:02 Elwell I notice the WIPO use it too but looks like its supported by liblime 08:02 paul_p (and hopefully another one in Neuchatel in the coming weeks...) 08:02 chris kf: maybe ask on the koha-translate list? 08:02 kf you can use me for training :) 08:02 paul_p we have some (few) customers in Switzerland (in Lausanne) 08:02 mc my german isn't fluent enought for this kind of chat ... but i work on it! 08:01 paul_p kf: I asked Elwell ;-) (I already knew you're german. And i'm happy to see new europeans being interested by Koha !) 08:01 Elwell paul_p: nope - still learning it 08:01 kf sorry, no :( 08:01 mc Elwell, we're almost neighbor 08:00 paul_p do you speak french ? (if yes, we have a french speaking channel, much more silent than this one though) 08:00 kf constance 08:00 Elwell paul_p: just over the swiss side of the Jura (work near geneva) 08:00 kf yes im from germany 08:00 mc kf: german ? 07:59 kf mc, im glad if someone tries to understand and help, i think its difficult for me to explain in english 07:59 kf and its confusing to have different versions of utf8-encoding for the same german letter 07:59 mc kf, sorry ... i stop to bug you is it seems i don't understand the pb 07:58 kf i think marc::charset works correct - but its still not what i need 07:58 paul_p (/me in Marseille, south of france) 07:58 mc Elwell, experienced some pb with my ubuntu as desktop. i'm not happy enought to use it for customers 07:58 paul_p Elwell: hi. Where are you located exactly ? 07:57 Elwell bonjour paul from just across the border 07:57 mc paul_p, hello 07:56 mc i'm not aware about char pbs but is marc::charset using iconv or something like that ? ? 07:56 paul_p good morning from france ! 07:56 paul_p hello everybody 07:55 kf is there a way to get records in marc8 to utf8 with german umlauts as single character? 07:54 mc Elwell, i left etch for a while as many of the koha dependancies are in lenny so koha installation is very clean 07:54 Elwell mc: cool - deb testing proved pretty damn reliable last time I used it (fraid I jumped ship to the ubuntu side for desktops) 07:53 mc even in production 07:53 kf its all there in single byte, just look at the french catalogs :( 07:52 mc Elwell, i use it for a while now 07:52 kf i think the symbols are not the problem 07:52 chris yep 07:52 Elwell OK - seeing as Debian Lenny is coming out 'soon' (bearing in mind debians normal speed...) -- has anyone done an install on it? 07:51 mc utf8 > latin1, something like that ... but what if you don't have the same symbol? 07:51 kf the problem is, i can have 2byte, it looks slightly wrong and can be searched, but if something is changed manually, it will get singly byte 07:50 mc thx chris 07:50 kf ah chris, i think you understand me :) 07:50 mc ohh 07:50 mc kf, it seems to me that you want to convert 07:50 chris mc: 2byte encoding to single byte encoding 07:49 kf do you mean alphabetical sorting? 07:49 kf sorry mc? 07:49 kf i dont know if i can really explain that in english 07:49 kf but if you look for french records at LOC, its always two character 07:49 mc or other thing ? 07:49 mc ö > o ? 07:48 kf and there its always single character version, because of unimarc and iso5... 07:48 mc want to convert umlauts symbols to what ? 07:48 kf - i cant speak french 07:48 kf i looked at french catalogs yesterday - there are many accents and things like â 07:48 mc hmm 07:48 kf i think the problem is too big 07:48 kf i dont know how to change that, we already converted data for batch import 07:48 chris then we could write some regex's in perl to convert them 07:47 kf its about the z39.50 download in koha 07:47 kf umlauts are ä ö and ü 07:47 chris code=could 07:47 kf its also about accents 07:47 chris if you code convert the marc records to xml 07:47 kf i dont want a catalog, where german umlauts dont look the way they should 07:47 chris how many letters can have an umlaut on them in german? 07:46 kf so its not really a bug, but annoying :( 07:45 kf i think the two character version is already in marc8 07:45 chris ahh 07:44 kf its about the way umlauts are encoded, i want a single character version, but with marc8 i always get a 2 character version that is not searchable and displayed wrong 07:43 chris http://search.cpan.org/~esummers/MARC-Charset-1.0/lib/MARC/Charset.pm 07:43 chris have you been using MARC::Charset? 07:42 kf i still have no solution, but i got some correct umlauts from a french z39.50-server now 07:42 kf i was near yesterday 07:42 kf lol 07:42 SelfishMan A few more minutes of fighting with it and I would have been a broken person hiding in the corner in tears 07:41 kf im too nice for other terms ;) 07:41 kf but our union catalog is MARC8 + MARC21 of course... 07:41 SelfishMan "problematic" is an interesting term to describe that 07:40 kf but at least i know that know - iso5... -> UTF8 works fine 07:40 chris yes MARC8 was a very stupid idea 07:40 kf MARC8 -> UTF8 encoding is problematic 07:39 chris hi mc 07:39 mc hello world 07:38 mc wow ... storm begun! 07:36 chris it will be someone at biblibre 07:34 Elwell hmm. who's the listadmin? http://lists.koha.org/ vs http://lists.koha.org/mailman/listinfo 07:33 chris never fun 07:31 kf im still working at my encoding problems 07:31 kf :) 07:20 chris evening kf :) 07:20 kf good morning #koha 03:42 Amit r u from khalsa? 03:39 Khalsa Hi 03:39 Amit hi khalsa 03:39 Amit 9.09 A.M IST 03:39 Amit i m from india 03:35 Khalsa Amit: what time zone are you in? 03:34 mason morning amit 03:23 Amit good morning mason, chris 03:23 Amit hi good morning 22:04 Elwell ok - got as far as mailman@koha.org - I'm off to bed. 21:59 gmcharlt you can send as an attachment if need be (would prefer to not munge any whitespace diffs) 21:58 chris nope you can send it from gmail 21:58 Elwell can I send the patch from gmail or does it break your handling? 21:58 Elwell yeah - got that (eventually once I worked out syntax -- first time with git) 21:57 chris did that not make a patch for you? 21:57 chris git format-patch origin 21:57 chris git format-patch 21:56 Elwell ** patches@koha.org R=nonlocal: Mailing to remote domains not supported 21:56 Elwell blame gmail :-) 21:55 Elwell ok - I'm not convinced anything got sent (maillog looks empty), but I managed to extract the patch into a file and run git send-email 21:38 Elwell bugger - can't see my diff as I did a git commit 21:35 chris comes as a separate package in debian 21:34 chris apt-get install git-email 21:34 Elwell ah. old. very. 1.4.4.4 21:34 gmcharlt what's your git --version 21:33 Elwell git: 'send-email' is not a git-command 21:33 Elwell meh 21:32 chris they go to the same place :) 21:32 chris or that 21:32 chris and send it to patches@lists.koha.org 21:32 gmcharlt to patches@koha.org 21:32 chris then git send-email 21:32 chris you will want to git format-patch 21:31 Elwell should have the changes 21:31 Elwell chris: OK. if I've battled correctly against git, commit d68e4340c41b7e59ad2cad6aef078dd381a341e4 21:15 Elwell /usr/share/perl5/POE.pm 21:15 Elwell /usr/local/share/perl/5.8.8/POE.pm 21:15 Elwell koha:/home/build# locate POE.pm 21:15 Elwell ok - libpoe-perl --etch packaged version is at 0.3502, CPAN 1.003. Both get installed. 20:51 Elwell ok - I'll double check what else is packaged with lib*-perl first 20:50 chris that would be great 20:50 chris yep 20:48 Elwell should I do a diff and add it to the debian.packages rather than the cpan line and submit? 20:47 Elwell http://packages.debian.org/etch/libhtml-scrubber-perl 20:45 chris that'll be fine 20:45 Elwell 0.08-3 20:44 Elwell 2 ticks (waiting for git) 20:44 chris if its greater that 0.08 then it will be fine 20:43 chris what version is in debian? 20:39 Elwell hmm, see the changelog for INSTALL.debian -- wants to install HTML::Scrubber from cpan and not from libhtml-scrubber-perl ?? 20:10 chris you could even check things like if you try to change a framework that has less marc tags defined, what information will be 'lost' etc 20:09 gmcharlt biblIo_framework.pl should be patched to do that as part of its delete_confirm check 20:09 gmcharlt no except for running the query select frameworkcode, count(*) from biblio group by frameworkcode; 20:08 liz omg, gmcharlt that is so good to know 20:08 owen But there's not any way from within Koha to tell what frameworks are in use. 20:08 gmcharlt assuming you haven't changed the Koha field to MARC mapping 20:07 gmcharlt assigning bibs in question to the default framework should be reasonably safe, at least in MARC21 20:06 gmcharlt and possibly worse 20:06 gmcharlt likely bib display oddities 20:05 owen Would anything negative result from deleting a framework which was "in use" by existing records? 20:04 owen :) 20:04 gmcharlt not saying that the current behavior is *useful*, mind you 20:04 gmcharlt owen: it's counting number of MARC tags you have defined in framework, not number of bibs using that framework 19:55 chris i find that hard to believe 19:50 owen Every time I try to delete an extra framework Koha says it's being used 312 times...Each of them is being used exactly 312 times? 18:34 Khalsa nvm 18:34 Khalsa oh ncm 18:33 Khalsa the ones that are really old? 18:33 Elwell hmm. kohadocs for 3.0 -- pdf's screwy for all? 17:35 hdl_laptop owen : this warning stack underflow:tags stack is empty ? 17:28 hdl_laptop mmm... strange. 17:27 hdl_laptop I took out TMPL_UNLESS with its /TMPL_UNLESS 17:26 owen according to the diff on git.koha.org, you took out a <!-- TMPL_UNLESS --> and a <!-- /TMPL_IF --> Aren't you getting template errors from that? 17:24 owen If the patron has messages (overdues, circulation note, etc) that block is showing up below the checkout form rather than to the right of it 17:23 hdl_laptop owen : can you point it to me ? 17:18 owen I do see a layout bug...let me try to track it down. 17:17 hdl_laptop (I think that eventually, it could be good if error messages or warnings, or even working area would be in different included files but would be a heavy refactoring.) 17:10 owen Certainly 17:07 hdl_laptop ) 17:07 hdl_laptop (They are not much factorized. 17:07 hdl_laptop It is quite uneasy to read tmpl files. 17:07 hdl_laptop just to check that nothing else is broken by this patch. 17:06 hdl_laptop Can you do some more tests ? 17:04 owen hdl_laptop: I see the problems you describe, and your updated file seems to fix them 16:56 rhcl yea, really strong wind up here too, and we're not even in Kansas! 16:55 liz lordy, everything you've ever heard about kansas and wind is coming true today 16:54 liz pianohacker: I can appreciate that fix, for sure 16:53 liz owen: hm, ours just shows the categories alphabetically, starting with the child categories, regardless of the supercategory 16:53 hdl_laptop b) Null checkouts and fines were displayed even when no borrowers wereselected. 16:52 hdl_laptop a) divs behaved quite badly when user was selected => lefthand menu bar was displayed at the bottom of circulation page. 16:51 hdl_laptop owen : there is 2 fixes in it. 16:47 owen it preselects the patron type you chose to add though 16:46 pianohacker It was a fix for not being able to change the patron category across supercategories; i.e, an adult patron could not become a homebound patron 16:45 pianohacker liz: believe it or not, I think you have me to blame for that 16:37 owen hdl_laptop: I'm not clear on what your change was supposed to fix. Can you explain? 16:35 liz i.e. if you are adding an adult patron, it shouldn't show you child patron categories 16:35 liz you know, the add patron interface really ought to exclude patron categories that don't match the type of patron you are adding 16:22 hdl_laptop It is on 3.0.x branch 16:21 hdl_laptop well.... I should have sent it to the list, but I pushed it through directly. 16:20 owen hdl_laptop: you sent an update where? 16:19 hdl_laptop owen cnighswongerer is not around is he ? 16:17 pianohacker Maybe a double patch 16:17 pianohacker Hrm 16:16 owen pianohacker: As far as I can tell. when I set the "hidden" value to display in the editor, it doesn't. It only displays if there is a pre-filled value or if it is mandatory. 16:15 pianohacker That setting really doesn't even work correctly? That would be the icing on the cake 16:15 pianohacker owen: just saw your post 16:14 hdl_laptop (nicomo is testing it on his machine.) 16:14 hdl_laptop owen: i just sent an update on circulation.tmpl on 3.0.1 can you proof read the result so that we can be sure not to have broken any feature ? 6 eyes are better than 1 16:03 liz I feel unnaturally welcomed this morning, thank you :) 16:02 nicomo hi liz 15:57 liz and hi everybody :D 15:57 liz lol owen 15:53 hdl_laptop hi liz 15:51 kf hi liz 15:51 liz did everybody have a lovely weekend? 15:50 liz 'mornin Owen 15:50 danny hey owen and #koha 15:50 owen Hi liz and danny 14:45 kf i sent you the link 14:41 hdl_laptop ich kann ein wenig deutsch sprechen. 14:41 hdl_laptop do you have a url ? 14:41 kf in english its difficult 14:41 kf i will try to explain 14:41 kf both, but zebra can solve the search problem 14:41 hdl_laptop ??? 14:40 kf a display problem 14:40 hdl_laptop Is it a display or search problem ? 14:40 kf marc21 14:40 hdl_laptop kf are you using MARC21 or unimarc ? 14:40 owen Thank you for confirming that hdl_laptop. That is what I wanted to hear :) 14:39 hdl_laptop owen : in statistics table in koha 2.2 it was the "issuing" branch twhich was stored. 14:39 kf we have a problem with german umlauts in utf-8 14:38 kf here 14:38 hdl_laptop kf ? 14:38 hdl_laptop yes 14:36 kf hdl, can i ask you something about french accents and utf-8? 14:34 hdl_laptop Sorry out of my hat, i can't answer you. 14:32 owen hdl_laptop: do you know how 2.x versions handled this situation? Do you know which branch would be credited with the issue statistic? 14:32 atz for single branch systems, i think it is equivalent 14:31 owen F'ing hell don't tell my boss that 14:31 atz i regard koha stats w/ suspicion. 14:31 atz basically the stats all key on "branchcode" because it is the one that gets results. but it isn't really the right one. 14:30 atz i think it should. the problem is that issuingbranch is the field it should query, but that is rarely if ever populated 14:29 owen So with CircControl set to ItemHomeLibrary, the statistic for a book checked out at *any* branch will list the item's home branch? 14:27 hdl_laptop np. 14:27 atz thx hdl_laptop 14:26 hdl_laptop atz: CircControl. 14:25 atz ) 14:25 atz but can be issuing branch (i think the syspref is HomeOrHoldingBranch 14:25 atz if you are setup to circ like most ppl, it is the owning branch 14:25 atz well, i should be more specific. branchcode is the brach whose rules govern the checkout 14:24 owen I thought branchcode *was* issuingbranch 14:24 atz (i.e. owner of the item) 14:24 atz just "branchcode" 14:23 atz owen: i don't think koha stats even records "issuingbranch" for a regular checkout 14:16 owen It makes it very difficult to calculate transactions per branch if 500,000 of your renewal stats for the year don't have a branch listed. 14:15 owen I'm wondering if Koha is still not recording a branch for some renewal transactions 14:11 owen Any Koha statistics experts around? 14:00 kf perhaps you have an idea, how to teach firefox to display them right :( 14:00 owen I don't know if I can help, but I'd be glad to take a look 14:00 kf owen, can you perhaps take a look at my problem with umlauts? 13:59 owen so yeah, that's the right setting. 13:58 owen Ah, but in the manual: Datedue = the calendar only affects a due date if the due date would normally land on a closed date. 13:57 owen ...but it doesn't mention datedue 13:57 owen I'm still confused because the description of the syspref says "select Calendar to use the holidays module, and Days to ignore the holidays module" 13:56 kf i think datedue is what the libraries here want too - that due dates dont fall on days, when the library is closed, but on the next day, the library is open 13:55 jwagner Owen, did the datedue fix it for you? 13:55 owen jwagner: We had the same confusion here. People were wondering why the due date had been extended by a day 13:55 jwagner Many thanks! I'll give that a try. 13:54 kf i think so 13:54 jwagner Yes. So, looking again at the values for that syspref, what we want is datedue rather than calendar? 13:52 kf what you want is, that closed days cant be a due date? 13:52 kf with calendar its does not count the closed days for the due date, as i understand it 13:51 kf i think you want to use datedue 13:49 jwagner Paul and KF, sorry, I stepped away for a few minutes. Our UseDaysMode syspref is set to Calendar. If I'm understanding it correctly, that means it should pay attention to the holidays defined in the calendar. It seems to be doing that; it's just extending the duedate even if the defined duedate isn't on the holiday. 13:32 owen Elwell: does the database have the appropriate fields for you to work with? Is it only a display issue? 13:31 Elwell hmm. If I want to get the addresses in swiss format (streetname number, postcode town) where do I start hacking? 13:29 kf atm i have a problem with geman umlauts and how they are displayed in firefox :( 13:28 kf im glad if i can help, because normally im just asking questions 13:27 paul_p kf ++ !!! I forgot this one !!! 13:27 kf useDaysMode 13:27 kf https://sites.google.com/a/liblime.com/koha-manual/Home/Table-of-Contents/administration/Global-Preferences/Global-Preferences--Circulation 13:26 kf jwagner, i thought you can configure how calendar is handled 13:26 kf there is a syspref 13:07 jwagner Thanks, Paul. I'll keep poking around. I didn't see any relevant bugs on the bugzilla site, but maybe this is a new one. 13:04 paul_p jwagner: I'm afraid I won't be helpful here : our libraries usually have due dates calculated in weeks. So if someone issues a book on monday (open), it's due on monday (open too !). So nobody ever reported a bug on that, & I never had to investigate. 13:02 jwagner Hmmmm. We've tested and it doesn't seem to be working that way. Feb 16 is defined as a holiday. If the loan period extends past Feb 16 (e.g., would normally be due on Feb 20), the system is making it due a day later (Feb 21). However, if the loan period ends before Feb 16, the due date falls on the proper date. As far as I can see, the calendar is set up correctly. What else can I look at? I don't see many policies or sysprefs other than the ones 13:00 paul_p hi jwagner. strange you're right. The way it's supposed to work, afaik, is to add days only if the due_date is a closed one, you're right 12:58 jwagner I had assumed that the holiday part only came into effect if a due date fell on a day defined as a holiday. What seems to be happening is that if a day defined as a holiday falls anywhere in the loan period, the loan period is extended by a day. Is this the way it's supposed to work? 12:56 jwagner Can someone answer a question about the logic behind calculating due dates with a holiday in the calendar?