← Previous day | Today | Next day → | Search | Index
All times shown according to UTC.
Time | Nick | Message |
---|---|---|
14:50 | kados | OK, goodie, now we're making progress |
14:52 | fbcit: how can I reproduce the issue, which bibs is it happening with? | |
14:56 | fbcit | that's the problem |
14:56 | one of my data entry people has the problem now | |
14:57 | the other does not | |
14:57 | grrrr | |
14:57 | kados | weird |
14:57 | they are using Koha's built-in MARC editor with Z39.50? | |
14:57 | 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 | btw: zebraqueue daemon is running and the missing records are begin processed by it, contrary to my previous observation | |
15:02 | but they do not show in a search | |
15:03 | 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 | and add a cron task with rebuild_zebra.pl and the -z option | |
15:03 | for bibs and authorities | |
15:04 | 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 | rhcl: ie, rather than a complete index re-build | |
15:09 | 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 | so i can reproduce it | |
15:09 | fbcit: I think the ebraqueue daemon issues are separate | |
15:09 | 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 | 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 | 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 | does it really matter what the mysql server is at that point? | |
15:13 | kados | yes, it really does |
15:14 | especially important is the encoding of the connection | |
15:14 | maybe not so much the server though ... | |
15:14 | 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 | that record is being pulled from UNC @ Chapel Hill | |
15:19 | afton.lib.unc.edu:210 | |
15:19 | innopac db | |
15:19 | utf8 encoding | |
16:14 | kados | fbcit: hack |
16:14 | back I mean | |
16:14 | 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 | while claiming to be utf8 | |
16:16 | 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 | kados: do a z3950 search on 8476456700 with all servers selected | |
16:20 | kados | k |
16:21 | is that at the chapel hill target? | |
16:21 | fbcit: i wanna test marc8 | |
16:21 | fbcit | no |
16:21 | 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 | fbcit: I changed the chapel hill target to marc-8 and it's working now | |
16:24 | fbcit: if you change it to marc8, Koha will convert it to utf8 for you automagically | |
16:25 | 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 | galen may have time next week to investigate what the specif problem with the III systems' UTF8 is | |
16:27 | 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 | but also 083793950X with the UNC target | |
16:29 | kados | another innopac system |
16:29 | 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 | 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 | at least for me they do | |
16:32 | and checking the sample data, it's in there | |
16:32 | fbcit | hrmm |
16:35 | 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 | 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 | my documentation | |
16:40 | 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 | 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/gi[…]658533d95912b5d6f |
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/gi[…]96cc5ad4fea545a9d |
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 | if ($rec) { | |
16:45 | my $marcrecord; | |
16:45 | $marcdata = $rec->raw(); | |
16:45 | fbcit: oddly, the error is claiming that $rec is undefined | |
16:45 | fbcit: but right above it, we test for that | |
16:46 | 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.kohalibra[…]span%CC%83ola%20/ |
16:49 | that's the error Im getting | |
16:51 | ||
16:51 | [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.kohalibra[…]pl?frameworkcode= | |
16:51 | [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.kohalibra[…]pl?frameworkcode= | |
16:51 | ||
16:51 | fbcit: where are you seeing the other, more useful error? | |
16:52 | fbcit: did you set DEBUG or something? | |
16:53 | fbcit | weird |
16:53 | no on DEBUG | |
16:53 | are you searching on 8423968146 @ UNC? | |
16:54 | 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 | " | |
16:56 | kados | huh |
16:56 | 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 | maybe we have different deubg levels or something | |
16:57 | 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 | interstingly, I get failyure with default settings in yaz-client for both cattnyp and unc | |
16:58 | f @attr 1=7 083793950X | |
16:58 | 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 | 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 | my $marcrecord; | |
17:00 | $marcdata = $rec->raw(); | |
17:00 | that might explain it | |
17:01 | kados | but I still get an error |
17:01 | 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 | the bib-1 error is somewhat telling | |
17:01 | 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 | any ISBN queries in particular? | |
17:02 | and if we try to find the same records via another mechanism does it fail? | |
17:04 | fbcit | bak |
17:04 | back even | |
17:05 | kados: it does not appear that any isbn searches work against those targets via z3960_search.pl | |
17:05 | kados | yea |
17:05 | I'm trying 'Who's Who in the Media and Communications 1998-9' | |
17:05 | as title now | |
17:05 | nothing found | |
17:05 | 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 | fbcit: http://irspy.indexdata.com/fin[…]_count=10&_skip=0 | |
17:09 | http://irspy.indexdata.com/raw[…]g%3A210%2FINNOPAC | |
17:10 | fbcit | cool |
17:12 | kados | oh, you're kidding me ... |
17:12 | 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 | fbcit: can we be blamed for conforming to the standard ? | |
17:14 | 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 | but we're blamed for following the standard | |
17:14 | arrrg | |
17:15 | fbcit: this is great: | |
17:15 | f @attr 1=1016 "Who's Who in the Media and Communications 1998-99" | |
17:15 | Sent searchRequest. | |
17:15 | Received SearchResponse. | |
17:15 | Search was a bloomin' failure. | |
17:15 | Number of hits: 0, setno 1 | |
17:15 | Result Set Status: none | |
17:15 | records returned: 1 | |
17:15 | Diagnostic message(s) from database: [100] Unspecified error -- v2 addinfo 'Search taking too much time. Server is disconnected.' | |
17:16 | so basically, I try a 1=1016 (actually keyword, but apparantly title in III), and it can't respond fast enough | |
17:16 | 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 | yea | |
17:17 | 5-lb-spiders-- | |
17:17 | 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 | this would be better handle with pazpar2 | |
17:20 | you can pass info about each target config separately before doing the federated search | |
17:20 | fbcit: I'm afraid this won't be fixed for 3.0 | |
17:20 | 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 | ccatalfo: around? | |
17:21 | ccatalfo | sure am |
17:22 | smth about using pazpar2 with different bib attributes per target? | |
17:23 | kados | ccatalfo: yea |
17:23 | ccatalfo: something to bear in mind for biblios | |
17:23 | 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 | 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 | oh, cool | |
17:24 | 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 | should be pretty swank actually | |
17:25 | 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 | fbcit: it appears from furthe tests that the actual connections to innopac are failing for isbn searches | |
17:50 | fbcit: I'm adding some user errors to make it clear where the problem is | |
17:50 | 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 | 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 | I used the command 'git send-email filename' | |
18:20 | Is there something else I need to do? | |
18:21 | kados | you may need to properly configure your outgling mail server |
18:21 | exim perhaps? | |
18:21 | or postfix? | |
18:22 | Kyle | From what I'm reading, it sounds like I can just send them to patcheskoha.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 | kados, who is the moderator for the patches@ list, anyway? | |
18:29 | Kyle, they'll get held up for moderation before they make it to that list if you're not subscribed. | |
18:30 | 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 | Kyle: gmail will definitely goof up the attachments | |
18:31 | 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 | acmoore: *nod* | |
18:38 | wow, you gotta love III, their errors always come back as "No error" | |
18:38 | brilliant! | |
18:39 | sawariwap | any tentative date for the final release? |
18:40 | kados | sawariwap: today, tomorrow? |
18:41 | this week for certain | |
18:44 | sawariwap | oh ok |
18:44 | cool | |
18:44 | :) | |
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/koh[…]lio.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 | I'm presuming I'm using it wrong, although I'm using it just like other calls. | |
20:41 | 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 | improved: C4::Output::pagination_bar builds an HTML pagination bar with no | |
20:49 | language dependency. This function hugely simplifies templates and offers a | |
20:49 | standard pagination method. This function also improves preformances. | |
20:49 | apparently its awesome :-) | |
20:50 | paul | was written a few weeks before pierrick leaved Ineo-ms... |
20:50 | probably "unfinished" code... | |
20:50 | chris | yep |
20:50 | knowing pierrick it would have been great once it was finished | |
20:50 | he's a very smart guy | |
20:51 | you must be on your way to bed paul? | |
20:51 | paul | yep. |
20:51 | although alone those weeks, so I work late ;-) | |
20:51 | chris | ahh :) |
20:51 | paul | mmm... kados... |
20:52 | the patch about Context.pm let a line 252 with "$context", which is useless & result in zillions of warnings in http conf | |
20:52 | I'll submit a patch for that immediatly | |
20:53 | 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 | so, patch for 1980 sent. that's my last blocker. | |
20:59 | Looks like we have 7 remaining. | |
20:59 | chris | nice work |
21:00 | paul | 4 of them being related to serials edition... |
21:01 | mmm... I get 8 in my bugzilla list. | |
21:01 | 3 of them having a "patch sent", and 4 related to serials edit | |
21:02 | the last one being "warn staff about resource hogging scripts" | |
21:03 | ok, time to leave for me. | |
21:03 | have a good day (end of wed of start of thurs...) | |
21:03 | 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 | i wonder if someone with a recent koha3-zeb can confirm something quickly for me.. | |
09:30 | 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 | lemme explain... | |
09:32 | paul | hey... you're right |
09:32 | it doesn't work | |
09:32 | anymore | |
09:32 | masonj | so i can do a search on books, and get 100 results... |
09:32 | and a search on magazines , and get 20 results | |
09:33 | but if i do a search on mags and books, i get 0 results not 120 | |
09:33 | . | |
09:35 | chris | i concur |
09:35 | same for me | |
09:36 | masonj | ok, good to know |
09:38 | 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 | so, the Q is - do you get any interesting output from zebrasrv , when zebrasrv is doing the character substitution? | |
09:41 | im trying to debug it | |
09:42 | 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 | 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 | try "moûtons" | |
09:46 | or "moùtons" | |
09:47 | 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 | is it correctly encoded on your server ? | |
09:48 | (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 | $ file sort-string-utf.chr sort-string-utf.chr: UTF-8 Unicode English text | |
09:56 | oops, missing a \n there | |
09:59 | 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 | 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 | line ? | |
10:06 | or the ' zebrasrv(18) [log] dict_lookup_grep:XXXX lines too? | |
10:06 | the zebrasrv [request] line doesnt seem to be doing the a search for 'moutons' anywhere, just lots of 'moùtons'.. | |
10:06 | 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 | . | |
10:06 | 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 | but i need someone else to confirm that | |
10:07 | no, i havent edited any of the zeb config files yet | |
10:09 | i looked about in the zebra-config dirs - to see if there was something i needed to update | |
10:09 | but i couldnt find anything | |
10:10 | looking at the default.idx, what would i need to change in there?? | |
10:13 | chris | the charmap bits presumably |
10:14 | # Sort register | |
10:14 | sort s | |
10:14 | completeness 1 | |
10:14 | charmap sort-string-utf.chr | |
10:14 | masonj | sure |
10:15 | 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 | 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 | 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 | 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 | 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 | the sort i think is just for sorting | |
10:26 | so that they order correctly | |
10:26 | masonj | ... as all of the mapping stuff in it was commented out |
10:26 | yeah, i got it now ;) | |
10:26 | chris | so whatever is doing the :w or :p |
10:26 | is the one that u need for the search | |
10:27 | so i guess we need an fr one of those? | |
10:27 | or we try changin | |
10:28 | charmap word-phrase-utf.chr | |
10:28 | to the sort-string one | |
10:28 | but now i must sleep | |
10:29 | masonj | ok hunny |
← Previous day | Today | Next day → | Search | Index