Today | Next day → | Search | Index
All times shown according to UTC.
| 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 | 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 | time to switch to a bug that's actually supported, then | |
| 23:30 | ricardo | LOL! |
| 23:31 | 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 | 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 | 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 | 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 | 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/gi[…]366e46344;hb=HEAD |
| 23:44 | and grep for NoZebraIndexes | |
| 23:44 | ricardo | gmcharlt: Great! Many thanks! :) |
| 23:45 | 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 | 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 | 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 | 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 | ricardo: yeah, adding a "mc-itemtype" might work | |
| 00:06 | ricardo | gmcharlt: OK, thanks. Let me try it. |
| 00:07 | Changed "NoZebraIndexes" value... Running rebuild_nozebra.pl ... | |
| 00:11 | Nope. Didn't work. I think these itemtypes / itype ... biblioitem / item will quickly lead me to Total Insanity! ;-) | |
| 00:12 | 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 | (using switch -c UNIMARC ) | |
| 00:18 | gmcharlt | if you query the nozebra table, do any 'mc-itemtype' entries show up? |
| 00:18 | (query using SQL, I mean) | |
| 00:19 | ricardo | gmcharlt: Good question (as always!). Let me check |
| 00:19 | gmcharlt: What's the name of the nozebra table? Is it "biblio"? | |
| 00:20 | "nozebra" | |
| 00:20 | Let me check it | |
| 00:22 | Is it really "nozebra"? :-/ The values are very weird | |
| 00:22 | gmcharlt | yes, it really is nozebra |
| 00:24 | 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 | ? | |
| 00:28 | ricardo | gmcharlt: Well, I have this output: |
| 00:28 | No results match your search with limit(s): 'mc-itemtype:1'. | |
| 00:30 | Hmmm.... | |
| 00:30 | "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 | 990 ## - ADDED ENTRY ELEMENTS (KOHA) | |
| 00:31 | c Koha item type ARTIGO | |
| 00:31 | ("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 | 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 | around line 2276 of C4/Search.pm | |
| 00:45 | if you change $string =~ s/-|\.|\?|,|;|!|'|\(|\)|\[|\]|{|}|"|&|\+|\*|\// /g; | |
| 00:45 | ricardo | And so...? Is this a Bug? |
| 00:45 | gmcharlt | to $string =~ s/\.|\?|,|;|!|'|\(|\)|\[|\]|{|}|"|&|\+|\*|\// /g; |
| 00:45 | would work, although likely at cost of adding another bug | |
| 00:45 | 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 | 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 | 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 |
Today | Next day → | Search | Index