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.
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?