http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9703 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |In Discussion --- Comment #3 from David Cook <dcook@prosentient.com.au> --- Actually, I don't think that this patch/concept is quite ready for master. I do think the Keyword to MARC mapping has a lot of potential to increase the customizability of the "Normal" view of bibliographic records for libraries in a user-friendly way that doesn't rely on XSL, and this is something important that we should be developing. However, I think we need a systematic approach for how these mappings can overwrite the default values supplied to the detail template (and maybe even the search results and lists although I would be hesitant with those). I don't think the use of an "as_string" parameter is necessarily the best way of doing this, since it glues together the results of an array with spaces when you might want to include punctuation. -- Ideally, I think the Keyword to MARC mapping table should include an extra optional column for glue/punctuation, which will follow each mapping. In some cases, you might not want to include punctuation, because your descriptive standard might already include it. Say, you want the "author" field to contain 100$a, 100$c, and 100$d (USMARC). The punctuation might already be included in those subfields. If it isn't, then you can add optional punctuation in your Keyword to MARC mapping to add it in. N.B. this would be more useful for situations when you're combining different MARC fields or disparate subfields from a field together to create an element on the Normal detail page. In any case, I think this is better than having to hard-code the punctuation into the templates like we currently do. -- You are receiving this mail because: You are watching all bug changes.