[Bug 13600] New: XSLT: 8xx not showing if there is no 4xx
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13600 Bug ID: 13600 Summary: XSLT: 8xx not showing if there is no 4xx Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Templates Assignee: oleonard@myacpl.org Reporter: nengard@gmail.com QA Contact: testopia@bugs.koha-community.org In records with series field(s) 800/810/830 only (no 4XX series), no series are displayed. The MARC21 rules say: "An 810 field is usually justified by a series statement (field 490) or a general note (field 500) relating to the series." "usually" means it should show even if there is no 490 http://www.loc.gov/marc/bibliographic/bd810.html -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13600 Winona Salesky <wsalesky@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |wsalesky@gmail.com --- Comment #1 from Winona Salesky <wsalesky@gmail.com> --- How about if there is 490$0 or 490$# ? Should the 8xx display in that case as well? (In reply to Nicole C. Engard from comment #0)
In records with series field(s) 800/810/830 only (no 4XX series), no series are displayed.
The MARC21 rules say:
"An 810 field is usually justified by a series statement (field 490) or a general note (field 500) relating to the series."
"usually" means it should show even if there is no 490
-- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13600 --- Comment #2 from Nicole C. Engard <nengard@gmail.com> --- (In reply to Winona Salesky from comment #1)
How about if there is 490$0 or 490$# ? Should the 8xx display in that case as well?
You know .. I don't know. The examples on the 810 documentation look like it should so not matter what the indicators ... On the 490 documentation the 830 only shows if the indicator is 1 - and so maybe if the indicator is 1 we shouldn't show the 8xx because it will be duplicate info. Anyone else have any feedback here? -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13600 Heather <heather_hernandez@nps.gov> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |heather_hernandez@nps.gov --- Comment #3 from Heather <heather_hernandez@nps.gov> --- Yes--the 8XX should always display. The 4XX is transcribed from the item, so would be present only if the series statement appears on the item. With a 490 1_ there should be a companion 8XX, with the 490 field transcribing the series statement from the item & the 8XX containing the series statement added entry. (These fields are a holdover from card printing, when you wanted the 4XX printed in parentheses as transcribed & then an added entry card printed with the form of the series as traced.) There could be a case where there is a 490 0_ and a 500 and an 8XX, e.g. (made up example): 490 0 _ Ballantine science fiction masters 500 _ _ Fifth in the Captain Proton series. 800 1 _ Smith, Joanna. $t Captain Proton series ; $v 5. In this made up example, the series is not traced because it's a publishers' artificial marketing series, but it's important to transcribe it for identification of the edition. Access is created for the "series" of novels featuring the character in order of publication, since people look for novels that way. This is a record where the 8XX field is justified by a 500 note: http://keys.bywatersolutions.com/cgi-bin/koha/opac-detail.pl?biblionumber=33... More typically, you will have a 490 1_ paired with an 830 0_. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13600 --- Comment #4 from Winona Salesky <wsalesky@gmail.com> --- Thanks Heather. That is very helpful. So to translate that into code, I could say, always display 8xx, but only display 490 where ind1 is NOT 1 (not traced). Is that accurate? -Winona -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13600 --- Comment #5 from Heather <heather_hernandez@nps.gov> --- (In reply to Winona Salesky from comment #4)
Thanks Heather. That is very helpful.
So to translate that into code, I could say, always display 8xx, but only display 490 where ind1 is NOT 1 (not traced).
Is that accurate? -Winona
It sounds accurate, Winona. I think you could also say, "...only display 490 where ind1 is zero." The 490 0_ display has traditionally been in parentheses, c.f. display examples here: http://www.loc.gov/marc/bibliographic/bd490.html It has traditionally not had any prefix or label to the field. 8XX fields have not traditionally displayed in parentheses, but have a prefix. Why, I don't know, but that's the way it is! Displays in systems I've seen vary, but other systems I've seen tend to have a prefix and group all displayed series entries, e.g.: Series: Magic ex libris ; bk. 2 DAW book collectors ; no. 1629 In this case, only "Magic ex libris" is a traced series (830 field), searchable via a series or title index search as well as a keyword search. "DAW book collectors" is untraced (490 0_ field) so is searchable only via a keyword search. Hope this helps! --h2 -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13600 --- Comment #6 from Winona Salesky <wsalesky@gmail.com> --- I can do that. What should happen where 490 ind1 is blank? In the example below if 490 ind1 is blank the field will be suppressed. It might make more sense to show the field as the default, and suppress it only when explicitly stated (by the indicator). Although I may be miss understanding how the field is coded. Thanks for the help, -Winona (In reply to Heather from comment #5)
(In reply to Winona Salesky from comment #4)
Thanks Heather. That is very helpful.
So to translate that into code, I could say, always display 8xx, but only display 490 where ind1 is NOT 1 (not traced).
Is that accurate? -Winona
It sounds accurate, Winona. I think you could also say, "...only display 490 where ind1 is zero." The 490 0_ display has traditionally been in parentheses, c.f. display examples here: http://www.loc.gov/marc/bibliographic/bd490.html It has traditionally not had any prefix or label to the field.
8XX fields have not traditionally displayed in parentheses, but have a prefix. Why, I don't know, but that's the way it is! Displays in systems I've seen vary, but other systems I've seen tend to have a prefix and group all displayed series entries, e.g.: Series: Magic ex libris ; bk. 2 DAW book collectors ; no. 1629
In this case, only "Magic ex libris" is a traced series (830 field), searchable via a series or title index search as well as a keyword search. "DAW book collectors" is untraced (490 0_ field) so is searchable only via a keyword search.
Hope this helps! --h2
-- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13600 --- Comment #7 from Heather <heather_hernandez@nps.gov> --- (In reply to Winona Salesky from comment #6)
I can do that. What should happen where 490 ind1 is blank? In the example below if 490 ind1 is blank the field will be suppressed. It might make more sense to show the field as the default, and suppress it only when explicitly stated (by the indicator). Although I may be miss understanding how the field is coded.
Thanks for the help,
-Winona
(In reply to Heather from comment #5)
(In reply to Winona Salesky from comment #4)
Thanks Heather. That is very helpful.
So to translate that into code, I could say, always display 8xx, but only display 490 where ind1 is NOT 1 (not traced).
Is that accurate? -Winona
It sounds accurate, Winona. I think you could also say, "...only display 490 where ind1 is zero." The 490 0_ display has traditionally been in parentheses, c.f. display examples here: http://www.loc.gov/marc/bibliographic/bd490.html It has traditionally not had any prefix or label to the field.
8XX fields have not traditionally displayed in parentheses, but have a prefix. Why, I don't know, but that's the way it is! Displays in systems I've seen vary, but other systems I've seen tend to have a prefix and group all displayed series entries, e.g.: Series: Magic ex libris ; bk. 2 DAW book collectors ; no. 1629
In this case, only "Magic ex libris" is a traced series (830 field), searchable via a series or title index search as well as a keyword search. "DAW book collectors" is untraced (490 0_ field) so is searchable only via a keyword search.
Hope this helps! --h2
Hey, Winona-- The 490 ind1 must never be blank--blank is not a valid value. The 490 first indicator must be zero or one. (The 490 second indicator must be blank, but the first indicator must be zero or one.) The required values are here: http://www.loc.gov/marc/bibliographic/bd490.html Hope this helps! --h2 -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13600 Winona Salesky <wsalesky@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |Needs Signoff -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13600 --- Comment #8 from Winona Salesky <wsalesky@gmail.com> --- Created attachment 40097 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=40097&action=edit Bug 13600 - XSLT: 8xx not showing if there is no 4xx Removes dependency on 490 ind1 for 8xx display. 8xx will always display. Test Plan: 1) Apply this patch 2) Ensure you are using the default XSLT setting for the staff and opac details view. 3) Find or create a record with MARC tags 800, 810, 830 4) Check display of 8xx tags, should always display if present in the record. 6) Repeat test for the staff interface -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13600 --- Comment #9 from Nick Clemens <nick@quecheelibrary.org> --- Created attachment 40106 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=40106&action=edit Bug 14280: Add branches fields to discharges letters Currently, when generating a discharge letter, branches fields are not translated in the letter (<<branches.branchname>>, <<branches.branchaddress1>>, etc.) This patch fixes that. How I tested: - Set syspref 'useDischarge' to 'allow' - Go to Home > Tools > Notices & Slips - Edit DISCHARGE, add to 'Email message': <p><<branches.branchname>><br /> <<branches.branchaddress1>><br /> <<branches.branchaddress2>><br /> <<branches.branchaddress3>><br /> <<branches.zip>> <<branches.city>><br /> </p> - Go to detail page of a patron > discharge - Click 'Generate discharge' - Verify that the PDF contains the information above. Signed-off-by: Marc Véron <veron@veron.ch> Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de> Signed-off-by: Tomas Cohen Arazi <tomascohen@unc.edu.ar> Signed-off-by: Nick Clemens <nick@quecheelibrary.org> -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13600 Nick Clemens <nick@quecheelibrary.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #40106|0 |1 is obsolete| | Attachment #40106|1 |0 is patch| | -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13600 Nick Clemens <nick@quecheelibrary.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Signed Off -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13600 Nick Clemens <nick@quecheelibrary.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #40097|0 |1 is obsolete| | --- Comment #10 from Nick Clemens <nick@quecheelibrary.org> --- Created attachment 40107 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=40107&action=edit [SIGNED OFF] Bug 13600 - XSLT: 8xx not showing if there is no 4xx Removes dependency on 490 ind1 for 8xx display. 8xx will always display. Test Plan: 1) Apply this patch 2) Ensure you are using the default XSLT setting for the staff and opac details view. 3) Find or create a record with MARC tags 800, 810, 830 4) Check display of 8xx tags, should always display if present in the record. 6) Repeat test for the staff interface Signed-off-by: Nick Clemens <nick@quecheelibrary.org> -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13600 Nick Clemens <nick@quecheelibrary.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |nick@quecheelibrary.org --- Comment #11 from Nick Clemens <nick@quecheelibrary.org> --- This works as described and is an improvement so signing off. All below are just wishlist: Punctuation could be better, between fields is ';' would be nice to see as '|' as on others Also, 8xx fields seems to be ending in ':' regardless of field ending in record Would also be nice to have some indication between author/title in the 8xx, maybe title in italics? (And apologies for mis-attached patch earlier) -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13600 --- Comment #12 from Winona Salesky <wsalesky@gmail.com> --- These are all simple additions and can be added. I will have an amended patch up by tonight. Thanks for the feedback! -Winona (In reply to Nick Clemens from comment #11)
This works as described and is an improvement so signing off.
All below are just wishlist:
Punctuation could be better, between fields is ';' would be nice to see as '|' as on others
Also, 8xx fields seems to be ending in ':' regardless of field ending in record
Would also be nice to have some indication between author/title in the 8xx, maybe title in italics?
(And apologies for mis-attached patch earlier)
-- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13600 --- Comment #13 from Heather <heather_hernandez@nps.gov> --- (In reply to Winona Salesky from comment #12)
These are all simple additions and can be added. I will have an amended patch up by tonight. Thanks for the feedback! -Winona
(In reply to Nick Clemens from comment #11)
This works as described and is an improvement so signing off.
All below are just wishlist:
Punctuation could be better, between fields is ';' would be nice to see as '|' as on others
Also, 8xx fields seems to be ending in ':' regardless of field ending in record
Would also be nice to have some indication between author/title in the 8xx, maybe title in italics?
(And apologies for mis-attached patch earlier)
An indication between author & title in the 800 & 810 would be great, but I think that if the title were in italics, it would be the only italics in the display. Also, no other titles in displays are in italics, and some of the other bib systems (e.g., Worldcat.org) don't display titles in italics. The MARC21 format recommends a period/full stop between authors & titles in most (or all) fields, and the author & title would be hyperlinked & clickable, right? So something like in our catalog, with the series hyperlinked, e.g. in this record, with the comma after "Patrick" replaced with a period/full stop? http://keys.bywatersolutions.com/cgi-bin/koha/opac-detail.pl?biblionumber=32... Series: O'Brian, Patrick. Aubrey/Maturin novels: 1. --heather -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13600 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |katrin.fischer@bsz-bw.de --- Comment #14 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- Hm, I am with Heather on the italics - what about he separator | Nick mentioned? For when the record is part of multiple series? I'd think it wouldn't happen often, but on the other hand... nothing is impossible I have learned. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13600 --- Comment #15 from Heather <heather_hernandez@nps.gov> --- Yes--multiple series do happen! I like the idea of a pipe between series entries. Maybe it would look cleaner without a period/full stop at the end: Series: Hines, Jim C. Magic ex libris: 1 | Wizard essential codices: 342 | Fantasy reading group favorites: v. 45 The single series entry may still look fine without the period/full stop at the end: Series: O'Brian, Patrick. Aubrey/Maturin novels: 1 --heather P.S. Don't tell other catalogers I suggested eliminating the Very Traditional Period/Full Stop at the end of the series entry!:) -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13600 --- Comment #16 from Heather <heather_hernandez@nps.gov> --- (In reply to Heather from comment #15)
Yes--multiple series do happen! I like the idea of a pipe between series entries. Maybe it would look cleaner without a period/full stop at the end:
Series: Hines, Jim C. Magic ex libris: 1 | Wizard essential codices: 342 | Fantasy reading group favorites: v. 45
The single series entry may still look fine without the period/full stop at the end:
Series: O'Brian, Patrick. Aubrey/Maturin novels: 1
--heather P.S. Don't tell other catalogers I suggested eliminating the Very Traditional Period/Full Stop at the end of the series entry!:)
ETA: I forgot to mention re. "Also, 8xx fields seems to be ending in ':' regardless of field ending in record," that this looks OK to me. Traditionally there is a "space, semi-colon, space" between the title and the number, but the colon snug against the title followed by a space looks good--it's neat and clear. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13600 --- Comment #17 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- I won't, because I like it :) -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13600 --- Comment #18 from Heather <heather_hernandez@nps.gov> --- (In reply to Katrin Fischer from comment #17)
I won't, because I like it :)
It is our secret!:) -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13600 --- Comment #19 from Nick Clemens <nick@quecheelibrary.org> --- (In reply to Heather from comment #16)
ETA: I forgot to mention re. "Also, 8xx fields seems to be ending in ':' regardless of field ending in record," that this looks OK to me. Traditionally there is a "space, semi-colon, space" between the title and the number, but the colon snug against the title followed by a space looks good--it's neat and clear.
I agree with that, but the case where there is no volume number I think the ':' looks a bit odd Italics was a radical idea, full stop does seem more reasonable. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13600 --- Comment #20 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- I think removing the : if there is no number/volume would make sense to me. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13600 --- Comment #21 from Heather <heather_hernandez@nps.gov> --- Just removing the ":" may look great. Traditionally the " ; " precedes the numbering in the $v if it is present. If there was no 8XX $v, then there was no punctuation at the end of the $t, because the field displayed within parentheses. I think it would be fine without terminal punctuation and/or punctuation between $t & $v fields, e.g.: Series: Hines, Jim C. Magic ex libris 1 | Wizard essential codices 342 | Fantasy reading group favorites v. 45 Series: Tolkien, J.R.R. Lord of the rings 2 | Ballantine basics | Best 100 books of the 20th century no. 3 --h2 -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13600 --- Comment #22 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- Hm, not sure about generally removing the separator between the title and the volumne - some 'volumes' might be more textual. It might be more clear with something in between. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13600 --- Comment #23 from Winona Salesky <wsalesky@gmail.com> --- I also like the ':' (currently it is ':' should it be ';'?) between title and volumne, a solution would be to make it conditional, so it only appears if a $v is present. I will also change the separator between multiple fields. I would suggest leaving terminal punctuation, simply because most of the fields in the current xslt do use it. Let me know what you all think, and I will try to get an amended patch up this evening. Thanks! -Winona (In reply to Katrin Fischer from comment #22)
Hm, not sure about generally removing the separator between the title and the volumne - some 'volumes' might be more textual. It might be more clear with something in between.
-- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13600 --- Comment #24 from Heather <heather_hernandez@nps.gov> --- (In reply to Winona Salesky from comment #23)
I also like the ':' (currently it is ':' should it be ';'?) between title and volumne, a solution would be to make it conditional, so it only appears if a $v is present.
I will also change the separator between multiple fields. I would suggest leaving terminal punctuation, simply because most of the fields in the current xslt do use it.
Let me know what you all think, and I will try to get an amended patch up this evening. Thanks! -Winona
(In reply to Katrin Fischer from comment #22)
Hm, not sure about generally removing the separator between the title and the volumne - some 'volumes' might be more textual. It might be more clear with something in between.
Very good point about the textual nature of some volume numbering--I hadn't thought of that! The RDA proscribed punctuation for data in 4XX & 8XX $v is in rule D.1.2.7, "Precede the numbering within a series or sub-series or multipart monographic resource by a semicolon." (It was the same in AACR2 & AACR2R.) Of course, not everyone catalogs according to RDA. But if this standard is to be implemented, then the $v in the 4XX & the 8XX would be preceded by a space-semicolon-space. As for terminal punctuation, MARC21 is inconsistent, e.g. 8XX ends with a period/full-stop, 4XX, 24X & 78X do not have terminal punctuation at all, etc. If the MARC21 standard is to be followed, then there should be a period/full-stop at the end of 8XX fields (and nothing at the end of 4XX fields). On this record, the 24X fields & 6XX fields lack terminal punctuation, and different field separators are used for multiple field displays (semicolons for the 24X field, pipes for the 6XX fields): http://keys.bywatersolutions.com/cgi-bin/koha/opac-detail.pl?biblionumber=35... The 24X field separators may be custom--I'm sorry, but I'm not sure. I think it would be great to have standard field separators for multiple field displays in Koha, whatever they are. If the RDA proscribed punctuation of a semicolon is to be implemented preceding the $v field(s) in 4XX & 8XX fields, then perhaps pipes should be used as field separators. And, in the future, perhaps such pipes should be used as field separators for other multiple field displays. Cheerio! --h2 -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13600 --- Comment #25 from Katrin Fischer <katrin.fischer@bsz-bw.de> ---
I also like the ':' (currently it is ':' should it be ';'?) between title and volumne, a solution would be to make it conditional, so it only appears if a $v is present.
I like the conditional and would like the ; a bit better (less likely to be used in the title?)
And, in the future, perhaps such pipes should be used as field separators for >other multiple field displays.
I think the trend goes to | currently - we already have that in several fields now. :) What I'd like to see is have them wrapped in a span with a class. So if you don't like the |, you can easily change it. I think we have done that in one place at least already. I am not sure how close we need to stick to the MARC21 standard here as we are building a 'normal view' targetted at patrons and all library staff. I know that the ending punctuation '.' has caused some questions here in the past - same for the / at the end of the title. I feel like most catalogs here don't have that, but they are mostly not MARC21 internally either. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13600 --- Comment #26 from Heather <heather_hernandez@nps.gov> --- (In reply to Katrin Fischer from comment #25)
I also like the ':' (currently it is ':' should it be ';'?) between title and volumne, a solution would be to make it conditional, so it only appears if a $v is present.
I like the conditional and would like the ; a bit better (less likely to be used in the title?)
And, in the future, perhaps such pipes should be used as field separators for >other multiple field displays.
I think the trend goes to | currently - we already have that in several fields now. :) What I'd like to see is have them wrapped in a span with a class. So if you don't like the |, you can easily change it. I think we have done that in one place at least already.
I am not sure how close we need to stick to the MARC21 standard here as we are building a 'normal view' targetted at patrons and all library staff. I know that the ending punctuation '.' has caused some questions here in the past - same for the / at the end of the title. I feel like most catalogs here don't have that, but they are mostly not MARC21 internally either.
Yes--the semicolon is rarely used in titles. And your idea about the span & class would be great! I think the slash in the 245 ("/") is misapplied. Most catalogs don't have it at the end of 245 subfields because it is not terminal punctuation. It is not supposed to be at the end of a field, but is supposed to *precede* the 245 $c (statement of responsibility) only if the $c is present. So it is like this semicolon for the 4XX & 8XX $v that we are discussing--it is supposed to appear preceding a field only if the field is present. Have a slash appear as terminal punctuation is not proscribed by AACR2, AACR2R, or RDA. (RDA D.1.2.2, "Precede the first statement of responsibility by a diagonal slash. Precede each subsequent statement of responsibility by a semicolon.") --h2 -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13600 Winona Salesky <wsalesky@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Needs Signoff -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13600 Winona Salesky <wsalesky@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #40107|0 |1 is obsolete| | --- Comment #27 from Winona Salesky <wsalesky@gmail.com> --- Created attachment 40207 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=40207&action=edit Bug 13600 - XSLT: 8xx not showing if there is no 4xx Removes dependency on 490 ind1 for 8xx display. 8xx will always display. Adds span class="separator" | between multiple series, changes : before $v to a conditional ; Test Plan: 1) Apply this patch 2) Ensure you are using the default XSLT setting for the staff and opac details view. 3) Find or create a record with MARC tags 800, 810, 830 4) Check display of 8xx tags, should always display if present in the record. 6) Repeat test for the staff interface -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13600 Nick Clemens <nick@quecheelibrary.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|oleonard@myacpl.org |wsalesky@gmail.com Status|Needs Signoff |Failed QA --- Comment #28 from Nick Clemens <nick@quecheelibrary.org> --- Working: OPAC now shows '|' separator ';' is enforced as title/volume separator no punctuation if volume isn't present Needs fixed: Staff side separator is still ';' SHOULD BE '|' ':' is enforced as title/volume separator - SHOULD BE ';' All fields have ending':' if volume is not present -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13600 Winona Salesky <wsalesky@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Failed QA |Needs Signoff -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13600 Winona Salesky <wsalesky@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #40207|0 |1 is obsolete| | --- Comment #29 from Winona Salesky <wsalesky@gmail.com> --- Created attachment 40636 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=40636&action=edit Bug 13600 - XSLT: 8xx not showing if there is no 4xx Removes dependency on 490 ind1 for 8xx display. 8xx will always display. Adds span class="separator" | between multiple series, changes : before $v to a conditional ; Adds patch to staff details interface. Test Plan: 1) Apply this patch 2) Ensure you are using the default XSLT setting for the staff and opac details view. 3) Find or create a record with MARC tags 800, 810, 830 4) Check display of 8xx tags, should always display if present in the record. 6) Repeat test for the staff interface -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13600 Winona Salesky <wsalesky@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #40636|0 |1 is obsolete| | --- Comment #30 from Winona Salesky <wsalesky@gmail.com> --- Created attachment 40637 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=40637&action=edit Bug 13600 - XSLT: 8xx not showing if there is no 4xx Removes dependency on 490 ind1 for 8xx display. 8xx will always display. Adds span class="separator" | between multiple series, changes : before $v to a conditional ; Adds patch to staff details interface. Test Plan: 1) Apply this patch 2) Ensure you are using the default XSLT setting for the staff and opac details view. 3) Find or create a record with MARC tags 800, 810, 830 4) Check display of 8xx tags, should always display if present in the record. 6) Repeat test for the staff interface -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13600 --- Comment #31 from Winona Salesky <wsalesky@gmail.com> --- Sorry about that, the original patch did not include a fix for the staff client. -Winona -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13600 Nick Clemens <nick@quecheelibrary.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Failed QA --- Comment #32 from Nick Clemens <nick@quecheelibrary.org> --- 800s look good. And now my apologies for incomplete testing previously 1 - 400s need the semicolon between title/volume 2 - there is no '|' between 440 / 490 / 8xxs (multiple 440s and 490s are separated by '|' so good there) I will mention that author dates are not displayed in series field, and the links for series use only the author name in their search so: 800 1_ $aAdams, Douglas, $d 1952-2001. 4t Dirk Gently’s Holistic Detective Agency Searches for se,phr:"Adams,Douglas" instead of se,phr:"Dirk Gently..." I think it is out of scope here, but wondering if the behavior is correct -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13600 Nicole C. Engard <nengard@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |nicole@bywatersolutions.com -- You are receiving this mail because: You are watching all bug changes.
participants (1)
-
bugzilla-daemon@bugs.koha-community.org