|
Help talk:Citation Style 1/Archive 78
when |archive-url= is brokenIn normal display mode (what readers see), broken archive urls are ignored except that the module emits an error message. When editors view the same article in preview mode, and when the archive url is an archive.org url, the module uses a modified form of the archive url. The purpose of that is to enable editors to see archive.org's calendar view so that they might choose the url of an appropriate snapshot to replace the malformed archive url in the template. When
In the above examples, the live version links to a "We're sorry — something's gone wrong" page while the sandbox links to the calendar view. —Trappist the monk (talk) 19:38, 5 August 2021 (UTC)
Cite magazine – why upper case Vol.?Why does {{Cite magazine}} emit volume in upper case: {{cite magazine|title=Some title|magazine=Some Magazine|volume=17}} -> "Some title". Some Magazine. Vol. 17. ? -- Michael Bednarek (talk) 09:23, 7 August 2021 (UTC)
display-authors bugIf you specify just one author and then invoke display-authors=1, you get an error. You need to specify an author2 to make it go away (even though author2 isn't displayed!). Urhixidur (talk) 15:19, 4 August 2021 (UTC)
Markup in titlesPeeking at Category:CS1 errors: markup, I see it doesn't include fields like "title". I'm in the process of cleaning up lots of HTML entities (which shouldn't be in these fields either), and I've seen lots of instances of double single quotes (''...'') in the title field. On Wikipedia, this will make italics, but apparently italics are not allowed in COinS fields? Is this something that should be systematically fixed? -- Beland (talk) 07:48, 9 August 2021 (UTC)
|
| Wikitext | {{cite web
|
|---|---|
| Live | "Title". Boomerocity.com. {{cite web}}: |access-date= requires |url= (help); |archive-url= requires |url= (help); Invalid |url-status=blacklisted (help); Missing or empty |url= (help)
|
| Sandbox | "Title". Boomerocity.com. {{cite web}}: |access-date= requires |url= (help); |archive-url= requires |url= (help); Invalid |url-status=blacklisted (help); Missing or empty |url= (help)
|
and when used with{{cite book}}for|chapter-url=. In this example,|chapter-url=<!-- blacklisted https://www(dot)boomerocity(dot)com/moonbeam-parade(dot)html blacklisted -->(where (dot) is a dot):
| Wikitext | {{cite book
|
|---|---|
| Live | "Chapter". Title. {{cite book}}: |access-date= requires |url= (help); |archive-url= requires |url= (help); Invalid |url-status=blacklisted (help)
|
| Sandbox | "Chapter". Title. {{cite book}}: |access-date= requires |url= (help); |archive-url= requires |url= (help); Invalid |url-status=blacklisted (help)
|
In this second example, because the module does not receive|chapter-url=it cannot know to apply|archive-url=to|chapter=.This scheme may not work all the time. It's unclear to me when the blacklister steps in and prevents saving of a page with a blacklisted url. For example, I was able to save my sandbox that has actual blacklisted urls commented out (taken from Giulia Millanta) but I am unable to save the same thing here.- —Trappist the monk (talk)
16:10, 6 July 2021 (UTC)13:07, 8 July 2021 (UTC) (strikeout)- In your examples did you you omit the protocol (URI scheme) intentionally? (As it returns errors). Also, is it possible for the blacklisted url to be commented out by a routine? If it is too hard I guess it can always be done by hand.
| Wikitext | {{cite web
|
|---|---|
| Live | "Title". BlacklistedWebsite.com. Archived from the original on 2021-07-06. Retrieved 2021-07-06. {{cite web}}: Invalid |url-status=blacklisted (help)
|
| Sandbox | "Title". BlacklistedWebsite.com. Archived from the original on 2021-07-06. Retrieved 2021-07-06. {{cite web}}: Invalid |url-status=blacklisted (help)
|
- Any ideas about adding an archive-url-status param? 65.88.88.57 (talk) 19:07, 6 July 2021 (UTC)
- (edit conflict)
- Not intentional and fixed. It is likely that I will revert this change because the regex that is the blacklister looks for anything following
http://orhttps://until the line item found in MediaWiki:Spam-blacklist; see mw:Extension:SpamBlacklist#Performance. So for the boomerocity.com archive url here,https://web.archive.org/web/20200122204730/https://boomerocity(dot)comwill match/https?:\/\/[a-z0-9\-.]*\bboomerocity\.com\b/Si. - As far as I know, no one has made a case for
|archive-url-status=. - —Trappist the monk (talk) 19:41, 6 July 2021 (UTC)
- I suppose I was asking whether something like this is feasible:
{{Cite web |title=Title |website=BlacklistedWebsite.com |url=http://blacklisted_url.com|archive-url=http://blacklisted_url.com-some_archive.org |archive-date=2021-07-06 |access-date=2021-07-06 |url-status=blacklisted|archive-url-status=blacklisted}}- to be auto-formatted as
{{Cite web |title=Title |website=BlacklistedWebsite.com |url=<!--http://blacklisted_url.com-->|archive-url=<!--http://blacklisted_url.com-some_archive.org--> |archive-date=2021-07-06 |access-date=2021-07-06 |url-status=blacklisted|archive-url-status=blacklisted}}
- 65.88.88.57 (talk) 19:30, 6 July 2021 (UTC)
- If I understand what you are saying, then the answer is: no. Modules and templates cannot modify and save wikitext.
- —Trappist the monk (talk) 19:43, 6 July 2021 (UTC)
- Right. I was thinking about something similar to the way
|url=original-url.comis auto-formatted when|url-status=dead, for example, to|url=archived-url.com(and the static text too). 65.88.88.57 (talk) 20:19, 6 July 2021 (UTC)
- Right. I was thinking about something similar to the way
- Blacklisted change has been reverted because it will not work properly.
- —Trappist the monk (talk) 13:07, 8 July 2021 (UTC)
- See also: Help_talk:Citation_Style_1/Archive_66#spam_black_list_and_archive_urls --Matthiaspaul (talk) 09:34, 13 August 2021 (UTC)
- Any ideas about adding an archive-url-status param? 65.88.88.57 (talk) 19:07, 6 July 2021 (UTC)
Replacing "--" by "–"...
Hi, this is a followup to a recent but meanwhile archived discussion at Help talk:Citation_Style_1/Archive_75#Issue_with_{{{issue}}}, which was about converting double-hyphens and triple-hyphens in page ranges to en dashes and em dashes.
I originally implemented that on 2020-11-17 based on some suggestion that double-hyphens could occur in BibTeX entries and thereby could end up here as well occasionally. Unfortunately, I introduced a bug into the code trashing stripmarkers ("never do any last-minute changes after having already tested the code..." ;-) and because I could not locate the original discussion any more, it was removed rather than fixed. Well, I still haven't found the original discussion, so it probably wasn't here, but I just ran into a site (by renowned Nelson H. F. Beebe) excessively using double-hyphens in (hundreds of) BibTeX citations, so I thought I would drop a link here just for reference:
http://ftp.math.utah.edu/pub/tex/bib/bstj1930.html
Since we are doing all kinds of plausibility checks and also some on-the-fly conversions (including with pages and page ranges), I still think we should cover this case. After all, a double-hyphen in a page range can never be part of the page designation itself and the only reasonable interpretation is as an endash in a page range. The alternative to just silently converting them to improve our display and make our metadata output more consistent would be to throw a maintenance message, but this would require more code. --Matthiaspaul (talk) 12:46, 17 June 2021 (UTC)
- Searches:
- —Trappist the monk (talk) 12:59, 17 June 2021 (UTC)
- Not sure why you escaped the dashes, but I can get to 36 with timeout.
- I do not see a need for this change. There are sufficiently few and clearly not many being introduced that the interested user can just work from a search. Izno (talk) 13:51, 17 June 2021 (UTC)
- In fact, I can refine this to
- Still don't think we need it. Izno (talk) 14:23, 17 June 2021 (UTC)
- I, on the contrary, don't see how it could cause any harm. It would improve consistency in how citations are displayed and metadata is generated. Using two consecutive hyphens for an endash was a common notation in pre-Unicode times and many people are still accustomed to it. While we support Unicode and therefore do not technically need this any more, in general it is still a good idea to maintain compatibility with ASCII conventions for as long as they don't step in the way of more modern conventions. En dashes are still difficult to type in many keyboard layouts and visually almost impossible to distingish from a hyphen in many fonts. So, while they are technically the correct thing to use, they are not convenient to use. Why not let the templates do the translation for the editors' convenience? After all, we already translate a variety of other special character "transliterations" on the fly, so this would not be anything new. Alternatively we could have someone looking for these strings every once in a while and fix them in citations, but this is a never-ending endeavour, and we would continue to generate strange looking citations and metadata until fixed.
- Alternatively, we could detect the pattern and issue an error message in order to force editors to use en dashes. However, this would require more code than to just translate this on the fly, so if code complexity would be the issue, an on-the-fly translation would be the preferable solution. --Matthiaspaul (talk) 14:41, 19 July 2021 (UTC)
- MOS:DASH asks us to avoid double and triple dashes. MOS is generally about the visible output, not necessarily about parameter input on source code level, but what we can draw from this is that we should not have "--" or "---" showing up in rendered citations and metadata (well, unless the metadata standard would require en/em dashes to be transliterated this way, which COinS, however, does not). So, we should either accept them on source code level and convert them on the fly for proper output as "–" or "—", or, since they can never be a valid part of a single page designation, we should check for this condition (similar to our various extra text checks) and emit an error message. I still prefer the former alternative because it is easier to implement and in some cases might even become useful when people want to enter an en dash in an environment not supporting direct entry of the glyph, but I would also support the latter alternative.
- --Matthiaspaul (talk) 10:42, 13 August 2021 (UTC)
Location within large tree-structured documents with no page numbers
I often need to cite material from a tree-structured document with no page numbers. Typically there is a sidebar for navigation. If section foo.bar.baz has a stable URL then I can use |section-url=, but often there is none. Ideally I would like to mark it up with something like
{{cite document
| title = Manual with nested sections and no page numbers
| section-1 = foo
| section-2 = bar
| section-3 = baz
}}
However, nothing like |section-n= is implemented. |section=foo: bar: baz and |section=foo - bar - baz look clunky. What is the best way to mark up such citations? --Shmuel (Seymour J.) Metz Username:Chatul (talk) 16:42, 11 August 2021 (UTC)
- This looks like you are trying to cite multiple sources with a cs1|2 template that is designed to cite one source at a time. Along with your
|section1=,|section2=,|section3=your next request will be for|section-url1=,|section-url2=,|section-url3=, etc. And, how would that render? cs1|2 citations are complex enough, I don't think that we should be making them more complex by attempting to cite multiple sources with a single template. As an aside, this is why I want to do away with|lay-url=and its companions. - Still, perhaps something like what you want is already available and linking is possible but ugly, very ugly:
{{cite manual |title=Manual with nested sections and no page numbers |at=§foo, §bar, §[//example.com baz]}}- Manual with nested sections and no page numbers. §foo, §bar, §baz.
- And don't use
{{cite document}}to cite a manual.{{cite document}}is a redirect to{{cite journal}}. Why? Don't know; it really ought not to redirect there...{{cite manual}}as I used here is a redirect to{{cite book}}. - —Trappist the monk (talk) 17:14, 11 August 2021 (UTC)
- I don't know why you wrote
This looks like you are trying to cite multiple sources with a cs1|2 template that is designed to cite one source at a time.
, since the first three sentences clearly are describing a single source that is at a third level branch of the navigation sidebar. That is, on the navigation bar of the web page, you have something like- Extraneous content entries
- Content entry for section foo
- Extraneous content entries
- Content entry for subsection bar of section foo
- Extraneous content entries
- Content entry for subsubsection baz of subsection bar of foo
- where the intended citation is for only for subsubsection baz of subsection bar of foo, not for the enclosing foo or bar. --Shmuel (Seymour J.) Metz Username:Chatul (talk) 11:28, 12 August 2021 (UTC)
- I know what you wrote, but to me, your example template skeleton seems to contradict your initial statement; mostly because you did not describe how such an assemblage of parameters is to be rendered. That is why I wrote what I wrote. If you are citing section 'baz', then the title of section baz should be all that you need.
- Even were we to create enumerated
|section<n>=parameters, you still have some sort ofclunky
rendering if you want all of those hierarchical names in the rendered citation:- "Content entry for section foo > Content entry for subsection bar of section foo > Content entry for subsubsection baz of subsection bar of foo". Manual Title.
- Isn't
|section=Content entry for subsubsection baz of subsection bar of foosufficient? - —Trappist the monk (talk) 12:04, 12 August 2021 (UTC)
- I didn't mention rendering because I'm more concerned with semantics than layout. If someone implements
|level-n-section=then I could live with whatever rendering they chose. I'd probably prefer "level-1 > level-2 > level-3", but that's a nit. - The name of the lowest level branch is definitely not all I need, since it doesn't tell the reader how to navigate to that.
|section=Content entry for subsubsection baz of subsection bar of foois sufficient. --Shmuel (Seymour J.) Metz Username:Chatul (talk) 19:10, 13 August 2021 (UTC)
- I didn't mention rendering because I'm more concerned with semantics than layout. If someone implements
- I don't know why you wrote
Identificativo SBN
Is there a way to put an Identificativo SBN (Italian identifier) in Cite book and similar templates?--Carnby (talk) 08:10, 12 August 2021 (UTC)
- @Carnby: The cheap and nasty workaround is to use
others=SBN 123456. Otherwise you have to request an addition to the template: I have no idea how you would do that. --John Maynard Friedman (talk) 09:53, 12 August 2021 (UTC)- @John Maynard Friedman:
|others=is for 'other' contributors; not for miscellaneous identifiers. - Carnby: use
|id=Identificativo SBN: <identifier number> - —Trappist the monk (talk) 11:39, 12 August 2021 (UTC)
- We have a dedicated template for this, so ideally you would use
|id=. (It is not named {{SBN}} because of the name conflict with the ISBN predecessor.){{ICCU|number}} - --Matthiaspaul (talk) 10:57, 13 August 2021 (UTC)
- Thank you very much, I didn't find that! Is it possible to add it as a normal identifier i.e. |iccu=? Thanks in advance.--Carnby (talk) 05:42, 14 August 2021 (UTC)
- @John Maynard Friedman:
How to extlink the components of a multi-component publication
This citation:
- {{citation | last = Theil | first = H. | authorlink = Henri Theil | journal = Nederl. Akad. Wetensch., Proc. | pages = 386–392, 521–525, 1397–1412 | title = A rank-invariant method of linear and polynomial regression analysis. [https://www.dwc.knaw.nl/DL/publications/PU00018789.pdf I], [https://www.dwc.knaw.nl/DL/publications/PU00018803.pdf II], [https://www.dwc.knaw.nl/DL/publications/PU00018886.pdf III] | volume = 53 | year = 1950}}
- Theil, H. (1950), "A rank-invariant method of linear and polynomial regression analysis. I, II, III", Nederl. Akad. Wetensch., Proc., 53: 386–392, 521–525, 1397–1412
{{citation}}: External link in|title=
is throwing a CS1 error "External link in |title= (help)". But obviously it wouldn't work to use |title-link= (the only suggestion at the help link) because the three components of this multi-component work need to be linked separately. Can anyone suggest a way to make this citation work without errors and without splitting it into three separate citations? All I would really want is to disable the CS1 error message, because except for that message the citation template appears to format the citation adequately. —David Eppstein (talk) 17:14, 13 July 2021 (UTC)
- You can link the page numbers:
{{citation | last = Theil | first = H. | authorlink = Henri Theil | journal = Nederl. Akad. Wetensch., Proc. | pages = [https://www.dwc.knaw.nl/DL/publications/PU00018789.pdf 386–392], [https://www.dwc.knaw.nl/DL/publications/PU00018803.pdf 521–525], [https://www.dwc.knaw.nl/DL/publications/PU00018886.pdf 1397–1412] | title = A rank-invariant method of linear and polynomial regression analysis | volume = 53 | year = 1950}}- Theil, H. (1950), "A rank-invariant method of linear and polynomial regression analysis", Nederl. Akad. Wetensch., Proc., 53: 386–392, 521–525, 1397–1412
- —Trappist the monk (talk) 17:48, 13 July 2021 (UTC)
- This might be a good solution in the current implementation as we strip off the link before generating the metadata for
|pages=and friends. It might be a good idea to consider to do the same for|volume=,|number=and|issue=as well in order to better support various kinds of multi-partite publications (currently we don't, so adding the links to those parameters would, while still looking nice, mess up the metadata). - In this specific case the perfect solution would be to add support for a dedicated
|part=parameter. Even COinS has a special attribute for this (rft.part, which we do not use at present), indicating that this is really something we are lacking support for in our current implementation. As far I see it, parts are typically displayed following the title, but before volumes. - --Matthiaspaul (talk) 18:38, 13 July 2021 (UTC)
- Thanks for the suggestions. I think support for parts would be a good idea, but I think for now I'll follow trappist's suggestion of putting the links on the pages. —David Eppstein (talk) 21:01, 13 July 2021 (UTC)
- The simplest solution may be implementing
|page-linkn=, this assumes the editor should match the link number to the page sequence in|pages=. 66.108.237.246 (talk) 13:33, 14 July 2021 (UTC)- There is no need for separate
|page-linkn=parameters.|pages=and friends already support page ranges, page lists as well as external links without messing up the metadata. (|volume=,|number=and|issue=don't support external links at present, though.) Hence, there is no need for a separate|page-linkn=parameter to provide links. Associating the nth-link with a particular list item would considerably complicate the code. --Matthiaspaul (talk) 20:41, 14 July 2021 (UTC)- There is a need for link parameters only when the module is designed logically. An entity and a link to the entity are not the same thing and should be represented separately, not with the same parameter. This is flexible and understandable by editors. On a lower level, data types should correspond to unique parameters. You shouldn't have the same field accepting images and free-form text for example, or URLs and plain text as another example. But as stated, this presumes a logical module design. So this is probably off-topic. 65.88.88.126 (talk) 20:57, 14 July 2021 (UTC)
- During the great hyphen war many [enough] users didn't care about logical design vs. ease of use. -- GreenC 16:15, 15 July 2021 (UTC)
- Another assessment would be that entrenched ways are largely immune to logic, especially when work is required to arrive at a rational state. Also, zealotry to do something is just as bad as inertia, as the tracking-category-deletion phase of the hyphen wars shows. 65.88.88.57 (talk) 17:45, 15 July 2021 (UTC)
- During the great hyphen war many [enough] users didn't care about logical design vs. ease of use. -- GreenC 16:15, 15 July 2021 (UTC)
- There is a need for link parameters only when the module is designed logically. An entity and a link to the entity are not the same thing and should be represented separately, not with the same parameter. This is flexible and understandable by editors. On a lower level, data types should correspond to unique parameters. You shouldn't have the same field accepting images and free-form text for example, or URLs and plain text as another example. But as stated, this presumes a logical module design. So this is probably off-topic. 65.88.88.126 (talk) 20:57, 14 July 2021 (UTC)
- There is no need for separate
- This might be a good solution in the current implementation as we strip off the link before generating the metadata for
- A related discussion: Help_talk:Citation_Style_1#Param_suggestion:_|page-url=
- --Matthiaspaul (talk) 13:42, 21 July 2021 (UTC)
- Another related discussion: Help_talk:Citation_Style_1#Multiple_URLs_(split_file)
- --Matthiaspaul (talk) 03:49, 17 August 2021 (UTC)
bad DOI check
The following throws an error, but it's resolving correctly
- O'Mullane DM (2016). "Fluoride and Oral Health". Community Dental Health (33): 69–99. doi:10.1922/CDH_3707O’Mullane31.
Headbomb {t · c · p · b} 09:27, 17 August 2021 (UTC)
- Given that we support both U+0027 and U+02BC, it seems we should support U+2019 as well (although I hate it).
- --Matthiaspaul (talk) 10:38, 17 August 2021 (UTC)
- Don't edit other editors' posts. I have restored the U+2019 character.
- —Trappist the monk (talk) 11:51, 17 August 2021 (UTC)
- Sorry, that was completely unintentional - AGF, it should have been obvious that this was just a mistake. I used the preview to experiment with different characters inserted into the citation, got distracted with something else, and simply overlooked the changed character when I wrote my comment later on...
- --Matthiaspaul (talk) 12:51, 17 August 2021 (UTC)
Fixed in the sandbox.
| Wikitext | {{cite journal
|
|---|---|
| Live | O'Mullane DM (2016). "Fluoride and Oral Health". Community Dental Health (33): 69–99. doi:10.1922/CDH_3707O’Mullane31. |
| Sandbox | O'Mullane DM (2016). "Fluoride and Oral Health". Community Dental Health (33): 69–99. doi:10.1922/CDH_3707O’Mullane31. |
—Trappist the monk (talk) 11:51, 17 August 2021 (UTC)
- There are probably other string functions we should be using mw.ustring for instead. You might consider having a general look. Izno (talk) 16:38, 17 August 2021 (UTC)
Date quarters
Some publications give a date as year and quarter, but, e.g., |date=3Q 1984, yields an error message:
"foo" (Document). 3Q 1984.
{{cite document}}: Check date values in:|date=(help); Cite document requires|publisher=(help)
Is there a legitimate way to enter a quarter in |date=? --Shmuel (Seymour J.) Metz Username:Chatul (talk) 14:49, 16 August 2021 (UTC)
{{cite journal |title=foo |journal=Journal |date=Third Quarter 1984}}- "foo". Journal. Third Quarter 1984.
- —Trappist the monk (talk) 15:29, 16 August 2021 (UTC)
- But be prepared for a strange result when the author name is provided
- Doe, John (Third Quarter 1984). "The unbearable brightness of fooing". Journal of Forensic Fooology.
- which is far from ideal. Would Chatul be better advised to use
issue=rather than (or even as well as)date=?{{cite journal |title= The unbearable brightness of fooing |journal=Journal of Forensic Fooology |date=1984 |issue=Third Quarter 1984 |first=John |last=Doe}}
- which yields
- Doe, John (1984). "The unbearable brightness of fooing". Journal of Forensic Fooology (Third Quarter 1984).
- which I suspect is what Chatul might prefer (and be more convenient to use with {{harv}} or {{sfn}}. --John Maynard Friedman (talk) 16:48, 16 August 2021 (UTC)
- No. The date parameter was specifically changed in the past year or so to accept quarterly dates. Your opinion on the appearance is, uh, noted elsewhere. Izno (talk) 18:34, 16 August 2021 (UTC)
- @Izno: It is not just my opinion. I don't have access to Cite them right, but this document from Library Services at London Metropolitan University says that it is based on Pears, R; Shields, G (2013). Cite them right: the essential referencing guide (9th ed.). Basingstoke: Palgrave Macmillan.:
Some journals use the month or season of publication, or just a number instead of the volume and issue numbers. Enter these details after the journal title in your reference list.
- (my emphasis).[1] I have never, ever, seen a citation that looks like Izno (Spring-Summer 1821); every case I have found is simply Izno (1821). Maybe you have access and there is a case in point? I am very happy to be put right if I am mistaken. --John Maynard Friedman (talk) 15:07, 18 August 2021 (UTC)
- cs1|2 is not beholden to Cite them right: the essential referencing guide or to Chicago Manual of Style or to any other style guide. In cs1|2 'style', when an author list is present, the publication date (
|date=or|year=) is rendered after the author list. It has been thus since forever. Editors at en.wiki commonly provide seasonal dates:- Spring: ~8600 hits (search times out)
- Summer: ~7400 hits (search times out)
- Winter: ~5000 hits (search times out)
- Fall: ~6300 hits (search times out)
- Autumn: ~3700 (search times out)
- and they even provide seasonal ranges:
- there are other combinations that I leave to the reader.
- —Trappist the monk (talk) 15:45, 18 August 2021 (UTC)
- cs1|2 is not beholden to Cite them right: the essential referencing guide or to Chicago Manual of Style or to any other style guide. In cs1|2 'style', when an author list is present, the publication date (
- And anyway, sfn/harv will still be put in as the year. Izno (talk) 18:38, 16 August 2021 (UTC)
- Where is
|date=ordinal quarter yeardocumented? Shouldn't it be included in the table of examples? --Shmuel (Seymour J.) Metz Username:Chatul (talk) 16:56, 17 August 2021 (UTC)- They are documented at Help:Citation_Style_1#Dates. I have added them to the error help as well. --Matthiaspaul (talk) 17:42, 17 August 2021 (UTC)
- I've added examples at Wikipedia:Manual of Style/Dates and numbers#Formats; do they look okay? --Shmuel (Seymour J.) Metz Username:Chatul (talk) 02:30, 18 August 2021 (UTC)
- I'm not convinced that the new examples belong in those two tables. MOS:DATES and those two tables were written to govern dates in article prose. cs1|2 has adopted MOS:DATES as the standard that governs date formats in the templates but cs1|2 does not have any authority to write the rules for article prose. Quarterly dates in article prose are not obliged to adhere to cs1|2 format rules. I think that the examples should be removed until there is a consensus at MOS:DATES to require a particular quarterly date format in article prose.
- —Trappist the monk (talk) 12:59, 18 August 2021 (UTC)
- I've added examples at Wikipedia:Manual of Style/Dates and numbers#Formats; do they look okay? --Shmuel (Seymour J.) Metz Username:Chatul (talk) 02:30, 18 August 2021 (UTC)
- They are documented at Help:Citation_Style_1#Dates. I have added them to the error help as well. --Matthiaspaul (talk) 17:42, 17 August 2021 (UTC)
- No. The date parameter was specifically changed in the past year or so to accept quarterly dates. Your opinion on the appearance is, uh, noted elsewhere. Izno (talk) 18:34, 16 August 2021 (UTC)
- But be prepared for a strange result when the author name is provided
References
- ^ Library Services (February 2016). "Harvard Referencing Guide" (PDF). London Metropolitan University. Retrieved 18 August 2021. (Section: Journal articles – print and electronic)
Push PMID limit up
- Donders, T.; Panagiotopoulos, K.; Koutsodendris, A.; Bertini, A.; Mercuri, A. M.; Masi, A.; Combourieu-Nebout, N.; Joannin, S.; Kouli, K.; Kousis, I.; Peyron, O.; Torri, P.; Florenzano, A.; Francke, A.; Wagner, B.; Sadori, L. (2021). "1.36 million years of Mediterranean forest refugium dynamics in response to glacial–interglacial cycle strength". Proceedings of the National Academy of Sciences of the United States of America. 118 (34): e2026111118. doi:10.1073/pnas.2026111118. PMID 34400496.
This should not throw an error. Headbomb {t · c · p · b} 03:52, 18 August 2021 (UTC)
Multiple URLs (split file)
We have this ref at United Airlines Flight 175
- Federal Bureau of Investigation (February 4, 2008). "Hijackers' Timeline" (PDF). NEFA Foundation. Archived from the original (PDF) on October 12, 2008. Retrieved October 6, 2008.
It's cited to a page on "NEFA Foundation", which isn't exactly reliable, but the report is the FBI's. The same report can be found on their website, but split into two portions (part-01-of-02, part-02-of-02) (perhaps for file size reasons). FBI site: [2][3]. How can we use the URLs from fbi.gov directly, but only using one cite tag? ProcrastinatingReader (talk) 13:54, 15 August 2021 (UTC)
- cs1|2 templates are designed to cite one source at a time. In United Airlines Flight 175, pages 218, 261, and 288 are the only pages cited in that report so the FBI part 2 source is all that is needed:
{{cite web |url=https://vault.fbi.gov/9-11%20Commission%20Report/9-11-chronology-part-02-of-02/ |title=Hijackers' Timeline (Redacted) (part 2 of 2) |website=Federal Bureau of Investigation |date=November 14, 2003 |access-date= |ref={{sfnref|''Federal Bureau of Investigation''|2003}}}}- "Hijackers' Timeline (Redacted) (part 2 of 2)". Federal Bureau of Investigation. November 14, 2003.
- You could include a link to part 1 of 2 under §Further reading if it is important.
- —Trappist the monk (talk) 14:55, 15 August 2021 (UTC)
- If I run into this situation, I typically append such extra links as raw URLs in square brackets (without title) to the end of the citation, that is, between the template's closing
}}brackets and Mediawiki's closing</ref>tag: [4][5] - Most often, such extra links are only meant to help prevent future link rot, so I want them to be rendered as short and unobtrusive as possible and deliberately don't add titles so that they don't consume much extra space in the reference. Since they are outside of the template's special handling for archived links, I typically choose archived links for them if available.
- If the source is available only in form of individual PDFs on a per-page basis, the links are probably better worked into the
|pages=parameter instead. - When the source is splitted over several multi-page-files (as in your example) and the reference is citing multiple pages distributed over several files, splitting the reference into multiple citations (as indirectly suggested by Trappist above) is certainly an option, but in most cases I find references to the same source (but page numbers) in multiple citations are adding too much redundancy and I therefore try to combine them into a single reference including such appended raw links.
- Not ideal, but there isn't much the templates could do to improve this situation because there is only one title. The only thing that could be improved by having multiple numbered
|urln=parameters would be that the extra links could be displayed immediately following the title instead of at the end of the main citation, like: - But still, display of dates and handling of archive links would only work for the main link, and metadata creation would be more complicated. Not sure if this would be worth it.
- --Matthiaspaul (talk) 21:43, 15 August 2021 (UTC)
- Abusing the
|type=parameter (which does not become part of the COinS metadata) could be used to produce a more reasonable rendering of multiple links - without solving the underlying problems with handling multiple dates and archive links, of course. However, while the current live version of the template does not produce any error message, the sandboxed version will throw an "External link in |type=" error (per Help_talk:Citation_Style_1/Archive_77#url_in_name_parameters). For illustration purposes only:- Federal Bureau of Investigation (2008-02-04). "Hijackers' Timeline" (PDF) (III). NEFA Foundation. Archived from the original (PDF) on 2008-10-12. Retrieved 2008-10-06.
{{cite web}}: External link in|type=
- Federal Bureau of Investigation (2008-02-04). "Hijackers' Timeline" (PDF) (III). NEFA Foundation. Archived from the original (PDF) on 2008-10-12. Retrieved 2008-10-06.
- Related topic: Help_talk:Citation_Style_1#How_to_extlink_the_components_of_a_multi-component_publication
- So, if we would want to add some limited support for multiple links, it could be implemented similar to
|type=. Perhaps this could be combined with the rendering of what an already proposed|part=parameter would produce (if we would allow external links there). - --Matthiaspaul (talk) 03:48, 17 August 2021 (UTC)
Support for slash in some date ranges?
Inspired by the discussion at Help_talk:Citation_Style_1#Undesirable_behaviour_of_issue=_in_cite_magazine_when_the_issue_is_a_month_or_months, I wonder if we should add support for two more date range formats allowed by our MOS, but not supported by CS1/CS2 at present:
Ranges with consecutive month names or years separated by "/" instead of "–". At present, they have to be "converted" into en-dash ranges:
- "November/December 2020" → "November–December 2020"
- "2020/2021" → "2020–2021"
For as long as only (non-digit) month names and/or 4-digit years are involved they appear to be free from any possible ambiguities.
The reason why it might be good to support them in citations is that, in the context of publications, if date ranges are used at all, they most often involve consecutive (weeks,) months or years, and if they are printed on a publications' cover, most often slashes are used rather than en-dashes, so a slash would look more "natural" in a citation when citing from, i.e., a bimonthly publication. It may also make entry of those ranges easier.
--Matthiaspaul (talk) 17:32, 17 August 2021 (UTC)
- Your first step would be to change MOS:DATERANGE. – Jonesey95 (talk) 20:34, 17 August 2021 (UTC)
- For the purposes of determining if adding support for this would be found useful, please assume MOS support to be a given.
- Actually, the slash is one of the explictly allowed formats already for year ranges with consecutive years, so no changes to the MOS would be required:
- "The slash notation (2005/2006) may be used to signify a fiscal year or other special period, if that convention is used in reliable sources"
- "fiscal year or other special period in reliable sources" is exactly where we would use this in citations, that is, when the source uses this format as well (else we have little need to use it).
- And somewhat further down:
- "An overnight period may be expressed using a slash between two contiguous dates: the night raids of 30/31 May 1942 or raids of 31 May / 1 June 1942."
- By extension and because it is not mentioned as disallowed, this would apply to consecutive months as well.
- I have never seen consecutive days being used in publication dates, but consecutive months separated by a slash are quite common in bimonthly publications and special issues. I have very rarely seen endashes being used there, hence this proposal.
- --Matthiaspaul (talk) 21:51, 17 August 2021 (UTC)
a given
No, that's a waste of our time to entertain the idea. Please get support there first. Izno (talk) 21:53, 17 August 2021 (UTC)- Reliable sources, for the purposes of citations, are either our MOS directly or other style/citation guides, not reliable sources for a specific domain as with TNYT or a specific journal source.
- Regarding slash between contiguous dates, that has a key word: "overnight". The examples are clearly not relevant. Izno (talk) 21:56, 17 August 2021 (UTC)
- I recommend that the OP dig through the MOS talk page archives to find the origin of the support for the slash notation, which clearly means "one part of one period, connected to a contiguous part of a subsequent period", like July 2005 through June 2006 for a fiscal year, or 9 pm on 30 May through 5 am on 31 May for a "night of". The slash notation is clearly not applicable to a range covering two full time periods, like November–December, which is what the date of a periodical intends. To say it another way, you could have "the nights of 29/30 May and 30/31 May" as acceptable usage, but not "the magazine issues for October/November 2005 and November/December 2005". – Jonesey95 (talk) 00:51, 18 August 2021 (UTC)
- Jonesey, thanks for taking up this discussion constructively. You are bringing up an interesting aspect.
- I can't see these implied differences being made in the relevant MOS text, but from my personal experience I agree that the slash notation has multiple implied meanings whereas the en-dash notation almost always means a complete period.
- However, if these differences are real, it would be even less desirable to blindly convert "2020/2021" or "November/December 2020" found in a source into "2020–2021" or "November–December 2020" in a citation (as we currently have to do because CS1/CS2 does not support the slash notation). Depending on circumstances it could change the meaning considerably and thereby invalidate the citation. If we do not know exactly what it means in a particular context, it is best to just use what is used in the source, similar to keeping a "Christmas 2020" date designation "as is" in a citation instead of trying to convert this into a specific date - because even in the Western world it could refer to the 2020-12-23, 2020-12-24, 2020-12-25 or 2020-12-26 or various combinations thereof (and in most cases the actual publication date would be several days earlier, anyway).
- --Matthiaspaul (talk) 02:29, 18 August 2021 (UTC)
- I recommend that the OP dig through the MOS talk page archives to find the origin of the support for the slash notation, which clearly means "one part of one period, connected to a contiguous part of a subsequent period", like July 2005 through June 2006 for a fiscal year, or 9 pm on 30 May through 5 am on 31 May for a "night of". The slash notation is clearly not applicable to a range covering two full time periods, like November–December, which is what the date of a periodical intends. To say it another way, you could have "the nights of 29/30 May and 30/31 May" as acceptable usage, but not "the magazine issues for October/November 2005 and November/December 2005". – Jonesey95 (talk) 00:51, 18 August 2021 (UTC)
- I, too, often find the date and issue CS1 rules too restrictive. If we remember that the whole purpose of bibliographical references is to provide the most complete and unambiguous link to the source, then if the source says "July/August 2021 issue", that is exacly how you would find it on the shelf in your library. In this case, July/August means "July and August" issue, so it is not a MOS:DATERANGE thing (July to August issue does not sound right, right?). Example here (title:&, text: /, and). In the past, a slash was used instead of today's comma, meaning "and" or "or". What gives us right to say Vanity Fair, Vogue, Elle, The Architectural Review, Dwell, Smithsonian Magazine, Men's Health, BA, The Atlantic (…) are all wrong and should be corrected to use an en-dash instead of their forward slashes? Ponor (talk) 02:56, 18 August 2021 (UTC)
- Citations are not bibliographic references. Also, any contiguous dates/date elements taken together constitute a time interval (range) irrespective of their separator. "July and August" is a range. The norm in CS1 has been to follow Wikipedia's MOS when possible, including the presentation of date ranges, although there are significant exceptions. But the date field in any citation system does not have to be presented verbatim. As long as the correct data is input in some form the work will be found by date, Date indices do not index text strings, but date data formatted according to masks/templates that may include ranges and the like. You would be just as likely to find a "July/August" item as a "July–August" item. The significant info, which indices understand, is "July" (in proximity, {AND/OR}) to "August". The separator used in the literal expression is a matter of presentation. 24.103.251.114 (talk) 12:16, 18 August 2021 (UTC)
- The bigger question is why do people expect that the templated CS1 solutions will apply to every case they can think of, and generally solve all problems. Where does this expectation come from? It is not as if these templates are obligatory. Development-wise such minor issues of presentation like the object of this thread are very much secondary. There are far more substantial development issues that may be tackled. Although, if I was a developer here I wouldn't lift a finger to cross a t. In this environment developers are expected to justify use of tracking elements. Any serious programmer would laugh you out of the room :) 24.103.251.114 (talk) 12:30, 18 August 2021 (UTC)
- I don't know what citations and bibliographical references are to you, we're discussing the latter. Those who (actually) write Wikipedia articles will find sources that have "July/August 2021" as their publication date, and will (not knowing the ""correct"" way) try to use them verbatim:
- "Laughter". Journal of Serious Programmers. July/August 2021.
{{cite journal}}: Check date values in:|date=(help).
- "Laughter". Journal of Serious Programmers. July/August 2021.
- See what happens here, see all the redness? It says it's wrong, even though it's not. This is a citation template (producing a bibl. reference) being smarter than the editor in a pretty common use case. That's not nice, just as it's not nice to be laughed at by a bunch of serious programmers... but I see that as their problem, not mine. Ponor (talk) 13:22, 18 August 2021 (UTC)
- CS1 is its own style regarding dates which comes out of WP:MOSDATE. I do not see anyone laughing at you. We have instead pointed you to the correct location if you should want to change that style. Izno (talk) 14:40, 18 August 2021 (UTC)
- The documentation, with all its problems, nevertheless clearly lays out what is right and wrong in the context of the non-obligatory CS1 templates. If you wish to use these templates, follow the guidelines. A bibliographical reference is information about a certain work. It usually includes a wealth of detail (depending on the bibliographic database) about the provenance, publishing history, editions etc. of the work. A citation in Wikipedia is information about quickly and easily locating a source in order to verify claims in wikitext. It is a different kind of animal. Those people who write articles in Wikipedia without reading the pertinent documentation will see all kinds of red messages. As for this minor issue, first clear it at MOS:DATERANGE. Don't "interpret" what is being stated regarding slashes and ranges, get an explicit answer. Then we can further discuss it here. I will add to Izno's comment: nobody is laughing at you, and the comment was referring to something else. It's not about you. 65.88.88.126 (talk) 15:45, 18 August 2021 (UTC)
- So according to you, 24.103.251.114 or 65.88.88.126 or ???, nothing should ever be discussed on this page because CS1 templates are non-obligatory. Use them as they are or leave? What a bureaucratic argument, I'd never expect that from an Wikipedian. I think you're confusing bibliographical references with Bibliographic records (note wikilinks). Also, a Citation is only a little (inline) pointer to the full reference, even Wikipedia can teach us that. My argument is that WP:MOS should not apply to bibliographic data, because those data are used to locate sources. You wouldn't correct this title "Everything You Need to Know About the July/August Issue of ‘Men’s Fitness,’ Starring M…." would you? So why enforce July–August when that's not what you'd find in your library? Minor or not, it's an issue. Discussing it is non-obligatory. But whoever wants to discuss it, and has time to discuss it, and doesn't feel it's waste of her time to discuss it, should discuss it with arguments other than "waste of our time", "go change WP:MOS first"... That's not how Consensus is built. I'm sorry, but no one has answered any of Matthiaspaul's or my concerns yet. Ponor (talk) 02:31, 20 August 2021 (UTC)
- I believe you misunderstand everything stated in the previous post, and that's fine. What is not fine is that you presume to know the motivation and thinking of others and then proceed on that presumption to make judgements and accusations out of thin air. That, coupled with putting your words on somebody else's mouth. A point-by-point rebuttal could be made, but what for? 64.18.10.208 (talk) 04:11, 20 August 2021 (UTC)
non-English translator templates and substing
I have hacked an experiment to make {{literatur/sandbox}} invoke a lua module. That is discussed at Template talk:Literatur § lua module experiment.
Because that template is supposed to be subst'd when used, for the experimental module to work with the live Module:Citation/CS1, it will be necessary to change {{citation}} as I did to {{citation/new}} with this edit. Without that change, the subst returns the content of the citation template:
{{#invoke:citation/CS1/sandbox|citation |CitationClass=citation }}
and that is a pretty much pointless {{citation}}: Empty citation (help).
If the {{literatur/sandbox}} experiment is successful, then it makes some sense to do the same thing for other translation templates:
{{Cita news}}– requires the subst fix for{{cite news}}and{{cite book}}{{Cita libro}}– requires the subst fix for{{cite book}}{{Cite web/German}}– these require the subst fix for{{cite web}}{{Cite web/Finnish}}{{Cite web/Swedish}}{{Cite web/Portuguese}}{{Cite web/Danish}}{{Cite web/French}}{{Cite web/Polish}}
no doubt there are other translation templates (some of this list I found in Category:Infobox importer templates – why there?) You might think that there is a subcategory in Category:Citation Style 1 templates for translation templates ... There isn't.
So, I propose to modify {{citation}}, {{cite book}}, {{cite news}}, and {{cite web}} so that translation templates can be subst'd.
Opinions? Objections?
—Trappist the monk (talk) 20:03, 19 August 2021 (UTC)
- Please test the change on one or another of the larger articles in existence (we really should have a list of go-tos) to establish that parser/expansion times are not problematically increased. Izno (talk) 14:57, 20 August 2021 (UTC)
- Alas, that will be a problem. I don't know where one might find a large article with only
{{citation}}templates so I created a test page (not saved) that had 1000 of this (grabbed from Module:Citation/CS1/testcases):{{citation| url=http://books.google.ca/books?id=WrkzPcxBnLMC |title=Takhta untuk Rakyat: Celah-celah Kehidupan Sultan Hamengku Buwono IX |trans-title=Serving the People: The Life Story of Sultan Hamengku Buwono IX |language=Indonesian |isbn=978-979-22-6767-9 |editor1-first=Mohamad |editor1-last=Roem |editor1-link=Mohamad Roem |editor2-first=Mochtar |editor2-last=Lubis |editor2-link=Mochtar Lubis |editor3-first=Kustiniyati |editor3-last=Mochtar |editor4-first=Maimoen |editor4-last=S. |last=Nasution |first=A. H. |author-link=Abdul Haris Nasution |publisher=Gramedia Pustaka Utama |location=Jakarta |year=2011 |origyear=1982 |edition=Revised}}
- Previewing that page rendered 930 templates before post‐expand include size limit was exceeded. The various times from the NewPP limit report were:
- CPU time usage: 8.633 seconds
- Real time usage: 8.611 seconds
- Lua time usage: 6.165/10.000 seconds
- and the Transclusion expansion time report (%,ms,calls,template)
- 100.00% 6926.279 1 -total
- 98.66% 6833.462 1000 Template:Citation
- Then I changed the 1000
{{citation}}templates to{{citation/new}}. Previewing the page again, only 604 template rendered before post‐expand include size limit was exceeded. The various times from the NewPP limit report were:- CPU time usage: 13.342 seconds
- Real time usage: 13.380 seconds
- Lua time usage: 10.026/10.000 seconds
- and the Transclusion expansion time report (%,ms,calls,template)
- 100.00% 11348.237 1 -total
- 98.16% 11139.520 1000 Template:Citation/new
- I tried an experiment where I used
{{ifsubst}}to choose between the subst'd form of the#invokeand the un-subst'd form- CPU time usage: 12.853 seconds
- Real time usage: 12.828 seconds
- Lua time usage: 9.639/10.000 seconds
- and the Transclusion expansion time report (%,ms,calls,template)
- 100.00% 11316.758 1 -total
- 98.57% 11154.984 1000 Template:Citation/new
- 94.54% 10698.378 1000 Template:Ifsubst
- I have removed the experiment so timing for
{{citation/new}}is:- CPU time usage: 9.469 seconds
- Real time usage: 9.441 seconds
- Lua time usage: 6.951/10.000 seconds
- and Transclusion expansion time report (%,ms,calls,template)
- 100.00% 7732.135 1 -total
- 98.69% 7630.937 1000 Template:Citation/new
- So, I guess that we can say that for now, any module-based translation templates must not be subst'd.
- I wonder if it's possible to have a
{{citation/subst}}template that the translation template could call. The inside of that template would have the substable version of the Module:Citation/CS1#invokeso when subst'd, would return a normal{{citation}}template except with the{{citation/subst}}name. If subst'd we might include a maint cat so that{{citation/subst}}might be manually tweaked back to{{citation}}. Perhaps a tweak to Module:Unsubst to add an expicit template-name override parameter to that would be in order... I'll ponder these ideas. For now, the subst experiment at{{citation/new}}has been reverted. - —Trappist the monk (talk) 17:14, 20 August 2021 (UTC)
- Created
{{citation/subst}}which can be called by the translator module. Without modification to Module:Unsubst, the resulting substitution of a{{Literatur/sandbox}}template is a{{citation/subst}}template. I have tweaked Module:Unsubst/sandbox so that{{citation/subst}}can supply an alternate name (in the current case,|$template-name=citation). When substing a{{Literatur/sandbox}}template using the Unsubst sandbox, the resulting substitution is a{{citation}}template. This, I think, solves the problem because{{citation/subst}}is only called by translation templates that need substing and then once subst'd, the template is a normal cs1|2 template. - Discussion about the change to Module:Unsubst is at Module talk:Unsubst § template invocation name override.
- —Trappist the monk (talk) 18:30, 20 August 2021 (UTC)
- Created
- Alas, that will be a problem. I don't know where one might find a large article with only
- I created a subcat for citation translation templates under Category:Citation Style 1 translation templates
- --Matthiaspaul (talk) 10:02, 21 August 2021 (UTC)
Permanent errors
- Note: I originally posted this[6] at Template talk:Citation, but moved it here 'cos I think this is a more appropraite location.
Category:CS1 errors: unsupported parameter includes 22 pages in the Wikipedia namespace: 14 AFD pages, and 8 pages from the Signpost.
These pages should not be edited, so they are perma-clutter in this cleanup category.
Please can the CS1/2 module(s) be modified to stop categorising citation errors in these pages? Cleanup categories should be capable of being fully cleaned up, but the inclusion of these pages prevents that. --BrownHairedGirl (talk) • (contribs) 01:47, 21 August 2021 (UTC)
- I think minor formatting corrections that do not change the actual discussion text are allowed on closed AfDs. —David Eppstein (talk) 02:21, 21 August 2021 (UTC)
- Thanks, @David Eppstein. I corrected two of them, but after a re-think, I reckoned it might cause grief, so I gave up. I will re-start.
- Do you think the same applies to the Signpost pages? --BrownHairedGirl (talk) • (contribs) 02:26, 21 August 2021 (UTC)
- Typos are routinely fixed on Signpost pages; cleaning up unsupported parameters should be uncontroversial. isaacl (talk) 02:49, 21 August 2021 (UTC)
- Unless changing the citation parameters would undermine the illustration of a problem or the flow of arguments in threads about CS1/CS2 citation template issues themselves, cleaning up such errors "under the hood" can only help to restore the former display of a citation and thereby preserve its original meaning or intention, so it is helpful maintenance not controversial.
- When I (have to) edit such pages I leave a HTML comment near the change indicating what was changed and why.
- If the problem can't be fixed by adjusting the template parameters (for example because this would change the meaning of arguments), an alternative to actually fixing the problem is to disable the template's categorization by adding a
|no-tracking=yesparameter to the offending citation. But this requires editing as well, of course. - --Matthiaspaul (talk) 07:35, 21 August 2021 (UTC)
- The simple fix is
|no-tracking=yes. It leaves the citation template as it was, shows the error messages, but keeps the page out of error categories. - —Trappist the monk (talk) 12:00, 21 August 2021 (UTC)
- Many thanks, Trappist the monk.
|no-tracking=yesis the least intrusive solution, so I will do that. --BrownHairedGirl (talk) • (contribs) 18:02, 21 August 2021 (UTC)- All those pages have now been cleared from the category. --BrownHairedGirl (talk) • (contribs) 18:38, 21 August 2021 (UTC)
- I routinely correct the kinds of pages in question and have had only one editor be annoyed (after which I explained that it was fine for various reasons, and he assented). Izno (talk) 15:43, 21 August 2021 (UTC)
Reftag error messages
Hello, http://reftag.appspot.com/ has been generating this error message for most of this week. Reftag shortens a googlebook url and usually provides the complete cite book reference, including ISBN. Reftag is mentioned in See also at the end of this article Template:Cite book. It is also the topic of this article here.
Error: Server Error The server encountered an error and could not complete your request.
Please try again in 30 seconds.
Nothing improves in 30 seconds or 3 days. Has the link for this helpful tool in Cite Book format been changed?
Thanks. --Prairieplant (talk) 04:07, 21 August 2021 (UTC)
- Unfortunately, we can't help you with that one here. This is not a CS1/CS2 citation template issue, but related to an external tool out of our control. You will have to ask the maintainer of the tool for help, who fortunately happens to have a Wikipedia account at User talk:Apoc2400. --Matthiaspaul (talk) 07:48, 21 August 2021 (UTC)
- Thank you for the link to Apoc2400. I have left a message at the talk page, and it turns out I am the second person to mention these error messages when trying to use the citation tool. --Prairieplant (talk) 04:40, 23 August 2021 (UTC)
Template:Cite_serial#In-source_locations
Template:Cite_serial#In-source_locations says that |season= is a supported parameter.
But at Amy's Choice (Doctor Who)#Continuity (permalink to current version), two refs using |season= are throwing a error:
- Russell T Davies (writer), Euros Lyn (director) (25 December 2009 – 1 January 2010). The End of Time. Doctor Who. BBC. BBC One.
{{cite serial}}: Unknown parameter|season=ignored (|date=suggested) (help) - Robert Holmes (writer), Peter Moffatt (director) (16 February – 2 March 1985). The Two Doctors. Doctor Who. BBC. BBC One.
{{cite serial}}: Unknown parameter|season=ignored (|date=suggested) (help)
How can this be fixed? --BrownHairedGirl (talk) • (contribs) 02:59, 22 August 2021 (UTC)
- Try using
|series=instead? In any case, this is the correct term for post-revival Doctor Who, see WP:WHO/MOS#Terminology. --Redrose64 🌹 (talk) 07:31, 22 August 2021 (UTC)- @Redrose64: see the examples above.
|series=is already in use. - I have no interest in the topic. This is just drive-by maintenance.
- I just want to get the citations to display the contents of each param to the citation, and thereby remove the page from Category:CS1 errors: unsupported parameter. The documentation says the current setup should work, but it doesn't
--BrownHairedGirl (talk) • (contribs) 10:38, 22 August 2021 (UTC)
- @Redrose64: see the examples above.
- Support for
|season=was withdrawn from{{cite serial}}with this edit which updated the wikitext version of the template to use{{citation/core}}. - I have updated the
{{cite serial}}doc. - —Trappist the monk (talk) 11:08, 22 August 2021 (UTC)
- @Trappist the monk: thanks. --BrownHairedGirl (talk) • (contribs) 23:11, 23 August 2021 (UTC)
Undesirable behaviour of issue= in cite magazine when the issue is a month or months
No doubt this is in the archives but I can't find it. Take for example this citation:
- Paul Lunde. "The Beginning of Hijri calendar". Saudi Aramco World Magazine. No. November/December 2005. Retrieved 1 January 2019.
The issue is "November/December 2005", it is nonsense to show it as "no. November/December 2005". The same problem would occur with "issue=Spring 2021" etc. Surely in the case where issues are numbered, the correct argument to use is "number="? How does it make sense to add a "no." prefix to "issue"? --John Maynard Friedman (talk) 09:46, 12 August 2021 (UTC)
- Aren't those better handled as dates? (Doing so would require changing November/December to November–December)Nigel Ish (talk) 10:56, 12 August 2021 (UTC)
- Agreed. In such cases, issues are dated, not numbered. 100.2.235.66 (talk) 11:46, 12 August 2021 (UTC)
- No, that gives a very ugly result:
- Paul Lunde (November–December 2005). "The Beginning of Hijri calendar". Saudi Aramco World Magazine. Retrieved 1 January 2019.
- which I admit is used and works fine for {{cite news}}. In this example, the 'issue=' setting puts the information in the logical place (after the title) in the citation: the only problem is that addition of the inappropriate 'no.' Why is that intrusion ever needed?
- Using (a test) number= gives
- Paul Lunde. "The Beginning of Hijri calendar". Saudi Aramco World Magazine. No. 567. Retrieved 1 January 2019.
- where the element is positioned logically and the insertion of 'No.' is entirely appropriate. --John Maynard Friedman (talk) 13:24, 12 August 2021 (UTC)
- Here is the pdf of the Saudi Aramco World magazine issue in question. Note that this issue is volume 56 number 6 and the date is November/December 2005 so:
{{cite magazine |url=https://archive.aramcoworld.com/pdf/2000/200506.pdf |title=Patterns of Moon, Patterns of Sun |first=Paul |last=Lunde |magazine=Saudi Aramco World |date=November–December 2005 |volume=56 |issue=6 |access-date=2021-08-12}}- Lunde, Paul (November–December 2005). "Patterns of Moon, Patterns of Sun" (PDF). Saudi Aramco World. Vol. 56, no. 6. Retrieved 2021-08-12.
- —Trappist the monk (talk) 14:04, 12 August 2021 (UTC)
- Touché! I shall go and stand in the corner for the rest of the class for not having checked a citation after I cleaned it up.
- BTW, why did you use "issue=6" and not "number=6"? Are they in fact synonymous, two names for the same bit of programming? If so, then that would explain everything and it will be obvious that my proposal (that
issue=should not insert No. ) must get spiked. --John Maynard Friedman (talk) 17:51, 13 August 2021 (UTC)|issue=and|number=are aliases.- —Trappist the monk (talk) 18:11, 13 August 2021 (UTC)
- @John Maynard Friedman: Further to what Trappist wrote, the documentation explicitly shows that
|number=is an alias for|issue=. So they must be expected to behave identically. --Redrose64 🌹 (talk) 22:56, 13 August 2021 (UTC)- @Redrose64: Add failure to RTFM to my sins. Detention as well for my pains.
- (But they should be different, they have different meanings, so it was not just a lazy assumption. [xref Matthias P remark below]. In my sample citation, the issue is November/December, the number is 6. The date of publication is most likely to have been October. Most "in your local newsagent" magazines come out best part of a month before their declared issue date .) --John Maynard Friedman (talk) 23:23, 13 August 2021 (UTC)
- @John Maynard Friedman: Further to what Trappist wrote, the documentation explicitly shows that
- (edit-conflict)
|issue=6is not wrong at present, but|number=6would be better in this case to improve forward compatibility. At present, both parameters are treated as aliases and produce identical output. But different periodicals use different nomenclatures. It is therefore a good idea to use|issue=when the publication uses "Issues" as well, and|number=when they use "Numbers", so that the template can adapt and generate the appropriate prefix "Iss." or "No.". If the publication itself does not prescribe a certain nomenclature, it is best to use issues for volume-relative numbering schemes (as well as non-numeric issue names/titles) and number for absolute numbering schemes (because that's what most periodicals use - but not all). - Also, when we will finally add support for periodicals featuring both, a number and an issue (requested multiple times and planned for a long while), we will have to better distinguish between them to generate the proper output.
- As discussed above, a date belongs into the
|date=parameter, but there are cases where issues have actual names or titles. This still looks reasonably good in conjunction with|issue=("Special issue") but not with|number=. - --Matthiaspaul (talk) 18:23, 13 August 2021 (UTC)
- I suggest you put aside notions of "ugly". Most citation systems use terse, functional statements. Aesthetics rarely if at all enter the discussion. That doesn't mean that formatting cannot be improved, but such improvement must primarily enhance understanding and utility. 64.18.9.209 (talk) 14:32, 12 August 2021 (UTC)
- I think that misses the point. The description "November/December 2005" is an adjectival phrase that relates to the magazine, not to the author. Fine, forget "ugly": let's be honest and say "amateurish". --John Maynard Friedman (talk) 17:51, 13 August 2021 (UTC)
- That part of the style is consistent with the academic citation styles on which it is based.Nigel Ish (talk) 18:03, 13 August 2021 (UTC)
- Well, the entire Wikipedia citation ecosystem, including CS1/2 has many, many faults in design, implementation, and documentation, not all which stem from misconceptions of what a citation system geared to non-expert users (readers) should be. But this case is fairly straightforward and easily addressable. The issue number and/or date are useful in locating the source, and if known should be made available, in a way that is obvious and clear. If the issue series is dated rather than numbered, use that information anywhere it makes sense. There is nothing wrong, ugly or amateurish in entering the issue date in the date field. This is correct. The formatting of the date itself is a different issue and does not affect the needed data. 69.193.187.30 (talk) 21:19, 13 August 2021 (UTC)
- There may be nothing wrong with entering the issue date in the date field, but there are occasional instances when it won't work; notably, when journals use wacky dates like "Michaelmas" and "Trinity" for their issues [7]. —David Eppstein (talk) 21:36, 13 August 2021 (UTC)
- OK, some magical process will turn static forms that apply certain generic positional & formatting rules - the so-called CS1/CS2 citation statements - into dymamic AI appliances that will perfectly account for every single special case under the sun, no matter how rare. Even though the current existing non-magical documentation at least hints otherwise, and even though 1. templates are not the only way to present CS1/CS2 citations and 2. CS1/2 citations are not the only way to reference. 68.173.76.118 (talk) 22:27, 13 August 2021 (UTC)
- The templates can already accommodate some "non-date dates" - i.e. seasons, Easter and Christmas according to Help:Citation_Style_1#Dates - whether the templates are modified to accommodate others will depend on how often they are used.Nigel Ish (talk) 11:03, 16 August 2021 (UTC)
- I think for this to be useful, we should support more or less complete sets. An editor of Christian topics would certainly wonder why s/he can enter "Christmas 2020", but not "Pentecost 2020", which both are used in clerical publications.
- https://www.ox.ac.uk/clarendon/offer-holders/clarendon-chronicle Hilary, Trinity, Michaelmas
- http://thecresset.org/archive.html Michaelmas, Advent-Christmas, Lent, Easter, Trinity
- https://web.archive.org/web/20200712075311/http://neurologicalsociety.org/journal1/index.php/clinneurosci/issue/view/1 Michaelmas
- https://heinonline.org/HOL/LandingPage?handle=hein.journals/ljusclr179&div=2&id=&page= Trinity/Michaelmas
- https://www.jstor.org/stable/155458 Qtr.
- https://www.loc.gov/standards/datetime/
- Help_talk:CS1_errors/Archive_2#Holiday_bad_date
- Help_talk:CS1_errors/Archive_2#Seasons_and_quarters_are_not_allowed_in_date_field
- Help_talk:CS1_errors/Archive_2#Quarterly_date_issues
- Help_talk:CS1_errors/Archive_3#Date_with_range_in_both_season_and_year
- Template_talk:Cite_journal/Archive_5#Citation_of_Journals_with_named_issues
- Help_talk:CS1_errors/Archive_2#Quarterly_date_issues
- Help_talk:CS1_errors/Archive_2#Seasons_and_quarters_are_not_allowed_in_date_field
- Help_talk:Citation_Style_1/Archive_3#Quarterly_periodicals
- Help_talk:Citation_Style_1/Archive_6#cite_journal_and_quarterly_publications
- Help_talk:Citation_Style_1/Archive_6#Quarterly_journal_date_format
- Help_talk:Citation_Style_1/Archive_6#Two_months_in_the_date_parameter
- Help_talk:Citation_Style_1/Archive_7#Date_parameter
- Help_talk:Citation_Style_1/Archive_8#Allow_"Quarter"_dates_in_Date_parameter?
- Help_talk:Citation_Style_1/Archive_10#Date_metadata
- Help_talk:Citation_Style_1/Archive_11#Cite_magazine_with_combined_season_date.
- Help_talk:Citation_Style_1/Archive_14#Quarterly_date_issues_(redux)
- Help_talk:Citation_Style_1/Archive_31#Multiple_years_and_seasons_in_a_date
- Help_talk:Citation_Style_1/Archive_61#Date_format_-_"Midsummer_1911"
- Help_talk:Citation_Style_1/Archive_67#Needs_exception_for_unusual-format_dates
- Help_talk:Citation_Style_1/Archive_67#Journal_with_nonstandard_date_format
- Wikipedia:Help_desk/Archives/2020_June_26#Dates_in_cite_news_template
- Help_talk:Citation_Style_1/Archive_68#named_dates:_Easter
- Help_talk:Citation_Style_1/Archive_68#Needs_exception_for_unusual-format_dates_(2)
- Help_talk:Citation_Style_1/Archive_69#Publication_date
- Let's try to come up with some list of named dates to be supported:
- Michaelmas, Martinmas, Advent, Christmas, Candlemas, Hilary, Epiphany, Lent, Easter, Pentecost, Trinity
- Midspring, Midsummer, Midautumn, Midwinter
- Carnival
- Holiday
- First Semester, Second Semester
- Winter Semester, Summer Semester
- First Quadrimester, Second Quadrimester, Third Quadrimester
- --Matthiaspaul (talk) 03:08, 18 August 2021 (UTC) (updated 13:25, 18 August 2021 (UTC), 17:54, 27 August 2021 (UTC))
- In some cases, suffixed with the word 'term', as in Michaelmas term, Easter term, Epiphany term, Hilary term, Lent term, Summer term and Trinity term. --John Maynard Friedman (talk) 20:51, 18 August 2021 (UTC)
- For this to be useful, may I suggest to stop proposing additional unnecessary complexity. Especially when there are other issues with the existing modules. Wikipedia is not a science publication or a clerical publication, or whatever your area of expertise or interest may be. There is more than enough badly presented complexity already. How many citations dated "Pentecost (year)" justify the additional coding and documentation (and for non-Christians, additional explanation)? There is
|issue=and|date=, and also|quote=where you can quote the date period verbatim. One or more of those 3 should be sufficient for a small minority of cases. 184.75.82.14 (talk) 21:35, 18 August 2021 (UTC)- I agree completely. These notations invariably indicate the issue of the periodical, not its date. But it seems that there is no consensus here for that view, despite it being the style used everywhere else. --John Maynard Friedman (talk) 22:20, 18 August 2021 (UTC)
- It would certainly be easier if this would always be the case. Unfortunately, the real world is often more complicated than this. Please read up the old discussions which led to general support for seasons, quarters and named dates in our citation templates. As you write, sometimes these names can be seen as part of the issue (and then should also be reported as named issue in
|issue=), but sometimes publications carry an|issue=in addition to a named date (and often no "normal" date at all). In these latter cases, these named dates need to be actually handled as a date in|date=, also for proper metadata generation. If not, it will become more difficult to locate these sources and obtain a copy of these publications in libraries, as they are often not found when stored under a different search key. There are even a number of dedicated COinS keys reserved for seasons (rft.ssn), quarters (rft.quarter) and named dates (rft.chron), clearly indicating that such dates are actually used in the publishing industry and that they need to be supported in the library business. - As editors of this encyclopedia, we have a duty to reproduce reference parameters as we find them (per our core policies on verifiability WP:V, neutral point of view WP:NPOV, and no original search WP:NOR), so we cannot simply "translate" a "Christmas issue" into a "December 24 issue" or a "Second Quarter issue" into an "April–June issue" just because we don't like these special dates - it would invalidate the reference making it difficult to find the publications. Also, we may be making invalid assumptions, as in some locales Christmas is in January, and quarters may start in different months depending on context.
- As developers and maintainers of our citation templates we should make sure that editors are able to create citations faithfully reflecting what they find in the sources (perhaps after some minor normalization) without having to trick the templates or fall back to non-templated citations.
- Editors like David Eppstein, Imzadi, Andy Dingley or Carcharoth have repeatedly asked to add support for them, not because they particularly "like" them, but simply because they run into them occasionally in their editing work. Many other editors don't have the stamina to come here asking but either give up on citation templates or invent unsupported workarounds which will lead to more inconsistency, more difficult maintainability, and lower accuracy and reliability.
- Commentors in this forum should seek for ways how to make life easier for readers and editors, not unnecessarily worry about (often enough incorrectly) anticipated implementation difficulties most of them cannot fathom anyway or trying to set priorities - they can leave that to the few volunteering programmers.
- What we do need your input for is when you see areas not fully or adequately covered by our templates yet and what kind of difficulties you run into or questions you might have when entering non-mainstream citations. Sharing these experiences with us will help to improve the templates and hence the quality of this encyclopedia (and quite a number of other projects taking indirectly advantage of our citations as well). Lamenting over the assumed complexity of a potential implementation does not - in the current somewhat schizophrenic situation, where people are criticizing our citation templates for non-performance in certain areas and at the same time are actively hindering the developers to implement the necessary improvements, it will only slow down the process and thereby progress as a whole. Citations are diverse and therefore complex by their underlying nature, we can't change this, but what we can help do is making it easier and more reliable to enter them anyway.
- The good news in this case is that, thanks to Trappist's great work, the infrastructure to support such special dates already exists in our templates since a couple of years (including the code for proper metadata generation), so adding more named dates does not actually add more complexity to the templates - it is, with minor exceptions, just adding more entries to an already existing table of named dates.
- --Matthiaspaul (talk) 11:34, 19 August 2021 (UTC)
- It would certainly be easier if this would always be the case. Unfortunately, the real world is often more complicated than this. Please read up the old discussions which led to general support for seasons, quarters and named dates in our citation templates. As you write, sometimes these names can be seen as part of the issue (and then should also be reported as named issue in
- I agree completely. These notations invariably indicate the issue of the periodical, not its date. But it seems that there is no consensus here for that view, despite it being the style used everywhere else. --John Maynard Friedman (talk) 22:20, 18 August 2021 (UTC)
- I think for this to be useful, we should support more or less complete sets. An editor of Christian topics would certainly wonder why s/he can enter "Christmas 2020", but not "Pentecost 2020", which both are used in clerical publications.
- There may be nothing wrong with entering the issue date in the date field, but there are occasional instances when it won't work; notably, when journals use wacky dates like "Michaelmas" and "Trinity" for their issues [7]. —David Eppstein (talk) 21:36, 13 August 2021 (UTC)
- I think that misses the point. The description "November/December 2005" is an adjectival phrase that relates to the magazine, not to the author. Fine, forget "ugly": let's be honest and say "amateurish". --John Maynard Friedman (talk) 17:51, 13 August 2021 (UTC)
- Here is the pdf of the Saudi Aramco World magazine issue in question. Note that this issue is volume 56 number 6 and the date is November/December 2005 so:
- No, that gives a very ugly result:
- Agreed. In such cases, issues are dated, not numbered. 100.2.235.66 (talk) 11:46, 12 August 2021 (UTC)
- You make several assumptions and statements above that are not based on fact. First, there are several large and small issues with the module design and with the implementation of that design. Secondly, the documentation (at all levels: for readers, editors, and developers) is hardly adequate. These existing issues should imo be addressed first.
- The policies of Wikipedia you mention apply mainly (and in some cases exclusively) to wikitext in article space. They also apply to things like having different citations that verify claims of all viewpoints present in the article, the citations mostly involving third-party sources with some past history of reliability. They do not apply to how citations themselves are structured. Instead, understandable citations are required to apply some of these policies. And that is it. Everything else: modules, templates, COins, formatting rules, etc. is irrelevant. Readers, who are Wikipedia's consumers, and the targeted recipients of its policies, do not need any of these add-ons to verify whatever nonsense one writes in article space. So, may I suggest that we make sure readers know why citations should exist. Make sure that they are presented in an understandable manner. Make sure that readers know what they consist of and why. And show them how they can verify the claims made in wikitext. Once you have a good idea about how to do all that, you can use it as the input for a citation system. You can even automate parts of that citation system, as one example, by using forms (templates). Any form standardizes a process, and thereby limits it, in order to be efficient, avoid the law of diminishing returns, for positive benefit/cost ratio etc. No form will ever account for all cases, but it can account for the basic, and most common cases. The basic cases are not a mystery. They are the minimal information needed to easily and quickly find the source that verifies the wikitext, because that is the point, and not how to embroider a citation.
- When readers try to discover a source, they have several options: libraries, museums, bookstores etc., other repositories of sources, and of course electronic searches online. The institutions/trade entities may or may not keep their own catalogs, but they as well as the online search engines, closely follow the way marketing, trade, and bibliographic databases are indexed. Traditionally (and presently) these indices may use the author name, the source name, and a subset of the publication info: the publishing source, the publishing date, the published version, the publishing location, etc. And also one or more marketing, classification or content-location identifiers. Every time a reader asks a person or a piece of software to find them a source, someone or something will eventually or immediately consult one or more of those (relatively few) classification databases, whether they realize it or not. As pointed out in another post, in these classification databases date indices do not order text data, but date data. The calendars used are reduced to certain date formats that include numbers and a small number of keywords (days of week, month-names etc). Personally I have not ever encountered a periodical classification database that includes keywords such as "Christmas" in their date indices. I have seen such keywords in the very rare "Issue name" field, but mostly in special fields such as "Notes", "Other", "Misc."
- So yes, even with their existing problems, CS1 templates can account for a "Christmas (year)" issue, by using one or more parameter as suggested in the previous post above. The source will be found. Resources can be used where needed in order to make a citation system that responds to readers first. Then we'll see about rare cases and if it is worth doing anything about them. 65.88.88.76 (talk) 21:09, 19 August 2021 (UTC)
- It is certainly important both to the editor and the reader that the reference matches as far as is reasonable how the date is presented by the publication - we shouldn't expect people who are trawling through piles of magazines (or possibly having to buy back issues) to have to infer dates which differ between the actual paper copy and the citation. The key question is how often these non-standard dates are used - ones like seasons, quarters and to a lesser extent Christmas and Easter are used sufficiently frequently (I've seen most of these in real life, often without a corresponding 'normal' date) for them to be already implemented (after much discussion) - how frequently are the suggested extra examples (and other possible examples such as say Passover or Eid) actually used?Nigel Ish (talk) 21:47, 19 August 2021 (UTC)
- Yeah, but back then our citation templates were really lacking support for them at a fundamental level. So this was a bigger issue. The infrastructure to support them first had to be implemented. Now, the effort isn't much more than adding a few more entries to a table.
- The point here is that most editors running into these things in real life won't come here asking us to add support for them, and even if the occasional editor finds the way into our forum, it is very inefficient to add them one after another over a period of a decade or so. If someone can run into examples using "Christmas" or "Easter" it is quite obvious by extension, that there will also be publications using some of the other important Christian liturgical dates, maybe a little less common but this doesn't really matter as it doesn't add complexity, and, in fact, someone found examples for "Trinity", etc. a couple of years later. That's why I think we should do this a little bit more systematically, and add them in sets, rather than individually. We'd stop annoying those editors running into them but not reporting them here until someone finally comes around, and it will free our minds to work on other, probably more important things.
- Regarding frequency of occurrence, fortunately they are rare. But they are also cheap to add. Until I was pointed to them in discussions I never saw those liturgical dates in publications, but I don't normally edit religious articles so the likelihood was low that I would run into them. Evidence has been given that they are actually used. Regarding the other entries, I personally ran into Midsummer, Carnival (as Karneval), and the various semester variants. Doing some dedicated research I also saw midwinter, midautumn and midspring, but I wouldn't have run into them if I wouldn't have searched for them. The quadrimester entries are derived from EDTF, a standard set up by the Library of Congress and many bibliographical institutions from all over the world (meanwhile also adopted by ISO). Obviously they saw a need to support them, and they are experts in the fields. Personally, I never saw them as "quadrimeters", only as "trimesters" (but apparently that's the same).
- --Matthiaspaul (talk) 00:10, 20 August 2021 (UTC)
- It is certainly important both to the editor and the reader that the reference matches as far as is reasonable how the date is presented by the publication - we shouldn't expect people who are trawling through piles of magazines (or possibly having to buy back issues) to have to infer dates which differ between the actual paper copy and the citation. The key question is how often these non-standard dates are used - ones like seasons, quarters and to a lesser extent Christmas and Easter are used sufficiently frequently (I've seen most of these in real life, often without a corresponding 'normal' date) for them to be already implemented (after much discussion) - how frequently are the suggested extra examples (and other possible examples such as say Passover or Eid) actually used?Nigel Ish (talk) 21:47, 19 August 2021 (UTC)
@Nigel Ish. These days, it is probable that the number of readers going through stacks of periodicals or buying back issues in order to verify a wikitext claim is smaller than the number of times an issue dated or labeled "Christmas (year)" appears in Wikipedia citations. It is much more likely they will ask someone or some thing for help. It was explained above what is likely to happen then. As was also pointed out before, there are ways to present rare dating info right now, even with rigid elements like templates. Sure, these ways may be stretching the use of the templates, but that is because the rare dating stretches the notion of "date". The entire point is that when there are other, more substantial issues regarding CS1, this and other minor (because rare) items can wait further judgement in time. In the meantime, one of the available fixes can be used. 64.18.10.203 (talk) 04:41, 20 August 2021 (UTC)
I have a list of 2.4 million journal and magazines like:
journal-of-black-psychology_2014-08_40_4 journal-of-primary-prevention_1982_spring_2_3 journal-of-occupational-and-environmental-medicine_1959-07_1_7
Note the "spring". The four seasons are most common. There are many "supplement, "index", "special issue". Also "first quarter". Many date ranges such as "jan-apr" (or "january-april"). And "winter-spring". Combos like "fourth quarter supplement" and "january-october cumulative". About 80 "christmas". About 20 "midsummer". Nothing with "semester" or "quadrimester". -- GreenC 05:17, 20 August 2021 (UTC)
"With Smith, John" in work lists
Many pages for academics have a "Works" or "Books" section that lists out their authored books, etc. (example). For these, I often like to use the CS1 citation templates, just without the surrounding ref tags and without the author parameters, as the author can be presumed to be the subject of the page. However, this gets tricky when there are multiple authors, as listing out only the other authors would be confusing and give the impression that the subject wasn't actually involved. For these instances, I could just write out With {{citation|last=Smith|first=John|title=..., but I feel like that wouldn't be good for the metadata. Is there a way to do this better within the citation template itself? If not, could we create it? {{u|Sdkb}} talk 05:17, 27 August 2021 (UTC)
- You're looking for the parameter
|author-mask=and its cousins|author-maskn=, I believe. — JohnFromPinckney (talk / edits) 06:16, 27 August 2021 (UTC)- Thanks! I just tried it here; hopefully I did it right. {{u|Sdkb}} talk 06:34, 27 August 2021 (UTC)
- You're welcome. You got close, but you've surely already seen that Headbomb and Redrose have tweaked the cites for you. HE, — JohnFromPinckney (talk / edits) 08:52, 27 August 2021 (UTC)
- Thanks! I just tried it here; hopefully I did it right. {{u|Sdkb}} talk 06:34, 27 August 2021 (UTC)
- The proper solution has been found already but I'd like to add an additional remark against just leaving out (some or all of) the names (or in other cases omitting the title), as this would create incorrect metadata for the citation. Since our citations are machine-readable and are harvested by external parties, this would cause such incomplete citations to be distributed elsewhere (which can cause confusion and various synchronization or merging problems further down the chain, which eventually not only affects those third-parties but also ourselves when our editors use such external data in other articles).
- So, the proper solution is, as correctly stated above, to provide all the data to make a citation self-complete, and then use special parameters (
|author/editor/translator/...-maskn=for the names) to suppress certain values from the local output of the citation. (A similar case exists for titles, and we already have some means to mute titles but we are still lacking a proper method to specify a title for metadata but mask it in the local output - I hope we can address this when we add support for descriptive titles, which should show up locally without text decoration, but should not normally be made part of the metadata, or at least not without being specially marked). - --Matthiaspaul (talk) 18:35, 27 August 2021 (UTC)
- Thanks; that's helpful to know! {{u|Sdkb}} talk 20:45, 27 August 2021 (UTC)
Same book source, different pages?
Good day,
Currently working on a major edit of MCW Metrobus, some of which involves adding book sources to previously unsourced content. But when using Template:Cite book, what general guidance is there for providing multiple sources from the same book? As in, one source uses the book on one set of pages, while another source uses the book on a different set of pages? Is there, perhaps, a way these sources can be 'combined' so there is no repetition, or is repetition the only way?
Cheers, Hullian111 (talk) 17:58, 27 August 2021 (UTC)
- Hi Hullian, there are several ways how to accomplish this.
- The easiest and most common method is to just combine the multiple pages into a list of cited pages in the
|pages=parameter, and optionally merge the corresponding quotes from the source into the|quote=parameter (which has a separate|quote-pages=parameter, if the quotes are from a subset of those pages given in the|pages=parameter only). Once you have defined this citation through something like<ref name="YourRefName">{{cite book |YourCitationParameters=...}}</ref>, you can then invoke this citation by<ref name="YourRefName"/>whereever it is needed to support an article statement. - If you need to specify individual pages (or quotes) at the various places where you invoke your citation, you can append {{rp}} like this:
<ref name="YourRefName"/>{{rp|YourPageNo}}. Some people like to combine this into a wrapper template{{r|YourRefName|p=YourPageNo}}- this gives exactly the same output but is shorter and easier to read. - All these methods are basically just variants of one main scheme how to produce citations. The advantage of all of them is that they require only one "References" section and that you can define the core citation either in the article body (so called "inline references") or, if you want to avoid the clutter a long citation definition might create in the middle of the wikitext for the article prose, it can be defined down in the "References" section (this is called "list defined references").
- All the linking down to the citations and the backlinks from there up to the invocation is carried out automatically by Mediawiki without any necessary manual intervention.
- There are a number of other citation methods as well, among them so called short references ({{sfn}}). Similar to {{rp}} they allow to specify short references with page numbers, but the linking works considerable different (the links are created by the templates, not by the underlying Mediawiki software which, depending on author names, dates and titles used in the core citation, can sometimes cause ambiguous or dangling pointers requiring manual fixup). Also, they require two special sections in the article, one for the short references (often named "References" or "Notes"), and another for the core citations (often named "Bibliography"). While it keeps the links in the prose extremely short even for citations with page number, this comes at the expense of an extra layer of indirection (the "References" section), which can add significant clutter to an article. Also, there are no backlinks from the core citations in the "Bibliography" section to the short references, which makes it more difficult to find and visit all invocations of a citation resolving to a single publication.
- I think I would start with the first method because it is by far the most commonly used method, it covers the majority of scenarios well, and is the easiest to master. If you then need to specify individual pages this can be easily added using {{rp}} in a second step.
- --Matthiaspaul (talk) 19:29, 27 August 2021 (UTC)
- I think it is inaccurate to say that short references require two separate reference sections. A solution to this problem, using only a single references section, is: use a footnote containing the full reference for the first occurrence of the book among the references, and then use short citations created by {{sfn}} or {{sfnp}} for subsequent citations to different pages in the same book. Also, I would advise against using {{rp}}; it is an abomination that mixes up footnote markers with citation metadata and requires readers to remember one piece of a citation while they look up the other. I would prefer for all instances of it to be replaced by less-bad referencing styles. —David Eppstein (talk) 19:41, 27 August 2021 (UTC)
- @Matthiaspaul:That’s a lot of wordage - I think I kind of understand what Matthias is going for in the first para. By the first method, I assume you mean typing out individual pages broken up by a comma? I’ve discovered you can type practically whatever you want in the page number section, so is that valid for a citation? Or do I have to break it down into individual cites?
- @David Eppstein: Yeah, I have to agree on that. Breaking down cites like that seems overly complicated, and page numbers don’t exactly help when I’m linking to Google Books pages for the URL sections. The print copy I have of Wharmby’s Metrobus book probably won’t line up with the eBook version, so that’s bound to confuse readers. Especially since Google Books doesn’t provide page numbers.
- Sorry if I’ve misunderstood anything, its late in the evening, and I’ll try and closely read what Matthias has proposed tomorrow. Hullian111 (talk) 22:12, 27 August 2021 (UTC)
- Please do not put things in the
|page=or|pages=parameter that are not page numbers. You can instead use|contribution=,|chapter=, or|at=(but|at=and|pages=cannot both be used in the same citation). For {{sfn}} there is also|loc=. —David Eppstein (talk) 22:17, 27 August 2021 (UTC)- That's something I happily agree with David.
|pages=supports comma-separated lists of pages, page ranges and linked pages in any combination, but please don't put other information into the parameter.|page=is for singular pages, and|at=is for other location information (sheets, columns, paragraphs, etc.) for which the prefix p. or pp. would be misleading. These prefixes also do not belong into the parameter, they are generated by the template itself. - --Matthiaspaul (talk) 22:28, 27 August 2021 (UTC)
- That's something I happily agree with David.
- Please do not put things in the
- (edit-conflict) That's interesting, David, because I come to just the opposite conclusions. ;-) In your suggested use of {{sfn}} with the core citation defined at the first occurence, the citation ends up in the same section as the short references, and, as it also serves as the core citation for the following short references, it either cannot contain page information for the first invocation (putting the first invocation at disadvantage), or it would have to carry a combined list of pages for all invocations (and thereby would create misleading metadata for the first invocation), or it would carry the page information for the first invocation only (and then show wrong page information for all the other invocations linking to it). Certainly a way to avoid the symmetrical two-section setup, but hardy ideal. Also, in order to keep the space occupied by the often very long lists of short references smaller, this section is often formatted as multi-column list with a small column width, but this does not work well when long citations are part of this section as well - to the effect that the list of references cannot be broken into multiple narrow columns and thus occupies a lot of display space creating huge areas of white space.
- I also don't understand your comment on {{rp}}. All it does is append some terse superscript page information to the superscripted links.[1]: 5 It does not deal with metadata at all and therefore cannot cause it to be mixed up.
- Regarding your comment that it "requires readers to remember one piece of a citation while they look up the other", this is exactly the situation I find myself in when having to sift through articles containing short references created with {{sfn}} (because of the missing backlinks from the core citations to the short references or the invocations). One of the advantages of {{rp}} or {{r}} is just that they do not have this problem and automatically provide the backlinks necessary to jump between all pages cited from a single publication. To me, this is a serious shortcoming of the former.
- To the OP it is important to know that the different systems obviously have different pros and cons (otherwise we wouldn't need them all ;-), and that WP:CITEVAR applies.
- --Matthiaspaul (talk) 22:19, 27 August 2021 (UTC)
- @Matthiaspaul: @David Eppstein: Morning all - now I’m able to look at this with a fresh head, with the recent arguments for and against in mind, I’m slowly coming round to think that {{rp}} might be my best bet for my intents and purposes. I will admit, I am still a bit of a novice at this whole Wikipedia thing despite massively picking up on editing this year, so thanks for additional clarification what shouldn’t go in the Template:Cite book page numbers area. Think I may have phrased it wrong by typing ‘anything’...
- As I understand it, using {{rp}}, would this [2]: 129 and [2]: 178 be suitable solutions for my page number problem? Or would the other ones be an optimal way to go? Hullian111 (talk) 08:38, 28 August 2021 (UTC)
- Yes, except that I would[3]: 131 use it like this:[3]: 185 See the added
|pages=131, 185parameter, merging the pages info from all short references like {{rp}}. This gives complete metadata, including page info, in the full citation. It may look a bit odd in the source code of this thread, because the definition of the full citation is located where we are actually only citing page 131, but it creates the correct output anyway, and the definition[4]: 201 could be added[4]: 205 into[4]: 231 the References section further down. I'm creating one here to illustrate this with a third citation:
- Yes, except that I would[3]: 131 use it like this:[3]: 185 See the added
- I think it is inaccurate to say that short references require two separate reference sections. A solution to this problem, using only a single references section, is: use a footnote containing the full reference for the first occurrence of the book among the references, and then use short citations created by {{sfn}} or {{sfnp}} for subsequent citations to different pages in the same book. Also, I would advise against using {{rp}}; it is an abomination that mixes up footnote markers with citation metadata and requires readers to remember one piece of a citation while they look up the other. I would prefer for all instances of it to be replaced by less-bad referencing styles. —David Eppstein (talk) 19:41, 27 August 2021 (UTC)
References
- ^ Dummy citation
- ^ a b Paul Williams (15 September 2016). Manchester Buses. Amberley Publishing Limited. ISBN 978-1-4456-5315-0. Retrieved 27 August 2021.
- ^ a b Paul Williams (1 March 2018). Manchester Buses, Revised (2nd ed.). Amberley Publishing Limited. pp. 131, 185.
- ^ a b c Harold Smith (15 January 2020). The Return of the Manchester Bus. Manchester Publishing Company. pp. 201, 205, 231.
- --Matthiaspaul (talk) 09:03, 28 August 2021 (UTC)
- (edit-conflict) The alternative using {{sfn}} would[1] look[2] like[3] this:[4]
References
- ^ Williams 2019, p. 131.
- ^ Williams 2019, p. 185.
- ^ Williams 2019, p. 190.
- ^ Williams 2021, p. 102.
Bibliography
- Williams, Paul (15 January 2019). Manchester Buses (corrected ed.). Amberley Publishing Limited. pp. 131, 185, 190.
- Williams, Paul (1 August 2021). The New Manchester Buses (fully revised 3rd ed.). Amberley Publishing Limited. p. 102.
- See, the actual links are a bit shorter because they don't show the page info embedded, but at the expense of an extra section, so you have to click twice to see the actual citation info. And once you reached the core citation, there are no links back to the individual short refs. Also, the linking itself relies on anchor names created by the citation templates (derived from the author surnames and year, and this can easily led to ambiguous anchor names and invalid HTML (when there are two publications by the same author in a year or two authors of the same name) or dangling pointers (if someone does not recognize that the citation in the bibliography section is referenced from the short references further up and changes or deletes it). There are sometimes also discrepancies between the anchor name created by the citation template and the assumed anchor name used in the short references (not in this example, of course). These errors can be fixed, but they are difficult to detect and therefore it often takes months or years until someone finally finds and fixes them (there are some tools to assist in this process). All in all this style requires careful testing and maintenance. This cannot happen with the style I am recommending further up because it does not rely on these self-created link names but only on those created and used by the underlying Mediawiki software (which reliably displays error messages when there are errors).
- --Matthiaspaul (talk) 10:30, 28 August 2021 (UTC)
- @Matthiaspaul: Thanks, think that's it! Testing it in Sandbox, I think that method you've suggested works well and should satisfy the issue for the four and potentially more page cites I need to insert into the article. Might take me a while to fully break it down, but I think that's my query solved. I'm going to be working on this MCW Metrobus page for a while over on Docs and Sandbox before I publish it, so if you happen to stop by, let me know if I'm doing it right. Still learning as I go along, after all.
- Cheers, Hullian111 (talk) 11:40, 28 August 2021 (UTC)
- @Hullian111: Have a look at Swindon railway station#History, references 1 through 7 inclusive. Is this what you are wanting? --Redrose64 🌹 (talk) 09:46, 28 August 2021 (UTC)
- This is in fact an example of the unsymmetrical {{sfn}} style David was recommending. However, in addition to the general issues with {{sfn}} described by me above, it creates misleading (and incomplete) metadata (only valid for the first citation) and "nicely" illustrates the excessive white space caused because short and long references are mixed in the same section so that columns must be wide enough for the long references. I think, in this example, it's still tolerable, but there are examples with much longer lists of short references, where it really impacts the visual appearance of an article. On the other hand, when the in-article-location information becomes much longer than a short page or page range, the {{rp}} style can become distracting as well. So, what's best in a particular article depends on the circumstances.
- --Matthiaspaul (talk) 10:46, 28 August 2021 (UTC)
- To the OP: take a look at WP:LDR and also templates {{harv}} and {{sfn}}. The short citations can be displayed with {{reflist}} and the full citations with something like the {{refbegin}}/{{refend}} combination. 68.173.76.118 (talk) 23:12, 28 August 2021 (UTC)
error messaging
This is a sidetrack off of Help talk:Citation Style 1/Archive 77 § summary messaging in the preview warning header. Over the past few days I have been reworking how error messaging is handled in the various modules (primarily Module:Citation/CS1 and Module:Citation/CS1/Identifiers which emit the most errors). In the previous conversation, I suggested that it would be a good thing to move all error messages to the end of the citation. As it is right now, some error messages are made part of the template's rendering which, to me, looks bad.
The live module has a table called z.message_tail which holds all of the error messages that are rendered following the citation. To load that table, it is necessary for the code to call set_message() in Module:Citation/CS1/Utilities. That function returns the error message as a plain message or as a message wrapped in <span>...</span> tags appropriately classed for hidden or visible error messages. The function that called set_message() then has to use the returned message as an appendage on a parameter's data or as a replacement for it; or, the function must insert the returned message into the z.message_tail table. Moving all error messages to the end of the citation means that set_message() can insert the message in z.message_tail as part of its normal operation and so the code is simpler and more consistent.
I have done that. The change primarily impacts Module:Citation/CS1/sandbox and Module:Citation/CS1/Identifiers/sandbox but also impacts Module:Citation/CS1/Utilities/sandbox. I have renamed z.message_tail to z.error_msgs_t so that the name reflects its content.
As part of this I have spent a bit of time refining the assembly of the various parts of the finished citation (the citation itself, the anchor ID and the css classes in the <cite> tag, the metadata, the error messages, the maintenance messages, and the categories (roughly the 100ish lines of code beginning at about line 3844 of Module:Citation/CS1/sandbox). This includes the error and maintenance summaries and the error message prefixes discussed in the previous conversation, sorting of error and maintenance messages. Empty citations will no longer produce metadata because why bother:
{{cite book}}-
{{cite book}}: Empty citation (help)'"`UNIQ--templatestyles-000000B2-QINU`"'<cite class="citation book cs1"></cite> <span class="cs1-visible-error citation-comment"><code class="cs1-code">{{[[Template:cite book|cite book]]}}</code>: </span><span class="cs1-visible-error citation-comment">Empty citation ([[Help:CS1 errors#empty_citation|help]])</span>
-
{{cite book/new}}-
{{cite book}}: Empty citation (help)'"`UNIQ--templatestyles-000000B5-QINU`"'<cite class="citation book cs1"></cite> <span class="cs1-visible-error citation-comment"><code class="cs1-code">{{[[Template:cite book|cite book]]}}</code>: </span><span class="cs1-visible-error citation-comment">Empty citation ([[Help:CS1 errors#empty_citation|help]])</span>
-
—Trappist the monk (talk) 22:02, 28 July 2021 (UTC)
- I wonder if some kind of "error framing" could be done (at least in preview) to make it easier for editors to spot the errors. Mockup:
{{cite journal |last=Smith |first=John |date=9999 |title=Title of Things |journal=Journal of Stuff |volume=Vol. 34 |issue=1 |pages=23–45 |doi=10.4321/3210 |pmid=012345}}- Smith, John (9999). "Title of Things". Journal of Stuff. Vol. 34 (1): 23–45. doi:10.4321/3210. PMID 012345. {{cite journal}}:
|volume=has extra text (help); Check date values in:|date=(help)
- Smith, John (9999). "Title of Things". Journal of Stuff. Vol. 34 (1): 23–45. doi:10.4321/3210. PMID 012345. {{cite journal}}:
- I assume it would complicate the code too much but still wanted to mention it to spread the idea.
- --Matthiaspaul (talk) 00:59, 29 July 2021 (UTC)
- In your example above
<span class="cs1-visible-error citation-comment">*</span><span class="cs1-visible-error citation-comment">*</span>
- the two message spans could be combined into one:
<span class="cs1-visible-error citation-comment">**</span>
- to reduce the size of the resulting HTML. However, I understand that this might not always be possible if they are interwoven with hidden messages, so I'm mentioning this just in case you see an easy way to do it anyway.
- --Matthiaspaul (talk) 12:07, 1 August 2021 (UTC)
- Yeah, they could be combined but it is much easier in the code to have them as separate spans because we can't always and forever know that the first error message after the {{Cite book}} prefix will be a visible error message. However, that does highlight a flaw in the prefix design; if all error messages emitted by a citation are hidden, then the prefix should also be hidden. As it is, it is always visible. I'll think about that ...
- —Trappist the monk (talk) 15:10, 1 August 2021 (UTC)
- Citations emitting only hidden error messages will also hide the error message prefix:
{{cite journal/new |title=Title}}- "Title".
{{cite journal}}: Cite journal requires|journal=(help)'"`UNIQ--templatestyles-000000BC-QINU`"'<cite class="citation journal cs1">"Title".</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=article&rft.atitle=Title&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+78" class="Z3988"></span> <span class="cs1-visible-error citation-comment"><code class="cs1-code">{{[[Template:cite journal|cite journal]]}}</code>: </span><span class="cs1-visible-error citation-comment">Cite journal requires <code class="cs1-code">|journal=</code> ([[Help:CS1 errors#missing_periodical|help]])</span>
- "Title".
- —Trappist the monk (talk) 16:29, 1 August 2021 (UTC)
- Citations emitting only hidden error messages will also hide the error message prefix:
- Do not emit duplicate IDs in any case. Our objective is to comply with HTML and that does not. Thanks. I'll revert the lot of the sandbox if that remains in the code. The supposed gain is not worth that. Izno (talk) 14:12, 3 August 2021 (UTC)
- Presumably this is related to discussion that occurred at Help talk:Citation Style 1/Archive 77 § summary messaging in the preview warning header regarding links from the preview warning messages to citations elsewhere in the previewed article. Where were you and your objections when we first discussed this? You were around and even edited this page during the period of that conversation. Instead of swooping in with drama and threats after the fact, it would have been better for you to participate in the discussion as it was on-going.
- The point is taken and I have removed the spans and go-to links.
- —Trappist the monk (talk) 15:37, 3 August 2021 (UTC)
- Busy trying not to care about Matthias' outlandish requests? :) Izno (talk) 15:51, 3 August 2021 (UTC)
- Not funny, and not outlandish at all. It's all about user-friendliness and usability.
- The anchors/spans are added only if there is a problem in a citation. So articles without problematic citations will never have them. Also, above I proposed to add them only in preview in order to not invalidate HTML in normal article view. Even web designers who otherwise care about good HTML often deliberately ignore trivialities like this, in particular if it is known to not cause any harm.
- Further, all articles with citations lacking disambiguation contain identical anchors and thereby contain invalid HTML - and not only in preview or with actual citation errors, but in normal article view for as long until the disambiguation gets fixed. And in this case, a doubled anchor actually causes "harm" as it makes subsequent citations "unreachable". When we discussed this when making
|ref=harvthe default, we decided to ignore this because the benefit far outweights the problem. Nobody complained about it. - We should do the same here as well, in particular as in this case the doubled anchors do not create any practical problem for browsers at all and do only exist in preview and when citations have errors, anyway. So, ignoring the "no double anchors" doctrine would be a valid engineering decision. If we do not, we should immediately switch off harv-style anchors as well.
- --Matthiaspaul (talk) 17:28, 3 August 2021 (UTC)
- Busy trying not to care about Matthias' outlandish requests? :) Izno (talk) 15:51, 3 August 2021 (UTC)
HTML structure of a citation
However, there is a related, more general issue. This is unrelated to preview messages and the restructuring of error messages, but since we are talking about the structure of the HTML for a citation, I'm bringing this up anyway.
The general structure of a citation (in the sandbox, that is, including the preview message) is as follows:
<span id="cite-book-error"></span><cite id="CITEREF*" class="citation book cs1">Citation with appended messages</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=*" class="Z3988"></span>- Citation with appended messages
Some browers and tools allow to highlight the scope of elements and navigate from element to element or otherwise take advantage of knowing the scope of data elements (screenreaders and browsing assistance tools, web development tools, web harvesters). Right now, they see a citation as an empty preview error span, the actual citation with optional messages appended, followed by the COinS info.
This is somewhat suboptimal. The preview error span should span over the whole citation including messages and COinS data.
In addition to this, the COinS span should ideally span over the citation and messages as well in order to declare the context of the COinS data. This would result in the following nested structure:
<span id="cite-book-error"><span title="ctx_ver=Z39.88-2004&rft_val_fmt=*" class="Z3988"><cite id="CITEREF*" class="citation book cs1">Citation with appended messages</cite></span></span>- Citation with appended messages
The only adverse effect of this rearrangement I can see right now is that the browser will now display the COinS data as tooltip, which might be confusing. So, if the contents of the COinS span really must be empty, it might be possible to do it the other way around and embed it into the cite element. The preview error span could still wrap around both:
<span id="cite-book-error"><cite id="CITEREF*" class="citation book cs1">Citation with appended messages<span title="ctx_ver=Z39.88-2004&rft_val_fmt=*" class="Z3988"></span></cite></span>- Citation with appended messages
In both of these two cases, the proper extraction of COinS data by existing tools would have to be tested, because in the examples I could find on the web they always suggest that this is an empty element (or only containing a space) immediately following the citation. At least wrapping the preview span around both of them will work regardlessly:
<span id="cite-book-error"><cite id="CITEREF*" class="citation book cs1">Citation with appended messages</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=*" class="Z3988"></span></span>- Citation with appended messages
--Matthiaspaul (talk) 12:07, 1 August 2021 (UTC)
- Umm, the general structure of a sandbox citation is not quite what you say it is. See for example this:
{{cite book/new |title=Title |access-date=2021-08-01}}- Title.
{{cite book}}:|access-date=requires|url=(help)<templatestyles src="Module:Citation/CS1/sandbox/styles.css"></templatestyles><span id="cite-book-error"></span><cite class="citation book cs1">''Title''.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Title&rfr_id=info%3Asid%2Fen.wikipedia.org%3ABlue" class="Z3988"></span> <span class="cs1-visible-error citation-comment"><code class="cs1-code">{{[[Template:cite book|cite book]]}}</code>: </span><span class="cs1-visible-error citation-comment"><code class="cs1-code">|access-date=</code> requires <code class="cs1-code">|url=</code> ([[Help:CS1 errors#accessdate_missing_url|help]])</span>[[Category:CS1 errors: access-date without URL]]
- Title.
- so what we have is:
<templatestyles></templatestyles><span id=<cite book error anchor>></span><cite>The Citation</cite><span <COinS metadata>></span><messaging><categories>
- I created empty error-anchor and maint-anchor spans because that is how
{{anchor}}implements anchors. It is easy enough to wrap the entire rendering from<cite>to the end of the last category in the error-anchor and maint-anchor spans. If we did that, we could add an undefined class so that editors can style the anchored citations; don't know how beneficial that would be ... - I am unwilling to change how the metadata span is handled without someone having conducted extensive research to prove that your suggestion does not break external tools. Apparently metadata works now so ain't-broke-don't-fix applies.
- —Trappist the monk (talk) 14:55, 1 August 2021 (UTC)
- Error-anchor and maint-anchors now wrapp entire citation from
<cite>to the end of the last category:{{cite book/new |title=Title |access-date=2021-08-01 |authors=Authors}}- Title.
{{cite book}}:|access-date=requires|url=(help); Unknown parameter|authors=ignored (help)'"`UNIQ--templatestyles-000000C8-QINU`"'<cite class="citation book cs1">''Title''.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Title&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+78" class="Z3988"></span> <span class="cs1-visible-error citation-comment"><code class="cs1-code">{{[[Template:cite book|cite book]]}}</code>: </span><span class="cs1-visible-error citation-comment"><code class="cs1-code">|access-date=</code> requires <code class="cs1-code">|url=</code> ([[Help:CS1 errors#accessdate_missing_url|help]])</span>; <span class="cs1-visible-error citation-comment">Unknown parameter <code class="cs1-code">|authors=</code> ignored ([[Help:CS1 errors#parameter_ignored|help]])</span>
- Title.
- —Trappist the monk (talk) 16:19, 1 August 2021 (UTC)
- Looks good, thanks.
- I agree, moving the COinS info will require more research in regard to what works with existing tools, and what might not. That's why I was bringing this up.
- Unfortunately, the standard itself is not very clear about it, so implementations might vary in regard to what they expect. As far as I understand it, there should be no inherent dependency of the COinS span from
<cite>, therefore from the viewpoint of data extraction, it should not matter, if one gets embedded into the other. - Regarding the contents of the COinS span, they suggest to use a space in environments where an empty span would be removed in some HTML optimization processes. From this we can at least derive that the span does not need to be empty.
- They also talk about the possibility to place some default text in there, leaving it open to interpretation if COinS-aware browser plug-ins are meant to replace this text with some link/icon to a pop-up etc., or if they are meant to insert such links/icon after the text. If we find a browser plug-in which would replace the text, we obviously cannot place the citation there, otherwise this would be the most-"natural" place for it. It would be interesting to learn from the community which tools they use and how they behave on the following two test citations:
- Manually crafted citation with
<cite>inside COinS span:- Statement of Principles. The International Conference on Cataloguing Principles (CCP). Paris, France. 1961-10-18 [1961-10-09].
- Manually crafted citation with COinS span inside
<cite>:- Statement of Principles. The International Conference on Cataloguing Principles (CCP). Paris, France. 1961-10-18 [1961-10-09].
- --Matthiaspaul (talk) 11:18, 3 August 2021 (UTC)
- Given that the COINS span outputs its content as a title, putting cite inside the span is a non-starter. Everything internal will have a hover over title completely meaningless to users and defeating the other over hovers we have (links predominantly). Izno (talk) 14:10, 3 August 2021 (UTC)
- Error-anchor and maint-anchors now wrapp entire citation from
Proposition: "narrator" alias
For audiobooks, mainly. Whenever the various situations are sorted out and proper development restarts. This alias may be useful. 66.108.237.246 (talk) 13:39, 1 September 2021 (UTC)
- Audiobook probably use
{{cite media}}with|others=Narrated by Simon Vance. The free-form|others=allows for multiple narrators; or, "Full-cast" such as BBC radio adaptations of a book that are too many to list, or some staring roles. --GreenC 14:58, 1 September 2021 (UTC)- There are also other situations for a narrator role apart from audiobooks, such as TV programs, films, and also things like scripts (of plays etc). I don't know if it as common as the translator role that has its own alias, but I wouldn't be surprized. 65.88.88.46 (talk) 15:15, 1 September 2021 (UTC)
- There are many roles (not a complete list): Author, Composer, Contributor, Cover artist, Cover designer, Designer, Director, Editor, Forward, Illustrator, Introduction, Narrator, Photographer, Preface, Translator. -- GreenC 15:25, 1 September 2021 (UTC)
|others=works fine for these roles. Almost none of them help with WP:V, which is the main purpose of these templates. – Jonesey95 (talk) 16:09, 1 September 2021 (UTC)- There is a rare case when the narrator info can contribute to verification. In many works (and unfortunately so, imo) the narration is acted rather than read straight. It is conceivable that the narrator's inflection may change the meaning for some listeners. Wikitext may claim a "fact" that depends on such meaning. There should be some indication that the wikitext claim is due to the narrator (as de facto editor) and not necessarily due to the author. But this may be better suited to a more complete citation system. 65.88.88.46 (talk) 17:09, 1 September 2021 (UTC)
- There are many roles (not a complete list): Author, Composer, Contributor, Cover artist, Cover designer, Designer, Director, Editor, Forward, Illustrator, Introduction, Narrator, Photographer, Preface, Translator. -- GreenC 15:25, 1 September 2021 (UTC)
- There are also other situations for a narrator role apart from audiobooks, such as TV programs, films, and also things like scripts (of plays etc). I don't know if it as common as the translator role that has its own alias, but I wouldn't be surprized. 65.88.88.46 (talk) 15:15, 1 September 2021 (UTC)
Adding an observation made in this discussion about the illustrator role. Audiobook titles can be found by using the "narrator" info, even when the author is not used. The major trade databases (wholesale & retail) index the "narrator" field, and the narrator is prominently displayed in browse lists along with the author. 65.88.88.76 (talk) 21:00, 2 September 2021 (UTC)
{{hyphen}} converted to dash
Help:Citation Style 1#pagehyphen says For a hyphenated page, use
However, I don't believe this is true, as |page=12{{hyphen}}34. This will not only properly display a hyphen..."{{cite book|title=Title|pages=1{{hyphen}}2}}" renders as "Title. pp. 1–2." with a dash. --Ahecht (TALK
PAGE) 02:27, 2 September 2021 (UTC)
|page=and|pages=are not the same thing. Compare your example:{{cite book|title=Title|pages=1{{hyphen}}2}}- Title. pp. 1–2.
- and the same citation according to the documentation:
{{cite book|title=Title|page=1{{hyphen}}2}}- Title. p. 1-2.
- —Trappist the monk (talk) 02:40, 2 September 2021 (UTC)
- @Trappist the monk Got it. I added to the "pages" section to clarify. While I have your attention, the "Accept-this-as-written markup" section says
Markup can be applied to the entry as a whole or to individual list entries
, but that doesn't seem to work for numbers with commas:{{cite book|title=Title|pages=1, ((1,234))}}- Title. pp. 1, 1,234.
- I understand that the logic for handling this case would be more complex than what the module currently does, and would require pre-processing the string before splitting it. If this behavior is intended, should the documentation clarify? --Ahecht (TALK
PAGE) 15:56, 2 September 2021 (UTC)- I saw your tweak to the documentation but the module is smart enough to handle the hyphenated case you demonstrated:
- But if you prefer to use the templates:
{{cite book |title=Title |pages=1{{hyphen}}2{{endash}}3{{hyphen}}4}}- Title. pp. 1-2 – 3-4. – still works properly
- We should reserve recommendation of the accept-this-as-written markup for those cases where it is truly needed so I am going to revert you.
- —Trappist the monk (talk) 16:08, 2 September 2021 (UTC)
- @Trappist the monk: I suppose a better example would be
{{cite book|title=Title|pages=((1{{hyphen}}2)), ((3{{hyphen}}4))}}where those are intended to by hyphenated page numbers. Any objection to me adding that to the help page? --Ahecht (TALK
PAGE) 19:29, 2 September 2021 (UTC)- No objection. You might want to note the difference between your example and this:
{{cite book|title=Title|pages=((1{{hyphen}}2, 3{{hyphen}}4))}}- Title. pp. 1-2, 3-4.
- because of what happens when a space character is omitted:
{{cite book|title=Title|pages=((1{{hyphen}}2,3{{hyphen}}4))}}- Title. pp. 1-2,3-4.
- —Trappist the monk (talk) 19:41, 2 September 2021 (UTC)
- No objection. You might want to note the difference between your example and this:
- @Trappist the monk: I suppose a better example would be
- @Trappist the monk Got it. I added to the "pages" section to clarify. While I have your attention, the "Accept-this-as-written markup" section says
Index:
pl ar de en es fr it arz nl ja pt ceb sv uk vi war zh ru af ast az bg zh-min-nan bn be ca cs cy da et el eo eu fa gl ko hi hr id he ka la lv lt hu mk ms min no nn ce uz kk ro simple sk sl sr sh fi ta tt th tg azb tr ur zh-yue hy my ace als am an hyw ban bjn map-bms ba be-tarask bcl bpy bar bs br cv nv eml hif fo fy ga gd gu hak ha hsb io ig ilo ia ie os is jv kn ht ku ckb ky mrj lb lij li lmo mai mg ml zh-classical mr xmf mzn cdo mn nap new ne frr oc mhr or as pa pnb ps pms nds crh qu sa sah sco sq scn si sd szl su sw tl shn te bug vec vo wa wuu yi yo diq bat-smg zu lad kbd ang smn ab roa-rup frp arc gn av ay bh bi bo bxr cbk-zam co za dag ary se pdc dv dsb myv ext fur gv gag inh ki glk gan guw xal haw rw kbp pam csb kw km kv koi kg gom ks gcr lo lbe ltg lez nia ln jbo lg mt mi tw mwl mdf mnw nqo fj nah na nds-nl nrm nov om pi pag pap pfl pcd krc kaa ksh rm rue sm sat sc trv stq nso sn cu so srn kab roa-tara tet tpi to chr tum tk tyv udm ug vep fiu-vro vls wo xh zea ty ak bm ch ny ee ff got iu ik kl mad cr pih ami pwn pnt dz rmy rn sg st tn ss ti din chy ts kcg ve
Portal di Ensiklopedia Dunia
