Help talk:Citation Style 1

From Wikipedia, the free encyclopedia
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.

Transcript parameter for cite podcast[edit]

Can a parameter for linking to a transcript be added to Template:Cite podcast?-- Brainy J ~~ (talk) 16:01, 13 June 2014 (UTC)

We already have |transcript-url= in the CS1 module, but it appears that it is not currently used in any citations that use the CS1 module for rendering (I could be wrong). It is used in {{cite serial}} and {{cite episode}}, but those still use the old citation/core code. Adding it to cite podcast should be straightforward but would take some new code. Let's see if it works already:
Cite podcast compare
{{ cite podcast | host=Jack Handey | title=Deep Thoughts with Jack Handey, episode 123 | transcript=Episode 123 transcript | transcript-url= | url= }}
Old Jack Handey. "Deep Thoughts with Jack Handey, episode 123" (Podcast).
Live Jack Handey. "Deep Thoughts with Jack Handey, episode 123" (Podcast). 
Sandbox Jack Handey. "Deep Thoughts with Jack Handey, episode 123" (Podcast). 
No, it looks like it doesn't work yet. – Jonesey95 (talk) 19:41, 13 June 2014 (UTC)
  1. What is the purpose of local TranscriptAssemble?
  2. Shouldn't we first find out why terminal punctuation isn't present before hard coding the terminal period in the way that you have done it here?
  3. Do you have test cases that show that your changes do no harm when |transcript-url= is missing or empty?
Trappist the monk (talk) 23:24, 1 July 2014 (UTC)

────────────────────────────────────────────────────────────────────────────────────────────────────I've tried again; I've corrected the needed modifications and included testcases below. The test citation template is {{cite podcast/sandbox2}}, which invokes the modified Module:Citation/CS1/sandbox4, which calls the modified Module:Citation/CS1/Configuration/sandbox3. The only change in the configuration module not documented below is that Module:Citation/CS1/sandbox4 calls Module:Citation/CS1/Configuration/sandbox3 under function z.citation(frame) rather than Module:Citation/CS1/Configuration/sandbox. (I was loathe to edit existing sandboxes for fear of disrupting other testcases; I don't know what standard practice is with regard to the sandboxes.)

Two parts of Module:Citation/CS1 need to be modified:

Line numbers 1817–1821


   if is_set(Transcript) then
       if is_set(TranscriptURL) then Transcript = externallink( TranscriptURL, Transcript ); end 
   elseif is_set(TranscriptURL) then 
       Transcript = externallink( TranscriptURL, nil, TranscriptURLorigin ); 

Proposed modification: (I added some additional line breaks to make the code more readable.)

   if is_set(Transcript) then 
       if is_set(TranscriptURL) then 
           Transcript = sepc .. " " .. externallink( TranscriptURL, Transcript ); 
           Transcript = sepc .. " " .. seterror('transcript_missing_url'); 
   elseif is_set(TranscriptURL) then
       Transcript = sepc .. " " .. seterror('transcripturl_missing_transcript'); 
       Transcript = ""; 
Line number 1906


   local idcommon = safejoin( { ID_list, URL, Archived, AccessDate, Via, SubscriptionRequired, Lay, Quote }, sepc ); 

Proposed modification:

   local idcommon = safejoin( { ID_list, URL, Archived, AccessDate, Via, Lay, Transcript, Quote, SubscriptionRequired }, sepc ); 

Additionally, Module:Citation/CS1/Configuration will need two new error messages in the citation_config.error_conditions section. I don't know what determines whether an error message is hidden or not; I would think these should always show, but I could be mistaken. Note that the category called by the errors doesn't currently exist; if it shouldn't be created, please comment out the category name. (I personally see no harm in having a new error category; it is not likely to ever have very many pages in it, but would be useful in tracking this particular error.) Please let me know if I need to create the category.

Proposed insertion after line 364
   transcript_missing_url = { 
        message = '<code>&#124;transcript=</code> requires <code>&#124;transcript-url=</code>', 
anchor = 'transcript_missing_url',
category = 'Pages with transcripturl citation errors',
hidden = false },
   transcripturl_missing_transcript = { 
        message = '<code>&#124;transcript-url=</code> requires <code>&#124;transcript=</code>', 
anchor = 'transcripturl_missing_transcript',
category = 'Pages with transcripturl citation errors',
hidden = false },

To answer the questions above:

  1. I don't know the purpose of local TranscriptAssemble; it was present in the sandbox I edited; it is no longer part of the proposed modifications.
  2. The terminal punctuation was a flaw in the sandbox I was using. "Clean" sandboxes, with the changes above, eliminate this error.
  3. Here are the testcases:
    1. Includes both |transcript-url= and |transcript= with data in both:
      {{cite podcast/sandbox2 |title=Deep Thoughts with Jack Handey, episode 123 |host=Jack Handey |url= |transcript-url= |transcript=Episode 123 transcript}}
      Jack Handey. "Deep Thoughts with Jack Handey, episode 123" (Podcast). Episode 123 transcript. 
    2. Omits both |transcript-url= and |transcript=:
      {{cite podcast/sandbox2 |title=Deep Thoughts with Jack Handey, episode 123 |host=Jack Handey |url=}}
      Jack Handey. "Deep Thoughts with Jack Handey, episode 123" (Podcast). 
    3. Both |transcript-url= and |transcript= are present but empty:
      {{cite podcast/sandbox2 |title=Deep Thoughts with Jack Handey, episode 123 |host=Jack Handey |url= |transcript-url= |transcript=}}
      Jack Handey. "Deep Thoughts with Jack Handey, episode 123" (Podcast). 
    4. Only |transcript= is present, but empty:
      {{cite podcast/sandbox2 |title=Deep Thoughts with Jack Handey, episode 123 |host=Jack Handey |url= |transcript=}}
      Jack Handey. "Deep Thoughts with Jack Handey, episode 123" (Podcast). 
    5. Only |transcript-url= is present, but empty:
      {{cite podcast/sandbox2 |title=Deep Thoughts with Jack Handey, episode 123 |host=Jack Handey |url= |transcript-url=}}
      Jack Handey. "Deep Thoughts with Jack Handey, episode 123" (Podcast). 
    6. Both parameters are present; however, only |transcript= is populated; |transcript-url= is empty. This now emits an error message:
      {{cite podcast/sandbox2 |title=Deep Thoughts with Jack Handey, episode 123 |host=Jack Handey |url= |transcript-url= |transcript=Episode 123 transcript}}
      Jack Handey. "Deep Thoughts with Jack Handey, episode 123" (Podcast). |transcript= requires |transcript-url= (help). 
    7. Only |transcript= is present and populated; |transcript-url= is not present. This now emits an error message:
      {{cite podcast/sandbox2 |title=Deep Thoughts with Jack Handey, episode 123 |host=Jack Handey |url= |transcript=Episode 123 transcript}}
      Jack Handey. "Deep Thoughts with Jack Handey, episode 123" (Podcast). |transcript= requires |transcript-url= (help). 
    8. Both parameters are present; however, only |transcript-url= is populated; |transcript= is empty. This now emits an error message:
      {{cite podcast/sandbox2 |title=Deep Thoughts with Jack Handey, episode 123 |host=Jack Handey |url= |transcript-url= |transcript=}}
      Jack Handey. "Deep Thoughts with Jack Handey, episode 123" (Podcast). |transcript-url= requires |transcript= (help). 
    9. Only |transcript-url= is present and populated; |transcript= is not present. This now emits an error message:
      {{cite podcast/sandbox2 |title=Deep Thoughts with Jack Handey, episode 123 |host=Jack Handey |url= |transcript-url=}}
      Jack Handey. "Deep Thoughts with Jack Handey, episode 123" (Podcast). |transcript-url= requires |transcript= (help). 

I'm not adept at coding in Lua; I had hoped that someone with more knowledge would springboard off what I had discovered and make any further changes needed to comply with the rest of the template coding. I was trying to help move the process along; I hope this is enough to get the changes made with any additional modifications known to be needed by someone who's adept at this! I'm learning as I go; hopefully, I'll keep getting better at it. (I have experience in other coding languages; Lua/Scribunto is not among them; I've bookmarked the relevant reference manual.) Thanks!—D'Ranged 1 VTalk 11:33, 2 July 2014 (UTC)

I've been wondering if idcommon is the correct location of the transcript text. It seems reasonable to assume that the podcast could be archived, could require a subscription (which might make the use of |quote= desirable) would then make this:
Jack Handey. "Deep Thoughts with Jack Handey, episode 123" (Podcast). Archived from the original on 2014-07-02. Episode 123 transcript. "Quoted text.". (subscription required (help)) 
{{cite episode}} places the transcript after |series= by using {{citation/core}} parameter |Other= (|others=). Perhaps something similar should be considered for {{cite podcast}}. Here I've used |others=[ Episode 123 transcript] to mimic the positioning used by {{cite episode}}:
Jack Handey. "Deep Thoughts with Jack Handey, episode 123" (Podcast). Episode 123 transcript. Archived from the original on 2014-07-02. "Quoted text.". (subscription required (help)) 
As an aside, I'm thinking that the position of the subscription note should be moved so that it is the last thing rendered in the citation.
Trappist the monk (talk) 14:10, 2 July 2014 (UTC)
I agree with moving subscription to the end; I've done so and your example above parses better. Below is an example testing the use of |registration= rather than |subscription= to ensure that it also falls at the end of the citation:
Jack Handey. "Deep Thoughts with Jack Handey, episode 123" (Podcast). Episode 123 transcript. Archived from the original on 2014-07-02. "Quoted text.". (registration required (help)) 
As for the placement used by {{cite episode}}; I dislike that the archive information appears after the transcript; it's less clear what is archived, the podcast, or the transcript?
It occurs to me that the transcript might be archived or require a subscription as well; do we want to go there?—D'Ranged 1 VTalk 16:37, 2 July 2014 (UTC)
Trappist the monk Will the changes above be implemented soon?—D'Ranged 1 VTalk 13:34, 3 August 2014 (UTC)
Perhaps; just now beginning to return from Wikibreak. Is there really a need for the |transcript= requires |transcript-url= error message?
Trappist the monk (talk) 14:14, 10 August 2014 (UTC)
I don't care about the error messages one way or the other; I would like to see the corrections included in the forthcoming update to the code since the original request for this fix was two months ago. What are your obejctions?—D'Ranged 1 VTalk 19:57, 18 August 2014 (UTC)

Restore error message style[edit]

This change to the css styling for the <code>...</code> tag has, in my opinion, buggered up the error messages emitted by Module:Citation/CS1. The new css is at skins/common/commonElements.css.

Before the change, CS1 error messages had this look:

|accessdate= requires |url=

After the change, the same error message looks like this:

|accessdate= requires |url=

With a small modification to override the text color (<code style="color: #cc0000;">...</code>), we could get this:

|accessdate= requires |url=

I think that we should return to the previous styling. There is no need to draw little boxes around the parameters displayed in error messages. To do that, I will replace <code>...</code> in error messages with <kbd>...</kbd> which seems to be the most appropriate tag; see The kbd Element.

Trappist the monk (talk) 14:07, 10 August 2014 (UTC)

Good. I've also proposed the change at {{para}} which is oft used here.
Trappist the monk (talk) 15:58, 10 August 2014 (UTC)
Support. I think the old styling was clear and uncluttered, while the new styling is too cluttered. – Jonesey95 (talk) 03:26, 11 August 2014 (UTC)
Or use <code style="color:inherit; border:inherit; padding:inherit;"> as recommended at VPT, to preserve the semantic meaning. – Jonesey95 (talk) 22:36, 11 August 2014 (UTC)
This is wrong; we don't abandon use of the correct markup to get around a style issue; just fix it with CSS. <kbd>...</kbd> is for examples of user input (i.e. the values of parameters), not the parameter= code! It's semantically incorrect to use kbd this way. Use Jonesey95's CSS fix, above.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  11:45, 13 August 2014 (UTC)
It's debatable. <code> is appropriate in that the parameter names and values are a kind of source code. But the problem was probably created by an editor typing incorrect or incomplete information on a keyboard, and will need to be corrected by an editor typing the appropriate information on a keyboard. By the way, where are these tags documented anyway? Jc3s5h (talk) 11:54, 13 August 2014 (UTC)
<kbd>...</kbd> is documented at w3c.
Trappist the monk (talk) 12:02, 13 August 2014 (UTC)
@SMcCandlish: Not Jonesey95's CSS fix - mine. See Wikipedia:Village pump (technical)/Archive 129#Displaying 'code' font text and search for "inherit".
@Jc3s5h: The HTML 5 documentation begins here and the various HTML elements concerning semantics are described in section 4.5 Text-level semantics. This includes: 4.5.12 The code element; 4.5.13 The var element 4.5.14 The samp element 4.5.15 The kbd element. If you examine the source for that page, you'll see just how often the <code>...</code> element is used. --Redrose64 (talk) 15:12, 13 August 2014 (UTC)
@Redrose64: Okay; I'm just going by what I see, above, where it was posted by Jonesey95.
@Jc3s5h: It's not "kind of" source code, it is source code, just at a different level than that code in the "Template:..." page itself. By way of analogy, Javascript is source code, but it's not the same source as that of JS interpreter written in Java built into a Java-based browser. The element is for marking up literal keyboard input that is not source code. Even wikitext markup like This is italic, while this is bold is source code (we call it wikisource and source-view editing for a reason), and definitely not within the intended uses of <kbd>...</kbd>, except in quite peculiar circumstances. E.g., perhaps if I were explaining on Simple Wikipedia, "How to make text italic: First type '' (two single-quote characters in a row)), then the word or words you want to make italic, then finish by typing '' again". Even then purists would say to use <code>...</code> because the input in question is the input of source code, and kbd does not mark up source code.
Anyway, the real question before us is whether to override the changes to <code>...</code> at all in this particular case. I'm in favor of doing so, because the boogering of this template's error message output is an unintended consequence of CSS changes to the element.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  19:02, 13 August 2014 (UTC)

In Module:Citation/CS1/sandbox I have overridden the default commonElements.css definition for <code>...</code> to <code style="color:inherit; border:inherit; padding:inherit;">...</code>.

Cite book compare
{{ cite book | accessdate=17 September 2014 | title=Title }}
Live Title. 
Sandbox Title. 

Trappist the monk (talk) 13:37, 16 August 2014 (UTC)

Indroducing "print year" in addition to "year"[edit]

(noticing that I have been redirected to this talk page via the talk page of Template:Cite journal, the following refers to articles in academic journals)

A number of bibliographic databases have introduced the parameters "print year" and "online year", due to the increasing problem of articles being originally published electronically one year and then published in print one or two years later. A journal article is considered published in the year it was first published (usually electronically these days), but that year might be a different year than the year the print issue appears. I suggest we add at least "print year", to be used with volume, issue, pages etc, when the electronic version that the doi usually refers to was published in a different year.

Example: If I published the article "The reliability of Wikipedia articles" in the Journal of Wikipedia Studies, that started publication with Volume 1 in 2014, it would usually first appear only electronically, and be cited as:

  • Bjerrebæk, J. (2014). "The reliability of Wikipedia articles". Journal of Wikipedia Studies. doi:10.2307/1321160. 

But then, a year later, in 2015, the editors would finally manage to squeeze the article into the print issue Vol. 2, Issue 1, and then we have, according to the current template:

  • Bjerrebæk, J. (2014). "The reliability of Wikipedia articles". Journal of Wikipedia Studies 2 (1): 50–65. doi:10.2307/1321160. 

Here we would need a parameter to indicate that the print version (Vol. 2, Issue 1, pp. 50–65) appeared in 2015, not in 2014. Changing the "year" parameter from 2014 to 2015 would not be acceptable, because the work originally appeared in 2014 and may be cited as such by other literature. Bjerrebæk (talk) 11:06, 13 August 2014 (UTC)

Just use year for the publication being cited, and orig. year for the earlier distribution. Clarify the /doc on this specific use case. No need for yet another parameter, very real as the problem is. I've used precisely this method to resolve it before, with no issues being raised.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  11:38, 13 August 2014 (UTC)
Aren't we supposed to "say where we got it?" If I use the print version of your article, I would cite it pretty much the way you did except that I'd use |date=2015 and possibly |origyear=2014:
Bjerrebæk, J. (2015) [2014]. "The Reliability of Wikipedia articles". Journal of Wikipedia Studies 2 (1): 50–65. doi:10.2307/1321160. 
|origyear= (and |doi= or other online links) may not be appropriate if there were editorial changes made to facilitate the hardcopy format. You can also use |type= to distinguish between versions
Trappist the monk (talk) 11:51, 13 August 2014 (UTC)
If there were editorial changes that affected the content in a meaningful way, they are for WP purposes different sources, just like different editions of a book. If they didn't affect the content, then we don't need to care. This is too hair-splitty. Agreed we can use |type= in a case this "delicate", and then just move on. Any time spent agonizing over this kind of source massaging is time not spent on adding more sources.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  19:27, 13 August 2014 (UTC)
Agree. |publication-date= might be applicable in some instances.
Markup Renders as
{{cite book |last=White |first=T. H |title=[[The Book of Merlyn]] |year=1941 |publication-date=1977 |publisher=University of Texas Press}}
White, T. H (1941). The Book of Merlyn. University of Texas Press (published 1977). 
--  Gadget850 talk 15:08, 16 August 2014 (UTC)
|publication-date= should not be used because it is not mentioned in Help:Citation Style 1. Thus, no one knows what it means or when it should be used. Maybe it is only intended for internal communications between templates. Maybe it is deprecated and is only supported to keep from breaking old citations that have not been updated yet. Jc3s5h (talk) 16:33, 16 August 2014 (UTC)
|publication-date= is documented on most, if not all, CS1 template documentation pages which, I think, should be the first place editors should go for template parameter information.
Trappist the monk (talk) 16:45, 16 August 2014 (UTC)
Help:Citation Style 1 updated. --  Gadget850 talk 17:21, 16 August 2014 (UTC)

"At=" and "pages=" should NOT be considered redundant to each other for Cite Book[edit]

They have an obvious use case when citing a chapter from a book (which has a page range), but also one wants reference a particular page within e.g. JMP EAX (talk) 13:13, 16 August 2014 (UTC)

My workaround insofar for stuff like this was to use {{rp}} in addition to the citation, but it tends to clutter the page. And I don't really want to use the two-level notes/references system, because it's so unwieldy. JMP EAX (talk) 13:15, 16 August 2014 (UTC)

Looking at the example in question, I have no clue what is meant by |pages=175–252 and |at=Theorem 2.2, p. 190.

{{cite book |last1=Mateescu | first1=Alexandru |last2=Salomaa|first2=Arto |editor1-first=Grzegorz| editor1-last=Rozenberg|editor2-first=Arto| editor2-last=Salomaa |title=Handbook of Formal Languages. Volume I: Word, language, grammar |publisher=Springer-Verlag |year=1997 |pages=175–252 |chapter=Chapter 4: Aspects of Classical Language Theory |isbn=3-540-61486-9|at=Theorem 2.2, p. 190}}

--  Gadget850 talk 15:03, 16 August 2014 (UTC)

I don't think that this is a obvious use case. If |pages=175–252 defines the page range occupied by |chapter=Chapter 4: Aspects of Classical Language Theory then one or the other of those two parameters is redundant. In this case it would seem that |at=Theorem 2.2, p. 190 concisely identifies the location of the material that supports the claim in the article.
Trappist the monk (talk) 15:23, 16 August 2014 (UTC)
I think a slightly different case would be a good case to look at. The |chapter= parameter is intended treating a chapter in an edited book (which has an overall editor and chapters written by different authors) as a separate publication. But if the entire book is written by one book, and a particular claim is supported by an entire chapter of the book, as well as a few pages from another part of the book, you could use at = Chapter 5, Whatchamacallits | pages = 219–30 but the reader couldn't tell if you are citing Chapter 5 and pages 219–30, or you are indicating that Chapter 5 occupies 219–30. It would better to write at = Chapter 5, Whatchamacallits, also pp. 219–30. Unless we want to create permanent rules on template developers (fat chance) about how to combine |at= and |pages=, the results will be unpredictable and the results may confuse readers, either now, or the next time the template gets changed. Jc3s5h (talk) 16:49, 16 August 2014 (UTC)
I suppose I could make an ad-hoc rule to add the chapter page range as chapter=Chapter title (pp. XXX-YYY). It would be better if there were a chapter_pages parameter. JMP EAX (talk) 08:38, 30 August 2014 (UTC)
Not recommended. |chapter= is intended to hold the chapter heading; not the chapter heading plus some other stuff. Also, adding other stuff to |chapter= will corrupt the citation's COinS metadata. How would |chapter-pages= be used? How would the value assigned to |chapter-pages= render in a citation?
Trappist the monk (talk) 09:43, 30 August 2014 (UTC)

Update to the live CS1 module week of 2014-08-24[edit]

After the end of this week 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 the things: in Module:Citation/CS1:

  1. Normalize LCCN values before validation (discussion)
  2. Identify and categorize citations with |firstn= / |lastn= mismatch (discussion) Undone. See discussion.
  3. arXiv validation (discussion)
  4. change |CitationClass= tests to require unspaced class names for {{cite DVD notes}} and {{cite AV media notes}} (discussion)
  5. fix bug in |vanc= handling (discussion)
  6. instances of four consecutive spaces converted to tabs

in Module:Citation/CS1/Configuration:

  1. Identify and categorize citations with |firstn= / |lastn= mismatch
  2. Add hyphenated parameter name aliases (discussion)
  3. instances of four consecutive spaces converted to tabs
  4. override <code>...</code> css formatting for error messages (discussion)

in Module:Citation/CS1/Whitelist:

  1. Add hyphenated parameter name aliases

in Module:Citation/CS1/Date validation:

  1. Add support for "Winter YYYY–YY" (discussion)
  2. Add support for whole date range validation (dmy - dmy and mdy - mdy formats) (discussion and discussion 2)

Trappist the monk (talk) 13:59, 17 August 2014 (UTC)

Hooray! Our last update was at the end of March. A reminder that, after the update, if you see pages that still show an error message for something that should no longer show an error message, try purging (to refresh the display of the page) or null editing (to remove category membership) the page to fix it. There is more information in this VPT thread. – Jonesey95 (talk) 20:03, 17 August 2014 (UTC)
Trappist the monk I'm trying to modify the sandboxes to include the corrections for {{cite podcast}}; what's the problem?—D'Ranged 1 VTalk 19:52, 18 August 2014 (UTC)
It has been my practice to freeze new changes to the sandbox from the time I announce the update to the live module so that new changes don't disrupt seemingly settled changes. It also gives editors another chance to point out my failings before an update affects untold numbers of pages. As you can see from your post below, that last bit works.
Because you hadn't replied to my last post at Transcript parameter for cite podcast by the time I announced this update, I left it out.
Trappist the monk (talk) 21:44, 18 August 2014 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── Additionally, the current Module:Citation/CS1/Configuration/sandbox is rendering |id= erroneously as a Usenet ID; |publisherid= was deprecated in favor of using |id=. Wouldn’t it be easier to create a new |usenet= parameter?—D'Ranged 1 VTalk 20:25, 18 August 2014 (UTC)

Template Markup Renders
Example 1
  live {{Cite AV media notes |title=Artist Live! |others=[[Artist]] |year=2000 |url= |first=Malcolm |last=Johnson |page=1 |type=Liner notes |publisher=Arid Publications |id=Catalog no. K2145 |location=Los Angeles |accessdate=July 2, 2014}} Johnson, Malcolm (2000). Artist Live! (Liner notes). Artist. Los Angeles: Arid Publications. p. 1. Catalog no. K2145. Retrieved July 2, 2014. 
  sandbox {{Cite AV media notes/sandbox2 |title=Artist Live! |others=[[Artist]] |year=2000 |url= |first=Malcolm |last=Johnson |page=1 |type=Liner notes |publisher=Arid Publications |id=Catalog no. K2145 |location=Los Angeles |access-date=July 2, 2014}} Johnson, Malcolm (2000). Artist Live! (Liner notes). Artist. Los Angeles: Arid Publications. p. 1. Catalog no. K2145. Retrieved July 2, 2014. 
Example 2
  live {{Cite AV media notes |title=Artist Live! |titlelink=Album Title |others=[[Artist]] |year=2000 |first=Malcolm |last=Johnson |page=1 |type=Liner notes |publisher=Arid Publications |id=Catalog no. K2145 |location=Los Angeles}} Johnson, Malcolm (2000). Artist Live! (Liner notes). Artist. Los Angeles: Arid Publications. p. 1. Catalog no. K2145. 
  sandbox {{Cite AV media notes/sandbox2 |title=Artist Live! |title-link=Album Title |others=[[Artist]] |year=2000 |first=Malcolm |last=Johnson |page=1 |type=Liner notes |publisher=Arid Publications |id=Catalog no. K2145 |location=Los Angeles}} Johnson, Malcolm (2000). Artist Live! (Liner notes). Artist. Los Angeles: Arid Publications. p. 1. Catalog no. K2145. 
The Usenet problem appears to be caused by new code in Configuration/Sandbox that starts with ['USENETID'] = {. Also in the Module itself, search for the new code beginning with -- special case for cite newsgroup which uses |id= for a usenet article or post idJonesey95 (talk) 20:32, 18 August 2014 (UTC)
This discussion about migration of {{cite newsgroup}} was archived without answering the question of whether to use a new parameter, |message-id=, instead of |id=. Maybe that new parameter is needed. – Jonesey95 (talk) 21:15, 18 August 2014 (UTC)
Right, forgot about this half-done change. Thanks for the reminder. I think that I'll comment-out the relevant portions so that the rest of the update can proceed.
Trappist the monk (talk) 21:44, 18 August 2014 (UTC)

Done. In the process I discovered that the documentation for the old style arxiv identifiers does not mention versioning as the new style identifiers do. So, I wrote the original test so that versioning was only allowed in the new style. Turns out that old style identifiers may have versioning. I've fixed both the sandbox and the live versions of the module to correct this error.

Trappist the monk (talk) 11:55, 24 August 2014 (UTC)

Documentation needed[edit]

We need documentation sections on Help:CS1 errors for the new arXiv and first name / last name errors. Does anyone have a sandboxed version of those new sections yet? If not, I'll start drafting them in commented sections on the page.

The styling change for the error message means that we will need to re-style the error messages on the Help page as well. Is there a clever way to do this for the whole page, or do we need to edit each instance of code individually? – Jonesey95 (talk) 20:40, 18 August 2014 (UTC)

On my list of things to do before the update but I won't turn away willing help. I am unaware of any clever tricks except a change to common.css (which I don't think will fly). So, each <code>...</code> in the example error messages in Help:CS1 errors has to become <code style="color:inherit; border:inherit; padding:inherit;">...</code>.
Trappist the monk (talk) 21:44, 18 August 2014 (UTC)
Error message style in Help:CS1 errors done.
Trappist the monk (talk) 21:59, 18 August 2014 (UTC)
I have added commented documentation to the Help page. I think it will look right when it is uncommented, but I am not sure. Feel free to tweak my wording if it does not make sense; consider my work a first draft. – Jonesey95 (talk) 17:40, 19 August 2014 (UTC)
And I've rather heavily edited them. I split the author/editor list errors into two descriptions because they really are two separate conditions. I'm wondering if they shouldn't also have separate categories. Have a look.
Trappist the monk (talk) 14:51, 20 August 2014 (UTC)

────────────────────────────────────────────────────────────────────────────────────────────────────Your edits look fine to me. I might tweak the wording a bit after it goes live and I can see it in context, but I do not expect to make major changes.

I don't think we need separate categories. In both cases, |lastn= is missing. That's the fundamental error. Now that there are two sections, however, to which section will the "help" link direct editors?

I do think that a missing editor should report "missing |editor-lastn=" instead of "missing |lastn=". The current error message is "missing |lastn=", which is confusing and not strictly accurate.

Cite book compare
{{ cite book | editor1=Editor 1 | editor4=Editor 4 | title=Title | editor2=Editor 2 | displayeditors=29 }}
Old Title.
Live Editor 1; Editor 2 (eds.). Title. 
Sandbox Editor 1; Editor 2; Editor 4 (eds.). Title.  Missing |last3= in Editors list (help)

Is that difficult or easy to modify? – Jonesey95 (talk) 15:39, 20 August 2014 (UTC)

That's why the error messages identify the particular list where the error was found and also why I added the blurb about the error messages using a bit of shorthand. I'm sure that we can tweak the error messages to get what we want but I'd rather not do that just now. We can certainly refine them before the next update.
Trappist the monk (talk) 16:49, 20 August 2014 (UTC)

Rendering problem with right-to-left language and trans-title[edit]

Trappist the monk and others who might know the details of the Lua code: please see the following thread at VPT: Wikipedia:Village pump (technical)#Citations with title parameter in rtl language.2C beginning with numbers: Display issue and workaroundJonesey95 (talk) 16:32, 18 August 2014 (UTC)

That discussion now in archive 129.
Trappist the monk (talk) 14:20, 13 September 2014 (UTC)

self-referential authorlinks[edit]

Is there a guideline which recommends using the authorlink parameter to refer to the same article that the cite book tag appears in? In this edit summary, Damiens.rf contends, "this parameter IS to be used even in the case of the subject's being the author. It would give an error otherwise." I don't see why this would be the case, as such a usage does not fall within the normal recommendations on self links. Nick Number (talk) 18:18, 21 August 2014 (UTC)

The link is optional in all cases, and is merely a convenience link. --  Gadget850 talk 18:31, 21 August 2014 (UTC)
It is neither recommended nor not recommended; certainly not required as Editor Damiens.rf seems to imply. No errors will be incurred in either case. Including |authorlink= can be a minor benefit when editors copy CS1 templates from one article to another. I see no other benefit or harm.
Trappist the monk (talk) 18:39, 21 August 2014 (UTC)
I double checked: The one issue is that a link to the current page is bolded:
Help talk:Citation Style 1. title. 
I am sure we discussed adding CSS to fix this. --  Gadget850 talk 19:36, 21 August 2014 (UTC)
Wikilinks that point to the page you are reading are bolded and not linked. I don't know where or when that stylistic decision was made, but it seems to me that we should not override it in one small place in the project. – Jonesey95 (talk) 20:27, 21 August 2014 (UTC)
@Jonesey95:, you mean that article should use the bolded and not the linked version, right?
@Trappist the monk:, I see the bolding itself as a benefit, since it works as a useful interface hint. It points out that the reference's author is the subject of the article. --damiens.rf 16:48, 22 August 2014 (UTC)
I don't think that either linking or bolding is useful. By using the |authormask= parameter, the citation templates can show a pair of em-dashes instead, see John Marshall (railway historian)#Selected publications by John Marshall. --Redrose64 (talk) 18:49, 22 August 2014 (UTC)
|authormask= can only be used in bibliographies or shortened footnotes where the order of the list can be controlled. --  Gadget850 talk 22:36, 22 August 2014 (UTC)

So, should we use authorlinks for the article subject or avoid it? --damiens.rf 03:33, 28 August 2014 (UTC)

I'd reiterate my preference that, following the existing guideline in Help:Self link, self-referential links should be avoided. There's no reason to make a specific exception in the case of authorlinks. Nick Number (talk) 21:41, 2 September 2014 (UTC)
  • @Damiens.rf: I respect your position and your sincerity, but I've got to agree with Nick Number and others above. The bolding overemphasizes that the reference's author is the subject of an article, in a way that some of us find extremely distracting. It doesn't conform to the norms in Wikipedia. In previous discussions of self-links, there was a consensus that bolding was useful in navigation boxes. However, in the context of citations and references, it isn't commonplace, and I have not found examples (by other editors) where an authorlink or subjectlink is intentionally used for emphasis that the reference's author is the subject of the article. I believe that an ordinary reader will not need that visual cue in order to recognize who wrote the reference. To the extent that bolding might provide a visual suggestion that the credibility of the reference could be perceived as questionable, I trust that the average reader can recognize the author's name, and the potential self-interest of the author, and can use their own judgment about that without any need for bolding. Lwarrenwiki (talk) 22:37, 2 September 2014 (UTC)
    • I didn't know the was just a side effect of it being a self-link. I thought it was a decision made by the authors of the cite template. Things make more sense to me now. --damiens.rf 15:29, 3 September 2014 (UTC)

Symbol question.svg Question: What about citations that are stored on templates, rather than articles (e.g. {{cite doi/φ}}, {{cite isbn/ψ}}), and that might be transcluded ({{cite doi|φ}}) in multiple articles? Is there a way, at {{cite doi/φ}}, of having |authorlink1= only/not appear if Condition A & Condition B, or whatever? It Is Me Here t / c 10:20, 10 September 2014 (UTC)

I'm pretty sure that I'm not sure what it is that you are asking. What are the undefined Conditions A and B? What do your example redlinked templates have to do with CS1?
Trappist the monk (talk) 11:54, 10 September 2014 (UTC)
OK, so take Template:Cite doi/10.3897.2Fzookeys.31.261:
Stümpel, N.; Joger, U. (2009). "Recent advances in phylogeny and taxonomy of Near and Middle Eastern Vipers – an update". ZooKeys 31: 179–191. doi:10.3897/zookeys.31.261. 
Imagine that we had articles on both Nikolaus Stümpel and Ulrich Joger, and that that template had |author1link=Nikolaus Stümpel and |author2link=Ulrich Joger, and that it was transcluded on Nikolaus Stümpel, Ulrich Joger, and Viper. Would it be possible for the authorlink to appear in the template's citation IFF the template were not being transcluded in the article that the authorlink pointed to? So, Nikolaus Stümpel would just show "Stümpel, N." (no links, no bolding), but "Joger, U."; etc. (I know it's not a perfect example, since the authors' articles don't exist, but imagine they did.) It Is Me Here t / c 12:18, 10 September 2014 (UTC)
I think that it can be done in the module. The module has access to the current page information and uses that for proper categorization, COinS, and |language= support. I think that we can pass the current page name to listpeople() where author links are processed and either allow or disallow linking.
Trappist the monk (talk) 12:50, 10 September 2014 (UTC)
I've modified Module:Citation/CS1/sandbox so that it doesn't link the author's name if the link would be self-referencing. Here, this example citation from Angela P. Harris links her name. If you copy the citation to her page and preview it, her name isn't linked.
{{cite book/new | last1 = Harris | first1 = Angela P. |authorlink=Angela P. Harris | last2 = Bartlett | first2 = Katharine | title = Gender and law: theory, doctrine, commentary | publisher = Aspen Law & Business | location = New York | year = 1998 | isbn = 9781567067408 }}
Harris, Angela P.; Bartlett, Katharine (1998). Gender and law: theory, doctrine, commentary. New York: Aspen Law & Business. ISBN 9781567067408. 
|editorlink= should work the same way though I haven't tested it yet has been tested and works the same way.
I don't know what happens if |authorlink= links to a redirect (either with this fix or without it). If anyone knows of an author or editor who has redirect pages we can test that. If I set author name and page name to lower case before doing the compare that will account for differences in capitalization.
Trappist the monk (talk) 18:16, 10 September 2014 (UTC)
Elwyn Brooks White is a redirect to the page for author E. B. White. – Jonesey95 (talk) 19:10, 10 September 2014 (UTC)
Setting |authorlink=Elwyn Brooks White caused both the live and sandbox versions of the module to render a non-bold link to Elwyn Brooks White. This is not surprising and as long as they both act the same way I'm content.
Is this 'feature' worth keeping? There has been some discussion of the topic at Module talk:Citation/CS1/Feature requests#Check for wikilink to current page.
Trappist the monk (talk) 23:00, 10 September 2014 (UTC)
Personally, I think it's a very good feature, so thank you for taking the time to develop it. I can confirm that it works, not just for |authorlink=, but also for |authorlinkn= and |editorlinkn=. It Is Me Here t / c 11:05, 11 September 2014 (UTC)

Missing name detection in author/editor lists revisited[edit]

See this discussion. Because of that bug, the missing name detection is currently disabled in Module:Citation/CS1. I think that I have fixed the problem and at the same time improved, in a minor way, the performance of the missing name detector code. In the previous version, whenever |firstn= was missing |lastn= the test stopped at the first 'hole'. Now, the test continues until it fails to find |lastn= and |lastn+1=.

these produce correct CITEREF ids
  • Last1, Title 
  • Last1. Title. 
  • Last1; Last2; Last3 et al. (eds.), Title 
  • Last1; Last2; Last3 et al. (eds.). Title. 
missing |last2=, |last4=, |last6=
  • Last1; Last3; Last5; Last7, Title  Missing |last2= in Authors list (help); Missing |last4= in Authors list (help); Missing |last6= in Authors list (help)
  • Last1; Last3; Last5 et al. (eds.). Title.  Missing |last2= in Editors list (help); Missing |last4= in Editors list (help); Missing |last6= in Editors list (help);
|first2= and |first3= without |last2= and |last3=
  • Last1, First1; Last4, First4, Title  |first2= missing |last2= in Authors list (help); |first3= missing |last3= in Authors list (help)
  • Last1, First1; Last4, First4 (eds.). Title.  |first2= missing |last2= in Editors list (help); |first3= missing |last3= in Editors list (help)

What this also does is it creates more complete author/editor lists. Previously, the author/editor list would end at the first 'hole'. Similarly, the CITEREF id will now use the first four last names in the author/editor list whereas previously it would stop at the 'hole'.

Cite book compare
{{ cite book | editor-first3=First3 | editor-last4=Last4 | editor-first2=First2 | editor-first1=First1 | title=Title | ref=harv | editor-first4=First4 | editor-last1=Last1 }}
Live Last1, First1 (ed.). Title. 
Sandbox Last1, First1; Last4, First4 (eds.). Title.  |first2= missing |last2= in Editors list (help); |first3= missing |last3= in Editors list (help)

Trappist the monk (talk) 23:30, 24 August 2014 (UTC)

Nice work. The "missing name" category contains a few hundred articles that were added before the erroneous code in the module was found and disabled. I have looked at a few, and they do appear to contain missing author or editor names, so they are available for fixing by interested editors. Once the code above is re-enabled, I expect that we will see many more articles join this error category. – Jonesey95 (talk) 00:30, 25 August 2014 (UTC)

Template:Cite web (archive-url, archiveurl, archive-date, archivedate)[edit]

The horizontal and vertical full parameter sets use "archive-url" and "archive-date", while everything else on the page, including the TemplateData parameters and examples use "archiveurl" and "archivedate". It's fine if the template accepts both variants, but in my opinion, the page should either only use the variants with hyphen-minus or only those without. Opinions? -- (talk) 19:58, 25 August 2014 (UTC)

RefToolbar uses without hyphen, so that should be the preference. --  Gadget850 talk 20:22, 25 August 2014 (UTC)
There was a recent RFC that approved addition of hyphenated parameters for all multi-word parameters (e.g. access-date, a new parameter alias). The changes were just implemented a couple of days ago, so you may see some inconsistency in the documentation.
One problem with using |accessdate= instead of |access-date= is that inexperienced editors see a red line under |accessdate= and "correct" it as a spelling mistake, leading to a citation error (Example edits of this type: [1] [2] [3]). Moving toward hyphenated multi-word parameters as the default choice could help editors avoid this confusion and reduce the number of citation errors that gnomes need to fix. – Jonesey95 (talk) 21:17, 25 August 2014 (UTC)
I knew this would happen. They are aliases; they are equally valid. Don't change the unhyphenated form to the hyphenated (or vice versa) without good reason. --Redrose64 (talk) 15:11, 26 August 2014 (UTC)

Time to show date error messages?[edit]

Currently, errors categorized in Category:CS1 errors: dates are hidden, pending fixing of as many as reasonably possible by a bot. The hiding decision was a result of this RFC.

BattyBot task 25 has been processing Category:CS1 errors: dates periodically for about eight months now. When BattyBot is not running, date errors are added to the category at a rate of hundreds per week, maybe more. The category population was about 100,000 when BattyBot started running; it is about 60,000 now, and would be tens of thousands higher than 100,000 if not for the bot's work.

I have been working with GoingBatty, the bot's operator, to add more patterns to the list of bot-fixable errors. You can see the latest round of proposed fixes on GoingBatty's talk page, and there are many previous rounds of this exercise in that page's archives.

I believe that we have reached a point of diminishing returns with the bot, and that the bot has "run to sufficient completion" (quoting the RFC closure decision). I believe that the date error messages should be exposed by default to editors when the live version of the citation module is next updated. Thoughts? – Jonesey95 (talk) 02:30, 26 August 2014 (UTC)

I agree that it's unlikely we'll find many more patterns that will significantly reduce the number of errors, although suggestions will always be appreciated. I think our next task is to prepare ourselves (and others) for the onslaught of questions and concerns that will be raised when these errors are visible to all.
  • People will see a "(help)" link in the article, which will take them to Help:CS1 errors#bad date. Are there any improvements needed here, such as:
    • Maybe mentioning why other text in the date field is bad, and providing a link to a simplified explanation of WP:COinS with examples?)
    • A link to Wikiblame to help research accessdates?
  • From there, people will see a link to Wikipedia:Help desk. We should announce there (and where else? WP:VP/T?) when the errors are scheduled to be turned on, and ensure we have extra people checking there.
  • People may also follow the link to Help:Citation Style 1#Dates. Are there any improvements needed here?
  • What guidance will we give people who have valid dates that are flagged as false errors?
Thanks! GoingBatty (talk) 03:56, 26 August 2014 (UTC)
Do you know of any valid dates that are being flagged as errors?
Trappist the monk (talk) 13:00, 26 August 2014 (UTC)
Seasons (e.g., winter 2013) are being flagged as errors if they are capitalized, but seasons should not be capitalized. This is actually a subtle issue. If the separator between citation elements is a period, and each clause separated by a period is punctuated as a sentence, and if the season is the first word in one of these elements, then it should be capitalized. But if the separator between elements is a comma, or if the season is not the first word in the element, it should not be capitalized. Finally, neither our dates nor the date element in the APA style, is properly punctuated as a sentence, so it isn't clear that seasons should ever be capitalized. I'll poke around to see what other styles do. Jc3s5h (talk) 13:13, 26 August 2014 (UTC)
To clarify: seasons that are not capitalized are flagged as errors.
In the CS1 citations, the separator between elements is a period. In CS1 citations, season dates begin with the season. So clearly in CS1 citations, the season portion of a season date shall be capitalized.
So is your question: What should we do in the {{citation}} template citations where the separator between elements is a comma? And as a corollary: what should we do when CS1 citations override the period separator with some other character?
My answer to those is: nothing different. The element should take precedence over punctuation because the element is the important part. The element is not like the element type indicator words 'retrieved', 'archived', etc.
In the magazine and journal world, do those periodicals that use season dating capitalize the season on the cover of each issue? My experience is that they do; excepting those hipster periodicals that don't capitalize stuff for stylistic reasons and just because they're cool.
Seasons in dates in CS1 citations are roughly synonymous with months in dates. As such they should be treated in the same fashion.
Trappist the monk (talk) 14:37, 26 August 2014 (UTC)
I checked the APA Style Blog. Their advice is

If the periodical uses a season with the year, put the year, a comma, and the season in parentheses (2008, Early Spring).

But I think this requires some consensus; we don't automatically follow other style guides. The distinction between the period and comma separator still applies. Jc3s5h (talk) 13:20, 26 August 2014 (UTC)
APA style dates are not supported by MOS:DATE and in the example you've posted, the season is capitalized.
Trappist the monk (talk) 14:37, 26 August 2014 (UTC)
The last time I asked about unhiding hidden error messages, I got no real support. I remain in favor of showing error messages so I support showing the date error messages at the next CS1 update.
Trappist the monk (talk) 13:00, 26 August 2014 (UTC)
BattyBot's latest run, which incorporated the new fixes linked above, fixed only 500 articles, out of the 60,000 in the category, and many of those articles had errors introduced between the bot's last run (which finished a few days ago) and this one. I think the bot has reached a point of substantial completion and we have met the conditions of the RFC.
GoingBatty makes some good suggestions above. Let's make sure our documentation is in order before the next code update. I have tweaked the help text a bit already. – Jonesey95 (talk) 13:42, 27 August 2014 (UTC)
I think it is a bad idea to enable display of 60,000+ error messages at a stroke (I assume we're talking about just Category:CS1 errors: dates not Category:Pages using citations with accessdate and no URL‎ too). The intent can only be that they should all be fixed, but the sheer size of the task is demoralising and the payoff is uninspiring. Preparing thoroughly would be essential but not necessarily sufficient. I think it is also important to be seen to have prepared (What is the effort required? How long will it take? Why is that a favourable cost/benefit ratio?), and to have considered other options (Are |date= and |accessdate= equally important? Could we focus on probable typos over incorrect style? Do we really want to enforce MOS:BADDATEFORMAT regarding dd-mm-yyyy and mm-dd-yyyy? What about trading Category:CS1 errors: dates for Category:Pages with citations having bare URLs‎ and Category:Pages with citations lacking titles‎?). To try to understand some of this better I started my own analysis of the remaining errors here which may be of interest (eg help should address the most common errors first). Is that analysis worth taking further (the sample size is currently far too small), or is there a better analysis already available? I realise some of this has been covered in the past (possibly multiple times) but I find it hard to get a handle on what is agreed, what is still controversial, and what has not been discussed.TuxLibNit (talk) 20:33, 1 September 2014 (UTC)
@TuxLibNit: Thanks for putting together this analysis. Some comments:
  • I've updated my bot's code to fix mm/dd/yy where "dd" > 12 and "yy" = 13 or 14.
  • The bot can be updated to change undated to n. d., but I was hoping that CS1 would be changed so that undated would be acceptable.
  • While my bot normally fixes July/August 2010, it did not in this case because of the (unnecessary) brackets within the citation template.
  • 1997-98 needed to be changed to 1997–98.
  • Ministry of Defense (Kuwait) contained |date=May–June 2004|year=84|volume=3, which needed to be changed to |date=May–June 2004|volume=84|issue=3
  • My bot will now fix Octrober, and fixed all five existing instances
  • I had already updated the bot's code to not create ranges such as Winter 2003–1904, and fixed all existing instances.
The rest are misuses and/or typos that can be fixed manually, and the red error will help editors to notice the issues so they can be fixed. GoingBatty (talk) 21:43, 1 September 2014 (UTC)
I've manually fixed as many of the articles that TuxLibNit identified as I could. I would appreciate if others could provide input on the validity of using undated (see above) and work on fixing the following articles:
Thanks! GoingBatty (talk) 15:54, 4 September 2014 (UTC)
Re "undated", here is a previous discussion. Style guides (at least Chicago and MLA) say that "n.d." should be used, but I think that abbreviation is needlessly obscure. I think that "undated" or "no date" should be allowed. I would suggest taking this to MOS or a wider forum, but I have been told recently that MOS is not the right place for citation-specific discussions. A few editors are fond of reminding us that nearly any consistent citation style may be used, so can we just be bold and decide that "undated" is part of CS1's consistent citation style? That would be my preference. – Jonesey95 (talk) 16:44, 4 September 2014 (UTC)
As far as undated goes, if we're going to have a style, we should follow it. If you want to let folks do their own thing, just remove all the requirements from this page and scrap all the error messages and bots. Jc3s5h (talk) 16:42, 4 September 2014 (UTC)

Is there a decision here? If not, what about some of the other hidden error messages?

Category:Pages using citations with format and no URL – 2649 pages
Category:Pages using citations with old-style implicit et al. – 248 pages
Category:Pages using citations with old-style implicit et al. in editors – 1167 pages

or, dare I even suggest it:

Category:Pages containing cite templates with deprecated parameters – 27,815 pages (down from 163,762 pages on 4 January 2014)

Trappist the monk (talk) 12:50, 15 September 2014 (UTC)

Nobody has disagreed with the statement that BattyBot has run to substantial completion, so I believe we should show the date error messages.
I believe that we should also show the deprecated parameter errors. Monkbot and BattyBot have removed the vast majority of errors from this category (its population has decreased from 164,000 articles to 28,000!). A little tweaking of Monkbot's code to add a few more template aliases may remove another 1,000 or so, but that is "substantial completion" by any measure.
The "et al." messages should be shown. I have worked with Citation Bot and manual edits to get the two categories down from about 12,000 articles to less than 1,500. This one has also run to substantial completion.
I haven't examined the "format and no URL" category in detail, but I don't think it is tractable with a bot, so those errors should probably be exposed as well.
We'll have to be ready for some communication about these error messages from people new to the conversation. Let's remember to treat them gently. – Jonesey95 (talk) 13:19, 15 September 2014 (UTC)

Proposal on season capitalization[edit]


  • The editors of this documentation decided to incorporate the date rules in WP:Manual of Style and WP:Manual of Style/Dates and numbers.
  • The editors of the {{Citation}} documentation defer to this documentation for publication date format.
  • Those guidelines, and this documentation, only discuss the capitalization of season names in general, as one would find in a dictionary entry.
  • Two prominent citation guidelines, as a special case, call for capitalizing season names in citations. ( APA Style Blog and Chicago Manual of Style 16th ed. paragraph 14.180)
  • Several editors involved in the programming of the cite module and the bot that fixes citations to remove citation errors took it for granted that season names should be capitalized in citations.
  • Since Chicago considers it necessary to explicitly state that seasons are capitalized in publication dates, this is not something that "everyone knows" and what we write in this documentation does not apply to all citations, only CS1 and {{Citation}}.

Therefore I propose the following change, with new text underlined on the talk page, but there will be no underline when added to the main page:

Prescriptions about date formats only apply when the date is expressed in terms of Julian or Gregorian dates, or which use one of the seasons spring, summer, autumn or fall, winter. Sources are at liberty to use other ways of expressing dates, such as "spring-summer" or a date in a religious calendar; editors should report the date as expressed by the source. Although the seasons are not normally capitalized, they are capitalized when used as dates in CS1 templates, and the capitalization of the season stated by the source may be altered to follow this rule.

Jc3s5h (talk) 18:35, 26 August 2014 (UTC), modified to link to WP:SEASON at 20:16 UT.

Support. Thanks for taking the time to think this through thoroughly and write up the above. We might consider linking "are not normally capitalized" to WP:SEASON so that people will understand the basis for that use of "normally". – Jonesey95 (talk) 20:06, 26 August 2014 (UTC)
Support with a minor change of using "CS1" (without a space).
Suppoert—this mirrors how citations are done in the outside world. Imzadi 1979  01:57, 27 August 2014 (UTC)
Done. I made the change described. Jc3s5h (talk) 16:01, 28 August 2014 (UTC)

"Date in a religious calendar"[edit]

I'm adding this as a separate topic so I don't muddy the season topic. If an editor uses CS1 citation templates to record a "date in a religious calendar", how would they do so properly so they don't get an error? Thanks! GoingBatty (talk) 01:24, 27 August 2014 (UTC)

There are some things the error checking can't recognize. So the error message would just have to be tolerated. There are other dates the error checking can't handle, such as 43 BC. Limitations of the error checking code must never be used as an excuse to exclude a source, nor should bibliographic information be changed to a form that may make it more difficult to find the work in question, just to avoid error messages. Jc3s5h (talk) 01:46, 27 August 2014 (UTC)
IMO it is always wrong to tolerate an error message. Either the usage is invalid and the error must not be tolerated, or the usage is valid and the error message should be removed. I think this specific example is crying out for |ignore-date-error=yes or an equivalent.TuxLibNit (talk) 20:42, 1 September 2014 (UTC)

et al.[edit]

This section Help:Citation Style 1#et al. currently says: It is used to complete a list of authors of a published work, where the complete list is considered overly long. The term is widely used in English, thus it is not italicized per MOS:FOREIGN. However, MOS:FOREIGN first says: Foreign words should be used sparingly. and then Use italics for phrases in other languages and for isolated foreign words that are not current in English. I suspect that WP:MOS#Foreign words was the intended target, but that says: Use italics for phrases in other languages and for isolated foreign words that are not common in everyday English. Et al. is not common in everyday English, while is it common in scientific and academic citation. There does seem to be a US/UK split in usage of italics for et al. See also: Wikipedia talk:Manual of Style/Abbreviations#et al. revisited. --Bejnar (talk) 17:53, 27 August 2014 (UTC)

We have discussed this before:
  • Chicago Manual of Style, 16th ed. p.365: says that commonly used Latin words and abbreviations should not be italicized, and lists "et al." as an example.
  • APA states that "et al." should not be italicized.[4]
FYI: The Shortened footnotes templates also do not italicize et al. I should create a help subpage to detail this. --  Gadget850 talk 18:22, 27 August 2014 (UTC)
The italic form of et al. in Citation Style 1 citations was discontinued with this edit to {{citation/core}} on 9 March 2011. This change appears to have been made without objection. Since then, Module:Citation/CS1 continues to render et al. without italics markup.
Trappist the monk (talk) 18:29, 27 August 2014 (UTC)
This change appears to have been made without much discussion. As least I could not find it. All I found was this: Wikipedia talk:Manual of_ Style/Abbreviations/Archive 2#Et al.. --Bejnar (talk) 21:14, 27 August 2014 (UTC)
Here are more specific references:
  • The Chicago Manual of Style, 16th ed., section 7.73: "Roman for Latin Words and Abbreviations: Commonly used Latin words and abbreviations should not be italicized. ibid., et al., ca., passim."
  • The Publication Manual of the American Psychological Association 6th ed., p. 105: "Do not use italics for: foreign phrases and abbreviations common in English (i.e., phrases found as main entries in Merriam-Webster's Collegiate Dictionary, 2005). a posteriori, et al., a priori, per se, ad lib, vis-a-vis."
  • MHRA Style Guide (2008) p.35: "Certain Latin words and abbreviations which are in common English usage are also no longer italicized. For example: cf., e.g., et al., etc., ibid., i.e., passim, viz."
--  Gadget850 talk 23:26, 27 August 2014 (UTC)
MOS:FOREIGN is clear on this issue; it looks like the OP missed this section: "Loanwords and borrowed phrases that have common usage in English—Gestapo, samurai, vice versa—do not require italics. A rule of thumb is not to italicize words that appear unitalicized in major English-language dictionaries." – Jonesey95 (talk) 00:57, 28 August 2014 (UTC)

Slight tweak may be helpful in LCCN code[edit]

The LCCN syntax guide says "The prefix is optional; if present, it has one to three lowercase alphabetic characters." It looks like our current code does not, but should, display an error message when upper case letters are used in the prefix.

Here's an example of the "same" LCCN that links to the correct book when a lower case prefix is used, but which gives a "LCCN Permalink Error" when an identical LCCN with an upper case prefix is used.

Cite book compare
{{ cite book | last=International Labour Office | first= | publisher=International Labour Office | title=Indigenous peoples: living and working conditions of aboriginal populations | lccn=l54000004 | location=Geneva | year=1953 }}
Live International Labour Office (1953). Indigenous peoples: living and working conditions of aboriginal populations. Geneva: International Labour Office. LCCN l54000004. 
Sandbox International Labour Office (1953). Indigenous peoples: living and working conditions of aboriginal populations. Geneva: International Labour Office. LCCN l54000004. 

Cite book compare
{{ cite book | last=International Labour Office | first= | publisher=International Labour Office | title=Indigenous peoples: living and working conditions of aboriginal populations | lccn=L54000004 | location=Geneva | year=1953 }}
Live International Labour Office (1953). Indigenous peoples: living and working conditions of aboriginal populations. Geneva: International Labour Office. LCCN L54000004. 
Sandbox International Labour Office (1953). Indigenous peoples: living and working conditions of aboriginal populations. Geneva: International Labour Office. LCCN L54000004 Check |lccn= value (help). 

I will adjust the documentation for the error message. Can the module sandbox be changed to give error messages for upper case letters in the prefix?

If I am misreading the syntax guide, let me know. – Jonesey95 (talk) 06:08, 28 August 2014 (UTC)

Done. Good catch. I've tweaked your examples.
Trappist the monk (talk) 11:42, 28 August 2014 (UTC)

not exactly pleased with "origyear"[edit]

Often enough I need to add an original publisher (i.e. different from the present/current edition one). There's no actual field for this and the way this is crammed in the origyear field in the examples makes it look very bad because the whole field is rendered before the title, and you don't normally put the publisher before the title. JMP EAX (talk) 08:36, 30 August 2014 (UTC)

Why? The purpose of a citation is to identify where you read or saw a particular fact that supports text in the article. If you read or saw this fact in the current edition, then cite that edition; there is no need to include the publication history. In fact, adding information pertaining to an older edition to a citation referring to the current edition may only serve to confuse readers. If the older edition is important, include it as a separate citation.
If I misunderstand you, an example of where such a combined older/newer cite is required would be helpful.
Trappist the monk (talk) 09:52, 30 August 2014 (UTC)
Some other style guides say you should cite the earlier edition. Some reasons it could be helpful:
  • A reader who possesses the earlier edition will know substantially the same book is being used (depending on what kind of changes were made in the revision process).
  • If the reader has read other works, in addition to the Wikipedia article, which refer to the earlier edition, the reader will know substantially the same book is being used as a source.
  • By giving the earlier publication date, and the original publisher, the reader will realize the ideas in the book may be outdated, and can evaluate the reputation of the original publisher.
Jc3s5h (talk) 11:28, 30 August 2014 (UTC)
WP:SAYWHEREYOUGOTIT. Each instance of a Citation Style 1 template is tool to identify one source and one source only. It is not the responsibility of Wikipedia editors to divine what editions a reader may possess or may have read. That a source may be out dated is irrelevant. The purpose of a citation is to identify and support statements in article text regardless of currency or factual correctness.
Trappist the monk (talk) 11:52, 30 August 2014 (UTC)
Disagree. Jc3s5h (talk) 11:56, 30 August 2014 (UTC)
Different versions of a work can vary quite a bit. If there is a compelling reason to cite different versions of a work, then cite them separately. For example, I have the 1989 and the 2001 versions of Baden-Powell and there are a lot of differences. --  Gadget850 talk 12:48, 30 August 2014 (UTC)
It's not so much a matter of different editions as indicating derivation or descent of an edition. E.g., if you and I are comparing notes from Darwin's Origin of Species the publication dates of my Modern Library edition and your (let's say) Norton edition are likely less significant to each other than that one is from Darwin's fifth edition and the other from his first or second edition. Yes, we WP:SAYWHEREYOUGOTIT, but it helps, and doesn't hurt, to where that came from. ~ J. Johnson (JJ) (talk) 22:46, 30 August 2014 (UTC)
Yeah, if we are making comparisons, then knowing the publication history of each is important. But it is not the purpose of a citation – any citation, not just CS1 – to make comparisons between sources. The purpose of a citation is to say to the reader, "Look here. This is where I found that fact." Nothing more, nothing less. I think that adding unnecessary publication history to a citation is a disservice to readers.
If it is important to the reader to know about previous editions or other versions of the same work, add another citation. Don't try to pack two or more into one.
(Addendum) Lest we repeat ourselves, we have discussed this before. Trappist the monk (talk) 15:40, 31 August 2014 (UTC)
Trappist the monk (talk) 10:51, 31 August 2014 (UTC)
Chicago Manual of Style 16th ed. paragraph 15.38 disagrees with Trappist the monk. This is part of Chicago's chapter on their author-date system, so the reference list entry given below would be referred to with a parenthetical inline citation that would contain any necessary page numbers. The following citation may be found there as an example of an acceptable citation:

Austen, Jane. (1813) 2013. Pride and Prejudice. London: T. Egerton. Reprint, New York: Penguin Classics. Citations refer to the Penguin edition.

Jc3s5h (talk) 15:45, 31 August 2014 (UTC)
Fortunately, Chicago Manual of Style and Trappist the monk don't have to agree. Chicago Manual of Style is not CS1. CS1 is not designed to provide a provenance for each citation. CS1 is designed to meet the requirements established by WP:V and WP:SAYWHEREYOUGOTIT. To meet this particular clause of chapter 15.38, CS1 would need to be modified to support at a minimum |orig-location=, |orig-publisher=, and in-source locators |orig-page=, |orig-pages=, and |orig-at=. This is a complicating path upon which I think we should not venture.
Trappist the monk (talk) 17:50, 31 August 2014 (UTC)

────────────────────────────────────────────────────────────────────────────────────────────────────CS1 is not really designed, full stop. The existence of |orig-year= suggests some desire on the part of template users to be able to provide some information about earlier editions. At present, this could be done by following the citation template with additional text explaining the situation. In any case, Trappist the monk's statement "any citation, not just CS1" just isn't so. Jc3s5h (talk) 18:26, 31 August 2014 (UTC)

As you wish. CS1 is not designed in a formal engineering sense. It has evolved and adapted to the environment in which it exists. So let me rephrase the sentence: CS1 is not designed adapted to provide a provenance for each citation.
Rather than simply saying that [my] statement "any citation, not just CS1" just isn't so, perhaps you could explain why you believe that?
Trappist the monk (talk) 22:20, 31 August 2014 (UTC)
In context, the statement was "But it is not the purpose of a citation – any citation, not just CS1 – to make comparisons between sources. The purpose of a citation is to say to the reader, 'Look here. This is where I found that fact.' Nothing more, nothing less." But Chicago says sometimes it is useful to provide information about the earlier edition of a work; presumably the writer citing the source only has access to the later edition, but the front matter of the later edition may allow the citing author to make simple statements about how the original differs (if at all) from the later edition. For example, the later edition might contain the same text but be paginated differently, putting a reader with the original edition on alert that the material of interest may be on a different page than indicate in the citation.
APA style 6th ed. is more emphatic. Section 6.18, "Classical Works", states "When you know the original date of publication, include it in the citation." So two major citation guides say that you may (Chicago) or should (APA) provide information about an earlier edition which you did not consult. Hence the claim "any citation, not just CS1" just isn't so. Jc3s5h (talk) 23:44, 31 August 2014 (UTC)
You missed the point of my statement entirely. Editor J. Johnson introduced the notion of two editors (he and me) comparing different editions of a source. Comparison of sources is something that we editors can do. Comparison of sources is not something citations can or should do. Neither Chicago nor APA nor CS1 compare sources.
In the Chicago example that you gave, a single citation identifies two sources. It makes no comparison but simply identifies the two sources. In CS1, if both are important, cite them both but cite them separately. In the quote from APA that you gave, APA limits itself to the original publication date. It also makes no comparisons between the original and the cited work. CS1 supports this through |orig-year=.
Trappist the monk (talk) 11:07, 1 September 2014 (UTC)
Chicago says that if both an original publication (which was not consulted) and republished version (which was consulted) of a work are mentioned, certain differences should be mentioned, if known. One such difference is whether the pagination is the same. This is a simple comparison. Jc3s5h (talk) 12:28, 1 September 2014 (UTC)
No, it just identifies two sources with a single citation. That one is not consulted is poor practice that ought not be condoned.
Aren't we done with this? Clearly, neither one of us is going to convince the other so perhaps it is best to leave off unless there are some new and interesting aspects to discuss. You may have the last word which I shall read; it is likely that I'll decline to respond.
Trappist the monk (talk) 14:08, 1 September 2014 (UTC)


The current description could use a bit of amplification:

  • origyear: Original publication year; displays after the date or year. For clarity, please supply specifics. For example: |origyear=First published 1859 or |origyear=Composed 1904.

Reading Chicago and APA, the intent of 'origyear' is to include the date of original publication for a reprint or modern edition of a work. In my collection, I have:

  • Handbook for Boys (Reprint, Applewood Books) (1st ed.). Doubleday, Page. 1997 [Original publication 1911]. 

Here, 'type' seems to work quite well. But again, this would only work for a reprint, not a different edition. --  Gadget850 talk 13:55, 31 August 2014 (UTC)

Note that Handbook for Boys (Reprint, Applewood Books) (1st ed.). Doubleday, Page. 1997 [Original publication 1911].  is hopelessly confusing in other ways. This suggests we need to rethink the order in which these things appear.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  14:53, 6 September 2014 (UTC)

Template:Cite web/doc[edit]

Full parameter set in horizontal format and Full parameter set in vertical format have different parameters ?
Xb2u7Zjzc32 (talk) 18:15, 1 September 2014 (UTC)

It just needs to be edited to add whatever parameters you find missing. --  Gadget850 talk 18:24, 1 September 2014 (UTC)

An ISO 639-1 language name test[edit]

Sometime ago somewhere there was a discussion about ISO 639-1 that led me to do a brief experiment with mw.language.fetchLanguageName(). Right now, Module:Citation/CS1/Configuration has a table of ISO 639-1 codes and their English meanings (["af"] = "Afrikaans"). It seems silly to me for us to be maintaining a list of these translations if there is some other place we can get the same information.

So, I've tweaked Module:Citation/CS1/sandbox to use mw.language.fetchLanguageName(). In the collapse box is a list of simple cites that use the names and codes from the list in Module:Citation/CS1/Configuration.

If the tweaked code works, and if mw.language.fetchLanguageName() agrees with Module:Citation/CS1/Configuration then the citation title and the parenthetical language element of the rendered citation should be the same.

{{cite book/new |title=Afar |language=aa}}
Afar (in Afar). 

I have been through the list and found a handful of code translations that do not match. Can anyone find others?

These codes produced results different from the current table of definitions in Module:Citation/CS1/Configuration. Each is accompanied by a link to SIL International (SIL) along with a list of language names. Presumably, where two or more language names are listed, the first listed should be preferred? Right? SIL is, according to the Library of Congress web site, is the keeper of ISO 639 (here is a table of ISO 639 codes at the Library of Congress).

  • Maldivian (in Divehi). code dv: Dhivehi; Divehi; Maldivian – neither CS1 nor mw.language.fetchLanguageName() use the preferred language name
  • Haitian Creole (in Haitian). code ht: Haitian; Haitian Creole – CS1 does use the preferred language name
  • Nuosu (in Sichuan Yi). code ii: Nuosu; Sichuan Yi – mw.language.fetchLanguageName() does not use the preferred language name
  • Gikuyu (in Kikuyu). code ki: Gikuyu; Kikuyu – mw.language.fetchLanguageName() does not use the preferred language name
  • Kwanyama (in Kuanyama). code kj: Kuanyama; Kwanyama – CS1 does use the preferred language name
  • Greenlandic (in Kalaallisut). code kl: Greenlandic; Kalaallisut – mw.language.fetchLanguageName() does not use the preferred language name
  • Central Khmer (in Khmer). code km: Central Khmer – mw.language.fetchLanguageName() does not use the preferred language name
  • Norwegian (in Norwegian). code no: Norwegian – bug in mw.language.fetchLanguageName()?
  • Ossetian (in Ossetic). code os: Ossetian; Ossetic – mw.language.fetchLanguageName() does not use the preferred language name
  • Tonga (Tonga Islands) (in Tongan). code to: Tonga (Tonga Islands) – mw.language.fetchLanguageName() does not use the preferred language name

With the exception of codes no and to, mw.language.fetchLanguageName() provides an approved language name for each of the codes I've tested here. If, at the very least, code no can be fixed then I think that Module:Citation/CS1 should discontinue use of it's current table of names in favor of mw.language.fetchLanguageName().

In the mean time I will adjust the existing table so that if it takes a while before code no is fixed at least CS1 will be doing correct code to language name translation for codes dv, ht, and kj.

Trappist the monk (talk) 23:06, 1 September 2014 (UTC)

Don't forget the parser function {{#language:}}, e.g. {{#language:dv}} → ދިވެހިބަސް and {{#language:dv|en}} → Divehi --Redrose64 (talk) 23:44, 1 September 2014 (UTC)
I'm going to hazard a guess that {{#language:}} and mw.language.fetchLanguageName() are intimately related: {{#language:no|en}} produces Norwegian (bokmål) which is the same wrong language name produced in the Norwegian language test above.
Trappist the monk (talk) 23:57, 1 September 2014 (UTC)
See also m:List of Wikipedias#Nonstandard language codes. --  Gadget850 talk 01:10, 2 September 2014 (UTC)

I have tweaked Module:Citation/CS1/sandbox to provide a workaround for the code no problem. This does not fix the {{#language:no|en}} magic word which relies on the same code in mw:Extension:CLDR. {{#language:no|en}} produces: Norwegian (bokmål). More at WT:LUA#Bug in mw.language.fetchLanguageName()?

With this tweak, I think we can remove the translation table from Module:Citation/CS1/Configuration.

Trappist the monk (talk) 16:59, 10 September 2014 (UTC)

If this is intended to appear in the citation, this would be way more helpful if the output was "(language: Langname)" instead of "(in Langname)", an ambiguous construction that relies entirely upon the reader's recognition of Langname as the name of a language. That is unworkable because of the large number of obscure languages on the planet, and the fact that some of them are not distinguished from geonyms or ethnonyms.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  14:49, 6 September 2014 (UTC)

I suspect that '(in language name)' is an artifact of published style manuals: this example at CMOS 14.110 for example.
Trappist the monk (talk) 14:45, 10 September 2014 (UTC)

I've been wondering if the categorization that Module:Citation/CS1 applies to pages with citations that assign ISO639-1 codes to |language= is correct. Right now, if |language=de is use then the page is added to Category:Articles with German-language external links. This may or may not actually be true. For example this citation provides no links except to Special:BookSources

{{cite book |last1=Busch |first1=Rainer |last2=Röll |first2=Hans-Joachim |title=Deutsche U-Boot-Verluste von September 1939 bis Mai 1945 |work=Der U-Boot-Krieg |volume=IV |publisher=Mittler |location=Hamburg, Berlin, Bonn |year=1999 |isbn=3-8132-0514-2 |language=de}}

Here, |language= is used to identify the language of the source which is in keeping with the CS1 documentation.

So my question is: Are we correctly categorizing these pages? If yes, then we're done; if no, how should these pages be categorized?

Trappist the monk (talk) 14:45, 10 September 2014 (UTC)

I added some comments about the 'no'/'nb' issue here. – Danmichaelo (talk) 20:03, 14 September 2014 (UTC)

Based on my conversation with Editor Danmichaelo, I have taken the decision that Module:Citation/CS1 will return the string '(in Norwegian)' when editors use |language=no.

I have removed the translation table from Module:Citation/CS1/Configuration/sandbox so language codes now get the language names from Mediawiki.

Still unanswered is the categorization question. Category:Articles with non-English-language external links appears to have been intended for just that: external links. Right now, the module is indiscriminate. Whenever a citation with |language=<ISO639-1 code> is used, we add the page to the 'language' sub category of Category:Articles with non-English-language external links regardless of whether the citation has an external link. We aren't the only violators of the category, editors use {{xx icon}} to identify a string of text as a particular language (see Borgund Stave Church at the top of the infobox for an example).

Trappist the monk (talk) 11:34, 15 September 2014 (UTC)

What about using the categorisation that the lang-xx templates use? For example, at Swansea, it has {{lang-cy|Abertawe}} which puts the page into Category:Articles containing Welsh-language text. --Redrose64 (talk) 15:07, 15 September 2014 (UTC)
I don't know. The text at the top of Category:Articles containing non-English-language text does say that articles added to those categories should be added by the {{lang}} family of templates. That restriction sort of disqualifies CS1, né?
Of course the question that I haven't asked yet is: do we need to categorize pages that cite foreign language sources? My guess is that there will be some sort of maintenance or other benefit that can be gained by doing so. As an aside, I've been thinking that CS1 needs a maintenance category any way so this could be the impetus to create one.
Trappist the monk (talk) 00:18, 16 September 2014 (UTC)

Is something wrong with the description of "Cite web"?[edit]

{{Help me}} I was looking at the description of Template:Cite web (edit|talk|history|links|watch|logs) and saw large boxes full of white space and all the parameters are described as "You can explore profiles of current Radio staff in the section of this site and learn more about the type of work we do on . Get the latest BBC Radio news from the and .". Is this just me (I got the same result in Chrome and Firefox) or is something wrong?BiologicalMe (talk) 15:41, 2 September 2014 (UTC)

Don't know what caused it. If it's still there, click the purge link (top of the green near the Template documentation header) and see if that fixes the problem.
Trappist the monk (talk) 15:51, 2 September 2014 (UTC)
Someone broke Template:Csdoc. -- John of Reading (talk) 16:09, 2 September 2014 (UTC)
It's working now. Thanks for the responses, and if someone did something to fix it that I didn't see in the histories, thank you as well.BiologicalMe (talk) 16:44, 2 September 2014 (UTC)
{{csdoc}} is a redirect to {{Citation Style documentation}}. I protected both. --  Gadget850 talk 22:49, 2 September 2014 (UTC)

Should Template:Cite report be listed on this Help page?[edit]

I recently came across an invalid LCCN in a {{Cite report}} template, which uses Citation/core, so it did not report an error message. Should {{Cite report}} be listed in the table on this Help page? – Jonesey95 (talk) 00:07, 5 September 2014 (UTC)

See the talk page. --  Gadget850 talk 01:19, 5 September 2014 (UTC)
Sorry, I must be dense. I looked at Template_talk:Cite_report but did not see anything related to my question. I'll explain more fully. It appears to me that {{cite report}} is a CS1 template, so I'm asking if {{cite report}} should be added to the table at Help:Citation_Style_1#General_use. – Jonesey95 (talk) 04:29, 5 September 2014 (UTC)
Yes. Done.
Trappist the monk (talk) 09:58, 5 September 2014 (UTC)
Then we need to change the CS1 description:

There are a number of templates that use a name starting with cite; many were developed independently of CS1 and are not compliant with the CS1 style. There are also a number of templates that use one of the general use templates as a meta-template to cite a specific source.

To be compliant with CS1, a template must:

  • Be based on {{citation/core}}, Module:Citation/CS1 or one of the templates listed below.
  • Use a period as a punctuation mark to separate fields and end the citation.
  • Use a semicolon as a punctuation mark to separate authors and editors.
  • Format longer works in italics.
  • Format short works such as chapters in quotes.
--  Gadget850 talk 10:31, 5 September 2014 (UTC)
All of those criteria are met, are they not, with the exception of title formatting? It isn't clear to me why the |title= value isn't formatted in the same way as other titles throughout Wikipedia. The title value passed to {{citation/core}} is |Title= ''&#xFEFF;{{{title|}}}&#xFEFF;'' which undoes normal italic formatting and adds zero-width no break space characters. Why undo the italic formatting and what purpose do the unicode characters serve?
Trappist the monk (talk) 10:57, 5 September 2014 (UTC)
Exactly. This is discussed on the talk page. The template is for "Unpublished reports by government departments, instrumentalities, operated companies, etc" which I also failed to understand. It is redundant to {{cite journal}}. --  Gadget850 talk 11:02, 5 September 2014 (UTC)
And the manner of usage is also odd. See Area 51 for example. --  Gadget850 talk 11:06, 5 September 2014 (UTC)
I don't think that the case has been well made for removing title styling contrary to MOS. As for use of {{cite report}} in Area 51, that looks like a case of profound laziness on the part of the editors. A few minutes in Google turned up pdf copies of both documents:
The U-2's Intended Successor: Project Oxcart,1956-1968
A-12, YF-12A, & SR-71 Timeline of Events
That second document doesn't have the pristine provenance of the first, but editors have been satisfied with less.
Trappist the monk (talk) 12:25, 5 September 2014 (UTC)

The documentation for {{cite report}} is so bad and the title formatting is so non-standard that this template should not be considered part of CS1. I consider the template unfit for any use at all and if I come across a featured article that uses it, I will change it. If the change is reverted I will challenge the FA status of the article. Jc3s5h (talk) 12:54, 5 September 2014 (UTC)

Thanks for adding the template to the table. Should {{cite report}} be converted to use the CS1 Module? It looks like that would clear up problems with title formatting, lack of availability of some parameters, and documentation. Are there problems that it would create? – Jonesey95 (talk) 13:59, 5 September 2014 (UTC)
Do you intend to keep the existing formatting? As best I recall, the only difference between {{cite report}} and {{cite journal}} is the title presentation and the 'docket' id (which may not be in use). --  Gadget850 talk 14:20, 5 September 2014 (UTC)
It would seem that {{cite report}} is in many ways similar to {{cite thesis}}. Both support |docket= and both are 'unpublished', and each sets |type= to a default value. Similarly, one might claim that {{cite report}} is similar to {{cite techreport}}; |type= set to default values and 'unpublished' in the sense expressed at {{cite report/doc}}. In both {{cite thesis}} and {{cite techreport}}, titles are italicized.
{{cite report |title=Title |id=ID |docket=Docketname}}Title (Report). Docketname.
{{cite thesis |title=Title |id=ID |docket=Docketname}}Title (Thesis). Docket Docketname. ID. 
{{cite techreport |title=Title |id=ID |docket=Docketname}}Title (Technical report). ID. 
And what does 'docket' mean in this context? The general definition (wikt:docket) isn't much help. Perhaps 'docket' is a contraction of 'docket number'? {{cite thesis}} adds the word 'Docket' to the value assigned to the module's internal variable ID when |docket= is used with {{cite thesis}}. Is there a real value gained from this?
Trappist the monk (talk) 15:26, 5 September 2014 (UTC)
Where are we on this? Either we change cite report (which will make it redundant), we change the description of CS1, or we leave cite report as a different style. --  Gadget850 talk 20:52, 10 September 2014 (UTC)
I'm of the opinion that {{cite report}} should be modified to put report titles in at least quotation marks or italics (my preference being the latter). The template is otherwise no more redundant than {{cite thesis}} and should be included in the CS1 family. Imzadi 1979  21:31, 10 September 2014 (UTC)

Cite news documentation[edit]

The {{cite news}} documentation says, correctly, that periodicals usually omit the publisher, and not to include it when it is substantially the same as the work name. But the example of "A news article with a credited author", as well as several other examples, is a newspaper where the publisher is very similar to the work name. In my opinion, the cite news examples and the blanks under "Usage" should not include the publisher. --JFH (talk) 01:39, 5 September 2014 (UTC)

Go for it. --  Gadget850 talk 01:41, 5 September 2014 (UTC)

Untitled work[edit]

I notice that CS1 does not support untitled works. Chicago would use a descriptive phrase where the title would normally go, and the phrase would not be in italics nor would it be enclosed with quotes. So if someone needs to cite an untitled work, what would they do, other than rewrite all the citations in the article to use a style other than CS1? Jc3s5h (talk) 13:26, 5 September 2014 (UTC)

Example? In my mind, untitled would mean unpublished, which would fail the reliability standard. --  Gadget850 talk 13:34, 5 September 2014 (UTC)
I will give an example from Chicago Manual of Style 16th ed. section 14.240:

42. Burton to Merriam, telegram, 26 January 1923, Charles E. Merriam Papers, University of Chicago Library.

Jc3s5h (talk) 13:46, 5 September 2014 (UTC)
That's arguably an unpublished source, per Gadget850's concerns, above, though some might consider it a primary source because it's publicly accessible and validated by the institution. While it's conventional in art-related publishing to treat untitled works as if their title was "Untitled" or Untitled, as appropriate, those are usually also unpublished works. The most common case for this where we'd care about it are small newspaper entries with no title, and these are actually quite common, or were, back in the day. I think the most common way of handling them has been to use their first few words and "..." as if it were a title: |title=Yesterday's Spinks vs. Schaefer match was... |at="Sports" section |department=Sports |work=[[New York Times]].... A |noquotes= parameter could be used to remove quotation marks from around descriptive entries that are not actually titles, per Chicago's usage (and properly documented as to why this parameter would ever be used). A corresponding |noitalics= could also be used, for even rarer cases, to deitalicize names of major works. Actually, the most common use for both cases might be where the title needs to ben manually given in the proper formatting and also be followed by an annotation that should not be quoted/italicized, e.g. |noitalics=y |title=''Serenity'' (original script) |at="Extras" section |work=[[Serenity (film)|Serenity]] |format=Blu-ray .... There are many cases of not-intended-to-be-published works which have subsequently been published as part of bigger collective ones, and which have no titles or have titles, have been assigned later, conventional names in critical lit that are not actually titles, or have titles that would be ambiguous or confusing without such notes. An obvious example is the enormous amount of draft and abandoned and incomplete work by J. R. R. Tolkien edited and published in collected volumes by his son, which includes examples of all three types of cases.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  14:36, 6 September 2014 (UTC)
Perhaps something like |description-in-lieu-of-title= (yeah, much too long as a parameter name but could be aliased to an initialism |dilot=). If |title= or |chapter= (or any of the appropriate aliases) is present in the template and has an assigned value, do not display |dilot=; else display the unstyled, unquoted content of |dilot=. Content of |dilot= would not be restricted; |url=, if present, attaches to |dilot= just as it does to |title=. CS1 templates that display |dilot= content would add the page to a maintenance category; it would be inappropriate to misuse this parameter for the purpose of affecting title style in a rendered citation.
Trappist the monk (talk) 16:01, 6 September 2014 (UTC)
But |title= is already mandatory. So, the simple way to get at this is to allow styling (quotes or italics) to be decoupled from that parameter when necessary. That's way simpler than that "dilot" stuff, the name of which no one is likely to remember. The real code to implement how you've described the behavior of such as |dilot= would be quite bloated; it's a bunch of nested ifs, and ifs in multiple sections of essentially unrelated code, etc. Let's go with the KISS principle on this.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  18:52, 6 September 2014 (UTC)
@SMcCandlish: Instead of |at="Sports" section I would recommend |department=Sports: "Regular department within the periodical. Displays after work and is in plain text." --  Gadget850 talk 16:32, 6 September 2014 (UTC)
Noted; that parameter must have been added since the last time I pored over the parameters list in any detail.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  18:52, 6 September 2014 (UTC)

Seasons and year–year boundaries[edit]

In the northern hemisphere, the transition from one year to the next occurs during winter. Not so,for the southern hemisphere. This morning I found an instance of a journal that was dated Summer 2003–2004. The current live version of the module doesn't support dates in that form. So, I've modified Module:Citation/CS1/Date validation/sandbox.

Cite book compare
{{ cite book | date=Winter 2003–04 | title=Title }}
Live Title. Winter 2003–04. 
Sandbox Title. Winter 2003–04. 
Cite book compare
{{ cite book | date=Summer 2003–04 | title=Title }}
Live Title. Summer 2003–04. 
Sandbox Title. Summer 2003–04. 
Cite book compare
{{ cite book | date=Winter 2003–2004 | title=Title }}
Live Title. Winter 2003–2004. 
Sandbox Title. Winter 2003–2004. 
Cite book compare
{{ cite book | date=Summer 2003–2004 | title=Title }}
Live Title. Summer 2003–2004. 
Sandbox Title. Summer 2003–2004. 

Trappist the monk (talk) 16:32, 5 September 2014 (UTC)

Cool. I actually needed that just the other day, with an Australian journal.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  14:02, 6 September 2014 (UTC)

Discussion on placement of ref-related tags[edit]

FYI: Pointer to relevant discussion elsewhere.

Please see Wikipedia talk:WikiProject Inline Templates#Placement of ref-related tags, on placement of reference-related inline templates (e.g. {{verify credibility}} and {{clarifyref2}}) inside or outside the <ref>...</ref> element.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  14:08, 6 September 2014 (UTC)

OL parameter not being processed optimally[edit]

I have noticed a problem with the CS1 citations' processing of the (little-used) |ol= parameter. You can see the problem in The Carnival. Click on the link in the OL value in the first paragraph, and you will see that the link leads to a 404 error. If you remove the leading "OL" from the OL value, it takes you to the correct page.

This OL is broken: Marjorie L. Burns (1980). How to Read a Short Story (Scholastic language skills). Scholastic Book Services. ISBN 978-0-590-30611-9. OCLC 8000874. OL OL10699186M. 

This OL works: Marjorie L. Burns (1980). How to Read a Short Story (Scholastic language skills). Scholastic Book Services. ISBN 978-0-590-30611-9. OCLC 8000874. OL 10699186M. 

The OLID listed on the resulting page is "OL10699186M", so we should expect editors to put in such values. We should also expect them to leave off the leading "OL", since doing so has presumably resulted in working links for some period of time.

I was unable to find a spec for the Open Library Identifier (OLID); someone else may have better luck finding it. It appears that we might want to ignore the presence of a leading "OL" in the |ol= parameter, however, when rendering a clickable URL for the OL value. – Jonesey95 (talk) 23:18, 8 September 2014 (UTC)

It isn't documented, but the leading OL is not supposed to be included in the id. I think we only check for the terminator. --  Gadget850 talk 00:30, 9 September 2014 (UTC)
Maybe it's not supposed to be there, but even the Open Library page that you get when you click an OL link shows "ID Numbers: Open Library OL10699186M". That is why I suggest making the code flexible, serving up a working link whether the "OL" prefix is included in the value or not. – Jonesey95 (talk) 03:15, 9 September 2014 (UTC)
I've tweaked the OL validation code so that it looks for a series of one or more digits followed by one of the characters 'A', 'M', or 'W'.
Cite book compare
{{ cite book | isbn=978-0-590-30611-9 | ol=OL10699186M | author=Marjorie L. Burns | publisher=Scholastic Book Services | year=1980 | oclc=8000874 | title=How to Read a Short Story (Scholastic language skills) }}
Live Marjorie L. Burns (1980). How to Read a Short Story (Scholastic language skills). Scholastic Book Services. ISBN 978-0-590-30611-9. OCLC 8000874. OL OL10699186M. 
Sandbox Marjorie L. Burns (1980). How to Read a Short Story (Scholastic language skills). Scholastic Book Services. ISBN 978-0-590-30611-9. OCLC 8000874. OL OL10699186M Check |ol= value (help). 
Trappist the monk (talk) 11:36, 9 September 2014 (UTC)
The page about Open Library's API may help. While it doesn't explicitly say it, a link to will bounce to and similar things happen for works or authors. For some reason, no similar handling is done for publishers.
LeadSongDog come howl! 13:58, 9 September 2014 (UTC)
{{OL}} shows an example of {{OL|ia:publicrecords02conn}}OL ia:publicrecords02conn which redirects to OL14052591M. --  Gadget850 talk 14:08, 9 September 2014 (UTC)
I've scanned through the developer documentation (such as it is) a couple of times without finding anything that describes the identifier system. I have often been unable to see those things I have been looking for when they are right before me, so other eyes to look would be helpful.
I'm not inclined to support |ol=ia:publicrecords02conn because the OpenLibrary web site does redirect at least some of these kinds of 'identifiers' to a proper OL identifier. Not all Internet archive material has OL identifiers: OL ia:wargardenguyed00nati. If one wants to cite material on Internet Archive, use |url= and perhaps |via=Internet Archive.
Trappist the monk (talk) 14:51, 9 September 2014 (UTC)
That disinclination is a good thing. Such records as "ia:publicrecords02conn" are, in many cases, defectively linked on OpenLibrary as "books" but not associated as instances of identified "works". The result is that neither edits to correct the book nor the work record are possible. It's a bug in the OpenLibrary software which mines the Internet Archive database which has been identified but the OpenLibrary database has not yet been cleaned up. LeadSongDog come howl! 17:09, 9 September 2014 (UTC)
Ok, I've linked that book under OL records as OL25620088M and OL6617739M under OL7744673W. They are fixable one at a time, once you figure out the technique. LeadSongDog come howl! 17:52, 9 September 2014 (UTC)
Trappist the monk, thanks for modifying the code. I expect that if implemented, it would result in a fair number of error messages that would be easy to fix, but I think that it would be better to silently discard the leading "OL" when creating a link. My reasoning is that we do not have a specification to refer people to, and the OL web site itself shows OLIDs with a leading "OL". – Jonesey95 (talk) 20:29, 9 September 2014 (UTC)
That would be inconsistent with the way we handle all of the other IDs. We don't silently ignore PMC or ISBN or any of the other identifier labels. I'd really rather not start making exceptions.
We're sort of at sixes with this one. Historically, CS1, {{citation/core}} through {{citation/identifier}}, has required that |ol= not include the 'OL'; {{OL}} requires that the id not include the'OL'; related templates {{OL author}}, {{OL book}}, and {{OL work}} do require the 'OL'. None of those templates has more than 500 transclusions so it wouldn't be too onerous to change them all to use the id without the 'OL' (which, because it never changes conveys no meaningful information except when the id is used in isolation).
Trappist the monk (talk) 21:16, 9 September 2014 (UTC)
I see the issue with silently ignoring the extra "OL", but perhaps a more useful diagnostic is the better way, suggesting the correction to be made rather than just complaining that it is wrong? There's some history behind all this Template:OL/doc and Template talk:Cite book/Archive 6, which indicates there used to be some ambivalence about including "OL" in the identifier, but ultimately what's past is past. LeadSongDog come howl! 22:32, 9 September 2014 (UTC)
At some point in the dim dark past, {{OL}} may have accepted either OL1234A or simply 1234A, but in its current implementation it doesn't: OL1234A OLOL1234A.
I have hacked up the sandbox version of {{OL author}} so that it will accept identifiers with or without the 'OL' prefix. See Template:OL author/testcases.
As for more useful diagnostic, that is why we have Help:CS1 errors. We can put a lot more information there than would ever be accepted in an in-article error message. I invite everyone to help us make the help text better.
Trappist the monk (talk) 23:15, 9 September 2014 (UTC)
I can live with |ol=OL12345A being flagged as an error; I'll whip up a quick AutoEd script to fix the errors that crop up, as I currently do with similar PMC, DOI, ISBN, and other ID errors. I just thought that it might be more forgiving in this case to allow the OL, since the definitive source does not really seem to have its act together. – Jonesey95 (talk) 23:38, 9 September 2014 (UTC)
  • I once came across this very issue and figured out that I need to remove the "OL" from the parameter value. I would support rolling out the {{OL author/sandbox}} code that lets you both include and omit "OL"; it seems useful for the reasons outlined in the OP. It Is Me Here t / c 10:12, 10 September 2014 (UTC)

TITLE or Title?[edit]

Hopefully this is an easy one. I would like to cite a Playboy article in which the title is in all caps.[5] Should I use |title=PLAYBOY INTERVIEW: MARK LANE OR |title=Playboy Interview: Mark Lane? Thanks! - Location (talk) 04:32, 9 September 2014 (UTC)

Sentence case or title case. See WP:ALLCAPS.
Trappist the monk (talk) 10:27, 9 September 2014 (UTC)
I use to reformat case. --  Gadget850 talk 10:39, 9 September 2014 (UTC)
Thanks for pointing me in the right direction! - Location (talk) 13:45, 9 September 2014 (UTC)

Cite original title or second title for the continuation of a newspaper story[edit]

Sometimes a story from one page of a newspaper (e.g. on page 1 "Easter Bunny Goes Berzerk") is continued on another page under a different title (e.g. on page 2, "Children run in terror; Chocolate eggs spilled everywhere - continued from p. 1"). If the material I want to use is on page 2, do I still cite only the original title? Should I use |page=2 or |pages=1-2 if I am only using material on page 2? In using the GNews archives, I am also wondering if I should use |url= to link to the original title on page 1 where the article starts or the second title on page 2 where the material I want to use is located. Thanks again! - Location (talk) 16:02, 10 September 2014 (UTC)

I suppose that you could do this:
{{cite news |title=Easter Bunny Goes Berzerk |chapter=Children run in terror; Chocolate eggs spilled everywhere |newspaper=[[Easter Bunny, Kill! Kill!]] |last=Lapin |first=Jacques |page=2 |url=//}}
which gives:
Lapin, Jacques. Children run in terror; Chocolate eggs spilled everywhere. "Easter Bunny Goes Berzerk". Easter Bunny, Kill! Kill!. p. 2. 
That sort of works but just isn't quite right. You might concatenate the two titles:
|title=Easter Bunny Goes Berzerk: Children run in terror; Chocolate eggs spilled everywhere
and then refer to |page=2
|title=Children run in terror; Chocolate eggs spilled everywhere |page=2 |url=<page 2 url>
Unless there is a need elsewise, link to page 2 if that is where the pertinent information is located.
Trappist the monk (talk) 17:16, 10 September 2014 (UTC)
|title=Easter Bunny Goes Berzerk|at=p. 2, "Children run in terror; Chocolate eggs spilled everywhere" --Redrose64 (talk) 18:11, 10 September 2014 (UTC)
IMHO, if possible, use a URL that links to the complete article, not a URL that links only to page 2. The reader may get a better understanding of the information on page 2 iif they have the context of the entire article. GoingBatty (talk) 22:19, 10 September 2014 (UTC)
Thanks again to all! - Location (talk) 18:45, 12 September 2014 (UTC)

Peculiar title formatting[edit]

When all three of |title=, |chapter=, and |work= (or their aliases) are used together in a CS1 citation, the normally (at least to me) expected formatting shifts. For example:

{{cite book |title=Title |chapter=Chapter}}"Chapter". Title. 

But when I add |work=, this:

{{cite book |title=Title |chapter=Chapter |work=Work}}Chapter. "Title". Work. 

If I take away |title=, this:

{{cite book |chapter=Chapter |work=Work}}"Chapter". Work. 

If I take away |chapter=, this:

{{cite book |title=Title |work=Work}}"Title". Work. 

I suppose that these last two are correct if you assume that |title= or |chapter= are 'smaller' or subsidiary portions of |work=.

This is a new 'feature' to CS1 if you believe this comparison:

Cite book compare
{{ cite book | chapter=Chapter | title=Title | work=Work }}
Old "Chapter". Title.
Live Chapter. "Title". Work. 

Is the module's current rendering of citations that use all three |title=, |chapter=, and |work= correct?

Trappist the monk (talk) 17:38, 12 September 2014 (UTC)

That looks wrong to me. I think the value of |chapter= should always be in quotation marks, and the value of |title= should be italicized, at least in {{cite book}}. Under what circumstances would one want to use both |title= and |work=? Shouldn't they be aliases, as with |journal= and |work= in {{cite journal}} and {{cite news}}? The goal is to cite a chapter/article (in quotation marks) within a larger work (in italics), I think. What is the point of having three distinct parameters?
I notice that |work= is not a documented parameter in the documentation for {{cite book}}.
If three distinct parameters are needed, I think the display should be "Chapter". Title. Work. – Jonesey95 (talk) 20:30, 12 September 2014 (UTC)
|work= is a generic parameter name for |journal=, |encyclopedia=, |dictionary=, etc. This is probably a good example of the dark side of Module:Citation/CS1 supporting every parameter regardless of template name. Here are {{cite journal}}, {{cite encyclopedia}}, {{cite AV media}} which all give the same result:
{{cite journal |title=Title |chapter=Chapter |journal=Journal}}Chapter. "Title". Journal. 
{{cite encyclopedia |title=Title |chapter=Chapter |encyclopedia=Encyclopedia}}Chapter. "Title". Encyclopedia. 
{{cite AV media |title=Title |chapter=Chapter |work=Work}}Chapter. "Title". Work. 
I think I agree with you that when this case exists, it should be as you described.
Trappist the monk (talk) 21:45, 12 September 2014 (UTC)

It works as documented, but this is because I documented it as it works:

  • work: Name of the source periodical; may be wikilinked if relevant. Displays in italics. Aliases: journal, newspaper, magazine, periodical.
    • issue: When the publication is one of a series that is published periodically. Alias: number.
When set, work changes the formatting of other parameters:
title is not italicized and is enclosed in quotes.
chapter is italicized and is not enclosed in quotes.
location and publisher are enclosed in parentheses.
page and pages do not show p. or pp.
edition does not display.
type does not display.

No one has ever been able to explain the formatting difference. I don't know why we even support chapter for journal and news. --  Gadget850 talk 00:49, 13 September 2014 (UTC)

In the code, the quote / italicize determination works this way:
if |work= is used then |title= is quoted.
if the citation is {{cite web}}, {{cite news}}, {{cite pressrelease}}, {{cite conference}}, or {{cite podcast}}; and |chapter= is not used then |title= is quoted.
|title= is italicized.
There is a similar construct for |chapter=:
if both |work= and |title= are used then |chapter= is italicized.
|chapter= is quoted.
I think that this is wrong and should be revised so that |chapter= is always quoted and (ignoring non-Latin languages for the time being) |title= is always italicized except when the citation is {{cite journal}}, {{cite web}}, {{cite news}}, {{cite press release}}, {{cite conference}}, or {{cite podcast}} in which cases |title= is quoted |chapter=, if used, is ignored. Further, |chapter= without |title= should cause a missing title error.
Trappist the monk (talk) 15:32, 14 September 2014 (UTC)
An addendum: |title= should not be italicized in {{cite journal}}. In those citations, |title= is always used for the title of the article within the larger work, at least in my experience of correcting citation errors in a zillion {{cite journal}} templates. |journal= or |work=, in italics, is used for the name of the larger work.
What about |title= in {{cite encyclopedia}}? I know that one is particularly complex.
I think the last suggestion about chapter without title may have unintended consequences and may merit a separate discussion. – Jonesey95 (talk) 15:39, 14 September 2014 (UTC)
Yep, missed that one; {{cite journal}} added. Did I miss any others? I can imagine that there might be encyclopediae with articles long enough to subdivide into chapter-like sections. |section= is an alias of |chapter= so the rule as I've proposed it would render something like this:
"Section Title". Article Title. Encyclopedia
But, the problem with this or any citation that uses the three parameters |work=, |title=, and |chapter=, is that |work= (which is |encyclopedia= in {{cite encyclopedia}}) doesn't make it into the COinS metadata so we've lost the most important identifier.
Trappist the monk (talk) 16:21, 14 September 2014 (UTC)

I've adjusted Module:Citation/CS1/sandbox to demonstrate how I think citations with |work=, |title=, and |chapter= should render:

Cite book compare
{{ cite book | chapter=Chapter | title=Title | work=Work }}
Live Chapter. "Title". Work. 
Sandbox "Chapter". Title. Work. 
Cite journal compare
{{ cite journal | chapter=Chapter | title=Title | work=Work }}
Live Chapter. "Title". Work. 
Sandbox "Title". Work. 
Cite encyclopedia compare
{{ cite encyclopedia | chapter=Chapter | title=Title | encyclopedia=Encyclopedia }}
Live Chapter. "Title". Encyclopedia. 
Sandbox "Chapter". Title. Encyclopedia. 

Note that in the ({{cite journal}} example, |chapter= is ignored.

I found an undocumented snippet of code that maps |title= to |chapter= if |work= is set and |chapter= is not set. I have disabled that in the sandbox:

Cite book compare
{{ cite book | work=Work | title=Title }}
Live "Title". Work. 
Sandbox Title. Work. 

I suspect it is there to force the title to render in quotes. If we adopt this change, I will leave it in the code, though disabled, in case it serves some other purpose that I haven't managed to noodle-out.

Trappist the monk (talk) 14:39, 16 September 2014 (UTC)

These all look right to me. Do we want to flag |chapter= in {{cite journal}} as an error of some sort, rather than silently discarding potentially useful information that has heretofore been displayed? – Jonesey95 (talk) 14:45, 16 September 2014 (UTC)
In the sandbox, |chapter= will be ignored by {{cite journal}}, {{cite web}}, {{cite news}}, {{cite press release}}, {{cite conference}}, and {{cite podcast}} when |title= and |work= are both set. For {{cite journal}}, {{cite web}}, {{cite news}}, and {{cite podcast}} this makes sense because |work= in those citation types is a journal or magazine, a newspaper, or a website. For {{cite press release}}, the quoted title is appropriate to the relative size of a press release. We should just get rid of {{cite conference}}. Most often, {{cite conference}} is used when {{cite journal}} or {{cite book}} or even {{cite speech}} would be more appropriate.
Certainly we should update the documentation for these particular templates to say that |chapter= is ignored. It isn't really an error to have a valid parameter that doesn't get used. Any reason that we shouldn't have |chapter= requires |title= (Help) when |chapter= is used without |title=?
Trappist the monk (talk) 15:24, 16 September 2014 (UTC)

Where is the deprecated parameter in this article?[edit]

Where is the deprecated citation parameter in Michael Sells? I have done a null edit and a purge, and it shows the deprecated parameter category, but I do not see any error messages or deprecated parameters.

The category appears to have been added with this recent edit.

The article also sorts at the very top of the error category, before the articles that start with numbers, for some reason. I don't know if that is relevant.

I am also seeing this same situation with Urban College of Boston, Wiktor Eckhaus, and University of Natal. – Jonesey95 (talk) 03:05, 14 September 2014 (UTC)

@Jonesey95: All four were using |access-date= instead of |accessdate=. I've been fixing these for about four years now; there is a citation tool that still insists on using the hyphen even though it's been deprecated for years. --Redrose64 (talk) 10:58, 14 September 2014 (UTC)
|access-date= is a legitimate parameter. But {{citation}} is different. {{citation}} is a hybrid of old Wiki markup and new module. The Wiki markup portion still has a call to {{citation/patent}}. As such it also includes the code that tests for the old list of deprecated parameters.
I don't think that it is necessary to keep the list – |accessdaymonth=, |accessmonthday=, |accessday=, |accessmonth=, |accessyear=, |day=, |access-date=, |dateformat=. There is some small possibility that some of these are still in use out there but none are supported by patent citations so will be silently ignored until patent citations can be brought into Module:Citation/CS1. Shall I remove this code?
Trappist the monk (talk) 11:52, 14 September 2014 (UTC)
Also, these four pages were listed at the top because the wiki markup categorization uses sort keys. The module doesn't.
[[Category:Pages containing cite templates with deprecated parameters|{{NAMESPACE}} {{PAGENAME}}]]
Trappist the monk (talk) 12:04, 14 September 2014 (UTC)
Yes, please either remove that code (preferred), or remove the portion of the code that categorizes the article in the error category, or add code that emits an error message that makes it possible to track down the error. Thanks.
Redrose64, the addition of |access-date= as a valid parameter is a recent change, after an RFC that standardized all multi-word parameters with aliases that contain hyphens in addition to their previous formats (i.e. lumped together like accessdate, or underscored like trans_title). – Jonesey95 (talk) 15:15, 14 September 2014 (UTC)
I took your original request of "Where is the deprecated citation parameter", and your subsequent actions (null edit, purge) to mean "please would somebody help to stop this error being reported". I did exactly that with edits like this. If it's a valid parameter, it shouldn't put the page in Category:Pages containing cite templates with deprecated parameters. --Redrose64 (talk) 15:23, 14 September 2014 (UTC)
Thanks for fixing it. It appears to be a valid parameter; it was being rendered properly in the version that I linked to, with no error message. – Jonesey95 (talk) 15:28, 14 September 2014 (UTC)

Deprecated parameter test removed from {{citation}}.

Trappist the monk (talk) 22:43, 14 September 2014 (UTC)

Missing space in cite conference[edit]

*{{cite conference
 | authors=Abe, M. et al.
 | date=2008
 | title=Ground-based observational campaign for asteroid 162173 1999 JU3
 | journal=[[Lunar and Planetary Science]]
 | volume=39 |pages=1594
 | conference=37th COSPAR Scientific Assembly
 | url=

Yields the following output.

Notice the part that says "37th COSPAR Scientific AssemblyLunar and Planetary Science", which should instead be "37th COSPAR Scientific Assembly. Lunar and Planetary Science". Headbomb {talk / contribs / physics / books} 16:31, 15 September 2014 (UTC)

Well ..., |journal= isn't defined for {{cite conference}}; it sort of works but not really. Perhaps you can do this with {{cite conference}}:

*{{cite conference
 | authors=Abe, M. et al.
 | date=2008
 | title=Ground-based observational campaign for asteroid 162173 1999 JU3
 | publisher=[[Lunar and Planetary Institute]]
 | volume=39 |page=1594
 | conference=39th Lunar and Planetary Science Conference
 | url=

Or, I think a better solution is to use {{cite journal}} or {{cite book}} because by all appearances, you are citing the proceedings not the actual talk given at the conference. Here's how cite journal might look:

As an aside, I think that {{cite conference}} should be used only very rarely. It implies a presence at a conference and that leads to verification questions and thus a source that isn't so reliable. Were it up to me, {{cite conference}} would just fade away ...

Trappist the monk (talk) 19:07, 15 September 2014 (UTC)

The |Periodical= meta-parameter was not implemented in the old version, thus there was no |journal=:
Cite conference compare
{{ cite conference | authors=Abe, M. et al. | date=2008 | journal=Lunar and Planetary Science | title=Ground-based observational campaign for asteroid 162173 1999 JU3 | volume=39 | conference=37th COSPAR Scientific Assembly | pages=1594 | url= }}
Old Abe, M. et al. (2008). "Ground-based observational campaign for asteroid 162173 1999 JU3". 39. 37th COSPAR Scientific Assembly. pp. 1594.
Live Abe, M. et al. (2008). "Ground-based observational campaign for asteroid 162173 1999 JU3". 37th COSPAR Scientific AssemblyLunar and Planetary Science 39: 1594. 
I agree with Trappist: this citation should use cite journal. Can we disable |journal= and the others for this? --  Gadget850 talk 23:24, 15 September 2014 (UTC)
Limiting individual parameter use to certain citation types wasn't something that was contemplated at the beginning of the switch to Module:Citation/CS1. I think that the genii is out and we may never catch him up and stopper the bottle. There is code (written before my time) that purports to 'account for the oddity that is {{cite conference}}, but it isn't qualified in any way (no test to restrict its operation to just {{cite conference}}) so I'm hesitant to simply add code that would set Periodical to nil or empty string.
Perhaps in the future we can begin to look at restricting which parameters are available to the various citation types.
In the meantime, just say no to {{cite conference}}.
Trappist the monk (talk) 00:32, 16 September 2014 (UTC)

archivedate considered harmful[edit]

(in the tradition of Goto considered harmful)

The existence of Help:CS1_errors#.7Carchiveurl.3D_requires_.7Carchivedate.3D makes little sense to me. 99%[1] of archiveurl fields on en contain the archive date within the URL, so the archivedate field is redundant, and where the archivedate field conflicts with the archive date within the URL, it's always the former that is wrong. I therefore proclaim archivedate considered harmful, and propose it be deprecated. --{{U|Elvey}} (tc) 08:09, 17 September 2014 (UTC)

  1. ^ (guesstimate)