Time  Nick      Message
14:50 kados     OK, goodie, now we're making progress
14:52 kados     fbcit: how can I reproduce the issue, which bibs is it happening with?
14:56 fbcit     that's the problem
14:56 fbcit     one of my data entry people has the problem now
14:57 fbcit     the other does not
14:57 fbcit     grrrr
14:57 kados     weird
14:57 kados     they are using Koha's built-in MARC editor with Z39.50?
14:57 kados     or some other process?
14:57 fbcit     right
14:58 kados     can you hook us up with the specific target info you have set up and which records specifically they are trying to import and subsequently add items too?
15:01 fbcit     yep
15:02 fbcit     btw: zebraqueue daemon is running and the missing records are begin processed by it, contrary to my previous observation
15:02 fbcit     but they do not show in a search
15:03 fbcit     most marc records are coming from loc here
15:03 kados     lets try this: turn off zebraqueue daemon, I don't trust it
15:03 kados     and add a cron task with rebuild_zebra.pl and the -z option
15:03 kados     for bibs and authorities
15:04 kados     so use -z -a -b
15:06 rhcl      For what it's worth, we had (have?) the _exact_ same problem here. Even though we still have the zebra daemon running, we either do a manual rebuild or wait for the cron job to rebuild zebra.
15:07 kados     yea, I pretty much have given up on the zebraqueue daemon
15:07 rhcl      we're using the flags "-w -b -a" for the cron rebuild
15:07 fbcit     k
15:07 kados     I'll make sure that's clear in the install docs
15:07 fbcit     cron task is in place
15:07 kados     rhcl: why not -z ?
15:08 fbcit     kados: so do we are thinking this is a script problem rather than some weird record problem, right?
15:08 rhcl      huh, just because I don't know?
15:08 kados     rhcl: I'd recommend -z, it will use the zebraqueue table, so you can run it every 5 minutes or so
15:09 kados     rhcl: ie, rather than a complete index re-build
15:09 kados     fbcit: if you are adding records that aren't making it into zebraqueue table, that sounds like abug, but I need specific examples
15:09 kados     so i can reproduce it
15:09 kados     fbcit: I think the ebraqueue daemon issues are separate
15:09 kados     fbcit: and running rebuild_zebra.pl with -z option should clear those issues up
15:10 fbcit     no, they appear to be making it there, I was mistaken earlier due to zebraqueue daemon running
15:10 kados     ahh
15:10 kados     ok, so then it's probably entirely the zebraqueue daemon
15:10 fbcit     it was grabbing them before I looked :-)
15:10 rhcl      the man page for zebra doesn't show a "-z" flag.
15:11 kados     rhcl: the -z flag is for the reubild_zebra.pl script
15:11 kados     rhcl: do misc/migration_tools/rebuild_zebra.pl --help
15:11 rhcl      OK, tnx
15:12 kados     fbcit: that's a huge relief, esp since I was hoping to get 3.0-stable out this week ;-)
15:12 fbcit     kados: about mysql utf-8
15:12 kados     fbcit: a bug where new items weren't getting added to zebraqueue would have thrown a wrench in that plan
15:13 fbcit     the koha db is utf-8 and db/table/column level
15:13 fbcit     does it really matter what the mysql server is at that point?
15:13 kados     yes, it really does
15:14 kados     especially important is the encoding of the connection
15:14 kados     maybe not so much the server though ...
15:14 kados     all I know is, I've seen some weird encoding issues without following things carefully
15:14 fbcit     so after setting up mysql server for utf-8, I need to export my bibs and re-import them to correct encoding?
15:15 kados     are you certain that's the cuprit?
15:15 fbcit     it does appear to be an encoding issue as it is occurring with every book in Spanish
15:15 kados     ok, that's a good sign
15:15 fbcit     diacriticals seem to be the issue
15:15 kados     yep
15:15 fbcit     so, fix config; export; import?
15:16 kados     if you could give me some specific examples, I'd like to make sure a properly encoded system handles those records correctly
15:16 fbcit     k
15:16 kados     but I hvae to eat breakfast first, so if you could send me a list of ISBNs or titles to search for on LOC that trigger a problem for you, I'll check them out when I get back
15:17 fbcit     Diccionario De La Lengua Española
15:17 kados     (you could also teston koha.liblime.com, though the indexing wont' updat there, but you could see if the encodings work)
15:17 fbcit     ISBN 8423968146
15:19 fbcit     that record is being pulled from UNC @ Chapel Hill
15:19 fbcit     afton.lib.unc.edu:210
15:19 fbcit     innopac db
15:19 fbcit     utf8 encoding
16:14 kados     fbcit: hack
16:14 kados     back I mean
16:14 kados     fbcit: testing now
16:15 fbcit     kados: it is definitely utf-8 afaict
16:15 kados     Ok, the title's showing up with a question mark, so it doesn't bode well
16:15 fbcit     I also added bug 2327
16:16 kados     I suspect that the encoding isn't utf8
16:16 kados     while claiming to be utf8
16:16 kados     have you tried marc8?
16:16 fbcit     no
16:16 kados     fbcit: got another isbn for me so I can test something?
16:17 fbcit     hold on
16:19 fbcit     kados: do a z3950 search on 8476456700 with all servers selected
16:20 kados     k
16:21 kados     is that at the chapel hill target?
16:21 kados     fbcit: i wanna test marc8
16:21 fbcit     no
16:21 fbcit     I'm trying to locate where they pulled it
16:21 kados     I need another example from chapel hill if you have one
16:23 kados     fbcit: I changed the chapel hill target to marc-8 and it's working now
16:24 kados     fbcit: if you change it to marc8, Koha will convert it to utf8 for you automagically
16:25 kados     fbcit: i've also had terrible problems iwth the LOC's claimed UTF-8 encoding, use MARC8 there too
16:27 fbcit     kados: works fine now
16:27 kados     fbcit: OK, I'll update the bug
16:27 kados     galen may have time next week to investigate what the specif problem with the III systems' UTF8 is
16:27 kados     but for now, setting to MARC8 is a decent alternative
16:27 fbcit     z3950 searches still blow chunks with isbn's on certian targets
16:28 kados     fbcit: can you give me some examples?
16:28 fbcit     see bug 2327 for starters
16:29 fbcit     but also 083793950X with the UNC target
16:29 kados     another innopac system
16:29 kados     III--
16:30 fbcit     even w/UNC set to MARC8 the error occurs
16:30 kados     intersting
16:30 fbcit     I also notice that none of the z3950 targets installed by the webinstaller have a default Encoding set
16:31 kados     ahh, I wonder if that's the prob
16:31 fbcit     that column should probably be set NOT NULL
16:31 kados     from the display it looks like the all have marc-8
16:31 kados     they I mean
16:32 fbcit     here they show nothing except where I set them
16:32 kados     yea, they have MARC-8
16:32 kados     at least for me they do
16:32 kados     and checking the sample data, it's in there
16:32 fbcit     hrmm
16:35 fbcit     well, that does not fix the can't call method raw error
16:37 nengard   owen (at least I think it was you) didn't we make it so that this preference 'OPACBaseURL' wasn't necessary ... or was that someone else I was talking with?
16:38 kados     nengard: it still is necessary for some stuff
16:38 kados     nengard: but there's a bug that we will fix in 3.2 to finally remove it
16:38 nengard   thanks kados - just checking as I browse through
16:38 nengard   my documentation
16:40 nengard   what is GranularPermissions - this is something new to me
16:41 kados     nengard: it turns on the little + button for some permission groups, like 'tools'
16:41 acmoore   OMG. ask gmcharlt. prepare for about 4 hours of explaining.
16:42 nengard   acmoore :) hehe
16:42 nengard   I like kados's explanation - I'll take that nice short one
16:42 kados     nengard: turn it ON and then edit a patron's permission, you'll see it for yourself
16:42 gmcharlt  nengard: also see http://git.koha.org/cgi-bin/gitweb.cgi?p=Koha;a=commit;h=cafaa26b4537fed3664f6dc658533d95912b5d6f
16:42 kados     it's the start of further granularization of permissions for Koha
16:43 gmcharlt  nengard: and http://git.koha.org/cgi-bin/gitweb.cgi?p=Koha;a=commit;h=70d33a82bb5d30c0455070e96cc5ad4fea545a9d
16:43 nengard   gmcharlt you mention a system preference: CheckSpecificUserPermissions - but i don't see it
16:43 gmcharlt  was renamed to GranularPermissions
16:45 nengard   k
16:45 kados     my $rec = $oResult[$k]->record($i);
16:45 kados                         if ($rec) {
16:45 kados                             my $marcrecord;
16:45 kados                             $marcdata   = $rec->raw();
16:45 kados     fbcit: oddly, the error is claiming that $rec is undefined
16:45 kados     fbcit: but right above it, we test for that
16:46 kados     strange
16:47 fbcit     very
16:47 nengard   gmcharlt - i may have missed this - but what if this is on and then gets turned off later - does it change the user's permissions from the granular form to the original? or do they keep their permissions until their record is edited?
16:48 gmcharlt  nengard: it reverts to the original behavior, although the specific permissions are retained
16:48 nengard   k
16:49 gmcharlt  practically, though, the syspref should never be changed from on to off
16:49 kados     fbcit: [Wed Jul 09 11:49:04 2008] [error] [client 166.129.4.61] ZOOM error 1 "Permanent system error" (addinfo: "Permanent system error") from diag-set 'Bib-1', referer: http://staff-jmf.dev.kohalibrary.com/cgi-bin/koha/cataloguing/z3950_search.pl?biblionumber=0&lccn=%20%202002398788&isbn=8423968146%20(O.C.)&isbn=8423968235%20(t.%201)&isbn=8423968243%20(t.%202)&title=Diccionario%20de%20la%20lengua%20espan%CC%83ola%20/
16:49 kados     that's the error Im getting
16:51 kados
16:51 kados     [Wed Jul 09 11:50:45 2008] [error] [client 166.129.4.61] ZOOM error 1 "Permanent system error" (addinfo: "Permanent system error") from diag-set 'Bib-1', referer: http://staff-jmf.dev.kohalibrary.com/cgi-bin/koha/cataloguing/z3950_search.pl?frameworkcode=
16:51 kados     [Wed Jul 09 11:50:45 2008] [error] [client 166.129.4.61] Premature end of script headers: z3950_search.pl, referer: http://staff-jmf.dev.kohalibrary.com/cgi-bin/koha/cataloguing/z3950_search.pl?frameworkcode=
16:51 kados
16:51 kados     fbcit: where are you seeing the other, more useful error?
16:52 kados     fbcit: did you set DEBUG or something?
16:53 fbcit     weird
16:53 fbcit     no on DEBUG
16:53 fbcit     are you searching on 8423968146 @ UNC?
16:54 fbcit     which error are you referring to?
16:55 kados     no, searcing catnyp, I'm talking about the error about raw() as documented in your bug report
16:55 fbcit     try 083793950X on the UNC target as that gives "Can't call method "raw" on an undefined value at /usr/share/koha/intranet/cgi-bin/cataloguing/z3950_search.pl line 216.
16:55 fbcit     "
16:56 kados     huh
16:56 kados     if I search it in cattnyp with yaz-client it returns no results
16:56 fbcit     it also produce that error on catnyp
16:56 kados     I don't get that error for some reason, i get the one above
16:56 kados     maybe we have different deubg levels or something
16:57 kados     fbcit: I'll try searching unc for that isbn using yaz-client
16:57 fbcit     so if no results are returned I wonder why "if ($rec) {" fails?
16:57 kados     not sure
16:58 kados     interstingly, I get failyure with default settings in yaz-client for both cattnyp and unc
16:58 kados      f @attr 1=7 083793950X
16:58 kados     returns no hits
16:59 fbcit     kados: when was that check added to z3950_search.pl? my version does not have it
16:59 kados     something screwy going on here :/
17:00 kados     fbcit: ? what check?
17:00 fbcit     if...
17:00 kados     fbcit: the check for $rec?
17:00 fbcit     right
17:00 kados     might have been yesterday, MJ added a couple things
17:00 fbcit                         my $rec = $oResult[$k]->record($i);
17:00 fbcit                         my $marcrecord;
17:00 fbcit                         $marcdata   = $rec->raw();
17:00 fbcit     that might explain it
17:01 kados     but I still get an error
17:01 kados     just not the same one
17:01 fbcit     this install was updated two weeks ago
17:01 kados     so that explains our difference :-)
17:01 kados     the bib-1 error is somewhat telling
17:01 kados     I suspect III is expecting a different set of arguments for queries than we're providing
17:02 fbcit     brb
17:02 kados     fbcit: are any queries on those targets working?
17:02 kados     any ISBN queries in particular?
17:02 kados     and if we try to find the same records via another mechanism does it fail?
17:04 fbcit     bak
17:04 fbcit     back even
17:05 fbcit     kados: it does not appear that any isbn searches work against those targets via z3960_search.pl
17:05 kados     yea
17:05 kados     I'm trying 'Who's Who in the Media and Communications 1998-9'
17:05 kados     as title now
17:05 kados     nothing found
17:05 kados     but no failures
17:06 fbcit     yea, titles do not cause failures here either
17:08 kados     OK, so there is something III catalogs are expecting that we're not providing
17:09 kados     fbcit: http://irspy.indexdata.com/find.html?cql.anywhere=&dc.title=&zeerex.country=&net.protocol=&net.host=catnyp.nypl.org&net.port=&net.path=&zeerex.libType=&dc.description=&dc.creator=&_sort=&_search=Search&_count=10&_skip=0
17:09 kados     http://irspy.indexdata.com/raw.html?id=Z39.50%3Acatnyp.nypl.org%3A210%2FINNOPAC
17:10 fbcit     cool
17:12 kados     oh, you're kidding me ...
17:12 kados     Innopac Z39.50 server does not always use the. standard Bib-1 attributes. For example, the Any. Field search (use attribute = 1016) is actually a. title search
17:14 kados     fbcit: can we be blamed for conforming to the standard ?
17:14 kados     this is why I get silly mad
17:14 fbcit     ok, code here is in sync now
17:14 kados     this is an instance where Koha gets blamed
17:14 kados     but we're blamed for following the standard
17:14 kados     arrrg
17:15 kados     fbcit: this is great:
17:15 kados     f @attr 1=1016 "Who's Who in the Media and Communications 1998-99"
17:15 kados     Sent searchRequest.
17:15 kados     Received SearchResponse.
17:15 kados     Search was a bloomin' failure.
17:15 kados     Number of hits: 0, setno 1
17:15 kados     Result Set Status: none
17:15 kados     records returned: 1
17:15 kados     Diagnostic message(s) from database: [100] Unspecified error -- v2 addinfo 'Search taking too much time.  Server is disconnected.'
17:16 kados     so basically, I try a 1=1016 (actually keyword, but apparantly title in III), and it can't respond fast enough
17:16 kados     fbcit: do you think you could explain this problem to your catalogers?
17:16 fbcit     looks like a 5 pound spider rather than a simple bug
17:17 kados     fbcit: in a way that they would feel warm and fuzzy about Koha ?
17:17 kados     yea
17:17 kados     5-lb-spiders--
17:17 kados     fbcit: Ok, I"ll add this additional info to the bug report
17:18 fbcit     sounds like we will have to have code to handle the various exceptions
17:19 kados     yep
17:19 kados     this would be better handle with pazpar2
17:20 kados     you can pass info about each target config separately before doing the federated search
17:20 kados     fbcit: I'm afraid this won't be fixed for 3.0
17:20 kados     but I'm confident we can work on a solution for 3.2 using pazpar2
17:21 fbcit     np, we'll work around it here
17:21 kados     fbcit: biblios already uses pazpar2
17:21 kados     ccatalfo: around?
17:21 ccatalfo  sure am
17:22 ccatalfo  smth about using pazpar2 with different bib attributes per target?
17:23 kados     ccatalfo: yea
17:23 kados     ccatalfo: something to bear in mind for biblios
17:23 kados     ccatalfo: each type of target is going to have different expectations for what a 'title'  search is for example
17:24 ccatalfo  kados: yup
17:24 ccatalfo  kados: as it happens, at some point over the last month i put a hack in place to let us do that in the biblios.conf file, but fallback on biblios' defaults if not specified
17:24 kados     ccatalfo: and I have some good news from Index Data about how to manage a database of target information too
17:24 kados     oh, cool
17:24 kados     you rock
17:24 ccatalfo  kados: it's not in the main git repo yet, though
17:24 kados     ccatalfo: I'll fill you in on the ID info when I have some time
17:24 ccatalfo  kados: ah, that sounds great
17:25 kados     it will allow us to pull from dbs like IRSPY and have local overrides on select values of fields, as well as add our own targets, per user
17:25 kados     should be pretty swank actually
17:25 kados     more on that later :-)
17:25 ccatalfo  cool, can't wait to get details and try out...
17:25 kados     fbcit: I will figure out a way to fix this completely broken instance, but as to getting III to work, that'll have to wait
17:27 fbcit     so not only are we expected to fix koha, but other systems too, heh?
17:27 kados     apparantly
17:50 kados     fbcit: it appears from furthe tests that the actual connections to innopac are failing for isbn searches
17:50 kados     fbcit: I'm adding some user errors to make it clear where the problem is
17:50 kados     to the actual cataloger
17:59 fbcit     tnx
18:16 Kyle      Hey all, I submitted some Koha 3 patches. I followed the git_usage guide on the koha wiki. I haven't seen them show up on the patches mailing list. Is there any way I can find out if they went through?
18:18 kados     Kyle: it's possible they are in moderation, are you subscribed to the koha-patches list on lists.koha.orjg?
18:18 kados     Kyle: if you want, you can also cc me, jmf AT liblime DOT com and I will confirm your outgoing mail is working
18:19 Kyle      Yes, however, I think it's a problem with mail email configuration. I'll cc them to you as well.
18:20 Kyle      I used the command 'git send-email filename'
18:20 Kyle      Is there something else I need to do?
18:21 kados     you may need to properly configure your outgling mail server
18:21 kados     exim perhaps?
18:21 kados     or postfix?
18:22 Kyle      From what I'm reading, it sounds like I can just send them to patches@koha.org as attachments from my gmail account. Is this correct?
18:28 acmoore   Kyle, they'll probably work OK like that, though some mailers are known to goof up attachments. give it a try, though.
18:28 acmoore   kados, who is the moderator for the patches@ list, anyway?
18:29 acmoore   Kyle, they'll get held up for moderation before they make it to that list if you're not subscribed.
18:30 acmoore   Kyle, have you been working on making your PHP enamcements work with koha 3?
18:30 kados     acmoore: hdl is the moderator for that list
18:31 kados     Kyle: gmail will definitely goof up the attachments
18:31 kados     Kyle: you could just point to them on a web server
18:31 acmoore   kados, thanks. It's dinnertime in France, so we might not get them approved today, I guess.
18:31 kados     and I can grab then from there
18:31 kados     acmoore: *nod*
18:38 kados     wow, you gotta love III, their errors always come back as "No error"
18:38 kados     brilliant!
18:39 sawariwap any tentative date for the final release?
18:40 kados     sawariwap: today, tomorrow?
18:41 kados     this week for certain
18:44 sawariwap oh ok
18:44 sawariwap cool
18:44 sawariwap :)
18:56 Kyle      acmoore: I probably won't be porting the koha-tools stuff until we get closer to our switchover. I would like to rewrite as much as possible in perl and integrate it into Koha 3.0. That way it benefits more people and is easier to maintain.
18:56 acmoore   Kyle, yeah, that would be great! It looks like you've been doing some cool stuff, and we could always use the help.
18:59 Kyle      Thanks. I really want to move away from 'doing my own thing' to contributing more directly to Koha. I've been moving stuff from koha-tools into dev_week. Recently, I rewrote our fines system ( which creates fines on an item's return, instead of nightly ) as part of Fines.pm in dev_week. It's been much more stable since.
20:39 acmoore   anyone know why C4::Output::pagination_bar makes links like http://example.com/cgi-bin/koha/acqui/neworderbiblio.pl?q=a?page=2  when you pass it a URL that already has some query_string n it. it seems like it doesn't realize it's supposed to be using &'s after there's already a ? in there.
20:39 acmoore   I'm presuming I'm using it wrong, although I'm using it just like other calls.
20:41 acmoore   coinsidering that it's been around for so long, nearly unmolested, I have to presume I'm using it wrong, but I can't figure out how to do it right.
20:44 kados     acmoore: I never presume anything with code taht's been around a log time in Koha:-)
20:49 chris     it was written by plg .. april 2006, so its relatively recent :-)
20:49 chris      improved: C4::Output::pagination_bar builds an HTML pagination bar with no
20:49 chris         language dependency. This function hugely simplifies templates and offers a
20:49 chris         standard pagination method. This function also improves preformances.
20:49 chris     apparently its awesome :-)
20:50 paul      was written a few weeks before pierrick leaved Ineo-ms...
20:50 paul      probably "unfinished" code...
20:50 chris     yep
20:50 chris     knowing pierrick it would have been great once it was finished
20:50 chris     he's a very smart guy
20:51 chris     you must be on your way to bed paul?
20:51 paul      yep.
20:51 paul      although alone those weeks, so I work late ;-)
20:51 chris     ahh :)
20:51 paul      mmm... kados...
20:52 paul      the patch about Context.pm let a line 252 with "$context", which is useless & result in zillions of warnings in http conf
20:52 paul      I'll submit a patch for that immediatly
20:53 paul      patch sent
20:55 acmoore   well, I hacked around the part of it that looked like a bug to me. If I'm using it wrong, we can correct my calls to it later. I can't figure out for the life of me how to use it right.
20:56 acmoore   so, patch for 1980 sent. that's my last blocker.
20:59 acmoore   Looks like we have 7 remaining.
20:59 chris     nice work
21:00 paul      4 of them being related to serials edition...
21:01 paul      mmm... I get 8 in my bugzilla list.
21:01 paul      3 of them having a "patch sent", and 4 related to serials edit
21:02 paul      the last one being "warn staff about resource hogging scripts"
21:03 paul      ok, time to leave for me.
21:03 paul      have a good day (end of wed of start of thurs...)
21:03 paul      i'll be here tomorrow (except for 2hours, meeting with my bank)
21:05 acmoore   paul, I limited out one that was set against 3.2. that left me with 7.
21:05 chris     cya paul
21:05 acmoore   bye, paul.
21:05 cnighs    bye paul
06:27 mc        hello
06:59 chris     hi mc
09:28 masonj    anyone aboot?
09:28 masonj    i wonder if someone with a recent koha3-zeb can confirm something quickly for me..
09:30 masonj    can anyone successfuly do a ' ' search , with 2 or more itypes, and get results?
09:31 paul      hi masonj
09:31 masonj    hi paul
09:32 masonj    lemme explain...
09:32 paul      hey... you're right
09:32 paul      it doesn't work
09:32 paul      anymore
09:32 masonj    so i can do a search on books, and get 100 results...
09:32 masonj    and a search on magazines , and get 20 results
09:33 masonj    but if i do a search on mags and books, i get 0 results not 120
09:33 masonj    .
09:35 chris     i concur
09:35 chris     same for me
09:36 masonj    ok, good to know
09:38 masonj    hey paul, could i ask you some little questions about the 'fr/sort-string-utf.chr' file
09:38 paul      yep
09:39 masonj    ive been working with some french data, and experimenting with the zebra search behaviour
09:41 masonj    so, the Q is - do  you get any interesting output from zebrasrv , when zebrasrv is doing the character substitution?
09:41 masonj    im trying to debug it
09:42 masonj    hmm, perhaps i should sentd you an email with some log output from my zebrasrv 1st
09:43 paul      yep, as I don't understand what you're speaking of...
09:45 masonj    if i have a title 'des moutons' - and i search for 'Dés Moutons' i should get a result
09:45 masonj    because sort-string-utf.chr is doing a ' map êèéëÊÈÉË        e'
09:46 paul      right
09:46 masonj    yet that doesnt seem to be working for me :(
09:46 paul      mmm... bad choice, as Des is also an empty word, so if you have french empty words, it will be ignored
09:46 paul      try "moûtons"
09:46 paul      or "moùtons"
09:47 paul      is your file correctly encoded (utf-8) on your server ? I had some problems with that
09:47 masonj    hmm, my sort-string-utf.chr file?
09:47 paul      yep.
09:48 paul      is it correctly encoded on your server ?
09:48 paul      (utf-8)
09:48 masonj    ahh, yes i did remember an error vim? gave me about my sort file too, some months ago..
09:49 paul      it's sometimes a pain to be sure, as you may have it latin1 encoded, and, if your console is latin1 too, you won't see the problem
09:50 masonj    right, let me send you this log ...., perhaps you can spot a difference in behaviour
09:56 masonj    $ file  sort-string-utf.chr sort-string-utf.chr: UTF-8 Unicode English text
09:56 masonj    oops, missing a \n there
09:59 masonj    so , on a zebra that is doing accented character mapping correctly - is there any extra stuff happening in the...
10:00 paul      masonj: did you adapt default.idx accordingly to thisnew .chr file ?
10:01 paul      charmap ...
10:06 masonj    zebrasrv(18) [request] Search biblios OK 0 1 1+0 RPN @attrset Bib-1 @or @or @or @or @or @attr 1=
10:06 masonj    line ?
10:06 masonj    or the ' zebrasrv(18) [log] dict_lookup_grep:XXXX lines too?
10:06 masonj    the zebrasrv [request] line doesnt seem to be doing the a search for 'moutons' anywhere, just lots of 'moùtons'..
10:06 masonj     zebrasrv(21) [request] Search biblios OK 0 1 1+0 RPN @attrset Bib-1 @or @or @or @or @or @attr 1=36 @attr 4=1 @attr 6=3 @attr 9=32 @attr 2=102 moùtons @attr 1=4 @attr 4=1 @attr 6=3 @attr 9=28 @attr 2=102 moùtons @attr 1=4 @attr 4=1 @attr 9=26 @attr 2=102 moùtons @attr 4=6 @attr 5=103 @attr 9=16 @attr 2=102 moùtons @attr 4=6 @attr 5=1 @attr 9=14 @attr 2=102 "moùtons? " @attr 4=6 @attr 9=14 @attr 2=102 moùtons
10:06 masonj    .
10:06 masonj    so im guessing that my zeb isnt doing the mapping correctly, as i would expect to see it also search for 'moutons' in that query
10:07 masonj    but i need someone else to confirm that
10:07 masonj    no, i havent edited any of the zeb config files yet
10:09 masonj    i looked about in the zebra-config dirs - to see if there was something i needed to update
10:09 masonj    but i couldnt find anything
10:10 masonj    looking at the default.idx, what would i need to change in there??
10:13 chris     the charmap bits presumably
10:14 chris     # Sort register
10:14 chris     sort s
10:14 chris     completeness 1
10:14 chris     charmap sort-string-utf.chr
10:14 masonj    sure
10:15 masonj    the only import thing i could find was the profilePath value in  ./zebra-biblios.cfg
10:15 chris     i think what default.idx is doing there is using it for the sort
10:15 chris     which isnt what you want it to do is it?
10:16 masonj    :/home/mason/koha/af-rc1/etc/zebradb/lang_defs/fr
10:16 masonj    the profilePath points to either the 'fr' or 'en' dir, to determine which 'sort-string-utf.chr' file to use
10:17 chris     yep, but how do you tell it to use it for substitution, not just sorting?
10:18 masonj    aaah, click...
10:19 chris     
10:20 masonj    yeah, i think youre right there chris
10:20 chris     im just guessing
10:20 chris     but it seems plausible :)
10:23 masonj    so it looks like 'word-phrase-utf.chr' is the real magical file for doing the subst.
10:24 masonj    it has a similar contents to 'sort-string-utf.chr', i thought it may have been a legacy file
10:25 chris     right
10:26 chris     the sort i think is just for sorting
10:26 chris     so that they order correctly
10:26 masonj    ... as all of the mapping stuff in it was commented out
10:26 masonj    yeah, i got it now ;)
10:26 chris     so whatever is doing the :w or :p
10:26 chris     is the one that u need for the search
10:27 chris     so i guess we need an fr one of those?
10:27 chris     or we try changin
10:28 chris     charmap word-phrase-utf.chr
10:28 chris     to the sort-string one
10:28 chris     but now i must sleep
10:29 masonj    ok hunny