http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7345 --- Comment #29 from Jared Camins-Esakov <jcamins@cpbibliography.com> 2012-02-05 20:01:13 UTC --- (In reply to comment #23)
QA Comment: First, looks very good, but still have a few questions:
1) Will a user know that marcstd means marc without private fields (9XX, X9X and XX9)? I did not realize it rightaway too ;) BTW Does not block this patch!
I still argue that this is primarily a developer-centric patch. It's needed so that we can interoperate with the rest of the library world who do not speak Koha. If you have a better idea for the label, please submit a follow-up patch by all means. I do not have any better ideas. I would probably use jQuery to call it "Raw MARC" because I don't see any use for the existing UTF-8 and MARC-8 exports.
2) While testing it, I saw that the fields 952 and 999 are still included. Note that these are certainly no marc standard fields, so if any should be excluded, they should. Since your regex tests /9/, I do however not understand why they are still there. Do you? Note that a local field 942 and subfields 9 were correctly removed in my testing. Could you test this too?
I did not have this problem, but your proposed fix worked, so I will attach the revised patch momentarily.
3) I doubt if the encoding is 100% correct. When I opened the exported file in notepad, some characters with umlaut did not come up completely correct. But when copying them somewhere else, they were correct after all. When I commented the call to SetUTFFlag, the results in notepad were correct. Tested with title: Vorläufer, Schüler, Zeitgenossen. Please note that GetMarcBiblio is already calling _new_from_xml with a utf8 parameter. Also note that this remark also pertains to existing format utf8 in export scripts. (So formally, it could be a report on itself.) Maybe Katrin can test it (probably she has the most experience with umlauts ;)
I think it is better not to fix this here, because I am not an expert in this, and it would be better to have someone who understands the problem fix it in both places than have me try to hack in a fix here.
4) Finally, elaborating on point 3: Not blocking this patch, but why would the marc2marc function not just demand a marc object (instead of optionally creating it). Note that the only call now already receives an object, created by GetMarcBiblio. And why not leave the call to as_usmarc to the export script, just as done in the case of format marc8, utf8 ?
I was using the existing marc2marc API, which specified that it should return the results of as_usmarc.
Changing status just to reflect need for some testing and answers..
-- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.