Help talk:Citation Style 1/Archive 70

Archive 65

←

Archive 68

Archive 69

Archive 70

Archive 71

Archive 72

→

Archive 75

Usurped must be reinstated as a valid url-status value!

I currently work as a computer security professional. There are times when the original ownership of a website has expired & a bad actor has acquired the website. In these cases, I absolutely want to completely suppress the original website & only display the archived link. We need to protect our users from malicious websites. Peaceray (talk) 00:37, 10 August 2020 (UTC)

Umm, it never went away:

{{cite book |title=Title |url=//example.com |archive-url=//archive.org |archive-date=2020-08-09 |url-status=usurped}}

Title. Archived from the original on 9 August 2020.{{cite book}}: CS1 maint: unfit URL (link)

Also, one conversation in one place. I have closed the other dicussion.

—Trappist the monk (talk) 00:43, 10 August 2020 (UTC)

@Peaceray:, you might be interested in this discussion. Mathglot (talk) 09:48, 12 August 2020 (UTC)

"archive-url" dependency

Prompted by the recent discussion on auto-linking, which exposed cases of non-url data in |url=.

To mitigate, |archive-url= could formally depend on |url-status= instead of |url= (without checking the module code, I believe that programmatically, "archive-url" does depend on "url-status").

The option |url-status=missing original would be one of the cases that would cause the archive to become the live location in the citation. If |url= needs to be present, perhaps a comment such as |url=<!--Original missing.--> could be auto-inserted. 98.0.246.251 (talk) 02:28, 10 August 2020 (UTC)

I'm not sure I understand you correctly, but the scenario you are describing appears to be covered by |url-status=dead already. If only the archived URL is known, the original URL should be derived from the archived URL and inserted into |url=. In most cases, the archive URL contains (perhaps not exactly the URL the user used when invoking the page originally, but at least) the page used by the archiver when archiving the page. Displaying the archived web site may reveal the original URL as well (depends on the archiver, though). In the case of archive URLs in form of tiny URLs there are tools to expanded them into their long forms. This should allow most original URLs (or equivalents) to be recovered from their archived URLs.

Of course, |url= would then no longer be available for overloading, but there are alternatives for this (e.g. using |title-link= instead. See Help_talk:Citation_Style_1#Towards_solving_pending_issues_of_the_auto-link_feature...

--Matthiaspaul (talk) 12:19, 13 August 2020 (UTC)

The discussion you linked is the one referenced in the OP. Basically, it is proposed to edit the doc so that it reflects the code: archive status depends on url status (which requires |url=). Not incidentally, this may help in keeping invalid data (non-URL entries) out of the URL field. Properly, all url indicators should be entered in the status parameter. An exception could be made for none in certain narrow well-defined cases. Since none is used elsewhere in the module, it wouldn't be a bad idea to declare it a special word. 172.254.241.58 (talk) 12:50, 15 August 2020 (UTC)

Use of Years from the Jewish Calendar?

I'd like to reference http://www.ajcarchives.org/AJC_DATA/Files/Vol_33__1931_1932.pdf using cite journal. The Year that is used is 5692 in the Jewish Calendar Anno Mundi. Is there any way to include this in the Cite Journal or is using the fallback 1931-1932 the only way?Naraht (talk) 03:43, 17 August 2020 (UTC)

According to Help:Citation_Style_1#Dates, "Sources are at liberty to use other ways of expressing dates.. such as religious calendars", but, "In cases where the date as expressed in the source is not compatible with the template software, the citation should be created without using a template." The principal of the template is to help readers find a source, for verifying a cite. If the reader can reliably find the source using the 1931-1932 date, it might be OK to use that if you still want to use the template. -- GreenC 04:03, 17 August 2020 (UTC)

In your specific case, you do not need to convert dates because the book itself is using the Gregorian calendar for publication dates: July 1931. You should not specifiy a year range, as the book was published on a specific date in 1931, and the fact that the application of the book as a year book spans from 1931 to 1932 is irrelevant in regard to the bibliographical data needed in a citation, and for all other purposes, that information is already in the title (otherwise, if important for the reader, it could be added as a note following the citation). Something like this:

{{cite book |title=The American Jewish Year Book 5692: September 12, 1931, to September 30, 1932 |date=1931-07-16 |volume=33 |editor-first=Harry |editor-last=Schneiderman |publisher=[[The Jewish Publication Society of America]] |location=Philadelphia, Pennsylvania, USA |url=http://www.ajcarchives.org/AJC_DATA/Files/Vol_33__1931_1932.pdf |access-date=2020-08-17}}

Schneiderman, Harry, ed. (16 July 1931). The American Jewish Year Book 5692: September 12, 1931, to September 30, 1932 (PDF). Vol. 33. Philadelphia, Pennsylvania, USA: The Jewish Publication Society of America. Retrieved 17 August 2020.

--Matthiaspaul (talk) 08:47, 17 August 2020 (UTC)

Small glitches masking and linking author names

Hi. I just documented an apparently undocumented special case of the |-mask= parameters. A numerical value of 0 will not display a dash at all, but if a corresponding |-link= parameter is defined as well, this will be taken as (linked) text. However, experimenting a bit with the parameter, I found a number of corner cases, which still seem to be a bit rough, that's why I am bringing this up for discussion and possible improvement:

• Without corresponding |-link=, |-mask=0 will still display a separator (; by default with CS1) in front of the following author names. Is this really useful or would it be better to suppress the leading separator as well and just start with the second name?
• If a corresponding |-link= is defined, it will be linked even if |-mask= has a numerical value > 0. While it might make sense to still link to the masked name if |-mask= is used to define some alternative text (see below), does it really make sense to link to a name labelled as dash (like ––)? After all, the supposed application of this parameter is a list of works by the same author, so it can be assumed that the author name is already linked to in an unmasked citation starting the list further above. Of course, a work-around is to not specify |-link= in conjunction with |-mask= > 1, but if there is no useful application to displayed linked dashes, it would be more logical to suppress linking in this case.
• If |-mask= defines some alternative text, it may or may not make sense being able to use it as link label, so |-link= might make sense here depending on the alternative text: If the alternative text is a "full replacement" of the original name (like "McCluskey Jr., Edward J." or "ditto"), linking to it can be useful. If, however, |-mask= is used to define some extra text in front or following the original name (e.g. |-mask=with Doe, John, a usage recently suggested in several other threads, e.g. here), the link should probably be applied to the embedded original name like "Doe, John" only, not to the whole alternative string like "with Doe, John" (as it currently does). Since the template has no reliable way to distinguish extra text from names, I propose the following enhancement:

If the string defined by |-mask= does not contain a * character, the whole string will be used as link label if |-link= is provided as well (as now). If, however, the mask text contains a *, the * will be treated as a "smart" placeholder and will be replaced by a string of the form "<last>[, <first>]" derived from the corresponding name parameters |-lastn=/|-firstn=. In this case, only this placeholder value will be used as link label if |-link= is provided as well.

So, the combination of |author-first=John |author-last=Doe |author-link=John Doe |author-mask=with * would result in "with Doe, John".

This would solve the "what to use as link label" problem and also avoid the repetition and hard-wiring of the name in the |-mask= parameter. It would also be a partial implementation of my more general placeholder proposal, discussed here: #Smart substitution token to reduce redundancy among input parameters.

--Matthiaspaul (talk) 09:27, 16 August 2020 (UTC)

I have tweaked the sandbox so that mdash-masked names don't link on the presumption that the unmasked name has been linked in a preceding citation.

Cite book comparison

Wikitext	{{cite book|author-link=Author|author-mask=2|author=Author|title=Title}}
Live	——. Title. {{cite book}}: |author= has generic name (help)
Sandbox	——. Title. {{cite book}}: |author= has generic name (help)

When |<name>-mask=0, the name is omitted from the rendering along with its separator:

Cite book comparison

Wikitext	{{cite book|author-mask=0|author2=Author2|author=Author|title=Title}}
Live	Author2. Title. {{cite book}}: |author= has generic name (help)CS1 maint: numeric names: authors list (link)
Sandbox	Author2. Title. {{cite book}}: |author= has generic name (help)CS1 maint: numeric names: authors list (link)

—Trappist the monk (talk) 18:49, 18 August 2020 (UTC)

Hm, but now the "special case" (|-maskn=0 in conjunction with |linkn=...) no longer works:

Cite book comparison

Wikitext	{{cite book|author-link1=John Doe|author-mask1=0|author1=Author1|author2=Author2|title=Title}}
Live	Author2. Title. {{cite book}}: |author1= has generic name (help)CS1 maint: numeric names: authors list (link)
Sandbox	Author2. Title. {{cite book}}: |author1= has generic name (help)CS1 maint: numeric names: authors list (link)

or

Cite book comparison

Wikitext	{{cite book|author-link2=John Doe|author-mask2=0|author1=Author1|author2=Author2|title=Title}}
Live	Author1. Title. {{cite book}}: |author1= has generic name (help)CS1 maint: numeric names: authors list (link)
Sandbox	Author1. Title. {{cite book}}: |author1= has generic name (help)CS1 maint: numeric names: authors list (link)

--Matthiaspaul (talk) 20:15, 18 August 2020 (UTC)

Historically, we have taken the decision to hide the author / contributor / editor / interviewer / translator name when |<name>-mask=0. Historically, when |<name>-mask=<n>, where 0 != <n>, we have taken the decision to replace the name with a concatenation of <n> mdashes. In this discussion it is proposed that these mdash replacements of name shall not be linked regardless of the state of |<name>-link=. It does not make sense to me to ignore the |<name>-mask=0 rule when |<name>-link= has a value because that kind of inconsistency just confuses editors. So the rule should be:

when |<name>-mask= is assigned a numeric value, |<name>-link= is ignored.

—Trappist the monk (talk) 21:54, 18 August 2020 (UTC)

Editors

Rats, I thought I might be able to make deprecating |editors= in this release. Just south of 800 to go. :^) --Izno (talk) 02:50, 7 July 2020 (UTC)

I'd be against deprecating |editors= much like I'd be against deprecating |authors=. They're convenient when you don't have the time or willpower to add |editor-last1=/|editor-first1= to |editor-last#=/|editor-last#= to a long list of editors. Headbomb {t · c · p · b} 13:36, 7 July 2020 (UTC)

It is already deprecated by the presence of Category:CS1 maint: uses editors parameter. --Izno (talk) 14:03, 7 July 2020 (UTC)

That's not deprecation, that's marking the usage as "not ideal, could probably be better". Very different things. Headbomb {t · c · p · b} 14:35, 7 July 2020 (UTC)

I have yet to be reverted in some 4000 edits removing the parameter. That's functionally deprecated, even if "CS1 maint" didn't give a strong clue as to our opinion on the condition existing. --Izno (talk) 14:56, 7 July 2020 (UTC)

I'd be against deprecating those two parameters also. (And by the sound of it, they're not deprecated, strictly speaking, just advised against.) Authors= and Editors= allows for situations where there are multiple individuals to name but some are credited under "with", ie they appear to be afforded a lesser credit (and a smaller font size) on a book cover and title page. This is often the case with autobiographies (for journalist co-writers) and revised editions of multiple-author works (where a previous editor might be credited under "with" because content from a previous edition is reproduced without any change). Besides, as ever, I wish template editors here would stop trying to jam an overly simplified, one-size-fits-all model down everyone's throats ... The important thing is to present the source accurately. JG66 (talk) 15:01, 7 July 2020 (UTC)

I would be shocked if you need "with" to do so. Even if "with" is important, and you don't want to include that person as an |editorn=, you have |others= to express in total free-text the full relationship of any other people involved in the work. I have removed several "withs" in my run to remove |editors= ("with", er, replacement as a "full" editor) and again, no reversions if in fact anyone cares that deeply. --Izno (talk) 15:26, 7 July 2020 (UTC)

Well, you'll just have to be shocked then, won't you. I'd happily revert every single instance where including "with" ensures the 'correct' author/editor credit appears. But that's because I write articles rather than gnome away. JG66 (talk) 15:37, 7 July 2020 (UTC)

Including attribution text in the rendering of a citation is one of the purposes of the |<name-list>-mask= parameters – this particular use in mentioned in the template documentation. This citation can be rewritten to avoid |editors= and maintain the proper metadata:

{{cite book/new |last=Marcus |first=Greil |authorlink=Greil Marcus |chapter=The Beatles |chapter-url=https://greilmarcus.net/2014/07/11/the-beatles-1979/ |editor=DeCurtis, Anthony |editor2=Henke, James |editor3=George-Warren, Holly |editor-mask3=with George-Warren, Holly; |editor4=Miller, Jim |title=The Rolling Stone Illustrated History of Rock & Roll: The Definitive History of the Most Important Artists and Their Music |url=https://books.google.com.au/books/about/The_Rolling_Stone_Illustrated_History_of.html?id=ubWAht7N7zsC&redir_esc=y |year=1992 |orig-year=1979 |publisher=Straight Arrow |location=New York |isbn=0-679-73728-6 |via=greilmarcus.net}}

Marcus, Greil (1992) [1979]. "The Beatles". In DeCurtis, Anthony; Henke, James; with George-Warren, Holly; Miller, Jim (eds.). The Rolling Stone Illustrated History of Rock & Roll: The Definitive History of the Most Important Artists and Their Music. New York: Straight Arrow. ISBN 0-679-73728-6 – via greilmarcus.net.

—Trappist the monk (talk) 13:03, 8 July 2020 (UTC)

In another thread I give an example how this could be further improved upon with the introduction of a "smart" placeholder *:

#Smart substitution token to reduce redundancy among input parameters

--Matthiaspaul (talk) 12:33, 10 August 2020 (UTC)

While I hate running into them in citations, I think, Headbomb has a good argument here for us multi-taskers. Sometimes, they really are convenient: When you are working on something different and don't want to or can't spend time on unrelated stuff, but just want to rush out a citation rather than to not provide the citation at all. However, someone will have to clean up the mess sooner or later. Putting them in a maintenance category is good, but perhaps we could also display a warning in article preview so that whoever edits the article will be made aware of the messy citation. Also, the parameters should be further marginalized in the documentation. This way, we could, perhaps, keep them longtime, but still reduce their use to a minimum.

--Matthiaspaul (talk) 15:02, 7 July 2020 (UTC)

I empathize with the "convenient" argument, but after clearing out 5000 pages (some credit to Ttm who picked up a few hundred), I much-more-deeply empathize with the "as an author, do your job and indicate clearly who is an editor and who is not in the CS1/2 style". :) --Izno (talk) 15:26, 7 July 2020 (UTC)

I'd be down for making most maintenance messages visible in previews (something like Preview message: consider replacing |editors= with |editorn-last=/|editorn-last=). Headbomb {t · c · p · b} 16:28, 7 July 2020 (UTC)

Which is why we have Module:Citation/CS1/Suggestions. --Izno (talk) 16:31, 7 July 2020 (UTC)

Sounds like a good solution. Glades12 (talk) 16:39, 7 July 2020 (UTC)

And just now finished the category off save for some drafts that would be better off G13d. --Izno (talk) 00:28, 8 July 2020 (UTC)

Call me ignorant, but what does G13d stand for?

--Matthiaspaul (talk) 12:45, 21 July 2020 (UTC)

Wikipedia:Criteria for speedy deletion § G13. Abandoned Drafts and Articles for creation submissions

—Trappist the monk (talk) 13:20, 21 July 2020 (UTC)

Thanks. :-) I was somehow trying to match that with numeronyms like I18n or L10n... ;->

--Matthiaspaul (talk) 13:38, 21 July 2020 (UTC)

So we should mark |editors= as deprecated. Because cs1|2 will never be smart enough to correctly parse-apart a string of human names in all of their possible forms, separated by an often inconsistent variety of separator characters, names listed in |authors= and |editors= have never and will never be included in the citation's metadata. It is time to deprecate and remove |editors=. Now seems as good a time as any.

—Trappist the monk (talk) 13:03, 8 July 2020 (UTC)

That will just lead to further abuse of |editor= to contain multiple editors, without the benefit of the maintenance category. Headbomb {t · c · p · b} 13:30, 8 July 2020 (UTC)

Possibly, but such misuse is caught and categorized in Category:CS1 maint: multiple names: editors list (106).

—Trappist the monk (talk) 14:07, 8 July 2020 (UTC)

Does it suppress metadata for as long as this condition applies?

Can this condition be indicated in preview as well?

--Matthiaspaul (talk) 14:21, 8 July 2020 (UTC)

Multiple names in single-name parameters are all shoehorned into a single key/value pair in the metadata because cs1|2 expects, and the documentation requires, one name per parameter. The whole list of names is present but the metadata are corrupted because each name should be in its own k/v pair. As I said before, cs1|2 is not smart enough to parse-apart a list of human names.

If editors have maintenance messaging turned on, the messages are always visible.

—Trappist the monk (talk) 14:47, 8 July 2020 (UTC)

Okay, but if the template can detect that there seems to be more than one name given in a single |author=/|editor= parameter in order to put it into a maintenance category, this could also be used to suppress metadata creation until someone has checked the issue and either splitted the list into many parameters or used (()) to accept the string as valid. With (()), metadata creation would be turned on again, warnings disabled, and the citation would no longer be put into a maintenance catagory.

With this metadata suppression in place and with warnings shown to anyone (not only those who opted in) in preview, I think, we could safely deprecate the |authors= and |editors= parameters. Headbomb's concerns, that people will then use |author=/|editor= to "park" name lists, will likely hold true, but with metadata suppressed and warnings in place, no harm would be done by this and the situation would likely be fixed earlier than having dedicated parameters to take multiple names. Appears like a good compromise and "best of both worlds" approach to me.

--Matthiaspaul (talk) 13:54, 9 July 2020 (UTC)

There are sufficient other maintenance/error categories and correct uses of the templates that I have made changes to the sandboxes to mark editors as deprecated:

--Izno (talk) 14:02, 16 July 2020 (UTC)

New autolinking of free dois breaks citations that deliberately omit title

In the citation

{{cite journal|last=Nespolo|first=Massimo|date=November 2019|doi=10.1107/s1600576719014055|issue=6|journal=Journal of Applied Crystallography|pages=1467–1468|title=none|volume=52|doi-access=free}}

currently formatted as

Nespolo, Massimo (November 2019). Journal of Applied Crystallography. 52 (6): 1467–1468. doi:10.1107/s1600576719014055.{{cite journal}}: CS1 maint: untitled periodical (link)

I am now seeing a visible url and a big red error "|doi= missing title" even in the not-logged-in view. This citation was previously error-free and was broken by recent changes to the citation template that added auto-linking of dois without taking adequate precautions that there is something to auto-link to.

I frequently and deliberately omit titles, using the documented method |title=none of doing this, as part of lists of multiple reviews of the same book that do not have individual titles. Many such reviews are not formatted with titles so any title that one included would have to be a made-up placeholder. In this case the review actually is formatted with a title, but not one that would be useful to include in a citation: the title, as formatted in the review, is "Fat Chance! Probability from 0 to 1. By Benedict Gross, Joe Harris, and Emily Riehl. Cambridge University Press, 2019. Pp. Xi+200. Paperback price GBP 19.99, ISBN 9781108728188. Hardback price GBP 49.99, ISBN 9781108482967. Ebook price USD 21.00, ISBN 9781108598705."

It should not be an error to omit the title and it should not be an error to mark dois as free even when the title is deliberately omitted. Please stop making the citation templates even more brittle and unusable than they have become, restore the ability to deliberately omit titles on citations, and un-break the many citations already existing within Wikipedia articles that this change has broken. —David Eppstein (talk) 22:18, 4 August 2020 (UTC)

This seems like a fairly clear bug to me. The tone from "please stop" was not necessary accordingly. --Izno (talk) 22:49, 4 August 2020 (UTC)

{{cite journal/new|last=Nespolo|first=Massimo|date=November 2019|doi=10.1107/s1600576719014055|issue=6|journal=Journal of Applied Crystallography|pages=1467–1468|title=none|volume=52|doi-access=free}}

Nespolo, Massimo (November 2019). Journal of Applied Crystallography. 52 (6): 1467–1468. doi:10.1107/s1600576719014055.{{cite journal}}: CS1 maint: untitled periodical (link)

—Trappist the monk (talk) 22:55, 4 August 2020 (UTC)

Thanks! It has historically not always been easy to distinguish changes that are recognized as bugs and fixed from changes that are intended to restrict how the template can be applied and are permanent. I'm glad this one landed on the fixed side. —David Eppstein (talk) 23:11, 4 August 2020 (UTC)

Perhaps some common sense would be useful next time? − Pintoch (talk) 07:08, 5 August 2020 (UTC)

Us editors on this talk page have been accused of lacking such on occasion. --Izno (talk) 18:54, 5 August 2020 (UTC)

Common sense is not as common as people think. It may also be not as sensible. 65.88.88.69 (talk) 17:26, 7 August 2020 (UTC)

Towards solving pending issues of the auto-link feature...

This was one of the (thankfully now fixed) open special cases already mentioned in the original thread (Help talk:Citation Style 1#Proceeding). There are more (see also Help talk:Citation Style 1/Archive 68#module suite update 11–12 July 2020). Would be nice to see them addressed before the next update is about to be rolled out, at least the manual override/disable facility we agreed upon by overloading |url=none/doi/pmc/<other-identifier-parameter-name>/<url>... --Matthiaspaul (talk) 12:26, 8 August 2020 (UTC)

If it was not clear, I oppose the use of |url=none/doi/pmc/.... Introducing these non-URL values in a field which currently expects URLs is likely to break many tools and scripts - this is a bad programming practice. Beyond that, I am yet to see an example of a citation where a |url=none would be desirable. For |url=doi and others, I would simply let people add those URLs directly in the URL field - there is no need for the additional complexity and indirections. If bots currently remove such URLs, they should stop doing that. − Pintoch (talk) 17:31, 8 August 2020 (UTC)

I agree that populating the url field with non-url content is not a good practice. I would make an exception for |url=none as long as the current dependency of |archive-url= is in place. I am fairly certain that reliable archives may have fascimiles of originals that can no longer be found. 98.0.246.242 (talk) 00:04, 9 August 2020 (UTC)

Alright then, in the previous discussions I raised specifically this concern as a potential problem twice, but over the course of weeks nobody confirmed it as a real problem, so weighing the various pros and cons we more or less settled on |url=none/doi/pmc/... (and reserved |chapter-url=none/doi/pmc/... for potential future use).

Avoiding this and leaving |url= (and |chapter-url=) for actual URLs only, the alternative is to overload |title-link=none/doi/pmc/..., instead. (In this case we'd have to support our special "accept this as is" ((syntax)) for |title-link= to still allow linking to Wikipedia articles in the rare case where they might clash with the bunch of supported identifier parameter names (no problem for the current ones, but could be if the list gets longer, as already requested) - alternatively, in these few cases, we could go through a redirect to avoid the name conflict. So, not a real issue, either.) However, if, at some point in the future, we'd add auto-linking also for chapters (as was already requested as well), the user interface might no longer remain self-expaining, as there is no corresponding |chapter-link= parameter (and no need to add one, as we don't have Wikipedia articles on chapters, or do we?). So, if we would want to override the automatic behaviour in this case, we would have to add these cases as arguments to |title-link= in a sensible way as well - it's definitely doable, the only case we could not control then is when a title is linked to a Wikipedia article (thereby occupying the parameter) and the chapter title should be linked to something different than the automatic default (or not at all).

The third alternative is to have a separate parameter to control the auto-linking behaviour like |auto-link=auto/none/doi/pmc/.... However, I don't like this variant much because it is bad user-interface design (and therefore difficult to remember for users) to scatter related functionality over multiple parameters in particular if they cover mutually exclusive cases like |auto-link=doi |title-link=WP-Article which requires error checking for cases (like "Conflicting link targets defined.") which could be ruled out simply by the underlying parameter logic already (because one parameter can hold only one value). The idea is to make existing parameters smarter rather than to introduce yet more new parameters for special cases which could be covered as part of existing parameters as well.

--Matthiaspaul (talk)

In my opinion, all these proposals try to address a problem that does not exist. Editors can link citation titles with |url= or |title-link= to any URL or internal link, there is no need to introduce a complex machinery to provide a convoluted alternative. The simpler we can keep these templates, the more reliable and easier to maintain they will be. I still have not seen an example of a citation where disabling auto-linking is desirable, too. − Pintoch (talk) 15:07, 9 August 2020 (UTC)

News article on two pages

Is there a best practice for citing a news article that starts on page 1, for instance, and continues on page 12? For instance, I have an article clipped on Newspapers.com and I had to do two separate clippings to get the whole thing. https://www.newspapers.com/clip/57596810/roads-an-explosive-issue-for-the-1980s/ and https://www.newspapers.com/clip/57596856/roads-an-explosive-issue-for-the-1980s/ and I'd like to link to both clippings in the ref. Thanks! –Fredddie™ 22:22, 19 August 2020 (UTC)

Sure, use the |pages=1, 12 parameter. Regarding two links, I would use |url= for the starting page of the article and append a convenience link (like [1]) at the end of the citation, that is immediately before the closing </ref>. For occasional use, you could also link the two pages |pages=1, 12 (as it happens a lot with documents hosted at archive.org recently), but I don't like this very much and don't recommend it for frequent use.

--Matthiaspaul (talk) 23:23, 19 August 2020 (UTC)

Translating into Sanskrit

This template(फलकम्:Cite news there) is not translated properly on the sa-WP as can be seen on this page. I asked for help regarding the same in Teahouse and I was asked to offer help in fixing this up on the talk page. It would be nice if someone could direct me regarding the same. --User:श्रीमान २००२ (User talk:श्रीमान २००२) 10:02, 18 August 2020 (UTC)

You have more problems than mere translation:

sa:Template:Cite news (not used on your example page) is from 2011 (pre-{{citation/core}})

sa:Template:Cite book is from 2012 and uses a 2012 version of {{citation/core}}

sa:Template:Cite journal looks like it is from 2016 (the history is oddly muddled) also uses the 2012 {{citation/core}}

sa:Template:Cite web is from 2013 and uses a 2013 version of the Module:Citation/CS1 suite

sa:Template:Citation is from 2015 also uses the 2013 Module:Citation/CS1 suite

I presume that sa.wiki has other cs1|2 templates (cs1 list here) so I expect that they are in a similar state of disarray.

My recommendation is to upgrade all of the cs1|2 templates to the current version of the Module:Citation/CS1 suite (not as simple as it sounds). The module suite has better support for other languages (you still have to translate the English into Sanskrit but nearly all of those translations are done at Module:Citation/CS1/Configuration. If the sa.wiki community decide to do this, and if you require assistance, let me know, I can help.

—Trappist the monk (talk) 11:39, 18 August 2020 (UTC)

@Trappist the monk: Thanks, I would bring it to notice of an admin of the sa-WP.--User:श्रीमान २००२ (User talk:श्रीमान २००२) 08:57, 20 August 2020 (UTC)

Follow up: Mode marker script

As a follow up to a previous discussion, a new script to highlight CS1/CS2 styles is available. See User:BrandonXLF/CitationStyleMarker for instructions and customization options. If you go in the 'Gadgets' tab of your preferences and select the 'Install scripts without having to edit JavaScript files' option at the bottom of the 'Editing' section, you can then go to User:BrandonXLF/CitationStyleMarker.js and simply click on the big 'install' button in the infobox to install it.

Thanks to BrandonXLF for the script. Headbomb {t · c · p · b} 22:32, 25 August 2020 (UTC)

Potential bug with Template:Cite book

Template:Cite book has a problem with the URLs used here. Veverve (talk) 16:33, 28 August 2020 (UTC)

Not a bug, just a limitation. The fix is explained (in somewhat technical terms) when you follow the help link. The URL may need to be converted. See the link following the text "Online tools are available to internationalize URLs that are written in non-Latin scripts:". – Jonesey95 (talk) 17:21, 28 August 2020 (UTC)

"Title in italics"?

Help:Citation Style 1#Titles and chapters now says title The title of the cited source. Titles are displayed in italics. However, CS1 instance Template:Cite web#Title says: title: ... Displays in quotes., and this is how it is shown indeed. Looks like the Helppage needs adjustment? -DePiep (talk) 07:53, 26 August 2020 (UTC)

This is because in cs1/2 there are different definitions of title. In some cases, title refers to the work, eg when citing books. In other cases, title refers to in-source locations such as articles or webpages eg when citing web-based sources. 64.61.73.84 (talk) 00:14, 27 August 2020 (UTC)

Could be, but why is the /doc wrong? -DePiep (talk) 00:24, 27 August 2020 (UTC)

The doc is not wrong. It accurately documents the code. There is nothing wrong with the code either. It accurately applies flawed design primitives, such as data labels that apply to different data fields. Why? Because... Start searching for it from around, I don't know, 2005? 64.18.9.242 (talk) 00:49, 28 August 2020 (UTC)

I do not understand what this reply says. -DePiep (talk) 22:38, 28 August 2020 (UTC)

One label (title) is used to refer to the source (the work), as in {{cite book}} and to an in-source-location (an article or a webpage) as in {{cite journal}} or {{cite web}}. This is a design flaw, not a logic or presentation one. 98.0.246.242 (talk) 23:05, 28 August 2020 (UTC)

I agree with the IP. This all looks as it should. --Izno (talk) 18:45, 30 August 2020 (UTC)

To me, editor here, title is no a label but a parameter |title=. -DePiep (talk) 20:50, 30 August 2020 (UTC)

Not to beat this to death, but "label" was used in a strictly technical context, which was the wrong way to go about it, apparently. In lay terms you are correct, title is indeed the parameter in question. In geekdom, "parameter" is ambiguous. When one mentions "parameter", do they refer to some value(s) the parameter can take (eg New York Times) or to the parameter itself (eg |newspaper=)? The latter is the parameter name or label. The former is the parameter value or the variable. Sorry for the diversion into tech mumbojumbo. 98.0.246.242 (talk) 01:50, 31 August 2020 (UTC)

If |title= has different meanings in different situations (all fine), each local /doc should say so. But the docs for {{Cite book}} and {{Cite web}} do not differ in this ("Displays in italics"). -DePiep (talk) 20:50, 30 August 2020 (UTC)

The SpongeBob Movie: Sponge on the Run

Trying to create a citation for the recent SpongeBob film so that it can be used as a source for the credits/cast/characters in the film, but what exactly should be the best way of going about this citation? Here's the best I believe I could do using Template:Cite AV media:

{{cite AV media|medium=Motion picture|people=Hill, Tim (Director)|date=August 14, 2020|title=The SpongeBob Movie: Sponge on the Run|publisher=[[Paramount Pictures]]|language=English}}

See also here, where it says what things should be included, some of which I wasn't entirely sure how to include in the citation. Magitroopa (talk) 20:07, 30 August 2020 (UTC)

I believe you have correctly formatted a workable citation. It is not necessary for every field to be included, even when it is relevant. You may include the minimum that would make a reader understand what you are citing and how verifying information could be discovered. Some people may be thankful for any and all relevant info in a citation. Others may find the complete form confusing or verbose. 98.0.246.242 (talk) 01:32, 31 August 2020 (UTC)

Access date for newspapers

The documentation at Template:Citation Style documentation/url asserts that Access dates are not required for links to ... news articles with publication dates.

Supplying access dates is surely essential where the url is not guaranteed to be stable. Newspapers regularly revise their content – even stories with publication dates – and older news stories may be archived to a different url or possibly removed altogether. How can we justify giving the advice that access dates are not needed? Where did the consensus for that come from? --RexxS (talk) 22:43, 25 August 2020 (UTC)

This should be update to say that those are not required for links to online access of printed material or online stable versions (e.g. online scientific journals which issue corrections via separate erratas and corrigendum) Headbomb {t · c · p · b} 22:55, 25 August 2020 (UTC)

Apparently there have been at least five variations of the advice:

• Not required for web pages or linked documents that do not change; mainly of use for web pages that change frequently or have no publication date – diff
• required for links to news articles on commercial sites (these are changed from time to time, even if also published in a physical media) – diff
• but should be used for links to news articles on commercial web sites (these can change from time to time, even if they are also published in a physical medium) – diff
• but should be used for links to news articles on commercial websites (these can change from time to time, even if they are also published in a physical medium) – diff
• not required for links to published research papers, published books, or news articles with publication dates – diff

It would seem then, that the community don't know what they want. If they don't know, what makes you think that we, paddling around in this little backwater eddy, are going to know?

—Trappist the monk (talk) 23:36, 25 August 2020 (UTC)

Reasoned argument? Occam's razor: If you find a citation-related topic that both Headbomb and I can agree on, chances are it's got some validity. --RexxS (talk) 22:14, 26 August 2020 (UTC)

In my opinion, this kind of "advice" does not belong into the citation template documentation at all -- it's not a guideline, and shouldn't become one.

It is my observation that in recent years several individuals have (ab)used the prominence of the citation template documentation (despite its many weaknesses) as a vehicle to push their personal point of view how citations should be formatted, and by means of Citation Bot some of these changes have even been forced into articles without many options for disagreeing users to respond (unless they were prepared to open the drama box -- but most serious contributors have better things to do). For some time, Citation Bot edits could even be carried out anonymously while the bot maintainers denied any responsibility for the edits, and if editors pulled the plug and blocked Citation Bot from editing articles, even this was removed by some CB pushers. In some cases this reached almost militant levels, while admins looked away and good editors left the project in frustration. While the current RfC is ongoing, many voiced opinions there already shockingly demonstrate how far off CB is from carrying out only edits which have community consensus (however, this also becomes obvious from studying the CB talk archives with endless lists of unaddressed complaints). Some of this can be traced back to some guidelineish statements having crept into our template documentation which were then cited elsewhere as if it was a guideline. Some editors even edit-war over it when users are trying to clean up the documentation.

The bottomline: In the template documentation we should just describe how to use the various parameters on a technical level (purpose, syntax, rendering, dependencies). Issues like what kind of URLs are "allowed" to be included, if they should be free or not, when access-dates should be given (beyond when they might be technically required), if publishers or ISSNs should be specified for periodicals, which combinations of identifiers are allowed or not, if legal company names or only trade names are to be used, and similar questions are ultimately up to individual editorial judgement of those who provide citations under consideration of the relevant policies and guidelines (and CITEVAR) -- this doesn't belong into our template documentation. --Matthiaspaul (talk) 23:56, 26 August 2020 (UTC)

This is a technical matter. Basing usage of access parameters on the stability of the content may be a narrow case. Virtual media may become unavailable for a variety of reasons and for a variety of time-periods. Obviously, sources on physical media are not subject to such disruptions, which may be platform-wide where virtual media are concerned. Not all physical copies of a journal will disappear suddenly. A disruption that affects a website that carries such a source's content is altogether a different thing. Verifying that source would then mean digging for mirrors and archives. This is a burden on readers verifying the citation, and presents other issues re: the archive's/mirror's reliability. In cases of disruption, access dates are a pointer to the "correct" snapshot or iteration of the original medium (website or other virtual location). This is not a remedy, but it is helpful, imo. 64.61.73.84 (talk) 00:05, 27 August 2020 (UTC)

I think the guidance is reasonable. Access date is primarily for things that change. While web resources generally can change (as in the first formulation, mainly of use for web pages that change frequently or have no publication date), I expect news outlets will appropriately identify those changes when they occur ("error corrected date X" "update date-time Y with new info Z"), in the article in question itself. Websites which don't tell the reader something has changed after publication is a smell for unreliability). That said, this seems like a reasonable wider discussion topic given the flip flops that Ttm evidences above. I'm willing to believe that the above diffs came after some discussion here, so perhaps we should review those first. --Izno (talk) 18:56, 30 August 2020 (UTC)

Considering that access dates are routinely removed when no url is specified, I think it's safe to assume that we record access dates only for online resources. News sources publish stories online, which are regularly used used as sources in articles and the access date is regularly supplied. The present guidance is being used to remove access dates if the publication date is also included. I believe that is not a good idea because newspaper and other news source (e.g. BBC) websites often change the story's url when archiving stories. It's not an issue of the story changing; it's an issue of not being able to find the story because the url has gone 404. Leaving the access date in place can help in finding archived copies whether or not the publication date is known. What benefit is there in removing access dates for news sources with a publication date? --RexxS (talk) 13:55, 31 August 2020 (UTC)

Because the page has an actual date, it is still just as findable on an archive site, which is the true remedy for the problem. If the article is dated January 1, 2020 and then gets moved January 2, or today August 31, an access date isn't any more helpful than the publication date for re-finding the page. You have an upper and lower bound regardless. If the original webpage was not archived at all, you're SOL in any regard and need to replace the citation--or just remove the URL, if you can find an offline copy and provide sufficient details to locate the article therein. In all regards, an access date duplicates the pertinent utility of the publication date and should then be removed accordingly. --Izno (talk) 14:23, 31 August 2020 (UTC)

Auto-linking titles with free DOIs

Extended content

Hi all, I would like to propose extending the auto-linking mechanism (providing a default value for |url= when |pmc= is available) to also cover |doi= with |doi-access=free. In short: if |url=, |chapter-url= and |pmc= are not set, but |doi= and |doi-access=free are set, the title of the citation would be linked using the DOI. Example With the following code: {{cite journal | author = Hoffman S.J., Lavis J.N., Bennett S. | year = 2009 | title = The Use of Research Evidence in Two International Organizations' Recommendations about Health Systems | journal = Healthcare Policy | volume = 5 | issue = 1| pages = 66–86 | doi = 10.12927/hcpol.2009.21005 | doi-access = free }} You would get the same result as if |url=https://doi.org/10.12927/hcpol.2009.21005 was set: Hoffman S.J., Lavis J.N., Bennett S. (2009). "The Use of Research Evidence in Two International Organizations' Recommendations about Health Systems". Healthcare Policy. 5 (1): 66–86. doi:10.12927/hcpol.2009.21005.{{cite journal}}: CS1 maint: multiple names: authors list (link) Motivation As a reader, it is natural to click on the title of a citation to access it. Clicking on identifiers is less intuitive, even when they are marked as free with . In fact, editors often fill the |url= field with the URL the DOI resolves to, to obtain this linked title (see statistics below). When an article is free to read from the publisher, it is generally preferable to point readers to the publishers' version. Not only is it the version of record, but this is also the place where any errata or retraction will be published, and the DOI link is less likely to rot. If for some reason another version is preferred (because it is the one the editor read when citing the work, or because it is more directly accessible than via the publishers' website), it would still be possible to override the link with |url=, just like for |pmc=. Since |pmc= is already used for auto-linking, I propose that |pmc= has priority over |doi=+|doi-access=free to generate the title link. This will ensure that all titles currently linked will not be changed by this move. PubMedCentral also stores versions of record, in a clean and readable way, so I do not think there is a need to override them. Similar ideas have been suggested before, for instance here by User:Headbomb. Statistics Here are some figures extracted from the enwiki dump of 2020-04-20. At this point, 189,097 citations had a |doi= and |doi-access=free set. 1,773 (1%) of these also had a |pmc= 28,012 (15%) did not have a |pmc= but had a |url= or |chapter-url= 159,312 (84%) had none of |pmc=, |url= or |chapter-url=, so their title was not linked, but would be linked using the DOI with this proposal. Among the templates with both a free-to-read DOI and a manually-specified URL, 66% of these are equivalent to the DOI link (they eventually redirect to the same website) or the URL points to the publishers' website but no longer works (404 error). This figure was obtained by randomly sampling 100 pairs of DOI/URL from the dataset and comparing the links manually. This shows that editors are keen to link the title of their citations. This encourages link rot since they rarely use |url=https://doi.org/... but rather the URL the DOI redirects to. Discussion Do we need to have an RFC about this? I am available to change the Lua code in the sandbox to implement the move if there is consensus for it. − Pintoch (talk) 12:55, 23 April 2020 (UTC) Previous relevant RFCs include: Wikipedia:Village pump (proposals)/Archive 135#Access Locks: Citation Template Behaviour RFC (Aspect B4) Help talk:Citation Style 1/Archive 59#RfC on linking title to PMC I don't think there is consensus for this change. Kanguole 13:14, 23 April 2020 (UTC) Support There was an RFC about this a while back, and there was fairly widespread support for the idea (see B4 above, nearly every comment was in support, I have no idea how the closer got no consensus from this, and most the opposes didn't were self-contradictory or based on minor technical details that can be easily solved). Auto-linking would be absolutely great. The only things that really needs to be decided is two things What's the default hierarchy (e.g. PMC > free DOI > free Bibcode > etc...). This should only apply to garanteed version of records, and not include preprints/general repositories like arXiv and CiteSeerX How do you overrule the default hierarchy (e.g. |auto-url=bibcode, |auto-url=citeseerx, etc...) Headbomb {t · c · p · b} 13:15, 23 April 2020 (UTC) Also I wouldn't say clicking on identifiers is any less intuitive. However auto-linking the title is certainly more accessible. Headbomb {t · c · p · b} 13:18, 23 April 2020 (UTC) My intention was to baby-step this by only adding DOIs first, as I think this is more likely to pass as a RFC (because the DOI normally points to the version of record) and does not require introducing heavy machinery to configure the auto-linking precedence. But I am not opposed with auto-linking other identifiers if there is broad support for it. The risk is repeating the RFC linked above (B4), and proposing an overly complicated system which puts off editors. − Pintoch (talk) 13:26, 23 April 2020 (UTC) I'm entirely fine by starting with DOIs autolinking (with something like PMC > DOI, with |auto-url=doi over-riding the default) and then phasing in the others afterwards. Headbomb {t · c · p · b} 13:39, 23 April 2020 (UTC) There was substantial support in that RFC, but there was also substantial opposition, which would be why that aspect was closed as "no consensus". Kanguole 13:47, 23 April 2020 (UTC) Support the proposal and thank you for the statistics. I think this proposal is consistent with consensus on how to work towards the overarching goal of Wikipedia:Verifiability. There was strong support for adding the PMC parameter and use it for links, I think it was a success. Given recent discussions and requests, I believe it would also appropriate to "linkify" the title when |hdl-access=free is set. For context, this includes many Hathi Trust URLs, like [2] which goes to [3]. These could be treated like PMC (used before the DOI, but after PMC), so as to preserve the links which no longer appear after a few thousand Handle System URLs were converted into |hdl= only. Nemo 13:24, 23 April 2020 (UTC) The hdl discussion which you linked to is as yet unresolved, so brought it back from the archive. If hdl is included, as you propose, that would be a firm oppose from me, as long as no clarity is given where we stand with that discussion. About the doi, I'm mildly positive. The hdl's access status is often difficult to define: it may be "free" when one visits the website from one country, and "non-free" if accessing the website from another (for that reason, I suppose, WorldCat's indications of whether a book is or isn't freely accessible at Hathitrust are notoriously unreliable) – dois have this problem far less in my experience: mostly either it's free for all, or subscription/registration for all. Anyway, bots should stop removing urls if there is a doi (there too, I don't know whether Citation bot or any other bot is still doing that – here's a beauty of one bot inserting doubled links in the same type of citation where another bot was removing somewhat similar redundancies). So there too, although I'm mildly positive for the doi's, the idea would be a firm "no" as long as it can not be ascertained that presence or absence of urls and dois is *as decided by human editors*, not what one bot after another makes of it. --Francis Schonken (talk) 14:10, 23 April 2020 (UTC) You seem to be very confused about just about everything here. There is no "warring bots". Citation bot cleans up a DOI url to a |doi= parameter as it should (much like it cleans up handle links to |hdl=). What GreenCBot does there is adds a free archived version of the PDF. There was an issue with GreenC bot, which has subsequently been fixed. This has nothing to do with Citation bot, or auto-linking free DOIs. Headbomb {t · c · p · b} 14:25, 23 April 2020 (UTC) Oppose as in the above RFC: Links for identifiers are generated anyway, but duplicating them on the title adds nothing but a bit more complexity and blue text. If a reader sees a linked title, is it an explicit |url= or a copy from one of the identifiers? If there is more than one identifier, which URL was copied? Let's avoid all that, by not copying. (I know we already copy links from |pmc=, and I'd like to remove that, but concede that there won't be consensus for that.) Kanguole 13:47, 23 April 2020 (UTC) "If a reader sees a linked title, is it an explicit |url= or a copy from one of the identifiers?" Why does that even matter? The only thing that should matter here is getting the reader to the free version of record. We should be consistent and do it for DOIs as well as PMCs Headbomb {t · c · p · b} 13:51, 23 April 2020 (UTC) I concur - I think most readers do not care about identifers. They should not need to know about the difference between a DOI and a HDL to read a cited article. − Pintoch (talk) 14:00, 23 April 2020 (UTC) It matters because simplicity of interface is important. I am opposed to having this wedge pushed any further in. Kanguole 14:04, 23 April 2020 (UTC) "Click on the title" is about as simple as it gets. Headbomb {t · c · p · b} 14:08, 23 April 2020 (UTC) If we duplicate free DOI URLs as well as PMC ones, the next step will be to duplicate the other free URLs, and then we will need a priority ordering as suggested above, and it will not be a simple matter for a reader to work out what they are going to get if they click on the title. As you say above, clicking on identifiers is simple (particularly when they are marked as free). Kanguole 14:21, 23 April 2020 (UTC) will not be a simple matter for a reader to work out what they are going to get if they click on the title They are going to get a free version of the article. Headbomb {t · c · p · b} 14:28, 23 April 2020 (UTC) Especially if you're on a desktop device and can hover over it, to see what link is actually there. (Don't tell me if you click on links without checking to see whether the alleged link is the real one, okay? That way lies hacked accounts.) I think that the assumption that readers know what those weird numbers at the end of the citation mean is extremely doubtful, especially for the vast majority of readers without graduate degrees. I think it would be ideal to have a link on the title whenever possible, even when that link is a duplicate. WhatamIdoing (talk) 15:17, 23 April 2020 (UTC) My position is the same as in the previous discussion. Yes, you'll need an RFC. No, I don't think here is where you should have it given the even split down the middle last time. WP:MOS or WP:VPPRO or WP:CITE. --Izno (talk) 16:45, 23 April 2020 (UTC) Thanks, I'll start an RFC at WP:VPPRO. − Pintoch (talk) 18:52, 23 April 2020 (UTC)

RFC

@Kanguole, Headbomb, Nemo bis, WhatamIdoing, and Francis Schonken: Here is an RFC: WP:VPPRO#Auto-linking_titles_in_citations_of_works_with_free-to-read_DOIs. − Pintoch (talk) 19:09, 23 April 2020 (UTC)

And I forgot to ping Izno, sorry. − Pintoch (talk) 20:52, 23 April 2020 (UTC)

Is it time to ask someone to close the RfC? Nemo 06:10, 2 May 2020 (UTC)

Early closes of RfCs can be proposed at WP:ANRFC (without much guarantee such early close proposal would be enacted upon). --Francis Schonken (talk) 06:15, 2 May 2020 (UTC)

I have done so. I agree it is early in comparison to the rest of the backlog but the participation has been good already and the consensus seems pretty clear. − Pintoch (talk) 17:45, 2 May 2020 (UTC)

Why? Is this a race? Will the sky fall if the rfc isn't decided now? I think that you should withdraw the early-closure request unless you can show that a normal rfc duration is somehow detrimental to something (what that might be, I don't know).

—Trappist the monk (talk) 17:55, 2 May 2020 (UTC)

There's no such thing as "early closure" of this RfC, which didn't have an advertised end date. "An RfC should last until enough comment has been received that consensus is reached, or until it is apparent it won't be. There is no required minimum or maximum duration" (Wikipedia:Requests_for_comment#Duration). One week is a rather common timescale for a number of decision-making processes on the English Wikipedia, we're not in WP:SNOW territory. Sure, the discussion can continue a few weeks if there's a point to it, but none has been offered so far. Nemo 18:12, 2 May 2020 (UTC)

Legobot appears and adds an {{rfc}} template. Thirty days later, Legobot returns and removes the {{rfc}} template. rfcs held here on this page over the last little while have all ended after Legobot removed the {{rfc}} template. Is there a reason why it is necessary to close the rfc before the thirty days?

—Trappist the monk (talk) 18:49, 2 May 2020 (UTC)

No opinion on whether or not this should be closed, but flipping the question around, is there a point to keeping the RFC open when the outcome is obvious? Headbomb {t · c · p · b} 18:51, 2 May 2020 (UTC)

I'm indifferent. When the norm around here has been to wait for Legobot to remove the {{rfc}} template, it just seems odd to me that there is this push to closure. I'm curious to know why there is such a rush.

—Trappist the monk (talk) 19:13, 2 May 2020 (UTC)

There is no particular rush, just excitement about seeing the citation templates get better! Is it not thrilling when we have an opportunity to deliver a simple change that will make editors and readers' lives easier? Seeing the surge of enthusiasm for the move is definitely motivating me to implement it swiftly. But I will not make the change in the sandbox until the RFC is closed. A WP:SNOW closure is proposed on the RFC, make sure you make yourself known if you oppose this closure (and more generally, your participation in the RFC would be welcome, of course, but I also understand if you prefer to remain neutral). − Pintoch (talk) 16:37, 4 May 2020 (UTC)

Implementation

The RFC has been closed, so I have implemented the change in the sandbox:

Cite journal comparison

Wikitext	{{cite journal|author1=Hoffman S.J.|author2=Lavis J.N.|author3=Bennett S.|doi-access=free|doi=10.12927/hcpol.2009.21005|issue=1|journal=Healthcare Policy|pages=66–86|title=The Use of Research Evidence in Two International Organizations' Recommendations about Health Systems|volume=5|year=2009}}
Live	Hoffman S.J.; Lavis J.N.; Bennett S. (2009). "The Use of Research Evidence in Two International Organizations' Recommendations about Health Systems". Healthcare Policy. 5 (1): 66–86. doi:10.12927/hcpol.2009.21005.
Sandbox	Hoffman S.J.; Lavis J.N.; Bennett S. (2009). "The Use of Research Evidence in Two International Organizations' Recommendations about Health Systems". Healthcare Policy. 5 (1): 66–86. doi:10.12927/hcpol.2009.21005.

Let me know if you spot any issue with the implementation. Thank you to everyone who participated! − Pintoch (talk) 18:32, 22 May 2020 (UTC)

On title-link and other things

It already starts to get nasty...

• The |title-link= parameter is not supported properly. If specified it must override any other settings. Right now (also in the current version), it throws the non-sensical error message: "|pmc= missing title" (or, in the sandbox version, also "|doi= missing title" if |pmc= is not given).
• For cite templates supporting chapters (like with |mode=book), there are a number of corner-cases if |chapter-url= is given instead or in addition to |url=, and with or without |chapter= given in addition to |title=. By default, |title-link= and |url= are for |title=, and |chapter-url= is for |chapter=. However, if |chapter=, |url= and |title-link= are not given, |chapter-url= should be used for |title= as well.
• There is no parameter to define which identifier should be used if multiple are available, or to force the auto-linking feature to be disabled. There are cases where linking to the doi or pmc is undesirable. So, we need something link |auto-link=none/pmc/doi - alternatively, the |title-link= parameter could be used for this as well, like |title-link=none/pmc/doi/... (where ... could be any Wikipedia article name (except for those few tokens used to specify an identifier) and IMO the default should be "none").

--Matthiaspaul (talk) 19:45, 24 May 2020 (UTC)

Just as a clarification to your "non-sensical error message": The title-link parameter is for internal wikilinks on titles, most often used for books for which we have articles. It is an error to try to place both an internal wikilink and an external url link on the same title. The unclear error message that you are seeing is from that error. So I agree with your main point here: autolinking must detect the situation that there is an internal wikilink on a title, just like it detects the situation that there is an explicit url= link, and not try to autolink in that case. It would also be helpful to have a way to disable autolinking more generally, but I think using a link=yes parameter to specify link=no is not exactly an intuitive design. —David Eppstein (talk) 20:00, 24 May 2020 (UTC)

@Matthiaspaul: good point about the issue with |title-link= - that was already an issue with |pmc= actually. I have disabled auto-linking when a |title-link= is provided - I think that is quite consensual? For your second point, could you give some examples of the issues you have noticed using {{cite compare}}? About adding a parameter to disable auto-linking in general, I think the best way forward would be that the RFC participants play by the rules and accept the consensus instead of trying to introduce backdoors in its implementation. You are of course welcome to start a new RFC once this change has been deployed, or challenge the closure of this RFC if you think it was conducted inadequately. Thank you! − Pintoch (talk) 21:44, 24 May 2020 (UTC)

I disagree. Use of |title-link= must not usurp a link to the source.

Auto-linking |title= with |pmc= / |doi= is only supported for {{cite journal}}. {{cite book}} has nothing at all to do with title auto-linking from identifiers; it does not happen.

I do agree that the error message is less than helpful; it is there to catch the legitimate case when |url= is set but |title= is not set. I have sandboxed a correction that will emit the message when |url= and |title-link= are both set. I did not save that because I think that the edit granting |title-link= priority over |url= should be reverted.

—Trappist the monk (talk) 22:12, 24 May 2020 (UTC)

@Trappist the monk: fair enough, I am happy with your solution too! Reverting my change now. − Pintoch (talk) 22:14, 24 May 2020 (UTC)

Here is the fix:

Cite journal comparison

Wikitext	{{cite journal|journal=Journal|pmc=12345|title-link=Title|title=Title}}
Live	"Title". Journal. PMC 12345.
Sandbox	"Title". Journal. PMC 12345.

Cite book comparison

Wikitext	{{cite book|title-link=Title|title=Title|url=//example.com}}
Live	Title. {{cite book}}: URL–wikilink conflict (help)
Sandbox	Title. {{cite book}}: URL–wikilink conflict (help)

—Trappist the monk (talk) 22:48, 24 May 2020 (UTC)

There are notable journal papers for which title-link would be appropriate and for which autolinking should not happen when title-link is set. Grothendieck's Tôhoku paper, as an example (of a notable journal paper, not of one with an open doi). As for autolinking not being available for {{cite book}}: whyever not? Books can have dois and I don't see why those dois might not be open access in some cases. —David Eppstein (talk) 04:01, 25 May 2020 (UTC)

No doubt. Maybe that is why {{citation}} doesn't have auto-linking capability:

{{citation/new|first=A.|last=Grothendieck|authorlink=Alexander Grothendieck|title=Sur quelques points d'algèbre homologique |title-link=Grothendieck's Tôhoku paper |journal=[[Tôhoku Mathematical Journal]]|volume=9|issue=2|series=(2)|pages=119–221|year=1957|mr=0102537|doi=10.2748/tmj/1178244839|doi-access=free}}

Grothendieck, A. (1957), "Sur quelques points d'algèbre homologique", Tôhoku Mathematical Journal, (2), 9 (2): 119–221, doi:10.2748/tmj/1178244839, MR 0102537

The same can be applied to books.

—Trappist the monk (talk) 13:55, 25 May 2020 (UTC)

@Trappist the monk: Just to be sure I understand: how are users supposed to solve the error that arises when both |pmc= and |title-link= are set? Remove one of them? Is that really satisfactory? I do not really see why we would forbid people from wikilinking the title if the PMC link is available as an identifier. Just like |url= can be used to override the link generated by auto-linking, I would expect the same of |link-title=. Of course we are talking about very rare corner cases, but it is worth getting them right. I am also not sure why {{cite book}} would behave differently: this has been the case so far because |pmc= is probably never applicable to books, but as David points out there are plenty of books with DOIs nowadays. − Pintoch (talk) 05:22, 25 May 2020 (UTC)

While I do not support the auto-linking feature myself (because it violates fundamental rules of good user interface design), if it gets implemented, it should be implemented as consistent as possible across all cite templates. Nobody can expect users to understand that it works for {{cite journal}}, but not for {{cite book}} etc. Implementing this differently and addressing the differences in the documentation would add unnecessary complexity without offering any benefit in return.

Regarding priorities, I think it is paramount that |title-link= cannot be overridden by other possible link targets, because internal links have priority over external links. Since there is no way to support a wikilink and an URL link in the same title and we should not silently suppress information given in a cite template, I think it is desirable to display an error message if both are available at the same time. The normal solution would be to remove |title-link= rather than |url= (or, where applicable, |chapter-url=), but it is also possible the other way around but much less likely to happen.

All the other external links from identifiers which could be used for auto-linking should only be used for the title link if |url= (or, where applicable, |chapter-url=) is not given. However, as this is an optional feature, the presence of external links from identifiers should also never override |title-link= and should never generate an error message, if both are present at the same time (after all, external links from identifiers are still present through their identifiers, so there is no display conflict).

Again, there are cases were auto-linking is inappropriate and there must be some way to override it. Otherwise, people would solve the problem by not providing identifier information in the first place, or not using citation templates at all - hardly a good solution. Also, in the discussion and the RFC, people have already stated that PMC and DOI will just be a start and that they plan to add support for auto-linking further identifiers in the future. As multiple identifiers can be given at the same time, we must define auto-linking priorities to them, and since whatever scheme we will come up with will not work for some cases (PMCs are not always "better" than DOIs, etc.), there must be some way to override this automatic selection and deliberately specify a particular identifier to be used for auto-linking. For this, we could introduce a new parameter like |auto-link=, but I suggest to overload the normal functionality of the |title-link= parameter for this by letting the parameter accept a number of special tokens (that is, the keyword "none" and the parameter names of all supported identifiers). If none of these special symbols like "pmc" or "doi" is given, |title-link= is treated like before - defining the internal link. I think, the corner-case that we'd want to link to an article named after an identifier is very rare (and we could still go through a redirect in this case), so no actual conflict would arise out of this double-use of the parameter. If the selected identifier is not provided, this could either be silently ignored or a warning be given.

One more thought: As already said, in contrast to the outcome of the RFC my personal preference for the auto-selection default would be "none", so that it would have to be deliberately enabled where actually needed (and possibly useful). If it would be implemented this way, we would not even need a "none" keyword and also would not have to set up priorities for the auto-selection; |title-link=doi would enable auto-linking for the |doi=, |title-link=pmc for the |pmc=, ..., |title-link=Title would link to Title etc. This would reduce unnecessary complexity, be more predictable (no surprises because the title auto-linking feature is only used when deliberately enabled) and much easier to explain in the documentation:

"If the title link should duplicate one of the links given as identifiers, you can select the desired identifier through |title-link=<identifier-parameter> without having to duplicate the identifier link as |url=".

Clean and easy.

--Matthiaspaul (talk) 12:42, 25 May 2020 (UTC)

because internal links have priority over external links I think that a citation is needed for that. In cs1|2, external links always have priority over internal links. We often see stuff like:

{{cite book |title=[[Abraham Lincoln]] |url=//example.com}}

which, because a single link cannot target multiple locations, produces an error message:

[[Abraham Lincoln]]. {{cite book}}: URL–wikilink conflict (help)

|title-link= is handled in the same way; |url= links the title and the citation emits an error message:

{{cite book/new |title=Abraham Lincoln |title-link=Abraham Lincoln |url=//example.com}}

Abraham Lincoln. {{cite book}}: URL–wikilink conflict (help)

In these cases we do not silently suppress information given in a cite template.

this is an optional feature Ha! For |pmc=, not so (alas). When I disabled the oddity that is {{cite journal}} with |pmc= set and |url= not set (a comment that used to be in the code) I died on that hill in a battle with WP:MED. While I have some sympathy for your |title-link= solution (I would have chosen to add keywords to the various url-holding parameters instead) you too, will die on the hill if you attempt to switch WP:MED from the fully automatic |pmc= to some sort of semi-automatic mechanism. Were we to implement a semi-auto-link mechanism, we will still have the abomination of special-case code because |pmc= will be fully automatic.

—Trappist the monk (talk) 15:07, 25 May 2020 (UTC)

Thanks for correcting me regarding that |url= takes priority over |title-link=. However, the basic argument remains valid that both cannot exist at the same time and the user has to remove one of them to get rid of the error message - which one should be a deliberate decision of the editor.

Regarding auto-selection or not, regardless if auto-selection for auto-linking will be enabled by default (by absense of a |title-link= parameter) or only on demand (through |title-link=), we need a parameter to either override or control the behaviour. If we use something like |title-link=doi (my suggestion) or |url=doi (your suggestion) for this does not matter much, however, I find |title-link= more intuitive to remember for this (and it might cause less confusion for bots trying to make sense of invalid URLs like "doi".).

Regarding the MED folks, what is so difficult for them to add something like |title-link=pmc to a citation, if it makes the auto-linking system as a whole more consistent and easier to understand for the majority of people outside of MED topics?

--Matthiaspaul (talk) 18:04, 30 May 2020 (UTC)

Followup regarding I think, the corner-case that we'd want to link to an article named after an identifier is very rare (and we could still go through a redirect in this case), so no actual conflict would arise out of this double-use of the parameter.

Instead of going through redirects to work around a conflict of a desired target article name with a parameter name for an identifier, we could use the "((just do it))" syntax to enforce the interpretation as article name rather than parameter name. So |title-link=((pmc)) would link the title to pmc instead of retrieving the link target from the |pmc= parameter, same for the other supported identifiers.

--Matthiaspaul (talk) 18:04, 30 May 2020 (UTC)

In the first sentence of the doi auto-link RfC you mention CS1/2 and in the second sentence you mention |chapter-url=. I guess that when you did your research before proposing the doi auto-link RfC that you did not notice that the pmc auto-link applied only to {{cite journal}}, has always applied only to {{cite journal}}. Go look at the pre-lua versions of the templates to see that.

The Grothendieck citation that I mentioned above is a solution for both journal and book cites with |pmc= or free-to-read |doi=. The help text could use a bit of a tweak to suggest this solution (among other things that need fixing there). And, because it is the first error message mentioned, could also use a bit of a tweak.

—Trappist the monk (talk) 13:55, 25 May 2020 (UTC)

@Trappist the monk: Yes indeed, the RFC text implies that the auto-linking would be deployed not just to cite journal, but to other CS1/2 templates as well, otherwise I would not have mentioned |chapter-url=. Yes, so far it applied only to cite journal, but the point of this RFC is to introduce a change in the behaviour of the CS1/2. So I do not see why we should preserve this restriction: even editors who oppose auto-linking agree that it would not make sense to keep it. So: we should enable auto-linking for all CS1/2 which accept doi or pmc, and disable auto-linking when a link-title is supplied. We cannot expect editors to switch to {{citation}} to disable auto-linking - even if we explicitly pointed to this "solution" in the error message: it just does not make sense. I understand you have a great knowledge of the internals and history of these templates and you probably find most of this very natural, but we cannot require editors to study the History of the English Wikipedia Citation Templates in five volumes, so that they know about the migration to Lua, the removal of pmc auto-linking, the WP:MED rebellion, and so on, to make sense of the historical oddities that we preserve for the enjoyment of future generations. Let's just make this usable. Please revert your own change to add the error message, I will then restore my version and generalize the auto-linking beyond {{cite journal}}. − Pintoch (talk) 15:24, 25 May 2020 (UTC)

Can you show how the error message fix that I made is somehow wrong and, because it is wrong, needs to be reverted?

Here are sixteen {{cite journal}} templates that cover the sixteen possible combinations of |pmc=, |title=, |url=, and |title-link=. Where there is an error message, the template is being asked to do something that it cannot do because of insufficient parameters or too many parameters vying for the use of a single resource:

• 0000: Journal. {{cite journal}}: Missing or empty |title= (help) – no pmc, no title, no url, no title-link
• 0001: Journal. {{cite journal}}: Missing or empty |title= (help) – title-link
• 0010: Journal //example.com. {{cite journal}}: Missing or empty |title= (help) – url
• 0011: Journal //example.com. {{cite journal}}: Missing or empty |title= (help) – url, title-link
• 0100: "Title". Journal. – title
• 0101: "Title". Journal. – title, title-link
• 0110: "Title". Journal. – title, url
• 0111: "Title". Journal. {{cite journal}}: URL–wikilink conflict (help) – title, url, title-link
• 1000: Journal. PMC 12345 https://www.ncbi.nlm.nih.gov/pmc/articles/PMC12345. {{cite journal}}: Missing or empty |title= (help) – pmc
• 1001: Journal. PMC 12345. {{cite journal}}: Missing or empty |title= (help) – pmc, title-link
• 1010: Journal. PMC 12345 //example.com. {{cite journal}}: Missing or empty |title= (help) – pmc, url
• 1011: Journal. PMC 12345 //example.com. {{cite journal}}: Missing or empty |title= (help) – pmc, url, title-link
• 1100: "Title". Journal. PMC 12345. – pmc, title,
• 1101: "Title". Journal. PMC 12345. – pmc, title, title-link
• 1110: "Title". Journal. PMC 12345. – pmc, title, url
• 1111: "Title". Journal. PMC 12345. {{cite journal}}: URL–wikilink conflict (help) – pmc, title, url, title-link

Because cs1|2 prioritizes external links over internal links, these templates render the title linked with the value assigned to |url= (1st) or |pmc= (2nd) when in conflict with |title-link= (or with a wikilink embedded in the |title= value). This is consistent for all cs1|2 templates and should not change. Making it so that auto-links from |pmc= and |doi= yield to |title-link= is inconsistent with the current handling of URL–Wikilink conflicts. To make cs1|2 consistent in a way that makes external links yield to internal links would mean that when editors write stuff like:

{{cite book |title=Title with partially wikilinked [[title]] |url=//example.com}}

would render as:

Title with partially wikilinked title.

And that is nonsense.

If this mechanism is to be made available to all cs1|2 templates and if it can be shown that it is absolutely required that auto-links yield to |title-link= then, no doubt, some sort of override mechanism can be concocted. Yes there are en.wiki articles about books and journal articles. I think that it misleads the reader who, seeing the blue-linked title, clicks it expecting to go to the actual book or journal article, and ends up at an en.wiki article about that book or journal article. It has happened to me. |title=, when linked, is an advertisement to see the actual source that is advertised. That was the whole purpose of this RfC was it not? Click this title to read the source.

—Trappist the monk (talk) 18:08, 25 May 2020 (UTC)

@Trappist the monk: Can you show how the error message fix that I made is somehow wrong and, because it is wrong, needs to be reverted yes, I have done so repeatedly, and so have David Eppstein and Matthiaspaul. You understand the problem very well, you are just trying to instrument this corner case to force the introduction of a parameter to disable auto-linking, because the outcome of the RFC is not to your taste. Statements such as "|title=, when linked, is an advertisement to see the actual source that is advertised" are obviously wrong: in that case, using |title-link= to point to Wikipedia articles should be forbidden, as they violate this rule. You are well aware of the fact that internal and external links are not rendered the same way, see the difference between your cases 0101 and 0110. I will explain one last time what the issue is: raising an error when pmc, title and title-link are present (your 1101 case) is wrong: in this case, the |title-link= should be used to link the title, without raising an error. If an editor uses |title-link= in that situation, they want to use this link on the title, and we need to respect this choice. The auto-linked URL is only a default value, that can be overridden by editors with any external or internal link. I have reverted my own proposal to let you try yours, which does not suit anybody except you: now is the time to accept that. Thank you in advance for your cooperation and good faith. − Pintoch (talk) 18:36, 25 May 2020 (UTC)

I'm pretty sure that you do not understand what it is that my fixed. So, direct comparisons: old v. new from the examples above. Remember what I said: this is an ; nothing more:

• 0111 (old): "Title". Journal. {{cite journal}}: URL–wikilink conflict (help) – title, url, title-link
• 0111 (new): "Title". Journal. {{cite journal}}: URL–wikilink conflict (help) – title, url, title-link
• 1101 (old): "Title". Journal. PMC 12345. – pmc, title, title-link
• 1101 (new): "Title". Journal. PMC 12345. – pmc, title, title-link
• 1111 (old): "Title". Journal. PMC 12345. {{cite journal}}: URL–wikilink conflict (help) – pmc, title, url, title-link
• 1111 (new): "Title". Journal. PMC 12345. {{cite journal}}: URL–wikilink conflict (help) – pmc, title, url, title-link

Presumably you intend to change:

if config.CitationClass == "journal" and not is_set(URL) then

to something akin to:

if not (is_set (TitleLink) or is_set(URL)) then

If that is your change, then the only thing that changes in the examples above is example 1101 which will not show an error. That does not make my wrong as you claim it to be.

You wrote that [I am] trying to instrument this corner case to force the introduction of a parameter to disable auto-linking. Where have I ever said that? In general I am opposed the the introduction of special case parameters of any sort into a template system that is already overburdened with too many parameters. It is highly unlikely that I would now start advocating for such a parameter either openly or sub rosa. I am opposed to special-case anything and gnash my teeth when special cases are unavoidable.

|title=, when linked, is an advertisement to see the actual source that is advertised (my words) is not obviously wrong (your words). The purpose of the RfC was to link |title= to the url created with the |doi= identifier when the source at that doi-identifier-url is free-to-read. A common rationale expressed at the RfC is that a linked title makes it easier for readers to get to that source when they might hesitate to click the doi identifier link because they don't know what a doi identifier is. The linked title is then an advertisement that says to these hesitant readers, "click me, I am a link to the source." Yes, I know about external link icons and the differences between external and internal link colors. That does not change the fact that readers, even those of us who are experienced with how en.wiki citations are rendered, will click blue-linked titles and be disappointed/astonished/frustrated to land at en.wiki's article about the source.

It is, in my opinion, poor practice to link a cs1|2 title to an article about that title. The purpose of a citation is to help readers locate the source that supports content in an en.wiki article. Articles about a source at en.wiki are not WP:RS but linking to such articles through a link at |title= makes it seem that the en.wiki article is the source (after all, it has the blue link). If it is important to mention a particular source in an article, then that mention should be in the body of the article or in an article footnote with standard wikilinks to the en.wiki article about the source. There is a use for |title-link=: citing sources at Wikisource because the link is to the source and the source is reached though standard interwiki links:

{{cite encyclopedia |title=Aard-vark |title-link=s:1911 Encyclopædia Britannica/Aard-vark |encyclopedia=Encyclopædia Britannica |year=1911}}

"Aard-vark" . Encyclopædia Britannica. 1911.

and, no, I don't think that using |title-link= to point to Wikipedia articles should be forbidden. Limited, certainly; forbidden, no.

—Trappist the monk (talk) 23:31, 25 May 2020 (UTC)

Your opinion that titles should not be linked to articles about the title is wrong, and you should feel bad about holding such a wrong opinion. My opinion, which is obviously the correct opinion, is that such links should always be made whenever we have an article about the reference that can be linked from its title. There are very good reasons for linking to an article about a reference: for instance, the article may include multiple free-to-read links where a reference can only have one, or the article may (and probably should) include opinions from the reviewers that may be relevant for how reliable it is as a reference (for an example see Osen's Women in Mathematics, which has sometimes erroneously been used as a reference here). Your opinion is also at odds with the very existence of the title-link parameter. More importantly, it is an editorial decision that should be made by the editors of articles, not enforced by fiat by the behavior of a citation template. If the editors of an article want to control how a title is linked by using a title-link parameter, for a reference that has a pmid or open doi, they should be allowed to control it, just as they can control it by using a url parameter. If the editors of an article for whatever reason decide that a title should not be linked, even though the default would be to auto-link it, they should be allowed to. You should not be inserting your opinions about this into the behavior of the templates. —David Eppstein (talk) 00:04, 26 May 2020 (UTC)

@Trappist the monk: Alright, let me put this differently. No matter whether you understand the problem with your change or not: you have in front of you three editors who disagree with it, and nobody to support it. You should recognize this situation and act accordingly. If you do not, you know what to expect. − Pintoch (talk) 06:28, 26 May 2020 (UTC)

Ok, I take that back, let me just do the change you suggest then - I understood that you were against it. − Pintoch (talk) 06:36, 26 May 2020 (UTC)

Please do not interpret the silence of some of us as agreement with one of the many positions taken above. This discussion appears to have gone far afield from its original purpose, which was to auto-link the title when a DOI was present, unless I am mistaken. It would be great if discussions could stay on topic. If there is a problem with |title-link=, perhaps it should be addressed in a separate thread. – Jonesey95 (talk) 06:51, 26 May 2020 (UTC)

Yes, this was just a corner case of the existing auto-linking mechanism, we should have had this discussion elsewhere in the first place. − Pintoch (talk) 07:00, 26 May 2020 (UTC)

Huh? This is not a corner case. The discussion belongs exactly here. It shows that the whole original proposal, which led to the RfC, was ill-defined. An RfC which cannot be implemented as proposed, because it conflicts with other functionality, is basically useless. What we can still extract from the RfC, even if it was not thought through, is the core message that many people want some form of auto-linking. But we are not going to break existing functionality for this, as the voters in the RfC certainly didn't intend to break existing functionality either. Instead, we will have to find solutions which solve all the issues brought up here before any of this can go live.

--Matthiaspaul (talk) 09:37, 9 June 2020 (UTC)

Auto-linking for book chapters

One issue with auto-linking for book chapters is that the DOI can potentially refer to the entire book or the individual chapter. If no |chapter= is present, I think we can auto-link the title safely. If a chapter is specified then there is a risk that we link the book title with a chapter DOI or that we link the chapter title with a book DOI. The simplest solution I can think of is to disable auto-linking when |chapter= is present, what do you think about that? − Pintoch (talk) 07:00, 26 May 2020 (UTC)

The DOI is supposed to refer to the work actually being cited, so I don't see a problem with linking it. If the citation contains the DOI of the wrong work, it will need to be fixed but there's nothing the template can do to guess it. Nemo 19:15, 7 June 2020 (UTC)

Yeah, but if the DOI only belongs to the |chapter=, not the |title=, the auto-linking should be applied to the chapter rather than the title. Otherwise it would be the same as linking |chapter-url= to |title= even if |chapter= is present. That would be really messy.

--Matthiaspaul (talk) 09:57, 9 June 2020 (UTC)

While this is complicating things even further unfortunately, you bring up a valid point. So far, I thought chapter DOIs would be just some "unofficial" private extension to DOIs by some publishers, but if they are not, we either need some means to declare the type of a given DOI or to provide up to two of them just like we have |url= and |chapter-url=: Perhaps |doi=/|work-doi= and |chapter-doi=?

Disabling auto-linking when |chapter= is present would create even more "unnecessary complexity", making the whole auto-linking thing look unpredictable to normal users. --Matthiaspaul (talk) 09:57, 9 June 2020 (UTC)

A related discussion: Help_talk:Citation_Style_1/Archive_67#Chapter-id_or_Chapter-doi_parameter?

--Matthiaspaul (talk) 11:38, 13 June 2020 (UTC)

I have added |doi= aliases |title-doi= and |chapter-doi= to the sandboxed version of the template, see also [4]. For now, they are treated equally and only one of them is allowed to be given at a time, but by providing these aliases we allow editors to be specific about the type of DOI they are entering. This is important information that may be needed when, following the various discussions, it becomes necessary to distinguish between these two types in the template (and potentially for additional error checking) e.g. so that a chapter DOI isn't accidently used to auto-link to a title etc. (At present, this isn't ruled out - and couldn't so far, because we didn't make any distinction here.) Giving users a chance to (optionally) specify what type of DOI they are providing (when known) reduces the amount of future maintenance work to disambiguate and sort the DOIs (using |doi=) where this information was not provided. --Matthiaspaul (talk) 13:27, 23 August 2020 (UTC)

This is premature. We don't have a design so we should not be making speculative changes to the module suite that may-or-may-not be used in an actual implementation if there ever is an implementation. Implement what we need when we need it; don't clutter the code with stuff that isn't used.

—Trappist the monk (talk) 14:50, 23 August 2020 (UTC)

I wanted to say the exact same today when I saw the edits. I would additionally ask the question whether we open Pandora's box regarding a similar implementation for the other identifiers and the subsequent combinatorial explosion (an issue we have mostly avoided). --Izno (talk) 15:57, 23 August 2020 (UTC)

See also: Help_talk:Citation_Style_1#Deprecating_some_unused_parameter_aliases

--Matthiaspaul (talk) 19:58, 10 September 2020 (UTC)

Proceeding

I understand that the code has been further refined, so we're ready to go, right? Nemo 19:15, 7 June 2020 (UTC)

I don't think so. We still need some generic means to override and optionally disable the auto-linking behaviour (e.g. by the suggested |title-link=none/identifier_parameter_name/[((]article_name[))] extension), and to sort out what to do with chapter DOIs (e.g. by adding |chapter-doi=).

--Matthiaspaul (talk) 10:11, 9 June 2020 (UTC)

As far as I am concerned this is ready to deploy. There is currently no problem with chapter DOIs since the mechanism is only implemented for {{cite journal}} for now - once this is rolled out we can gradually expand to other citation templates if there is consensus around the course of action for chapter DOIs. − Pintoch (talk) 08:37, 14 June 2020 (UTC)

In the current implementation, there is still no way to (optionally) disable auto-linking or to override the auto-selection of PMCs or DOIs. Also, in other threads people are already asking about adding auto-linking support for S2CID as well. This clearly indicates that we need a proper generic solution instead of continuing to add kludges on kludges only complicating things on all fronts (in the implementation, in the documentation for users, and in the maintenance of citations) further in the long run.

In another thread, I was questioning the very need of existence of the |title-link= parameter, because, as was discussed in that thread, |title= allows for internal links as well (even more flexible than via |title-link= - so, if that parameter would have been removed to reduce unnecessary complexity, my proposal to overload the |title-link=none/<identifier_parameter_name>/[((]internal_link[))] functionality to also control the auto-linking behaviour would have been voided as well, however, I meanwhile have come to the conclusion that |title-link= is still needed to link a combined title if both |title= and |script-title= are used at the same time, therefore my suggestion still remains a possible solution, fortunately. If I understood Trappist correctly, he suggested to use something like |url=none/<identifier_parameter_name>/external_link instead. While the parameter name is less intuitive IMHO, it would even have the advantage that the auto-linking of titles and chapter titles could be controlled individually by something like |chapter-url=none/<identifier_parameter_name>/external_link, whereas in my proposal this would be implicit.

(There are two more cases to be properly addressed in the future: Works without any title at all, and works with a so called descriptive title. At present, {{cite journal}} already implements a special case |title=none to specify a non-existing title. The discussion of these cases is not necessarily related to the question how to control the auto-linking behaviour above, but depending on what solution we would actually go for, it might be possible to address this in one coherent way in order to keep the user interface as easy and intuitive to use as possible. However, at present, my suggestion how to address these two cases would not involve |title-link= etc. at all, but other users might have other ideas.)

--Matthiaspaul (talk) 16:04, 14 June 2020 (UTC)

@Matthiaspaul: I encourage you to run RFCs to get approval for the changes you propose. I suggest we do it only after the current version has been rolled out. − Pintoch (talk) 19:54, 14 June 2020 (UTC)

Following-up on the proposals how to implement the auto-link override, I searched old threads for other proposals and found that Trappist the Monk already suggested |url=none/<identifier_parameter_name>/external_link and Headbomb |autolink=no/yes/<identifier_parameter_name> back in 2016. In 2019, Headbomb suggested |auto-url=none, whereas Nardog and I proposed |url=none/<identifier_parameter_name>/external_link, followed by my newer proposal for |title-link=none/<identifier_parameter_name>/[((]internal_link[))]. These proposals are all very similar in nature. In order not to introduce yet another parameter for this, I think, overloading either |url=/|chapter-url= or |title-link=/(|chapter-link=) is the way to go. Overloading the url parameters could have the disadvantage of temporarily causing trouble for bots trying to make sense of these special values. Overloading |title-link= (without introducing |chapter-link=) leaves open the question of how to best cope with chapter identifiers. Therefore, if the potential bot issue could be ruled out or is found to be minor, I would also support Trappist's proposal of overloading |url=/|chapter-url=. Opinions?

--Matthiaspaul (talk) 14:03, 15 June 2020 (UTC)

Just like I respected the few who opposed my initial proposal on this page and required me to go through an RFC process for a change that turns out (surprise) to be very consensual, please respect my own opposition to your proposal. Is it too much to ask for? − Pintoch (talk) 18:25, 15 June 2020 (UTC)

If you cannot draw this from the very fact that I spent considerable time thinking about a solution how to properly integrate the auto-linking feature although I do not consider it useful, let me state that I do respect your opinion. That doesn't mean that I think it is correct.

However, as your RfC did not define the scope of the auto-linking feature and since it ignored addressing important real-world cases (which, however, need to be solved in an actual implemention), the only thing that can be drawn from the RfC reliably is that many people want some form of auto-linking, leaving it up to us to find a proper solution how to integrate it into the existing citation framework. Specifically, what cannot be drawn from that discussion is that they want to enforce autolinking without any means to override it, as you now seem to push for.

In that discussion, here, and in prior discussions over several years, the whole auto-linking idea was always discussed under the assumption that there is some means to override it where necessary. This was requested even by people who think auto-linking is a good idea. It is obvious that we need this before auto-linking can go live. While other implementation details (such as adding support for S2CID or extending the scope beyond {{cite journal}} and thereby indirectly also addressing the case of chapter identifiers) can be delayed, the implementation of some override functionality can not be delayed any further as we now have two rather only one identifier to distinguish (PMCs and DOIs), and not having any means to override the behaviour when the auto-selection would select and link to the wrong identifier is violating WP:CITEVAR and WP:RS. It would destroy the trust we put into citations which were deliberately set up in a certain way and not in another by those who provided the citations originally.

So, for as long as no means to optionally override auto-linking are implemented, I oppose rolling out the currently half-finished implementation - as is, it is potentially harmful to the project.

Let's solve this issue by thinking through if overloading |url= (or |title-link=) is an extensible solution addressing all potentially desired future cases (I think it is) and not causing problems for bots (not sure about that). And if so, then let's implement it, so that auto-linking can go live without causing harm.

--Matthiaspaul (talk) 19:57, 15 June 2020 (UTC)

I have no interest in continuing this argument. I will just let other editors judge your attitude on their own. − Pintoch (talk) 07:29, 18 June 2020 (UTC)

Screenshot for reference: . Nemo 15:37, 12 July 2020 (UTC)

Where are we on this?

What's the progress/holdup on making all |id-access-free= auto-link? It's been over a month since there was movement on this. Headbomb {t · c · p · b} 17:29, 4 August 2020 (UTC)

See also:

• Help_talk:Citation_Style_1/Archive_70#Towards_solving_pending_issues_of_the_auto-link_feature...
• Help_talk:Citation_Style_1#Guidance_on_title-linking:_update_after_RfC
• Help_talk:Citation_Style_1#Manual_override_of_auto-linking

--Matthiaspaul (talk) 11:33, 10 August 2020 (UTC) (updated 07:49, 23 September 2020 (UTC), 18:56, 27 September 2020 (UTC))

Wikidata identifiers

I would like to see a |wikidata= parameter added to CS1. With the advent of things like Scholia (Q45340488) and Template:Cite Q (Q22321052) we now have a large body of scholarly articles indexed in Wikidata. I have manually added a few via |id= (which can be found via Special:WhatLinksHere/WDQ (identifier)). I can understand the resistance to added any and all such identifiers (e.g., Google Scholar paper ID (P4028), Semantic Scholar paper ID (P4011), Microsoft Academic ID (P6366), NII article ID (P2409), etc.; many more can be found at d:Template:Bibliographic properties) however, I believe we should at least support our own WMF identifiers and then the rest can be linked from there. Thank you, —Uzume (talk) 17:20, 8 July 2020 (UTC)

I disagree. The purpose of a citation is to help the reader find a publication. The citation is not meant to be a list of all the places that have cataloged the publication. So please explain how your addition will help the reader find the publication. Jc3s5h (talk) 17:27, 8 July 2020 (UTC)

@Jc3s5h: It sounds like you are advocating more for adding things like Internet Archive ID (P724). Have you looked at some the Wikidata records? For example, Semantics of context-free languages (Q56672530) has many links to actual PDFs of the article via full work available at URL (P953). I do not see how this is much different from the likes of |citeseerx=, etc. —Uzume (talk) 17:31, 8 July 2020 (UTC)

This reminds me of {{cite doi}} and its friends, which were rejected in multiple discussions: Cite doi template substing (Sep 2014) and deprecation of Cite doi templates (Sep 2015). Those discussions mentioned Wikidata as a possible repository for citation information, but I haven't seen any move in that direction. I think the original idea was that something like {{Cite Q}} would be used in place of {{cite journal}} rather than adding wikidata options to CS1 templates. I could be misremembering, though. – Jonesey95 (talk) 17:54, 8 July 2020 (UTC)

@Jonesey95: if it isn't already, {{Cite Q}} could just be a wrapper for CS1 pulling data from Wikidata and filling in fields. —Uzume (talk) 18:02, 8 July 2020 (UTC)

{{cite Q}} uses {{citation}} so that it can do both periodica and book type citations.

—Trappist the monk (talk) 20:03, 8 July 2020 (UTC)

Adding an identifier (as suggested here) is somewhat different than {{cite Q}}, which is the parallel to {{cite doi}}. --Izno (talk) 18:00, 8 July 2020 (UTC)

I'm not enthusiastic about this. There is ongoing discussion (thankfully, mostly elsewhere) where one camp apparently believes that identifiers are wholly ignored by readers because the readers don't know what the identifiers are so won't click them to get to a copy of the source. If that is true, you can be sure that no one will ever follow a wikidata identifier link and, even were they to do so, the wikidata presentation is so user-unfriendly that readers will flee from it.

There is a possible issue of copyright. I notice that the example of Knuth's "Semantics of context-free languages" is behind a paywall at the publisher (doi:10.1007/BF01692511) yet there are 7 purportedly 'free' copies available under the 'full work available at URL' heading at Q56672530. What is the copyright status of all of those?

And then there is the perennial issue of wikidata reliability ...

—Trappist the monk (talk) 20:03, 8 July 2020 (UTC)

Six of the seven copies to which you refer are on .edu domains. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:17, 8 July 2020 (UTC)

Just because a University uses a reference in a course and uploads it to the internet for use of its students (presumably under fair-use terms) does not mean the original copyright holder has surrendered their rights. We need to be very careful about linking to such things. What is appropriate fair use for a student on a course is not necessarily fair use for random members of the public.Nigel Ish (talk) 21:38, 8 July 2020 (UTC)

I checked one of the two instances of WDQ (identifier) being used in a CS1 citation, in this case at Virtuality (software design). When I click through to the Wikidata page, I am met with a page whose title does not match that of the cited journal article, and also with a list of seven links to download the article. This article is not freely available; access to its contents is clearly prohibited by the ACM's terms. Such linking is forbidden by Wikipedia policy, which reminds us that Knowingly and intentionally directing others to a site that violates copyright has been considered a form of contributory infringement in the United States. I did not see a corresponding page at Wikidata; clicking on "Wikidata item" from WP's copyright page leads to an irrelevant page, and I did not find a copyright policy linked at d:Wikidata:List of policies and guidelines. I could just be bad at finding things, though.

TL;DR: It appears that this Wikidata entry, chosen at random, is violating US copyright law, as least as described at en.WP's copyright page. I don't see how we can in good faith link to such Wikidata entries, over which we have no control or oversight. – Jonesey95 (talk) 18:36, 9 July 2020 (UTC)

Apparently, according to the discussion at d:Property talk:P953, the "full work available at URL" property under which those urls were listed was, until 2017, primarily intended and documented to be used for free links to non-free works. I.e., piracy. The property documentation now says it should be for "legal online providers" of the resource, but obviously from your example that's not very carefully enforced. —David Eppstein (talk) 19:01, 9 July 2020 (UTC)

It is one thing to criticize Wikidata for copyright issues (linking or otherwise) but I do not see this as substantially different than linking to "S2CID 2556127" which the same reference on Virtuality (software design) also refers to with |s2cid=2556127. You will notice Semantic Scholar also has a links to the full content—possibly in copyright violations as well. How is |s2cid= which already exists better than a potential |wdqid=, |qid=, or |wikidata=? If anything Wikidata is more readily accessibly and such issues could be more easily rectified. If not linking to something because it has issues is a compelling argument, I would advocate we should not allow linking to some other non-English Wikipedias (or even some local articles which are not in good shape in such regards). —Uzume (talk) 04:56, 17 July 2020 (UTC)

I agree that linking to this paper's s2cid page is not substantially different from linking to its Wikidata page. Both the s2cid page and the Wikidata page clearly link to freely downloadable copies of copyrighted material, in apparent contravention of copyright law. I think that we at Wikipedia should not link to that s2cid page or to the Wikidata page from any articles until the links to copyvio material have been removed. – Jonesey95 (talk) 05:40, 17 July 2020 (UTC)

I see your point, but I think you put too much weight on one possibly weak spot completely ignoring the potential benefits.

First of all, most of the listed links on these sites probably go to works which are legal to share, and second, at least in my judgement, links to copies of a work are the least interesting thing why we would want to link to Wikidata specifically:

Wikidata is about semantic organization of data and advanced data retrieval and research methods around this concept - something that is not in the scope of citations at Wikipedia, but nevertheless is in the scope of at least some among our audience. For example: When I read about a topic, I am typically not only interested in the topic itself, but also in the context, the history, etc. If I read a citation, I quite often do not only want to learn about the contents of the work, but also about the circumstances when the work was written, in the publication history, in the author (education, life, philosophy), the publisher (history as a company, other publications), other related works on a subject by the same or other authors or publishers, etc. To me, this is interesting in itself (YMMV), but studying the background often enough has helped (me) to get a better insight into a topic, and it also helps to improve the contents and citations in Wikipedia. Wikidata is (or will be) a resource for semantic research beyond what Wikipedia provides, so IMO it is quite important that we establish a link to the corresponding entries there.

On a different matter, I do not in any way endorse the illegal distribution of works, but legally, it is not the act of pointing to, but the act of making available without appropriate license and the act of using of such material, that is illegal. By itself, pointing to is a neutral act, unless it would be deliberately misleading like advertising a link as a free download when the material is in fact not free. It is a (common) misconception to assume that anything that "opens" (without password) when clicking on it is free, and, by extension, that anything that is not free would be illegal to link to. By providing a link to Semantic Scholar or Wikidata, we do not assume responsibility for them.

Also, as Uzume has pointed out already, in the case of Wikidata, we at least have means to correct problems there. Whenever we do, we help to reduce the amount of incorrect information floating around in the net, and since (among others) Wikidata is used by information providers which in turn are used by our editors, this will indirectly also help to reduce the amount of crap that gets imported into Wikipedia (by refill, citoid, etc.) So, helping them, we indirectly help ourselves.

--Matthiaspaul (talk) 16:02, 17 July 2020 (UTC)

It's high time we have a Wikidata identifier (and possible one that's automatically appended when there's a matching doi/whatever). It's one database amongst many, but one we should highlight. If something is wrong on Wikidata, it's like anything on Wikipedia. Fix it. This is very different from {{cite Q}} which imports things from Wikidata, and which should never be done. Headbomb {t · c · p · b} 22:49, 8 July 2020 (UTC)

The problem with "so fix it" is that there is already plenty that needs fixing on Wikipedia without taking on responsibility for another project. Kanguole 10:59, 12 July 2020 (UTC)

I share most of the concerns regarding Wikidata (user interface, reliability, etc.), but nevertheless I think that it would be beneficial for both projects if semantically related entries are linked. For this, we do not have to take on responsibility for Wikidata. A link makes it easy to compare the data and possibly correct incorrect information, thereby reducing the amount of bogus info floating around in the net, which will indirectly also help us because auto-fill tools retrieving citation data from external resources will less likely import junk. Without a link, it is unlikely that errors will be detected until we would have an article about the title (which then has a link to Wikidata). Also, Wikidata's organization of data can aid further and deeper research in ways which would be out of scope for citations in Wikidata, but which nevertheless might be interesting for people researching a topic.

--Matthiaspaul (talk) 11:36, 13 July 2020 (UTC)

So we fill Wikidata with rubbbish and they fill WP with rubbish? I really do not see the point - it is just creating a massive circular mess. - Sitush (talk) 11:40, 13 July 2020 (UTC)

I wonder how you read that from my comment, because I stated more or less the exact opposite. Can we focus on solutions rather than polemics?

--Matthiaspaul (talk) 12:13, 13 July 2020 (UTC)

Another annual discussion. I'm afraid the position is uncharged. Wikidata still has reliability issues, possible copyvio traps, and circular reference/self-reference problems. CS1/2, which purports to be an aid to avoiding these, has a pretty good fix in place regarding Wikidata already. 65.88.88.69 (talk) 23:41, 8 July 2020 (UTC)

Of course Wikidata has issues. Everything does but we are already importing data from there for certain things (I doubt anyone is going to make sitelinks go away anytime soon). That said isn't it high time these things are addressed and made better? Commons also has its problems. I do not think it should just be written off because they exist. Copyvio problems are hard to answer. Sure there is the question if that should be in Wikidata but is it better for us to link to CiteSeerX, Semantic Scholar, or Google Scholar, etc. which has many of the same links? That seems pointless. I agree "fair use" is not context insensitive but public Internet links are, so these are copyvio and security concerns at the point of publication—as it has always been. Our linking to them or not isn't much different than using {{external media}} over Commons and local hosting. Are we policing all the CS1 |url= values and article external links too? At least one of the .edu links for Semantics of context-free languages (Q56672530) is also found at Attribute grammar#External links. If they are to be policed they should be equally so. Is it better to police them from here or a more consolidated location like Wikidata? My point is that Wikidata is WMF data and as such is our data. For that reason I believe it is foolish for WMF wikis to intentionally ignore such because it might need work. —Uzume (talk) 02:56, 9 July 2020 (UTC)

Just because we are already doing it for some things does not mean we should expand it to others. There are already numerous problems with the some things, such as short descriptions, and your argument is sort-of circular - "we already use it, so use it". I would oppose pretty much any further integration of Wikidata into this project until that project has got its act together, which looks likely to take years. If you think our syntax etc is mystifying, it is nothing compared to the experiment that is Wikidata and increased obscurity does not make things easier to work with. We are mostly writers, not data scientists. - Sitush (talk) 10:26, 9 July 2020 (UTC)

I support linking to Wikidata. So far, if we had a Wikidata entry but no Wikipedia article about a title or one of its authors, I have used |title-link=:wikidata:Q..., |author-link=:wikidata:Q... or |editor-link=:wikidata:Q... to establish a connection. If we have an article, there is no need to link to Wikidata directly, because the article (or redirect) will (or can) have a link to Wikidata instead. Bots running into iwls such as :<language>: or :wikidata: can follow the link and check if an article exists in the local Wikipedia meanwhile - if so, the link can be updated to point to the local article.

Obviously, this doesn't work for titles if the citation has a |url= as well. This is, where a |wikidata= parameter could be useful.

Another approach to this could be: Help_talk:Citation_Style_1#Another_approach_for_Wikidata_links

--Matthiaspaul (talk) 10:02, 9 July 2020 (UTC) [edited on 2020-09-08]

• To be fair, this isn't something we should be deciding with just a casual discussion. This should be a full RFC (which makes it painfully clear that we're not asking for a {{cite Q}}/{{cite DOI}} situation, but rather simply supporting links to WD). Headbomb {t · c · p · b} 14:15, 9 July 2020 (UTC)

• If someone does put together an RFC, please make the question something other than "should a |wikidata= parameter be added to CS1?" RFCs cause lots of trouble when they are poorly worded and incompletely thought out. If someone here is contemplating an RFC to decide this issue, please start a discussion first to clarify (for both potential supporters and potential opponents) what you are really asking for, functionally, as a change. You are more likely to get the result you want with a clear RFC statement and question. – Jonesey95 (talk) 14:54, 9 July 2020 (UTC)

Wow, I figured it would be good to ask here first but I really did not think asking for the addition of a single identifier for a WMF sister project would required extended discussion (not that I am against such). I wonder if it would take as much for other potential identifiers like Semantic Scholar corpus ID (P8299) or ResearchGate publication ID (P5875) (I am not suggestion they be auto-populated by Wikidata just CS1 parameters with arguments with the same well defined identifier meanings; any potential auto-population can be saved for the likes of {{cite Q}}, etc.). Those can and do store/cache actual copies of scholarly articles much like CiteSeerX does (although I personally feel Semantic Scholar (Q22908627) is the best of the three). —Uzume (talk) 17:00, 9 July 2020 (UTC)

It is likely that you have a clear vision of what you are asking for, but some of us here do not. Please give an example of how this proposed new parameter would work. Show us what an example cite template would look like in code and rendered. You don't have to actually code the template, just show us a mockup of the rendered wikicode. – Jonesey95 (talk) 17:17, 9 July 2020 (UTC)

It'd be something like

• Smith, J. (2015). "Title of Things". Journal of Stuff. 34 (1): 23–45. doi:10.4321/3210. PMID 012345. Wikidata:Q0123465.

Headbomb {t · c · p · b} 17:38, 9 July 2020 (UTC)

Thanks, that helps. So the QID would point to a Wikidata entry for the item described in |title= for {{cite journal}}? Is that the only template in which |wikidata= would be supported? Are there a lot of useful Wikidata entries for journal articles? Can you provide a real-world example with a real article? I poked around at Wikidata for a bit, but none of my normal Wikipedia tricks like "What links here" work as I expect over there, so I was unable to find a transclusion count, or whatever it is called at Wikidata. – Jonesey95 (talk) 18:19, 9 July 2020 (UTC)

That would be general parameter for for all CS1/CS2 templates, no different than |bibcode= or |pmid=. Headbomb {t · c · p · b} 19:04, 9 July 2020 (UTC)

Since |wikidata= is a bit ambiguous and could mean a lot of things (some of which some people seem to be afraid of), perhaps it would make sense to name the parameter |qid= to make sure that we are linking only to item node IDs, not property IDs - this would also be more in line with the other parameters for identifiers, where we used the abbreviated name. Also, to make it impossible to link to other stuff, the "Q" prefix could be made part of the predefined part of the link, so it would look like:

• Smith, J. (2015). "Title of Things". Journal of Stuff. 34 (1): 23–45. doi:10.4321/3210. PMID 012345. QID Q0123465.

or even just

• Smith, J. (2015). "Title of Things". Journal of Stuff. 34 (1): 23–45. doi:10.4321/3210. PMID 012345. QID 0123465.

If this still isn't short enough to be unobtrusive, we could even think about reducing this to something like:

• Smith, J. (2015). "Title of Things". Journal of Stuff. 34 (1): 23–45. doi:10.4321/3210. PMID 012345. QID @.

After all, the QID number will be used only to establish a connection between the reference and the Wikidata entry, not to cite the work externally, so it is not really necessary to display the ID number in the citation for as long as there is some element a user can click on to jump to the Wikidata entry.

--Matthiaspaul (talk) 10:53, 12 July 2020 (UTC)

@Matthiaspaul: Being so short, I think "QID" is also too ambiguous and it has already been used by others (e.g., What is a QID identifier?). Why not |wdqid= which is inline with |s2cid= which CS1 already has (as a fairly recent addition)? It should perhaps be noted at this point that the QID is not really a Wikidata thing so much as a Wikibase thing. So far there are no other significant Wikibase databases besides Wikidata but nothing stops anyone from using Wikibase for something else in the future (e.g., Commons already has another but so far they are only using specialized MediaInfo entities and otherwise leveraging Wikidata item and property entities). Talk:WDQ (identifier) is also some related discussion on this topic. —Uzume (talk) 03:46, 17 July 2020 (UTC)

|wdqid= would be another possibility. IMO, it is better than |wikidata=, but not as good as |qid= - unless there would be other work or author identifiers named QID in use somewhere:

The link you provided lists one other identifier named QID, but it is not used in the context of citations. So far, I couldn't find any information on Commons' regarding how they call their IDs, but unless they would be called QIDs as well, I don't see a problem there as well - we would not link to both Wikidata and Commons, because the link to Commons could be found at Wikidata.

Although this is not a hard requirement, ideally, the name of the parameter would match the abbreviated (official) name of the identifier for consistency, that's why I (still) prefer |qid=, but would support |wdqid= as well, of course.

--Matthiaspaul (talk) 10:19, 18 July 2020 (UTC)

Can someone explain to me what useful information a wikidata link on a reference would provide to a reader of our articles? Because I'm not seeing it. It just looks like clutter to me. If we were storing reference metadata on wikidata and using a template parameter to tell the template code to expand the metadata from there, that would be one thing, but that's not what's being proposed. I don't see the value in making wikidata ids visible to readers. —David Eppstein (talk) 19:05, 9 July 2020 (UTC)

Things like author affiliation, ORCIDs, possibly other (more obscure) identifiers like holdings/links to specific libraries (e.g. BnF) etc... Crossed-linked to information about the journal (e.g. ISSN, OCLC) and so on. It's not the most useful of things, but I'd consider it way more useful than an ISSN link personally. Headbomb {t · c · p · b} 20:00, 9 July 2020 (UTC)

The point of a citation is to enable the reader to find the source of the information should they want to. I'm with David Eppstein here; a wikidata link would provide no useful information to the reader about the citation. (An ISSN link isn't usually useful, I agree, but can very occasionally clarify which journal is meant when there are journals with very similar names or names which have changed over time.) Peter coxhead (talk) 20:16, 9 July 2020 (UTC)

(edit conflict) If an editor thinks |issn=, |oclc=, or |isbn= are needed to identify/disambiguate/help locate a particular source, they're already going to add them to the citation. I'm not why it's useful to send readers to another site in order to get yet another, more obscure or less-useful identifier. IDs like ISSN/OCLC/ISBN are useful outside of the Wikimedia Foundation; if someone has a printed out copy of a Wikipedia article, they can use those IDs to fill out, an interlibrary loan request form, to search a library catalog, etc. I realize Wikipedia is an online encyclopedia and hence most viewers will be able to click on links (such as the present system of links from OCLCs and ISSNs to Worldcat and from ISBNs to Special:BookSources, which seems more than sufficient to help readers locate sources), but linking Wikidata entries just seems like extra clutter for not much added benefit. Citations are to help readers and editors find the source; being able to find fields like author affiliations and the like seem superfluous to me. Umimmak (talk) 20:31, 9 July 2020 (UTC)

I usually omit or remove ISSN identifiers for the same reason, unless it's a particularly obscure periodical whose identity might not be clear: they don't help readers locate the specific publication being cited. An ISBN at least goes to the specific book being cited, and can lead to online resources like Google Books or WorldCat, so those are more useful. —David Eppstein (talk) 20:36, 9 July 2020 (UTC)

...but ISSNs can also lead to WorldCat, which quickly lists libraries where issues of the periodical are available? I don't understand that part of your comparison. Glades12 (talk) 07:00, 10 July 2020 (UTC)

It should be noted the Wikidata Q identifier (Q43649390) can be used to link to other things besides the entity page, e.g., d:Special:EntityPage/Q56672530 vs. Q56672530 @ Scholia (Q45340488) vs. Q56672530 @ Reasonator (Q20155952), etc. In my opinion some are considerably less "noisy" than others and even better ones could be built for citation purposes (if they do not already exist). —Uzume (talk) 05:28, 17 July 2020 (UTC)

Another approach for Wikidata links

Thinking about how to integrate support for linking to Wikidata in a way acceptable to most users, I would like to discuss an alternative approach, making such links as unobtrusive as possible (and even conditional on user opt-in) by just providing a small clickable Wikidata symbol instead of listing them as "Wikidata:Q123456" or "QID Q123456" among the other identifiers (however, that would be possible as well). Commons does this in a similar way already, see e.g. in the "Summary" section here: c:File:Tarzan_and_the_Golden_Lion_-_McClurg1923.pdf

Rationale:

• Wikidata is our sister project; this might warrant to special case them somewhat compared to other identifiers.
• Wikidata QIDs are public and mostly static, but they are not designed to be semi-permanent. In contrast to other identifiers, they are not used in the outer world to refer to works in citations. Therefore, it is not actually necessary to present those Q numbers in a citation for as long as we can establish the link.
• As soon as we have an article about a title (or an author) we do no longer need to link to Wikidata directly, as the corresponding entry can be reached through the "edit" link for inter-wiki links in an article's side bar. Therefore, direct links to Wikidata are often (although not always) a temporary measure in the process to set up infrastructure.
• At least I find it desirable to establish links to Wikidata for authors even more than for works, because author names are often ambiguous and therefore linking entries can help to determine a particular author and avoid possible mix-up of the names in the future (can also be used to help automate the process of establishing iwls).
• Introducing a dedicated parameter like |qid= or |wdqid= can help to simplify linking to Wikidata entries for works, but not for authors. In general, using |-link= parameters with :d: or :wikidata: prefixes is a more flexible approach, with the sole exception of a |url= external link to a work being provided as well. In this case, the two links should both be given (instead of disallowing this combination as we do when the |title-link= would not point to Wikidata), with the Wikidata link presented by a Wikidata icon immediately following the external link, only. (If it would be desirable to support |-link= links to Wikipedia articles in addition to links to Wikidata, a dedicated parameter like |qid= or |wdqid= would still be needed.)

Thereby we could integrate Wikidata links in a very "natural" way, and even indicate to users that the link goes to Wikidata before they have to click the link (per the principle of least surprise and with all implied disclaimers regarding user interface, reliability, etc.). The approach would avoid to actually display the Q number or other extra clutter like "Wikidata:Q123456" or "QID Q123456" in the citation, and links to Wikidata entries for works and authors would work in an identical way.

Example 1:

{{cite book |last=Burroughs |first=Edgar Rice |date=1922 |title=Tarzan and the Golden Lion |title-link=:d:Q9081967 |publisher=A. C. McClurg |page=3}}

Burroughs, Edgar Rice (1922). Tarzan and the Golden Lion . A. C. McClurg. p. 3.

Alternative implementation of example 1: If the title would not be included in the link, the icon labels to Wikidata could even be made conditional on user opt-in through CSS, so that they become available only to more advanced users:

Burroughs, Edgar Rice (1922). Tarzan and the Golden Lion . A. C. McClurg. p. 3.

Example 2: Special case if both |url= and |title-link= to Wikidata would be given:

{{cite book |last=Burroughs |first=Edgar Rice |date=1922 |title=Tarzan and the Golden Lion |title-link=:d:Q9081967 |publisher=A. C. McClurg |page=3 |url=https://books.google.com/books?id=Wrk8AAAAYAAJ}}

Burroughs, Edgar Rice (1922). Tarzan and the Golden Lion. A. C. McClurg. p. 3.

--Matthiaspaul (talk) 12:49, 18 July 2020 (UTC)

What percentage of readers would recognize the Wikidata logo and understand that it is a clickable link? How would this usage meet MOS:ICON? Nikkimaria (talk) 14:16, 18 July 2020 (UTC)

At least the people at Commons seem to assume that the Wikidata icon is already recognized widely enough for using it in their database interface templates (see the Commons link above).

In the first variation of the first example above, the citation title is a clickable blue link as well, with just the Wikidata icon added afterwards. In that case there is almost no difference compared to other icons (like those "external link", "access lock" or "PDF" icons defined here ([5]), in fact, this would be better than the current state of affairs where |-link= links show as internal links without any special link decoration, so the users won't know that they will jump to Wikidata before clicking the link.

As shown in the second example, only in the case that we would have to provide a |url= external link in addition to a |title-link= link to Wikidata, the icon would become a separate element by itself without some label text (except for the alt= text), but still next to the citation's title. (Same for the alternative proposal to support a |-link= link to Wikipedia and a |qid= link to Wikidata in parallel - personally, I think, we can treat links to internal articles and links to Wikidata as mutually exclusive, but others might not agree on this.) An alternative would be to list the Wikidata link among the other identifiers as in the other examples further above. (I support both approaches, but the community would have to agree on only one of them, of course.)

In this special case of providing two links, some users may, for a while, miss the fact, that clicking on the blue title would jump to the external URL or Wikipedia's article and clicking on the icon would transport them to the corresponding Wikidata entry instead, but that is something than can be explained in the documentation, and the users would probably discover this by themselves as well. While it would be prohibitive to use a graphical-only element for some essential user interface, I do consider a graphical-only approach acceptable in this particular case because this scenario occurs only when two links are provided at the same time, and because the Wikidata link is a non-essential element. The icon is embedded in the normal text flow of a citation, instead of being some free-floating picture. Therefore, it can be selected even with text-only browsers and screen readers. They would either present the alt= description "Wikidata link to Q9081967" as link label or render the link similar to something like [https://www.wikidata.org/wiki/Q9081967] or [I]. So, the feature is usable even by visually impaired people.

Finally, if we present these icons only after opt-in (even better would be to display them by default and mute them after opt-out, if that's technically possible), this would address any concerns regarding it being a non-recognized or "unwanted" icon.

--Matthiaspaul (talk) 18:04, 18 July 2020 (UTC)

Following up on this, I meanwhile found {{Cite wikisource}}, a citation template I was unaware of. It is interesting in this context because it does something very similar for links to Wikisource already (although in a dedicated template, and not for dual title links) by appending the Wikisource icon as link decoration to Wikisource links:

{{cite wikisource |editor-first=Hugh |editor-last=Chisholm |chapter=Aard-vark |wslink=1911 Encyclopædia Britannica |plaintitle=[[Encyclopædia Britannica Eleventh Edition|Encyclopædia Britannica]] |edition=11 |date=1911 |publisher=Cambridge University Press}}

Chisholm, Hugh, ed. (1911). "Aard-vark" . Encyclopædia Britannica (11th ed.). Cambridge University Press – via Wikisource.

Since links to Wikisource are on a middle-ground between internal and external links, I think, per the principle of least surprise, we should incorporate this idea into the other citation templates as well by appending the icon whenever a |-link= parameter points to Wikisource, that is, when its value is prefixed by :s: or :wikisource:.

And, by extension, the same should happen for links to Wikidata, when a :d: or :wikidata: prefix is used in a |-link= parameter.

--Matthiaspaul (talk) 20:45, 19 July 2020 (UTC)

See also: #Proposal_to_support_link_decoration_not_only_for_links_to_Wikisource_but_also_for_other_inter-wiki_links

--Matthiaspaul (talk) 13:29, 9 August 2020 (UTC)

Wikidata is our sister project, therefore it reflects worse on us than other sites might when they host pirate links and we boost their signal in doing so. Does Wikidata even have any guidelines or policies about which external links are or are not permissible? When I follow the wikidata link from WP:EL to its equivalent page on Wikidata, I get a page https://www.wikidata.org/wiki/Q4657623 with no guidelines and no discussion. Maybe that is only the wikidata item hosting cross-links to different sites' external link guidelines and not the guidelines themselves, but it has no cross-link to Wikidata itself. —David Eppstein (talk) 18:38, 18 July 2020 (UTC)

You already linked to the discussion of property "full work available at URL" (P953) above. I meanwhile found what appears to be the original proposal to add this property: https://www.wikidata.org/wiki/Wikidata:Property_proposal/Archive/15#P953

From this it can be deduced that the links are meant to point to legal free or non-free resources (including links pointing to resources behind a paywall). Pointing to openly accessible illegal copies of a work are not an intended use, so such links could be safely deleted when spotted.

My point is that this is an issue that can't be solved by ignoring it, in particular not ignored by us as Wikipedia is already interconnected with Wikidata in many ways, and (we may like it or not) the WMF is enforcing an even tighter integration in the future. So, if Wikidata looks bad, this already reflects bad on us. The only solution, as I see it, is to fix the issues at Wikidata as soon as possible. Providing links to Wikidata, as proposed in this thread, can IMO only help to put the focus on the corresponding Wikidata entries which are relevant for us and clean them up if necessary. As most citations at Wikipedia are probably better researched than Wikidata entries, Wikipedia's citations could become part of the necessary web of trust for a more reliable future Wikidata. Without a link, problems may continue to exist there for many years to come, which will fall back bad on us.

However, in all those years I am linking to Wikidata through |-link= parameters, I cannot remember a single case where the Wikidata entry contained links to illegal copies of a work. In most cases, the Wikidata entries didn't use P953 at all. If that would have been the case, I would probably have deleted the questionable links there - or would not have provided a link to the Wikidata entry in the first place.

Just because we would have integrated support for Wikidata links we are not obligated to provide such links if there is anything questionable about an entry (and cannot be fixed) there. This is not different from links provided via |url= - if we find one which is problematic, we would remove it from a citation.

So, arguing against links to Wikidata just because some entries over there are problematic despite the many other entries without issues seems like throwing the baby out with the bathwater to me. To make sure that such links would not be abused, we could add a reminder to the documentation that links to problematic entries should be removed. --Matthiaspaul (talk) 23:01, 18 July 2020 (UTC)

@Matthiaspaul: I like the idea and the logo is well associated with Wikidata even locally (see this search), however, I wonder how this might fly in the face of current policy with regard to icons being the main link target label in main article space, e.g., see {{Wikidata icon}} and and the results of its TFD: Wikipedia:Templates for discussion/Log/2018 January 16#Template:Wikidata icon. On the other hand, we also have things like {{EditAtWikidata}} (albeit with different icon) which is used extensively in main article space as the main link target label for Wikidata links. Perhaps the "edit at" pencil (which is specially locally cached, see File:OOjs UI icon edit-ltr-progressive.svg and Wikipedia:Cascade-protected items#Cascade protected images) would be better specialized with the Wikidata logo behind it (e.g., File:Wikidata CheckUser.svg, the Wikidata logo with a magnifying/search glass over it and of course File:Wikidata-edit.svg). The icon used could also further be specialized by having a default icon sizing such as File:Notification-icon-Wikidata-logo.svg. —Uzume (talk) 20:17, 19 July 2020 (UTC)

Thank you very much for the links, I wasn't aware of these templates and prior discussions.

I would have no problems using a different icon, if that would improve acceptance (I particularly like the loupe). The pencil icon might be problematic, though, because it somehow implies that we would pull Wikidata contents into the local citation, which we expressively do not want to do in this proposal.

--Matthiaspaul (talk) 21:22, 19 July 2020 (UTC)

Proposal to support link decoration not only for links to Wikisource but also for other inter-wiki links

@Trappist the monk: Above you wrote: "The s: and wikisource: prefixes have special meaning because cs1|2 creates urls from these inter-wiki links so that it can add the wikisource icon." I didn't know that and thought it would be a special feature of {{cite wikisource}} rather than a general CS1/CS2 feature. However, trying it out I found that it works only with prefix "s:", not with ":s:":

{{cite book |title=Aard-vark |title-link=s:1911 Encyclopædia Britannica/Aard-vark |work=Encyclopædia Britannica |date=1911}}

Aard-vark . 1911. {{cite book}}: |work= ignored (help)

{{cite book |title=Aard-vark |title-link=:s:1911 Encyclopædia Britannica/Aard-vark |work=Encyclopædia Britannica |date=1911}}

Aard-vark. 1911. {{cite book}}: |work= ignored (help)

Shouldn't this work for both variants?

Actually, per the principle of least surprise, I think, it would be useful to add the same functionality also for links to other inter-wiki-links (iwl), but at least for links to the two most important ones, Wikidata (:d:/:wikidata:) and Commons (:c:/:commons:).

In the case of iwls, the corresponding project logos could be used as icons (as per Wikisource).

If we would extend the idea to inter-language-links (ill) as well and make it a general principle, we should not display iconized country flags, but instead just append a small text postfix composed of the prefix in square brackets (so, prefix :de: would result in [de] being appended to the link, similar to what links created by {{ill}} look like).

--Matthiaspaul (talk) 10:09, 9 August 2020 (UTC)

The s: and :s: prefixes work as they should work. When the {{cite wikisource}} parameter |noicon= is present and has a value (do not display the icon), {{cite wikisource/make link}} creates an inter-wiki link with the :s: prefix; else {{cite wikisource/make link}} creates an inter-wiki link with the s: prefix to show the icon.

—Trappist the monk (talk) 11:01, 9 August 2020 (UTC)

Okay, then it is a feature. But is it a useful feature to have this choice (as part of the link syntax being used, that is)? (This certainly could be controlled in different ways as well.)

I would think that in the majority of cases displaying the link decoration would be preferable - after all, we also cannot (at least not on user level) disable the external link arrow icon being displayed for external links. And in cases, where no icons should be displayed for some reason, it would be a template-wide rather than a link-specific setting (therefore having an option like |noicon= to control it).

Either way, if we have it for Wikisource, why not for Wikidata and Commons as well for reasons of consistency?

--Matthiaspaul (talk) 11:58, 9 August 2020 (UTC)

Actually, this can be seen also as a light-weight or "half" solution to my alternative proposal for linking to Wikidata. While, according to the original discussion, it may still be premature to add support for a dedicated Wikidata parameter like |qid=, links to Wikidata are provided even now when it is important to establish a connection to a specific title or author if we don't have a local article and the Wikidata entry has useful information or if it helps to preempt wrong associations in case of ambiguous names or titles. Adding the link decoration as discussed here would at least tell readers that a link is not internal but to a sister-project before they click on it.

--Matthiaspaul (talk) 21:29, 13 September 2020 (UTC)

Wayback Machine

Hello, I came across a reference title of "Wayback Machine", having done a search there are close on 2,000 of these. Was wondering if it worth extending the "Archived copy" tracking to include this as well, so that the articles can be modified to give something useful. Keith D (talk) 21:21, 5 August 2020 (UTC)

This would be good. There is a tool (reFill) that when it encounters a bare or square web.archive.org link generates a {{cite web}} set with |title=Wayback Machine and |website=web.archive.org (diff). My tool WaybackMedic unwinds some of it (diff) but the title remains as "Wayback" -- GreenC 01:47, 6 August 2020 (UTC)

The sandboxed version of the template now adds such citations to a maintenance category:

{{Cite book/new |title=Wayback Machine}}

Wayback Machine.

(Of course, it is still empty until the change will be rolled out.)

--Matthiaspaul (talk) 23:20, 22 August 2020 (UTC)

In Module:Citation/CS1/Configuration/sandbox you included a comment no translation necessary for this one. How do we know that?

This search finds almost 2000 instances of this 'title'. I wonder if a maintenance category is proper here. To me, |title=Wayback Machine just as bad a |title= (empty or missing); it is no help to the reader, maint cats are hidden so most editors don't notice that this bogus title replaces a real title; maint cats usually imply that whatever it is that they categorize is minor so there is no sense of urgency to fix them. I think that if we are going to retain this change, it should be as an error not as a maint cat.

—Trappist the monk (talk) 11:03, 23 August 2020 (UTC)

Regarding "no translation necessary", it is my assumption that the Wayback Machine has no alternative names in different countries. If it has, and the tools use different strings in different WP entities, then, of course, we may need translations. Does someone know for sure?

Re error or maintenance, I was just following the example of "Archive[d] copy", which should also be an error in my judgement, but is only flagged for maintenance (perhaps because of the extremely high number of hits?). Opinions? --Matthiaspaul (talk) 12:44, 23 August 2020 (UTC)

Yeah, I think |title=Archive[d] copy should be an error but, you know, pitchforks and torches because oh-my-god-the-sky-is-falling. I have thought that we might somehow emit error messages in dribs and drabs; article titles ending with [Aa] only and then to be followed at the next update with article titles ending with [Bb] , etc. – last letters to reduce clumping which might provoke pitchforks and torches. We might even build in a timer release so that every month a new terminal letter is added. Or we could have an RfC on the topic ... wherein, of course, we will be admonished to have a bot fix all of those articles before we show the error messaging even though |title=Archive[d] copy is created by a bot when it cannot determine the title of the source. As you might guess, I have little faith in that path.

I think we need to do something; if we don't, Category:CS1 maint: archived copy as title (52,760) will continue to grow.

—Trappist the monk (talk) 14:20, 23 August 2020 (UTC)

I also have been concerned about the continued failure of that category of clear errors to be cleaned by anyone. I do not think it would have the same reaction as last year's website given that these should ostensibly not occur more than a few times a page. --Izno (talk) 16:00, 23 August 2020 (UTC)

For wayback titles we might do:

err_suspect_title = {
		message = 'Citation has a suspect title',
		anchor = 'suspect_title',
		category = 'CS1 errors: suspect title',
		hidden = false,
		},

Is there a better (less cryptic) error message? better cat name?

When 'Wayback Machine' is a legitimate title, |title=((Wayback Machine)).

—Trappist the monk (talk) 16:25, 23 August 2020 (UTC)

I do not think we need to support the exception here (at this time); few or no citations will be citing the front page of Wayback (and where they do, more likely it should go in work or publisher or via parameters).

I would be more direct since this is the only set of titles we have worries about this concern: "Citation (title?) generated by web archive bot" or similar. Which is not strictly true in the "Wayback" title case but close enough for purposes. --Izno (talk) 16:41, 23 August 2020 (UTC)

Regarding "don't need to support the ((exception)) here", I recalled that we already supported this for |title= to suppress the removal of trailing dots etc. Therefore, I looked up the documentation for this and in there it is stated that this syntax is only supported for {{cite journal}}, {{cite magazine}}, {{cite news}} and {{cite web}}. I was wondering why we would not support this in general (also to simplify the code and the documentation) and running some tests I found that it also works for {{cite book}}. So, unless I am missing something, this bit appears to be a leftover from the past and we can safely remove the mentioning of this restriction from the documentation, right?

--Matthiaspaul (talk) 18:51, 25 August 2020 (UTC)

Removed this non-existent restriction from the documentation now. --Matthiaspaul (talk) 09:37, 27 August 2020 (UTC)

Other ideas: "Citation has a generic bot-generated title", or "Citation has an ambiguous title". Possibly leave off "bot-generated" as in second case. -- GreenC 18:54, 23 August 2020 (UTC)

Before I saw how many hits we have for "Archive[d] copy" I was about to put "Wayback Machine" into the same category, possibly renaming the message and cat into something about "bogus titles". However, then I thought "Wayback Machine" would go under among "Archive[d] copy" (thereby making its maintenance difficult) so introduced a new cat for it.

However, for a cat holding only a few thousand pages, I think we could lump together "Wayback Machine" with some other bogus strings in the title like "[(]unknown [title][)]" (in a category "Non-sensical" or "bogus titles").

--Matthiaspaul (talk)

The problem with "bogus", "non-sensical" and "suspect" it will probably result in Phab tickets for IABot ("The bot is creating bogus titles") as if the bot was making a mistake and should stop doing that. Less judgemental and more objective words like ambiguous and generic would produce less friction. -- GreenC 19:30, 23 August 2020 (UTC)

In fact, I wonder if the bot isn't making a mistake. Correct would be to add an empty |title= parameter, causing the template to throw an error message. Alternatively, but only slightly better, the dummy title should trigger the template to throw a (more specific) error message, as we all seem to agree now. Maintenance cat won't cut it, if nobody is acting on it.

--Matthiaspaul (talk) 20:30, 23 August 2020 (UTC)

Nobody has been acting on it, but it can be acted on. See User_talk:Citation_bot#Query_re:_titles. Probably overkill to red error that many citations while there are still possibilities for correction. -- GreenC 20:44, 23 August 2020 (UTC)

Re error or maint for "Archive[d] copy" I would support to change this to error as well. Yes, it will annoy readers, but apparently this is the only way to move forward.

And if the number of entries in that cat actually still increases, we should block the tools introducing this mess (and also the careless users using these tools). While I prefer to have fully blown up citations (filled by humans), I would rather prefer to have citations missing some entries than citations containing pure junk.

--Matthiaspaul (talk) 19:21, 23 August 2020 (UTC)

IAbot made this edit 2 minutes after your post.

—Trappist the monk (talk) 19:33, 23 August 2020 (UTC)

Exactly. The alternative is bare link + {{webarchive}} which sucks for a number of reasons. The archive bot has to do something when it encounters bare-link link-rot and conversion to CS1|2 moves the process forward. The generic title is a flag for a title bot to fill in the correct title. There is currently no title bot, but we had them before. -- GreenC 19:59, 23 August 2020 (UTC)

The point I was answering was And if the number of entries in that cat actually still increases. Yep, it still increases; IAbot is not going to go away. The problem with |title=Archived copy is that at a glance, everything appears to be correct because there are no red and only those of use who have maintenance messaging enabled will see the maintenance category messages. For me, I have little faith in automation as a way of solving the archived copy title problem. IAbot is apparently capable of finding titles so when it can't, what makes us think that some other bot can?

—Trappist the monk (talk) 22:02, 23 August 2020 (UTC)

IABot doesn't find titles. There are other title fixing bots operating back over 10 years ago, and Citation bot also has that feature when it is working (third party tool currently offline working to restore). -- GreenC 00:41, 24 August 2020 (UTC)

We should start a list of other 'titles' that might go into the same category as wayback machine titles. Here are a couple:

• This website is for sale – this search
• HugeDomains.com – this search

I'm pretty sure that I've seen others; I've even seen the same sort of 'titles' in languages other than English.

—Trappist the monk (talk) 22:02, 23 August 2020 (UTC)

Bloomberg's "Are you a robot?" Jumps immediately to mind. --Izno (talk) 23:26, 23 August 2020 (UTC)

• insource:/| *title *= *[([{<]?[Uu]nknown[>}\])]? *[|}]/ --> [6] (455)
• insource:/| *title *= *[([{<]?[Uu]nknown *[Tt]itle[>}\])]? *[|}]/ --> [7] (127)
• insource:/| *title *= *[([{<]?[Tt]itle *[Uu]nknown[>}\])]? *[|}]/ --> [8] (157)
• insource:/| *title *= *[([{<]?[Ee]mpty *[Tt]itle[>}\])]? *[|}]/ --> [9] (1)
• insource:/| *title *= *[([{<]?[Mm]issing *[Tt]itle[>}\])]? *[|}]/ --> [10] (~5)
• insource:/| *title *= *[([{<]?[Dd]ummy[>}\])]? *[|}]/ --> [11] (4)
• insource:/| *title *= *[([{<]?[Pp]laceholder[>}\])]? *[|}]/ --> [12] (3)
• insource:/| *title *= *[Tt][\.]?[Bb][\.]?[Dd][\.]? *[|}]/ --> [13] (~4)
• insource:/| *title *= *[Tt]o *[Dd]o *[|}]/ --> [14] (~1)
• insource:/| *title *= *[Nn][\.]?[\/]?[Aa][\.]? *[|}]/ --> [15] (~11)
• insource:/| *title *= *[Nn][\.]? *[Tt][\.]? *[|}]/ --> [16] (~1)
• insource:/| *title *= *[([{<]?[Nn]o *[Tt]itle[>}\])]? *[|}]/ --> [17] (~306)
• insource:/| *title *= *[([{<][Nn]one[>}\])] *[|}]/ --> [18] (16) (not matching the reserved keyword "none")
• insource:/| *title *= *None *[|}]/ --> [19] (~61) (not matching the reserved keyword "none")
• Titles containing "Free Download & Streaming: Internet Archive" [20] (288)
• Many titles (but not all of them) containing "brought to you by " [21] (354)
• insource:/| *journal *= *[([{<]?[Rr]eport[>}\])]? *[|}]/ --> [22] (apparently done by Citation bot [23]) (14)

--Matthiaspaul (talk) 00:37, 24 August 2020 (UTC)

"Page not found" (1,733). "404" (972) -- GreenC 00:56, 29 August 2020 (UTC)

I have changed the messaging to an error message and added detection for these sub-strings:

• page not found
• 404 error
• website is for sale
• HugeDomains.com

I chose these because they seemed most likely to have been placed by something other than human. I thought about [%(%[{<]?unknown[>}%]%)]? but decided against it because there are too many uses that seem to me to be placed by a human.

{{cite book/new |title=Wayback machine}} → Wayback machine.

{{cite book/new |title=A page not found}} → A page not found. {{cite book}}: Cite uses generic title (help)

{{cite book/new |title=404 error}} → 404 error. {{cite book}}: Cite uses generic title (help)

{{cite book/new |title=Some.domain.name - This website is for sale! Cheap!}} → Some.domain.name - This website is for sale! Cheap!. {{cite book}}: Cite uses generic title (help)

{{cite book/new |title=HugeDomains.com - Some.domain.name for sale}} → HugeDomains.com - Some.domain.name for sale. {{cite book}}: Cite uses generic title (help)

If there really is an article title like one of these, then:

{{cite book/new |title=((Wayback machine))}} → Wayback machine.

Category will be Category:CS1 errors: generic title.

—Trappist the monk (talk) 22:39, 3 September 2020 (UTC)

Given that we provide ((this method)) to bypass the error check, I would add all the other "bogus" titles to the list as well (except for "Brought to you", which also has at least one "good" real-world use case). Bot generated or human generated - who cares? Something like "Unknown", "Placeholder", or "To Do" never makes sense as a title and thus is undesirable. While the number of hits is lower than for bot generated titles, I think, we should also keep editors from adding such pseudo-titles in the first place.

I would also include the many variants of expressing "No title" and add support for a special token like "no-title" to indicate this condition;

[Splitted out sub-topics into separate thread: Descriptive titles and tokenizing the "No title" case]

--Matthiaspaul (talk) 10:19, 4 September 2020 (UTC)

I agree, generic titles are not acceptable. However, catching every possible unacceptable title is not something that the module should attempt – it takes time to repeat all of these pattern searches which is something that has bitten us badly in the past. I have added ^[%(%[{<]?unknown[>}%]%)]?$ and ^[%(%[{<]?no +title[>}%]%)]?$ as the patterns with the most cirrus-search hits. I have also added are you a robot which I overlooked earlier.

I have also attempted to speed up the searching by complicating the tables in ~/Configuration so that pattern matching is disabled for plain-text searches.

This is not the place to discuss related topics. If they are important, please extract them from this discussion and post them separately.

—Trappist the monk (talk) 13:55, 4 September 2020 (UTC)

Splitted out sub-topics into separate thread: Descriptive titles and tokenizing the "No title" case

--Matthiaspaul (talk) 16:37, 4 September 2020 (UTC)

template:cite conference: Proper markup for citing a paper at a conference.

I would like to cite a paper from the 1965 Fall Joint Computer Conference, sponsored by the American Federation of Information Processing Societies (AFIPS). The title of the book is AFIPS CONFERENCE PROCEEDINGS VOLUME 17 PART 1 1965 FALL JOINT COMPUTER CONFERENCE. There is no part= parameter for volumes that are subdivided, and no organizer= parameter. I get when I use the markup

 {{cite conference
 |      title = INTRODUCTION AND OVERVIEW OF THE MULTICS SYSTEM
 |  booktitle = AFIPS CONFERENCE PROCEEDINGS VOLUME 27 PART 1 1965 FALL JOINT COMPUTER CONFERENCE
 |       page = 185
 |    author1 = F. J. Corbaro
 |    author2 = V. A. Vyssotsky
 |     volume = 27 Part 1
 | conference = Fall Joint Computer Conference
 |  publisher = Spartan Books
 }}

Is that really how it should be rendered? Shmuel (Seymour J.) Metz Username:Chatul (talk) 22:58, 12 August 2020 (UTC)

References

At the very least, you should change the capitalization; see MOS:ALLCAPS. Either spell out the volume in the title or use a separate |volume= parameter, but don't do both. Also, I would generally use only one of |booktitle= and |conference=. Your formatting of the page numbers makes this look like a one-page paper (not true); the correct parameter would be |pages=185–196 (note en-dash not hyphen in the page range). And you should probably list a doi (doi:10.1145/1463891.1463912) and an ISBN if you can find it. —David Eppstein (talk) 23:34, 12 August 2020 (UTC)

Thanks. I have a few questions:

• Is there a web site for looking up the DOI of a paper?
• If I am only citing a single sentence, should I still give the full page range of the paper? That would seem to make it more difficult for a reader to verify the quote.
• To what extent is it permissible to redact the title? Is this permissible:

 {{cite conference
 |      title = Introduction and Overview of the Multics System
 |  booktitle = [[AFIPS]] Conference Proceedings
 |        doi = 10.1145/1463891.1463912
 |       page = 185
 |    author1 = F. J. Corbaro
 |    author2 = V. A. Vyssotsky
 |     volume = 27 Part 1
 | conference = [[Joint Computer Conference|Fall Joint Computer Conference]]
 |       year = 1965
 |  publisher = Spartan Books
 }}

To put it in context, I frequently need to cite documents that were printed before there was such a thing as a DOI, and that often don't even have an ISBN. Shmuel (Seymour J.) Metz Username:Chatul (talk) 01:44, 13 August 2020 (UTC)

Chatul, use the oclc number from WorldCat when there is no isbn (you can, even when there is): oclc=8558302617, thus. Note that there is no reason to WP:PIPE the Fall Joint Computer Conference; you can just use it directly. Mathglot (talk) 02:31, 13 August 2020 (UTC)

I would use |doi= and |oclc= if I knew how to look them up given the title. Shmuel (Seymour J.) Metz Username:Chatul (talk) 04:42, 13 August 2020 (UTC)

OCLC numbers can be looked up by searching for the work's title at https://worldcat.org. Glades12 (talk) 19:06, 10 September 2020 (UTC)

References

Regarding page numbers, we recently had several discussions on page numbers where we came to the conclusion that, in cases such as yours, we need parameters to optionally specify both, individual pages and page ranges. We also discussed two notations how to display this. Until these new parameters materialize, you can do it manually by specifying |pages=185–196 [185], assuming that 185–196 is the page range of the article or chapter, and 185 the individual page where you found the citation.

Also, it is a good idea to use the |date= parameter instead of the |year= parameter. |year= is a leftover to provide an additional disambiguator in some cases in conjunction with harv referencing, in all other cases, |date= is the preferred parameter to be used - it is also more flexible. --Matthiaspaul (talk) 07:05, 13 August 2020 (UTC)

For what it's worth, I found the doi in this case (and the full page number range) by searching for the title (in double quotes) on Google Scholar, and following the first link that it gave me. The doi was both shown in the text of the page and incorporated into its url. But in many cases there are bibliographic databases like DBLP for computer science papers or MathSciNet and zbMATH for mathematics papers that have cleaner data than Google Scholar. The doi system used to have their own search engine for dois but I don't think it's there any more. As for whether to cite full page number ranges: for journal or conference articles, yes, for books, no, just cite the page you are using. It may be helpful to write out which page you are getting some fact from in a journal article, especially in longer ones, but I don't think that should go in the citation template itself (it can instead be a plain text note immediately following the template), and it may be better to name the subsection of the paper than just to use a page number in case a reader uses a copy of the paper that is paginated differently. —David Eppstein (talk) 07:29, 13 August 2020 (UTC)

Citation Style documentation/id2

With this edit Editor Francis Schonken added an {{under discussion}} template to Template:Citation Style documentation/id2. The {{under discussion}} template points to an RfC at Wikipedia:Village pump (proposals) § Issues raised by Citation bot. Because that RfC is not about the cs1|2 identifier documentation template, I reverted. Editor Francis Schonken ignored WP:BRD and reverted me with the edit summary The RfC might result in a rewrite of this template documentation. I will not edit war. Editor Francis Schonken: you should self revert and discuss here.

—Trappist the monk (talk) 15:17, 23 August 2020 (UTC)

I, too, think that the template does not belong there. On the other hand, the linked discussion won't last forever, so it is a temporary issue only.

However, speaking about this documentation snippet, I take serious issue with the notion regarding |url= being a link to a free resource:

"The |url= parameter [...] can then be used for its prime purpose of providing a convenience link to a free-to-read copy of the source that would not otherwise be obviously accessible."

This is one possible use of the parameter, but not its primary purpose per our policies and guidelines on citations. While, of course, it is always great if the link points to a free resource, and it is perfectly fine to select a free one if we are in the luxury of having multiple links available (and there are no other reasons to prefer another link), there is no fundamental requirement for the link to point to a free resource.

The requirement, per our policies, is that the link is the one used by the editor adding the citation to support a statement in an article. If this happens to be hidden behind a paywall or by other means limiting the access, that may make things more difficult for other readers but it does not invalidate the citation or the link. In fact, removing such an URL for being unfree would invalidate the citation.

I can see the desire to promote free resources, but this is the wrong place for it - it is actually counter-productive here. The wording needs to be adjusted to be in sync with our policies and guidelines.

--Matthiaspaul (talk) 18:24, 23 August 2020 (UTC)

@Matthiaspaul: I'd like to see your opinion in the WP:VPPR#Issues raised by Citation bot RfC, instead of initiating, here, a same discussion about the same topic that is currently the subject of an open RfC. I assume that answers Trappist the monk's question too: could we all give it a little more effort not to duplicate the same discussion over multiple talk pages at the same time? It's not only against the rules on WP:CONSENSUS, but entirely impractical. --Francis Schonken (talk) 04:41, 24 August 2020 (UTC)

In view of a comment I got here, pinging all participants in this talk page section, thus including Trappist the monk, asking to go express their opinion on the ground of the matter at WP:VPPR#Issues raised by Citation bot. --Francis Schonken (talk) 06:58, 24 August 2020 (UTC)

SeeAlso: Help_talk:Citation_Style_1#Guidance_on_title-linking:_update_after_RfC

--Matthiaspaul (talk) 10:21, 25 September 2020 (UTC)

Considering that in the linked discussion some users have described the discussion on what templates do as a "red herring", I suggest that it's not at all clear whether this documentation is supposed to be affected. It's not clear whether this warning is neutral. Nemo 12:59, 24 August 2020 (UTC)

@Nemo bis: Documentation is for users that use the template. Template documentation can be updated without a change in the template code (the code is what defines what the template "does"). Giving an example (for another template): this was a major update of a template's documentation, without any change in that template's code. That update to the documentation had been discussed before it was implemented, and that prior discussion was in response to the outcome of an RfC. It seems rather useful to attract broad attention to the Citation bot RfC, drawing attention to the fact that it might affect the template documentation. If "it's not at all clear whether this documentation is supposed to be affected" and open-ended questions in an RfC allow to give answers that divert from what is written in the template documentation, then of course whether or not the template is directly or indirectly affected is part of the RfC's topic. Which should (as long as the RfC is open) be discussed at the RfC and not here. --Francis Schonken (talk) 15:36, 24 August 2020 (UTC)

I agree with Francis that the discussion cited is pertinent to the documentation (without necessarily blessing the view that changes will be made pending the outcome). --Izno (talk) 18:58, 30 August 2020 (UTC)

Support for ISO:2019 month precision

Matthias had been adding support for ISO:2019 month precision in the sandbox based on WT:Citing sources#No known day? (it comes up regularly here and there). I think it is prudent to advertise those changes here and verify there is consensus both for the functionality and for the particular implementation. (I for one think it is reasonable functionality; it may need testing on rtl wikis.)

Some examples:

• Title. 2020-01-XX. {{cite book}}: Check date values in: |date= (help) with {{Cite book/new |title=Title |date=2020-01-XX}}
• Title. 2020-01-XX. {{cite book}}: Check date values in: |date= (help) with {{Cite book/new |title=Title |date=2020-01-XX |df=mdy}}

And a few which still error (as expected):

• Title. 2020-01. {{cite book}}: Check date values in: |date= (help)
• Title. 2011-12. {{cite book}}: Check date values in: |date= (help)
• Title. 2020-01. {{cite book}}: Check date values in: |date= (help)

I do not personally like the -XX in the first example, but feel free to review. This may also be something to let WT:MOSDATE know about. --Izno (talk) 16:19, 23 August 2020 (UTC)

This should not be supported unless there's consensus at MOS:DATES to consider 2010-01-XX an acceptable format. Headbomb {t · c · p · b} 17:18, 23 August 2020 (UTC)

(edit-conflict) This is meant as kind of a compromise/workaround. It is deliberate that your second set of dates (in "yyyy-mm" format) still fails for now. My plan was/is to allow the ISO 8601:2019 form "yyyy-mm-XX" on template input parameter level only in order to give users some option to enter dates with unknown days in templates otherwise using the ymd format. At present, because the more obvious form "yyyy-mm" is still disallowed by MOS, users are forced to use "MMMM yyyy" instead, and some users are then trying to use this inconsistency to convert whole articles to use the dmy or mdy format in citations. No good.

My plan was for dates entered in the form "yyyy-mm-XX" to still display as "MMMM yyyy" for now, however, this automatic conversion didn't work as expected (I have to more carefully study the code around the reformatter routine for this), so that, at present, dates entered in the form "yyyy-mm-XX" are, by default, actually displayed as such as well (unless overridden by |df= or the presence of a {{use xyz dates}} template).

At a later stage (but this actually requires a slight change of the MOS to disallow the "yyyy–yy" form in citations and instead allow the "yyyy-mm" form there), such dates could be more reasonably displayed as "yyyy-mm" instead of "MMMM yyyy" (or "yyyy-mm-XX"). At that later stage, we could allow the "yyyy-mm" form also on input level. However, I think, we should count in several months as a transitional period.

It is my estimation that we have about 200 instances where abbreviated year ranges are used in the |date= parameter (but the insource search times out, so I don't know for sure). Oddly enough, abbreviated year ranges are more prevalent in the |year= parameter (probably for historical reasons), but, still, the usage is minimal compared to the literally millions of places where the "yyyy-mm" form could be reasonably used in citations in order to improve consistency and readability.

Most of the uses of year ranges (abbreviated or not) in citations seem to be actually wrong and just rooted in the fact that the exact publication date isn't known. That's why I proposed to have a maintenance category for this to make it easier to check these ranges. With the necessary research it should be possible to provide a specific publication date instead of a year range in most of the cases (example: Help_talk:Citation_Style_1/Archive 70#Use_of_Years_from_the_Jewish_Calendar?). There might be a few exceptions, but in none of the citations I inspected so far I could identify some underlying need to use an abbreviated year range, so that, even if the actual publication date remains unclear, it is still possible to convert such date ranges to their non-abbreviated form without any backdraws for the readers.

--Matthiaspaul (talk) 17:35, 23 August 2020 (UTC)

Oppose. This is a totally novel notation and should be strictly forbidden. It doesn't work with any tool that a person might use to help format citations for Wikipedia. It's confusing and hideous. Jc3s5h (talk) 19:27, 23 August 2020 (UTC)

It is an international standard notation (recommended by ISO, but also by various other institutions) - you can be sure tools will be updated to support it. However, I, too, don't find it visually particularly pleasing. But what I displease much more is that some users attempt to convert citations in ymd format into other formats for the occasional use of the "MMMM yyyy" form for incomplete dates. The goal is to eliminate a need to "abuse" the "MMMM yyyy" form and use a true ymd form also for incomplete dates for improved readability and consistency.

As I wrote (and this is also why I didn't announce this extension at this time), the implementation is not finished yet: The "yyyy-mm-XX" is not meant for display purposes, but only for entry purposes on source code level, so there won't be any visual change in how citations look like in articles.

--Matthiaspaul (talk) 19:56, 23 August 2020 (UTC)

Oppose. Actually, I sometimes do use notation like 2020-08-XX — when I'm patrolling recently prodded articles by date, building a list of them to add to deletion sorting pages, and haven't filled in some of the dates yet. If they ever creep into an actual edit, it's a mistake and I want that mistake to be flagged, not treated as meaningful. I agree with Jc3s5h's description of this as "confusing and hideous". Maybe "an abomination" would be more accurate. If the ISO approved these, it suggests that there's something seriously broken at the ISO. —David Eppstein (talk) 22:08, 23 August 2020 (UTC)

To me such rants suggest a seriously broken state of the English Wikipedia ("being almost too clumsy to move forward and not agile to address real-world needs any more") and that some of its users have lost contact with the progress in the outside world. Makes me sad.

It's not "if", the notation is part of ISO 8601, and has been adopted in countless country-specific standards internationally.

What might be even more shocking then is the fact that it was the US Library of Congress together with many other libraries and publishers who have been pushing this notation forward in particular for use in bibliographical contexts since 2012, see e.g. [24].

A usage even pre-dating this initiative has been in technical guidelines by the BSI for reliable and secure document exchange.

So, perhaps it is time to switch from foot-stomping fundamental opposition to versatile solution-oriented thinking again. E.g. in regard to your described personal habits, you would just have to use lowercase letters 'x' and your personal notation won't clash with the international standard any more. Much more sensible than trying to tell other users not to use a notation where appropriate, IMHO.

--Matthiaspaul (talk) 15:12, 24 August 2020 (UTC)

@Matthiaspaul: your many long replies here suggest that it might be helpful for you to read WP:BLUDGEON. —David Eppstein (talk) 17:07, 24 August 2020 (UTC)

Oppose. The date notation is unusual and confusing. We need to reduce date format options rather than extending them. The ISO date format is confusing to many and is not clear what it means. There are large numbers of people who cannot follow the rules and put it in incorrectly so it would be a much more sensible option to get rid of ISO date formats completely. Keith D (talk) 22:56, 23 August 2020 (UTC)

Trying to tell users not to take advantage of a notation just because of the ignorance of a few does not sound very sensible to me, in particular because those few can continue to use whatever they have used so far ("backward-compatibility is built-in") and they won't even see a difference in the rendering of citations in articles despite this notation being used by other users. (What? No difference? How is that? Well, this requires reading before complaining...)

Proposing to get rid of one of the two most commonly used date formats on this planet is, IMHO, the opposite of smart. If there is ever a format to go away it would be the mdy format because this is only used by a minority of users and is causing an endless stream of confusion (and accidents). Actually, if we would have to adopt a single format only, it would be the ymd format for sure, as the international date format is understood anywhere (except for, perhaps, in a few ignorant holdouts living more than four decades in the past, that is, before ISO 8601 became an international standard).

No, I don't propose this, but it hopefully illustrates how arrogant and childish it is to deny other people's obvious needs.

Regarding reducing date format options, the very goal of this minimal change is actually to reduce the formats that have to be used in citations at the same time. But the solution cannot be to get rid of the ymd format, but to make it possible to use that format consistently also if the day is not known, that is, to first work around an arbitrary restriction only imposed by the current wording of the MOS, and at a later stage to eliminate the restriction completely. This will significantly improve the situation for millions of citations, and without any need to remove support for ymd (your proposal) or mdy (my somewhat pointy, but tongue-in-cheek counter-proposal). Peace.

--Matthiaspaul (talk) 15:12, 24 August 2020 (UTC)

Oppose This date notation is very useful for a very specific use case, and we are not this case. AManWithNoPlan (talk) 23:07, 23 August 2020 (UTC)

Citing from the Library of Congress' EDTF documentation:

"Unspecified digit(s) from the right: The character 'X' may be used in place of one or more rightmost digits to indicate that the value of that digit is unspecified, for the following cases: [...] Year and month specified, day unspecified in a year-month-day expression (day precision) [...] Example [...]‘1985-04-XX’"

So, the usage of the "yyyy-mm-XX" notation (with uppercase letter 'X') is a perfect match for the intended purpose given that the only way we can currently specify a date in the "yyyy-mm-dd" mask (but with unknown day) is using its "yyyy-mm-XX" sub-format. Other ad-hoc forms I have seen being used in the wild over the years were "yyyy-mm-uu" (with lowercase letters 'u'), "yyyy-mm-00" and "yyyy-mm-??", but none of them was formally standardized. Of course, just using "yyyy-mm" would be even better. --Matthiaspaul (talk) 15:12, 24 August 2020 (UTC)

Oppose. The YYYY-MM-DD date format is ugly and confusing enough for regular readers. Using "XX" instead of days and then hiding the "XX" when the page is rendered is even more confusing. This new format, which is in part a proposed change to MOS:DATES, should be proposed at a MOS talk page. – Jonesey95 (talk) 16:11, 24 August 2020 (UTC)

Given this response, I think these changes should be reverted/removed from the sandbox modules and some requirements/design discussion had (if not also the MOS:DATE blessing). --Izno (talk) 18:41, 30 August 2020 (UTC)

This has been introduced and withdrawn before. I'm not opposed to supporting this format as input and I really like it for tools that write cs1|2 citation templates – machine talking to machine. But, from the discussion above, it appears that the community aren't interested in supporting this date format.

When this topic was reintroduced, I promised myself that I would take the time to write testcases for date validation. I have done that now; Module:Citation/CS1/testcases3 (run). That shows that there are flawed date formats that aren't being detected as errors; see test_dmydmy_dates, test_mdymdy_dates, and test_ssy_dates.

So, I shall be reverting the YYYY-MM-XX date format changes in Module:Citation/CS1/sandbox and Module:Citation/CS1/Date validation/sandbox.

—Trappist the monk (talk) 13:53, 3 September 2020 (UTC)

I suggest the next time you're revising your test case, you make every case unique to make it easy to search for a particular case. So rather than having dozens of cases in October 1980, start with 1 March 1980 and work your way up. What with date ranges and all, you might end at 1 July 1981. Jc3s5h (talk) 14:23, 3 September 2020 (UTC)

Reverts done and fixes applied. In Module talk:Citation/CS1/testcases3 test_dmydmy_dates, the first six test-result errors show that the live module is not catching month-name spelling and capitalization errors. For the other two test-result errors, one of the month names in each test has a trailing comma. Because cs1|2 is used at Wikipedias that do not use Latin-based script and some of those languages include punctuation characters within month names, anywhere month names or abbreviations are expected in a date string, cs1|2 uses the +(%D-) + pattern (similar to regex +(\D+?) + – any character except digits, don't be greedy). That means that October, and November, are misspellings, not punctuation errors. The fix for misspellings in the first six test_dmydmy_dates test-result errors fixes the last two. A similar fix fixes the test_mdymdy_dates text-result errors.

For the test_ssy_dates, a new test in the code to make sure that the seasons in a Season–Season YYYY date are not the same, resolves that issue.

—Trappist the monk (talk) 17:01, 3 September 2020 (UTC)

use xxx dates redirects

Editor Matthiaspaul modified the table of {{use xxx dates}} redirect patterns (df_template_patterns{}) in Module:Citation/CS1/Configuration/sandbox. I have tweaked that to allow multiple space characters between words in the redirect names and updated the use counts.

—Trappist the monk (talk) 14:24, 25 August 2020 (UTC)

Editor Matthiaspaul: I will not discuss changes to the module suite via edit summaries; that is the wrong place for discussion.

You replaced + (one or more) with * (zero or more). In the wikisource of an article there can be any number of spaces between use and dmy and dates as an editor wants to put there. {{Usedmydates}} is not a redirect so we do not want a pattern that matches that as {{ *[Uu]se *(dmy) *dates *[|}] does. However, {{Use dmy dates}} is valid and the pattern {{ *[Uu]se +(dmy) +dates *[|}] will match. Try these in the debug console:

=string.match ('{{Usedmydates}}', '{{ *[Uu]se *(dmy) *dates *[|}]') – matches when it shouldn't
=string.match ('{{Usedmydates}}', '{{ *[Uu]se +(dmy) +dates *[|}]') – shouldn't match and doesn't
=string.match ('{{Use     dmy     dates}}', '{{ *[Uu]se +(dmy) +dates *[|}]') – should match and does

—Trappist the monk (talk) 16:25, 25 August 2020 (UTC)

Fine with me. I misunderstood your intention when you added the wildcards in the first place.

I would rather like to reduce the number of naming variants we have to search for because the more we allow, the more easy it is for other templates & bots to get out of sync (and also for performance reasons in case of misses on large articles with lots of citations). The only reason why I added one variant was because another user recently created a new redirect (which we didn't recognize—see above); instead of deleting this redirect I renamed it to the one missing pattern in the existing set so that we now have a fully symmetrical list of names for both, dmy and mdy. We could either settle on this and document this set for other template & bot implementors, or could use this as a starting point to slowly work on reducing the necessary naming patterns.

(Well, in the very long run, I envision both {{use xyz dates}} templates being replaced by/merged into one generic template for all kinds of article-wide configuration settings like (purely hypothetical)

{{defaults |lf=AE<!-- language variant --> |df=dmy<!-- date format in body -->,ymd<!-- date format in citations --> |cf=CS1<!-- citation format --> |af=last, first<!-- name format in citations --> |sc=no<!-- serial comma or not --> |dp=.<!-- decimal point --> |s=,<!-- thousands separator --> |ls=,<!-- list separator --> |bp=KB<!-- binary prefixes --> |...}}

but this would be a performance-bottleneck if this would be for more than to document the desired settings for bots and editors, and every template with auto-formating capabilities would have to scan an article's code on its own, so something conceptually different than what MW currently provides might be necessary (variables, environment settings, etc.)... But beyond the scope here...)

--Matthiaspaul (talk) 17:58, 25 August 2020 (UTC)

The list at present is (the first two being the canonical forms):

• '{{ *[Uu]se +dmy +dates *[|}]'
• '{{ *[Uu]se +mdy +dates *[|}]'
• '{{ *[Uu]se +DMY +dates *[|}]'
• '{{ *[Uu]se +MDY +dates *[|}]'
• '{{ *[Uu]se *dmy *[|}]'
• '{{ *[Uu]se *mdy *[|}]'
• '{{ *[Uu]se +DMY *[|}]'
• '{{ *[Uu]se +MDY *[|}]'
• '{{ *[Dd]my *[|}]'
• '{{ *[Mm]dy *[|}]'
• '{{ *[Dd]MY *[|}]'
• '{{ *[Mm]DY *[|}]'

Since you readded '{{ *[Uu]semdydates *[|}]', which is not used in the wild any more (but still supported by your test JS), we either should add '{{ *[Uu]sedmydates *[|}]' as well for symmetry, or delete '{{ *[Uu]semdydates *[|}]'.

--Matthiaspaul (talk) 15:45, 26 August 2020 (UTC)

I included {{ *[Uu]semdydates *[|}] because {{usemdydates}} is a valid redirect to {{use mdy dates}} and because that pattern can't be correctly made part of any of the other patterns and remain meaningful. {{usedmydates}} is not a valid redirect so including a pattern for it is pointless; symmetry be damned. If you want, as you have written to reduce the number of naming variants, → WP:RfD.

—Trappist the monk (talk) 16:03, 26 August 2020 (UTC)

See also: Wikipedia:Redirects_for_discussion/Log/2020_August_28#Template:Usemdydates

--Matthiaspaul (talk) 10:27, 6 September 2020 (UTC)

Quotation in title

Could there be some guidance added re quotes in |title=? Especially since the title itself has quotation marks. Example (from here):

• Bell, J. L. (28 March 2017). ""We pronounce it to be an impudent forgery"". Boston 1775. Retrieved 24 August 2020.{{cite web}}: CS1 maint: url-status (link)

or

• Bell, J. L. (28 March 2017). "'We pronounce it to be an impudent forgery'". Boston 1775. Retrieved 24 August 2020.{{cite web}}: CS1 maint: url-status (link)

Of course consistency-within-article applies, but there might be a wider style preferrence. -DePiep (talk) 08:01, 26 August 2020 (UTC)

Maybe, MOS:QWQ? 64.61.73.84 (talk) 00:16, 27 August 2020 (UTC)

Maybe then, then say so? -DePiep (talk) 00:26, 27 August 2020 (UTC)

I don't see an issue with a pointer to the MOS on the subject. Where were you looking that you thought a comment was needed? --Izno (talk) 18:44, 30 August 2020 (UTC)

? I gave two bulleted examples. They show different quote-quotes (in a title rendering). So I asked: what is our guidance? -DePiep (talk) 20:39, 30 August 2020 (UTC)

No, where in the documentation? --Izno (talk) 23:02, 30 August 2020 (UTC)

OK, MOS:QWQ says it. -DePiep (talk) 09:28, 5 September 2020 (UTC)

Incorrect error message when given param is used

These samples should explain themselves - the first error message is wrong, the second one is right.

• ABC. {{cite book}}: |given= missing |surname= (help)
• ABC. {{cite book}}: |first= missing |last= (help)

ネイ (talk) 15:02, 29 August 2020 (UTC)

The error message is not incorrect. For some mysterious reason, given applies to both first and last, per the doc. Don't feel like hunting for the code to see if this is actually how the module does it. For similar delights, see "Title in italics"? above. 64.61.73.84 (talk) 01:41, 30 August 2020 (UTC)

No, this is an error in the module of some sort. Configuration clearly establishes given as a synonym for first. ['AuthorList-First'] = {"first#", "author-first#", "author#-first", "given#"},. --Izno (talk) 02:05, 30 August 2020 (UTC)

Too damn many aliases ...

• {{Cite book/new|given=Hello|title=ABC}} → ABC. {{cite book}}: |given= missing |surname= (help)
• {{Cite book/new|first=Hello|title=ABC}} → ABC. {{cite book}}: |first= missing |last= (help)

—Trappist the monk (talk) 02:57, 30 August 2020 (UTC)

Looks good. Thank you for your help. ネイ (talk) 03:22, 3 September 2020 (UTC)

Counting semicolons

I have made a slight adjustment to the main module sandbox today. Previous, the (maintenance category) check to see whether there might be two names in a last name displays the message when there is more than one comma, or more than one semicolon. Based on a discussion (of which I did not understand some part at the time), I've changed the check such that any semicolon will emit a maintenance message.

Example:

Cite book comparison

Wikitext	{{cite book|author=Author1; Author2|title=Title}}
Live	Author1; Author2. Title. {{cite book}}: |author= has generic name (help)CS1 maint: multiple names: authors list (link) CS1 maint: numeric names: authors list (link)
Sandbox	Author1; Author2. Title. {{cite book}}: |author= has generic name (help)CS1 maint: multiple names: authors list (link) CS1 maint: numeric names: authors list (link)

--Izno (talk) 18:32, 30 August 2020 (UTC)

That would be this discussion?

—Trappist the monk (talk) 19:04, 30 August 2020 (UTC)

No, this one. Speaking of (since concerns were voiced both there and in mine), I'd like to propose a |org-authorn= (etc.) to take care of our remaining comma problem (which would not perform this check) and remove one need for our parentheses hack (do we have a tracking category for that hack?), and then I think we could probably promote the maint message to an error. But perhaps another thread for that... (It is pertinent to this one, it just may require some more work than I can put in.) --Izno (talk) 19:31, 30 August 2020 (UTC)

Actually, if it would not be implemented already I would have proposed the implementation of the ((accept-this-as-it-is)) syntax for this instead of introducing a new parameter to bypass the checks.

If the purpose of an |org-*= variant would be to semantically distinguish corporate names from human names because they need to be rendered or otherwise treated differently in the future (beyond the comma checking, that is), this would be another case.

--Matthiaspaul (talk) 14:39, 3 September 2020 (UTC)

cite news should have two dates

Articles very often now have original publication dates and then an "updated" date, so we should make "updated" a new optional field for when that happens. 64.228.90.251 (talk) 23:32, 30 August 2020 (UTC)

If it is important to cite the original publication date and the updated date, use |orig-year= for the original date and |date= for the updated date. – Jonesey95 (talk) 01:20, 31 August 2020 (UTC)

|orig-year= sadly does not support a date. We should have |orig-date= however, but we currently don't. Headbomb {t · c · p · b} 14:16, 31 August 2020 (UTC)

|orig-year= supports a date just fine: "Title". Newspaper. 1 January 2020 [Dec 10, 2019]. – Jonesey95 (talk) 15:40, 31 August 2020 (UTC)

Maybe rename |orig-year= to |orig-date=. Also does this work in just cite news or cite web too? -- (please  mention me on reply; thanks!) Emir of Wikipedia (talk) 15:50, 31 August 2020 (UTC)

@Emir of Wikipedia: it uses the same code, so:

• {{cite web |url=https://www.website.com/ |title=Title ||date=1 January 2020 |orig-year=10 December 2019}} → "Title". 1 January 2020 [10 December 2019]. {{cite web}}: Cite has empty unknown parameter: |1= (help)

It works as expected. Maybe just create an alias to accommodate |orig-date=? --RexxS (talk) 21:24, 31 August 2020 (UTC)

I have proposed this many times.

Old threads:

• Help talk:Citation Style 1/Archive 8#Update to the live CS1 module weekend of 18–19 April 2015
• Help_talk:Citation_Style_1/Archive_11#Suggestion_for_orig-date=_parameter
• Help_talk:Citation_Style_1/Archive_54#Date_indicated_in_journal_versus_actual_publication_/_availability_date
• Help_talk:Citation_Style_1/Archive_54#Published_online_parameter?
• Help_talk:Citation_Style_1/Archive_67#Harmonizing_CS1/CS2_into_CS,_and_other_cleanups_for_consistency?

--Matthiaspaul (talk) 12:43, 2 September 2020 (UTC)

I have now implemented |orig-date= and made |orig-year= an alias of it, so that we are free to deprecate it at a later stage (after fixing up existing citations).

Cite book comparison

Wikitext	{{cite book|author=Author|date=2020|orig-date=2019|title=Title}}
Live	Author (2020) [2019]. Title. {{cite book}}: |author= has generic name (help)
Sandbox	Author (2020) [2019]. Title. {{cite book}}: |author= has generic name (help)

Cite book comparison

Wikitext	{{cite book|author=Author|date=2 September 2020|orig-date=7 August 2019|title=Title}}
Live	Author (2 September 2020) [7 August 2019]. Title. {{cite book}}: |author= has generic name (help)
Sandbox	Author (2 September 2020) [7 August 2019]. Title. {{cite book}}: |author= has generic name (help)

--Matthiaspaul (talk) 13:16, 2 September 2020 (UTC)

Thank you. I support |orig-date=, but I have removed the addition of the new parameter |origdate=. The CS1 standard is hyphenated parameters; the unhyphenated parameters are supported only for backwards compatibility. – Jonesey95 (talk) 14:06, 2 September 2020 (UTC)

In fact, I was thinking about skipping the non-hyphenated variant as well. However, I was not sure if we actually have something like a formal decision to not introduce non-hyphenated variants any more. I would appreciate it, in fact, I would even appreciate to deprecate all non-hyphenated forms in the long run (as they are difficult to read and don't wrap as nicely as their hyphenated variants in narrow editing windows.

--Matthiaspaul (talk) 14:25, 2 September 2020 (UTC)

Updated metaparameters and other origyear names.

—Trappist the monk (talk) 15:36, 2 September 2020 (UTC)

But does it work for old dates?

Cite web comparison

Wikitext	{{cite web|date=March 2002|last=Gregory XIII|orig-date=24 February 1582|title=Inter Gravissimas|translator-first=Bill|translator-last=Spencer|url=http://www.bluewaterarts.com/calendar/NewInterGravissimas.htm|work=Inter Gravissimas}}
Live	Gregory XIII (March 2002) [24 February 1582]. "Inter Gravissimas". Inter Gravissimas. Translated by Spencer, Bill.
Sandbox	Gregory XIII (March 2002) [24 February 1582]. "Inter Gravissimas". Inter Gravissimas. Translated by Spencer, Bill.

But let's make it harder.

Cite web comparison

Wikitext	{{cite web|date=September 2, 2020|last=Some English Dude|orig-date=February 29, 1700|title=Some old pamphlet|url=https://en.wikisource.org/wiki/Winkworth,_Catherine_(DNB00)|work=Famous transcriber's website}}
Live	Some English Dude (2 September 2020) [February 29, 1700]. "Some old pamphlet". Famous transcriber's website.
Sandbox	Some English Dude (2 September 2020) [February 29, 1700]. "Some old pamphlet". Famous transcriber's website.

So far, so good. Jc3s5h (talk) 14:00, 2 September 2020 (UTC)

It's just an alias, so it should work exactly the same as |orig-year= does now.

Cite web comparison

Wikitext	{{cite web|date=September 2, 2020|last=Some English Dude|orig-date=Sometime about 246 years ago|title=Some old pamphlet|url=https://en.wikisource.org/wiki/Winkworth,_Catherine_(DNB00)|work=Famous transcriber's website}}
Live	Some English Dude (2 September 2020) [Sometime about 246 years ago]. "Some old pamphlet". Famous transcriber's website.
Sandbox	Some English Dude (2 September 2020) [Sometime about 246 years ago]. "Some old pamphlet". Famous transcriber's website.

The parameter is quite accepting of unusual input. – Jonesey95 (talk) 14:19, 2 September 2020 (UTC)

Actually, there was an error, which I didn't spot at first. The documentation at {{Cite web}} indicates automatic date format if {{Use dmy dates}} or {{Use mdy dates}} are present. Neither of these are present on the talk page. Therefore the format change from the wikitext "September 2, 2020" to "2 September 2020" is an uncommanded change. Jc3s5h (talk) 14:27, 2 September 2020 (UTC)

No error. Help talk:Citation Style 1 § use xxx dates redirects. Spaces between the words use and dmy and dates are required; there is nothing that requires only-and-only-one space. The current version is in error because it does not recognize that multiple spaces are allowed.

—Trappist the monk (talk) 15:15, 2 September 2020 (UTC)

(edit-conflict) Actually, it happens that the template is present in the current version of this talk page (it's in Trappist's debug console example in the thread use xxx dates redirects). If you look at it in section preview, you will see that everything is fine.

--Matthiaspaul (talk) 15:30, 2 September 2020 (UTC)

(edit-conflict) Note, however, that |orig-date= is a free-text parameter (like |orig-year=) without plausibility checking and auto-date formatting. This would be difficult to add because of the extra text beyond just dates carried in this parameter in many real-world citations. Hard to formalize and apply retro-actively, there are just too many variants. Nevertheless, this shortcoming should not keep us from finally implementing a more reasonable parameter name (as in many cases today the |orig-year= parameter already carries a date rather than a year).

Therefore, we may still need an |update-date= parameter just like we have a |publication-date= parameter with full error checking and auto-date formatting. If both are used, we know that the newer one must be the date that would be used instead of the default |date= parameter, and the older one would be treated similar to how we treat |orig-date= now. By providing such more specific parameter names we allow editors (that is those who actually have the document in front of them at this point in time) to document what type of date they are actually entering - information we otherwise don't have (and which might be impossible or at least very difficult and with much overhead involved to retrieve at a later stage, when the original editor and document are no longer around to check). This has been (and still is) a repeating failure mode in the maintenance of the current citation templates.

--Matthiaspaul (talk) 14:25, 2 September 2020 (UTC)

Well, this discussion is mystifying. Reading the OP, it seems that this mainly concerns articles on virtual media, where updates may be easily applied. An updated article in a physical publication would involve a different issue or edition, and there are parameters for these circumstances. AFAIK |orig-year= is purely an informational parameter, and not really material in discovery. If the cited article is published in virtual media, and is an updated version, the update date would be the |date=. I don't think any further date information is required, because any reader would be able to find the updated version, and only that version. A problem would arise when a previous version verified the wikitext but the updated current one doesn't. This has an easy solution: the citation no longer verifies the wikitext, and has no business as a reference. 98.0.246.242 (talk) 04:53, 4 September 2020 (UTC)

Help needed with CS1 "no key" error

Can I get help with a CS1 error at Anti-LGBT rhetoric? I've tried various things, and I don't see where the error lies. This involves four named {{efn}}s in a row, linking via named ref to the explanatory notes defined as list-defined references in the references section.

I'm getting an "LDR has no name" (references no key) error, which apparenty comes from the first {{efn}} in section #Homintern, coded as: {{efn|name="Powell-1981"}}. The #Notes section displays the CS1 "no key" error.

Note that in Note a, there are two links, 'a' and 'b'—which makes no sense, as there is no other {{efn}} in the body that uses "Powell-1981"—and the second link, i.e., 'b', is #cite_ref-Powell-1981_125-1 but that goes nowhere; whereas link 'a' is #cite_ref-Powell-1981_125-0 and goes here, as expected. Thanks in advance for any help you can offer. Mathglot (talk) 04:32, 1 September 2020 (UTC)

I don't know that cs1|2 has a 'no key' error. I can't find the word 'key' anywhere in Anti-LGBT rhetoric. Where (exactly) are you seeing this error? What makes you think that the 'no key' error is a cs1|2 error?

—Trappist the monk (talk) 11:03, 1 September 2020 (UTC)

Possibly related discussions at Wikipedia:Help desk § Help:Cite errors/Cite error references missing key and Wikipedia:Village pump (technical) § Bug in list-defined references?.

—Trappist the monk (talk) 11:12, 1 September 2020 (UTC)

This seems to be related to the long-standing LDR bug (there since the feature's inception). Nested references in single-group reference lists have to be listed first in the list of notes. The problem here seems to be there are two notes with nested references. The only other option I can think of is using multiple note groups, each with a single nested reference at the top. Another option is to use a {{harv}} anchor inside a named {{refn}} entry. This has worked for me, and it may also work for a [{{efn|[{{harv}}]}}] combination. 98.0.246.242 (talk) 15:39, 1 September 2020 (UTC)

Thanks, that appears to be right, and there is indeed a bug. For the record, some links about this:

• Wikipedia:Nesting footnotes#4. List-defined references
• Wikipedia:Village pump (technical)/Archive 183#Bug in list-defined references?
• Help:Cite errors/Cite error references missing key
• T22707

Thanks, Mathglot (talk) 00:40, 4 September 2020 (UTC)

i18n doi inactive categories

We have these three oddball types of categories that are the result of |doi-broken-date= they are: Category:Pages with inactive DOIs and subcategories that have the form Category:Pages with DOIs inactive as of <year> and Category:Pages with DOIs inactive as of <year> <month name>. For internationalization, these category names need to be moved into Module:Citation/CS1/Configuration (they are currently defined and assembled in Module:Citation/CS1/Identifiers).

Category:Pages with inactive DOIs is listed in Category:CS1 maintenance yet this category isn't treated as a 'maintenance' category by cs1|2 – nor are its subcategories. Unlike any other 'maintenance' issue, |doi-broken-date= causes cs1|2 to emit a non-standard message:

Title. doi:10.12345/something (inactive 9 September 2020).{{cite book}}: CS1 maint: DOI inactive as of September 2020 (link)

To standardize, I'm thinking that we can create three (or maybe two) maintenance entries in the error_conditions{} table. This would standardize the whay we apply the categories and support i18n in the same way we support i18n for other maintenance categories.

For me, I would do away with the '(inactive <date>)' message. I think that inactive-dois and dois-with-errors should not auto-link |title= (happens in both cases now) – this same should also apply to |pmc= ...

—Trappist the monk (talk) 19:05, 9 September 2020 (UTC)

Sounds good to me, including disabling auto-linking if a DOI is broken.

While I am not against recording a date in the parameter, I wonder if we actually need this and more than one category for broken DOIs (like we have for invalid ISBNs). From the viewpoint of the readers, a DOI either works or it doesn't. We at Wikipedia have no control over it and cannot do much to fix a broken condition (and even if we could this would be the personal initiative of some individuals but outside the scope of our project, so we don't need to support it if it gets in the way of another feature).

I'm asking because if we could reduce this to a Boolean flag, we could streamline the parameter name to |doi-status=dead or even eliminate it completely by using our special syntax as in |doi=((invalid-number)).

--Matthiaspaul (talk) 21:14, 9 September 2020 (UTC)

As I understand it, |doi-broken-date= is to identify dois that have the correct form here but do not resolve correctly at doi.org. Were we to support accept-this-as-written markup for |doi=, it would not do anything about that. Were we to support accept-this-as-written markup, it could be used for valid dois that fail the validation tests (doi ending with a dot, for example).

—Trappist the monk (talk) 11:09, 10 September 2020 (UTC)

Thanks for the explanation, I wasn't aware of such misformed but correct DOIs (example from Help_talk:Citation_Style_1/Archive_62#template-doc-demo_should_be_a_bad_parameter_in_the_mainspace: |doi=10.1130/focus122009.1.). It makes sense to use the ((syntax)) for this purpose (and thereby eliminate the need for the |no-cat= workaround for this).

So, |doi-broken-date= has more in common with |pmc-embargo-date= - with the logic kind of "reversed". It's good that they are both grouped under the |-date= umbrella now, but we should revisit this if more identifiers would exhibit some date dependencies in the future; perhaps this can be generalized and merged into a |xyz-status= (or |xyz-access-date=) parameter then.

--Matthiaspaul (talk) 23:37, 10 September 2020 (UTC)

I have tweaked Module:Citation/CS1/Identifiers/sandbox:

when |doi-access=free and when |doi= has errors or when |doi-broken-date= is set, |title= will not be auto-linked from |doi=:

{{cite journal/new |title=Title is auto-linked |journal=Journal |doi-access=free |doi=10.12345/something}} → "Title is auto-linked". Journal. doi:10.12345/something.

{{cite journal/new |title=Title not auto-linked |journal=Journal |doi-access=free |doi=10.12345/some thing}} → "Title not auto-linked". Journal. doi:10.12345/some thing. {{cite journal}}: Check |doi= value (help)

{{cite journal/new |title=Title not auto-linked |journal=Journal |doi-access=free |doi=10.12345/something |doi-broken-date=Sep 2020}} → "Title not auto-linked". Journal. doi:10.12345/something (inactive September 2020).{{cite journal}}: CS1 maint: DOI inactive as of September 2020 (link)

{{cite journal/new |title=Title not auto-linked |journal=Journal |doi-access=free |doi=10.12345/some thing |doi-broken-date=Sep 2020}} → "Title not auto-linked". Journal. doi:10.12345/some thing (inactive September 2020). {{cite journal}}: Check |doi= value (help)CS1 maint: DOI inactive as of September 2020 (link)

when |pmc= has errors, |title= will not be auto-linked from |pmc=:

{{cite journal/new |title=Title is auto-linked |journal=Journal |pmc=1}} → "Title is auto-linked". Journal. PMC 1.

{{cite journal/new |title=Title not auto-linked |journal=Journal |pmc=0}} → "Title not auto-linked". Journal. PMC 0. {{cite journal}}: Check |pmc= value (help)

when |pmc= has errors, |title= will not be auto-linked from |pmc= but will be auto-linked from properly formed |doi= with |doi-access=free:

{{cite journal/new |title=Title is auto-linked from pmc |journal=Journal |pmc=1 |doi-access=free |doi=10.12345/something}} → "Title is auto-linked from pmc". Journal. doi:10.12345/something. PMC 1.

{{cite journal/new |title=Title is auto-linked from doi |journal=Journal |pmc=0 |doi-access=free |doi=10.12345/something}} → "Title is auto-linked from doi". Journal. doi:10.12345/something. PMC 0. {{cite journal}}: Check |pmc= value (help)

—Trappist the monk (talk) 11:09, 10 September 2020 (UTC)

Changed the sandboxen so that |doi-broken-date= causes cs1|2 to emit maint messages in the three-styles:

year and month:

{{cite journal/new |title=Title |journal=Journal |doi=10.12345/something |doi-broken-date=Sep 2020}} → "Title". Journal. doi:10.12345/something (inactive September 2020).{{cite journal}}: CS1 maint: DOI inactive as of September 2020 (link)

year:

{{cite journal/new |title=Title |journal=Journal |doi=10.12345/something |doi-broken-date=2020}} → "Title". Journal. doi:10.12345/something (inactive 2020).{{cite journal}}: CS1 maint: DOI inactive as of 2020 (link)

something other than a date:

{{cite journal/new |title=Title |journal=Journal |doi=10.12345/something |doi-broken-date=XXXX}} → "Title". Journal. doi:10.12345/something (inactive XXXX). {{cite journal}}: Check date values in: |doi-broken-date= (help)CS1 maint: DOI inactive (link)

—Trappist the monk (talk) 12:11, 10 September 2020 (UTC)

Fixed an old bug where the template would link to PubMed Central rather than PMC (identifier) if the PMC is under an unexpired embargo:

{{cite journal/new |title=Title |journal=Journal |doi=10.12345/something |doi-broken-date=2020-08-31 |pmc=1 |pmc-embargo-date=2020-12-31}} → "Title". Journal. doi:10.12345/something (inactive 31 August 2020). PMC 1.{{cite journal}}: CS1 maint: DOI inactive as of August 2020 (link) CS1 maint: PMC embargo expired (link)

Regarding the category names, if they stay, perhaps we should change them from "Category:Pages with DOIs inactive as of <yyyy> <MMMMM>" to Category:Pages with DOIs inactive as of <MMMMM> <yyyy>" in the English version of the template.

--Matthiaspaul (talk) 16:29, 10 September 2020 (UTC)

Adjusted maint message and category name accordingly. --Matthiaspaul (talk) 18:19, 10 September 2020 (UTC)

Module:Citation/CS1/Identifiers/sandbox

@Matthiaspaul: At this edit you Restored old version of is_embargo() as lang.formatDate throws an error. Where were you seeing that happen?

—Trappist the monk (talk) 09:43, 11 September 2020 (UTC)

Whenever an embargo is set, regardless if this is in the future or already expired. It bailed out in line 155 ("todays_date = lang.formatDate ('U');"):

{{cite journal/new |title=Title |journal=Journal |doi=10.12345/something |doi-broken-date=2020-08-31 |pmc=1 |pmc-embargo-date=2020-12-31}} → "Title". Journal. doi:10.12345/something (inactive 31 August 2020). PMC 1.{{cite journal}}: CS1 maint: DOI inactive as of August 2020 (link) CS1 maint: PMC embargo expired (link)

It might still be possible to avoid the second pcall() but I thought it would be best to first go back to the last known-good version because it was throwing big red error messages in several examples on this talk page.

--Matthiaspaul (talk) 10:07, 11 September 2020 (UTC)

Too-many-editors-editing-too-many-things-that-are-too-closely-related bug. Lua script error was masked in the testcases page by the error so argument inactive in the function call doi (id, inactive, access) was not set. Next time don't revert, just tell me about it?

—Trappist the monk (talk) 10:35, 11 September 2020 (UTC)

mailinglist

|mailinglist= and |mailing-list= are unique to {{cite mailing list}} I have moved them to the unique_arguments{} table in the whitelist sandbox.

—Trappist the monk (talk) 19:13, 11 September 2020 (UTC)

format-requires-url error message

The various format-requires-url error messages are currently being rendered without a leading space character. Fixed that.

—Trappist the monk (talk) 14:37, 12 September 2020 (UTC)