Help talk:Citation Style 1/Archive 68

This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

• {{cite journal |last1=Sundquist |first1=Alma |title=Lika lön för lika arbete: varför män böra arbeta för kvinnans politiska rösträtt |journal=Rösträtt för Kvinnor |date=1 April 1913a |volume=2 |issue=7 |pages=1–2 |url=https://gupea.ub.gu.se/bitstream/2077/462/1/gupea_2077_462_1.pdf |trans-title=Equal Pay for Equal Work: Why Men Should Work for Women's Political Right to Vote |publisher=Landsföreningen för kvinnans politiska rösträtt |location=Stockholm |language=Swedish}}

Doesn't display the 1913a in the date. It does when you preview, but not in live version. Purging doesn't help.

Same at

b

} 21:43, 18 June 2020 (UTC)

Strange. The "a" displays when I copy that section to my sandbox. Is this a namespace difference? – Jonesey95 (talk) 21:51, 18 June 2020 (UTC)

Wonder if

b

} 21:54, 18 June 2020 (UTC)

It amazes me sometimes how long it takes us to recognize that there is something not right in a rendering. This particular bug has been with us since auto-date formatting was established.

When an article has {{use xxx dates}}, cs1|2 cannot see that template if you are previewing a section that does not include the {{use xxx dates}} template. So, because the bug is related to the {{use xxx dates}} reformatting, previewing the entire page will render the date without the anchor ID disambiguator. Because the date format in the template is the same as specified by {{use xxx dates}}, it is not obvious that something is wrong except that one little character is missing. In a sea of characters, detecting a missing character is difficult.

This discussion has {{use dmy dates}} so this should render a disambiguated date in dmy format:

{{cite book/new |title=Title |author=author |date=April 1, 1913a}}

author (1 April 1913a). Title. {{cite book}}: |author= has generic name (help)

This one should not render a disambiguated dmy date, but the anchor ID will be disambiguated:

{{cite book/new |title=Title |author=author |date=1913-04-01 |year=1913a}}

author (1 April 1913). Title. {{cite book}}: |author= has generic name (help)

'"`UNIQ--templatestyles-0000000B-QINU`"'<cite id="CITEREFauthor1913a" class="citation book cs1">author (1 April 1913). ''Title''.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Title&rft.date=1913-04-01&rft.au=author&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+68" 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">&#124;author=</code> has generic name ([[Help:CS1 errors#generic_name|help]])</span>

—Trappist the monk (talk) 22:13, 18 June 2020 (UTC)

I half-remember discussions about this going way back. The obvious solution would be to use a custom harvid. Because I am not fond of disambiguating full dates, unless it involves the (I assume) very rare instance of referencing two separate works by the same author and same full date. I would consider a full date to be its own disambiguator. 64.9.245.162 (talk) 00:18, 19 June 2020 (UTC)

Dates have to be disambiguated in print too.

b

} 14:07, 20 June 2020 (UTC)

Re the {{Cite web}} and similar templates citing a date: some Web pages cited are kept up-to-date, or updated frequently. When citing a source, it is usual to set the date parameter value to the date when the page was last updated (if stated), with an access-date. It would be useful to have a date value of "updated periodically" or similar (at present I achieve this with a note after the cite web template, e.g. Web page updated continuously.) The purpose of this is to encourage the reader needing latest information to go to the source, rather than accepting that only old information is available. Best wishes, Pol098 (talk) 13:48, 20 June 2020 (UTC)

The opposite is true in citations: The edition that was consulted to support a wikitext claim is the one that should be used for verification. If the information in that edition is no longer valid, the citation should be removed. Unless the wikitext claims that sometime in the past, such information was accepted as true. 172.254.241.58 (talk) 14:25, 20 June 2020 (UTC)

Need to clarify. Non- material updates are basically reprints and can be substituted for the original. Content-related updates may edit the verifying info and imo should be considered editions. In that case, the new version may or may not support the wikitext. 172.254.241.58 (talk) 14:42, 20 June 2020 (UTC)

Need to clarify. Indeed I do. I'm thinking here (following a recent edit I did) not of sources that are updated as and when new information happens to come to hand, but of sources that are updated routinely. For example, System of Rice Intensification#Criticism said "as of 2019 there are over 1,000 articles ... published in ... journals"[1], citing a Web page. While editing I modified the text to report 1,200 articles in 2020; the Web page cited already had this figure. Someone reading the article needed to be encouraged to follow the source for the current figure.

However, the arguments against my suggestion being adopted for general-purpose use have merit; I now think the best solution is what I already do, to append "Frequently updated" to the citation, instead of allowing the date parameter to say this. Best wishes, Pol098 (talk) 15:09, 20 June 2020 (UTC)

|archive-url= can be a useful parameter to show the state of a given web page on a given date. – Jonesey95 (talk) 16:10, 20 June 2020 (UTC)

Is {{cite report}} actually limited to reports issued by governmental entities, or is it permissible to use it for reports issued by non-governmental corporations? Using {{cite web}} for scanned images of such reports doesn't feel right, and some such reports are available only on paper. Shmuel (Seymour J.) Metz Username:Chatul (talk) 13:57, 7 June 2020 (UTC)

Why wouldn't it be?

b

} 14:28, 7 June 2020 (UTC)

The first sentence, "This Citation Style 1 template is used to create citations for reports by government departments, instrumentalities, operated companies, etc.. ", in {{cite report}} seems to exclude non-governmental entities. Shmuel (Seymour J.) Metz Username:Chatul (talk) 17:27, 7 June 2020 (UTC)

There are bigger reliability problems with private-entity reports, both commercial & non-profit. Public-entity reports usually undergo a higher level of scrutiny, and are supposed to be impartial. Emphasis on "supposed to be". There is NO source that is a priori reliable. Some sources have been proven to be retroactively more reliable than others, in past cases. 64.61.73.83 (talk) 19:53, 7 June 2020 (UTC)

However, that is completely irrelevant in regard to our citation templates. They are just a vehicle to display in a standardized fashion what contributors to an article decide to include in an article. It is not up to a template or template editors or template documentation writers to recommend one type of source over another. If there are issues with

WP:RS

that is something that should be dealt with on article talk pages, not by "disallowing" certain types of sources (in the template documentation or even programmatically). Template documentation and help pages have zero "binding power" in this respect, only our policies and guidelines have. Ideally, template documentation should not discuss anything beyond just the technical matters, but where (for the convenience of the users) it overlaps into areas which are covered by our guidelines, it should just neutrally reflect what is written there.

{{

cite newspaper}}, {{cite magazine}}, {{cite conference

}}...).

The somewhat misleading documentation should be reworded accordingly.

--Matthiaspaul (talk) 15:46, 8 June 2020 (UTC)

Indeed the underlying reliability is irrelevant. As noted, there is no source that should be considered inherently reliable or unreliable. However there are some things that should be signaled in citations that may have an impact on perceived reliability. An example would be a self-published source. Sorry if this veers off-topic. 64.9.245.152 (talk) 23:54, 8 June 2020 (UTC)

Cases like this seem so rare that you might as well just write out the citation in plain text. New templates or parameters shouldn't be created for every single imaginable situation; doing that only serves to complicate things. Glades12 (talk) 09:14, 21 June 2020 (UTC)

Personally, I don't use cite report; instead I prefer to use {{cite book}} with |type=Report as appropriate. Most reports are long enough that the title should appear italics, and all cite report seems to do is not italicize the title and add a default type indicator. Imzadi 1979 → 12:52, 21 June 2020 (UTC)

I wouldn't do that myself because not all reports, even offline ones, are published in a book format. Another difference is that most reports aren't available in libraries (and instead have to be found in circulation or ordered directly from the publisher). Glades12 (talk) 16:35, 21 June 2020 (UTC) The latter unless they exist online, of course. 16:42, 21 June 2020 (UTC)

Cite report is quite anomalous in the CS1 scheme. All other templates render the main title of a source in either italics or quotation marks. CS1 is heavily based on the APA style of citation in that the elements (author, title, date, publisher, etc) appear in roughly the same order and formatting, but it was modified to handle URLs and source identifiers (ISBN, etc) more elegantly for our purposes. Reports in APA are rendered like books, so I find it entirely appropriate to render report citations here like books, regardless of how they may or may not be held in libraries or how their bindings may be constructed. (P.S. many government reports are deposited in libraries.) Imzadi 1979 → 17:42, 21 June 2020 (UTC)

I've been reviewing a draft concerning a company and it has references to a 2-3 minute news segment that has played on NBC Today show and later repeated on NBC Nightly News. Should it be cited with cite news (since it's news), cite AV media (since it's a video), cite episode (as part of a broadcasted news show)? It isn't a live segment, but on one of the shows, it was given like a 30-second introduction by the host. It also has its own producer, editor, and narrator/feature reporter. AngusWOOF (bark • sniff) 21:26, 3 June 2020 (UTC)

For me, {{cite news}} (presuming that the source is a news piece and not merely talking-head jabber). {{cite news}} supports |time= and |minutes= so you can specify when in the video the source supports our article.

—Trappist the monk (talk) 22:05, 3 June 2020 (UTC)

I'd recommend {{Cite episode}}. In my view, Cite news is only for actual (printed) newspapers, and Cite AV media is chiefly for recordings on other media than radio and TV. Glades12 (talk) 10:21, 24 June 2020 (UTC)

Because of this discussion at the help desk, I have added Easter as a named date:

{{cite news/new |title=Estate |work=Royal Military College magazine |date=Easter 1925 |pp=116-117}}

"Estate". Royal Military College magazine. Easter 1925. pp. 116–117.

—Trappist the monk (talk) 12:50, 26 June 2020 (UTC)

Could a parameter for translated title of the encyclopedia be added to {{Cite encyclopedia}}? Right now the only translated title parameter available is for the article within the encyclopedia. I noticed this issue at Angel Savov. Thanks! Calliopejen1 (talk) 18:00, 28 June 2020 (UTC)

Rewrite it:

{{Cite encyclopedia |last=Тошева |first=Кристина |url=https://books.google.com/books?id=x1kqAQAAIAAJ&newbks=0&printsec=frontcover&q=%D0%90%D0%BD%D0%B3%D0%B5%D0%BB+%D0%A1%D0%B0%D0%B2%D0%BE%D0%B2&hl=en |entry=Савов, Ангел Сотиров |title=Енциклопедия на българския театър: актьори, режисьори, драматурзи, сценографи, композитори, педагози, хореографи, критици, театри, институции, печат |trans-title=Encyclopedia of Bulgarian Theater |date=2008 |publisher=Trud |isbn=978-954-528-771-8 |language=bg}}

Тошева, Кристина (2008). "Савов, Ангел Сотиров". Енциклопедия на българския театър: актьори, режисьори, драматурзи, сценографи, композитори, педагози, хореографи, критици, театри, институции, печат [Encyclopedia of Bulgarian Theater] (in Bulgarian). Trud.

ISBN 978-954-528-771-8

.

—Trappist the monk (talk) 18:13, 28 June 2020 (UTC)

Thanks. But what if someone wants translations for both entry title and encyclopedia title? Seems like that could be needed/helpful fairly often. Calliopejen1 (talk) 01:21, 29 June 2020 (UTC)

Use |trans-entry=:

{{Cite encyclopedia |last=Тошева |first=Кристина |url=https://books.google.com/books?id=x1kqAQAAIAAJ&newbks=0&printsec=frontcover&q=%D0%90%D0%BD%D0%B3%D0%B5%D0%BB+%D0%A1%D0%B0%D0%B2%D0%BE%D0%B2&hl=en |entry=Савов, Ангел Сотиров |trans-entry=Savov, Angel Sotirov |title=Енциклопедия на българския театър: актьори, режисьори, драматурзи, сценографи, композитори, педагози, хореографи, критици, театри, институции, печат |trans-title=Encyclopedia of Bulgarian Theater |date=2008 |publisher=Trud |isbn=978-954-528-771-8 |language=bg}}

Тошева, Кристина (2008). "Савов, Ангел Сотиров" [Savov, Angel Sotirov]. Енциклопедия на българския театър: актьори, режисьори, драматурзи, сценографи, композитори, педагози, хореографи, критици, театри, институции, печат [Encyclopedia of Bulgarian Theater] (in Bulgarian). Trud.

ISBN 978-954-528-771-8

.

—Trappist the monk (talk) 02:45, 29 June 2020 (UTC)

As stated previously at #Trans-title for encyclopedia instead of just entry title, I think |trans-work=, which works in other templates, should work in this one too. Glades12 (talk) 07:04, 29 June 2020 (UTC)

I don't know if this is an error or intended, but if url-status is set to usurped or unfit, hovering the mouse over a <ref> link displays "cs1 maint: unfit (link)" (at least it does with Firefox 77.0.1 on my Win10/64 computer), although this isn't shown in the list of references. Hover over this link (until it's fixed).^[1]

Best wishes, Pol098 (talk) 23:20, 28 June 2020 (UTC)

Not really clear to me what it is that you mean. When I hover over the superscript [1] in your post, I get a pale-blue highlight over the entire citation rendered inside the {{reflist-talk}} template. Included in that is the CS1 maint: unfit url (link) message because I have maintenance message display enabled – because these messages are, for me, enabled, I see them all the time. This with current version chrome.

In and of themselves, the messages do no harm and may prompt an editor do do something about that particular citation.

—Trappist the monk (talk) 23:39, 28 June 2020 (UTC)

Thanks for response.
"Not really clear..." Sorry, I thought that this would display consistently. Before clarifying, I add that the issue also arises on an Android tablet (Android 7; same in Opera Mini and Firefox); while there is no mouse cursor to hover, the "maint" message is displayed following the reference in the list. What is shown (mouse hover in Windows, numbered ref in Android but not Windows) is:

"Wikipedia, the free encyclopedia - Main Page". English Wikipedia. Archived from the original on 31 March 2018. Retrieved 28 June 2020.CS1 maint: unfit url (link)

The link points to https://en.wikipedia.org/wiki/Category:CS1_maint:_unfit_url.

This on a system that is not set up to display maintenance messages, and never otherwise shows them.

"The messages do no harm": I don't think they are desirable; they are displayed to any reader, the only such messages displayed, but do not display in edit mode; clicking the link takes a reader to the technical Category:CS1 maint: unfit url. I think the issue is not merely "do no harm" (a matter of opinion), but "is the message there intentionally?". If it is (or is an artefact of my incorrect Wikipedia configuration), I withdraw my comment; I disagree but comply. If it isn't intended to be there, though, it shouldn't display.

By the way, where is the best place to discuss this (here or elsewhere), if it turns out that there is indeed something needing discussing? Best wishes, Pol098 (talk) 10:36, 29 June 2020 (UTC)

When I disable maintenance-message display, on the desktop view of this page, I do not see the maintenance message. When I then shift to mobile view (link at bottom of this page) and select this discussion, I see the unstyled maintenance message. The html produced by cs1|2 and MediaWiki for the message is exactly the same for both views (taken from right-mouse→View page source):

<span class="cs1-maint citation-comment">CS1 maint: unfit url (<a href="/wiki/Category:CS1_maint:_unfit_url" title="Category:CS1 maint: unfit url">link</a>)</span>

cs1|2 includes two classes in the wrapping <span>...</span> tag:

citation-comment – a user definable class that is used to hide or show all error and maintenance messages on a per-user basis from the user's personal css page

cs1-maint – defined in Module:Citation/CS1/styles.css:

.cs1-maint {
	display: none;
	color: #33aa33;
	margin-left: 0.3em;
}

But, when I do this same experiment with pages listed in Category:Category:CS1 maint: unfit url (and other maintenance categories), I do not see the maintenance messages in desktop view (as one would expect) nor do I see the maintenance messages in mobile view.

Where, exactly, did you first see this? Name the page and the reference.

If this is a recent occurrence, then the problem is likely not with cs1|2 (there have been no changes to cs1|2 since 18 April 2020) unless there are new requirements for mobile css that we are not aware of. You might raise this issue at

WP:VPT

. If you do, post a link to that discussion here.

—Trappist the monk (talk) 12:04, 29 June 2020 (UTC)

Where, exactly, did you first see this? I saw it first maybe months ago; I don't remember the page or date (I think well before 18 April 2020), but am quite sure it was as I described it here. I worked around it by setting |url= to the archived URL, and not using |archive-url= (after searching unsuccessfully for a better reference to the text sourced). I didn't see it again for a long time, but probably never used |url-status=usurped/unfit. Name the page and the reference. Last night I used this status in reference 7 of this edit of "Tissot", and got the message as I described. The Wikipedia Main Page example I give above behaved exactly the same as the Tissot page for me (and still does).

It sounds as if this might be due to my setup, or at least is infrequent enough not to have been raised before. It seems not to be the simple issue I thought it might be, and probably not worth bothering with unless others report it. If it's an error in my setup, I certainly don't want to waste anyone's time looking for it. Thanks again and best wishes, Pol098 (talk) 13:05, 29 June 2020 (UTC)

For the record, with maintenance messages enabled, I see the styled maintenance message at ref 7 of this version of Tissot in both desktop and mobile views. When I disable maintenance messages, I do not see the maintenance message in either view.

—Trappist the monk (talk) 13:27, 29 June 2020 (UTC)

The issue on this talk page is phab:T251024. If you cannot reproduce elsewhere, then it is likely the issue was corrected elsewhere. (To wit, there was a time where indeed this was an issue for some views, whether app, mobile, or desktop, sometimes in hover cards and sometimes elsewhere. Each of these has been fixed as its been exposed.) --Izno (talk) 16:02, 29 June 2020 (UTC)

• Tausch, Arno (15 October 2015). "Die Buchpublikationen der Nobelpreis-Ökonomen und die führenden Buchverlage der Disziplin. Eine bibliometrische Analyse" [The Book Publications of the Nobel-Prize Economists and the Leading Book Publishers of the Discipline. A Bibliometric Analysis] (in German).
  SSRN 2674502
  .

Fixed in the sandbox:

{{cite ssrn/new|title=Die Buchpublikationen der Nobelpreis-Ökonomen und die führenden Buchverlage der Disziplin. Eine bibliometrische Analyse|last1=Tausch|first1=Arno|date=October 15, 2015|language=German|trans-title=The Book Publications of the Nobel-Prize Economists and the Leading Book Publishers of the Discipline. A Bibliometric Analysis|ssrn=2674502}}

Tausch, Arno (15 October 2015). "Die Buchpublikationen der Nobelpreis-Ökonomen und die führenden Buchverlage der Disziplin. Eine bibliometrische Analyse" [The Book Publications of the Nobel-Prize Economists and the Leading Book Publishers of the Discipline. A Bibliometric Analysis] (in German).

SSRN 2674502

.

—Trappist the monk (talk) 13:01, 30 June 2020 (UTC)

Several instances of Cite book isbn parameters are now showing up as red links in my Wikiversity pages. See, for example: https://en.wikiversity.org/wiki/Transcending_Conflict#Further_Reading These have been in place for some time, so I suspect it has something to do with the recent CS1 to CS2 conversion. How can I correct these errors? Thanks! --Lbeaumont (talk) 15:48, 1 July 2020 (UTC)

Create a redirect?

b

} 16:10, 1 July 2020 (UTC)

(edit conflict)

The module suite is looking for a redirect ISBN → International Standard Book Number (this is true for all identifier labels). Without a redirect there will be a redlink. The change was implemented here at the 2020-04-18 update and by Evolution and evolvability at wikiveristy on 2020-05-31.

—Trappist the monk (talk) 16:16, 1 July 2020 (UTC)

 Fixed by creating redirect. – Jonesey95 (talk) 16:39, 1 July 2020 (UTC)

I would like to cite this document that I found via this page at the

It seems the paper ("Form: Personal history ...") is part of a certain issue (a dated release) of a report series ("JFK assassination system etc"). The papers originator ("author") is the CIA. The issue (and entire report series) compiler ("editor") is the short-lived Review Board. The disseminating entity ("publisher") is NARA. You could use {{cite report}}. Or, {{citation}}. Or, custom-cite manually. 64.9.245.153 (talk) 04:00, 27 June 2020 (UTC)

To add: Use the publisher's id, since that is the way the in-source location is classified. That would be the NARA docid. You can include the identifier for the including source too (the release-batch). The pub date is the date NARA made it public. The work date is the date the Review Board presented the release batch. 65.88.88.57 (talk) 14:29, 27 June 2020 (UTC)

Hey! This is a document from the JFK Assassination Records Collection at NARA. These documents are usually cited by the 13 digit record number at the top (AKA a RIF number). One example of how this might be done is in Michael Dobbs' book One Minute to Midnight where he uses styles like "JFKARC record no. 104-10324-1003". Perhaps you could add "NARA" in front of JFKARC to clarify. Or just explain the whole mess in your citation note. I don't think you need to explain what the CIA document is. Sometimes it can be quite hard to tell; in this case, the personal history statement is just one form in Conein's OP (Office of Personnel) file. Do not worry about citing dates on ARC docs, it can get very messy. Rgr09 (talk) 22:52, 27 June 2020 (UTC)

Sources should be cited so they can be found easily. The OP already has a clue: The way s/he found it in the first place, by visiting the publisher. Drilling down, it was found that this belonged to a certain department, which issued a series of reports. The document, produced by a certain agency, is an in-source location of one such report issue. If one comes to this page to ask about formatting a citation, it is presumed one wants to follow the related guidelines. 64.9.245.153 (talk) 02:34, 28 June 2020 (UTC)

Thank you all for your feedback! Much appreciated! -

Location (talk

) 20:50, 29 June 2020 (UTC)

Thanks again for all of your help. I'm wondering if what I have below is sufficient? I have not used this link that led me to the pdf.

Central Intelligence Agency (25 September 1961). Assassination Records Review Board (ed.). Form: Personal History Statement of Conein, Lucien Emile (PDF) (Report). JFK Assassination System. National Archives and Records Administration (published 24 July 2017). p. 3. DocId: 32399265. Retrieved 1 July 2020.

{{cite report |author=Central Intelligence Agency |author-link=Central Intelligence Agency |date=September 25, 1961 |title=Form: Personal History Statement of Conein, Lucien Emile |url=https://www.archives.gov/files/research/jfk/releases/docid-32399265.pdf |publisher=National Archives and Records Administration |publication-date=July 24, 2017 |editor=Assassination Records Review Board |page=3 |series=JFK Assassination System |id=DocId: 32399265 |access-date=July 1, 2020 }}

Thanks! -

Location (talk

) 18:58, 1 July 2020 (UTC)

I would say Lucien Emile Conein is the author, not the CIA. It isn't really settled for Citation Style 1 whether organizations involved in the creation of a work should be listed as an author/editor, or whether the organization should just be listed as the publisher. In this case, I agree with listing National Archives and Records Administration as the publisher. Since the report says deletions were made, if you can determine it was the CIA that controlled the deletions, I would but a note after the citation that the CIA censored it, thus:

• Conein, Lucien Emile (25 September 1961). Assassination Records Review Board (ed.). Form: Personal History Statement of Conein, Lucien Emile (PDF) (Report). JFK Assassination System. National Archives and Records Administration (published 24 July 2017). p. 3. DocId: 32399265. Retrieved 1 July 2020. Censored by Central Intelligence Agency

Jc3s5h (talk) 19:20, 1 July 2020 (UTC)

Read the particulars again. The document is a form produced by the Review Board responsible for making certain records of the JFK assassination public. These records were/are in possession of different government agencies. The form was published by NARA on 06-14-2017 classified with document id 32399265. This "JFK Assasination System Identification Form" identifies one such record: another form originating with the CIA whose subject is one "Conein, Lucien". As it happens with many if not all government agencies, the form's designer (and the completed form's sole proprietor) is the form's issuer. The applicant is not the "author" of anything. Nor imo could he be listed as a contributor: he contributed nothing to the authorship of the form. He could be listed as the form's subject (as identified in the NARA cover page), or a bit clumsily, I think, as the applicant in |others=. But the form's title includes that information. All of this is an approximation of course. The forms native to cs1/2 do not offer a perfect fit for such a citation. That is why it was suggested that a manual free-form citation may be a good option. 98.0.246.242 (talk) 01:16, 2 July 2020 (UTC)

Sorry, bad jokes.

I've been seeing, especially a lot of non-anglosphere articles, the practice of placing a year in |publisher=. I think it might be useful to have a tracking category for this practice. --Izno (talk) 12:42, 4 July 2020 (UTC)

There is truly no limit to ways editors misuse citation templates. Glades12 (talk) 16:54, 4 July 2020 (UTC)

• The Novel Coronavirus Pneumonia Emergency Response Epidemiology Team (2020). "The Epidemiological Characteristics of an Outbreak of 2019 Novel Coronavirus Diseases (COVID-19) — China, 2020". China CDC Weekly. 2 (8): 113–122.
  doi:10.46234/ccdcw2020.032
  .

{{cite journal/new|doi=10.46234/ccdcw2020.032|title=The Epidemiological Characteristics of an Outbreak of 2019 Novel Coronavirus Diseases (COVID-19) — China, 2020|year=2020|last1=Cdc Weekly|first1=China|journal=China CDC Weekly|volume=2|issue=8|pages=113–122}}

The Novel Coronavirus Pneumonia Emergency Response Epidemiology Team (2020). "The Epidemiological Characteristics of an Outbreak of 2019 Novel Coronavirus Diseases (COVID-19) — China, 2020". China CDC Weekly. 2 (8): 113–122.

doi:10.46234/ccdcw2020.032

.

—Trappist the monk (talk) 19:04, 4 July 2020 (UTC)

The original discussion has been archived without resolution. Are we keeping quarterly dates in some form? If we are keeping them, what is the definitive list of quarterly date formats that cs1|2 should accept?

—Trappist the monk (talk) 12:54, 26 June 2020 (UTC)

There is no formal resolution, but adequate guidance, imo. Quarter-based dates were supported. Ordinals to be avoided. People like both the abbreviated & full forms. The main thing is to have at least one option for entering such dates that does not return an error. 172.254.241.58 (talk) 13:12, 26 June 2020 (UTC)

Yes, yes, I know all that. The question was: what is the definitive list of quarterly date formats that cs1|2 should accept?

—Trappist the monk (talk) 13:16, 26 June 2020 (UTC)

"#Q [year]". "Q# [year]". "# Quarter [year]". "Quarter # [year]". "Month range may be substituted". 172.254.241.58 (talk) 13:32, 26 June 2020 (UTC)

Should there not be a comma between '#' and '[year]' when the two are adjacent? Isn't that the same as Month #, [year]? The issue of month-range-substitution is not something that the module should be doing because the module cannot know when a publisher's quarter begins and ends.

—Trappist the monk (talk) 14:20, 26 June 2020 (UTC)

Before I am willing to entertain what is the definitive list of quarterly date formats that cs1|2 should accept? I request the metadata be resolved.

The previous discussion used the emission of metadata as a justification for not adding some kind of flag to tell the module to just take the date as-is, and not check it. If we're going to use metadata as an excuse to scream false error messages, we should at least emit correct metadata. I remind all of a comment from the previous discussion by Trappist the monk:

COinS is a layer on top of OpenURL. COinS, from the documentation that I have been able to scrape from various places (see Module talk:Citation/CS1/COinS § References), uses a subset of OpenURL to which it adds certain constraints (for example, the quarter key/value pair is restricted to journal objects in COinS but may be used for all other objects in OpenURL).

Because we already parse months, seasons, and proper names into dates usable by COinS, it wouldn't be that difficult to parse 1st quarter 2020 into &rft.quarter=1&rft.date=2020. We went to great effort to eliminate date parts from cs1|2 (|day=, |month=) so we should not return to that method with |quarter=1.

—Trappist the monk (talk) 11:33, 17 May 2020 (UTC)

I therefore request specification of what metadata will be emitted and under which circumstances. I suggest that the metadata from the 11:33, 17 May 2020 (UTC) post be emitted, but only if the citation is recognized by the module as a citation to a journal (or at most, some periodical, such as a magazine). Otherwise only the year should be emitted. Jc3s5h (talk) 13:43, 26 June 2020 (UTC)

Objects that cs1|2 does not treat as periodicals do not render the quarter metadata:

{{cite book/new |title=Title |date=Fourth Quarter 1995}}

Title. Fourth Quarter 1995.

'"`UNIQ--templatestyles-00000037-QINU`"'<cite class="citation book cs1">''Title''. Fourth Quarter 1995.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Title&rft.date=1995&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+68" class="Z3988"></span>

Objects that cs1|2 treats as periodicals may emit the quarter metadata if the date is a properly formatted quarterly date:

{{cite magazine/new |title=Title |magazine=Magazine |date=Fourth Quarter 1995}}

"Title". Magazine. Fourth Quarter 1995.

'"`UNIQ--templatestyles-0000003B-QINU`"'<cite class="citation magazine cs1">"Title". ''Magazine''. Fourth Quarter 1995.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=article&rft.jtitle=Magazine&rft.atitle=Title&rft.quarter=4&rft.date=1995&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+68" class="Z3988"></span>

—Trappist the monk (talk) 14:20, 26 June 2020 (UTC)

In the prior discussion there seems to be a rough consensus for comma-less rendition. 69.193.187.30 (talk) 14:30, 26 June 2020 (UTC)

I have checked Chicago, Publication Manual of the American Psychological Association, and The Associated Press Stylebook 2019. I can find nothing about writing quarters, neither in running text, nor in citations.

My thoughts are

1. We should specify what will be accepted as input, what will be rendered, and what will be emitted as metadata.
2. We should decide if the rendered output will be capitalized. In the case of seasons, we decided that even though they aren't capitalized in running text, they are in CS1|2, because some style manuals capitalize seasons in citations. We have no such guidance in this case.
3. In documentation, if we need to specify whether suffixes like "st" and "rd" are to be added, we shouldn't use the word "ordinal" or related terms, because ordinal indicates that a set of things has an inherent order. Dates have an inherent order whether we add one of those suffixes or not. Jc3s5h (talk) 15:54, 26 June 2020 (UTC)

Re:

1. Date validation is just that: validation. If the date format is a 'valid' format, that is what cs1|2 renders. If the date format is invalid, cs1|2 does nothing with it except to render as-is and to emit an error message. When dates do not validate, metadata for that date is not emitted. When cs1|2 emits journal-object metadata, and when |date= (only) holds a quarterly date, cs1|2 will emit &rtf.quarter with a digit 1–4 specifying the quarter and &rtf.date specifying the year-portion of the date; no date metadata when |date= holds an invalid date.
2. Capitalized because it is part of a date just as seasons are capitalized when they are part of a date.
3. We don't accept ordinal suffixes with dmy / mdy dates so we should not accept ordinal suffixes with quarterly dates. I don't follow your argument against ordinal suffixes because quarterly [dates] have an inherent order whether we add one of those suffixes or not: 1st quarter precedes 2nd quarter precedes 3rd quarter precedes 4th quarter precedes 1st quarter ... Or, are you saying that we should not support spelled-out forms: 'First', 'Second', 'Third', 'Fourth'?

—Trappist the monk (talk) 17:07, 26 June 2020 (UTC)

A set of ordinal dates: {Christmas 2010; July 4th, 1976; 2020-06-2020}. They're ordinal because there is an inherent order. In order, the first element is July 4th, 1976. The second element is Christmas 2020. The third element is 2020-06-2020.

A non-ordinal set: {6642, 8K901173, J784901}. These are serial numbers of various pieces of hardware near my computer. There is no inherent order. But the cardinality is 3, because there are 3 elements in the set.

Oh by the way, ISO defines an ordinal date to be a year and day of year; today is 2020-178. Jc3s5h (talk) 17:49, 26 June 2020 (UTC)

This is why "ordinal" is not a good word to use while documenting anything to do with dates.

Date formats are fungible, and each format may have its own inherent order. It is correct to write 2020-06-25 and also June 25 2020. The ordinal here, as far as I understand it refers to the natural order of the date elements, not the entire date. Specifically, in the rendering of a Quarter's position. And even that may be arbitrary. Let's not get lost in detail. Pick the 3-4 most commonly used formats and apply them.

The original impetus for this was the fact that a certain publication date could not be rendered satisfactorily, presumably making it harder for readers to discover the source. That is what matters. 65.88.88.69 (talk) 18:27, 26 June 2020 (UTC)

65.88.88.69, thanks for providing yet another plausible meaning for "ordinal" in regards to dates. I regard "ordinal" as unusable in date discussions. Jc3s5h (talk) 19:24, 26 June 2020 (UTC)

Yeah, and while I support the addition of Quarters, what David suggested (in the old thread) originally was a way to suppress the error messages. I think we need both:

As many cases as are reasonally possible should be detected and supported by the code, but there will always be cases, which don't fit and starting discussions for individual things like "Easter" above seems inefficient to me (many people would never start a discussion about things like this and try to work around the issue - so we would never learn about areas where the templates lack support).

Instead, we should support the "((take this as it is))" syntax also for dates, and then put these cases into a maintenance category for evaluation. As it fills up we will see which patterns still need to be supported and so we can add direct support for them (probably in a more coordinated way than for individual examples like Easter. What about Christmas? What about Carnival? What about Summer holidays? What about Fiscal years? etc.) If not emptied manually a bot could occasionally clean up meanwhile supported formats by replacing the "((date))" by "date" in the corresponding citations.

And while we are in the process of adding support for Quarters, I think we should also add Quadrimesters and Semesters (following the example of EDTF).

--Matthiaspaul (talk) 08:52, 7 July 2020 (UTC)

How can I clarify by using this template that the url-access are only limited to a geographically area like norwegian IP-addresses ? Best regards and a safe and happy summer from Migrant (talk) 17:54, 7 July 2020 (UTC)

A cs1|2 template itself cannot do that. You can add explanatory text following the template and before the closing </ref> tag to explain the limitation.

—Trappist the monk (talk) 18:05, 7 July 2020 (UTC)

@Trappist the monk: Tried a version on Bjørge Lillelien and that article section for bibliography (Bjørge Lillelien#Bibliography). Hopefully that one is okay. Best regards Migrant (talk) 18:42, 7 July 2020 (UTC)

Please take a look at

Note that this will be responsible for a great deal of errors in

b

} 15:58, 8 July 2020 (UTC)

Any of the |<name-list>-mask= parameters, when given text, may include a semicolon name-list separator character so the extra punctuation test inappropriately adds the page to Category:CS1 maint: extra punctuation.

Fixed in the sandbox.

—Trappist the monk (talk) 12:36, 8 July 2020 (UTC)

... That's a use of the mask parameter I hadn't thought of. --Izno (talk) 12:58, 8 July 2020 (UTC)

And why should you? Such usage is incorrect. Masking parameters are there to mask other parameters. They should not be used for novel information. The documentation contortions needed to fully justify this inconsistency should be interesting. 65.88.88.69 (talk) 22:57, 8 July 2020 (UTC)

• {{Citation|chapter=Front Matter|date=2016|work=A Feminist Companion to Shakespeare|pages=i–xix|publisher=John Wiley & Sons, Ltd|language=en|doi=10.1002/9781118501221.fmatter|isbn=978-1-118-50122-1}}

Gives

• A Feminist Companion to Shakespeare, John Wiley & Sons, Ltd, pp. i–xix, 2016,
  ISBN 978-1-118-50122-1 {{citation}}: |chapter= ignored (help); Missing or empty |title= (help
  )

Module:Citation/CS1 uses the presence of any one of the |work= aliases as a control to shift {{citation}} from 'book' mode to 'periodical' mode. This is necessary for proper rendering of both types of citations and for the proper creation of the citation's metadata.

—Trappist the monk (talk) 10:58, 8 July 2020 (UTC)

This is a perennial issue. The bad design stems from the very first citation templates which badly mangled the meaning of "work". The resulting inconsistent treatment of |title= in serials vs one-offs continues. So every so often a similar question is asked. 65.88.88.69 (talk) 23:08, 8 July 2020 (UTC)

I propose that the namespaces of the parameters |script-title=, |script-chapter= and |script-work= be changed to use ISO 15924 codes instead. This has the benefits of eliminating ambiguity (for instance, whether a Chinese-language source is written in traditional or simplified characters, or whether a Mongolian one uses the Cyrillic or Traditional Mongolian writing system) as well as making it easier to properly display obscure scripts which are not presently known by CS1, but coded by the ISO. (See Category:Indonesian scripts for starter examples of the latter.) Glades12 (talk) 14:52, 22 June 2020 (UTC), updated 14:52, 1 July 2020 (UTC)

The HTML standard requires

BCP 47 (see [2]). --Izno (talk

) 15:14, 22 June 2020 (UTC)

Why? The scripts are what may be rendered wrong, not the languages themselves, right? Or am I completely mistaken? Glades12 (talk) 19:12, 22 June 2020 (UTC)

You are not mistaken. The proposal seems beneficial and uncontroversial. 65.88.88.69 (talk) 13:32, 23 June 2020 (UTC)

@Izno: You still haven't explained. Glades12 (talk) 17:55, 5 July 2020 (UTC)

Please read the provided links. If you still have questions, please let me know. --Izno (talk) 18:49, 5 July 2020 (UTC)

I have read both of them several times, and still do not understand how either supports the current system. Is the problem that the title needs to be pronounced correctly or accommodate users of different fonts? If that was the case, we would logically also require specific language codes in |title=, |quote=, etc.. The fact that we don't leads to the conclusion that only the scripts themselves are necessary to specify. Glades12 (talk) 19:36, 5 July 2020 (UTC)

The specification requires BCP 47. The syntax we output and accordingly require as input should conform to BCP 47 accordingly. Is that fact confusing? How so? --Izno (talk) 20:29, 5 July 2020 (UTC)

Template:MongolUnicode seems to work pretty well without it. Glades12 (talk) 06:55, 6 July 2020 (UTC)

That comment does not answer my question. --Izno (talk) 11:56, 6 July 2020 (UTC)

I don't know about you, but to me it shows that ISO 639 codes are not absolutely necessary just to display a script correctly. Glades12 (talk) 07:28, 7 July 2020 (UTC)

I did not argue that ISO 639 codes are necessary. Nor did you, until just now, indicate what you were attempting to do. I have no objection to BCP 47 codes, but the overhead associated with MongolUnicode is frankly unnecessary for this template for all languages and I would oppose on that basis an implementation of CSS in these templates. I suspect if you had actually comprehended

BCP 47 you would have observed that ISO 15924 is included as valid in the BCP, so the request to add accepting those codes seems valid, but you somehow have not brought that up yet. --Izno (talk

) 16:19, 7 July 2020 (UTC)

I'll be happy to read ISO 15924 just as $61.63 in the form of United States currency or a United States postal money order arrives in my physical mailbox. Until them I'm opposed. Jc3s5h (talk) 16:09, 7 July 2020 (UTC)

There is literally no way to know that from your links (do you expect everyone you meet to be a HTML genius?), and the way you replied made it seem like you did disagree. Anyway, sorry for the misunderstanding. Glades12 (talk) 12:47, 10 July 2020 (UTC)

I've suddenly seen several cite errors for citations with dates that use season ranges, for example in Franz Kafka:

• Panichas, George A. (Spring–Fall 2004). "Kafka's Afflicted Vision: A Literary-Theological Critique" (PDF). Humanitas. 17 (1–2). Bowie, Maryland. {{cite journal}}: Invalid |ref=harv (help)

These were not edited recently, so why would any recent change make this a new error? — Preceding unsigned comment added by Kennethaw88 (talk • contribs)

This looks like a bug possibly introduced by the work done for the addition of quarters that was made. Trappist the monk looks to be working on it. --Izno (talk) 00:20, 12 July 2020 (UTC)

I'm about to turn into a pumpkin so I'll get to it tomorrow morning. I know the cause, the issue is how to best fix it.

—Trappist the monk (talk) 00:24, 12 July 2020 (UTC)

Fixed, I think. Live module updated.

—Trappist the monk (talk) 12:00, 12 July 2020 (UTC)

To our citation template documentation such as Cite journal/doc#URL, could we add a sentence explaining that one should not add |url=http://dx.doi.org/10.2307/1440636 if there's already |doi=10.2307/1440636 defined, as was for instance here? Same goes for JSTOR or Worldcat (OCLC), where we don't need |url=http://worldcat.org/oclc/777999581 if there's already |oclc=777999581, as here. --bender235 (talk) 17:47, 24 June 2020 (UTC)

That doesn't seem like a common enough error to warrant yet another addition to a group of pages that are already so bloated with instructions that they're barely navigable. We should focus on cutting the CS documentation down. Glades12 (talk) 10:46, 25 June 2020 (UTC)

Depends on your definition of "common." I've been fixing this issue over the past couple of days with

AWB. The DOI-in-URL issue alone affects about 2,000 articles, and I was just scanning for the outdated dx.doi.org scheme. --bender235 (talk

) 16:41, 25 June 2020 (UTC)

There may be issues here. See § Auto-linking titles with free DOIs and the related RfC. 64.61.73.83 (talk) 20:12, 25 June 2020 (UTC)

Could you please elaborate on what issues you expect? The way I understand the linked RfC (which I missed, unfortunately, but in retrospect wholeheartedly support) a link is being placed under the article title if |doi= and |doi-access=free is set, but it does not mean we actually need to place anything in the |url= parameter. In fact, anything put in there would overwrite the DOI link. --bender235 (talk) 16:52, 28 June 2020 (UTC)

Mainly that the AWB edits may be at cross-purposes with the new auto-linking feature, or perhaps redundant. I see similar/additional concerns are discussed directly below. Not disputing the merit of your proposal, however. 98.0.246.242 (talk) 20:59, 29 June 2020 (UTC)

Okay, maybe it's enough then. Glades12 (talk) 07:19, 26 June 2020 (UTC)

This only holds true if the url added would be exactly the same as the link provided by doi. For example, if

|doi=10.1145/360569.360660

is already present in a citation, it does not make any sense to add:

|url=https://doi.org/10.1145%2F360569.360660

In many cases, it also would not make sense to add

|url=https://dl.acm.org/doi/10.1145/360569.360660

(the link the doi resolves forwards to at present), because the forwarding might go down in the future or resolve to something else, so the links are not exactly redundant - however, that's debatable.

However, even with |doi=10.1145/360569.360660 being present in a citation (and with DOI auto-linking enabled in the future), it still makes a lot of sense to add |url= if it points to a better source or even the actual document rather than only a metapage, so

|url=https://dl.acm.org/doi/pdf/10.1145/360569.360660

(a very similar looking link, but pointing to the PDF, rather than only to the metapage) is still appropriate to add, in particular since

|archive-url=https://web.archive.org/web/20200624113752/https://dl.acm.org/doi/pdf/10.1145/360569.360660

can be added as well then (it cannot for |doi= alone).

Example without url (in the future with DOI auto-linking):

Chen, Tien Chi; Ho, Irving Tze (January 1975). "Storage-Efficient Representation of Decimal Data".

S2CID 14301378

.

Preferred example with url:

Chen, Tien Chi; Ho, Irving Tze (January 1975). "Storage-Efficient Representation of Decimal Data".

S2CID 14301378. Archived

from the original on 24 June 2020. Retrieved 24 June 2020.

--Matthiaspaul (talk) 23:39, 25 June 2020 (UTC)