Wikipedia talk:Citing sources/Archive 54

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

Archive 50

←

Archive 52

Question about ref names

What does it mean when the name of the ref is :0? I encountered this on the Steven He article and was curious. I cannot find any mention of :0 on the citing sources page. Rusty4321 ^{talk contributions} 23:41, 26 September 2023 (UTC)

It means the reference was added with the visual editor, rather than the source editor. You can change these to something more mnemonic if you like, though be careful to do so for all instances of any given reference you change. I believe there's a tool available to convert them to mnemonic names, though I can't remember where to find it. Mike Christie (talk - contribs - library) 23:48, 26 September 2023 (UTC)

Wikipedia:VisualEditor/Named references. Nikkimaria (talk) 23:49, 26 September 2023 (UTC)

@Mike Christie @Nikkimaria Thank you for responding!

a Rusty4321 ^{talk contributions} 23:53, 26 September 2023 (UTC)

User:Rusty4321, changing this default behaviour has been requested by the community and placed sixth in the 2023 Community Wishlist Survey. Folly Mox (talk) 02:22, 27 September 2023 (UTC)

Citation template warnings?

When I edit Fleetwood Park Racetrack (Special:Permalink/1181853516) and do "Show preview", I get:

Script warning: One or more {{cite report}} templates have maintenance messages; messages may be hidden (help).

Script warning: One or more {{cite book}} templates have maintenance messages; messages may be hidden (help).

Any idea what's going on here? RoySmith (talk) 17:00, 25 October 2023 (UTC)

Follow the help link in those preview messages to learn how to show the attendant maintenance messaging. The maintenance messaging will have a link to the maintenance category where you will find information about the message and what to do about it.

—Trappist the monk (talk) 17:04, 25 October 2023 (UTC)

OK, I did that. Still no joy. RoySmith (talk) 17:16, 25 October 2023 (UTC)

If you now search the article for "CS1" you should find five instances, all with the message "{{cite book}}: CS1 maint: date and year (link)". The link will take you to a page that, in detail, tells you that both date and year have been used (if you didn't get that from the basic message).

You can clear the messages by removing |year= in the cites where |date= have been used. It's redundant as the "date" field will always include the year. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 17:24, 25 October 2023 (UTC)

Yes, and the |year= parameter is deprecated anyway, in favor of the more flexible |date=. So, just stop using |year= at all. [Well, there's technically one remaining use for it in a specific templating circumstance, but it is rare.] — SMcCandlish ☏ ¢ 😼 03:16, 26 October 2023 (UTC)

I'll add that to my laundry list of ways the whole citation system is user-unfriendly. Maybe even user-hostile. The documentation for "year" (at least in {{cite book}}) says, "Year of the source being referenced; use 'date' instead, if month and day are also known". If the intent of that is "This field is deprecated", that's about as confusing a way to say it as I could imagine.

I've always been careful to use "year" when I only have the year and "date" when I also have a month and date. You're telling me I shouldn't be doing that? RoySmith (talk) 14:31, 26 October 2023 (UTC)

|year= is not deprecated; see the documentation. Use of |date= is preferred because for all MOS:DATES-acceptable values, |date= is semantically correct whereas |year= is only semantically correct for years. Using |year=2023 is perfectly acceptable.

—Trappist the monk (talk) 15:35, 26 October 2023 (UTC)

Contradictory. Since |date=2023 is clearly use of a MOS:DATES-acceptable value, there is no meangingful difference between "|date= is preferred over |year=" and "|year= is deprecated in favor of |date=". They are equivalent statements. As one of the principal maintainers of this documentation, if you want it to make sense to anyone but you, and not just lead to pointless feuding, make it clearer that date, as you say, is preferred and thus to be used instead of year, and stop "advertising" year as a parmeter to still use, or the statement "|date= is preferred" is just demonstrably false. It's no wonder I have to clean up so many instances of |year= being used. Just fix the doc. Getting this template system cleaned up in even the smallest ways is like pulling teeth, and it really, really needs not to be. — SMcCandlish ☏ ¢ 😼 16:58, 26 October 2023 (UTC)

Template:Citation Style documentation/date has never used the term 'deprecated'. The term in use is 'discouraged' added at this edit by another editor. Deprecated has a particluar meaning in the cs1|2 world: this thing (function, parameter, whatever) is going to go away. |year= is not going to go away any time in the foreseeable future. |year= has a use and will continue to have a use until en.wiki decides to prohibit YYYY-MM-DD style dates (don't hold your breath). It is possible that cs1|2 might allow CITEREF disambiguation that adds the disambiguator at the end of a YYYY-MM-DD string (2023-10-26a) but until such time, templates using YYYY-MM-DD date formats and requiring CITEREF disambiguation will require |date=2023-10-26 and |year=2023a to support that disambiguation. In the event that we no longer need |year=, getting rid of that parameter will be an uphill struggle that I, for one, do not look forward to.

I have been very public in admitting my inability to write acceptable documentation; in short, I suck at documentation. I have repeatedly asked editors who complain about the cs1|2 documentation to do something to make it better. After all, those who are complaining are typically Wikipedia editors who know how to string together the appropriate words necessary to make complex subjects understandable; surely they have the skills to tweak the documentation. Alas, the documentation wallows in its mediocrity because those editors haven't taken up the pen.

Yeah, I agree, [getting] this template system cleaned up in even the smallest ways is like pulling teeth for the which see {{Section link}}: required section parameter(s) missing.

—Trappist the monk (talk) 18:17, 26 October 2023 (UTC)

I was already the one who pointed out that |year= had a remaining special use case (and yes |year=2003a, for cases of multiple publications by the same author in the same year, is that case, but there must be a better way to do this). That doesn't mean in any way that |year= is advisable/preferred/whatever-you-like-to-say in any other case. It doesn't matter at all whether the documentation right now happens to use the term "deprecated" or "discouraged" or "is not preferred" or what; they all mean the same thing to [nearly?] everyone reading them: don't use this option for that purpose, use this other option instead. That is the entire point here. The |year= documentation is wrong. It directly contradicts the |date= documentation. It is not possible for |date= to be preferred if (for the same kind of use) |year= is not "dis-preferred" in one wording or another. The doc for |year= needs to be rewritten to say that it is specifically for the |year=2023a sort of case, and that the use of it for publication years is otherwise deprecated/discouraged/obsolete/not recommended/whatever in favor of the more flexible |date=; any phrasing at all will be fine, as long as it gets the point across. — SMcCandlish ☏ ¢ 😼 19:10, 26 October 2023 (UTC)

Editor Rjjiii has tweaked the |year= documentation; see this diff.

—Trappist the monk (talk) 22:21, 26 October 2023 (UTC)

Thanks for the ping. Does that make the intended usage of |year= clearer or less clear? Rjjⁱⁱⁱ (talk) 01:00, 27 October 2023 (UTC)

For me, I don't think so. I cannot imagine that |year= will ever go away as |month= and |day= have. I think that |year= should be treated as a fully valid parameter. |year= should not be 'discouraged' nor should |date= be 'preferred'. We should somehow distinguish between |date= and |year=. When all you have or need is the year portion of a publication date, use |year= or |date=; for all other publication dates use |date=. Perhaps both definitions should link to a common note that defines that one condition where both |date= and |year= are required. If we do these things, cs1|2 should be modified so that the module emits an invalid date error message when |year= holds any value that is not a simple year (with or without CITEREF disambiguation) (|year=27 October 2023 should cause an error message). Because a year is a date, |date=2023 will not cause cs1|2 to emit an error message.

—Trappist the monk (talk) 14:31, 27 October 2023 (UTC)

If it's invalid to have both at the same time, I don't see any reason to have both. It should be trivial to analyze the string and determine if it's a full date or just a year (a good first day assignment for an "intro to regex" class). Software should be doing work to make things easier on humans, not humans doing work to make things easier for the software. RoySmith (talk) 14:39, 27 October 2023 (UTC)

I'm pretty sure that I never said that it's invalid to have both at the same time. That you took that meaning from what I have written is yet more evidence that I should not be writing template documentation.

There is a legitimate case for having both |date= and |year= in a single cs1|2 template. When the chosen date format is YYYY-MM-DD, we set |date=2023-10-27. If we also need to disambiguate that year for use with {{sfn}} and the like, we set |year=2023a etc which cs1|2 uses in the rendered template's <cite id="CITEREF<author-surname-list>2023a"> tag.

—Trappist the monk (talk) 15:59, 27 October 2023 (UTC)

That you're putting 2023a in a citation template is, IHMO, just plain broken. I understand the style, having used it myself when a journal wants it. But the citation should describe the thing being cited; the "a" suffix isn't part of that, it's part of the paper/article it's being used in.

In a sane bibliographic management system, I should be able to build a database of citations, and then pick which ones I want to use in a given document. If I cite all three of my own papers from this year, the system should be smart enough to label the first one I use as "Smith 2023a", the next one I mention as "Smith 2023b" and the final one as "Smith 2023c". And when during the course of rewrites, my fourth paper comes out and I want to cite that one before the others, the system should be smart enough to automatically relabel them all on the fly. I was using a system which did exactly that 35 years ago. It's mind-boggling that people are doing that manually today. RoySmith (talk) 16:37, 27 October 2023 (UTC)

In a sane bibliographic management system Umm, Wikipedia is not a bibliographic management system and because Wikipedia is a wiki is far from sane. The cs1|2 templates and the {{sfn}} and {{harv}} templates that make use of CITEREF disambiguators are constrained by the limits that MediaWiki places on Scribunto. Without jumping through hoops, templates and modules cannot see outside of their bounding {{ and }}. If you want something like refer, I suspect that you will have to make your case at phabricator.

—Trappist the monk (talk) 16:53, 27 October 2023 (UTC)

The solution to this problem is almost certainly having some way to tag multiple works by the same author in the same year, that does not operator-overload the basic date-recording functionality in the template. This could be done either by adding (or adding functionality to) a special parameter for this, a way to override CITEREF default behavior, or having CITEREF automatically do something smarter. My gut feeling is that the existing |ref= parameter could be leveraged in some way. But right now, using |ref= can break |sfn= usage, and it's difficult to figure out exactly what CITEREF wants without digging around in the rendered HTML source of the page. One thing I've already done at a few articles with complex citations is look in the source to find what string CITEREF wants to use and manually use it. This has been useful in cases where {{sfn}} citations are in heavy use, but a particular case needs something richer than {{sfn}} can generate, e.g.

<ref>[[#CITEREFDunbar1979|Dunbar (1979)]], pp. 41–42, quoting Kirk (1677) in ''[[Robert Wodrow|Wodrow]] Mss.'' vol. XCIX, no. 29.</ref>

The issue here is that CITEREF is both inflexible (at least as implemented in {{sfn}}) and opaque. If it were easier to see what it is doing and modify what it is doing/expecting, then a lot of more complex citation needs could be solved, and we would probably have a way to not crappify the date parameters just to arrive at something that CITEREF and {{sfn}} can work with. PS: The very fact that the "2023a trick" is even dependent on also having a |date=2023-10-27 date also specified, in that exact format, is itself inherently problematic, because hardly anyone is going to understand that, it's making use of redundant parameters for date encoding, and it forces ISO dates in some citations in articles that have a declared DMY or MDY format, which means other editors are going to normalize them to the declared format eventually and break the citation that depends on |date=2023-10-27|year=2023a (plus also the problem that we don't have such specific dates for various sources anyway; for books we usually just have a year). In short, this is bunch of tail wagging the dog, the code and the rationales behind its particular engineering forcing human editors trying to build an encyclopedia to have to jump through hoops to "satisfy" a robotic system that is supposed to be serving us instead of us serving it. — SMcCandlish ☏ ¢ 😼 03:47, 28 October 2023 (UTC)

The very fact that the "2023a trick" is even dependent on... I may be misunderstanding you, but ISO dates aren't required. You could use |date=2023-10-27|year=2023a or |date=27 October 2023a and either would work for {{sfn|Doe|2023a|p=x}}. It's the year parameter that is required for ISO dates. Rjjⁱⁱⁱ (talk) 04:12, 28 October 2023 (UTC)

Good to know that wasn't a broken as I thought, then. But including a redundant date-specifying parameter and then putting a string like "2023a" that is not a date in it, is still a daft way to disambiguate between same-author, same-year publications cited in the same article. We need a more sensible way to do this. — SMcCandlish ☏ ¢ 😼 06:04, 28 October 2023 (UTC)

Just to say that if you don't like the standard method of disambiguation you can always setup |ref= and use anything you want, see {{harvid}}/{{sfnref}}. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 11:03, 28 October 2023 (UTC)

As I'm saying above, I suspect that |ref= is going to have much to do with eventually resolving the problem, and I make frequent use of it for various purposes. The fact that we have {{harvid}} and {{sfnref}} as more flexible alternatives to {{sfn}} gives the lie to the idea that the code and behavior by {{sfn}} is a "standard" and that it mustn't be touched. There is really no reason not to just replace it with something more robust, that doesn't confusingly abuse a date-specification parameter for disambiguation purposes. — SMcCandlish ☏ ¢ 😼 11:25, 28 October 2023 (UTC)

Harvid and sfnref are not alternatives to sfn, they setup alternative anchor points for use with sfn. I assume the anchor points are created by mediawiki. That the anchor points are created using the relevant author and date parameters, which leads to using disambiguation of the date to solve two or more cites having the same anchor point. It's used due to limitations of the mediawiki software. (I'm happy for Trappist to correct me if I'm wrong with any of that).

Also the method used isn't exactly original, you can find it in many academic articles. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 11:43, 28 October 2023 (UTC)

{{Harvid}} is a redirect to {{SfnRef}}. {{SfnRef}} creates a CITEREF anchor ID:

{{sfnref|Doe|2023a}} → CITEREFDoe2023a

When {{sfnref}} is assigned to the cs1|2 parameter |ref=, Module:Citation/CS1 uses that value for the template's anchor ID:

|ref={{sfnref|Doe|2023a}} → |ref=CITEREFDoe2023a → <cite id="CITEREFDoe2023a">

And yeah, Wikipedia did not invent the alpha character suffix for harvard referencing multiple works by the same author in the same year; here's a google search

—Trappist the monk (talk) 14:11, 28 October 2023 (UTC)

What Wikipedia did invent was (to continue with the theme here) failing to separate data and presentation, in setting up metadata emission for a date like "2023" and then emitting bogus data through it in the form "2023a", by failing to understand that "2023a" is a disambiguation string not a date, and that it is an arbitrary presentation matter for distingiushing between two cites by same author in same year, not part of the citation's intrinsic data. — SMcCandlish ☏ ¢ 😼 00:37, 29 October 2023 (UTC)

Umm, no. {{sfn}} does not emit metadata. cs1|2 templates do emit metadata and when given a disambiguated date do not include the disambiguator in the metadata. In the mess below look for the &rft.date= key:

{{cite book |title=Title |last=Green |first=EB |date=2023a}}

'"`UNIQ--templatestyles-00000016-QINU`"'<cite id="CITEREFGreen2023a" class="citation book cs1">Green, EB (2023a). ''Title''.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Title&rft.date=2023&rft.aulast=Green&rft.aufirst=EB&rfr_id=info%3Asid%2Fen.wikipedia.org%3AWikipedia+talk%3ACiting+sources%2FArchive+54" class="Z3988"></span>

Green, EB (2023a). Title.

Including the disambiguator in the rendered citation's date is consistent with standard Harvard referencing practice and allows readers of printed Wikipedia articles to distinguish Doe 2023a from all other Doe 2023x citations in §Bibliography.

—Trappist the monk (talk) 01:05, 29 October 2023 (UTC)

printed Wikipedia articles: What a quaint idea. RoySmith (talk) 01:10, 29 October 2023 (UTC)

I didn't say {{sfn}} emitted metadata. The <ref>{{cite journal |year=2023a ...}}</ref> used by {{sfn}} emits metadata, and it is incorrect/polluted/false/whatever-term-you-like, since it claims to be a date but "2023a" is not a date. This is a classic bad-idea (in old hacker jargon, bletcherous or bagbiting) form of operator overloading, being done without any regard for the consequences of trying to make one parameter serve two entirely unrelated purposes. It's basically the same as declaring that the |location= AKA |place= parameter for city of publication can now also serve double-duty as an alias of |at= or |page[s]= for location within the source, and triple-duty as an indicator of a headline location about where the events in the source took place (the "New York" in "New York: Two cats were apprehended stealing fresh-caught salmon from the docks today ...."). It's not a sensible way to code these tools, and to the extent that we've done any of it, we need to undo it, even if this requires a bot to go around and patch things up afterward. There must be some other way to resolve "same author, same year" referencing ambiguities, whether that entails adding a new parameter, doing something novel with |ref=, or having something in the code that auto-generates disambiguated IDs like CITEREFMcCandlish2023a using some as-yet unspecified logic. I have faith that our community (even just the more technical slice of it) is competent to come up with a solution that doesn't involving blantantly lying in the metadata that a year of publication is the invalid date string "2023a". Come to think of it, it might be as simple as having code that silently stops emitting any date-related metadata for |year= any time it contains a non-date string like "2023a", as long as a valid |date= is also present (and throwing an error if one is not), and then we deprecate (or whatever term you like better) all use of |year= for date usage, and reserve it for only |year=2023a cite-disambiguation usage with {{sfn}}-style referencing. Though by that point, it might be better called |sfn-year= or |dab-year= or something, with |year= just being retained as an historical alias of it. — SMcCandlish ☏ ¢ 😼 04:23, 29 October 2023 (UTC)

As someone who spends a lot of time trying to correct issue with the current setup this all sounds like a bad idea, especially any attempt to hide the disambiguator. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 11:51, 29 October 2023 (UTC)

I did show in my post above that when a cs1|2 template has |date=2023a, the rendered metadata is &rft.date=2023 so the CITEREF disambiguator does not cause the metadata to be incorrect/polluted/false/whatever-term-you-like.

—Trappist the monk (talk) 14:02, 29 October 2023 (UTC)

Okay. This is working better than I thought, then. The concern was |year=2023a not |date=2023a, but I'm also not able to get &rft.date=2023a out of that, so polluted date metadata is not a concern after all. Just the fact that we confusingly have two date parameters, and the only reason we have the obsolete |year= one is the |year=2023a disambiguation case for {{sfn}}, which really serves no date-encoding need [any longer], only a need for distiguishing target sources for sfn and related templates. It's rather like having a coffee maker and a vacuum cleaner but also building a coffee maker into the vaccuum cleaner for no reason. It seems that the needed functionality could be served by something like a |snf=a parameter, with no date-related strings in it. We could just append that value to the YYYY found in |date=. Or less minimalistically do |sfn-year=2023a if we wanted to make people continue to put in a longer string. If the latter, the current |year= template could be renamed to |sfn-year= (or whatever), with |year= being an alias, but a discouraged one, and deprecated for use as an alternative to |date=2023. I.e., for use only in "2023a" source-disambiguation uses, and should use |sfn-year= anyway. — SMcCandlish ☏ ¢ 😼 16:46, 29 October 2023 (UTC)

Still a no from me, it will just lead to more broken sfn/harv references. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 17:46, 29 October 2023 (UTC)

Well, the minimalist idea |sfn=a would require a bot to update old instances of things like |year=2023a to the new minimalist format (after tweaking {{sfn}}, etc. to recognize it). But the less minmalist idea of renaming the parameter to |sfn-year=2023a and retaining |year=2023a as a discouraged alias for it that is also deprecated for use for regular dates (use |date=2023) would have no effect on sfn/harv, even without any bot cleanup. — SMcCandlish ☏ ¢ 😼 18:19, 29 October 2023 (UTC)

All to accommodate a rarely used date format, and an even rarer usage of that date format with short form refs. A better idea would be to stop the usage of that date format. The use of |date= with disambiguation would continue with or without this, as that is both standard pratice here and outside of Wikipedia and not doing so leads to the reader being left with ambiguity. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 19:37, 29 October 2023 (UTC)

On the topic of it forces ISO dates in some citations in articles that have a declared DMY or MDY format, this again seems totally silly. From my viewpoint, putting ISO dates in the templates makes total sense (and is indeed what citoid and/or VE do). Whether that gets displayed in DMY or MDY format is a display issue and the software should be able to take the ISO date in the template and the formatting directive from {{use mdy dates}} and turn that into the correctly formatted output on the fly. In fact, it appears that it does since Special:Permalink/1174525779 and Special:Permalink/1174525779 display identically, even though one has ISO dates in the templates and the other had those converted to MDY format via Special:Diff/1175426949.

It is mind-boggling to me that anybody would invest time to make those sorts of edits which have zero impact on how the article is shown to an end user. Computers should be doing work to make things easier for humans, not the other way around. Separating the internal format of how information is stored from how it is displayed externally is a concept that goes back to the earliest days of computing. RoySmith (talk) 14:33, 28 October 2023 (UTC)

Reading {{use xxx dates}} templates was added to Module:Citation/CS1 so that editors would not have to fuss with date formats in cs1|2 templates. Yet still, there are editors out there who insist that an article cannot be a quality article if its cs1|2 templates (in wiki text) hold a variety of date formats. I suspect that there is another cadre of editors who wield a user script that formats dates according to {{use xxx dates}} as a way of augmenting their edit counts – like anyone else really cares about edit counts. The user script that I'm thinking of is (last I heard) only partially compliant with the {{use xxx dates}} template.

And, yeah, I agree, the best date format for templates (in wiki text) would be true ISO 8601. We tried to implement a variant (Extended Date/Time Format (EDTF) specification) both here and in citoid but that was ultimately abandoned on the citoid end (phab:T132308).

—Trappist the monk (talk) 15:00, 28 October 2023 (UTC)

Still takes cleanup work either way. Either you have to add a consistent |df= to all the citations, or just switch all the dates to the same format to begin with. Doing the latter makes for fewer parameters and for code that is easier to human-read for not veering back and forth between at least three formats. — SMcCandlish ☏ ¢ 😼 00:37, 29 October 2023 (UTC)

When articles have a {{use xxx dates}} template, |df= is extraneous unless there is a very pressing need for this cs1|2 template to use a format different from all of the other cs1|2 templates. I don't think that I've ever seen an example of that. Mayhaps there are editors who struggle with reading wikitext where different cs1|2 templates use different date formats but I suspect that there aren't many of those kinds of editor. But, if it makes their life easier, I won't object If they run the script to normalize the dates in cs1|2 template. I do object to the editors who normalize date formats simply to increase their edit counts.

—Trappist the monk (talk) 01:05, 29 October 2023 (UTC)

{{Use xxx dates}} can require a consensus discussion first or lead to drama, but maybe that is ultimately the easiest solution. I still run into a lot of |df=, most often being used in cases of something like {{Use DMY dates}}...<ref>{{cite web ... |date=2022-01-04 |archive-date=2022-10-14 |access-date=2023-10-29 |df=dmy}}</ref>. Maybe that is pointless markup, but I keep finding it. One of the searches I typically do when in a cleanup run at a page is for the string "df=". It's always either trying to defy the declared date format at the top of a page for no reason, or it's seemingly being used to make a citation with ISO or MDY dates conform to DMY to go along with the rest of the page's declared DMY. If the first is unconstructive and the second is redundant with the page-top {{use DMY dates}} template, then why do we have |df=? — SMcCandlish ☏ ¢ 😼 16:46, 29 October 2023 (UTC)

The discussions (and their starting dates) that lead to the creation of |df= and auto-date-formatting are:

Help talk:Citation Style 1/Archive 10 § Automatic ISO conversion – 18 December 2015
Help talk:Citation Style 1/Archive 54 § auto date formatting – 11 March 2019

That is why we have |df=.

—Trappist the monk (talk) 17:25, 29 October 2023 (UTC)

That explains the origin, but not why we still have and (decreasingly often) use it. The first of those discussions pre-dates auto-formatting the display (in rendered page for the reader) of dates based on a {{Use xxx dates}} template at the top of the page. I think the second discussion post-dates it, but seems to be dwelling on using the parameter to particularly format individual citations differently, i.e. in ways that conflict with a {{Use xxx dates}} template at the top of the page (not desirable behavior), or in the same way as the page-top template (just redundant, since the page-top template already performs this function today). So, what is the present utility of this parameter? — SMcCandlish ☏ ¢ 😼 18:10, 29 October 2023 (UTC)

Because no one has bothered to suggest that we no longer need it? Here are a couple of cirrus searches for articles that use |df= in cs1|2 templates:

for articles that have a {{use dmy dates}} template: ~43,800 articles (search times out)
for articles that have a {{use mdy dates}} template: ~34,300 articles

These searches suggest that there are more than 78,000 articles with at least one use of |df=. That is too many to just suddenly deprecate. Sure a bot could be written to remove |df= but such a bot runs the risk of being declared WP:COSMETICBOT so removal of these parameters will need to be done some other way.

And then there are the articles that have neither of the {{use xxx dates}} templates:

~31,500 articles (search times out)

What to do about those?

If we are going to consider removing support for |df=, discussion about that should take place at Help talk:Citation Style 1, not here.

—Trappist the monk (talk) 19:12, 29 October 2023 (UTC)

A bot to replace old template code is a pretty common thing. But a good start might be re-documenting |df= as being something to use only in absence of a {{use xxx dates}}, with establishing a {{use xxx dates}} being preferable anyway. To stop further spread of unhelpful instances. — SMcCandlish ☏ ¢ 😼 19:41, 29 October 2023 (UTC)

(edit conflict)

What does that mean: Still no joy? If you've added the correct css to User:RoySmith/common.css you should see the maintenance message following this citation:

{{Cite report |url=https://s-media.nyc.gov/agencies/lpc/lp/1898.pdf |title=Clay Avenue Historic District |last=Dolkart |first=Andrew S. |author-link=Andrew Dolkart|date=April 5, 1994 |publisher=The Landmarks Preservation Commission |location=New York |pages=2-5 |id=LP-1898 |access-date=December 4, 2021 |archive-url=https://web.archive.org/web/20211203234117/https://s-media.nyc.gov/agencies/lpc/lp/1898.pdf |archive-date=December 3, 2021 |url-status=live |editor-last=Pearson |editor-first=Marjorie |editor2-last=Urbanelli |editor2-first=Elisa |year=1994}}

Dolkart, Andrew S. (April 5, 1994). Pearson, Marjorie; Urbanelli, Elisa (eds.). Clay Avenue Historic District (PDF) (Report). New York: The Landmarks Preservation Commission. pp. 2–5. LP-1898. Archived (PDF) from the original on December 3, 2021. Retrieved December 4, 2021.{{cite report}}: CS1 maint: date and year (link)

(Fleetwood_Park_Racetrack#cite_note-:2-5)

—Trappist the monk (talk) 17:31, 25 October 2023 (UTC)

OK, got it now. I do have to say, this is rather a user-unfriendly process. See https://en.wiktionary.org/wiki/no_joy RoySmith (talk) 17:37, 25 October 2023 (UTC)

I know what 'no joy' means but in the context of problem solving, catch phrases aren't of much value because they convey no information that can help get to a resolution. If you were to make the process more user-friendly, how would you do it?

—Trappist the monk (talk) 17:51, 25 October 2023 (UTC)

I had to think about what was wrong here too. The message should say something like "both date and year provided". "date and year" is not meaningful, and makes the editor look for an erroneous date parameter. Hawkeye7 (discuss) 20:21, 25 October 2023 (UTC)

Trappist, to answer your question, this is user-unfriendly is so many ways. In arbitrary order:

You only even see the summary warnings in the classic editor. I almost always use the visual editor, where they're not visible at all.
The way the message is worded, it sounds like there's something broken in the template itself, not in your use of the template; "maintenance messages" certainly doesn't sound like something that should apply to an end user. And then when you get to Help:CS1 errors (assuming you get that far), it's talking about script warnings, and CSS modifications. I looked at that, read a little bit, and just assumed it was meant for the maintainers of the templates, not me.
I've had other errors which show up immediately in the template edit box. For example:
{{cite web}}: |access-date= requires |url= (help); |archive-url= requires |url= (help); Missing or empty |url= (help)

Why could that error show up in a reasonable way, but not this one?

Once you do manage to understand what you have to do and install the required CSS (i.e. up to the point where I said "Still no joy"), what you've got is some error messages basically camouflaged in-line with the references. If they were at least in some big giant font, or otherwise stood out (no, green didn't make them stand out, and I'm not even colorblind), it would have been OK, but I didn't even see them until I was told exactly where to look.
Sort of a corollary to that, it doesn't even tell you which references are the problem. Just "One or more {{cite book}} templates".

That's all I can think of at the moment, but I think it's enough to support my claim. RoySmith (talk) 20:58, 25 October 2023 (UTC)

Replies:

MediaWiki doesn't provide a mechanism for VE to display preview messaging; that is not fixable with Module:Citation/CS1
The way the message is worded, ... which message? Maintenance messages are not errors nor are they warnings. Labeling those messages as maintenance messages was the best we could come up with. We chose to describe non-error messages as maintenance messages to avoid unnecessary alarm. Summary messaging in the preview box is severely handicapped by MediaWiki-imposed limitations; the 'script warning' text is provided by MediaWiki over which we have no control; I would suppress that if I could. Wording of the maintenance messages that appear where the template is rendered is simply the title of the category that collects articles that have a template that emits that particular warning (Category:CS1 maint: date and year in the example template above). If you assumed that something that you read at Help:CS1 errors was meant for the maintainers, how would you improve it so that others don't make that same assumption?
Because a maintenance message is not an error, the decision was taken to suppress those messages without individual editors enable maintenance message display. Were it up to me, all messaging would be visible all the time so that fixes get made. Alas, my view does not agree with consensus.
There has been sufficient pushback against error messaging that big, obvious maintenance messages would bring out the torches and pitchfork so maintenance messaging is editor-optional and uses muted color.
Among the first versions of the summary messaging were those that linked a summary message to the first template to which the summary message applied. But, that mechanism was dropped when it was pointed out that doing so violated the HTML 5 standard so all we can do is say to the editor that somewhere in the article there is at least one of a particular {{cite ...}} template that has an error message and at least one of a particular {{cite ...}} template that has a maintenance message.

Despite all of this, the summary messaging works.

—Trappist the monk (talk) 22:59, 25 October 2023 (UTC)

MediaWiki doesn't provide a mechanism for VE to display preview messaging I don't understand. I gave an example above of such a message. Here's a screenshot of a similar one. RoySmith (talk) 23:24, 25 October 2023 (UTC)

You wrote You only even see the summary warnings in the classic editor. Your summary warnings are my preview messaging – only visible in preview mode when using the 2010 wikitext editor; see the yellow-ish mockup at Help:CS1 errors § Preview messages.

—Trappist the monk (talk) 23:55, 25 October 2023 (UTC)

RoySmith has some points. Even I (and I like to think of myself as verging on a CS1 expert at this point) find some of the wording of the errors/warnings rather opaque ("date and year" instead of "both date and year provided" is a good example but just one). And when it comes to font size and color of internal editorial messaging that is never shown to end readers or even to editors who do not jump through hoops to enable it, there will be no "torches and pitchforks" in making these messages easier to find in the ref listing. Another issue is that some of the errors/warnings do not make it clear which citation in particular has the problem, necessitating that you manually go through every citation one by one until you identify the issue, which in a long article can take half an hour or more in some cases; very frustrating. I've forgotten exactly what cases that happens with but will try to remember to make a note of it here (or more likely at WT:CS1) next time it happens to me. — SMcCandlish ☏ ¢ 😼 03:16, 26 October 2023 (UTC)

Alas, there have been torches and pitchforks risings in the past over error messaging. At cs1|2 we are (I am) eager to avoid those risings because they are so painfully dramatic and accomplish so little.

Readers likely don't care about maintenance messaging so they are hidden by default. If you know a better way to make these messages available to editors, tell us.

some of the errors/warnings do not make it clear which citation in particular has the problem You will have to provide evidence to support that claim. As one of the final steps taken in rendering a cs1|2 template, Module:Citation/CS1 appends a list of error and maintenance messages, along with error, maintenance, and propery categories to the rendered citation. Show me where that is not happening.

—Trappist the monk (talk) 15:35, 26 October 2023 (UTC)

If you know a better way to make these messages available to editors, tell us how about instead of a link to a complicated page filled with cryptic instructions explaining what steps you need to do to find the error messages, just show the error messages. You've already explained that there are limitations in VE that make that impossible, so open a phab ticket to get the required changes to VE to make it possible. Subscribe me to the phab ticket and I'll add my voice.

I've been a software developer all my life. I understand that developers sometimes get tunnel vision about how to do things because they know the system so intimately it's impossible for them to step back and see things how a user sees things. I'm a user. I don't want to know about CS1 vs CS2. I don't want to know about CSS. I don't want to know about the internal architecture of the editor. I just want the system to tell me when I've done something wrong. Or even better, to prevent me from doing it wrong in the first place. With all due respect, if at this point in the discussion you're still coming up with "Show me where that is not happening", you're just not paying attention. RoySmith (talk) 15:58, 26 October 2023 (UTC)

You are the one who told me that VE does not show the preview messages. I don't use VE and never will so I really am wrong person to start a discussion at Phabricator. Still: phab:T349851.

Tracked in Phabricator
Task T349851

—Trappist the monk (talk) 17:40, 26 October 2023 (UTC)

@SMcCandlish You may be thinking of the message generated when a cite uses the same field more than once, which is quite unhelpful.

As to the help pages they can be editted by any editor wishing to make them more user friendly, no editor is required to edit. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 16:20, 26 October 2023 (UTC)

In theory, sure. In practice, I find these pages strongly gake-kept by one or two editors. My attempts to improve them are usually reverted. So, it seems more practicable to raise discussion about problems until there's sufficient consensus pressure to effectuate a change, even if that takes a long time. PS: I think you're right about the message type; what's coming to mind is cases when there are two aliases of the same parameter in use in the same template. These can take a very long time to track down in a big article, and it would be vastly more helpful if the warning/error identified the problem citation in particular, the way most such cite problems are flagged. — SMcCandlish ☏ ¢ 😼 16:25, 26 October 2023 (UTC)

Writing help documentation is unfortunately not a priority for many editors.

P.S. Not come across that particular issue, hoping it stays that way. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 16:37, 26 October 2023 (UTC)

(edit conflict)

This kind of message?

Warning: <page> is calling Template:Cite ... with more than one value for the "<parameter name>" parameter. Only the last value provided will be used.

{{cite book |title=Title1 |title=Title2}}

Title2.

—Trappist the monk (talk) 16:47, 26 October 2023 (UTC)

Yeah, I think that's what I was thinking of, and it sounds like we're stuck with it. — SMcCandlish ☏ ¢ 😼 03:26, 28 October 2023 (UTC)

About "MediaWiki doesn't provide a mechanism for VE to display preview messaging", I wonder if that will be affected by the transition to Parsoid for all pages/all editors. Has anybody checked? WhatamIdoing (talk) 01:40, 28 October 2023 (UTC)

I don't know what parsoid is. Perhaps this question is better asked at the phabricator ticket?

—Trappist the monk (talk) 14:11, 28 October 2023 (UTC)

ISBN RfC

FYI

– Pointer to relevant discussion elsewhere.

Please see: Wikipedia:Village pump (policy)#RfC: Standardizing ISBN formatting (and an end to editwarring about it) — SMcCandlish ☏ ¢ 😼 07:09, 31 October 2023 (UTC)

Changing the "year" parameter documentation

I updated the documentation to make the usage of |year= more clear,[1] but it seems there was not consensus for its previous status as "discouraged". Is this closer to the expected usage:

Here is how the formatting renders:

year: Year of publication. Do not use in combination with the |date= parameter, unless both of the following conditions are met:
1. Shortened footnotes target multiple citations with same last name and year of publication. (This situation necessitates a CITEREF disambiguator, usually a lowercase letter suffixed to the year.)
2. The |date= format is YYYY-MM-DD. (This format prevents the addition of a disambiguating letter to the year.)

I'll hold off making this change to the documentation because it changes rather than clarifies the existing advice. Rjjⁱⁱⁱ (talk) 01:23, 29 October 2023 (UTC)

My personal feeling on this particular edge case is that either of the following two options is cleaner than the proposal:

Remove the specifics from |date= and just use the sfn-disambiguating |date=2013a etc.
Use |ref= to set the disambiguator manually, and add text like Cited as Rjjiii 2013a after the full citation.

Folly Mox (talk) 04:59, 29 October 2023 (UTC)

Oh, great, another "discouraged" parameter that the maintainer of the citation templates will likely eventualy declare to be "deprecated" and then remove altogether, breaking all my software. FWIW, my preferred usage of these parameters is to use year= when the date consists only of a year, and to use date= when there is more than a year in the date. I will revert you and cite CITEVAR if you try to change this usage. It is a consistent style, I like it, and I am not going to change it (because I cannot because I have legacy software that does the same thing that I cannot update). —David Eppstein (talk) 06:57, 29 October 2023 (UTC)

If you software does already understand |date=, which is what you seem to be indicating, then why would you put "2023" in |year=? — SMcCandlish ☏ ¢ 😼 07:13, 29 October 2023 (UTC)

It understands date=. It generates year=, when it can. What is the point of arguing about long-ago and now-unchangeable design decisions? The point is they cannot be changed, and yet the citation templates keep churning in backwards-incompatible ways that break things, without any compensating benefit. —David Eppstein (talk) 07:33, 29 October 2023 (UTC)

What tool? What efforts have been made to see if someone can update or replace it? "Some editor has an obsolete tool" doesn't equite to "unchangeable" and "cannot be changed", but this community is pretty good at coming up with ways to fix things like tools that are aging poorly. — SMcCandlish ☏ ¢ 😼 19:39, 29 October 2023 (UTC)

Put full dates in |date= and put years in |year=. Simple. Documentation that disagree with this is simply documentation that is wrong. Headbomb {t · c · p · b} 19:22, 29 October 2023 (UTC)

Nah, year is a subset of date, and |date= handles a year, meanwhile |year= serves no suriving purpose but |year=2023a citation disambiguation. — SMcCandlish ☏ ¢ 😼 19:39, 29 October 2023 (UTC)

|date= also accepts alphabetic year disambiguators, which the {{harv}}-{{sfn}} template families can also read. I think the documentation is just outdated? Folly Mox (talk) 20:52, 29 October 2023 (UTC)

Re "serves no suriving purpose": Incorrect. year= serves the "suriving purpose" of not breaking all of the citations in the history of our articles (which cannot be changed because they are in the history) and of not breaking legacy citation-generation software. —David Eppstein (talk) 21:06, 29 October 2023 (UTC)

Agree with this. We can say whatever makes sense about how to use |year= going forward, but backwards compatibility demands it stay a valid parameter. Folly Mox (talk) 21:28, 29 October 2023 (UTC)

No one suggested disabling the parameter; this is a silly red herring. — SMcCandlish ☏ ¢ 😼 05:10, 30 October 2023 (UTC)

Let's just accept that both can peacefully coexist next to each other and be used for formatting year-only dates? The only major thing to point out seems to be that (rare exceptions excepted) both should not be used next to each other in the same cite entry. Gawaon (talk) 19:51, 29 October 2023 (UTC)

That I can agree on. —David Eppstein (talk) 21:07, 29 October 2023 (UTC)

I will go ahead with changing the documentation unless there are any specific issues with wording. The above posts seem to confirm the lack of consensus for "discouraged". Rjjiii (ii) (talk) 00:42, 3 November 2023 (UTC)

Approximate source date

When the source for the details of an event is a poster/flyer or a webpage serving as its online version its publication date often isn't stated but may be suggested to within a day or two from another source (newspaper articles/announcements or social media posts mentioning the event but with less detail). How is the approximate/probable/possible date indicated in the citation using VirtualEditor and source editor? Mcljlm (talk) 22:07, 1 November 2023 (UTC)

Mcljlm, if I don't know the day I'll use the month and year, and if I don't know the month I'll just use the year. Only if I don't know the year will I start estimating or approximating, and usually only to give an idea how many decades / centuries later a work was written than the events it describes. Folly Mox (talk) 00:16, 2 November 2023 (UTC)

Isn't it possible Folly Max to do something which results in a specific date appearing in square brackets and/or with a question mark? Mcljlm (talk) 01:56, 2 November 2023 (UTC)

You can always use "c." to mean Circa, e.g. "|date=c. November 2023" is the approximate date of this post. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 02:04, 2 November 2023 (UTC)

Mcljlm, to answer your specific formatting question, no, neither the CS1|2 templates nor the vcite series have a |date= parameter that will produce that format of output. You can always use manually formatted citations if displaying an approximate date with square brackets and question mark is important for you. Folly Mox (talk) 03:28, 2 November 2023 (UTC)

I'd be grateful for an example Folly Mox showing me how that can be done. I'm not certain I understand. Mcljlm (talk) 03:38, 2 November 2023 (UTC)

Sure; I'm not sure how to do formatting changes in the VisualEditor (I imagine it's highlight and tap an option, like in word processors, but in the source editor you would write something like:

<ref>[https://example.com/undated-announcements.html "Event announcement webpage."] [3 September 2023?]. ''Event Announcement Central''. Accessed 3 November 2023.</ref>

That will produce a citation that looks like this:

"Event announcement webpage." [3 September 2023?]. Event Announcement Central. Accessed 3 November 2023.

See Help:Wikitext for more manual formatting information. Folly Mox (talk) 04:03, 2 November 2023 (UTC)

Thanks Folly Mox. I'll try to use that later today. Mcljlm (talk) 04:12, 2 November 2023 (UTC)

It worked Folly Mox. I'd like to add an already created archived URL since the the currently live URL is likely to die in a few years if not this. How can I include it? Mcljlm (talk) 21:26, 2 November 2023 (UTC)

{{Webarchive}}. — SMcCandlish ☏ ¢ 😼 08:44, 3 November 2023 (UTC)

How SMcCandlish do I use that in the example Folly Mox gave? Mcljlm (talk) 11:57, 3 November 2023 (UTC)

Mcljlm, fill out the |url= and |date= parameters as described in the documentation for {{Webarchive}}, and insert that code, including curly brackets, after the "accessed on" date, and before the closing </ref> tag. Folly Mox (talk) 12:38, 3 November 2023 (UTC)

Actually, since I'm bad at explaining things, I made the edit to show you the syntax. Folly Mox (talk) 12:45, 3 November 2023 (UTC)

Thanks to both of you SMcCandlish and Folly Mox. Mcljlm (talk) 13:43, 3 November 2023 (UTC)

Talk:Jill_Ovens#WP:CITESTYLE

A discussion on what is and isn't different CITESTYLE, your input is welcome. Gråbergs Gråa Sång (talk) 15:38, 21 November 2023 (UTC)

Not linking to a copyvio

Nemo bis being 'reasonable certain' that it's not copyvio is at odds with WP:ELNEVER and other copyvio policy that say you must have no reason to believe it's copyvio. -- LCU ActivelyDisinterested «@» °∆t° 15:32, 7 December 2023 (UTC)

Can you explain in what circumstances you would be "reasonably certain" it's not copyvio while having a reason to believe it's copyvio, or vice versa? Are you saying that your change would make more link additions fall afoul of this guideline, or less? It's not clear to me which language is stricter.

If there's a difference, it would be useful to clarify which version actually reflects consensus, considering that this page's phrasing is apparent consensus since 2008, while the other language is more recent. Nemo 15:48, 7 December 2023 (UTC)

If a source was of a kind the editor doesn't usually use, the editor may not have any idea if it is of a type that is commonly a copyright violation. If the editor hadn't come across some indication that it is a violation, under the "no reason to believe" criterion the editor could use it. But under the "reasonably certain" criterion the editor would be obliged to conduct some sort of investigation before using it. Jc3s5h (talk) 16:35, 7 December 2023 (UTC)

If you felt there could be a chance that the content is copyvio but you don't think that chance is reasonable, then the current wording says it's ok to link to it. This is wrong the standard, if you have any concerns (even if you feel they are unreasonable) then you shouldn't link to it.
The wording here is using a different weighting of responsibility than the policy pages for copyvio, which is why I imported the wording from WP:ELNEVER. -- LCU ActivelyDisinterested «@» °∆t° 17:00, 7 December 2023 (UTC)

As to consensus the policy of WP:COPYVIO and it's legal requirements outweigh a guideline. -- LCU ActivelyDisinterested «@» °∆t° 17:02, 7 December 2023 (UTC)

I think the current wording is fine and there is no need to change it. We can't expect unreasonable things from editors. Gawaon (talk) 18:16, 7 December 2023 (UTC)

The policy requirement is that a link should be excluded unless there is certainty that it's not copyvio, this doesn't place any greater burden on editors. The only difference is changing "if you're almost certain it's OK" to "if you're almost certain it's not OK".
Again, regardless of the wording here, editors are required by policy to follow that practice. -- LCU ActivelyDisinterested «@» °∆t° 20:57, 7 December 2023 (UTC)

The important thing is that, as long as you're reasonably certain, it's OK. Which is what this page already says. I don't think that "almost certain" and "reasonably certain" mean the same thing. Or do you think that someone who's "almost healthy" is "reasonably healthy"? Gawaon (talk) 21:25, 7 December 2023 (UTC)

One issue here is that a link can be non-copyvio in and of itself (because it is fair use, for instance as part of a reading list for a university course) and yet unusable by us (because that fair use does not apply to us and we are unwilling to make our own claims of a different fair use for such links). We should not link these, and we should not change the wording into something that would seem to allow linking them. —David Eppstein (talk) 17:10, 7 December 2023 (UTC)

That wouldn't be covered by the current wording and possibly not by the wording from ELNEVER. Do you have an alternative? -- LCU ActivelyDisinterested «@» °∆t° 17:37, 7 December 2023 (UTC)

The copyright violations policy states "Copyright-infringing material should also not be linked to." I read that as meaning that if the editor believes a page that might be linked to contains copyright violations, it should not be linked to. The criterion is not "if some of the material on the page about to be linked to were copied to a Wikipedia article, it would be a copyright violation". If it appears material was copied into the potentially linked-to source is fair use in that context, it is not a copyright violation and we can link to it, even if the same material in a Wikipedia article would not be fair use and would be a copyright violation. Jc3s5h (talk) 18:26, 7 December 2023 (UTC)

Sounds plausible. Fair use is, by definition, not a copyvio. Gawaon (talk) 18:43, 7 December 2023 (UTC)

That's also my understanding of the law. Nemo 18:49, 7 December 2023 (UTC)

It is not my understanding. Fair use by us that we properly declare to be a fair use is not a copyvio, but is highly constrained by our internal requirements for fair use. Fair use by someone else is not relevant for how we use something. The fact that someone made a fair use claim on certain material does not throw it open to public domain for the world; it only legitimizes their own use of that material, not anyone else's. Using it in ways not part of that fair use claim can be and often is copyvio.

We should not link to material for which the use of that material as a link from Wikipedia would be a copyright violation. The existence of some other non-Wikipedia use of the same link does not make Wikipedia's use any less of a copyright violation. For instance, we should not link to sci-hub, because it is widely agreed that sci-hub links are copyright violations, even if we find someone outside Wikipedia who also links to sci-hub but justifies them as fair use. For the same reason we should not link to the web site of a university course that makes copies of readings available to its students, which are copyright violations for us, even if making readings available to course students is fair use. Anything else is making excuses for piracy.

The only links we should make to public copies of copyrighted references are links where we can be reasonably certain that the publisher or author has licensed the material for free reading or has provided a copy free to the public. Archived copies of formerly-free copies, showing their provenance from a free copy are ok. Random copies on other sites of unclear provenance are not. —David Eppstein (talk) 21:23, 7 December 2023 (UTC)

Uh, "fair use" is actually a well-defined term. Just because somebody says "sci-hub is fair use", doesn't make it so. Gawaon (talk) 21:27, 7 December 2023 (UTC)

Someone can easily say that their link to sci-hub is not contributory infringement because they have a legitimate fair use to the linked material. That does not cause sci-hub itself to be fair use, but (the point you are missing) it also does not open the same material to copyright-free access by anyone anywhere else. —David Eppstein (talk) 21:29, 7 December 2023 (UTC)

Well, "That does not cause sci-hub itself to be fair use" is the important piece here. Since it isn't, we wouldn't link to it. End of story. Gawaon (talk) 21:43, 7 December 2023 (UTC)

I add to Gawaon's comments that just because somebody says ____ is not fair use, doesn't make it so, either. Fair use is what a court declares, and what we "we properly declare to be a fair use" is irrelevant. You don't have to declare whether something is fair use for it to be fair use. Our NFCC paperwork is for our own internal convenience; it is not legally necessary.

Also, as a side note, ELNEVER is irrelevant, as the Wikipedia:External links guideline is about ==External links==, not about citing sources in the ==References==. See Wikipedia:Copyrights#Linking to copyrighted works ("LINKVIO") for the relevant rules. WhatamIdoing (talk) 22:30, 7 December 2023 (UTC)

When Wikipedia links to a source, Wikipedia is not using the words of the source, just bringing attention to the source. There is no problem with linking unless the source contains copyright violations. Jc3s5h (talk) 21:52, 7 December 2023 (UTC)

There is a problem with linking if we are linking to a source whose public availability is a copyvio, even if the people who made the link available could plausibly claim that they have an unrelated fair use. We should never do that. —David Eppstein (talk) 23:00, 7 December 2023 (UTC)

Yes you're it's only a problem if there isn't certainty over the copyvio issue. -- LCU ActivelyDisinterested «@» °∆t° 20:58, 7 December 2023 (UTC)

Semi-protected edit request on 25 December 2023

This edit request to Wikipedia:Citing sources has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

i want to be wikipedia editor. Qaisar Hussain1 (talk) 10:02, 25 December 2023 (UTC)

Congratulations, you already are one! Gawaon (talk) 14:07, 25 December 2023 (UTC)

What to do if original website was replaced by predatory dangerous website

What is the easiest way to modify the "cite web"? See example of what I did [2]. Do not click on link I replaced! But obviously it is not a good way. And there are several dozens of links to this website - Altenmann >talk 06:20, 15 February 2024 (UTC)

@Altenmann, I believe that you are looking for |url-status=usurped. See the options in Template:Cite web#URL if you want to read more about it. WhatamIdoing (talk) 06:50, 15 February 2024 (UTC)

|url-status=unfit. — Archer1234 (t·c) 06:51, 15 February 2024 (UTC)

url-status=usurped worked great in George de Godzinsky, thanks! It made the original link invisible. - Altenmann >talk 06:57, 15 February 2024 (UTC)

FWIW, here is a link to the section of the {{cite web}} documentation where all of the supported values for |url-status= are explained: Template:Cite_web#csdoc_urlstatus — Archer1234 (t·c) 07:05, 15 February 2024 (UTC)

How to cite an archived EBSCO source?

Reference 9 in Special:Permalink/1193884301 is:

Slone, George B (September 2015). "Sloane's Column: American Bank Note Co. – Centenary". U. S. Stamp News. 21 (9): 21–22. ISSN 1082-9423. Archived from the original on December 8, 2023. Retrieved December 8, 2023 – via The Wikipedia Library.

Clicking on the url= link gets me to the wikipedia library page for that document, with a "PDF Full Text" link that works properly. The problem is, the archive-url= link is farshtunken. When you click on it, you get to what looks like a correct archive of the original but a few seconds later that's replaced by a EBSCO login screen. I don't know if this is EBSCO's fault, or IABot's fault, or archive.org's fault. But, is there some way to make this work right? RoySmith (talk) 03:36, 6 January 2024 (UTC)

I don't think this answers your question about how to archive these links, but see User talk:Citation bot § Should not remove via=The Wikipedia Library on cite encyclopedia. As the outcome of that discussion, I think instead of using a |url= parameter with an EBSCO link, it would be better to do the following:

Look at the EBSCO url
Instead of |url=whatever, use |id={{EBSCOhost}}
Fill in the first (unnamed) parameter of the EBSCOhost template with the number in the AN= part of the EBSCO url
Fill in the |dbcode= parameter of the EBSCOhost template with the value of the db= part of the EBSCO url

In this case, that would give you a link looking like EBSCOhost 109018814 in the citation, freeing up the url parameter for something more archiveable. —David Eppstein (talk) 07:28, 6 January 2024 (UTC)

OK, that seems to work, at least as far as generating a usefully clickable link and preventing IABot from producing a broken archive entry. It wold be nice if there was a way to actually get this archived, but this is at least an improvement. Thanks. RoySmith (talk) 14:30, 6 January 2024 (UTC)

User:Citation bot does a lot of good work subbing out nonfree URLs in favour of identical stable identifiers (chiefly DOI) in order to prevent situations like this, but I sometimes wonder how many of Internet Archive's eight hundred billion plus webpage snapshots are variations of "you must be logged in to view this content", "this content no longer exists at this address", "you have reached your viewing limit for this book", etc. User:GreenC may have information on what Internet Archive does to identify these non-content snapshots and if they have any plans to deal with them (if not, apologies for the ping). Folly Mox (talk) 15:07, 6 January 2024 (UTC)

User:RoySmith: gets me to the wikipedia library page for that document, with a "PDF Full Text" link that works properly - that's true, but only because you are logged into your library account. Try it in an incognito window ie. logged out doesn't work. This is a subscription site, archive providers won't be able to capture it. The go-to place for subscription links is archive.today but they appear to not support the Wikipedia Library: [3] -- GreenC 17:17, 6 January 2024 (UTC)

Fine style point with "Citations" and "Works cited" subsections

Hello. Presently, my preferred style for articles is to have a top "References" heading, with "Citations" consisting mostly of shortcites, and "Works cited" containing the works those shortcites point to. Possibly, a "Further reading" top heading also.

But—I often find it redundant when a work only has one shortcite pointing to it, so my natural inclination is to have the full citation in the {{Reflist}} alongside the shortcites to works that are cited multiple times, as one can presently see on Zhuangzi (book). Do other editors prefer that all works go in the latter section, regardless of how many times they're cited? My preference is not strong, but I could see a strong preference the other way. Remsense留 02:13, 10 January 2024 (UTC)

Predominant practice (in articles with consistent citations, and which are regularly maintained) seems to be to have the full citation be in your "Works cited" section only when cited multiple times. There's no point making a reader click twice to get to the citation details if this is not effectively necessary due to the work being cited repeatedly and needing shortened footnotes for that (to avoid repeating the entire citation mutiple times). The majority of our editors (especially those using VisualEditor) are never going to put a one-use citation manually at the bottom of the page and use {{sfnp}} or <ref>{{harvp|...}}....</ref> to refer to it, so trying to impose that structure is futile. PS: Using three headings for this is redundant; it is sufficient to have ==References== for the entirely inline cites and the shortenend footnotes, and below that a ===Sources=== or ===Bibliography=== (not advised for a bio of an author!) or ===Works cited=== for the long-form citations that are reused. Some editors even omit that subheading and simply put the reused long-form ones between a {{refbegin}} and {{refend}} right below the {{reflist}} or <references>. — SMcCandlish ☏ ¢ 😼 03:08, 13 January 2024 (UTC)

sfn/harvnb or sfnp/harvp

@SMcCandlish: I don't think the {{harvnb}} or {{sfn}} templates are meant to look like the output of the {{citation}} template (CS2-style). They seem to have evolved from {{harv}} which provided nearly Harvard-style in-text citations normally found in parentheses.[4] {{sfn}} places that instead into a footnote. {{sfnp}} was made to give a more consistent presentation (the editor doesn't say if they mean with APA footnotes, Harvard full citations, {{citation}}, or CS1 full citations but all would be true).[5] It looks like there was once a plan to update to {{sfn}} to {{sfnp}} but a fork resulted instead.[6]1 below this

I personally use "sfn" examples because it's so widely used, but have left "sfnp" on the page because there's no policy reason to reason to prefer it (that I know of; there are many policies). Rjjⁱⁱⁱ (talk) 20:43, 13 January 2024 (UTC)

{{Sfn}} and {{harvnb}} are so widely used simply because they were first (and {{sfn}} has a shorter name), and they're consequently mentioned in more documentation. The solution is the clean up the documentation. :-) What they do is output like "Smith 2020, p. 97". You're right about CS2 {{Citation}}; I had mis-remembered what this disused template's output was. Anyway, WP:CITESTYLE says to use a consistent citation style throughout the page, and {{sfnp}} and (where actually needed) {{harvp}} are the templates in that family that will actually do this, with "Smith (2020), p. 97" output that matches the "Smith, Janet (2020). Things and Stuff. London: Big Book Company." output of the full-length citation. Recommending the consistent ones is something we should have done ages ago, but it just kind of slipped under the radar. {{Sfn}} really shouldn't be used except in articles with Vancouver system citations or some other odd-ball format with dates without parentheses/round-brackets around the years, and the ratio of articles using such non-CS1/CS2 citations goes down over time (maybe even the raw headcount of them does, too, as the rate of editorial shifting to CS1 probably outstrips the creation of new articles in manually-enforced off-site citation styles, which was mostly a 2000s obsession). — SMcCandlish ☏ ¢ 😼 21:01, 13 January 2024 (UTC)

What's the problem in using sfn together with CS2-style citations? They seem to play together well. Gawaon (talk) 03:23, 14 January 2024 (UTC)

There are none - both harvnb/sfn and harvnp/sfnp are legitimate citation methods which are compatible with CS1 or CS2 references. Changing between types is covered by WP:CITEVAR (i.e. obtain consensus before changing an established style).Nigel Ish (talk) 17:06, 14 January 2024 (UTC)

Proposed amendment regarding links/IDs

This guideline currently states that A citation ideally includes a link or ID number to help editors locate the source. I suggest amending it to be more direct, along the lines of If a source is available online and/or has an ID number, those links and identifiers should be included in the citation.

The equivocal language of the current wording makes sense to a degree: some of the best sources are not available online, and some do not have even an OCLC to help track them down. But sources increasingly can be found online, as they are increasingly published digitally or scanned. If a source has a URL or a DOI, I think the default should be to expect its inclusion. Even if it has only an ISBN or an OCLC, those should be expected too. And if it has none of those identifiers, the proposed wording would still ensure that citing the source remains fully appropriate. --Usernameunique (talk) 00:51, 21 January 2024 (UTC)

I would oppose this proposal as written, although there might be a way to incorporate the intent. One major issue is a potential conflict with WP:COPYLINK, since "available online" would include illegitimate copies. Another is the vagueness of "ID number" - some of these are more useful than others, and we want to avoid piling on ones that are less useful. Nikkimaria (talk) 01:10, 21 January 2024 (UTC)

I would also strongly oppose mandating ID numbers. There are certain ID numbers that we currently frequently include, like s2cid, that I think are mostly useless spam and would be better omitted. OCLC and ISSN are again almost always useless noise. And I agree with Nikkimaria that wording encouraging direct source links to, say, sci-hub, would be inappropriate. —David Eppstein (talk) 01:26, 21 January 2024 (UTC)

I agree with both of you: that is to say, links should be cabined to legitimate sites, and not every ID number need be added (personally, I add only those that are on a work's copyright page, such as an ISBN or LCCN, and add after-the-fact IDs, such as an OCLC, only if the former are missing). But I think those caveats can be ably dealt with in either a footnote or the text that follows. --Usernameunique (talk) 01:32, 21 January 2024 (UTC)

Troublesome reference link

Not sure if this is the right place to ask, since this is more a technical external link issue than it is a referencing issue, but...

I cleaned up a reference in the article Who Knows Where the Time Goes? (ref #3, the Financial Times article) and added an URL accessed through a Google search result. When I used the link in the search results page, it went right to the correct page with no problem. But now, when I try to use the link in the Wikipedia article, it sends me to a "subscribe to FT" page. Is there any way to manipulate the URL so that it works on Wikipedia? Or is this a paywall mechanism where the FT website decides who gets in depending on where the query comes from? Any insights appreciated. —ShelfSkewed Talk 07:02, 28 January 2024 (UTC)

That sounds like a paywall mechanism, and I'd guess that it is specific to you. Some websites detect how many articles you've read recently and prevent subsequent ones. If you need to access the source yourself, then it might be worth trying Wikipedia:The Wikipedia Library, but if you are concerned about readers (99.7% of whom won't try to read any refs), then I wouldn't worry about it. It might work just fine for them as it is. WhatamIdoing (talk) 08:02, 28 January 2024 (UTC)

Perhaps that's it, and in any case another editor has addressed the issue by adding an archive link that works. Thanks all! —ShelfSkewed Talk 15:15, 28 January 2024 (UTC)

I've encountered this with the paper: I think it allows you to view one page for free, maybe in a given period, perhaps a couple more pages over a longer period. But as the earlier reply suggests, most users probably aren't returning readers, and the new link will hopefully solve the problem (I'm not sure about the netiquette, but I won't tell). Quantist (talk) 22:23, 29 January 2024 (UTC)

Require in-text attribution where reputable authorities differ.

Too many Wikipedia pages are a mess, with erroneous assertions being presented as statements of fact qualified only by footnotes to which few readers probably pay attention anyway ("It was online so it must be true" being only a dumber rendition of the similarly naive "It was in a book so it must be true").

Where there is reasonable doubt about a claim or where multiple reputable sources disagree, in-text attribution should be a requirement: "Gubbins says (a); Muggins says (b)." To present both (a) and (b) as facts differentiated only by footnotes is nonsensical, and to offer just the one when there are valid grounds to query it is even worse. Let's say who said what, and not just assert it as fact when it isn't: burying a source in a footnote doesn't nullify a falsehood. Quantist (talk) 12:24, 27 January 2024 (UTC)

If there are differing view points backed up by reliable sources, then there is already policy to cover this, see WP:INTEXT and WP:ATTRIBUTEPOV. But note the caution about inadvertently making statements not neutral by doing so though, per the example "Humans evolved through natural selection" not "Charles Darwin says that humans evolved through natural selection". Where the majority view is clear, and backed up by independent reliable sources, attribution can cause a WP:FALSEBALANCE. -- LCU ActivelyDisinterested «@» °∆t° 13:28, 27 January 2024 (UTC)

Indeed, I understand that there's a tightrope to be walked to avoid false equivalence of sound and crackpot propositions, but on that score I'd rely on the general good sense of the community. I was trying to tackle that in my outline of when such a requirement should operate: the threshold for "reasonable doubt" can be a high one where well-founded findings exist, but statements are too often based on little more than speculation (which may or may not be well-reasoned) on the part of some putative authority, or occasionally on misinterpretation or misrepresentation of sometimes inconclusive evidence.

For the record, I'm not an "alternative facts" type by any means, I'm very much for traditional scholarly process, but to me part of that is not to state a questionable finding as a fact, though it may properly be presented as a finding prefaced by an attribution of authorship. I think there's a wider discussion to be had too about "verifiability": being able to cite a seemingly authoritative source for an assertion doesn't prove it's true, as verification implies: where there is legitimate uncertainty and no scientific or scholarly consensus (which of course doesn't have to be unanimous), only saying that an author offers a given finding is demonstrably true. A supporting source does not confer verifiability: I can come up with reputable supporting sources for all manner of nonsense - even the best sometimes get it wrong when they stray from their core field or from scholarly objectivity, or even when they miss an element from a calculation (I can think of two such readily-demonstrable bloopers by leading scholars I rate very highly indeed). Quantist (talk) 16:12, 27 January 2024 (UTC)

As I'm sure you can imagine Wikipedia attracts all kinds, so these questions always attract some caution. As to verification on Wikipedia it is that the content in Wikipedia is backed up by reliable sources, so it's not used here as you might expect elsewhere. You may be interested in WP:EXPERT which has some advise on how Wikipedia differs from scholarly and scientific publishing.
Many editors who are writing articles will be people interested in the topic rather than experts in the field, so editors with expert knowledge can be invaluable in adding nuance missed by others. This would certainly include attribution of positions that other editors mistakenly took as being the consensus. This shouldn't be taken to say editors have no knowledge in the areas they write, but someone with a degree and someone well published in the field will have different levels of understanding. -- LCU ActivelyDisinterested «@» °∆t° 19:55, 27 January 2024 (UTC)

Yes, I just think it's a misnomer that conveys an unfounded degree of confidence: offering a reputable source alone doesn't confer reliability, which is why I think the attribution should be upfront when the uncertainty justifies it. In practice editors make that call all the time, some assertions warranting attribution, others not: I'm essentially just proposing that it should preface the assertion rather than being appended as a footnote to a statement that may not be as factual as its form might suggest. Quantist (talk) 20:58, 27 January 2024 (UTC)

Putting the attributions in body text rather than in footnotes risks running afoul of our deprecation of in-text citations. —David Eppstein (talk) 21:49, 27 January 2024 (UTC)

Doubtless so. So I suppose I'm questioning that deprecation. I think it's a gross error that devalues the information that does merit presentation as generally-accepted fact rather than the finding of a given authority (which may be widely accepted even if consensus as so far lacking - and that broad agreement too can be noted where it applies). The unintended consequence of relegating attribution to a footnote is ironically to offer nonsensical claims just the spurious authority that the policy seeks to avoid. Quantist (talk) 05:04, 28 January 2024 (UTC)

I'm not sure of you mean something like parenthetical referencing which is, as David Eppstein says, deprecated on Wikipedia or something else. -- LCU ActivelyDisinterested «@» °∆t° 22:40, 27 January 2024 (UTC)

My preference would be to put the attribution at the start of the statement, so "David Eppstein says..." rather than "... (Eppstein 2024)." - but again it's only in instances where an assertion is already considered to warrant attribution rather than to rank as generally-understood fact. There's really no ideal solution: I just think the existing convention's failing badly in allowing claims that may be patent rubbish to be presented as factual statements. Quantist (talk) 05:19, 28 January 2024 (UTC)

I don't think it's a problem of policy, but rather a question of editors enforcing, as good as they can, the policies that are already in place. If rubbish or factually doubtful statements are detected, they should be removed or at least marked as such. There is nothing in the existing policies that hinders such improvements, but of course somebody needs to notice first. On the other hand, rubbish doesn't cease being rubbish if somebody adds "XY says" before it. Gawaon (talk) 06:10, 28 January 2024 (UTC)

I'm still not sure of the protocol for removing the "rubbish": in olden days there was a presumption against deletion unless it amounted to vandalism or evident fabrication: I take it that's eased.

Yes XY can still be cited as the source of a nonsensical claim, but "XY says... while AB says..." offers an opportunity to address the relative standing of the two assertions. "Life expectancy at birth was about 20.[1] Life expectancy at birth was 42.[2]" (just to cite a recent case I encountered) makes no sense. Quantist (talk) 13:12, 29 January 2024 (UTC)

Assuming that both sources seem reliable, I'd probably rewrite that as something like Modern estimates of life expectancy at birth vary widely, ranging from about 20[1] to 42.[2] Gawaon (talk) 13:31, 29 January 2024 (UTC)

That seems a good way round it. The catch though is that one of the sources (and indeed the higher number) isn't reliable at all, but I don't have access to it so I can't really challenge its credibility. In fact the other figure looks improbably low to me too, though that's from a reputable scholar in the field and it's doubtless closer to the reality. These things are sent to try us. Quantist (talk) 22:13, 29 January 2024 (UTC)

And I actually don't think a case such as this would in any way benefit from "X says 20, Y says 42." Lay readers will have no idea who X and Y are, so it won't help them at all, and the knowledgeable will easily find this information by hovering over the references, so they don't need it in the text. Gawaon (talk) 13:34, 29 January 2024 (UTC)

I agree that naming people isn't always helpful. Strictly speaking, we don't necessarily want in-text attribution to individuals for views that are held by groups of people, either. We should often be saying "Republocrats say X and Demicans say not-X" or "Consequentialists say X and and deontologists say not-X" rather than giving in-text attribution to individuals like "Alice says X and Bob says not-X". WhatamIdoing (talk) 23:16, 29 January 2024 (UTC)

Automatic citation question

Hi, not sure where to ask this, so I'm trying a few different places.

Last year, I had a zotero translator accepted into the main github repo. I use the source I wrote the translator for a lot, but automatic citations for it still don't work on Wikipedia for some reason. Is there something I should do or someone I should ask to make sure it'll work going forward? toobigtokale (talk) 05:48, 3 February 2024 (UTC)

Why are changes to/from citation templates not allowed?

WP:CITEVAR says we should avoid adding citation templates to an article that already uses a consistent system without templates, or removing citation templates from an article that uses them consistently.

I fail to see how this fits with the intent of the arbitration ruled in 2006, which is presumably concerned with styles that are of high visibility to the encyclopaedia user (the person served by this project). So it would be clear that, for instance, US versus British English is something that the reader will see. I question whether or not referencing using a citebook template would even be visible to a reader – I argue that this sort of thing is only an issue for a limited number of Wikipedia editors.

I note that I can find no clear definition of what is meant by "citation style". The definition could come in at a number of levels – I had presumed (perhaps wrongly) that this differentiated between short and full citations (per WP:SFN). Have I missed this term being defined or is there a general understanding that I have missed? ThoughtIdRetired (talk) 16:07, 31 January 2024 (UTC)

I think you're not reading CITEVAR the way most editors do: it's used for styles that are primarily visible to editors as much as it is used for styles visible to end users. There are editors who don't use citation templates, and those who prefer them; CITEVAR allows those editors to retain those preference on the articles they edit. Mike Christie (talk - contribs - library) 16:28, 31 January 2024 (UTC)

But why should it matter to an editor if someone else working on the same article uses a cite template when they choose not to? I see no logic to this whatsoever. The main thrust of all rules on Wikipedia is that this is all about developing an encyclopaedia, and hence all about what the reader sees. A result of current practices is that older articles are less readable to the user as they tend not to use the more recent (though well established) functionality of templates. I am sure you are well aware of this functionality, but what these older articles miss out on is demonstrated here. ThoughtIdRetired (talk) 16:50, 31 January 2024 (UTC)

The real point of CITEVAR, along with other types of preferred styles, is to stop people edit warring to enforce their own preferences. As long as the style of referencing is clear, it doesn't really matter, but edit warring about it is damaging to the encyclopedia and is contrary to a collaborative editing environment.Nigel Ish (talk) 18:50, 31 January 2024 (UTC)

My experience of this is of an editor who has a strong objection to templates going on to change the templates used by other editors to non-template forms. This I see as nascent edit warring. So in this case CITEVAR is doing nothing to prevent edit warring; rather it is arguably encouraging it. A principle of not messing with other editor's references as long as they do the job and meet the higher level referencing method of the article would be more likely to supress edit warring. ThoughtIdRetired (talk) 19:16, 31 January 2024 (UTC)

If some citations in an article use templates and others do not, this (often) leads to inconsistency in how citations are displayed to the reader, in addition to how referencing is done from the editor perspective. I'm not sure why you would describe making citations consistent as "nascent edit warring" - if I add a citation and you change how it's formatted, there's no reverting involved there. It's only if there is disagreement that that might become a problem, and that's the purpose for which CITEVAR exists. Nikkimaria (talk) 00:40, 1 February 2024 (UTC)

There are good reasons to deliberately avoid using citation templates. Among them: to prevent the bots from spamming useless ids to the citations, and to handle situations that the citation templates do not cover well. If one is deliberately avoiding templates for such reasons, then it can be highly annoying for some other consistency-obsessed editor to steamroller over that preference, and only common courtesy to discuss the issue first. —David Eppstein (talk) 18:57, 31 January 2024 (UTC)

I agree, citation templates do not handle every situation. I very strongly support concerns about consistency-obsessed editors. Unfortunately my experience of such an editor is for it to be impossible to engage them in any sort of productive discussion. Any comeback on a lengthy "no" gives an accusation of disruptive editing. Whilst my original aim of producing an article where the reader can easily see where the content comes from will clearly be blocked by such an individual, a ban on using the automation that is widely used in Wikipedia will make adding extra content to the problem article extremely burdensome – and a lot of extra content is now overdue following the publication of a new totally definitive source.
I have not seen any of the bot related problems with templates – is this a real thing or just a theoretical possibility? ThoughtIdRetired (talk) 19:16, 31 January 2024 (UTC)

See e.g. User talk:Citation bot#Semantic scholar links continue to mostly consist of spam. —David Eppstein (talk) 19:20, 31 January 2024 (UTC)

Thanks for the example. Whilst I agree this is a problem, I don't see it as a reason not to use templates – that would be like not using electronic banking because of potential security problems. In either case, you block the abusing entity and get on with using welcome functionality. ThoughtIdRetired (talk) 19:31, 31 January 2024 (UTC)

I agree. We should cure the disease (Semantic Scholar spam), not collude by concealing the symptoms. --𝕁𝕄𝔽 (talk) 23:45, 31 January 2024 (UTC)

Yep. A bot doing a wrong thing is a reason to fix the bot, and if it's bad enough even to stop the bot until it's fixed; it's not a reason to avoid using citation templates, which are really the only way we get pretty close to consistent citations (except in a vanishingly small number of articles that are obsessively hand-maintained by a single editor with a particular citation-style pecadillo, and that's a dying breed). It's a bit like insisting on spinning your own yarn and weaving your own cloth to make socks for your family instead of going to the store and buying some socks. Use the tools we have, save a lot of time and effort, get the feet warm sooner than later. — SMcCandlish ☏ ¢ 😼 11:29, 2 February 2024 (UTC)

I recommend knitting the socks instead of weaving them. ;-) They'll stay on your feet better. WhatamIdoing (talk) 17:22, 2 February 2024 (UTC)

It's a hobby for those with time to spare. Kinda the same here, except "hand knitting" citations imposes complications on other editors who come to the article. It's ultimately a lost cause that we tolerate due to "my citation format is better than yours" holy-warring in the early 2000s, before we even had a citation template system. When the hand-maintainer of a "precious" citation format eventually isn't around any longer, conveniently templated citations will creep in, the cite style will become inconsistent, and someone will eventually renormalize them all, sensibly to templated citations. Happens all the time, and should. — SMcCandlish ☏ ¢ 😼 21:49, 2 February 2024 (UTC)

The 2006 ArbCom statement is a bit of a retcon; it didn't have any role in the creation of this section (in 2010 and 2011).

I suspect that if we set up an RFC on this subject today, there would be a majority in favor of treating WP:CS1 templates as the normal and default (but not required) way to add citations to any article. I would also not be surprised to discover that editors specifically believed that CITEVAR should say that switching to CS1 templates was usually okay, and removing them was generally not. There seem to be few experienced editors, and basically no new ones, who feel strongly about maintaining an absolutely even-handed approach.

What I think is most important is not in CITEVAR, but at the top: While you should try to write citations correctly, what matters most is that you provide enough information to identify the source. Others will improve the formatting if needed. WhatamIdoing (talk) 04:47, 1 February 2024 (UTC)

I. for one. feel that. CS2. is. far. far. better. than CS1. It isn't. so. choppy. because. it. isn't. interrupted. with. so. many. periods. —David Eppstein (talk) 05:07, 1 February 2024 (UTC)

The presence or absence of full stops seems ... really minor. I mean, I would prefer all cases of eg (and akin abbreviations such as viz, ie, nb, sv, and etc) to be without points, same with titles like Dr or MSt and names like T R S Broughton. But people all have different preferences on this sort of thing. Ifly6 (talk) 15:33, 1 February 2024 (UTC)

I also prefer CS2 for another reason: its default formatting template, {{citation}}, doesn't force me to decide whether the thing I am citing was published in a magazine or a journal or a newspaper or a web site. You can just cite it, without having to pick the right kind of citation template for the right kind of publication venue. —David Eppstein (talk) 00:17, 2 February 2024 (UTC)

They mostly support the same parameters anyway; if you cite a journal as a magazine or vice versa, it will still work fine. {{cite magazine}} even supports {{cite journal}} parameters the documentation of the former doesn't specify, including |journal=, |vauthors=, |citeseerx=, etc. They're all processed by the same Lua module code. Where there are differences is mostly books; it uses |title= as the work and |chapter= AKA |contribution= as the sub-work; all the periodical templates use |title= as the sub-work, and for the main work it's |work= or one of its numerous aliases (|journal=, |magazine=, |newspaper=, |website=, etc.) But CS2 also has issues like this; if you don't include something like |journal=, it defaults to treating the work as a book, and you'll get undesired results if it's not one. CS2 is all actually now handled by the same module code anyway. — SMcCandlish ☏ ¢ 😼 11:21, 2 February 2024 (UTC)

It's the same module, but the CS1 templates are more inflexible; they have many parameters that only work within one of the templates but not the others, or that have different interpretations in different templates. Try using |work= with {{cite book}}, for instance, or explaining why |title= is the title of a book for {{cite book}} but not for {{cite encyclopedia}}. —David Eppstein (talk) 06:23, 3 February 2024 (UTC)

How about allowing articles to be migrated to either CS1 or CS2 (based on editorial discretion), but not away from any existing citation template style? I can see very little downsides to allowing such migrations. Gawaon (talk) 06:03, 1 February 2024 (UTC)

I would support this. Ifly6 (talk) 15:30, 1 February 2024 (UTC)

I do find it sometimes confusing to know whether an article which doesn't make use of citation templates was just written by someone who didn't know about them / just didn't feel like doing it or who by someone who does know about them but there is a local consensus to avoid using them for a specific reason. I use CS1 templates when I write articles, but there have definitely been a few times where I'm sort of hacking together what to put in various parameters to get it to best work and a freeform citation would allow editors to be strictly speaking more accurate when a citation doesn't neatly fit into what the templates expect the parameters for a given type of work should have; I've also been annoyed at bots in the past changing/reformatting/adding useless or incorrect information to citations making use of templates and can also imagine some editors just finding it easier to not use the citation templates to avoid all this.

Before a big change like changing all of an article's citations it still is probably worth discussing on the talk page to see if there is a reason why the citations were formatted that way or not. Umimmak (talk) 20:32, 1 February 2024 (UTC)

Speaking purely from my own recent experience, if a website gives me a copy-and-paste option for a citation and its URL gets parsed badly by our automagic tools, I'm likely to copy the pre-made citation instead of putting it into a citation template. I figure that if the article ever reaches Wikipedia:Featured article candidates, and the source is still being cited by that point, then the FAC nom will clean it up, and I won't care which method they use to do so. WhatamIdoing (talk) 23:52, 1 February 2024 (UTC)

I've always taken the spirit of CITEVAR, ENGVAR, and such as "go do something useful instead". The vast majority of readers don't care whether references are text based or use a template, and a vanishingly small part of those that do care even understand the formatting differences between CS1 and CS2. As long as you're not generating large red error messages the important part is putting in enough information that it can be reasonably verified by another person.
Personally I prefer templates because they are less likely to suffer from information rot than a text based version, and will usually generate notices if something has gone wrong. But unless you are writing or rewriting an article, there are far more important issues to deal with than the style of referencing. -- LCU ActivelyDisinterested «@» °∆t° 00:44, 2 February 2024 (UTC)

Perhaps this is because I am older than many here, but I find citation templates very confusing to use. So, I usually don’t. I just write my citations out by hand, the old way… even when the article clearly already uses templates. I assume that someone else will follow along after me and convert my hand written citation into whatever preferred template format has been chosen. No big deal. Blueboar (talk) 12:41, 2 February 2024 (UTC)

Fair enough, as long as that's not forbidden! But the (text-mode) editor has a nice enough Cite / Templates function that can be used to create CS1 citations. I use it all the time and I guess it's the main reason I use CS1 rather than CS2. Gawaon (talk) 13:25, 2 February 2024 (UTC)

But a wikilawyer reading of CITEVAR says that someone who comes along and converts hand-written references to templates may be wrong – however much that might improve the encyclopaedia user's experience. ThoughtIdRetired (talk) 14:48, 2 February 2024 (UTC)

Unless you're planning to work on the article content yourself, I agree with ActivelyDisinterested that it's best to just not change the formats, as it's article content that's the most valuable thing for our readers. If you do want to work on the article, a quick look at the history stats and a note on the talk page will soon tell you if there are objections to making this sort of change -- and in most cases, unless it's an article that an active editor has put a good deal of work into, there will be no objections. When you do run into a situation like that, there's little value to the encyclopedia in prolonging a discussion. At a minimum it'll annoy an editor who's put a lot of work into the article, and it might stop them from maintaining it. There are more productive things to do with one's time than push back on CITEVAR disagreements -- and I think that's the main reason CITEVAR exists, because those discussions are unproductive. And as you can see from the comments above, not everyone agrees with you about whether the templatese are important to the end-user's experience. Mike Christie (talk - contribs - library) 15:01, 2 February 2024 (UTC)

@ThoughtIdRetired, according to CITEVAR, it's only wrong to change whole articles that already have an established style. Improving on the best efforts of any editor who provides information about a source to the best of their ability is 100% okay. If Blueboar does his best (a complete citation is very much appreciated even if it's formatted the "wrong" way), and you make it match whatever style is established for that article, then nobody will yell at you. WhatamIdoing (talk) 17:26, 2 February 2024 (UTC)

Thanks for that comment. I am beginning to think I need to work on people handling skills to solve the precise problem in front of me, not broader knowledge on referencing guidance. I have invested a large amount of reading time (many days, and more to go) for one particular article, but find the referencing to be (in my view) somewhat chaotic and archaic, with the 40% editor of it switching horses between "you can use templates if you wish" to removing the templates that I have used on a reference problem I sorted out. The article should have a large amount of new text soon due to a new authoritative source. I recently realised it might even justify an article of its own, which is an appealing idea in the circumstance, and just have a summary transcluded into the main article. I have a lot more reading to do before I need to make a decision on this. ThoughtIdRetired (talk) 18:52, 2 February 2024 (UTC)

Are you working with the most popular citation templates (like {{cite book}}) or with something less common, like {{sfn}}? WhatamIdoing (talk) 04:30, 3 February 2024 (UTC)

Hmm, these are commonly combined? I always use {{cite book}}) when citing a book for the first time (or in the general list of references), {{sfn}} for references to (other) specific page numbers in the same book. {{cite book}}) by itself can't handle such situations. Gawaon (talk) 05:11, 3 February 2024 (UTC)

You can use the cite book template for a title–page number short ref: "Government Report. p. 23." Other people (especially if the book is only used for a couple of pages) simply repeat the full citation, putting in different page numbers each time. WhatamIdoing (talk) 18:13, 3 February 2024 (UTC)

No, don't write {{cite book |title=Government Report |page=23}}. That creates an incomplete citation both visually and in the metadata. {{sfn}} and the {{harv}} family of templates are designed specifically for such 'short form' referencing. Use an appropriate template of simply write a short-form reference with wikitext (''Government Report''. p. 23); don't abuse the {{cite book}} template.

—Trappist the monk (talk) 18:21, 3 February 2024 (UTC)

Plus {{sfn}} and friends also have the advantage of showing the full citation details in an additional mouseover, while with a repeated short {{cite}} the user needs to find the full citation details manually (which might be non-fun, especially if the article has 100s of references). Gawaon (talk) 22:04, 3 February 2024 (UTC)

To answer User:WhatamIdoing, my referencing repertoire is:
(case A, where there is a single list of references, each showing the full reference): For a new source, I use a cite book/journal/etc. template as offered in the wikitext editing window I am using now. I always give a reference a name, whether I immediately expect to re-use the reference or not, with name almost invariably being author surname plus year of publication. I use the {{rp}} template for the page numbers in this first use. On second use of one of these sources I use the {{r}} template, putting the page number or other location in the template.
(case B, where there is a list of short references and a list of full references). For a new source I put the full reference in using wikitext cite book/etc. templates and then use the {{sfn}} template in the article text to produce a short reference and page number.
Having got this far with learning how to reference, this seems to meet all my requirements and meets what I see as the major referencing style division, which I have called case A and case B. (Terminology gap here: what do other editors call my "case A" and "case B"?)
I am also a great fan of the {{efn}} template. I find it is helpful for explaining points that would otherwise be unexplained, but will (a) be obvious to some readers, (b) seriously breaks up the flow of the article or (c) slightly steps away from the summary style of an article by giving just a bit more detail. In an article that has a lot of these explanatory footnotes, it is useful to see them all collected together at the end. I particularly dislike articles that muddle explanatory notes in with the rest of the references – I cannot see why that is allowed, even if it mimics some printed works. ThoughtIdRetired (talk) 10:56, 3 February 2024 (UTC)

I think your 'case B' is popular among FAC folks, particularly for history-like subjects (i.e., articles mostly written from 10 good books instead of 20 good journal articles or 50 good websites). I think it's mostly called "using sfn", though that's not at really specific.

For your 'case A', I'm not sure why you are using {{r}} at all; after the first ^[1]^: 23, why not keep using {{rp}}, e.g., ^[1]^: 56, ^[1]^: 35, and so forth? I'm not familiar with the {{r}}, so perhaps it has some convenience that I'm unaware of. WhatamIdoing (talk) 18:19, 3 February 2024 (UTC)

Thanks. The {{r}} template was recommended to me by another user. I use it solely because if involves typing one less character, but you can read the technical details on the template for yourself. I appreciate it has only 43% of the popularity of {{rp}}, but that is still a sizeable constituency.
BTW, sfn/case B referencing is not my first choice, but I will use it when it is established in an article. Case A referencing has the advantage that you can go to the list of references and see exactly how much of an article relies on one reference – tracking up into the article (one click) to see exactly what content is involved and then quickly back to the reference. That's important if you are improving an article that is over-reliant on one poorer quality reference. (The example I have in mind is with author Basil Lubbock in, for example Clipper and Great Tea Race of 1866 – Lubbock is a prolific source, but his historical work is not up to the standards of a proper maritime historian. However, (1) we know some of his identified inaccuracies and (2) he is sometimes the only source, so you have to go with it. Checking an article's reliance on him leads to cutting his involvement to the minimum necessary. Sorry, deep in one aspect of maritime history there, but it illustrates one useful feature of how Wikipedia displays references.) ThoughtIdRetired (talk) 19:48, 3 February 2024 (UTC)

If I see an article with an inconsistent or messy citing style, and I have the time to spare, I will try to impose a consistent citation style (I generally use CS1, Sfn, and Efn). If there are a lot of page watchers, I will ask first on the talk page if there are objections, as I did here. On more obscure articles, I will be bold and rework the citations. No one has reverted me or objected to such changes, so far. - Donald Albury 15:18, 2 February 2024 (UTC)

I am very interested to see how your work on Joseph Conrad removed the necessity for the now-deprecated parenthetical referencing in individual notes. (Obvious when you see it demonstrated, but not beforehand!) ThoughtIdRetired (talk) 15:59, 2 February 2024 (UTC)

An illustration

Whilst commending the very useful breadth of discussion on this, I just wanted to illustrate (literally) the focus on the enclyopedia user who wants to see where article content is sourced. These screenshots show how full use of templates make if easier to do this. Source articles are Yawl and Vasa (ship). The former uses entirely short referencing with sfn and cite book/journal/etc. templates, the latter article mostly short referencing but few templates. I appreciate different browsers may depict this differently but my mobile phone, at least, gives different displays where I still think the "preferred" version has better functionality. I appreciate that this may be obvious to some, but using my own technical knowledge as a model, it is likely not obvious to all. A further note on the screenshot should have emphasised the irritation in a long article of having to go to the cited sources at the end to find a full reference and then get back to the point where you were reading.

ThoughtIdRetired (talk) 15:46, 2 February 2024 (UTC)

Fun fact: All of this can be done without citation templates, too. You just put an anchor at the full citation (the one you show in the top article for John Leather's book is "#CITEREFLeather1989", but you can name it anything) and add a regular [[#section link]] to your anchor in the ref.

I have actually done this before, but I don't necessarily recommend it. It's easier to have the templates manage all the anchors. WhatamIdoing (talk) 17:32, 2 February 2024 (UTC)

Same. I did this kind of linking by hand in a long article, but am going to redo it all with {{sfnp}} (and {{harvp}} in a few cases that need annotations within the ref tag). The templated method is actualy still superior, because you get a mouseover popup (on any kind of system that supports that functionality) for the short cite and get another one for the long cite if you mouse-hover that inside the short cite's popup; the latter part doesn't happen if this stuff's link-coded manually. — SMcCandlish ☏ ¢ 😼 21:56, 2 February 2024 (UTC)

"Mouseover popup" – that's the terminology I was looking for! And the second mouse-hover is definitely the bit that aids readability for the encyclopaedia user. ThoughtIdRetired (talk) 11:08, 3 February 2024 (UTC)

clarification of CITEVAR

Not too long ago I was castigated for adding content with a different citation style than was in use at an article. But I don't actually understand how to use the other citation style and find it clunky to even try to verify content from. I'm completely fine if someone wants to change the citation style I used to conform with what's currently being used (and I can see how it would be annoying if someone feels they have to come along behind me to convert my additions to that style), but the strong implication from the other editor was that I shouldn't be adding citations at all if I didn't want to use the current citation style myself.

At any rate, can I get some clarity on what CITEVAR actually means in this situation? I've always interpreted it as "Don't change the current style, and particularly not if anyone objects" rather than "Adhere to the current style", if you see what I mean? CITEVAR does say "If the article you are editing is already using a particular citation style, you should follow it", though.

Thanks for any insight! Valereee (talk) 14:05, 3 February 2024 (UTC)

I take CITEVAR to mean that it would be polite to try to follow the established style, so if I edit an article in an unfamiliar style I do my best to follow it. Most articles don't have an established style, though; for anything that's not GA/FA/A class it probably doesn't matter much, though sometimes you can tell someone's worked to make it consistent. If I felt unable to comply with the style because I didn't understand it, I'd probably post a simple plain text citation and leave an apologetic note on the talk page, or (if it's clear there's an active editor maintaining the article) I'd post the information on the talk page and let them deal with it. But I don't think I've ever run into a case where I couldn't add the information in the requested style, though for sfn and r I would have to spend a bit of time figuring it out. Mike Christie (talk - contribs - library) 14:31, 3 February 2024 (UTC)

Yeah, sfn is just opaque for me. And I don't even know what r is. :) The citation form I was using was whatever VisEd uses. I'd be happy to convert if there were a script or something that made that easy. Valereee (talk) 15:00, 3 February 2024 (UTC)

CITEVAR says you shouldn't attempt to change the referencing style that is already in the article, as a courtesy you should try to add references that match the articles style but CITEVAR doesn't say that failing to do so is a crime. Anyone wanting to keep a consistent style can always update your references to match the article. -- LCU ActivelyDisinterested «@» °∆t° 17:05, 3 February 2024 (UTC)

And I do see the appeal of a consistent style, it's prettier. Valereee (talk) 17:13, 3 February 2024 (UTC)

This is the second question along these lines in the last couple of weeks. I'll go add a reminder to CITEVAR that this is a collaborative project, not a children's game. WhatamIdoing (talk) 18:22, 3 February 2024 (UTC)

☛ What matters most is that you provide enough information to identify the source. Others will improve the formatting if needed.

Done. If that doesn't work, then we can add this box to the top of the section. (It's a quote from the lead of this guideline.) WhatamIdoing (talk) 18:43, 3 February 2024 (UTC)

I think this just highlights that the subjects of
(a) how references are displayed in Wikipedia and
(b) how we achieve that
are a complete mess. Taking this edit [7] by User:Valereee as an example (please don't take this personally – I just needed edits by someone who used visual editor), we can see that it generates wikitext references behind the scenes that give meaningless names to references. In this case it assigns ref name=":3">, but here in citevar we are encouraged to set about replacing opaque named-reference names with conventional ones, such as "Einstein-1905" instead of ":27" So Visual editor is automatically creating content that it is deemed desirable to change. The discussion above (Wikipedia talk:Citing sources#Why are changes to/from citation templates not allowed?) demonstrates that there are wide variations in how much editors understand referencing. I went to quite a bit of trouble to learn my limited understanding, helped along by one or two other editors who generously took me through things step by step. I don't think what I learnt was difficult to understand – it's just that a simple "how to" explanation didn't seem to exist anywhere. This may be a cause of so many different editors having their own way of doing things. A review of the whole subject now seems due - What we want and how editors learn to achieve that. ThoughtIdRetired (talk) 20:22, 3 February 2024 (UTC)

I discovered Nardog's RefRenamer recently, a very cool script that replaces those crappy VisEd names. I've been using it frequently on articles I've added citations to. Valereee (talk) 20:29, 3 February 2024 (UTC)

Just used it at Liege waffle, which was a creation from today. Valereee (talk) 20:34, 3 February 2024 (UTC)

Great find, but this illustrates the typical sticking plaster solutions that come up in Wikipedia and that are not known to the vast majority of editors. We really should be free to concentrate on article content (what an encyclopaedia is all about) rather than the vagaries of the referencing system. ThoughtIdRetired (talk) 21:28, 3 February 2024 (UTC)

Oh, definitely great script! I wish there were one that would let me change a ref to adhere to the currently used one in an article, but the best I've found will just do it for cite book > sfn. Valereee (talk) 22:19, 3 February 2024 (UTC)