Time Nick Message 20:24 slef oops 20:24 slef <link rel="alternate" type="application/rdf+xml" title="slef-reflection in RSS 1.0"><xsl:attribute name="href"><xsl:value-of select="/rdf:RDF/rss:channel/@rdf:about" /></xsl:attribute></link> 17:31 chris I dont really mind who wins, as long as they play well 17:31 chris my wife does, she lived there for 6 months 17:28 slef chris: hehe... you don't want Italy to win? 16:48 chris ohh thats pretty cool 16:47 chris ill go look now 16:46 kados chris: check out the proof of concept faceted search results on zoomopac when you get a chance 16:46 kados hehe 14:13 kados :-) 14:13 thd kados: thanks, i will refer tumer to More Fun as the possible solution to his manifestation of the problem. 14:07 kados all is explained there 14:07 kados http://www.mail-archive.com/perl4lib@perl.org/msg01006.html 14:07 kados emails 14:07 kados best refer to my email on perl4lib 14:07 kados it's complicated 14:06 kados well ... 14:06 thd kados: The problem was that MARC::File::XML had made some silly change and you had to update XML::SAX or what was it that needed updating? 14:04 thd and for tumer 14:04 kados yes 14:04 thd kados: could that have been the problem for Afognak? 14:03 kados yes, because I had the wrong parser installed 14:03 thd kados: was MARC::File:XML doing double encoding at one time? 14:02 thd kados: I do not think that MySQL would do this no matter what the MySQL encoding was set to it would only keep you from finding the records 14:01 thd kados: maybe it was careless kittens on the keyboard or path name priority 14:00 kados right 13:59 thd kados: Yet I almost completely replaced the import script that you supplied with good code which I later committed 13:58 kados but by the time I did wipo's current installation, I had perfected it (mostly :-)) 13:58 kados and how to manipulate it in perl 13:58 kados also, I believe when I did afognak, i did not fully understand encoding 13:58 kados but the tables are set to utf8 13:57 kados no 13:57 thd kados: are the WIPO records being stored in Zebra? 13:56 thd kados: yes, I do not see anything worse than the font problem which cannot be seen on MS Windows according to tumer 13:50 thd \ 13:50 thd kados: tumer did have a problem with the record editor not clearing $9 for adding or changing an authorised heading to a bibliographic record but you would have to ask him the details which he had been discussing with hdl to know the problem more clearly 13:50 kados thd: they have lots of accented chars that are just fine 13:49 kados thd: take wipo for example 13:49 kados thd: http://wipoopac.liblime.com 13:48 kados I don't think it happens elsewhere 13:47 thd kados: if you have not seen this occurring elsewhere then we have to ask tumer for how he can repeat it reliably 13:46 thd kados: this affects all the accented characters that I had noticed on Afognak but I had presumed the font problem for displaying in UTF-8 was the factor 13:44 thd kados: the odd thing is that tumer has reported the same problem 13:43 thd kados: that only is an issue for indexing and not for the actual string of byte content stored 13:41 kados my new installs do, but that one may be a layover 13:41 thd kados: if I remember our discussion at the time well you had used it 13:41 kados it's possible my mysql for that install isn't set up to have utf8 tables 13:41 kados I can't remember now 13:41 kados I think I used it 13:40 thd s/mark/marc/ 13:40 thd kados: If you had used the bulkmarkimport.pl script which I supplied and told you to use you we should have had identical import processing between my system and Afognak 13:38 thd kados: on my X-windows system the fonts do not display correctly for the result set but they do display correctly for the individual record 13:37 thd kados: tumer said he had a record with the same author in his system with the same double encoding problem 13:35 kados before I blamed Koha 13:35 kados or in my pre-processing script 13:34 kados but I would suspect that I ruined encoding on import 13:34 thd one moment 13:34 thd kados: That is the worrying thing but you can see the same record on my own system 13:33 kados thd: when you attempt to edit it, you'll see that 13:33 kados thd: the encoding problem is in the record itself 13:33 thd kados: I never touched that record to my knowledge 13:32 kados thd: have you tried manually editing that record? 13:31 kados Valerie 13:31 kados ahh, I see it now 13:31 kados where is the problem there? 13:31 kados ok 13:31 thd kados: http://library.afognak.org/cgi-bin/koha/opac-detail.pl?bib=154 13:30 thd I am finding the example that I showed tumer 13:29 kados thd: show me 13:29 thd kados: well something strange is happening 13:29 kados but not for afognak 13:29 kados on that server, yes 13:28 thd kados: but do you not have Zebra configured for storage there? 13:28 kados thd: that's a rel_2_2 system 13:28 kados thd: no 13:27 thd kados: Are the Afognak records in Zebra for the server that I am using? 13:27 thd kados: tumer's conclusion is that Zebra or Koha Zebra and not SQL Koha is the problem 13:25 kados what was your conclusion? 13:23 thd kados: before my test I considered it likely that I and not Koha was responsible 13:22 thd kados: i spent all night the night before last only because my system s too slow and not enough RAM confirming that nothing that I had done had introduced this double encoding problem 13:21 kados thd: hi there 12:56 thd kados: are you there?