Help talk:Citation Style 1

From Wikipedia, the free encyclopedia
Jump to navigation Jump to search
Citation templates
... in conception
... and in reality

Generic title[edit]

Hello, could |title=Login be added as a generic title, |title=Login • Instagram appears to produce the "Cite uses generic title (help)" but not just |title=Login. Keith D (talk) 18:31, 10 June 2022 (UTC)[reply]

In my usage "Login" would be the title, while "Instagram" is either the work/website or the publisher, depending on this specific context. SamuelRiv (talk) 20:39, 23 June 2022 (UTC)[reply]

Proposed document edit[edit]

Currently the Work section contains the following sentence:

Aliases: journal, newspaper, magazine, periodical, website.

However, at least in the case of journal, the citation format can change from the layout for the 'work' option. For example:

work= : Gontcharov, G. A. (November 2006), "Pulkovo Compilation of Radial Velocities for 35495 Hipparcos stars in a common system", Astronomy Letters, vol. 32, no. 11, pp. 759–771, arXiv:1606.08053, Bibcode:2006AstL...32..759G, doi:10.1134/S1063773706110065, S2CID 119231169.
journal= : Gontcharov, G. A. (November 2006), "Pulkovo Compilation of Radial Velocities for 35495 Hipparcos stars in a common system", Astronomy Letters, 32 (11): 759–771, arXiv:1606.08053, Bibcode:2006AstL...32..759G, doi:10.1134/S1063773706110065, S2CID 119231169.

I'm proposing the sentence be changed to the following:

Aliases: journal, newspaper, magazine, periodical, website. (The alias journal will modify the citation format.)

Praemonitus (talk) 16:57, 20 June 2022 (UTC)[reply]

@Praemonitus I have no objection to you adding this clarification to the documentation. Be bold and make the edit! Thank you for your efforts to improve the documentation! GoingBatty (talk) 03:47, 24 June 2022 (UTC)[reply]

Proposed change or changes to the link status parameter[edit]

I started a discussion at Wikipedia:Village pump (technical)#Proposal to change citation templates which hurt articles' Google ranking and was told about this page. I'm not sure if this discussion will move here, but if not at least there is a link to the VP discussion.--Epiphyllumlover (talk) 17:48, 21 June 2022 (UTC)[reply]

Yes, I've seen quite a few such template instances that have an archive link but are still active. Perhaps the bot is checking the links at a time when there is an outage or a certificate issue? Sometimes it can be as simple as the link changing from http to https. Praemonitus (talk) 01:49, 22 June 2022 (UTC)[reply]
Among the suggestions at the Village Pump was to change the dead links to plain unlinked text. I haven't seen an example how that might look, but I suspect it would add considerable verbiage to the emitted text. I suggest that would be a bad thing; it would add horrible clutter. -- Michael Bednarek (talk) 02:36, 22 June 2022 (UTC)[reply]
There are inline googleoff and googleon tags that could be used. Praemonitus (talk) 03:41, 22 June 2022 (UTC)[reply]
Like nofollow, this should probably be a mainspace-wide issue. Another problem with delinking the "original" url is the case of preemptive archiving. In such cases the original link is not dead, only pre-empted. This is an efficient way of handling possible link rot, as it requires no maintenance, without any degradation of the reader-facing info. 172.254.222.178 (talk) 11:42, 22 June 2022 (UTC)[reply]
The citation templates already have a parameter, |url-status=live, to indicate preemptive archival linking. When used, the citation will continue to link to the original article, with the archive link only being listed as a backup. As such, there is no reason to de-link the originals in those cases, and all of the information is available to disable de-linking for those citations. It shouldn't be a problem. FeRDNYC (talk) 18:38, 23 June 2022 (UTC)[reply]
That wasn't quite what I'm envisioning, rather it was to add an extra parameter which could be used on some articles, and probably not much. There already is an extra parameter for inappropriate links. I would use it for articles where I'm concerned about Google ranking, because Google has changed and is apparently following links even when told not to. The discussion has since been archived at Wikipedia:Village pump (technical)/Archive 198#Proposal to change citation templates which hurt articles' Google ranking. It seemed like a roughly divided response, but one that could change if views on the site got worse. I don't expect it to be accepted at the moment.--Epiphyllumlover (talk) 22:35, 1 July 2022 (UTC)[reply]

Template:Cite magazine[edit]

This has both page= and pages= as required parameters. Is it possible to make the former unrequired as it is redundant to the latter, similar to the TemplataData of {{cite news}} and {{cite book}}? Kailash29792 (talk) 06:27, 22 June 2022 (UTC)[reply]

It's one or the other, and they are different. Compare
"Foobar". Barfoo Monthly. p. 9.
"Foobar". Barfoo Monthly. pp. 9–10.
Headbomb {t · c · p · b} 06:50, 22 June 2022 (UTC)[reply]
Why I brought this was, because the other two cite templates have only "pages=" which can be used even for single pages. So, consistency. Kailash29792 (talk) 06:55, 22 June 2022 (UTC)[reply]
??? Not true, both forms (singular & plural) exist as distinct parameters. Afaik there is no input validation to check if it matches the singular or plural form. 172.254.222.178 (talk) 11:26, 22 June 2022 (UTC)[reply]
I've always interpreted the singular form of the 'pages' parameter as listing the number of pages. Praemonitus (talk) 12:32, 22 June 2022 (UTC)[reply]
That is an incorrect interpretation; see |page= documentation (and |pages= documentation).
—Trappist the monk (talk) 12:53, 22 June 2022 (UTC)[reply]
How then does one list the number of pages? Praemonitus (talk) 16:36, 22 June 2022 (UTC)[reply]
|page= is used to list the singular page within a source that is being cited. |pages= is used to list the range of pages within a source that is being cited. For citation purposes, we do not care about the total number of pages within a work.
So for example, if I'm citing a magazine article that appears on just page 3 of the issue, I would use |page=3 to get "p. 3" listed in my citation. If instead that same article ran over to a second page, |pages=3–4 to get "pp. 3–4" or |pages=3, 7 to get "pp. 3, 7" in my citation. Imzadi 1979 → 16:44, 22 June 2022 (UTC)[reply]
"...we do not care about the total number of pages within a work." Is this some undocumented tribal knowledge? Just curious. Some digital papers don't have a normal page range, so the number of pages can provide the equivalent information. Praemonitus (talk) 01:23, 23 June 2022 (UTC)[reply]
@Praemonitus: the documentation mentioned above for |pages= says: "do not use to indicate the total number of pages in the source". The citation style is based on elements from APA and CMOS styles, neither of which cite the total number of pages in a work in a citation. Imzadi 1979 → 02:44, 23 June 2022 (UTC)[reply]
Okay, but that only applies to the specific parameter, not to listing the total pages in general. Praemonitus (talk) 04:39, 23 June 2022 (UTC)[reply]
There is no parameter for a magazine's (or a book's or a newspaper's …) total number of pages, because it's of no importance. OTOH articles in journals are often cited with teir total page range and the page number for the cited instance: Doe, Jane (24 December 1968). "The wider application of paper clips". Science. 17 (42): 121–132 (125).. -- Michael Bednarek (talk) 06:42, 23 June 2022 (UTC)[reply]
To add: Citation formatting developed/descended from bibliographic formatting, which developed/descended from catalog formatting (of works in libraries, mainly). Sources (works) have been generally classified by the published unit (book, periodical, website, audio/video recording etc.). So when citations point to specific locations within sources, the page or some other marker is necessary, in order to easily find the cited in-source item. For citation purposes, the total number of pages (or bytes, or minutes) is irrelevant. Bibliographies (like catalogs) sometimes include that information, mainly to further distinguish editions/versions. 68.132.154.35 (talk) 15:38, 23 June 2022 (UTC)[reply]
Okay, thanks for that explanation. I'll also repeat that the lack of need for this information doesn't appear to be explained to the editing community. Or at least I couldn't readily find it. The information about the number of pages is provided on some sources for citations, such as NASA ADS, so it seems appropriate to include it in a cite. Perhaps even a footnote on the topic would be useful? Praemonitus (talk) 14:06, 24 June 2022 (UTC)[reply]
Well, footnotes and citations are different things and exist for different reasons. Also, it is not useful to compare citations in Wikipedia with any other formal system, or any institutional practice. Wikipedia articles (and their citations, if any) are written by anonymous contributors of uncertain expertise, and are geared to a general, non-expert audience. As for this citation "style" (a misnomer as it includes many non-style-related elements), it is highly structured as far as Wikipedia norms are concerned, and accepts the data that fit the project parameters. In CS1, if there is no reference to a certain property (such as work length), it is highly likely that such property is not part of the system, and should not be expected to make an appearance. Highly structured does not mean correctly structured, but in the particular case under discussion CS1 is codifying the correct approach imo. 68.132.154.35 (talk) 18:42, 24 June 2022 (UTC)[reply]
|page= and |pages= are not required parameters for {{cite magazine}} nor for any of the other 20-ish cs1|2 templates. Are you seeing something somewhere that says that in {{cite magazine}} |page= or |pages= is required? If so, where are you seeing that 'requirement'?
—Trappist the monk (talk) 12:02, 22 June 2022 (UTC)[reply]
Again, it's one or the other, and they are different. Compare
"Foobar". Barfoo Monthly: 9-10.
"Foobar". Barfoo Monthly: 9–10.
The first has a hyphen, the second an endash. Headbomb {t · c · p · b} 12:03, 22 June 2022 (UTC)[reply]
Ya'll, see the end of the original sentence: TemplateData. $OP is not referencing what is actually required.
That said, {{cite magazine}}'s current documentation says suggested for both |page= and |pages=. Indeed, where are you seeing otherwise Kailash29792? Izno (talk) 16:00, 22 June 2022 (UTC)[reply]
By mistake. I confused suggested and required. Alright, is it okay to remove page= from suggested and retain pages=? Kailash29792 (talk) 03:21, 23 June 2022 (UTC)[reply]
Not really, because it depends on whether or not you're citing one page or many. Headbomb {t · c · p · b} 04:07, 23 June 2022 (UTC)[reply]

Chicago Manual of Style 17th ed. ¶ states

In notes, where reference is usually to a particular passage in a book or journal, only the page numbers pertaining to that passage are given. In bibliographies, no page numbers are given for books cited as a whole; for easier location of journal articles or chapters or other sections of a book, the beginning and ending page numbers of the entire article or chapter are given.

My recollection from university are that if one's own library didn't hold a particular journal, it might be possible to get another library to send a copy of an article, and it was expected to include the page range of the article so that the student-employee who actually made the copy would not have to judge where the article began and ended. When using citation templates, we could use cite xxx for the book or article in a bibliography and {{sfn}} with the page(s) that support the claim in the Wikipedia article. Jc3s5h (talk) 11:27, 23 June 2022 (UTC)[reply]

That's the practice that I follow and I do so for that very reason; inter-library loan is much easier when you know the page range. Mackensen (talk) 19:49, 24 June 2022 (UTC)[reply]

Error in author parameter[edit]

If you add {{Interlanguage link|Example|sv|Example}} for author "CS1 maint: multiple names: authors list (link)" will pop up in web cite template. Eurohunter (talk) 21:13, 22 June 2022 (UTC)[reply]

Not an error. See the template documentation for {{ill}} in particular the Mbox with the Stop hand nuvola.svg image.
To interwikilink an author's name, write |author-link=:sv:Example.
—Trappist the monk (talk) 21:26, 22 June 2022 (UTC)[reply]
@Trappist the monk: Yes but then people say they are surprised that article is Swedish and they want to see this Christopher Friman [sv]. Eurohunter (talk) 17:30, 24 June 2022 (UTC)[reply]
This has been discussed here several times, and it seems that {{ill}} is not going to be supported. The obvious workaround is to construct a manual citation. -- Michael Bednarek (talk) 02:23, 25 June 2022 (UTC)[reply]

Update the module[edit]

I've asked 2 months ago and was ignored. Can the module be updated with the pending changes? Gonnym (talk) 14:02, 23 June 2022 (UTC)[reply]

The previous update to the modules was on 22 January 2022. We usually list the changes here for comment for about a week before updating. I propose that an admin update the modules no earlier than 1 July 2022, one week from today. In the interim, I have marked this request as "answered" so that it does not sit in the edit request queue. That does not mean it is actually answered; it should be reactivated on 1 July.
Updates to the modules, based on the notes in the sandboxes, will be:
I think that is all of the changes, aside from trivial changes to things like PMID limits that have already happened in the live modules. If not, please amend the list above. Corrections to the above are welcome. – Jonesey95 (talk) 15:29, 23 June 2022 (UTC)[reply]
I have reactivated this edit request, since a week has passed since I posted the details above. Can an admin please update the modules listed above? Thanks. – Jonesey95 (talk) 16:59, 1 July 2022 (UTC)[reply]

Tracking (more) cites with generic author names[edit]

A couple of months ago, Jonesey95 pointed out the large number of citations using the author last name "By", and provided a handy search. I was able to expand that to capture a few more, by adding last1= through last4= to the regexp (and then remove a few by limiting it to the Article namespace). There are, nevertheless, nearly 200 such citations. Jonesey95 wondered if, perhaps, |last=By could be flagged as a generic name by the CS1 Module, as names like "Editors" and other generics already are.

David Eppstein correctly pointed out that By is a valid surname, particularly in Norway, as illustrated by three biographical article links to the Norwegian Wikipedia. Jonesey95 conceded that, in the original search, there were two cites to authors named "By" that appeared to be genuine.

Be that as it may, in looking over the results of my search, I noted a couple of patterns:

  1. The citation has an author |last[1234]?=By with no corresponding |first[1234]?= parameter at all.
  2. The citation has an author |last[1234]?=By with a corresponding |first[1234]?= containing a detectably generic string.
    • Overwhelmingly, the majority are citations to |last=By |first=Provided. (Such citations also comprise all of the |last2= |first2= matches I've seen so far.)
    • Occasionally, |last=By |first=Audio is used.
    • There's one instance of |last=By |first=Admin which is particularly bizarre (I could see if the first/last were reversed), but whatever..

As such, it seems to me that there's more than enough information available to detect abusive uses of |last[1234]?=By in citations, and to include them in Category:CS1 errors: generic name, without any of the false-positive flagging of real authors named "By" that David Eppstein was concerned about. There's no reason generic-name detection has to operate exclusively on a single citation parameter in isolation, when it can incorporate the other parameters (or lack thereof) to enable more advanced and accurate detection. FeRDNYC (talk) 19:45, 23 June 2022 (UTC)[reply]

One check that can also be useful is all-numeric / close to all numeric entries in last/first. Like if you have |first=2015-09 that's clearly an issue. Headbomb {t · c · p · b} 20:14, 23 June 2022 (UTC)[reply]
I thought there was already a CS1 error for "date in <non-date parameter>" or something like that, no? I'll have to check. If not, I can certainly agree that would be useful to watch for. FeRDNYC (talk) 20:36, 23 June 2022 (UTC)[reply]
Aha! there's already a name_is_numeric check in the module, as it turns out. It actually looks for any string consisting entirely of non-alphabetic characters. (The actual code is this:) 
if mw.ustring.match (name, '^[%A]+$')
Where %A is the Lua pattern-matching equivalent of [^a-zA-Z] in standard Perl-Compatible Regular Expression syntax.) So it should already detect "name"s like 2015-09. FeRDNYC (talk) 21:28, 23 June 2022 (UTC)[reply]
(Pretend I wasn't being a tedious American stereotype there, by acting as if names contain ASCII characters exclusively. Unicode letter glyphs like ä, ç, è, and etc. are undoubtedly also supported by the version of Lua pattern-matching implemented in mw.ustring.match.) FeRDNYC (talk) 21:37, 23 June 2022 (UTC)[reply]
Pinging Trappist the monk to the discussion as the primary author of the current generics detection code. FeRDNYC (talk) 20:35, 23 June 2022 (UTC)[reply]
Hmm, looking at the current generic detection code (local function name_checks at line 1401 of the current Module:Citation/CS1), I see that generic-name detection is performed as either a pattern or simple string search on each of the last and first parameters in turn. So, detections that target specific paired uses of |last= & |first= probably aren't possible with the current code.
I would propose, to Trappist, the addition of a further ['full_generic_names'] list, against which a check is run on a joined representation of the entire author name. (So, effectively, undoing the splitting performed by extract_names before checking the name.) that would allow detection of joined names like these:
  • provided by
  • audio by
  • admin by
  • ^by$
Which would cover the vast majority, if not all, of the problematic uses of |last=By that Jonesey95 originally pointed out, without any false positives on valid uses of |last=By. And we'll probably find more instances where it's useful for detecting other generics, as well.
The ['full_generic_names'] list would hopefully be much shorter than the ['generic_names'] list used to check first/last names separately, so scanning it hopefully wouldn't have a severe impact on performance. (Please correct me if I'm wrong about that.) Could something like that be a workable approach to generic whole-name detection, where the individual first/last name(s) alone don't tell enough of the story? FeRDNYC (talk) 21:17, 23 June 2022 (UTC)[reply]
Maybe I misunderstand your proposal, but wouldn't adding say, "provided", "audio" etc. in Module:Citation/CS1/Configuration's 'generic_names' list accomplish similar results? These terms would be considered generic whether they appear in |lastn= or |firstn=. 71.105.141.131 (talk) 23:26, 23 June 2022 (UTC)[reply]
It would accomplish results, but not necessarily similar ones. I guarantee there's someone, somewhere in the world with the first or last name "Audio". "Provided" isn't outside the realm of possibility, either. (Edit: And that still doesn't cover the question of "By" alone, which is insufficiently generic as a first or last name but is flaggably generic when used as the entire name. That's something the current code can't detect.) FeRDNYC (talk) 00:04, 24 June 2022 (UTC)[reply]
Ok, but by the same token, any term or combination of terms may exist somewhere as a name. And there is the issue of code efficiency and code complexity. Perhaps a certain number/percentage of such generics should actually be detected in live citations before any list/code expansion is considered. 65.254.10.26 (talk) 00:21, 24 June 2022 (UTC)[reply]
Well, we have numbers on "By": Nearly 200 cites with the last name "By". A couple are seemingly genuine. A large percentage of them are of the (currently undetectable) form |last=By |first= (meaning, no first-name value provided). I'd guesstimate 80-90%, from looking through the matches. It's hard to be exact, because you can't search for the lack of a parameter without getting into unworkably complex regular expressions that the server will reject as too expensive. FeRDNYC (talk) 00:29, 24 June 2022 (UTC)[reply]
Then again, a search for cites with "Audio" as the first or last name finds 17 matches, all of which are flaggably generic. (Mostly, they're cites from some audio website that use the name of the site as the author name.) So "Audio" may be a good candidate for generic_names regardless. FeRDNYC (talk) 00:22, 24 June 2022 (UTC)[reply]
Meh. If we add ^by$ to the list and the test just happens to catch a real name (surname or given) we have the accept-this-as-written markup that will bypass the error detection. For example, Twitter and Google are both generic names so this cite emits error messages:
{{cite book |first=Google |last=Twitter |title=Title}}
Twitter, Google. Title. {{cite book}}: |last= has generic name (help)
with the markup, no error messaging:
{{cite book |first=((Google)) |last=((Twitter)) |title=Title}}
Twitter, Google. Title.
I don't think that adding 'audio' is worthwhile if there really are only 17 hits; just fix them. A similar search for 'provided' returned 6 hits (timed out so there could be more) so, again, just fix them. I think that we rejected testing for 'admin' because it was suggested that there might be too many false positives where 'admin' really is the author.
—Trappist the monk (talk) 00:58, 24 June 2022 (UTC)[reply]
Fair 'nuff. I find myself in agreement with Jonesey95's original proposal that ^by$ is a good candidate for the generics, then. The five or six false positives (now that I've looked through the entire list), as you say we can mark as accept-as-written, and there are still close to 195 more that are flaggable.
There are also a number of cites, I'm now seeing, that use |last=By |first=<entire_author's_name>, so it'd be nice to have the generics matching find those as well. I just fixed one... FeRDNYC (talk) 01:10, 24 June 2022 (UTC)[reply]
Regarding I don't think that adding 'audio' is worthwhile if there really are only 17 hits; just fix them.: While I understand and can appreciate that position, it does also sort of implicitly assume that no more instances will be created in the future.
If all of the "Audio" links were really old and just never got cleaned up, that'd be fine. We could just fix those 17, and that would be that. But this one was added in 2019, and this one in May 2020.
(The second one is actually a cite to a YouTube video, posted by the account "Madhura Audio". I'm not 100% sure what our policies are on that; perhaps it's even correct for the author to be listed as "Madhura Audio". But the cite is written as |first1=Madhura|last1=Audio which definitely feels wrong to me. Business YouTube accounts don't have first and last names, they're not people.) FeRDNYC (talk) 07:13, 24 June 2022 (UTC)[reply]

i18n Season YYYY–YYYY date fix[edit]

Wikis that use the cs1|2 module suite and allow local names for Season YYYY–YYYY dates don't work. Fixed in the sandbox. To show that I have not broken anything here, these two should not display error messages:

  • {{cite book/new |title=Title |date=Winter 2008–2009}} → Title. Winter 2008–2009.
  • {{cite book/new |title=Title |date=Summer 2008–2009}} → Title. Summer 2008–2009.

these three should show error messages:

  • {{cite book/new |title=Title |date=Spring 2008–2009}} → Title. Spring 2008–2009. {{cite book}}: Check date values in: |date= (help)
  • {{cite book/new |title=Title |date=Fall 2008–2009}} → Title. Fall 2008–2009. {{cite book}}: Check date values in: |date= (help)
  • {{cite book/new |title=Title |date=Autumn 2008–2009}} → Title. Autumn 2008–2009. {{cite book}}: Check date values in: |date= (help)

—Trappist the monk (talk) 14:03, 25 June 2022 (UTC)[reply]

If you intend this to go into production in a few days, can you please add this to the change log above for the upcoming module update? Thanks. – Jonesey95 (talk) 23:00, 26 June 2022 (UTC)[reply]

Suggestions to expand "Cite uses generic title/name" errors[edit]

Could someone please expand the "Cite uses generic title" error to also include "PressReader.com - Digital Newspaper & Magazine Subscriptions"? There seem to be 272 articles with this text in the |title= parameter. Thanks! GoingBatty (talk) 19:54, 25 June 2022 (UTC)[reply]

@Trappist the monk: Is this suggestion worth considering? Thanks! GoingBatty (talk) 00:30, 2 July 2022 (UTC)[reply]
Not for me to say. The community appear to be indifferent so ...
—Trappist the monk (talk) 11:00, 2 July 2022 (UTC)[reply]
@Trappist the monk: Not all of us. :-) GoingBatty (talk) 18:47, 2 July 2022 (UTC)[reply]

@Trappist the monk: Could you please consider expanding the "Cite uses generic name" error to also include |last=Admin and |author=Admin ("Admin" and "admin")? There seem to be over 3,300 articles with this text . Thanks! GoingBatty (talk) 00:36, 2 July 2022 (UTC)[reply]

Have a look in the archives. I think that we decided against 'admin' because it is too often a legitimate author name.
—Trappist the monk (talk) 10:56, 2 July 2022 (UTC)[reply]
@Trappist the monk: Aha - found Help talk:Citation Style 1/Archive 79#Unlikely authors where "Admin" was already discussed. Thanks! GoingBatty (talk) 18:47, 2 July 2022 (UTC)[reply]

Catalogue numbers in {{cite}} templates[edit]

Originally posted at Village pump (idea lab), it was suggested that here would be a better place.

Hi all, am I the only person who finds the layout of catalogue numbers (eg isbn, jstor, oclc, doi) a bit intrusive? I came across James Leasor#Bibliography, which is a good example of how they can dominate the screen. I find that small caps ISBN 9780552105866 are much less wearing on the eye than ISBN 9780552105866, and are the same size as a standard url link. I'm sure no-one would advocate url links this size. Would there be a case for incorporating this into all the the {{cite}} and similar templates? I imagine it would be trivial to implement, but what do others think? I should mention that my prefs/gadgets include "Disable smaller font sizes of elements such as infoboxes, navboxes and reference lists", but there is still an inconsistency in the relative 'importance' of the information. Cheers, MinorProphet (talk) 10:05, 29 June 2022 (UTC)[reply]

A few observations:
  • Citation templates are not bibliographic records, and are not the proper tool for descriptive bibliographies like the one in the article you linked. Citations exist to help discover works that support article wikitext, not to populate work lists.
  • The "numbers" you mention can be very important in discovering works, and they are the most easily consulted information for this purpose, as they are always indexed.
  • Because of the above, where citations are concerned, it is not imo a good idea to diminish their screen real estate, and citation templates should adhere to that.
Bibliography lists are a different animal. Perhaps non-citation-template based lists can be formatted differently. But structured citation formats like CS1 have different approaches to presentation, where function is more important than form. 172.254.222.178 (talk) 12:16, 29 June 2022 (UTC)[reply]
"Citations exist to help discover works that support article wikitext, not to populate work lists." Citations templates can definitely be used to populate lists of works though. It's a perfectly legitimate use case. Headbomb {t · c · p · b} 14:19, 29 June 2022 (UTC)[reply]
You can use anything to list anything, but that is not why citations exist. They exist to cite sources. Citations, and their narrow representation as templates, can make for very stunted bibliographies. 50.75.226.250 (talk) 14:55, 29 June 2022 (UTC)[reply]
MinorProphet, please see MOS:SMALLFONT for the reason we can't do this. Text in {{reflist}}, where the vast majority of cite templates exist, is already rendered at 90% of the nominal page size, and we can't go below 85%. – Jonesey95 (talk) 13:33, 29 June 2022 (UTC)[reply]
Why would reducing the size of important discovery items (relative to the rest of the citation) be even considered? Is this just an intellectual exercise? 50.75.226.250 (talk) 15:02, 29 June 2022 (UTC)[reply]
This can be worked around however. Today |format= takes a diminished size and could be even smaller than it is if someone wanted it. Izno (talk) 17:16, 29 June 2022 (UTC)[reply]
Not relevant. |format= is a post-discovery helper parameter for |url=. Identifiers such as those mentioned by the OP are discovery parameters, and should not be visually demoted relative to the rest of the citation. Perhaps all these "ideas" are humorous and I am missing the joke. 172.254.155.50 (talk) 19:49, 29 June 2022 (UTC)[reply]
A statement about the technical feasibility of a change, correcting another's misstatement, is not a judgement of the change itself, regarding particularly the identifiers.
As for |format=, before the TemplateStyles change, it was actually at 85%, but 85% times the 90% Jonesey makes a comment about was indeed much smaller than the 85% of total. Something in the realm of 76.5%. I bumped it up to 95% then having realized that we were missing the 85% mark. Izno (talk) 20:06, 29 June 2022 (UTC)[reply]

Thanks to all for your comments and suggestions. Looks like that's a no, then. MinorProphet (talk) 17:00, 1 July 2022 (UTC)[reply]

vauthors bug for period saints[edit]

No, I'm not talking about CS1 being biased against Medieval Catholicism, although this bug did come up when editing the Quran article. The period in "St. Clair" throws an error (regardless of the hyphenation). Just for fun I tested some other possible problematic names I could think of but those seem fine.

{{cite web|vauthors=Warraq I, St. Clair-Tisdall W, de la Croix CC, O'Conner TS |url=http://debate.org.uk/topics/books/origins-koran.html |title=The Origins of the Koran |website=The Debate |access-date=15 March 2011}}

Warraq I, St Clair-Tisdall W, de la Croix CC, O'Conner TS. "The Origins of the Koran". The Debate. Retrieved 15 March 2011. {{cite web}}: Vancouver style error: punctuation in name 2 (help)

{{cite web|vauthors=Warraq I, St Clair-Tisdall W, de la Croix CC, O'Conner TS |url=http://debate.org.uk/topics/books/origins-koran.html |title=The Origins of the Koran |website=The Debate |access-date=15 March 2011}}

Warraq I, St Clair-Tisdall W, de la Croix CC, O'Conner TS. "The Origins of the Koran". The Debate. Retrieved 15 March 2011.

Note this even fails if using the tag display-authors=1. My brief search didn't yield whether Vancouver says to not use such punctuation. SamuelRiv (talk) 23:29, 30 June 2022 (UTC)[reply]

Not a bug. Vancouver style drops the dot from St. Whatever; see Surnames with hyphens and other punctuation in them.
—Trappist the monk (talk) 23:36, 30 June 2022 (UTC)[reply]
Cool thanks, good to know. My google-fu black belt is apparently revoked. SamuelRiv (talk) 23:39, 30 June 2022 (UTC)[reply]

RfC: Should Citation bot use cite web, or cite magazine, or cite news?[edit]

 – Redrose64 🌹 (talk) 08:13, 2 July 2022 (UTC)[reply]

If an article is published on a website associated with a magazine, or newspaper, but does not appear on the print edition of the publication, should you use {{Cite web}}, or {{Cite magazine}}, or {{Cite news}}? Sideswipe9th (talk) 23:55, 30 June 2022 (UTC)[reply]

Should you use {{Cite web}}, or {{Cite magazine}}, or {{Cite news}}?
Reasoning to use {{cite web}} Reasoning to use {{cite magazine}} or {{cite news}}
  • The websites are not the same as the physical publication.
  • Content published exclusively on the website of a publication is not the same as content published in the publication.
  • Many publications separate print editions, digital editions, and website content.
  • Specialised templates should only be used for print or digital editions of a publication. Not content on their websites.
  • Content published exclusively on the website of a publication is the same as content published in a publication.
  • The only difference between print editions, digital editions, and website content is the delivery mechanism.
  • Specialised templates should be used for any content published by the publication, via any delivery mechanism.
  • Using a specialised template ensures that the correct COinS metadata is embedded for reference management software.
  • For readers consuming the content via a browser, there is no difference between the generic or specialised templates.
The full past discussion on this can be found at here.
Example URLs for website only articles

Which citation template should be used for: https://ew.com/movies/doctor-strange-in-the-multiverse-of-madness-cast/

{{Cite web |last=Romano |first=Nick |date=December 10, 2020 |title=Doctor Strange sequel confirms cast, will tie into ''Spider-Man 3'' |url=https://ew.com/movies/doctor-strange-in-the-multiverse-of-madness-cast/ |url-status=live |archive-url=https://web.archive.org/web/20201211011901/https://ew.com/movies/doctor-strange-in-the-multiverse-of-madness-cast/ |archive-date=December 11, 2020 |access-date=December 10, 2020 |website=[[Entertainment Weekly]]}}

Romano, Nick (December 10, 2020). "Doctor Strange sequel confirms cast, will tie into Spider-Man 3". Entertainment Weekly. Archived from the original on December 11, 2020. Retrieved December 10, 2020.

{{Cite magazine |last=Romano |first=Nick |date=December 10, 2020 |title=Doctor Strange sequel confirms cast, will tie into ''Spider-Man 3'' |url=https://ew.com/movies/doctor-strange-in-the-multiverse-of-madness-cast/ |url-status=live |archive-url=https://web.archive.org/web/20201211011901/https://ew.com/movies/doctor-strange-in-the-multiverse-of-madness-cast/ |archive-date=December 11, 2020 |access-date=December 10, 2020 |magazine=[[Entertainment Weekly]]}}

Romano, Nick (December 10, 2020). "Doctor Strange sequel confirms cast, will tie into Spider-Man 3". Entertainment Weekly. Archived from the original on December 11, 2020. Retrieved December 10, 2020.

Which citation template should be used for: https://www.washingtonpost.com/technology/2022/04/25/twitter-elon-musk-deal/

{{Cite web |last=MacMillan |first=Douglas |last2=Siddiqui |first2=Faiz |last3=Lerman |first3=Rachel |last4=Telford |first4=Taylor |date=April 25, 2022 |title=Elon Musk acquires Twitter for roughly $44 billion |url=https://www.washingtonpost.com/technology/2022/04/25/twitter-elon-musk-deal/ |url-access=limited |url-status=live |archive-url=https://web.archive.org/web/20220425201853/https://www.washingtonpost.com/technology/2022/04/25/twitter-elon-musk-deal/ |archive-date=April 25, 2022 |access-date=April 26, 2022 |website=[[The Washington Post]]}}

MacMillan, Douglas; Siddiqui, Faiz; Lerman, Rachel; Telford, Taylor (April 25, 2022). "Elon Musk acquires Twitter for roughly $44 billion". The Washington Post. Archived from the original on April 25, 2022. Retrieved April 26, 2022.

{{Cite news |last=MacMillan |first=Douglas |last2=Siddiqui |first2=Faiz |last3=Lerman |first3=Rachel |last4=Telford |first4=Taylor |date=April 25, 2022 |title=Elon Musk acquires Twitter for roughly $44 billion |url=https://www.washingtonpost.com/technology/2022/04/25/twitter-elon-musk-deal/ |url-access=limited |url-status=live |archive-url=https://web.archive.org/web/20220425201853/https://www.washingtonpost.com/technology/2022/04/25/twitter-elon-musk-deal/ |archive-date=April 25, 2022 |access-date=April 26, 2022 |newspaper=[[The Washington Post]]}}

MacMillan, Douglas; Siddiqui, Faiz; Lerman, Rachel; Telford, Taylor (April 25, 2022). "Elon Musk acquires Twitter for roughly $44 billion". The Washington Post. Archived from the original on April 25, 2022. Retrieved April 26, 2022.

Survey[edit]

  • Use {{cite magazine}} or {{cite news}}: I'm pretty firmly of the opinion that we should use {{cite magazine}} or {{cite news}} as appropriate for a source. I do not see a difference between content that appears in the print edition of, for example, Entertainment Weekly and content that appears on Entertainment Weekly's website. Sideswipe9th (talk) 23:55, 30 June 2022 (UTC)[reply]
  • Use {{Cite web}}: A website associated with a magazine or newspaper is a different entity from the print magazine or newspaper. Due to cost and space constraints, many articles are only published on the magazine or newspaper-associated website, but are not present on the print edition. As a result, it is inaccurate to state that an article that appears on a magazine or newspaper-associated is equivalent to an article from a print magazine or newspaper. Many print magazine and newspaper publishers also publish digital PDF-style editions of their magazines and newspapers, which would more accurately fit the description of an online magazine. A website associated with a magazine or newspaper is inherently a website, and websites should be cited using {{Cite web}}. Finally, {{Cite magazine}} and {{Cite news}} contain parameters not found on {{Cite web}} that are not applicable to articles published on magazine or newspaper-associated websites, such as |volume= and |issue=. There is therefore no substantial benefit to use those two templates over {{Cite web}}. InfiniteNexus (talk) 00:47, 1 July 2022 (UTC)[reply]
  • Use {{cite magazine}}/{{cite news}}: much like online journals are journals, which should be cited with {{cite journal}}, online magazines are magazines, and should be cited with {{cite magazine}} template. This emits the correct metadata, and respects the principle of least surprise. It is also useful for our WP:MCW compilation, just like {{cite journal}} is useful for our WP:JCW compilation. {{Cite web}} is for general websites and other online sources that aren't covered by the other templates, per its documentation, and should ideally not be used for magazines. The same applies for {{cite news}}. Headbomb {t · c · p · b} 03:47, 1 July 2022 (UTC)[reply]
  • Speedy close as WP:POINTy and malformed RFC by a small group of editors butthurt that their opinions were second-guessed by a bot, per earlier discussion. Also, the question is written in a way that presupposes that group's intended answer, that being published on a website is somehow different from being in "the print edition" of a magazine, as if such a thing always exists these days. And it fails to distinguish magazine content on the web site (for which the correct answer in my opinion is {{cite magazine}} regardless of print appearance) from other content that happens to be on the same site (like say an faq on subscriptions, which I think should use {{cite web}}) As such, the wording is too prejudicial to produce a meaningful result, and incapable of being answered in a way that would actually describe my position. —David Eppstein (talk) 05:56, 1 July 2022 (UTC)[reply]
Nice try. There was consensus in the discussion above for an RfC (save for opposition from two editors) since participants were equally split on the issue. Falsely describing editors who disagree with your views as WP:POINTy and disruptive is deeply uncivil and not assuming good faith. InfiniteNexus (talk) 16:31, 1 July 2022 (UTC)[reply]
A small group of people repeating the same points over and over and over and over again until everyone else gets tired and stops responding is not consensus for action, it is WP:BLUDGEONING. And this RFC is continued bludgeoning. —David Eppstein (talk) 19:02, 1 July 2022 (UTC)[reply]
Multiple users expressed approval for an RfC, with only two dissenters with rather weak arguments. There is a legitimate reason to start an RfC, because the discussion above ended up with no consensus. To quote WP:BLUDGEONING, To falsely accuse someone of bludgeoning is considered incivil, and should be avoided. InfiniteNexus (talk) 00:53, 2 July 2022 (UTC)[reply]
@InfiniteNexus: at User talk:Citation bot#Why_do_we_need_an_RFC? I count five editors (including me) who agree that the RFC is a pointless timewaster.
So @David Eppstein 's complaint is true, and you are falsely accusing David of a false accusation.
On 13th June, @Sideswipe9th presented a big table of data[1] showing how @Citation bot makes hundreds of changes of template type per day. The three sites to which changes are opposed by @InfiniteNexus and the rest of the angry dozen from WP:WikiProject Film/Marvel Cinematic Universe task force account for less than 1% of all template-type-changes ... while nobody else joined in the earlier discussion to endorse the angry dozen Marvelites.
That is classic bludgeoning. BrownHairedGirl (talk) • (contribs) 16:37, 4 July 2022 (UTC)[reply]
@BrownHairedGirl: The only users who have explicitly rejected the idea of an RfC are you and David. On the contrary, Adamstom.97, Favre1fan93, Sideswipe9th, Rlink2, and I were all explicitly in favor of one. You all had a whole month's time to suggest an alternate way to end this dispute, but you didn't. InfiniteNexus (talk) 17:07, 4 July 2022 (UTC)[reply]
Oh dear. I could dig out all the diffs to show that you are misrepresenting the discussion, but to avoid overloading I will just present one: [2], where @Sideswipe9th writes I'm very heavily leaning towards what BrownHairedGirl has said; "that a small number of editors are making a mountain out of a molehill", as not only is the total number of reverts for any reason tiny, the total number of reverts as part of this dispute is even smaller
The reason why Sideswipe9th proceeded with the RFC is simply that @InfiniteNexus and the rest of the Angry Dozen were unswayed by the evidence that they are in a tiny minority, and continued their WP:BLUDGEONING. BrownHairedGirl (talk) • (contribs) 17:27, 4 July 2022 (UTC)[reply]
The reason why Sideswipe9th proceeded with the RFC Somewhat this, but also of all the options that I saw available to resolve the issue, this was the least worst. Ignoring it was just going to keep folks angry at each other. All the references in all of the MCU articles getting tagged with {{cbignore}} also impacts on the work of IABot and I believe WaybackMedic, both of which are vital to ensure archives are added to sources to prevent link-rot. And if behavioural issues spiralled, I could foresee one or more highly acrimonious ANI threads being opened. I'd rather this issue gets resolved by a strong community consensus, than any of the other potentially worse options. Sideswipe9th (talk) 17:36, 4 July 2022 (UTC)[reply]
@BrownHairedGirl: Okay, but the rest of my statement holds true. Adamstom said, I think we are good to go per the latest comments at Sideswipe9th's talk page. Favre said, I still feel an RfC will be helpful in gathering consensus on how editors approach these sources and which citation templates they use. Rlink2 said, RFC it is then. Indagate said, Think RfC is probably best way to get a consensus, current discussion is lengthy and doesn't seem to be reaching a conclusion. And as a bonus, Gonnym said, They don't need your approval to start the RfC and this sub-section of yours is very condescending. InfiniteNexus (talk) 17:43, 4 July 2022 (UTC)[reply]
@InfiniteNexus: v fine cherrypicking.
You selected the statements which support holding an RFC to put an end to your bludgeoining, and omitted several which do not support you. I am not going to get into posting every diff, but your blatant misrepresentation is an ugly followup to your assumptions of bad faith (e.g. [3] I feel like some editors are just trying to stall the RfC from happening) and your outrageous choice to attack me for complaining about a malicious accusation that the bot was engaging in vandalism BrownHairedGirl (talk) • (contribs) 18:19, 4 July 2022 (UTC)[reply]
@BrownHairedGirl: Sigh, here we go again. I read through that discussion several times, and I reaffirm my prior statement that only two (or three, if you count Sideswipe9th) editors have explicitly said no to an RfC. I selected the statements which support holding an RFC because you and David claimed there was no consensus for an RfC, which is not true. I was setting the record straight, not cherrypicking. And once again, I never attacked you for your comments about Darkwarriorblake. My full quote was, Sure, it was a fair request to ask Darkwarriorblake to retract their claim about vandalism. But did you really need to add a snarky statement at the end? Notice how I conceded it was a fair request in the first half of the sentence? Constructive criticsm != attack. InfiniteNexus (talk) 18:37, 4 July 2022 (UTC)[reply]
I selected the statements which support holding an RFC because you and David claimed there was no consensus for an RfC
Oh dear, oh dear. I should not need to explain that if you want to demonstrate that there is a WP:CONSENSUS, then counting only the views on one side is not the way to do that. But indeed, here we go again: sadly, such basics do need to be explained in this case.
And again, your quoted comment about Darkwarriorblake reaffirms my point: you made no criticism of Darkwarriorblake, but chose instead to criticise my response to a nasty attack by Darkwarriorblake in which they repeated their bogus allegation of vandalism.[4]
My response[5] was OK, so either you have't read WP:NOTVAND ... or you have read it and want to make false allegations anyway. So much so that you repeat those false allegations. Not good conduct ... but you chose to call me snarky for noting that a repeated false allegation of vandalism is not good conduct. Boggle. BrownHairedGirl (talk) • (contribs) 19:03, 4 July 2022 (UTC)[reply]
@BrownHairedGirl: I should not need to explain that if you want to demonstrate that there is a WP:CONSENSUS, then counting only the views on one side is not the way to do that. – I agree. But to reiterate what I said, 5 users expressed approval for an RfC (with a legitimate reason) while only 3 did the opposite (by falsely claiming only a "minority" of participants wanted an RfC). You tell me if that's consensus.
Your quoted comment about Darkwarriorblake reaffirms my point – your "point" was I attacked you, not I criticized you. There's a difference. Yes, I criticized you, but I never attacked you.
You chose to call me "snarky" for noting that a repeated false allegation of vandalism is "not good conduct"  – apologies if I wasn't being clear, but I was referring to your comment that said, If you make utterly bogus allegations, no wonder you get laughed at. That sounds snarky to me, do you not think so? InfiniteNexus (talk) 19:40, 4 July 2022 (UTC)[reply]
  1. Two straw men. I did not claim that there was a consensus in that discussion, or that only a minority in that discussion wanted a RFC. I simply contested your false statement that only two editors objected to the RFC. And it's not three objectors; it's 4.
    I pointed out that the only edits being objected to were the few relating a few websites, so that it was clear that the vast majority of editors do not object to these changes.
    You however, continue to focus only on your group of a dozen angry editors from WP:WikiProject Film/Marvel Cinematic Universe task force, falsely assuming that the wee group who got each other all angry on one project page are representative of the wider community ... despite the evidence that hundreds of similar edits are made by Citation bot every day, and only the 12 angry Marvelites object. I took that as a clear indication that the 12 Angry Marvelites are in a small minority, and nothing I have since leads me to reconsider that assessment.
  2. Attack, criticise; whatever. But you made no criticism of the editor who made a bogus allegation, and who repeated it when challenged. And here you are again, still making no criticism whatsoever of your ally who made the bogus allegation, and who repeated it again when challenged. That is classic tag-teaming conduct. You have now had at least five opportunities to clearly condemn the bogus allegation of vandalism, and your continued failure to do so does not paint a good picture of you.
    And no, I do not think that it is snarky to explain to someone who complains of being laughed at that repeating a grave and wholly bogus allegation of misconduct is likely to make people laugh at you. My response was harsh, but the allegation was very serious. BrownHairedGirl (talk) • (contribs) 20:50, 4 July 2022 (UTC)[reply]
If you have a problem with Darkwarriorblake's comments, their talk page and ANI are both right around the corner. I'm not sure how my opinion on this matter is relevant. Per Sideswipe, silence is the weakest form of consensus. I also don't find it appropriate for you to disregard the opinion of a group of "Marvelites" just because they're from the same WikiProject taskforce. I am so fed up with this. InfiniteNexus (talk) 22:41, 4 July 2022 (UTC)[reply]
I am fed up with this too: your continued creation of straw men is wearing.
  1. Your opinion on Darkwarriorblake is relevant because you chose to criticise me rather than him. You can remedy that if you want to, but it seems that you are still satisfied to act as the protector of a smear-monger.
  2. I do not disregard the opinion of a group of "Marvelites" just because they're from the same WikiProject taskforce.
    However, I do note that their complaint and their anger seems to be shared by nobody outside that group, which is a strong indicator that the 12 Angry Marvelites have created a prolonged drama out of nothing. BrownHairedGirl (talk) • (contribs) 23:29, 4 July 2022 (UTC)[reply]
  • Use {{cite magazine}}/{{cite news}} in the cases likely to be of main interest: online magazines are magazines, and online newspapers are newspapers, just like online academic journals are online academic journals. The argument that a print newspaper is a different entity from its online version relies on distinctions that don't matter as far as our policies are concerned: their stories are by the same people, under the same editorial supervision, held to the same standards. {{cite web}} can be the better option for content that happens to share a domain name, as mentioned above (a "Contact Us" page isn't a news story, for example, and Forbes "contributor" blogs aren't Forbes magazine). I share the concern raised above that this is not a well-formed RfC, despite (or because of?) the lengthy discussion that apparently led up to it. XOR'easter (talk) 16:29, 1 July 2022 (UTC)[reply]
To test this out, I just ran Citation bot on my sandbox. Apparently, it doesn't even change Forbes or Scientific American citations from {{Cite web}} to {{Cite magazine}} even if it's an article, but for this non-article from the Entertainment Weekly website, it did. InfiniteNexus (talk) 16:50, 1 July 2022 (UTC)[reply]
It looks like the bot can't always make the right decision going by URLs alone. Film at 11. XOR'easter (talk) 17:05, 1 July 2022 (UTC)[reply]
I know Citation bot isn't technically part of this RfC question, but this whole issue came about because of Citation bot's automated changes. InfiniteNexus (talk) 00:53, 2 July 2022 (UTC)[reply]
  • Use {{Cite web}} by default, as the bot cannot work out whether the web article is actually part of a physical or digital magazine or if it is non-magazine web content. It should be on the user who is adding the source to determine whether {{Cite magazine}} should be used instead. I have already elaborated on my opinions a lot as part of the previous discussion, I won't repeat all of that here unless someone asks me to. - adamstom97 (talk) 02:35, 2 July 2022 (UTC)[reply]
  • Do not use {{cite web}} for any sources that can be otherwise classified. CS1, like most citation systems, cites sources by type of work, not by type of media. An online periodical work is a magazine. An online news agency or newspaper is a work of journalism. Outside of the present case, an online book/encyclopedia/image is a book, an encyclopedia or an image. Something found in a corporate/institutional/government website is information in a corporate/institutional/government promotional publication. And so on. Citations are structured to follow these conventions. That is why they include authors of works, dates of publication of works, etc. Citing by medium has no analog in the real world, except in the rare cases that cannot be classified otherwise. 68.174.121.16 (talk) 16:00, 2 July 2022 (UTC)[reply]
  • Change templates and/or citation guidelines per my comment below. If templates are web-exclusive, those are at the top of the visual hierarchy and print-exclusive at the bottom. If print-vs-web is tagged, the proper usage of such tags must be explicitly clear to every editor. Either way, for a site that prides itself on verifiability, the fact that we've been completely ambiguous in templates so far about whether we cite print or web news is inexcusable. SamuelRiv (talk) 17:08, 2 July 2022 (UTC)[reply]
Structured citations cite works, mainly by title, author and date, because that is how works are easily found. Any other relevant information, including the publishing medium, is secondary. The important primary citation elements are substantially related to the work type as magazine, book, image, recording or whatever. This general citation practice should, and largely is, followed by CS1, by its template applications, and by helper scripts such as this bot. 68.174.121.16 (talk) 20:06, 2 July 2022 (UTC)[reply]
I thought this was clear from below: The medium is critical if the substance of the source differs, which it almost always does in modern print journalism. The only fidelity you'll get is from digitized archives. Note also (browse ProQuest, say) that major papers such as NYT have separate archives for digitized print -- including modern articles -- and their online versions. Most editors will cite online versions, so most of the templates and instructions should be aimed toward that audience, but then explicitly telling editors how to cite print when they use print. This shouldn't be a foreign concept -- it's already widely understood that you must cite the correct ISBN for books for correct pagination (and edition/revision), especially in the case of EBooks. SamuelRiv (talk) 21:14, 2 July 2022 (UTC)[reply]
No, this is not how citations work. Primarily, sources are not classified by medium. Citations have to follow classification in the real world if sources are to be discovered easily. Emphasizing the publishing medium (at best a secondary or tertiary index) may potentially make the source harder to find and impede the speedy verification of wikitext. It also does not matter in this discussion whether newspapers have separate digital or print or whatever versions, any more than they have separate weekday and Sunday editions. Citations do not cite editions/versions. They cite works, with all other information being ancillary to the work. Such as, |edition=online. There is no "special" citation information in the real world about publishing media that could elevate that element to a point where templates should be named for it, no matter what some Wikipedia editors think. 66.108.237.136 (talk) 13:44, 3 July 2022 (UTC)[reply]
You do understand that the content in the online version of a modern newspaper is different than what is in the print version, correct? SamuelRiv (talk) 16:29, 3 July 2022 (UTC)[reply]
Sure. Citations have been dealing with different editions of works (which may have differences in content) practically since their foundation. 4.30.91.142 (talk) 21:46, 3 July 2022 (UTC)[reply]
Yes, and there are multiple checks in CS1 on a citation of a book, say, for the precise edition: edition=, isbn=, and sometimes publisher= and year. (And of course, an EBook version also lacks page numbers.) For general websites the check is date and access-date, and to my surprise most editors seem to have gotten used to recording access-dates. In both cases I've found that probably a majority of citations are verifiable, and if not the citation usually is fatally flawed in multiple ways. For journal articles there is a known rampant problem here (in parts of academia too, frankly) of not specifying whether one is citing the preprint or the version in the doi, because the only real check there is page number (and sometimes date). For online vs print news, there are about the same two potential checks: page number and date. Based on the examples of books and websites, a change in presentation and norms is for the most part all that's necessary, for the issue raised by this RfC in particular. SamuelRiv (talk) 22:07, 3 July 2022 (UTC)[reply]
  • Cite news or cite magazine. cite web says it is used to create citations for web sources that are not characterized by another CS1 template. Because we have cite news and cite magazine, cite web should not be used here. weeklyd3 (message me | my contributions) 17:31, 2 July 2022 (UTC)[reply]
  • Cite news or magazine - The feedback request bot brought me here. Looked at the documentation for each of the templates and cite web's documentation says it is a generic catchall for web citations that do not otherwise fit into other CS1 templates. Cite news, for example, is a CS1 template and web content is specifically listed as valid content for cite news. Since a news article would fit in cite news, cite web is, per its own documentation, not the appropriate template to use. The same with cite magazine. I admit that I'm guilty of using cite web when other templates would be more appropriate, but I think the answer to the questions raised by the RfC is that cite web should only be used when cite news or cite magazine would not apply; an online version of news is still news, and an online version of a magazine is still a magazine. - Aoidh (talk) 03:09, 3 July 2022 (UTC)[reply]
  • Use {{cite magazine}} or {{cite news}}: online newspapers are still newspapers, and online magazines are still magazines.
    This RFC is a timewasting drama created as the result of a few angry editors who got worked up about Citation bot's edits to refs to a small set of publications. They wouldn't take no for an answer, and made repeated allegations of bad faith: one of them even accused Citation bot of vandalism, and then others tag-teamed to attack me for denouncing the smear on the bot-owner.
    The core issue here is simple: the publishing industry is in transition to new media, but the nature of the publications remains largely unchanged.
    Take for example, The Guardian newspaper in London. For 100 years it was available only on paper. Some time in the 20th century, it also became available on microfilm, mainly for use in libraries. By the 1990s, it was also available on some commercial databases. In the mid 1990s, it began to publish some of its stories on the guardian.co.uk website, and by the early/mid 2000s the website's scope extended beyond that of the print edition: not just more frequent updates, but additional content. In 2011, it adopted a "digital first" strategy: in May 2021, former editor Alan Rusbridger described this as part of a revolution which had begun in 1993.
    Now The Guardian is published in several formats: as a print paper (tho less focused on breaking news), on its website theguardian.com, and as an app for mobile devices.
    But for all these technical changes, it is still a newspaper. It still publishes daily, still publishes news, still employs lots of journalists, still carries opinion pieces and editorial and reader's letters.
    Sure, its focus has shifted in response to the immediacy of the internet, but it has been through similar shifts before: a century ago, radio began to take over the role of breaking news headlines, and sixty years ago television became the primary medium for delivering pictures. A century before that, the arrival of the railways had allowed newspapers to expand their distribution way beyond one city. And along the way, several major advances in printing technology radically reduced the time involved to assemble sub-edited articles into a printed paper, pushing copy deadlines much closer to the moment when the paper reached the streets.
    Those who try to maintain the notion of some clear distinction between a print newspaper or magazine and its electronic formats are out of touch with the reality of 2020s journalism, and seemingly unaware that digital is just the latest step in a long journey of change. Their stance that it's not a newspaper article unless it is read on a printed page is an absurdity which denies the multiple-media nature of 2020s newspapers and magazines.
    Citation bot does a great job of deploying the various templates which format citations to various types of publications, and it is a great shame that so much energy has been wasted by a few editors whose fundamental error is to conflate the type of publication (newspaper, book, magazine, journal etc) with the medium of distribution. --BrownHairedGirl (talk) • (contribs) 16:11, 4 July 2022 (UTC)[reply]
  • Use {{cite magazine}} or {{cite news}} per existing guidelines as mentioned above. A magazine, whether online or in print, is still a magazine; mutatis mutandis about newspapers. Imzadi 1979 → 17:31, 4 July 2022 (UTC)[reply]
  • Use {{cite web}}, It's notable that despite me having raised this issue many times that the CitationBot groupies have not notified me of this vote because they know I will not go the way they want which is a deliberate attempt to sway the vote. Websites are not newspapers or magazines, articles that appear online do not necessarily appear in print and vice versa and it's bizarre to me how strongly the citationbot groupies are fighting against what clearly so many people outside their sphere do not want. It's an attempt to fix a problem that does not exist, even more bizarrely trying to force upon the wider Wikipedia something they did not ask for. There does not seem to be much notification about this RFC to the wider Wikipedia but funnily enough those directly involved with the bot, with a specific agenda, are all fully aware of it. As print inevitably dies, we will still be citing website only companies as magazines and newspapers? How would that make sense. Citation Bot should be fixing existing references, not modifying them to something different entirely which seems entirely beyond its purview or purpose. The citationbot groupies aggressively defend their position as can be seen on the talk page history, they are unwilling in anyway to see any POV that is not their own regarding this issue and so it must be forced upon them that they are not to be mass changing reference types by pretending that digital, online sources, are somehow a print magazine or newspaper. EDIT: TO put this in perspective, Entertainment Weekly ceased publication 3 months ago, and it's been a website since the 1990s. It's been a website almost as long as it was a magazine and it will be a website longer than it was a magazine. Now that any article it publishes is digital only, are we still meant to be citing it to a magazine?Darkwarriorblake / SEXY ACTION TALK PAGE! 08:12, 8 July 2022 (UTC)[reply]
    You have a watchlist just like the rest of us. Additionally "articles that appear online do not necessarily appear in print and vice" is completely irrelevant, and doesn't change an online magazine into a non-magazine. Headbomb {t · c · p · b} 08:31, 8 July 2022 (UTC)[reply]
    I don't watch the page as I don't like to see the constant bullying going on. But you have ignored that I've just said Entertainment Weekly, as a magazine, no longer exists, and it was posted online pretty much from the outset. Darkwarriorblake / SEXY ACTION TALK PAGE! 16:08, 8 July 2022 (UTC)[reply]
    It exists as an online magazine. Which is what you constantly forget, hence the need to repeat the obvious. Headbomb {t · c · p · b} 20:02, 8 July 2022 (UTC)[reply]
    Please note that Darkwarriorblake's accusations of bullying are malicious and unfounded.
    The only bullying which has occurred was that Darkwarriorblake accused @Citation bot (and by implication it maintainers @AManWithNoPlan) of vandalism. When pointed to WP:NOTVAND, Darkwarriorblake repeated te false accusation.[6]
    It is disgraceful that the bully Darkwarriorblake is trying to abuse this RFC as a place to try to invert history. BrownHairedGirl (talk) • (contribs) 14:57, 11 July 2022 (UTC)[reply]
  • Use {{citation}} That's what I do and I've never understood why we have a proliferation of media-specific templates when many sources are multimedia. For example, I get physical copies of The Times newspaper and especially look at its obituaries for notable deaths. I usually work from a clipping but, when citing this, add a URL for the web copy for the convenience of readers who can get past the paywall. This copy will then end up in various newspaper archives. And sometimes such obituaries are bound into books. A generic template which caters for such multiplicity seems best because it avoids arguments and provides alternatives for readers. Andrew🐉(talk) 09:18, 8 July 2022 (UTC)[reply]
    • That's a nice idea, but it means that people have to be very careful about parameter choices, which is its own can of worm. Also, some combinations of the paramters that make sense are not allowed. AManWithNoPlan (talk) 16:55, 8 July 2022 (UTC)[reply]
      I use the {{citation}} template routinely and have no trouble with it. Other experienced editors such as Johnbod don't use a template at all and just cite with plaintext in a natural way. The more the process of citation is complicated, the more difficulty it causes and the more of a barrier to new editors it becomes. See the KISS principle. Andrew🐉(talk) 10:14, 9 July 2022 (UTC)[reply]
  • Use {{cite magazine}} or {{cite news}} per existing guidelines as mentioned above. AManWithNoPlan (talk) 16:55, 8 July 2022 (UTC)[reply]
  • Use {{cite magazine}} or {{cite news}} according how the source describes itself. The medium is as irrelevant as whether the journalist wrote the story on a PC or a Mac. --John Maynard Friedman (talk) 17:02, 8 July 2022 (UTC)[reply]
  • Use {{Cite web}} or {{Cite news}} without rehashing all of my points listed in the past discussion at the CitationBot talk page, no where in current documentation for {{Cite magazine}} does it discuss "online magazines". In my opinion, based on the documentation of Cite magazine, that template should be used for your "actual" magazine issue publication and anything within it, be it in a print or digital "online" version. If you have an article published by the publication on their website (more so today than ever) that appears in no way shape or form in the magazine issue, Cite web or Cite news seems like the appropriate template per documentation that should be used. - Favre1fan93 (talk) 17:03, 8 July 2022 (UTC)[reply]
  • Use {{Cite web}}: basic rule of referencing is to cite the actual thing you've read, content beteen web and magazine can be different. Indagate (talk) 17:15, 8 July 2022 (UTC)[reply]
    • Not sure how that is relevant. Changing from {{Cite web}} to {{Cite magazine}} does not magically do a web search and replace the URL with a link to a library to pick up a copy. AManWithNoPlan (talk) 17:49, 8 July 2022 (UTC)[reply]
  • Use {{cite magazine}} or {{cite news}}. As others have noted, it's about the source, not the medium - the medium isn't relevant, because if it was, it would have some silly implications. Imagine two editors are adding content to a Wikipedia article, and both cite the same news article. One uses the physical medium version of an article, the other editor the web edition. If we want to be really strict, that means that the two editors should use/create distinct references, one to web and one to news/magazine, despite the source content being identical? That seems pointless, and worse, misleading, since the source is the same (barring some sort of online-only correction). Additionally, what about e-books? Those uncontroversially use cite book (I hope!). SnowFire (talk) 13:40, 9 July 2022 (UTC)[reply]
    • Obligatory proviso: Note that in the cases where a newspaper/magazine owns or sets up a website sufficiently separate from their main product, then {{cite web}} is fine, since that's more a website that happens to be published by a company that is also a newspaper / magazine. (e.g. FiveThirtyEight is not the same as ABC News, despite being owned by them.) I don't know what citation bot was doing, but a change like that would be bad (e.g. using the "corporate parent" too seriously). SnowFire (talk) 13:40, 9 July 2022 (UTC)[reply]
      • Note that in the cases where a newspaper/magazine owns or sets up a website sufficiently separate from their main product, then {{cite web}} is fine, since that's more a website that happens to be published by a company that is also a newspaper / magazine. This is a great comment that I think summarizes my feelings. And I'd take it a step further in asking (which is similar to a comment response I added below), if the website shares the same name as the newspaper/magazine, but what's being published on the website far exceeds what is included in said newspaper/magazine, should that be considered sufficiently separate to use separate cite templates? - Favre1fan93 (talk) 16:01, 9 July 2022 (UTC)[reply]
  • Use {{Cite magazine}}/{{Cite news}}. My reasoning stands not from the method of publication, but from the editorial process that is shared between the content published in print and on the web. I conceptualize {{Cite web}} as something published online with less editorial oversight than something reliable at RSP. E.g. WP:FORBESCON (ignore that it's generally unreliable--this is an example) I would use {{Cite web}}, NOT {{Cite news}}. I prefer {{Cite magazine}} over {{Cite news}} for magazines because the publication is a magazine. SWinxy (talk) 00:38, 11 July 2022 (UTC)[reply]
  • Use whatever. Online newspapers and magazines are web sources; they are also newspapers/magazines and news media. These categories are not mutually exclusive. As such, the jurisdictions of {{cite web}} and {{cite magazine}}/{{cite news}} overlap, with both being equally appropriate for online newspapers/magazines. They give exactly the same output as each other when used for online news sources under almost all circumstances (the only exception - and it's a rare one - is if you need to take advantage of a parameter that's available in one template and not in the others, in which case you should use the citation template that allows the use of said parameter). Seriously, people, don't we have more-important things to become mortal enemies about? 🤦‍♀️ Whoop whoop pull up Bitching Betty ⚧️ Averted crashes 07:39, 11 July 2022 (UTC)[reply]
  • That's exactly the point I tried to make in previous discussions, but the operators of Citation bot insisted on changing {{Cite web}} to {{Cite magazine}} even though there is practically nothing wrong with using {{tl|Cite web}). InfiniteNexus (talk) 16:36, 11 July 2022 (UTC)[reply]
  • cite book, cite journal magazine, etc. The following examples show that cite book, cite journal magazine, etc. are designed to display all the information that a reader is likely to want to locate the source in whichever form is available, or which the reader prefers. This is not the case for cite web.
Cite magazine comparison
Wikitext {{cite magazine|access-date=October 18, 2013|date=2008|doi=10.1016/j.enpol.2007.05.021|first1=Myriam B. C.|first2=Guy R.|issue=6|journal=Energy Policy|last1=Aries|last2=Newsham|name-list-style=amp|pages=1858–1866|title=Effect of daylight saving time on lighting energy use: a literature review|url=http://archive.nrc-cnrc.gc.ca/obj/irc/doc/pubs/nrcc49212/nrcc49212.pdf|volume=36}}
Live Aries, Myriam B. C. & Newsham, Guy R. (2008). "Effect of daylight saving time on lighting energy use: a literature review" (PDF). Energy Policy. Vol. 36, no. 6. pp. 1858–1866. doi:10.1016/j.enpol.2007.05.021. Retrieved October 18, 2013.
Cite web comparison
Wikitext {{cite web|access-date=October 18, 2013|date=2008|doi=10.1016/j.enpol.2007.05.021|first1=Myriam B. C.|first2=Guy R.|issue=6|journal=Energy Policy|last1=Aries|last2=Newsham|name-list-style=amp|pages=1858–1866|title=Effect of daylight saving time on lighting energy use: a literature review|url=http://archive.nrc-cnrc.gc.ca/obj/irc/doc/pubs/nrcc49212/nrcc49212.pdf|volume=36}}
Live Aries, Myriam B. C. & Newsham, Guy R. (2008). "Effect of daylight saving time on lighting energy use: a literature review" (PDF). Energy Policy. pp. 1858–1866. doi:10.1016/j.enpol.2007.05.021. Retrieved October 18, 2013.
Notice cite web omits the volume information. Jc3s5h (talk) 13:09, 11 July 2022 (UTC)[reply]
  • This RfC is about {{Cite magazine}} and {{Cite news}}, not {{Cite journal}}. There is no opposition against using {{Cite journal}} to cite journals. InfiniteNexus (talk) 16:39, 11 July 2022 (UTC)[reply]
    • Revised 16:46 UTC to reflect RFC asks about cite magazine and cite news. — Preceding unsigned comment added by Jc3s5h (talk • contribs) 16:47, 11 July 2022 (UTC)[reply]
      • Also note that the specialised parameters such as volume, issue, pages, etc. do not apply to web pages anyway. The only difference between using {{Cite magazine}} and {{Cite news}} instead of {{Cite web}} is that we have to put the website's name in the magazine or work parameters. - adamstom97 (talk) 21:22, 11 July 2022 (UTC)[reply]
        • That's not entirely true. As was discussed at User talk:Citation bot and is in the summary below the question, each of the different templates also outputs different COinS metadata. The use of {{cite magazine}} over {{cite web}} ensures that the correct metadata is embedded for that source. Information on how the metadata differs was detailed in this reply by Trappist the monk. Functionally there is a significant difference between all of the CS1 cite templates. Sideswipe9th (talk) 22:02, 11 July 2022 (UTC)[reply]
          • That would only be true if we agreed that a web article associated to a magazine should have the same metadata as an article that actually appears in a magazine, but that has not yet been determined since this RfC is still ongoing. - adamstom97 (talk) 22:26, 11 July 2022 (UTC)[reply]
        I disagree that the volume, issue, or pages parameters do not apply to web pages. It depends on the arrangement of the web page. It might be a landing page where one can select the issue one needs. Or it might be a PDF with a large number of pages, and the same pagination as the print version. I consider it easier to just use cite news, cite magazine, etc. whenever possible, rather than puzzle over all the subtle differences between these templates and cite web. Jc3s5h (talk) 23:00, 11 July 2022 (UTC)[reply]
  • Use {{cite magazine}} or {{cite news}} (Summoned by bot). Also use them in cases where print news and magazines publish online editions (or audible editions, or braille, or whatever) that may have different content. This is no different than the NY Times publishing several city editions, a couple of national editions, and an international edition. Online editions are merely an extension of this, and there is no need to treat the different content as "not a newspaper" or magazine, merely because it is published in a different medium or because the content may not be identical with a print edition. Mathglot (talk) 05:43, 13 July 2022 (UTC)[reply]

Discussion[edit]

Note: So far I've only added the tech topic. I'm not sure if any of the other topics are appropriate, but if they are feel free to add em or let me know and I'll add them. We'll also want to notify any relevant WikiProjects if anyone has a list of those handy, and the village pump about this discussion, as it is relevant to a great many pages across enwiki. Thanks. Sideswipe9th (talk) 23:55, 30 June 2022 (UTC)[reply]

Notified: Help talk:Citation Style 1, WikiProject Citation cleanup, WikiProject Academic Journals, WikiProject Magazines, WikiProject Newspapers Sideswipe9th (talk) 00:10, 1 July 2022 (UTC), updated Sideswipe9th (talk) 16:24, 1 July 2022 (UTC)[reply]
Note: Updated the notices after the move, and I've struck the one for this page because that's now where we're holding the RfC. Sideswipe9th (talk) 16:12, 2 July 2022 (UTC)[reply]
Comment: Before I do so, do editors believe it would be considered WP:CANVASSING to notify Wikipedia:WikiProject Film/Marvel Cinematic Universe task force of this RfC, as that is where this issue first arose? InfiniteNexus (talk) 00:49, 1 July 2022 (UTC)[reply]
Yes, because this is not specific to that WikiProject. WP:JOURNALS and WP:MAGAZINES should be notified though, since these are the projects associated with journals, magazines, etc... Headbomb {t · c · p · b} 03:50, 1 July 2022 (UTC)[reply]
I've now notified WikiProject Academic Journals, Magazines, and Newspapers. Sideswipe9th (talk) 16:24, 1 July 2022 (UTC)[reply]
What about Wikipedia:Bots/Noticeboard? InfiniteNexus (talk) 00:53, 2 July 2022 (UTC)[reply]
@InfiniteNexus: I've been thinking about this one for the past few days. While the discussion did spin out from Citation Bot's talk page, due to issues that were originally raised there, the RfC question itself is somewhat broader because it's asking specifically about the citation templates and not the bot's edits. Because of this and the header at BOTN, I'm not entirely sure this is within the scope of that noticeboard. I'd like to hear from others though on this.
Conversely, what do people think about notifying one of the Village Pumps? I'm not sure which of them to notify though, otherwise I likely would have done it already. Sideswipe9th (talk) 15:37, 8 July 2022 (UTC)[reply]
@Darkwarriorblake: if you feel as though this RfC has not been adequately publicised, please feel free to suggest additional pages where we can provide that notification. There's still at least 23 days until the RfC tag expires, so that is plenty of time to provide further notifications. Sideswipe9th (talk) 15:33, 8 July 2022 (UTC)[reply]
Featured Articles should be asked, since the changes that this bot makes that introduce inconsistencies between citations have been cited as an issue in several FAs I've put forward. But requesting comments from the groups whose templates would BENEFIT from enforcing the improper use of cite newspaper and magazine to cite websites is not a fair RFC. Darkwarriorblake / SEXY ACTION TALK PAGE! 16:12, 8 July 2022 (UTC)[reply]
WP:FA has many pages, though I can't immediately see a noticeboard. Is there a centralised FA discussion noticeboard that I'm missing, or do you have a specific talk page where such a notification would be best placed? I'll make no more comment than I have above in the survey about whether or not one of the options is an improper use of the various citation templates, because ultimately that is what is under discussion here. Sideswipe9th (talk) 16:19, 8 July 2022 (UTC)[reply]
I probably should have done this earlier, but to address Darkwarriorblake's concerns I will go ahead and ping all those who participated in the prior discussion but have yet to vote here (which should not be considered canvassing per WP:APPNOTE, which allows notifying Editors who have participated in previous discussions on the same topic (or closely related topics)): @Abductive, AManWithNoPlan, Eurohunter, Favre1fan93, Gonnym, Indagate, John Maynard Friedman, Rlink2, Trailblazer101, Trappist the monk, and ZooBlazer. InfiniteNexus (talk) 16:50, 8 July 2022 (UTC)[reply]

Physical print media will always require a different citation than the same item posted online (unless perhaps if it's an image scan). Anyone who has ever looked up a recent news article online can see the "Updated on xx-xx-xxxx" date and know that there will be some, however slight, difference from whatever went out in print. That said, WP citations from print media will likely be extremely rare relative to online-access media (with the diminishing exception of long-form books). So I ask what is the point of having "news", "journal", and "magazine" citation templates presented so prominently when it would seem for all online publication the proper template would "cite web" (or some variant for journals – remember print can be different there too). Really this requires rethinking how the template options are presented to editors: almost always the sources will be either print books or web-accessible. After those are introduced, then you can show the exceptional cases, such as A/V media and from-print citations. SamuelRiv (talk) 03:10, 1 July 2022 (UTC)[reply]

I suppose this could be accomplished with just a type=Print source or similar specification tag, but the rules on how to cite, use citation templates, and for these types of tag have to be made crystal clear. Verifiability is not an MOS issue. SamuelRiv (talk) 19:17, 1 July 2022 (UTC)[reply]
@SamuelRiv writes Anyone who has ever looked up a recent news article online can see the "Updated on xx-xx-xxxx" date and know that there will be some, however slight, difference from whatever went out in print.
That is partially true. Yes, online stories can be modified indefinitely; but many newspapers go through several editions each day of the printed paper. Sometimes the front page and several other pages of the final print run can be almost entirely different from that day's first edition.
Some newspapers, such as the UK's Daily Mail and Daily Express run radically different version of the same story in different regions, with the English edition denouncing as a outrage something which the Scottish edition cheers in the same front page slot.
So the variability applies to both media, just to a different degree.
The way to deal with this is simple for online sources: to include with each ref an archived copy of the source as used for the article. I have been doing this for years, and it should be standard practice; the use of an unarchived (and hence modifiable) sources should be strongly deprecated. BrownHairedGirl (talk) • (contribs) 16:23, 4 July 2022 (UTC)[reply]
Right, obviously you cite the edition -- if something other than the national/syndicated edition -- when you cite print news. It is a known historical problem that most newspapers only microfilm one of their daily editions, which excludes some articles, though libraries sometimes do have different editions archived. I'd say it's one of those cases where the internet took a problem that was more of an idiosyncrasy in the past, limited just to big papers and simply resolved with a library visit, and made it far more pervasive. Now even the crummiest local or school papers update their stories many days after publication, so edition control is no longer just an issue for urban giants. Of course thanks to iarchive it's often possible to recover several intermediate versions if necessary. I'm not implying the old days were better -- I mean they were for journalism, but not at all for this reason. But this is getting quite off topic.
The point is that if someone, for whatever reason (e.g. a lot of freelance work is not archived online per Tasini), is citing a print source for WP to the exclusion of an electronic version, the procedure and template has to be clear for that purpose. The misunderstanding between the two sides that is driving this RfC is in part that one side is saying essentially, "What are cite news and cite magazine for if not for print sources," while the other is saying, "How does that make sense with how the templates are used in practice?" Given that the number of citations from print sources (aside from books) is a tiny minority, I think the variety of templates offered to the users should reflect that. But the instructions for use should be presented clearly -- "If you are citing print, this is the method" -- and the templates themselves should in turn be less ambiguous in their documentation.
And if your argument is that we should prefer online-accessible sources, then I completely agree. Of course if an editor is replacing original citation information they have to check that the citation still verifies what is attributed to it (which is just good practice for citation maintenance anyway because the prevalence of citation decay and plain misattribution is pretty unsettling). And of course the reason this RfC is here as far as I understand are enthusiasts who are using print sources and don't really have an adequate alternative. And then you have all the print books that are used, the plethora of English-language print from just this century that still hasn't been digitized. And if you want any good historical material for anywhere else in the world, it's going to be a long long time before anyone has the inclination to digitize that stuff. It's just something that has to be addressed. SamuelRiv (talk) 20:13, 4 July 2022 (UTC)[reply]
@SamuelRiv: no, I am not arguing that we should prefer online-accessible sources. Many fine scholarly sources are not online, and in my view Wikipedia is far too tolerant of low-quality online sources.
I am simply noting that while the move online has (as we seem to agree) massively increased the modification of articles, most of the problems can be resolved by the simple good practice of archiving the page as cited. Citation decay is rampant, but we already have all the tools in place to prevent decay of most online refs. Sadly, many editors think it is acceptable to add a bare URL as a ref, and there is no systematic effort to discourage that. Few editors routinely archive the citations they add, and I have several times faced angry responses from editors who think that the archive data is clutter.
The variability of printed newspapers is less easy to track. It's not just a matter of national/syndicated versions; each edition may change in the course of a print run. As a young policy wonk in the political system, I often used to note how the first edition copy I purchased on my way home at midnight was significantly different from that which my housemates purchased in the morning. And most newspapers are far from clear in identifying what edition the reader holds in their hands.
After a year of working full time on refs, my conclusion is that WP:Verifiability does not in practice carry anything remotely like the weight that it should, or that it purports to carry. It's not just that we tolerate widespread use of newspapers and magazines rather than insisting on scholarly sources; we are very lax in how sources are cited.
In my first few weeks at a university humanities course, our twice-weekly tutorial papers were mercilessly shredded for failures in citation. They were returned in front of the whole (smallish) class, with fierce criticism of any failure to attribute or any lack of completeness in the citation. It was brutal, but it worked. It seems to me that very few en.wp editors have ever received such invaluable training in the centrality of citations to scholarly writing.
Here on Wikipedia, we gently treat wholly a unsourced addition as a minor lapse which might merit a {{citation needed}} tag, while bare URLs and other vague waves at sources are rarely reproached, and the widespread practice of citing a long book or PDF without a page number is almost never rebuked. Instead of telling newbies firmly that full and accurate citations to high-quality sources are the absolute basic standard required of any contribution, WP:BITE is thrown at those who try to uphold good practice. Heck, this whole RFC arose out of some editors focused on refs to three magazines: Entertainment Weekly, Rolling Stone, and Billboard. They are better than blogs, but would not be acceptable as sources of fact in academic work. Heck, we even have hundreds of of thousands of articles with references to user-generated sites such as IMDB and Ancestry.com, and to social media.
So long as we tolerate such low standards, I fear that the energy involved in precise attention to the nuances is misplaced. BrownHairedGirl (talk) • (contribs) 21:40, 4 July 2022 (UTC)[reply]
I applaud your sentiment; people should not get through high school without being able to cite properly. Alas, adding a archive reference to every link is not currently possible. I have tried to persuade archive.org to archive pages off the Wikipedia feed (and when that did not work, I tried to get WMF to buy archive.org). I do feel that we should be able to speedily delete unsourced articles, but WP:PRESERVE is the policy that says that we must gently treat a wholly unsourced addition as a minor lapse which might merit a {{citation needed}} tag. If you want to start an RfC to repeal or rewrite it, you have my support. Hawkeye7 (discuss) 00:06, 6 July 2022 (UTC)[reply]
Thanks, @Hawkeye7, but it seems to me that the culture of patronising newbies by tolerating unsourced or poorly-cited additions is very deeply ingrained. So I don't see much point in starting an RFC which would just descend into an acrimonious bout of shouting from those who don't want to be held to anything remotely near basic scholarly standards. BrownHairedGirl (talk) • (contribs) 16:51, 6 July 2022 (UTC)[reply]

David Eppstein I wanted to address and query one point you raised above with respect to the RfC being malformed, specifically the question written in a way that presupposes that group's intended answer. As is clear from my contributions in the past discussion, I drafted a not insubstantial amount of the RfC and how it was presented. I did this because, per my comments in #Why do we need an RFC? I saw no other way to address an intractable dispute between editors that was spilling over into the article space. I was open to, and acted upon feedback from many contributors both in favour of the transformations of the bot and who are opposed to it. As there was a period of 30 days between the posting of the second draft, and the opening of the RfC, why did you not voice any concerns about the question being leading or presupposed towards an intended answer? I would happily have tried to address those concerns during the drafting period, as while my opinion is firmly in that the bot's edits are fine and correct, I wanted to be as fair as I possibly could to both sides of the argument. Sideswipe9th (talk) 19:19, 1 July 2022 (UTC)[reply]

@Sideswipe9th: - For the record the feedback request bot brought me here so that question was my first interaction with what's going on in the discussion. I think it's very neutrally worded and after getting a better perspective on what the various talking point are, is a good summation. - Aoidh (talk) 03:11, 3 July 2022 (UTC)[reply]
@Aoidh: thank you for the kind words. While I obviously have my own views on the situation, I wanted to be as fair as possible to both sides of this disagreement. It's also why I'm trying to be proactive in addressing issues as they arise, as ultimately I want this to be the strongest possible consensus no-matter the outcome, because I want to see this issue resolved without further acrimony where possible. Sideswipe9th (talk) 16:28, 8 July 2022 (UTC)[reply]

Comment: I've seen a few editors opine on this above, and wanted to address this directly. The issue of whether or not the website of a publication, eg Entertainment Weekly or The Guardian, is the same as or different to the print edition of the publication when it comes to citations is fundamentally the locus of this dispute. This is an important question to consider across enwiki as print media continues to decline, and more traditionally print only sources like newspapers and magazines become website only. It is clear from the discussion above that there are editors who believe that using {{cite magazine}} for Entertainment Weekly, or {{cite news}} for article content on their websites is appropriate, and it is also clear that there are editors who believe that only {{cite web}} is appropriate. This RfC is best thought of, in my opinion, as a measuring stick to gauge what the community consensus is on this issue, and it is not an appropriate discussion to be remarking on behavioural concerns. Sideswipe9th (talk) 16:40, 8 July 2022 (UTC)[reply]

I agree. That in my eyes is what I hoped to gain clarity on. Sure, an "online magazine" is a magazine, but where does the classification distinction come up, when you have more and more content released from these publications that aren't actually featured in their "magazines"? - Favre1fan93 (talk) 15:57, 9 July 2022 (UTC)[reply]
Especially in the cases where the publication has an "online magazine" that is separate from their website and the content between the two is different, which is basically where this discussion started. Many of the editors who has responded to the RfC have not addressed this part of the issue, which was a concern of mine when drafting the RfC question. - adamstom97 (talk) 02:01, 10 July 2022 (UTC)[reply]
That seems almost a philosophical question. Do you consider the website of a publication to be separate from the publication? Or is the website of a publication another distribution mechanism for the publication's readers? Does is strictly matter from our perspective of citing a source if one format of a publication has content exclusive to one of it's delivery mechanisms? Sideswipe9th (talk) 22:05, 11 July 2022 (UTC)[reply]
Also I think it's possible to infer from some of the answers. Take SWinxy's contribution, it's pretty clear that if you were citing an article on the website of a magazine or newspaper where the website shares the same editorial standards, you would use {{cite magazine}} or {{cite news}} as appropriate.
I could also reverse the question. Using the EW example above, why do editors like Favre1fan93 and yourself see that as not being published by the magazine? Why is the website of the publication different from the publication itself? Sideswipe9th (talk) 22:13, 11 July 2022 (UTC)[reply]
Because if you are to define what a magazine is (a publication of various articles "bound" in issues or volumes), if a web article published by someone like EW doesn't appear in that "bounded" magazine (being it on physical print paper or a digital/scanned version), how can we call that a "magazine"? - Favre1fan93 (talk) 17:26, 12 July 2022 (UTC)[reply]
I don't think that's the sole universally accepted of a magazine, and it pretty much excludes online magazines that are delivered via website instead of PDF or some other ebook container format. And while all print magazines will likely have issues (typically numbered or date delineated), not all will have volumes. Are print magazines without volumes less of a magazine than one that does? Sideswipe9th (talk) 18:05, 12 July 2022 (UTC)[reply]
Perhaps my quick definition wasn't the best, but there is, and I think should, be a distinction between material presented within an issue publication (choose your "container" method of delivery), and then a web article that simply is not part of such publication. - Favre1fan93 (talk) 18:39, 12 July 2022 (UTC)[reply]
a web article that simply is not part of such publication I can't agree with that. Sticking with the EW example, content on ew.com is subject to the same editorial standards as their former print edition, and is published by the same organisation. This is also true for content on Variety, Billboard, and TIME. As such I do not see any distinction between an article that is published only on that publication's website, and an article that is published only on that publication's print or ebook container. It is fundamentally the same publication, written by the same authors, edited by the same editors, and held to the same standards. Sideswipe9th (talk) 18:48, 12 July 2022 (UTC)[reply]
But there is a difference to them, they are deciding what content goes in their actual magazine (physically published or digitally published) and what content will just go on their website. We aren't saying there is a difference in quality, just that there is a difference, and using {{cite magazine}} with the |magazine= parameter to source information that they didn't put in their magazine just seems incorrect. As pointed out above, {{cite magazine}} and the other more specific cite templates include parameters that are specific to their respective media, they are designed for sourcing information from that media. If I have never read EW magazine and I am just getting information from ew.com that was never included in any (physical or digital) magazine publication and does not need any of the special magazine parameters that {{cite magazine}} was designed to provide, then why should I use {{cite magazine}}? The answer seems to be that the metadata in {{cite magazine}} is required for such a citation, but that metadata is incorrectly saying that the information comes from a magazine. - adamstom97 (talk) 00:47, 13 July 2022 (UTC)[reply]

s2cid limit needs to be updated[edit]

I recently added a citation with the correct s2cid of 250118314, but received a "check value" error; the help directed me to report this here. Clicking the link generated in the citation confirms it is correct. The article I had edited was Linear Elamite. – Scyrme (talk) 16:02, 2 July 2022 (UTC)[reply]

Seems it's been updated. Thanks to whoever did this! – Scyrme (talk) 21:55, 3 July 2022 (UTC)[reply]

Is catalog lookup link mandatory for id template compatibility[edit]

Title? I'm updating/creating templates for EUR-Lex codes with hopes for compatibility with CS1's id parameter, so I copied the same pattern used in {{SELIBR}} and others, and they all use {{Catalog lookup link}}, but is it required? I ask because {{ECLI}} does its own thing and, as I only started learning template code today, it will take time for me to wrap it in Cll, so I'm just wondering whether I even need to (I know practically I don't because CS1 is not ideal for most law at the moment anyway, but I raised that issue elsewhere).

As an aside, lookup templates based on Cll, somewhat tailored for CS1, (like SELIBR and those with native support like {{ISBN}}) still work in CS1 with multiple identifier arguments, which doesn't really make sense for citation purposes. {{Citation|title=Apu|id={{SELIBR|1|2|3|4}}}} Apu, SELIBR 1, 2, 3, 4 I doubt it's worth coding an exception over that unless it's easy. SamuelRiv (talk) 01:24, 4 July 2022 (UTC)[reply]

Afaik, catalogs will add multiple identifiers only when the work exists in multiple editions or formats in their repository (sometimes with a "master" identifier if the catalog allows master records). In this case, only the identifier that corresponds to the edition/format consulted by the citing editor is required and appropriate. As for the use of Cll, this is not the purview of CS1. You may want to raise the issue in a more template/module-specific forum, where issues of code reuse, compatibility, and development can be discussed more fully. 50.75.226.250 (talk) 15:07, 5 July 2022 (UTC)[reply]
I have several other questions just about what's possible with a CS1 wrapper -- should I got to WikiProject Template then? SamuelRiv (talk) 22:06, 5 July 2022 (UTC)[reply]
I would start at the talk pages of the templates/modules you're working with, including Cll, and expand from there if there's no traction. I haven't looked into CS1 wrappers/metatemplates in a few years, but I remember the category was pretty messy, and iirc included templates that were based on CS1 style elements, but not CS1 templates. Some of the editors regularly posting here did some cleanup in the meantime I believe. 64.18.11.64 (talk) 11:04, 6 July 2022 (UTC)[reply]

Inter-language author-link[edit]

I have some cases where the author of a source has a Wikipedia page, but not on the English-language Wikipedia. Is iy possible to have an inter-language author-link? Hawkeye7 (discuss) 00:08, 6 July 2022 (UTC)[reply]

Yes.
|author=[[:<lang tag>:<author name>|<author name>]]
or
|author-link=:<lang tag>:<author name>
—Trappist the monk (talk) 00:34, 6 July 2022 (UTC)[reply]
(edit conflict) @Hawkeye7:, yes:
Fabian foresaw the consequences that the war guilt question could have for the rise of extremism, which had been awakened in Germany as early as 1920 with the creation of the Nazi Party (NSDAP), which would make the Treaty of Versailles and the question of responsibility its trademark issue: "But the war guilt question can also lead to the poisoning of relations between peoples, it can become a weapon forged for the hand of international nationalism."[1]
Mathglot (talk) 00:38, 6 July 2022 (UTC)[reply]

References

  1. ^ Fabian, Walter (1985) [1926]. Die Kriegsschuldfrage. Grunsätzliches und Tatsächliches zu ihrer Lösung [The War Guilt Question. Basic and Factual Information on its Solution]. Kultur- und Zeitfragen, 19 (in German) (1st ed.). Bremen: Ernst Oldenburg. ISBN 3-924444-08-0. OCLC 1075866888.
Thanks! That's awesome! Hawkeye7 (discuss) 05:26, 6 July 2022 (UTC)[reply]

What is the correct value for the website parameter?[edit]

I've been searching through the archives, as well as the documentation at {{cite web}}. What is the correct value for |website=? For example, if I had the following citation {{cite web |url=https://news.xbox.com/en-us/ ... is the domain name |website=news.xbox.com correct, or should it be |website=Xbox Wire?

The {{cite web}} documentation for this is kinda opaque. It says that website is an alias for work, and that work should be the name of the source. But it doesn't give any examples. Template:Cite web#Examples says that for my example you'd use |website=Xbox Wire, as does Help:Citation Style 1#Work and publisher. However in the archives for this talk page, I found the following conflicting discussions; Archive 82:Cite web Website parameter being misused?, Archive 81:website or publisher parameter, Archive 77:Bad value in website= field

If the value should be |website=Xbox Wire, could we get that more clearly spelled out at Template:Cite web#Website? I know of at least one lame edit war in the last day that revolved entirely around this issue, and I know I come across {{cite web}} citations frequently where the domain name |website=news.xbox.com has been used.

Note: URL was picked at random, and obviously I wouldn't cite the index page of that website. Sideswipe9th (talk) 01:59, 6 July 2022 (UTC)[reply]

The current instructions at Template:Cite web now say website: Title of website; may be wikilinked. Displays in italics. Aliases: work". That's pretty clear, but the underlined text could be added so it says "website: Title of website (not the domain name, unless that is also the name of the website); may be wikilinked. Displays in italics. Aliases: work". It's always seemed clear to me, but I run into this error frequently. SchreiberBike | ⌨  02:33, 6 July 2022 (UTC)[reply]
Yeah, that's the way I've always used it, or tried to use it myself. But I wanted a sanity check, especially after seeing an edit war about it yesterday. After finding conflicting information in the archives, I thought it best to ask and possibly see if we can improve the documentation at {{cite web}} to make it clearer. Sideswipe9th (talk) 02:39, 6 July 2022 (UTC)[reply]
Same. So, |website=New York Times, not: |website=nytimes.com. Mathglot (talk) 02:44, 6 July 2022 (UTC)[reply]
Well, except that we shouldn't be using cite web for the NYT; that goes under cite news, with newspaper= rather than website=. —David Eppstein (talk) 05:00, 6 July 2022 (UTC)[reply]
Agree with User:David Eppstein here; my example was not the best. But yes, in this case it should be |newspaper=New York Times. If it's a web site, then |website=PayPal. Mathglot (talk) 05:53, 13 July 2022 (UTC)[reply]
The underlined text doesn't have consensus I'd say; our preference might be for the English text, but we do (or at least should) still accept the domain name if the plain English doesn't feel right (for example, I've used the domain for citations to faculty spaces hosted on a university website, when the name of the faculty's space was not otherwise clear). Izno (talk) 05:56, 6 July 2022 (UTC)[reply]
Previously, the doc stated that the website name would be the home page's title tag. Or top heading if the title is non-sensical or generic (such as "Home", "Index" etc.). There may also be (increasingly rare) situations where the domain suffix is included in the trade name ("Company.com Inc.") and would be also included in the website name. 64.18.11.64 (talk) 10:52, 6 July 2022 (UTC)[reply]
Based on the above, it seems that there's agreement that |website= should not be the domain name when the website has a clear name. I frequently see people using domain names, e.g. |website=rottentomatoes.com instead of |website=Rotten Tomatoes, and I think it should be discouraged. I suggested some language above and I'll try again. How about "website: Title of website (not the domain name when the website has a clear name); may be wikilinked. Displays in italics. Aliases: work" ? SchreiberBike | ⌨  14:50, 7 July 2022 (UTC)[reply]
Yeah I think something like that would bring some clarity to the parameter part of the documentation. I wouldn't be surprised if some of the confusion and bad practice is because the text at Template:Cite web#Website doesn't actually state how to use it in practice, just that it's a alias for |work=. Expecting editors to look at the Examples or Help:Citation Style 1 where it is clearer what the value should be, is not a good information flow to inform editorial practice. Sideswipe9th (talk) 14:56, 7 July 2022 (UTC)[reply]
How about phrasing it to suggest what to do rather than saying what not to do, e.g. "When the website has a clear name, use that rather than the domain name"? Kanguole 15:01, 7 July 2022 (UTC)[reply]
@Sideswipe9th and Kanguole: Yep, much better. How about "website: Title of website (when the website has a clear name, use that rather than the domain name); may be wikilinked. Displays in italics. Aliases: work" ? Any suggestions for how to modify Template:Cite web#Website? SchreiberBike | ⌨  15:11, 7 July 2022 (UTC)[reply]
As this has sat here for a while and had no objections, I've gone ahead and edited Template:Citation Style documentation/web, which seems to have inserted the text above into various Template:Cite ... documentation pages. It's not perfect, but it's a step forward. Thank you, SchreiberBike | ⌨  02:41, 14 July 2022 (UTC)[reply]

Issue regarding the transcript-url parameter on Cite podcast[edit]

According to the documentation for {{Cite podcast}}, while the parameter |transcripturl= has been deprecated, the parameter |transcript-url= should work. However, when using it, the template returns an unknown parameter error:

  • {{Cite podcast |url=https://soundcloud.com/user-735940457-95015381/did-economists-move-the-democrats-to-the-right |title=Did economists move democrats to the right? |website=The Science of Politics |publisher=[[Niskanen Center]] |last=Grossman |first=Matt |date=20 April 2022 |time=5:18–7:19 |access-date=6 July 2022 |transcript-url=https://www.niskanencenter.org/did-economists-move-democrats-to-the-right/ |transcript=Transcript }}
  • Grossman, Matt (20 April 2022). "Did economists move democrats to the right?". The Science of Politics (Podcast). Niskanen Center. Event occurs at 5:18–7:19. Retrieved 6 July 2022. {{cite podcast}}: Unknown parameter |transcript-url= ignored (help); Unknown parameter |transcript= ignored (help)

Compare the equivalent {{Cite AV media}} where the parameter does work:

  • {{Cite AV media |url=https://soundcloud.com/user-735940457-95015381/did-economists-move-the-democrats-to-the-right |title=Did economists move democrats to the right? |website=The Science of Politics |publisher=[[Niskanen Center]] |last=Grossman |first=Matt |date=20 April 2022 |time=5:18–7:19 |access-date=6 July 2022 |transcript-url=https://www.niskanencenter.org/did-economists-move-democrats-to-the-right/ |transcript=Transcript }}
  • Grossman, Matt (20 April 2022). Did economists move democrats to the right?. The Science of Politics. Niskanen Center. Event occurs at 5:18–7:19. Transcript. Retrieved 6 July 2022.

I've tried looking at the relevant module to see what change might've caused this, but it's beyond me. Does anyone know what the issue might be? Sincerely, InsaneHacker (💬) 11:24, 7 July 2022 (UTC)[reply]

{{cite podcast}} has never supported |transcript= or |transcript-url=.
Cite podcast comparison
Wikitext {{cite podcast|access-date=6 July 2022|date=20 April 2022|first=Matt|last=Grossman|publisher=[[Niskanen Center]]|time=5:18–7:19|title=Did economists move democrats to the right?|transcript-url=https://www.niskanencenter.org/did-economists-move-democrats-to-the-right/|transcript=Transcript|url=https://soundcloud.com/user-735940457-95015381/did-economists-move-the-democrats-to-the-right|website=The Science of Politics}}
Old Grossman, Matt (20 April 2022). "Did economists move democrats to the right?". The Science of Politics (Podcast). Niskanen Center. Event occurs at 5:18–7:19. https://soundcloud.com/user-735940457-95015381/did-economists-move-the-democrats-to-the-right. 
Live Grossman, Matt (20 April 2022). "Did economists move democrats to the right?". The Science of Politics (Podcast). Niskanen Center. Event occurs at 5:18–7:19. Retrieved 6 July 2022. {{cite podcast}}: Unknown parameter |transcript-url= ignored (help); Unknown parameter |transcript= ignored (help)
Sandbox Grossman, Matt (20 April 2022). "Did economists move democrats to the right?". The Science of Politics (Podcast). Niskanen Center. Event occurs at 5:18–7:19. Retrieved 6 July 2022.
For the above comparison, I have tweaked the module sandbox so that |transcript= and |transcript-url= are recognized and so not discarded. This shows that Module:Citation/CS1 does not support these parameters for {{cite podcast}} and never has. I don't know why {{cite podcast/old}} repeats |url= as a bare url (and I'm not going to spend any time trying to figure that out).
For the community: should the cs1|2 module suite be changed to support |transcript=, |transcript-format=, and |transcript-url=?
—Trappist the monk (talk) 12:12, 7 July 2022 (UTC)[reply]
{{cite podcast}} has never supported |transcript= or |transcript-url=. Well, that explains it. I hope I didn't misunderstand the documentation, which seems to list it as a valid parameter?
[S]hould the cs1|2 module suite be changed to support |transcript=, |transcript-format=, and |transcript-url=?. Are the equivalent parameters in {{Cite AV media}} not from the CS1 module?
I personally think a transcript link parameter is beneficial for AV media, since it increases accessibility and eases verification checks by other users. I was looking at the archives of this talk page while searching for a solution to my problem, and it seems this has been discussed before without any outcome. Sincerely, InsaneHacker (💬) 12:25, 7 July 2022 (UTC)[reply]
The {{cite podcast}} template documentation says nothing about |transcript=. The deprecated and recently removed parameter tables are generic and are included in most if not all cs1|2 template doc pages.
Of the 27 cs1|2 templates, |transcript=, |transcript-format=, and |transcript-url= are supported only by {{cite AV media}} and {{cite episode}}.
Can you link to the previous discussions? Such links can be helpful.
—Trappist the monk (talk) 14:12, 7 July 2022 (UTC)[reply]
I was primarily thinking of this discussion where an anon user complained about the supposed disappearance of the parameter in a variety of templates, although as I understand your comment, it wasn't present in some of these to begin with at all. The last few comments in that discussion were about whether or not such a parameter was needed. Others of interest are this one which appears to be right before the introduction of the parameter to {{Cite AV media}} and this one where including the parameter in other templates, including {{Cite podcast}} was aired, but the discussion seemingly didn't go anywhere. Sincerely, InsaneHacker (💬) 19:27, 7 July 2022 (UTC)[reply]

Trappist asked for comments on the use of the |transcript= parameter group.

The parameter group should be supported, but only if designed, applied and documented correctly.

Let's start with definitions: Transcript Definition & Meaning - Merriam-Webster (3 definitions).

  • Definition 3 (medical usage): Ii doesn't seem any CS1 templates need to employ the medical definition (DNA transcript), and is hard to conceive of a situation they would.
  • Definition 2 (art usage, see more here): Probably, {{cite sign}} and {{cite map}} could conceivably use this parameter group in rare cases.
  • Definition 1b (court or academic record): It is possible that the court usage of transcript and the court transcript itself may need to be indicated, but as there is no specialized template for citing court cases, this could be wide open. Academic transcripts are considered private documents and there is no reason to presume they would be published, except rarely, as parts of other works such as biographies perhaps. Or to make things more convoluted, academic transcripts could be entered as evidence in court cases, so one could conceivably cite academic transcripts as in-source locations of court transcripts.
  • Definition 1a (verbatim copy, the most common use): any work that may be cited in non-text media could use the parameter group. This includes {{cite book}} (an audiobook not specifically published as a print book), {{cite interview}}, {{cite podcast}}, {{cite press release}}, {{cite speech}} etc. etc.

Application note: Transcripts themselves should be cited as the works they represent if they are expressly published as transcripts, for example such transcript of a speech should still be cited with {{cite speech}}. Some transcripts are published with titles different from the original. Others may be cited in non-online media, and therefore such transcripts would not use a URL. There may also be situations where transcripts may have a different title, and a URL. All these cases should be formatted and presented differently. For now, this comment is just exploring the definitiona and their applicability. 68.132.154.35 (talk) 16:55, 7 July 2022 (UTC)[reply]

Following from the above, an implementation proposal:

  • Renames: |transcript= to |transcript-title=
  • Adds: |transcript-url-access=
  • Presentation: transcript parameter values render in plain-text for simplicity
  • Conditions:
    • |transcript-url-format= ignored if there is no |transcript-url=
    • |transcript-url-access= ignored if there is no |transcript-url=
    • |id= (for the transcript) required if there is |transcript-title= but no |transcript-url=
    • |transcript-url=[displays |transcript-title= value] else |transcript-url=[displays] Transcript (static text)
    • When both guideline items below apply, format the citation similarly to citing a translation — Preceding unsigned comment added by 50.75.226.250 (talk) 15:48, 8 July 2022 (UTC)[reply]
  • Guidelines:
    • Editors should add |transcript-title= when different from work title
    • When editors cite a work via its transcript only, strongly encourage |type=transcript

Other, advanced considerations: transcript identifiers, transcript archiving, other-language transcripts. 50.75.226.250 (talk) 15:36, 8 July 2022 (UTC)[reply]

unsupported and deprecated parameter cleanup[edit]

I am reminded that, per Editor Jonesey95, we should have a formal discussion to fully remove support for:

  • |booktitle=
  • |chapterurl=
  • |episodelink=
  • |mailinglist=
  • |mapurl=
  • |nopp=
  • |publicationdate=
  • |publicationplace=
  • |serieslink=
  • |transcripturl=

All of these, if used in a cs1|2 template, will emit the unknown parameter error message, |transcripturl= excepted which is deprecated in {{cite episode}}.

The only vestiges of these parameters are found in Module:Citation/CS1/Configuration except for |transcripturl= which is also in Module:Citation/CS1/Whitelist.

Shall we remove support for the above named parameters?

—Trappist the monk (talk) 14:25, 7 July 2022 (UTC)[reply]

I support this cleanup. To elaborate on the above description, the function of the canonical versions of these parameters is not being removed; we are only removing the unhyphenated aliases of the parameters. We have slowly standardized on hyphenation of multi-word parameters over the years. In other words, |chapter-url= will continue to work fine, but |chapterurl= will not. The above parameters currently emit an "unknown parameter" error message in preview as well as assigning Category:CS1 errors: unsupported parameter. That category contains only 69 pages currently, so finally removing the above parameter aliases should not affect the display of articles beyond those 69 pages. Trappist, please correct any of this if it is incorrect. – Jonesey95 (talk) 16:07, 7 July 2022 (UTC)[reply]
This search should find articles in Category:CS1 errors: unsupported parameter that use any of the above listed parameters except |transcripturl= for which use this search.
—Trappist the monk (talk) 18:56, 7 July 2022 (UTC)[reply]
One other category where use of these parameters might be found is Category:CS1 errors: empty unknown parameters. Use this search to look there (includes |transcripturl=).
—Trappist the monk (talk) 21:35, 9 July 2022 (UTC)[reply]
I've gnomed that category down to empty and none of the errors that I fixed were caused by the parameters in question. Tangent alert! There were, however, a lot of errors caused by |deadurl=. Is there currently a bot fixing these, and if not might Monkbot be interested in them? They're a bit tedious to do by hand but a bot should find them tasty. Best, Wham2001 (talk) 09:07, 8 July 2022 (UTC)[reply]
Support the cleanup, per Jonesey95. 68.132.154.35 (talk) 17:04, 7 July 2022 (UTC)[reply]
The documentation for Citation Style Vancouver suggests the opposite convention to CS1|2 – not using hyphenated parameter aliases – for the sake of getting out every bit of performance. Will CSVAN's documentation change to encourage using to hyphenated parameter names? Is CSVAN still even maintained? SamuelRiv (talk) 17:57, 7 July 2022 (UTC)[reply]
Those templates use a mishmash of parameter styles: |trans_chapter=, |chapter-url=, and |chapterformat= are listed in the documentation for {{Vcite book}}. CS1 started moving away from this mishmash long ago, and is almost done. {{Vcite book}} has only 123 transclusions, and {{Vcite web}} has only 93. It would be an interesting exercise to determine if those templates could be converted to {{cite book}} with appropriate style parameter values without changing their rendered appearance. If so, it would probably make sense to merge them with their corresponding CS1 templates. – Jonesey95 (talk) 18:36, 7 July 2022 (UTC)[reply]
Small-caps is going to be a hard stop. Izno (talk) 18:51, 7 July 2022 (UTC)[reply]
Is CSVAN still even maintained? No, and the user who created it mostly by himself has been blocked for a long time now. Izno (talk) 18:50, 7 July 2022 (UTC)[reply]
I think that I would oppose merging Citation Style 1 with Citation Style Vancouver. cs1|2 is complex enough that attempting to support CSVAN would be a nightmare. Perhaps best to simply let existing {{vcite ...}} citations fade away and then remove support for the templates via TFD.
—Trappist the monk (talk) 18:56, 7 July 2022 (UTC)[reply]
@Izno: the user who created it mostly by himself has been blocked for a long time now Who might that be? The templates {{Vcite book}}, {{Vcite journal}}, {{Vcite news}} and {{Vcite web}} were all created by Eubulides (talk · contribs), who is no longer around, this is true; but their block log is clean. --Redrose64 🌹 (talk) 19:40, 8 July 2022 (UTC)[reply]
I'm thinking of Wikid, who I recall pushing these as if they were sliced bread. Izno (talk) 21:13, 8 July 2022 (UTC)[reply]
Who also has a clean block log, and moreover, zero edits in template space. --Redrose64 🌹 (talk) 20:48, 9 July 2022 (UTC)[reply]
@Redrose64: I think "Wikid" refers to Wikid77. * Pppery * it has begun... 21:17, 9 July 2022 (UTC)[reply]
Performance may have been one of the reasons that the {{vcite ...}} templates were created but that 'advantage', if it were an advantage, pretty much went away when MediaWiki enabled mw:Extension:Scribunto and Lua.
—Trappist the monk (talk) 18:56, 7 July 2022 (UTC)[reply]
I'm only now trying to learn this stuff and searching through the forums gives all the discussions of the old performance issues of COinS but only hints as to what extent that was resolved (other than people stopped talking about it). CSVAN still features prominently in {{Wikipedia referencing}} which is on the CS1 Help page, so if it's old and dead (as are a lot of citation templates) then some cleanup is warranted just to let people know what the current standards are. I'm still curious if it's possible to "switch off" the metadata tags with say a wrapper for CS1|2-based templates which may have some fields that might not be suitable for inheritance, such as if the data in the field will likely always be considered polluting. SamuelRiv (talk) 19:12, 7 July 2022 (UTC)[reply]
Use of the {{vcite ...}} templates in mainspace:
These numbers suggest that the popularity of the {{vcite ...}} templates is on the wane. No doubt the primary reason is that bots, visual editor, RefToobar, Diberri Boghog template filler, etc create cs1|2 templates. If I'm not mistaken, WP:MED used to be one of the primary users of the {{vcite ...}} templates. The above searches suggest that WP:MED has moved away from {{vcite ...}}.
Wrapping cs1|2 templates gives you the benefits of the cs1|2 module suite which includes metadata, error checking, presentation, etc. If you don't want metadata or if you think that the metadata provided by a wrapped cs1|2 template would be bogus, it would probably be best to write your template from scratch. If you expect such a template to be used in articles that are predominantly cs1|2-cited articles, be mindful of presentation because editors care about that; that includes differentiating between cs1 and cs2 presentation.
—Trappist the monk (talk) 22:07, 7 July 2022 (UTC)[reply]
No. Significant opposition to the proposed changes was raised in the RfC, and it does not appear that anything has changed since then.
Pinging participants in that RfC who have not yet commented here, apologies if I've missed anyone: @Pppery, Thryduulf, Imzadi 1979, Kusma, MichaelMaggs, Fram, Wham2001, Hawkeye7, Gonnym, Tol, Levivich, JohnFromPinckney, Andrew Davidson, Finnusertop, and MGA73:. Nikkimaria (talk) 01:38, 8 July 2022 (UTC)[reply]
What is the objection to this specific change, which will have zero effect on any articles? Deprecation of the above parameters happened in February 2021, all of the parameters were updated shortly thereafter, and any stray instances of those parameters have been generating error messages (and have been quickly fixed) since April 2021. Additional factual information appears in this discussion. – Jonesey95 (talk) 13:45, 8 July 2022 (UTC)[reply]
The problems with this effort were outlined in the two previous RfCs, plus there is the concern raised by Hog Farm/Nosebagbear below. Nikkimaria (talk) 17:21, 9 July 2022 (UTC)[reply]
  • Support removal—since these unhyphenated forms don't do anything anymore except generate errors, why are we keeping them around any longer. Imzadi 1979 → 02:52, 8 July 2022 (UTC)[reply]
  • Thank-you for the ping Nikkimaria – my watchlist is currently an unusable tire-fire so I would have missed this discussion otherwise. I support (if we're doing bold !voting) removal of these aliases largely per Jonesey95. They appear not to be in use anywhere in the encyclopedia (unlike, say, |accessdate= which was controversial in the RFC). As such I think that standardisation on the hyphenated variants is only beneficial. Best, Wham2001 (talk) 09:14, 8 July 2022 (UTC)[reply]
  • Support removal - it is much easier to maintain (and copy to other wikis) if there are not a bunch of variants that are really not needed. And thank you for the ping. --MGA73 (talk) 16:24, 8 July 2022 (UTC)[reply]
  • There is a rough consensus that non-hyphenated parameters should not be deprecated in citation templates (option C). That's April 2021. What did I miss? Levivich[block] 16:55, 8 July 2022 (UTC)[reply]
    It is confusing. What you missed is the link to a subsequent January 2022 RFC at the top of this thread; in that RFC, the above parameters remained deprecated, but complete removal of support for them was pushed to a new discussion. This is that discussion. What you and many participants in that April 2021 discussion missed is that the above parameters did not exist in article space at the time of the discussion. They had already been deprecated, and removal of support for them was to be a mere formality. Unfortunately, they were one of the babies thrown out with the bathwater and remained in a sort of limbo. This discussion is finishing that cleanup work in the formal way required by the January 2022 RFC closure. Support for or deprecation of the six remaining active unhyphenated parameter aliases, |accessdate=, |airdate=, |archivedate=, |archiveurl=, |authorlink=, and |origyear=, is not being contemplated in this discussion, and I beg everyone here not to mention them again in this thread, lest it go off the rails. – Jonesey95 (talk) 06:36, 9 July 2022 (UTC)[reply]
    I am confused. Thanks for the link, but what you linked to does not appear to be an RFC. What I linked was an RfC from a year ago where we decided not deprecate any unhyphenated parameters. So where is the RfC that changed that consensus? Because from where I'm sitting, since April 2021, there are no deprecated unhyphenated parameters. I don't think there's been another RfC since there, has there? Even this isn't tagged RfC. So what gives? Why are editors referring to deprecated parameters after the April 2021 RFC? Levivich[block] 02:48, 10 July 2022 (UTC)[reply]
    The January 2022 RfC here. -- GreenC 03:01, 10 July 2022 (UTC)[reply]
    Where in that RFC was it decided to deprecate anything? Can you quote it for me? Levivich[block] 03:07, 10 July 2022 (UTC)[reply]
    That RFC found no consensus to remove deprecated parameters, and though it's not stated in the closing, the reason is because there aren't supposed to be these deprecated parameters in the first place. chapterurl should be an alias for chapter-url, booktitle should be an alias for book-title, and so forth. That's what the April 2021 RFC decided, and as far as I can tell, that hasn't changed. People are pointing to a (non-RFC) discussion in Feb 2021 as the place where it was decided to deprecate these parameters, but that local consensus was overridden by the global consensus of the April 2021 RFC that said "There is a rough consensus that non-hyphenated parameters should not be deprecated in citation templates." That global consensus wasn't changed by the January 2022 RFC. This is all highly irregular. Levivich[block] 03:10, 10 July 2022 (UTC)[reply]
    The January 2022 RFC said that there is no consensus on removal of deprecated parameters in this discussion, and further discussion will be necessary to roll that part out. This is that necessary discussion, a year and a half after the January 2022 RFC. The parameters above have been deprecated since February 2021, have not been used anywhere since March or April 2021, and the proposal now is to remove them from the citation module code entirely. This is how deprecation works, when it works; parameters or methods are deprecated, then removed from use, then discontinued entirely. Historically, with these modules, the process has happened much more smoothly and with a lot less drama. – Jonesey95 (talk) 06:17, 10 July 2022 (UTC)[reply]
    What does "non-hyphenated parameters should not be deprecated", from the April 2021 RFC mean, and why doesn't that override the earlier Feb 2021 decision to deprecate? I'm sorry that my questions are too "drama" for you, I'll try to ask them in a less dramatic way. Can we just do this where you pretend I'm not stupid and explain in plain English why the words "non-hyphenated parameters should not be deprecated" doesn't mean that non-hyphenated parameters should not be deprecated, and why you're saying that any non-hyphenated parameters are deprecated if there was an RfC that resulted in consensus that non-hyphenated parameters should not be deprecated. Because that's how RFCs work. Levivich[block] 06:37, 10 July 2022 (UTC)[reply]
    When the closer said that "non-hyphenated parameters should not be deprecated" in April 2021, they were referring to the remaining six unhyphenated multi-word parameters: |accessdate=, |airdate=, |archivedate=, |archiveurl=, |authorlink=, and |origyear=. Those six parameters are not at issue here; the beginning of mass bot modification to hyphenated parameters prior to a deprecation discussion about those six was the main cause of that RFC and the main objection of participants. Maybe that is the main source of your confusion? That would be understandable, because that discussion got pretty convoluted.
    As of April 2021, the parameters at the top of this discussion were already deprecated and had been removed from all namespaces that assign CS1 tracking categories. They were not undeprecated by the April 2021 discussion. Now, go forward in time to January 2022. In that month's RFC, there was a long list of code changes proposed, including remove support for previously deprecated parameters |booktitle=, |chapterurl=, |episodelink=, |mailinglist=, |mapurl=, |nopp=, |publicationdate=, |publicationplace=, |serieslink=, |transcripturl= (note that this is the list of ten parameters, deprecated since February 2021, at the top of this July 2022 discussion). Those changes were generally approved for implementation, but there is no consensus on removal of deprecated parameters in this discussion, and further discussion will be necessary to roll that part out, so those ten parameters remained in the deprecated state. Now we are having that further discussion, with the goal of moving those ten parameters from deprecated, non-standard, and unused (where they have been since February 2021) to completely unsupported, i.e. removed from the code. – Jonesey95 (talk) 07:07, 10 July 2022 (UTC)[reply]

Please quote where in the April 2021 RFC it specified certain parameters and not others. The RfC question was Should non-hyphenated parameters be fully removed from the CS1/2 family of templates? The background section said In 2014 an RFC determined that all parameter names in Citation Style 1 templates should have an alias...This meant, for example, that access-date= would be shown as the preferred parameter while accessdate= was shown as acceptable but discouraged from use. In the following years there have been various trends and discussions formally deprecating many of the non-hyphenated parameters, from a small handful (2019 example) to the current list which contains over 70 entries. Many of these are the non-hyphenated variants of the preferred/hyphenated versions, which are being removed to decrease the maintenance burden and increase the uniformity between templates (i.e. "ease of use")...In October 2020, all non-hyphenated parameters were added to the "current list" linked above. Option C was Option C: Non-hyphenated parameters should not be deprecated; deprecation should not be continued and bot approval should be revoked. This will also mean that the deprecated parameter list will need to be updated to remove the non-hyphenated parameters. And the close was: There is a rough consensus that non-hyphenated parameters should not be deprecated in citation templates (option C). This means that existing hyphenated (e.g. access-date) and non-hyphenated (e.g. accessdate) parameters should both continue to be supported by the templates. Bot removal of non-hyphenated parameters from transclusions, i.e. Monkbot task 18, does not have community consensus. Where does any of that specify some deprecated parameters and not others? In October 2020, all non-hyphenated parameters were added to the "current list" and This will also mean that the deprecated parameter list will need to be updated to remove the non-hyphenated parameters. means, to me, that ALL non-hyphenated parameters were un-deprecated in April 2021. @Joe Roe: am I misreading this close? Levivich[block] 14:39, 10 July 2022 (UTC)[reply]

It is clear to me that my multiple attempts to use words to explain the timeline have not been effective for you, so I will either leave it to someone else to help you, or leave it to the person who summarizes this discussion to determine what the next step should be. Happy editing! – Jonesey95 (talk) 04:02, 11 July 2022 (UTC)[reply]
  • Support removal - been deprecated for a long time, and are essentially unused now. Time to clean them up. --PresN 19:25, 8 July 2022 (UTC)[reply]
  • Support removal it's high time to cleanup. Headbomb {t · c · p · b} 20:00, 8 July 2022 (UTC)[reply]
Support removal. Was pinged to this discussion. These parameters are not used and the convention is to use hyphenated versions. Gonnym (talk) 23:18, 8 July 2022 (UTC)[reply]
Support removal for these few as they've been essentially trace fossils for quite some time, with the understanding that this discussion should not be claimed as a consensus for removal of other non-hyphenated parameters. Hog Farm Talk 06:40, 9 July 2022 (UTC)[reply]
Concur with removal for these without precedent - as with Hog Farm, I back the removal here without wanting the risk for it to act as a precedent across all paramaters. Nosebagbear (talk) 12:32, 9 July 2022 (UTC)[reply]
Oppose This is trying to justify something that the community agreed should never have been done based on a fait accompli * Pppery * it has begun... 18:44, 9 July 2022 (UTC)[reply]
  • Support removal and thank you for your efforts in maintaining citation templates. 19:42, 9 July 2022 (UTC) — Preceding unsigned comment added by Renata3 (talk • contribs)
  • Oppose because this is going to be used as evidence to remove the other non-hyphenated parameters --Guerillero Parlez Moi 14:11, 11 July 2022 (UTC)[reply]
    That is not a valid reason for any opinion, pro or con. A discussion result is not evidence of anything except of the existence or absence of consensus among participants of said discussion. Apart from that anything can be used to promote or oppose anything. And that is irrelevant. 50.75.226.250 (talk) 15:54, 11 July 2022 (UTC)[reply]
  • Support removal of these parameters for better standardisation. Tol (talk | contribs) @ 18:58, 12 July 2022 (UTC)[reply]
  • Support only for those that generate errors - What is the point of keeping them if they generate errors? I opposed ditching the hyphenated parameters in the previous RfC, and still think there are too many hyphenated parameters that people actively use. I don't mind deprecating them, but they shouldn't be removed. Just have a bot/AWB/whatever go around and clean them up if they're functional-but-not-ideal. The idea is to to maximize user functionality. Lots of people have used hyphenated parameters for a long time, so getting rid of them... is just going to generate errors or not show up. Of course, if some are already only generating errors, that ship has sailed. — Rhododendrites talk \\ 12:29, 13 July 2022 (UTC)[reply]
    @Rhododendrites: Do you mean non-hyphenated? No one is suggesting to get rid of the hyphenated ones. –MJL ‐Talk‐☖ 06:48, 14 July 2022 (UTC)[reply]
    All of the parameters listed at the top of this discussion generate error messages and error-tracking categories. They have been deprecated since February 2021. Deprecated (and unsupported) parameters in CS1 templates generate error messages and error-tracking categories. – Jonesey95 (talk) 07:41, 14 July 2022 (UTC)[reply]
    Yes, I understand that, but they're not hyphenated (eg. |booktitle= is unhyphenated). –MJL ‐Talk‐☖ 19:17, 14 July 2022 (UTC)[reply]
  • Oppose removal, after thinking about it a bit, because instead of removal, what should happen is that these unhyphenated parameters should be aliases to their hyphenated counterparts. |booktitle= should be an alias to |book-title=, |chapterurl= should be an alias to |chapter-url=, and so on. That these parameters currently give errors isn't a reason to remove them, it's a reason to fix them and return them to the aliases they used to be. The April 2021 RFC found consensus that non-hyphenated parameters should not be deprecated in citation templates and that the deprecated parameter list will need to be updated to remove the non-hyphenated parameters. Assuming that was done, there should be no non-hyphenated parameters on the deprecated parameter list; they should not be throwing off errors; support for these parameters should not be removed; they should be returned to functioning aliases. Levivich (talk) 02:28, 17 July 2022 (UTC)[reply]
  • Comment: I am not sure what the best option is here, since I can come up with decent arguments in favor of either. On one hand, removing them would be kind of a pain in the ass. Having the templates break entirely when given unhyphenated parameters would cost us something, in that everyone trying to insert a reference would have to go back and dick around with the template to fix huge red error messages. In a big article with a lot of references, this can be a significant amount of work. On the other hand, keeping them would also be kind of a pain in the ass -- it would populate the citation error category, requiring someone to go through and gnome the errors out. On the third hand, though, this seems a lot easier than having people fix the parameters while writing the article (you could probably just have a bot go through every few days and fix the errors). In conclusion... who knows. jp×g 20:15, 17 July 2022 (UTC)[reply]
    It is possible that JPxG misunderstands the proposed change and its effects. These unhyphenated multi-word parameters, like |chapterurl=, have been deprecated for a year and a half, currently display error messages, do not (or should not, at least; we may have missed a couple) appear in the documentation, and are not in use in the spaces that are categorized by the citation templates. Nobody is going to have to do any work to implement or clean up after this change. Standard hyphenated multi-word parameters, like |chapter-url=, will continue to work without any problems. – Jonesey95 (talk) 23:35, 17 July 2022 (UTC)[reply]
Yeah, sorry, I wrote this ass-backwards. I meant to say "unhyphenated". jp×g 07:14, 18 July 2022 (UTC)[reply]

i18n uncategorized namespace list[edit]

Some history:

In Module:Citation/CS1/Configuration at line 12 we have a list of namespaces that cs1|2 does not categorize. The namespace names there are the canonical (English) names that appear to work in all other wikis when used in a wikilink or url. But, when cs1|2 fetches the namespace name from a non-English wiki, the non-English wiki returns the name in its own language. That means that editors in those other-language wikis must translate (replace) the English names with local names.

I have hacked Module:Citation/CS1/Configuration/sandbox to fetch the list of talk namespace identifiers from MediaWiki. The namespace list is specific to the local wiki in that local namespace names are the local language names but the namespace identifiers are the same for all wikis: namespace 2 at en.wiki is 'User' and at sq.wiki is 'Përdoruesi'.

This has the further benefit of making sure that the list of talk pages remains up-to-date; for example, at some point, apparently, the 'Book talk' and 'Education Program talk' namespaces and associated subject-namespaces disappeared.

—Trappist the monk (talk) 15:10, 9 July 2022 (UTC)[reply]

@Trappist the monk, shouldn't we also allow a way for foreign wikis to add add/remove untracked NS to wish? Or advise how to do so with a comment? That's how I was envisioning the change initially when I proposed it, even though maybe it won't be as much of a problem anyway. - Klein Muçi (talk) 15:39, 9 July 2022 (UTC)[reply]
Oddly enough, I watch this page, no need to ping me.
A custom list of uncategorized namespaces is possible. If, for example, you don't want to track errors in the 'Kategoria' namespace, change:
uncategorized_namespaces_t = {[2]=true};
to:
uncategorized_namespaces_t = {[2]=true, [14]=true};
I suspect that most wikis are content with the default that we use here. If they are not, they can change uncategorized_namespaces_t to suit their needs.
This change should resolve the issue at sq:Diskutim:Lasgush Poradeci that you mentioned on my talk page.
Documentation will come...
—Trappist the monk (talk) 16:06, 9 July 2022 (UTC)[reply]
Oh, okay then. I was thinking that they would have to figure that out on their own so I was suggesting either to have most NS numbers there and commented out and advise how to comment/uncomment at wish or advise on doing what you propose, which is more elegant but heavier on the comments' side.
PS: Generally speaking, I find your sense of irony amusing, at least. This was a bit bland though. :P - Klein Muçi (talk) 16:34, 9 July 2022 (UTC)[reply]

documentation[edit]

I've tweaked Module:cs1 documentation support to add an uncategorized namespace lister function. This function is intended for use in Help:CS1 errors § Notes. After the next cs1|2 update, add this in place of the manual list:

{{#invoke:cs1 documentation support|uncategorized_namespace_lister}} →
Talk (1), User (2), User talk (3), Wikipedia talk (5), File talk (7), MediaWiki talk (9), Template talk (11), Help talk (13), Category talk (15), Portal talk (101), Draft talk (119), TimedText talk (711), Module talk (829), Gadget talk (2301), and Gadget definition talk (2303)

For convenience, I added one parameter to that function. |all= when set to any value will emit a simple unordered list of all namespace names and their identifiers. Namespace names with identifiers less than 1 (currently Mainspace (0), Special (-1), and Media (-2), are omitted from the list:

{{#invoke:cs1 documentation support|uncategorized_namespace_lister|all=1}} →
  • Talk (1)
  • User (2)
  • User talk (3)
  • Wikipedia (4)
  • Wikipedia talk (5)
  • File (6)
  • File talk (7)
  • MediaWiki (8)
  • MediaWiki talk (9)
  • Template (10)
  • Template talk (11)
  • Help (12)
  • Help talk (13)
  • Category (14)
  • Category talk (15)
  • Portal (100)
  • Portal talk (101)
  • Draft (118)
  • Draft talk (119)
  • TimedText (710)
  • TimedText talk (711)
  • Module (828)
  • Module talk (829)
  • Gadget (2300)
  • Gadget talk (2301)
  • Gadget definition (2302)
  • Gadget definition talk (2303)

—Trappist the monk (talk) 18:23, 9 July 2022 (UTC)[reply]

Add a brief note regarding Worldcat (OCLC) as a reliable source[edit]

Template:Cite book states at Parameters » Description » URL: "Do not link to any commercial booksellers, such as Amazon; use isbn= or oclc= to provide neutral search links for books."

However, if you use the very helpful Unreliable/Predatory Source Detector (UPSD), book titles hyperlinked to a corresponding Worldcat page will be highlighted in light yellow, indicating a potentially unreliable source. In this case, Worldcat.org is flagged as a "preprint or general repository".

The rationale for this categorization is that Worldcat.org contains self-published books, which are usually not reliable sources. Thus, one should not assume that a book found in a union catalog such as Worldcat.org is necessarily a reliable source. Stated differently, one should not assume that an OCLC link always constitutes a "neutral search".

At the same time, Worldcat.org listings serve important functions, such as helping readers find a book in a nearby library. And editors can identify vanity books (one form of self-published texts) as an unreliable source and not cite them in the first place.

I therefore suggest adding a brief explanatory note {{efn}} at the end of the sentence quoted above that reads something like this:

Keep in mind that an OCLC number, which corresponds to the book's listing on Worldcat.org, does not convey any sort of special status for a book. Editors should first determine if a book is a reliable source, and then cite the book with (among other data) an OCLC number. Hyperlinking book titles to Worldcat.org, or simply including the (automatically hyperlinked) OCLC number, helps readers find books in nearby libraries, so it is a desirable component of a citation.

Thank you for your kind consideration,

Mark D Worthen PsyD (talk) [he/him] 20:58, 9 July 2022 (UTC)[reply]

I don't think the note you're proposing is needed. That's true of ISBNs as well. The current note is to favour neutral link over commercial links. Whether or not a source is reliable is hardly related to citation templates. Headbomb {t · c · p · b} 21:39, 9 July 2022 (UTC)[reply]
I agree with Headbomb, and thought of ISBNs, ASINs, and even DOIs. Pretty much all identifiers are just that, identifiers, and do not necessarily convey information about the reliability of the linked item. They are finding aids. – Jonesey95 (talk) 02:18, 10 July 2022 (UTC)[reply]
When I see the title of a source linked, meaning someone supplied a value for |url=, then my assumption is that the link will take me to a digital copy of the source. Since Worldcat is not hosting the book, but instead providing the ability to find a copy of the book in a library, the URL for the book's listing at Worldcat shouldn't be provided in |url=. If I see that it is, I assume it's an errant attempt to supply |oclc= and edit the citation accordingly to remove the URL and make sure the OCLC is listed instead. I take similar action when someone links a book to a publisher's catalog listing/sales page for a book or for third-party sales page like Amazon. Imzadi 1979 → 04:12, 10 July 2022 (UTC)[reply]
Thank you Imzadi1979, that is very helpful.
Headbomb said, "Whether or not a source is reliable is hardly related to citation templates." If that is true, why does your script identify the source (Worldcat.org) as potentially unreliable? Excuse my ignorance if the answer is obvious (to everyone but me). :^\
- Mark D Worthen PsyD (talk) [he/him] 04:58, 10 July 2022 (UTC)[reply]
See WP:UPSD#OCLC Headbomb {t · c · p · b} 11:11, 10 July 2022 (UTC)[reply]
Thank you - pithy, helpful explanation. Mark D Worthen PsyD (talk) [he/him] 23:44, 10 July 2022 (UTC)[reply]
Does Worldcat actually host books though, like Google Books? Or is it just cataloging them? That's an important distinction, I think. Imzadi 1979 → 00:19, 11 July 2022 (UTC)[reply]
AFIACT, it's just a catalog listing. Some people mentioned that it showed a Google Book embedded preview, but I've never seen that one myself. Headbomb {t · c · p · b} 00:43, 11 July 2022 (UTC)[reply]
Worldcat used to link to Googlebooks for some catalog entries. But when Google shifted to the 'new' books, that stopped working. I delete |url=https://www.worldcat.org/oclc/<id> on sight when |oclc=<id> matches. If only ve would stop adding the worldcat url when it writes a template with |oclc=<id>...
—Trappist the monk (talk) 00:54, 11 July 2022 (UTC)[reply]
Might be time to propose a bot run to purge those links (and replace them with |oclc=). Same for pubmed links that can be handled by PMID. Headbomb {t · c · p · b} 01:02, 11 July 2022 (UTC)[reply]

CITEREF disambiguators in date-holding parameters other than |date= and |year=[edit]

Another discussion elsewhere got me wondering why we don't trap the use of CITEREF disambiguators in date-holding parameters that don't contribute to the citation's anchor ID. The parameters that contribute to the anchor ID are:

  • |date=
  • |year= – promotes to |date= when |date= not present in the template
  • |publication-date= – promotes to |date= when both of |date= and |year= are not present in the template

All other date-holding parameters should not have CITEREF disambiguators. I have tweaked Module:Citation/CS1/Date validation to catch CITEREF disambiguators in parameters where they are not appropriate:

Cite web comparison
Wikitext {{cite web|accessdate=11 July 2021a|archive-date=11 July 2022a|archive-url=//archive.org|title=Title|url=//example.com}}
Live "Title". Archived from the original on 11 July 2022a. Retrieved 11 July 2021a.
Sandbox "Title". Archived from the original on 11 July 2022a. Retrieved 11 July 2021a. {{cite web}}: Check date values in: |accessdate= and |archive-date= (help)
Cite book comparison
Wikitext {{cite book|publication-date=2022a|title=Title}}
Live Title. 2022a.
Sandbox Title. 2022a.
Cite book comparison
Wikitext {{cite book|date=2022a|publication-date=2021a|title=Title}}
Live Title (published 2021a). 2022a.
Sandbox Title (published 2021a). 2022a. {{cite book}}: Check date values in: |publication-date= (help)

—Trappist the monk (talk) 14:30, 11 July 2022 (UTC)[reply]

Here's a hypothetical situation:
A dynamic webpage updated >1 daily
on the same date
citation0 (cites update0) archived in archive-snapshot0
citation1 (cites update1) archived in archive-snapshot1
?: Keep dab on archive dates?
50.75.226.250 (talk) 15:42, 11 July 2022 (UTC)[reply]
I don't think so. Citation anchor IDs are composed of up to four author/contributor/editor surnames and the year portion of the publication date with optional disambiguator. The date assigned to |archive-date= plays no part in that and shouldn't; it should only hold the date of the archived snapshot. If an editor must cite the same dynamic webpage updated >1 daily then multiple cs1|2 templates each with a different |archive-url= and |date= appropriately disambiguated. If required, |ref=CITEREF<something>a, |ref=CITEREF<something>b, etc.
—Trappist the monk (talk) 17:40, 11 July 2022 (UTC)[reply]
The hypothetical case has nothing to do with the CITEREF anchor, it was remarked upon because of the proposed disallowance of disambiguated archive dates. It is admittedly a far-edge case, and its only function would be to visibly signal a match between the update URL and the archive URL (via the respective dates of both). This may be useful, especially (but not solely) when/if one or more of the original URLs are marked as not live. Additionally, allowing dab in |archive-date= is probably a small net positive. The code will not have to error-out any and all disambiguated archive dates except the ones with matching disambiguators, likely a very small percentage of a very small percentage of cases. 68.132.154.35 (talk) 19:06, 11 July 2022 (UTC)[reply]
I don't see value to supporting anything but the parameters Ttm originally identified here. There is no edge case here; disambiguation has always been documented as expected to be in |date=. |archive-date= isn't |date= and is never promoted as such in the module or in documentation. Izno (talk) 19:11, 11 July 2022 (UTC)[reply]
The status quo now is that |archive-date= accepts disamibuators. This would be useless, unless there is a case of two or more citations which cite updates of the same webpage on the same day (dab date), with corresponding archives on the same day (dab archive date). Can such a case be ruled out? Does it cost anything to leave the status quo as is regarding dab archive dates? If anything, leaving |archive-date= out of the particular error-checking routine may be a net plus. 68.132.154.35 (talk) 19:25, 11 July 2022 (UTC)[reply]
unless there is a case of two or more citations which cite updates of the same webpage on the same day So use the already supported "same day" mechanism we have in place for anything else. Izno (talk) 19:44, 11 July 2022 (UTC)[reply]

Warning generated for list of authors[edit]

"author=Technical Committee ISO/TC 58, Gas cylinders, Subcommittee SC4" is generating a warning. What is wrong with the format? · · · Peter Southwood (talk): 08:57, 12 July 2022 (UTC)[reply]

cs1|2 is not smart enough to distinguish a comma separated list of human names from a corporate or organizational name that contains commas. |author= must hold only one name. cs1|2 allows one comma in |author= (for Last, First names). Any more than one comma in |author= (or any semicolon) is presumed to be a list of human names so cs1|2 emits the maintenance message.
When citing a corporate or organizational author with commas, you can do this (described at Help:Citation Style 1 § Accept-this-as-written markup):
{{cite book |author=((Technical Committee ISO/TC 58, Gas cylinders, Subcommittee SC4)) |title=Title}}
Technical Committee ISO/TC 58, Gas cylinders, Subcommittee SC4. Title.
It may not be the case here but I very often encounter corporate or organizational 'authors' that are essentially duplicates of the publisher. For those citations, |author= can be deleted.
—Trappist the monk (talk) 11:46, 12 July 2022 (UTC)[reply]

need to automate doi-access change to 'free', based on date[edit]

Is this worth adding to the module, or should I create a new citation template for JIPA?

We will be citing several hundred illustration of the IPA in JIPA, linked via DOI to their host publisher site at CUP. They are subscription for the first 3 years, then free public access. It would be nice if the template could handle this. E.g., something like doi-access= {{#ifexpr:(({{CURRENTYEAR}} - {{{date}}}) > {{{freeage}}})|free}}, where we could set freeage to 3. (Since for the URL link 'free' is the default, there shouldn't be any confusion that 'freeage' applies to the DOI link.)

See Qaqet language#Further reading, where I used the 'translation' parameter to add a note about the article. It is -- or will be -- in the 'Illustrations of the IPA' section of the journal, and that is the standard wording used in the lit to refer to these JIPA articles, so that phrasing should be included but isn't part of the title. Also there is supplementary material (sound files) online which are a good publicly accessible resource and should be mentioned, but I don't see a param designed to handle that info.

Please ping. Thanks, — kwami (talk) 21:48, 12 July 2022 (UTC)[reply]

For pmc identifiers we have |pmc-embargo-date=. But, embargoed pmcs are relatively common and not constrained to any particular journal. Are there other journals or publishers that have similar doi embargos? I'm not enthusiastic about creating and maintaining code in the cs1|2 module suite that will support only one journal. If doi embargos are a common practice among multiple journals/publishers then we might consider creating |doi-embargo-date=.
|trans-title= has a defined purpose. Do not misuse cs1|2 parameters for purposes that do not fit with the parameters' defined purposes. Use |department= for the 'Illustrations of the IPA' section of the journal.
—Trappist the monk (talk) 11:04, 13 July 2022 (UTC)[reply]
@Trappist the monk: Okay, thanks. That meaning of "department" isn't in my vocabulary. What param should I use for notes/comments, such as 'includes supplementary material'? 'Pages', maybe? — kwami (talk) 01:54, 18 July 2022 (UTC)[reply]
|doi-embargo-date= has some merit as an idea. The issue is mostly that this is a very hard thing to keep track of manually, since it varies a lot by journal and publisher. Headbomb {t · c · p · b} 02:18, 18 July 2022 (UTC)[reply]
cs1|2 does not have any parameters for notes/comments. |pages= has a defined purpose. Do not misuse it for something else. If you want to append notes/comments to a citation, they can go at the end – after the template's closing }} and before the reference's closing </ref>.
—Trappist the monk (talk) 11:39, 18 July 2022 (UTC)[reply]

url-status=live without an archive-url[edit]

I've added this to Template:Citation Style documentation/doc:

Note: if |url-status=live is included but there is no |archive-url=, an error message is displayed when the link is hovered over, and a warning shown when the edit is previewed, although the reference shows normally in the list.

It is a pain to find and remove these instances; I'd suggest that |url-status=live be allowed without generating an error message, it seems harmless.

I added this comment to the documentation boldly; if it's thought inappropriate, or needs rewriting, go ahead.

Best wishes, Pol098 (talk) 11:45, 13 July 2022 (UTC)[reply]

This is about this edit at Template:Citation Style documentation/url‎.
A maintenance message is not an error message. To display maintenance messages, editors must enable them using the css specified at Help:CS1 errors § Controlling error message display. Are you using Navigation popups? That tool does not obey css rules and so displays the maintenance message on hover. The generic popup does obey css rules so the normally hidden maintenance messages are not displayed in the popup on hover unless they have been properly enabled.
I will undo your edit at Template:Citation Style documentation/url‎.
—Trappist the monk (talk) 13:14, 13 July 2022 (UTC)[reply]
Thanks for response and revert. The documentation doesn't make any suggestion about whether adding |url-status=live without an |archive-url= is appropriate; should there be any preferred option? I won't do anything else. Best wishes, Pol098 (talk) 14:02, 13 July 2022 (UTC)[reply]
Perhaps. At the time of original insertion. all URLs are presumed live, so adding the parameter then may or may not be deemed overkill. Establishing a relationship between |url-status= and |archive-url= when the URL is not live may prompt editors to add an archived version. But I don't see any utility in generating any kind of message, maintenance or otherwise, when there is no |archive-url= and there is |url-status=live. 50.75.226.250 (talk) 14:49, 13 July 2022 (UTC)[reply]
@Pol098: It should be documented that using any value of |url-status= is incorrect, unless the citation includes an |archive-url=. (I thought it was, somewhere, but I'll have to look.) The reasoning is that Wikipedia can never make statements about the "current status" of a URL in citations (since that status can change at any moment, and the parameter would not be updated), so in fact we don't do that because it's not what |url-status= means.
|url-status=live actually has nothing to do with the status of the URL itself, really, its sole purpose is to communicate to an |archive-url= parameter that it should allow the |url= parameter to remain the primary link for the citation, rather than being relegated to a "the original" link with the |archive-url= displayed as primary. So |url-status= is merely a secondary argument to |archive-url=, like |archive-date=, that controls how the citation is formatted. The same way an |archive-date= without an |archive-url= would be a mistake (it makes no sense whatsoever), a |url-status= without an |archive-url= is a mistake for the same reason.:::|url-status=live/dead is probably misnamed, and should have been called |archive-status=backup/primary or something similar. (With |archive-status=primary being the default, corresponding to the default |url-status=dead today.) That would better communicate both the true meaning of the parameter and its relationship to |archive-url=. That'd be a hard thing to change now, but might be worth it anyway just to clear up the confusion that results from the generic |url-status= label. FeRDNYC (talk) 15:06, 14 July 2022 (UTC)[reply]

Thanks @FeRDNYC and Trappist the monk for useful contributions. FeRDNYC's explanation makes so much sense, though I don't know any of the background, that I propose another edit to the documentation in place of what I originally said. I will consider adding it if there are no comments to the contrary, and nobody else has done it (probably better).

The |url-status= parameter should not be used (with any value) unless a (dated) |archive-url= has been provided. Wikipedia never knows the current status of a URL, whatever it was when a citation was created.

Best wishes, Pol098 (talk) 15:38, 14 July 2022 (UTC)[reply]

You misunderstand the nature and purpose of |url-status=. It is a secondary helper parameter, and its value, following the norm of CS1 templates, was never expected to be automated or dynamic. It is a static value (including a default static value), valid at the time of a related URL-based edit, that may trigger a change in the presentation of some URL-based parameters and other associated parameters. Granted that is not documented clearly, but your proposal makes things worse, and misrepresents the issue. 68.132.154.35 (talk) 19:27, 14 July 2022 (UTC)[reply]
I understand what url-status is for; I don't see how to word this very briefly in documentation. My wording won't actually make usage worse - it should discourage anyone who reads it from using it for non-archived references, but I'm the first to agree that others can do better. Describing it as a " a secondary helper parameter", while correct, requires quite a bit of explanation to an editor seeking simple guidance. How do you, 68.132.154.35, or anyone suggest this should be worded in documentation with the purpose of discouraging misuse? "It should be said this way" is useful; "it shouldn't be said that way" is not. Beat wishes, Pol098 (talk) 19:36, 14 July 2022 (UTC)[reply]
It can definitely be worded better. However, the responses only referred to your proposed edit. Also, is it worth anybody's time and effort getting involved in this any more than cursorily? For instance, imo your proposal approaches this from the wrong angle. A rational design would simply make the parameter dependent on the presence of any URL-based parameter, not just one of them, and condition its value range accordingly. The current blinkered design and implementation is reflected in the documentation and obviously generates equally confused/confusing contributions such as this section or the RFC to rename the parameter, as if the name was the fundamental problem here. Good luck in your endeavors! 50.75.226.250 (talk) 15:38, 15 July 2022 (UTC)[reply]
Thanks. It can definitely be worded better. - so how about some actual suggestions, or even edit the documentation appropriately? is it worth anybody's time and effort getting involved in this any more than cursorily? Cursorily is my aim, add a sentence to the documentation to reduce the instances of unneeded live statuses, not the "proper solution" proposed.

Where I'm coming from: editing articles I find warnings in the edit preview. There is no information on which of the huge number of references is at fault, or how, and many warnings don't show as red messages in the references. While I suppose there are better ways to find the errors, I haven't gone about this systematically, but simply tried hovering over each reference number in the preview, which is tedious. It would be a minor improvement if editors were encouraged not to add unnecessary statuses, rather than think that it is "helpful". Best wishes, Pol098 (talk) 16:24, 15 July 2022 (UTC)[reply]
There is no information on which of the huge number of references is at fault. Not in the yellow preview-message box, but every cs1|2 template that contributes to the green messages in the yellow preview-message box emits its own warning message where the template is rendered. This template emits the warning message for |url-status=live without |archive-url=:
{{cite book |title=Title |url-status=live}}
Title.{{cite book}}: CS1 maint: url-status (link)
If you do not see the maintenance message at the right end of the line above, you need to enable message display for which, see Help:CS1 errors § Controlling error message display.
—Trappist the monk (talk) 16:45, 15 July 2022 (UTC)[reply]
@68.132.154.35: It is a secondary helper parameter, and its value, following the norm of CS1 templates, was never expected to be automated or dynamic. Well... I mean, except for the bot we have running around, making automated changes to that and other parameters. FeRDNYC (talk) 03:56, 19 July 2022 (UTC)[reply]
What CS1 is about, and what other scripts do with it, are different subjects. In this case, the particular script is helpful. As stated above, the problem is with the design and implementation of |url-status=, not with the archive parameters or any script that applies them. In any case, "dependent variable" does not necessarily mean "dynamic variable". 50.75.226.250 (talk) 15:23, 19 July 2022 (UTC)[reply]

RFC: Rename url-status parameter[edit]

WP:SNOW
Editors agree that this proposal is unnecessary. Further, commenters suggest that the proposer should have started an informal discussion on the issue before starting an RfC. (non-admin closure) 🐶 EpicPupper (he/him | talk) 22:30, 21 July 2022 (UTC)[reply]
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

The meaning of the |url-status= citation parameter is frequently misunderstood by editors. (See the discussion immediately above this one, url-status=live without an archive-url, for just one example of literally dozens, if not hundreds, over the years.)

I would argue that this confusion is our fault, because the current parameter name is just terrible. |url-status= has nothing whatsoever to do with the current status of the citation URL. (An unknowable, since it can change at any moment.) The only effect of |url-status=live is to prevent the citation's |archive-url= from being promoted to the primary citation link, the way it otherwise is with the default |url-status=dead in effect. Like |archive-date=, NO value of |url-status= has any meaning unless an |archive-url= parameter is also provided.

As such, the name of the parameter should clearly start with archive-. Above, I proposed |archive-status=primary/backup, but that doesn't account for the third possible value of the existing parameter, |url-status=usurped. So upon further reflection, I instead propose that we deprecate |url-status= and replace it with |archive-display=primary/backup/usurped.

|archive-display=primary
Would be the default, where the |archive-url= is the primary citation link and the |url= becomes a "the original" link. Same as the current default |url-status=dead.
|archive-display=backup
Would disable the replacement of the |url= as the primary link, to support preemptive archival linking of non-dead citations. (Same as |url-status=live today.)
|archive-display=usurped
Would, like |url-status=usurped today, disable all linking to the citation's original |url=, for situations where the original link has changed without becoming dead.

I'm fully conscious of what a colossal PITA it will be to make this change, but I feel it can be done in stages (and with some bot assistance) to ease the pain. More importantly, I feel it's ultimately worth the pain because the current parameter name, |url-status=, is just bad. It bears almost no relation to the actual meaning of the parameter, in ways that will continue to mislead and confuse editors until we finally fix our stuff. (I'll cross-link this proposal to Village Pump (technical) as well.) FeRDNYC (talk) 18:15, 14 July 2022 (UTC)[reply]

I ended up posting at Wikipedia:Village_pump (proposals)#Discussion on renaming Citation Style 1 template parameter url-status instead. FeRDNYC (talk) 18:27, 14 July 2022 (UTC)[reply]
Strong oppose. You said that url-status= has nothing whatsoever to do with the current status of the citation URL when in fact it literally does. The whole point of url-status is to determine if the link is dead. You can have url-status=dead without there being an archive link. That way, other people can add the archived link later.
Besides the amount of disruption and work required for a basically cosmetic change is not worth it. Rlink2 (talk) 18:30, 14 July 2022 (UTC)[reply]
Comment I have no opinion even though it will result in a lot of broken bots and user tools that would need to retool (if ever gets done, some poorly maintained but active tools remain nameless). Also "primary" and "backup" are coded terms that are not in themselves explanatory. Suggest "first" and "second" ie. archive URL displayed first ie. archive-display=first .. is a lot more intuitive and easy to remember what it means. -- GreenC 18:36, 14 July 2022 (UTC)[reply]
Strong oppose—this parameter was renamed/reworked not that long ago, and renaming it again would be highly disruptive. Imzadi 1979 → 18:39, 14 July 2022 (UTC)[reply]
History:
—Trappist the monk (talk) 18:42, 14 July 2022 (UTC)[reply]
Oppose Let's not have more of this sort of churn please. * Pppery * it has begun... 18:44, 14 July 2022 (UTC)[reply]
Oppose pointless churn, big hassle for editors and bot developers, no benefit to readers. —David Eppstein (talk) 18:58, 14 July 2022 (UTC)[reply]
  • Oppose, no benefit. Proposal is worse than the status quo. Editor should not have attempted to start an RFC before starting a discussion to get the general consensus, which is clearly opposed. – Jonesey95 (talk) 19:14, 14 July 2022 (UTC)[reply]
  • Oppose I don't see how this parameter is confusing. InfiniteNexus (talk) 04:11, 19 July 2022 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Accept zero padding in dates[edit]

Currently the template does not accept a date such as 09 July 2022, giving an unhelpful error message. Instead one must write 9 July 2022. I think it's silly to bother editors with this, the template should accept both styles and silently reformat it. I thought it would be better to ask here before changing it because this template is so widely used. Tercer (talk) 12:52, 16 July 2022 (UTC)[reply]

See MOS:DATESNO: "Do not zero-pad day". – Jonesey95 (talk) 20:20, 16 July 2022 (UTC)[reply]
You misunderstand me. I'm saying that we should always display 9 July 2022, but allow editors to input 09 July 2022. Tercer (talk) 20:28, 16 July 2022 (UTC)[reply]
Why not get people to do it right in the first place? If they get into the habit of using it in cite templates then they will use it in other places in the text which will not get autocorrected. Keith D (talk) 22:27, 16 July 2022 (UTC)[reply]
Tercer, I understand what you are saying, but it is a bad idea, as Keith D explains. For the same reason, we also emit error messages when editors type 1/15/2003 or 01-15-03 or 2004-05. Editors should type valid dates so that there is a better chance that the date they type is correct and will not have to be checked or fixed by others. – Jonesey95 (talk) 00:19, 17 July 2022 (UTC)[reply]
Dates in M/D/Y format, two-digit years, or "2004-05" are ambiguous (though technically speaking, 1/15/2003 isn't). 09 July 2022 isn't ambiguous, though. (On a side note: Module:Citation/CS1/Date validation seems to have the code already written to support leading zeros, though it is commented out.) isaacl (talk) 20:56, 17 July 2022 (UTC)[reply]

Frankly, annoying editors with a pointless error message in order to teach them a minor stylistic point? You guys are a lost cause. I'm sorry I tried to help. Tercer (talk) 08:12, 17 July 2022 (UTC)[reply]

You are correct, and such pointless error messaging has caused problems in the past. Also agree this increasingly looks like a lost cause. 104.247.55.106 (talk) 13:43, 17 July 2022 (UTC)[reply]

I entirely agree with @Tercer. I do a lot filling of refs, and for accuracy's sake I copy-paste the date from the article where possible. Many date formats are unambiguous, but need to be re-formatted to avoid error error messages. These other formats are easily parsed; why trigger an error message when the date is unambiguous?

e.g. for 9 December 2014, the templates should accept:

  • 09 December 2014
  • 9 December, 2014
  • 9 DECEMBER 2014
  • 9 DECEMBER, 2014
  • 9 DEC 2014
  • 9 Dec. 2014
  • 09 Dec., 2014
  • 09th DEC, 2014
  • ... and many other variants.

The current demand for conformity is just a make-work. --BrownHairedGirl (talk) • (contribs) 08:03, 22 July 2022 (UTC) By all means trigger a warning, but not an error.[reply]

When updating the URL, should the access-date and archive-url parameters also be updated?[edit]

One of the pages I'm wanting to edit uses the {{cite news}} template, but the news article URL that the page links to 404s - the site in question has changed its layout. I've found the new URL on the site, and I'm assuming (but am not completely sure) that the access-date parameter should be changed in the template, since the new URL was accessed on the date I'm editing. Is this correct?

Obviously, the old archive-url link still works, since it's, well, an archive. Should I leave the archive URL as-is, or update it to match the new URL? --TheSophera (talk) 23:48, 17 July 2022 (UTC)[reply]

However you like, so long as the links verify the cited fact. If there no fact being cited, IMO prefer the newer link in both url and archive-url .. the main thing is WP:V -- GreenC 23:55, 17 July 2022 (UTC)[reply]

AV identifiers[edit]

For your consideration:

May have enough critical mass to be included in the Identifiers group. 50.75.226.250 (talk) 16:09, 18 July 2022 (UTC)[reply]

Cite document emits a missing periodical maintenance message. It shouldn't[edit]

Case in point:

Pinging User:Keith D. Headbomb {t · c · p · b} 12:28, 22 July 2022 (UTC)[reply]

It also does not have the page identifier (pp.) Keith D (talk) 12:32, 22 July 2022 (UTC)[reply]
{{cite document}} is not a cs1|2 template. It is merely a redirect to {{cite journal}}. As such, cs1|2 sees the template as a {{cite journal}} template and renders whatever it has been given as a journal-style citation. {{cite journal}} requires |journal= so when that parameter is empty or omitted, cs1|2 emits the error message. Pagination rendering follows the {{cite journal}} format (<colon><space><pagination>).
The source in the example template is clearly not a journal so were it me, I'd rewrite the example template:
{{cite web |last=Amos |first=David |url=https://www.academia.edu/40640025 |title=Controversies in Coal: Internment, Impoundment and Intrigue at Harworth Colliery (1913–1924) |date=January 2017 |pages=10–11 |access-date=5 October 2020 |website=Academia}}
Amos, David (January 2017). "Controversies in Coal: Internment, Impoundment and Intrigue at Harworth Colliery (1913–1924)". Academia. pp. 10–11. Retrieved 5 October 2020.
—Trappist the monk (talk) 13:07, 22 July 2022 (UTC)[reply]
cite document is meant for things that aren't journals and should behave accordingly. The solution can't also be to redirect it to cite web instead of cite journal because it should also not require a url. Headbomb {t · c · p · b} 13:16, 22 July 2022 (UTC)[reply]
Documents should be cited only when published. Unless published as pamphlets, i.e. standalone which would fall under {{cite book}}, they are mostly published as parts of other works, including collections, repositories and websites. The citation should follow the conventions of the including entity, so {{cite web}} seems proper here. The logical treatment would be to delete so-called citation templates that contravene these simple guidelines, or at a minimum to strongly emphasize that editors should not expect support for such templates here if they insist on using them. This page should not waste time every time an editor gets a fancy redirect idea. 50.75.226.250 (talk) 14:53, 22 July 2022 (UTC)[reply]
I agree with Headbomb, a document is not necessarily contained in a journal, and it does not necessarily have a URL. Two CS1 templates that seem close are {{cite report}} and {{cite techreport}}. "Cite report" documentation says

[it] is used to create citations for reports by government departments, instrumentalities, operated companies, etc. Examples include: government printed reports which lack ISSN or ISBN numbers, and reports from major semi-governmental instrumentalities that are freely circulating and available for verification, but which lack a formal ISBN/ISSN publication process.

It isn't spelled out what it is about "cite report" that make it unsuitable for any report, published by anybody, that isn't in the domain of one of the other CS1 templates. If it's a paper report published by the Committee to Use Customary American Units of Measure (which I just made up) why would and somehow manages to satisfy WP:IRS, why couldn't you use "cite report"? Jc3s5h (talk) 15:02, 22 July 2022 (UTC)[reply]
Although all reports are documents, not all documents are reports (technical or otherwise). CS1 definition is narrow, but correct. Published government reports are generally easily available and are usually subject to higher scrutiny before and after publication, at least in countries with some semblance of working democratic institutions. There are specific reasons why government publishers may not care for an ISBN, ISSN or any identifier other than their own, or perhaps an id from a catalog of record which in the US is the Library of Congress. Like published court opinions, government reports are authoritative records, not just reliable ones. 172.254.222.178 (talk) 00:46, 23 July 2022 (UTC)[reply]

Generic title[edit]

Hello, can "Page Title" at the start of a |title= be added to the generic title list. Currently about 25 occurrences. Thanks, Keith D Keith D (talk) 23:04, 22 July 2022 (UTC)[reply]

Retrieved from "https://en.wikipedia.org/w/index.php?title=Help_talk:Citation_Style_1&oldid=1099867580"