Jump to content

Template talk:Citation/Archive 9

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 5←Archive 7Archive 8Archive 9

Protected edit request on 15 October 2019

Shouldn't a period be rendered at the end by default, as in Template:Cite book etc.?--Hildeoc (talk) 19:05, 15 October 2019 (UTC) Hildeoc (talk) 19:05, 15 October 2019 (UTC)

No. That is one of the differences between Citation Style 2 (the result of this template's formatting in its default settings) and Citation Style 1 (the result of cite book etc). Citation style 1. Has lots. Of silly. Periods, partitioning. Each citation. Into sentence fragments. Citation Style 2 uses commas, instead, and no period at the end either —David Eppstein (talk) 19:11, 15 October 2019 (UTC)
@David Eppstein: Thank you for your reply! But what exactly is wrong with having a period at the end of the footnote here, as is common in scientific / reference works?--Hildeoc (talk) 19:38, 15 October 2019 (UTC)
Nothing wrong with a dot at the end of a {{citation}} template. If you want a dot at the end of a {{citation}} template (in cs2 mode), here are two possibilities:
{{citation |title=Title}}. → Title. – this form is quite common
{{citation |title=Title |postscript=.}} → Title. – this form not so common
Also, please read the documentation at {{edit fully-protected}}; particularly the first paragraph. {{edit fully-protected}} should not be used until there is consensus for the proposed change and at least a rudimentary road-map on what edit(s) is / are required to achieve that consensus.
—Trappist the monk (talk) 19:52, 15 October 2019 (UTC)
@Trappist the monk: Okay, thanks, but once again: Why not add the dot at the end in the default settings here (as it already is in the other citation templates), not least in order to achieve at least some harmonization?--Hildeoc (talk) 19:58, 15 October 2019 (UTC)
If you want harmonization between {{citation}} and the cs1 templates, use only cs1 templates or only {{citation}} or, in a mixed environment, in {{citation}}, set |mode=cs1 (or in the cs1 templates set |mode=cs2). I don't know the exact reason for cs2's lack of terminal punctuation but I believe that there are those who believe that bibliographic listings made using {{citation}} are more grammatically correct than making the same listing using cs1 with its terminal punctuation. I could be wholly wrong about this. {{citation}} was developed more-or-less separately from the cs1 templates. Perhaps if you troll through this talk page's archives, you will discover the answer to the question. If you do, post that answer here.
—Trappist the monk (talk) 20:13, 15 October 2019 (UTC)
Probably the most common form of citation in Wikipedia is a CS1 or CS2 template between a <ref> and </ref> tag. Of the style manuals that heavily influenced CS1 and CS2, the only one that advocates (as one option) footnote superscript numbers in the text with the citations appearing as a footnote or end note with the same number is The Chicago Manual of Style. That manual calls for this style of citation to separate the elements with commas and end the note with a period. For Wikipedia citation templates, I believe it would be most consistent with the roots of the system to use CS2 when end notes are being used, and to alter CS2 to end with a period by default. Jc3s5h (talk) 23:34, 15 October 2019 (UTC)
No. Quite often it is useful to append various text after a citation (though many editors seem oblivious to that possibility), which (for cs2 style) requires a comma. The automatic inclusion of a terminating period (as done by the cite xxx templates) is a dubious convenience. The notion that having to type a single "." is so burdensome it must be done automatically, while not having it requires typing "|postscript=none", seems bass-ackwards. ♦ J. Johnson (JJ) (talk) 06:32, 16 October 2019 (UTC)

How should these be dealt with, now that the dead-url parameter has been deprecated?--Farang Rak Tham (Talk) 20:15, 3 September 2019 (UTC)

Follow the "help" link, which should get you to the text duplicated at Category:CS1 errors: deprecated parameters. Replace |dead-url=yes with |url-status=dead, for example. There is more complete documentation at Template:Cite web#URL. – Jonesey95 (talk) 20:47, 3 September 2019 (UTC)
Thanks, Jonesey95!--Farang Rak Tham (Talk) 12:50, 4 September 2019 (UTC)
Why is there no output when looking at citations? Govvy (talk) 17:15, 20 October 2019 (UTC)
What do you mean by no output?
—Trappist the monk (talk) 17:32, 20 October 2019 (UTC)
When you view the citations at the bottom of the page, there is no output for deadurls, it would be helpful to have an output to tell people that the current citation in question is dead. Govvy (talk) 17:42, 20 October 2019 (UTC)
Are you sure? Here are examples; note the differences (the linked portions of the static text) between the renderings of #1 and #2 (are the same) when compared to #3:
  1. |url-status= omitted so |url= is presumed to be dead:
    Title, archived from the original on 2002-01-20 – Title linked to the archive
  2. |url-status=dead explicitly states that |url= is dead:
    Title, archived from the original on 2002-01-20 – Title linked to the archive
  3. |url-status=live explicitly states that |url= is live:
    Title, archived from the original on 2002-01-20 – Title linked to the original url
—Trappist the monk (talk) 18:18, 20 October 2019 (UTC)

Well, In Predator (franchise) article I tagged cite #10 as a deadlink, yet there is no output. Govvy (talk) 18:26, 20 October 2019 (UTC)

Because you did not provide an archive url when you added |url-status=dead. Read the documentation for that parameter. Without |archive-url= with a value, |url-status= is ignored.
If you want to mark the url in a citation as dead but can't, or don't want to, find an archived copy, use {{dead link}} per the instructions in that template's doc page.
—Trappist the monk (talk) 18:49, 20 October 2019 (UTC)

Thats kind of stupid, an editor should be able to tag citations either as live or dead and that should have an output regardless of an archive url. Govvy (talk) 11:50, 21 October 2019 (UTC)

url-access parameter

The 'free' value is throwing (has been throwing for some time) an validation problem against the CS-1 check engine. At Help:CS1_errors#invalid_param_val, 'free' is not included as a valid parameter, yet it appears in many documentation pages for templates. Is there a plan to either a) include 'free' as an option which is supported by the CS-1 check engine, or b) update documentation to remove this from the viable options? I'd be willing to pitch in to either effort (though really qualified only for the second). Regards --User:Ceyockey (talk to me) 01:23, 19 October 2019 (UTC)

See the CS1 documentation for the access parameters. – Jonesey95 (talk) 01:28, 19 October 2019 (UTC)
Yes, but "free" is NOT allowed; it results in CS-1 errors. --User:Ceyockey (talk to me) 02:27, 19 October 2019 (UTC)
Where does it say that |url-access=free is supported? It is not, and has never been. If there is some place that says that it is supported, that place needs to be corrected.
—Trappist the monk (talk) 02:43, 19 October 2019 (UTC)
It's in all the template documentations, though I know most 'advanced' editors never bother to read that because they already know it all. Look at Template:Citation#Subscription_or_registration_required which is contradicted in the next section, Template:Citation#Access_indicators_for_url-holding_parameters; or Template:Cite_web#Subscription_or_registration_required; etc. --User:Ceyockey (talk to me) 00:31, 26 October 2019 (UTC)
OK—I tracked down the source template for this documentaiton to Template:Citation_Style_documentation/registration and revised it to remove reference to the 'free' option. Not sure how many template documentations this is transcluded into, but should impact these once the individual documentation pages are next edited (or null-edited). --User:Ceyockey (talk to me) 02:31, 26 October 2019 (UTC)
...and it was reverted. https://wiki.riteme.site/w/index.php?title=Template:Citation_Style_documentation/registration&oldid=prev&diff=923072222&diffmode=source --User:Ceyockey (talk to me) 06:26, 26 October 2019 (UTC)
I think that I agree with the revert. cs1|2 really does define four separate access levels; Template:Citation § Subscription or registration required merely lists those access levels with brief definitions of the icon meanings. It is left to subsequent sections of the documentation to specify the application of the access parameters. I have tweaked the doc a bit.
—Trappist the monk (talk) 12:14, 26 October 2019 (UTC)

"language" is equal to "en"

The argument for not deleting the "language = English" parameter is that it makes easier copying and translating articles into Wikipedia sections in other languages. On the other hand, some editors do not like the extra page code. Is there any opinion formed on this subject? (plz ping me in case of answer) ·Carn !? 14:18, 29 November 2019 (UTC)

related discussions?
Help talk:Citation Style 1/Archive 8 § AWB volunteer to clean up Category:CS1 maint: Unrecognized language?
Module talk:Citation/CS1/Archive 11 § Language parameter
Do these answer your questions? If not, please clarify.
—Trappist the monk (talk) 14:50, 29 November 2019 (UTC)
Thank you! As I see, now, than the language annotation for |language=English or |language=en is not displayed, one should not delete them. @Sabbatino: is it ok to you?·Carn !? 16:32, 29 November 2019 (UTC)
@Trappist the monk: I vaguely remember some discussions where editors decided that if the reference is in English then the |language= parameter should not be used, because the "English" is not shown anyways. I have been removing it for a very long time when adding and/or fixing references that come in English language, but the user who started this discussion, started bothering me with it out of the blue. Therefore, I will ask you a clearer question – is it acceptable to not use or remove the "English" tag from the |language= parameter when the source is in English? – Sabbatino (talk) 17:16, 29 November 2019 (UTC)
Do the links that I posted not answer your questions? If not, say how they do not answer your questions.
—Trappist the monk (talk) 17:24, 29 November 2019 (UTC)
Yes, they are for me. Thank you for your participation! But Sabbatino wants direct answer. ·Carn !? 17:38, 29 November 2019 (UTC)

Summary: Trappist the monk had already given this answer on mentioned above page at 15:07, 1 May 2015 (UTC) and 17:21, 6 May 2015 (UTC):If we do this [that |language=English or |language=en don't display the language annotation], it has been proposed at Module_talk:Citation/CS1#Language_parameter that the practice of deleting |language=en and |language=English be stopped.
Quiddity (WMF) wrote on 18:27, 30 April 2015 (UTC) that using |language=English would make the citation's language (meta-info) programatically available for researchers (rather than them having to just assume a missing language=..).

Quote from Module_talk:Citation/CS1#Language_parameter:

You know, thinking about how often WPMED folks (especially the translation task force) copy citations to other Wikipedias, it might be a good idea to keep the |language=en information. Maybe we should hide it, rather than removing it. WhatamIdoing (talk) 17:38, 5 May 2015 (UTC)

That is a good point. Paging Doc James, who does a lot of this copying, I believe. – Jonesey95 (talk) 18:25, 5 May 2015 (UTC)
I think it is good information to provide. Yes we are adding En references to nearly 100 other Wikipedias. Doc James (talk · contribs · email) 19:34, 5 May 2015 (UTC)

So I would say, although it is not necessary to set the "language = en" parameter, but it is not worth removing it when others set it.·Carn !? 20:20, 29 November 2019 (UTC)

There are many other editors besides me that remove the |language=en (English) parameter. I am not the first and not the last editor who uses this practice so stop with the WP:HOUNDING. . – Sabbatino (talk) 22:50, 29 November 2019 (UTC)
Please call these participants into the discussion because I did not understand your arguments for such a deletion. Arguments against are given above.·Carn !? 09:29, 30 November 2019 (UTC)

If you have a policy-based reason to remove the |language=en parameter, please provide it. If someone else has added the parameter, then you should not remove it per WP:CITEVAR, which provides no support for such a change. Thanks, Mathglot (talk) 11:09, 30 November 2019 (UTC)

I am fine with |language=en remaining. Would be useful as mentioned when content is translated via CTX into other languages. Doc James (talk · contribs · email) 16:36, 30 November 2019 (UTC)
Have to agree, I see no good reason to remove the parameter. The template is already designed so it does not show the language when it's English. It does add a little to the wikicode, but it seems too minor to worry about. I'm not suggesting that people mass add the parameter, but if someone has added it, it's probably best not to remove. And more importantly, if you do remove, and someone objects and gives a reasonable reason why they don't want it removed, it seems to me you should revert or at least say they're welcome to revert, and stop doing it in any articles likely to affect this editor who objected. Frankly since there's a fair chance the same reason could apply to other articles for other people, this adds to my view it's best not to remove it at all. Nil Einne (talk) 18:28, 1 December 2019 (UTC)

Spaced endash in date ranges?

MOS:DATERANGE says If at least one item on either side of the en dash contains a space, then a spaced en dash ( – ) is used. This seems to say that a bi-monthly magazine date should look like "May – June 2004". The cite templates, though, require (and reproduce) an un-spaced "May–June 2004". Is this inconsistent with the MoS or did I miss something? —[AlanM1(talk)]— 05:13, 3 December 2019 (UTC)

It's subtle point, but (using parentheses to show what binds to what) it's not
May to (June of 2004) thus May – June 2004
but rather
(May to June) of 2004 thus May–June 2004
Within MOS:DATERANGE the month–month bullet speaks to this. Admittedly the section as a whole is a thicket, but you should have seen it before... EEng 06:44, 3 December 2019 (UTC)
I don't know about should (it's the middle example in that bullet and the whole thing is rather complicated for someone who isn't deeply familiar with it), but I see it now. Thanks. —[AlanM1(talk)]— 21:48, 3 December 2019 (UTC)

Publication-place, location and Citation bot

Some readers are finding the documentation here ambiguous. Specifically:

place: For news stories with a dateline, that is, the location where the story was written. [...] Alias: location publication-place: Geographical place of publication; [...]. If only one of publication-place, place, or location is defined, it will be treated as the publication place and will show after the title; if publication-place and place or location are defined, then place or location is shown before the title prefixed with "written at" and publication-place is shown after the title.

This has led to the maintainers of citation bot interpreting this as meaning use the location parameter for the publication place and delete the publication-place parameter entirely. For example see this diff. I raised this a while back and the general response was that the template documentation was wrong, but then citation bot seemed to stop doing it. Recently it has restarted, and again the response is that the template documentation is wrong. I was referred to Help:Citation_Style_1#Work_and_publisher and Help:Citation Style 2 with the observation that

You're right that Template:Citation currently lists "publication-place" first when naming the variants of this parameter, however I don't see any specific discussion of whether or why it should be preferred.

which seems to be at variance with the documentation. Indeed, it was further stated that

The template documentation is more-or-less not authoritative, especially when there are apparently ambiguities

I've found a clear and unambiguous discussion here, but this seems to be at variance with current advice. The people responding on the citation bot talk page are highly experienced editors of long standing and experts in template construction (which is why I feel like a minnow amongst sharks!): Nemo bis, Trappist the monk, and Izno. Taking their opinions in this matter as gospel, may I suggest that we change the documentation to read:

  • location: The place where the article was published. If the article was written in a different location, see publication-place below. Alias: place.
  • publication-place: Not normally used. Occasionally an article may have been written in a different location from where it was published. In this case use location to specify where it was written and then use publication-place to show where the article was published. If you use publication-place without location it will be displayed as if it were a location.

Comments? Martin of Sheffield (talk) 08:49, 6 December 2019 (UTC)

There is a discussion underway at Help talk:Citation Style 1 § publication-place, place, or location and their proper use which calls into question the necessity of the peculiar mechanism we are using now. This discussion here should be closed and made part of the discussion at WT:CS1.
—Trappist the monk (talk) 12:10, 6 December 2019 (UTC)

Collection

If a work is part of a collection, it would be good to note that it is part of the collection, using Coll. "collection name". - Chris.sherlock (talk) 00:40, 22 January 2020 (UTC)

@Chris.sherlock: Try |series=collection name . Mathglot (talk) 10:47, 22 January 2020 (UTC)

Corporate author that contains a comma

I'm trying to {{cite report}} by a corporate author. If I pass |author=National Academies of Sciences, Engineering, and Medicine, the template complains "CS1 maint: multiple names: authors list". It thinks I'm passing a list of three separate authors via a field that only takes a single author. But it is only a single author, just one with an embedded comma in its multiword name. Is there a way to mask the comma here? {{,}} is a different character, {{comma}} is quite unrelated, and I don't see anything else in Category:Character-substitution templates. DMacks (talk) 03:59, 23 February 2020 (UTC)

So it turns out (thanks DS67!) <nowiki>,</nowiki> works. Not pretty, but good enough for me. Is it worth a note in the docs, or would that be WP:BEANS to circumvent the proper passing of multiple authors? DMacks (talk) 05:06, 23 February 2020 (UTC)
See Help:Citation Style 1 § Accept-this-as-written markup.
{{cite report |title=Title |author=((National Academies of Sciences, Engineering, and Medicine))}}
National Academies of Sciences, Engineering, and Medicine. Title (Report).
—Trappist the monk (talk) 10:01, 23 February 2020 (UTC)
Perfect! Thanks to you and to User:‎Ita140188 who made the same correction to my actual use-case. DMacks (talk) 15:55, 23 February 2020 (UTC)

New errors displayed in articles

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

This week, for the first time ever that I know of, ordinary {{cite web| ... and {{cite new| ... and probably other such templates are suddenly displaying warnings like

"Harv warning: There is no link pointing to this citation. The anchor is named CITEREFLaSala2016."

This type of message used to occur, helpfully, only when there was an explicit Harvard parameter indicating that links were expected: ... |ref=harv }]

That was useful as one normally only put the harv indicator in when the plan was to insert inline citations in the text, and missing one was obviously a problem.

Now, however, the error occurs WITHOUT the ref=harv parameter! This makes no sense: it causes an error if any citation is listed in a bibliography or further reading, and worse, if citations are listed inside an inline ref tag --- it seems to happen from the third citation onwards --- there is a fine specimen at K. Pattabhi Jois, and there is no visible means of suppressing the errors.

This makes checking for ACTUAL errors much more difficult, as false positive "errors" are displayed all over. Would be glad if the status quo could be resumed, please. Chiswick Chap (talk) 07:28, 21 April 2020 (UTC)

See the discussion at Help talk:Citation Style 1 § Cite book Harv warning.
—Trappist the monk (talk) 11:52, 21 April 2020 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Effect of website=

I've been using {{cite book|url=foo|website=bar}} and {{cite book|url=foo|website=bar}}. Should I be using {{citation|url=foo|website=bar}}instead, and what effect would the website= have on the formatting and indexing? Shmuel (Seymour J.) Metz Username:Chatul (talk) 14:36, 22 April 2020 (UTC)

If you're citing a website, you should use either {{citation|url=|website=}} or {{cite web|url=|website=}}. Headbomb {t · c · p · b} 14:39, 22 April 2020 (UTC)
I'm citing a manual[1] that has been scanned into a PDF. You can download the PDF from a web site, but the manual is not a website. Shmuel (Seymour J.) Metz Username:Chatul (talk) 15:22, 22 April 2020 (UTC)
For the purpose of cs1|2, you are citing a book so {{cite book}} (or its redirect {{cite manual}}) is appropriate. Or, since you are using |mode=cs2, {{citation}} without |mode=.
I would avoid the use of |website= because the way the templates render, makes it look like Bitsavers is part of IBM. Instead of |website=, a better choice might be |via=:
{{cite manual |publisher=IBM |title=IBM Operating System/360 Concepts and Facilities |id=C28-6535-0 |year=1965 |url=http://www.bitsavers.org/pdf/ibm/360/os/R01-08/C28-6535-0_OS360_Concepts_and_Facilities_1965.pdf |via=Bitsavers |mode=cs2}}
IBM Operating System/360 Concepts and Facilities (PDF), IBM, 1965, C28-6535-0 – via Bitsavers
—Trappist the monk (talk) 15:42, 22 April 2020 (UTC)
I'm a bit confused. I could find no real documentation of website= except as an alternative to work=. For via, does "in a format other than the original" include scanning into a PDF? Should it be via=shortname, via=domain or via=URL? I do have a URL and it is clear from the URL that the provider (not publisher) is bitsavers.
Is this[2] the markup that you recommend? Shmuel (Seymour J.) Metz Username:Chatul (talk) 16:24, 22 April 2020 (UTC)
Yes, the last one. With |via=bitsavers or |via=bitsavers.org being very optional. I would personally omit those. Headbomb {t · c · p · b} 16:29, 22 April 2020 (UTC)
|website= is an alias of |work= and was created primarily for {{cite web}} because |work= was apparently confusing to editors.
For me, the important part of Template:cite book#csdoc via is: "Name of the content deliverer (if different from publisher)." In this case, Bitsavers is the content deliverer. Annotating the citation this way removes (or reduces) reader-astonishment when they click the title link and end up some place that is definitely not IBM. Because this is a PDF there is probably not much in the way of astonishment but, the link could have connected to a landing page at Bitsavers – that sort of thing is rather common.
It matters not a whit to me which of {{cite book}} or {{citation}} you use as long as whatever you use is internally consistent with other cs1|2 templates in the article. If you are going to keep |via= (contrary to Editor Headbomb, I think you should), I would capitalize Bitsavers.
—Trappist the monk (talk) 16:50, 22 April 2020 (UTC)
I usually figure that the reader will know about bitsavers, and so it will be obvious enough. I believe I have also given web references to , for example, Intel manuals still in print. Also to IBM manuals available in PDF form from IBM. For older ones that people are not so likely to have around, the bitsavers reference is the one that they will expect to use. Gah4 (talk) 08:47, 24 April 2020 (UTC)
I have been around cs1|2 citations for several years and have seen thousands of them. Bitsavers is new to me in this discussion. You should not assume that readers will know anything about anything ever.
—Trappist the monk (talk) 11:13, 24 April 2020 (UTC)

References

  1. ^ IBM Operating System/360 Concepts and Facilities (PDF), IBM, 1965, C28-6535-0 {{cite book}}: |website= ignored (help)
  2. ^ IBM Operating System/360 Concepts and Facilities (PDF), IBM, 1965, C28-6535-0 – via bitsavers

Italics in publisher

I really wish somebody would fix this to allow manual italics. Onai Pass I want to italicize Kabul Times and it won't do it.† Encyclopædius 13:56, 30 April 2020 (UTC)

The Kabul Times is a newspaper, so use |newspaper= not |publisher=. Headbomb {t · c · p · b} 14:10, 30 April 2020 (UTC)
(edit conflict)
This one?
{{cite web|url=https://books.google.co.uk/books?id=ZLPCAAAAIAAJ&q=Onai+Pass+.&dq=Onai+Pass+.&hl=en&sa=X&ved=0ahUKEwjd58PrpZDpAhWGfMAKHUBJC4Y4ChDoAQhAMAM|title=The Kabul Times Annual|publisher=Kabul Times Publishing Agency|p=270|year=1970}}
"The Kabul Times Annual". Kabul Times Publishing Agency. 1970. p. 270.
It appears that you are citing a book so it should be cited as a book. Kabul Times Publishing Agency is the publisher not the newspaper The Kabul Times. Consider using this instead:
{{cite book |url=https://books.google.co.uk/books?id=ZLPCAAAAIAAJ&q=Onai+Pass+.&dq=Onai+Pass+.&hl=en&sa=X&ved=0ahUKEwjd58PrpZDpAhWGfMAKHUBJC4Y4ChDoAQhAMAM |title=The Kabul Times Annual |publisher=Kabul Times Publishing Agency |page=270 |year=1970}}
The Kabul Times Annual. Kabul Times Publishing Agency. 1970. p. 270.
—Trappist the monk (talk) 14:15, 30 April 2020 (UTC)

Propose PhilSci parameter

I would like to propose the addition of a |philsci= parameter, that would generate the text (e.g.) "PhilSci:3886", analogous to how the |arxiv= parameter works. This is a link to the PhilSci-Archive, an archive of papers on the philosophy of science that is cited rather often in Wikipedia, usually with ugly or inconsistent results. Tercer (talk) 22:58, 27 February 2020 (UTC)

The best place to make this proposal is at Help talk:Citation Style 1, where there is already a related conversation in progress. – Jonesey95 (talk) 00:27, 28 February 2020 (UTC)
Thanks for the tip. Tercer (talk) 06:34, 28 February 2020 (UTC)
FWIW, this discussion can be found here: Help_talk:Citation_Style_1/Archive_63#Add_medrxiv_template/parameter_similar_to_biorxiv
--Matthiaspaul (talk) 11:07, 5 November 2020 (UTC)

Others

Moved to WT:CS1#Others. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:11, 10 November 2020 (UTC)

Proposed Consensus parameter

I would like to propose addition of a non-displaying Consensus parameter where a diff link of a talk page discussion can be added, so that normally-unacceptable sources (self-published books at vanity presses, blogs etc) can be marked up and we can avoid subsequent tagging with {{self-published source}}, {{unreliable source}} and the like. Thus:

consensus=<!-- If this source has been specifically discussed, with consensus for inclusion in this article, replace this comment with a permalink to the discussion -->

This should help to avoid confusion and disputes. Guy (help!) 21:52, 27 February 2020 (UTC)

Talk-like discussion of quality of sources does not belong in article source code (which readers and Visual Editor users are unlikely to see), it belongs on the talk page, where we can take a more nuanced view than "this is reliable, yes or no, per the following link". And in any case it is a mistake to treat sources as being reliable in and of themselves, divorced from the context of what claims they are being used as sources for. —David Eppstein (talk) 22:05, 27 February 2020 (UTC)
If this sort of thing is placed in an article, it should be independent of the citation style being used. Rather than incorporate it into a single citation template, just create a new template that can be placed inside any ref tag or after any full citation in a list of references. – Jonesey95 (talk) 22:54, 27 February 2020 (UTC)
As I understood the proposal, it was to add means to link to the relevant discussions on talk pages rather than to move them into the HTML comments in the article. Actually, it is common practise to indicate something special or not obvious to other editors through HTML comments and also provide links to talk threads where appropriate. However, if it does not produce some visible output (as suggested), I don't think we need a special "one-size-fits-all" |consensus= parameter for this, because a HTML comment like:
<!-- See Template_talk:Citation#Proposed Consensus parameter -->
would do just the same as
|consensus=See Template_talk:Citation#Proposed Consensus parameter
and it works everywhere and even more granular.
If we were about to improve the communication among editors for frequently occuring standard cases that can be formalized (like "This parameter value looks odd and needs review", "This parameter value looks odd but has been verified to be correct", "This parameter value was added by a bot, and needs verification by a human", etc.), I propose a different light-weight and easy to memorize communication process and modell, where the individual parameters can be kind-of-prefixed (with prefixes such as "-" and "+" or "?" and "!") to indicate the status of their values:
Help_talk:Citation_Style_1/Archive_71#Possible_scheme_to_mark_parameter_values_for_review
This would make it unnecessary to use HTML comments for these standard cases (they would still be needed for more complicated cases like linking to a talk page thread) and effortlessly make communication faster and more reliable, thereby gaining the quality of citations. However, it only makes sense to be implemented for large and frequently used templates such as the citation templates, and while easy to implement and document with minimal overhead, it would take some time before the community would become used to it and not see such parameters as errors.
--Matthiaspaul (talk) 15:37, 10 November 2020 (UTC)
If the original discussion did not gain any support, it seems unlikely that continuing to beat this particular drum will change that lack of support to support. Too complicated, too jargony.
—Trappist the monk (talk) 15:47, 10 November 2020 (UTC)
Help:Comment tags can accomplish this more easily. --Bsherr (talk) 05:29, 28 February 2020 (UTC)

ISBN line breaks

Moved to Help talk:Citation Style 1/Archive 73 § ISBN line breaks
 – {{u|Sdkb}} talk 20:04, 16 November 2020 (UTC)

Et al

This paper is explicitly attributed to "Ignacio Lopez de Blas; et al", yet the template throws an error if |author2=et al. is used.

Ignacio L. B. Munguira (17 August 2019). Thomas Shafee; Ian Alexander (eds.). "Lysenin" (PDF). WikiJournal of Science. 2 (1): 6. doi:10.15347/WJS/2019.006. ISSN 2470-6345. Wikidata Q76846397.{{cite journal}}: CS1 maint: unflagged free DOI (link)

-- Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:10, 10 November 2020 (UTC)

Because 'et al.' is not an author's name. For cs1|2 to display all authors and 'et al.', use |display-authors=etal.
Is that wiki journal article correctly attributed? The wiki journal article itself names Ignacio L. B. Munguira as the author yet the suggested citation names Ignacio Lopez de Blas. Are they the same person?
—Trappist the monk (talk) 13:12, 10 November 2020 (UTC)
But this question is for {{cite Q}} where the data is pulled from Wikidata. The template would need some means to override or mute a pulled value with a local one, but an empty |last2= gets ignored, and while overriding with something like |last2=xyz would work (if it would not be generating another message) something like |last2=(()) to use the accept-this-as-written syntax to indicate "this is meant to be empty" expectedly does not work either (but might be useful to allow in {{cite Q}}). |display-authors=etal works in general, but does not mute the error message here as well. Seems like {{cite Q}} needs to detect and special-case the various "et al." forms before passing down.
--Matthiaspaul (talk) 15:05, 10 November 2020 (UTC)
It seems to me that this is a discrepancy in wikidata. 'et al.' is not an author's name so does not belong in an author property and therefore does not belong in |authorn=. Some sort of other-unnamed-authors property (a boolean perhaps?) can be used to tell Module:Cite Q to emit |display-authors=etal.
Something that {{cite Q}} should allow is local override of data retrieved from wikidata (which functionality I thought once existed) but this:
{{Cite Q|Q76846397|author2=Red, Yellow}}
does not work:
Ignacio L. B. Munguira; Red, Yellow (17 August 2019). Thomas Shafee; Ian Alexander (eds.). "Lysenin" (PDF). WikiJournal of Science. 2 (1): 6. doi:10.15347/WJS/2019.006. ISSN 2470-6345. Wikidata Q76846397.{{cite journal}}: CS1 maint: unflagged free DOI (link)
—Trappist the monk (talk) 15:35, 10 November 2020 (UTC)
Yeah, it doesn't work for |author2= but works for |last2=. But, as I wrote, it throws another error message then.
Regarding not overriding but muting data pulled from Wikidata, a special parameter for the "et al" case might do, but since it would have to suppress the invalid "et al." in the |author2= parameter it would have to detect this condition by itself anyway (unless this would be a value given by the new parameter, which would look cumbersome). And if it does detect this automatically, it can also just "translate" this into muting the found parameter containing the "et al" and setting |display-authors=etal.
However, as other data can also be wrong in Wikidata, {{cite Q}} still needs some generic way to completely mute parameter data pulled from there; a single Boolean flag won't do, one for each parameter would be needed. The |xyz=(()) notation might be useful to indicate just this on user-level. {{cite Q}} would then mute the parameter and populate some maintenance category so that Wikidata can be cleaned up, whereas CS1 templates would display the "empty parameter" message instead for syntax compatibility (and to allow local cleanup of this syntax).
--Matthiaspaul (talk) 16:03, 10 November 2020 (UTC)
This is not a question for {{Cite Q}}; the error is displayed by {{Citation}}, when it is passed that string, whether by Cite Q or manually. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:27, 10 November 2020 (UTC)
Yes, cs1|2 emits an error message when some form of 'et al.' is included in a name (author, contributor, editor, interviewer, translator) because et al. is not a name. This is not new; cs1|2 has been catching this error since March of 2015. {{cite Q}} shows the error message because it uses {{citation}}. If you want to avoid the error, avoid giving {{citation}} improper parameter values.
—Trappist the monk (talk) 21:01, 10 November 2020 (UTC)
As noted in my OP, the paper is explicitly attributed to "...et al". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:35, 11 November 2020 (UTC)
The WikiJournal page at wikiversity:WikiJournal of Science/Lysenin attributes the authorship as "Author: Ignacio L. B. Munguira , et al."; also explitly. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:29, 10 November 2020 (UTC)
Yes, but in the right column of that article at v:WikiJournal of Science/Lysenin, the recommended citation attributes the article to 'Ignacio Lopez de Blas; et al.' as your {{cite Q}} template above does. So the question stands: Who is the real author of this work?
—Trappist the monk (talk) 21:01, 10 November 2020 (UTC)
The first author is Ignacio L. B. Munguira, who is also known as Ignacio Lopez de Blas. The second author is attributed as "et al". My comment is about the latter. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:35, 11 November 2020 (UTC)
While implementing the (()) proposal to mute an entry pulled from Wikidata in {{cite Q}} would solve this particular case (and many others), I think, we might also need to rethink the "et al." logic in CS1 citations somewhat:
We should still throw an "et al. extra text" or "multiple names" error, if any of the known variants of "et al." are found in a name entry mixed up with another name.
However, specifying something like "et al." in a name parameter is not much different from specifying a corporate name, except for that additional conditions apply.
It should only be allowed if it is found in the last entry (n) in a row which also must not be the first entry (1). Under these conditions we should not throw an error but simply suppress the free-text entry, set the internal |display-author=etal "flag" so that the predefined "et al." message from /Configuration gets displayed at the end of the name list. (In this case, providing the |display-author=etal parameter would be redundant, and |author-linkn= (possibly also |author-maskn=) would not be allowed for the corresponding entry n.)
At present, the COinS metadata does not include any form of "et al.", but for as long as it would be appended in a separate "&rft.au=[et al.]" entry (exact predefined message text also from /Configuration, not from the actual name entry; square brackets to indicate a descriptive entry rather than an actual name), I think it would be even desirable to include this information in the metadata. Otherwise, metadata consumers will never know if the list of names is complete or not.
--Matthiaspaul (talk) 17:19, 11 November 2020 (UTC)
According to this thread (Template_talk:Cite_Q/Archive_2#Para_to_omit_editors), suppressing author and editor names seems to have worked already some months back using a reserved keyword unset added by Trappist.
--Matthiaspaul (talk) 11:31, 12 November 2020 (UTC)
Okay, I modified the sandboxed {{cite Q}} so that it allows to override the name parameters as well. Hopefully, this does not affect the other logic of the template.
It is now possible to set |author2=unset or |author2=(()) to mute the "et al." pulled from Wikidata. The "ed al." condition can be reasserted using |display-authors=etal, resulting in:
{{cite Q/sandbox |Q76846397 |author2=unset |display-authors=etal}}
expanding to:
Ignacio L. B. Munguira; et al. (17 August 2019). Thomas Shafee; Ian Alexander (eds.). "Lysenin" (PDF). WikiJournal of Science. 2 (1): 6. doi:10.15347/WJS/2019.006. ISSN 2470-6345. Wikidata Q76846397. {{cite journal}}: Unknown parameter |_debug= ignored (help)CS1 maint: unflagged free DOI (link)
and being rendered as:
Ignacio L. B. Munguira; et al. (17 August 2019). Thomas Shafee; Ian Alexander (eds.). "Lysenin" (PDF). WikiJournal of Science. 2 (1): 6. doi:10.15347/WJS/2019.006. ISSN 2470-6345. Wikidata Q76846397.{{cite journal}}: CS1 maint: unflagged free DOI (link)
To automate this, code needs to be added to the {{cite Q}} wrapper detecting all variants of "et al." in name parameters, and if found mute the corresponding parameter and set |display-authors=etal.
What also needs to be considered is whether we should better implicitly unset |author-link2= internally if a |author2= parameter overriding the Wikidata entry is found without |author-link2= being specified as a parameter as well. Otherwise, the locally overridden name might be linked to the link target corresponding with the name stored at Wikidata. This might be desirable if we just want to override a typo, but is inappropriate if we override the entry because of a wrong author.
--Matthiaspaul (talk) 02:53, 13 November 2020 (UTC)
The template should not be used to "just ... to override a typo" nor to "override the entry because of a wrong author"; such issues should be fixed at Wikidata. Your change does not address the fact that the paper "is explicitly attributed to "Ignacio Lopez de Blas; et al"; and such attribution does not appear to be rendered in its emitted COinS metadata. This remains an issue for {{Citation}}, not {{{Cite Q}}. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:26, 13 November 2020 (UTC)
(edit-conflict) Actually, I think, the change does address the immediate problem at hands.
For this template (or ultimately similar functionality incorporated into CS1/CS2 itself some day - I think that's the long-time goal?), it is paramount that any information coming from Wikidata can be locally overridden in Wikipedia in convenient means. You cannot expect Wikipedians to edit Wikidata (it's a different project with different rules and a vastly different user interface, even with different participants). Sure, ideally a Wikipedian editor would go there to fix an entry but it also must be possible for the Wikipedian to corrrect the problem locally and forget about it, and for the template to populate some maintenance category indicating that the local contents differs from the Wikidata contents so that other editors (or bots) can go and fix the Wikidata entry.
Therefore, overriding any pulled parameter value must be possible. It didn't work for any of the name-related parameters. My edit addresses this (there still might be a few other missed parameters in the code, though).
You are pointing at a possibly deeper issue regarding the best way how to deal with "et al." in CS1/CS2, though. It is correct that the "et al." condition does not show up in the COinS metadata at present. According to Trappist, this is deliberate.
Our COinS metadata also does not list any editors or other contributors. Presumably, this is also deliberately coded this way because editors are not authors. I inspected the COinS data generated by other parties and found that in the majority of cases, editors are missing from their output as well. Only very few samples were lumping editors into the &rft.au entries as well, sometimes only, if there were no authors at all.
I see the problem, but it is apparently down to limitations in the COinS specification not addressing these cases. I think that it is a pity that we could provide much richer metadata if there only would be some way to include it without abusing or polluting existing entries.
For example, as I wrote above, I personally would think that adding something like "&rft.au=[et al.]" (deliberately in square brackets) as a last entry for authors would not create confusion but would help to avoid it (because authors or other contributors are missing) not only because it may be interesting/important for consumers to know that there are more authors missing, but also when merging entries from different sources, some omitting some authors, some not - are they describing the same work or a different one? Ideally, there would be some established model by others for this already.
It might also be possible to devise a model to add extra metadata info on a "meta-meta" layer on top of COinS in a backward-compatible fashion. It would be ignored by current COinS importers but could be picked up by future ones. As Wikipedia, I think, we are strong enough to establish a standard for this, if there aren't other similar solutions for this already.
However, this is beyond the immediate fix of this problem and, I think, such a discussion would better belong into Help talk:Citation Style 1.
--Matthiaspaul (talk) 13:20, 13 November 2020 (UTC)
Meanwhile I have improved the code to no longer pull author name links from WD if the author name got overwritten by a local parameter and this name does not happen to be the same as the WD one.
--Matthiaspaul (talk) 14:49, 13 November 2020 (UTC)

I think the problem here is that some people are conflating the use of "et al" to mean "the paper cited attributes more authors than I am going to list here" and the very explicit "et al" attribution used by the paper at hand. Perhaps it would help to consider other explicit, pseudonymous, group attributions such as "Pupils of Blah High School" or "RSPB volunteers", or even "Anon.". {{Citation}} would not throw an error of these were included as |author-lastn= nor |authorn=. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:36, 13 November 2020 (UTC)

(edit-conflict) It might be difficult for editors and readers to distinguish between authors omitted by the publisher or authors omitted by our editors. In both cases, the list of authors is incomplete and if this fact is known, we should somehow indicate this in the metadata. The third case, a complete list of authors deliberately truncated down only for display purposes via |display-authors= is not actually a problem here, because in this case the metadata will provide the complete author list regardlessly.
Can you provide examples, or is there an established convention somewhere in the outer world to add, for example, a "&rft.au=[et al.]" or even "&rft.au=et al." entry as a last author name entry in COinS? (I have seen "[and others]" entries in some bibliographical data entries but don't know where they came from.)
--Matthiaspaul (talk) 13:20, 13 November 2020 (UTC)
This person is not conflating as you describe. This person thinks that the problem lies with the paper's editors, who, through ignorance or laziness, failed to name the other authors as any 'real' journal would do. If I'm mistaken, and 'real' journals do attribute papers that they publish to a primary author and an 'et al' group of unknowns, then perhaps I will change my opinion of this paper's attribution.
cs1|2 has |collaboration= for the group-type attributions like those you name:
{{citation |author=Author |collaboration=Pupils of Blah High School |title=Title}}
Author; et al. (Pupils of Blah High School), Title {{citation}}: |author= has generic name (help)
—Trappist the monk (talk) 12:33, 13 November 2020 (UTC)
But for constructions like
{{cite Q/sandbox |Q76846397 |author2=unset |collaboration=authors}}
Ignacio L. B. Munguira; et al. (authors) (17 August 2019). Thomas Shafee; Ian Alexander (eds.). "Lysenin" (PDF). WikiJournal of Science. 2 (1): 6. doi:10.15347/WJS/2019.006. ISSN 2470-6345. Wikidata Q76846397.{{cite journal}}: CS1 maint: unflagged free DOI (link)
the "et al." condition would still not show up in the metadata. (I know, this is deliberate at present, so this is just to illustrate this for Andy.)
--Matthiaspaul (talk) 13:47, 13 November 2020 (UTC)
As far as I know, including et al. in the citation's metadata has not been considered. Likely, I suspect, because before the transition to Lua, the cs1|2 templates imposed a hard limit of 9 authors; rendering eight + et al. but including all nine in the metadata. Author parameters with enumerators of 10+ were ignored:
{{citation/old |title=Title |author=One |author2=Two |author3=Three |author4=Four |author5=Five |author6=Six |author7=Seven |author8=Eight |author9=Nine |author10=Ten}}
One; Two; Three; Four; Five; Six; Seven; Eight et al., Title 
<span class="citation " id="CITEREFOneTwoThreeFour">One&#059;&#32;Two&#059;&#32;Three&#059;&#32;Four&#059;&#32;Five&#059;&#32;Six&#059;&#32;Seven&#059;&#32;Eight&#32;et al.,&#32;''Title''</span><span class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Title&rft.aulast=One&rft.au=One&rft.au=Two&rft.au=Three&rft.au=Four&rft.au=Five&rft.au=Six&rft.au=Seven&rft.au=Eight&rft.au=Nine&rfr_id=info:sid/wiki.riteme.site:Template_talk:Citation/Archive_9"><span style="display: none;">&nbsp;</span></span>
We have also not considered including the name assigned to |collaboration= in the metadata though perhaps we should.
Including some sort of indication of et al. in the metadata, were we to take the decision to do so, should only be done when |display-authors=etal because that parameter/value pair is the only case where cs1|2 'knows' that an en.wiki editor chose to omit author names from the template. With |display-authors=n, cs1|2 only knows that it is supposed to render n names from the list but cannot know if the list is complete or if the list is incomplete.
—Trappist the monk (talk) 15:06, 13 November 2020 (UTC)
The editor in this case is User:Evolution and evolvability; so perhaps he can answer the "ignorance or laziness" question, and say whether or not this is a "'real' journal". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:01, 13 November 2020 (UTC)
10.1016/j.ijcard.2016.05.022 lists its final author as "The MAGIC investigators" (plural).
10.1016/j.jadohealth.2017.05.011 lists its final author as "the Adolescent Trials Network for HIV/AIDS Interventions".
-- Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:50, 13 November 2020 (UTC)
Yeah, but these examples won't pose problems, because these "corporate names" can be added as usual and they will show up in the metadata. This doesn't work for et al. at present.
But here's an (unofficial) way to avoid the problem:
{{cite Q/sandbox |Q76846397 |author2=((et&nbsp;al.))}}
{{cite Q/sandbox |Q76846397 |author2=et&nbsp;al.}} (possibly after the next CS1/CS2 update, see link)
Ignacio L. B. Munguira; et al. (17 August 2019). Thomas Shafee; Ian Alexander (eds.). "Lysenin" (PDF). WikiJournal of Science. 2 (1): 6. doi:10.15347/WJS/2019.006. ISSN 2470-6345. Wikidata Q76846397.{{cite journal}}: CS1 maint: unflagged free DOI (link)
In this case the metadata even contains &rft.au=et al. (with the non-breaking space being converted into a normal space).
--Matthiaspaul (talk) 20:20, 13 November 2020 (UTC)
" This doesn't work for et al. at present." This is precisely the problem that I am seeking to resolve; in cases where "et al" is used by the publisher, as a "corporate name". Unfortunately - and despite denials - this is still being conflated with the more common usage. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:48, 15 November 2020 (UTC)

@Trappist the monk, Matthiaspaul, and Pigsonthewing: Apologies for the delayed response. Being able to indicate et al in the authorlist would be highly useful. I can't speak for other journals that include group attributions in their author metadata ('editorial board' is a common one; example), but the WikiJournals use 'et al' to acknowledge when there have been a large number of contributors who don't individually satisfy the ICMJE authorship defintion but who collaboratively made a significant contribution to an article i.e. when it is adapted from a wikipedia page. For example, the article on Lysenin (wikipedia → WikiJournal+Wikidata). We used to not include 'et al' in the wikidata item and just used the wrapper {{Cite_Q_EtAl}} to calculate the nunmber of authors before the |display-authors= (via {{GetEtAl}}). Switching to using 'et al' explicitly in wikidata was suggested here, which started the errors. Is there a possible solution to this within {{cite Q}}? Otherwise, I can just update {{Cite_Q_EtAl}} to work with the new {{Cite_Q/sandbox}} like it used to for the old {{Cite_Q}} for when these articles need to be cited. I'm keen to remove the error warnings popping up after every usage of it on WP and WV. Indeed, eventuall it would be useful to have an optional equivalent of |authorlink= for the 'et al'. T.Shafee(Evo&Evo)talk 08:12, 24 November 2020 (UTC)

There is a solution that avoids the |authorn=et al.. Give the group of your collaborators a name and then use |collaboration=collaboration name. For example, assume that the name you have chosen for your group of collaborators is 'Wikipedia Editors Collaboration':
{{cite Q/sandbox |Q76846397 |author2=unset |collaboration=Wikipedia Editors Collaboration}} – |author2=unset to remove improper use of et al. as an author name
Ignacio L. B. Munguira; et al. (Wikipedia Editors Collaboration) (17 August 2019). Thomas Shafee; Ian Alexander (eds.). "Lysenin" (PDF). WikiJournal of Science. 2 (1): 6. doi:10.15347/WJS/2019.006. ISSN 2470-6345. Wikidata Q76846397.{{cite journal}}: CS1 maint: unflagged free DOI (link)
—Trappist the monk (talk) 13:49, 24 November 2020 (UTC)
@Trappist the monk: Ah, interesting. I'd not come across that parameter before. Fine by me. Do you know hat the expected timeline is for those features be implemented from sandbox to the main {{cite Q}} template? T.Shafee(Evo&Evo)talk 03:11, 25 November 2020 (UTC)
That is a question best asked of the editors who work on {{cite q}}, isn't it?
—Trappist the monk (talk) 14:24, 25 November 2020 (UTC)
Thanks - done (link). T.Shafee(Evo&Evo)talk 11:58, 26 November 2020 (UTC)

date or year?

The simple citation shows the <year> parameter, but below in the article it says, "The usage of this parameter is discouraged; use the more flexible |date= parameter instead unless both of the following conditions are met:" Likewise, the <cite book> template uses the <date> parameter in the simple citation at the top. Is there a reason it is currently using <year> on this page in the example? Cuñado ☼ - Talk 05:11, 26 November 2020 (UTC)

I don't understand the "both of the following conditions" part of the documentation. |year= can be used in combination with |date= to make disambiguated dates regardless of the date format; it doesn't need the date to be in YYYY-DD-MM format. And when only one of the two parameters is provided, they are more or less synonymous; in what way is |date= more flexible than |year=? My own usage has generally been to choose |year= for references that I want to list as dated only to the year level of granularity (books for instance — I don't think finer-grained dates are very meaningful for book publications and even the years can be somewhat fictional) and to choose |date= for references that have a date and not just a year. —David Eppstein (talk) 06:35, 26 November 2020 (UTC)
So... what is the recommended format? I've been moving a lot of references from <year> to <date> based on the recommendation on this page. If it should be <date>, then the simple citation on this page needs to be updated. Cuñado ☼ - Talk 00:47, 1 December 2020 (UTC)
Use |date= unless the chosen date style is YYYY-MM-DD and it is necessary to disambiguate the year (using short-form referencing where an author created two or more works in the same year). So, Author Blue wrote an article "All about Blue" in 2020 and Author Blue also wrote an article "Blue Shades" in 2020. For dmy or mdy dates, disambiguation is easy: |date=1 February 2020a |date=June 20, 2020b. For ymd dates, the disambiguator is not allowed (|date=2020a-02-01) so write |date=2020-02-01 and |year=2020a.
For the normal case, use |date=
—Trappist the monk (talk) 01:17, 1 December 2020 (UTC)
I realize that this it would probably be a bad idea to do this, but using both date and year allows the disambiguator in the year to be made invisible. E.g. with date=1 February 2020 but year=2020a, the disambiguator works but is not shown in the citation. —David Eppstein (talk) 01:24, 1 December 2020 (UTC)
Not completely invisible (to editors who have maintenance messaging turned on). For me this:
{{cite book |title=Title |author=Blue |date=2020 |year=2020a}}
Blue (2020). Title.{{cite book}}: CS1 maint: date and year (link)
shows a maintenance message:
CS1 maint: date and year (link)
But for readers, yeah, not a good idea to hide the disambiguators...
—Trappist the monk (talk) 01:37, 1 December 2020 (UTC)
Perhaps it is really time to think about options how to split off the disambiguator from the |year=/|date= parameter. I know, it is a shorthand notation for some, but semantically it is odd to specify a disambiguator in a date-related parameter and therefore difficult to learn by newbies and more difficult-than-necessary to parse by machines. Given that the |ref= already allows to specify reference IDs, perhaps the disambiguator should be moved into the |ref= parameter as well.
Ideally, reference IDs would not use single letters, then we could just take |ref=l (with l being a single letter a-z or A-Z) as disambiguator when assembling a reference ID (implying "harv"-style anchor generation), and longer strings (except for the reserved keyword "harv") as complete reference IDs. In the real world, however, single letters are already used as reference IDs in |ref=, but they do not seem to be particularly common so it still might be possible to change existing uses to different reference IDs in order to free single letters for their new use as disambiguators. Alternatively, we could use a special prefix like #, *, @ or similar to distinguish harv-style disambiguators from full reference IDs. Example: |ref=#l (for disambiguator l).
So, something like
{{cite book |title=Title |author=Author |date=2020a}}
or
{{cite book |title=Title |author=Author |year=2020a}}
would become
{{cite book |title=Title |author=Author |date=2020 |ref=#a}}
or
{{cite book |title=Title |author=Author |date=2020 |ref=*a}}
or
{{cite book |title=Title |author=Author |date=2020 |ref=@a}}
Slightly longer, but still easy to type and much more logical.
--Matthiaspaul (talk) 12:21, 2 December 2020 (UTC)

Italics in title

My reading of the documentation is that this template can't be used to display italics in titles. Is that correct?

There is discussion about the need to do this. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:36, 23 December 2020 (UTC)

{{Citation}} can display italics within titles:
{{citation|title=Title with ''one phrase'' in italics|work=Name of Work|author=Author, Firstname|year=1999}} →
Author, Firstname (1999), "Title with one phrase in italics", Name of Work {{citation}}: |author= has generic name (help)
Is that what you meant? – Jonesey95 (talk) 16:07, 23 December 2020 (UTC)

Using author-link1 and author-link2 in

{{cite book |author-last1=Mawer |author-first1=A|author-link1=[[Allen Mawer]] |author-last2=Stenton |author-first2=F M |author-link2= [[Frank Stenton]] |title=The Place-Names of Worcestershire |date=1969 |publisher=Cambridge University Press |location=Cambridge |page=314}}

I am getting errors:

  • Mawer, A; Stenton, F M (1969). The Place-Names of Worcestershire. Cambridge: Cambridge University Press. p. 314. {{cite book}}: Check |author-link1= value (help); Check |author-link2= value (help)

Can anyone see why? I am a bit stumped. Jim Killock (talk) 12:45, 17 January 2021 (UTC)

See Template:Citation § Authors where it says for |author-link=:
Title of existing Wikipedia article about the author—not the author's website; do not wikilink.
Taking out the wikilink markup:
{{cite book |author-last1=Mawer |author-first1=A|author-link1=Allen Mawer |author-last2=Stenton |author-first2=F M |author-link2=Frank Stenton |title=The Place-Names of Worcestershire |date=1969 |publisher=Cambridge University Press |location=Cambridge |page=314}}
Mawer, A; Stenton, F M (1969). The Place-Names of Worcestershire. Cambridge: Cambridge University Press. p. 314.
—Trappist the monk (talk) 12:52, 17 January 2021 (UTC)

False PMID error?

What's wrong with this?

  • Wang Z, Singh A, Jones G, Winzenberg T, Ding C, Chopra A, Das S, Danda D, Laslett L, Antony B (January 2021). "Efficacy and Safety of Turmeric Extracts for the Treatment of Knee Osteoarthritis: a Systematic Review and Meta-analysis of Randomised Controlled Trials". Curr Rheumatol Rep. 23 (2): 11. doi:10.1007/s11926-020-00975-8. PMID 33511486.

Alexbrn (talk) 08:53, 30 January 2021 (UTC)

Open-ended date range

Would it be possible to allow an open-ended date range (meaning "to present"), as in "1997-" (or allow the word "present"), without returning an error? I have often been frustrated when citing a periodical or series and not being able to do this. Also, as far as I can see, the date range only works with year only, not month YYYY to month YYYY, which I have just found I needed for one citation. Laterthanyouthink (talk) 07:30, 8 February 2021 (UTC)

If YYYY is the same year in |date=Month YYYY – Month2 YYYY then, yes, there will be an error:
{{cite book |title=Title |date=January 2021 – February 2021}}
Title. January 2021 – February 2021. {{cite book}}: Check date values in: |date= (help)
The correct form for such date ranges is: |date=Month–Month2 YYYY
{{cite book |title=Title |date=January–February 2021}}
Title. January–February 2021.
When YYYY is not the same for both dates then:
{{cite book |title=Title |date=December 2020 – February 2021}}
Title. December 2020 – February 2021.
I'm not convinced that cs1|2 should support open-ended dates. There is no guarantee that a 'perpetual' source will continue to be 'perpetual' beyond the current year.
—Trappist the monk (talk) 16:01, 8 February 2021 (UTC)
Ah, thanks for that, Trappist the monk. It was indeed within the same year, hence the error I kept getting.
The reason for an open-ended date, from a librarian's point of view, is that whenever there is a need to cite a whole publication that is produced as a series of separate items, such as a series (of books, reports, whatever) or periodical (which includes journals, newspapers, magazines and suchlike), at the point of citing, if it is ongoing, then it is ongoing at that point - and some go on for centuries. I know that it doesn't occur as often as the need to cite a single article in a journal, but I like to add publications produced by the organisation in an article about the organisation, for instance. The only way to do this at present is to use the start date, but it doesn't then represent the whole bibliographic item. Laterthanyouthink (talk) 04:51, 9 February 2021 (UTC)
Wikipedia is not a library. Citing the entirety of a series of publications to support some portion of the text in an article seems to me to do a great disservice to those readers who are interested in consulting the source that supports an en.wiki article.
You could spoof the cs1|2 template by writing 1900–{{CURRENTYEAR}}:
{{cite book |title=Title |date=1900–{{CURRENTYEAR}}}}
Title. 1900–2024.
The same maintenance problem exists because someone will have to fix |date= when {{CURRENTYEAR}} continues to increment after the publication is terminated.
—Trappist the monk (talk) 14:03, 9 February 2021 (UTC)
Hi Trappist the monk. Yes, I realise the differences between Wikipedia and a library, but citing a periodical or series may be viewed as analogous to citing a monograph, for example in many lists of works of individual authors; it's not used to support a specific bit of content other than its existence. The description, including the date of publication, describes the whole entity. Anyway, it's really not a big issue, because it occurs relatively rarely, so I'm prepared to live with it, that's fine. Thanks for the tip re current year - I'm not sure about that because of the problem you mention, but I'll have a think about it next time I encounter one of these. Laterthanyouthink (talk) 02:10, 10 February 2021 (UTC)
It is important to remember that although we call these things citation templates, they are really bibliographic data formatting templates. They have many useful purposes other than citation, and some of those purposes (like the one described above) may reasonably involve open-ended date ranges even if having such a range in an actual citation is unlikely to be useful. —David Eppstein (talk) 05:49, 10 February 2021 (UTC)

Can I ask, the parameter to add dead-link so it displays in the citation list. I simply don't see that happening anymore, found that rather helpful before so I as I know that a citation url needs to be updated or replaced. Not sure why it looks like the code was deprecated. I found that really unhelpful, so how does the dead-link thing work now? Govvy (talk) 11:25, 24 February 2021 (UTC)

There isn't and never has been a dead link parameter. There was |dead-url= and |deadurl=, both of which have been replaced with |url-status=. Use of these parameters determines which of |url= or |archive-url= is attached to |title= when the citation is rendered:
when |url-status=live:
[<url> <title>]
when |url-status=dead:
[<archive-url> <title>]
There is a template, {{dead link}} that renders as a superscripted note:[dead link] cs1|2 has never had a parameter that invokes that template.
—Trappist the monk (talk) 12:02, 24 February 2021 (UTC)
okay, so I really just need to place the deal link template maybe, I always thought it was done from cite. Govvy (talk) 13:03, 24 February 2021 (UTC)

refcite

It seems that every time I see or use {{cite}}, it's wrapped in a <ref>, e.g <ref>{{cite}}</ref>.

Would it be possible to create a single macro that combines both functions? Or is there already such a macro?

Regards, Ben Aveling 12:39, 12 March 2021 (UTC)

As far as I know, en.wiki doesn't have macros. You can use WP:RefToolbar which automatically includes the <ref>...</ref> tags. I presume that WP:VE does the same. I know that RefToolbar does not support {{cite}} (a redirect to {{citation}}); don't know about ve because I don't use that thing. I suppose that you can create a separate template that calls {{citation}} via {{#invoke:Template wrapper|wrap|_template=citation}} ... but that seems to me to be more work that it's worth because you will have to add support for the various attributes supported by <ref>...</ref> tags.
—Trappist the monk (talk) 13:14, 12 March 2021 (UTC)
I think the question is more whether we can move the <ref>...</ref> tags inside the citation template, thereby turning <ref>{{cite X...}}</ref> into {{cite X...}}, but with the latter still appearing as a reference; for example, having the core of {{cite web}} be
<ref>{{#invoke:citation/CS1|citation
|CitationClass=web
}}</ref>
or even including the ref tag inside the module itself. I can see some immediate issues with this (such as naming the refs), though, some of which would be easy (e.g. adding a "name" param) but others which might be more hassle than they're worth. If we go with my coded example, we'd also have to make sure every cite X template had that formatting, and we'd also have to update literally every article on Wikipedia...
In other words, the more I think about it the more I realize that it's a good idea, but one that's come about 15 years too late to really implement. Primefac (talk) 14:06, 12 March 2021 (UTC)
I didn't get as far as adding <ref>...</ref> tags to Module:Citation/CS1 or to the various cs1|2 templates because cs1|2 templates are quite often used without <ref>...</ref> tags in various bibliographic lists. adding a "name" param (among others) is what I was referring to when I mentioned support for the various attributes. Still, OP could write separate templates, though not as you describe, because the module {{#invoke:citation/CS1|citation|CitationClass=<template name>}} swallow's every parameter in the parent frame; those special parameters for <ref>...</ref> tag attributes would be passed on to Module:Citation/CS1 which would then emit Unknown parameter |name= ignored error messages. That was why I suggested using Module:Template wrapper
—Trappist the monk (talk) 14:55, 12 March 2021 (UTC)
I would be against such new templates, because it would be yet one more class of citation templates to maintain, and break most bots dealing with citations. Headbomb {t · c · p · b} 15:01, 12 March 2021 (UTC)

Harv warning

Practically every page on WP has a lot of "Harv warning"s - including this template's own documentation. I understand that originally the templates defaulted to |ref=none and that this warning was only shown if |ref=harv was used - which makes sense. But a while back |ref=harv became the default. So when any cite template is used for things like bibliographies (which are not meant to have <ref>...</ref> pointing to them, otherwise they would be reference entries, not bibliography entries), we get nasty orange warnings littering so many pages. We can add |ref=none to all these entries (and I have done for a few articles) but this is adding yet another burden to the editors and has complications when used with {{sfn}}. Can we turn these warnings off.  Stepho  talk  12:44, 24 April 2021 (UTC)

The warnings do not come from this template or from any of the cs1 templates. The warning and error messages are created by a user script. To get rid of the warnings, you must remove importScript('User:Ucucha/HarvErrors.js'); from User:Stepho-wrs/common.js. But, that will also prevent you from detecting any short-form-to-long-form link errors. You may be able to customize the Ucucha script; see its documentation at User:Ucucha/HarvErrors.
—Trappist the monk (talk) 13:03, 24 April 2021 (UTC)
Weird. I have no memory of editing that file but removing it did fix the problem. Thanks.  Stepho  talk  11:41, 25 April 2021 (UTC)

Permament errors

Post moved[1] to Help talk:Citation Style 1/Archive 78#Permanent_errors. --BrownHairedGirl (talk) • (contribs) 01:51, 21 August 2021 (UTC)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Category:CS1 errors: unsupported parameter includes 22 pages in the Wikipedia namespace: 14 AFD pages, and 8 pages from the Signpost.

These pages should not be edited, so they are perma-clutter in this cleanup category.

Please can the CS1/2 module(s) be modified to stop categorising citation errors in these pages? Cleanup categories should be capable of being fully cleaned up, but these pages prevent that. --BrownHairedGirl (talk) • (contribs) 21:56, 20 August 2021 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Possibly doi-access could be "abstract" or "limited"

doi-access, and similar access parameters deemed to be normally paywalled, only allow value "free" (deemed normally to be "subscription"). It's fairly common to allow free access to the abstract, only, of a paper, which is usually a lot better than nothing at all. Possibly a little more than an abstract is sometimes offered; I'm not sure. I would suggest allowing value "abstract" (and possibly "limited") for these access parameters, with suitable displayed wording such as "free access to abstract only". Possible counter-argument: free access to abstract is very common, perhaps universal, so no real need to specify. Up for discussion. Best wishes, Pol098 (talk) 13:24, 20 September 2021 (UTC)

Put me in the oppose category. I'm sure that I've seen publisher sites where everything is paywalled except some amount of bibliographic information. I've seen paywalled sites where you can read the first page of an article (abstract, first paragraph or a bit more, and a footnote or two). I've seen paywalled sites where an article's reference list is reproduced. If you want to cite something in a journal article's abstract and the abstract is available on the journal article's landing page, use {{cite web}}, set |type=abstract, and omit |doi= or other identifier.
If we support minor variants like |<identifier>-access=abstract for free access to abstract only, where does it end?
—Trappist the monk (talk) 13:57, 20 September 2021 (UTC)
Without trying to push the matter, the large variety of partial information that could be available might possibly justify |<identifier>-access=limited. But I take it that Trappist the monk is against it, and I'm not strongly for it because, as a reader, I'm aware that clicking a DOI link is often useful even without full-text access. Pol098 (talk) 15:06, 20 September 2021 (UTC)
Or alternatively, simply a {{cite journal |... |doi=... |at=Abstract}} or See abstract in {{cite journal |... |doi=...}} if you're citing the abstract. Headbomb {t · c · p · b} 15:16, 20 September 2021 (UTC)
While we should be careful in our selection of possible states and not introduce semantical redundancy, I think these various access and status parameters don't make any sense at all if the real-world states cannot intuitively be associated with the supported states. So, to answer the question, IMO it should stop when we have covered a reasonable abstraction of possible real-world cases. This may also require to review the set of supported states once in a while in order to check if new real-world states have emerged which are worth to be included. --Matthiaspaul (talk) 22:22, 20 September 2021 (UTC)

Non-breaking spaces

Why does the template throw ugly errors on the page for non-breaking spaces in content, including in names, titles, quotations, and other fields? Like this:

  1. Non-breaking spaces are a normal part of written text. They are absolutely required in practically all kinds of text, including in normal content from sources cited, according to our own Manual of Style and authoritative references. They are also mandatory for common punctuation in foreign-language text (e.g., in French for colons, semicolons, question marks, and exclamation marks).
  2. If there is a reason to flag these, then an invisible error should only show up in previews and in the Visual Editor. It should not create ugly breakage in article text displayed to the reader, interfering with reading.
  3. The basic template docs should explain this.

Example of error messages generated by correct text:

  • J. K. Doe (2021), L'espace insécable : oui!, Quoi ? {{citation}}: no-break space character in |author= at position 3 (help); no-break space character in |quote= at position 5 (help); no-break space character in |title= at position 19 (help)

Example of mandatory non-breaking spaces in typographically correct normal English usage:

  • En dashes: NBSP-dash-space, according to MOS:DASH
  • Ellipses: NBSP-dot-dot-dot per MOS:DOTDOTDOT, or space-dot-NBSP-dot-NBSP-dot per the CMOS
  • Initials: J.-NBSP-R.-NBSP-R. Tolkien, per MOS:INITIALS

It drives me nuts to get these messages all the time when I’ve pasted correct text into references, and then have to go track down the correct invisible characters that I or someone else has taken the trouble to enter, strip them out, and see the citation content display incorrectly in an article. Based on no rationale that I can fathom. —Michael Z. 17:08, 4 March 2021 (UTC)

Because intentional non-breaking spaces should be declared with &nbsp;, not just the direct character. Headbomb {t · c · p · b} 17:26, 4 March 2021 (UTC)
And if you just want to clear the errors, just run User:Citation bot on the article, and it will remove all invisible non-breaking spaces. Headbomb {t · c · p · b} 17:47, 4 March 2021 (UTC)
Per MOS:NBSP:
Insert non-breaking and thin spaces symbolically ({{nbsp}}, {{thinsp}}, &nbsp; or &thinsp;), never by entering them directly into the edit window from the keyboard – they are visually indistinguishable from regular spaces, and later editors will be unable to see what they are.
But, the templates {{nbsp}}, {{thinsp}} should not be used in cs1|2 template parameters because they render extraneous markup that corrupts the citation's metadata. The templates render like this:
<span class="nowrap">&nbsp;</span> ← {{nbsp}}
<span style="white-space: nowrap;">&thinsp;</span> ← {{thinsp}}
Careful construction of parameter values may be something that you do, but, the vast preponderance of the no-break space character in |<param>= at position n that I have fixed are copy/pastes from sources that appear to use no-break space characters indiscriminately.
And, last point, cs1|2 are not CMOS, are not APA, are not Bluebook, are not any published style. cs1|2 are amalgams of various styles plus stuff that en.wiki have decided for themselves to make part of the cs1|2 styles.
—Trappist the monk (talk) 17:47, 4 March 2021 (UTC)
Thank you. Is anyone able to fix this? Please update the error message text so:
  1. It makes this clear, say, as Unicode no-break space character in |title= at position 00 should changed to latin entity &⁣nbsp;?
  2. It only appears in previews and editing?
I can update the documentation.
There still remains a problem that literal NBSPs will be transcluded from sources that we have no control over, i.e., in {{cite q}}, and I will mention that problem at the relevant talk page. —Michael Z. 17:49, 4 March 2021 (UTC)
Updated docs.[2] —Michael Z. 17:57, 4 March 2021 (UTC)
@Mzajac, I've been annoyed by this, too. Help talk:Citation Style 1/Archive 74#ISBN line breaking redux may be related. {{u|Sdkb}} talk 05:10, 27 August 2021 (UTC)
The proposed HTML simplifier in CS1/CS2 and a scheme to enhance other templates (like {{nbsp}}, {{thinsp}}, {{lang}}, {{nowrap}}...) to emit internal metadata for CS1/CS2 might become part of a possible solution to this problem, see Help_talk:Citation_Style_1#Guidance_for_science_etc.
--Matthiaspaul (talk) 13:33, 28 September 2021 (UTC)

How to add lang attribute to chapter title?

It seems the template doesn't add a lang attribute to a chapter title based on |language=. Is this intended or not? If it is intended I'll use {{lang}} for that job? Thanks in advance for any help, (pings appreciated) --Marsupium (talk) 17:47, 20 September 2021 (UTC)

It is as intended. We cannot know that the title or chapter-title is in the same language as the text of the rest of the book. If the title or chapter title is written using a non-Latin script, use |script-title= or |script-chapter=. Do not use {{lang}} in cs1|2 |title=, |chapter=, or any other parameter that contributes to the citation's metadata; doing so will corrupt the metadata.
—Trappist the monk (talk) 17:54, 20 September 2021 (UTC)
I propose to allow all language codes in |script-title= and |script-chapter=, not just those for non-Latin scripts. For those in the short list of non-Latin scripts, the parameter would behave just as before (bdi etc.), but for the other codes, after stripping off the code, it would contribute to |title=, but we would have a proper language code we could use for the lang= attribute. See also:
--Matthiaspaul (talk) 22:10, 20 September 2021 (UTC)
Brings up a related issue: At present we also don't set the lang= attribute of the <q> element in |quote= sections. Given that the quote is an extract of the contents of the publication written in the language specified by |language=, I think we would be safe to assign this attribute to the <q> element. (|script-quote= already uses lang=, but only for the <bdi> defined by |script-quote=, not for the quote as a whole.)
--Matthiaspaul (talk) 13:46, 28 September 2021 (UTC)

Free-form "Editors"?

Hi. The template already supports a free-form "authors" field. Could it support a similar free-form "editors" field, please? Thanks. fgnievinski (talk) 05:15, 23 October 2021 (UTC)

No. |editors= was deprecated at this edit and removed at this edit. Of all the 'name' (author, contributor, editor, interviewer, translator) parameters, the only free-form parameter is |authors=. Use of |authors= is discouraged; see Template:Citation § Authors.
—Trappist the monk (talk) 11:25, 23 October 2021 (UTC)

conference param

I suggest making |conference= an alias of |title= and automatically detecting conference type in that case. Needed especially in cases like this for easy conversion from {{cite conference}}. Invasive Spices (talk) 3 December 2021 (UTC)

I don't think so. {{citation}} is not going to automatically support all variations of the 26 cs1 templates. If you want to cite a conference and have the citation rendered in cs2 format, use |mode=cs2. But, ...
This template is a mess:
{{citation | first1=Azaiez Ouled | last1=Belgacem | author2={{small|1=([[ORCID]] [http://orcid.org/0000-0002-5946-7540 0000-0002-5946-7540])}} | first3=Safaa Mohammed | last3=Al-Farsi | first4=Hayel Al | last4=Wawi | first5=Hadi Abdullah Shaif | last5=Al-Yafei | first6=M. | last6=Al-Sharari | first7=Ahmed Mohamed | last7=Al-Hamoudi | first8=Mounir | last8=Louhaichi | author9={{small|1=([[ORCID]] [http://orcid.org/0000-0002-4543-7631 0000-0002-4543-7631])}} | title=Spineless cactus in the Arabian Peninsula: adaptive behaviors and production performances | publisher=[[CGIAR]] | hdl=20.500.11766/9182 | title=IX INTERNATIONAL CONGRESS ON CACTUS PEAR AND COCHINEAL - "CAM crops for a hotter and drier world" | location=[[Coquimbo]], Chile | date=March 26–30, 2017 | s2cid=199636444}}
An ORCID identifier is not an author so does not belong in the |authorn= parameters.
No cs1|2 template can have two |title= parameters because the template cannot see both (MediaWiki supplies only the last of the two) and if it could, which should it display? That is not a decision that a template should be making.
The use of templates inside cs1|2 template should be avoided: the {{small}} template doc specifically notes this.
According to this website, the paper: "Spineless cactus in the Arabian Peninsula: adaptive behaviors and production performances" was presented on 28 March 2017. According to this website, the paper was not included in the conference proceedings. {{cite conference}} is best suited to citing conference proceedings. If the paper is published elsewhere (abstract p. 77 – I didn't find a copy of the full paper online) then perhaps a different cs1|2 template should be used. This abstract appears to be the same as the content provided at hdl:20.500.11766/9182 which does not appear to link to the full paper.
There is nothing of interest at Semantic Scholar so retaining the s2cid identifier seems rather pointless because a reader will gain nothing from it.
The default automatic citation for {{citation}} is a book-style citation. For books, |location= is the location of the publisher, not the location of this conference.
If the abstract is sufficient to support a claim in Cactus, them consider rewriting the template:
{{citation |first1=Azaiez Ouled |last1=Belgacem |first2=Safaa Mohammed |last2=Al-Farsi |first3=Hayel Al |last3=Wawi |first4=Hadi Abdullah Shaif |last4=Al-Yafei |first5=M. |last5=Al-Sharari |first6=Ahmed Mohamed |last6=Al-Hamoudi |first7=Mounir |last7=Louhaichi |title=Spineless cactus in the Arabian Peninsula: adaptive behaviors and production performances |work=[[CGIAR]] |hdl=20.500.11766/9182 |hdl-access=free |date=March 26–30, 2017 |type=Abstract}}
Belgacem, Azaiez Ouled; Al-Farsi, Safaa Mohammed; Wawi, Hayel Al; Al-Yafei, Hadi Abdullah Shaif; Al-Sharari, M.; Al-Hamoudi, Ahmed Mohamed; Louhaichi, Mounir (March 26–30, 2017), "Spineless cactus in the Arabian Peninsula: adaptive behaviors and production performances", CGIAR (Abstract), hdl:20.500.11766/9182
—Trappist the monk (talk) 21:28, 3 December 2021 (UTC)

Wrapper Template:FEIS provokes error message

Every single use of {{FEIS}}, a citation wrapper template, now raises an error: {{citation}}: External link in |via= . What should we do about this? Just remove the link? Replace it with a URL-like string such as feis-crs.org/feis?

Example output:

"Pinus lambertiana". Fire Effects Information System (FEIS). US Department of Agriculture (USDA), Forest Service (USFS), Rocky Mountain Research Station, Fire Sciences Laboratory – via https://www.feis-crs.org/feis/. {{citation}}: External link in |via= (help) – Anon423 (talk) 03:24, 9 February 2022 (UTC)

It is not necessary to subst the template here; a simple transclusion is sufficient.
{{FEIS}} is misusing |via=. When a source is distributed by an entity that is not the publisher, |via= takes the name of the distributor. In this case, the publisher is US Forest Service which is also the distributor so the |via= claim is redundant. And, URLs are only allowed in URL-holding parameters (those with url as part of the parameter name; |url=, |archive-url=, etc). The fix, it seems to me, is to remove |via= from {{FEIS}}; but, discussion about that should take place at that template's talk page.
—Trappist the monk (talk) 14:06, 9 February 2022 (UTC)
Agreed. The link to the FEIS home page is available from the top of the URL that is used in the citation, so it is not needed in the citation. – Jonesey95 (talk) 14:46, 9 February 2022 (UTC)
I brought up the subject at Template talk:FEIS. Since the two of you already agree, If nobody objects, here or there, I'll implement the suggested change in a day or two. – Anon423 (talk) 18:49, 9 February 2022 (UTC)
I substituted the template intending to provide a record that persists after the template is changed. Is that not a good idea? – Anon423 (talk) 18:41, 9 February 2022 (UTC)

revised-date?

Is this the best way to document a living document with a date of original publication and a date for the latest update (ignoring the update)? Does orig-date apply here (and if so, can we make that explicit in the documentation, please?)? Thanks for any advice! HLHJ (talk) 17:20, 29 January 2022 (UTC)

Cite the date of the version that supports the in-text claim. You can add |archive-url= and |archive-date= if you want to link to a specific version of a page. – Jonesey95 (talk) 18:00, 29 January 2022 (UTC)
I came to this Talk page to discuss just this, and a solution I have found for a source which states that it was published on a certain date, and updated on a different date. Linking to an archived version is not appropriate in this case. Most date parameters require a rigidly specified date format—"|date=March 1, 2008, updated March 1, 2012" is not allowed—but orig-date is free-format; it displays its contents in square brackets after the date, and documentation encourages that an explanation be included: |date=1 December 2022|orig-date=originally published 31 November 2022, rendering as "1 December 2022 [originally published 31 November 2022]". When the original publication date is more important, e.g. to establish precedence, I use the parameter backwards: |date=30 November 2022|orig-date=updated 1 December 2022. Maybe the parameter orig-date should have an alternative, optional, name, possibly alt-date or update-date, or both?
I used this in partygate.[1]
@HLHJ: This may be the solution you seek.
@Jonesey95: Maybe also of interest.

  1. ^ Crerar, Pippa (30 November 2021) [updated 1 December 2021]. "Boris Johnson 'broke Covid lockdown rules' with Downing Street parties at Xmas". Daily Mirror.
Best wishes, Pol098(talk) 14:22, 7 February 2022 (UTC)
Thank you, Pol098, Jonesey95! That's just what I needed to know, and I've updated it. HLHJ (talk) 01:42, 10 February 2022 (UTC)

Feature request

It would be useful to have (an) alias(es) for orig-date, to give update dates, translation dates, dates spanning multiple days or years, and other dates that do not fit the standard format. See above. HLHJ (talk) 16:30, 12 February 2022 (UTC)

|archive-date= feature request

{{Webarchive}} extracts the date from the URL if no date is supplied. Can the citation templates learn this trick too? ~Kvng (talk) 00:14, 23 February 2022 (UTC)

Second that. It is a considerable waste of time to go back and extract the date, while the information is already present in archive-url field. -- Kautilya3 (talk) 13:28, 16 April 2022 (UTC)

Spurious error message?

The citation <ref>{{Cite web |title=/e/OS - deGoogled unGoogled smartphone operating systems and online services |author= |website=e Foundation |date= |access-date=22 February 2022 |url=https://e.foundation/e-os}}</ref> is correct (when clicked on it goes to a valid page), but displays {{cite web}}: Check |url= value (help) in the {{reflist}} when invoked in Fairphone.[1]

  1. ^ "/e/OS - deGoogled unGoogled smartphone operating systems and online services". e Foundation. Retrieved 22 February 2022.

Best wishes, Pol098 (talk) 19:35, 25 February 2022 (UTC)

url-status=deviated??

At the moment the documentation says "When the original URL is 'live' but no longer supports the article text, set |url-status=deviated." The documentation does not say what effect this is supposed to have, and I couldn't find any information elsewhere. In practice it seems to work exactly the same as "dead": it shows the archived link first, then "archived at". Personally I think it should act the same as "usurped" or "unfit", but my opinion doesn't matter. What it does need is documenting. At present it seems that there are 3 behaviours (and they seem to cover all possibilities): dead (default), with synonym deviated; live; and usurped, synonym unfit. Best wishes, Pol098 (talk) 15:43, 3 March 2022 (UTC)

Unchanged as of 20 May 22. I also comment that url-status=unfit or usurped generate the warning "{{cite web}}: CS1 maint: unfit URL (link)" when hovering the reference number. Best wishes, Pol098 (talk) 12:40, 20 May 2022 (UTC)

Restore display command

Seems someone nixed or forgot to include |display-translators= along with the commands for authors and editors. Sure it's less important, but it still needs to be available when needed. — LlywelynII 22:09, 15 May 2022 (UTC)

|display-translators= is a valid, supported, and properly functioning parameter:
{{cite book |title=Title |translator=Black, AB |translator2=Brown, CD |display-translators=1}}
Title. Translated by Black, AB; et al.
{{cite book |title=Title |translator=Black, AB |display-translators=etal}}
Title. Translated by Black, AB; et al.
—Trappist the monk (talk) 22:20, 15 May 2022 (UTC)
I see the problem. It pops up as an invalid field error when the |translator= field has been left blank for future use. Instead of anything about a name being required, it tells editors that |display-translators= doesn't exist. — LlywelynII 21:31, 16 May 2022 (UTC)
If you tell the template to display some number of translator names, and there are no translator names to display, then Module:Citation/CS1 will tell you that the number is invalid:
{{cite book |title=Title |display-translators=1}}
Title. {{cite book}}: Invalid |display-translators=1 (help)
because the module can't display one when there are none.
If you give the module something like this:
{{cite book |title=Title |translator= |display-translators=etal}}
Title.
no error message but the module should probably display: Invalid |display-translators=etal
—Trappist the monk (talk) 22:05, 16 May 2022 (UTC)

New Work field

Personally, I find it entirely superfluous since |contribution= and |title= worked just fine. If people prefer to have |url= and |title= mean multiple things for different purposes... eh... seems ill considered to me but fine. The problem is that there seems to be no |work-url= field to allow the work as a whole to be linked. Ok... fine... I'll just format it the old way... but then |issue= doesn't display, apparently out of pure peevishness. What possible reason could there be to surpress the issue number if everything else is correct?

That said, of course it might just be my own misunderstanding of the new code (as above) or a missing field in the documentation around the |work= parameter. — LlywelynII 21:35, 16 May 2022 (UTC)

New? |work= was added to the 'old' wikitext {{citation}} at this edit 20 May 2009 – almost exactly 12 years ago.
—Trappist the monk (talk) 21:47, 16 May 2022 (UTC)
Retrieved from "https://wiki.riteme.site/w/index.php?title=Template_talk:Citation/Archive_9&oldid=1135174091"