This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 65 | ← | Archive 68 | Archive 69 | Archive 70 | Archive 71 | Archive 72 | → | Archive 75 |
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)
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)
|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.|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...|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)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)
{{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}}
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:
|-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?|-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.|-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:|-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.|author-first=John
|author-last=Doe
|author-link=John Doe
|author-mask=with *
would result in "with
Doe, John".|-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)
Wikitext | {{cite book
|
---|---|
Live | ——. Title. {{
cite book}} : |author= has generic name (
help)
|
Sandbox | ——. Title. {{
cite book}} : |author= has generic name (
help)
|
|<name>-mask=0
, the name is omitted from the rendering along with its separator:Wikitext | {{cite book
|
---|---|
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)
|
|-maskn=0
in conjunction with |linkn=...
) no longer works:Wikitext | {{cite book
|
---|---|
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)
|
Wikitext | {{cite book
|
---|---|
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)
|
|<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:
|<name>-mask=
is assigned a numeric value, |<name>-link=
is ignored.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)
|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)
|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)
|<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}}
|editors=
with |editorn-last=
/|editorn-last=
).
Headbomb {
t ·
c ·
p ·
b} 16:28, 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)
|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.|editor=
to contain multiple editors, without the benefit of the maintenance category.
Headbomb {
t ·
c ·
p ·
b} 13:30, 8 July 2020 (UTC)
|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.|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.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:
Wikitext | {{cite book
|
---|---|
Live | Title. {{
cite book}} : Cite uses deprecated parameter |authors= (
help); Unknown parameter |editors= ignored (|editor= suggested) (
help)
|
Sandbox | Title. {{
cite book}} : Unknown parameter |authors= ignored (
help); Unknown parameter |editors= ignored (|editor= suggested) (
help)
|
-- Izno ( talk) 14:02, 16 July 2020 (UTC)
In the citation
currently formatted as
{{
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)
{{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}}
{{
cite journal}}
: CS1 maint: untitled periodical (
link)|url=none/doi/pmc/<other-identifier-parameter-name>/<url>
... --
Matthiaspaul (
talk) 12:26, 8 August 2020 (UTC)
|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)
|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)|url=none/doi/pmc/...
(and reserved |chapter-url=none/doi/pmc/...
for potential future use).|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).|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.|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)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)
|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.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)
{{
citation/core}}
){{citation/core}}
{{citation/core}}
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)
Template:Cite book has a problem with the URLs used here. Veverve ( talk) 16:33, 28 August 2020 (UTC)
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)
|title=
. -
DePiep (
talk) 20:50, 30 August 2020 (UTC)
|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)|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)
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)
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)
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)
Extended content
|
---|
Hi all, I would like to propose extending the auto-linking mechanism (providing a default value for In short: if ExampleWith the following code:
You would get the same result as if
MotivationAs 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
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 Since Similar ideas have been suggested before, for instance here by User:Headbomb. StatisticsHere are some figures extracted from the enwiki dump of 2020-04-20. At this point, 189,097 citations had a
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 DiscussionDo 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)
|
@ 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)
Is it time to ask someone to close the RfC? Nemo 06:10, 2 May 2020 (UTC)
{{
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?{{
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.The RFC has been closed, so I have implemented the change in the sandbox:
Wikitext | {{cite journal
|
---|---|
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)
|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).|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.|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").|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)
|title-link=
must not usurp a link to the source.|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.|url=
is set but |title=
is not set. I have sandboxed a correction that will emit the URL–wikilink conflict 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.Wikitext | {{cite journal
|
---|---|
Live | "Title". Journal. PMC 12345. |
Sandbox | "Title". Journal. PMC 12345. |
Wikitext | {{cite book
|
---|---|
Live |
Title. {{
cite book}} : URL–wikilink conflict (
help)
|
Sandbox |
Title. {{
cite book}} : URL–wikilink conflict (
help)
|
{{
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}}
|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)
|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.|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).|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.|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:
|title-link=<identifier-parameter>
without having to duplicate the identifier link as |url=
".because internal links have priority over external linksI 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}}
{{
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}}
{{
cite book}}
: URL–wikilink conflict (
help)silently suppress information given in a cite template.
this is an optional featureHa! For
|pmc=
, not so (alas). When I disabled the oddity that is {{cite journal}} with(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|pmc=
set and|url=
not set
|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.|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.|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".).|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?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.
|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.CS1/ 2and 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.|pmc=
or free-to-read |doi=
. The URL–wikilink conflict 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, |<param>=
missing title could also use a bit of a tweak.|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)
{{
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:
{{
cite journal}}
: Missing or empty |title=
(
help) – no pmc, no title, no url, no title-link{{
cite journal}}
: Missing or empty |title=
(
help) – title-link{{
cite journal}}
: Missing or empty |title=
(
help) – url{{
cite journal}}
: Missing or empty |title=
(
help) – url, title-link{{
cite journal}}
: URL–wikilink conflict (
help) – title, url, title-link{{
cite journal}}
: Missing or empty |title=
(
help) – pmc{{
cite journal}}
: Missing or empty |title=
(
help) – pmc, title-link{{
cite journal}}
: Missing or empty |title=
(
help) – pmc, url{{
cite journal}}
: Missing or empty |title=
(
help) – pmc, url, title-link{{
cite journal}}
: URL–wikilink conflict (
help) – pmc, title, url, title-link|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}}
|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.Can you show how the error message fix that I made is somehow wrong and, because it is wrong, needs to be revertedyes, 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)
{{
cite journal}}
: URL–wikilink conflict (
help) – title, url, title-link{{
cite journal}}
: URL–wikilink conflict (
help) – title, url, title-link{{
cite journal}}
: URL–wikilink conflict (
help) – pmc, title, url, title-link{{
cite journal}}
: URL–wikilink conflict (
help) – pmc, title, url, title-linkif config.CitationClass == "journal" and not is_set(URL) then
if not (is_set (TitleLink) or is_set(URL)) then
[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 advertisementthat 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.
|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}}
using |title-link=
to point to Wikipedia articles should be forbidden
. Limited, certainly; forbidden, no.|title-link=
, perhaps it should be addressed in a separate thread. –
Jonesey95 (
talk) 06:51, 26 May 2020 (UTC)
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)
|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.|url=
and |chapter-url=
: Perhaps |doi=
/|work-doi=
and |chapter-doi=
?|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)|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)
I understand that the code has been further refined, so we're ready to go, right? Nemo 19:15, 7 June 2020 (UTC)
|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=
).|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.|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.)|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?|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.Screenshot for reference: . Nemo 15:37, 12 July 2020 (UTC)
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)
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)
|citeseerx=
, etc. —
Uzume (
talk) 17:31, 8 July 2020 (UTC)
{{
cite Q}}
uses {{
citation}}
so that it can do both periodica and book type citations.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.
|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)
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)
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)
|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)
|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.|url=
as well. This is, where a |wikidata=
parameter could be useful.|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)It'd be something like
Headbomb { t · c · p · b} 17:38, 9 July 2020 (UTC)
|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)
|bibcode=
or |pmid=
.
Headbomb {
t ·
c ·
p ·
b} 19:04, 9 July 2020 (UTC)
|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:
|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:|qid=
, but would support |wdqid=
as well, of course.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)
|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)
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:
|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:
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:
Example 2: Special case if
both |url=
and |title-link=
to Wikidata would be given:
-- Matthiaspaul ( talk) 12:49, 18 July 2020 (UTC)
|-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.|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.)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.|-link=
parameter points to Wikisource, that is, when its value is prefixed by :s:
or :wikisource:
.:d:
or :wikidata:
prefix is used in a |-link=
parameter.|-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.|url=
- if we find one which is problematic, we would remove it from a citation.s:
", not with ":s:
":
{{cite book |title=Aard-vark |title-link=s:1911 Encyclopædia Britannica/Aard-vark |work=Encyclopædia Britannica |date=1911}}
{{cite book |title=Aard-vark |title-link=:s:1911 Encyclopædia Britannica/Aard-vark |work=Encyclopædia Britannica |date=1911}}
:d:
/:wikidata:
) and Commons (:c:
/:commons:
).:de:
would result in [de] being appended to the link, similar to what links created by {{
ill}} look like).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.|noicon=
to control it).|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.
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)
{{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" --
Green
C 01:47, 6 August 2020 (UTC)
{{Cite book/new |title=Wayback Machine}}
no translation necessary for this one. How do we know that?
|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.|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.err_suspect_title = {
message = 'Citation has a suspect title',
anchor = 'suspect_title',
category = 'CS1 errors: suspect title',
hidden = false,
},
|title=((Wayback Machine))
.|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?|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.{{
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. --
Green
C 19:59, 23 August 2020 (UTC)
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 error messages 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?page not found
404 error
website is for sale
HugeDomains.com
[%(%[{<]?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){{cite book/new |title=((Wayback machine))}}
→ Wayback machine.^[%(%[{<]?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 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 [1] 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
{{
cite conference}}
: Unknown parameter |booktitle=
ignored (|book-title=
suggested) (
help)
|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){{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)
oclc=8558302617
, thus.
[2] 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)|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)
References
{{
cite conference}}
: Unknown parameter |booktitle=
ignored (|book-title=
suggested) (
help)
{{
cite conference}}
: Unknown parameter |booktitle=
ignored (|book-title=
suggested) (
help)
|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.|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)
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)
|url=
being a link to a free resource:
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)
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:
{{
cite book}}
: Check date values in: |date=
(
help) with {{Cite book/new |title=Title |date=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):
{{
cite book}}
: Check date values in: |date=
(
help){{
cite book}}
: Check date values in: |date=
(
help){{
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)
|df=
or the presence of a {{use xyz dates}}
template).|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.test_dmydmy_dates
, test_mdymdy_dates
, and test_ssy_dates
.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.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.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)
+
(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
{{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 --> |...}}
'{{ *[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 *[|}]'
.{{ *[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.
Could there be some guidance added re quotes in |title=
? Especially since the title itself has quotation marks. Example (from
here):
{{
cite web}}
: CS1 maint: url-status (
link){{
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)
These samples should explain themselves - the first error message is wrong, the second one is right.
{{
cite book}}
: |given=
missing |surname=
(
help){{
cite book}}
: |first=
missing |last=
(
help)ネイ ( talk) 15:02, 29 August 2020 (UTC)
['AuthorList-First'] = {"first#", "author-first#", "author#-first", "given#"},
. --
Izno (
talk) 02:05, 30 August 2020 (UTC)
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:
Wikitext | {{cite book
|
---|---|
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)
|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)
|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.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)
|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)
|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)
|orig-date=
? --
RexxS (
talk) 21:24, 31 August 2020 (UTC)
|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).Wikitext | {{cite book
|
---|---|
Live | Author (2020) [2019]. Title. {{
cite book}} : |author= has generic name (
help)
|
Sandbox | Author (2020) [2019]. Title. {{
cite book}} : |author= has generic name (
help)
|
Wikitext | {{cite book
|
---|---|
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)
|
|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)
origyear
names.But does it work for old dates?
Wikitext | {{cite web
|
---|---|
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.
Wikitext | {{cite web
|
---|---|
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)
|orig-year=
does now.Wikitext | {{cite web
|
---|---|
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. |
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.|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).|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. 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)
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)
{{efn|[{{harv}}]}}
combination.
98.0.246.242 (
talk) 15:39, 1 September 2020 (UTC)
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:
{{
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)
|doi-status=dead
or even
eliminate it completely by using our special syntax as in |doi=((invalid-number))
.|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).|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).|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.|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)|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)|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)|doi-broken-date=
causes cs1|2 to emit maint messages in the three-styles:
{{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){{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){{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){{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)
@
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)
{{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)|embargo=
ignored 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?|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)
The various format-requires-url error messages are currently being rendered without a leading space character. Fixed that.
Wikitext | {{cite book
|
---|---|
Live | Title. {{
cite book}} : |format= requires |url= (
help)
|
Sandbox | Title. {{
cite book}} : |format= requires |url= (
help)
|
— Trappist the monk ( talk) 14:37, 12 September 2020 (UTC)
This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 65 | ← | Archive 68 | Archive 69 | Archive 70 | Archive 71 | Archive 72 | → | Archive 75 |
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)
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)
|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.|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...|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)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)
{{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}}
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:
|-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?|-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.|-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:|-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.|author-first=John
|author-last=Doe
|author-link=John Doe
|author-mask=with *
would result in "with
Doe, John".|-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)
Wikitext | {{cite book
|
---|---|
Live | ——. Title. {{
cite book}} : |author= has generic name (
help)
|
Sandbox | ——. Title. {{
cite book}} : |author= has generic name (
help)
|
|<name>-mask=0
, the name is omitted from the rendering along with its separator:Wikitext | {{cite book
|
---|---|
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)
|
|-maskn=0
in conjunction with |linkn=...
) no longer works:Wikitext | {{cite book
|
---|---|
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)
|
Wikitext | {{cite book
|
---|---|
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)
|
|<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:
|<name>-mask=
is assigned a numeric value, |<name>-link=
is ignored.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)
|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)
|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)
|<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}}
|editors=
with |editorn-last=
/|editorn-last=
).
Headbomb {
t ·
c ·
p ·
b} 16:28, 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)
|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.|editor=
to contain multiple editors, without the benefit of the maintenance category.
Headbomb {
t ·
c ·
p ·
b} 13:30, 8 July 2020 (UTC)
|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.|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.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:
Wikitext | {{cite book
|
---|---|
Live | Title. {{
cite book}} : Cite uses deprecated parameter |authors= (
help); Unknown parameter |editors= ignored (|editor= suggested) (
help)
|
Sandbox | Title. {{
cite book}} : Unknown parameter |authors= ignored (
help); Unknown parameter |editors= ignored (|editor= suggested) (
help)
|
-- Izno ( talk) 14:02, 16 July 2020 (UTC)
In the citation
currently formatted as
{{
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)
{{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}}
{{
cite journal}}
: CS1 maint: untitled periodical (
link)|url=none/doi/pmc/<other-identifier-parameter-name>/<url>
... --
Matthiaspaul (
talk) 12:26, 8 August 2020 (UTC)
|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)
|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)|url=none/doi/pmc/...
(and reserved |chapter-url=none/doi/pmc/...
for potential future use).|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).|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.|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)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)
|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.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)
{{
citation/core}}
){{citation/core}}
{{citation/core}}
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)
Template:Cite book has a problem with the URLs used here. Veverve ( talk) 16:33, 28 August 2020 (UTC)
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)
|title=
. -
DePiep (
talk) 20:50, 30 August 2020 (UTC)
|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)|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)
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)
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)
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)
Extended content
|
---|
Hi all, I would like to propose extending the auto-linking mechanism (providing a default value for In short: if ExampleWith the following code:
You would get the same result as if
MotivationAs 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
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 Since Similar ideas have been suggested before, for instance here by User:Headbomb. StatisticsHere are some figures extracted from the enwiki dump of 2020-04-20. At this point, 189,097 citations had a
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 DiscussionDo 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)
|
@ 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)
Is it time to ask someone to close the RfC? Nemo 06:10, 2 May 2020 (UTC)
{{
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?{{
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.The RFC has been closed, so I have implemented the change in the sandbox:
Wikitext | {{cite journal
|
---|---|
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)
|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).|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.|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").|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)
|title-link=
must not usurp a link to the source.|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.|url=
is set but |title=
is not set. I have sandboxed a correction that will emit the URL–wikilink conflict 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.Wikitext | {{cite journal
|
---|---|
Live | "Title". Journal. PMC 12345. |
Sandbox | "Title". Journal. PMC 12345. |
Wikitext | {{cite book
|
---|---|
Live |
Title. {{
cite book}} : URL–wikilink conflict (
help)
|
Sandbox |
Title. {{
cite book}} : URL–wikilink conflict (
help)
|
{{
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}}
|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)
|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.|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).|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.|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:
|title-link=<identifier-parameter>
without having to duplicate the identifier link as |url=
".because internal links have priority over external linksI 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}}
{{
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}}
{{
cite book}}
: URL–wikilink conflict (
help)silently suppress information given in a cite template.
this is an optional featureHa! For
|pmc=
, not so (alas). When I disabled the oddity that is {{cite journal}} with(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|pmc=
set and|url=
not set
|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.|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.|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".).|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?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.
|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.CS1/ 2and 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.|pmc=
or free-to-read |doi=
. The URL–wikilink conflict 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, |<param>=
missing title could also use a bit of a tweak.|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)
{{
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:
{{
cite journal}}
: Missing or empty |title=
(
help) – no pmc, no title, no url, no title-link{{
cite journal}}
: Missing or empty |title=
(
help) – title-link{{
cite journal}}
: Missing or empty |title=
(
help) – url{{
cite journal}}
: Missing or empty |title=
(
help) – url, title-link{{
cite journal}}
: URL–wikilink conflict (
help) – title, url, title-link{{
cite journal}}
: Missing or empty |title=
(
help) – pmc{{
cite journal}}
: Missing or empty |title=
(
help) – pmc, title-link{{
cite journal}}
: Missing or empty |title=
(
help) – pmc, url{{
cite journal}}
: Missing or empty |title=
(
help) – pmc, url, title-link{{
cite journal}}
: URL–wikilink conflict (
help) – pmc, title, url, title-link|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}}
|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.Can you show how the error message fix that I made is somehow wrong and, because it is wrong, needs to be revertedyes, 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)
{{
cite journal}}
: URL–wikilink conflict (
help) – title, url, title-link{{
cite journal}}
: URL–wikilink conflict (
help) – title, url, title-link{{
cite journal}}
: URL–wikilink conflict (
help) – pmc, title, url, title-link{{
cite journal}}
: URL–wikilink conflict (
help) – pmc, title, url, title-linkif config.CitationClass == "journal" and not is_set(URL) then
if not (is_set (TitleLink) or is_set(URL)) then
[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 advertisementthat 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.
|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}}
using |title-link=
to point to Wikipedia articles should be forbidden
. Limited, certainly; forbidden, no.|title-link=
, perhaps it should be addressed in a separate thread. –
Jonesey95 (
talk) 06:51, 26 May 2020 (UTC)
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)
|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.|url=
and |chapter-url=
: Perhaps |doi=
/|work-doi=
and |chapter-doi=
?|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)|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)
I understand that the code has been further refined, so we're ready to go, right? Nemo 19:15, 7 June 2020 (UTC)
|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=
).|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.|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.)|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?|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.Screenshot for reference: . Nemo 15:37, 12 July 2020 (UTC)
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)
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)
|citeseerx=
, etc. —
Uzume (
talk) 17:31, 8 July 2020 (UTC)
{{
cite Q}}
uses {{
citation}}
so that it can do both periodica and book type citations.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.
|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)
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)
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)
|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)
|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.|url=
as well. This is, where a |wikidata=
parameter could be useful.|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)It'd be something like
Headbomb { t · c · p · b} 17:38, 9 July 2020 (UTC)
|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)
|bibcode=
or |pmid=
.
Headbomb {
t ·
c ·
p ·
b} 19:04, 9 July 2020 (UTC)
|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:
|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:|qid=
, but would support |wdqid=
as well, of course.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)
|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)
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:
|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:
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:
Example 2: Special case if
both |url=
and |title-link=
to Wikidata would be given:
-- Matthiaspaul ( talk) 12:49, 18 July 2020 (UTC)
|-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.|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.)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.|-link=
parameter points to Wikisource, that is, when its value is prefixed by :s:
or :wikisource:
.:d:
or :wikidata:
prefix is used in a |-link=
parameter.|-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.|url=
- if we find one which is problematic, we would remove it from a citation.s:
", not with ":s:
":
{{cite book |title=Aard-vark |title-link=s:1911 Encyclopædia Britannica/Aard-vark |work=Encyclopædia Britannica |date=1911}}
{{cite book |title=Aard-vark |title-link=:s:1911 Encyclopædia Britannica/Aard-vark |work=Encyclopædia Britannica |date=1911}}
:d:
/:wikidata:
) and Commons (:c:
/:commons:
).:de:
would result in [de] being appended to the link, similar to what links created by {{
ill}} look like).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.|noicon=
to control it).|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.
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)
{{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" --
Green
C 01:47, 6 August 2020 (UTC)
{{Cite book/new |title=Wayback Machine}}
no translation necessary for this one. How do we know that?
|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.|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.err_suspect_title = {
message = 'Citation has a suspect title',
anchor = 'suspect_title',
category = 'CS1 errors: suspect title',
hidden = false,
},
|title=((Wayback Machine))
.|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?|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.{{
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. --
Green
C 19:59, 23 August 2020 (UTC)
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 error messages 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?page not found
404 error
website is for sale
HugeDomains.com
[%(%[{<]?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){{cite book/new |title=((Wayback machine))}}
→ Wayback machine.^[%(%[{<]?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 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 [1] 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
{{
cite conference}}
: Unknown parameter |booktitle=
ignored (|book-title=
suggested) (
help)
|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){{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)
oclc=8558302617
, thus.
[2] 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)|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)
References
{{
cite conference}}
: Unknown parameter |booktitle=
ignored (|book-title=
suggested) (
help)
{{
cite conference}}
: Unknown parameter |booktitle=
ignored (|book-title=
suggested) (
help)
|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.|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)
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)
|url=
being a link to a free resource:
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)
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:
{{
cite book}}
: Check date values in: |date=
(
help) with {{Cite book/new |title=Title |date=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):
{{
cite book}}
: Check date values in: |date=
(
help){{
cite book}}
: Check date values in: |date=
(
help){{
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)
|df=
or the presence of a {{use xyz dates}}
template).|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.test_dmydmy_dates
, test_mdymdy_dates
, and test_ssy_dates
.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.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.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)
+
(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
{{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 --> |...}}
'{{ *[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 *[|}]'
.{{ *[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.
Could there be some guidance added re quotes in |title=
? Especially since the title itself has quotation marks. Example (from
here):
{{
cite web}}
: CS1 maint: url-status (
link){{
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)
These samples should explain themselves - the first error message is wrong, the second one is right.
{{
cite book}}
: |given=
missing |surname=
(
help){{
cite book}}
: |first=
missing |last=
(
help)ネイ ( talk) 15:02, 29 August 2020 (UTC)
['AuthorList-First'] = {"first#", "author-first#", "author#-first", "given#"},
. --
Izno (
talk) 02:05, 30 August 2020 (UTC)
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:
Wikitext | {{cite book
|
---|---|
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)
|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)
|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.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)
|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)
|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)
|orig-date=
? --
RexxS (
talk) 21:24, 31 August 2020 (UTC)
|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).Wikitext | {{cite book
|
---|---|
Live | Author (2020) [2019]. Title. {{
cite book}} : |author= has generic name (
help)
|
Sandbox | Author (2020) [2019]. Title. {{
cite book}} : |author= has generic name (
help)
|
Wikitext | {{cite book
|
---|---|
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)
|
|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)
origyear
names.But does it work for old dates?
Wikitext | {{cite web
|
---|---|
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.
Wikitext | {{cite web
|
---|---|
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)
|orig-year=
does now.Wikitext | {{cite web
|
---|---|
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. |
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.|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).|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. 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)
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)
{{efn|[{{harv}}]}}
combination.
98.0.246.242 (
talk) 15:39, 1 September 2020 (UTC)
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:
{{
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)
|doi-status=dead
or even
eliminate it completely by using our special syntax as in |doi=((invalid-number))
.|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).|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).|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.|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)|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)|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)|doi-broken-date=
causes cs1|2 to emit maint messages in the three-styles:
{{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){{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){{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){{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)
@
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)
{{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)|embargo=
ignored 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?|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)
The various format-requires-url error messages are currently being rendered without a leading space character. Fixed that.
Wikitext | {{cite book
|
---|---|
Live | Title. {{
cite book}} : |format= requires |url= (
help)
|
Sandbox | Title. {{
cite book}} : |format= requires |url= (
help)
|
— Trappist the monk ( talk) 14:37, 12 September 2020 (UTC)