https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40300 --- Comment #7 from Bernard <bernard.scaife@openfifth.co.uk> --- (In reply to Alexander Wagner from comment #3)
Probably a bit philosophical: While I am personally all for removing punctuation from records and adding them automatically, I do wonder if in your case Koha is not entering a strange mixture. IMHO
- if a punctuation _is there_ the logic should be to keep and use it. - if no punctuation is there it should add it.
IOW while I see what your code does and I also perfectly agree that having ` ; ; ` is wrong _and_ ugly, I do wonder why the ` ; ` in `|p` is different from the `.` in `|a` or `|v` and thus treated differently.
So, I think instead of chopping the punctuation from `|p` and add it again automatically, the code should look at leader 18 and decide if it should do anything wrt the punctuation in the first place. And if the leader says "all chars are there" it should just do nothing and leave it as is. (My guess would be your records states that it holds those chars.)
BTW: I started working on automatic punctuation in https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21303. After playing around with XSLT and some discussion with Cait we came to the conclusion (which might be wrong) that it is probably _a lot_ easier to do this punctuation stuff by means of a Marc Filter in Perl especially as there are some complex things out there. Cf https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37196, https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37325 and their tests for examples and an implementation for a few fields.
Interesting. I'm all for anything that can make this simpler and I like your idea of a separate punctuation.pm. I would be reluctant to have to rely on the LDR position 18 value as experience shows this may be set to "a" but that not be the reality. Perhaps a syspref making it an option? I guess the issue is if we currently already use chopPunctuation at all in the xslt (we do), it should do it everywhere required. Or else not at all. For now, pragmatically, I think I'd rather stick to fixing what we have. -- You are receiving this mail because: You are watching all bug changes.