Help talk:Citation Style 1

From Wikipedia, the free encyclopedia
  (Redirected from Template talk:Cite episode)
Jump to: navigation, search
the Wikipedia Help Project (Rated B-class, High-importance)
WikiProject icon This page is within the scope of the Wikipedia Help Project, a collaborative effort to improve Wikipedia's help documentation for readers and contributors. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks. To browse help related resources see the help menu or help directory. Or ask for help on your talk page and a volunteer will visit you there.
B-Class article B  This page does not require a rating on the project's quality scale.
 High  This page has been rated as High-importance on the project's importance scale.
 

Contents

Bug[edit]

Please see Emi Takei, footnote #2, where it says that there is no "title" parameter, even though it does exist. Debresser (talk) 16:27, 26 June 2015 (UTC)

From the help

{{cite episode}} will show this error if |series= is blank (even if a |title= is provided).

Keith D (talk) 16:35, 26 June 2015 (UTC)
That should be fixed then to read "Missing or empty |series=" instead of "Missing or empty |title=" Debresser (talk) 21:46, 27 June 2015 (UTC)

Fixed in the sandbox:

{{cite episode/new |title=Title |series=Series}}
"Title". Series. 
{{cite episode/new |title=Title |series=}}
"Title".  Missing or empty |series= (help)

and to prove that I haven't broken the missing title error message for other templates:

{{cite book/new |title= |series=Series}}
. Series.  Missing or empty |title= (help)
{{citation/new |title= |series=Series}}
, Series  Missing or empty |title= (help)

Trappist the monk (talk) 10:30, 4 August 2015 (UTC)

Chapter ignored message[edit]

Where is the problem with chapter=ignored message, like in Apricot oil ? Following are the parameters given (striped away one { and } to freeze template from interpreting):

{cite web
|url=http://www.botanical.com/botanical/mgmh/a/apric050.html
|title=A Modern Herbal
|chapter=Apricot
|publisher=Botanical.com
|author=Mrs. M. Grieve
|accessdate=2008-08-20
|archiveurl= http://web.archive.org/web/20080809232203/http://www.botanical.com/botanical/mgmh/a/apric050.html
|archivedate= 9 August 2008 
|deadurl= no}

What is wrong ? I see here that there are more than 4700 ... --Robertiki (talk) 04:57, 30 June 2015 (UTC)

Try using:
Mrs. M. Grieve. "Apricot". A Modern Herbal. Botanical.com. Archived from the original on 9 August 2008. Retrieved 2008-08-20. 
I don't think |chapter= is valid for {{cite web}}. What is the |chapter= in your citation is the |title= of an individual web page, and what is the |title= is the name of a |work= hosted on that web site. Imzadi 1979  05:06, 30 June 2015 (UTC)
Or, alternatively, since this is a book hosted online, use {{cite book |...}}. Peter coxhead (talk) 05:54, 30 June 2015 (UTC)
I am non interested about the article Apricot oil, I could also have made the Aval example or any other of the 4,700 articles that unexpectedly now signal this error. The problem is that in the example I don't see any chapter parameter, so what ? --Robertiki (talk) 02:36, 1 July 2015 (UTC)
Sorry, now I see it. --Robertiki (talk) 02:37, 1 July 2015 (UTC)
Let us change example, in article Aval:
{Cite journal 
| last =Badr 
| first = Gamal Moursi 
| contribution =Islamic Law: Its Relation to Other Legal Systems 
| journal= American Journal of Comparative Law 
| volume=26 
| issue=2 
| title = Proceedings of an International Conference on Comparative Law, Salt Lake City, UT, February 24–25, 1977] 
| date=Spring 1978 
| pages=187–98 
| doi = 10.2307/839667 
| ref=harv 
| jstor= 839667}

Where is the "chapter" parameter ? Sorry for the false start. Maybe I don't understand how it works. --Robertiki (talk) 02:40, 1 July 2015 (UTC)

What's wrong here is the reference itself. Either this is a journal article, in which case the required parameters are |title= and |journal=, or it's a book in which the proceedings of a conference were published, in which case the required parameters are |chapter= and |title=. If the proceedings of the conference were published as a journal volume, then it should be treated as a set of journal articles. Peter coxhead (talk) 06:49, 1 July 2015 (UTC)
What's wrong is that we have no parameter to indicate that this issue of the journal is a special issue with its own title. The closest one can get is to pretend that, instead of a journal, it's a book series (and then italicize it manually):
  • {{Cite book | last =Badr | first = Gamal Moursi | contribution =Islamic Law: Its Relation to Other Legal Systems | series= ''[[American Journal of Comparative Law]]'' | volume=26 | issue=2 | title = Proceedings of an International Conference on Comparative Law, Salt Lake City, [[Utah|UT]], February 24–25, 1977 | date=Spring 1978 | pages=187–98 | doi = 10.2307/839667 | ref=harv | jstor= 839667}}
  • Badr, Gamal Moursi (Spring 1978). "Islamic Law: Its Relation to Other Legal Systems". Proceedings of an International Conference on Comparative Law, Salt Lake City, UT, February 24–25, 1977. American Journal of Comparative Law 26 (2). pp. 187–98. doi:10.2307/839667. JSTOR 839667. 
David Eppstein (talk) 07:34, 1 July 2015 (UTC)
|contribution= is an alias of |chapter=. {{cite journal}} does not support |chapter= and so does not support |contribution=. The thing that throws the spanner in the works is the conference information. If you rewrite the citation as {{cite conference}} you get this:
  • {{Cite conference | last =Badr | first = Gamal Moursi | title=Islamic Law: Its Relation to Other Legal Systems | journal= [[American Journal of Comparative Law]] | volume=26 | issue=2 | conference= Proceedings of an International Conference on Comparative Law, Salt Lake City, [[Utah|UT]], February 24–25, 1977 | date=Spring 1978 | pages=187–98 | doi = 10.2307/839667 | ref=harv | jstor= 839667}}
  • Badr, Gamal Moursi (Spring 1978). Islamic Law: Its Relation to Other Legal Systems. Proceedings of an International Conference on Comparative Law, Salt Lake City, UT, February 24–25, 1977. American Journal of Comparative Law 26 (2): 187–98. doi:10.2307/839667. JSTOR 839667. 
The code supporting {{cite conference}} should probably be tweaked so that the article title is rendered quoted and not italicized when |journal= (or an alias) is part of the template.
Trappist the monk (talk) 11:14, 1 July 2015 (UTC)
With the fix to quote the article title, I guess this is ok, but the question remains: why do editors want to include the conference information in this case? The purpose of a citation is not to tell you all about the source (if it was, why not include the number of pages in a book, the number of illustrations, and so on?), but to give sufficient information to locate the source. The title of the published entity (here the journal) is sufficient. {{Cite conference}} should be used when the proceedings are published as an independent entity, i.e. a book. Peter coxhead (talk) 14:05, 1 July 2015 (UTC)
In the case of some leading computer science cconferences (some of which are indeed published in journals in this way) the journal part of the citation tells you where to find the publication but the conference part tells you something about how important the paper was regarded at the time of publication, since the good conferences are typically much more selective than the journals. So both pieces are important parts of the citation. —David Eppstein (talk) 15:30, 1 July 2015 (UTC)
Agreed. I also agree that display should be corrected to italicize the right title depending on the parameters in use.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  23:36, 30 July 2015 (UTC)

accessdate when url changes[edit]

When a Wikipedia editor discovers that a URL has changed, I think it is good for the editor to update the url parameter. If there is an existing accessdate parameter, and the editor does not wish to take the time to verify that the reference supports the article text, that leaves a dilemma. Leaving accessdate unchanged falsely implies to most users that the displayed URL worked on that date. Removing the accessdate parameter removes the fact that some other editor claimed to have verified that the linked page supported the article text on that date. —Anomalocaris (talk) 17:52, 1 July 2015 (UTC)

What use is the new URL if it does not support the text that it claims it support. When changing a URL it should obviously be checked to verify that it still supports the text that it is attached to. Keith D (talk) 21:37, 2 July 2015 (UTC)
It may be obvious to you, but it is not obvious to me. Several newspaper websites, including The Jerusalem Post, Haaretz, and The Guardian have recently changed their URLs of existing articles. In some cases old URLs automatically redirect to new URLs; in other cases the old URL redirects to the home page, but the new URL can often be located by using the website's search feature and searching for the original article title. There is no doubt that it is the same article, because it has the same author, title, date, and publication. I should not have to re-verify that the article still supports the text, especially if the article is quite long and the subject abstruse. But I should update the link, as the new URL is more likely to be supported in the future. For example, when The Jerusalem Post changed from URLs of the form fr.jpost.com with numeric article names to URLs of the form www.jpost.com with friendly names, for awhile, the old URLs redirected to the new ones, but they don't any more. I believe that editors who update URLs are helping Wikipedia, and I don't believe they should be required to reread each external article so affected to assure that it still supports the text. Furthermore, there is the point in the next thread that a given reference may be cited many times in one article. Is the editor required to verify that each point used for a given reference is supported by the reference? And what if some are and some are not?—Anomalocaris (talk) 22:21, 2 July 2015 (UTC)
There's no problem updating the accessdate along with the URL.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  01:56, 31 July 2015 (UTC)

Add column and day of week parameters?[edit]

Hello. Over at Template talk:Cite newspaper The Times I've been asking why that template can't redirect to {{cite news}}. The key reasons seem to be the lack of a column parameter, as well as a 'day of week' parameter, in this template. Reasons for why these parameters are useful are given there. Would it be possible to add those parameters to cite news, or are there good reasons for not doing so? Thanks. Mike Peel (talk) 08:18, 7 July 2015 (UTC)

Should be supported in the general template, since the rationales for them pertain to any newspaper with columns and/or with multiple daily editions. The templates should be merged.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  23:22, 30 July 2015 (UTC)

Allow "Quarter" dates in Date parameter?[edit]

To my recollection, reference templates such as {{cite journal}} used to allow entries such as "First Quarter 2005" in the 'date' parameter up until several months back. Now I realize that "Winter 2005"- and "January–March 2005"-type entries are still allowed, but I was wondering if "First Quarter"-type entries in the 'date' parameter were ever likely to be allowed again? There are definitely journals that publish by "First Quarter" dates rather than "Winter" or "January–March" dates, so it would be desirable if "Quarterly" dates would be allowed in these reference templates' 'date' parameters again. --IJBall (contribstalk) 21:12, 9 July 2015 (UTC)

This topic has been discussed before. cs1|2 take date format guidance from MOS:DATEFORMAT which is mute on quarterly dates (there is a brief mention at WP:SEASON but that date style is not listed in the Acceptable date formats table).
Trappist the monk (talk) 21:48, 9 July 2015 (UTC)
In that previous discussion, I commented that this should be allowed. The MOS might be silent on this, but we cannot while still providing the facilities to faithfully render the publication information for sources in CS1/CS2. We already override the MOS to capitalize season names when used in citation dates, and I agree with that as it promotes consistency between "January 2005" and "Winter 2005". Since my comments last October, I think that the word "quarter" should also be capitalized in citations for the same consistency reasons. I would also whitelist "Q1 2005" as a standard abbreviation analogous to the abbreviations for month names. This abbreviation convention is already quite common in corporate financial documents, among other places. Imzadi 1979  22:30, 9 July 2015 (UTC)
Yes, "Quarter"-type publication dates are definitely common in some of the official documents I run across from organizations and businesses when looking for references. I absolutely agree that the by "Quarter" dates should probably be included in the 'date' parameters again, esp. as the MOS is actually silent on "disallowing" their use. --IJBall (contribstalk) 22:40, 9 July 2015 (UTC)
Support allowing quarters (and seasons), but question whether this should be directly mingled with, rather than juxtaposed against, date data. For one thing, mingling them could break various tools. For another, many publications use both; the quarter or season is at least as much akin to title data as date data: Journal of Chicken Lips, June/July 2015 (Summer issue), etc. For a third, they can span multiple quarters or seasons, which spans themselves can cross a year boundary (Winter 2014/2015, 4Q 2014 / 1Q 2015, etc.)  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  23:25, 30 July 2015 (UTC)

Author’s initials only[edit]

This news article is credited only to “C.R.”. How should this be handled? (I note that author is deprecated.)

  • |author=<!-- C.R. -->?
  • |author=C.R.?
  • |first=C. |last=R.?

80.192.177.23 (talk) 00:38, 13 July 2015 (UTC)

Until you discover who C.R. is, and can provide a complete name, |author=C.R. works. Can you show where it is written that |author= is deprecated? That assertion is not true so anyplace saying otherwise needs to be corrected.
Trappist the monk (talk) 00:51, 13 July 2015 (UTC)
Thanks. I misread: it's |coauthor= that's deprecated, not |author=. —80.192.177.23 (talk) 03:17, 13 July 2015 (UTC)
FWIW, I always put these in scare-quotes, e.g. "C. R.", and include a note (another good use for the |note= parameter I've proposed) that a more complete name for the author is not presently available.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  23:18, 30 July 2015 (UTC)

Feature request: |note= parameter[edit]

It'd be nice to have a |note= parameter, so that things like "Source is a blog, but published by a project of the city government; primary but not self-published.", kept with (inside) the citation instead of external to it in an HTML comment. It's pretty common to to use a pseudo-parameter like |note=, or (in other contexts, like cleanup/dispute templates) |reason=, for this purpose, but CS1's auto-detection and red-flagging of unrecognized parameters makes this impossible at present.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  16:06, 15 July 2015 (UTC)

It would be nicer still to have a |null= to work around the red-flagging because there are time when as SMcCandlish unrecognized parameters are convenient. -- PBS (talk) 22:56, 15 July 2015 (UTC)
I think the problem with the example above is that all of the other parameters in CS1 are for bibliographic data that theoretically at least is understandable to readers and meaningful outside Wikipedia. Whereas that comment would be understandable to maybe 1 or 2 out of every 1,000 Wikipedia readers – the ones who are familiar with what WP editors usually mean when they call a source "primary". For that sort of thing, an HTML comment embedded in the wikitext seems like exactly the right way to handle it. Let's keep meta comments and WP-specific issues separate from the data. – Margin1522 (talk) 11:21, 16 July 2015 (UTC)
SMcCandlish is not proposing a display variable, but one to be used in place of <!-- a hidden comment --> as the parameter |reason= is used in the template {{Clarify}}. -- PBS (talk) 19:35, 16 July 2015 (UTC)
I can see the advantage of a |note= parameter. I find the |others= parameter very useful - today I've used it to flag "(published anonymously)". Library catalogs sometimes use square brackets for this. Aa77zz (talk) 20:19, 16 July 2015 (UTC)
Like this from Finch?:
{{ cite book | last=Leach | first=William Elford | author-link=William Elford Leach | year=1820 | chapter=Eleventh Room | title= Synopsis of the Contents of the British Museum | place=London | publisher=British Museum | edition=17th| pages=65-70 | others=(published anonymously) }}
Specifically these bits:
| publisher=British Museum and | others=(published anonymously)
One contradicts the other. And, from the template documentation at Authors:
  • others: To record other contributors to the work, including illustrators and translators. For the parameter value, write Illustrated by John Smith or Translated by John Smith.
I think that your use of |others= as you have done is an improper use of the parameter.
Trappist the monk (talk) 22:23, 16 July 2015 (UTC)
I was well aware that my use was "improper" but I had wanted to say that the author wasn't specified rather than the publisher wasn't specified. I've now deleted the parameter.Aa77zz (talk) 07:05, 17 July 2015 (UTC)
At Finch it now says: "The name of the author is not specified in the document." If that is so, then who is | last=Leach | first=William Elford?
Trappist the monk (talk) 09:31, 17 July 2015 (UTC)
I was trying to simplify as this isn't an important reference. In the Finch article I've actually cited two sources - the other is Bock 1994. It is Bock who gives the information about the publication: "All the parts of this public guide to the British Museum are unsigned, however, this part was clearly written by Leach as indicated by the fact that he was Keeper of Zoology at the time and by the numerous references to Leach's list of family-group names by his contemporaries." I'm reluctant to add a notelist with this info. It is not uncommon to have "unsigned" articles. I've met them in 19th century book reviews. Sometimes there is a RS giving the authors name. I've seen square brackets used in references when the information isn't present on the title page - such as the author or the year of publication. Aa77zz (talk) 10:17, 17 July 2015 (UTC)
If Synopsis ... doesn't identify the authors then | last=Leach | first=William Elford | author-link=William Elford Leach should be removed from that citation. You might then change the note to read: "Attributed to Leach in Both 1994." I'm not at all sure that this is even important. Will knowing that Both thinks that Leach wrote "Eleventh Room" help readers find a copy of Synopsis ...?
Trappist the monk (talk) 12:13, 17 July 2015 (UTC)

────────────────────────────────────────────────────────────────────────────────────────────────────The conversation has moved a long way from User:SMcCandlish's request for a |note= parameter to allow a hidden editor to editors message, similar to |reason= in the cleanup templates. -- PBS (talk) 21:23, 30 July 2015 (UTC)

And it would actually serve the purpose Aa77zz has in mind, anyway. So, I renew the request. All fields I'm aware of, including physical sciences, social sciences, humanities, law, etc., that regularly cite sources do in fact have definitions of "primary source" and so on (even if they sometimes differ in their particulars), so the objection to my example isn't even valid. And it was just an example. There are any number of reasons to use such a parameter, e.g.:
  • |note=Titled "Blood of the Isles" in the UK printing.
  • |note=Paywall can be bypassed by request at URL here.
  • |note=Page 17 is missing from this Project Gutenberg scan, but is not part of the cited material.
  • |note=There is a newer edition, but the cited section has not changed, according to URL to changes list.
  • |note=This is a master's thesis, but was reviewed by Notable Researcher Here, and has been cited in 12 journal papers as of July 2015.
etc. There's no reason to put these in messy HTML comments that some editors are apt to delete on sight because they don't like HTML comments. And, really, no one's head will asplode if someone happens to include a more WP-jargon-specific note. They'll just shrug and move on. No one will see them but wikitext-editing users anyway.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  23:15, 30 July 2015 (UTC)
Are you hoping that the note will appear when a user mouses over the tag as with {{clarify-inline}} ? AngusWOOF (barksniff) 08:12, 22 August 2015 (UTC)

In Template:Cite episode, network = publisher?[edit]

Shouldn't |network= be documented as an alias of |publisher=?  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  01:24, 22 July 2015 (UTC)

{{cite episode |title=Title |series=Series |network=Network |publisher=Publisher}}
"Title". Series. Publisher. Network. 
As can be seen in my crude example, |network= is not an alias of |publisher=, so in answer to your question, no, |network= should not be documented as a strict alias of |publisher=. But that raises the question: should |publisher= be valid for use in {{cite episode}}?
Trappist the monk (talk) 02:17, 22 July 2015 (UTC)
I guess it could be in some cases, when the production is attributed to one entity, and it retains rights to it, syndicates it later on other networks, reissues it on DVD, etc., all without involvement of the original network. Will definitely need documentation clarification.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  08:04, 22 July 2015 (UTC)

Definite error in same template[edit]

No idea how this is happening: |series= is not italicizing, but it's clearly intended as a replacement for |work= (which is absent from this template's documentation). The only way to get a properly italicized series name with this template is to use |work=, which suggests that it's not actually coded as an alias of |work= for some reason, but as a separate parameter.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  08:08, 22 July 2015 (UTC)

Series is italicised in Trappist's example above... - Evad37 [talk] 08:51, 22 July 2015 (UTC)
It appears that the |series= parameter is being repurposed. When I started six years ago, it was used in {{cite journal}} to resolve duplication when the same volume/issue numbers were used for two different issues. --Redrose64 (talk) 13:16, 22 July 2015 (UTC)
Well, as with |title= doing something different in different templates, this one needs to as well.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  23:21, 22 July 2015 (UTC)

Template:Cite journal has had |series= since 26 October 2008 [1]. Template:Cite episode has had it since its creation on 4 March 2006 [2]. It may have been around in some other template even longer; not sure. Was added to {{Cite book}} in 2007, for example. Anyway, it's highly desirable that it italicize in {{Cite episode}}. I would just go fix it, but I can't due to full protection on the module. — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  21:47, 24 July 2015 (UTC)

Test: Onie-Maus, Ann (19 July 2015). "Athena's Earlobes". Cracksmokin' Buttmonkeys. Season 2. Episode 6. This parameter seems to serve no purpose (in Gaelic). Weed, New Mexico. 48 minutes in. Insipid Broadcasting Network. KBLARGH. Retrieved 20 July 2015. My chicken has bigger nuggets than yours! 

Hmm. OK, it's italicizing now.

But note that the |city= parameter is not working, though it has been documented at this template for a long time (the |location= version works, and I'll go change the template's documentation, but it should probably have city as an alias). But its value is misplaced in the sequence. It should immediately precede the |station= value, if present, e.g. Weed, New Mexico: KBLARGH, fallback to preceding the network in same format, and finally to appearing alone, with no colon, as in the above display, if neither are present, in which case it should be just before the accessdate. It's really weird that it is inserted into episode-specific data, between transcript info and timecode info.

It has another problem, too: The misfeature that it always throws an error if there is no |title= value, even though some TV show's episodes do not have titles. It should detect some specific string, e.g. [none] and suppress display of that value or of the error in that case. This would also allow it be used to cite one-off programs (TV specials, either stand-alone or of a regular series), without having to use some other template like {{cite video}} or {{cite film}}.

Next, the |transcript= parameter verges on useless, unless the transcript has a special, unique title. If you leave it out/blank, then |transcript-url= throws an error. Instead |transcript=Transcript should simply be the default value. If a value is provided, it should appear as Transcript: "value of transcript parameter here".

 — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  00:07, 31 July 2015 (UTC)

{{cite episode}}: the Module:Citation/CS1 version very closely follows, and in some cases improves upon, {{cite episode}}: the {{citation/core}} version as can be seen by comparing your example citation rendered here by both:
Cite episode compare
{{ cite episode | number=6 | last=Onie-Maus | access-date=20 July 2015 | date=19 July 2015 | season=2 | minutes=48 | transcript=This parameter seems to serve no purpose | quote=My chicken has bigger nuggets than yours! | language=Gaelic | network=Insipid Broadcasting Network | first=Ann | series-link=Humor | transcript-url=http://yandex.com | episode-link=Rickrolling | title=Athena's Earlobes | location=Weed, New Mexico | series=Cracksmokin' Buttmonkeys | station=KBLARGH | url=http://www.google.com }}
Old Onie-Maus, Ann (19 July 2015). "Athena's Earlobes" (in Gaelic). Cracksmokin' Buttmonkeys. Season 2. Episode 6. This parameter seems to serve no purpose. Weed, New Mexico. 48 minutes in. Insipid Broadcasting Network. KBLARGH. http://www.google.com. "My chicken has bigger nuggets than yours!" 
Live Onie-Maus, Ann (19 July 2015). "Athena's Earlobes". Cracksmokin' Buttmonkeys. Season 2. Episode 6. This parameter seems to serve no purpose (in Gaelic). Weed, New Mexico. 48 minutes in. Insipid Broadcasting Network. KBLARGH. Retrieved 20 July 2015. My chicken has bigger nuggets than yours! 
|city= doesn't work in the Module version because it doesn't work in the {{citation/core}} version.
Trappist the monk (talk) 00:52, 31 July 2015 (UTC)
So shouldn't it have that as an alias, given that it was deployed for a long time with |city= as the parameter name? PS: Just to be clear my sample test code is to play with swapping stuff in and out. It mostly doesn't directly illustrate the problems I talked about, or I would have had to use it numerous times in the same post.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  01:53, 31 July 2015 (UTC)

extra text in |edition= detection bug[edit]

There is a bug in the extra text detector. The current detector was intended to find |edition=2nd ed. which would render as

Title (2nd ed. ed.). 

But, it also finds the 'ed' at the end of illustrated, revised, etc:

Title (revised ed.). 

So, I've adjusted the test:

Title (2nd ed. ed.).  – should find 'ed.'
Title (revised ed.).  – should not find 'ed'

Trappist the monk (talk) 11:38, 25 July 2015 (UTC)

I'm still seeing the error raised with "revised": {{Cite book|authorlink=Maynard Solomon|last=Solomon|first=Maynard|title=Beethoven|edition=2nd revised|location=New York|publisher=Schirmer Books|year=2001|isbn=0-8256-7268-6}}:
but not in {{Cite book/new}}:
Any reason why {{Cite book/new}} cannot be deployed? -- Michael Bednarek (talk) 13:42, 9 August 2015 (UTC)
{{cite book/new}} is the same as {{cite book}} except that it uses the sandbox version of Module:Citation/CS1. Because every change to the live module dumps a couple of million articles on the job queue, we collect multiple changes in the sandbox before updating the live module.
Trappist the monk (talk) 14:44, 9 August 2015 (UTC)

Question about CS1 maint: Extra text[edit]

I have submitted Wikipedia:Bots/Requests for approval/BattyBot 46 to fix articles in Category:CS1 maint: Extra text. The category page states "This is a tracking category for CS1 citation parameters that have parameters that contain text that duplicates static text provided by the template. For example, |edition=2nd ed will be rendered as (2nd ed ed.)." However, there are articles in this category that do not meet this criteria.

Reference #72 in 1956 Winter Olympics is presumably in this category because of the |pages=:

{{cite journal |title=IOC and OCOG Abbreviations for NOCs |last=Mallon |first=Bill |author2=[[Ove Karlsson (sports journalist)|Ove Karlsson]] |journal=[[Journal of Olympic History]] |volume=12 |issue=2 |date=May 2004 |pages=pp. 25–28 |url=http://www.la84foundation.org/SportsLibrary/JOH/JOHv12n2/johv12n2l.pdf |format=PDF |accessdate=2 March 2010}}

However, if we remove "pp." from the parameter value, we see that "pp." is not static text provided by {{cite journal}}:

{{cite journal |title=IOC and OCOG Abbreviations for NOCs |last=Mallon |first=Bill |author2=[[Ove Karlsson (sports journalist)|Ove Karlsson]] |journal=[[Journal of Olympic History]] |volume=12 |issue=2 |date=May 2004 |pages=25–28 |url=http://www.la84foundation.org/SportsLibrary/JOH/JOHv12n2/johv12n2l.pdf |format=PDF |accessdate=2 March 2010}}

How should we resolve this discrepancy?

  1. Change {{cite journal}} so that it always displays "pp."?
  2. Change {{cite journal}} so the maintenance category is not populated in this case?
  3. Change the category description to explain why it is inappropriate to put "pp." in |pages= in this case?
  4. Something else?

Thanks! GoingBatty (talk) 15:51, 25 July 2015 (UTC)

  1. There has been discussion on these pages before about making {{cite journal}} render the 'p.' and 'pp.' prefixes when the citation does not use |volume= and |issue=
  2. No
  3. In the case of {{cite journal}}, the 'p.' and 'pp.' prefixes duplicate the colon (which for this template is the static text):
    {{cite journal |title=Title |journal=Journal |page=100}}
    "Title". Journal: 100. 
  4. perhaps. such as?
Trappist the monk (talk) 16:11, 25 July 2015 (UTC)
The problem also appears when using {{citation}} where you end up with a meaningless number for the page number. Can we do something to always render the p. or pp. for page number as the colon is not intuitive and we are producing references which are not easily understood by the majority of readers. If this needs a wider discussion then we should set one up so that we can see if there is consensus for change. Keith D (talk) 18:49, 4 August 2015 (UTC)
When citing scholarly journals, {{cite journal}} and {{citation}} follow the model established and used by scholarly journals: volume (issue): page(s). Why should cs1|2 deviate from that standardized presentation? For example, PMID 11470414 cites the journal date; location this way: Curr Biol. 2001 Jul 10;11(13):1068-73.
Trappist the monk (talk) 23:21, 4 August 2015 (UTC)
Problem comes when you are not using the volume and issue fields but just a page number it just shown a number that has no context and which needs something to show its purpose. I would guess that most readers would not know what the number relates to. Keith D (talk) 23:32, 4 August 2015 (UTC)
Why are you leaving out those rather important bits of information? Volume and issue are, pretty much, requisite elements of a proper journal cite, are they not?
Trappist the monk (talk) 23:51, 4 August 2015 (UTC)
Because it is not a journal but a newspaper. Keith D (talk) 00:23, 5 August 2015 (UTC)
Why are you not using {{cite news}}? Use the correct tool for the job. --Izno (talk) 00:38, 5 August 2015 (UTC)
Argh! Why didn't you say you were citing a newspaper and not a journal? {{citation}} doesn't do a good job of citing newspapers. To get around that, do as Editor Izno suggested and also add |mode=cs2 so that you get a rendered citation that looks like it was made with {{citation}}.
Trappist the monk (talk) 00:59, 5 August 2015 (UTC)
A better example would not be a newspaper but a magazine. The correct tool for the job would be {{cite magazine}} - but {{cite magazine}} is a redirect to {{cite journal}}, and not all magazines have volume or issue numbers. Some do: this one for instance, but by no means all. Some people refuse to add the issue number even if one exists, on the basis that the cover date is sufficient to identify the issue. So when {{cite journal}} is used, there is actually a fair chance that no issue number has been provided. --Redrose64 (talk) 08:20, 5 August 2015 (UTC)
That would suggest that perhaps, {{cite magazine}} should redirect to {{cite news}} instead of {{cite journal}} because {{cite news}} also supports |volume= and |issue= but uses p. and pp. prefixes:
"Cite news with volume and issue". Magazine X (23). pp. 50–76. 
Alternately, we might modify |p-prefix= and |pp-prefix= handling within Module:Citation/CS1 to override the colon for journal cites. Then again, perhaps not. An insource search for 'p-prefix' and 'pp-prefix' finds no instances of either of the prefix parameters. If editors aren't using them is there any reason to keep them?
Trappist the monk (talk) 10:13, 5 August 2015 (UTC)
I have two ideas in this regard. The first is to possibly remove the compressed format for journals and use "vol. 1, no. 2, p. 3" or similar. CMOS16 uses "1, no. 2 (XXX): 3" (where the XXXX is the date or year of publication. This would have the advantage that page numbers would then always be preceded by the appropriate abbreviation, and readers who aren't familiar with the meaning of the bold-faced and bracketed numbers or the colon would have a more explicit frame of reference in the reference.
The other idea is to emit the "p." or "pp." as appropriate unless a volume, an issue or both are also defined. So: "1 (2): 3", "1: 3", "(2):3" or just plain "p. 3" would be display options depending on what parameters are defined. The latter idea may be simpler to code, and bots could then strip manually inserted "p." or "pp." to avoid doubling up. Imzadi 1979  11:24, 5 August 2015 (UTC)
I would favour the first option as that removes any ambiguity for the reader. Keith D (talk) 11:41, 5 August 2015 (UTC)
@Trappist the monk: Altering Template:Cite magazine to point to {{cite news}} instead of {{cite journal}} should not be undertaken lightly. It has been suggested before, several times, in different venues. For instance, at Wikipedia talk:WikiProject Academic Journals/Journals cited by Wikipedia#Unfortunate interaction between template and wikiproject. Notice in particular my comment of 14:02, 2 October 2011: whenever I have used {{cite magazine}}, someone with AWB has popped by and altered it to {{cite journal}}. So altering the redirect will not fix everything, but will cause a large number of magazine citations that directly use {{cite journal}} to suddenly become "wrong".
As for the suggestions of Imzadi1979: I go with the second - in the absence of volume and issue, emit "p." or "pp." --Redrose64 (talk) 15:44, 5 August 2015 (UTC)
If we right-this-minute stop AWB from doing its template rename thing as Editor John of Reading suggests, {{cite magazine}} is used in 1924 pages and {{cite journal}} used in 419,414 pages. Clearly that latter number is big, but that's not the group we care about. The group we care about is the {{cite magazine}} group and there, the work is to inspect those cites to see if they changed to {{cite journal}} or to {{cite news}}.
We could set up a maintenance category and have Module:Citation/CS1 populate it with pages that have {{cite journal}} templates that don't use a specified subset of the identifiers (arxiv, bibcode, doi, jfm, jstor, pmc, pmid, etc) which identifiers are commonly associated with academic journals. Based on the content of the category we could make a better decision on how to proceed with the {{cite magazine}} question.
Trappist the monk (talk) 19:07, 5 August 2015 (UTC)
@Redrose64: If this discussion does end up with an agreed edit to the redirect, you can instantly reconfigure AWB's behaviour by editing WP:AWB/TR. -- John of Reading (talk) 16:10, 5 August 2015 (UTC)
That's not what I mean. My point is: who is going to go around undoing all the bypassing of redirects that AWB users have already done? --Redrose64 (talk) 16:22, 5 August 2015 (UTC)
@John of Reading: For example, the edit I mentioned at 08:20, 5 August 2015, has now been redirect-bypassed by AWB to use {{cite journal}} instead of {{cite magazine}}. --Redrose64 (talk) 11:01, 6 August 2015 (UTC)
Not using the {{cite news}} template so as to avoid mixing CS1 and CS2 style templates in the same article as that causes inconsistencies in the output of the information. Personally I tend to use CS1 templates and avoid CS2 where possible. Keith D (talk) 11:34, 5 August 2015 (UTC)
The purpose of |mode= is to allow mixing cs1 and cs2 templates while retaining the characteristic display style of one. So, if an article uses {{citation}} but needs to cite a newspaper and {{cite news}} does a better job at that than {{citation}}, use {{cite news}} and set |mode=cs2 so that the rendered output is in the cs2 format:
Author (5 August 2015), A book source using citation, Location: Publisher, p. 100 
Author (5 August 2015), "A newspaper source using cite news and mode=cs2", Newspaper 
To make {{citation}} render in the style of cs1, set |mode=cs1
Trappist the monk (talk) 11:53, 5 August 2015 (UTC)
Related question - when editors add "p" or "pp" to the parameter value because it is not automatically displayed, does this mess up the COinS metadata? Thanks! GoingBatty (talk) 19:01, 4 August 2015 (UTC)
Judging by the two examples which you provided at the start, yes. The first has &amp;rft.pages=pp.+25-28 where the second has &amp;rft.pages=25-28 --Redrose64 (talk) 20:05, 4 August 2015 (UTC)

and others is a synonym of et al.[edit]

There aren't that many but editors have used |author=and others (some of these are the result of Monkbot making author parameters from |coauthors=). These author parameters aren't currently detected by name_has_etal () in Module:Citation/CS1. I have tweaked the sand box so that they are:

Cite book compare
{{ cite book | title=Title | author2=and others | author=First author }}
Live First author; and others. Title. 
Sandbox First author; et al. Title. 

Such citations will be added to Category:CS1 maint: Explicit use of et al..

Editors have also used |author=others but there were (according to an insource: search) only a dozen of them so I just fixed them instead of adding a test to the module.

Trappist the monk (talk) 18:56, 26 July 2015 (UTC)

Support. – Jonesey95 (talk) 08:47, 29 July 2015 (UTC)
  • Oppose, just change them to "et al". Also best to keep coauthors and an option. -- PBS (talk) 21:27, 30 July 2015 (UTC)

How do you suppress errors when titles are missing?[edit]

For instance, in the PMNS matrix article, we have citations such as

*{{cite journal
 |last1=Pontecorvo |first1=B.
 |year=1957
 |title=Mesonium and anti-mesonium
 |journal=[[Zhurnal Éksperimental’noĭ i Teoreticheskoĭ Fiziki]]
 |volume=33 |pages=549–551
 |bibcode=
 |doi=
}} reproduced and translated in {{cite journal
 |last1=<!----> |first1=<!---->
 |year=1957
 |title=<!---->
 |journal=[[Soviet Physics JETP]]
 |volume=6 |pages=429
 |bibcode=
 |doi=
}}

Giving out

There's no reason why this should be considered invalid. How do you suppress the error message? Headbomb {talk / contribs / physics / books} 15:34, 29 July 2015 (UTC)

Each citation template is a stand-alone object that produces stand-alone metadata. While the text "reproduced and translated in" visually connects the two in the article, there is no such connection in the metadata because there is no inter-template communication.
If both journal articles were consulted when writing PMNS matrix, then both templates should have all of the required information and both used separately. If only one journal article was consulted for PMNS matrix then only that template is required (the other, completed template could be added to §Further reading or similar section – perhaps with a note identifying it as the original or the translation).
When the article's citation style dictates it, you can use |title=none in {{cite journal}} and {{citation}} when |journal= is set to suppress the error message. It is my belief that this sort of shorthand is inappropriate because it leaves the metadata incomplete.
The parameters |language=; |script-title= for the original language and/or |title= for a transliterated title; and |trans-title= for the translated title would be appropriate for the first (original language) template.
Trappist the monk (talk) 16:16, 29 July 2015 (UTC)
This rigid attitude is driving people away from using the citation templates, with the result that no metadata at all is produced. For example, my recommendation here (as I have used and seen in several other articles) would be to manually format the second part of the citation (where this article appears in translation, or in some other cases where it appears in an edited volume of journal reprints) since our citation templates are unable to produce elided citations in an appropriate format, the appearance to our readers should be a much higher priority than the quality of the metadata, and (as evidenced above) our template software maintainer is unwilling to fix the problem. —David Eppstein (talk) 22:53, 3 August 2015 (UTC)
Agreed. And see WP:SAYWHEREYOUGOTIT.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  23:37, 30 July 2015 (UTC)
I would be so glad if |title=none worked as claimed, but, hmmm [looking at “Jones (1957). "none". ”], it doesn't. And you seem to have missed the implication that if the metadata must always be complete, then only those sources with complete metadata - more precisely, complete COinS metadata - can be cited. ~ J. Johnson (JJ) (talk) 22:05, 3 August 2015 (UTC)
But it does work when you use |title=none in {{cite journal}} and {{citation}} when |journal= is set. Rewriting your example as cs1:
{{cite journal |last1=Jones |year=1957 |title=none |journal=Journal}}
Jones (1957). Journal. 
and as cs2:
{{citation |last1=Jones |year=1957 |title=none |journal=Journal}}
Jones (1957), Journal 
Yes, I know that the metadata for such citations is incomplete and as such I don't care for this 'style' (which apparently really exists in some scholarly communities). I could have chosen to omit mention this functionality in my first post in this discussion. Of course, if I had omitted it, someone else would have pointed that out.
Trappist the monk (talk) 00:43, 4 August 2015 (UTC)
That's fine where the source is a journal. Can you make it work with |chapter/contribution= where the source is not a journal? ~ J. Johnson (JJ) (talk) 21:30, 4 August 2015 (UTC)
And as I said in another post here, having the exact value |title=none should work in some other situations. It's very irksome (both for make-work reasons and for accuracy reasons) to have to input fake "titles" for citing something's homepage, as in this example:
     "Ministry of Foreign Affairs Homepage". MoFA.gov.pk. Government of Pakistan. 2013. Retrieved 4 August 2015. 
which I had to do yesterday at both Pakistan and Foreign relations of Pakistan (and "Government of Pakistan" is kind of a lame |publisher= value). Properly, this would just be something like:
     {{cite web |title=none<!--homepage--> |work=MoFA.gov.pk |url= http://www.mofa.gov.pk/index.php |publisher=Pakistan Ministry of Foreign Affairs |date=2013 |accessdate=4 August 2015}}
but the template won't permit this.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  00:11, 6 August 2015 (UTC)
I would have used |title=Ministry of Foreign Affairs [homepage], using the brackets to show that "homepage" didn't actually appear in the source. Printed style guides call for just using a description with no italics nor quote marks if a source has no title, but this family of templates can't do that. — Preceding unsigned comment added by Jc3s5h (talkcontribs) 00:20, 6 August 2015‎
Reasoned, but my point is that it shouldn't be necessary.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  17:20, 6 August 2015 (UTC)
{{cite report}} renders title without title styling:
Ministry of Foreign Affairs [homepage]. Government of Pakistan. 2013. Retrieved 4 August 2015. 
Setting |type=none disables the default type annotation.
Trappist the monk (talk) 10:10, 6 August 2015 (UTC)
But it's not a report, so it's wrong. I consider lying to the template to make it look right intolerable. If I found an article that did that I would rip all the templates out and switch to a citation style based on a paper style guide. Jc3s5h (talk) 15:39, 6 August 2015 (UTC)
You wrote: a description with no italics nor quote marks if a source has no title, but this family of templates can't do that. I merely point out that, in fact, a member of this family of templates does render a description in lieu of title without styling.
Without doubt, we can concoct a mechanism that disables the default title styling; I once suggested a separate title parameter for that purpose which conversation didn't go very far. Since we have parameters like |name-list-format= and |mode= we could have something similar for titles where the parameter takes a named constant and applies a defined rule to the content of |title= or not even bother with a new parameter and just change |mode= processing to accept a comma delimited list of descriptors so {{cite web}} might have |mode=cs2, desc to render a web cite in cs2 style with an unstyled title.
Trappist the monk (talk) 16:27, 6 August 2015 (UTC)
Works for me. While I wouldn't go as far as Jc3s5h vows (probably tongue-in-cheek), I too object to having to use the wrong template, both on the basis that it's using the wrong template, and the more pragmatic one that the next editor to come along is liable to "fix" it to use the correct one that does the undesirable formatting.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  17:20, 6 August 2015 (UTC)


As before: can you make "none" work with |chapter/contribution= where the source is not a journal? ~ J. Johnson (JJ) (talk) 23:43, 11 August 2015 (UTC)
If you are asking for |chapter/contribution=none, simply omit |chapter/contribution= or leave it blank.
Trappist the monk (talk) 13:29, 12 August 2015 (UTC)
No, I am asking for suppression of the "missing or empty title" error message, or explicit suppression of a title. Omitting use of a citation template is even simpler, but that is not a constructive answer.
To be more explicit, can you make |title=none (or some variation) suppress the title without having to specify {{cite journal}} or |journal=? E.g., for "{{citation |year= 1990 |title=none |author= Folland et al. |chapter= Chap. 7: Observed Climate Variation and Change }}", which produces: Folland et al. (1990), "Chap. 7: Observed Climate Variation and Change", none  . ~ J. Johnson (JJ) (talk) 20:27, 12 August 2015 (UTC)
These discussion again? My position as stated there has not changed.
Trappist the monk (talk) 11:59, 13 August 2015 (UTC)

What, that attitude again? Trappist, you're being a jerk. There are cases where it is quite valid to cite a chapter (or contribution) in a larger work without directly including the title of the work. (For brevity I omit the winding, tendentious details we have previously traced out.) Yet you are obsessed with requiring a title for all uses. When this was discussed last January (see cite journal without Ctitle) you grudgingly ("I'd rather not if I can avoid it") accepted Gadget850's proposal (endorsed by Imzadi) that |title=none should suppress the error message. Yet you adamantly refuse to make any concession for other uses, You are fixated on this idea that every citation template must produce "stand-alone" (complete within itself?) COinS metadata, never mind that your rigid attitude (as enunciated above by David Eppstein) is going to drive people away from using templates and thereby reduce the metadata. The degree of your obsession is indicated in the time and effort you have spent objecting and resisting this (and in developing the misbegotten harvc template), which is likely more time than it would have taken to extend the "none" exception. (Or even better, to just eliminate the title test.) To insist that ALL citations must be "COinS complete" (which implies that only sources with complete COinS data can be cited using templates) is counter-productive. In the end your position is just "I don't like it." That is a very feeble argument. And your intransigence impairs the work of others. ~ J. Johnson (JJ) (talk) 21:00, 13 August 2015 (UTC)

To be honest JJ, you haven't shown consensus for your change. Trappist has provided an alternative method, and your use case is unrelated to the thread above from my read. If you really think the template should change, start an RFC or a straw poll, lay out all the options (since there are now alternatives), and ask the community whether it makes sense to support what you think should be supported. --Izno (talk) 21:17, 13 August 2015 (UTC)
Consensus? Off-hand I don't recall where the consensus was for Trappist to break existing valid usage. Nor was any explicit consensus needed for him to add the 'journal' exception. As to alternatives, the one he provided is {{harvc}}, which is an abomination that makes citation more complex and harder to understand (discussed elsewhere). The other alternatives are: 2) to characterize a non-journal source as a journal (which amounts to metadata corruption); 3) not use citation templates; 4) not write anything requiring citations. #2 seems the least offensive, but even so this "lying to the template" (as Jc3s5h calls it) is "right intolerable", while SMc has noted the pragmatic problem where such misuses are "fixed" by subsequent editors. None of these alternatives are good, but everyone else has to accept them because one editor "do[es]n't care for this 'style'"? ~ J. Johnson (JJ) (talk) 22:28, 14 August 2015 (UTC)
Requests for comments is -> that way. --Izno (talk) 04:46, 15 August 2015 (UTC)
That way? What is wrong with here? As stated at the top of this very page: "This is the talk page for discussing improvements to the Citation Style 1 page". Not only is it a matter of a particular 'style' that is raised here, but here is the very question I would like answered: How do you suppress errors when titles are missing? Trappist has provided an answer for use with 'cite journal'; my particular question is how to suppress these "errors" for non-journal sources. As Trappist is the WP:WikiKing here, what would be the point of asking for comments from anyone else? ~ J. Johnson (JJ) (talk) 20:35, 16 August 2015 (UTC)
Then what you're looking for is {{RFC}}. Continuing to ask and ask and ask is not going to get you anywhere, so not asking for external comments is not an option. If consensus decides that it's a valuable change, then we'll go find a template editor/coder to make the desired change. If not, then you have an answer that isn't decided by a so-called WikiKing. It's really that simple. --Izno (talk) 21:08, 16 August 2015 (UTC)
Izno, are you even paying attention? You seem to be saying (yes?) that whatever I ask has to go through the hoop of an RfC. Perhaps you would permit me to ask you directly: Where was the Rfc that decided that this "title test" was a valuable change? Or the RfC to add the journal-only "title=none" exception? ~ J. Johnson (JJ) (talk) 23:28, 18 August 2015 (UTC)
Of course I'm paying attention. It seems you aren't, so I'm done replying. --Izno (talk) 03:23, 19 August 2015 (UTC)
Your replies seem to consist solely of enabling for Trappist's intransigence, so that's probably a net positive. —David Eppstein (talk) 03:33, 19 August 2015 (UTC)
Yours seem to be enabling JJ's. Starting an RFC is not hard and gets results. Whining that process wasn't followed does not. Want something to change? Be bold. Can't change it yourself? Ask for help. If help does not want to be given by a certain person, or if it is not obvious what the consensus should be and so it is not obvious that your desired help is that consensus, find that consensus. How do we do that? An RFC. Or if you think the behavioral issues so insurmountable as to prevent you from such, take it to the dramaboard. As I said before, it's simple. Trappist seems unwilling to help you. Guess what that means: an RFC, or ANI. Or identify an expert-editor of templates/Lua, have said person take time to analyze the problem and provide the solution, and then convince Trappist not to edit war. You know which one gets a positive result? I certainly do. Since you decided to snipe at me instead of taking the literal 5 minutes for yourself to start the RFC, I'll take it that you don't. Or you don't care. One of the two. (And yes, I understand the irony of "taking the literal 5 minutes for yourself...". I'm not the one who wants the change.) --Izno (talk) 05:20, 19 August 2015 (UTC)
Izno: I am sorry if you think I am sniping at you. Undoubtedly you understand that I am rather frustrated here; I think you will also understand why I might feel even more frustrated at your suggestion that I should jump through more hoops. But now you have clarified: you are suggesting with how I might deal with the intransigence. Right? In your conception I can seek to build community consensus that a certain state of affairs is desireable (whether it be striking the title-test, adding a non-journal exception, or something else), and request to have it implemented. When the request is refused go back to the community for support - and then what? Sanction Trappist? I think that is where a formal by-the-rules (i.e., "Rfc") approach ends up, and, frankly, I don't like it. (Way too much drama, all around, not because I begrudge 5 minutes, literally or figuratively.) I would prefer to deal with this informally, here. With the understanding that I really don't want to go nuclear, would you have you have any suggestions how else I might proceed? ~ J. Johnson (JJ) (talk) 17:34, 19 August 2015 (UTC)
Quick Re On Sniping: No, I was commenting on David's comment at 3:33. --Izno (talk) 18:22, 19 August 2015 (UTC)
Oh. I was wondering if he was chastising me. ~ J. Johnson (JJ) (talk) 18:32, 19 August 2015 (UTC)
Izno: again, do you have any suggestions how to proceed, without going nuclear? ~ J. Johnson (JJ) (talk) 20:33, 23 August 2015 (UTC)


Returning to the original example, I would have written

*{{cite journal
 |last1=Pontecorvo |first1=B. |author-link=Bruno Pontecorvo
 |year=1957
 |title=Mesonium and anti-mesonium
 |journal=[[Soviet Physics JETP]]
 |volume=6 |pages=429–431
 |url=http://www.jetp.ac.ru/files/pontecorvo1957_en.pdf
}} English version of {{cite journal
 |last1=Pontecorvo |first1=B. |author-mask=2
 |year=1957
 |title=Mezoniy i antimezoniy
 |journal=[[Zhurnal Éksperimental’noĭ i Teoreticheskoĭ Fiziki]]
 |volume=33 |pages=549–551
 |url=http://www.jetp.ac.ru/files/pontecorvo1957_ru.pdf
}}

which yields

Kanguole 15:56, 17 August 2015 (UTC)

Merging Template:Cite ArXiv[edit]

After a discussion at Wikipedia talk:Identifying reliable sources#Unpublished/SPS/UGC sources and Template:Cite arXiv, to make sure that we should ever be citing arXiv for anything but a convenience link, it's become clear that there are only two use cases for this template:

  1. Citing an arXiv paper that has also been published in a journal, where the arXiv URL is a convenience link, in which case it can be replaced with
    {{Cite journal |url=URL of published copy at journal or indexing service, if one is available |arXiv=URL of the preprint at arXiv |at=value that would have been in the arXiv "class" parameter |...}} It can actually just be swapped with: {{Cite journal |url=URL of published copy at journal or indexing service, if one is available |eprint=URL of the preprint at arXiv |...}} and can be done with just swapping in {{cite journal}} with no adjustments at all if there's no non-arXiv URL to put in.
  2. Citing (rarely) an arXiv paper that has not yet been reputably published but is being cited as a primary source for some reason, and for which there is no other URL, in which case it can be replaced with
    {{Cite web |url=URL at arXiv |at=value that would have been in the arXiv "class" parameter |...}} It can actually just be swapped with: {{Cite web}} with no adjustments at all.

The one and only thing that this template does "special" is provide an optional |class= that gives the arXiv category the paper is in, and this is only "needed" for certain arXiv URLs that don't already include it. It's not actually required at all, since it does not aid in identifying and retrieving the source anyway; it's just a categorization identified that is sometimes in arXiv URLs, sometimes not, but which some like to include. If as I suspect we want to retain it:

  • The template can be replaced with a call to {{Cite web}}, that maps |class= to |at=, and passes all the other standard parameters for the template; or
  • The template can just redirect to {{Cite web}}, after aliasing |class= to |at=.

Either way, for cases where the paper has subsequently been journal-published (case #1, the vast majority of legitimate citations using this template), the proper template to use, even if we did nothing else at all, is {{Cite journal}}. It, too, should probably support |class= as an alias of |at=, just to preserve that tidbit of information. (It's not quite as trivial as some other info we discard, like total number of pages and arXiv.org prefers that it being included in citations to papers it hosts.) Never mind: All the CS1 and CS2 templates already handle |class= directly.

The {{Cite arXiv}} template serves no purpose at all as a stand-alone template, and it's standard operating procedure, both site-wide and with regard to citation templates specifically, to merge redundant ones. Instances of this template cannot be "upgraded" with additional details after journal publication without replacing the template anyway, because it does not support |doi=, |volume=, etc., while both {{Cite journal}} and {{Cite web}} don't have this problem. And the use of this identifier-based, site-specific template hampers the ability to do source verification, because it mix-and-matches completely different (for WP purposes) kinds of sources – peer-reviewed publications vs. unpublished materials – solely on the criterion of what website they're hosted at. Yet we already deprecated and merged the entire little family of {{Cite doi}} and related templates, for the same reason, that they were identifier-based. This arxiv-specific template is foolhardy for the additional reason in that it effectively encourages citation of unpublished arXiv papers as if they were equivalent to peer-reviewed journal papers as a class; it lends false reliability to what amounts to self-published/user-contributed content. While arXiv is arguably better than various other sites that allow people to publish papers on their own, this fact that it's essentially a papers-wiki for original academic research cannot be avoided. Many instances of case #2 should probably be deleted, as failing WP:V's basic requirements, but that's probably only determinable on a case-by-case basis – specifically because of this template's commingling of the two source types as undistinguished.

It's my impression that WT:CS1 prefers collectively to handle merge discussions here than take them to WP:TFD, so here we are.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  02:44, 31 July 2015 (UTC)

Two points:
  1. You have completely misrepresented the content of the discussion, instead putting forward your minority opinion as the consensus. None of the other participants said anything in favor of merging or deleting {{cite arxiv}}
  2. {{cite arxiv}} and {{arxiv}} serve completely different purposes, and merging them makes no sense. One of them is for formatting citations. The other is for formatting links to the arxiv, within citations (usually but not always redundant with the |arxiv= parameters of the various citation templates and/or with direct wikilink syntax [[arxiv:...]]).
I see no valid justification for this merge proposal. —David Eppstein (talk) 02:49, 31 July 2015 (UTC)
A clear case of WP:IDIDNTHEARTHAT by SMcCandlish here. As for his two scenarios, they manage to be both gross oversimplifications and bad practice as the same time. Headbomb {talk / contribs / physics / books} 03:10, 31 July 2015 (UTC)
I see no reason to merge Template:ArXiv with any other template, as proposed in the section header, based on the confusing narrative above. ArXiv, Cite arxiv? What templates are we talking about here?
I have looked at the original discussion. There is no consensus there, and a lot of misunderstanding and failure to communicate effectively. I disagree with the OP's suggestion that on that page, "it's become clear that...."
I suggest that this discussion continue at the original location, per WP:MULTI. – Jonesey95 (talk) 04:12, 31 July 2015 (UTC)
It's no longer relevant to or at WP:RS; I moved it for a reason. I made no claims about any consensus in either direction, BTW. I simply stated the fact that only two kinds of use-case for {{Cite journal}} had been outlined. Go read the discussion, and you'll see that this is entirely factual. Still is, even factoring in this discussion. All this hand wave activity isn't going to change that.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  11:21, 1 August 2015 (UTC)
The value assigned to |class= in {{cite arxiv}} should not be mapped to |at= because |at= is an in-source location parameter which |class= is not.
|class= is part of the |arxiv= identifier handling code in Module:Citation/CS1. If |class= is set, its value is concatenated with the value assigned to |arxiv= at rendering. Because it is one of the predefined identifiers, |arxiv= is available to all cs1|2 templates; |class= is ignored if |arxiv= is not set.
Converting {{cite arxiv}} to {{cite journal}} is a simple matter of changing the name of the template and adding the appropriate journal parameters, typically |journal=, |volume=, |issue=, |pages= plus perhaps |doi=, |bibcode=, etc:
{{cite arxiv |last=Lodders |first=K. |date = 2008 |title=The solar argon abundance |arxiv=0710.4523v1 |class=astro-ph}}
Lodders, K. (2008). "The solar argon abundance". arXiv:0710.4523v1 [astro-ph]. 
becomes
{{cite journal |last=Lodders |first=K. |date = 2008 |title=The solar argon abundance |arxiv=0710.4523v1 |class=astro-ph |journal=[[Astrophysical Journal]] |volume=674 |pages=607 |doi=10.1086/524725 |bibcode=2008ApJ...674..607L}}
Lodders, K. (2008). "The solar argon abundance". Astrophysical Journal 674: 607. arXiv:0710.4523v1 [astro-ph]. Bibcode:2008ApJ...674..607L. doi:10.1086/524725. 
Trappist the monk (talk) 11:11, 31 July 2015 (UTC)
Moot point about |at=, since |class= is supported anyway (but I would have disagreed; the |at= parameter is for location within the source |work=, not necessarily within the |title= object. One of the most frequent uses of |at= is identifying named sections of websites, periodicals, etc., in which the |title= article is located. But who cares? It doesn't matter anyway: The |class= value, as you say, is already part of all the cs1|2 templates.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  11:21, 1 August 2015 (UTC)
I never said that |at= was anything but an in-source location parameter. That was my reasoning for why |class= should not be mapped to |at=. At arXiv, class is akin to Wikipedia's categories.
Trappist the monk (talk) 14:06, 1 August 2015 (UTC)
OK. Not worth arguing about since it's doesn't matter anyway; |class= is directly supported.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  23:48, 5 August 2015 (UTC)
Two editors who cannot provide a rationale to keep this template, nor refute arguments to merge it, but just rant at me about it with a lot of heat, do not magically make a consensus. The fact that |class= is already handled by {{Cite journal}} (I hadn't noticed, and thought it might need to be added) just proves that the one thing that maybe, kinda-sorta made this template possibly not redundant, is actually irrelevant. This template is totally redundant. There is nothing I am "not hearing". I moved the discussion here because it was no longer relevant at its original location (no RS question is open any longer). But you can move it where ever you want; there doesn't appear to be anything left to discuss: There is literally no rationale for keeping this template at all. I decline to get worked up about it. The level of emotional invective being spewed about this is entirely out of proportion.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  11:14, 1 August 2015 (UTC)

PS: @David Eppstein: We not talking about merging {{arxiv}} with anything (I see there was one typographical error in the previous discussion about this stuff that referred to {{arxiv}} in passing instead of {{cite arxiv}}, in a side discussion about {{cite doi}}, but I would think the fact it was a typo would have been clear in the context, since the arguments about the latter do not pertain to the former, and none of that was central to the main thread to begin with. {{arxiv}} can be used to provide additional links if necessary to, e.g., multiple versions of the same paper, as someone else mentioned in the previous discussion. Is most of this angry verbiage simply generated because of a typo? This discussion is only about {{Cite arXiv}}.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  11:34, 1 August 2015 (UTC)

I haven't seen a lot of emotion, just confusion and attempts by other editors to find a way through the confusion. I can explain our confusion about which template you are proposing to discuss. The header of this section refers to {{ArXiv}}, but the discussion appears to be about {{Cite ArXiv}}. – Jonesey95 (talk) 02:41, 3 August 2015 (UTC)
Fixed! It doesn't explain the vitriol about this at Wikipedia talk:Identifying reliable sources#Unpublished/SPS/UGC sources and Template:Cite arXiv, which is entirely about Template:Cite arXiv. It all boils down to a defense of citing self-published claptrap at arXiv that isn't permissible under WP:SPS / WP:UGC.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  23:48, 5 August 2015 (UTC)

Non-URL not detected?[edit]

I came across this citation in ¿Dónde Están Mis Amigos?:

Cite web compare
{{ cite web | title=Spanish album certifications – Extremoduro – ¿Dónde están mis amigos? | work=[[Promusicae]] | url=Salaverri, Fernando. Sólo éxitos: año a año : 1959-2002. Iberautor Promociones Culturales, 2005. ISBN 84-8048-639-2 | language=Spanish | accessdate=1999 }}
Old [Salaverri, Fernando. Sólo éxitos: año a año : 1959-2002. Iberautor Promociones Culturales, 2005. ISBN 84-8048-639-2 "Spanish album certifications – Extremoduro – ¿Dónde están mis amigos?"] (in Spanish). Promusicae. Salaverri, Fernando. Sólo éxitos: año a año : 1959-2002. Iberautor Promociones Culturales, 2005. ISBN 84-8048-639-2. Retrieved 1999. 
Live [Salaverri, Fernando. Sólo éxitos: año a año : 1959-2002. Iberautor Promociones Culturales, 2005. ISBN 84-8048-639-2 "Spanish album certifications – Extremoduro – ¿Dónde están mis amigos?"]. Promusicae (in Spanish). Retrieved 1999.  Check date values in: |accessdate= (help)
Sandbox [Salaverri, Fernando. Sólo éxitos: año a año : 1959-2002. Iberautor Promociones Culturales, 2005. ISBN 84-8048-639-2 "Spanish album certifications – Extremoduro – ¿Dónde están mis amigos?"] Check |url= scheme (help). Promusicae (in Spanish). Retrieved 1999.  Check date values in: |access-date= (help)


The 1999 access date properly throws an error, but the URL does not, even though it probably should. Can the module code be tweaked to detect the above URL value as an error? – Jonesey95 (talk) 11:52, 31 July 2015 (UTC)

I suggested such a check here but there was no response. Keith D (talk) 12:34, 31 July 2015 (UTC)
The extra stuff in |url= like that of your example citation is caught by the modified test described below:
{{cite news/new| url=Read more: http://www.politico.com/story/2015/01/police-union-wants-protection-under-hate-crime-law-113976.html#ixzz3Y5B26xv1| title=Police union wants protection under hate crime law| publisher=Politico| date=January 5, 2015}}
[Read more: http://www.politico.com/story/2015/01/police-union-wants-protection-under-hate-crime-law-113976.html#ixzz3Y5B26xv1 "Police union wants protection under hate crime law"] Check |url= scheme (help). Politico. January 5, 2015. 
Trappist the monk (talk) 13:04, 31 July 2015 (UTC)

(edit conflict)

The value in |url= is not determined to be bad because it contains one or more colons. To satisfy the one of the conditions of the test, a colon may be preceded by anything but a forward slash. I don't think that spaces are allowed in a uri so I've tweaked the test so that the test will fail if the uri has spaces. More research is required I think. I've tweaked your compare template.
Trappist the monk (talk) 12:48, 31 July 2015 (UTC)
Indeed, external links in Wikipedia cannot have a space since we cannot manipulate the href attribute of the a. However, they can have a character encoded space e.g. %20. --Izno (talk) 13:37, 31 July 2015 (UTC)
External links in WP cannot contain white space, per Help:URL#Linking_to_URLs. I wanted to make sure that there was verification of this statement, and it looks like there is.
I suspect that this new test will unearth a lot of faulty URL parameter values (I'm guessing between 1,000 and 10,000) that have previously gone undetected. More work for us gnomes.... – Jonesey95 (talk) 14:13, 31 July 2015 (UTC)
The gnomes shall inherit... --Izno (talk) 14:43, 31 July 2015 (UTC)
It's not just external links in Wikipedia. URLs anywhere cannot contain spaces (internal links in Wikipedia that contain spaces actually contain underscores when expressed as URLs) - they're not explicitly allowed by RFC 3986, therefore they are forbidden. Percent encoding is a way to workaround the problem that forbids the use of several characters (not just spaces) in URLs, see section 2.1. Percent-Encoding. Indeed, spaces can have a special meaning, see Appendix C. --Redrose64 (talk) 19:40, 31 July 2015 (UTC)
This added check does seem like an improvement to the templates. Have the templates also recently changed to turn newlines in article titles into spaces? I seem to remember that causing problems with links before, but now I can't get it to misbehave. —David Eppstein (talk) 20:39, 31 July 2015 (UTC)

I've tweaked the url test a bit. The first thing the sandbox does is look for space characters in the whole of the url. In the earlier fix the sandbox checked for space characters only in the scheme portion. Next the sandbox tests for protocol relative urls (those urls that begin with '//' – no scheme). And lastly sandbox looks at the composition of the scheme itself. The scheme must begin with a letter, may contain letters, digits, and the plus, period and hyphen ('+', '.', '-') characters and be terminated with a colon (':').

  • [www.example.com "Fail: no scheme, not protocol relative"] Check |url= scheme (help). 
  • [http//www.example.com "Fail: no colon"] Check |url= scheme (help). 
  • [8http://www.example.com "Fail: scheme begins with a digit"] Check |url= scheme (help). 
  • [ht tp://www.example.com "Fail: space in scheme"] Check |url= scheme (help). 
  • ample.com "Fail: space in domain name" Check |url= scheme (help). 
  • [[3] "Fail: wikimarkup"] Check |url= scheme (help). 

We support scheme:path urls in {{cite newsgroup}} so the url we create should look like news:comp.os.minix

And the usual suspects:

There is a list of official and semi-official uri schemes at URI scheme.

Trappist the monk (talk) 23:13, 31 July 2015 (UTC)

This seems suboptimal: [www.example.com "Fail: no scheme, not protocol relative"]. Anything that parses as a domain name should be treated by default as if preceded by http://, I would think. Or if that's hard to detect without false positives, anything of the form ww*.*.*[.*[.*]] should probably be treated that way (ww*. to catch "ww2.", "www2.", etc.; and [.*[.*]] to catch long university domain names, like worst case scenario: www2.phys.sci.ic.ac.uk, to make one up).  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  12:04, 1 August 2015 (UTC)
I disagree; one could set up an FTP server at www.example.com. Or any of a number of other schemes, such as mailto. --Izno (talk) 01:15, 3 August 2015 (UTC)
So? I could name my cat www.feedme.com. It's not reasonable to expect non-web addresses in this field (unless someone very explicitly puts in something like "ftp://..."), any more than pet's names appearing here. We can't reasonably be expected to account for every PEBKAC situation. It is increasingly and very common for people to drop the "http://" from Web addresses, since there are [probably] zero extant browsers that don't do precisely what I'm suggesting here: Treat a URL without the protocol identifier as an http:// URL by default.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  23:58, 5 August 2015 (UTC)
How do we positively identify a URL if it does not have http:// at the start? What pattern do we search for? For some real-life examples of what editors do to the |url= parameter, look through Category:Pages with URL errors. At least half of the ones I just looked at would not link to a source if we simply added "http://" to the front of the parameter's value. Those need to be tagged or investigated by a human, something that would not happen without the error message. – Jonesey95 (talk) 01:12, 6 August 2015 (UTC)
I already gave the pattern to look for (albeit not as a regexp).  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  17:16, 6 August 2015 (UTC)

Actually, there's a more trivial use case to consider: the odd website that does not serve content over HTTP but instead HTTPS. Like we do, these days. HTTP happens to redirect but that's a function of the particular website, not a global assumption that can be made. Regardless of what browsers do, I would prefer to see the error rather than gracefully permit an editor to leave off the scheme where it might be the case that the page in question does not use HTTP.

@Trappist the monk: I assume this is the case, but does |archiveurl= have these checks? --Izno (talk) 17:44, 6 August 2015 (UTC)

yes. It's part of the code that renders a wiki external link so applies to all external links made by the module:
[8ttp://example.com "Example"] Check |url= scheme (help). Archived from [/example.org the original] Check |url= scheme (help) on 2015-08-06. 
[example.org "Chapter"] Check |url= scheme (help). Example. 
Trappist the monk (talk) 18:01, 6 August 2015 (UTC)

Italicization of websites in citations[edit]

If I may revive an old discussion (pardon me if there are other threads), I don't understand why we are italicizing websites (thru the |website= parameter) in citation templates. The argument seems to be that the alias of |website= is |work= (meaning you can use one or the other but not both) and obviously |work=, |journal=, etc. should be italicized. But the plain fact is that, per the MOS, while we italicize the names of publications, we (generally) do not do so for websites. So these parameters should not be interchangeable. For example: TMZ, Gawker, BroadwayWorld.com and other sites and urls should not be italicized. And while for content found in both a print publication and on its website I may cite The Advocate or Entertainment Weekly, if the actual url is being cited (Advocate.com or EW.com) it should not be italicized. This seems like a no-brainer.— TAnthonyTalk 21:16, 31 July 2015 (UTC)

"Generally" is the key word here, though. The vast majority of the time when a WP article is referring to a website, it's referring to it a business entity (or other kind of entity, e.g. a nonprofit, a free software coding group, a government project, whatever), or in a functional way, e.g. as a service or product. But when we cite it as a source, we're referring to it as a major published work, like a book, journal, magazine, film, etc. So, whether the italics are "required" or not, they're definitely not incorrect when applied in this case. It's consistent and uncomplicated for us to continue italicizing them in source citations.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  09:53, 1 August 2015 (UTC)
As a journalist and editor, I need to disagree with the premise that when we cite Amazon.com, or the British Board of Film Classification or Marvel.com that these entities transmogrify into "a major published work, like a book, journal, magazine, film, etc."
No mainstream source italicizes Amazon.com, British Board of Film Classification, Marvel.com, or, for that matter, Rotten Tomatoes or Box Office Mojo, and none of these entities themselves italicize their names.
Italicizing dotcom names is not done anywhere else, and I'm afraid I can't find a valid reason that Wikipedia should create a non-traditional form of punctuation. Indeed, not even Wikipedia italicizes these entities in their respective articles. So I'd like to ask for what compelling reason we do so here. --Tenebrae (talk) 19:43, 29 August 2015 (UTC)
I agree. Entirely. ~ J. Johnson (JJ) (talk) 22:25, 30 August 2015 (UTC)
With what, though? Half of that wasn't cogent. British Board of Film Classification is a publisher, not a work of any kind, and what source italicizes itself (except as an incidental stylistic matter)? Looking at an entire bookshelf, only a tiny handful of covers have italic titles, and if you look at the actual title on the frontispiece, and at the top or bottom of each (or every other) page in the book, it is not italicized. This tells us nothing at all about whether WP would italicize the book title in a citation to it. No one made any such argument of "transmogrification". What I actually said was 'when we cite [a website] as a source, we're referring to it as a major published work, like a book, journal, magazine, film, etc. So, whether the italics are "required" or not, they're definitely not incorrect when applied in this case. It's consistent and uncomplicated for us to continue italicizing them in source citations.' This argument has not actually been responded to at all. Instead, Tenebrae told us what some other publishers are doing, and made some unrelated observations. But WP's citation system is not that of any other site or publication, and no case has been made for why WP should treat the titles of all major works consistently (italicizing them by template) except when they're online publications.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  23:21, 30 August 2015 (UTC)
The problem is with how the website parameter is used. Since it's a synonym for work, it should only be used when a work is given as the value. "Amazon.com" is not a work. Peter coxhead (talk) 00:59, 31 August 2015 (UTC)

HTML5 bait-and-switch: The cite element again[edit]

FYI: Pointer to relevant discussion elsewhere

See MediaWiki talk:Common.css#The cite element needs to not auto-italicize any longer. Summary: After something of an HTML developer community revolt, the early HTML5 change of <cite> element to only pertain to the title of the work has been abandoned since late 2013, and the published, non-draft version of HTML5 (issued in late 2014) has gone back to HTML 4.01's broader scope for this element (and this is maintained in the HTML5.1 draft). So, the auto-italicizing of this element needs to stop, its use at Template:Quote needs to shift back, and that may need to be done here in CS1, too, if we're making any use of it. The element, though commonly used with <blockquote>; is not tied to it; rather, it generically represents any citation. Now that the title-only change has been abandoned, <cite>...</cite> should surround the entire citation generated by CS1 (and the rest of the citation templates), but only after MW:Common.css stops italicizing its content.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  10:14, 1 August 2015 (UTC)

<cite>...</cite> is not used in cs1|2.
Trappist the monk (talk) 10:55, 1 August 2015 (UTC)
But it could be. I'm not sure what Semantic HTML gold would be earned by doing so, but it's feasible (after the CSS tweak), and wouldn't seem to "cost" anything but a few characters.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  11:55, 1 August 2015 (UTC)
Not even that. Right now we wrap the citation in a <span>...</span> which I think, could just as easily be <cite>...</cite>. From this:
{{cite book |title=Title |author=Author |location=Location |publisher=Publisher |date=1 August 2015}}
Module:Citation/CS1 creates this:
<span class="citation book">Author (1 August 2015). ''Title''. Location: Publisher.</span>
and could easily be changed create this:
<cite class="citation book">Author (1 August 2015). ''Title''. Location: Publisher.</cite>
Trappist the monk (talk) 14:25, 1 August 2015 (UTC)
Well, one would need to move the full stop I think since that's not part of the title, but that's a minor issue. Maybe that's actually a bug in the current module? --Izno (talk) 16:05, 1 August 2015 (UTC)
I understood Editor SMcCandlish's comment to mean wrapping the entire cs1|2 citation in <cite>...</cite>. Adding separate tags to each title part (chapter, title, work) and each name (author, editor, other) seems enormously redundant given that the citation is the sum of all of its various parts which, each taken separately, may or may not be recognizable as a citation. If mw:common.css is changed so that italic styling is no longer applied to <cite>...</cite> then the change I illustrated, now expanded for clarity, can be made – assuming that w3c settles on a definition that isn't tied solely to titles or persons.
Trappist the monk (talk) 16:47, 1 August 2015 (UTC)
That was indeed his comment. I was commenting on the fact that your previous examples appeared to be outputting an incorrect span, but I see that's not the case now. --Izno (talk) 18:21, 1 August 2015 (UTC)
Yes, I mean replace the entire <span>...</span> with <cite>...</cite>.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  23:44, 5 August 2015 (UTC)
We can actually just do this right now, using <cite style="font-style: normal">...</cite>, and not wait for the interminable WP:FILIBUSTER process at Mediawiki:Common.css, in which the self-appointed gatekeepers generally will stonewall anything that doesn't do precisely what the W3C default suggestions are.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  23:44, 5 August 2015 (UTC)
filibuster[ing] gatekeepers: Erm? --Izno (talk) 02:21, 6 August 2015 (UTC)
Don't need to get into it in detail here.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  17:14, 6 August 2015 (UTC)
I was looking for a reason for the personal attacks. I agree you don't need to get into it here, and shouldn't have used the phrase at all.

That aside, I disagree with the assertion that We can actually just do this right now. Let's figure out whether we want to use cite that way first (there) and then we can make the change (here). --Izno (talk) 17:38, 6 August 2015 (UTC)

It's not up to the CSS page to determine what elements and classes are to be used in Wikipedia. It's up to implementors of templates, etc., to determine what elements and classes they need implemented at the CSS page! You're putting the cart before the horse. More like putting the horse in the driver's seat of the cart. Also, criticism of longstanding editing patterns isn't an "attack".  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  03:15, 7 August 2015 (UTC)

It's not up to the CSS page I agree with. I disagree with [i]t's up to implementors of templates, etc. My position is that you are, intentionally or otherwise, attempting to split discussion of what we should do with the element. Seeing as the discussion at MW:Common.css was opened prior to this one, my position is also that we should stop commenting here on that point.

Also, criticism of longstanding editing patterns isn't an "attack". Any comment not in accordance with NPA is on the wrong track. From that policy, Do not make personal attacks anywhere in Wikipedia. Comment on content, not on the contributor. In this case, it is clear to me you have commented on the contributors, not the content. If you think that there are problems with the users at that page, ANI is -> that way. --Izno (talk) 04:21, 7 August 2015 (UTC)

@Izno: What we should do editorially with the element is entirely a matter for contextual discussion with regard to different templates and other situations, and across MW generally, not just at en.wp. I.e., those are automatically separate discussions. One thing that should be done with <cite> is, for example, to wrap users' signatures in it on talk pages (when used with ~~~ and ~~~~, which is attribution, but not with ~~~~~, which is just a shorthand for date insertion). Something similar should be done around both parameters of {{Unsigned}}, and the attributive parameter of {{Talkquote}}. What should be done with it in the citation templates is wrap the entire output with it instead of with <span>. What should be done with it at Template:Quote is put it around both the |author= and |source= parameters' output if one or both are used, and suppress it otherwise. And so on. I'm sure we can devise many distinct uses and implementations of this semantic metadata markup.

What we should do technologically about the element at Mediawiki/common.css is obviously to stop force-italicizing it, because that's pointless, wrong for most uses we can put to the element, and it interferes with and prejudices decisions about what we should do editorially with the element. Except when it is essentially impossible to work around, technological considerations never dictate content editing matters here.

These are completely severable discussions, and should be split. The fact that it's virtually impossible to get the controllers of that interface page to do even simple, commonsense things means that the editorial, context specific discussions necessarily need to address "routing around" this processual "damage" to get the work done. It would be completely ridiculous if 6 months from now we're still not doing the more useful things with this element simply because undoing the forced italics was still being stonewalled at Mediawiki/common.css, a sadly predictable outcome, though I may try an RfC to get it done. I'll also take the matter up with the MW developers, since this italicization doesn't make sense as a MW default to begin with, just as it did not for <dfn>, but I'll have to bother to figure out the new-ish ticket tracking system. (Haven't filed a MW bug since they quit using Bugzilla.)  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  06:58, 7 August 2015 (UTC)

discontinuing support for some deprecated parameters[edit]

There are several deprecated parameters that I have been weeding out of Category:Pages containing cite templates with deprecated parameters over the past few months. When I started that category had 23k+ articles. Because the parameters that I propose to kill are rarely used, those that still exist will show up in Category:Pages with citations using unsupported parameters, a relatively small category. There is the additional benefit that the unsupported parameter error messages are not hidden so that editors other than the usual gnomes might (yeah, might) help to fix them. Here is a list of the parameters that I propose to kill:

these will be added to Module:Citation/CS1/Suggestions:

  • |authorformat=
  • |author-format=
  • |began=
  • |editorformat=
  • |editor-format=
  • |ended=
  • |separator=

these not added to Module:Citation/CS1/Suggestions because lowercase versions will be automatically suggested by the code:

  • |Author=
  • |Authorn=
  • |Editor=
  • |Editorn=
  • |EditorGiven=
  • |EditorGivenn=
  • |EditorSurname=
  • |EditorSurnamen=

these not added to Module:Citation/CS1/Suggestions because there are no one-to-one replacements for them:

  • |author-name-separator=
  • |author-separator=
  • |chapter-link=
  • |editor-name-separator=
  • |editor-separator=
  • |name-separator=

Still deprecated then would be |coauthor=, |coauthors=, and |month=.

Trappist the monk (talk) 18:24, 3 August 2015 (UTC)

I've rearranged the list above because of the module handles incorrect case without needing to consult the suggestion list.
Trappist the monk (talk) 18:46, 3 August 2015 (UTC)
Support. I think we should remove support for |month= as well, but we might need to have a separate, well-advertised thread for that suggestion. It has been deprecated for a long time, and there are periods where there are no instances of |month= at all, typically after one of us gnomes has used an insource search to find and fix a few dozen that have cropped up. – Jonesey95 (talk) 00:59, 4 August 2015 (UTC)
Yeah, I just ran Monkbot task 1 and it made so 60 edits so I agree that we can kill |month=. I don't know if we need a separate thread to advertise that |month= is going to be killed. Certainly a post at User talk:ProveIt GT is in order – as I understand it, that tool is still emitting |month=.
Trappist the monk (talk) 12:36, 4 August 2015 (UTC)
Two requests have been posted at the ProveIt talk page in the past couple of years. A bug report has also been filed at its Github site. I went to the Github site and attempted to submit a code change proposal, but I don't really know what I'm doing there, so I don't know if it will work. That's probably enough notice for ProveIt. – Jonesey95 (talk) 13:39, 4 August 2015 (UTC)
Some how, when we deprecated and removed the mixed case parameter names, we missed |PPrefix=. This parameter is, according to an insource search, not used so I will remove it.
Trappist the monk (talk) 10:19, 5 August 2015 (UTC)

I have deactivated the above named parameters. These citations are here to show that they are deactivated and that the changes necessary to deactivation did not break anything.

  • Last, FM; Last2, FM. Title.  Unknown parameter |authorformat= ignored (|name-list-format= suggested) (help)
  • Last, FM; Last2, FM. Title.  Unknown parameter |author-format= ignored (|name-list-format= suggested) (help)
  • Last2, FM. Last, FM, ed. Title.  Unknown parameter |editorformat= ignored (|name-list-format= suggested) (help); Missing |last1= in Authors list (help)
  • Last2, FM. Last, FM, ed. Title.  Unknown parameter |editor-format= ignored (|name-list-format= suggested) (help); Missing |last1= in Authors list (help)
  • Last, FM; Last2, FM. Title.  Unknown parameter |separator= ignored (|mode= suggested) (help)
  • Title.  Unknown parameter |Author= ignored (|author= suggested) (help); Unknown parameter |Author2= ignored (|author2= suggested) (help)
  • Title.  Unknown parameter |Editor= ignored (|editor= suggested) (help); Unknown parameter |Editor2= ignored (|editor2= suggested) (help)
  • Title.  Unknown parameter |EditorGiven2= ignored (help); Unknown parameter |EditorSurname2= ignored (help); Unknown parameter |EditorSurname= ignored (|editor-surname= suggested) (help); Unknown parameter |EditorGiven= ignored (|editor-given= suggested) (help)
  • Last, FM; Last2, FM. Title.  Unknown parameter |author-separator= ignored (help)
  • Last, FM; Last2, FM. Title.  Unknown parameter |author-name-separator= ignored (help)
  • Last, FM; Last2, FM. Title.  Unknown parameter |editor-separator= ignored (help)
  • Last, FM; Last2, FM. Title.  Unknown parameter |editor-name-separator= ignored (help)
  • Last, FM; Last2, FM. Title.  Unknown parameter |name-separator= ignored (help)
  • Last, FM; Last2, FM. Title.  Unknown parameter |PPrefix= ignored (help)
  • Last, FM; Last2, FM. "Chapter". Title.  Unknown parameter |chapterlink= ignored (help)
  • Last, FM; Last2, FM. "Chapter". Title.  Unknown parameter |chapter-link= ignored (help)
  • Last, FM (1963). Title.  Unknown parameter |month= ignored (|date= suggested) (help)
  • Last, FM. Title.  Unknown parameter |began= ignored (|date= suggested) (help); Unknown parameter |ended= ignored (|date= suggested) (help)
    • tests to prove that removing |began= / |ended= did not break these:
      • Last, FM (1963). Title (published 10 October 1963). 
      • Last, FM (10 October 1963). Title. 
      • Last, FM (1963). Title (published 10 October 1963). 

While not a result of this deactivation, the tests for |EditorGiven2= and |EditorSurname2= do show that the suggestion code doesn't support enumerated parameters. I've added that to Feature requests.

Trappist the monk (talk) 15:20, 6 August 2015 (UTC)

deprecate enumerator-in-the-middle parameters[edit]

See this archived discussion.

I propose to deprecate these parameters and standardize on the enumerator-at-the-end form. The numbers in the preference ratio column are caclulated from the values in the tables in the archived discussion: (terminal enumerator ÷ medial enumerator). Where the cells are blank the denominator is zero.

CS1 parameters to be deprecated
parameter extant replacement preference ratio
|authorn-last= |author-lastn= 2.51
|authorn-first= |author-firstn= 2.36
|authorn-link= |author-linkn=dagger 1.91
|authornlink= |authorlinkn= 1066.9
|authorn-mask= |author-maskn=dagger 101.43
|authornmask= |authormaskn= 23.23
|editorn-link= |editor-linkn=dagger 1.54
|editornlink= |editorlinkn= 7.24
|editorn-mask= |editor-maskn=dagger 3.17
|editornmask= |editormaskn= 16
|editorn-first= |editor-firstn= 1.42
|editorn-given= |editor-givenn=
|editorn-last= |editor-lastn= 1.58
|editorn-surname= |editor-surnamen=
|subjectn-link= |subject-linkn=dagger 47
|subjectnlink= |subjectlinkn=

dagger these parameters are the canonical form

Trappist the monk (talk) 13:26, 4 August 2015 (UTC)

Makes more conceptual sense the other way around. editor2-last implies the last name of editor #2, but editor-last2 implies the second surname of the editor.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  23:33, 5 August 2015 (UTC)
I agree with SMC on this point and think it would make more sense to keep the number in the middle than to have it out there hanging at the end. --Izno (talk) 17:47, 6 August 2015 (UTC)
The implication arises from the sense of the digit binding more tightly than the hyphen. (I.e., to "last" rather than "editor-last".) On the otherhand, when indexing a list of authors/editors I have found it most useful to have the index digit next to the equals sign, which gives the index better visibility, and provides a handy anchor for a regex. It's also easier to scan a list of authors/editors when the index is not buried inside the string. Which all might explain the medial location is not as widespread as the terminal form. I prefer the latter. ~ J. Johnson (JJ) (talk) 20:16, 7 August 2015 (UTC)
And yet others of us view the number as better in the middle. Comparing |editor2-last= and |editor-last2=, I parse the first as being the last name of the second editor and the second as the second last name of the (singular) editor. YMMV, and as far as I'm concerned, there's no harm in retaining both forms. Imzadi 1979  20:44, 7 August 2015 (UTC)
I am sympathetic to both points of view though my personal preference is terminal enumerator. I have added a column to the table that shows that overall, editors who have used these enumerated parameters generally prefer to use the terminal enumerator forms.
Trappist the monk (talk) 12:26, 8 August 2015 (UTC)
That's surely skewed by how they're documented, and likely also by some individuals, perhaps even with AWB scripts, manually changing them to your "preferred" version. I know I've occasionally seen diffs that include this change along with other "general cleanup".  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  04:06, 9 August 2015 (UTC)
Of course it's possible that the documentation has influenced one style choice over the other and its possible that editors change extant parameters to suit their own preferences. I don't know that AWB, as part of its general fixes, makes this kind of change; I haven't noticed changes of that kind. If you are suggesting that I have written an AWB script that changes enumerator-in-the-middle to enumerator-at-the-end, then you would be wrong.
Trappist the monk (talk) 12:35, 9 August 2015 (UTC)
  • Strongly oppose deprecation. These are still listed as the primary parameter names for {{citation}} and we should not diverge the CS1 and CS2 templates so far from each other as to deprecate one template's parameters in the other. Additionally, these are used by software for creating citation templates (I know, because I have written such software myself). What purpose is served by this change? What does it make better? It seems to me to be purely a foolish consistency. Finally, I note that once again Trappist is proposing major changes that relate to {{citation}} without even bothering to mention the discussion on Template talk:Citation. Trappist, you have been told over and over again: don't do that. —David Eppstein (talk) 17:14, 8 August 2015 (UTC)
    I don't understand why you think this affects {{citation}}... when it doesn't. --Izno (talk) 21:09, 8 August 2015 (UTC)
This change affects {{citation}} because {{citation}}, despite being cs2, is rendered by Module:Citation/CS1.
Trappist the monk (talk) 21:52, 8 August 2015 (UTC)
Yes, and also because it is desirable to continue the current state of affairs in which we can change CS1 to CS2 or vice versa just by changing the template name. Not that changing the citation style of an article is frequent nor usually a good idea. But finding articles that mix the two styles is common enough, and changing them to use only one is usually a (minor) improvement. Thanks to recent improvements it's also possible to do this using a parameter but changing the actual template name seems less likely to encourage more inconsistency later. —David Eppstein (talk) 06:27, 9 August 2015 (UTC)
Standardizing on terminal enumerators will not prevent editors from changing CS1 to CS2 or vice versa just by changing the template name. Standardizing on lowercase parameter names did not change that nor did standardizing on the hyphen as a separator in parameter names change that.
Trappist the monk (talk) 12:35, 9 August 2015 (UTC)
Citation Style 2 is distinguished from Citation Style 1 by its element separator (comma vs period), by lowercase static text (retrieved..., archived from ..., written at ..., etc. vs Retrieved..., Archived from ..., Written at ..., etc.), by terminal punctuation (none vs period), and cs2 automatically sets |ref=harv, cs1 doesn't. cs2 is not distinguished from cs1 by some subset of the commonly shared parameters.
The primary documentation for both cs1 and cs2 is {{csdoc}}. I grant that {{csdoc}} has a cs1 bias, so does Help:CS1 errors though I did a bit of work on that recently that removed some of the bias.
Of the sixteen parameters in the above table, these seven are found in Template:Citation/doc outside of the {{csdoc}} content:
|authornlink=
|authorn-link=
|editorn-first=
|editorn-last=
|editorn-link=
|editorn-given=
|editorn-surname=
Are we to believe then that the other nine are not or should not be supported by {{citation}}?
Yep, it is just for consistency whether you think it foolish or not. This choice is no different from the choice we made to standardize on parameter names that use hyphens instead of underscores or spaces; and standardize on lowercase instead of capitalized or camel-case. Choosing one flavor or the other is merely for consistency.
Trappist the monk (talk) 21:52, 8 August 2015 (UTC)
Yes, I think it is foolish to suddenly kill off the primary documented parameter choices of the sister CS2 style, that our templates have been handling perfectly well, for the sake of no reason at all but neatness. The costs of this proposal involve breaking software or forcing the developers of the software to make parallel changes, breaking the mental model of who knows how many editors (as an example, I am still months after you made this change unable to remember to use contribution-url= in place of url= for the url of book chapters, and this is causing actual citations to be formatted wrong), forcing edits to who knows how many live citations after the red error messages start showing up, etc. The benefit of the proposal is appeasing the OCD of one single software developer who wants all the ducks to be perfectly lined up in a precise row. It's a bad idea. —David Eppstein (talk) 02:52, 9 August 2015 (UTC)
Agreed (other than the assumption of mental issues), and as I said earlier, the proposed "norms" don't make conceptual sense: |author2-last= implies the surname of the second author, while |author-last2= implies the second surname of the (singular) author. I.e., there are multiple, independent reasons not to deprecate this, and at least one to actually prefer the form Trappist wants to deprecate.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  04:00, 9 August 2015 (UTC)
Deprecation does not suddenly kill off anything.
Trappist the monk (talk) 12:35, 9 August 2015 (UTC)
Must be why I still have an ant problem. This bug spray says "Deprecates on Contact!"  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  17:41, 10 August 2015 (UTC)
:-} ~ J. Johnson (JJ) (talk) 23:38, 11 August 2015 (UTC)

separator preceding et al. static text[edit]

See this discussion. (I have taken-up that conversation up here so that Module talk:Citation/CS1 can be archived and then redirected here per this discussion.)

I have tweaked Module:Citation/CS1/sandbox to insert the name-list separator character and a space between the end of the trailing author/editor name and the 'et al.' static text. The code uses the separator character that is associated wwith the particular name-list format: a semicolon for generic cs1|2 |lastn= / |firstn= / |authorn= names list (the same for the editor versions of these), and a comma for Vancouver system author and editor name lists: |vauthors=, |veditors=, and the last/first/author (and editor) lists when |name-list-format=vanc.

{{cite book/new |title=Title |last=Last |first=First |display-authors=etal}}
Last, First; et al. Title. 
{{cite book/new |title=Title |editor-last=Last |name-list-format=vanc |editor-first=First |display-editors=etal}}
Last F, et al. Title. 
{{cite book/new |title=Title |editor-last=Last |editor-first=First |display-editors=etal}}
Last, First; et al. (eds.). Title. 
{{cite book/new |title=Title |vauthors=Last F |display-authors=etal}}
Last F, et al. Title. 
{{cite book/new |title=Title |vauthors=Last F et al.}}
Last F, et al. Title. 
{{cite book/new |title=Title |veditors=Last F |display-editors=etal}}
Last F, et al. (eds.). Title. 
{{cite book/new |title=Title |veditors=Last F et al.}}
Last F, et al. (eds.). Title. 

I don't think that there is a solution for the free-form author and editor parameters |authors= and |editors= so for these, the static 'et al.' text is appended without a separator character (this is the same as the current live version:

{{cite book/new |title=Title |authors=Last, First and Last2, First2 M. |display-authors=etal}}
Last, First and Last2, First2 M. et al. Title. 
{{cite book/new |title=Title |editors=Last, First and Last2, First2 M. |display-editors=etal}}
Last, First and Last2, First2 M. et al. (eds.). Title. 

Trappist the monk (talk) 16:34, 4 August 2015 (UTC)

Missing author without error message[edit]

I found the following citation in ¡Vivan los niños!, which was in Category:CS1 errors: missing author or editor:

Cite news compare
{{ cite news | date=2003-03-15 | first=SUN-AEE | publisher=El Siglo de Torréon | title=Vivan los niños llega a su fin | work=Online edition | url=http://www.elsiglodetorreon.com.mx/noticia/23653.vivan-los-ninos-llega-a-su-fin.html | language=Spanish | accessdate=2009-10-21 }}
Live "Vivan los niños llega a su fin". Online edition (in Spanish) (El Siglo de Torréon). 2003-03-15. Retrieved 2009-10-21. 
Sandbox "Vivan los niños llega a su fin". Online edition (in Spanish) (El Siglo de Torréon). 2003-03-15. Retrieved 2009-10-21.  |first1= missing |last1= in Authors list (help)


As of this writing, the above citation does not emit a red error message (for me, at least), but I think it should. It has a first name with no last name. – Jonesey95 (talk) 04:26, 5 August 2015 (UTC)

Yep, and I am perplexed.
Trappist the monk (talk) 12:01, 5 August 2015 (UTC)
Ha! Found it! In the function select_author_editor_source() we select one of three possible name lists to use: |authorn= / |lastn= / |firstn= or |vauthors= or |authors=. The code looks for |last=, |last1= and |last2= (and aliases). If the code doesn't find any of these and also doesn't find |vauthors= and |authors=, then it returns a value indicating that there isn't an author list. That no-author-list return value causes the missing name check to be skipped. For now, I've set the code to assume that there is an |authorn= / |lastn= / |firstn= list when no author-name-lists are defined so that the missing name test can catch a |first= only error.
Trappist the monk (talk) 12:44, 5 August 2015 (UTC)

Erroneous maintenance warning[edit]

I'm afraid that the error checking is treating |edition=Updated as an error. I imagine we need to check for /\b[Ee]d\W*$/ or whatever in the regular expression (or whatever). Please see this edit which showed the problem. --Mirokado (talk) 22:49, 5 August 2015 (UTC)

This has been fixed in the sandbox. See Help_talk:Citation_Style_1#extra_text_in_.7Cedition.3D_detection_bug and Help_talk:Citation_Style_1#.22Revised.22_in_edition_parameter_is_triggering_maintenance.
Trappist the monk (talk) 23:00, 5 August 2015 (UTC)
Thanks, I didn't notice the other sections. --Mirokado (talk) 12:47, 6 August 2015 (UTC)

Minor bug in Template:Cite book[edit]

It's no longer properly supporting the |work= parameter:

Thor, A. U. (2015). "My First Chapter". My First Book.  Missing or empty |title= (help)

While it displays |work= as an alias of |title=, the missing title routine fails to do so.

This obviously impedes correction of misuse of {{Cite journal}} and {{Cite web}} for books.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  23:53, 5 August 2015 (UTC)

Back in the old days of {{citation/core}}, |work= and its aliases were ignored by {{cite book}}.
|title= has no aliases.
Whatever content is contained in |work= in {{cite book}} is not passed on to the metadata because there is no place for it
Perhaps, |work= and its aliases should again be ignored for {{cite book}} and perhaps other cs1 templates
Trappist the monk (talk) 10:27, 6 August 2015 (UTC)
Need to do the opposite, since having |work= not function for this and some other templates obviously impedes correction of misuse of {{Cite journal}} and {{Cite web}} for books.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  17:12, 6 August 2015 (UTC)
Use {{cite encyclopedia}} instead, with the same parameters: Thor, A. U. (2015). "My First Chapter". My First Book.  --Redrose64 (talk) 19:10, 6 August 2015 (UTC)
Yet another "use the wrong template, which someone else will just revert later" non-solution.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  03:17, 7 August 2015 (UTC)

error handling for parameters with defined values[edit]

As the result of a conversation elsewhere, I have added a function is_valid_parameter_value() that checks a parameter's value against a list of accepted values. If the parameter value is not a member of the accepted list, the function emits an invalid parameter error. There is code in the current live module that detects these kinds of errors for |mde= and |name-list-format=. This new code extends that functionality to several other parameters.

|nopp=
accepted values are 'yes', 'true', 'y'
  • Title: nopp=y. pp. 45-46. 
  • Title: nopp=true. pp. 45-46. 
  • Title: nopp=yes. pp. 45-46. 
  • Title: nopp=1. p. pp. 45-46.  Invalid |nopp=1 (help)
|name-list-format=
accepted value is 'vanc'
  • Last FG, Laster AB, Lastest F. Title: name-list-format=vanc. 
  • Last, Fred George; Laster, A. B.; Lastest, First. Title: name-list-format=venc.  Invalid |name-list-format=venc (help)
|mode= – accepted values are 'cs1', 'cs2'
  • Last, Fred George; Laster, A. B.; Lastest, First. Title: mode=cs1. 
  • Last, Fred George; Laster, A. B.; Lastest, First, Title: mode=cs2 
  • Last, Fred George; Laster, A. B.; Lastest, First. Title: mode=cs3.  Invalid |mode=cs3 (help)
|dead-url=
accepted values are 'yes', 'true', 'y', 'no'
|subscription=
accepted values are 'yes', 'true', 'y'
  • Title: subscription=y. (subscription required (help)). 
  • Title: subscription=true. (subscription required (help)). 
  • Title: subscription=yes. (subscription required (help)). 
  • Title: subscription=1. (subscription required (help)).  Invalid |subscription=1 (help)
|registration=
accepted values are 'yes', 'true', 'y'
  • Title: registration=y. (registration required (help)). 
  • Title: registration=true. (registration required (help)). 
  • Title: registration=yes. (registration required (help)). 
  • Title: registration=1. (registration required (help)).  Invalid |registration=1 (help)

Have I missed any others? —Trappist the monk (talk) 17:11, 7 August 2015 (UTC)

I did:
|ignore-isbn-error=
accepted values are 'yes', 'true', 'y'
|no-tracking=
accepted values are 'yes', 'true', 'y'
  • Title: no-tracking=y. 
  • Title: no-tracking=true. 
  • Title: no-tracking=yes. 
  • Title: no-tracking=1.  Invalid |no-tracking=1 (help)
Trappist the monk (talk) 17:43, 7 August 2015 (UTC)
and another:
|last-author-amp=
accepted values are 'yes', 'true', 'y'
  • Title: last-author-amp=y. 
  • Title: last-author-amp=true. 
  • Title: last-author-amp=yes. 
  • Title: last-author-amp=1.  Invalid |last-author-amp=1 (help)
Trappist the monk (talk) 14:46, 10 August 2015 (UTC)
I've created a table of keywords in Module:Citation/CS1/Configuration/sandbox so that the keywords can be defined and the same reused; 'yes, true, y' is used for several parameters – no need to keep separate lists.
Trappist the monk (talk) 17:19, 15 August 2015 (UTC)
Why reinvent the wheel, when we have {{yesno}}? --Redrose64 (talk) 17:34, 15 August 2015 (UTC)
template vs module.
Trappist the monk (talk) 17:39, 15 August 2015 (UTC)
Module:Yesno does exist. My concern using it in general would be that in a number of cases we don't have a boolean consideration (e.g. yes v. no) but instead an enumerated comparison. --Izno (talk) 19:02, 15 August 2015 (UTC)

another missed capitalized parameter[edit]

|Ref= escaped the purge. Until now. I have deprecated it for reasons of non-standard capitalization.

Trappist the monk (talk) 00:08, 8 August 2015 (UTC)

Suggestion to expand CS1 maint: Extra text to editor fields[edit]

Have you considered expanding Category:CS1 maint: Extra text to identify when some form of "ed." is in an |editor= field? For an example, see Template:Animal Burnie. GoingBatty (talk) 02:15, 8 August 2015 (UTC)

May also be worth looking in the |author= fields to track when the wrong field has been used for editors. Keith D (talk) 11:11, 8 August 2015 (UTC)

(edit conflict)

Yes, but not enough to figure out how to do it. The addition of editor descriptor text is quite common in author parameters; I've found quite a lot of them while trolling through Category:Pages containing cite templates with deprecated parameters.
The other 'extra' text in your example is the ampersand:
|editor=David Burnie & Don E. Wilson (eds)
singular parameter name, multiple editors. There is a whole iceberg there in both |author= and |editor= parameters.
cs1|2 give conflicting instruction to editors. On the one hand they are instructed to leave out extraneous text but on the other hand to add extra text; |credits= and |others= come to mind. It is the purpose of the templates to add standardized text to the rendering and pass the names to the metadata. It is very difficult to extract single names from a list of multiple names when the list has no rules – it's the rules that make |vauthors= possible.
Yeak, ok, I'm done ranting ...
Trappist the monk (talk) 11:29, 8 August 2015 (UTC)

AWB or bot opportunity to fix 1000+ missing author errors[edit]

There are over 1,000 (around 1,200, I think) articles on towns in India that have citations with a |first= but no |last=. I have changed a few hundred of these from |first= to |publisher=, but my fingers are getting tired. If someone with AWB or some nice bot code wants to have a go at them, do a search for this:

insource:/\|first=Registrar General...Census Commissioner, India/

Here is a sample change.

If it would help to have a list of these article titles, let me know, and I'll compile one. – Jonesey95 (talk) 20:10, 9 August 2015 (UTC)

Note that since the most recent edit to the CS1 module, these citations with a |first= but no |last= no longer generate a missing author error. The example article you give no longer shows a missing author error if you look at the revision[4] immediately before your edit. The count of articles populating Category:CS1 errors: missing author or editor has dropped precipitously since the recent edit to the CS1 module, from almost 9000 articles to a current count of roughly 1300. Stamptrader (talk) 00:22, 10 August 2015 (UTC)
Fixed in the sandbox. See Missing author without error message
Trappist the monk (talk) 00:28, 10 August 2015 (UTC)
True, but these are definitely errors, and they are all of the same type, so a script or bot should be able to fix them quickly and easily. – Jonesey95 (talk) 03:34, 10 August 2015 (UTC)

vancouver errors[edit]

From AKAP12 this cite:

{{cite journal | vauthors = Lin F, Wang Hy, Malbon CC | title = Gravin-mediated formation of signaling complexes in beta 2-adrenergic receptor desensitization and resensitization | journal = J. Biol. Chem. | volume = 275 | issue = 25 | pages = 19025–34 | year = 2000 | pmid = 10858453 | doi = 10.1074/jbc.275.25.19025 }}
Lin F, Wang H, Malbon CC (2000). "Gravin-mediated formation of signaling complexes in beta 2-adrenergic receptor desensitization and resensitization". J. Biol. Chem. 275 (25): 19025–34. doi:10.1074/jbc.275.25.19025. PMID 10858453.  Vancouver style error (help)

The error occurs because the second author includes a lowercase initial. The author's name, according to the doi link is Hsien-yu Wang.

According to Citing Medicine: The NLM Style Guide for Authors, Editors, and Publishers surnames are listed first followed by one or two uppercase initials. In this case, because the author is Asian, Hsien-yu is the surname and Wang the given name. Has PubMed got it wrong?

What advice should be given at Vancouver style error to editors who encounter this sort of error?

Trappist the monk (talk) 15:37, 10 August 2015 (UTC)

Few editors follow this page. You might to better to ask at the humanities reference desk about how asian authors shorten their name when using the Roman alphabet. Then there is the additional problem of how journals that use Vancouver style shorten the names of asian authors, which could be different. Jc3s5h (talk) 16:19, 10 August 2015 (UTC)

@Trappist the monk: It's also unlikely that the order given is wrong. Chinese names in the form Foo-bar are usually given names, so a Western source would be likely to call this person Hsien-yu Wang, who would be Wang Hsien-yu at home, and the proper family-name-first version in the Western bibliographic style is Wang, Hsien-yu. The "Foo-bar" convention is not universal, and the same name will often be rendered "Foo-Bar", and sometimes "Foo Bar" or even "Foobar", depending on how sources treat Chinese names in latin script. I encounter this issue a lot in cue sports writing, since China fields many players of pool, snooker, and carom billiards. "Foo-bar" seems to be something of a spreading convention, but it may vary geographically (you have Taiwan, Hong Kong, Macau, and Singapore to factor in, plus Chinese diaspora in the US, etc., and it's highly unlikely they're all converging on exactly the same format). Anyway, the point being you can get away with "Wang HY".  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  17:05, 10 August 2015 (UTC)

Even western authors with hyphenated names should sometimes have the second part of the name included in the initials. And sometimes the correct initials really do include lower-case letters. I have a Belgian co-author named Jean-Claude who insists that the correct abbreviation of his name is J.-Cl. On the other hand I know a Japanese author named Ken-ichi who wants his name abbreviated K. rather than K.-I. or K.-i. My general feeling is that any attempt to automatically deduce how to rearrange human names is doomed to at least occasional failure (as usual, see "Falsehoods Programmers Believe About Names") so it is essential that there be some workaround that we can use when the machines get it wrong. In this case, "Hy" is the correct Vancouver initialization and there should be some way of persuading the template to allow it. —David Eppstein (talk) 17:21, 10 August 2015 (UTC)
Agreed. – S.McC.
PS: I wasn't meaning to imply "do the wrong thing to make the template happy", but rather that since the name is a transliteration anyway, in a style that's not used consistently, that it might not matter in this case. There are Europeans who abbreviate names like Christophe as "Ch.", so my lackadaisicalness on this wouldn't help them.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  17:37, 10 August 2015 (UTC)
The rules for Vancouver system author name lists prohibit hyphens in the given name initials, see: Given names containing punctuation, a prefix, a preposition, or particle. The error mentioned at the start of this conversation is not the result of an attempt to automatically deduce how to rearrange [a] human name, but arises because Module:Citation/CS1 cannot know if the lowercase 'y' is intentionally lowercase (cases like this or as the result of Romanization: Θ → Th) or a typo. The error can be suppressed after review by treating the name as an institutional name: |vauthors=Lin F, ((Wang Hy)), Malbon CC
Trappist the monk (talk) 15:13, 14 August 2015 (UTC)

DOI throwing an error[edit]

Disregard: PEBCAK!

The DOI found here is not accepted by the DOI checking code called by {{Cite journal}}.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  16:54, 10 August 2015 (UTC)

(Edit conflict: Trappist, you accidentally removed my earlier comment.)
Looks ok to me: Pérez-García, Alejandro; Romero, Diego; Fernández-Ortuño, Dolores; López-Ruiz, Francisco; De Vicente, Antonio; Torés, Juan A. (2009). "The powdery mildew fungus Podosphaera fusca (synonym Podosphaera xanthii), a constant threat to cucurbits". Molecular Plant Pathology 10 (2): 153–160. doi:10.1111/j.1364-3703.2008.00527.x.  Maybe you're incorrectly including the period that pubmed puts after it? —David Eppstein (talk) 17:04, 10 August 2015 (UTC)
Not intentionally.
Trappist the monk (talk) 17:10, 10 August 2015 (UTC)
Don't include the terminal period that PubMed includes:
"Title". Journal. doi:10.1111/j.1364-3703.2008.00527.x. Check |doi= value (help). 
The doi checking code looks for a terminal comma or period. If one of those is found, the code emits the error message. Was the help text insufficient to the task?
Trappist the monk (talk) 17:06, 10 August 2015 (UTC)
@David: Ah, yeah, that would be it. Derp.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  17:07, 10 August 2015 (UTC)
@Trappist: Yeah, it says "Check |doi= value (help)", and I looked at the help but somehow did not see "does not end with punctuation". Total PEBCAK on my part. Time for coffee.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  17:30, 10 August 2015 (UTC)

Suppress original URL[edit]

Discussion moved here for a somewhat broader audience.

When urls die for whatever reason, normal practice is to keep the url and if possible, add |archive-url= and |archive-date=. Doing so links |title= to the archive copy and links static text provided by the template to the original url.

It has been suggested that we adopt a mechanism to suppress the original url when it is not dead in the sense of 404 or gateway errors and the like, but dead in the sense that the url has been taken over by someone and is now a link farm or advertising or phishing or porn or other generally inappropriate content.

To accomplish this I have suggested modifying the code that handles |dead-url=. This parameter takes a limited set of defined keywords (yes, true, y, no) and adjusts the rendered output accordingly. We could add another keyword that would render the static text in the same way as |dead-url=yes except that this value would not link the static text with the original url.

The question is: What should this defined keyword be? These have been suggested: hide, nolink, origspam, originalspam, spam, advert, phishing, fraud, unfit, usurped.

Is any of these the best keyword? Is there another keyword that would be better?

Trappist the monk (talk) 15:05, 12 August 2015 (UTC)

Commenters are encouraged to read through the original thread also. --Izno (talk) 15:32, 12 August 2015 (UTC)
I suggest topic-changed. This covers complete takeover by an undesireable publisher, but also covers the case of the original publisher no longer having a page that supports the material in the article. For example, software publisher X had a page about a quirk of version 99 of their software, which Wikipedia described with a citation to the relevant X webpage. Once version 100 of the software is released, X removes the relevant webpage and does not provide information about the quirk anywhere on their site. Jc3s5h (talk) 15:43, 12 August 2015 (UTC)
The purpose of |dead-url= is to indicate for pages which are still live that they can be accessed (when an archive url is also present) (for the case of the original publisher). So from this point of view, adding an archiveurl solves that "broader" issue. Even in the case where an archiveurl cannot be identified and subsequently provided, you can set deadurl to yes and still have that case covered. --Izno (talk) 16:06, 12 August 2015 (UTC)
I don't see any benefit in having citations provide links to dead URLs. However, if other people do, then I suggest simply |dead-url=nolink to describe the function, with an update to the template documentation describing when it is appropriate (or not) to not provide the link to a dead URL. Thanks! GoingBatty (talk) 19:01, 12 August 2015 (UTC)
The benefit I see to providing links to dead URLs (not necessarily clickable) is that the editor who marked the URL as dead might not have the knowledge to find a substitute at a related web page, but a later editor might have that knowledge; the dead URL serves as a clue for finding a substitute. Jc3s5h (talk) 19:18, 12 August 2015 (UTC)
@Jc3s5h: I agree that a later editor may be able to use the dead URL to find a substitute web page, and the archiveurl does not necessarily contain the original URL. I'm all for keeping the dead URL in the citation template for this purpose. However, I suggest that the citation only provide one link for the reader when the original URL is dead. Thanks! GoingBatty (talk) 02:38, 13 August 2015 (UTC)
What about adding a few more keywords, say:
  • usurped for domains now operated by a different entity (covers advertising, linkfarm, fraud, spam, phishing, or site/content unrelated to original)
  • purged for domains operated by original entity but for which the original website content has been deleted
  • abandoned for domains that are no longer registered
The latter may not as desirable as the first two, as domain registrations can fluctuate. Mindmatrix 21:53, 12 August 2015 (UTC)
Multiple keywords are possible. For the purposes of this conversation, I don't think abandoned domains need to be hidden because such domains are the definition of dead. I see no reason to hide links like that.
Trappist the monk (talk) 10:22, 13 August 2015 (UTC)

Since it has gotten quiet here I have implemented |dead-url=usurped to suppress the link to the original url:

Cite news compare
{{ cite news | dead-url=usurped | last=Frankel | date=June 9, 2003 | first=Daniel | publisher=Video Business | title=''Artisan pulls the repackaged Hip Hop Witch'' | archivedate=24 October 2006 | archiveurl=https://web.archive.org/web/20061024013933/http://www1.videobusiness.com/article/CA616459.html | url=http://www.videobusiness.com/article/CA616459.html | accessdate=29 March 2009 }}
Live Frankel, Daniel (June 9, 2003). "Artisan pulls the repackaged Hip Hop Witch". Video Business. Archived from the original on 24 October 2006. Retrieved 29 March 2009. 
Sandbox Frankel, Daniel (June 9, 2003). "Artisan pulls the repackaged Hip Hop Witch". Video Business. Archived from the original on 24 October 2006. Retrieved 29 March 2009. 

And here are tests to show that |dead-url=no and |dead-url=yes still works as they should:

{{cite web/new |title=Title |url=//example.com |archive-url=//example.org |archive-date=2015-08-14 |dead-url=no}}
"Title". Archived from the original on 2015-08-14. 
{{cite web/new |title=Title |url=//example.com |archive-url=//example.org |archive-date=2015-08-14 |dead-url=yes}}
"Title". Archived from the original on 2015-08-14. 

Trappist the monk (talk) 16:39, 14 August 2015 (UTC)

The documentation of the parameter value should make the intent of |dead-url=usurped clear (in accordance with the discussion above). Other than that, looks good. --Izno (talk) 16:54, 14 August 2015 (UTC)
Looks good. Mindmatrix 15:09, 16 August 2015 (UTC)
The more I think about the keyword usurped, the less I like it. The term certainly fits for those cases where a domain name has been usurped but does it fit for all other cases where it is prudent to suppress the original url? I'm not sure, so rather than use a keyword that may have limited specificity, I think we should switch to a more general keyword, perhaps unfit, which would covers a broader variety of reasons for suppression of the original url.
Trappist the monk (talk) 19:26, 17 August 2015 (UTC)
At the risk of boring all of you, I will re-express my view that the parameter value should express the function, not the reason (as I said in the previous discussion linked above, and as GoingBatty said above. I like "hide" or "nolink".
TL:DR; version: The value of |display-editors=, for example, is either a number (to show a given number of editors) or "etal" (to show "et al." without listing all of the editors in the citation template. We don't dictate why an editor should use a specific value, we just show how to get the display you want, assuming that editors will make a good choice (a bad assumption, I know, but you have to start by treating people like competent adults). There are many reasons why someone might want to suppress a link to the original URL: it is a porn site, the site has been sold, the page has been moved or archived, the editor wants a consistent citation style, or other reasons I can't think of. We can list some of them in the documentation, but assuming only one reason for hiding the URL paints us into a corner. – Jonesey95 (talk) 19:42, 17 August 2015 (UTC)
I was hoping you wouldn't re-iterate your opinion so I wouldn't have to reiterate mine. To wit: The problem I have with function over purpose is that function enables behavior that may not be desirable. For example, I can't think of any reason other than a link being a "bad" link to be correct to hide. And my feeling is that the suitable keyword should reflect the reason. This allows us to trivially say "yes, you have used this as intended". I want in fact to preempt other reasons for usage without associated keywords, because I do not want "oh, the site is dead" simply to cause the link to be suppressed (as I am sure there is at least one person who would be wont to do so). See above illustrative discussion on that point. --Izno (talk) 21:59, 17 August 2015 (UTC)
In the cases of |dead-url=hide or |dead-url=nolink or similar, we create a mechanism that doesn't explain to editors of a later age why the action was taken. With |display-editors=etal, |mode=cs2 it's pretty easy to determine why the parameter was set the way it was set and that it is, or is not, set properly. Setting |dead-url=usurped or |dead-url=unfit gives follow-on editors some indication why the original url is suppressed. Like Editor Izno, I can think of no real reason why an original url should be suppressed unless it leads to inappropriate content. As I indicated before, we can have a variety of keywords to use as reasons should experience dictate a need.
Trappist the monk (talk) 13:08, 18 August 2015 (UTC)

Supported keywords are now unfit and usurped (also shows that auto |format=PDF works correctly when original url is suppressed):

{{cite webnew |title=Title |url=//example.com |archive-url=//example.org |archive-date=2015-08-14 |dead-url=unfit}}
"Title" (PDF). Archived from the original on 2015-08-14. 
{{cite webnew |title=Title |url=//example.com |archive-url=//example.org |archive-date=2015-08-14 |dead-url=usurped}}
"Title" (PDF). Archived from the original on 2015-08-14. 

Trappist the monk (talk) 16:45, 24 August 2015 (UTC)

How to cite letter in CS1?[edit]

I would like to cite the letter found here. The hard copy of the letter appears to be held by the National Archives and Records Administration (NARA) in a box titled "HSCA Segregated CIA Collection, Box 19", and they appear to refer to the letter as "NARA Record Number: 1993.08.02.09:31:14:370053". If I use {{cite letter}}, then...

{{cite letter |first=Sturgis |last=Frank |recipient=Gene Wilson |subject=Pre-freedom of information request notice of charges |date=May 7, 1976 |url=http://www.maryferrell.org/showDoc.html?docId=76999 |accessdate=August 11, 2015}}

...gives me...

Frank, Sturgis (May 7, 1976). "Pre-freedom of information request notice of charges" (Letter to Gene Wilson). Retrieved August 11, 2015. 

Unfortunately, with the above template I don't believe I am able to note additional information about where this original document may be found, such as the |id= noted above. Is there something similar in CS1 that I can use? If so, what is the equivalent of |recipient= in CS1? Also, should |title= be "Letter from Frank Sturgis to Gene Wilson" or the subject noted by the author, and NARA, as "Pre-freedom of information request notice of charges"? Sorry for so many questions. Thanks! - Location (talk) 20:29, 12 August 2015 (UTC)

Try:
{{cite letter |first=Sturgis |last=Frank |recipient=Gene Wilson |subject=Pre-freedom of information request notice of charges |date=May 7, 1976 |url=http://www.maryferrell.org/showDoc.html?docId=76999 |accessdate=August 11, 2015 |via= National Archives and Records Administration (HSCA Segregated CIA Collection, Box 19) |id= NARA Record Number 1993.08.02.09:31:14:370053 }}
which gives:
Frank, Sturgis (May 7, 1976). "Pre-freedom of information request notice of charges" (Letter to Gene Wilson). NARA Record Number 1993.08.02.09:31:14:370053. Retrieved August 11, 2015 – via National Archives and Records Administration (HSCA Segregated CIA Collection, Box 19). 
I just added |id= to the template, and |via= was already there. Imzadi 1979  20:51, 12 August 2015 (UTC)
Are you citing the hard copy? Have you actually seen the hard copy? If not, and you are citing the copy at the Mary Ferrell Foundation website, then the direct cs1 equivalent to {{cite letter}} would be {{cite web}} (WP:SAYWHEREYOUGOTIT applies). It should be noted that {{cite letter}} is a meta-template of {{cite news}}. Such a citation might look like this:
{{cite web |last=Sturgis |first=Frank |title=Pre-freedom of information request notice of charges |type=Letter to Gene Wilson |website=Mary Ferrell Foundation |date=May 7, 1976 |url=http://www.maryferrell.org/showDoc.html?docId=76999 |accessdate=August 11, 2015}}
Sturgis, Frank (May 7, 1976). "Pre-freedom of information request notice of charges". Mary Ferrell Foundation (Letter to Gene Wilson). Retrieved August 11, 2015. 
In your example, |last= and |first= are swapped; the writer's name if 'Frank Sturgis'.
Trappist the monk (talk) 21:01, 12 August 2015 (UTC)
Imzadi1979, Trappist the monk: Thanks for the feedback! - Location (talk) 22:49, 13 August 2015 (UTC)

I think the advice to use {{cite web}} instead of a more specific citation type for a source found on the web rather than through hardcopy is wrongheaded. When we find books online through Google books, we should use {{cite book}}, not {{cite web}}. When we find academic journal articles online at their official publisher's online repository, we should use {{cite journal}}, not {{cite web}}, even for journals that have no print edition and are only online. And for the same reason, if we are viewing a facsimile of a written letter, we should still use {{cite letter}}. —David Eppstein (talk) 23:51, 13 August 2015 (UTC)

Yes, this is why the |url= parameter is not confined to {{cite web}} but is included in all the others. --Redrose64 (talk) 12:12, 14 August 2015 (UTC)

|script-chapter=[edit]

Following up on this conversation, I've added |script-chapter=. Styling and order of rendered chapter parts follows the same rules as |script-title=:

{{cite book/new |title=Tōkyō tawā |script-title=ja:東京タワー |trans-title=Tokyo Tower}}
Tōkyō tawā 東京タワー [Tokyo Tower]. 

Here are those same parameter values moved to their chapter equivalents:

{{cite book/new |title=Title |chapter=Tōkyō tawā |script-chapter=ja:東京タワー |trans-chapter=Tokyo Tower}}
"Tōkyō tawā" 東京タワー [Tokyo Tower]. Title. 

and with a link:

{{cite book/new |title=Title |chapter=Tōkyō tawā |script-chapter=ja:東京タワー |trans-chapter=Tokyo Tower |chapter-url=//example.com}}
"Tōkyō tawā" 東京タワー [Tokyo Tower]. Title. 

I wonder if the |script-chapter= value should be quoted when rendered especially in the case where the template also has |script-title= without |title=:

{{cite book/new |script-title=ja:東京タワー |script-chapter=ja:東京タワー}}
東京タワー. 東京タワー. 

Still to do: include |script-chapter=value in the metadata; support |script-title= and |script-chapter= in {{cite encyclopedia}} and {{cite episode}}.

Trappist the monk (talk) 11:37, 15 August 2015 (UTC)

Metadata support added, {{cite episode}} code tweaked which resolves this issue, and {{cite encyclopedia}} code tweaked which resolves this issue.
Trappist the monk (talk) 12:50, 15 August 2015 (UTC)

time to abandon protocol relative urls for the predefined identifiers?[edit]

There is a move afoot to replace http:// and relative protocol (//) with https: for certain urls in article space and in |url= in citations. These replacements mostly involve Google, YouTube, and Internet Archive. In September 2013, Module:Citation/CS1 converted all of the identifier urls that could be converted to relative protocol. That was a time when logged-in users used https: but users who weren't logged in used http:. Since then, Wikimedia has migrated everyone to using https:. Part of the reason for the module's switch to protocol relative urls was to prevent switching back and forth from secure (at Wikipedia) to not-secure (the identifier's site).

It appears that all but two of the predefined identifiers supported by the module and that use external links can be accessed using https:. The two that cannot be accessed are bibcode and LCCN. Here is a list of the identifiers with the various flavors of url:

Is there any need to continue to support protocol relative urls for these identifiers?

Trappist the monk (talk) 22:41, 15 August 2015 (UTC)

If everyone is using https, then protocol-relative links would use https also. Why change // to https://? It seems like another source of potential typos and errors. – Jonesey95 (talk) 00:34, 16 August 2015 (UTC)
Then for bibcode and lccn, we make sure that all links are explicitly http: - since the rest are all working in each available method, we leave these links alone. --Redrose64 (talk) 08:04, 16 August 2015 (UTC)
You can't be here (on Wikipedia) without your browser supports an https: connection. If the identifier sites support an https: connection (and all do except bibcode and LCCN) then there is no need for us to support the protocol relative scheme. For identifiers, editors don't have to type a url so I'm not clear on how this change would be a source of typos and errors. Can you expand on that?
Trappist the monk (talk) 12:45, 17 August 2015 (UTC)
So the "https:" would be added by the module only for the identifiers linked above? In that case, I'm fine with that. The first sentence of this section made it sound like we were going to go around replacing "//" with "https:", which sounded unnecessary and potentially harmful.
Again, though, if it's not currently broken, I don't see why we should fix it. If it is broken in some way that I do not understand, I'll go along with it. – Jonesey95 (talk) 14:47, 17 August 2015 (UTC)
One conversation about changing http: to https: is here. We change lots of stuff that isn't 'broken' for a variety of reasons. This is just another of those.
Trappist the monk (talk) 15:13, 17 August 2015 (UTC)

urls in |title=[edit]

Per this discussion, this discussion, and this discucssion, I have added a test that finds external wikilinks within the content of |title=. I expect to add calls to this same test for |chapter= and |website=. Templates that fail the test are added to Category:CS1 errors: external links

{{cite book/new |title=[//example.com Title]}}
Title.  External link in |title= (help)
{{cite book/new |title=[http://example.com Title]}}
Title.  External link in |title= (help)

External wikilink with leading text:

{{cite book/new |title=Leading text [http://example.com Title]}}
Leading text Title.  External link in |title= (help)

External wikilink with trailing text:

{{cite book/new |title=[http://example.com Title] trailing text}}
Title trailing text.  External link in |title= (help)

External wikilink with leading and trailing text:

{{cite book/new |title=Leading text [http://example.com Title] trailing text}}
Leading text Title trailing text.  External link in |title= (help)

The external wikilink must be protocol relative or have valid scheme (uses much the same test as is newly implemented for url tests):

{{cite book/new |title=[8http://example.com Title]}}
[8http://example.com Title]. 

The external wikilink must be complete:

{{cite book/new |title=[http://example.com Title}}
[http://example.com Title. 
{{cite book/new |title=http://example.com Title]}}
http://example.com Title]. 

The limitations of the test as just described mean that it does not answer the challenge posed here. I chose a vague error message so that should we decide to change the test to find urls, not just external wikilinks, in parameter values, we can do so without needing to change messaging and categorization.

Trappist the monk (talk) 22:27, 19 August 2015 (UTC)

An external link on the whole title can obviously be replaced by |url=, but this change is going to prevent editors from making external links on only part of a title. I don't know of a valid use case for doing that, but maybe there is one. Before making this change, is there any way to search for the citations that already have links on part of but not the whole title, so that we can judge whether any of them are appropriate? —David Eppstein (talk) 22:31, 19 August 2015 (UTC)
This search string should answer: insource:/\| *title *=[^\|\}]*http/ but it doesn't. The regex works in AWB but is not working for me as an insource: search. This search string: insource:/\| *title *=[\|\}]*http/ at least returns |title=http...
The reason for this test is that external links (as external links, not plain text) in |title= corrupt the metadata. This is why we have |url=.
Trappist the monk (talk) 23:09, 19 August 2015 (UTC)
Sure, but I'm primarily concerned about being able to generate a correct rendering of all valid citations, and only secondarily concerned about generating proper metadata for them. So if this change prevents us from formatting valid citations that happen to include external links in only part of the title, then it's a bad thing, even if it also constrains the citations in such a way as to make it easier to generate valid metadata. In this particular case, it seems likely enough that there are no valid citations that we'd be breaking, but I'm not certain of that, and you haven't convinced me that you have any evidence of that either. So running a search that would find them would be helpful, if we could get such a search to work. —David Eppstein (talk) 23:18, 19 August 2015 (UTC)
Perhaps it is working, sort of. insource:/\| *title *=[^\|\}]*http/ finds four results (it should find a lot more). The regex means:
Find a pipe, zero or more spaces, the string 'title', zero or more spaces, an equal sign, zero or more characters that are not a pipe or closing curly brace, and the string 'http'.
That means it should find |title=http.... It didn't, but it did find these (none of which are cs1|2):
| title = [http://www.google.com/patents/US2615129 Synchro-Cyclotron]
|title=Jamaica by-election (April 13, 2005): Kingston West<ref>http://www.eoj.com.jm/content-70-243.htm</ref>
|title = Surrey County Council election results, 2009, Guildford<ref>Sources: http://www1.surreycc.gov.uk/election2009/</ref>
|title=2014 Minnesota Legislature - House District 39A<ref>http://electionresults.sos.state.mn.us/Results/StateRepresentative/20?districtid=431</ref>
If we can presume that the search tool works well enough to find these where the url occurs after the beginning of |title= then that may mean that cs1|2 templates that have urls embedded midway or at the end of |title= do not exist.
That leaves us with urls that begin the |title=parameter value. For that, this search string:
insource:/\| *title *= *http/ (c. 290 hits)
This search string finds external wikilinks at the beginning of the |title= value:
insource:/\| *title *= *\[http/ (c. 150 hits)
These are the type of url-in-title that the test is currently configured to catch.
Trappist the monk (talk) 00:26, 20 August 2015 (UTC)
I generally support this error check. I believe that due to the uncertainty that exists in describing this situation, the failure of the insource search, and the wide variety of weirdness that editors put into citation templates, we should either hide this error message by default and/or have this check result in a maintenance message rather than a red error message. I think that we are going to see some false positives. I think that our credibility is diminished when we roll out code to all readers that shows errors for valid text like |edition=Illustrated, as we have recently done, and I think this particular check has a high likelihood of doing that.
One note about the terminology used in this discussion section: I believe that on WP, "wikilink" means a link to an article within WP, while "external link" means a link (generally a URL) that leads outside of WP. See Help:Link#Wikilinks and Help:Link#External_links. I do not think that the phrase "external wikilink" used above has a valid meaning on WP. Let's be clear in our use of language. – Jonesey95 (talk) 04:41, 20 August 2015 (UTC)
If that's all this check dug up, I'm happy enough with this new restriction. I don't think any of those are good uses of external links in titles. BTW, re the above comment: I was assuming that "external link" meant single-bracketed links and that "wikilink" meant double-bracketed links. The double-bracketed kind usually stay within WP but not always; for instance, it's possible to use double-bracket syntax for doi or arXiv links. —David Eppstein (talk) 04:56, 20 August 2015 (UTC)
I've looked at about 50 of the c. 150 pages returned by the insource:/\| *title *= *\[http/ search. Of those, I found three where the |title= value was more than just an external wikilink:
{{cite web|last=Flexible Plug and Play website |title=[http://www.flexibleplugandplay.co.uk/ Flexible Plug and Play]''accessed 18 October 2012}}
Flexible Plug and Play website. "Flexible Plug and Playaccessed 18 October 2012". 
{{cite web | last =FamilySearch.org | first = | coauthors = | title = [https://familysearch.org/pal:/MM9.1.1/K42Z-L65 1940 US Census] and [https://familysearch.org/pal:/MM9.1.1/KYFC-72S United States Public Records Index] | publisher =FamilySearch.org | | url = |accessdate = 12 March 2014 }}
FamilySearch.org. "1940 US Census and United States Public Records Index". FamilySearch.org. 
{{cite press release |title=[http://www.letu.edu/_Other-Resources/presidents_office/about.html] LeTourneau University Names New President |publisher=LeTourneau University |date=2007-03-08 |url=http://www.letu.edu/opencms/opencms/_Other-Resources/presidents_office/news/presAnnouncement.html |accessdate=2007-08-09}}
"[http://www.letu.edu/_Other-Resources/presidents_office/about.html] LeTourneau University Names New President" (Press release). LeTourneau University. 2007-03-08. Retrieved 2007-08-09. 
In each of the cases above, the templates are clearly malformed or misused.
I chose to use the term 'external wikilink' because the code is looking for urls formatted with wiki markup: opening square bracket, url, optional link-label text, closing square bracket. I used this term to distinguish that form of url from a plain url or external link (one without the wiki markup).
I did consider maintenance rather than errors but chose error because:
  • url-in-title corrupts the metadata
  • url-in-title can trigger access-date-requires-url errors
  • for {{cite web}} url-in-title triggers missing-or-empty-url errors
  • for other templates, url-in-title can trigger format-requires-url errors
  • automatic pdf format annotation doesn't work when the url is part of title
If the insource search results are to be believed, there aren't enough url-in-title errors to warrant hiding them.
Trappist the monk (talk) 12:54, 20 August 2015 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── WP:VPT is your friend:

insource:title insource:http insource:/\| *title *=[^\|\}]*http/

That search string first finds pages with the strings 'title' and 'http' and then does the regex search on those pages. However, more results aren't necessarily better results. In the first page of results, these:

{{cite web | url= | title=http://www.edmonton.ca/city_government/documents/Callaghan_NASP_Consolidation.pdf Neighbourhood Area Structure Plan (Office Consolidation) | publisher=City of Edmonton | date=March 2011 | accessdate=2012-06-08}}
"http://www.edmonton.ca/city_government/documents/Callaghan_NASP_Consolidation.pdf Neighbourhood Area Structure Plan (Office Consolidation)". City of Edmonton. March 2011. 
{{cite web|title=The Beverly clock|type=Abstract|journal= [[European Journal of Physics]]|publisher=IOPscience|title=http://iopscience.iop.org/0143-0807/5/4/002}}
"http://iopscience.iop.org/0143-0807/5/4/002". European Journal of Physics (Abstract). IOPscience. 

clearly, both malformed. But, the search also finds stuff like this:

<ref>[http://stljazznotes.blogspot.com/2014/07/bull-of-heaven-performing-at-lnac-this.html|title=St. Louis Jazz Notes: Bull of Heaven performing at LNAC this Saturday, August 2]</ref><ref>[http://news.allaboutjazz.com/jazz-this-week-st-louis-cabaret-festival-bull-of-heaven-all-that-tap-xxiii-and-more.php|title=Jazz This Week: St. Louis Cabaret Festival, Bull of Heaven, "All That Tap Xxiii," and More]</ref>

which is also clearly broken but outside the cs1|2 remit.

Trappist the monk (talk) 13:37, 20 August 2015 (UTC)

I have added code that also checks |chapter= and |work=:

{{cite book/new |title=Title |chapter=[//example.com Chapter]}}
"Chapter". Title.  External link in |chapter= (help)
{{cite journal/new |title=Title |journal=[//example.com Journal]}}
"Title". Journal.  External link in |work= (help)

The test can handle all three in the same template:

{{cite encyclopedia/new |title=Title |article=[//example.com Article] |encyclopedia=[//example.com Encyclopedia]}}
"Article". Title. Encyclopedia.  External link in |chapter=, |title=, |work= (help)

The error message lists the 'prime' (for lack of a better term) alias. Is there some way to mark the prime alias in an error message that tells readers that the message for this parameter may be aliased? For instance, |work= could be |newspaper=, |journal=, |encyclopedia=, ... We might tweak the error message so that it reads:

External link in |<work>=
External link in <|work=>
External link in |work=
External link in |work=

Other, better ideas?

Trappist the monk (talk) 22:16, 20 August 2015 (UTC)

when both original and archive urls are dead[edit]

This conversation at WP:Help desk is perhaps vaguely related to this discussion about suppressing the original url. In that discussion is this cs1 template:

{{cite web| url=http://www.planning.org/thenewplanner/nonmember/default1.htm |title=The New Planner: Drowning Office Park Rescued by Students During High Tide | accessdate=2006-11-01 |archiveurl = http://web.archive.org/web/20060714232619/http://www.planning.org/thenewplanner/nonmember/default1.htm <!-- Bot retrieved archive --> |archivedate = 2006-07-14}}
"The New Planner: Drowning Office Park Rescued by Students During High Tide". Archived from the original on 2006-07-14. Retrieved 2006-11-01. 

Neither the original url nor the archive url work. To me this seems a case of 'find-another-source-to-cite'. Until that other source can be located, is there something that cs1|2 can/should do to indicate to readers that both urls are dead? Is this even in the cs1|2 remit?

Trappist the monk (talk) 20:25, 21 August 2015 (UTC)

To me, archived copies of web sources are similar to, but not the same as, courtesy links to online copies of books. If we assume the underlying source is (or was) reliable when it was consulted, then there is a bit of a presumption that it is still reliable going forward. The archived copy makes otherwise inaccessible sources accessible again, much like a Google Books-hosted copy of a rare book. If that same Google Books link stopped working, it could be removed without changing the fact that the underlying source, the rare book, was used to source the cited information.
In other words, if it were just me, and I discovered that an archived copy no longer worked, I'd remove or comment out |archive-url= and |archive-date= and add a {{dead link}} tag to the citation. This would notify editors that we would want a new archive of the original source, if possible. We'd still be free to locate replacement sources to cite, just as we'd be free to attempt to find other books that are more accessible than rare books housed in only a few select libraries. Because our sources need to be accessible to someone somehow someway, we allow citation of very rare sources, and we'd eventually want a dead online source to be resurrected or replaced. I hope my thought processes make some sense. Imzadi 1979  03:15, 22 August 2015 (UTC)

Why is the archive URL not working? Sometimes it's a temporary issue with IA and it works again a few days later. In several cases, inspecting the edit history revealed a rogue edit had added or removed a character from the URL rendering it non-functional. -79.74.108.165 (talk) 23:31, 22 August 2015 (UTC)

IA says "Page cannot be crawled or displayed due to robots.txt." It could be that planning.org added their robots.txt page after the archiveurl was added to the citation. GoingBatty (talk) 18:43, 23 August 2015 (UTC)

ISBN error category[edit]

So that it is consistent with the naming convention of other identifier error categories, and while it is mostly empty, I've changed the ISBN error category name from Category:Pages with ISBN errors‎ to Category:CS1 errors: ISBN in Module:Citation/CS1/Configuration/sandbox.

After the next module update, I think that the old category Pages with ISBN errors ‎can go away.

Trappist the monk (talk) 16:34, 22 August 2015 (UTC)

Support. It helps distinguish it from Category:Articles with invalid ISBNs as well. – Jonesey95 (talk) 10:14, 23 August 2015 (UTC)

url-wikilink conflict error category and error message change[edit]

To shorten and make it more consistent with other error categories, in Module:Citation/CS1/Configuration/sandbox I have changed the Category:Pages with citations having wikilinks embedded in URL titles to Category:CS1 errors: URL–wikilink conflict. Because of this change I have also changed the error message to reflect the category name: 'Wikilink embedded in URL title' to 'URL–wikilink conflict'.

Trappist the monk (talk) 17:10, 22 August 2015 (UTC)

I support the two criteria listed, but I think that both the old and the new names are confusing to readers. I will try to come up with a proposal for one that meets the criteria: short, consistent, clear. I hope we don't have to settle for two out of three. (And a pedantic note: as I read the "In compounds when the connection might..." section of MOS:DASH, that should be an en dash, not a hyphen. Let's not pick that fight with pedants like me.)
If these category name changes stick, we'll need to update the math on the CS1 errors category page and check for links to the old category names. – Jonesey95 (talk) 10:10, 23 August 2015 (UTC)
I concur and have changed the sandbox to use ndashes. {{category redirect}} for hyphenated versions is appropriate.
Internal–external link conflict? Clash? Collision?
Trappist the monk (talk) 10:37, 23 August 2015 (UTC)
"URL overrides wikilink"? "Duplicate links"? "Redundant links"? "External link and wikilink?" I like the last two better than the first two ("duplicate links" makes it sound like they are identical). – Jonesey95 (talk) 11:04, 23 August 2015 (UTC)

error handling for |trans-title= and |trans-chapter=[edit]

In Module:Citation/CS1/Configuration, there are two nearly identical entries in the error_conditions table for |trans-title= and |trans-chapter= missing their original language counterparts. I have tweaked the code in Module:Citation/CS1/sandbox and Module:Citation/CS1/Configuration/sandbox to combine these two error handlers. Examples:

  • "Chapter". Title. 
  • [Trans Chapter] |trans-chapter= requires |chapter= (help). Title. 
  • "Chapter". [Trans Title] |trans-title= requires |title= (help). 
  • [Trans Chapter] |trans-chapter= requires |chapter= (help). [Trans Title] |trans-title= requires |title= (help). 
  • "Chapter" [Trans Chapter]. Title [Trans Title]. 

Similarly, in Help:CS1 errors the help text for these two errors is nearly identical. When we make the next update to the live module, the help text for trans-chapter should be merged into the help text for trans-title (trans-title has the common anchor for the error message help link).

The two error messages shared Category:Pages with citations using translated terms without the original. That category name changes to Category:CS1 errors: translated title.

Trappist the monk (talk) 21:50, 22 August 2015 (UTC)

Yet another example of two levels of title within a journal publication[edit]

The following reference is a paper, part of a conference proceedings that was published as an issue of a journal (whose name indicates that it regularly publishes proceedings in this way, but with a combined volume and issue numbering system that looks much more like a journal than like a book series). The following formatting produces a citation that looks correct but with what I believe to be incorrect metadata. Is there a way to get the metadata right, too, or is this the best I can do?

{{cite journal | last = Charatonik | first = Janusz J. | title = Selected problems in continuum theory | url = http://topology.auburn.edu/tp/reprints/v27/tp27107.pdf | issue = 1 | journal = Topology Proceedings | mr = 2048922 | pages = 51–78 | department = Proceedings of the Spring Topology and Dynamical Systems Conference | volume = 27 | year = 2003}}

produces

Charatonik, Janusz J. (2003). "Selected problems in continuum theory" (PDF). Proceedings of the Spring Topology and Dynamical Systems Conference. Topology Proceedings 27 (1): 51–78. MR 2048922. 

David Eppstein (talk) 01:41, 25 August 2015 (UTC)

Because there is no COinS record assigned to |department=, 'Proceedings of the Spring Topology and Dynamical Systems Conference' is not included in the metadata. Rewriting this cite to use {{cite conference}} isn't much better:
{{cite conference | last = Charatonik | first = Janusz J. | title = Selected problems in continuum theory | url = http://topology.auburn.edu/tp/reprints/v27/tp27107.pdf | issue = 1 | journal = Topology Proceedings | mr = 2048922 | pages = 51–78 | booktitle= Proceedings of the Spring Topology and Dynamical Systems Conference | volume = 27 | year = 2003}}
In this case, 'Topology Proceedings' is left out which isn't any better and is probably worse, because the journal title is common to the two volumes published each year.
Trappist the monk (talk) 10:38, 25 August 2015 (UTC)
Use of |contribution/chapter= seems more suitable, but – oops! – red messages:
~ J. Johnson (JJ) (talk) 20:55, 26 August 2015 (UTC)
Yes, that would be my preference, if it worked. But it doesn't, {{cite journal}}/|department= does, and it appears from Trappist's message above that it doesn't even produce bogus metadata. So that's what I'll be using for now. —David Eppstein (talk) 20:11, 29 August 2015 (UTC)
On one hand, I would be happy for any reasonable work around. On the other hand, COinS is not the only kind of metadata here. The names of parameters also carry information regarding the nature of the data encoded. E.g., |journal= implies the source is journal (specfically, an academic journal), which is different from a newspaper or a book. Likewise, |department= is defined at Cite journal#Periodical as "Title of a regular department, column, or section within the periodical or journal", and has specific effects on the resulting formatting. To use these parameters for other purposes is a form of metadata corruption. And (as has been previously commented) eventually leads to some unsuspecting editor attempting to "correct" what looks like an error. ~ J. Johnson (JJ) (talk) 22:18, 30 August 2015 (UTC)

|translator=[edit]

For a very long time editors have been asking for |translator= in some form or other. For a very long time the answer has been |others=. While I have been hacking away at the |coauthors= problem in Category:Pages containing cite templates with deprecated parameters I have become somewhat sympathetic to that request. So, here it is, these new parameters:

|translator=
|translatorn=
|translator-first=
|translator-last=
|translator-link=
|translator-mask=
|translator-firstn=
|translator-lastn=

And an example:

{{cite book/new |chapter=Works and Days |title=English Translations: From Ancient and Modern Poems |volume=2 |chapter-url=https://books.google.com/books?id=mHNHAQAAMAAJ&pg=PA745 |page=745 |last=[[Hesiod]] |translator-first=Thomas |translator-last=Cooke |translator-link=Thomas Cooke (author) |date=1810 |publisher=N. Blandford}}
Hesiod (1810). "Works and Days". English Translations: From Ancient and Modern Poems 2. Translated by Cooke, Thomas. N. Blandford. 745. 

Relatively little is new as the translator-name-list makes use of existing author- and editor-name-list code. Currently, there is no support for et al. and no support for Vancouver styling.

Right now, |others= is appended to |translator= and the two rendered in the same place as |others=. This may not be the correct placement. There have been suggestions that |translator= belongs with |author=. What say you? Also, keep? Discard? What about punctuation? Static text?

Trappist the monk (talk) 17:36, 25 August 2015 (UTC)

This is a good addition to the module. It will be welcomed by many editors. Here's how it looks with |others=:
{{cite book/new |chapter=Works and Days |title=English Translations: From Ancient and Modern Poems |volume=2 |chapter-url=https://books.google.com/books?id=mHNHAQAAMAAJ&pg=PA745 |page=745 |last=[[Hesiod]] |translator-first=Thomas |translator-last=Cooke |translator-link=Thomas Cooke (author) |date=1810 |publisher=N. Blandford|others=Illustrated by Jane Doe}}
Hesiod (1810). "Works and Days". English Translations: From Ancient and Modern Poems 2. Translated by Cooke, Thomas. Illustrated by Jane Doe. N. Blandford. 745. 
That looks right to me. As for the fixed text "Translated by", I like it. Our guidance in the documentation for CS1 templates has contained only this recommended form since October 2012, as far as I can tell. – Jonesey95 (talk) 18:17, 25 August 2015 (UTC)
The ball on naming of parameters with numbers hasn't been resolved yet, so I would expect to see the number-in-the-middle variants also. --Izno (talk) 21:40, 25 August 2015 (UTC)
I don't think consistency requires us to introduce number-in-the-middle variants of new parameters, just because some of our old and entrenched parameters already have them. I'd prefer to see only one version of the new parameters rather than trying to duplicate all the variants of the old parameters. —David Eppstein (talk) 17:29, 27 August 2015 (UTC)

────────────────────────────────────────────────────────────────────────────────────────────────────

  • Hesiod (1810). "Works and Days". In Smith, Edward. English Translations: From Ancient and Modern Poems 2. Translated by Cooke, Thomas. Illustrated by Jane Doe. N. Blandford. 745. 

I wondered how the above would work in with an editor. Are the translator and the illustrator meant to be volume wide and not related to the chapter?

Translator is one option but another is "Reviewed by" which is used by the ODNB, another is "Illustrated by". So rather than having a specific type why not have other parameters with a "other string" it could default to ("translated by") but be set to another word such as "Reviewed" or "Illustrated" etc. or set to "none" if other is a mixture of more than one type (translated by some, and illustrated by others), and instead of |translator-firstn= have |other-firstn= etc. -- PBS (talk) 16:52, 27 August 2015 (UTC)

Good, as long as these also work:
|translatorn-first=
|translatorn-last=
Discussions above do not indicate a consensus in favor of this role-lastn order, with multiple editors objecting to it as counter-intuitive.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  02:16, 29 August 2015 (UTC)

Time of day field[edit]

I would like to propose that we add an optional field to Template:Cite web (and by extension also to Template:Cite tweet) for the hours and minutes of the day, perhaps also time zone.

This data is sometimes available in things, and where it is, I think it would be a good thing to add it.

This helps in cases where there is a dispute on how to organize things, who said what first, etc.

Sometimes you might want to cite 2 news articles about something made in the same day (or 2 tweets) and knowing that information could be useful for putting them into the correct order without requiring people to constantly go and check what the tweet said. This is also particularly useful if the tweet is taken down and wasn't archived. Ranze (talk) 22:02, 28 August 2015 (UTC)

If a tweet is taken down, and has not been archived anywhere, then it is not verifiable, and I would question its suitability as a source. If you feel it is useful to document the exact time some tweet or other information is posted/published, you can always add that following the template. I am not aware that a "time" field is necessary. ~ J. Johnson (JJ) (talk) 22:47, 28 August 2015 (UTC)
I would think that in the rare instance where it was necessary to discuss the time various sources were published, it would be necessary to describe the times in the body of the article rather than leaving it to the footnotes. Jc3s5h (talk) 00:09, 29 August 2015 (UTC)