Help talk:Citation Style 1

From Wikipedia, the free encyclopedia
  (Redirected from Template talk:Cite podcast)
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.
 

Update to the live CS1 module weekend of 11–12 October 2014[edit]

Over the 11–12 October 2014 weekend I propose to update:

Module:Citation/CS1 to match Module:Citation/CS1/sandbox (diff)
Module:Citation/CS1/Configuration to match Module:Citation/CS1/Configuration/sandbox (diff)
Module:Citation/CS1/Whitelist to match Module:Citation/CS1/Whitelist/sandbox (diff)
Module:Citation/CS1/Date validation to match Module:Citation/CS1/Date validation/sandbox (diff)

This update changes these things:

in Module:Citation/CS1:

  1. Bug fix in get_coins_pages(); (discussion)
  2. Bug fix in extractnames(); (discussion)
  3. Change lccn() to require lower case alpha characters; (discussion)
  4. Change openlibrary() to emit error message when OL identifier contains leading alpha characters; (discussion)
  5. Change |language= support (discussion):
    1. get ISO639-1 language name from Wikimedia;
    2. Add support for right-to-left languages using new parameter |script-title=; (discussion) and (discussion)
    3. Categorize pages when |language=language name;
  6. Change listpeople() so that we don't link to the current page through |authorlinkn= or |editorlinkn=; (discussion)
  7. Add code to strip wikimarkup (italics and bold) from titles and chapters when adding those to COinS metadata; (discussion)
  8. Add Australia, Brazil, Mexico to list of countries supported by |asn-tld=; (discussion)
  9. Undo peculiar title and chapter format swap when |work= or any of its aliases set; (discussion)
  10. Categories:
    1. Add support for maintenance categories; discussion
    2. Change amazon() to add maintenance category when |asin= value is an isbn; discussion
    3. Add support for properties categories; (discussion)

in Module:Citation/CS1/Configuration:

  1. Updated JFM and ZBL prefixes; (discussion)
  2. deleted ISO639-1 table; (discussion)
  3. Changed error categories for doi and ol errors (discussion)
  4. Make date errors visible; (discussion)

in Module:Citation/CS1/Whitelist:

  1. add new parameter |script-title= (discussion) and (discussion)

in Module:Citation/CS1/Date validation:

  1. Add support for valid date formats Summer yyyy–yy and Summer yyyy–yyyy; (discussion)

There is enough here that there is a deal of documentaion to be done. I think that I'll begin that and not bother to hide it prior to the live update – it's just easier that way.

Trappist the monk (talk) 16:18, 30 September 2014 (UTC)

I think this update will also re-enable the missing author/editor errors. And wasn't there something about creating an error when |chapter= exists when there is no |title= or |work=? (See "I have removed the tests for" above.) – Jonesey95 (talk) 16:52, 30 September 2014 (UTC)
Missing author/editor is the extractnames() bug (#2); |chapter= is Undo peculiar title ... (#9).
Trappist the monk (talk) 17:25, 30 September 2014 (UTC)

Done.

Trappist the monk (talk) 14:20, 11 October 2014 (UTC)

script-title[edit]

Could the value of |script-title= not be underlined? Kanguole 17:51, 30 September 2014 (UTC)

Agree. The proper name mark is a Chinese convention that would not apply to other writing systems such as Hebrew or Arabic. --  Gadget850 talk 18:12, 30 September 2014 (UTC)
and an obsolete Chinese convention at that. But these are conventions for Chinese running text, which isn't the situation here. Kanguole 20:26, 30 September 2014 (UTC)
Looks like that was removed.
  • {{cite book/new |title=ABC |script-title=ar:العربية}}
ABC العربية. 

Documentation:

script-title: Title in the original writing system where it is not appropriate to italicize (e.g. Arabic, Chinese, Hebrew, Japanese). Displays after title in upright font and is isolated from the surrounding text-direction settings so that right-to-left scripts render properly. The language may be set by prefixing the value with the ISO 639-1 two-character language code followed by a colon. Unrecognized codes are ignored and will display in the rendered citation. Example: |script-title=ar:العربية.

--  Gadget850 talk 18:05, 1 October 2014 (UTC)

I'd suggest using Chinese or Japanese as the example language, as those are the two for which CMOS recommends also including the original form. Kanguole 20:50, 1 October 2014 (UTC)
Sample? --  Gadget850 talk 12:56, 2 October 2014 (UTC)
  • Wang, Li (1985). Hànyǔ Yǔyīn Shǐ 汉语语音史 [History of Chinese Phonetics] (in Chinese). Beijing: China Social Sciences Press. ISBN 978-7-100-05390-7. 
  • Morohashi, Tetsuji (1984–1986). Dai Kan-Wa Jiten 大漢和辞典 [Comprehensive Chinese–Japanese Dictionary]. Tokyo: Taishukan. 
Kanguole 00:45, 19 October 2014 (UTC)
Arabic is a good example because it is both non-Latin and rtl, and because support for rtl is a substantial reason for the existence of |script-title=.
Trappist the monk (talk) 13:15, 2 October 2014 (UTC)
Arabic is an unfortunate example, because it's one of the languages that CMOS recommends be transliterated, whereas Chinese and Japanese are the languages where it recommends using the original form in addition to romanization. Kanguole 00:45, 19 October 2014 (UTC)

Error checking[edit]

Unrecognized codes are not ignored:

  • {{cite book/new |title=ABC |script-title=zz:العربية}}
ABC zz:العربية. 

More than two characters or other than alpha characters do show the language code. --  Gadget850 talk 14:25, 2 October 2014 (UTC)

Thanks for that. Fixed.
Trappist the monk (talk) 14:38, 2 October 2014 (UTC)

Related discussions[edit]

See Template talk:Lang#Rtl-lang in citation titles. --  Gadget850 talk 12:49, 3 October 2014 (UTC)

Titles of journal articles[edit]

Titles of journal articles used to be in roman, wrapped in double quotes, as in {{cite journal}}:

  • {{cite journal | author = Author | year = 2000 | title = Article title | journal = Journal | ref = none }}
  • Author (2000). "Article title". Journal. 

but now in {{citation}} they're in italics:

  • {{citation | author = Author | year = 2000 | title = Article title | journal = Journal | ref = none }}
  • Author (2000), "Article title", Journal 

However {{cite journal}} still does it the old way. Kanguole 00:56, 19 October 2014 (UTC)

It does seem to have changed, yes. This might be the same issue as Template talk:Citation#Formatting of journal article_title. --Redrose64 (talk) 08:39, 19 October 2014 (UTC)
Oversight on my part when I undid the peculiar title formatting. Fixed in the sandbox so that now if the using {{citation}} with one of the |work= aliases then |title= is upright and quoted.
Author (2000), "Article title", Journal 
Trappist the monk (talk) 10:07, 19 October 2014 (UTC)
@Trappist the monk: {{citation}} is still wrong:
  • {{citation |last1=Jones |first1=P. |date=2014 |title=Some interesting paper |journal=Journal of Interesting Papers }} → Jones, P. (2014), "Some interesting paper", Journal of Interesting Papers 
whereas it did produce and should produce: Jones, P. (2014), "Some interesting paper", Journal of Interesting Papers. Peter coxhead (talk) 11:40, 2 November 2014 (UTC)
As I wrote before, it is fixed in the sandbox:
Jones, P. (2014), "Some interesting paper", Journal of Interesting Papers 
The live module will get the fix at the next update.
Trappist the monk (talk) 11:48, 2 November 2014 (UTC)

Time to retire Category:Pages using citations with old-style implicit et al.?[edit]

Category:Pages using citations with old-style implicit et al. is down to about 160 articles, from well over 10,000 last year. I believe that once the remaining articles are fixed, there is no further need for this error category or for the error message that goes along with it.

The category, as I understand it, was intended as a maintenance category to hold citations that had ambiguous uses of exactly nine authors. Once the category is empty, all future citations with exactly nine authors should display all nine of the authors unless editors use |display-authors=.

Can the citation module sandbox be modified before the next code sync to reflect these changes? I will clear out the remaining 160 articles before the sync happens. – Jonesey95 (talk) 02:18, 16 November 2014 (UTC)

Perhaps convert to a maintenance category instead? If we do that, the module can fill it with pages that have citations using |display-authors= where the value is the same as the number of |author= parameters. A bot or script can then troll that category and delete extraneous |display-authors=.
Trappist the monk (talk) 14:37, 16 November 2014 (UTC)
I disagree "et al" is useful and should be placed in the coauthors parameter. -- PBS (talk) 15:31, 16 November 2014 (UTC)
A new maint category would be fine with me. It could look for citations where the value of |display-authors= is greater than or equal to the number of displayed authors. A citation with nine authors and |display-authors=29 should be placed in the maint category along with an identical citation with |display-authors=9.
PBS, can you please explain what you mean, preferably with example citations? I can't make sense of your comment as written. – Jonesey95 (talk) 16:03, 16 November 2014 (UTC)
If coauthors is used then the Harvard templates link to the long citation,[1]{{sfn|Smith|2001|p=2}} they do not if display_author is used.[2][3]{{sfn|Beta|2002|p=3}}{{sfn|Beta|Gamma|Delta|2002|p=4}} Adding display_author to the {{harv}} templates is one solution but every change like this makes it more and more complicated and more of a hurdle for beginners (even for beginners with a programming background which will be a minority) to use the citation templates. As you will know if you lurk around WT:CITE there is a lot of resistance to using citation templates and making the interface more complicated does not help encourage their take up. As you will see there is a "et al" default for the harv of 4 last names no matter how many are in the list.[4] {{sfn|Gamma |Delta |Epsilon |Zeta |2003 |p=5}} it would seem sensible to me to default display_author to four so that the short and long citations defaulted to the same number.
{{reflist}}
* Alpha, Fred; et al (2001), A title  
* Beta, Fred et al. (2002), B title 
* Gamma, Fred; Delta; Epsilon; Zeta; Eta (2003), C title 
* {{citation |first=Fred |last=Smith |year=2001 |coauthors=et al |title=A title}}
* {{citation |first=Fred |last=Beta |last2=Gamma |last3=Delta |last5=Eta |display-authors=1 |year=2002 |title=B title}}
* {{citation |first=Fred |last1=Gamma |last2=Delta |last3=Epsilon |last4=Zeta |last5=Eta |year=2003 |title=C title}}
-- PBS (talk) 17:22, 16 November 2014 (UTC)
Just for clarity, the harv link to {{citation |first=Fred |last=Beta |last2=Gamma |last3=Delta |display-authors=1 |year=2002 |title=B title}} is not broken because |display-authors=1. It is broken because {{sfn|Beta|2002|p=3}} is incomplete. Figuring out how to better do harv referencing is a topic for another discussion. This discussion is about what to do with the error category and message.
@Jonesey95, you're right: categorize when number of authors is less than or equal to |display-authors=<value>.
Trappist the monk (talk) 18:11, 16 November 2014 (UTC)

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

Cite book compare
{{ cite book | author7=Author7 | author4=Author4 | author8=Author8 | author6=Author6 | author9=Author9 | title=Title | author1=Author1 | author5=Author5 | author2=Author2 | author3=Author3 }}
Live Author1; Author2; Author3; Author4; Author5; Author6; Author7; Author8; Author9. Title. 
Sandbox Author1; Author2; Author3; Author4; Author5; Author6; Author7; Author8; Author9. Title. 
Cite book compare
{{ cite book | author7=Author7 | author4=Author4 | author8=Author8 | author6=Author6 | author9=Author9 | display-authors=8 | title=Title | author1=Author1 | author5=Author5 | author2=Author2 | author3=Author3 }}
Live Author1; Author2; Author3; Author4; Author5; Author6; Author7; Author8 et al. Title. 
Sandbox Author1; Author2; Author3; Author4; Author5; Author6; Author7; Author8 et al. Title. 
Cite book compare
{{ cite book | author7=Author7 | author4=Author4 | author8=Author8 | author6=Author6 | author9=Author9 | display-authors=9 | title=Title | author1=Author1 | author5=Author5 | author2=Author2 | author3=Author3 }}
Live Author1; Author2; Author3; Author4; Author5; Author6; Author7; Author8; Author9. Title. 
Sandbox Author1; Author2; Author3; Author4; Author5; Author6; Author7; Author8; Author9. Title. 
Cite book compare
{{ cite book | author7=Author7 | author4=Author4 | author8=Author8 | author6=Author6 | author9=Author9 | display-authors=10 | title=Title | author1=Author1 | author5=Author5 | author2=Author2 | author3=Author3 }}
Live Author1; Author2; Author3; Author4; Author5; Author6; Author7; Author8; Author9. Title. 
Sandbox Author1; Author2; Author3; Author4; Author5; Author6; Author7; Author8; Author9. Title. 


No more error messages. Categorize in Category:CS1 maint: display-authors.

Trappist the monk (talk) 19:37, 16 November 2014 (UTC)

As of my time stamp, Category:Pages using citations with old-style implicit et al. is empty except for a few archived pages that do not need to be modified. The category is ready to go away after the module updates are applied this weekend. A million thanks to Citation Bot for doing the lion's share of work in cleaning up this category. It always has a few little bugs, but it does vast amounts of tedious work that improves the encyclopedia. – Jonesey95 (talk) 05:42, 27 November 2014 (UTC)

What about a work title?[edit]

[Edit: I mean in {{cite web}}. Didn’t realize the talk page redirects here.] If a webpage is a piece of a larger work, and that larger work does not define the website, does this template allow citing it?

Let’s say the website Example.com has a whole section titled The Fooiest Bars. We need to cite “Foobar #37: The Baz Biz.” How do we do that here? Do we just ignore the fact that it’s part of The Fooiest Bars? Or do we cite that title and ignore the individual entry’s title? —174.141.182.82 (talk) 16:35, 18 November 2014 (UTC)

Just so I can wrap my little brain around what it is that you're asking, can you give me real life example, please?
Trappist the monk (talk) 17:22, 18 November 2014 (UTC)
Here’s one. The site is IGN, and I’d say the title is “Rick Grimes - #26 Top Comic Book Heroes”, and the work title is “IGN’s Top 100 Comic Book Heroes”. —174.141.182.82 (talk) 18:58, 18 November 2014 (UTC)
Perhaps like this:
{{cite web |department=[http://www.ign.com/top/comic-book-heroes IGN's Top 100 Comic Book Heroes] |website=[[IGN]] |title=#26 – Rick Grimes |url=http://www.ign.com/top/comic-book-heroes/26 |accessdate=2014-11-18}}
"#26 – Rick Grimes". IGN's Top 100 Comic Book Heroes. IGN. Retrieved 2014-11-18. 
Trappist the monk (talk) 19:23, 18 November 2014 (UTC)
I would treat this the same way that we treat subtitles. |title=The Fooiest Bars: Foobar #37: The Baz Biz. There are plenty of {{cite web}} templates in articles with titles like this. Web sites often use the pipe (vertical bar) character, which you need to substitute with {{!}} or the equivalent HTML entity in |title=. – Jonesey95 (talk) 17:56, 18 November 2014 (UTC)
I concur with Jonesey95. And you don't have to use the same typographic style, you can replice a pipe or middot with a colon. --  Gadget850 talk 18:44, 18 November 2014 (UTC)

Update to the live CS1 module weekend of 29–30 November 2014[edit]

Over the weekend of 29–30 November 2014 I propose to update the live versions of:

Trappist the monk (talk) 19:39, 21 November 2014 (UTC)

Wow, that's a lot of work!
I looked through the above list a couple of times and did not see "add Category:CS1 maint: Date and year when a citation uses both |date= and |year=," per a discussion above, on this pageJonesey95 (talk) 01:02, 22 November 2014 (UTC)
Hey, wanted to leave a note that immediately following [1] "Synch from sandbox;", the page I was working on in my sandbox began throwing the error "Lua error in Module:Citation/CS1 at line 189: Argument map not defined for this variable." for each instance of cite web. -- Limulus (talk) 12:13, 29 November 2014 (UTC)
@Limulus, Trappist the monk: I got the same error with {{cite book}} and {{cite news}} while previewing some edits I was making to an article. However, by the time I saved the edits, the error message disappeared and proper citations appeared in the article as normal. Imzadi 1979  12:25, 29 November 2014 (UTC)
That sort of thing happens because there are four pages to update so for a short period of time there is a mix of old and new. If you find any articles with that error that aren't fixed by a null edit, let me know.
Trappist the monk (talk) 12:29, 29 November 2014 (UTC)
Thanks! I tried a null edit (just entered text in summary field) and that fixed the error. -- Limulus (talk) 12:48, 29 November 2014 (UTC)

Citation formatting RfC[edit]

FYI: Pointer to relevant discussion elsewhere.

Please see Talk:Aspromonte goat#RFC on citation formatting for an RfC about the scope of WP:CITEVAR and whether it can be used to prevent changes to underlying technical coding of reference citations, including correct XML, and changing problematic ref IDs.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  19:48, 21 November 2014 (UTC)

Additional archive URLs[edit]

I have been adding an additional archive URL to citations, to preserve references if an archive link goes dead (had this happen with an Internet Archive url, luckily it was a live website pre-emptively archived). The format I've been using is something like <ref>{{cite xxx|...}} {{webcite|...}}.</ref>, which ends up as something like "Archived from the original on 29 August 2014. Retrieved 13 October 2014. Archived 23 October 2014 at WebCite." I'm wondering if there is, or could be, a better way to do this? - Evad37 [talk] 02:20, 22 November 2014 (UTC)

Check {{Cite additional archived pages}}. --  Gadget850 talk 02:32, 22 November 2014 (UTC)

Circa[edit]

RE: "Supports c. only with a single year value (no ranges or day/month combinations)," it would be helpful if this could be adjusted. There are legitimate times when "c. 1999-2000", for example, is the most accurate thing one can say. --Tenebrae (talk) 22:37, 22 November 2014 (UTC)

Real life example of where it's important to use such a date? Where neither c. 1999 or c. 2000 are suitable?
Trappist the monk (talk) 13:59, 23 November 2014 (UTC)

The quotation marks are part of the bibliographic entry for the work, not of the title of or link to the work[edit]

   This talk contrib applies to {{cite web}}, and (i presume) many other templates within the scope of this talk page.
   The topic may well have previously been talked to completion somewhere in the consolidated talk archive, for all i know.

   I was forced, by a violation of our nested-quotation-marks guideline, to notice that the quotations marks around some suitable works are

  1. supplied by the templates and
  2. inside the "click to display linked-content" zone of the external link.

That is, the link to the text of "The Night Before Christmas" underlines, and converts from black to blue, not just the four words and the blanks separating them, but also the quotation marks around those.
   Now, it's not necessarily the case that anyone's semantic analysis has any bearing at all on what our style should be for the relationship between web pages and the links to them. But for me, that's the best guide, so here's my opinion:

   The name of the poem consists of four words separated by spaces, and does not include any punctuation. The quotation marks we place around that name, in a variety of situations, are not part of its name, but rather clarifying marks placed adjacent to the name in those situations, to for instance help distinguish short formats (e.g. essay, or typical-length "poem", or article, or track within an optical-disk sound recording, or speech within a play) from long ones (e.g. book, magazine, optical-disk embodying multiple sound recordings, or play). When a title appears on a physical realization of the work -- on the cover of a book, above the poem, on the CD, and AFAIK at the top of the Web page that presents or, often, comments on on the work (except where titles like
Review of "The Night Before Christmas"
are chosen) -- neither quotes nor italics are used. And orally, very little if any distinction is made, that would correspond to quotes or italics.
   (For names of works that deserve italics, of course, the format-cue is inseparable from the letters, and there's no choice to be made in the relationship between the format-cue and the spatial boundary of the click-to-display-linked-content zone.)
   My suggestion is that that zone should extend only as far as the title itself does, and exclude the quotation marks, which are about the relationship between the title and the context (prose reference, bibliographic entry, etc.) within which the name is being used. It's a fine distinction, but IMO not an expensive one to shift to, and one that remedies a slight undercutting of semantic clarity.

--Jerzyt 09:23 & 09:41, 23 November 2014 (UTC)

The quote marks do differ, depending on whether it is a wikilink or a URL:
Markup Renders as
{{cite journal |title=The Night Before Christmas |url=https://en.wikipedia.org/wiki/A_Visit_from_St._Nicholas}} 
"The Night Before Christmas". 
{{cite journal |title=[[The Night Before Christmas]]}} 
"The Night Before Christmas". 
--  Gadget850 talk 10:37, 23 November 2014 (UTC)


We are somewhat bound by the limitations imposed by Mediawiki. The wiki markup that Module:Citation/CS1 generates looks like this:
[https://en.wikipedia.org/wiki/A_Visit_from_St._Nicholas "The Night Before Christmas"]
which gives this:
"The Night Before Christmas"
If we move the enclosing quote marks like this:
"[https://en.wikipedia.org/wiki/A_Visit_from_St._Nicholas The Night Before Christmas]"
we get this:
→"The Night Before Christmas"
As you can see, the external link icon gets in the way. I don't know of a simple way to avoid that. I think that it is important to keep the icon. We could do this:
"[https://en.wikipedia.org/wiki/A_Visit_from_St._Nicholas The Night Before Christmas"]
we get this:
→"The Night Before Christmas"
which is halfway to what you want.
Trappist the monk (talk) 12:08, 23 November 2014 (UTC)

Check date values in date[edit]

It might have been months ago, or perhaps even a couple of years ago, when cite web and related templates started displaying date format errors like this:

Check date values in: date

But I am just now getting around to questioning why this check is necessary.

  • Could someone point to a talk page somewhere where the case was made for introducing that error message? I know about WP:DATESNO but there must be something more than that.

I imagine there's some benefit to it, so I have a follow-on question. Why does this

  • {{cite news|url=http://en.wikipedia.org/wiki/Wikipedia:Wikipedia_Signpost/Archives/2014-11-12| title= Wikipedia Signpost‎| publisher= Wikimedia Foundation|date= September 03, 2014 | agency= Associated Press |accessdate= 2014-11-23}}

product an error:

  • "Wikipedia Signpost‎". Wikimedia Foundation. Associated Press. September 03, 2014. Retrieved 2014-11-23.  Check date values in: |date= (help)

Surely Postel's robustness principle applies:

"implementations should follow a general principle of robustness: be conservative in what you do, be liberal in what you accept"

There is no obvious reason that the leading zero in "September 03" should be treated as an error.

72.244.200.236 (talk) 20:30, 23 November 2014 (UTC)

Since you read WP:DATESNO then you know that we don't use leading zeroes in this date format. Our style guidelines are based on current major published guidelines, which allows a leading zero here? --  Gadget850 talk 20:49, 23 November 2014 (UTC)
Postel's principle does not apply because he was writing about input to a computer program, which need not be aesthetically pleasing or readily comprehended by people. Although values of template parameters are used by computer programs, they also are read by editors, so should conform to norms for human-readable text. Jc3s5h (talk) 21:01, 23 November 2014 (UTC)
Perhaps it started here. To answer that, we implemented date validation in Module:Citation/CS1 and later in Module:Citation/CS1/Date validation. The beginning of that discussion is here. Rather than invent a CS1-specific standard for date formats, we adopted WP:DATESNO and try to adhere to it because that is a standard that the community have agreed amongst themselves. At present, WP:DATESNO allows leading zero dates only in year initial numeric format. If you believe that leading zeros should be acceptable in other date formats, the proper venue for that discussion is WT:MOSDATE.
Trappist the monk (talk) 21:09, 23 November 2014 (UTC)
Thanks to all for the replies. Trappist points to places I can read more about why we are where we are. It sounds like the consensus is its better to prioritize style over an unambiguously-formatted date. When I am filling in the parameters of cite web/cite news I am cutting the date from a web page and pasting into the article. Marking such a date as an error makes adding ref details a bit more tedious than it needs to be. In a bizarre way, rejecting dates on style guidelines can encourage editors to not bother cut/pasting _any_ date at all. By following Postel's principle both editors and readers would benefit. 72.244.200.236 (talk) 21:33, 23 November 2014 (UTC)
P.S. Maybe the ideal solution is to allow editors to supply ref dates in any unambiguous format they want, but rendering the article for readers based on settings specified by templates like {{Use dmy dates}} and WP:SKIN 72.244.200.236 (talk) 21:54, 23 November 2014 (UTC)
Lets consider two other guidelines:
  • MOS:DATEUNIFY: "Publication dates in an article's citations should all use the same format."
  • WP:CITEVAR: "Editors should not attempt to change an article's established citation style merely on the grounds of personal preference, to make it match other articles, or without first seeking consensus for the change."
Thus, when you add a new reference you need to follow the established style and use it for all the publication dates. You also need to consider other style issues such as sentence case v. title case for titles.
The issue of automatic date formatting has a long history of discussion that resulted in the existing methods being removed as useless. There is currently no way to read {{Use dmy dates}} and apply it on the fly. {{Use dmy dates}} is for bots and follow on editors. --  Gadget850 talk 22:04, 23 November 2014 (UTC)

Updated Articles[edit]

For updated articles, for the date, do you put the date it was published or the date that the latest update happened? — Preceding unsigned comment added by Copulative (talkcontribs) 04:21, 26 November 2014 UTC

Put the date of the version of the article that you are citing in the |date= parameter in the citation. If you want to show that the article was originally published on an earlier date, you can use |origyear=. – Jonesey95 (talk) 04:26, 26 November 2014 (UTC)
Is there a way to put the original full date instead of just the year? — Preceding unsigned comment added by 166.137.242.122 (talkcontribs) 09:46, 26 November 2014 (UTC)
Yes. Put the original full date in |origyear=. It allows free-form text. See Template:Cite_web#Date for an explanation. – Jonesey95 (talk) 17:50, 26 November 2014 (UTC)

COinS: surname? first?[edit]

I notice in the COinS doc section it lists |surname#= as a set of parameters yet the author doc section does not list this as a valid alias. Also, while |last#= is listed as being used by COinS, |first#= is absent. Does COinS use the |first#= information? Jason Quinn (talk) 11:13, 27 November 2014 (UTC)

Yes, |first= is included in the COinS metadata. Thanks for pointing that out. I've fixed the documentation. As for |surname= and |given=, these two parameters are rarely used. I don't think that I've seen them in the wild so am much in favor of deprecating and removing them.
Trappist the monk (talk) 12:38, 27 November 2014 (UTC)
I don't think I recall coming across |surname= and |given= either during many thousands of cite template edits. Completely concur with deprecation and removal. Jason Quinn (talk) 13:47, 27 November 2014 (UTC)
I haven't seen many |surname= parameters in the wild, but they are out there. Search for insource:/\|\s*surname\s*=\s*[A-Z\d]/ using the beta search (soon to be the default search engine at WP). I get 267 hits from that search; YMMV, as I often get different results each time I use the beta search to search. I would consider that number a minimum. – Jonesey95 (talk) 15:38, 27 November 2014 (UTC)
So, while we're thinking about this, should we just go ahead and do the deed? Should also include |given= as well. I can do up an AWB script to scan through the search results and change |surname#= and |given#= to |last#= and |first#=. Changing the search string to insource:/\|\s*[Ss]urname\d?\s*=/ finds 306 pages. Change to Module:Citation/CS1/Whitelist/sandbox is just changing the value assigned to these parameters from true to false.
Trappist the monk (talk) 16:10, 27 November 2014 (UTC)
I did not document parameters with very low use. If figured they would wither and we would eventually discard them. --  Gadget850 talk 17:36, 27 November 2014 (UTC)
@Trappist the monk, Gadget850, Jonesey95: We could add entries to WP:AWB/RTP to change the parameters. I am also willing to enter a AWB request to update its list of valid cite web parameters. GoingBatty (talk) 02:01, 28 November 2014 (UTC)


Should we change author doc section to indicate a preference for the author[n] parameter synonym rather than the last[n] parameter when citing a corporate author?
Is it misleading to use the last[n] parameter if the author is from a culture that usually writes the family name first? Jc3s5h (talk) 17:12, 27 November 2014 (UTC)
There is no semantic difference between the parameters |author= and |last=. --  Gadget850 talk 17:36, 27 November 2014 (UTC)
Which reminds me, why do we still have both if they mean the same thing? It just confuses people and complicates software. We ought to be phasing one or the other out. LeadSongDog come howl! 18:14, 27 November 2014 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── While there is no semantic difference between |author= and |last=, there is a semantic difference between the words that they stand for, "author" and "last name of author". If we are going to use names for parameters that suggest the meaning of the parameter, the name should really suggest the meaning of the parameter. If not, lets use parameter names like "p74". Jc3s5h (talk) 18:28, 27 November 2014 (UTC) (edit conflict)

@Jc3s5h: Do you have a suggested wording for an author[n] preference?

I don't know that it's necessarily misleading. It might not render correctly if the family name is placed in |last= and the rest of the name placed in |first= because CS1 will render the two names with a comma separator:

Ban, Ki-moon. Title. 

One can use |author-name-separator=&#32;: (need to fix this to be |author-name-separator=none)

Ban Ki-moon. Title. 

but that only works when all names have that format. If we mix in western-style names, no comma where there should be one:

Ban Ki-moon; Smith Jack. Title. 

Still, we want to keep the ability to have separate last/first parameters so that we can provide clean COinS metadata. I'm beginning to wonder if we should have alternate authorname parameters that are equivalent to |last= and |first= that somehow inhibit placement of the author separator (usually the comma) for those parameters. I don't know what these parameters might be called nor do I have any idea how we might implement them.

@Gadget850: From the template and module viewpoint, you are correct. But, I think that humans make a distinction; last is last and only last, but author is the whole enchilada. And, I wonder if the module should also make that distinction when it's creating the metadata. Right now, when |last=Smith, John the author metadata look like this:

&rft.aulast=Smith%2C+John&rft.au=Smith%2C+John

compared to |last=Smith |first=John:

&rft.aufirst=John&rft.aulast=Smith&rft.au=Smith%2C+John

It seems that the former actually violates the COinS specification (see rtf.aulast). If it is in violation, then we should only create rft.aulast when |last1= (or any of its aliases) has a matching |first1=.

@LeadSongDog: I agree that |last= and |author= having the same definition is / can be confusing. I think that there is reason to more formally distinguish them from each other as humans do. —Trappist the monk (talk) 18:36, 27 November 2014 (UTC)

We should not make any more changes to the sandbox version of the module before the pending merge, which is supposed to happen in two or three days. – Jonesey95 (talk) 18:38, 27 November 2014 (UTC)
@Trappist the monk:, you asked "@Jc3s5h: Do you have a suggested wording for an author[n] preference?" I don't have an exact wording in mind. Since names of people from various parts of the world as well as corporate authors may already be in "author[n]" or last[n], any sort of bot correction of past entries is probably not feasible. I would prefer for last[n] to only apply to the family name or patronym of a person from a culture where that name is usually written last. The author[n] alias should be used for single word names of a human, corporate authors, and family full names of people from cultures who usually write the family name first. Jc3s5h (talk) 20:01, 27 November 2014 (UTC) modified 20:54 UT.
I would amend that last phrase as follows: "... and familyfull names of people from cultures who usually write the family name first." --Redrose64 (talk) 20:48, 27 November 2014 (UTC)
It's true that |first= and |last= are not particularly appropriate parameter names for names written surname-first, but I don't think that means they should be combined in one |author= parameter. We still want short citations consisting of Surname (year) for such names. Kanguole 21:27, 27 November 2014 (UTC)
Whatever they are called, I agree that we need separate parameters for the family/last name and the given/first name(s). Then there should be numbered parameters, say |nameN-separator=, which can be set to none independently, so that |last1=Ban |first1=Ki-Moon |name1-separator=none |last2=Smith |first2=Jack produces "Ban Ki-Moon; Smith, Jack". Peter coxhead (talk) 23:14, 27 November 2014 (UTC)
@Kanguole: You can do that. You would put {{cite book |author=Ban Ki-moon |year=2014 |title= (etc. etc.) |ref={{harvid|Ban|2014}} }} and then you can use {{harvnb|Ban|2014|p=123}} --Redrose64 (talk) 23:18, 27 November 2014 (UTC)
OK, but that's a roundabout fix. I don't think it gets "Ban" in rft.aulast and "Ki-Moon" in rft.aufirst either. This discussion seems to be conflating semantics and presentation. These authors have surnames and given names, and we want to treat their surnames in the same way as surnames of other authors, so it's natural to use the same parameter for the surname in both cases. In such cases it's confusing that it's called last, but a more meaningful alias like surname could be offered as well. Ditto for the given name. That is, I suggest that the solution is not to tweak the recommendation for |author=, but to merely retain |surname= and |given= as aliases, possibly with |nameN-separator= as above. Kanguole 23:58, 27 November 2014 (UTC)
Agreed. The |nameN-separator= idea is only for presentation. The semantics are paramount. Peter coxhead (talk) 10:15, 28 November 2014 (UTC)

Since |surname= is used in only 300ish of the 2.4ish million pages that use Module:Citation/CS1, it would seem that regardless of appropriateness, editors prefer |last=, |first=, and |author= to |surname= and |given=. With such an overwhelming preference, I think we should deprecate and remove |surname= and |given=. We need to investigate and implement some method that will solve the presentation problem. I will do that and report back.

Trappist the monk (talk) 15:47, 28 November 2014 (UTC)

Agree that removing given & surname would be a step forward. Those 300 pages could easily use |author= instead. A peek at Ban's viaf record is illuminating. With all the variations listed, there's not likely much point concerning ourselves about the order we present. We'd do better to focus our efforts on linking to an independent authoritaties database. This would also help article translation efforts to more readily identify the name form that will be recognized by the target language readers. LeadSongDog come howl! 19:21, 28 November 2014 (UTC)
The most important thing is to remove the recommendation, both here and at {{Citation Style documentation/author}}, to use |author=/|last= for some personal names. It's particularly incongruous to cite Chinese as an example, when standard practice at WP:CHINA is to use |last= for the surname and |first= for the given name (cf WP:MOSCHINA#Citations and WP:MOSKOREA#Citations; MOSJAPAN has no citation guidance, and WP:HUNGARY has no MoS). That way the short references work (and we get the right data in the COinS fields). Kanguole 22:03, 28 November 2014 (UTC)
Let me state the obvious: If the documentation for CS1 is inadequate, have a go at changing it so that it's correct.
Trappist the monk (talk) 23:03, 28 November 2014 (UTC)

I made a simple experiment in Module:Citation/CS1/sandbox that (mis)used |author-format=nosep to replace the default author-name-separator with a space. I chose |author-format= simply because it was convenient for the experiment. It was enough of an experiment to show that doing |last= and |first= without a separator shouldn't be that difficult. The experiment has been removed from the sandbox.

The question that arises from the experiment is: were we to implement some sort of mechanism to disable the author-name-separator for individual authors, what would the editor use to do that? Some possible answers:

  1. create |author-name-separatorn= which would specify author-name-separator for authorn and where |author-name-separatorn=none would use a space as the separator character
  2. create |author-name-separatorn=none which would replace the author-name-separator for authorn with a space; any value other than none is an error. |author-name-separator= (without the n) specifies the separator character for all author names if different from the default.
  3. Something else?

Presumably, it would be necessary to do the same for editor names.

And all of that, raises other questions: Why do we have |author-name-separator= and |editor-name-separator=? Is there a need to separate author first from last with a character that is different from the character used to separate editor first from last? Similarly, we have |author-separator=, |editor-separator=, and |name-separator=. |name-separator= is an alias of both |author-separator= and |editor-separator= but |author-separator= and |editor-separator= are not aliases of each other. Is there a reason to separate authors in the author-list with a character that is different from the character that separates the editors in the editor-list?

Trappist the monk (talk) 16:50, 14 December 2014 (UTC)

Indeed, disabling the comma separator for names usually written surname-first would require a parameter for each author and each editor, because one often gets a mix of such names. The but I think the motivation for current setup is that although it doesn't cover all those cases, it handles some more, e.g. it covers a case where the sole author has a Chinese name and the editors have English names, or vice versa. That is, it's a kludge; doing it properly requires two families of parameters.
That said, I don't think the ability to disable the name separator is that important. In works aimed at an audience familiar with Chinese names, the bibliography will have all names surname-first, with Chinese author names having no separator and Western ones having a comma. However works aimed at a more general audience will tend to use commas for all names, making the surname (which is also used in Harvard citations) clear to a reader unfamiliar with Chinese. I'd say Wikipedia should be more like the latter. Kanguole 14:49, 15 December 2014 (UTC)

Insering wikilinks from works[edit]

Many academic journals have WP articles about them. Can we enforce some minimal wiki-linking to them (as per Help:Citation_Style_1#Work_and_publisher): "If the work is notable and has an article in Wikipedia, it should be wiki-linked at first appearance in citations in the article." If desirable, could it be automated, with a bot? Thanks. Fgnievinski (talk) 19:24, 28 November 2014 (UTC)

What is Insering?
Whether to link or not to link the value in |journal= is a decision left entirely to the editors of the article where the citation template is used. CS1 does not require editors to link any parameters to articles within Wikipedia.
Trappist the monk (talk) 20:11, 28 November 2014 (UTC)
Agreed; it absolutely should not be automated. (I'd like to see where the consensus was developed for wiki-linking journal titles in citations. "It should be wiki-linked at first appearance in citations" doesn't make sense; another reference using the same journal may later be added earlier in the article or existing references using the same journal may later be re-ordered.) Peter coxhead (talk) 20:18, 28 November 2014 (UTC)
@Fgnievinski: what you are describing is how I link things now. However, as Template:Ul Peter coxhead notes, additional editing can reorder the footnotes, shuffling a new citation to be the first one that should have the link. (By the same token, additional editing can shuffle the text in the body of the article, changing what prose should have the wikilink.) That's why I don't worry about it until its an article that's substantially complete content-wise. Rather than have a bot handle the task, a user script that could shift the links for authors, works, and publishers to their first footnote appearance would be nice. There's a similar script that highlights duplicate wikilinks in body text. Imzadi 1979  21:39, 29 November 2014 (UTC)

"format= requires url=" error checking needs adjustment[edit]

After the latest changes to the targeting of the |url= parameter, it looks like the error-checking for the "format= requires url=" error may need some adjustment. Here's an example from Template:Citation/doc:

Citation compare
{{ citation | last=Sullivan | contribution-url=http://tf.nist.gov/timefreq/general/pdf/1485.pdf | first=D.B. | publisher=National Institute of Standards and Technology | title=2001 IEEE Int'l Frequency Control Symp. | format=PDF | year=2001 | contribution=Time and frequency measurement at NIST: The first 100 years }}
Old Sullivan, D.B. (2001), "Time and frequency measurement at NIST: The first 100 years" (PDF), 2001 IEEE Int'l Frequency Control Symp., National Institute of Standards and Technology, http://tf.nist.gov/timefreq/general/pdf/1485.pdf
Live Sullivan, D.B. (2001), "Time and frequency measurement at NIST: The first 100 years", 2001 IEEE Int'l Frequency Control Symp. (PDF), National Institute of Standards and Technology 


Whatever the "access-date= without url=" is doing seems to be working fine though. This is the above citation with |access-date= added.

Citation compare
{{ citation | last=Sullivan | contribution-url=http://tf.nist.gov/timefreq/general/pdf/1485.pdf | access-date=4 November 2014 | first=D.B. | publisher=National Institute of Standards and Technology | title=2001 IEEE Int'l Frequency Control Symp. | format=PDF | year=2001 | contribution=Time and frequency measurement at NIST: The first 100 years }}
Old Sullivan, D.B. (2001), "Time and frequency measurement at NIST: The first 100 years" (PDF), 2001 IEEE Int'l Frequency Control Symp., National Institute of Standards and Technology, http://tf.nist.gov/timefreq/general/pdf/1485.pdf, retrieved 4 November 2014
Live Sullivan, D.B. (2001), "Time and frequency measurement at NIST: The first 100 years", 2001 IEEE Int'l Frequency Control Symp. (PDF), National Institute of Standards and Technology, retrieved 4 November 2014 


I hope it's an easy fix. – Jonesey95 (talk) 19:02, 29 November 2014 (UTC)

It's not broken. There is no |url= so the error message is correct. Changing the citation to use |chapter-format=PDF removes the error message and places the annotation in the correct place:
Sullivan, D.B. (2001), "Time and frequency measurement at NIST: The first 100 years" (PDF), 2001 IEEE Int'l Frequency Control Symp., National Institute of Standards and Technology, retrieved 4 November 2014 
What is not quite right is the error message help text which needs a bit of a massage and we need to document |chapter-format=.
Trappist the monk (talk) 19:19, 29 November 2014 (UTC)
Also all the aliases of "chapter" need to work with "...-format". In the specific example from Template:Citation/doc it would be very odd to have to use |chapter-format= with |contribution=, but |contribution-format= doesn't work:
Sullivan, D.B. (2001), "Time and frequency measurement at NIST: The first 100 years", 2001 IEEE Int'l Frequency Control Symp., National Institute of Standards and Technology, retrieved 4 November 2014  Unknown parameter |contribution-format= ignored (help)
I commented out |format=PDF from the Template:Citation/doc example for the present until |contribution-format=PDF can be used. Peter coxhead (talk) 20:22, 29 November 2014 (UTC)
@Trappist the monk: I see that you removed my commenting out and put in |chapter-format=PDF – that is so, so ugly with |contribution= and |contribution-url=! Peter coxhead (talk) 20:54, 29 November 2014 (UTC)

New ASIN-checking code marks 10-digit ISBN ending in X as an error[edit]

The new ASIN-checking code appears to mark a 10-digit ASIN ending in "X" as an error instead of marking it as an ISBN. I have adjusted the sandbox code to allow ASINs to have 10-digit ISBNs ending in X.

Cite book compare
{{ cite book | title=Title | author=Author | asin=630580916X }}
Old Author. Title. ASIN 630580916X.
Live Author. Title. ASIN 630580916X Check |asin= value (help). 
Sandbox Author. Title. ASIN 630580916X. 


ASINs like this that are valid 10-digit ISBNs will be added to Category:CS1 maint: ASIN uses ISBN. Feel free to correct or improve upon my change to the sandbox if I did something wrong. – Jonesey95 (talk) 18:02, 30 November 2014 (UTC)

@Jonesey95: Should there be a visible error, to make it easier for editors to know which reference needs to be fixed? Thanks! GoingBatty (talk) 18:16, 30 November 2014 (UTC)
We have had complaints about the red error messages, especially when they highlight a condition that may or may not be an actual error. In this case, the ASIN/ISBN is fully functional, but it should be cleaned up to point to a neutral source instead of Amazon. I imagine that a bot or human running a script could take care of it pretty easily. That is the idea behind the maintenance categories.
I understand people's concerns about filling our pages with red error messages, especially for issues that are very minor. I am fully supportive of the error messages for actual errors like the ones that are currently displayed. – Jonesey95 (talk) 18:23, 30 November 2014 (UTC)
I have an AWB script that I periodically use to sweep Category:CS1 maint: ASIN uses ISBN which converts |asin= to |isbn=.
Trappist the monk (talk) 18:33, 30 November 2014 (UTC)
I'm pretty sure that I warned against marking X as an error... ah yes, right here at 07:05, 25 September 2014. --Redrose64 (talk) 19:07, 30 November 2014 (UTC)

New error in cite conference: "chapter= ignored"[edit]

I'm seeing a lot of "chapter= ignored" errors (and non-formatting of the conference paper title) in {{cite conference}} templates with a conference paper title in |title= and the title of the overall conference proceedings in |booktitle=. There are five of these in isolation lemma, for instance. An example:

Cite conference compare
{{ cite conference | ref=harv | url=http://portal.acm.org/citation.cfm?id=1429791.1429816 | isbn=978-3-540-85362-6 | date=2008 | booktitle=Proceedings of the 11th international workshop, APPROX 2008, and 12th international workshop, RANDOM 2008 on Approximation, Randomization and Combinatorial Optimization: Algorithms and Techniques | last2=Mukhopadhyay | first2=Partha | last1=Arvind | publisher=Springer-Verlag | first1=V. | title=Derandomizing the Isolation Lemma and Lower Bounds for Circuit Size | location=Boston, MA, USA | pages=276–289 | accessdate=2010-05-10 }}
Old Arvind, V.; Mukhopadhyay, Partha (2008). "Derandomizing the Isolation Lemma and Lower Bounds for Circuit Size". Proceedings of the 11th international workshop, APPROX 2008, and 12th international workshop, RANDOM 2008 on Approximation, Randomization and Combinatorial Optimization: Algorithms and Techniques. Boston, MA, USA: Springer-Verlag. pp. 276–289. ISBN 978-3-540-85362-6. http://portal.acm.org/citation.cfm?id=1429791.1429816. Retrieved 2010-05-10.
Live Arvind, V.; Mukhopadhyay, Partha (2008). "Proceedings of the 11th international workshop, APPROX 2008, and 12th international workshop, RANDOM 2008 on Approximation, Randomization and Combinatorial Optimization: Algorithms and Techniques". Boston, MA, USA: Springer-Verlag. pp. 276–289. ISBN 978-3-540-85362-6. Retrieved 2010-05-10.  |chapter= ignored (help)

Is this a new bug? And if so can we please get it fixed? —David Eppstein (talk) 20:56, 30 November 2014 (UTC)

It's a new error message, not necessarily a new bug. {{cite conference}} is problematic. Its name suggests that a 'conference' is being cited (what does that mean, exactly?) when it appears that most often, the editor is citing the published proceedings of that conference. A conference and its proceedings are, I think two difference beasts. I think that {{cite conference}} should only be used on those rare occasions when an editor has actually attended the conference, but then, such use is questionable because of verification issues. For these reasons I have suggested elsewhere, though not formally, that {{cite conference}} should be abandoned.
It appears that all of the citations at isolation lemma that display the chapter-ignored error message are actually citing the proceedings of a conference, not the conference itself. Because this example citation appears to be citing the proceedings of the conference, it (and the others at isolation lemma) might be rewritten to use {{cite book}} {{cite encyclopedia}}:
{{cite encyclopedia |last1=Arvind |first1=V. |last2=Mukhopadhyay |first2=Partha |chapter=Derandomizing the Isolation Lemma and Lower Bounds for Circuit Size |title=Proceedings of the 11th international workshop, APPROX 2008, and 12th international workshop, RANDOM 2008 on Approximation, Randomization and Combinatorial Optimization: Algorithms and Techniques |date=2008 |url=http://portal.acm.org/citation.cfm?id=1429791.1429816 |location=Berlin |publisher=Springer-Verlag |isbn=978-3-540-85362-6 |doi=10.1007/978-3-540-85363-3_23 |pages=276–289 |ref=harv}}
Arvind, V.; Mukhopadhyay, Partha (2008). "Derandomizing the Isolation Lemma and Lower Bounds for Circuit Size". Proceedings of the 11th international workshop, APPROX 2008, and 12th international workshop, RANDOM 2008 on Approximation, Randomization and Combinatorial Optimization: Algorithms and Techniques. Berlin: Springer-Verlag. pp. 276–289. doi:10.1007/978-3-540-85363-3_23. ISBN 978-3-540-85362-6. 
Trappist the monk (talk) 22:10, 30 November 2014 (UTC)

Yes, those citations might be coded better. Nevertheless, the comparison I included in my previous post clearly shows that it used to work ("Old") and now doesn't ("Live"). I have no idea how many of these there are out there but I suspect it's not a small number. Additionally, the "Examples" section of the cite conference documentation is exactly this, a paper in a proceedings, although for some reason that one doesn't seem to be broken — I think because they use |conference= instead of |title=. And the {{cite book}} explicitly says not to use cite book for edited collections (which most conference proceedings including this are). Can't we just get this to work? —David Eppstein (talk) 22:27, 30 November 2014 (UTC)

PS Two of the five problematic citations on isolation lemma really were miscoded, by Citation bot when it filled out some {{cite doi}} templates. It used {{cite journal}} for a conference paper, with |title= being the conference title and |chapter= being the paper title. I'm not going to try to argue that the bad rendering on these ones is a bug in the templates. But this sort of mess is one reason I personally prefer {{citation}}: if you don't have to figure out whether it's a conference or a book or a journal (and there are conference proceedings published as special issues of journals — how are they supposed to be coded) then there are fewer mistakes you can be making. —David Eppstein (talk) 22:41, 30 November 2014 (UTC)
I'm not sure why {{cite book}} says: For edited collections, use {{cite encyclopedia}}. So, I changed my example above to use {{cite encyclopedia}}. I also changed it to use |chapter-url= so that the cite links the paper's title rather than the proceedings title. Should have done that when I did the {{cite book}} version.
I believe that the the answer to Can't we just get this to work? is to abandon {{cite conference}} as we know it today. We could do this by redirecting to {{cite encyclopedia}}, deprecating the unique {{cite conference}} parameter combination of |booktitle= and |title= in favor of |title= and |chapter=. |location= has a peculiar meaning in {{cite conference}} where it identifies the place where the conference convened. That is problematic because it ends up in the citation's COinS metadata as the place of publication For this example, Boston, the location of the conference is identified as the place of publication when in reality, that place is Berlin.
The process would seem to be:
  1. redirect {{cite conference}} to {{cite encyclopedia}}
    here is your example citation unchanged except to use {{cite encyclopedia}}:
    Arvind, V.; Mukhopadhyay, Partha (2008). "Derandomizing the Isolation Lemma and Lower Bounds for Circuit Size". Proceedings of the 11th international workshop, APPROX 2008, and 12th international workshop, RANDOM 2008 on Approximation, Randomization and Combinatorial Optimization: Algorithms and Techniques. Boston, MA, USA: Springer-Verlag. pp. 276–289. ISBN 978-3-540-85362-6. Retrieved 2010-05-10. 
  2. write an AWB script that would:
    1. change |title= to |chapter=
    2. change |trans-title= to |trans-chapter=
    3. change |url= to |chapter-url=
    4. change |booktitle= to |title=
    5. hide the content of |location= in <!-- --> markup or perhaps move the content into |type=
    6. clarify the documentation to indicate that {{cite conference}} is to be used to cite conference proceedings and to correct examples and parameter documentation
  3. in Module:Citation/CS1 deprecate |booktitle=
Have I missed anything? Probably. What?
Trappist the monk (talk) 14:00, 1 December 2014 (UTC)
I also noticed the large jump in the number of "chapter ignored" errors, so a couple of days ago I saved a screen capture of the error counts on Category:CS1 errors. Among the categories with at least 500 pages containing errors, there are a couple of anomalies that have seen real big increases in error counts in the past 48 hours.
There's clearly something going on with recent changes to the way errors are flagged on pages in the top two categories on this list. It appears that {{cite conference}} is one culprit, but I don't know what is causing all the recent "wikilinks embedded in URL" errors. - Stamptrader (talk) 07:23, 3 December 2014 (UTC)
We've been discussing that one over on Template talk:Citation. It's caused when you have |contribution=, |url=, |title=, and a wikilink in the title. The |url= parameter used to attach to the lowest-level named subdivision (the |contribution=, in this case). In the latest version, it always attaches to the title, and any other parameter that wants a url has its own separate url-parameter such as |contribution-url=. So, in a large number of cases that had a |contribution= or |chapter= with a |url= (papers in conference proceedings and chapters in edited volumes) the url is now linked in the wrong place. If that wrong place is a title that happens to also have a wikilink, you get this error. Think how many other references there must be out there that also now have misplaced urls but aren't made visible by wikilinks in the title.
By the way, I remember discussing exactly this issue when we were in the process of switching from the core template to the Lua module (or maybe even earlier when we first started using core? I'm not sure), and the consensus then being that attaching to the lowest level named subdivision was the correct thing to do, because it was the most common case. If there was a subsequent discussion that changed that consensus before this change to the software was made, I don't know where it happened. —David Eppstein (talk) 08:20, 3 December 2014 (UTC)

Documentation confusion[edit]

I am confused by the matching of |trans-title=/|trans-chapter=, |title=/|chapter=, and |url=/|chapter-url= in Template:Citation_Style_documentation/conference_title. Can someone please look at it to see if it makes sense? It looks all mixed up to me. It would be nice for it to make sense between now and the time when we eventually get rid of this template, if ever. – Jonesey95 (talk) 06:55, 2 December 2014 (UTC)

As it exists now, |booktitle= is only supposed to be used in {{cite conference}} though, there isn't anything in the module to prevent its use in any other template. If |booktitle= is set then the module does these substitutions:
  1. chapter gets its value from title
  2. chapter-link gets its value from title-link
  3. trans-chapter gets its value from trans-title
  4. title gets its value from booktitle
  5. title-link and trans-title are set to empty strings
This remapping reflects how parameters were remapped in the {{citation/core}} version and shows why the placement and use of |trans-chapter= (with |title=) and |trans-title= (with |booktitle=) is so odd.
Alles klar?
Trappist the monk (talk) 11:34, 2 December 2014 (UTC)

To my mind the recommendation to use {{cite encyclopedia}} for citations to papers in conference proceedings is wrongheaded and bizarre. They are not encyclopedia articles. They do not even resemble encyclopedia articles. The whole point of the {{cite}} series of templates, in contrast to the one-size-fits-all {{citation}} (which I prefer) is to have the template name tell you what kind of citation it is. The fact that {{cite conference}} has a |booktitle= parameter (in contrast to other cite templates) should make it obvious that the intent of the template was to support citations to books produced from conferences (i.e. proceedings) and contradicts what is claimed above that this was only ever supposed to be for citations to talks (a very unusual use case, much less common than proceedings). And, when editors saw this template available and used it in the past to produce citations to conference proceedings papers, these citations came out correctly formatted. Now they are broken.

This is part of a change in the way these templates have been managed that I have seen over the past few months and that I strongly object to. It used to be that they were extremely stable, with any incompatible change subject to much debate, and they had a philosophy of being able to handle any citation, with accuracy of the metadata being an important criterion as well but one that was clearly secondary to stability and flexibility. Now, Trappist has taken a hard line that certain templates and certain parameters can only be used in the proper way, that anything that doesn't fit that narrow view is erroneous, and that the templates should fail to render such usages, has changed the templates in multiple ways to fit that point of view, and responds to all complaints with assertions about how he thinks the templates should be used properly rather than with any flexibility. The result has been that thousands of Wikipedia articles have damaged citations, many of them difficult to track down and repair, and that software that depended on the past behavior of these templates is also broken. Another symptom of this was the recent breakage of journal formatting in the citation template. Yet another problematic feature of recent changes is that they have made significant changes to the {{citation}} template formatting but have been discussed if at all only here, at a talk page that does not relate to the citation template.

My desire would be (1) restore the past behavior, including chapter/contribution being allowed to work in cite conference/citation-with-journal/wherever it was recently broken, and also including the behavior that url= attaches to the lowest-level named heading of a citation and that attaching specifically to the title requires a more specific parameter like title-url, (2) that every change to the software be tested for regressions against a large collection of pre-existing citations with a variety of reasonable choices about how to parameterize them, and not made live until no regressions occur, (3) that any incompatible change have a full RFC before happening, and that that RFC should be advertised on all of the relevant talk pages, not just this one, (4) if a major regression is not discovered by testing and goes live (like the citation journal formatting one that was live for all of November) then we immediately revert to the previous version instead of waiting until the next scheduled update, and add those test cases to the bank of test cases for future regression testing, and (5) if Trappist the monk is not willing to be more flexible in how citations are allowed to be formatted, that someone else be found to maintain the software.

In the long term this may be moot as I think eventually we should and probably will shift to a wikidata-based reference formatting system but in the middle term I think the stability and usability of these templates is very important, has been forgotten in recent changes, and that something needs to be done about this. —David Eppstein (talk) 21:00, 4 December 2014 (UTC)

Documentation updated: hyphenated parameters, removed parameters[edit]

I have updated all of the subtemplates of Template:Citation Style documentation that I could find, with the primary goal of making multi-word parameter hyphenation consistent and the secondary goal of reflecting changes in how |chapter= and |day= are treated in the latest round of updates. If I missed anything, or if I did anything wrong, feel free to correct my omissions or mistakes.

I think there are further updates that could add a little bit of code to separate Lua instructions from non-Lua instructions, but how and where (and even why) to do this is not clear to me.

The hyphenated parameters were standardized after this RFC in July 2014. – Jonesey95 (talk) 07:00, 2 December 2014 (UTC)

I have also updated all of the template documentation for the individual CS1 templates that use the Lua module. If I missed anything or made any errors, let me know here or correct them. – Jonesey95 (talk) 18:00, 2 December 2014 (UTC)
Some of my edits were reverted for reasons that have not been made clear to me. I am waiting for a response from the reverting editor, but if anyone understands the message on my talk page and can explain what I did wrong, I welcome the feedback. – Jonesey95 (talk) 04:19, 4 December 2014 (UTC)
I was trying to figure that as well, so let us know.
Changing the documentation is all well, but the old parameters will continue to be used until you get all the tools changed: AWB, CitationBot, RefScript, RefToolbar, ProveIt, etc. --  Gadget850 talk 11:53, 4 December 2014 (UTC)
I created a new section below to discuss the reverts.
I'm not worried about the tools, since aliases will continue to work. I just want the documentation to be internally consistent and easy to understand, now that all parameters have similar structures. That documentation consistency has not yet been achieved, due to the reverts. – Jonesey95 (talk) 04:34, 5 December 2014 (UTC)

CS1 date error at Development of the New Testament canon[edit]

The last paragraph of the lead of Development of the New Testament canon contains several CS1 date errors ("Check date values in: |date= (help)". For example, the citation {{Citation | author = Eusebius | title = Church History | at = 3.25.1–7 | year=c. 303–25}} renders as "Eusebius (c. 303–25), Church History, 3.25.1–7  Check date values in: |date= (help)". According to MOS:DATERANGE the preferred form would be "c. 303 – c. 325", although that produces the same error. "303–325" works, but omits the circa. "c. 303" works, but omits the range. I've tried various other combinations without success. I assume this is some overzealous editing somewhere in the bowels of template:citation, but I've not yet managed to follow that code far enough to find where, yet. Any suggestions? Rwessel (talk) 04:02, 4 December 2014 (UTC)

Why did the editors of that page do that? I know, a rhetorical question embodying several other questions ...
CS1 and CS2 do not support circa date ranges. This is noted at CS1 compliance with Wikipedia's Manual of Style. At the time the date validation code was developed, circa date range style was not on the must-have list. You might add it to Module talk:Citation/CS1/Feature requests.
Trappist the monk (talk) 13:26, 4 December 2014 (UTC)
At least for the Eusebius reference, it's a series of several writings, and the approximate range of years in which they were written is known, but not the exact dates. For example, because of the dedication of the last part, it's known to have been completed before 325, but whether it was 323 or 324 is not known. Some of that is covered at Church History (Eusebius). I believe the same applies to the start date. So using circa is at least reasonable. I will ask over in module talk. Thanks. Rwessel (talk) 20:33, 4 December 2014 (UTC)

Edits to template documentation per RFC reverted; how to improve documentation consistency?[edit]

Back in July, an RFC on this page resulted in a consensus decision that all multi-word parameters should have at least one alias that uses hyphens to separate each word, and that "The documentation is to show this lowercase, hyphenated version as the one for 'normal use'."

I recently updated the shared template documentation, along with the documentation pages for all of the citation templates that use the Lua module, to reflect the above consensus. In the process, I appear to have caused problems with some of the TemplateData sections that are used by the Visual Editor. The edits that caused these problems were reverted in their entirety by another editor. After some discussion on my Talk page, I reinstated some of the changes to the template documentation pages, carefully leaving the TemplateData sections alone, except for a couple of outdated notes about how "et al." is used. Those edits were reverted in their entirety by the same editor.

At this point, the template documentation pages are inconsistent with one another and with the RFC outcome. They also contain inaccurate information about when "et al." is displayed. I am reluctant to edit the pages again, since it appears that I am in the middle of an edit war. Any ideas on how to resolve this situation are welcome.

In addition, if anyone knows of good reference material that explains how to avoid causing problems with the TemplateData section, please link to it here. I found Wikipedia:TemplateData/Tutorial, but it does not contain information about how to avoid or detect the sort of problem that I am told I created.

The template documentation pages in question are Template:Cite journal/doc‎ (history), Template:Cite book/doc (history), Template:Cite press release/doc (history), and Template:Cite news/doc (history). – Jonesey95 (talk) 04:31, 5 December 2014 (UTC)

Regarding TemplataData, some important points are:
  1. You have to follow the proper structure, as set out on the tutorial page
  2. If both normal documentation and TemplateData are both present, then the main purpose of the TemplateData is to be used in VisualEditor's template editor
  3. Wikilinks, external links, formatting, templates, and in fact any wikimarkup will not work in the description fields, so [[Template:Cite journal/doc#Date]] will display as "[[Template:Cite journal/doc#Date]]", which as plain text is probably useless for a large percentage of VisualEditor's intended users. (See Wikipedia talk:TemplateData#Extending_use.3B_removing_redundancy, and other discussions in the archives)
  4. Referring to "(above)", as in the normal documentation, is of little value: in VisualEditor, all that will be displayed is what is in the TemplateData
  5. If a parameter name is changed, the previous name should be made an alias, assuming it can still be used
  6. The TemplateData and normal documentation, including examples, should be consistent
—Note: comment from uninvolved editor - Evad37 [talk] 07:02, 5 December 2014 (UTC)
It seems clear to me that the reverting editor is correct with regard to the use of wikitext in the template data parameter description field. It also seems clear to me that the reverting editor is incorrect with regard to the changes to the main template documentation pursuant to the RFC and incorrect with regard to the |display-authors= description. Perhaps the next step is to make the changes to the main template documentation to bring it into compliance with the RFC. Then, perhaps ask the editors at the VisualEditor feedback page how to safely update the template data to bring it into compliance with the RFC. Then, scrupulously follow their advice.
Trappist the monk (talk) 12:40, 5 December 2014 (UTC)
Treating documentation as code that affects the function of an editor is an egregious sin and this methodology should be forbidden. If the visual editor developers don't agree, rip out visual editor and burn the backup tapes. Jc3s5h (talk) 12:44, 5 December 2014 (UTC)
TemplateData includes both technical controls, and prose descriptions; it is the duplication of the latter which is the problem. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:02, 5 December 2014 (UTC)
"If both normal documentation and TemplateData are both present" this is a stupid practice. See Wikipedia talk:TemplateData#Extending use; removing redundancy for reasoning and a proposed resolution. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:53, 5 December 2014 (UTC)
Evad37, thanks for the tips. Is this information available in documentation somewhere? I have been unable to find it. It is difficult to do error-free editing without documentation.
Trappist the monk, I agree, and if you read the article history and my talk page, that is exactly what I did with my second set of edits. Nonetheless, those edits were reverted wholesale, leading to the current state of the documentation (i.e. inconsistent and incorrect).
Pigsonthewing and Jc3s5h, I was also surprised that modifying the documentation affected the functioning of a tool. That was the first time I had encountered this effect, and it seems like an undesirable coding practice to me. Perhaps, as a workaround, we should modify these citation template documentation pages so that the TemplateData section is contained within its own subtemplate, with comments before the subtemplate call and within the subtemplate itself explaining that changing the text within the subtemplate could cause problems with VE functioning. That way, someone like me doing straightforward editing of wikitext in the documentation would be alerted that There Be Dragons and I should not mess with the subtemplate. – Jonesey95 (talk) 16:00, 5 December 2014 (UTC)
Widely used templates are protected so only administrators can edit them, but the documentation of those templates is generally unprotected. Presumably this is because there are not enough administrators with the writing skills and interest to do the documentation of templates. But if anything in the unprotected documentation cam mess up VE, and the vandals hear about it, that's the end of VE. Jc3s5h (talk) 17:43, 5 December 2014 (UTC)
All the more reason to separate the TemplateData text from the documentation page, via a subtemplate or other means. The subtemplate could be protected while leaving the documentation page available for editing by regular editors willing to do so. – Jonesey95 (talk) 17:51, 5 December 2014 (UTC)
Thereby vastly increasing - virtually ensuring - the likelihood of the two not being kept in sync. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:10, 5 December 2014 (UTC)
Doc pages are rarely protected: it's nothing to do with admins not having "the writing skills and interest to do the documentation of templates", but because pages aren't pre-emptively protected - only when there is a demonstrable need to do so. Until TemplateData came along, a bad edit to a doc page would, at the worst, compromise the categories or interlanguage links for the template. A bad edit to the TemplateData also won't break anything on an article, although it might make the template more difficult to use in VE. Wikilinks don't work inside TemplateData and not just because the MediaWiki parser ignores Wiki markup inside <templatedata>...</templatedata> - the TemplateData is in JSON format, where the square bracket has a completely different meaning - it encloses an array, so a double square bracket encloses two nested arrays. --Redrose64 (talk) 18:17, 5 December 2014 (UTC)
Perhaps the answer, then is to have the documentation written in standardised, human-readable way (with links and formatting) and have a script (part of VE?) read it and convert that to JSON on the fly, when needed? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:55, 5 December 2014 (UTC)
I would agree with this. Some standardized documentation format that a machine could read, though probably not JSON because of its no-wiki-text limitations, that some specially developed tool could read would be at least better than what we have now. <rant>What we do have now is the VE crowd essentially saying to us: "We need this, so here is a limited functionality format, write our documentation for us, and, just to show what good guys we are, here is an editing tool for you to use to create and maintain our documentation for us. Yeah, it's marginally usable, but we think it's really quite pretty. Thanks, call us when it's done." You might get the impression that I object to this way of doing things. You would be right.
I object to having two sets of documentation to maintain; I object them both being visible at the same time. Can we at the least wrap <TemplateData>...</TemplateData> in <div style="display:none;">...</div> so that it's out of sight?</rant>
Just so there isn't a misunderstanding: even though I object to the current state of affairs, that doesn't mean that I would not willingly participate in conversation directed toward a solution.
Trappist the monk (talk) 19:50, 6 December 2014 (UTC)
Can we at the least wrap <TemplateData>...</TemplateData> in <div style="display:none;">...</div> so that it's out of sight? There is no need for it to be immediately visible - it can be wrapped in {{Cot|TemplateData}} ... {{Cob}} so that it is obvious that it has been created, and those who want to look at it can expand it, but most people can just ignore it and look at the normal documentation. Obviously just an interim solution, being able to have a single, unified documentation would be better. - Evad37 [talk] 01:19, 7 December 2014 (UTC)

Migrating cite mailing list to Module:Citation/CS1[edit]

I've been thinking about migrating {{cite mailing list}} to Module:Citation/CS1. This template is essentially {{cite web}} with a tweak. There is one unique parameter |mailinglist=. If this parameter has a value, {{cite mailing list}} uses in the same way that {{cite web}} uses |work= or |website= except that it tags on the text 'mailing list' to whatever is provided in |mailinglist=:

{{cite mailing list |title=Title |url=//example.com |mailinglist=Example |date=6 December 2014}}
"Title". Example mailing list. 6 December 2014. //example.com.

This functionality isn't a lot different from what {{cite AV media notes}}, {{cite DVD notes}}, {{cite podcast}}, {{cite press release}}, {{cite techreport}}, {{cite thesis}} do except that these templates provide the annotation text to the meta variable TitleType if |type= is empty or omitted.

If we migrate {{cite mailing list}} I think that we should follow the example set by these other templates. This example, using {{cite web}} with |website=Example and |type=mailing list illustrates how the migrated template would render compared to the previous example:

"Title". Example mailing list. 6 December 2014. //example.com. – current {{cite mailing list}}
"Title". Example (Mailing list). 6 December 2014. {{cite web}} as prototype

Alternately, since there are 450ish transclusions of {{cite mailing list}} we could just deprecate it and run a script that would convert them all to {{cite web}}.

Opinions?

Trappist the monk (talk) 20:24, 6 December 2014 (UTC)

The last thing you said, about converting them all to {{cite web}}, is what occurred to me when I read your second sentence. I would support converting all of them to {{cite web}} and then turning {{cite mailing list}} into a redirect to {{cite web}}.
One caveat: {{cite web}} requires |url= and |title=. It seems possible that someone could cite a mailing list post without providing a URL, although someone else might claim that doing so fails WP:V. What do we do about instances of {{cite mailing list}} that lack |url=?
I don't know enough about the process for this, but I think the first step would be to gain consensus here, then to take {{cite mailing list}} to TfD, proposing to redirect it to {{cite web}}. Does that seem right? – Jonesey95 (talk) 20:39, 6 December 2014 (UTC)
Good point. First get consensus here and then do it again at TfD. Too much trouble for such a little-used template. So I've stricken that idea.
Like {{cite podcast}} before it, {{cite mailing list}} would be subject to the same tests as {{cite web}}. Though I have not done an exhaustive search, I have not seen the case where |url= is empty or omitted.
Trappist the monk (talk) 18:04, 7 December 2014 (UTC)

Migrated to Module:Citation/CS1/sandbox:

Cite mailing list compare
{{ cite mailing list | title=Title | mailinglist=Example | date=9 December 2014 | url=//example.com }}
Live "Title". Example mailing list. 9 December 2014. //example.com.
Sandbox "Title". Example (Mailing list). 9 December 2014. 

See also testcases.

Trappist the monk (talk) 15:37, 9 December 2014 (UTC)

Template documentation standard?[edit]

In a previous discussion we raised the topic of reducing the workload required because there are two separate and incompatible sets of documentation that must be maintained for every parameter of every template. The first set of documentation is the verbose, human readable documentation that is present on all CS1 and CS2 template pages. The second is the JSON formatted documentation used by the visual editor. This second documentation set imposes certain limits on what is and is not allowed in the documentation.

In the previous discussion, Editor Andy Mabbett suggested: documentation written in standardised, human-readable way (with links and formatting) and have a script (part of VE?) read it and convert that to JSON on the fly. I can't speak to conversion but perhaps the standardized form for human readable documentation light take the form of a series of templates which, when used in the correct order would produce a human readable table. The templates would have parameters to match the JSON keywords. For example, this is the template data for |last= from {{cite book}}:

"last": {
        "label": "Last name",
        "description": "The surname of the author; don't wikilink, use 'authorlink'; can suffix with a numeral to add additional authors",
        "aliases": [
                "author",
                "author1",
                "authors",
                "last1"
        ],
        "suggested": true
},

This might be adapted to a template that would look like this:

{{template param doc
|name=last
|ve-label=Last Name
|ve-description=The surname of the author; don't wikilink, use 'authorlink'; can suffix with a numeral to add additional authors
|description='''last''': Surname of author. Do not wikilink—use '''author-link''' instead. For corporate authors, simply use '''last''' to include the same format as the source
|alias1=author
|alias2=author1
|alias3=authors
|alias4=last1
|type=string  <!-- undefined, string, boolean, date, page, user, file, content, unbalanced wikitext, line -->
|default=none
|ve-autovalue=none
|suggested=true
|required=false
}}

So here we have most if not all of the components that ve requires for its documentation all neatly bundled and from which it may take to format as it sees fit. Similarly, we can now take this same bundle of stuff and do likewise. We might create {{template param doc start}} and {{template param doc end}} templates that would create wikitable header and footer and where each {{template param doc}} would be a row in that table. We might add parameters that ve doesn't want or require: |used in COinS=true, |prerequisites=none, |can enumerate=true, etc. Perhaps another presentation style would be better.

Trappist the monk (talk) 15:49, 8 December 2014 (UTC)

Because entering wikitext in the regular editor is so different that creating citations in VE, helpful descriptions of what to do for wikitext are useless as VE tips. So it will be necessary, in general, to provide different descriptions (although some fields might be able to use the same description for both). |last= is a perfect example; if you want to add another author in VE, you go to the bottom of the box and click "add more info", you don't suffix the "last" parameter with a digit. Jc3s5h (talk) 17:11, 8 December 2014 (UTC)
Which is why there is |ve-description=. It can contain whatever descriptive text is appropriate to ve. Yeah, the above still has two separate descriptions but only one definition for all others and uses only one format and structure.
Trappist the monk (talk) 17:21, 8 December 2014 (UTC)
I like this idea. It could help with consistency between the parameter lists and tables that are typically at the top of our documentation and the VE documentation.
We may have some trouble with variables that are unbounded, like "lastn". I don't know how the VE documentation, which feeds the VE template editor, is set up to deal with those. It seems foolish to list last1, last2, last3, ... last30, but would that be the only way to deal with VE? I guess my question, for now, is: what happens right now if I try to edit a thirty-author "cite journal" template with VE? I haven't tried it. – Jonesey95 (talk) 18:20, 8 December 2014 (UTC)
I charge you to try it and report back.
The unbounded parameters is why I suggested the |can enumerate=true parameter so that we don't have to repeat like is currently done at Template:Cite_journal#Template_data.
Trappist the monk (talk) 18:37, 8 December 2014 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── Documentation in the form I described above might be rendered this way:

Parameter documentation for {{template param doc}}
name description aliases type condition
name name of the template parameter none string required
description wikitext that describes the purpose and or function of the parameter none string required
ve-description plain-text that describes the purpose and or function of the parameter; used by visual editor; do not use wikimarkup none string required
aliasn used when alternate parameter names for a parameter are available; enumerated parameter where n is 1–9 none string suggested
type identifies the type of the parameter value:
  • undefined – <definition>
  • string – a set of characters, like this sentence
  • boolean – <definition>
  • date – <definition>
  • page – <definition>
  • user – <definition>
  • file – <definition>
  • content – <definition>
  • unbalanced wikitext – <definition>
  • line – <definition>
none string suggested
default identifies the parameter's default value when the parameter is empty or omitted none string suggested
ve-autovalue see mw:Help:TemplateData#Auto_value none string none
suggested set to true when use of the parameter is recommended; default is false none boolean none
required set to true when use of the parameter is required for proper template operation; default is false none boolean none

Trappist the monk (talk) 11:56, 9 December 2014 (UTC)

Strictly speaking, for the type, one should explain that all the suggested types are strings. The type described as "string" is a free-form string with minimal rules (what are those rules?). The other types are strings that must represent an instance of the type, for example, "123" is a string of three Unicode characters that represents a number. In a more formal document, a detailed description of allowed values for each type would be specified. Jc3s5h (talk) 12:33, 9 December 2014 (UTC)
Type values are lifted from template data editor. Except for 'string', mw:Help:TemplateData doesn't define what those types actually mean. Certainly in the above example, description could wikilink to complete descriptions at an appropriate help page or, as I have modified above, brief descriptions can be provided for each optional value or, we could do both.
Trappist the monk (talk) 13:17, 9 December 2014 (UTC)
This resurrects a previous problem: what if a parameter value is a true and necessary description of a source, but not supported by CS1 due to software limitations. For example, the date of a newspaper printed in England on 29 February 1600 1700; this is not a valid Gregorian calendar date but was a valid Julian calendar date. Accept it in VE and let the red message appear in the article? Advise the editor that CS1, and therefore, VE, are inappropriate for this article and advise the editor to use "Edit Source" and rewrite all the citations without templates? Jc3s5h (talk) 12:41, 9 December 2014 (UTC), fixed 15:53 UT
Sure, that's an issue to be dealt with in the documentation, but is off-topic when the topic is standardizing documentation format so that the maintenance task is reduced to a single format. And 29 February ...
Trappist the monk (talk) 13:17, 9 December 2014 (UTC)

Well, I thought I had an idea. It seemed to me that we could write a couple of templates and some Lua code that would allow us to implement Editor Andy Mabbett's suggestion. So I took a crack at it. The results are {{template parameter doc}}, {{template parameter doc item}}, and Module:template parameter doc. As you can see at both template pages, the implementation doesn't work. I don't know this for sure, but I'm guessing that <TemplateData>...</TemplateData> is processed before templates and modules are processed. I surmise this because I can copy and paste the template data created by the module, into the page, save the page, and produce the usual template data documentation table.

Trappist the monk (talk) 14:57, 13 December 2014 (UTC)

WP:VPT comes through again. {{template parameter doc}}, {{template parameter doc item}}, and Module:template parameter doc are now doing what I had hoped they could do.
Trappist the monk (talk) 01:46, 14 December 2014 (UTC)
Well I spoke too soon. The fix I mentioned above, renders a nice pretty TemplateData table but more is needed. I'm guessing that Visual Editor and the TemplateData editor both read the source file for the template (which transcludes the documentation page). They don't read the rendered page which is where template and module output goes. I believe this to be true because if I attempt to add {{template parameter doc}} to a page, ve produces this message:
You are adding the "Template parameter doc" template to this page. It doesn't yet have a description, but there might be some information on the template's page.
But, if I attempt to add {{template parameter doc item}}, ve finds the TemplateData that I added to that page as a test of the output from Module:template parameter doc.
So, this idea may have run its course.
Trappist the monk (talk) 12:58, 14 December 2014 (UTC)

Cite conference[edit]

{{cite conference}} is broken. Fixed, I think, in the sandbox.

Cite conference compare
{{ cite conference | chapter=Chapter | title=Title | conference=Conference }}
Old "Title". Conference.
Live "Title". Conference.  |chapter= ignored (help)
Sandbox "Chapter". Title. Conference. 
Cite conference compare
{{ cite conference | conference=Conference | booktitle=Booktitle | title=Title }}
Old "Title". Booktitle. Conference.
Live "Booktitle". Conference.  |chapter= ignored (help)
Sandbox "Title". Booktitle. Conference. 


See also testcases.

Trappist the monk (talk) 00:13, 9 December 2014 (UTC)

Encyclopedia-style output from citation[edit]

{{citation}} does not currently support 'encyclopedia'-style output akin to that produced by {{cite encyclopedia}}. I have tweaked Module:Citation/CS1/sandbox so that it does. This functionality is invoked when {{citation}} uses |encyclopedia=. These examples compare {{citation}} output to the same parameter set rendered by {{cite encyclopedia}}:

  • {{citation/new |article=Article |encyclopedia=Encyclopedia}}
    • "Article", Encyclopedia 
    • "Article". Encyclopedia. 
  • {{citation/new |title=Title |encyclopedia=Encyclopedia}}
    • "Title", Encyclopedia 
    • "Title". Encyclopedia. 
  • {{citation/new |article=Article |title=Title |encyclopedia=Encyclopedia}}
    • "Article", Title, Encyclopedia 
    • "Article". Title. Encyclopedia. 

Both {{citation}} and {{cite encyclopedia}} produce the same COinS output:

  • <span class="citation">"Article", ''Title'', ''Encyclopedia''</span><span title="ctx_ver=Z39.88-2004&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1&rft.atitle=Title&rft.btitle=Encyclopedia&rft.genre=bookitem&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook" class="Z3988"><span style="display:none;">&nbsp;</span></span>
  • <span class="citation encyclopaedia">"Article". ''Title''. ''Encyclopedia''.</span><span title="ctx_ver=Z39.88-2004&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1&rft.atitle=Title&rft.btitle=Encyclopedia&rft.genre=bookitem&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook" class="Z3988"><span style="display:none;">&nbsp;</span></span>

Trappist the monk (talk) 16:59, 9 December 2014 (UTC)

It's good that "three level" citations will be available to CS2 /{{citation}} users and I look forward to this being deployed; thanks for your prompt response. Two things I find a little odd, although probably acceptable, are:
  • The way that |url= shifts from title to encyclopedia when title is omitted.
  • The fact that both |article= and |title= can be omitted without error if |encyclopedia= is present.
I do also slightly worry that editors are being encouraged to use |encyclopedia= to achieve a formatting effect when semantically the top level work isn't an encyclopedia. Ideally I'd like to be able to use something more generic like |contribution= |title= and |work= to achieve "three levels". Peter coxhead (talk) 19:27, 9 December 2014 (UTC)
It isn't that |url= shifts, its that |encyclopedia= shifts to fill the hole left vacant by the omitted or empty |title=. |url= belongs to |title=.
You can also leave off a title from a journal citation, and get the same result:
{{citation |journal=Journal}}
Journal 
Conversely, you can have {{cite journal}} without specifying |journal=:
{{cite journal |title=Title}}
"Title". 
Both of those conditions should probably be addressed.
Trappist the monk (talk) 20:24, 9 December 2014 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── In the COinS metadata examples above, I notice this:

&rft.atitle=Article&rft.btitle=Title

and wonder if it is really as it should be. The COinS provides for only two title items. It seems that when {{citation}} or {{cite encyclopedia}} use |article=Article, |title=Title, and |encyclopedia=Encyclopedia, then what the COinS should have is:

&rft.atitle=Title&rft.btitle=Encyclopedia

Trappist the monk (talk) 20:24, 9 December 2014 (UTC)

I have tweaked the COinS code so that when:
{{cite encyclopedia |article=Article |title=Title |encyclopedia=Encyclopedia}}
or
{{citation |article=Article |title=Title |encyclopedia=Encyclopedia}}
then COinS is:
&rft.atitle=Title&rft.btitle=Encyclopedia
Trappist the monk (talk) 12:38, 10 December 2014 (UTC)

CITEREF anchor id without names and dates[edit]

Here we have two simple templates:

  • {{cite book |title=Title |ref=harv}}
  • {{citation |title=Title}}

And here, the output rendered by Module:Citation/CS1. Neither have authors or dates yet both have id="CITEREF":

  • <span id="CITEREF" class="citation book">''Title''.</span><span title="ctx_ver=Z39.88-2004&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1&rft.btitle=Title&rft.genre=book&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook" class="Z3988"><span style="display:none;">&nbsp;</span></span>
  • <span id="CITEREF" class="citation">''Title''</span><span title="ctx_ver=Z39.88-2004&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1&rft.btitle=Title&rft.genre=book&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook" class="Z3988"><span style="display:none;">&nbsp;</span></span>

It seems to me that having an anchor id that is just CITEREF serves no useful purpose. So, I've tweaked Module:Citation/CS1/sandbox to omit the anchor id when the template hasn't got at least one author or a date. Here, the output from the same two templates rendered by the sandbox:

  • <span class="citation book">''Title''.</span><span title="ctx_ver=Z39.88-2004&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1&rft.btitle=Title&rft.genre=book&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook" class="Z3988"><span style="display:none;">&nbsp;</span></span>
  • <span class="citation">''Title''</span><span title="ctx_ver=Z39.88-2004&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1&rft.btitle=Title&rft.genre=book&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook" class="Z3988"><span style="display:none;">&nbsp;</span></span>

For CS1, should we be flagging templates that have |ref=harv but are missing one or both of author and date? No need for CS2; because |ref=harv is the default state, the error category would be flooded. For CS1, we presume that the editor intended to use Harvard referencing if |ref=harv is present.

Trappist the monk (talk) 18:28, 9 December 2014 (UTC)

Flagging this (in CS1 only) looks like a good idea to me, since there is no sensible ref=harv id to be produced. —David Eppstein (talk) 18:44, 9 December 2014 (UTC)

A new kind of author-link error to detect[edit]

Can we detect this kind of |author-link= error, in addition to the ones we already detect?

[[Nick Tolhurst|Tolhurst, Nick]] (2008). The A to Z of Corporate Social Responsibility. Wiley. ISBN 978-0-470-72395-1. 

Jonesey95 (talk) 06:44, 10 December 2014 (UTC)

[[Nick Tolhurst|Tolhurst, Nick]] Check |authorlink= value (help) (2008). The A to Z of Corporate Social Responsibility. Wiley. ISBN 978-0-470-72395-1. 

  1. {{cite book/new |title=Title |author=Author |authorlink=Author}}
    Author. Title. 
  2. {{cite book/new |title=Title |author=Author |authorlink=[[Author]]}}
    [[Author|Author]] Check |authorlink= value (help). Title. 
  3. {{cite book/new |title=Title |author=Author |authorlink=[[Author]}}
    {{cite book/new |title=Title |author=Author |authorlink=[[Author]}}
  4. {{cite book/new |title=Title |author=Author |authorlink=[[Author}}
    {{cite book/new |title=Title |author=Author |authorlink=[[Author}}
  5. {{cite book/new |title=Title |author=Author |authorlink=[Author}}
    [[[Author|Author]] Check |authorlink= value (help). Title. 
  6. {{cite book/new |title=Title |author=Author |authorlink=[Author]]}}
    [[[Author]]|Author]] Check |authorlink= value (help). Title. 
  7. {{cite book/new |title=Title |author=Author |authorlink=[Author]}}
    [[[Author]|Author]] Check |authorlink= value (help). Title. 
  8. {{cite book/new |title=Title |author=Author |authorlink=Author]]}}
    Author|Author]] Check |authorlink= value (help). Title. 
Trappist the monk (talk) 11:59, 10 December 2014 (UTC)
Also, checks for authorlink = y, yes, n, no, or one digit would be appreciated. I've just cleaned up a bunch of these. Thanks! GoingBatty (talk) 00:59, 11 December 2014 (UTC)
Just one digit?? So |authorlink=45 is ok? Why the distinction?
Trappist the monk (talk) 12:02, 11 December 2014 (UTC)
I've been trying to think of a case where any purely numerical string would be a valid value for |author-link=. I haven't been able to come up with a person or organization with a purely numerical name. The closest I've been able to come is 99, but she is a fictional character. There are hip-hop artists whose names pretty short, like D12 and D4L, which gives us an upper bound for values to mark as errors.
I propose marking any single-character entry as an error, and any purely numerical value as an error (this may bite us, so we should be willing to do a quick fix to the code). We could try marking two-character values as errors, but I suspect there are valid two-character article names out there for authors of some kind.
On the original topic: Trappist the monk, I don't see error messages for all of the author-link values above, only for some of them. Items 3 and 4 above do not show an error message, but it seems like they should. – Jonesey95 (talk) 21:54, 11 December 2014 (UTC)
They don't show errors because those particular conditions aren't recognized as valid templates so {{cite book/new}} is never called; the parser gets to the end of the file without finding the matching ]] so doesn't see the closing }}. You can prove that by removing the <nowiki>...</nowiki> tags from around the two square brackets in the previous sentence. The parser then finds the two curly braces and emits the check authorlink error message. Nothing that the module can do about that.
Trappist the monk (talk) 22:37, 11 December 2014 (UTC)
@Trappist the monk, Jonesey95: I can't think of a valid |authorlink= value with a purely numerical name either. (Even if we were citing something from Agent 99, we wouldn't want to link to the year 99.) Thanks for taking my suggestion a step further. GoingBatty (talk) 19:33, 13 December 2014 (UTC)

Cite report[edit]

Yeah, I'm about to open that can of worms (see here, continued here).

Apparently, {{cite report}} is to be used only for things that are unpublished, where the definition of unpublished appears to mean that the item has not been made available to the public. This definition seems to be a bit fuzzy. The example in the template's documentation page is:

{{cite report |title=Rhode Island Roads |publisher=Rhode Island Department of Public Works |date=1956}}
Rhode Island Roads (Report). Rhode Island Department of Public Works. 1956.

Given what I know about that report (nothing, because I don't have access to it) this example clearly fits the definition.

This example, taken from the template's talk page, doesn't seem to fit the definition so well:

{{cite report|url=http://www.nhc.noaa.gov/archive/storm_wallets/atlantic/atl1993/gert/prenhc/prelim01.gif|title=Preliminary Report Hurricane Gert: 14-21 September 1993|series=Hurricane GERT, Hurricane Wallet Digital Archives|date=1993-11-10|first=Richard J.|last=Pasch|accessdate=2011-10-03|location=Miami, Florida|publisher=[[National Hurricane Center]]|page=[1]}}
Pasch, Richard J. (1993-11-10). Preliminary Report Hurricane Gert: 14-21 September 1993 (Report). Hurricane GERT, Hurricane Wallet Digital Archives. Miami, Florida: National Hurricane Center. p. [1]. http://www.nhc.noaa.gov/archive/storm_wallets/atlantic/atl1993/gert/prenhc/prelim01.gif. Retrieved 2011-10-03.

It doesn't fit the definition because the citation has |url= which seems to me to indicate distribution, if not publication for public consumption. That being the case, the citation should be rewritten as {{cite web}}.

In the documentation, the template skeletons (inconsistently) have |url=, |accessdate=, and |format=. While not in the skeletons, the documentation lists |laysummary= and |laydate=. It isn't quite clear to me if these indicate distribution or not. The template code, supports the standard set of identifiers: ISBN, DOI, JSTOR, etc. all of which, if included in {{cite report}} would, to me, indicate distribution or publication.

{{cite report}} is stylistically different from all other CS1 templates in how it handles the title element. In CS1, titles of items that are a part of a larger whole, are rendered quoted, while the larger whole is rendered in italics. {{cite report}} renders its title element in normal upright font without quote marks. Yet, at the same time, it supports |chapter= or |section= so you end up with this:

{{cite report |title=Title |chapter=Chapter}}
"Chapter". Title (Report).

In the template code is this:

|Title= ''&#xFEFF;{{{title|}}}&#xFEFF;''

What is the purpose of the pair of &#xFEFF; (zero width no-break space) characters? Were they on the outside, I could see them separating the italic markup here from the italic markup added by {{citation/core}}. But they aren't so it isn't clear to me why they're there. The final rendered title looks like this:

''''&#xFEFF;Title&#xFEFF;''''&#32;

So, what to do about {{cite report}}? Do we maintain {{cite report}} as a CS1 template? Do we migrate it to Module:Citation/CS1? There has been some discussion about supporting unstyled title elements (here) which may (or may not) have relevance to this discussion.

Trappist the monk (talk) 14:21, 11 December 2014 (UTC)

Per WP:SOURCE: "Base articles on reliable, third-party, published sources with a reputation for fact-checking and accuracy. Source material must have been published, the definition of which for our purposes is "made available to the public in some form". Unpublished materials are not considered reliable."
Per {{cite report}}:

Unpublished reports by government departments, instrumentalities, operated companies, etc.

These reports are to be published in the Wikipedia sense of verifiability: a responsible organisation must have fact checked them; and the selection process for publication must not have been automatic.
Examples include: government printed reports which lack ISSN or ISBN numbers, and reports from major semi-governmental instrumentalities that are freely circulating and available for verification, but which lack a formal ISBN / ISSN publication process.
The definition in {{cite report}} has never made sense to me. Neither ISBN nor ISSN have nothing to do with verifiability and ISSN is assigned to a periodical, not an individual publication. And the title formatting has never made sense.
See previous discussion at Template talk:Cite report#Update to citation/core. --  Gadget850 talk 15:56, 11 December 2014 (UTC)

Lets take a look at a sample of uses:

  • Area 51: The U-2's Intended Successor: Project Oxcart,1956-1968 (Report). approved for released by the CIA in October 1994. "The new 8,500-foot runway was completed by 15 November 1960."
Approved for release indicates to me this is published, and a quick search readily finds it on the web.[2] Date requires cleanup.
Linked and publisher indicated.
Linked and publisher indicated. This one uses |docket= but looking at other use on the web, it is a subtitle.
Linked, document shows the publisher is the U.S. Air Force.
Linked and publisher indicated.

Chicago 16 has a section on "Unpublished and Informally Published Material, 14.224 ff.

  • 14.224 THESES AND DISSERTATIONS: Titles of unpublished works appear in quotation marks--not in italics. This treatment extends to theses and dissertations, which are otherwise cited like books.
  • 14.225 UNPUBLISHED MANUSCRIPTS: Titles of unpublished manuscripts, like the titles of other unpublished works, appear in quotation marks.

...and so on.

Chicago 16 does cover generic names:

  • 14.234 SPECIFIC VERSUS GENERIC TITLES FOR MANUSCRIPT COLLECTIONS: In notes and bibliographies, quotation marks are used only for specific titles (e.g., "Canoeing through Northern Minnesota"), but not for generic names such as report or minutes. Generic names of this kind are capitalized if part of a formal heading actually appearing on the manuscript, lowercased if merely descriptive.

APA 6:

  • 7.09, Unpublished and Informally Published Works: Unpublished work includes work that is in progress, has been submitted for publica­tion, or has been completed but not submitted for publication. This category also includes work that has not been formally published but is available on a personal or institutional website, an electronic archive such as ERIC, or a preprint archive.
It then goes on to show unpublished works formatted with quotes or italics as other sources.

But we need to put this into context. Chicago and APA are for a general audience and do not cover our verifiability polices and the prohibition on original research.

Summary: Every use I have encountered can be replaced by {{cite journal}}. There would be cleanup needed because many of these are badly formatted, especially with dates but that is nothing new. I see no need for |type=Report being set as default. Darned if I know what to do with |docket= except go through and clean it up. --  Gadget850 talk 13:26, 13 December 2014 (UTC)

Absolutely none of the samples above are suitable for {{cite journal}}. That should only be for papers that are published in academic journals, not true for any of these. And as well as carrying the wrong metadata, {{cite journal}} will probably format these wrong. —David Eppstein (talk) 18:22, 13 December 2014 (UTC)
The {{cite journal}} description is "used to create citations for articles in magazines, journals, newsletters, and for academic papers." Limiting it to academic journals is a lost battle and if you want to discuss it further please start a separate discussion. --  Gadget850 talk 19:39, 13 December 2014 (UTC)
I agree that {{cite report}} appears to be redundant to other citation templates. It looks like it's time for a widely advertised TfD, since the template is used in about 5,000 articles. – Jonesey95 (talk) 16:09, 13 December 2014 (UTC)

In academic computer science, at least, and probably also in many other areas of academic publishing (CS is the one I'm most familiar with), preprints of papers that have not yet been published as journals or conferences are considered as "unpublished", but are often made publicly available online as part of a technical report series. That is what this template is for. If you eliminate it, there will be no appropriate cite template for them to go in. They are not books (too short, no isbn, etc), they are not conferences, they are not journals, etc. And they have their own somewhat specialized formatting requirements: they are generally numbered as part of a technical report series, and that number is an important part of their citation data. Being available online is not inconsistent with being "unpublished", because in this context published means having gone through a formal peer review and appearing in a publication put out by a third party rather than merely being available to the public. They are really more self-published than unpublished, but they're called unpublished. Often they should be replaced by a later published version of the same work but sometimes for whatever reason that doesn't happen. We still cite them sometimes, e.g. under the "recognized expert" clause of WP:SPS. The first few examples I found in a quick search all happened to be formatted with CS2 rather than CS1 but I think they are still reasonably representative:

So your objections to the existence of this template seem to be founded purely on ignorance of this kind of publication. What alternative template in the CS1 series do you think (1) will adequately format these, and (2) per the CS1 philosophy that the template name tells you what kind of citation it is, will adequately convey that piece of metadata? —David Eppstein (talk) 17:58, 13 December 2014 (UTC)

In the case of all three of your examples, the CS1 template most appropriate would seem to be {{cite techreport}}:
Trappist the monk (talk) 18:17, 13 December 2014 (UTC)
Ok, then. What is the intended difference between cite techreport and cite report? Because maybe they should be merged. Also, is cite techreport capable of using a name for the technical report series other than "Technical report"? Because they're not always called exactly that. And why the parentheses around the words "Technical report" and the separation from the number in the report series? I want to see formatting like "Technical report RC-5431" or "Report no. 172", not to have "(Technical report)" somewhere in the citation and the report number divorced from its context somewhere else. —David Eppstein (talk) 18:23, 13 December 2014 (UTC)
|type=none and |number=Report no. 172
Why the parentheses? Because CS1 and CS2 do that with the value assigned to |type=:
Stockmeyer, Larry J. (1975), The set basis problem is NP-complete (Technical Report), IBM, RC-5431 .
Trappist the monk (talk) 18:41, 13 December 2014 (UTC)
This is the typical sort of answer from you that I've been finding really frustrating. Why? Because that's the way it's programmed. That's not what I want to know. What was the rationale for programming it that way? If CS1 and CS2 parenthesize the type parameter in this way, then either that choice of formatting is wrong, or the type parameter is the wrong one to be using for the name of a technical report series. The formatting from my {{citation}} examples above is much closer to what I want to see. Is there some approved way of obtaining this formatting, that won't suddenly get deprecated later? —David Eppstein (talk) 19:08, 13 December 2014 (UTC)
The long gone editors who first created these templates made some style choices and we have consistently maintained them over the years. If you want to see a change, create a new discussion and make a specific proposal with some rationale. --  Gadget850 talk 19:57, 13 December 2014 (UTC)
In my own editing I prefer CS2. But from the discussion above it appears that {{cite report}} can be used to generate what I would consider appropriate formatting for a technical report, and that {{cite techreport}} cannot (as a consequence of the past decision to make the name of the technical report series be a "type" instead of a "series"). If I were to use CS1 (for instance because that was the established style of an existing article) and wanted to cite a technical report, based on this discussion, I would use {{cite report}}. So the status quo is acceptable to me. What I would find objectionable would be the change proposed by others above, where we get rid of the working template {{cite report}} and shoehorn everything into other templates that don't work so well for this kind of publication. —David Eppstein (talk) 20:08, 13 December 2014 (UTC)
There are an awful lot of words on this page that I put here. I have no problem being verbose. But, somehow, your posts to and about me have made me unwilling to respond to you with any more words than are absolutely necessary. There is precious little documented rational for why CS1/2 are the way they are. You have been here longer than I so you know this to be true. If there is anything written about why |type= is rendered in parentheses, it will be found in an archive somewhere.
It seems to me that this conversation has come adrift. The topic is {{cite report}} and what to do about it.
Trappist the monk (talk) 19:59, 13 December 2014 (UTC)
Some time back I went through archives and template histories going back to 2007. There is little discussion on why certain styles were chosen. If changed is desired, I have some thoughts on formatting. --  Gadget850 talk 20:15, 13 December 2014 (UTC)

Migrated to Module:Citation/CS1/sandbox. See testcases. Should work more-or-less like the {{citation/core}} version works. If we decide that we don't like the unstyled titles (or anything else about this template), we can change it.

Trappist the monk (talk) 21:27, 14 December 2014 (UTC)

Duplicate punctuation fix[edit]

There has been a long-standing CS1 and CS2 bug where the code that didn't address the case where terminal punctuation of a title matched the separator character when the template had both |title= and |url=. Here I have set |separator=# so that the bug is obvious:

Cite book compare
{{ cite book | publisher=Publisher | title=Title# | separator=# | url=//example.com }}
Live Title## Publisher. 
Sandbox Title# Publisher. 

This fix does not address the same thing occurring when |chapter=Chapter#

Citation compare
{{ citation | chapter=Chapter# | publisher=Publisher | title=Title# | separator=# | url=//example.com }}
Live "Chapter#"# Title## Publisher 
Sandbox "Chapter#"# Title# Publisher 

There is no systematic mechanism deal with title elements that have terminal punctuation either as correct components of the title (see this feature request) or as typographical errors by editors. This will require some thought, but in the meantime this particular bug is fixed.

Trappist the monk (talk) 18:50, 11 December 2014 (UTC)

While I agree that terminal punctuation = separator should cause the separator to vanish, I'm not sure it's the only potential problem of this form. Suppose that the separator is a comma (the default in CS2 but also an option in CS1) and a title or chapter ends with a period (as sometimes happens). Presumably one of the two punctuation characters should vanish in this case, but which one? —David Eppstein (talk) 20:16, 13 December 2014 (UTC)
That is the topic of the feature request I mentioned and is not part of this fix.
Trappist the monk (talk) 20:20, 13 December 2014 (UTC)

Separator parameters[edit]

At this discussion I asked why we have several different separator parameters. This discussion assumes that we don't need so many and proposes a path to streamlining this set of parameters.

CS1/2 needs three types of separator: one to separate |first= from |last=, one to separate the items in a name list (authors, editors), and one to separate the various elements of the citation. This discussion applies to the first two of these.

The name separator parameters are:

|author-name-separator=
|editor-name-separator=

I can see no reason to have different separators for first/last name separation in a citation. Whatever separator is used to separate author last/first names should be used to separate editor last/first names. We should combine the functionality of these separate parameters into a single parameter. The most appropriate parameter name would be |name-separator=. But that parameter name is already in use.

The name list separator parameters are:

|author-separator=
|editor-separator=
|name-separator=

Again, I see no reason to have different separators for name lists in a citation. Whatever separator is used to separate authors in the author list should be used to separate editors in the editor list. We should combine the functionality of these separate parameters into a single parameter. The most appropriate parameter name would seem to be |name-list-separator=.

Because |name-separator= is already in use, I think that we need a two-stage process to cleanup this mess. In the first stage we:

  1. create |name-list-separator=
  2. make |author-separator=, |editor-separator=, and |name-separator= aliases of |name-list-separator=
  3. modify Module:Citation/CS1 to use |name-list-separator= where it now uses |author-separator=, |editor-separator=, and |name-separator=
  4. deprecate |author-separator=, |editor-separator=, and |name-separator= in favor of |name-list-separator=
  5. create a script (or bot if necessary) to troll Category:Pages containing cite templates with deprecated parameters that will replace instances of |author-separator=, |editor-separator=, and |name-separator= with |name-list-separator=
  6. after the number of instances of |author-separator=, |editor-separator=, and |name-separator= in Category:Pages containing cite templates with deprecated parameters has been reduced to an acceptable level, these three parameters are added to Module:Citation/CS1/Suggestions, are removed from Module:Citation/CS1/Whitelist, are removed as aliases of |name-list-separator=, and are removed from the documentation

At some point after the last step in stage 1, do stage 2:

  1. remove |name-separator= from Module:Citation/CS1/Suggestions
  2. recreate |name-separator=
  3. make |author-name-separator= and |editor-name-separator= aliases of |name-separator=
  4. modify Module:Citation/CS1 to use |name-separator= where it now uses |author-name-separator= and |editor-name-separator=
  5. deprecate |author-name-separator= and |editor-name-separator= in favor of |name-separator=
  6. create a script (or bot if necessary) to troll Category:Pages containing cite templates with deprecated parameters that will replace instances of |author-name-separator= and |editor-name-separator= with |name-separator=
  7. after the number of instances of |author-name-separator= and |editor-name-separator= in Category:Pages containing cite templates with deprecated parameters has been reduced to an acceptable level, add these two parameters to Module:Citation/CS1/Suggestions, remove them from Module:Citation/CS1/Whitelist, remove them as aliases of |name-separator=, and remove them from the documentation

Are there flaws in this plan? Should I proceed?

Trappist the monk (talk) 13:20, 15 December 2014 (UTC)

Looks good. I recall this being discussed a few years ago, but the discussion went off the rails. I did a quick search for |author-separator=; every use also makes the style changes made by {{vcite2 journal}}. --  Gadget850 talk 13:42, 15 December 2014 (UTC)
I support the basic idea here, but it would be great to come up with parameter names for these two items that are less ambiguous. We already see unsupported parameters like |name= and |published= used by editors, for whatever reason.
It looks like we are proposing default parameters of |name-separator= as the separator between first and last names (typically a comma in CS1 citations), and |name-list-separator= as the separator between authors (typically a semicolon in CS1 citations). These parameter names imply that there is a |name= parameter, but there is not. I understand that we are trying to indicate that there is one of each separator parameter that covers both authors and editors.
I would love to see parameter names that are more self-evident; if I have to look at the documentation to remember which is which, the names are not good enough. I don't have a brilliant suggestion right now, but one of us may be able to come up with something. I will be OK with the above plan going forward even if there are no suggestions. – Jonesey95 (talk) 21:58, 15 December 2014 (UTC)
There's no point in having a parameter for the default separator between first and last names. If people want to get rid of the comma in names that are usually written surname first, the only sensible way to do that is with a separate parameter for each author or editor name. |author-name-separator= and |editor-name-separator= are just hacks that do that in some cases but not others. (Not that getting rid of the comma is necessarily a good idea, but that's a different issue). Kanguole 22:32, 15 December 2014 (UTC)

(edit conflict)

No argument. Instead of |name-separator= we could use |last-first-separator= because it only applies to |last=, |first=, |editor-last=, and |editor-first=. Or we could ask a more fundamental question: do we even need to specify a last/first separator character? It has been argued that we don't need to disable the separator for Asian names. It could be argued that we only 'need' |author-name-separator= and |editor-name-separator= when editors want to use CS1/2 in quasi-Vancouver mode (|author-format=vanc or |editor-format=vanc). Is there any other case where |first= is separated from |last= by any other character than a comma? If no, then why have |author-name-separator= and |editor-name-separator=?
Trappist the monk (talk) 22:44, 15 December 2014 (UTC)

Display parameters: do we need them?[edit]

Discussion split from above.

That then begs the question: do we need any of the display parameters for CS1? I have previously expressed that if the Vancouver or other style is to be used, then a specific template should be created. And now we have {{vcite2 journal}} for just that purpose. Would it be possible to change the display parameters so that they can only be called by another module or template? This discussion may need to be split as it is straying from the original topic. --  Gadget850 talk 22:54, 15 December 2014 (UTC)

I don't think that there is a way of 'denying' the use of a parameter except by using the value assigned to CitationClass as a qualifyier. We have parameters that only work with one template: |mailing-list= only works with {{cite mailing list}} because we look for CitationClass equals mailinglist which is set with {{#invoke:citation/CS1|citation|CitationClass=mailinglist}}. Yes, I agree, if the question to be discussed is :Do we need any of the display parameters? then we should split that off.
Trappist the monk (talk) 23:11, 15 December 2014 (UTC)
I see that |author-mask= is used for bibliography lists and I know |display-authors= is well used.
These parameters are generally used in conjunction with others to form a variant style.
  • |authorformat=
  • |author-name-separator=
  • |editor-name-separator=
  • |author-separator=
  • |editor-separator=
  • |name-separator=
  • |last-author-amp=
  • |postscript=
  • |separator=
We have a lot of inconsistent uses, such as Way of the Patriarchs where one cite template uses |author-name-separator=.
If CitationClass would do it, then that would be a solution. Set it to ExternalTemplate or the like. --  Gadget850 talk 00:15, 16 December 2014 (UTC)
I think that keeping |postscript= and |separator= has some value because the allowed editors to mix CS1 and CS2 and have the rendered styling be the same for all citations. Here is an admittedly poor example. Presume that the page primarily uses CS2 so |postscript= and |separator= are added to the CS1 {{cite press release}} so that it stylisically resembles the predominat CS2 style:
  • Smith, Bob; Jones, Joe (15 December 2014), "Press Release Title" (Press release), Big Big Newspaper 
  • Smith, Bob; Jones, Joe (15 December 2014), "Web Page Title", Website 
Trappist the monk (talk) 01:18, 16 December 2014 (UTC)
For that we should have |cs2=y. --  Gadget850 talk 01:56, 16 December 2014 (UTC)
Now that is the kind of good idea I was hoping for above. Is it loaded with unintended consequences? Can it be combined with |author-format=vanc into a single parameter that controls multiple display elements? – Jonesey95 (talk) 04:36, 16 December 2014 (UTC)
I strongly support the idea of having a single parameter to convert "cite" templates to CS2. Because {{citation}} doesn't provide the extra information in the second part of the "cite" template name, it's proved impossible to fully replicate some behaviours between the CS1 and CS2 templates (thus {{cite web}} can produce a title in double quotes without |website=; {{citation}} cannot). Hence users of CS2 are occasionally obliged to use "cite" templates with the ugly additions |separator=, |postscript=none. How about |style=cs2 with alternatives like |style=vanc? Peter coxhead (talk) 10:16, 16 December 2014 (UTC)
|cs2= would be for the occasional use where we need to mix with CS2 where {{citation}} simply does not work. If you are going to use the Vancouver style, then it needs to be used for all citations. The new {{vcite2 journal}} is a step in the right direction. With the name, it immediately establishes the citation style and allows follow on edits to conform. While doing parameter use searches, I found a number of articles with very inconsistent use; for example, Tropical cyclone has a number of uses of {{cite web}} but only one uses |author-separator=. There is another article where one citation uses |. There is currently no way to discover consistency within an article other than by scanning it by eye. --  Gadget850 talk 21:46, 16 December 2014 (UTC)
|cs2= would also be useful for using templates that provide a specific reference in cs1 style (example: {{Introduction to Algorithms}}) within a cs2-styled article, assuming those templates can easily be modified to pass that parameter along. But they would have to be individually programmed to do this, which makes it unlikely the {{cite doi}} can do this, unfortunately. —David Eppstein (talk) 21:56, 16 December 2014 (UTC)
It could be done. First, update the bot so it adds |cs2= to each new citation, then add |cs2= to each doi subtemplate, another bot job. But I'm not sure of the status of {{cite doi}}. --  Gadget850 talk 22:26, 16 December 2014 (UTC)
I think I prefer |style= because it's then relatively simple for an editor to copy a CS1 or CS2 template from a page using one style to a page using the other style. It's only one parameter so converting CS2 to CS1 would be {{citation |... |style=cs1}}.
Adding a pass-through |style={{{style|}}} to the templates listed at Category:Cite doi templates looks like a relatively simple bot task. Trolling Category:Mathematics source templates, Category:Citation Style 1 specific-source templates etc. should be just as simple.
Trappist the monk (talk) 23:02, 16 December 2014 (UTC)
Many templates recognise a |style= parameter, and it's almost always intended for a semicolon-separated list of CSS declarations, and as such is passed unchanged into the style="..." attribute of some HTML element. We should not introduce confusion by using |style=cs2 (or variations on that) for a completely unrelated purpose - at some point somebody will attempt to use |style=background-color: yellow; border: 1px solid blue; font-family: Times,serif; and wonder what went wrong. --Redrose64 (talk) 00:42, 17 December 2014 (UTC)
Redrose64 has a good point. Maybe |citation-style= or |citation-format= instead. – Jonesey95 (talk) 03:37, 17 December 2014 (UTC)
When editors wonder what went wrong: Check |style= value (Help)? I like to think that most editors are clever enough to understand a word's meanings in when it is used in different contexts.
Alternate names: |styling=, |mode=, |form=, |appearance=
Trappist the monk (talk) 11:57, 17 December 2014 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── For the sake of argument, let us assume that we have or will settle on a parameter name that is both descriptive and not likely to be confused for some other parameter. In the discussion that follows, I use |<style>= to identify this unnamed parameter. What is required to implement this functionality?

  1. create the new parameter – not required in all CS1/2 templates; when not used, default values used according to the value assigned to CitationClass
  2. define the values that it will accept
    1. cs1
    2. cs2
    3. vanc – this sub-style only applies to author/editor lists so |author-format=vanc can only modify |<style>= author/editor related settings
    4. are there others?
  3. define the list of existing parameters that will be obsoleted by this new parameter
    1. |author-name-separator=
    2. |editor-name-separator=
    3. |author-separator=
    4. |editor-separator=
    5. |name-separator=
    6. |separator=
    7. are there others?
  4. in Module:Citation/CS1/Whitelist mark these parameters as deprecated
  5. in Module:Citation/CS1 and Module:Citation/CS1/Configuration create code that allows for |<style>= and/or these deprecated parameters in a citation. When they coexist, the value in |<style>= controls.
    1. define default values:
      1. |author-name-separator= and |editor-name-separator= functionality (combined): separator character is comma; when |author-format=vanc, space
      2. |author-separator= and |editor-separator= and |name-separator= functionality (combined): separator character is semicolon; when |author-format=vanc, comma
      3. |separator= functionality: separator character is period (CS1), comma (CS2)
  6. in Module:Citation/CS1 and Module:Citation/CS1/Configuration create error message code for times when |<style>=value is not one of the defined values
  7. after the change has been taken live, create a script or bot task to remove the deprecated parameters
    1. if |separator=, and CitationClass is CS1 then |<style>=cs2
    2. if |separator=. and CitationClass is CS2 then |<style>=cs1
  8. after the number of these deprecated parameters in Category:Pages containing cite templates with deprecated parameters has been reduced to an acceptable level, obsolete the deprecated parameters and modify Module:Citation/CS1 accordingly.

What did I miss? Shall I proceed?

Trappist the monk (talk) 16:40, 18 December 2014 (UTC)

I don't understand the remark about not being needed in all CS1/CS2 templates, unless you mean the ones that are not handled by the LUA module. It seems to me that CS2 is close to the styles generally used outside Wikipedia for footnotes and endnotes, while CS1 is close to the style usually used outside Wikipedia for bibliographies, lists of works cited, etc. I can't think of a single kind of work that couldn't be cited with either an endnote or a bibliography entry, depending on the citation style adopted for a particular article. Thus, I can't think of any kind of work that wouldn't need both CS1 and CS2 available. Jc3s5h (talk) 18:21, 18 December 2014 (UTC)
I presume that you are referring to not required in all CS1/2 templates; ... I meant that CS1/2 templates default to their 'native' set of separators. We don't need to have {{citation |title=...|style=cs2}} because the module will assign the defaults to the rendered citation based on what CitationClass tells it. CitationClass is a parameter passed to the module as part of its invocation. Here is the module invocation for {{citation}} (which I notice is out of date because |separator=, |ref= and |postscript= are set to their defaults inside the module):
{{#invoke:citation/CS1|citation |CitationClass=citation |separator=, |ref=harv |postscript=}}
Trappist the monk (talk) 18:37, 18 December 2014 (UTC)
I propose cite-format. --  Gadget850 talk 20:19, 18 December 2014 (UTC)

Postscript[edit]

I did insource searches for these parameters:
  • |authorformat= found 991 (scap & vanc)
  • |author-name-separator= found 642
  • |editor-name-separator= found 1
  • |author-separator= found 4356
  • |editor-separator= found 2
  • |name-separator= found 2
  • |last-author-amp= found 1
  • |postscript= found 12247 (insource:/\|\s*postscript/) "|postscript=—Based on the Random House ...", "|postscript=<!--None-->", "|postscript=<!-- Bot inserted parameter. ...", "|postscript=none"
  • |separator= found 2901 (insource:/\|\s*separator/)
|postscript= is, I think, going to be the most difficult parameter because it is (mis)used in a variety of ways. |postscript=<!--None-->, is the same as |postscript= which does nothing; |postscript=none specifies no postscript character which functionality would be handled by |style=cs2; these can be removed by bot or script. Parameters like |postscript=—Based on the Random House ... are problematic because they may contain useful information. It would seem that for such use where the value assigned to |postscript is not a single character or html entity or hidden inside &<lt;!--...-->, then such text should be moved so that it follows the citation template's closing }}. And then there is this which is added by Citation bot: |postscript=<!-- Bot inserted parameter. Either remove it; or change its value to "." for the cite to end in a ".", as necessary. -->{{inconsistent citations}}. What do we do about that? If it has value, it can be moved outside the citation template.
Trappist the monk (talk) 12:31, 16 December 2014 (UTC)
Re including non-trivial text in postscripts: I don't do this, but one reason some editors might want to use in combination with |ref=harv linking, so that the added text stays within the text that is highlighted by clicking on the reference link. —David Eppstein (talk) 17:00, 16 December 2014 (UTC)
David Eppstein@ Do you have an example? Perhaps we should test |postscript for values over one character and put them in a hidden category so we can see what we are dealing with. This field was only intended for the terminating character of the citation, not for elements of a citation. --  Gadget850 talk 18:06, 16 December 2014 (UTC)
I think most examples are likely better handled either by |at= or by just putting the text after the reference. (I agree with you re the intended use of postscript, and only use it for that myself, but any time we provide a convenient but semantically-wrong parameter for producing text in some kind of format, you know there will be editors who use it.) One style that I sometimes use is "(reference). As cited by (parenthetical cite of other reference)." for situations where it is clear from the other reference that the first reference is the appropriate one to cite for some piece of information but I haven't been able to track it down and read it myself. I think it's ok that the "As cited by" part doesn't get highlighted, but others could disagree. I'll also sometimes put "Reprinted in..." information following a reference to the original publication of some work. —David Eppstein (talk) 18:23, 16 December 2014 (UTC)

Formatting of Cite news "issues" value not clear[edit]

We currently format the Cite news and Cite web as follows:

In my opinion it is not clear that "2001" is an issue number. It is also also ambiguous with a date (especially when compared to the output of Cite web). Would formatting it as "issue #2001" be an improvement? Krinkle (talk) 05:48, 17 December 2014 (UTC)

Perhaps. The rational behind certain styling choices may (or may not) be found in an archive somewhere. Isn't it true that the vast majority of newspapers, and consequently citations to same, are dated? Redrawing your examples:
{{cite news |author=Author |title=Title |newspaper=Newspaper |url=//example.org |date=24 July 2001 |issue=2001}}
Author (24 July 2001). "Title". Newspaper (2001). 
{{cite web |author=Author |title=Title |url=//example.org |website=Website |date=2001}}
Author (2001). "Title". Website. 
the same without author:
{{cite news |title=Title |newspaper=Newspaper |url=//example.org |date=24 July 2001 |issue=2001}}
"Title". Newspaper (2001). 24 July 2001. 
{{cite web |title=Title |url=//example.org |website=Website |date=2001}}
"Title". Website. 2001. 
|issue= is also closely associated with |volume=. How would you render |issue= when |volume= is present?
Trappist the monk (talk) 11:42, 17 December 2014 (UTC)
It appears we uses the APA style here.[3] --  Gadget850 talk 13:55, 17 December 2014 (UTC)
To summarize what Gadget850's link says, the issue is not the date the issue was published. Academic journals, and some magazines, are formally identified by volume and issue. Usually, a volume consists of all the issues printed during a year. The first year of publication would be volume 1, and so on. Each issue within the year is assigned a number (or sometimes an alphanumeric name, such as S1 for the first special issue). So the issue of QST I have at hand is volume 98 (the 98th year of publication) issue 12 (they print 12 issues per year; 12 is the December issue). Jc3s5h (talk) 14:12, 17 December 2014 (UTC)
I believe that in Krinkle's example, the 2001 is an issue number.
  • "Title". Newspaper (2001). p. 28. 
  • "Title". Newspaper (2001). December 17, 2014. p. 28. 
  • Last, First (December 17, 2014). "Title". Newspaper (2001): 28. 
  • Last, First (December 17, 2014). "Title". Newspaper (2001). p. 28. 
--  Gadget850 talk 14:24, 17 December 2014 (UTC)
I believe Krinkle has probably misused the issue parameter to indicate the year (especially since the date is also 2001). Most publications set the issue number back to 1 at the beginning of each year, and it is unlikely a newspaper will have 2001 issues in a single year. (However, today's New York Times is Vol 164 issue 56,718. Apparently the NYT never resets the issue number and in the last 164 years they have published 56,718 issues.) Example:
  • Ivory, Danielle; Ruiz, Rebbecca R. (December 17, 2014). "Recalls of Cars Abroad Prompt No U.S. Urgency". New York Times 164 (56,718). 
It is confusing if the editor fails to supply a volume parameter. Perhaps a solution is to create an error message if the issue (or the synonym number) is given but the volume is not given. Jc3s5h (talk) 15:20, 17 December 2014 (UTC)
Jc3s5h (talk) 15:11, 17 December 2014 (UTC)
While I can't point a finger at one, I'm pretty sure that I've seen citations that correctly used |issue= or |number= without |volume=.
Trappist the monk (talk) 16:05, 17 December 2014 (UTC)
Here's an actual journal that uses "number" but does not organize issues by volume at all: http://www.reei.org/revista/anteriores.php. I have seen others cited in WP. – Jonesey95 (talk) 17:34, 17 December 2014 (UTC)

────────────────────────────────────────────────────────────────────────────────────────────────────The documentation from 2007 for cite journal had this to say:

  • volume: Volume number of the journal in which the article is found
  • issue: Issue number of the journal in which the article is found

It seems the process of combining the documentation from all the cite templates into one has confused the meaning of volume and issue. They really have different connotations for periodicals than they do for books or websites. (Books don't have issues, and who knows what "issue" would mean for a website.) Clearly our format was chosen to present either a volume and issue, or a volume alone (the latter would be appropriate if the page numbering is continuous throughout the volume). So if we want to keep the format the way it is, we shouldn't allow issue without volume; let the editor put suitable wording in the "at" parameter. If we want to support issue alone, we need to change the format of the citation as presented to the reader. Jc3s5h (talk) 17:47, 17 December 2014 (UTC)

Another comment: if the location of the date were made consistent, always the second element, after the author(s) if there are any, or after the title if there are no authors, it would at least be clear that a number in parentheses later in the citation isn't a date. This is already on the list of things to do. Jc3s5h (talk) 18:00, 17 December 2014 (UTC)

We cannot assume that |issue=n without |volume= is an error. The use of issue numbers is not confined to academic journals; many other periodicals - including newspapers and magazines - have issue numbers and not all have volume numbers. --Redrose64 (talk) 19:15, 17 December 2014 (UTC)
Something else that could be noted, is that volume and issue aren't exactly useful information for newspapers. If I were to look for today's edition of The Mining Journal, the local paper for my hometown, and I needed to pull it off microfilm, I'll be looking by "December 17, 2014", not "volume 12, issue 349" because the libraries don't index the volume/issue numbers on the microfilm reels. On the other hand, if I'm looking at my local university library for academic journals, they'll usually be bound by volume number. Sometimes they might be bound, microfilmed, or digitized by year of publication. Magazines could be either way, but by date is more common in my experience.
Anyway, I'd be in favor of setting up {{cite news}} and {{cite journal}} to use the "VV (II): pp" format consistently unless only a page or page range is provided, at which point the "p." or "pp." appears. Imzadi 1979  21:36, 17 December 2014 (UTC)

There are actually two distinct meanings of "volume" for books, by the way. If the book is part of a numbered series, indicated in our templates with |series=, then |volume= is its number in that series. And if it is a single book that for reasons of length was split into multiple volumes, but is not part of a series, and we want to refer to something in one of those volumes, then |volume= indicates which one. Often the individual volumes have subtitles as well but then it works better to put that in the title: |title=Winning Ways for your Mathematical Plays, Vol. I: Games in General. I don't know of a good way of indicating both kinds of volumes for the same book (as sometimes happens) using |volume= parameters. And I don't know of a good way to indicate the multiple-pieces-of-a-single-text meaning for a book that also indicates the series it's in, e.g. my copy of Heath's Euclid is published in three volumes (further split into 13 books, something else we don't have a good way to indicate) but is part of the unnumbered series "Dover Books on Advanced Mathematics". —David Eppstein (talk) 21:25, 18 December 2014 (UTC)

CS1/2 templates and voulme/issue/page(s)/at
template volume issue page(s) at
{{citation}} Yes Yes Yes Yes
{{cite AV media}} No No No ?
{{cite AV media notes}} No No Yes Yes
{{cite book}} Yes Yes Yes Yes
{{cite conference}} Yes Yes Yes Yes
{{cite DVD notes}} No No Yes Yes
{{cite encyclopedia}} Yes Yes Yes Yes
{{cite episode}} No No No ?
{{cite interview}} No No No ?
{{cite journal}} Yes Yes Yes Yes
{{cite mailing list}} No No No X
{{cite map}} Yes Yes Yes ?
{{cite news}} Yes Yes Yes Yes
{{cite newsgroup}} No No No X
{{cite podcast}} No No No ?
{{cite press release}} No No No X
{{cite report}} ? ? Yes Yes
{{cite serial}} No No No ?
{{cite sign}} No No No X
{{cite speech}} No No No X
{{cite techreport}} ? ? Yes Yes
{{cite thesis}} No No Yes Yes
{{cite web}} No No ? Yes

A previous post in this thread got me wondering where use of the various parameters |volume=, |issue=, |page(s)=, and |at= is appropriate. So I concocted this table. It seemed to me that |at= might have application in any template but, for those templates where the at column is  ? , a better in-source location identifier parameter exists or should exist: |time=, |minutes= comes to mind; for maps we have |section=.

For those templates where the at column is  X , it isn't clear to me that there is much use for |at=, but I could be persuaded either way.

In the other columns,  ?  marks parameters and templates where I'm not sure that the parameters should be supported but can imagine that there are times when they should.

So then the question is: what do we do with this? Do we do nothing? Do we make decisions about the templates/parameters marked  ?  and  X  and then adopt the result of the decisions?

Trappist the monk (talk) 14:05, 19 December 2014 (UTC)

The documentation for cite interview and speech both indicate they may be used for published works, not just broadcasts. Press releases may extend over several pages on occasion. So the page/pages parameters apply to these. In the case of interviews, they are often contained in magazines or newspapers, so all the parameters for cite journal apply to cite interview. Jc3s5h (talk) 15:24, 19 December 2014 (UTC)