You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

after hunting down and fixing the last batch (there were about 1,600 of them) of broken call numbers (they weren't really broken but they were wrong) which included either vol., no., pt., or ser. but not the all important |z it was time to continue going thru the list of instance fields for which MARC parsing code had not yet been written

it wan't long before I came upon instances.languages - I went into the sandbox to edit an instance and found that adding a language required me to select a language, not a code, from a very long select box - so I looked in Settings to find the list of languages and codes (which I expected would jive with the MARC Code List for Languages) and couldn't find it - when I looked at the JSON document for the instance that I had just edited what I found was the code, not the language - so how does FOLIO know?

my next thought was that it might be like contributorNameTypes which is a db table that API knows about but Settings does not - couldn't find anything in the list of APIs that looked like it would give me a clue re languages

my next thought was that this might be included in the "reference data" which I asked EBSCO not to load - the answer to that question could be answered by running the bibLoad.pl script against the production server

so I did that and the script threw an error because the contributorNameTypes and indentifierTypes that I loaded in production are slightly different than those that are in the sandbox

so I updated my bibLoad.pl script so that it would not throw those errors and realized that now I have to test the rest of those "types" - here's a checklist to help me keep track:

and, by the way, it turns out that the production server knows about the languages and their codes which is a very good thing but I still don't know where they are hiding - it doesn't really matter but I am very curious!



  • No labels