http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13912
--- Comment #13 from Thomas Dukleth <td-koha-b...@agogme.com> --- The proposed fix using $DefaultCountryField008 follows the somewhat less problematic example of $DefaultLanguageField008. 1. CORRECTING HARD CODED CHOICES. Already existing code has hard coded choices for both language of content and country of production in marc21_field_008.pl if no preference is specified, but we should not be perpetuating that mistake in a new patch. Country also has a narrower scope and is thus more likely to be wrong if not specified than language. If no preference has been set, the corresponding value should be empty by default or specified as an equivalent to "no attempt to code" where relevant. 2. MARC NEUTRAL APPLICATION. The proposed $DefaultCountryField008 follows the mistaken pattern of $DefaultLanguageField008 for the MARC 21 based description in `systempreferences`.`description`. However, the same list of language codes for language of content applies to the current standard for both MARC 21 and UNIMARC $DefaultLanguageField008. [There had been a few differences in language codes for the respective bibliographic standards from the 1990s and earlier.] Consequently, a default specified in $DefaultLanguageField008 could be used equally for both MARC 21 and UNIMARC. A more universal approach for specifying country of production could use a value list for country which would be a superset of country specifications from both the ISO 3166 Country Codes list and Library of Congress MARC Country Codes list. The user could choose by the label for the country code in a manner independent of MARC and the appropriate code could be used based on the MARC standard specified in Koha $marcflavour. Alas, I am uncertain, if I am prepared to do all the work which would be necessary for such a worthy goal along with related validation at the present time. 3. KOHA MARC FRAMEWORK CENTRIC DEFAULT. Tomás Cohen Arazi is interested in tying a default setting closer to the Koha MARC frameworks. An advantage would be that the user could choose from different default values by choosing different frameworks which the user could create. The difficulty of using `marc_subfield_structure`.`defaultvalue` is that fixed fields, such as MARC 21 008, would be difficult for users to encode as a default. A plugin for the frameworks editor similar to one for the record editor could be used to populate default values for fixed fields in the frameworks. [In the Koha MARC frameworks, MARC 21 fixed fields are managed as if they are subfield $0 of the respective fields. UNIMARC fixed subfields are subfields which is unproblematic for the original design of the Koha MARC frameworks code.] I am a little uncertain of the degree of debugging time required for plugins to work on framework values relative to my time. I would be happy to have a more MARC neutral system preference for country of production at the present time in which the user would enter a value as in the proposed fix, but choosing from the linked documentation for MARC country code list for MARC 21 or the ISO 3166 code list for UNIMARC. We could then file an enhancement bug for adding more granular defaults for fixed fields and fixed subfields associated with Koha MARC frameworks. -- You are receiving this mail because: You are watching all bug changes. _______________________________________________ Koha-bugs mailing list Koha-bugs@lists.koha-community.org 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/