Time |
S |
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/gi[…]366e46344;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 |