← Previous day | Today | Next day → | Search | Index
All times shown according to UTC.
| Time | Nick | Message |
|---|---|---|
| 12:05 | MrDys | *yawn* |
| 12:05 | guten morgen | |
| 12:05 | it looks like the first bugs I'm going to go after are the osx related ones...since that's my platform | |
| 12:05 | kados | are there OSX related ones? |
| 12:06 | maybe only by accident :-) | |
| 12:06 | MrDys | I was reading in the install that there's no z39 support and that |
| 12:06 | kados | ahh |
| 12:06 | that should be fixed now | |
| 12:06 | with the new Net::Z3950::ZOOM module | |
| 12:07 | need to update the docs | |
| 12:07 | MrDys | ah fantastic |
| 12:07 | kados | so you could test it out :-) |
| 12:07 | see if it works :-) | |
| 12:07 | then update the docs :-) | |
| 12:08 | MrDys | hehe I will after my uke lesson |
| 13:04 | owen | kados: still there? |
| 13:04 | dewey | it has been said that there is a minor diff in <div>s, that I missed |
| 13:04 | kados | owen: yep |
| 13:04 | I've updated the bug list | |
| 13:04 | so it's readable | |
| 13:04 | http://wiki.liblime.com/doku.php?id=koha226bugs | |
| 13:04 | hehe | |
| 13:05 | and linked each item to a bug in bugzilla | |
| 13:05 | for reference | |
| 13:06 | owen: so what's up? | |
| 13:07 | damaged => don't show up in OPAC, can't reserve, can't issue | |
| 13:07 | owen | What did you have in mind when you brought up HLT's transfer/transit process? |
| 13:07 | kados | well ... |
| 13:07 | don't they do something funky with branches? | |
| 13:07 | you wrote up something about what NPL needed for transfers | |
| 13:07 | owen | yeah, they use branches like we would use statuses (like 'damaged') |
| 13:09 | kados | hmmm |
| 13:09 | owen | That's why they use Transfers extensively |
| 13:10 | kados | I see |
| 13:10 | well ... | |
| 13:10 | what if NPL used branches and branch categories | |
| 13:10 | so you have two categories: | |
| 13:10 | normal | |
| 13:10 | transfers | |
| 13:10 | branches in transfers are: | |
| 13:10 | APL to NPL | |
| 13:10 | NPL to APL | |
| 13:11 | etc. | |
| 13:11 | woudln't that work? | |
| 13:11 | those would be in transit branches | |
| 13:11 | or ... | |
| 13:11 | a generic in transit branch | |
| 13:11 | to make things really simple | |
| 13:13 | owen | To be honest, I think the only way folks are going to be happy is if Koha does /everything/ for them, just like Spydus does. |
| 13:13 | Meaning, if you check an Athens book in in Nelsonville, it's automatically made 'in transit from NPL to APL' | |
| 13:14 | kados | but |
| 13:14 | owen | I don't think staff would be happy with a solution that required them to re-scan stuff |
| 13:14 | kados | what about when you're in athen, and you check in a book on reserve in NPL? |
| 13:14 | owen | Then it should automatically be made 'in transet from APL to NPL' |
| 13:15 | kados | well IMO that's mainly interface |
| 13:15 | I think if we use 'in transit branches' we can acomplish what they want | |
| 13:15 | we'd need to add a button to returns | |
| 13:15 | when there's a reservation | |
| 13:16 | they could click 'make in transit to NPL' | |
| 13:16 | same thing when the holding branch isn't the same as the current branch | |
| 13:17 | heh | |
| 13:17 | why? | |
| 13:18 | are there other cases to consider? | |
| 13:19 | heh ... you could also search by in transit that way | |
| 13:20 | owen | Well, that's one problem with using Branches for something other than real branches: It messes up every interface where you get a branch choice. |
| 13:21 | So when the patron is trying to find their branch to reserve a book, they've got a bunch of 'junk' branches to sift through. | |
| 13:21 | kados | I thought there were certain hard-coded branch categories that didn't show up |
| 13:21 | if not, there should be | |
| 13:23 | owen | I said I was skeptical because I think any solution that involves extra scanning or extra clicking will not go over well with the staff. And from my point of view there's no reason /not/ to have the system behave as I describe. But that's because that's the way /I/ expect it to work best. |
| 13:23 | kados | well ... we could make it happen behind the scene |
| 13:23 | s | |
| 13:23 | wouldn't need to click anywhere | |
| 13:26 | I'll ask chris when he's up what he thinks | |
| 13:28 | hold the phone | |
| 13:29 | why can't we just use the 'binding' status in items? | |
| 13:31 | owen | ? |
| 13:31 | kados | for damaged items |
| 14:04 | owen-away: new bug in the Intranet found | |
| 14:04 | owen-away: submitted as 1115 | |
| 16:11 | :( | |
| 16:12 | tumer[A] | kados: it just says not available |
| 16:12 | kados | yea, that's just silly :-) |
| 16:13 | tumer[A] | well some people still want to see the bibliographic record |
| 16:13 | kados | yea |
| 16:13 | but some don't :-) | |
| 16:13 | so we have a syspref | |
| 16:14 | tumer[A] | a use selectable pref better |
| 16:14 | kados | s/have/should have/ |
| 16:14 | true | |
| 16:14 | tumer[A] | s/use/user |
| 16:14 | i mean in opac | |
| 16:34 | kados | yep |
| 16:34 | I agree | |
| 16:35 | today | |
| 16:35 | great | |
| 16:35 | how's it going? | |
| 16:35 | are you looking at rel_2_2 way? | |
| 16:36 | tumer[A] | yep |
| 16:36 | kados | what are you having trouble with? |
| 16:36 | tumer[A] | cloning a subfield messes the way authorities work |
| 16:36 | kados | ahh |
| 16:37 | tumer[A] | i have to understand this java |
| 16:37 | kados | this is why we need one MARC framework :-) |
| 16:37 | and one MARC editor :-) | |
| 16:37 | chris | wont happen :) |
| 16:37 | tumer[A] | the index numbers seem to change if you clone subfields |
| 16:37 | chris | but one editor per framework could |
| 16:38 | tumer[A] | i am talking about the MARC editor not authorities editor |
| 16:38 | in marc edtor we fill authors from authorities table | |
| 16:39 | uneditable fields you see | |
| 16:39 | chris | yeah the marc editor as it current stands with its reliance on javascript is exceeeedingly fragile |
| 16:39 | tumer[A] | its not set up for you so you dont probably see it |
| 16:39 | just like value builder but more complex | |
| 16:39 | chris | right |
| 16:40 | tumer[A] | has to fill all subfields |
| 16:40 | why im i tumer[A] ?? | |
| 16:40 | chris | :-) |
| 16:41 | because of the way the form is built, adding subfields throws things off .. even with the value builder | |
| 16:41 | tumer | on the other hand cloning subfileds is very handy |
| 16:42 | chris | yep |
| 16:42 | i wonder how far the opencataloger project got with the XUL based marc editor | |
| 16:43 | tumer | i never saw that just rumors about it |
| 16:43 | chris | i must ask antoine |
| 16:43 | tumer | has anybody thought of ISIS marc editor whether it can be implemented in koha |
| 16:44 | its very advanced editor | |
| 16:44 | even with online help for each field/subfield | |
| 16:44 | chris | ill have to take a look |
| 17:11 | well since its the first day in the while i can see the sun (we've been having a lot of rain here lately) | |
| 17:12 | i might go outside :) | |
| 17:31 | kados | tumer[A]: so a quick question if you're around |
| 17:31 | tumer[A]: am I correct that in dev_week, the only thing that is different is: | |
| 17:32 | some routines in .pm files | |
| 17:32 | searching with zoomsearch.pl (that I wrote) | |
| 17:32 | ? | |
| 17:32 | tumer[A] | i thinkk yes |
| 17:33 | also circulation is a bit diff | |
| 17:34 | dev_week when i uploaded my files may not have all the new stuff like branch specific aditing and issuing etc. | |
| 17:40 | kados | k |
| 17:40 | also ... | |
| 17:41 | I've got a library that already has Koha | |
| 17:41 | they are migrating to dev_week | |
| 17:41 | I dump out the records in MARC21 | |
| 17:41 | then run them through a pre-process routine to fix them up | |
| 17:41 | then I import them into zebra with zebraidx | |
| 17:41 | but now I have a problem | |
| 17:42 | tumer[A] | but records will be in iso8759 |
| 17:42 | kados | because when I run biblio_framework.sql |
| 17:42 | the MARC will be different than what's in zebra | |
| 17:42 | (ones in sql will be 8859 encoded, in zebra they will be utf-8) | |
| 17:42 | (in sql, may be missing 090, in zebra they won't) | |
| 17:42 | (etc.) | |
| 17:43 | so I need a routine to add them back to Koha's sql | |
| 17:43 | quickly | |
| 17:43 | tumer[A] | why run biblio_framework?? |
| 17:43 | keep their own framework | |
| 17:44 | do not change their marc structure change zebra record.abs to matzch that | |
| 17:44 | kados | don't I need to move the MARC to the biblioitems table? |
| 17:44 | I have to change the MARC | |
| 17:44 | for instance, the records don't have leaders | |
| 17:44 | because the original version of Koha that 'supported MARC' deleted leaders! | |
| 17:44 | tumer[A] | yes you do and when you do marc will be in their structure |
| 17:45 | kados | will MARCgetbiblio pull from Zebra? |
| 17:45 | tumer[A] | no |
| 17:46 | kados | grrr |
| 17:46 | tumer[A] | when you are uilding and converting these marcs they will automatically have leaders |
| 17:46 | kados | ok ... let me be clear |
| 17:46 | tumer[A] | i now have ZEBRAgetbiblio |
| 17:46 | kados | 1. I run updatedatabase from rel_2_2 |
| 17:46 | 2. I export MARC records | |
| 17:47 | 3. I run a script on the MARC that fixes several things (like adding proper leaders, but also other things, like 007 and 008) | |
| 17:47 | 4. I import those fixed records into Zebra | |
| 17:47 | now I have a problem | |
| 17:47 | because the MARC in Koha is different than the MARC in zebra | |
| 17:48 | so I need a ZEBRAgetbiblio I think | |
| 17:48 | can you commit it to dev_week please? | |
| 17:48 | I think that would solve my problem | |
| 17:48 | tumer[A] | why is it different apart from 007 and 008 which old koha does not use anyway |
| 17:48 | kados | it is very different in many ways |
| 17:49 | and since dev_week still pulls from the koha tables for display | |
| 17:49 | even for MARC display | |
| 17:49 | tumer[A] | by the way you reimport these marx into biblioitems so your matcs will be exactly the same |
| 17:49 | kados | it is important that the two MARC need to be in sync |
| 17:49 | ?? | |
| 17:49 | tumer[A] | you missed one step |
| 17:49 | kados | what step? |
| 17:50 | tumer[A] | 5. import marcs into biblioitems |
| 17:50 | kados | ok ... to do that I need a ZEBRAgetbiblio, right? |
| 17:50 | in move_marc_to_biblioitems.pl | |
| 17:51 | tumer[A] | no you build these marc somewhere wherverev you processed that |
| 17:51 | kados | it calls MARCgetbiblio( $dbh, $bibid ); |
| 17:51 | and MARCgetbiblio, you said, does not use Zebra | |
| 17:51 | so it will get obsolete data | |
| 17:51 | tumer[A] | ok |
| 17:51 | kados | right? |
| 17:51 | tumer[A] | maybe you have some scripts missing i'look |
| 17:52 | once you build these marcs in biblioitems export them out | |
| 17:52 | process them outside utf8 007 etc | |
| 17:53 | then i have import_ into_ biblioitems which just reads an external fiel | |
| 17:53 | file i mean dont you have that | |
| 17:54 | well i need a beer | |
| 17:54 | kados | :-) |
| 17:54 | me too :-) | |
| 17:54 | tumer[A] | i 2 check and commit it to dev week |
| 17:54 | kados | thanks |
| 17:55 | tumer[A] | that way the records that you will be indexing with zebra will be identical |
| 17:58 | kados | great! |
| 17:59 | tumer[A]: does rebuild_non_marc work in dev_week? | |
| 17:59 | guess it should as long as the API is unchanged | |
| 18:00 | because if it does, it might be best to: | |
| 18:00 | 1. export MARC | |
| 18:00 | 2. pre-process to fix everything that's wrong | |
| 18:00 | 3. import_into_biblioitems on a _brand new database_ | |
| 18:00 | 4. run rebuild_non_marc | |
| 18:00 | to populate koha tables | |
| 18:01 | then ... import the rest of the data separately | |
| 18:01 | issues, borowers, etc. | |
| 18:01 | sweet | |
| 18:08 | tumer[A]: having problems committing? | |
| 18:08 | tumer[A] | kados:rebuild_non_marc should work |
| 18:08 | i have committed | |
| 18:09 | as long as its using MARCgetbiblio it should be ok | |
| 18:09 | kados | thanks |
| 18:10 | :-) | |
| 18:11 | tumer[A] | why are you thinking of importing into blank database? |
| 18:11 | kados | well ... especially for NPL |
| 18:12 | historically, NPL was the first large library to go live with Koha | |
| 18:12 | that was version 1.9 something | |
| 18:12 | and the db has changed considerably since then | |
| 18:12 | their db is a hybrid | |
| 18:12 | updatedatabase doesn't fix it | |
| 18:12 | so it would be easier to just import everything into a new db | |
| 18:12 | separately | |
| 18:13 | have a new MARC framework, etc. | |
| 18:13 | tumer[A] | very dangerous |
| 18:13 | kados | why? |
| 18:13 | tumer[A] | if itemnumbers change issues is a mess hapðpened to me |
| 18:14 | issues and itemnumbers are all in sync. | |
| 18:15 | if you are importing into a new database and not veeeery careful deb will produce new item numbers | |
| 18:15 | kados | right |
| 18:15 | shouldn't itemnumbers be the same? | |
| 18:15 | with importtobiblioitems.pl? | |
| 18:16 | tumer[A] | when you use that biblionumbers are preserved. Itemnumbers are in the marc record. |
| 18:17 | But if you use Non_marc you have to make sure that its actually reading things correctly and not producing new numbers | |
| 18:19 | on an empty database you cannot update itemnumbers to be the same | |
| 18:19 | they have to be there to be updated | |
| 18:20 | otherwise you will generate new numbers or lots of DBI errors | |
| 18:20 | kados | hmmm |
| 18:21 | tumer[A] | on an update similar to that it took me a week to resync issues and items using there barcodes cause itemnumbers was changed |
| 18:22 | well i know you have backups so good luck | |
| 18:23 | kados | here is my plan: |
| 18:23 | assuming oldkoha.xml has old db listed and koha.xml has new one: | |
| 18:23 | export KOHA_CONF = /koha/etc/oldkoha.xml | |
| 18:23 | perl -I /koha/cvsrepos/dev_week/koha export.pl oldkoha.mrc # MARC records using special npl-specific export routine | |
| 18:23 | export KOHA_CONF = /koha/etc/koha.xml | |
| 18:23 | perl -I /koha/cvsrepos/dev_week/koha pre-process-mrc.pl oldkoha.mrc /koha/zebradb/records/newkoha.utf8.iso2709 # on new MARC records | |
| 18:23 | perl -I /koha/cvsrepos/dev_week/koha import_into_biblioitems.pl /koha/zebradb/records/newkoha.utf8.iso2709 # to import the repaired records into biblioitems.marc | |
| 18:23 | zebraidx -g iso2709 -c /koha/etc/zebra-biblios.cfg -d kohaplugin update /koha/zebradb/records | |
| 18:24 | perl -I /koha/cvsrepos/dev_week/koha rebuildnonmarc.pl | |
| 18:25 | the new koha db (was blank before) should have everything now | |
| 18:25 | tumer[A]: right? | |
| 18:25 | tumer[A] | the last line worries me i'll check |
| 18:27 | 1.rebuildnonmarc will not work it calls marc_biblio and bibid which does not exist | |
| 18:29 | kados | damn |
| 18:29 | we need to fix it | |
| 18:29 | tumer[A] | 2.It calls for NEWmoditems which say update items where itemnumber=itemnumber |
| 18:29 | ie you have to have a populated database | |
| 18:30 | kados | grrr |
| 18:31 | and I assume bulkmarcimport won't either | |
| 18:31 | Burgundavia | hey kados |
| 18:31 | kados | it will ignore itemnumber and biblionumber and create it's own I think |
| 18:31 | Burgundavia: hey there | |
| 18:32 | Burgundavia | who is responsible for the OPAC/Intranet web interface? |
| 18:32 | tumer[A] | kados:if it does that than you re going to be in big trouble |
| 18:32 | kados | Burgundavia: everyone :-) |
| 18:32 | Burgundavia | ah |
| 18:32 | kados | Burgundavia: you are in fact :-) |
| 18:32 | Burgundavia | ouch, and I just joined |
| 18:32 | kados | hehe |
| 18:33 | tumer[A]: can we get around it somehow? | |
| 18:33 | Burgundavia | I have been kicking around ideas about the OPAC interface since we talked at ALA |
| 18:33 | kados | tumer[A]: it would really be ideal |
| 18:33 | Burgundavia: cool | |
| 18:34 | tumer: maybe we can edit rebuildnonmarc to not require existing items if they don't exist but to create them | |
| 18:34 | tumer: what do you think? | |
| 18:34 | Burgundavia: remind me, who are you? :-) | |
| 18:34 | tumer | the only way is to use proprietary NEWmoditem |
| 18:34 | Burgundavia | Corey Burger, Userful |
| 18:34 | kados | right |
| 18:35 | tumer: by proprietary, you mean the one in dev-week? | |
| 18:35 | tumer | no we have to write one for this and not use Biblio.pm |
| 18:36 | kados | tumer: my rebuildnonmarc uses 'localNEWmoditem' |
| 18:36 | tumer: not one in Biblio.pm | |
| 18:36 | tumer: (in dev-week) | |
| 18:36 | tumer | aha |
| 18:37 | kados | well ... still it uses Biblio in the end :-) |
| 18:37 | C4::Biblio::OLDmoditem( $dbh, $olditem ); | |
| 18:37 | tumer | still uses Biblio oldmoditem |
| 18:37 | kados | so we need a localOLDmoditem and local NEWmoditem :-) |
| 18:37 | tumer | which is the actual db sql script |
| 18:38 | kados | hmmm ... why won't OLDmoditem work? |
| 18:38 | tumer | thats where it says "update.. items" |
| 18:38 | kados | my $query = "update items set barcode=?,itemnotes=?,itemcallnumber=?,notforloan=?,location=?,multivolumepart=?,multivolume=?,stack=?,wthdrawn=?,holdingbranch=?,homebranch=?,cutterextra=?, onloan=?"; |
| 18:39 | does't say 'where itemnumber=?' | |
| 18:39 | tumer | it should say "insert .. " |
| 18:39 | kados | ahh ... itemnumber is autogenereated I bet |
| 18:39 | tumer | no its not autogenerated |
| 18:40 | kados | | itemnumber | int(11) | | PRI | 0 | | |
| 18:40 | tumer | you cannot use update on a blank database |
| 18:40 | kados | of course |
| 18:41 | tumer | if you look the bottom of that script it says where itemnumber=? |
| 18:41 | kados | tumer: I think we could use a single sql query |
| 18:41 | tumer: directly in the rebuildnonmarc.pl script | |
| 18:41 | tumer | yes can be so |
| 18:42 | kados | Burgundavia: well you can see the two generations of OPACs in Koha: |
| 18:42 | http://opac.liblime.com | |
| 18:42 | http://zoomopac.liblime.com | |
| 18:42 | Burgundavia: the second being the one we're almost done with (but still quite a bit of interface cleaning to do) | |
| 18:44 | tumer: does MARCfind_frameworkcode rely on koha tables or zebra? | |
| 18:44 | tumer | kados: if these people never mapped those fields to MARC they will all be blank |
| 18:45 | frameworkcode only exists in SQL | |
| 18:46 | kados | uses bibio |
| 18:46 | that should be mapped to MARC | |
| 18:46 | poor design | |
| 18:46 | well ... it looks like my upgrade path for this lib is dashed | |
| 18:46 | :( | |
| 18:47 | well I can assume default framework actually | |
| 18:47 | and make sure the framework is well defined | |
| 18:47 | tumer | do they have many frameworks? |
| 18:47 | kados | no just one :-) |
| 18:47 | which is why this is simple :-) | |
| 18:47 | tumer | wouldn't default suffice |
| 18:47 | kados | yep |
| 18:47 | perfect | |
| 18:47 | so now I just need a custom rebuildnonmarc.pl script | |
| 18:48 | that directly inserts into items | |
| 18:48 | and uses default framework | |
| 18:48 | tumer | and all other atbles as well |
| 18:48 | biblio, authors etc | |
| 18:49 | kados | yea |
| 18:49 | tumer | infact you need a new importintobiblioitems.pl as well |
| 18:49 | kados | hehe |
| 18:49 | my $sth = $dbh->prepare("select bibid from marc_biblio"); | |
| 18:49 | that line kills my idea :-) | |
| 18:49 | tumer | you need a whole new set of scrippts |
| 18:50 | kados | is there an equivilent in Zebra? |
| 18:50 | tumer | not fiiling a blank db no. koha3 will have |
| 18:51 | kados | well ... |
| 18:51 | bulkmarcimport.pl works | |
| 18:51 | but it won't help because we've got issues data, etc. | |
| 18:51 | shoot | |
| 18:51 | I need a beer | |
| 18:52 | tumer | no it does not do what you want. Creates new biblionumbers and itemnumbers as far i remember |
| 18:53 | it would ptobably be easier to write an upgrade script for the existing datavbase | |
| 18:53 | just add missing fields | |
| 18:53 | kados | hmmm |
| 18:53 | tumer | convert the db to utf8 andd the 5 steaps you hav |
| 18:53 | kados | but then we rely on the old db |
| 18:53 | for things like biblionumber :-) | |
| 18:54 | tumer | no |
| 18:54 | your 5 steps ensures that biblionmbers exist | |
| 18:54 | also you can run rebuildnonmarc on taht | |
| 18:55 | and that ensures data is synced | |
| 18:56 | so before your 5 steps you just update the database to have missing fields thats all | |
| 18:56 | do not delete anything | |
| 18:58 | kados | tumer: when do I run convert_to_utf8.pl? |
| 18:59 | tumer | after adding missing fields before exporting maRC |
| 18:59 | kados | hmmm ... not sure about before exporting MARC |
| 18:59 | because I handle the transformation in my preprocess script | |
| 19:00 | convert_to_utf8 doesn't update the leader | |
| 19:00 | tumer | k i dont know about convert_to_utf8 |
| 19:01 | i couldnt se it | |
| 19:01 | how does your preprocess convert from iso to utf8? | |
| 19:02 | if they are al ascii no problem though | |
| 19:03 | kados | it uses MARC::File::XML |
| 19:03 | some are not ascii | |
| 19:03 | in fact, I expect many problems with charsets | |
| 19:04 | so that's OK | |
| 19:04 | tumer | marcxml does not convert from iso8859 to utf8 |
| 19:04 | kados | true |
| 19:04 | tumer | mysql will |
| 19:04 | kados | I think these are actually in marc8 |
| 19:04 | I'm not sure if mysqldump can even export them as marc8 | |
| 19:04 | i will do some tests | |
| 19:05 | but I'm not that concerned about the encoding | |
| 19:05 | most of this is ascii stuff | |
| 19:05 | tumer | it can |
| 19:05 | kados | how? |
| 19:05 | tumer | i have breeding in marc8 biblio in utf8 |
| 19:05 | well if they are already marc8 i mean otherwise no | |
| 19:06 | kados | they are in the db as marc8 |
| 19:06 | but I think if I export them with mysqldump they are corrupted :-) | |
| 19:06 | the nonascii ones at least | |
| 19:06 | tumer | in old koha only breeding is marc8 |
| 19:07 | it is not possible for them to be marc8 anywhere else | |
| 19:08 | kados | ahh |
| 19:08 | right | |
| 19:08 | tumer | because there is no marc objec t anywhere in old koha |
| 19:08 | kados | right |
| 19:08 | tumer | just lots of parsed text |
| 19:09 | so encoding wise if its a problem est to convert to utf8 first | |
| 19:10 | but change your process to now that it should only change the leader when making marc | |
| 19:10 | dewey | tumer: that doesn't look right |
| 19:10 | tumer | kados:we are having problems of definition i think |
| 19:10 | kados | perhaps |
| 19:11 | tumer | marchtml2marc can be tweeked to get utf8 data out with correct utf8 header |
| 19:12 | thats the routine that builds your marc | |
| 19:12 | kados | !! |
| 19:12 | only in the old editor I hope | |
| 19:12 | that routine is really bugy | |
| 19:13 | tumer | but whatever the data coming from it alwyas adds a marc8 header |
| 19:13 | kados | well ... |
| 19:13 | in a new rel_2_2 install | |
| 19:13 | if you import as utf8 | |
| 19:14 | it always comes out with a utf8 header | |
| 19:14 | leader even | |
| 19:14 | tumer | i am talking about upgrading the old koha |
| 19:14 | kados | ahh |
| 19:14 | tumer | when you get marc out of it how is it build |
| 19:14 | kados | using export.pl |
| 19:15 | so with a marc8 leader (but leaders have all been destroyed :-)) | |
| 19:17 | tumer | i do not have that old export.pl so i dont remember how marc is buit from marc_subfield_table |
| 19:17 | kados | there is another complication with encoding to deal with |
| 19:18 | i have set up the server to default to utf8 | |
| 19:18 | but the old db is set to latin1 | |
| 19:18 | in mysql, 'show variables;' yields: | |
| 19:18 | | character_set_database | latin1 | | |
| 19:19 | | collation_database | latin1_swedish_ci | | |
| 19:19 | and I don't think our convert_to_utf8.pl script will do the trick there | |
| 19:21 | tumer | you will need to tell tell that "character_set_client=latin1" character_set_results=utf8 and so ano and so |
| 19:21 | kados | yea |
| 19:22 | tumer | i have to get back to the authorities problem.Ping me if you nedd help |
| 19:25 | kados | k, thx |
| 20:35 | Burgundavia | kados: UI suggestions for the zoomopac interface. To you or to koha-devel? |
| 20:43 | kados | Burgundavia: :-) |
| 20:43 | Burgundavia: there are many, I know :-) | |
| 20:43 | Burgundavia: koha-devel is a good place | |
| 20:44 | Burgundavia | ok |
| 20:44 | I could start with the 4 tabs... | |
| 20:44 | kados | :-) |
| 20:46 | Burgundavia | time to load up straining inbox even further |
| 20:52 | kados: is there a design document anywhere for the OPAC interface? | |
| 21:05 | kados | Burgundavia: nope |
| 21:05 | Burgundavia | right, then you are getting one |
| 21:05 | kados | sweet |
← Previous day | Today | Next day → | Search | Index