Time  Nick     Message
23:25 gmcharlt ricardo: I only aim at misbehaving bots ;)
23:25 ricardo  gmcharlt:  :)
23:26 gmcharlt one of these days I'm going to fix the bot so that it deals with the IRC server disconnecting ...
23:26 ricardo  gmcharlt: Right
23:27 ricardo  What's "newlogbot" running? Is it eggdrop?
23:27 gmcharlt it's a funbot
23:28 ricardo  gmcharlt:  Hmmm... Does "funbot" have a web site? Google searches are returning diverse results for "funbot"
23:30 gmcharlt http://spisa.act.uji.es/~peralta/adibot/, but that link's dead
23:30 gmcharlt time to switch to a bug that's actually supported, then
23:30 ricardo  LOL!
23:31 ricardo  Yeah... When using "BUGs", at least let them be *supported* bugs, right?  ;-)
23:31 gmcharlt well, we certainly don't want freefalling bugs now, do we? :)
23:32 ricardo  Eheheh
23:33 ricardo  This is probably documented somewhere (feel free to point me): when translating via "po" files (instead of using Kartouche), what else is required besides editing the po file?
23:34 gmcharlt I think nothing except using tmpl_process3.pl to generate the actual templates and to make sure you haven't introduced a typo in the po file
23:35 gmcharlt or rather, a typo that breaks structure ... tmpl_process3.pl doesn't spellcheck your Portugese for you ;)
23:36 ricardo  gmcharlt: Right... BTW: "Portugese" *is* a typo. The correct English spelling is "Portuguese"  (with an "u" between the "g" and the "e")  :)
23:37 gmcharlt my point exactly ;) (I thought I was forgetting a 'u')
23:37 ricardo  The original native spelling is "Português", BTW ... Gotta love those "accented characters"!  ;-)
23:38 ricardo  Is running   /misc/translator/install_code.pl also necessary (and or advisable) ?
23:40 gmcharlt I don't think install-code.pl needs to be used, afaict
23:40 ricardo  gmcharlt:  OK, thanks
23:42 ricardo  Is paul awake?  I would like to have the "NoZebraIndexes" value for UNIMARC again, please  :)  (I have them at work, but not here at home)
23:44 gmcharlt ricardo: http://git.koha.org/cgi-bin/gitweb.cgi?p=Koha;a=blob;f=installer/data/mysql/fr-FR/1-Obligatoire/unimarc_standard_systemprefs.sql;h=a059cf2788cdfcf8de12f42e4a5b0e5366e46344;hb=HEAD
23:44 gmcharlt and grep for NoZebraIndexes
23:44 ricardo  gmcharlt: Great! Many thanks!  :)
23:45 ricardo  Off-Topic: what do you Galen - and anyone else, for that matter - use for "Virtual Machines"? I'm getting disappointed with XEN regarding VM migration ("guests") between different "hosts"  :-/
23:46 gmcharlt my personal use of VMs is limited to Parallels on OS X
23:47 ricardo  gmcharlt:  Ah right. Thanks
00:01 ricardo  gmcharlt: Why are searches for item types querying "mc-itemtype"? (what does "mc" stand for)?
00:02 gmcharlt not sure what "mc" stands for, but it's currently used by advsearch to prefix index codes used for search limited
00:03 gmcharlt limiting
00:04 ricardo  Hmmm... I'm not sure that's working. At least, when one changes the "item-level_itypes" System Preference value to OFF  (as I did)
00:05 ricardo  gmcharlt: Do  I have to change the "itemtype" name in "NoZebraIndexes" to something else (eg: "mc-itemtype"?)
00:05 gmcharlt hmm, looks like it's mapping biblioitems.itemtype to mc-itemtype and items.itype to mc-itype
00:06 gmcharlt ricardo: yeah, adding a "mc-itemtype" might work
00:06 ricardo  gmcharlt: OK, thanks. Let me try it.
00:07 ricardo  Changed "NoZebraIndexes" value... Running rebuild_nozebra.pl ...
00:11 ricardo  Nope. Didn't work. I think these itemtypes / itype ... biblioitem / item  will quickly lead me to Total Insanity!  ;-)
00:12 ricardo  I'm pointing "mc-itemtype" to the 990c field (that is the same used in "biblioitems" in the "MARC Mapping" area)
00:12 gmcharlt and 990$c is actually populated in your data (just to double-check)?
00:14 ricardo  gmcharlt: Yep. At least, they are in the "iso" files that I ran through bulkmarcimport.pl
00:14 ricardo  (using switch  -c UNIMARC )
00:18 gmcharlt if you query the nozebra table, do any 'mc-itemtype' entries show up?
00:18 gmcharlt (query using SQL, I mean)
00:19 ricardo  gmcharlt: Good question (as always!). Let me check
00:19 ricardo  gmcharlt: What's the name of the nozebra table? Is it "biblio"?
00:20 ricardo  "nozebra"
00:20 ricardo  Let me check it
00:22 ricardo  Is it really "nozebra"?  :-/ The values are very weird
00:22 gmcharlt yes, it really is nozebra
00:24 gmcharlt i.e., select count(*) from nozebra where indexname = 'mc-itemtype';
00:24 ricardo  gmcharlt: http://pastebin.com/m33b313b4
00:25 gmcharlt and 1, 2, 5, 8 are valid itemtype codes in your test DB?
00:25 ricardo  Yep!  :)
00:26 gmcharlt so then, query being generated is actually "... and mc-itemtype=8"
00:26 gmcharlt ?
00:28 ricardo  gmcharlt: Well, I have this output:
00:28 ricardo  No results match your search  with limit(s): 'mc-itemtype:1'.
00:30 ricardo  Hmmm....
00:30 ricardo  "MARC view" in Koha (in Intranet) is showing me the Item Type description (not the code). I don't know if that's usual behavior or not:
00:31 ricardo  990 ## - ADDED ENTRY ELEMENTS (KOHA)
00:31 ricardo  c  Koha item type  ARTIGO
00:31 ricardo  ("1" is the code for the "ARTIGO" description)
00:33 gmcharlt hmm - if you add SetEnv DEBUG 1 to your Apache config for your OPAC and restart Apache, the resulting exact query will show up in the Apache log
00:34 ricardo  gmcharlt: Okie Dokie. Let's do that!  :)
00:38 ricardo  gmcharlt: http://pastebin.com/d4186213e
00:41 gmcharlt ok, there's the problem - "mc-foo" isn't working because NoZebra query parsing converts the hyphen in the index name to a space, and ends up effectively converting search to mc=1
00:42 ricardo  So the indexname in "NoZebraIndexes" should be 'mc itemtype' instead of 'mc-itemtype'?
00:44 gmcharlt "mc", actually, but that's a fail because *all* search limits would end up hitting the mc index
00:44 gmcharlt around line 2276 of C4/Search.pm
00:45 gmcharlt if you change   $string =~ s/-|\.|\?|,|;|!|'|\(|\)|\[|\]|{|}|"|&|\+|\*|\// /g;
00:45 ricardo  And so...? Is this a Bug?
00:45 gmcharlt to   $string =~ s/\.|\?|,|;|!|'|\(|\)|\[|\]|{|}|"|&|\+|\*|\// /g;
00:45 gmcharlt would work, although likely at cost of adding another bug
00:45 gmcharlt in any event, yes, this is a NoZebra search bug
00:45 ricardo  Isn't life great?!   :S
00:46 gmcharlt it will be even better if I can convince to try Zebra ;)
00:46 ricardo  *egads"!
00:46 cnighs_  I finally gave up in favor of zebra
00:48 ricardo  gmcharlt: Eheh.... You deserve it. Thanks a lot!  :) Although, I must admit, those "RegExps" make my head hurt a lot
00:48 gmcharlt well, perl wouldn't be executable line noise without them :)
00:48 ricardo  LOL!
00:51 ricardo  I think I'll try to report this bug on Wednesday night (I have a demo on Wednesday morning) and really do NOT have the time to submit a detailed Bug Report until then  :(
00:51 cnighs_  ricardo: anymore problems w/bug 2392?
00:52 gmcharlt ok - maybe just paste the IRC log into a bug report, then clean it up on Wednesday
00:52 ricardo  cnighs_: That's not mine  :)
00:54 cnighs_  different ricardo then?
00:55 ricardo  cnighs: Ah sorry! I mistyped the bug number. You're right. I'm "that" Ricardo  :)  Yep, no more problems with [0] array references so far (knocks on wood...)
00:56 cnighs   ricardo: tnx!
00:56 ricardo  cnighs: No, thank YOU :)
01:28 ricardo  Gotta go. Take care everyone. Thanks Galen and Chris!
03:45 atz_     no zebra = trying to paint stripes on a horse.
04:02 cnighs   hehe