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)