Help talk:Citation Style 1

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

"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)
For the record, I agree that the bot fixes have run to substantial completion but I'm opposed to displaying the error. While I appreciate the responses that I got to an earlier post here, those responses did nothing to address my reasons for objecting. If the error is to be enabled I'd appreciate at least a few days advance notice because I intend to modify the help text so that it more directly addresses the most common errors.TuxLibNit (talk) 23:42, 17 September 2014 (UTC)
Is there a reason that you can't make improvements to the help text now? Even though the errors are hidden from most editors, there are editors who have enabled the error display for hidden errors so whatever improvements you make can help those editors right now.
And why is that you're opposed?
Trappist the monk (talk) 23:52, 17 September 2014 (UTC)
TuxLibNit: the error messages used to be displayed. They were hidden after an RFC with one condition: that a bot designed to remove the errors in each category "run to sufficient completion". That condition has been met for the "dates" category. At this time, articles with date errors are being added to the error category at a rate of about 100 per day. If we continue to hide the error messages, some erroneous dates will continue to be added, but some editors will see the error, read the (improved?) help text, and fix the errors.
I reread the comments of TuxLibNit above, and I found it difficult to determine the editor's reasons for objecting. I saw a lot of questions and a link to an analysis of a sample of dates. What are the objections at this point? Do they outweigh the clear reasons for displaying the error messages, e.g. dates generating error codes are ambiguous, missing data, or otherwise not as clear as they should be? – Jonesey95 (talk) 06:21, 18 September 2014 (UTC)
OK, I'll try to be clearer. I was trying to be brief because I didn't want to generate a wall of text and because I'm aware I'm coming late to this discussion so I thought there was a good chance I'd be pointed to some conclusive argument or agreement that would render a more complete post pointless. As that does not appear to be the case, here we go:
  • A side point regarding the RFC: My understanding of the RFC is that "run to sufficient completion" merely signals the end of an agreement that this error should be disabled. While the closer does explicitly bless re-enabling the errors that the RFC hid, I beleive this is just to restore the status quo — with the messages enabled, but their status disputed. I didn't see a consensus that those arguing for the messages to be disabled more permanently had failed to make their case and that the messages should remain enabled despite their objection.
  • Trying to be clearer about my position:
    • I'm opposed to leaving the red error messages enabled on large numbers (say more than 400 pages/category) of minor errors (subjective, but an ambiguous date in a cite definitely qualifies for me) for long periods of time (really more than a month or so, but I'll be generous and say a year). I hope the principle at least is not too controversial — that the harm done by the presence of an error should be weighed against the harm done by displaying the corresponding error message and the latter harm is at its greatest for an error that does not get fixed for a long time. The messages are there to help ensure the errors are fixed, if they are not doing that job, then they are purely harmful (in the sense that they are defacing the article with no benefit) and should be turned off.
    • I'm not disputing that the overwhelming majority of dates flagged in this category are indeed errors that in an ideal world would be fixed. However I'm not convinced that simply enabling the errors as proposed is a fair or effective way to get them fixed.
    • Regarding fairness. The intended effect of an error message is to flag up an error that a grateful (or at least dutiful) editor will then voluntarily fix because it is an error. This should apply to all major errors and to recently introduced minor errors, but in the case of sufficiently minor errors this logic can be reversed so that the editor will fix the error primarily because the error message defaces the article not because they consider the error itself particularly worth fixing for its own sake. When the errors arise piecemeal (because the error has just been introduced) this can still be tolerable but if lots of minor errors appear all at once it becomes a problem, because the editor feels forced to expend a significant amount of effort right now simply to suppress the error messages, whereas the errors themselves could have been left until later (or arguably even left indefinitely). Forcing an editor to make trivial changes would be unfair.
    • Regarding effectiveness. There are already error categories with red messages enabled that contain huge numbers of members that are not declining significantly. Why should this error be any different (i.e. get fixed rapidly)? I also regard the history of Category:Pages_with_ISBN_errors as support for my position because although there has recently been some success in reducing it, it had remained large for a long period of time and the success has come from a (more or less) coordinated effort by a relatively small number of editors making many edits, and even then, every time that effort flags, the size of the category stabilises again (growing slowly). I think this means that people are mainly fixing these errors from the category and/or from WP:WikiProject_Check_Wikipedia/ISBN_errors, not because they happen to be viewing an article containing an error message.
  • Some final comments for now:
    • It appears that no-one here realised that when I was asking questions in my first post it was because I hoped for answers.
    • There's nothing stopping me editing the help, its on a to-do list but I haven't got to it yet. If the message enable was imminent it would bump that task up my list.
    • If it helps, I could for example support unhiding the error message for a single large category (eg the date errors with 60000 members) if there was also an agreement that if the category did not decline fast enough (say by 5000 messages in a calendar month) while it remained large (say over 400 members) then the message would be hidden again. That doesn't mean I'd be willing to put in much effort into fixing them myself.
    • On the other hand I realise there is no particular need for you to get hung up on one person's objections.
    • I hope that gives a clearer idea of the arguments and reasoning behind my objections. Apologies for the long post, but you did ask for it.
TuxLibNit (talk) 22:32, 18 September 2014 (UTC)
Thank you for the long post. I did ask for it, and your post was helpful. I will respond to a few of the points raised.
  1. I got involved in fixing citation errors because I saw a red error message and it made me curious. If all of the error messages had been hidden, I probably would not be here. Since I began fixing those errors in 2013, I have fixed errors in 20,000 to 30,000 pages. I typically fix 50 to 100 errors per day. There are other gnomes and bots who have fixed many more.
  2. There are currently 28 subcategories of CS1 errors. Of those, 19 are essentially empty or are close to empty due to diligent work by a handful of editors. A few more categories have been massively reduced in the last year; many categories had "huge numbers of members" (quoting the response above) recently, but they have been addressed in a reasonable amount of time. The wikilinks error category, for example, had something like 8,000 articles in it last year, and is empty now. The ISBN error category had about 7,000 articles in it just a few months ago, and it has been reduced to 650 during 2014 (it was at about 1,000 a month or two ago; progress has slowed, since the remaining cases are more difficult than the low-hanging fruit that was there initially). The "old style et al." categories had about 12,000 articles and are now down to about 1,400. My point is that significant progress has been made on almost all of the categories. Most of this work has been done by gnomes and bots, many of whom have been attracted to the work by the error messages. I have some evidence to show that individual reader/editors are motivated by the error messages to fix errors; sometimes I will queue up 20 articles to fix, only to find when I get to the 15th article that an editor actively working on the article has already fixed the error.
  3. The categories that have a stable and large number of members may need to be discussed here individually (e.g. accessdate without URL, format without URL). If nobody wants to fix these errors, maybe we need to set them aside. The "dates" and "deprecated parameters" categories are large, but not large and stable; they have both decreased significantly because editors are interested in fixing these errors.
  4. ReferenceBot has been configured to notify editors when they add some types of CS1 errors to articles. There are additional categories that need to be added to its notification list; I will help those categories to get on the bot's list one of these days. I have evidence that these notifications motivate editors to return to articles and clean up after themselves. Not everyone does so, of course, but many do.
  5. You suggest "more than a year" as a time to determine if progress has been made on reducing error messages in articles. There are currently about 60,000 date errors, with about 100 being added daily. That says that we need to fix about 260 articles per day for a year to clear out the category. Based on my own experience with fixing CS1 errors, I think it is reasonable to expect that focused effort by gnomes and bots on this category could achieve that. Adding ReferenceBot notification (optional, to be decided here) and showing the date errors make it more likely that we could reach that goal.
Thanks for your interest and the explanation. – Jonesey95 (talk) 23:38, 18 September 2014 (UTC)
The date is one of the critical elements of a citation that is used to identify the source. Error checking is intended to identify issues in the citations for quality assurance. Browsing a sample of articles, a large number of errors are due to ambiguous formats such as 9/10/2013 that a bot cannot resolve. Editors should be reviewing their work and if they see an obvious error message they should be able to use the help page and fix the problem quickly. This not currently happening since the messages are hidden by default. --  Gadget850 talk 11:34, 19 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)
The solution is to fix the template, not bury our heads in the sand pretending the problem doesn't exist. Headbomb {talk / contribs / physics / books} 13:54, 17 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)
Cute, but... MOS:DATEUNIFY, even ignoring those archiveurls which don't "point to" the date. Can you make the template rendering of the date from the archiveurl context sensitive, so it matches the other dates in the article? LeadSongDog come howl! 13:38, 17 September 2014 (UTC)
I can't tell if the OP is joking or not. If so, the sarcasm is subtle.
URLs from typically have their archive dates in the URL, but those from some other archiving sites, like, do not (see, for example, this reference). In any event, someone who does not know how to decode the date in an URL (which requires hovering over the link with a mouse and reading the URL in the browser's status bar, if it is being displayed) is out of luck unless a human or bot editor converts it to a human-readable archive date. – Jonesey95 (talk) 16:05, 17 September 2014 (UTC)
For the Owen Edwards example, see [6] to see how timestamps are available. That raises the point though... couldn't a bot check archiveurl strings from major archives for matching archivedate values, and put them in the format appropriate for the article? LeadSongDog come howl! 18:33, 17 September 2014 (UTC)

Publication within a publication[edit]

The Sun Magazine used to appear every Sunday in The Baltimore Sun. (It now appears to be part of it six times each year: [7].) If I am using Template:Cite news for an article published in The Sun Magazine, do I indicate that for |newspaper= or the parent paper, The Baltimore Sun? Thanks! - Location (talk) 21:18, 17 September 2014 (UTC)

Use |department=. --  Gadget850 talk 22:30, 17 September 2014 (UTC)
I agree with Gadget on this one. That would look something like:
  • Doe, John (September 13, 2014). "Article". The Sun Magazine. The Baltimore Sun. p. 2. 
If you were citing Parade magazine, which is published completely independently of the newspaper itself with separate publication staff, I wouldn't bother to mention the paper into which it was enclosed, whether it is The Baltimore Sun, or The Mining Journal. But in this case, that magazine is a component of a specific larger paper, I would use the |department= parameter. Imzadi 1979  02:09, 18 September 2014 (UTC)

Wikimarkup and COinS metadata[edit]

One very common corrupter of the COinS metadata is wikimarkup when it is used to add bold and / or italic styling to |title= (or to undo the default italic styling). The problem arises because the markup gets copied into the metadata. In this example, all of the apostrophes used to make the title bold italic appear in the metadata as a string of %27 which are not part of the actual title:

  • '''''Bold italic''''' title → "Bold italic title". :
  • <span class="citation news">"'''''Bold italic title'''''".</span><span title="ctx_ver=Z39.88-2004&" class="Z3988"><span style="display:none;">&nbsp;</span></span>

In Module:Citation/CS1/sandbox, I have created a function get_coins_title(), that strips the most common legitimate markup from |title= before adding the title to the metadata:

the five-apostrophe cases
  • '''''Bold italic''''' title → "Bold italic title". :
  • <span class="citation news">"'''''Bold italic title'''''".</span><span title="ctx_ver=Z39.88-2004&" class="Z3988"><span style="display:none;">&nbsp;</span></span>
  • '''''Bold''' italic'' title → "Bold italic title". :
  • <span class="citation news">"'''''Bold''' italic'' title".</span><span title="ctx_ver=Z39.88-2004&" class="Z3988"><span style="display:none;">&nbsp;</span></span>
  • '''''Italic'' bold''' title → "Bold italic title". :
  • <span class="citation news">"'''''Bold'' italic''' title".</span><span title="ctx_ver=Z39.88-2004&" class="Z3988"><span style="display:none;">&nbsp;</span></span>
  • ''Italic '''bold''''' title → "Italic bold title". :
  • <span class="citation news">"''Italic '''bold''''' title".</span><span title="ctx_ver=Z39.88-2004&" class="Z3988"><span style="display:none;">&nbsp;</span></span>
  • '''Bold ''italic''''' title → "Bold italic title". :
  • <span class="citation news">"'''Bold ''italic''''' title".</span><span title="ctx_ver=Z39.88-2004&" class="Z3988"><span style="display:none;">&nbsp;</span></span>
simple bold
  • '''Bold''' title → "Bold title". :
  • <span class="citation news">"'''Bold''' title".</span><span title="ctx_ver=Z39.88-2004&" class="Z3988"><span style="display:none;">&nbsp;</span></span>
simple italics
  • ''Italic'' title → "Italic title". :
  • <span class="citation news">"''Italic'' title".</span><span title="ctx_ver=Z39.88-2004&" class="Z3988"><span style="display:none;">&nbsp;</span></span>
a combination of all three
  • '''''Bold''' italic'' title and ''italic'', '''bold''', '''bold again''', last ''italic'' → "Bold italic title and italic, bold, bold again, last italic". :
  • <span class="citation news">"'''''Bold''' italic'' title and ''italic'', '''bold''', '''bold again''', last ''italic''".</span><span title="ctx_ver=Z39.88-2004&" class="Z3988"><span style="display:none;">&nbsp;</span></span>

The above examples use {{cite news}} because that template renders titles in upright font.

Have I missed anything obvious?

With this fix, the work discussed at Module talk:Citation/CS1#non-italic titles may no longer be necessary.

Trappist the monk (talk) 12:46, 18 September 2014 (UTC)

Renamed function to strip_apostrophe_markup() and now also used to strip wikimarkup from |chapter=.
Trappist the monk (talk) 10:52, 19 September 2014 (UTC)