http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7345
--- Comment #29 from Jared Camins-Esakov <[email protected]> 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. _______________________________________________ Koha-bugs mailing list [email protected] http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
