https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29897
--- Comment #33 from Jonathan Druart <[email protected]> --- (In reply to Katrin Fischer from comment #26) Thanks for your time, Katrin! > 0) Linkage $6 > > In your code you assume that $6 is a URL, but that will NEVER be the case > according to MARC standard. We are going to lose flexibility, but I agree we should follow the standard. > 1) Missing POD for _get_marc_authors > > Could it be a little confusing having _get_marc_authors and get_marc_authors? Added POD. > 2) On get_marc_contributurs, you write: > > (700..712 for MARC21) > > but: > > + if ( $marcflavour eq "UNIMARC" ) { > + $mintag = "700"; > + $maxtag = "712"; > + $fields_filter = '7..'; > + } else { # marc21/normarc > + $mintag = "700"; > + $maxtag = "720"; > + $fields_filter = '7..'; > + } > > Overall using a range instead of a list seems a little risky, but works for > MARC21. It looks like a lot of fields, but actually it's only: 700, 710, 711 > and 720. > (https://www.loc.gov/marc/bibliographic/bd70x75x.html) Adjusted the POD! > 3) Missing 110, 111 > > If we get 710 and 711 we should probably include 110 and 111 in > get_marc_authors as well. As it was 'wrong' before, should we file a > separate bug report to extend this method? Hum, yes? I don't know! Any ideas why it's missing here? > 4) Pref description > > I am struggling a bit with the description. > > [Display|Don't display] author identifiers for research publications. > > It makes it sound, like it was limited to research publications, while the > limit is actually the 024 existing or not. > > Adding information that this requires authorities and 024 would be good I > think. Maybe: > > > [Display|Don't display] identifiers for authors and contributors to the > detail pages in the OPAC. This feature requires authorities with 024 Done, thanks for the suggestion. > 5) Selection of $2 > > + [% CASE 'orcid' %]ORCID: > + [% CASE 'scopus' %]ScopusID: > + [% CASE 'loop' %]loop: > + [% CASE 'rid' %]Publons: > > a) Should these be surrounded by <span>? > b) $2 are usually taken from the official LOC list: > https://www.loc.gov/standards/sourcelist/standard-identifier.html > > orcid = ORCID OK > scopus = ScopusID OK > loop = doesn't exist in official list. I am fine with it if that is a custom > one, but maybe worth checking? > rid = ResearcherID, linking to: > http://www.researcherid.com/#rid-for-researchers, stating: > ResearcherID profiles moved to Publons on 15 April 2019 - so probably OK Hugo, do you know "loop"? > viaf might be a good candidate (for another bug). I have added here. > The fallback worries me: > [% CASE %][% identifier.source | html %]: > > I think we should stick with a hardcoded list as not all $2 codes and > identifiers are useful to patrons (and they might get into the catalog, if > you use a central authority file) Done, but I am not sure I agree with this :) Won't we get request from lot of people to add theirs? > c) I'd also suggest to add a class with the $2 to the <li> element, this way > each entry could be hidden and customized easily. Can you be more specific please? There is a class on the div already (author_identifier). With the new patches, do you think we should have: <span class="orcid">ORCID</span> ? -- You are receiving this mail because: You are watching all bug changes. _______________________________________________ Koha-bugs mailing list [email protected] https://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/
