View text source at Wikipedia

Help talk:Citation Style 1/Archive 9

Archive 5←Archive 7Archive 8Archive 9Archive 10Archive 11→Archive 15

urls in |title=

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

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

External wikilink with leading text:

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

External wikilink with trailing text:

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

External wikilink with leading and trailing text:

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

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

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

The external wikilink must be complete:

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

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

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

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

WP:VPT is your friend:

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

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

{{cite web | url= | title=http://www.edmonton.ca/city_government/documents/Callaghan_NASP_Consolidation.pdf Neighbourhood Area Structure Plan (Office Consolidation) | publisher=City of Edmonton | date=March 2011 }}
"http://www.edmonton.ca/city_government/documents/Callaghan_NASP_Consolidation.pdf Neighbourhood Area Structure Plan (Office Consolidation)". City of Edmonton. March 2011. {{cite web}}: External link in |title= (help); Missing or empty |url= (help)
{{Cite journal|duplicate_title=The Beverly clock|type=Abstract|journal= [[European Journal of Physics]]|publisher=IOPscience|title=http://iopscience.iop.org/0143-0807/5/4/002}}
"http://iopscience.iop.org/0143-0807/5/4/002". European Journal of Physics (Abstract). IOPscience. {{cite journal}}: External link in |title= (help); Unknown parameter |duplicate_title= ignored (help)

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

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

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

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

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

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

The test can handle all three in the same template:

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

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

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

Other, better ideas?

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

How do you suppress errors when titles are missing?

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

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

Giving out

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

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


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

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

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


Returning to the original example, I would have written 

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

which yields

Kanguole 15:56, 17 August 2015 (UTC)

when both original and archive urls are dead

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

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

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

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

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

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

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

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

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

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

error handling for |trans-title= and |trans-chapter=

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

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

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

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

Suppress original URL

Moved from Module talk:Citation/CS1/Feature requests § Suppress original URL

Discussion moved here for a somewhat broader audience.

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

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

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

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

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

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

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

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

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

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

{{cite web/new |title=Title |url=//example.com |archive-url=//example.org |archive-date=2015-08-14 |dead-url=no}}
"Title". Archived from the original on 2015-08-14. {{cite web}}: Unknown parameter |dead-url= ignored (|url-status= suggested) (help)
{{cite web/new |title=Title |url=//example.com |archive-url=//example.org |archive-date=2015-08-14 |dead-url=yes}}
"Title". Archived from the original on 2015-08-14. {{cite web}}: Unknown parameter |dead-url= ignored (|url-status= suggested) (help)

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

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

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

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

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

Yet another example of two levels of title within a journal publication

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

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

produces

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

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

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

vancouver error tweak

I have noticed that a space between the two initials of a name in |vauthors= is not detected as an error. I think that I have fixed that:

Cite book comparison
Wikitext {{cite book|title=Title|vauthors=Last AA, Last B B}}
Live Last AA, Last B B. Title. {{cite book}}: Vancouver style error: initials in name 2 (help)
Sandbox Last AA, Last B B. Title. {{cite book}}: Vancouver style error: initials in name 2 (help)

—Trappist the monk (talk) 21:55, 31 August 2015 (UTC)

Time of day field

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

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

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

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

If a tweet is taken down, and has not been archived anywhere, then it is not verifiable, and I would question its suitability as a source. If you feel it is useful to document the exact time some tweet or other information is posted/published, you can always add that following the template. I am not aware that a "time" field is necessary. ~ J. Johnson (JJ) (talk) 22:47, 28 August 2015 (UTC)
I would think that in the rare instance where it was necessary to discuss the time various sources were published, it would be necessary to describe the times in the body of the article rather than leaving it to the footnotes. Jc3s5h (talk) 00:09, 29 August 2015 (UTC)
"Footnotes" is a bit ambiguous. More particularly, if short cites are used then the time could be used in the same manner as a page number, perhaps using |loc=. But however this might be done, the bottom line here is that (lacking any specific demonstrated need) we seem to have adequate means for adding timestamps, and the proposed field is not needed. ~ J. Johnson (JJ) (talk) 19:26, 2 September 2015 (UTC)

page protection applied to the suggestions list

Module:Citation/CS1/Suggestions has been, since it creation, unprotected. At the time, I wondered if that page should be protected, but I didn't pursue it and have come to believe that protection of that page is not necessary.

The page was set to template editor level protection by Editor Courcelles at the request of Editor CFCF. That discussion, since archived, is here. Because it has been archived, I have raised the issue here.

Is the current (template editor) protection appropriate?

Should we keep or revert?

—Trappist the monk (talk) 10:50, 4 September 2015 (UTC)

As an editor with template editor rights, I don't mind, but I think it's odd that a page that has never been vandalized or even edited incorrectly, as far as I can tell, would be protected. The page has 42 edits total, by my count.
Since you bring it up, is it somehow possible to use regular expressions on that page? I may have asked this before. There are a lot of creative spellings of |access-date=, for example, that could be caught with a few regular expressions. – Jonesey95 (talk) 14:01, 4 September 2015 (UTC)
Perhaps improperly edited once (you reverted).
Feature requests has your regex suggestion.
—Trappist the monk (talk) 15:32, 4 September 2015 (UTC)
Oops. I think my brain thought to set it to semi, and my fingers to template. Courcelles (talk) 17:32, 4 September 2015 (UTC)

pattern matching for suggestion list

Perhaps there is reason to be somewhat optimistic. I think that all of these are caught by this pattern: ['ac+es+ ?d?a?t?e?'] = 'accessdate'

As the pattern is written, |accessdare= returns a partial match 'accessda'. I guess that could be a good or bad; too tight and we might as well just use the exact-match-method we use now or too loose and we get a lot of false positives.

At the moment, Module:Citation/CS1/sandbox only catches |access-date= errors – I did that so that I could be sure that the errors weren't being caught by the existing code. Now I have to figure out how to integrate this with the existing test. And of course, I need to ask, do we really need this?

—Trappist the monk (talk) 18:45, 4 September 2015 (UTC)

Regular exact-match-method restored. I've added a second pattern for variations on a theme of publisher using this pattern: ['pu[blish]+ers?$'] = 'publisher'

—Trappist the monk (talk) 22:21, 4 September 2015 (UTC)

At the end of this discussion, I noted that the suggestion mechanism doesn't allow suggestions for enumerated parameters. This is true except for the specific case of |autor2= which has an exact-match rule ['autor2'] = 'author2'. Using patterns may be a way to solve this weakness. Using this pattern: ['a[utho]+r%d+'] = 'author#':

—Trappist the monk (talk) 11:51, 5 September 2015 (UTC)

These new suggestions look helpful. Can we use something like '$1' in the suggestion to repeat the number that was detected by the pattern? – Jonesey95 (talk) 21:32, 5 September 2015 (UTC)
Without getting too complicated we can do one capture:
['a[utho]+r(%d+)'] = 'author$1' (see my previous example to see that it works)
More than that and some more involved code will be required.
—Trappist the monk (talk) 22:58, 5 September 2015 (UTC)

Double period bug (again)

I know this was reported before, but this bug is still alive and annoying.

Steps to replicate: give the publisher parameter a value that ends with a period.

Result: Two periods after the publisher. Which is wrong. Mature software such as BibTeX and Citation Style Language can deal with this.

Real-life example: Look for “Digitalcourage e.V.” on de:Digitale_Gesellschaft_(Schweiz). --Thüringer ☼ (talk) 08:08, 7 September 2015 (UTC)

Here is the citation from de:Digitale_Gesellschaft_(Schweiz):
{{Cite web |title=Überwachung in und aus der Schweiz: Das volle Programm |url=https://digitalcourage.de/blog/2015/ueberwachung-in-und-aus-der-schweiz-das-volle-programm |author=Digitale Gesellschaft Schweiz |publisher=Digitalcourage e.V. |date=2015-08-18 |accessdate=2015-09-07 }}
Digitale Gesellschaft Schweiz (2015-08-18). "Überwachung in und aus der Schweiz: Das volle Programm". Digitalcourage e.V. Retrieved 2015-09-07.
De:wp does not use the en:wp Module:Citation/CS1 to render citation templates. The de:wp, {{cite web}} is a template that is written using wiki markup.
Probably best to raise the issue at de:Vorlage Diskussion:Cite web.
—Trappist the monk (talk) 11:09, 7 September 2015 (UTC)

RfC closure challenge: Template talk:Cite doi#RfC: Should Template:cite doi cease creating a separate subpage for each DOI?

Please take part in the discussion at Wikipedia:Administrators' noticeboard#RfC closure challenge: Template talk:Cite doi#RfC: Should Template:cite doi cease creating a separate subpage for each DOI? Curly Turkey 🍁 ¡gobble! 05:12, 8 September 2015 (UTC)

RFCs on citation templates

There are ongoing discussions (mostly parallel but since each one is argued as separate consensus, separate) regarding the use of (A) Template:Cite wdl (which creates subpages for a wrapper of cite web) here; (B) Template:Cite pmid (which is a wrapper for cite journal either in-article or via pages at Category:Cite pmid templates) here; and (C) another RFC at Template:Cite doi (a cite journal wrapper with almost 60k pages at Category:Cite doi templates) here. There are unique wrinkles to each one but basically all three discussions concern whether to deprecate these templates or not. Please comment there if everyone could. -- Ricky81682 (talk) 06:22, 8 September 2015 (UTC)

Italicization of websites in citations

Stale
 – Discussion has moved on, to #Request for Comments: Italics or Non-Italics in "website" field.

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

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

I think you all are missing a couple key things here:

  1. the name of the website very rarely includes the domain space (.com, .org, etc)...eg. it's "Wikipedia" not "Wikipedia.org"
  2. citation styles are, generally, an exception to the MoS...the citation styles are intended to reflect common citation styles. Of the common citation styles, condsider how the following handle the names of websites:
  1. MLA uses italics (scroll down to the section "A page on a website")
  2. Chicago uses italics
  3. APA generally doesn't include the name of a website that's not scholarly website (eg. an online journal), but instead uses "Retrieved from [url]".
  4. ASA and Oxford style also does not include the name of the website, but rather the url
  5. Vancouver style (see page 5) does not italicize the name of the website, but includes "internet" in brackets after the website name, for example: Wikipedia [internet].

While there are many exceptions, websites are generally a work/publication. Of the citation styles that include the name of the website, the two general style guides (MLA and Chicago) both italicize the name of the website, while the Vancouver style guide is generally reserved for the physical sciences. AHeneen (talk) 01:58, 3 September 2015 (UTC)

I don't think we need to research varied style guidelines. It's already established that websites/urls are generally not italicized at Wikipedia, and I'm not aware that we have separate formatting conventions for citations in this regard. The fact that cite templates equate "website" with "work" is the problem, because while one or the other should be required, they do not have the same established formatting style. Period. If I'm citing EW.com, I actually cite |work=Entertainment Weekly because the website is an obvious platform of that publication. But when you cite a website not affiliated with a conventional publication, yes it may be considered a "major published work" in the sense that it is a reliable source, but I don't see why it should be italicized when it does not meet the criteria for that formatting, and would not be italicized in other contexts at WP. I get SMcCandlish's basic argument, but it is not as if there a requirement somewhere that something has to be italicized in each citation, or that the source has to be italicized no matter what it is.— TAnthonyTalk 19:24, 3 September 2015 (UTC)
Okay, we need some clarification here, as it seems that "website" is being used in several different ways. Note that websites usually have a proper name, such as "Google", "The New York Times", "Entertainment Weekly", and "Rotten Tomatoes". Websites also have hostnames, such as (resp.) "www.google.com", "www.nytimes.com", "ew.com", and "wwww.rottentomatoes.com", which often (but not always) incorporate some form of the website's (or parent entity's) name. Hostnames are usually part of URLs (but see below), and as such have specific form and usage in the context of the Internet. As hostnames (URLs) they are not italicised, nor capitalized. What are italicized are titles, such as the names of books, periodicals, and (generally) works. A book title in the form of a hostname, such as Amazon.com, would be italicized, but only because it is a title.
It seems to me the real issue here is what constitutes a title; particularly, the name of a source. "The New York Times" and "Entertainment Week" are the names of both publications and their associated websites; "nytimes.com" and "ew.com" are not. (Entertainment Weekly could have named their website "EW.com", in which case it could be a title, but they did not.) Note that a further distinction can be made between a publisher and a publication (or work). E.g., "Amazon" (the website) might be the publisher of a reveiw found there, but is it a publication? ~ J. Johnson (JJ) (talk) 21:34, 3 September 2015 (UTC)
Amazon, or Amazon.com, indeed is not a publication. Neither is the publisher Simon & Schuster or simonandschuster.com. Likewise, Sears.com is not a publication, and citing, just for example, the number of stores that Sears owns would be to the website Sears.com, and not Sears.com.
TAnthony is correct that if we're citing something created by the editorial department of Entertainment Weekly or The New York Times, we credit the publication rather than ew.com or nytimes.com, and these publications of course are italicized. In such cases, we use "work=" or "newspaper=" or "journal=". But neither Black & Decker nor blackanddecker.com is italicized. Same with The Home Depot or homedepot.com.
The sensible solution, I believe, is to have the "website" field not italicize its contents. That way we're not putting in " Amazon.com " or " Sears.com ". If we're citing an actual publication, we have three different fields we can use. --Tenebrae (talk) 22:48, 3 September 2015 (UTC)
Careful! You seem to be sliding back to confusing the name (as in a proper name) of a website with its hostname. E.g., "Sears.com" is not the name of a website, so should not be put in anywhere. If you want to cite something from the Sears website (located at "www.sears.com"), then you cite that, not its hostname. If a website is a publication (e.g., "Rotten Tomatoes") then its name is properly italicized. ~ J. Johnson (JJ) (talk) 23:27, 3 September 2015 (UTC)
I don't think I am. And I think you are the only person on this thread making the argument that Amazon.com should be italicized. And, certainly, no one italicizes Rotten Tomatoes, not even Rotten Tomatoes, as it is not, by any definition, a publication.
What do the other editors think? Aside from one holdout, the consensus seems to be to have the "website" field be non-ital. Do we need to create a formal RfC, or have we reached consensus? --Tenebrae (talk)
If all sources are italicized, including sources that contain the cited work, then websites should be italicized for both stylistic consistency and semantic reasons (e.g. to distinguish a webpage or section from the hosting website). — Preceding unsigned comment added by 64.134.64.231 (talk) 21:43, 5 September 2015 (UTC)
T: You don't seem to understand the distinction I am making, and have thereby misstated my view. Note: I believe we have no disagreement that (e.g.) titles can be (even should be) italicized. Also, that hostnames - such as found in URLs, and when used as hostnames - are NOT italicised. What you don't seem to understand is the use of a hostname in other contexts, such as in a title, or as the proper name of a website. Where I say that "Amazon.com" - note the capitalization, which is generally not done in urls - could be italicized it is very much dependent on it being used in the context of a title (like of a book) or proper name. That you think there is consensus to not italicize "website" is only because you have conflated "website" with "hostname". This is indicated by your earlier reference to "dotcom names". Strictly speaking, there no such things, except in the casual use of "XXXX.com" to refer to the website of some company XXXX. While such uses are in the fashion of a hostname, simply adding ".com" to some name does not make it a hostname, and does not exclude it from italicization. ~ J. Johnson (JJ) (talk) 22:05, 5 September 2015 (UTC)
I believe this is a valid point. The print product Grapes of Wrath, delivered by a printer, is not the book Grapes of Wrath delivered by a publisher. The digital product Amazon.com, delivered by a software developer, is different from the website www.amazon.com delivered by an online publisher. In most cases what is cited as the source is the content, not the "delivery method/packaging", as it were.208.87.234.201 (talk) 14:43, 6 September 2015 (UTC)

I can only repeat my previous point. At present, |website= is simply a synonym of |work=, and so its value should be italicized, in line with the usual style for a work. It would be possible to give the two parameters a different meaning, but this would require a huge number of existing uses to be checked. Since "website" seems to be widely misunderstood, perhaps its use should be deprecated? Peter coxhead (talk) 19:28, 6 September 2015 (UTC)

I agree that "website" (as in "work") can be italicized; the problem seems to be where people mistakenly equate it with the url/hostname. Perhaps the documentation should be clearer about this. And perhaps a bot could flag all the instances where the value of |website= is a valid hostname. I am reluctant to deprecate |website= as I think it has a good use, but if the problem is too great then that is something to consider. ~ J. Johnson (JJ) (talk) 21:34, 6 September 2015 (UTC)
Editors were perplexed or confused with the term 'work'. In response to this feature request, |website= became an alias of |work=.
—Trappist the monk (talk) 22:12, 6 September 2015 (UTC)
Suggesting that it is the concept of "website" as a "work" that is confusing. ~ J. Johnson (JJ) (talk) 22:36, 6 September 2015 (UTC)
So Amazon.com should not be italicized by www.amazon.com should, is what you're saying? First, I'm not sure how often we would be citing a raw URL. Second, I don't see URLs italicized in any mainstream source. I'm not sure it's a positive thing for WIkipedia credibility to be adopting highly non-standard forms of citation. I'm not sure this is any different from citing authors by first name rather than last. That would be a highly non-standard way of citing, and would only make Wikipedia look eccentric. I'm thinking that italicizing URLs where virtually no one else does might do the same. --Tenebrae (talk) 17:03, 7 September 2015 (UTC)
No, I believe he's saying the reverse. Amazon.com is the name of a website, and as a major published work, it would be itaicized if included in a citation. On the oter hand, www.amazon.com is the hostname and wouldn't be itaicized nor would we need to cite it. Imzadi 1979 → 17:59, 7 September 2015 (UTC)
Again, no one italicizes Amazon.com or Sears.com, RottenTomatoes.com, etc., including those companies themselves. A URL / hostname / website does not suddenly change and become a book, magazine, newspaper or other "major published work." There's a reason we say things are "posted to the Web" and not "published to the Web". I think the fact no one in the mainstream italicizes these things should be a significant factor in this discussion. --Tenebrae (talk) 18:24, 8 September 2015 (UTC)
Exactly. Tenebrae, you started off with an incorrect understanding, so everything else that follows is invalid. If you start off the right way (and if you understand/accept that "website" ≠ hostname) I think you will find that we are largely in agreement. ~ J. Johnson (JJ) (talk) 20:40, 7 September 2015 (UTC)
I would like to think so, but a fundamental issue is that I believe the "website" parameter should not be italicized. Virtually no mainstream source italicizes either website names or URLs, which I take it is what you mean by "hostname". Italicizing websites/URLs is non-standard and does Wikipedia no good. --Tenebrae (talk) 21:52, 7 September 2015 (UTC)
You need to loosen your death-grasp on 'the "website" parameter should not be italicized'. Your implicit argument is that URLs (which includes hostnames) are not italicized. Look, we all get that part - everyone agrees that URLs should not be italicized. And that includes parts of a URL, such as hostnames. So it is a bit annoying that you keep asserting that. What you don't get is that this is irrelevant, because "website" does not equal URL/hostname. In particular, what you don't get is that a website - that is, a site on the World Wide Web with "web page" (HTML) content - can have a proper name. E.g.: the name of the website located at the WWW address "www.nytimes.com" is The New York Times - which is properly italicized. I repeat: "website" ≠ hostname. ~ J. Johnson (JJ) (talk) 21:58, 8 September 2015 (UTC)
With all respect, we're talking specifically about a field in "cite web" called "website". If we're citing The New York Times, we use "cite news or "cite newspaper" and enter the name of the paper in the field "work".
But I am confused, because it does sound as if we both agree that the name of a website is not italicized unless it's a newspaper, magazine, etc. ... in which case we wouldn't use "cite web." So ... am I wrong or do we agree that if we use "cite web" that the field "website" should not be italicized?--Tenebrae (talk) 22:29, 8 September 2015 (UTC)
Suppose one wanted to cite this web page. Becuase it isn't a newspaper, it isn't a journal, nor a book, nor anything but a web page, then I would cite it with {{cite web}} like this:
{{cite web |url=http://www.cdc.gov/ncbddd/autism/data.html |title=Autism Spectrum Disorder (ASD) |website=[[Centers for Disease Control and Prevention]] |date=12 August 2015}}
"Autism Spectrum Disorder (ASD)". Centers for Disease Control and Prevention. 12 August 2015.
—Trappist the monk (talk) 23:04, 8 September 2015 (UTC)
Yet nowhere else is the Centers for Disease Control and Prevention italicized. Same with CNN or CBS News. They are not publications, and I'm not sure it makes sense for Wikipedia to transmogrify them and pretend that they are publications. CBS News is never italicized. CNN, Sears, BBC, Rotten Tomatoes — none of these are italicized. If virtually no one else in the mainstream is italicizing these entities, I'm not sure why Wikipedia would. It makes us look eccentric. Do you see my reasoning?--Tenebrae (talk) 23:54, 8 September 2015 (UTC)
Agreed, yet the name of the website at http://www.michiganhighways.org , if it were being cited, is "Michigan Highways" per the site's mastheads. If it were being cited, it should appear in italics as the name of a major work (as opposed to individual webpages within the site which would be minor works in quotation marks). There is no entity named "Michigan Highways" to be called a publisher. In some of those cases being mentioned above, what is being claimed as the name of a website is the publisher. Not all websites have names, but when they do, they should be in italics. If a website lacks a separate name, without resorting to creating "Official website of X", then |website= should be left blank. It's the same in comparing the news sites of WLUC-TV (Upper Michigan's Source) with that of WBUP-TV (no name). Imzadi 1979 → 00:48, 9 September 2015 (UTC)
cs1|2 take their styling cues from MLA, APA, CMOS, and, no doubt, stuff we've made up ourselves. There is this, which on pages 4 and 5, compares three style guides for citing online material:
"The Purdue OWL: Citation Chart" (PDF). Online Writing Lab. Purdue University. pp. 4–5.
If one is to believe that, website names are rendered in italics in citations so my CDC citation above is correctly rendered.
—Trappist the monk (talk) 00:51, 9 September 2015 (UTC)

Wikipedia is highly non-standard. Contributors are not vetted. Sources are not systematically checked. Citation styles are not enforced. Editors have widely varying expertise. Consumers cannot be assumed to be experts. The present problem should I think take this non-standard approach into account. If the source is a website (a collection of pages connected by hyperTEXT links and employing the digital equivalent of a markup language) then should be treated the same way CS1 treats other similar collections in other media. --— Preceding unsigned comment added by 64.134.64.231 (talk • contribs) 19:43, 7 September 2015

Tenebrae, lets say I want to something from the New York State Department of Motor Vehicles website, something that only appears on the website, and is not in any book, pamphlet, etc. So I use cite web. And I use |website= = New York State DMV because that is the title of the web site. I know it is the title of the website because when I examine the html source for the home page of the web site I find <title>New York State DMV</title>. It should be italicised because that is the title of the work. Jc3s5h (talk) 23:06, 8 September 2015 (UTC)
Except no one other than we italicize it. New York State DMV is a proper-noun entity, but to suggest that all proper-noun entities be italicized — I dunno. I mean, what's the advantage of italicizing CBS News, Sears, New York State DMV, Yellowstone Park or United Airlines? Would readers not understand that " 'Traffic Laws in 2015'. New York State DMV." comes from the New York State DMV? I'm not sure what the advantage is of going with a deliberately eccentric format.--Tenebrae (talk) 23:58, 8 September 2015 (UTC)
At the NYS DMV website, the <title>New York State DMV</title> html officially declares to the world "the title of our website is New York State DMV. My Firefox browser responds to that declaration by putting that title in the tab associated with the web page. Style guides outside Wikipedia, mentioned in this discussion, explain that when a website has a title, that title is italicised, and we have decided to follow that guidance. It has nothing to do with whether "New York State DMV" is a proper noun phrase or not. Jc3s5h (talk) 14:15, 9 September 2015 (UTC)
And my Google Chrome does not italicize anything at http://dmv.ny.gov/. Nor does the title of the page itself, in big blue letters. As for "we have decided," that's what this discussion is for, to discuss a change. Because having a style that virtually no one else uses just seems remarkably eccentric for no purpose. I don't believe any of us has ever seen, anywhere, "Author's Page". Simon & Schuster. No one would ever italicize the publisher Simon & Schuster. And to suggest that Rotten Tomatoes, which is not italicized in article text, be italicized in the footnote seems determinedly inconsistent. I think we're going to need wider input from all of Wikipedia.--Tenebrae (talk) 16:35, 9 September 2015 (UTC)
T: We are not saying that "that all proper-noun entities be italicized". In the context of citation publications ("works") are italicized, publishers are not. This is not "eccentric", this is a standard convention. So we italicize the titles of webpages (as Jc3s5h just explained), such as Sears or New York State DMV. We do not italicize Simon & Schuster, Sears (the company), nor the New York State Department of Motor Vehicles. What kind of font is used on the website has nothing to do with it. (E.g., that the New York Times uses a serif title font has absolutely no bearing whatsoever on how a citation is formatted.)
Your persistent failure to understand this is starting to sound like a WP:HEARing problem. ~ J. Johnson (JJ) (talk) 01:13, 10 September 2015 (UTC)
No, it is the other way around, and I'll thank you stop casting aspersions. Pick up some books with footnotes and see whether web pages are italicized. See what AP Stylebook, the largest style guide in the English-speaking world, has to say. Nobody properly writes Rotten Tomatoes in regular font in article prose and then, inconsistently, puts it in italics in footnotes. Virtually no one in the world would italicize an organization like CBS News when citing something from the CBS News website. Organizations and institutions don't suddenly become titles because they have a web page.
Try and WP:HEAR this: The information we get from the New York State Department of Motor Vehicles comes, ultimately, under the auspices of the New York State Department of Motor Vehicles and not from the Web editor who inserted the information onto the web. Just as we cite The New York Times and Entertainment Weekly and not NYTimes.com or EW.com, the information from those websites ultimately comes under the auspices of those organizations. And in the case of non-publications, those organizations' names are not italicized. Now stop making false accusations — I understand perfectly, as I've said. It's you who seem to have trouble grasping the concept. --Tenebrae (talk) 20:26, 10 September 2015 (UTC)
False accustations? Aspersions? Perhaps you should review the bit at WP:NPA that accusing someone of a personal attack can also be considered a personal attack.
My "accusation" is that you have repeatedly failed to understand what is being said here. E.g., you have just insisted that "no one in the world would italicize an organization like CBS News", and "those organizations' names are not italicized." But who has said we should? You have implied that I did (and again at the RfC (below). But that is false. I have no where said that names of organizations should be italicized. And you seem to have totally missed what I said in my last comment regarding organizations: We do not italicize Simon & Schuster, Sears (the company), nor the New York State Department of Motor Vehicles. (Emphasis added for the hard of hearing.) You have mis-taken my position, and are arguing against something (italicization of organizational names) that nobody is arguing for. If you in fact do "understand perfectly" then why are you arguing a non-issue? I surmise that you have confused "website" with "publisher", just as you earlier confused it with "hostname". I submit that not understanding this despite repeated explanations does sound like a WP:HEARing problem. ~ J. Johnson (JJ) (talk) 22:38, 10 September 2015 (UTC)
Don't you dare accuse me of uncivil behavior, when you were the first to say that anyone who took a different position from yours must, of course, have "faulty" reasoning. And you compound your incivility by falsely claiming I was deliberately misunderstanding in order to obfuscate. How dare you. Look around this RfC — other people have no problem whatsoever understanding my point, so the fact that only you seem to have a problem understanding seems ironic, given your accusations. You say organizations should not be italicized, but you support leaving the "website" field italicized (01:19, 10 September 2015) because the very same words are not, in your view, that of organization anymore but of a page title. That seem contradictory. I've already explained that when we're using publications, we wouldn't be using "cite web" field but "cite news" etc., so why you keep bringing up publications is beyond me. --Tenebrae (talk) 23:23, 10 September 2015 (UTC)
Yes, I think I will dare to accuse you of uncivil behavior: of grotesquely misrepresenting my views, of attributing to me things I have clearly not said. Let's start with your statement that I was "the first to say that anyone who took a different position from yours must, of course, have "faulty" reasoning." Where? Give us a diff. That view is entirely your interpretation. As I said at the RfC, you it have backwards: I disagree with your position because your reasoning is faulty, not the other way around. As to your "deliberately misunderstanding in order to obfuscate: I asked why (if, as you stated, you "understand perfectly") you are arguing a non-issue. Again, the suggestion "in order to obfuscate" is entirely yours, not mine. But now that you have raised it, is that your answer to my question?
I think it is quite evident that your understanding of matters here (and reasoning) is faulty, but as all efforts (of others as well as mine) to explain this to you are unavailing it seems pointless to continue. If you can provide that diff, fine, but otherwise you should cease your flailing about. If anyone else thinks that I have misunderstood something, please bring it to my attention. ~ J. Johnson (JJ) (talk) 23:48, 11 September 2015 (UTC)

deprecate enumerator-in-the-middle parameters

See this archived discussion.

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

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

† these parameters are the canonical form

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

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

While all these are valid and could exist in the same article

|authorn-last= vs. |lastn=
|editorn-first= vs. |firstn=

they are also inconsistent. Just as parameter case was decided to be lower-case, this could also be decided in similar fashion.72.43.99.130 (talk) 19:34, 9 September 2015 (UTC)

|translator=

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

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

And an example:

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

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

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

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

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

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

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

Good, as long as these also work:
|translatorn-first=
|translatorn-last=
Discussions above (e.g. #deprecate enumerator-in-the-middle parameters) do not indicate a consensus in favor of this role-lastn order, with multiple editors objecting to it as counter-intuitive.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  02:16, 29 August 2015 (UTC)
As also noted in the relevant discussion, retaining both
|[role]n-last=
|lastn=
and
|[role]n-first=
|firstn=
is inconsistent and could also be counterintuitive. Per your suggestion then, |lastn=, |firstn= should be deprecated? 208.87.234.201 (talk) 14:52, 12 September 2015 (UTC)

Request move for Module talk:Citation/CS1

Could use some eyeballs at Module talk:Citation/CS1/Archive 12#Requested move 9 September 2015. Thanks! Kaldari (talk) 01:37, 15 September 2015 (UTC)

Add citationstyle= parameter to CS1 templates

All the talk about having |website= in italics or not got me thinking:

What if the cs1 templates like {{cite web}} etc. had a |citationstyle= parameter, with values of LSA, Vancouver, etc.

When these values are used, the CS1 templates would become "wrapper" templates to the existing Vancouver, LSA, etc. templates.

This would be a lot of work, but assuming the work got done, do you think the parameter would get a lot of use? davidwr/(talk)/(contribs) 02:47, 11 September 2015 (UTC)

We have a start to this in |mode= and |name-list-format=, but you're right, it would take some work. – Jonesey95 (talk) 02:58, 11 September 2015 (UTC)
Your idea has been in the back of my mind since the introduction of |mode= or there abouts. At about the same time there was a kerfuffle regarding small caps and LSA if I recall correctly. I have thought that we can extend |mode= to support clearly defined styles. Step 1 after we decide that this is something that we should be doing is to set down just exactly what it is that defines a particular style and then and only then hack the code to make it a reality.
—Trappist the monk (talk) 03:04, 11 September 2015 (UTC)
I strongly favour this idea. It would render the maintenance of citations easier if there are fewer citation template types. Also, fixing inconsistent citation styles or changing them when there is consensus to do so would be much easier.Jo-Jo Eumerus (talk, contributions) 08:54, 12 September 2015 (UTC)
Ideally, in my view, |mode= would be used with the {{citation}} template, which would make life much simpler for users – no need to choose which of the cite templates to use. However, I suspect this is difficult or impossible in all cases because there isn't always enough information to pick the right formatting. The |website= discussion above exemplifies one issue: having it as an alias of |work= loses information. Peter coxhead (talk) 10:00, 12 September 2015 (UTC)
I strongly oppose having multiple citation styles at all, much less supporting external ones (i.e. other than CS1 and CS2, and we should retire CS2). But if we're stuck with it, something like this is the way to do it, and we should get rid of external-citation-style-specific templates for Vancouver, etc., and just have it all done by the Lua module on the fly. So consider this "support until we come to our senses and have a single citation style like, well, every other publication in the world".  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  12:31, 12 September 2015 (UTC)
If we are to retire one of CS1 or CS2, I would strongly prefer it to be CS1. All. Those. Periods. Make. It. Very. Difficult. To. Read. And. Really. What's. The. Point. Of. Them? —David Eppstein (talk) 20:28, 15 September 2015 (UTC)
Not sure how I feel about this being in {{cite xxx}} / {{citation}}, but I'd definitely support this feature if it could be shoved in {{reflist}}. Headbomb {talk / contribs / physics / books} 13:27, 12 September 2015 (UTC)
Reflist is only capable controlling styling of what's inside it, but that requires a strong classing dicsipline inside the templates (so same problem as above). It has absolutely no way of controling content of these templates. -- [[User:Edokter]] {{talk}} 09:06, 13 September 2015 (UTC)

Handling multiple italicized titles

Notwithstanding the above RfC, which appears to be firmly in favor of retaining the italics by default, we might actually want a |work-noitalic=yes, as something to be used on a case-by-case basis for a reason, and not just created so people can evade a style they don't like. A genuine use case for it would be books (discrete major works) that have been published inside other books (bound paper things) with separate titles. I'd like to be able to do: {{Cite book|chapter=Foreign Words and Phrases|work-noitalic=yes|work=''The Oxford Guide to Style'', in ''Oxford Style Manual''|...}}.

Another example would be: {{Cite book|chapter=Foreign Words and Phrases|work-noitalic=yes|work=''Blood of the Isles: Exploring the Genetic Roots of Our Tribal History'' [North American title: ''Saxons, Vikings and Celts: The Genetic Roots of Britain and Ireland'']|...}}.

Another approach to this, that might be less prone to "gimme my own style" abuse, would be to distinguishing the two use cases:

My approach to handling the former case has been {{Cite book|chapter=Foreign Words and Phrases|title=The Oxford Guide to Style|...}} (published as part of {{Cite book|title=Oxford Style Manual|...}}. For the latter I've been doing something similar, using two citation templates. It's an unnecessarily longwinded way to do it, and prone to breakage because it doesn't keep all the citation's details in one template "package".  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  16:12, 14 September 2015 (UTC)

{{cite encyclopedia}} does something like this:
{{cite encyclopedia |chapter=Chapter |title=Title |encyclopedia=Anthology}}
"Chapter". Title. Anthology.
and so does {{cite book}} (sort of):
{{cite book |chapter=Chapter |title=Title |encyclopedia=Anthology}}
"Chapter". Title. {{cite book}}: Unknown parameter |encyclopedia= ignored (help)
There are constraints imposed by the metadata. A book title in the metadata is two parts: article (chapter) title and book title. {{cite encyclopedia}} emits the value from |chapter= and |encyclopedia=. {{cite book}} on the other hand, emits the values from |chapter= and |title=. Presumably, the {{cite encyclopedia}} model is the preferred model for an anthology because, one presumes, that parameters like ISBN, publisher, etc. apply to the anthology and not to the component book. There is no way that I know of to feed a three-part title to the metadata.
It would seem not to difficult a task to create {{cite anthology}} and |anthology= so that we don't 'misuse' {{cite encyclopedia}}.
—Trappist the monk (talk) 17:15, 14 September 2015 (UTC)
The example of different titles depending on place of publication seems to go against the principle of editors citing the copy that they examined. In most cases one editor would add the cite, and would have had access to only one copy. If an American and UK edition were used, probably they were used by two different editors, and the two editors would not necessarily know if the pagination in the two versions was the same. Jc3s5h (talk) 17:55, 14 September 2015 (UTC)
Right. Titles are the primary identifier of books (and other items), and if a publisher changes the title there is no telling what else may have been changed. If two titles are actually identical than one might be considered a reprint of the other, but how would an editor know that? Best that distinct titles have distinct citations. If a book or article has been republished under a different title that can be mentioned following the citation. ~ J. Johnson (JJ) (talk) 22:40, 14 September 2015 (UTC)
This isn't quite what I'm getting at. These are works that I have on hand, and they have three relevant titles: "Chapter/Article", Logical Book, Physical Book, in the one case, and "Chapter/Article", Regional Book Title I [Regional Book Title II], in the other. In the first case, I'm citing the specifics of a single work that has a hierarchy of three, not two, titles. In the other, I'm providing information to help readers locate the same source under two names (it has a typical hierarchy of two titles, but the major title has two variants). They're different cases.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  01:23, 15 September 2015 (UTC)
Oh. What you are talking about is not alternative titles, but titles at hierarchial levels of organization (e.g., work/chapter/section) - right? I got into that with the IPCC citations, but I am disinclined to re-visit it. ~ J. Johnson (JJ) (talk) 23:04, 15 September 2015 (UTC)

Cite book needs work alias for title

The above reminds me: {{Cite book}} needs to support |work= as an alias of what it calls |title=; as far as I recall, it's the only template in the series that doesn't support |work=, and this is a hassle for multiple reasons (having to remember which template demands what, not being able to convert easily between {{cite web}} and {{cite book}} for e-books, etc.).

Strictly speaking, it might make the most sense to re-code the {{Cite book}}'s |title= as an alias of existing |work= code (the input that gets italicized as a major work) in Cite/core, and use the same code to generate all |work= titles across all the templates. What is presently handled as |title= in almost all the templates (i.e., the input that gets quotation marks as a minor work) could be turned into an object called |item= or something, with |title= usually being an alias to it, and {{Cite book}}'s |chapter= being one, but using the same function to generate it regardless what template calls it.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  16:12, 14 September 2015 (UTC)

For the purposes of cs1|2, {{citation/core}} is dead.
{{cite book}} only supports |work= visually (discussed here) for which reason I have suggested elsewhere in these pages that |work= and its aliases should be ignored by {{cite book}} as they were in the old days of {{citation/core}}.
—Trappist the monk (talk) 17:54, 14 September 2015 (UTC)
That you have a preference in this regard doesn't address why lack of support for |work= is problematic. I'm not suggesting that {{Cite book}} handle |title= and |work= as separate entities, but rather alias one to the other, the same way |accessdate= can also be called |access-date=. I'm not sure what "only supports |work= visually" even means, but have to run for now; will re-read that stuff and see if I can suss your meaning, if you don't clarify in the interim.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  01:27, 15 September 2015 (UTC)
{{cite book}} only supports |work= visually... means that you can have |work= in {{cite book}} with |title= and you will see it in the rendered citation. But, a value in |work= without |chapter= causes an error in the metadata – the citation is treated as a journal article (a bug I think that bears some thinking on). When |chapter= is included with |title= and |work= in {{cite book}}, |work= is rendered but not made part of the metadata while the other two parameters are (correctly this time).
—Trappist the monk (talk) 03:03, 15 September 2015 (UTC)
That sounds like it would be fixed by having |work= and |title= be the same thing (one an alias for the other). Why would we want {{Cite book|title=...|work=...}}? That would generally make the same not-sense as {{Cite journal|journal=...|work=...}}. That said, having a special case where the use of both would case |work= to render but be omitted from the metadata would actually resolve my above need for being able to cite The Oxford Guide to Style (a logical |work=, and previously published as a separate volume, and in both editions having its own chapters and authors and such), and the Oxford Style Guide (a published |title= of the book in the "bound thing of paper in my hands" sense). In pseudocode:
if $title
if $work
[optional code for handling work-editor, etc., if separate from editor, etc., of $title]
print italicized $work [without metadata]; print ', in '; print italicized $title [with metadata];
else print italicized $title [with metadata]
else if $work
print $work [with metadata as if $title]
else [i.e. both are missing] throw missing-title error
Seems pretty simple, though I forget what is using template code and what is using Lua in these things. This could even be used for bound journals, with the bound physical book being cited as the |work= and the journal issue being cited as |journal=. I ran into this problem before trying to cite my bound volumes of Jugend, The Studio, etc., in some Art Nouveau articles, and again ended up doing the two-citations-back-to-back thing: {{Cite journal}} followed by a {{Cite book}} for the bound volume that was largely a redundant citation, but necessary to both WP:SAYWHEREYOUGOTIT and preserve the details of the bound and original publications. This can be important because, e.g. The International Studio was bound by more than one operation, and differently; I have some bound volumes of it that overlap, with some being bound by calendar year, the others being bound by the journal's own volume/issue numbering order.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  23:49, 16 September 2015 (UTC)

The main use case I can see for having both |title= and |work= in a {{cite book}} would be for a long multivolume work where you want to separately represent the titles of the whole work and of the volume. But that's better handled with |title= and |volume= now that the volume parameter knows to not boldface long parameter values, as for instance in

{{cite book|first1=Elwyn R.|last1=Berlekamp|first2=John H.|last2=Conway|first3=Richard K.|last3=Guy|title=[[Winning Ways for your Mathematical Plays]]|volume=Volume 2: Games in Particular|year=1982|publisher=Academic Press}}
Berlekamp, Elwyn R.; Conway, John H.; Guy, Richard K. (1982). Winning Ways for your Mathematical Plays. Vol. Volume 2: Games in Particular. Academic Press. {{cite book}}: |volume= has extra text (help)

So I agree with the general sentiment that having title and work be aliases of each other seems harmless enough, as long as we can get an error flag when both are used together to let us find them and replace one of the two parameters by volume or series or whatever the replacement should be. However, this does bring up a different issue (not really solved very well by misuse of the work parameter): what do we do when we have a book series that contains a multivolume book and we want to refer to one volume of that book? The |volume= parameter currently has two quite different semantics: the number of a book within a series of books, and the number or title of a volume within a single multivolume book. Is there some way to add a |series-volume= parameter to be used in ambiguous cases, or something like that? —David Eppstein (talk) 00:37, 17 September 2015 (UTC)

choosing the correct metadata when |chapter=, |title=, and |work= are all set

Here is a list of all of the cs1 templates in the form:

{{cite ___ |title=Title |chapter=Chapter |work=Work}}

and cs2:

The purpose of this list is to examine how the various templates handle the three parameters when all are set. Another conversation led me to discover that Module:Citation/CS1 may not be emitting correct metadata when |work= is set.

In Module:Citation/CS1 (and in {{citation/core}} before it), |work= and its aliases (|journal=, |newspaper= etc.) map to the meta-parameter Periodical. Similarly, |chapter= (and its aliases |article=, |contribution=, etc.) map to the meta-parameter Chapter.

There are two types of metadata: book and journal. When creating the citation's metadata, the module looks first at Chapter. If Chapter is set then the metadata type is set to book. If Chapter is not set but Periodical is set then the metadata type is set to journal. For all other cases, the metadata type is set to book.

Because the module knows which of the cs1|2 templates it is processing, we can use that knowledge to fix this issue. I will change the module so that these templates produce journal type metadata:

Then comes a more difficult question. The metadata can accommodate two title-holding parameters: rft.jtitle and rft.atitle for journals, or rft.btitle and rft.atitle for books. When cs1 templates use three title-holding parameters |chapter=, |title=, and |work=, which two of these should be made part of the metadata? Some templates are already constrained to one or two title-holding parameters; should others be similarly constrained?

—Trappist the monk (talk) 13:35, 15 September 2015 (UTC)

Module:Citation/CS1/sandbox tweaked. These are {{cite conference}} examples:
  • |title=, |chapter=, |work= – uses jtitle, atitle, and sets genre to article
    • '"`UNIQ--templatestyles-000000B9-QINU`"'<cite class="citation conference cs1">"Chapter". ''Title''. ''Work''.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=conference&rft.jtitle=Work&rft.atitle=Title&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+9" class="Z3988"></span>
  • |title=, |chapter= – uses btitle, atitle, and sets genre to bookitem
    • '"`UNIQ--templatestyles-000000BB-QINU`"'<cite class="citation conference cs1">"Chapter". ''Title''.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=conference&rft.atitle=Chapter&rft.btitle=Title&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+9" class="Z3988"></span>
  • |title= – uses btitle and sets genre to book
    • '"`UNIQ--templatestyles-000000BD-QINU`"'<cite class="citation conference cs1">''Title''.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=conference&rft.btitle=Title&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+9" class="Z3988"></span>
the same but this time with the one-way alias |book-title=; chapter is held in |title= (|chapter= is ignored when |book-title= is set):
  • |book-title=, |title=, |work= – uses jtitle, atitle, and sets genre to article
    • '"`UNIQ--templatestyles-000000BF-QINU`"'<cite class="citation conference cs1">"Chapter". ''Title''. ''Work''.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=conference&rft.jtitle=Work&rft.atitle=Title&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+9" class="Z3988"></span>
  • |book-title=, |title= – uses btitle, atitle, and sets genre to bookitem
    • '"`UNIQ--templatestyles-000000C1-QINU`"'<cite class="citation conference cs1">"Chapter". ''Title''.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=conference&rft.atitle=Chapter&rft.btitle=Title&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+9" class="Z3988"></span>
  • |book-title= – uses btitle and sets genre to book
    • '"`UNIQ--templatestyles-000000C3-QINU`"'<cite class="citation conference cs1">''Title''.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=conference&rft.btitle=Title&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+9" class="Z3988"></span>
—Trappist the monk (talk) 15:05, 15 September 2015 (UTC)

error message tweak

I have tweaked Module:Citation/CS1/sandbox. The current live version of the module lumps all aliases of |chapter= into a single '|chapter= ignored' error message. This tweak causes the error message to identify the alias that is used in the cs1|2 template:

—Trappist the monk (talk) 23:53, 15 September 2015 (UTC)

Wouldn't it be far more helpful to directly alias these to cite journal's version of |title=, given that that's what they mean? If they're used at the same time, then |chapter= could be treated as |at=, within |title=. And if |at= is also present, well, I dunno; have an |at2=.

This brings me back to my earlier proposal of normalizing all these parameter names across all the templates. It would be so much simpler if we had something like this:

{{Cite ______
|cite=
|at=
|work=
|...
}}

where |cite= is the minor work being cited (article, episode, book chapter, song on album, etc.); |at= is a subset there of, where relevant (section of article, section of book chapter, whatever); |work= is the major work (journal/newspaper/magazine, website, book title, album, TV series, etc.). I get more and more tempted all the time to just go create a CS3 designed from the start to be mutually consistent across all media types, so someone could learn how to cite in one sitting and get it right no matter what they're citing.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  23:12, 16 September 2015 (UTC)

Hindsight being what it is, were we to do it again, crafting a citation system from the ground up by starting with a real style guide and then coding to that would be preferable. But that isn't how it happened. We started with one or two templates that evolved into some twenty, all written independently. {{citation/core}} reduced the differences amongst the templates and Module:Citation/CS1 continues that with varying amounts of success. That is the problem with the evolutionary nature of Wikipedia: start with something disruptive and then tweak it until it's just good enough.
—Trappist the monk (talk) 09:59, 17 September 2015 (UTC)

COinS and smallcaps

Template:Smallcaps/doc needs an update (where the {{clarify}} tag is) on what people should do to get the desired Small Caps effect for certain things in particular citation styles, given that {{Smallcaps}} is not COinS-safe.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  23:02, 16 September 2015 (UTC)

 Done. Let me know if my edits are unclear in incomplete. – Jonesey95 (talk) 03:37, 17 September 2015 (UTC)

<cite> has been fixed, so we can now use it for entire citation

Yay! <cite>...</cite> has now been fixed to stop forcing italicization, so we can now use it instead of <span>...</span> to wrap the entire citation. This, BTW, has been interesting in that WP as a "developer user" of HTML & CSS has actually gotten W3C to fix things. Their own advice with regard to this element was self-contradictory between documents, and I got them to normalize to the current HTML5 description of the element. Details at Mediawiki talk:Common.css#cite-updates (anchor to update reporting in middle of larger thread about this issue over the last month or two).  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  12:54, 12 September 2015 (UTC)

Done in the sandbox; compare live:
'"`UNIQ--templatestyles-000000CF-QINU`"'<cite class="citation book cs1">''Title''.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Title&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+9" class="Z3988"></span>
to sandbox:
'"`UNIQ--templatestyles-000000D1-QINU`"'<cite class="citation book cs1">''Title''.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Title&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+9" class="Z3988"></span>
—Trappist the monk (talk) 13:47, 12 September 2015 (UTC)
Two comments:
  1. @Pigsonthewing:, I think this may be the incorrect way to handle the microformat. Have a look, if indeed that first span is intended as a microformat.
  2. The intent was for the <cite> to wrap the entire citation, whereas the sandbox is only wrapping the title. --Izno (talk) 19:30, 12 September 2015 (UTC)
Re: #1: why do you think it's wrong?
Re: #2: I made a minimal example because that is easier to read. Here is one that is more complex:
'"`UNIQ--templatestyles-000000D3-QINU`"'<cite class="citation web cs1">[http://www.cdc.gov/ncbddd/autism/data.html "Autism Spectrum Disorder (ASD)"]. ''[[Centers for Disease Control and Prevention]]''. 12 August 2015.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=unknown&rft.jtitle=Centers+for+Disease+Control+and+Prevention&rft.atitle=Autism+Spectrum+Disorder+%28ASD%29&rft.date=2015-08-12&rft_id=http%3A%2F%2Fwww.cdc.gov%2Fncbddd%2Fautism%2Fdata.html&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+9" class="Z3988"></span>
—Trappist the monk (talk) 19:41, 12 September 2015 (UTC)

The class=citation book looked like a microformat pair of classes to me, rather than what is their more likely use of just plain ol' CSS classes.

Didn't realize the COinS was dumped at the end of the citation. I haven't looked too closely at the HTML behind the template system before.... --Izno (talk) 00:08, 13 September 2015 (UTC)

Looks OK to me. Strictly, COinS isn't a microformat, and works differently to them. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:12, 12 September 2015 (UTC)
I would check and make sure that Mediawiki:* and other parts of the CSS cascade aren't anywhere doing anything that relies on span.citation vs just .citation, and same for the .book class selector. I.e., ensure that moving the classes from <span> to <cite> doesn't break something we don't notice immediately. Then again, if it does, I'm sure someone will tell us. I've not looked at COinS much; if the book, etc., classes are part of COinS, they do seem to need to be in <span>, so we might need both (presumably the <span> inside the <cite>, since the span by itself would have no semantic "reality" on its own); but if that's just one of WP's own classes, it can be in the <cite>.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  22:43, 12 September 2015 (UTC)
The extent of .citation in Common.css is the following: 
/* Highlight clicked reference in blue to help navigation */
span.citation:target {
    background-color: #DEF;
}

/* Styling for citations (CSS3). Breaks long urls, etc., rather than overflowing box */
.citation {
    word-wrap: break-word;
}

/* For linked citation numbers and document IDs, where
   the number need not be shown on a screen or a handheld,
   but should be included in the printed version */
@media screen, handheld {
    .citation .printonly {
        display: none;
    }
}
Indeed, @Edokter: I'm not sure about that first item there. Does the <ref>...</ref> include a span when it drops its content into the bottom of the page, or is that meant to specifically target our various and sundry reference templates? --Izno (talk) 00:13, 13 September 2015 (UTC)
That's the thing that makes the [2] or whatever of the ref citation turn light blue when you are in the refs section and click on the ^ link to get back to where you were in the text. So, yeah, that would need to change to refer to the <cite>, or to be a class by itself without the element being named (unless we really do need the span as well; I'm still not sure if that class has anything to do with COinS). Ultimately it probably does not matter if have a <cite><span>{{cite journal|...}}</span></cite> structure; costs nothing but a few bytes.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  03:21, 13 September 2015 (UTC)
The Cite extension already provides the styles to turn the automatically generated referneces blue with the selector ol.references li:target, sup.reference:target. [Removed my own irrelevant bits] The span.citation:target snippet is an old remnant of the old link targeting mechanism, before the extension took over. The current snippet is useless and can be safely removed, because 1) references generated by citation templates, by themselves (ususally appearing between {{refbegin}}/{{refend}}), have no id and therefor 2) are not (and cannot) be linked to. That makes :target pretty pointless. -- [[User:Edokter]] {{talk}} 10:01, 13 September 2015 (UTC)

class="citation" is required so that a cs1|2 template in a bibliography gets the blue highlight when linked from a reference in a reference list.[1] I've hacked the sandbox code so that class="citation" is not part of the <class> as an illustration.[2]

References

  1. ^ Blue 2008.
  2. ^ Not blue 2008.

—Trappist the monk (talk) 11:05, 13 September 2015 (UTC)

I see. In that case, The span should be removed or replaced by <cite>. Though it will work without the element in the selector, I'd prefer to keep the specificity consistent to prevent accidental linking to other elements with the .citation class. But that should not be a problem until the conversion is complete. -- [[User:Edokter]] {{talk}} 12:36, 13 September 2015 (UTC)
Sorry, I do not understand what you just wrote. In Module:Citation/CS1/sandbox, the cs1|2 template output (except for the COinS) was wrapped in <span>...</span>. It is now wrapped in <cite>...</cite>. My example shows, I think, that <cite class="citation"> is required to get the blue highlight when the target cs1|2 template is outside of a {{reflist}} as commonly occurs when an article uses {{sfn}} and {{harv}} et al.
—Trappist the monk (talk) 13:19, 13 September 2015 (UTC)
I was talking about the selector in Common.css. It should match whatever the module outputs. It now targets neither span or cite tags; just the .citation class, which is too broad. So I will make it target only cite.citation once the modules have been converted. If you still don't understand, don't worry about it. -- [[User:Edokter]] {{talk}} 21:52, 13 September 2015 (UTC)
FWIW, I am seeing blue highlight for the [2] ref even for the "Not blue" sample above, when I click on it's "^" link-back. I'm supposing this is because the underlying sandbox code has changed in the interim, but thought I'd report it in case not, and the example is supposed to do something else, since it might be relevant for debugging, if so.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  16:21, 14 September 2015 (UTC)
The superscripts do have the blue highlight; that isn't the issue. The issue is with the long-form citations; these links: #CITEREFBlue2008 and #CITEREFNot_blue2008 (or their mates in the reference list). The 'Blue' citation was rendered with <cite class="citation book"> but the 'Not blue' citation was rendered with <cite class="book">.
—Trappist the monk (talk) 16:33, 14 September 2015 (UTC)
Hack to Module:Citation/CS1/sandbox in support of the examples I made here is undone.
—Trappist the monk (talk) 11:23, 19 September 2015 (UTC)
@SMcCandlish: Congratulations on getting this fixed; it's good to see us as a movement contributing in that way. I've previously had WP:NOT cited at me when I've tried to get us to lead by example in similar areas. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:12, 12 September 2015 (UTC)
Pfft! WP:NOT has no power whatsoever to tell me who I can and can't contact off-wiki to fix things like W3C contradicting their own standards. >;-) It's the kind of thing I'd do anyway; the WP issue just made me notice this particular case. This may actually have quite noteworthy longer-term effects; apparently the entire W3C Cheatsheet was not being synched with the actual, live W3C Recommendation (the real spec), but had only been synched by hand or something to some old version in 2009! And WHATWG does what the Cheatsheet says. And browser makers and many others do what WHATWG says, to some extent. As far as I know, WHATWG has not updated its own materials yet since this W3C fix, but they should soon enough. I suspect and hope that much of what we're seeing with browsers lagging so far behind what the W3C HTML5 Recommendation says to do may be directly and primarily due to this synchronization failure. It would certainly be hot if that's the case, and all of sudden they started consistently implementing stuff we've been waiting on since 2013.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  22:28, 12 September 2015 (UTC)
2013 is awfully optimistic. --Izno (talk) 00:06, 13 September 2015 (UTC)
Hee haw! Yeah, I mean just the new stuff; I wasn't talking about stuff we've been waiting to work properly since the '90s. LOL. There did seem to be a rush to implement (at least with prefixes) lots and lots of stuff from the old draft and early release versions of HTML5, and then it just kind of stopped. I think it's because the Cheatsheet wasn't updated, so WHATWG didn't update. Then the HTML5 spec was revamped in 2013, and kinda nothing happened.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  03:09, 13 September 2015 (UTC)

In my opinion the CS1 and CS2 templates should produce HTML that not only gives the desired appearance at this moment, but also uses the HTML tags correctly. This thread should have begun with a link to the current official definition of the <cite> element so we could evaluate whether the changes discussed in this thread obey the documentation. Jc3s5h (talk) 15:22, 13 September 2015 (UTC)

WP:PROCESS is only important when it's important. :-) That documentation was already provided and discussed in the previous edition of this thread just a couple of weeks ago, and is also provided prominently in the Mediawiki talk:Common.css discussion linked to in the first post in this thread, where I indicated the matter had been discussed at length. Here it is again, with all the relevant off-site links. The purpose of pointers to such discussions is to avoid rehashing the same discussions. The entire point of these threads is, yes, to use the HTML correctly; the limitation of <cite> to title only was a 2009–2013 experiment that the HTML-using community rejected. As in HTML 4, the HTML5 spec allows this to cover citation data generally (the only required part is that at least one of the following must be present to use <cite>: author, title, URL).  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  13:53, 14 September 2015 (UTC)

Update: I've fixed the placement and styling of <cite>...</cite> in all the templates using it that are not Template:Cite something, Template:Cite/something, or Template:Citation/something, which I've deferred here to Help talk:CS1. (This was mostly fixing it in single-source citations and in quotation templates). All that remains is for it to be integrated into the more complex citation templates.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  13:53, 14 September 2015 (UTC)

|section= not working in cite news?

I used |section= in a {{cite news}} in the My War article, and I got the error: "|chapter= ignored (help)". Curly Turkey 🍁 ¡gobble! 23:13, 15 September 2015 (UTC)

This?
{{cite news |last = Hampton |first = Howard |title = Black Flag: Waving Goodbye to the World |newspaper = [[The Phoenix (newspaper)|The Phoenix]] |date = 1984-04-17 |page = 8 |section = 3 |url = https://news.google.com/newspapers?nid=1959&dat=19840417&id=OXMhAAAAIBAJ&sjid=OogFAAAAIBAJ&pg=2247,1781571&hl=en |ref = harv}}
Hampton, Howard (1984-04-17). "Black Flag: Waving Goodbye to the World". The Phoenix. p. 8. {{cite news}}: |section= ignored (help); Invalid |ref=harv (help)
|section= is an alias of |chapter=, hence the error message. Consider |at=Section 3, p. 8
Hampton, Howard (1984-04-17). "Black Flag: Waving Goodbye to the World". The Phoenix. Section 3, p. 8. {{cite news}}: Invalid |ref=harv (help)
—Trappist the monk (talk) 23:24, 15 September 2015 (UTC)
Is |section= (or |chapter= or whatever) not supposed to work, then? Curly Turkey 🍁 ¡gobble! 00:29, 16 September 2015 (UTC)
The mention of |chapter= and |section= in Template:Cite news#COinS could lead someone to think it is OK to use those parameters in {{cite news}}. GoingBatty (talk) 02:31, 16 September 2015 (UTC)
I sthere some reason it shouldn't be? The newspaper I cited had sections with their own paginations. Curly Turkey 🍁 ¡gobble! 03:58, 16 September 2015 (UTC)
Isn't it true that most newspapers have separate sections and pagination? The documentation for |at= at {{cite news}} specifically includes Section. The decision to make |section= an alias of |chapter= was taken long ago in support of another template ({{cite manual}} I think). Chapters are not supported in periodicals because it is not possible to shoehorn three cs1|2 title-holding parameters (|newspaper=, |title=, and |section= in this case) into the two metadata title-holding parameters (rft.jtitle and rft.atitle). Because there is an in-source metadata parameter (rft.pages), setting |at=Section 3, p. 8 renders the complete citation visually as well as in the metadata.
—Trappist the monk (talk) 10:46, 16 September 2015 (UTC)
Well, that went over my head, but okay ... But wouldn't it be better to have the template automatically format it at least, rather than spit out an error? Curly Turkey 🍁 ¡gobble! 12:18, 16 September 2015 (UTC)
The template spits out an error because it doesn't know what to do with a chapter alias in a periodical-style citation. How should it be automatically formatted? Quoted? Italics? Neither of those? Where in the rendered citation should it go? The answers to these questions must apply to a very large majority of the templates in which |section= is used.
—Trappist the monk (talk) 15:02, 16 September 2015 (UTC)
Well, if it's what I have to do then it's what I have to do, but it (a) feels like a hack, and (b) is totally unintuitive. |at= "May be used instead of 'page' or 'pages' where a page number is inappropriate or insufficient"—in this case |page= sure doesn't seem insufficient (it's on page 8!), and |at= isn't the obvious answer (you have to dig to find it, and then interpret the documentation as "Aha! This situation!").
if |section= et. al don't work, then shouldn't they be removed from the "COinS metadata is created for these parameters" section? Curly Turkey 🍁 ¡gobble! 23:27, 16 September 2015 (UTC)
|section= should be supported in periodicals, independently of |chapter=, because there are important sources that do break articles by sections. Also by paragraphs. ~ J. Johnson (JJ) (talk) 22:40, 17 September 2015 (UTC)

ISBN error category

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

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

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

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

This will break some ISBN fixing tools such as WPCleaner. -- Magioladitis (talk) 12:39, 19 September 2015 (UTC)

If Category:Pages with ISBN errors is hard coded into the tool, I have no sympathy. Wikipedia:WPCleaner/Configuration/Help#isbn_errors_categories suggests that ISBN categories are kept in a configuration file somewhere though that isn't at all clear from the documentation. If this latter is true, then I see no reason not to proceed.
—Trappist the monk (talk) 13:39, 19 September 2015 (UTC)
Magioladitis, can you provide some details? If we are breaking something by standardizing this category name, we are willing to help fix it or test the tool after the change. It looks like we may need to change the second category name at User:NicoV/WikiCleanerConfiguration#ISBN; will that fix the problem? – Jonesey95 (talk) 13:46, 19 September 2015 (UTC)

Test for date in |author=?

I came across a date in |author= while working on something else. How hard would it be to test for dates, or at least well-formed dates, in |author= fields? As always, I worry about false positives, so it may be something to put in a maintenance category.

I suspect that some sort of automated reference-filling tool populated |author= with dates, or at least included dates along with the author name, due to bad metadata on the source web page or bad processing of the page's data. – Jonesey95 (talk) 13:58, 19 September 2015 (UTC)

If such a test is to be created, bear in mind we allow editors to enter corporate authors in this field. Some organizations have a date fragment in their name. So the test should only be triggered if a well-formed date containing a year, month, and day is present. Jc3s5h (talk) 14:11, 19 September 2015 (UTC)
@Jonesey95: Edits like the one you've mentioned are a result of editors not fixing the suggestions given by Reflinks before saving their edits. We tried to discuss this with Dispenser but did not get any answer. BattyBot tries to fix/remove some bad author values, but can't fix them all. Therefore, I support a maintenance category. GoingBatty (talk) 14:16, 19 September 2015 (UTC)
Reflinks was the tool: diff and diff. But, like any edit, the tool-user is equally culpable.
If this is a problem caused by a tool, then the tool should be fixed. I suspect that searching for date formats that both do and don't comply with WP:DATESNO is a challenge that we should only accept if there is significant evidence of widespread malformed |author= parameters in the field.
(I've renamed this section to remove {{para}} so that section links from watch lists work.)
—Trappist the monk (talk) 14:31, 19 September 2015 (UTC)
@Trappist the monk: A quick search of the September 2015 database dump of found 2,304 results. I'm sure other formats will find additional instances. I'm adding some rules for BattyBot to remove the date from the author parameter when it matched the YYYY-MM-DD date in the date parameter. I'd also be happy if ReferenceBot would notify editors when they added references with incorrect parameters like this. GoingBatty (talk) 15:40, 19 September 2015 (UTC)
Is that number sufficiently large to make us add code to the module and create some sort of category to support it? Is this an automated tool issue or is it an error commonly made by editors filling out the template?
—Trappist the monk (talk) 16:06, 19 September 2015 (UTC)
@Trappist the monk: To determine if it's sufficiently large enough, I guess you would first identify the most common incorrect formats, see how many added/tweaked rules could be added to BattyBot, and then see how many are left. My guess is this is commonly an issue of people not taking care when using automated tools (and people unwilling to fix their tools), but I have no statistics on that. GoingBatty (talk) 18:32, 19 September 2015 (UTC)
How can BattyBot fix these errors if they are not yet in a category? – Jonesey95 (talk) 20:31, 19 September 2015 (UTC)
@Jonesey95: I built the list of articles based on a database search for author\s*=\s*(January|February|March|April|May|June|July|August|September|October|November|December)\s+\d{1,2},\s+\d{4}. GoingBatty (talk) 20:40, 19 September 2015 (UTC)

Citeweb website parameter

Would it be possible to make this respond to typing "site=" as well as "website=" ? "Web" is implied by the use of the template and this would take up less space and I find myself using that by accident a lot. Ranze (talk) 14:52, 22 September 2015 (UTC)

Proposal for lead with the main cite that Wikipedians come to this page for

I think right on the "first screen" that the reader sees, without having to scroll down, she should see what is probably the main cite format that people to come to this page for: cite web |url= |title= |last1= |first1= |last2= |first2= |date= |website= |publisher= |access-date= |quote=}}. I think this would be helpful : )OnBeyondZebrax • TALK 17:03, 17 September 2015 (UTC)

To be consistent, we would need to change the documentation for dozens of cite templates. Are there other templates whose documentation is structured in this way? I clicked on a sample of templates that I watch, including {{Birth date}}, {{Birth date and age}}, {{Death date and age}}, {{GOCE award}}, {{Infobox body of water}}, and {{Template for discussion}}. Of those that have a lead section and a table of contents, none of them do what OnBeyondZebrax proposes. – Jonesey95 (talk) 01:02, 18 September 2015 (UTC)

I think this would be quite unhelpful, actually. We should be encouraging Wikipedia editors to cite newspapers, books, and academic journals rather than web pages. And when they do cite those things, we should not be encouraging them to use the wrong template to do so. —David Eppstein (talk) 01:12, 18 September 2015 (UTC)

Yes. Especially where a web "source" only echoes a printed source. A large proportion of WP editors are quite unacquainted with the broad range of possible sources, and we need to gently encourage them to see beyond the web. ~ J. Johnson (JJ) (talk) 21:20, 23 September 2015 (UTC)

Foreign language authors & publishers

I'm wondering whether we should establish a way that foreign language author and publisher names should be handled in citation templates. This has been addressed before here: Help_talk:Citation_Style_1/Archive_8#Foreign author name (perhaps elsewhere but I was unable to find it) but there wasn't consensus on what should be done with author names that are written in non-Latin scripts. I understand that English sources are preferred on the English Wikipedia, but if the only sources available are written in Korean or Chinese, how should the author's name be included? Including only a transliteration does nothing to help someone who is trying to locate an article if its URL is dead. Since using the script-title and trans-title parameters produces "Script title [trans title]", perhaps something similar should be prescribed for author and publisher names? For example: [1]

References

  1. ^ 고경석 [Go Gyeong-seok] (3 December 2010). '헬로우 고스트' 명품조연 고창석-장영남, 코믹귀신 '변신' ["Hello Ghost" Supporting Actors Ko Chang-seok & Jang Young-nam, Comic Ghost "Transformation"]. 아시아경제 [Asian Economy]. Retrieved 22 September 2015. {{cite news}}: Invalid |script-title=: missing prefix (help)

As someone who has done a lot of work trying to rescue dead references, I've found it very frustrating if all I have available is the URL and an author name that was romanized in a non-standardized manner. Thanks, and I'm looking forward to your input, Ry's the Guy (talk|contribs) 18:05, 22 September 2015 (UTC)

Non-standard romanisations could be addressed by including the author's ORCID iD, or other authority control (or even a Wikidata ID), where they have one. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:11, 23 September 2015 (UTC)r
Thanks for your response. Most of the references I come across are Korean online newspapers and the authors are generally not notable enough to have any data on Wikidata and there is no ID identifying them. In the past I have used the romanization with the corresponding Hangul in parentheses for author names, and have had others remove the Hangul because they thought that I hadn't formatted the reference correctly. As the citation templates' documentation are written now, there's nothing specifying whether the original script name or romanization should be included. Ry's the Guy (talk|contribs) 06:54, 24 September 2015 (UTC)

Update to the live CS1 module weekend of 26–27 September 2015

On the weekend of 26–27 September I propose to update the live CS1 module files from the sandbox counterparts:

Changes to Module:Citation/CS1 are:

  1. bug fix in |edition test; discussion
  2. bug fix in parse_vauthors_veditors(); discussion
  3. add test for 'and others' text to name_has_etal (); discussion
  4. enhanced |url= scheme test; discussion
  5. fix cite episode missing |series= error message; discussion
  6. bug fix in select_author_editor_source () that skipped extract_name(); discussion
  7. remove support for deprecated parameters, including |month=; discussion
  8. expand defined-value error detection; discussion
  9. add Macedonian (mk) to languages supported by |script-title=;
  10. suppress original url when |dead-url=usurped; discussion
  11. add support for |script-chapter=; discussion
  12. hyphenate parameter names in error messages; discussion
  13. move url prefixes for identifiers |asin= and |ol= to /Configuration;
  14. add url in |title=, |chapter=, |work= parameters; discussion
  15. combine |trans-title= & |trans-chapter= error messages; discussion
  16. remove stray colon from ismn rendering;
  17. add translator support; discussion
  18. tweak COinS to prevent duplication of first author; discussion
  19. enhance |vauthors= error checking; discussion
  20. replace wrapping <span>...</span> with <cite>...</cite>; discussion
  21. COinS output by citationClass rather than by parameter; discussion
  22. tweak missing chapter error messages; discussion

Changes to Module:Citation/CS1/Configuration are:

  1. deactivated 24 deprecated parameters; discussion
  2. create table of keywords used by is_valid_parameter_value(); discussion
  3. hyphenate parameter names in error messages; discussion
  4. add translator support; discussion
  5. move url prefixes for identifiers |asin= and |ol= from Module:Citation/CS1
  6. add url in |title=, |chapter=, |work= parameters; discussion
  7. change isbn error category name; discussion
  8. change embedded wikilink error message and category; discussion
  9. combine |trans-title= & |trans-chapter= error messages; discussion

Changes to Module:Citation/CS1/Whitelist are:

  1. deactivated 24 deprecated parameters; discussion
  2. deprecate |Ref=; non-standard capitalization; discussion
  3. add translator support; discussion

Changes to Module:Citation/CS1/Date validation are:

  1. hyphenate parameter names in error messages; discussion

—Trappist the monk (talk) 12:10, 19 September 2015 (UTC)

Looks good to me. Look at all of the good work we have accomplished in the last couple of months! – Jonesey95 (talk) 13:45, 19 September 2015 (UTC)
For the record, this update happened about 40 minutes before my time stamp. – Jonesey95 (talk) 16:54, 26 September 2015 (UTC)

techreport in a collection?

What is the proper markup to use for a tech report that's published as part of a collection of such papers? Specifically, what's the term to use to indicate the collection's title, as opposed to the article within it? Maury Markowitz (talk) 19:17, 24 September 2015 (UTC)

Would |series= work for your source? See the cite techreport documentation. – Jonesey95 (talk) 19:46, 24 September 2015 (UTC)
I believe a "series" is usually taken as, well, a series of separate publications over a period of time (i.e., "periodically"). For a collection of articles (or reports) published together "work" seems more appropriate. The documentation suggests that "works" are only newspapers, magazines, and journals – i.e., periodicals – but "work" as a collection seems well established. Perhaps at some point that should be documented. ~ J. Johnson (JJ) (talk) 20:04, 25 September 2015 (UTC)

So {{cite work? That seems appropriate. Maury Markowitz (talk) 13:33, 4 October 2015 (UTC)

There are articles showing up in the new Category:CS1 errors: external links because of the following citation format:

Citation comparison
Wikitext {{citation|contribution=[[s:Encyclopædia Britannica, Ninth Edition/Angora|Angora]]|date=1878|display-editors=0|editor-first=Thomas Spencer|editor-last=Baynes|location=New York|p=45|publisher=Charles Scribner's Sons|ref=CITEREFEB1878|title=''[[s:Encyclopædia Britannica, Ninth Edition|''Encyclopædia Britannica'', 9th ed.]], [[s:Encyclopædia Britannica, Ninth Edition/Volume II|Vol. II]]''}}
Live "Angora" , Encyclopædia Britannica, 9th ed., Vol. II, New York: Charles Scribner's Sons, 1878, p. 45
Sandbox "Angora" , Encyclopædia Britannica, 9th ed., Vol. II, New York: Charles Scribner's Sons, 1878, p. 45

I have seen a few in this format in a sample of articles from the category. We should probably have a recommended way of fixing these. Any proposals? – Jonesey95 (talk) 16:35, 26 September 2015 (UTC)

Follow-up: {{EB1911}} is also generating this error message. It is transcluded in 12,387 articles. It uses {{Cite EB1911}}, which is transcluded in 16,067 articles. It would be good for us to find a fix for this template before this red error message is displayed on that many pages. – Jonesey95 (talk) 16:49, 26 September 2015 (UTC)

The test was fooled by the [[s: the last three characters of which look like a legitimate uri scheme. I've added a check for internal wikilinks to a namespace. Here we see that the rest of the code still catches a legitimate uri scheme:

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

Live module updated.

—Trappist the monk (talk) 17:19, 26 September 2015 (UTC)

That works for me. Thanks. This pattern may need some more tweaking. This citation is causing an error message:
Cite journal comparison
Wikitext {{cite journal|accessdate=2013-07-01|archivedate=2013-07-05|archiveurl=http://www.webcitation.org/6HsSVueeU|date=September 2012|deadurl=no|first=Marjeta|issn=1318-797X|issue=7|journal=Ljubljana: glasilo Mestne občine Ljubljana [Ljubljana: The Bulletin of the City Municipality of Ljubljana]|language=sl|last=Šašel Kos|pages=28–29|title=2000 let Emone? Kaj bomo praznovali?|trans_title=2000 Years of Emona? What Will We Celebrate?|url=http://www.ljubljana.si/file/1174311/gl_2012_07_internet.pdf|volume=XVII}}
Live Šašel Kos, Marjeta (September 2012). "2000 let Emone? Kaj bomo praznovali?". Ljubljana: glasilo Mestne občine Ljubljana [Ljubljana: The Bulletin of the City Municipality of Ljubljana] (in Slovenian). XVII (7): 28–29. ISSN 1318-797X. Archived from the original (PDF) on 2013-07-05. Retrieved 2013-07-01. {{cite journal}}: Unknown parameter |deadurl= ignored (|url-status= suggested) (help); Unknown parameter |trans_title= ignored (|trans-title= suggested) (help)
Sandbox Šašel Kos, Marjeta (September 2012). "2000 let Emone? Kaj bomo praznovali?". Ljubljana: glasilo Mestne občine Ljubljana [Ljubljana: The Bulletin of the City Municipality of Ljubljana] (in Slovenian). XVII (7): 28–29. ISSN 1318-797X. Archived from the original (PDF) on 2013-07-05. Retrieved 2013-07-01. {{cite journal}}: Unknown parameter |deadurl= ignored (|url-status= suggested) (help); Unknown parameter |trans_title= ignored (|trans-title= suggested) (help)
We'll get this thing debugged. We may need to settle for finding specific patterns, like "http://". – Jonesey95 (talk) 17:52, 26 September 2015 (UTC)
The fix for this is pretty easy. In correctly formed external wikilinks, the first character after the required colon should not be a space. The fix then is changing:
value:match ("%[%a[%a%d%+%.%-]*:.*%]")
to
value:match ("%[%a[%a%d%+%.%-]*:%S.*%]")
But, should we? Should |journal= be holding both original and translated journal titles? (In this discussion, that is a rhetorical question that should be taken up and answered.) The url test, as it is, may find other templates that look like this one but I suspect that there won't be many of them. If that is a reasonable assumption, I'll tweak the sandbox but leave the live version alone.
—Trappist the monk (talk) 18:33, 26 September 2015 (UTC)
As far as I know, we don't have a |trans-work= or |trans-journal= parameter, so what's an editor to do if that editor wants to be helpful by providing a translation of a journal name?
As the category populates, we'll get a better sense of how much of this stuff is out there. – Jonesey95 (talk) 19:01, 26 September 2015 (UTC)

I have refined the test pursuant to this conversation. The new test is:

value:match ("%f[%[]%[%a[%a%d%+%.%-]*:%S.*%]")

The frontier pattern adds the requirement that any character immediately preceding an external wikilink's opening square bracket must be something other than another square bracket:

pass: doesn't find interwiki link w:Example.com.
w:Example.com pass: doesn't find interwiki link at start of title.
fail: finds external link [1]. {{cite book}}: External link in |title= (help)
[2] fail: finds external link at start of title. {{cite book}}: External link in |title= (help)
fail: w:Example.com finds external link [3] even with interwiki link. {{cite book}}: External link in |title= (help)

—Trappist the monk (talk) 12:12, 27 September 2015 (UTC)

Bad rendering and erroneous "extra text" message for author=Beaudet AL

I found this citation in 5-HT2C receptor:

Cite journal comparison
Wikitext {{cite journal|author=Sahoo T, del Gaudio D, German JR, Shinawi M, Peters SU, Person RE, Garnica A, Cheung SW, Beaudet AL|doi=10.1038/ng.158|issue=6|journal=Nat Genet|pages=719–21|pmc=2705197|pmid=18500341|title=Prader-Willi phenotype caused by paternal deficiency for the HBII-85 C/D box small nucleolar RNA cluster.|volume=40|year=2008}}
Live Sahoo T, del Gaudio D, German JR, Shinawi M, Peters SU, Person RE, Garnica A, Cheung SW, Beaudet AL (2008). "Prader-Willi phenotype caused by paternal deficiency for the HBII-85 C/D box small nucleolar RNA cluster". Nat Genet. 40 (6): 719–21. doi:10.1038/ng.158. PMC 2705197. PMID 18500341.{{cite journal}}: CS1 maint: multiple names: authors list (link)
Sandbox Sahoo T, del Gaudio D, German JR, Shinawi M, Peters SU, Person RE, Garnica A, Cheung SW, Beaudet AL (2008). "Prader-Willi phenotype caused by paternal deficiency for the HBII-85 C/D box small nucleolar RNA cluster". Nat Genet. 40 (6): 719–21. doi:10.1038/ng.158. PMC 2705197. PMID 18500341.{{cite journal}}: CS1 maint: multiple names: authors list (link)

The |author=...Beaudet AL causes an "extra text" message to appear, and the author's name is not rendered correctly, presumably because the author's name ends in "et AL". I suppose you could say "don't list the authors that way", but a single author listed as |author=Beaudet AL is acceptable, and it generates the same error:

Cite journal comparison
Wikitext {{cite journal|author=Beaudet AL|doi=10.1038/ng.158|issue=6|journal=Nat Genet|pages=719–21|pmc=2705197|pmid=18500341|title=Prader-Willi phenotype caused by paternal deficiency for the HBII-85 C/D box small nucleolar RNA cluster.|volume=40|year=2008}}
Live Beaudet AL (2008). "Prader-Willi phenotype caused by paternal deficiency for the HBII-85 C/D box small nucleolar RNA cluster". Nat Genet. 40 (6): 719–21. doi:10.1038/ng.158. PMC 2705197. PMID 18500341.
Sandbox Beaudet AL (2008). "Prader-Willi phenotype caused by paternal deficiency for the HBII-85 C/D box small nucleolar RNA cluster". Nat Genet. 40 (6): 719–21. doi:10.1038/ng.158. PMC 2705197. PMID 18500341.

Just a minor bug to squish. – Jonesey95 (talk) 20:00, 26 September 2015 (UTC)

squished.
—Trappist the monk (talk) 21:33, 26 September 2015 (UTC)

Cite xxx defaults to |nopp=y

Please revert to prior. 65.88.88.69 (talk) 20:01, 26 September 2015 (UTC)

Module_talk:Citation/CS1#Recent_change.
—Trappist the monk (talk) 21:34, 26 September 2015 (UTC)

I'm seeing a template with 100s of uses throwing this error message everywhere (which it didn't previously). The help link says to not put a URL in the work but put it in the url field. But what if the specific citation AND the work as a whole each have a URL, having just one url field isn't sufficient, so you have to do |work=[someurl workname] as your only option. We often see the same problem with online accessible books/journals where you would like to have a URL for both the metadata (usually a library catalogue entry) as well as for the fulltext. One url field isn't sufficient, you really need at least 2 URL fields, one that takes you to the actual data and one that takes you to the work or meta-data that provides the contextual information surrounding the data (which might include how to interpret the data, the licensing etc). Until now you could do the work-around of having an external link in the work field or other field as necessary, but now this is prevented, how do we provide these 2 urls to the reader? I hope this can be fixed quickly. Kerry (talk) 06:51, 27 September 2015 (UTC)

@Kerry Raymond: could you provide a specific example of a citation that causes you this problem? Note that two URLs are available via |contribution-url= and |url=. Peter coxhead (talk) 08:18, 27 September 2015 (UTC)
Template:Cite QPN is one. The URL field (which is sort-of broken at the moment due to a recent change in the govt website but I am working to fix that) is different to the Work URL that explains what this data set is. Kerry (talk) 08:29, 27 September 2015 (UTC)

This is a time when the general purpose nature of {{citation}} is a benefit:

{{citation |mode=cs1 |contribution=Kenmore (41505) |contribution-url=https://www.dnrm.qld.gov.au/mapping-data/place-names/search/queensland-place-names-search?id=41505 |url=http://www.qld.gov.au/environment/land/place-names/ |title=Queensland Place Names |publisher=Queensland Government |access-date= |ref=CITEREFQPN41505 }}
"Kenmore (entry 41505)". Queensland Place Names. Queensland Government. Retrieved 13 September 2015.

—Trappist the monk (talk) 09:06, 27 September 2015 (UTC)

Another advantage of this approach (i.e. using the {{citation}} template as the primary one) is that by having |mode= available in the secondary template, it can be deployed in articles that use CS2. Many secondary citation templates don't allow a choice between CS1 and CS2, which prevents their use in many articles. Peter coxhead (talk) 09:40, 27 September 2015 (UTC)
Is contribution-url documented? I cannot see it. Kerry (talk) 00:33, 29 September 2015 (UTC)
Visual editor does not know about it either. Kerry (talk) 00:40, 29 September 2015 (UTC)
|contribution-url= is listed at Template:Citation#Template Data. It is a valid parameter that is an alias of |chapter-url= (also listed at Template Data). We need someone who knows and uses VE to update the VE-only documentation. As far as I know, there was never any documentation for |contribution= and |contribution-url=. There is no indication that either of these will be going away.
—Trappist the monk (talk) 00:56, 29 September 2015 (UTC)

"The features of this template will be added to the citation templates in the next update."

Greetings. Template:Lang (and other templates) say that their features (which presumably includes the <span lang= microformat) will be included "in the next update". Has this been done for that specific template? I wanted to update the documentation there, but I don't know much about these übercomplicated templates.Jo-Jo Eumerus (talk, contributions) 21:15, 27 September 2015 (UTC)

Retired Editor Gadget850, once a significant contributor to this project, added that comment. I'm not sure what his intentions were nor how he imagined that the facilities of {{lang}} et al. would be included in cs1|2. At a guess, I think that support for certain languages that use non-Latin alphabets was something that he was considering. Some of the {{lang}} support is present in cs1|2 when editors use the |script-title= and |script-chapter= parameters. |language= now accepts ISO 639-1 codes. Editor Gadget850 participated regularly at this talk page and all of the cs1 template talk pages before they were merged into this talk page, and also to the talk pages for Module:Citation/CS1 and {{citation}}. Perhaps your answer lies there. If you discover what it was that he meant by that rather cryptic note, come back and tell us what you've discovered.
—Trappist the monk (talk) 21:41, 27 September 2015 (UTC)
Doesn't look like it ever happened; there is a brief discussion here but if it was implemented I can't see it. My understanding is that the language class could interfere with the COinS metadata; is there a solution to that?Jo-Jo Eumerus (talk, contributions) 08:16, 28 September 2015 (UTC)
Only the |script-title=, |script-chapter=, |language= I mentioned above has been implemented. There isn't a mechanism to automagically know that the content of |title= is indeed Spanish when |language=es. I suppose we could use something similar to the language specifier that is used in |script-title= so that concerned editors could write |title=es:... or maybe create |lang-title= that would use the content of |language= to wrap the title in <span lang=...>...</span>.
—Trappist the monk (talk) 10:36, 28 September 2015 (UTC)

Cite archive

Editors may be interested in this proposal for a "cite [museum] archive" template. --Izno (talk) 18:50, 28 September 2015 (UTC)

Protected edit request on 1 October 2015

197.156.86.194 (talk) 12:54, 1 October 2015 (UTC)

@197.156.86.194: we need to know what change you desire to be made. Please provide us with some idea, preferably in a before and after format, so we know what it is you want us to do. Imzadi 1979 → 13:12, 1 October 2015 (UTC)

Referencing foreign language programs with English captions to be CS1 compliant

In referencing television episodes, I sometimes have to deal with cases where the episode is dubbed in a non-English language but presented with captions in English, but putting "language=Japanese with English subtitles" raises a problem with CS1. What would be the CS1-confirming way to describe that? "language=Japanese, English"? This would be for cases where the caption presented is important to the reference. Similarly what if I want to reference a program in which the English caption presented is different from the English that is said? This assumes the captions are pre-loaded for the broadcast and not transcribed on the fly. AngusWOOF (bark • sniff) 18:15, 4 October 2015 (UTC)

|language= is used for categorization so extraneous text confuses Module:Citation/CS1. |language= merely indicates which languages a source uses, not how they are used. As to which language should come first in your example, |language= doesn't care so it is up to you to decide whether you emphasize one language over the other by the order in which they appear in the rendered citation. You might consider |type= to point to the subtitles:
{{cite episode |title=Title |series=Series |language=en, ja |type=subtitles}}
"Title". Series (subtitles) (in English and Japanese).
For the case where closed captioning is different from the spoken word: find a better source? Inaccurate transcriptions of the spoken word are inaccurate; they are the result of an editorial process gone awry either by omission or commission. Where this occurs, perhaps the best course is to use |quote= to include both an accurate transcription of the audio and an accurate transcription of the closed caption. Or find a better source.
—Trappist the monk (talk) 11:48, 6 October 2015 (UTC)

|subscription= and |registration= font size tweak

The rendered versions of |subscription= and |registration= use css copied directly from {{link note}}:

<span style="font-size:0.95em; font-size: 90%; color: #555">

I have changed that to:

<span style="font-size: 90%; color: #555">

compare:

Title. {{cite book}}: Unknown parameter |subscription= ignored (|url-access= suggested) (help)
Title. {{cite book}}: Unknown parameter |subscription= ignored (|url-access= suggested) (help)
Title. {{cite book}}: Unknown parameter |registration= ignored (|url-access= suggested) (help)
Title. {{cite book}}: Unknown parameter |registration= ignored (|url-access= suggested) (help)

—Trappist the monk (talk) 00:09, 8 October 2015 (UTC)

Strange rendering of invalid access-date= parameter

I found a citation similar to this one out in the wild. I have simplified it a bit:

Cite web comparison
Wikitext {{cite web|accessdate=7 October2015|language=Danish|title=title|url=http://www.example.com|website=indenforvoldene.dk}}
Live "title". indenforvoldene.dk (in Danish). Retrieved 7 October2015. {{cite web}}: Check date values in: |accessdate= (help)
Sandbox "title". indenforvoldene.dk (in Danish). Retrieved 7 October2015. {{cite web}}: Check date values in: |accessdate= (help)

I see "Retrieved $1 $2" in the rendered citation where the access-date parameter is supposed to be. I wonder if that is a bug that will manifest itself even with valid dates. When the date is corrected, it looks fine:

Cite web comparison
Wikitext {{cite web|accessdate=7 October 2015|language=Danish|title=title|url=http://www.example.com|website=indenforvoldene.dk}}
Live "title". indenforvoldene.dk (in Danish). Retrieved 7 October 2015.
Sandbox "title". indenforvoldene.dk (in Danish). Retrieved 7 October 2015.

Any thoughts? – Jonesey95 (talk) 05:22, 8 October 2015 (UTC)

nowrap_date() had mismatched %s*%d%d%d%d and %s+%d%d%d%d patterns; one doesn't care if there are spaces preceding the year value and the other does. Now they both care. The problem also manifests when |access-date= is mdy:
Cite web comparison
Wikitext {{cite web|accessdate=October 7,2015|language=Danish|title=title|url=http://www.example.com|website=indenforvoldene.dk}}
Live "title". indenforvoldene.dk (in Danish). Retrieved October 7,2015. {{cite web}}: Check date values in: |accessdate= (help)
Sandbox "title". indenforvoldene.dk (in Danish). Retrieved October 7,2015. {{cite web}}: Check date values in: |accessdate= (help)
—Trappist the monk (talk) 10:09, 8 October 2015 (UTC)

Where is the URL error here?

I must be missing something. Where is the URL error here?

U.S. Census Bureau. Census 2000, Summary File 1. "GCT-PH1. Population, Housing Units, Area, and Density: 2000 - County -- Subdivision and Place". American FactFinder. <http://factfinder2.census.gov>. Retrieved 2008-01-31. {{cite web}}: External link in |work= (help)

When I View Source on this rendered page, I do not see a problem with the URL. I need another pair of eyes. – Jonesey95 (talk) 14:37, 29 September 2015 (UTC)

Template:American Factfinder2, used in the creation of the URL, includes a comment at the beginning. Maybe that's causing the issue? --Izno (talk) 14:58, 29 September 2015 (UTC)
{{Cite American Factfinder2}} gets it's value for |url= from {{American Factfinder2}} to which is passes three values, in this case 2, 46013, and county. With those values, {{American Factfinder2}} returns this as a value for |url=
https://factfinder.census.gov/bkmk/table/1.0/en/DEC/00_SF1/GCTPH1.CY10/0500000US46013
Module:Citation/CS1 rejects it because the 'url' contains spaces which urls must not do.
—Trappist the monk (talk) 15:02, 29 September 2015 (UTC)
@Jonesey95: I patched up those two templates; the URL error is no longer present. There is more that could be done (and a 2010/2000 census option could be added) but they don't seem to be used much. Outriggr (talk) 06:37, 13 October 2015 (UTC)
Thanks! I stared at them for a while, but I wasn't able to parse the syntax. I moved on to a bunch of templates with external link errors, which reduced the external link category count by a few thousand. – Jonesey95 (talk) 06:40, 13 October 2015 (UTC)

Feature request: |note= parameter

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

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

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

And it would actually serve the purpose Aa77zz has in mind, anyway. So, I renew the request. All fields I'm aware of, including physical sciences, social sciences, humanities, law, etc., that regularly cite sources do in fact have definitions of "primary source" and so on (even if they sometimes differ in their particulars), so the objection to my example isn't even valid. And it was just an example. There are any number of reasons to use such a parameter, e.g.:
  • |note=Titled "Blood of the Isles" in the UK printing.
  • |note=Paywall can be bypassed by request at URL here.
  • |note=Page 17 is missing from this Project Gutenberg scan, but is not part of the cited material.
  • |note=There is a newer edition, but the cited section has not changed, according to URL to changes list.
  • |note=This is a master's thesis, but was reviewed by Notable Researcher Here, and has been cited in 12 journal papers as of July 2015.
etc. There's no reason to put these in messy HTML comments that some editors are apt to delete on sight because they don't like HTML comments. And, really, no one's head will asplode if someone happens to include a more WP-jargon-specific note. They'll just shrug and move on. No one will see them but wikitext-editing users anyway.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  23:15, 30 July 2015 (UTC)
Are you hoping that the note will appear when a user mouses over the tag as with {{clarify-inline}} ? AngusWOOF (bark • sniff) 08:12, 22 August 2015 (UTC)
That might be useful, sure, but was not central to the nature of the request, which is about keeping these notes with (i.e., inside) the citations, so that nothing is put between them, etc.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  12:50, 12 September 2015 (UTC)
I support the note= parameter idea. In fact, I'm looking for something similar, but for visible commentary. Some while ago I proposed a comment= parameter to have a well defined location to append some commentary on a citation if required, but it was quickly archived without any discussion emerging at all.
For example, I have occasionally run into references, which fulfill our criteria as reliable sources but are nevertheless known to contain annoying typographical (f.e. misspelled names or wrong dates) or even more serious factual errors elsewhere (and in some cases, such errors might contradict other factually correct statements in the article). I would not normally use such sub-standard references in order to not give it the "fame" of being used as a "reliable" reference in Wikipedia and to simply avoid that someone picks it up and the faulty information spreads further. However, there are cases where sources supporting a factual correct statement in an article are extremely difficult to find, and such a sub-standard reference might happen to be the only one around. If it is known to at least correctly represent the statement needing support, it can be used as a reference, but it might be still a good idea to inform potential readers about the otherwise sub-standard nature of the reference. IMO, a comment= or note= parameter would be the ideal place to put such commentary.
--Matthiaspaul (talk) 15:30, 13 October 2015 (UTC)
I was recently involved in a discussion (Talk:C (programming language)#IBM 310), where that would have been appropriate. The reference in question was an old Bell System Technical Journal article (circa 1978), which was now available online, in the form of a OCR'd scan. The PDF mentions IBM 360 and 310 systems. The latter is clearly an OCR glitch, since there was no such system, and "370" instead fits both the context and time (and is supported by other sources as well). We left a comment in the article to warn future editors, but a note in the cite itself would be better. Rwessel (talk) 16:05, 13 October 2015 (UTC)
Good example! --Matthiaspaul (talk) 18:25, 13 October 2015 (UTC)
I just realized that the postscript= parameter can be technically "misused" for the proposed purpose. In fact, some editors actually use it for this purpose ([4]), so we could just change the documentation to reflect this. However, it might have unwanted sideeffects, so a dedicated parameter for comments still seems like a cleaner solution. --Matthiaspaul (talk) 18:25, 13 October 2015 (UTC)
The usual easy solution for this is to put the text outside of the citation template, but prior to the closing ref tag. This keeps any free-form notes with the citation information and does not run afoul of the CS1 error-checking code. I wouldn't recommend hiding commentary in the wikitext and hoping that editors, let alone readers, find it by viewing the source of the page. All of the example notes given above are information that I as a reader/researcher would want to see if I were digging into the references at the bottom of an article to find original source material. They should not be hidden. – Jonesey95 (talk) 21:52, 13 October 2015 (UTC)

ed. display quirk

Markup Renders as 
{{cite book|editor=Editor|date=|title=Title}}

Editor (ed.). Title. {{cite book}}: |editor= has generic name (help) 

{{cite book|editor=Editor|date=2015|title=Title}}

Editor, ed. (2015). Title. {{cite book}}: |editor= has generic name (help)

208.87.234.201 (talk) 00:57, 15 October 2015 (UTC)

I don't see that difference documented in the {{cite book}} documentation.
Markup Renders as 
{{cite book|chapter=Chapter|editor=Editor|date=|title=Title}}

Editor (ed.). "Chapter". Title. {{cite book}}: |editor= has generic name (help) 

{{cite book|chapter=Chapter|editor=Editor|date=2015|title=Title}}

Editor, ed. (2015). "Chapter". Title. {{cite book}}: |editor= has generic name (help) 

{{cite book|author=Author|chapter=Chapter |editor=Editor|date=2015|title=Title}}

Author (2015). "Chapter". In Editor (ed.). Title. {{cite book}}: |author= has generic name (help)

Here are three more examples to show that editor rendering is inconsistent (and has been for many years, according to a posting at Template:Cite book/testcases). – Jonesey95 (talk) 03:04, 15 October 2015 (UTC)
@Jonesey95: Hope you don't mind that I fixed one of your examples above. GoingBatty (talk) 04:42, 15 October 2015 (UTC)
The culprit in the inconsistent display of the suffix is |date=. This seems to be CS1-wide. It's as if those parentheses have to go somewhere.72.89.174.207 (talk) 12:27, 15 October 2015 (UTC)

Which citation format to use?

This pdf from the LOC has some biographical material I would like to use in an article. Should I use {{cite web}} or {{cite document}}/{{cite journal}}? Thanks! - Location (talk) 20:54, 15 October 2015 (UTC)

{{cite web}} should work fine. – Jonesey95 (talk) 22:31, 15 October 2015 (UTC)
Thanks! By the way, the pdf notes "Prepared by Bradley E. Gernand" and "Revised and expanded by Karen Linn Femia". Do you think they should be noted as author1 and author2? - Location (talk) 23:55, 15 October 2015 (UTC)
The document does not make it clear if those people were actual authors or simply compilers of the information in the document. To avoid making an untrue statement about the authorship of this document, I would put the names in the |others= parameter, with the above quoted words for explanation. – Jonesey95 (talk) 03:27, 16 October 2015 (UTC)
That's a good idea. Thanks! - Location (talk) 19:48, 16 October 2015 (UTC)

language=English no longer detected?

I think that |language=English is supposed to display an error message and put articles in a maintenance category, but that code may not be working. Look at reference 14 in List of French football transfers summer 2015, for example. – Jonesey95 (talk) 03:54, 16 October 2015 (UTC)

No more errors or categorization for |language=en. See this discussion and this discussion.
—Trappist the monk (talk) 11:06, 16 October 2015 (UTC)

Cite video game

I'm wondering if it's possible to get default support for Template:Cite video game in Module:Citation/CS1 or perhaps some help with integrating it better with CS1. Right now, it bizarrely relies on Template:Cite journal (for the metadata???), which is inhibiting the correct citation of a video game with italics. Current example of an outputted title would be: "Example", as opposed to the correct Example. Previous discussion at Template talk:Cite video game#Quotes versus italics petered out in 2013 regarding the change (incorrectly) from quotation marks to italics. --Izno (talk) 00:10, 24 September 2015 (UTC)

{{cite AV media}}? 

{{cite AV media
 |title=[[Halo 3]]
 |author=[[Bungie]] <!-- developer -->
 |publisher=[[Microsoft Game Studios]]
 |date=2007-09-25
 |series=[[Xbox 360]] v1.0 <!-- concatenation of |platform= and |version= -->
 |at=The Storm
 |language=
 |quote='''Arbiter''': "More Brutes?" / '''Master Chief''': "Worse."
}}

Bungie (2007-09-25). Halo 3. Xbox 360 v1.0. Microsoft Game Studios. Arbiter: "More Brutes?" / Master Chief: "Worse."

—Trappist the monk (talk) 00:53, 24 September 2015 (UTC)

|series= probably isn't much worse than |volume= + |issue=, I guess. |via= might be better but for the fact of the pre-output "via". --Izno (talk) 01:20, 24 September 2015 (UTC)
I modified the sandbox of {{Cite video game}} to use {{cite book}} instead of {{cite journal}}. It looks like this:
{{cite video game/sandbox |title=[[Halo 3]] |developer=[[Bungie]] |publisher=[[Microsoft Game Studios]] |date=2007-09-25 |platform=[[Xbox 360]] |version=1.0 |level=The Storm |language= |quote='''Arbiter''': 'More Brutes?' / '''Master Chief''': 'Worse.' }}
Yields:
Bungie (2007-09-25). Halo 3 (Xbox 360) (1.0 ed.). Microsoft Game Studios. Level/area: The Storm. Arbiter: 'More Brutes?' / Master Chief: 'Worse.'
Compare to the current template:
Bungie (2007-09-25). Halo 3 (Xbox 360) (1.0 ed.). Microsoft Game Studios. Level/area: The Storm. Arbiter: 'More Brutes?' / Master Chief: 'Worse.'
It looks like the sandbox results in the current rendering, except with italics for the title, per WP:VG/STYLE. – Jonesey95 (talk) 03:31, 24 September 2015 (UTC)
I updated the module. If we see a regression, someone can come bug me. --Izno (talk) 17:03, 24 September 2015 (UTC)
You should probably post a note at the very active Wikipedia talk:WikiProject Video games, citing WP:VG/STYLE as the reason for the change. Citation-related talk pages are often watched by few people compared to the number who watch project pages. – Jonesey95 (talk) 17:14, 24 September 2015 (UTC)
I'm part of WP:VG, but I probably should anyway. ;) --Izno (talk) 17:44, 24 September 2015 (UTC)

I'm not sure that {{cite book}} is the right template. One of the things that will change with the next update to the module is that the metadata will be in slightly closer alignment to the template that creates it; see choosing the correct metadata when |chapter=, |title=, and |work= are all set.

Also see Module_talk:Citation/CS1/COinS. The Used keys table there shows which metadata keywords are supported for the two object types available to us. Right now, everything is a book unless it is {{cite arxiv}}, {{cite journal}} or {{cite news}} in which case it is a journal. {{citation}}, {{cite conference}}, {{cite interview}}, and {{cite press release}} are treated as journal when the the module's metaparameter Periodical is set; otherwise these are treated as book.

The metadata keyword rft.genre has several set values that it can hold depending on the object (book or journal). After this next update to the module, I intend to refine how rft.genre is used for the individual templates.

Getting back to the topic, because {{cite video game}} uses {{cite book}}, the metadata will describe the video game as a book. Just as {{cite journal}} was the wrong template because of visual styling, so too is {{cite book}} the wrong template because of the metadata that will/are being produced. Because those things typically cited with {{cite AV media}} are not books or journals and because the metadata only give us book or journal, we should choose book for the metadata and then set rft.genre to unknown. Because |volume= and |issue= are not supported in the metadata for book, |series= is an appropriate choice to receive both |platform= and |version=.

I have hacked the {{cite video game}} sandbox to use {{cite AV media}}:

Bungie (2007-09-25). Halo 3 (Xbox 360) (1.0 ed.). Microsoft Game Studios. Level/area: The Storm. Arbiter: 'More Brutes?' / Master Chief: 'Worse.'

Visually similar except for the parentheses around |version=.

—Trappist the monk (talk) 23:41, 24 September 2015 (UTC)

Citing catalogs and similar materials

What would be the best template for a product brochure? It's not really a book, and it's not really a techreport. Maybe I'm splitting hairs, or maybe there's the perfect template for this? Maury Markowitz (talk) 11:51, 2 October 2015 (UTC)

Not a "tech report", probably a pamphlet. One of the reasons I generally prefer {{citation}} over the {{cite xxx}} family is not having to specify the nature of the source. And there is an option (off-hand I forget which) which makes 'citation' display in a manner consistent with 'cite xxx', so it is feasible to mix them. ~ J. Johnson (JJ) (talk) 22:25, 19 October 2015 (UTC)

Citoid and language codes for CS1 templates

Hello, currently there seems to be a minor problem, when Citoid tries to create Template:cite web with "en-IN" and similar language codes. I have posted a request for clarification at Visual Editor feedback. Additional input from CS1-knowledgeable editors would be appreciated. GermanJoe (talk) 14:32, 19 October 2015 (UTC)

cs1|2 does not support RFC 1766-style language codes (code-subcode where code is an ISO 639-1 language code and subcode is an ISO 3166 country code. Module:Citation/CS1 uses this list as a reference.
—Trappist the monk (talk) 14:55, 19 October 2015 (UTC)

One cite episode template with multiple errors, none detected

I found the following {{cite episode}} template in Las Balsas:

Cite episode comparison
Wikitext {{cite episode|airdate=2014-01-02|minutes=11|network=[[BBC]]|series=Witness|serieslink=http://www.bbc.co.uk/programmes/p004t1hd|station=[[BBC World Service]]|time=08:50 GMT|title=The Longest Ever Raft Journey|url=http://www.bbc.co.uk/programmes/p01nnrx4}}
Live "The Longest Ever Raft Journey". Witness. 2014-01-02. 11 minutes in. BBC. BBC World Service. {{cite episode}}: Check |serieslink= value (help); External link in |serieslink= (help); More than one of |minutes= and |time= specified (help); Unknown parameter |serieslink= ignored (|series-link= suggested) (help)
Sandbox "The Longest Ever Raft Journey". Witness. 2014-01-02. 11 minutes in. BBC. BBC World Service. {{cite episode}}: Check |serieslink= value (help); External link in |serieslink= (help); More than one of |minutes= and |time= specified (help); Unknown parameter |serieslink= ignored (|series-link= suggested) (help)
I've added redundant parameter error checking for |time= and |minutes=.
Also added a wikilink/url check similar to the |author-link= check to |series-link=. Should probably add checks for |title-link= and |episode-link=. That done, we should probably create a single error message/category pair for these kinds of errors to also include |author-link=, |editor-link=, and |translator-link=.
—Trappist the monk (talk) 21:40, 2 October 2015 (UTC)
I agree with expanding this check to all "-link" parameters. I think that a simple "Check |editor-link= value" or "Check |title-link= value" should work as an error message. The current category is called Category:CS1 errors: authorlink. We could call the replacement category Category:CS1 errors: link, which is a bit obtuse, or perhaps Category:CS1 errors: invalid link. Modifying the documentation should be straightforward. – Jonesey95 (talk) 23:49, 2 October 2015 (UTC)
It should not be marked as any kind of error to supply a valid redlink for one of these parameters. But as long as the error checker is only looking for things that are formatted as urls rather than wikilinks. it should be ok. —David Eppstein (talk) 23:53, 2 October 2015 (UTC)
As far as I know, no one has ever suggested testing wikilinks for color. The test is looking for wikilink markup in a |<param>-link= parameter because that extra markup breaks rendering of the link:
{{cite episode/new |series=Series |series-link=[[Las Balsas]]}}
Series. {{cite episode}}: Check |series-link= value (help)
—Trappist the monk (talk) 00:23, 3 October 2015 (UTC)
Ok, but that's a different error than the one Jonesey95 was talking about, which involved putting a URL in the link field. Those would look more like redlinks except for the URL syntax. —David Eppstein (talk) 00:30, 3 October 2015 (UTC)
I'm confused. In the example at top, the error message is present because the assigned value is a url:
|serieslink=http://www.bbc.co.uk/programmes/p004t1hd
My example above shows the error because of the wikilink mark up. Both of these are the same as the errors displayed when |author-link= contains a url or wikilink markup which is, I think, the error that Editor Jonesey95 was talking about, is it not? Is it even possible to get a red external link (without applying special styling)?
—Trappist the monk (talk) 00:48, 3 October 2015 (UTC)
David Eppstein: Nobody is suggesting here that we check for non-existent WP article names in |whatever-link=. We are simply talking about applying the existing |author-link= check (for // and [[*]] ) to other -link parameters. The checking code in question is: if is_set(person.link) and ((nil ~= person.link:find("//")) or (nil ~= person.link:find("[%[%]]")))
As you can see in my example above (copied from an actual article), the series link is rendered as http://www.bbc.co.uk/programmes/p004t1hd|Witness, which is clearly not the intent of the original editor. The new test will put these broken links in an error category so that we can fix them and help readers and editors find sources. – Jonesey95 (talk) 02:11, 3 October 2015 (UTC)
You know we have an article en://, right? (Well, it's a dab, but it could be an article.) Also en://Hus and a few dozen redirects [5]. How are we going to link to these after this test is made? —David Eppstein (talk) 04:09, 3 October 2015 (UTC)
Link to en:// from |editor-link=? Let's resolve that edge case when it occurs. – Jonesey95 (talk) 13:40, 3 October 2015 (UTC)
Percent encoding:
{{cite episode/new |series=// |series-link=:en:%2F%2F}}
//.
—Trappist the monk (talk) 19:41, 3 October 2015 (UTC)
That is a gross hack. Percent encoding has nothing to do with whether something is a valid URL (the same URL with slashes percent-encoded still works equally well) nor whether something is a valid wikilink. Presumably the intended meaning is "this text is unterpreted unusually so I'm going to encode it unusually" but the encoding and the semantics are otherwise unrelated. It amounts to leaving an undocumented back door in the pattern matching code (that it doesn't know how to match patterns in strings when the strings happen to be percent-encoded) with the intention of using that back door when we need to bypass the code, and hoping that some future software maintainer doesn't clean up the code to make it handle strings with different encodings more smoothly. —David Eppstein (talk) 19:57, 3 October 2015 (UTC)
Yep, this text is [i]nterpreted unusually so I'm going to encode it unusually. Not so much different from the requirement to use these replacements in urls:
sp " ' < > [ ] { | }
%20 %22 %27 %3c %3e %5b %5d %7b %7c %7d
I'm all ears. If you have a better solution, tell us.
—Trappist the monk (talk) 11:48, 4 October 2015 (UTC)

It occurs to me to wonder if we shouldn't refine the url test to look for a dot somewhere in the hostname. MediaWiki is confused by:

[[//hus]]
[[6]]

so editors must use interwiki notation:

[[en://hus]]
en://hus

To Module:Citation/CS1 en://hus looks like a valid url (though MediaWiki sees that it isn't):

{{cite book |title=Title |url=en://hus}}
[en://hus Title].

IPv4 in dot-decimal notation (192.168.0.0) and domain names (example.com) are hostnames with dots. IPv6 syntax is different and (at the moment) I can find no use of it as a link in en:wp. Looking for the dot that separates IPv4 elements or domain-name labels will identify and flag |url=en://hus as malformed. Looking for the dot will not identify |title-link=en://hus as an error. Looking for the dot is no help when |title-link=//hus; MediaWiki will still be confused.

—Trappist the monk (talk) 13:05, 6 October 2015 (UTC)

{{cite book/new |title=Title |url=en://hus}}
[en://hus Title].
and a variety of other conditions:
pass protocol relative with dot.
fail protocol relative without dot.
[/example.com fail path only with dot]. {{cite book}}: Check |url= value (help)
[example.com fail labels only with dot]. {{cite book}}: Check |url= value (help)
pass scheme; hostname with dot.
fail scheme; hostname without dot.
[8ttp://example.com fail bad scheme; hostname with dot]. {{cite book}}: Check |url= value (help)
If this change is to be kept, it will be necessary to change the error message.
—Trappist the monk (talk) 14:52, 6 October 2015 (UTC)
These look like reasonable tests. How about "check url= value" for an error message? That matches some of our other error messages. – Jonesey95 (talk) 21:25, 6 October 2015 (UTC)

I've created a new function that does this:

  1. checks |<param>-link= for illegal article title characters per WP:TSC
  2. looks for text that precedes a colon that could be a scheme
  3. looks for text that could be a protocol relative url
  4. inspects what should be the hostname for character or digit, dot, character or digit

See Editor Jonesy95's example. Here are others using |author-link= (same code as |series-link=):

Abraham Lincoln. Pass, proper usage. – expected use
Abraham Lincoln. Fail, wikilinked. {{cite book}}: Check |author-link= value (help)
Abraham Lincoln. Fail, attempt to ext-wikilink to author's website. {{cite book}}: Check |author-link= value (help); External link in |author-link= (help)
Abraham Lincoln. Fail, attempt to use plain url with scheme and author name. {{cite book}}: Check |author-link= value (help); External link in |author-link= (help)
Abraham Lincoln. Fail, attempt to use author name and plain url with scheme. {{cite book}}: Check |author-link= value (help); External link in |author-link= (help)
Abraham Lincoln. Fail, attempt to use plain url with scheme. {{cite book}}: Check |author-link= value (help); External link in |author-link= (help)
Abraham Lincoln. Fail, attempt to use protocol relative url. {{cite book}}: Check |author-link= value (help); External link in |author-link= (help)
Abraham Lincoln. Fail, link to //hus. {{cite book}}: Check |author-link= value (help); External link in |author-link= and |title= (help)
Abraham Lincoln. Pass, link to en://hus. {{cite book}}: Check |author-link= value (help); External link in |author-link= and |title= (help)

Still to do is |title-link= and |episode-link=. All of these should share the same error message and category so I'll think about that as well.

—Trappist the monk (talk) 23:42, 6 October 2015 (UTC)

|title-link= and |episode-link= tests added. All of the |<param>-link= parameters are now using a common error message and handler. If this change is retained we will need to move Category:CS1 errors: authorlink to Category:CS1 errors: parameter-link. Similarly, Check |author-link= value help text gets a new anchor, title, and expanded text.

|title-link=:

Pass, proper usage.
fail, wikilinked. {{cite book}}: Check |title-link= value (help)

|title-link= in {{cite encyclopedia}}:

"Pass, proper usage". Encyclopedia.
"fail, wikilinked". Encyclopedia. {{cite encyclopedia}}: Check |title-link= value (help)

|episode-link= in {{cite episode}}:

"Pass, proper usage". Series.
"fail, wikilinked". Series. {{cite episode}}: Check |episode-link= value (help)

|editor-link= and |translator-link=:

Sam Houston; Abraham Lincoln (eds.). Fail, wikilinked. {{cite book}}: Check |editor-link2= value (help)
Fail, wikilinked. Translated by Abraham Lincoln. {{cite book}}: Check |translator-link= value (help)

—Trappist the monk (talk) 15:29, 7 October 2015 (UTC)

Nice work. These all look good to me. Here's one with multiple link errors (editor-link and translator-link) and a missing editor, just to be cruel:
Abraham Lincoln (ed.). Fail, wikilinked. Translated by Mary Todd Lincoln. {{cite book}}: Check |editor-link2= value (help); Check |translator-link= value (help); Cite has empty unknown parameter: |1= (help); Missing |editor1= (help)
It shows all three errors, with the very minor problem that the editor error message says that there is an error in |editor-link1= instead of |editor-link2= because the first editor is missing. – Jonesey95 (talk) 19:23, 7 October 2015 (UTC)
fixed.
—Trappist the monk (talk) 19:59, 7 October 2015 (UTC)

Improved error reporting. I've changed the code so that error messages related to malformed url-holding parameter values report the name of the parameter:

broken |url= and |archive-url=

broken |chapter-url= and |archive-url=

broken |url=, |chapter-url= and |archive-url=

broken aliases of |chapter-url=

broken |transcript-url= and |transcripturl=

broken |conference-url= and aliases

broken |lay-url= and aliases

broken |map-url= and |mapurl=

—Trappist the monk (talk) 17:45, 9 October 2015 (UTC)

This is a legitimate url:

http://alcme.oclc.org/openurl/servlet/OAIHandler?verb=ListRecords&metadataPrefix=oai_dc&set=Core:Metadata+Formats

but it was failing the new url check because the patterns used to split the url into scheme and hostname were too greedy. They took everything preceding the colon in the last query key/value pair (http://...&set=Core:) as the scheme and the rest (Metadata+Formats) as the host name. The scheme test failed because the 'scheme' contained illegal characters and the hostname test failed because the 'hostname' did not contain a dot. This has been remedied:

"Registry for the OpenURL Framework - ANSI/NISO Z39.88-2004". OCLC. Retrieved 2015-09-27.

—Trappist the monk (talk) 13:30, 21 October 2015 (UTC)

First-name only causes error

{{Cite web}} is throwing an error on Myles Jackman for a citation of a page where the author is known only by a first name. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:04, 20 October 2015 (UTC)

This is expected. Use |authorn= for this case. --Izno (talk) 18:14, 20 October 2015 (UTC)
Thank you, but why is it expected? It seems logical to allow this pattern. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:13, 21 October 2015 (UTC)
The module detects, and considers it an error, when a first name is provided without a corresponding last name. This erroneous condition often happens when there is a list of authors and a parameter like |first4= is missing a corresponding |last4=, typically because an editor made a typo or an omission. In order to describe sources accurately so that our readers can locate them, we check for this condition.
For legitimate cases of authors with only one name, like Bono or Sting or United Nations, the author's name should be placed in |last= (or |lastn=), or its alias, |author= (or |authorn=).
I have clarified the guidance in the CS1 templates' documentation for the |author= parameter. Does that help? – Jonesey95 (talk) 21:58, 21 October 2015 (UTC)

Proposal for trans-quote= parameter

Our MOS recommends to provide a translation when quoting citations in foreign languages. We have |trans-title= and |trans-chapter= parameters to allow translations for |title= and |chapter=, but a |trans-quote= parameter to provide a translation of |quote= is still missing, therefore we should add it in order to allow a translation to be presented in a more organized way than what's possible at present. --Matthiaspaul (talk) 16:03, 13 October 2015 (UTC)

|quote= is a free-form parameter. We have |trans-title= and |trans-chapter= so that we have |title= and |chapter= in their original language for the metadata. Since the value assigned to |quote= is not made part of the metadata it can hold both the original and a translation.
—Trappist the monk (talk) 17:26, 13 October 2015 (UTC)
Yes, this is what I have seen happening in practise in most such citations, with [square brackets] being used for the translation most often according to my observation.
I thought it would be good to have a more "formally" defined place for it to keep it separated from the quotation itself. For example, the |quote= and |trans-quote= parameters could be framed with the equivalent HTML of the lang template, taking the argument from the |language= parameter for the |quote= parameter. This would help screen readers to change the pronunciation or allow browsers to choose more appropriate fonts if the quotation would contain unsupported glyphs. It would also help improve consistency in the visual appearance of citations and allow the rendering of citations be changed in the future without having to actually change the wikitext again. Who knows, it might even help automatic translation services elsewhere (even if not part of our metadata at present, web crawlers could extract the info from the wikitext directly).
--Matthiaspaul (talk) 21:45, 13 October 2015 (UTC)
All this presumes on |quote= being a good thing in the first place. As stated above, I think quotations ought not to be in the citation template itself (because they are not really part of the citation), but can and should follow the citation. This avoids the whole issue of processing quotations as citation metadata. ~ J. Johnson (JJ) (talk) 00:25, 14 October 2015 (UTC)
Obviously, I do consider the |quote= parameter a good thing. While I see your point and have used this style myself in the past, I think it is easier for editors to use a simple parameter for quotations than remembering where and how to exactly include the quotation after the cite template. Also, this keeps the quotation connected to the citation.
The |quote= parameter is a reality, therefore, if there is potential for further improvement, why not go for it? Nobody is forced to use |quote= or the proposed |trans-quote= parameter, although I assume that quite a few would do, if it becomes available.
The general idea is to keep the content separated from its presentation (a fundamental principle in authoring and organizing information). The presentation might need to change later on (because of changes in fashion, individual preferences, different output devices, because metadata like language info should be provided, or because some of the information should be processed or filtered for some reason). If so, it would be possible to achieve this simply by modifying the central cite template instead of having to edit millions of individual citations distributed over the articles. And finally, in the unlikely event that the community would come to the conclusion that the whole structure would have to be reorganized, having the contents separated into different parameters aids machine readability and allows automatic processing into whatever new organization would be required. So, these proposals also ensure forward compatibility.
--Matthiaspaul (talk) 04:37, 14 October 2015 (UTC)
There is value to |quote=, actually: it adds the <q> HTML tag to the material quoted. This is desirable. --Izno (talk) 12:36, 14 October 2015 (UTC)
Nonetheless this could be in a separate template that does such tagging. All the best: Rich Farmbrough, 21:23, 14 October 2015 (UTC).
I support this. It's mainly an issue of formatting, but I don't have a good suggestion for such formatting. The problem with the brackets is that they can be used to replace text within a quote, eg. "John is a man. He is 37 years old." becoming "[John] is 37 years old." (of course, this is a very simple example and not an example of a case where a quote should be used in a citation). While it should be obvious when a bracket contains a different language, the formatting would not look good if a bracket is needed to replace text in the quote, eg. "[John] a trente sept ans. [[John] is 47 years old.]". Plus, which order? English in brackets? |trans-quote= would be useful to, at least, format translated quotes consistently across articles. I don't have a good suggestion for formatting, but do think that |trans-quote= should be added as a parameter to promote consistent formatting. AHeneen (talk) 01:41, 15 October 2015 (UTC)
As Rich says, the benefit Izno cites could be met with a separate template. Such a template could have other benefits. E.g., Matthiaspaul would like a quotation to be strongly connected with the citation. However, there is a confusion here between the proper use of a full citation, which contains the complete bibliographic detail of a source as a whole, and short citations ("short cites"), which point to specific locations within a source. This is not so noticeable when a source is cited for only a single passage, but becomes readily apparent when a source is used more than once. So if an editor wishes to supply two (or more) quotations, how does he pack them into 'quote='? Much more suitable would be having a 'quote=' parameter in, say, {{Harv}}. I can envision a variant that would link back to a full citation in the same manner as Harv, but displays only an icon, which could be clicked to show the quotation and any comments. Or even a translation. Which is to say I could be entirely in favor of what Matthiaspaul has requested here, excepting only that it shouldn't be done in CS1/2. ~ J. Johnson (JJ) (talk) 20:03, 16 October 2015 (UTC)
I just saw that another editor has made basically the same proposal recently: Template talk:Citation#Trans quote
--Matthiaspaul (talk) 23:01, 22 October 2015 (UTC)

Idea for small "note"

In the section at Template:Cite web that contains the information that

|url=   is still required.

, IMHO it might be informative [helpful] to add something like

<note>Note that "|url=   is still required", even though, in most typical cases, the value for the "archive-url" field tends to be a [longer] character string, that already includes -- as a substring -- something identical to, or similar to, the value for the "|url=  " field.</note>

I am not sure whether such a "<note>((text...))</note>" sequence is the correct bit of wikitext to cause it [the "Note" text] to show up -- [or, "pop" up] -- (like a "tooltip") (during hovering of the mouse over a superscript number inside some [square] brackets) as footnotes sometimes do; ... but there is probably some wikitext way to achieve that goal.

I do not know how to do it. So, the change, if any (if approved by some consensus, or whatever), would have to be made [edited] by a person who has a better understanding than I do, of the nesting of transcluded template pages, and the appropriate methods for being careful to make sure that the "edit" will not have any unintended ill effects, before putting it in to the [non- /sandbox] version of the appropriate template "doc" [sub-] page, or whatever. So, at this point, this is a just a suggestion. Any comments? --Mike Schwartz (talk) 17:43, 21 October 2015 (UTC)

The sub-section you're referring to being that on dead urls under Template:Cite web#URL. It is not clear just what you want there – a pop-up tool tip? More explanation as to why a url is still required? Is there some specific problem you have in mind? ~ J. Johnson (JJ) (talk) 19:29, 24 October 2015 (UTC)

What is the best way to include a long quote in a citation so it displays an abbreviated form by default?

I was writing this and realized that if I want to include a long quote in a reference but doing so would make the reference look "ugly," I didn't know the best way to do it.

Ideally, I would use an "inline expansion template" within |quote= so the quote would be clickable/touchable/mouse-over-able and when the reader clicked/touched/moused-over the abbreviated quote the full quote would appear, but I'm not aware of any such template.

Maybe something like 

*{{cite work
|url=http://constitutionus.com/|title=Constitution of the United States of America
|quote= We the people...this constitution of the United States of America{{Fix
 |text= full quote
 |title= We the People of the United States, in Order to form a more perfect Union, establish Justice, insure domestic Tranquility, provide for the common defence, promote the general Welfare, and secure the Blessings of Liberty to ourselves and our Posterity, do ordain and establish this Constitution for the United States of America.
 }}
}}

which produces

My main concern is that this probably won't work with mobile and blind users who may not be able to "hover over".

My secondary concern is that the "fix" template isn't meant to be called directly and it's "link to" and "categorization" elements aren't really applicable here. Ideally there would be a standardized way of doing an abbreviated in-line quotation that expands when the user asks it to, and that method could be documented in the documentation pages for the Citation Style 1 templates.

The other option of using a <ref group=expand></ref> and {{reflist|group=expand}} within another reference is just plain awkward-looking - it's like having footnotes within footnotes.

Ideas anyone? davidwr/(talk)/(contribs) 16:50, 10 October 2015 (UTC)

I think that quotes in citations almost always look ugly regardless of length. Perhaps it is better to put the long quote in a footnote – perhaps with {{efn}} and then cite that:
Example article text that refers to a footnote.[a]
  1. ^ Here in the footnote we have the quoted text and a reference that supports it:
    "We the People of the United States, in Order to form a more perfect Union, establish Justice, insure domestic Tranquility, provide for the common defence, promote the general Welfare, and secure the Blessings of Liberty to ourselves and our Posterity, do ordain and establish this Constitution for the United States of America."[1]

References

  1. ^ Constitution of the United States of America. {{cite book}}: Unknown parameter |subscription= ignored (|url-access= suggested) (help)
I added |subscription=yes to my example because if one is to use the title attribute in some template intended to be placed in |quote= it should stylistically resemble the pseudo-help link following the 'Subscription required' text. I think that the accessibility issues you mentioned argue against the use of such a template.
Because {{abbr}} uses the <abbr>...</abbr> tag, using that template to make tool tips from long strings of text that are not expansions of abbreviations or acronyms violates the tag's particular semantic meaning.
—Trappist the monk (talk) 17:27, 10 October 2015 (UTC)
I was going to say about the same thing as Trappist, though not as well. Separate the quotation from the citation. I find that quotations within citations just get lost in the jumble of dates, italics, and author initials. – Jonesey95 (talk) 00:07, 11 October 2015 (UTC)
It's not just that "quotes in citations almost look ugly", they are somewhat immiscible. It seems that the intention of having a quote in a citation is to provide the exact text of a point that is being paraphrased in the article. I allow that can be useful in the WP context, but a citation (precisely, a full citation that identifies a source) is the wrong place. Where quotation of a passage, or any other comment about it, is useful, it should be treated like page numbers or any other information pertaining to specific passage: following the citation. I suspect many WP editors are confused about this because they often cite only a single passage in a source, and tend to incorporate the specific details into the full citation. Not only should the quotation be separate from the citation, I think we should be deprecating |quote=. ~ J. Johnson (JJ) (talk) 21:15, 11 October 2015 (UTC)
I completely disagree. Separating detailed locations within a source from the general reference information about the source can be a good thing to do in longer articles that re-use some of the same sources many times, but we should not force editors to do that. And when we have a source that is used only once, for a specific passage, a brief quote from the passage can be very helpful in making the source verifiable especially when the actual content is paywalled. Logically, your reasoning would lead us to deprecate |pages= on templates like {{cite book}}; I hope you can see how stupid an idea that would be. —David Eppstein (talk) 21:52, 11 October 2015 (UTC)
Re: paywalled sources and using quotes for verify-ability - yes yes yes this, along with making it easier for future editors to verify hardcopy references and references likely to suffer bitrot, are the primary reason I use long quotes in references. I do see the point about splitting them off if the same basic source is used many times (similar to Template:rp), but that's not the common case for things I edit. davidwr/(talk)/(contribs) 23:09, 11 October 2015 (UTC)
Both of you, please: you misunderstand what I said. I have absolutely no objection to using quotes for the purpose you describe. My objection is to using the |quote= parameter for that purpose. E.g., instead of doing something like
  • <ref>{{cite work ... |quote= We the people ...}}</ref>
we should do
  • <ref>{{cite work ...}} "We the people ..." </ref>.
That is, quotation outside of the cite template, but in the footnote. Okay? ~ J. Johnson (JJ) (talk) 22:51, 12 October 2015 (UTC)
But then when we use {{harv}} and |ref=harv the quote will be outside of the highlighted citation. —David Eppstein (talk) 23:05, 12 October 2015 (UTC)
No problem. "{Harv ...}" is a straight substitution for "{cite work ....}". E.g.:
  • <ref>{{harv ...}} "We the people ..." </ref>.
The "highlighted citation" you refer to – that would be the little drop-down box that appears when you mouse-over the hyperlink to the note? That actually includes the entire contents between the ref tags. For an example see note #12 (and others) at Leech River Fault: two Harv short-cites and a comment that includes a direct quote. Does that work for you? ~ J. Johnson (JJ) (talk) 00:04, 14 October 2015 (UTC)
No, that is not what I mean. I mean that if you use {{harv}} or its relatives somewhere in an article, and one of the CS1 templates with |ref=harv elsewhere in the article, the {{harv}} citation is shown bluelinked. If you click on the bluelink, the article scrolls to the CS1 citation that it corresponds to and highlights it. In some cases you might not want the quote to be highlighted (for instance, if the {{harv}} link is part of a reference that uses a different passage from the same book) but in other cases the quote should be highlighted, and the only way to achieve that is by including the quote in the actual citation template. —David Eppstein (talk) 00:19, 14 October 2015 (UTC)
Oh. Well, then I don't understand what you are talking about. Could you point out some examples? ~ J. Johnson (JJ) (talk) 00:29, 14 October 2015 (UTC)
Look at Riemann hypothesis. Notice that it uses parenthetical referencing (a valid and accepted Wikipedia style) rather than footnote referencing. (It also uses CS2 instead of CS1 but that makes no difference to any of this.) Click on any short reference in the text. Your browser should go to the corresponding long reference in the reference list and highlight it in a light blue color. Now notice that a couple of the references include quotes, including Radziejewski (2007) and Rosser et al (1969). The short (inline) reference to Radziejewski can be found in Riemann hypothesis#Montgomery's pair correlation conjecture. If you click on it, the whole reference, including the quote, is part of the light blue highlighted region. That would not be possible under your proposal. —David Eppstein (talk) 01:29, 14 October 2015 (UTC)
Not so much "not possible" as just not done. But so what? What is highlighted is the full citation itself, rendered as the anchor of the hyperlink. And I would say that is proper. Citations are compact and concise, and any kind of quotation confuses that. Not highlighting the quotation clarifies the citation, and does nothing to diminish the quotation. In what cases would you want the quote to also be highlighted, and why? ~ J. Johnson (JJ) (talk) 05:21, 15 October 2015 (UTC)
It should be highlighted because it is part of the full reference that one wants readers to see when they click on the short reference. Just like a quote in a footnoted reference should be part of the pop-up the readers see when they hovers over a footnote mark. Or do you want to damage that functionality too? —David Eppstein (talk) 05:28, 15 October 2015 (UTC)

What I have suggested does not damage any functionality (as far as I see it). I am wondering about what particular kind of functionality you think you need. Note that you are mixing two different - albeit very similar - things here. In a footnoted reference the superscripted, bracketed number (e.g.: [1]) is a link to everything that was placed between <ref>...</ref> tags. By virtue of magical software hovering over the link produces (but perhaps not on the Talk page) the little pop-up box with the contents of the <ref>...</ref> tags. Which contents can be citations - or quotations, comments, whatever. In this case taking a quotation out of a citation makes no difference at all in this display functionality as it acts on the contents of the ref tags as a whole. (See Leech River Fault for examples.)

References

  1. ^ Citation: Smith (1900), Title. "Quotation outside of template." Comment.

In the second case ("Harvard" parenthetical style as seen at Riemann Hypothesis) the in-line link is produced by a Harv template, and hovering over it does not generate a pop-up box. When you click on the link the target you go to is the citation, embedded in the adjacent text. The only difference (from the pov of display) between having a quotation inside the citation or following it is whether it is highlighted. E.g., compare these two links:

No pop-up boxes, that is the inherent functionality of Harv, but once at the target readers see everything, including what is outside of the citation template. Is there some functionality you have in mind that I have missed? ~ J. Johnson (JJ) (talk) 22:51, 15 October 2015 (UTC)

David Eppstein: comment? I think I have shown there is no loss of functionality in not using 'quote='. Is there anything I may have missed? ~ J. Johnson (JJ) (talk) 22:07, 19 October 2015 (UTC)

Yes. You have missed that when the quote is not highlighted, it is seen by readers as not being part of the citation, when it should be treated as part of the citation and should be highlighted. What part of this is hard to understand? —David Eppstein (talk) 01:06, 20 October 2015 (UTC)
David, getting snippy is not useful. What is hard to understand here are the parts that you don't fully explain. I am trying to work out exactly what you mean, what you want, and even why you want it. My understanding (currently) of what you want is that when the reader clicks on a Harv-style link (such as Odlyzko 1992a) and lands on the target the quotation is highlighted as well as the citation. (Right?) This would be similar to the effect when using the <ref> tags where the entire note is highlighted.
Our key difference here is where you think the quotation "should be treated as part of the citation" (and thus highlighted). My objection is that quotations are not part of any citation. (Obviously!) But before we run off about that, please note that we can finesse this particular point by replacing your reference to "citation" with "note". That is, that you want to highlight both the citation (as I narrowly define it) and the quotation associated with it, in the manner seen when using <ref> tags. Whether that is a reasonable expectation is still open, but with this understanding we avoid my objection and therefore have scope for discussion. Is that acceptable? ~ J. Johnson (JJ) (talk) 23:08, 21 October 2015 (UTC)
David? I am interested in what you think. ~ J. Johnson (JJ) (talk) 19:13, 24 October 2015 (UTC)
I have already told you what I think. Anything more is just tedious wikilawyering. —David Eppstein (talk) 19:57, 24 October 2015 (UTC)
No, it is not wikilawyering, it's figuring out what you want, and why, when you told it poorly. Anything less is just subjective like/dislike, deserving no argumentive weight. I am disappointed, but so be it. ~ J. Johnson (JJ) (talk) 21:18, 26 October 2015 (UTC)

Request for Comments: Italics or Non-Italics in "website" field

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.
The arguments are good and thought out on both sides of the question. The support argument is that style guidelines like MLA and Chicago suggest italics and standardization of articles on WP. The oppose argument is that it should be up to the editors or that its not needed. The two sides are almost dead even, so this RFC is closed no consensus. There was also a tangent into work vs website that didnt come to any conclusion. AlbinoFerret 15:26, 27 October 2015 (UTC)

In the template "cite web", which is used when "cite news", "cite newspaper" or "cite journal" is not, should the "website" field italicize the name of websites, in the manner of books or periodicals?

  • Oppose No mainstream source italicizes British Board of Film Classification, U.S. State Department, Sears, Rotten Tomatoes, New York State Department of Motor Vehicles or other entities. Indeed, none of these entities themselves italicize their names on their own websites. These aren't publications, and we have templates like "cite newspaper" that we use for publications. It seems eccentric to use a citation format virtually no one else uses, and it also seems inconsistent that a movie article, for example, would mention Rotten Tomatoes in text but call it Rotten Tomatoes in a footnote. --Tenebrae (talk) 16:50, 9 September 2015 (UTC)
"No mainstream source italicizes [examples]". Wrong. The most commonly-used style guides MLA ([7], scroll down to the section "A page on a website") and the Chicago Manual of Style ([8]) both use italics for all websites. ASA style (generally used in sociology field) and Oxford style only include the url, not the website name. APA, generally used in the field of psychology, doesn't include the name of a website unless it corresponds to a scholarly journal (otherwise, it uses "Retrieved from [url]"). Vancouver style (see page 5, generally used in the bio-sciences) does not italicize the name of the website, but includes "internet" in brackets after the website name, for example: Wikipedia [internet]. Since the AP style guide is intended for new stories, it does not cover footnote/bibliographic citations, since new stories use in-text attribution. "AP doesn't use italics in news stories. That includes newspaper names and magazine references. No italics." ([9]). So BOTH of the major style guides (MLA & Chicago) that are used for general writing italicize the name of a website, while one (Oxford) does not include the name of a website. Of the style guides that are widely used only in a limited field, only one style guide for citations (Vancouver) does not italicize the names of websites and two generally do not include the names of the website (ASA, APA). AHeneen (talk) 22:19, 11 September 2015 (UTC)
  • The MLA is an inapplicable example. It says to include the additional information or otherwise modified information, like domain names [e.g. .com or .net]" (brackets in original source) and to even do so if it's a publication name. It's well-established that Wikipedia cites The New York Times and not nytimes.com, and even editors who who want to keep the "website" field italicized agree Wikipedia does not and should not cite "Sears.com" or italicize names with ".com" in the formal name, like Amazon.com. So MLA has no bearing on the disucssion here. --Tenebrae (talk) 22:35, 11 September 2015 (UTC)
  • Additionally, it is not, in fact, wrong to say "No mainstream source italicizes [examples]". I'm referring to the fact that Amazon.com, Sears, CBS News, etc. are not italicized terms in general prose use. Yes, you can find a style guide that italicizes website names in footnotes. And you can find style guides that do not, so that part's a wash. The fact is that unlike periodicals, entities such as Amazon.com, Sears, CBS News, etc. are not normally italicized in prose text, and there's no reason to have a non-periodical in regular font in prose and italicized i footnote. One can always find someone doing things eccentrically — I believe The New York Times, maddeningly, says 1950's rather than 1950s when it means the entire decade. But just because The New York Times or Chicago Manual of Style does something eccentrically that we have to be eccentric as well. We can use common sense. --Tenebrae (talk) 22:42, 11 September 2015 (UTC)
MLA does not say to use the domain name, except in limited circumstances where the publisher uses the domain name in the website name. The full quote, which you conveniently did not include, is: "Remember that some Print publications have Web publications with slightly different names. They may, for example, include the additional information or otherwise modified information, like domain names [e.g. .com or .net]." It's not common, but some publishers include the domain name, "[name] online", or do something similar with the name of their website. It is absolutely not eccentric to italicize all websites. It is eccentric to have a policy that is inconsistent and determines which sites to italicize based on users' opinions. For example, you give the example of CBS News, but it is a major news site that is little different than a newspaper or TV news program, which is considered a work by any sensible person, except that it is on the internet. Websites like the New York Times have content on their websites that are not published in print. Your comments drive home the reason why we need a simple, common-sense policy about italics...there should not be excessive dispute about which websites merit italics and which do not. Common sense is to italicize all websites, rather than have a policy that is open to differing opinions among users. AHeneen (talk) 03:24, 12 September 2015 (UTC)
Um, most of those examples are not |work= (i.e. |website=) values but |publisher=. Of the entire list only Rotten Tomatoes is a |work=, and, yes, various sources do, and various style guides would, recommend italicizing it (same goes for CBS News as a news source rather than as an intellectual property business entity. I'm not sure what relevance that external style guides are thought to have here, and that's all I'll say on that matter for now.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  12:22, 12 September 2015 (UTC)
  • Comment: MOS:TITLE#Italics says, "Website titles may or may not be italicized depending on the type of site and what kind of content it features. Online magazines, newspapers, and news sites with original content should generally be italicized (Salon.com or The Huffington Post). Online encyclopedias and dictionaries should also be italicized (Scholarpedia or Merriam-Webster Online). Other types of websites should be decided on a case-by-case basis." I think if the website title is italicized in its Wikipedia article, it should be italicized in the citation template as well (and probably should use the {{cite news}} template as well). We do have a challenge here when it comes to websites that are not identical to news sources. Rotten Tomatoes and Box Office Mojo are more like database sources, but they do have parts of the website where there are write-ups that are basically like news articles. (Rotten Tomatoes has a "Critics Consensus" news column, and Box Office Mojo summarizes box office forecasts and actual performances in such articles.) I suppose if websites like these are not primarily news-type outlets, we do not italicize them? Erik II (talk | contrib) (ping me) 17:03, 9 September 2015 (UTC)
  • Italicise value of website parameter. This is supported in Chicago Manual of Style 16th ed. p. 754 which I quote:

16. Ellis, Rhian, J. Robert Lennon, and Ed Skoog. Ward Six (blog). http://wardsix.bog.spot.com/.

Jc3s5h (talk) 17:12, 9 September 2015 (UTC)
And other style guides do not. Some do, some don't. Cherrypicking just one that supports your arguments isn't helpful. --Tenebrae (talk) 22:46, 11 September 2015 (UTC)
  • Italicize and on a case-by-case, editors can omit the name of a website that matches its publishing entity and give just the |publisher= instead. So to reply to Tenebrae, |publisher=British Board of Film Classification would be 100% appropriate and correct, and the rendered formatting for the publisher would not be in italics. Imzadi 1979 → 17:30, 9 September 2015 (UTC)
  • Italicise per Jc3s5h, we should take our lead from mainstream style guides. According to Jc3s5h, Chicago Manual of Style italicises them. Likewise the 19th edition of The Bluebook (legal citation) requires them to be in small caps, which is also how it treats books and magazines (italics being largely reserved for case names). By contrast however, AP style is to use standard type but title-style capitalization, so its not uniform. ~ ONUnicorn(Talk|Contribs)problem solving 17:31, 9 September 2015 (UTC)
  • Leave default alone but add named parameters to give editors control of how this is displayed, e.g. |title-format=, |publisher-format=, |website-format=, etc. with values that correspond to "quoted," "italic," and "plain". davidwr/(talk)/(contribs) 18:35, 9 September 2015 (UTC)
  • Leave un-italicized - There have been many discussions at the MOS about whether or not to italicize website names. Our current guidelines are a sensible compromise. By leaving them un-italicized by default, we allow the editor to choose (and thus to properly conform to the MOS). I would probably support making them italic by default if either the MOS is changed or a new parameter is added to allow overriding the default italicization. Kaldari (talk) 22:41, 9 September 2015 (UTC)
  • Yes, italicize, as it is standard practices to italicize the names of publications. Tenebrae's opposition is faulty because he has persistently misunderstood (see the extended discussion above) the intended scope of the |website= parameter, first conflating it with hostnames (URLs), now with publishers. ~ J. Johnson (JJ) (talk) 01:19, 10 September 2015 (UTC)
No. Just because you disagree with me does not make my position faulty. I am not misunderstanding anything. You are claiming that corporations and government agencies suddenly transmogrify by magic into publications. I've tried to be politic here, but if you're going to get personal and suggest that anyone who disagrees with you must have "faulty" reasoning is insulting and plain wrong. Virtually no mainstream source italicizes Sears, Home Depot, Simon & Schuster or the New York State Department of Motor Vehicles. We don't italicize Rotten Tomatoes in article prose, yet you want a field that italicizes it in footnotes. That's ridiculous. --Tenebrae (talk) 01:30, 10 September 2015 (UTC)
Again you have it backwards. Your position is faulty because of your imprecise thinking, quite independently of what ever I think about it (or you). You certainly misstate my position: I have not "claim[ed] that corporations and government agencies suddenly transmogrify by magic into publications", and I will thank you to stop such misrepresentation. If you are going to take disagreement as a form of insult perhaps you should refrain from requesting comments. ~ J. Johnson (JJ) (talk) 22:47, 10 September 2015 (UTC)
  • Comment It depends on usage. Sometimes, a web site is semantically almost the same as a publication. Other times it is semantically almost the same as a publisher (no italics). At other times, it is semantically more akin to a bookstore or library (again, no italics). We need a clean, somewhat consistent way for editors to cite the website by name and give it the proper italics or lack of italics depending on the semantics. Here's an example: If you cite a copy of a pre-1923-century National Geographic Magazine article hosted at Project Gutenberg, you probably don't want |website=Project Gutenberg to show up in Italics. On the other hand, if you cite the same article hosted at http://ngm.nationalgeographic.com/, you probably may very well want |website=National Geographic Magazine italicized. Note - for those counting noses I already made my main comment above - see "Leave default alone." davidwr/(talk)/(contribs) 02:08, 10 September 2015 (UTC)
I understand the comment about the bookstore/library, but it's is important to note that your example is bad. The "via" parameter in Citation Style 1 templates is intended for this purpose. Your example should use Template:Cite journal with |via=Project Gutenberg. AHeneen (talk) 22:19, 11 September 2015 (UTC)
  • Oppose forcing italicization for reasons explained by Davidwr above. Granting users the right to understand context, and italicize properly on their own should be what we do. As noted, there are many cases where the name of the website itself should not be italicized. And many cases where it should. Having a single "one size fits all" solution is not good, as having a template that forces a certain style which may not be universal would do. Yes, we should italicize appropriately. But is it really that hard for users to type four apostrophes when needed? --Jayron32 02:30, 10 September 2015 (UTC)
  • Thanks for the endorsement, but the "two apostrophes" solution may not be the best solution, in that computer programs that parse this template for meaning may be confused. See my suggestion above ("Leave default alone") for having a different parameter to govern the formatting. davidwr/(talk)/(contribs) 02:57, 10 September 2015 (UTC)
    • Actually, I think both of you are on the right track. Normally, editors add the two apostrophes before and after a word or phrase to italicize it. So while that can work in reverse — ading two apostrophes before and after a word or phrase in an italicized field to un-italicize it — that's counterintuitive. So wouldn't it make sense to have the website field non-ital, and that way editor who want to italicize something there can do so the normal way. --Tenebrae (talk) 23:28, 10 September 2015 (UTC)
    • Add to address davidwr's astute point, I think if we were citing National Geographic we would use "cite news" or "cite journal", so the question of having a publication in the "cite web" website field shouldn't really be an issue. --Tenebrae (talk) 23:31, 10 September 2015 (UTC)
The template's we're discussing are Citation Style 1 templates, so all usage of the templates should be the same style. If an article is using a different style (eg. MLA, Vancouver, APA), then these templates shouldn't be used. AHeneen (talk) 22:19, 11 September 2015 (UTC)
  • Leave default/italicized. As has been stated in the discussion above, the title of the website is used, not the domain name or the URL. The website is generally not the publisher; e.g., Deadline Hollywood, TheWrap, Indiewire, Vox (website), Rotten Tomatoes, and Metacritic are not publishers (editors have added them to the publisher= field). Moreover, other style guides, such as the Chicago Manual of Style, italicize the name of the online source. Some editors either confuse the name of the website as the publisher or just use the publisher parameter so the online source isn't italicized. Template:Cite_web#Publisher says, "Do not use the publisher parameter for the name of a work (e.g. a book, encyclopedia, newspaper, magazine, journal, website). ... Omit where the publisher's name is substantially the same as the name of the work (for example, The New York Times Co. publishes The New York Times newspaper, so there is no reason to name the publisher)". WP:ITALICS says, "The medium of publication or presentation is not a factor"; whether or not the online source/website is also a print publication is irrelevant; it's the name of a work - which has produced the content cited - therefore it should be italicized. I'd say one should use the work= parameter to cite print publication and online sources/websites that are also print publications; use website= parameter for strictly online sources. Lapadite (talk) 02:20, 11 September 2015 (UTC)
Indeed, the "publisher" field is being used for, say, Rotten Tomatoes since the "website" field italicizes it, and Rotten Tomatoes simply isn't italicized. Same with Metacritic and Box Office Mojo, these all being commonly used in WP:FILM articles.
Template:Cite_web#Publisher says, as you note, "Do not use the publisher parameter for the name of a work (e.g. a book, encyclopedia, newspaper, magazine, journal, website)." Yet having that last word in this list of examples, "website", does not mean websites are automatically italicized, because Wikipedia:Manual of Style/Titles#Major works states, "Website titles may or may not be italicized [emphasis mine] depending on the type of site and what kind of content it features." It goes on to gives examples of what should be italicized: "Online magazines, newspapers, and news sites with original content should generally be italicized (Salon.com or The Huffington Post). Online encyclopedias and dictionaries should also be italicized (Scholarpedia or Merriam-Webster Online)." And then it specifically notes, "Other types of websites should be decided on a case-by-case basis."
Case-by-case basis. So websites are not to be automatically italicized. It would seem to make sense, then, that the "website" field not automatically italicize, since things that need to be italicized can still be italicized in the regular manner if the field doesn't do it automatically. --Tenebrae (talk) 03:33, 11 September 2015 (UTC)
I'm repeating one of Tenebrae's comments above for emphasis: editors specifically use the "publisher" parameter for website titles because the "website" parameter italicizes by default, and every commonly used website title I've seen is not italicized by our own MOS guidelines. As I note below, the very examples Lapadite77 cites in his argument above to keep the italics are not italicized in their own articles. The number of website names established as "major works" that should be italicized is relatively small compared to those that are not. — TAnthonyTalk 19:54, 11 September 2015 (UTC)
  • Oppose default italics, as is currently in place. See #Italicization of websites in citations, above. Most website names and/or urls are not italicized per current MOS convention, so this should not be the default. A general discussion about outside style guides is irrelevant because the current Wikipedia style guides establish that website names are not italicized like "publications" are, as in the given examples of TheWrap, Indiewire and Rotten Tomatoes. If our articles about these websites establish and confirm this style, citations should not diverge from it. In the case of items like The Huffington Post, the publication should be cited as |work=The Huffington Post rather than |website=HuffingtonPost.com anyway, but even if the url is preferred to be shown, it should be HuffingtonPost.com and not HuffingtonPost.com. — TAnthonyTalk 17:17, 11 September 2015 (UTC)
The "url" form is NOT preferred. Unless, of course, it has been adopted as the name of an organization, publication, or (horrors) website. ~ J. Johnson (JJ) (talk) 23:57, 11 September 2015 (UTC)
  • Italics by default As I mentioned in the previous discussion above ("Italicization of websites in citations") and in the response to the first comment by Tenebrae, the two most widely-used style guides (MLA and the Chicago Manual of Style) both use italics for the names of all websites. A citation style should be as uniform as possible, not filled with vague criteria. How will we determine which websites merit italics and which do not? This can especially be a point of disagreement in a featured article/list nomination. The problem is that there is an increasing amount of websites that function much like a publication such as a book or magazine, without a print equivalent, and in such cases the website is essentially a work similar to a book or magazine. There is too much opinion involved in distinguishing a website that should be italicized and one that shouldn't. Adding a parameter to not italicize something would not fix this problem. Furthermore, I think the implications of a change haven't been appreciated by the other commenters. The citation style 1 templates are used millions of times on Wikipedia (there are almost 5 million articles on en-wp, most use CS1 templates, and the articles with no CS1 citation templates are balanced by articles with 20..50...100...200+ CS1 templates). Changing the default behavior of these templates to not italicize websites and forcing users to manually add italics would be a monumental task to implement and not very easy to do with a bot. Using italics for all website names is simply the easiest way to format citations, eliminates disputes over which websites should and should not be italicized, and matches the two most widely-used style guidelines. AHeneen (talk) 22:19, 11 September 2015 (UTC)
Here's the thing, if these are the (external) style guidelines Wikipedia should be following, why are the majority of website titles which are the subject of articles currently not italicized? And where is the discussion that initiated the idea that the website parameter be italicized? The fact that the template is in use by a trillion articles means nothing if the format was not set with an adequate discussion, or for that matter, if it is now being challenged. — TAnthonyTalk 00:40, 12 September 2015 (UTC)
In 2009, there was a discussion about italicizing everything in the work parameter, including websites. At the time, neither the MOS/Titles nor MOS/Text formatting pages addressed whether italics should be applied to websites or not. The titles page simply said (emphasis mine) "Italic type (text like this) is generally used for the following categories of titles:" followed by a list of things. AHeneen (talk) 03:24, 12 September 2015 (UTC)
  • Support italics. When we cite, in |website= (which is {{Cite web}}'s |work= parameter), something like FooBarBaz.com we're citing it as the title of a publication, not referring to it as an entity, so it is properly italicized as the title of major work, like a journal, book, or feature film. When I say "Jane works at FooBarBaz.com", I'm referring to a business entity. When the site has a conventional title, without the .com or whatever, we use that: {{Cite web|website=[[Slate (magazine)|Slate]]|...}}, not {{Cite web|website=[[Slate (magazine)|Slate.com]]|...}}. When the site has no such non-domain-name title, the domain name is the title, and this quite common for online publications, as in our FooBarBaz.com example. In running prose, write: "According to a FooBarBaz.com article ...", but "...as the new CEO of 's.com". When the website/work and publisher are the same or essentially the same, omit the publisher, exactly as we do for newspapers: {{Cite web|news=[[The New York Times]]|...}}, not {{Cite web|news=[[The New York Times]]|publisher=[[The New York Times Company]]|...}}. This is quite common with online publications, where the business entity does not really exist separately from the website for our intents and purposes. This is usually apparent in the copyright notice; if the indicia for SnorkelWeasels.com says "Copyright 2015 SnorkelWeasels.com" or "Copyright 2015 Snorkel Weasels LLC", you can usually safely omit the publisher parameter.

    This would necessarily invalidate much of the oppose reasoning above relating to stuff like "British Board of Film Classification, U.S. State Department, Sears ... New York State Department of Motor Vehicles or other entities"; those are all |publisher= (as "entities" indicates), and their corresponding |website= a.k.a. |work= parameters are, respectively: BBFC.co.uk, State.gov, Sears.com, and DMV.NY.gov. This is important, because most such entities have multiple publications, online and offline. "U.S. State Department" is absolutely not a work title. It's typical, not just common, for universities to have dozens of websites on a departmental level (foo.bar.UofBaz.edu) that are often separately written, maintained, and funded, with separate purposes and audiences, and with their own editorial processes. It's also common for major governmental departments/ministries to do likewise (e.g. USEmbassy.gov is also a US State Dept. website). And it's fairly common for business entities to have multiple consumer-facing websites (usually divisional and/or world-regional), plus a separate Corporate.Quux.com type of site for non-consumer information about the company. And so on. Even Sears has multiple websites (I know, because it gives me a headache to remember which one to log into with what password to pay my bill); we might cite any of them (even the Sears bill-paying one, e.g. for what their privacy policy states vs. what some journalist wrote about it in a security scandal article or whatever). For any news publisher with multiple publications and different editorial boards, such that the paper and online editions may differ radically in content, it is safest to cite the online edition by its domain name (without "www." unless DNS resolving fails without it) as the work (or the online one's separate title if there is one, e.g. Wired News vs. Wired the magazine, which are from the same publisher) rather than the name of the paper publication. I tend to do this to be safe anyway, and cite, e.g. Guardian.co.uk not The Guardian, because I don't know their online vs. paper editorial process.

    The easiest way to keep this straight in one's head is probably to stop using |website= and always use |work=, to remind oneself that the parameter is about a publication. And if ever in doubt, remind yourself that Apple Records is a publisher and The Magical Mystery Tour is a work. It never ceases to amaze me how frequently people confuse |publisher= with |work= and its aliases. There's no reason for it. We all understand the difference between Marvel Comics, the business entity, and Ultimate Fantastic Four, the comic book series, don't we? Apply the same reasoning to websites. Oxford University Press is a publisher, not a book.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  12:22, 12 September 2015 (UTC)

    Self-correction: Salon has gone back to using Salon instead of Salon.com as the title, and the business name has changed, to Salon Media Group, so it's essentially the same as Wired News as an example; I've changed the Salon example to a hypothetical one.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  15:46, 14 September 2015 (UTC)

I, for one, appreciate anyone willing to do a detailed analysis, although a non-succinct wall of text such as this, as we've seen in countless previous discussions all over Wikipedia, can sometimes be used to overwhelm a discussion. I'm not saying that's the intent here, and in fact, I see things I agree with and things I disagree with in the text above, which suggests it's an attempt at a fair analysis (though the lack of paragraph breaks makes it all a little hard to follow). It also sounds as if while he says "Support Italics", he actually doesn't support them in the website field: "Oxford University Press is a publisher, not a book." Absolutely. So it sounds as if he would not italicize "Oxford University Press".
I absolutely agree with him, and I think we all do, that when dealing with something that's unquestionably a publication, like The New York Times, "The easiest way to keep this straight in one's head is probably to stop using |website= and always use |work=, to remind oneself that the parameter is about a publication."
But as we're dealing with the field "website" here, we still need to reach consensus on that. I think the simplest way to address this is to note that Wikipedia:Manual of Style/Titles#Major works states, "Website titles may or may not be italicized [emphasis mine] depending on the type of site and what kind of content it features." Since we have a a choice of whether to italicize or not, I'm not sure why we're forcing italics in the field rather than not italicizing and letting editor italicize when appropriate. --Tenebrae (talk) 20:26, 13 September 2015 (UTC)
Thank you, Mac. Tenebrae, you say you "absolutely agree with him", even though you also say there are things you with which disagree. I think what you agree with is that the title of works are italicized. What you object to is the italicization of certain cases, such hostnames (from a URL) and names of organizations (including publishers). But that is not a matter of disagreement, because no one here accepts such italicization. Your more particular objection – to "forcing italics" on the content of |website= when the content is such as we all agree should not italicized – overlooks a very essential point: if the content is not the name of the work then it should not be in "website" in the first place. The problem there is not the italicization, but misuse of the parameter.
You have cited the MOS that "Website titles may or may not be italicized ...". Please note that that section gives no examples of a website whose name ought not to be italicized. If you have any such examples it might be useful to mention them. ~ J. Johnson (JJ) (talk) 22:58, 13 September 2015 (UTC)
What I said was that I absolutely agreed with him on the specific point that we italicize something that is "unquestionably a publication, like The New York Times. You were deliberately misrepresenting my stance with your opening sentence above in a false attempt at making me appear contradictory. You additionally put words in my mouth. I can state my position; I don't need you to misstate it.
And, again, you refuse to listen to examples I've made previously: Rotten Tomatoes and Metacritic, to name just two websites, are websites. They are not italicized. No one italicizes them in prose, not even RT and MC themselves, and they don't suddenly become The New York Times in a footnote. And I shouldn't have to give examples when the MOS itself says there are website titles that may not be italicized.
And since the MOS says "Website titles may or may not be italicized ...", I'm not sure why we're forcing titles in the "website" field to italicize.--Tenebrae (talk) 15:10, 15 September 2015 (UTC)
Jeez, will you ever learn to pay attention? My "opening sentence above" in no way misrepresents what you said. I quite understand that your "absolute agreement" is not universal (i.e., applies to a specific point); I have not said otherwise. The only problem here is where you assumed that I was asserting your agreement as applying universally, and then further assumed I that was acting in bad-faith. If you thought I had misstated something you could have asked for clarification, but no, you just start assuming bad motives. This is a clear violation of WP:AGF. And you're so wrapped up in this that it seems you have totally missed why your "forced italics" is a false issue.
As to why we italicize titles in |website=: because by definition they are titles of works, which are italicized by standard citation convention.
I will address your other points below. ~ J. Johnson (JJ) (talk) 22:47, 15 September 2015 (UTC)
(edit conflict)Tenebrae, thanks ever so much for coming to the conclusion that maybe my faith was good after all, because you happen to agree with some of what I said (or think you do). Some of us value precision over convenience. I'm getting a bit tired of being berated for being in the former camp. I don't see the point in grousing about a few paragraphs of text on a site that consists of about 99.5% paragraphs of text. How can paragraph breaks make text hard to follow? The very purpose of them is that they make text easier to follow; that's why they were introduced so many centuries ago.

Anyway, of course we would not italicize Oxford University Press. "Oxford University Press" does not go in the website field, it goes in the publisher field, just like Apple Records or Universal Studios, or Marvel Comics, etc. It appears to me that you skimmed what I wrote, concluded what you wanted to, and are now putting words in my mouth that are the exact opposite of what I said, e.g. 'It also sounds as if while he says "Support Italics", he actually doesn't support them in the website field', which is bassackwards. No separate consensus needs to be reached on |website=; it's the same thing as |work=, just as |journal= is in {{Cite journal}}. I just use |work= in all of them, and it works fine.

The poorly-worded guideline quote is trying awkwardly to get at the "according to a FooBarBaz.com article" vs. "according to FooBarBaz.com's privacy policy" distinction drawn earlier, and to separate sites that intrinsically are publications (like Slate or xkcd) from those that are services/applications/shops (Gmail, Yandex, Amazon.com). That's about use in running prose; in a citation, if we use |website= a.k.a. |work=, we're citing something as a published work, whatever it's other possible uses.

Contrived example where the publisher shares essentially the same name as the publication, and it's name is Billiards.info (not Billiards):

Examples and stuff
  • If you want to cite an article: {{Cite web|title=How to Win a Lot|first=Sam|last=Jones|website=Billiards.info|url=...}}
  • If you want to cite their privacy policy, which is not really part of the publication but part of the entity's corporate e-paper: {{Cite web|title=Privacy Policy|publisher=Billiards.info Inc.|url=...}}
Easy-peasy. If it were stuff where the publisher, the domain name, and the title of the publication are all distinct, it could be done this way, also easy:
  • Article: {{Cite web|title=You Can't Outrun a Komodo Dragon|first=Chris|last=Chan|website=[[Wired.com|Wired]]|publisher=Condé Nast|url=...}} (note piped link to distinguish from paper edition)
  • Something else: {{Cite web|title=Wired.com Terms of Use|author=Digital Properties Legal Department|publisher=Condé Nast|url=...}}, with no need to insert |website=Wired.com at all (and using |website=Wired might be questionable, since the policy is about use of the online service, Wired.com, not use of the publication as a publication, and might cover other things at that site, such as user forums, that are not part of the publication proper).
But all of this is really hair-splitting; I'm skeptical that enough editors could care that we need to get into this in any more detail. What's important is that citations be usable to find sources accurately, and secondarily that they be consistent enough to be usable in this way. We don't need micro-formatting exceptions that don't help in that regard.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  15:46, 14 September 2015 (UTC)
    • And I ask, for what reason? Because the MOS says "Website titles may or may not be italicized ...". Since that's the case, why are we forcing titles in the "website" field to italicize? On its face, that goes against the MOS. --Tenebrae (talk) 15:13, 15 September 2015 (UTC)
  • WP:MOS does not say "Website titles may or may not be italicized". — Preceding unsigned comment added by Jc3s5h (talk • contribs) 16:01, 15 September 2015‎
The MOS does say "may or may not be italicized." (Second paragraph from the bottom of the seciton.) However, what Tenebrae seems to have missed is that this is not permissive, at the whim of individual editors. It depends "on the type of site and what kind of content it features. But while the MOS provides several examples that should be italicized, it does not provide any contra-examples. It says only: "Other types of websites should be decided on a case-by-case basis." In a previous comment (above) I suggested to Tenebrae that if he had any useful examples it might be useful to mention them. He said (15:10, 15 Sep) that he "shouldn't have to give examples when the MOS itself says there are website titles that may not be italicized." Which is partly true — and partly false. What is false is the assertion that "the MOS itself says there are website titles that may not be italicized." The MOS makes no such assertion that such titles exist, and certainly not that "may not be italicized" (in the sense of not permitting). It only allows the possibility of such cases. And so far we have not seen any clear instances of "website titles" as titles of works - which is how |website= is defined - which should not be italicized. Lacking any such instances the argument for non-italics seems distinctly hypothetical. ~ J. Johnson (JJ) (talk) 22:55, 15 September 2015 (UTC)
      • I'm rather tired of J. Johnson (JJ) not listening to the examples I've constantly given. For the fourth or fifth time: Rotten Tomatoes, Box Office Mojo and Metacritic are website names that are not italicized.
      • This editor also apparently has never encountered the concept of "corollary": If MOS says, "Website titles may or may not be italicized", then the inherent corollary is that some website titles are not italicized. That's basic use of the English language. --Tenebrae (talk) 17:36, 17 September 2015 (UTC)
And I am rather tired of your constant misrepresentations, failure to understand, and AGF failure. But perhaps you are ready to listen this time?
As I have been trying to explain to you for some time: the problem with these hypothetical italicizations that you object to – that everyone agrees would be improper – is not with the handling of |website=, but with the improper use of |website=. This parameter is defined at Template:Cite_web#Publisher as an alias for |work=, which contains the name of certain kinds of publications. Note: places, hosts, organizations, and publishers are NOT works. The problems you object to arise solely from your vague, ill-defined, and over-inclusive concept of "website names". In regard of Rotten Tomatoes (and your other examples): is that a publication (work), such as regularly publishes articles? Or is it a place, where a whole lot of diverse and constantly changing content can be found? If it is a place it does not belong in |website=, and there is no issue with italicization. Your entire tendentious complaint here rests entirely on such incorrect usage.
BTW, your understanding of corollary is faulty. The implication that there might exist a "website title" that 1) is properly used in |website= as the title of a work, and 2) should not be italicized, in no way establishes whether such an instance actually does exist. The examples you have offered are worthless because of their work/non-work ambiguity. ~ J. Johnson (JJ) (talk) 22:20, 17 September 2015 (UTC)

Checking back in on this messy debate, and J. Johnson I'm trying to follow your logic. Are you saying that Rotten Tomatoes is a place/publisher and not a website? Then what is |website= used for? My original point in all this is that it makes no sense to me why |work= and |website= are interchangeable when in many (most?) instances they are not publications. This is the issue Tenebrae and I seem to be stuck on: The Rotten Tomatoes article asserts that it is a website, but "Rotten Tomatoes" is not italicized. Either:

1. This is improper application of the MOS, and similar website titles (Box Office Mojo, Metacritic, etc) should be italicized in their articles, or
2. The |website= should not italicize by default, or
3. (By your logic above) The Rotten Tomatoes article should call it an "online publisher" rather than a website.

I see the distinction you are making, that we should be putting sites like Rotten Tomatoes in |publisher=, but that is counterintuitive to most editors, and |website= is mostly used for urls and website titles.— TAnthonyTalk 22:40, 17 September 2015 (UTC) '

No. What I am saying is that if the Rotten Tomatoes website is deemed to be a place/publisher/etc. – and I leave that determination to whoever wants to take it on – then it is not a work, and therefore does not belong in |website=. The question is not whether whether RT is a website (that is, an Internet location containing "web" content), but whether that website is a kind of publication (i.e., a work), or something else. (And incidentally: RT is a website, and the publisher is probably Flixter, Inc.)
Whether the articles for all Category:Film review websites should be italicized in the same manner as done for newspapers is a MOS issue, and would depend on whether they are newspaper-like works. If they are not italicized, then presumably they are not "works". In that case they should not be used in |work= – or its aliases.
It is a standard citation convention, and established here by default, that the titles of works are italicized. The whole problem here seems to come to some editors thinking |website= encompasses all websites, including those that are not "works". (It certainly should not be used for urls.) If this is too difficult for general understanding then perhaps this parameter should be removed. ~ J. Johnson (JJ) (talk) 00:18, 18 September 2015 (UTC)
On removing "website" altogether: You bring up a good point. As an editor, I just assumed that the website= parameter was for the web site itself, but that it should only be used if adding the web site was helpful. I did not, do not, and probably will not assume that "website=" should only be used when the website is a "work," unless/until the documentation is updated to reflect this. If the consensus here is that |website= should only be used when the web site is a "work" and that it should not be used when it is a "place" or other "non-work descriptor" then all related documentation should be updated to make this point crystal-clear. Ditto if that's not the current consensus but the consensus evolves to that in the future. davidwr/(talk)/(contribs) 04:19, 18 September 2015 (UTC)
I believe all related documentation should be updated to make it crystal clear that |website= is an alias of |work= and should be used for the title of the website. There are two situations where the website (or work) parameters should not be used. One is if the website does not have a title (the html title tag might have a value, but that value might actually be nonsense, or the name of a company, and there is no large text near the top of the page that serves as a title). The other situation is where |title= is also the title of the "home page" where the information is found. A large website with many subpages can be a work, whether it has been assigned a title or not, and whether it corresponds to a traditional paper or film work or not. If it hasn't been assigned a title, I would just set |title= and leave it at that. Jc3s5h (talk) 12:04, 18 September 2015 (UTC)
It seems funny to me to try and force/enforce a counterintuitive usage of a parameter, especially when novice editors may not read the documentation in depth or at all, or may use the wizard tools. J. Johnson has made a valid argument (that I agree with) to consider certain websites to be "publishers" if they are not considered "works", but I think that distinction will be lost on the common editor, documentation or not. Of course, I am saying this from my belief that most of the websites I have seen cited as such (those without associated magazines or newspapers etc.) seem to fall into the "publisher" category.— TAnthonyTalk 15:29, 18 September 2015 (UTC)
To do a little fine-tuning: not necessarily publisher, as many of these sites are aggregators, more in the nature of a big wall where individuals hang their posters. The key point is not a "work". The term "website" gives no clue that it is meant to be used in such a carefully distinguished manner. (Cf. "website-as-a-work".) Given this basic weakness, a similar weakness in understanding the nature of a "work", existing mis-usage, and a general disdain for RTFD (especially when a term and its intended use seems "obvious"), I rather doubt that documentation will have much effect.
At this point I am thinking that |website= could be deprecated, with better documentation of where to use |work=. (Those editors that understand it can use it, and the others won't be mislead.) But this is getting beyond the scope of this RfC. ~ J. Johnson (JJ) (talk) 22:12, 18 September 2015 (UTC)
I'm going to try to stay positive here and say that I agree with J. Johnson (JJ) that this particular template field, "website", be deprecated. It does seems to have such an inherent ambiguity that it creates confusion and definitional issues. Since it has to be replaced with something, would it be "work = | publisher = ", as we have for other templates? --Tenebrae (talk) 20:34, 20 September 2015 (UTC)
Thank you. I don't see that |website=, as an alias for |work=, requires any replacement. Where the content of a "website" (in the broader usage) can be taken as a "work" that parameter is still available. I think that not using |work= when it might be applicable is a lesser (and addressable) problem than the misuse of |website=. However, all this is getting into a follow-up discussion. For the purpose of this RfC I think there is consensus that the contents of the |website= parameter, in the scope of its proper and restricted usage, should be italicized. ~ J. Johnson (JJ) (talk) 20:55, 20 September 2015 (UTC)
Oh, for goodness' sakes: No. Italicizing it goes directly against the MOS, which says that website names can be either italicized or not — and so forcing italics, rather than leaving the field open to italicize or not, is contrary to MOS. --Tenebrae (talk) 21:29, 20 September 2015 (UTC)
Wrong. As previously explained (22:55, 15 Sep), and recapped below. ~ J. Johnson (JJ) (talk) 22:30, 21 September 2015 (UTC)
Jeeminy Christmas, no. The MOS absolutely says website names can be either italicized or not. And I even agree with you that it's not subject to individual editors whims. That why I say below that Rotten Tomatoes is not italicized as per WP:FILM consensus and even a citation template at WikiProject:Film. Forcing the field to italicize when the MOS itself says website names such as this example don't have to be italicized goes completely against the MOS. --Tenebrae (talk) 22:50, 21 September 2015 (UTC)
  • Italicize as |work= does. I didn't even know |website= existed until stumbling upon it yesterday, and I still can honestly say I (and perhaps others) do not know when to use |website= over |work=. Assume that they are used interchangeably, and have the format be consistent between them. No prejudice if they are both not italicized, as long as they are consistent.—Bagumba (talk) 22:44, 15 September 2015 (UTC)
  • Summary: I think most (sigh) everyone's understanding is now adequate for the following summary. As the contents of the |work= parameter are titles of "works", which by standard convention are properly italicized, the contents of |website=, being an alias of |work=, and intended for those cases where the contents of a website are deemed to be "works", are also properly italicized. The objections raised here about improper italicization arise from improper use of the parameter for the names of non-works, such as hostnames or names of publishers. This misuse appears to arise from non-recognition of the non-obvious restriction of "website" to a form of title of a work. ~ J. Johnson (JJ) (talk) 20:59, 20 September 2015 (UTC)
  • That Is a False Summary: I take exception to a participant in the discussion, as opposed to a disinterested third party, giving any summary at all, let alone one that favors his personal opinion. Italicizing the "website" field goes directly against the MOS, which says that website names can be either italicized or not — and so forcing italics, rather than leaving the field open to italicize or not, is contrary to MOS. If a field is called "website", then editors naturally assume that any website name goes there. Rotten Tomatoes is a website. But Rotten Tomatoes, as per WP:FILM consensus and even a citation template there, is not italicized. This is just one example of why "website" should not force italics. --Tenebrae (talk) 21:29, 20 September 2015 (UTC)
    The template at the top of all MOS pages begins (emphasis added): "This guideline is a part of the English Wikipedia's Manual of Style. Use common sense in applying it; it will have occasional exceptions." The subject of this discussion can be considered a reasonable exception. AHeneen (talk) 17:14, 21 September 2015 (UTC)
    A "regular" or "expected" exception is an oxymoron. --Izno (talk) 19:10, 21 September 2015 (UTC)
    No. A well-defined exception is a normal part of any process or system description. – Jonesey95 (talk) 19:13, 21 September 2015 (UTC)
    I'm a little confused. By saying an exceptions can be made, are we saying we want to italicize things that should not be italicized? That doesn't really make sense. Rotten Tomatoes and Metacritic, for example, are websites that aren't italicized. So I'm not sure what AHeneen is saying.--Tenebrae (talk) 21:32, 21 September 2015 (UTC)

Comments re misrepresentation, "smokescreening", etc.

I have split off the following comments as they only rehash what has been said above (or in the previous discussion) without adding anything new (to date) on the question of the RfC ("Italics or Non-Italics ..."). ~ J. Johnson (JJ) (talk) 21:34, 7 October 2015 (UTC)

I have qualified my prior comment with most, as one editor keeps going around and around and around like a broken record. Tenebrae: your objections are getting tiresome, even tendentious. To your objection to certain names being italicized when they get stuffed into the 'website' parameter, my simple suggestion is this (are you paying attention?): don't stuff those names into the 'website' parameter. At a slightly higher level you object that "[i]f a field is called "website", then editors naturally assume that any website name goes there." While that is an understandable assumption, it remains a fact that 'website=' is an alias of 'work=', and thus restricted to the latter's use for titles of works, and thus italicized.
Your assertion that all this "goes directly against the MOS" is flat-out wrong, because (as previously explained) you keep forgetting the bit about "depending on the type of site and what kind of content it features." Your Rotten Tomatoes example is rotten because you have not shown that it is the title of a work. Failing that, it does not belong in 'website', and thus is irrelevant. ~ J. Johnson (JJ) (talk) 22:49, 21 September 2015 (UTC)
No. And stop with the name-calling. The only thing tendentious is your suggesting that Rotten Tomatoes is not a website. That's just remarkable. As for " 'website=' is an alias of 'work=' ", that's what this entire RfC is about: whether it's proper for website= to be an alias of work=. And since the MOS says website names aren't required to be italicized, it's improper for it to be an alias of work= and force italicization in the field. If anything, it should be an alias of publisher=, so that if someone wants something italicized in that field, they can always add two quote marks to the beginning and end of the term. What the heavy burden or big deal is to do that, I have no idea. --Tenebrae (talk) 22:57, 21 September 2015 (UTC)
There you go again. Flat-out wrong. Not only have I not suggested (as you state) that "Rotten Tomatoes is not a website", it seems you completely missed where I said that it is a website. (Which statement is likely to confuse you even further, as you quite evidently do not understand the distinction between 1) name of an Internet location containing web content, and 2) name of a work.) As to "what this entire RfC is about", I will quote your very own words when you opened this disucssion: "... should the "website" field italicize the name of websites, in the manner of books or periodicals?". That |website= is an alias of |work= is a given. If you want to discuss whether this is proper open another discussion. ~ J. Johnson (JJ) (talk) 00:08, 22 September 2015 (UTC)
Your double-talk is such that I'm beginning to think you're pranking me and seeing how far you can go before I realize you're pulling my leg.. You said: "Your Rotten Tomatoes example is rotten because you have not shown that it is the title of a work." The field we are talking about is called "website". Whether RT is a "work" or not is irrelevant. The field is not called "work" — it's called "website." So, yes, if you're saying it doesn't belong in the "website" field, you're saying it's not a website. That's obviously ridiculous.
RE: "That |website= is an alias of |work= is a given." It is nothing of the sort. Nothing is a "given". This entire RfC is about whether or not the "website" field should be italicized, and your bringing in irrelevant, extraneous points to create a smokescreen because you like the field to be italicized is just remarkable.
You refuse to address a point I keep bringing up: The MOS says website names can be either italicized or not. So forcing the "website" field to italicize goes completely against the MOS. --Tenebrae (talk) 02:43, 22 September 2015 (UTC)
Wrong again. See below. ~ J. Johnson (JJ) (talk) 20:54, 23 September 2015 (UTC)
What are you, five? I've seen below. You continue to refuse to address the fact that the MOS says website names can be either italicized or not. So forcing the "website" field to italicize goes completely against the MOS. --Tenebrae (talk) 22:21, 23 September 2015 (UTC)
What are you, blind? The MOS does not say "website names can be either italicized or not." (Note the closing full-stop.) It says: "Website titles may or may not be italicized depending on the type of site and what kind of content it features." (Emphasis added.) What part of the qualifying "depends on ..." do you not understand? Oh, sorry, I forgot: none of it. Never mind. ~ J. Johnson (JJ) (talk) 22:41, 23 September 2015 (UTC)
OK, I've tried my best to keep a civil tongue, but your baiting me with insults has just pushed me over the line. I've been a professional writer and editor for over 35 years, and the garbled, verbose, unclear nature of your writing as seen here would never be acceptable in any mainstream periodical. I'm tired of what I now believe is your deliberate dissembling and your ignoring my addressing of your points. I have twice now addressed "depending on the type of site and what kind of content it features" — on Sept. 11 and again today — so just stop your smoke-screening and your arguments that come down to WP:ILIKEIT. I will say it again since you appear slow: "Case-by-case basis" means editors reach consensus whether to italicize or not. So forcing italics is wrong because it's simpler and more intuitive to italicize something that needs italics than to de-italicize something that doesn't. Your ridiculous argument only results in things being italicized that should not be. --Tenebrae (talk) 23:20, 23 September 2015 (UTC)
You consider characterizations like "double-talk", "ridiculous", "what are you, five?", "smoke-screen", and "the garbled, verbose, unclear nature of your writing" (all from you) to be civil?? Not the slightest bit provocative? Attributing your failure to understand to "deliberate dissembling" on my part is not civil (and also violates WP:AGF), nor does it encourage any continuance of a civil discussion. Whether we continune this discussion is another matter. ~ J. Johnson (JJ) (talk) 22:01, 24 September 2015 (UTC)
This discussion seems to be getting a bit personal, which is not helpful. It's simply a fact that at present, |website= is an alias of |work=. Of course, this could be changed and they could be made two separate parameters with different behaviours. But, and it's a big "but", first thousands of uses would have to be checked to see which meaning was intended, since there's no guarantee that editors have used the parameters with different meanings. I can only say that since I know they are aliases, I've not been consistent in which I used. So to this extent, J. Johnson is right to say that the current aliasing is a given. If separate parameters were agreed, then one could indeed be italicized and one not, but this is a different issue. Peter coxhead (talk) 08:14, 22 September 2015 (UTC)
I appreciate your trying to cool the waters. I do have to say I've never heard of any RfC where someone contends we'd have to check "thousands of uses" before we make a change. This RfC is no different than any other, where a consensus is reached among the editors discussing it, and to throw in some clearly undoable obstacle in order to retain the status quo is a bit questionable. You also seem to be saying that "since the website field is italicized currently, then it's a given that it's italicized". That seems a circular argument at best: It's not inherently italicized, as if anointed by God. That's what we're here to decide. And I'm still getting no one to address a point I keep bringing up: If the MOS says website names can either be italicized or not, why should the field force website names to be italicized? The website Rotten Tomatoes, for example, is not italicized, per WP:FILM consensus. Why would we force it to be? --Tenebrae (talk) 13:04, 22 September 2015 (UTC)
Tenebrae, I have addressed the point you keep bringing up, multiple times even. (As well as several other points you keep bringing up.) In your obsession with that bit at MOS:TITLE#Major works you keep quoting only part of it. So here is the whole of it, with the part you keep leaving off emphasized: "Website titles may or may not be italicized depending on the type of site and what kind of content it features." The "or may not be italicized" is not a general permission for individual discretion, it is contingent (depends) on a certain distinction of site and content. There is no "forcing" of italics as use of 'website=' is entirely voluntary. But as you are resistant to understanding any of this further explanation seems futile. Calling my efforts "double talk" only underscores your lack of understanding.
The bottom line here is that a majority of respondents favor italicization. As to keeping "Rotten Tomatoes" (or any other name) non-italic in a citation, there is a very simple solution for you: do not stuff it into |website=. That the established and documented use of this parameter does not conform to your notion of what the general term "website" should cover: that is not what you requested comments on. ~ J. Johnson (JJ) (talk) 21:01, 23 September 2015 (UTC)
  • Sigh*. Anyone who has spent enough time on Wikipedia knows very well that in RfC discussions we don't count "votes" but try to achieve consensus. One third of the respondents here oppose forcing italics in the "website" field. That's a a large enough opposition that we're far from consensus.
And you are I hope inadvertently and not purposefully inaccurate when you claim I haven't addressed "depending on the type of site and what kind of content it features". At 03:33, 11 September 2015, I used those very words: "Wikipedia:Manual of Style/Titles#Major works states, 'Website titles may or may not be italicized [emphasis mine] depending on the type of site and what kind of content it features.' ... it specifically notes, 'Other types of websites should be decided on a case-by-case basis.'" And you can read my analysis of this in that Sept. 11 post, so don't you dare make up false claims and accusations, and dissemble like that.
"Case-by-case basis" means that editors reach consensus whether to italicize or not. You refuse to understand that simple point.
Nor the point that it's simpler and more intuitive to italicize something that needs italics than to de-italicize something that doesn't. You refuse to address the fact MOS says website names can be either italicized or not and so forcing the "website" field to italicize goes against the MOS. Rather, you point to something else in the MOS that I addressed 12 full days ago and claim I didn't address it. Well, I address it once again here. --Tenebrae (talk) 22:36, 23 September 2015 (UTC)
And it is completely disingenuous to claim that most editors will not put a website into the "website" field. Why you want to encourage editors to wrongly italicize (and this is just one example of many) Rotten Tomatoes is incomprehensible to me. --Tenebrae (talk) 22:37, 23 September 2015 (UTC)
Your assertion that I "want to encourage editors to wrongly italicize" is completely false, and I will yet again request that you refrain from misrepresenting my positions. I say that what should not be italicized should not go into the 'website=' parameter. Your argument is that certain names should go into 'website=', and then you are unhappy because it got italicized.
You should note that lack of consensus is not grounds for changing established usage. Where you don't want something italicized, don't use 'website='. No one is forcing you to use it, so all your jabbering about "forcing" of italics is just a red herring. The rest of your comments I reject categorically. ~ J. Johnson (JJ) (talk) 22:11, 24 September 2015 (UTC)
I'm not misrepresenting anything. The field's name is "website". Non-italicized aggregators like Rotten Tomatoes and the Grand Comics Database are websites. If you're suggesting that the average editor doesn't know what "website" means and won't naturally put websites in the "website" field ... wow!!
And how can anyone say that putting something in the current "website" field won't force italics? You've said yourself the field "website=" is an alias of "work=", which automatically italicizes whatever's in the field. "Automatically italicizing" means the same thing as "forcing". Good gracious.
Maybe a consensus solution is this: We change the name of the field from "website" to the extant "work." Boom. No more confusion, no more chance of someone putting a website into "website=" that shouldn't be italicized. --Tenebrae (talk) 22:35, 28 September 2015 (UTC)
In your comment just above (22:37, 23 Sep) you imputed that I "want to encourage editors to wrongly italicize". That is false, and absolutely contrary to everything I have said here; it constitutes a misrepresentation of my views. You have done this several times before. That you do not listen, or perhaps lack the intellectual competency to understand, does not excuse your bad manners, and interferes with any progress in this discussion. And I have had enough. I demand an apology for this and other misrepresentations — Preceding unsigned comment added by J. Johnson (talk • contribs) 02:47, 30 September 2015 (UTC)

Only someone who knows he has no valid argument is going to start insulting another person, since that's a form of misdirection, and you've been smokescreening for most of this discussion. You're clearly so angry that rather than read thoroughly and think straight, you evidently only skim what I've been writing here. I've repeated myself blue in the face, and you still act as if you don't understand. That's just remarkable behavior. And it's typical of someone such as this that that you won't consider or even acknowledge a compromise suggestion but instead insist on some scorched-ground approach. I'm appalled and sad.

Once again: The field's name is "website". Non-italicized aggregators like Rotten Tomatoes and the Grand Comics Database are websites. The average editor who knows the definition of "website" will put websites in the "website" field. Are you following? Now, the "website" field forces italics. I know you understand that. Italicizing websites that should not be italicized goes against the MOS, which allows for italics or non-italics depending on the website. I don't know how to explain it any more simply.

The solutions are simple: 1) make the website field not italicize automatically, so that editors can add the double-quote italic code in order to italicize, or 2) change the name of the field to something other than "website". That way, websites like Rotten Tomatoes and Grand Comics Database can go in a non-italicized field. There is a middle ground unless you simply want to have things your way without reaching reasonable compromise like an adult. --Tenebrae (talk) 03:43, 30 September 2015 (UTC)

That is a very impressive piece of "smokescreening" you have just done, dancing all around and accusing me of the very things you are doing without addressing the fact that you have misrepresented me. Would someone else please step in and explain this to him?
For the record, I quite understand what you are saying. As before (22:11, 24 Sep): I say that what should not be italicized should not go into the 'website=' parameter. Your argument is that certain names should go into 'website=', and then you are unhappy because it got italicized. And as I have also previously said, no one is forcing you to use "website=", so you have no basis for complain when you voluntarily elect to mis-use it. The problem here is that you don't understand (hear) any of this (or the MOS), insisting on your own idiosyncratic interpretations. As long as that condition continues there is no basis for further discussion. ~ J. Johnson (JJ) (talk) 21:56, 30 September 2015 (UTC)
No, again it is you who appears to be purposefully misunderstanding. Once again — and no one else is saying they have trouble following this — the field's name is "website". Non-italicized aggregators like Rotten Tomatoes and the Grand Comics Database are websites. The average editor who knows the definition of "website" will put websites in the "website" field.
I never said anyone "is forcing you to use 'website='", so that's simply a false, straw-man argument. You know very well that editors know the definition of "website", and would have no reason not to put websites into a field named "website". You continue to refuse to address this simple fact. You don't want to discuss it further, fine. The fact you refuse to address this elementary point speaks volumes. --Tenebrae (talk) 20:05, 6 October 2015 (UTC)
Except that I never said that you said anyone "is forcing you to use 'website='." That is what I said, except that you left off the bit about "no one is forcing you...", which constitutes a blatant misquotation of my statement in the immediately preceeding comment. Your denial of having said what no one attributes to you is the very strawman argument that you then attribute to me. As to your "editors know the definition of "website"": that assertion has been questioned, and that issue addressed. Did you forget? ~ J. Johnson (JJ) (talk) 00:12, 7 October 2015 (UTC)
Your comment of 21:56, 30 September 2015: "And as I have also previously said, no one is forcing you to use 'website='..." And as I replied, "I never said anyone 'is forcing you to use "website=" ' ". And that is your smokescreening. I'll explain again: Non-italicized aggregators like Rotten Tomatoes and the Grand Comics Database are websites. The average editor who knows the definition of "website" will put websites in the "website" field. No one is "forcing" them, but the definition of "website" directs them to do so. (And the only time I used the word "force" is saying that the "website=" field is coded to force italics, which it does.)
It's blatantly obvious that "website" is a poor name for the field since it communicates something unintended — and I say this as an editor, journalist and author of over over 35 years. --Tenebrae (talk) 18:53, 7 October 2015 (UTC)

I have repeatedly objected to Tenebrae's misrepresentation of my views, which he has rejected as "smokescreening". Before I take this elsewhere would anyone else care to offer any comments? ~ J. Johnson (JJ) (talk) 21:37, 7 October 2015 (UTC)

And I object to J. Johnson's refusal to respond to my repeated statement that if you call a field "website", editors will put the names of websites in it — whether a particular website should be italicized or not. The field's name is needlessly misleading. If we're going to have a field that forces italics, logic demands it be called something other than "website". --Tenebrae (talk) 19:54, 8 October 2015 (UTC)
Wrong again. I originally addressed this point at 00:18, 18 Sep {"The whole problem here...."). You subsequently raised it at 21:29, 20 Sep, and I responded again at 22:49, 21 Sep. Your premise is false. ~ J. Johnson (JJ) (talk) 01:00, 9 October 2015 (UTC)
  • Sigh*. No. at 00:18, 18 Sep, you say "that if the Rotten Tomatoes website is deemed to be a place/publisher/etc. – and I leave that determination to whoever wants to take it on – then it is not a work, and therefore does not belong in |website=. ... and incidentally: RT is a website, and the publisher is probably Flixter, Inc.). ... The whole problem here seems to come to some editors thinking |website= encompasses all websites, including those that are not "works". (It certainly should not be used for urls.) If this is too difficult for general understanding then perhaps this parameter should be removed."
So it appears we agree that the confusing parameter "website=" should be removed. And when I agree, you turn and disagree. As well, I agree with your statement that "some editors thinking |website= encompasses all websites, including those that are not 'works' ". So we're agreed that editors will place websites into a field called website=, which forces italics, even though not all websites should be italicized (such as Rotten Tomatoes and Grand Comics Database).
Yet that's not addressing the issue, but only the underlying reasons. The issue is: If the field website= forces italics on non-italicized websites, then why do we force that? Would it not make more sense to make the field non-italic and let editors quite easily italicize those websites which need it? --Tenebrae (talk) 05:14, 10 October 2015 (UTC)
No, we do not agree. I said that if the proper use of this parameter was too difficult for general understanding then perhaps this parameter should be removed. Perhaps you missed the conditional nature of "if" and "perhaps"? Would more emphasis and/or highlighting be useful? Or superfluous?
Passer-bys might note that I have opened a report at WP:ANI#User:Tenebrae. ~ J. Johnson (JJ) (talk) 20:46, 10 October 2015 (UTC)
Yes, where other editors commenting disagree with him and his belittling and inaccurate characterization of me and my position. I urge all editors to go read what they have to say, and J. Johnson's defensive reply that those editors must be wrong as well for not agreeing with him.
And his uncivil sarcasm and patronizing tone in his most recent post here aside, editors logically will place place websites into a field called website=. The field forces italics, even though not all websites should be italicized (such as Rotten Tomatoes and Grand Comics Database). So I'm not sure how "website=" is the best of all possible things to call the field. Is there really no other term whatsoever for a field that italicizes, when not all websites are italicized? No other, clearer term whatsoever?--Tenebrae (talk) 18:08, 11 October 2015 (UTC)
No, I believe sarcasm would be more in the nature of noting that your repeated reference to plural "editors commenting" at the ANI, when (so far) there is only one such editor, reflects either a failure to understand the plural form despite 35 years of editorial experience, or a failure to count. But leaving aside any such imputations, the mere existence of such a simple error seems an accurate characterization of your frequently inaccurate comprehension. ~ J. Johnson (JJ) (talk) 20:23, 11 October 2015 (UTC)
Oh, yes, heaven forfend that I skimmed something that needlessly and purely vindictively was taking up my time. Oh, the horror.
But I'm not surprised at such an attitude from an editor who tells others on his talk page: "your delusions tiresome, and your general incivility unwelcome. Please do not waste any more space here on such puerile comments." Despite his use of an incomplete sentence, incidentally, you don't see me accusing him of "a failure to speak proper English." We all know people like this who routinely insult others ... and we know what drives them to do it and how seriously to take them.
By the way, a second editor at the ANI has now taken J. Johnson to task, so "editors" plural is certainly accurate now.
And getting back to the point of this RfC: The MOS plainly states not all website names are italicized in footnotes. Nonetheless, the field "website=" forces italics. So that goes against the MOS and, I believe, common sense. Nonetheless, I suggested a compromise: Change the name of field from "website=" to something more accurate. But some people refuse to ever compromise. And we all know people like that. --Tenebrae (talk) 17:39, 12 October 2015 (UTC)
Actually, looking at my ANI comments again, I said, "As other editors note...." I didn't say as "As other editors note here on this page." So "editors" plural was indeed correct. "[A] failure to count" — wow, another inaccurate and unnecessary personal attack. At least he's not calling me delusional and puerile, as he's done with at least one other editor. --Tenebrae (talk) 17:45, 12 October 2015 (UTC)
Oh, I thought we were talking about sarcasm and what it might look like. (Sorry, but sometimes a little emphasis really is needed to avoid ambiguity.) Certainly my previous comment asking if you had missed the conditional nature of a prior comment hardly qualifies. As to the entirely hypothetical question of whether you can count: I expect you can count, and that your miscount – and despite your ex post facto revisionism it was, at the time you wrote it, a miscount – was only a minor slip. (And possibly no big deal.) What is quite telling here is how you try to justify your statement by invoking an unexpressed condition ("not: here on this page"), yet you are so careless of my explicit (and bolded) "if". As to your other rhetorical devices (specifically the unuseful one of namecalling): I have never called you delusional. Nor even ridiculous, although you have persistently insulted me with that and other disparaging terms. I will call you careless, as that seems amply demonstrated. And seems to be the grounds of most of your complaining. ~ J. Johnson (JJ) (talk) 23:37, 13 October 2015 (UTC)
Oh, please. Would you just listen to yourself. Do you have any idea how you sound? RE: "I have never called you delusional." Who's being careless now? I never said you did — and you know I did not, yet you set up a red herring to take down. You know very well I was referring to your comment to "Pete" here.
But getting back to the point: You don't want to non-italicize a field ("website=") that should not automatically italicize. I disagree, but fine. I am completely puzzled, however, that you won't even address a compromise that, seemingly in line with your own comments, would make sense: Since not all websites should be italicized, calling the field "website=" is inaccurate — and at the very least is not the best, least confusing, most optimal name for the field. I have to wonder why anyone would be so adamantly wedded to that word when a word that suggest italics always would be more accurate.--Tenebrae (talk) 18:12, 14 October 2015 (UTC)
Please stop. Both of you. – Jonesey95 (talk) 03:42, 14 October 2015 (UTC)
I agree with the sentiment. If I could suggest, then, perhaps other editors might comment on the compromise proffered? --Tenebrae (talk) 18:33, 14 October 2015 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Now that the CS1 module revision of a couple of weeks ago has had time to work through all or most of Wikipedia, we can see how many new errors were picked up by the changes. The three categories that saw the most changes were the "missing author" category (due to an error that stopped being detected in a previous revision and is now detected again), the "URL errors" category (in which there is a lot of cruft in the |url= parameter), and the "external links" category.

I'm seeing a large number of articles in Category:CS1 errors: external links that are caused by editors wanting to link |work= or |journal=, or their aliases, to an external URL. The current Help page text for this error condition says:

External link in |<param>=

This error occurs when any of the CS1 or CS2 citation title-holding parameters – |title=, |chapter=, |work= or any of their aliases – hold a properly formatted external link (URL). External links in these parameters corrupt the citation's metadata and can be the source of a variety of other error messages.

To resolve this error, remove external link syntax and put the url in the appropriate parameter (|url=, |chapter-url= etc.).

I have had no trouble fixing this problem when there was an external link in |title= or |chapter=, but I am at a loss as to what to do when there is an external link in |work=, |journal=, or their aliases.

Here are some examples from actual articles:

There are also templates that have links in |work=, such as {{Australian Wetlands Database}}, {{Cite AHPI}}, and {{Cite Monumentenregister}}.

What should our advice be? Should there be a |work-url= or |journal-url= parameter? – Jonesey95 (talk) 03:45, 12 October 2015 (UTC)

My view is that there should never (or almost never?) be the need for an external link in the |work= or |journal= fields. In the first example, the required parameter is |url=http://www.msri.org/attachments/media/news/emissary/EmissarySpring2004.pdf which links to the correct volume of the 'journal'. In the second of your two examples above, the journal link is simply unnecessary – the reference is to the article, not the journal. So in my view the citations should be:
(A few other changes have been made above: separating the fields of |author= and treating "Spring 2004" as a issue indicator not a volume.) Peter coxhead (talk) 09:23, 12 October 2015 (UTC)
Is there a policy or guideline that backs up your view? I'm just asking, not trying to be confrontational. I have a feeling that if I started removing these links, editors would complain that I was removing useful information that was not harming anyone.
I feel like I have seen some guidance that explains that it is OK to link to a larger work if the link serves to explain where the link to the source comes from, but I can't find that guidance now. – Jonesey95 (talk) 14:32, 12 October 2015 (UTC)
Policy doesn't support many of the restrictions in the citation templates. WP:CITEVAR is regularly invoked by editors or groups of editors to defend their right to format references virtually however they like. So I think the real issue is different: what should the citation templates support? I can only say that I see no case for them to support external links to works or journals. If editors want such links, then they can always use manual citations. Peter coxhead (talk) 15:12, 12 October 2015 (UTC)
There is this from Help:Citation Style 1#Work and publisher:
If the "title" is already linked to externally, do not externally link to the "work".
—Trappist the monk (talk) 15:21, 12 October 2015 (UTC)
Suppose that we wish to cite an article in an online newsletter. Suppose also that (as often happens) the whole issue of the newsletter containing the article is available as a pdf file from the publisher's web site, but the individual article is not available as a separate download. Where, in your view, should the url for the issue of the newsletter be linked within the citation? If you rule out links on |work= or |journal=, the only choice is on the article title, but in that case we have a misleading link: readers who click on the link will be expecting the individual article and get something else. —David Eppstein (talk) 00:25, 14 October 2015 (UTC)
You don't have a choice, unless you want to extract the article in question and host it yourself, an activity of dubious legality in many cases. Put the URL for the whole PDF in the |url= parameter, just as we do with a journal article or a report or any other long document, and then use |page= and |title= (and |author=, if applicable) to guide readers to the correct location within the PDF. There is also a PDF linking trick that works with some browsers. – Jonesey95 (talk) 03:48, 14 October 2015 (UTC)
Moved from User talk:Trappist the monk

Per Editor Jonesey95 I have moved this conversation here.

Editor Peaceray posted this on my talk page:

Hi, I have been looking through various Help_talk:Citation_Style_1 discussions in an attempt to understand why having an external link in |work= is now generating an error. I have been populating this parameter with external link for years & just noticed that it now causes an error. It is obvious to me why external links in |title= & in |chapter=, as they conflict with |url= & |chapter-url= respectively. However, there is nothing like a |work-url= for |work= to conflict with. The documentation essentially just says that's the way it is.

I have seen your username all over the discussions at Help talk:Citation Style 1#choosing the correct metadata when |chapter=, |title=, and |work= are all set & Help talk:Citation Style 1/Archive 9#How to resolve external link errors without work-url= or journal-url=?. I am just hoping to get a succinct, coherent explanation why external links in |work= cause a problem.

I am a heavy user of citation templates. I also have been in IT for 25 years & have dabbled in my share of programming languages, so while I may not be familiar with the syntax of modules, I probably get a grasp of a moderately technical discussion.

Peaceray (talk) 21:38, 20 October 2015 (UTC)

You know that the twenty-some cs1|2 templates were created independently. {{citation/core}} was the first real attempt to consolidate them so that they were more stylistically and functionally similar than the original templates. That consolidation is ongoing in Module:Citation/CS1 and is far from complete.

Part of the consolidation that we've accomplished so far is to define a more uniform parameter naming convention. The canonical form of all URL-holding parameters is |<name>-url=. |dead-url= is an exception that still needs to be fixed.

The first mention of any prohibition of external links in |work= and alias parameters, technical or other wise, appears to come with this edit. Those words still exist in Help:Citation Style 1 though not in the same place. There have been requests in the past for the module to flag URLs in |website= because new users confuse |website= with |url=. I'm unable to locate where I read those requests but I am sure that I am not imagining that they were made.

The metadata formatting that cs1|2 uses provides for four general types of citation: book, journal, dissertation, and patent. Our challenge is to somehow shoehorn the twenty-ish cs1|2 templates into those four. In the version of the metadata code that I'm working on now, journal-type metadata are created for:

  1. {{cite arxiv}}, {{cite journal}}, {{cite news}}
  2. {{cite conference}}, {{cite interview}}, {{cite map}}, {{cite press release}}, {{cite web}} when Periodical meta-parameter is set
  3. {{citation}} when Periodical is set but |encyclopedia= is not set

All the rest of cs1|2 create book type except {{cite thesis}} which uses dissertation type. The patent-type metadata are created in the weird hybrid of {{citation}} and {{citation/patent}} and not currently supported by Module:Citation/CS1.

In the creation of the metadata, the value of |work= and aliases (the Periodical meta-parameter) is assigned to the metadata key &rft.jtitle=. That key is defined to be a character string and further defined to be a 'Journal title'.[1] I choose to read that standard strictly, so a URL is not appropriate.

It isn't because of a conflict between |title= and |url= (or the chapter pair). External links in |title= (&rft.btitle=) and |chapter= (&rft.atitle=) have similar metadata definitions so URLs in these parameters are similarly inappropriate.[2]

References

  1. ^ "Matrix defining the KEV Format to represent a journal publication". OCLC. Retrieved 2015-09-27.
  2. ^ "Matrix defining the KEV Format to represent a Book". OCLC. Retrieved 2015-09-27.

—Trappist the monk (talk) 12:33, 21 October 2015 (UTC)

Well, the timing of that edit explains why I was able to go down the path that I did for |work=, since I started 22 months before that, &, as a part-time university reference librarian, definitely read through the citation template documentation of the time as wanted to attend to citations. I probably was obsessive-compulsive about it for awhile & tried to pack as much info in as possible.
Can anyone recommend a semi-automated tool that can help me clean up citations that I made that are now generating this error? I have used WP:AutoWikiBrowser on a couple of occasions for mass changes, but am unsure about its capability for this task.
Peaceray (talk) 22:51, 27 October 2015 (UTC)
AWB can do some very complex things so should be quite up to the task of doing what you want done.
—Trappist the monk (talk) 11:24, 28 October 2015 (UTC)

Protected edit request on 26 October 2015

In your template you omit a category for Paperbacks. e.g. a book is published in New York, but the paperback version in another year is brought out in Greece about the Greek War, but is in English. How do you write to include the same book in paperback in another year and/or language? Category: Language, Year/Date, Hardback/Paperback; Template: Cite book| Justin Grant-Duff 22:45, 26 October 2015 (UTC)

Is this a question about the documentation (that it should give guidance for this case) or a request for a specific change to the template, and if so what change? In any case the usual answer is: cite the edition that you got the information from. If you want to indicate that it's a reprint of a previous edition, we have the |orig-year= parameter for that. We do not have a parameter for the physical details of the binding: whether it is hardcover or softcover, whether it comes in a slipbox or not, whether it is folio, octavo, or some other size, whether the pages are deckled, etc.; why do you think these are important information for a citation? —David Eppstein (talk) 23:10, 26 October 2015 (UTC)
Not done: Marking as not done, as it looks like this isn't a request for an update to the actual template. — Mr. Stradivarius ♪ talk ♪ 23:20, 26 October 2015 (UTC)
@Jgrantduff: There's already a way to indicate what you want. For example, if I wanted to cite the original hardcover edition of a specific book from the library, I'd use:
  • Lewis, Tom (1997). Divided Highways: Building the Interstate Highways, Transforming American Life. New York: Viking. ISBN 9780670866274.
But since I own the paperback Updated edition, instead I'd cite:
  • Lewis, Tom (2013). Divided Highways: Building the Interstate Highways, Transforming American Life (Updated ed.). Ithaca: Cornell University Press. ISBN 9780801478222.
In the latter case though, if they hadn't already specified it as an Updated edition, I could have used |edition=Paperback with the updated year/location/publisher details. Just another pairing to demonstrate:
Imzadi 1979 → 01:42, 27 October 2015 (UTC)
@Jgrantduff:: If it's not clear from the above examples, use the {{cite book}} template twice, once for each edition, if you are listing all of the editions of a book. If you are citing a source, cite only the edition that you have seen with your own eyes. See WP:SAYWHEREYOUREADIT for a full explanation. – Jonesey95 (talk) 02:54, 27 October 2015 (UTC)

Proposal for more detailed parameters than the catch-all others= parameter

I would like to propose alternative and more detailed parameters to the |others= parameter, which is currently a "catch all other contributors" parameter. If the |?-first= and |?-last= parameters are used in the remainder of the citation, they cause author and editor names to occur in the order "last, first" by default. It looks odd, if additional contributors listed under |others= still occur in the order "first last". Specifically, I propose the following optional new parameters for illustrators, correctors/pre-publish-reviewers, printers, translators and other contributors (where [?] is an optional number):

|illustrator-first[?]= |illustrator-last[?]= |corrector-first[?]= |corrector-last[?]= |printer-first[?]= |printer-last[?]= |translator-first[?]= |translator-last[?]= |contributor-first[?]= |contributor-last[?]=

At a (much) later stage, the |others= parameter could be deprecated. I'm well aware of the fact that these parameters will remain empty in most citations, but in those cases, where the information is known and presented in the book, it would be very useful to have some more organized means to include the information than possible at present. This would also help to make meta-data parsing more reliable in the future. --Matthiaspaul (talk) 15:53, 13 October 2015 (UTC)

We have |translatorn=, |translator-firstn=, |translator-lastn=, |translator-linkn=, and |translator-maskn=. These were added in a recent update because over the years they have been identified as something that editors wanted. I don't recall seeing similar desire for any of the others. We might alias |contributor= to |author= and we might add |illustrator= if there is sufficient need. How does knowing the 'corrector's' name or the 'printer's' name help readers find a copy of the cited work?
Is there something inherently wrong with keeping the catch-all |others= parameter?
Because |others= is free-form, names can be added to it in last, first order. On the other hand, there are those who believe that only the primary author should be listed last-name-first and all others shold be listed first-name-first.
—Trappist the monk (talk) 17:11, 13 October 2015 (UTC)
Thanks for the hint! I wasn't aware of the |translator= group of parameters, they are not currently documented (except for the |translator-mask= parameter.
Regarding the other parameters, I don't see their main purpose in helping to locate a citation, although in some cases (f.e. with strangely formatted historical sources) they might actually help in doing so. The main purpose, as I see it, would be to help build the web and aid further research into a subject. For example, mentioning the various kinds of contributors specifically and in a standardized way would allow for much easier reverse lookup of information. This can be useful when evaluating sources in their historical context, and might reveal collaborations and connections otherwise remaining "hidden".
Regarding changing the order of names in |others= manually. Sure this could be done, but the appearance of citations might change over time as fashions and habits change (think of Wikipedia ten or twenty years in the future). Separate parameters for first and last names allow to change the visual representation of a citation without manually changing the physical wikitext again. At some point in the future it might become possible to select the preferred format of citations or set filter masks in Wikipedia's user configuration (or external "frontends"). So, better to allow editors to provide the information in a universal format right from the start (and with the source still in front of them) than having to manually edit uncountable citations later on (without neither the sources or the original editors at hands to clear up possibly arising questions).
--Matthiaspaul (talk) 22:32, 13 October 2015 (UTC)
I have no problem finding the |translator= documentation at {{cite book}}, {{cite journal}}, {{cite news}}, and {{cite web}}. Where are you looking that you only find documentation for |translator-mask=?
I don't know that build[ing] the web is in the cs1|2 remit. Perhaps that is better left to the time when (if) cs1|2 is somehow integrated with wikdata.
There are editors who have railed loudly against separate first and last parameters for author names. WP:MED uses |vauthors= preferentially to avoid the 'clutter' of last/first parameters.
—Trappist the monk (talk) 23:58, 13 October 2015 (UTC)
Regarding (missing) documentation, see: Help:Citation_Style_1
--Matthiaspaul (talk) 08:01, 16 October 2015 (UTC)
Ah, yes that page. I don't know what to say about that page. It is a mix of stuff that rightly belongs there and stuff that is better left to the template pages. In the best of all possible worlds we would blank the page and start over.
—Trappist the monk (talk) 11:18, 16 October 2015 (UTC)
I think, the main purpose of the cite templates is to reliably identify and locate a source, but it serves other purposes as well. We even have a range of parameters (like |lay-summary= and friends) helping readers to decide if a source might be interesting at all and worth some further study. In comparison, listing contributors is much more closely related to the original descriptive purposes of the source, but it might also help to pre-evaluate a source.
That's why I think there should be a way to more formally define how this info can be presented than putting it all into the "one-size-fits-all" parameter |others=.
I don't know if this information would ever become part of exported metadata, but if that would be desirable somewhen in the future, certainly it'll be easier to extract and process the info from separate parameters than trying to make sense of a string lumping it all together in the |others= parameter.
--Matthiaspaul (talk) 18:07, 29 October 2015 (UTC)

Suggestion: maintenance or error category for characters that do not belong in any citation template

This is a suggestion for a new maintenance or error category that could be created when characters are detected in citations that should not be in any citations. I'm thinking of various hidden characters and the � (question mark inside a diamond, character U+FFFD) that sometimes show up in Wikipedia articles because of copy-pasted text with hidden characters or characters that failed a transition from one character set to another. There may be a list of these undesirable characters in AWB's general fixes or somewhere else in a WP cleanup script. – Jonesey95 (talk) 01:26, 2 October 2015 (UTC)

Basically the "no such character" characters, right? Sounds good. ~ J. Johnson (JJ) (talk) 22:16, 2 October 2015 (UTC)
Are there other "no such character" characters? What other legitimate characters? Zero-width space? Soft hyphen? What about Non-breaking space?
—Trappist the monk (talk) 00:29, 3 October 2015 (UTC)
I suspect that there is a list of them somewhere, possibly in the AWB source. I have one in line 20 of User:Jonesey95/AutoEd/doi.js that shows up in copy-pasted DOI values sometimes. You can't see it, but it's there and it causes a DOI validation error.
The character in line 20 of your script is the Zero-width space.
—Trappist the monk (talk) 01:39, 3 October 2015 (UTC)
This MOS section may provide some guidance. – Jonesey95 (talk) 01:30, 3 October 2015 (UTC)
Wikipedia:Manual of Style/Text formatting#Private Use Area and invisible formatting characters?
—Trappist the monk (talk) 01:42, 3 October 2015 (UTC)
Here's a possible solution for three of the characters:
  • Title with � character. {{cite book}}: replacement character in |title= at position 12 (help)
  • Lorem​Ipsum with ZWS. {{cite book}}: zero width space character in |title= at position 6 (help)
  • Margaret­Are­You­Grieving with SHY. {{cite book}}: soft hyphen character in |title= at position 9 (help)
The test loops through all of the parameters in a template and tests each for all three. If a 'bad' character is found in a parameter, subsequent tests are not performed on that parameter. Is there a better error message? Yes, it needs proper formatting, I'll get to that.
  • Lorem​Ipsum. Margaret­Are­You­Grieving with SHY. {{cite book}}: soft hyphen character in |title= at position 9 (help); zero width space character in |author= at position 6 (help)
—Trappist the monk (talk) 12:50, 4 October 2015 (UTC)
Expanded a bit so that the test finds most of the C0 and C1 control characters
  • Lorem Ipsum with HT. {{cite book}}: horizontal tab character in |title= at position 6 (help) – a horizontal tab (might be best to split HT, LF, and CR into separate test)
  • U+008F between dots .. {{cite book}}: C1 control character in |title= at position 22 (help) – SS3 (single shift three)
  • Lo�rem Ipsum with BEL. {{cite book}}: replacement character in |title= at position 3 (help) – either Lua or mediawiki replace most C0 controls with the replacement character when the citation is rendered so the test for the replacement character thinks that the string is good.
{{cite book/new |title=Margaret
Are
You
Grieving}}
  • Margaret Are You Grieving. {{cite book}}: line feed character in |title= at position 9 (help) – each word of the title is on a different line
—Trappist the monk (talk) 13:17, 5 October 2015 (UTC)
I don't think there is anything wrong with having tab characters or line breaks in citation parameter text, as long as they do not break the rendered citation. People are used to the idea that white space of various sorts is rendered as a single space, and in this case, it looks to me like a case of "it ain't broke, so don't fix it". – Jonesey95 (talk) 14:09, 5 October 2015 (UTC)
Removed, but I'm not sure that they should be. The undetected and so uncorrected C0 control characters are included in the metadata. Here is the multi-line Margaret Are You Grieving example:
'"`UNIQ--templatestyles-0000022C-QINU`"'<cite class="citation book cs1">''Margaret Are You Grieving''.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Margaret+Are+You+Grieving&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+9" class="Z3988"></span> <span class="cs1-visible-error citation-comment"><code class="cs1-code">{{[[Template:cite book|cite book]]}}</code>: </span><span class="cs1-visible-error citation-comment">line feed character in <code class="cs1-code">&#124;title=</code> at position 9 ([[Help:CS1 errors#invisible_char|help]])</span>
Something else has changed. When I first wrote it, the Lo�rem Ipsum with BEL test above did not render with the replacement character and showed the correct C0 controls error message. Now I can't insert the BEL character (or any other C0 control) without it is replaced. I'll leave the test in the code.
—Trappist the monk (talk) 12:12, 6 October 2015 (UTC)
Because of the metadata issue, I have restored HT, CR, and LF detection. Also added Unicode Private Use Areas detection:
Margaret AreYou Grieving.
Margaret Are󰃿You Grieving.
Margaret Are􀃿You Grieving.
—Trappist the monk (talk) 11:41, 10 October 2015 (UTC)

I just found this character:  in George Mason. I don't know what it is, but I don't think it has a use in citation templates.

Example template using the sandbox: George  Mason.

Looks like it is not part of the character groups we are searching for yet. – Jonesey95 (talk) 15:09, 24 October 2015 (UTC)

U+FFFC, object replacement character, part of Specials (Unicode block). Now detected.
—Trappist the monk (talk) 15:30, 24 October 2015 (UTC)

I have given this group of errors an error message that fits in form and function with the other error messages that cs1|2 emit. The error category is Category:CS1 errors: non-printable characters.

I have also tweaked the detection code a bit because, formerly, it used a for char, pattern in pairs (cfg.nonprint_chars) do construct. While that works, the order of the values returned by pairs () is arbitrary. By tweaking the code to start at the top of cfg.nonprint_chars and work down, we can check first for single characters (the replacement character for example) that are also members of the larger set of characters detected later (replacement is a member of Specials).

—Trappist the monk (talk) 16:57, 30 October 2015 (UTC)

Template:Cite journal

Accordingly, "This Citation Style 1 template is used to create citations for articles in magazines, journals, newsletters, and for academic papers." Is this only true for printed articles? For instance, not all news articles on Billboard got covered on the magazine's print version. Should we use cite news instead of cite journal? Another. Should we use cite journal for this chart history?--Efe (talk) 20:44, 10 October 2015 (UTC)

The term "journal" is ambiguous. It can mean any periodical loosely (see Journal), but tends to be used more in the sense of scientific journal or academic journal. Given the existence of {{cite news}} and {{cite magazine}}, I think {{cite journal}} should be more narrowly restricted. Even though the initial sentence there is permissive, a narrower usage seems preferable, as otherwise there is a suggestion of greater authority than may be warranted.
As to to situations where a newspaper or magazine have both print and on-line versions, which are not entirely identical, it might be useful to restrict 'cite news' and 'cite magazine' to the print version, and use 'cite web' for the on-line version. Come to think of it, some journals also have "enhanced" editions on-line. Hmmm, I think this question just flooded my waders. ~ J. Johnson (JJ) (talk) 22:27, 10 October 2015 (UTC)
Use what you think makes sense. {{cite web}} is fine for pretty much anything that appears on the web.
Note that {{cite magazine}} is an alias for {{cite journal}}.
P.S. I have fixed the grammar in the sentence quoted above. – Jonesey95 (talk) 00:12, 11 October 2015 (UTC)
Hello. Thanks for the clarification. --Efe (talk) 14:40, 11 October 2015 (UTC)
I have tweaked that initial sentence. Hopefully that is a smidgin closer to perfection. ~ J. Johnson (JJ) (talk) 00:13, 14 October 2015 (UTC)
Is this allowed: cite magazine |magazine= cite newspaper |newspaper? I personally do not support the idea of using cite journal for magazines such as Billboard. Thanks. --Efe (talk) 12:41, 31 October 2015 (UTC)

ISBN formats 10 and 13

A book I own has 4 ISBNs listed inside the cover and I am not sure which to use. Two say "bound" and the two say "paperback". The cover feels smooth and from my experience with RPGs I believe it is bound so I'll probably go with that half...

The other problem though is that there is also division into either "ISBN-10" and "ISBN-13". I am not sure which of the two we use. The ISBN-13s begin with 978- while the ISBN-10s begin with 1- and Template:Cite book includes examples of both. How do you choose which is appropriate? Ranze (talk) 04:36, 23 October 2015 (UTC)

When you have a choice between 10- and 13-digit ISBNs, choose the 13-digit.
—Trappist the monk (talk) 10:14, 23 October 2015 (UTC)
I agree, but also when you have a choice between 10- and 13-digit ISBNS, there is no difference in the information content provided by the two numbers. So you're not losing anything by only including the 13-digit one. —David Eppstein (talk) 18:24, 29 October 2015 (UTC)
Yes, if the choice is only one or the other. But is there any harm in having both? E.g.: if a book that originally has only a 10-digit ISBN is reprinted with addition of 13-digit ISBN, someone with the original might not recognize it if only the 13-digit ISBN is given. Same thing where identical content is published with different covers. So why not include all of the ISBNs? ~ J. Johnson (JJ) (talk) 22:32, 29 October 2015 (UTC)
With the same argument, you should add all the ISBN numbers as books routinely have more than one ISBN number and upwards of 10 and this doesn't include different versions of books. Primary purpose of the ISBN number is to find the book. As the 10 and 13 digits are identical, only one is fine. A few countries have already run out of 10-digit numbers and are only issuing 13-digits. Bgwhite (talk) 06:58, 31 October 2015 (UTC)
Yes, but here we are bridging two kinds of cases. In the first case the source is simply an editor's source, and WP:SAYWHEREYOUGOTIT applies. Here I would argue for inclusion of only the ISBNs applicable to that specific source. But if the intent is to enable other editors and readers to find any/all editions, then, yes, it might be reasonable to list ten or more ISBNs. Not that it happens very often.
Incidentally, as the templates take only a single ISBN (the others have to be suffixed to the citation using {{ISBNT}}) I think the 13-digit ISBN should be preferred. ~ J. Johnson (JJ) (talk) 22:51, 31 October 2015 (UTC)

Pages using citations with format and no URL

Pershing missile bibliography is in Category:Pages using citations with format and no URL. I enabled the error message but I still don't see what is wrong in that article. --21lima (talk) 14:54, 31 October 2015 (UTC)

One citation had |url= and |chapter-format=. Kanguole 15:12, 31 October 2015 (UTC)
Thanks. |chapter-format= does not generate an error message: (chapter-format). title. {{cite book}}: |chapter-format= requires |chapter-url= (help) --21lima (talk) 15:31, 31 October 2015 (UTC)

Because the cite used {{cite journal}}, |chapter= is not part of the rendered display. When |chapter-format= is set, it is error checked and if there is no |chapter= (or alias) then an error message is added to the content of |chapter-format= and an error category is added to category list. Because this cite is {{cite journal}}, all of the chapter parameters (except |chapter-format=) are set to empty strings and |chapter-format= is simply ignored.

I have modified the sandbox so that meta-parameter ChapterFormat is not error checked for cs1|2 templates that don't support chapter parameters. Instead, ChapterFormat is checked for content and if set, the parameter-ignored-error-message and category are added to the rendered output.

Cite journal comparison
Wikitext {{cite journal|author=Shi-Xue Tsai|chapter-format=PDF|others=SCITRAN (trans.)|publisher=[[National Air Intelligence Center]]|title=Introduction to the Scene Matching Missile Guidance Technologies|url=http://www.dtic.mil/cgi-bin/GetTRDoc?AD=ADA315439}}
Live Shi-Xue Tsai. "Introduction to the Scene Matching Missile Guidance Technologies". SCITRAN (trans.). National Air Intelligence Center. {{cite journal}}: |chapter-format= ignored (help); Cite journal requires |journal= (help)
Sandbox Shi-Xue Tsai. "Introduction to the Scene Matching Missile Guidance Technologies". SCITRAN (trans.). National Air Intelligence Center. {{cite journal}}: |chapter-format= ignored (help); Cite journal requires |journal= (help)

This change also fixes an ignored parameter bug where a parameter's name is left out of the error message:

Cite journal comparison
Wikitext {{cite journal|journal=Journal|script-chapter=Script-Chapter|title=Title}}
Live "Title". Journal. {{cite journal}}: |script-chapter= ignored (help)
Sandbox "Title". Journal. {{cite journal}}: |script-chapter= ignored (help)

For {{cite book}} and other non-periodical cs1|2 templates that do support |chapter= and aliases and related parameters, the extant code ignores the chapter-format-requires-url error message because ChapterFormat (which has the error message) is not concatenated onto Chapter. I have changed the code so that Chapter gets the value of ChapterFormat when set:

Cite book comparison
Wikitext {{cite book|chapter-format=chapter-format|title=title}}
Live (chapter-format). title. {{cite book}}: |chapter-format= requires |chapter-url= (help)
Sandbox (chapter-format). title. {{cite book}}: |chapter-format= requires |chapter-url= (help)

—Trappist the monk (talk) 16:57, 31 October 2015 (UTC)

That makes sense. --21lima (talk) 14:37, 1 November 2015 (UTC)

What to use?

Sorry. I must have been confusing myself. Anyway, this is where I should probably ask for guidance. What to use for the following materials found on the website of, for instance, The Guardian, a British national daily newspaper? Such materials may or may not be found on the print version.

Appreciate advice. Thanks. --Efe (talk) 13:01, 31 October 2015 (UTC)

{{cite news}} or {{cite website}} can be used to cite a news source in all of those cases, though most at this page usually tend to prefer Cite news since it is more semantic to the type of source being cited (regardless whether the source was printed online or offline). Example: {{cite news |url=http://www.example.com |publisher=The Guardian |title=Example Title |date=October 31, 2015}} generates "Example Title". The Guardian. October 31, 2015. In the case of an interview, I would probably tend toward using {{cite interview}} instead, since I don't think {{cite news}} can handle the interviewing piece of it. --Izno (talk) 13:23, 31 October 2015 (UTC)

The confusion (of mine) arises in those cases. It is more on the source (The Telegraph), or the material (album review) being cited? --Efe (talk) 13:28, 31 October 2015 (UTC)
The material, in the general case. We don't have anything like a "cite album review" since album reviews will generally be found on a website or in a magazine, for which we have {{cite magazine}} (with optional |url=) and {{cite website}}. --Izno (talk) 13:48, 31 October 2015 (UTC)
Hi Izno, apparently I came here because there seems to be a restrictive use of templates. For instance, if it's coming from Billboard, the {{cite journal}} was used throughout a given article. Although MOS stipulates that uniformity of style should be achieved. So, for clarification, I'm using the following examples all from Billboard site:
Am I close to being proper? --Efe (talk) 18:23, 31 October 2015 (UTC)
You can use {{cite web}} for basically any web-based source and no-one will bat an eye. Generally, the guideline "same citation style" extends only to how you format the citations at a broad level and not usually whether a specific template in the CS1 family is the correct template. on As I have already said, you should prefer a more specific type of template if you can. --Izno (talk) 12:47, 2 November 2015 (UTC)

non-English in date parameter

Not sure if BattyBot or one of the other bots fixes these.... Content Transcrapulator doesn't translate the contents of |date=, if it translates the cite template at all. Does the bots fix |accessdate=13 de diciembre de 2013 or if the cite template wasn't translated at all, ie |fechaacceso=13 de diciembre de 2013? Bgwhite (talk) 08:17, 2 November 2015 (UTC)

I think that the |accessdate=13 de diciembre de 2013 is the sort of thing that BattyBot 25 is intended to fix; don't know about the other. When I looked in the script for the terms diciembre and fechaacceso I didn't find them. What is Content Transcrapulator?
—Trappist the monk (talk) 11:18, 2 November 2015 (UTC)
There is no bot that fixes |fechaacceso=, but I clean out the "unsupported parameter" category almost every day. Once I turn that parameter into |access-date=, BattyBot will find and fix the dates.
BattyBot Task 25 will find and fix dates in Spanish and many other languages. The key line is here:
ArticleText = Regex.Replace(ArticleText, @"(?i){{(\s*[Cc]it(?:e|ation))([^}]+)(\s*\|\s*archive-?date\s*=\s*\d{0,2}[\.,]?\s*)(?:(?:de )?(?:de[csz]embr[eo]|d[éi]ci?embre)(?: del?)?|d?e[csvz]m?e?w?mn?e?b+[ae]?r?|d[ec]+mber|decembrie|Decembwe|Disember|grudnia|декабря|декабрь|Декември|децембар|aralık|grudzien|prosinec|Rhagfyr),?\s*(\d{0,2}(?:st|nd|rd|th)?,?\.?\s*\d{4})(?:\s*г(?:ода|\.?))?,?(\s*[\|}<])", "{{$1$2$3December $4$5");
Very clever BattyBot. It runs about once a month.
"Content Transcrapulator" is Bgwhite's affectionate name for the beta "Content Translation" gadget that a few of us gnomes clean up after. It has a few bugs, like any beta software. – Jonesey95 (talk) 14:02, 2 November 2015 (UTC)
BattyBot maybe clever, but GoingBatty is a genius for creating it. Sorry, but Content Transcrapulator is not beta quality. It is horrid. But what makes it worse is all the new editors, who don't know English, creating articles. Bgwhite (talk) 20:12, 2 November 2015 (UTC)
@Bgwhite: Thanks for the kind words. BattyBot 25 will fix dates in many date parameters, it doesn't fix |fechaacceso=, because AWB's order of procedures runs the custom module before replacing template parameters. I haven't run that task in a while, so I'll do it soon. Thanks for the reminder. GoingBatty (talk) 03:37, 3 November 2015 (UTC)

last-author-amp change

For some reason this parameter is now reporting as invalid if the value is 1, as I've been using in hundreds of articles. Changing the value to y makes it display properly. Looking at the documentation any value should work, including 1. What has happened?--Sturmvogel 66 (talk) 23:01, 26 September 2015 (UTC)

Good catch. I updated the documentation. This changed today; some parameters that had previously been lax about checking for appropriate values have been made more strict. One of the friendly gnomes here, maybe me, will be sweeping through with a script to update all of those "1" values. – Jonesey95 (talk) 23:22, 26 September 2015 (UTC)
Paging GoingBatty or someone else with access to AWB and some time on your hands. Do a search for insource:/\|\s*lastauthoramp\s*=\s*[1&]/ to see a list of between 750 and 1,000 articles containing values of "1" or "&" for |lastauthoramp=. – Jonesey95 (talk) 01:30, 27 September 2015 (UTC)
@Jonesey95: BRFA filed. GoingBatty (talk) 12:29, 27 September 2015 (UTC)
While you were doing that I hacked a simple script to fix those |last-author-amp= parameters with something other than yes-true-y and remove |last-author-amp=no and |last-author-amp=n and that were in Category:CS1 errors: invalid parameter value.
Find: \|\s*last\-?author\-?amp\s*=\s*(?:no|n) Replace: with nothing
Find: \|\s*last\-?author\-?amp\s*=\s*[^\s\|\}]*([\s\|\}]+) Replace: |last-author-amp=yes$1
—Trappist the monk (talk) 13:04, 27 September 2015 (UTC)
Nice. I've done a few dozen with an AutoEd script, but (a) 1,000 or so is more of a bot task, and (b) the errors are trickling into the category slowly, so if we can go find them before the red error messages show up for readers, that is a better approach. – Jonesey95 (talk) 14:57, 27 September 2015 (UTC)

I asked this on the BRFA, and was suggested by Batty to repeat it here: Why do we need to make the parameter more strict? Some users are likely to continue to use the old values; can't we leave in support for it but have the alternate values be undocumented? Thanks. — Earwig talk 22:38, 27 September 2015 (UTC)

See this discussion and the discussion that preceded it. We had a number of parameters that were documented inconsistently and that functioned inconsistently and, sometimes, counterintuitively. For example, setting |last-author-amp=no would give you an ampersand before the last author, even though you thought you were asking to the ampersand to be suppressed. On the other hand, setting |subscription=no worked as expected. We made these parameters work consistently.
Because some of the parameters' documentation instructed editors to use any value to make the parameter work, we are cleaning up these now non-standard usages to preserve the editors' intent. – Jonesey95 (talk) 23:10, 27 September 2015 (UTC)
Thanks, this helps clarify things. — Earwig talk 01:26, 28 September 2015 (UTC)

contribution= rather than others=

A book may have main authors and other contributors such as the author of a preface or introduction. They should display as something like

Smith, John; Doe, Jane (preface); Bloggs, Fred (illustrator) ...

At present, the other contributors are given in the free-form |others= area. No COinS metadata is generated for the other contributors, and it is probably not practical to generate metadata, because the |others= field tends to be a grab-bag for any other information that seem relevant, such as details of reprints, explanation of publication circumstances, whatever.

One approach that looks o.k. is to put the other contributors in the |author# list, with the role in parentheses:

|author1=Smith, John |author2=Doe, Jane (preface) |author3=Bloggs, Fred (illustrator)

The result looks o.k., but messes up the metadata. A possible solution would be a new set of parameters, |contribution#, whose value would show in parentheses after the author name, or first name:

|author1=Smith, John |author2=Doe, Jane |contribution2=preface |author3=Bloggs, Fred |contribution3=illustrator

This would give the right visual appearance and generate the metadata. It could also eliminate the need for the |editor= family of parameters, since editing is just a type of contribution.

Comments? Aymatth2 (talk) 16:29, 30 October 2015 (UTC)

"The best is the enemy of the good" applies here, I think. We can go on making the citation templates more and more complex to allow for every possible case, but this just makes them harder to use and more error-prone (|contribution= has an existing, different meaning; non-matching numbered parameters are a common source of error). Peter coxhead (talk) 17:02, 30 October 2015 (UTC)
This would more difficult, not less difficult, for editors, and |contribution= is already a valid parameter used for something else. – Jonesey95 (talk) 20:24, 30 October 2015 (UTC)
A contributor is not a contribution. The latter is typically used for a source, such as a paper, that was contributed to some larger work, not what an individual author contributed. If such individual contributions really warrant mention then I suggest adding them parenthetically after the first name. E.g.: "|last3=Bloggs |first3= Fred (illustrator)".
Note also that editing generally is not a form of contribution. ~ J. Johnson (JJ) (talk) 22:23, 30 October 2015 (UTC)
Adding them as part of the value of a firstN parameter will pollute the metadata, though I suppose a final parenthesized part could be stripped off. Peter coxhead (talk) 22:31, 30 October 2015 (UTC)
Anything like "|author3=Bloggs, Fred" pollutes the metadata, too. If the "last" name (which is important for bibliographic purposes) is good I am less concerned about the first name. First names tend to be squishy anyway. ~ J. Johnson (JJ) (talk) 23:13, 30 October 2015 (UTC)
I don't think this level of detail is appropriate for a reference. Citing an invited foreword in a book by another author is a different matter, to which we unfortunately don't have a good solution. There's a similar problem when a book by some author includes a chapter by another author that we want to cite – we have no way to distinguish the author of the contribution from the author of the book – calling the latter an editor would be inaccurate. But there's no need to say who wrote the foreword if we're not citing text from it. Kanguole 23:18, 30 October 2015 (UTC)
  • The suggestion of "contribution" as the parameter name seems to have been unfortunate. I first thought of "author-type" but it seemed clumsy. Maybe "role" works. The author, editor, illustrator, translator, prefacer etc. all play roles in making the book.
|author1=Smith, John |author2=Doe, Jane |role2=preface |author3=Bloggs, Fred |role3=illustrator
  • If accepted, the new structure would reduce complexity by letting us remove all the "editor" parameters, which mirror all the "author" parameters. After the change had settled in, with the "editor" parameters deprecated, a bot could run through the cites replacing them, e.g. "|editor-last2=Smith" becomes "|last3=Smith|role3=editor". This would be a significant reduction in complexity and a significant gain in flexibility, since other types of contributor could now be identified and generate metadata.
  • The name should be given as precisely as possible to make the COinS metadata as useful as possible to external applications. See Template:Cite book#COinS – "As a general rule, only one data item per parameter. Do not include explanatory or alternate text." That is, do not code "|first=John (preface)".
  • Digression:
The concept of first and last names is mostly used in European-origin cultures. It is preferable to identify them where known, as
|last=León y Pizarro |first=José García de
In most of Asia, the family name is followed by the given name. "Xi Jinping" is "President Xi", a member of the Xi family. It seems quite confused to use:
|last=Xi |first=Jinping
Issa Ahmed Mohammed, who has no family name, can only be cited as
|author=Issa Ahmed Mohammed
Patxo Unzueta has a first and last name, but I do not know which is which. When in doubt, "|author=" is safest.
  • Sometimes the preface and commentary may be what are most important: the Pale Fire effect. I come across this quite often with books of "collected writings" by the subject of the article, which may include letters, diary entries and so on. The writings are primary sources, best used sparingly, but the commentary is a legitimate source. An Icelandic saga would be similar: the author of the saga may be unknown, but the author of the notes and commentary is important.
Assuming the parameter set is called |role=, or something, any other comments? Aymatth2 (talk) 01:07, 31 October 2015 (UTC)
If you wanted to use something like |role= to replace the |author= and |editor= parameters, it would take a major rewrite of the citation module code. If someone wants to take on that rewrite in a separate sandbox and then show us how it works, including all of the existing formatting and error checking, that would be impressive. – Jonesey95 (talk) 13:51, 31 October 2015 (UTC)
  • The idea is not to replace the |author= family of parameters but to supplement them.
  • Leave the existing parameters unchanged
  • Add |role=, |role1=, |role2= etc.
  • Where present, the value of the |roleN= parameter would be given in parentheses after the corresponding |authorN= or |firstN=
|last3=Smith|first3=John|role3=translator would generate Smith, John [translator]
  • The |roleN= parameter value would also be written as COinS metadata, e.g. rft.aurole=translator
This does not seem like a huge change. Later stages would be:
  • Change the documentation to deprecate the |editor= family of parameters, with |author= and |role=editor to be used instead
  • Develop a bot to run through articles changing to the new style
  • Cut out the code for the |editor= family, maybe, some day...
The job is far from trivial but simplifies the citation templates considerably and supports much more structured data. Aymatth2 (talk) 15:07, 31 October 2015 (UTC)
&rft.aurole is not supported by the metadata standard.
I'm not sure that |rolen= is necessary. The purpose of a citation template is to render in standardized format enough information for a reader to locate the source; it is not to give credit to every person who at some point in the process touched the author's work. cs1|2 should not be in the business of mimicking Hollywood film credits – we don't need to know the name of the caterer's assistant.
A more useful task I think, is to specify a method by which we can cite a foreword by someone other than the work's author(s) as was mentioned above.
—Trappist the monk (talk) 19:16, 31 October 2015 (UTC)
Aymatth2: I think you have missed the significance of "editors" not being any kind of "author". Authors have original and primary responsibility for whatever they have produced at the level of a book or article. Where editors assemble a set of such books or articles they may lean on the authors, but their responsibility is at a different level. It is not just incorrect to mingle these two different levels, it would be seriously misleading, and against all established citation practice. Elimination of the various "editor" parameters is quite unlikely to happen.
You are correct (and not just as a COinS rule, but as general rule) of "only one data item per parameter". That is also why I believe in splitting the family name (or surname, our so-called "last" name) from the personal or "first" name (and I believe everyone here understands those distinctions): the last/surname is very important for lexicographical ordering, the first/personal name not so much. If the specific roles or responsibilities of any of the authors are so important that they deserve mention then I suggest stuffing it into |firstN=. But I concur with Kangoule that "this level of detail is appropriate for a reference", and with Trappist that it is not the purpose of citation "to give credit to every person who at some point in the process touched the author's work."
I agree with you that sometimes "the preface and commentary [or other material] may be what are most important". But note that a collection of someone's writing is usually credited – as a collection – to the editor/compiler, and this generally includes any commentary. If you want to cite something like a foreword then you use the "in" form. E.g.: Tom Smith, "Foreword", in Robert Brown, Autobiography. There are no COinS fields for Smith because if go to your local library what you will be looking for is Brown's book. Perhaps that suffices for your needs? ~ J. Johnson (JJ) (talk) 22:38, 31 October 2015 (UTC)

To some of the points above:

|last=Green|first=Jane|editor-last=Smith|editor-first=Fred
we enter
|last=Green|first=Jane|last2=Smith|first2=Fred|role2=editor
There is one less parameter to remember and much more flexibility. What is the downside? Aymatth2 (talk) 01:16, 1 November 2015 (UTC)
  1. Yes and no. Yes, you 'could' cite a preface as a chapter and cite the preface's author but it is unlikely, is it not, that the book will be cataloged under the preface author's name?
    • I often use {{cite book}} to define a section in a book such as a preface, chapter or encyclopedia entry with its author for citation purposes. It is important to give credit to the author and avoid plagiarism if at all practical. I am obsessive enough that if an entry is signed with initials, I try to track down the corresponding name. For a recent clumsy example see Jacques-Guillaume Legrand#Sources:
    Landon, C. P. (1809). "Notice sur Legrand". Essai sur l'histoire générale de l'architecture: pour servir de texte explicatif au recueil et parallèle des édifices de tout genre, anciens et modernes, remarquables par leur beauté, leur grandeur ou leur singularité par J. G. Legrand (in French). {{cite book}}: External link in |chapterurl= (help); Unknown parameter |chapterurl= ignored (|chapter-url= suggested) (help)
    This is a preface to a book by the subject that gives a sketch biography of the subject. If you scroll up to the Publications section you will see that three of the six books by the subject were co-authored.
  2. Do we? Do we have some champion here who can give the time and whatever else is required to shepherd such changes through the standards approval process? I'm not interested in that task. Are you?
    • Yes, I would be glad to shepherd the change through, assuming we can get concurrence here. I do not anticipate any serious objections. But it needs broader discussion within Wikipedia first. Not sure the right forum... Aymatth2 (talk) 02:02, 2 November 2015 (UTC)
  3. Yes, one of the primary purposes of cs1|2 templates is to [ensure] that the list of books by the subject and the list of sources for the article have consistent format.
    • Also "Further Reading" lists – anywhere a book is defined Aymatth2 (2 November 2015). talk. (UTC).{{cite book}}: CS1 maint: numeric names: authors list (link)
  4. Of course. In a book of Ansel Adams photographs, it's entirely possible that the preponderance of the text is written by an editor. The work is still that of Mr Adams.
  5. Editors are free to identify whatever information they deem relevant. But, it isn't necessary to include all of that in the cs1|2 template. Would not the different editions that you suggest have different dates? possibly different edition identifiers? possibly different publishers? possibly different ISBNs? all of which are standard elements of bibliographic catalog listings?
  6. I don't see |rolen= as a simplification – mostly because such a change would be felt on millions of articles for little real benefit. It's a case of 'if it ain't broke, don't fix it.' COinS currently doesn't support a link between keywords so while you champion the addition of &rft.rolen, the definition of &rft.au will need to change to support &rft.aun
    • From the viewpoint of a WP editor, going forward, it would be a simplification and would solve the problem of how to identify the "others" who have contributed to a book.
    • A one-off conversion can tidy up existing articles after the new parameter has become familiar – but there is no urgency. I can write the bot.
    • We have implemented the |author= family, then the very similar |editor= family, but we really do not want to implement the |illustrator=, |preface= and so on families. The |role= approach is a simple generalization.
    • Surely &rft.aun must be supported anyway for co-authors. The kind of non-fiction books I cite often have two or more authors. E.g. in Léon Martinaud-Déplat#Sources two books out of the eight cited have multiple authors. Ditto with Pierre Forgeot: two out of nine. Note Pierre Forgeot#Publications: he wrote the preface for two of the four books listed, and co-authored a third.
    • COinS is very much a version 0.1 standard, with a 1-dimensional structure. It obviously needs extension to support a more realistic view of publication data. Again, I would be happy to work that one through. The benefits would be obvious to any librarian. Aymatth2 (talk) 13:15, 2 November 2015 (UTC)
—Trappist the monk (talk) 20:52, 1 November 2015 (UTC)
Aymatth2: that you don't accept the distinction between authors and editors (and the distinct roles of each) is not persuasive, given the long and well-established acceptance of that distinction by effectively everyone else. And in the rare cases where it is useful to add more information you are quite free to add it following the citation; a special parameter is not needed. ~ J. Johnson (JJ) (talk) 22:26, 1 November 2015 (UTC)
  • The editor is the person listed as "edited by" at the front of a book. Their role in a compilation may have been simply to assemble individual contributions. However, they may have written an extensive introduction that provides context and a summary of the rest of the book, which may be cited in an article. In this case they may be seen as one of the authors. With some of the classics, a short book is embedded in a mass of valuable material provided by the "editor". I was flipping through an edition of King Harald's Saga the other day, a translation of part of Snorri Sturluson's Heimskringla. The translators, Magnus Magnusson and Hermann Pálsson, provide a 32-page introduction plus many footnotes. Again, their contribution may be cited, and in that sense they are co-authors. We can of course muddle by as we have in the past. No changes are essential... Aymatth2 (talk) 16:12, 2 November 2015 (UTC)
If Smith and Jones write "an extensive introduction that provides context and a summary" for a collection of T. S. Eliot's poetry, does that make them coauthors of "The Love Song of J. Alfred Prufrock"? No! Their authorship is only of the introduction (or whatever they wrote); they are only editors – not authors! – of the poetry. Even if the tail is big enough to wag the dog – say a 600 page critical edition of a twenty page poem – such that Smith and Jones are deemed authors of the book, there is still no "co-" authorship with the poet. Writing an introduction, no matter how many pages, does not make Magnusson and Pálsson coauthors with Sturluson. ~ J. Johnson (JJ) (talk) 21:44, 2 November 2015 (UTC)
  • The {{cite book}} template is usually used to identify a book and its authors in a citation. In the hypothetical T. S. Eliot example, Smith & Jones are co-authors of the book and should be identified to avoid any hint of plagiarism when citing their commentary. The {{cite book}} template could also be used to describe the book in the article on Jones. Her role in creating the book must be shown. Finally, the template generates metadata that may be used by crawlers to find references to the book or to works by Eliot, Smith or Jones.
The proposal is to reduce complexity for WP editors by deprecating the |editor2= |editor2-last= |editor2-first= |editor2-link= parameters and replacing them by the equivalent |author2= parameters plus |role2=editor. The |role2= parameter could also accept values like "translator", "preface", "illustrations" and so on. This would give more consistent format in book definitions and more complete metadata generation. Aymatth2 (talk) 01:16, 3 November 2015 (UTC)
It seems you are still missing the point. Your concept seems to be that we should have a master list of persons connected with the source (person1=, person2=, etc.), and then a parallel list describing their roles. For sure, such a scheme could generate a list of the proper authors, but that is not how these things are done. Long established practice is that we list authors separately from persons in other roles. Your scheme does not reduce complexity, and having such a novel scheme entirely unknown outside of WP would make WP harder to use. ~ J. Johnson (JJ) (talk) 00:14, 4 November 2015 (UTC)

Break

Person ––––∈ Role ∋––––Publication
A related change, which may be done independently, would add this structure to the COinS metadata, so Wikipedia would no longer look quite so naive to the librarian community. When COinS is enhanced to support multiple authors, which is overdue but inevitable, it should be enhanced at the same time to show their roles. Aymatth2 (talk) 01:32, 4 November 2015 (UTC)
This proposal would seem to increase, not decrease, the number of parameters for each individual citation template, and not decrease the number of parameters editors need to know about. Currently, most contributors to a reference are represented by two or three parameters: surname, given name, and possibly authorlink. Your proposal would make that three or four, by adding a role for each contributor. In addition, currently, in most cases editors need to know only about author and editor parameters, which act much the same as each other. Your proposal would replace these with a single combined set of parameters, but would add the new role parameter, and a lot of special keywords for the role, not really reducing the cognitive load of working with these parameters. So overall it seems like an increase rather than a decrease in editor effort, for little purpose. —David Eppstein (talk) 02:35, 4 November 2015 (UTC)
Yes. The standard and long-accepted practice is that we have a list of authors, and it is implicit that every person (or entity) in that list is an author (coauthor). In this proposal that characterization (the metadata) is elsewhere, we have to consult a different list (of roles) to if a given person is an author, or something else. And we have to always do it, because we can never be certain without checking. It also plays hob with bibliographic sorting and indexing, because this is (and should be) done by authors, without regard to illustrators, caterers, personal assistants, etc. And if a person has more than one role, than s/he has to be listed more than once. This is more complex. ~ J. Johnson (JJ) (talk) 21:05, 4 November 2015 (UTC)
  • @J. Johnson: This may be getting into too much detail but... The article text will be parsed and loaded into memory structures, assembling items like name2, first2, last2, link2 and role2 into array entry 2, then reformatted and written out as HTML. Output code that is only interested in authors will only look at entries for authors. If a person has more than one role and both are important, they must both be identified. Today that would mean something like |last=Smith|first=John|others=Smith, John (illustrator). In the new scheme it would be like |last=Smith|first=John|role=author, illustrator, which seems a bit more natural. Aymatth2 (talk) 02:50, 5 November 2015 (UTC)
Scenario Current Proposed
Author only |last=Smith |first=John |last=Smith |first=John
Author and editor |last=Smith |first=John|editor-last=Doe |editor-first=Jane |last=Smith |first=John|last2=Doe |first2=Jane |role2=editor
Author and preface |last=Smith |first=John|others=Bloggs, Fred (preface) |last=Smith |first=John|last2=Bloggs |first2=Fred |role2=preface
Author, editor and preface |last=Smith |first=John|editor-last=Doe |editor-first=Jane|others=Bloggs, Fred (preface) |last=Smith |first=John|last2=Doe |first2=Jane |role2=editor|last3=Bloggs |first3=Fred |role3=preface
With this enhancement. the WP editor uses the |author= parameter set, which now includes |role=, for all names. They do not need the |editor= set and |others= for the names that do not fit. Typed characters are about the same. I would not enforce a standard on values for |role=, any more than standards are enforced for |others=, although the documentation should give examples, and we could generate abbreviations for the common values (e.g. "Editor" becomes "ed."). Apart from the simpler and more consistent syntax, with no significant change in the amount of typing, by taking names out of the |others= parameter the change makes it practical to consolidate the names in the displayed citation. although this is a separate discussion:
Scenario Current Possible improvement
Author only Smith, John (1977). Tropical penguins. Smith, John (1977). Tropical penguins.
Author and editor Smith, John (1977). Doe, Jane (ed.). Tropical penguins. Smith, John; Doe, Jane, ed. (1977) Tropical penguins.
Author and preface Smith, John (1977). Tropical penguins. Bloggs, Fred (pref.). Smith, John; Bloggs, Fred, pref. (1977) Tropical penguins.
Author, editor and preface Smith, John (1977). Doe, Jane (ed.). Tropical penguins. Bloggs, Fred (pref.). Smith, John; Doe, Jane, ed.; Bloggs, Fred, pref. (1977) Tropical penguins.
It also makes it possible to generate COinS metadata for all the names, once the standard has been upgraded to allow multiple authors. However, as J. Johnson (talk · contribs) points out, it would mean changing long-established practice, and that is not how things are done. This seems rather an obscure place to discuss it. @Trappist the monk: Is there a better forum? Aymatth2 (talk) 13:13, 4 November 2015 (UTC)
&rft.au=Author[2..n] is a repeatable parameter so all authors are included in the COinS. Editors, translators, illustrators and names listed in |others= are not made part of the metadata because there are no key/value pairings defined for them.
  • That makes more sense. I could not see how there would be no support for multiple authors. But I am surprised at the lack of support for roles. The national libraries all index by role, which seems an obvious thing to do.
This is the proper forum for any and all topics relating to cs1|2 citation templates. You might post a note referring to this discussion at other talk pages; WT:CITE might be one-such.
—Trappist the monk (talk) 16:38, 4 November 2015 (UTC)
Aymatth2: your example is inconsistent in how you apply |role=. An editor is a person with a certain function (or role); a preface is not a role, but an object (item?) for which someone might have a certain responsibility. Which might be in the form of writing it, editing it, or even illustrating it.
So is your "prefacer" the person who wrote the preface? Or edited it? Or illustrated it? What if these are three different people? ~ J. Johnson (JJ) (talk) 01:24, 5 November 2015 (UTC)
You state that "national libraries all index by role". I don't doubt that. But I think they index them separately. Can you provide any examples where a work's authors are merged with the editors (etc.)? ~ J. Johnson (JJ) (talk) 21:25, 4 November 2015 (UTC)
I don't know how much citations are done differently in French and German, but as this is the English Wikipedia I think we should stick with examples in English. Regarding your BnF example, that is more in the nature of an old-fashioned catalog card, presenting all the information they have about that item. And while it contains the information that would be used in creating a citation, it is not an example of a citation. And as you "have no idea" of the internal representation, you really cannot claim that they are using this scheme you propose here. ~ J. Johnson (JJ) (talk) 01:26, 5 November 2015 (UTC)
  • National libraries provide indexes, not citations. They are relevant when discussing metadata. Citation style guides discuss output formats. We are on our own in deciding how we should represent information about a book internally. This proposal suggests a simpler and more flexible internal syntax. Aymatth2 (talk) 03:43, 5 November 2015 (UTC)
Yes, libraries provide indexes. We provide only citations, with the bibliographic detail appropriate for that purpose. (And I concur with Imzadi's remarks, following.) How libraries might represent information internally – which you admit you don't know – is entirely irrelevant for us. The bottom line here is: your proposed scheme is NOT "a simpler and more flexible internal syntax." ~ J. Johnson (JJ) (talk) 22:51, 5 November 2015 (UTC)

I understand what the proposal is trying to do, but the question comes down to what the core purpose of a citation is. The purpose is to identify the source so that a reader can locate his or her own copy for verification purposes. No more, no less, and I think this proposal is exceeding that core purpose. In short, we are generating citations, and we should be looking at citation guides, not library catalogs for guidance here.

Maybe someday we'll have Wikidata items on every individual source, and then those WD records can store all of the misc. contributor information while our citations parse that information for display in a standardized format in the guise of footnotes. Until then, I don't see a need for this level of complexity here. Imzadi 1979 → 04:41, 5 November 2015 (UTC)

No, it's just too wrong. ~ JJ 23:03, 5 November 2015 (UTC)
As has been explained: your proposal is NOT a simplification, does NOT reduce the number of parameters (actually increases them), and is MORE complex. ~ JJ 23:03, 5 November 2015 (UTC)
  • The purpose of a citation is to identify the source and give due credit. If a foreword is being cited, the author of the foreword should be identified. If a translation is being quoted, the translator should be identified. Aymatth2 (talk) 15:51, 5 November 2015 (UTC)
In the immediately preceeding discussion (#Forward) Imzadi showed (22:58, 31 Oct) how to cite the author of a foreword (see second form), which can be generalized to all similar cases. ~ JJ 23:03, 5 November 2015 (UTC)
  • The change gives greater structure, which makes it easier to ensure the displayed information has standard format. Most citation guides give rules for where and how "preface", "translator" etc. should be represented. MLA style examples:
With the present WP style the secondary contributors get stuck at the back in random format. Aymatth2 (talk) 13:10, 5 November 2015 (UTC)
Secondary contributors "get stuck at the back" because they are, well, secondary. How to specifically cite such secondary contributions has already been shown. ~ JJ 23:03, 5 November 2015 (UTC)
Wikipedia is an encyclopedia, not a bibliographic database. We provide links, starting with the ISBN, to most bibliographic databases. We don't do databases, the database people don't do encyclopedias. ~ J. Johnson (JJ) (talk) 23:03, 5 November 2015 (UTC)

Online date

An increasing number of journals have an "online first" date as well as a printed publication date. Often, the same article has two dates — the date it was first printed online, and the date of the physical paper copy. Is it possible to have a "first online" parameter? Or isn't it important to note that? (Given that the online version can appear many months before the printed one, I'd suggest it might be!) MeegsC (talk) 14:18, 4 November 2015 (UTC)

Use |date= to cite the publication date (on-line or in print) of the version you are citing to support a statement in a WP article. You don't have to overcomplicate it. – Jonesey95 (talk) 15:22, 4 November 2015 (UTC)
It's even simpler than that. The online version is a true copy of the print version, and the usual citation form for a journal article gives the volume and issue with the date they were printed. The online date is more detail than is needed. Kanguole 15:49, 4 November 2015 (UTC)
The online version for a newspaper article does not always give the page number for the physical publication. Nor does the online version of a periodical always give the volume or issue. In such cases the online date may be vital. And even for a print publication I think the publication date provides very helpful context in many cases, and should always be included in the cite if it is available. It can help in detecting out-of-date sources, or seeing a timeline of sourcing on rapidly changing events, where some events may have occurred after the pub date. Depending on the publication, it may also be easier to find by date than by vol/issue. For academic journals vol/issue is generally best, but not always for other publications, which still often use {{cite journal}} as if it were {{cite magazine}}. If both dates are present, I would use the earlier, as that is when the articel was first published in any medium. DES (talk) 19:27, 4 November 2015 (UTC)
I beg to differ: on-line versions often are not "a true copy of the print version", as the on-line versions sometimes reflect corrections. (Alternately, an on-line pre-print might not include late changes to the printed version.) A print version needs the actual date of print publication, and on-line version needs its own publication/revision date. Of course, sometimes those dates are not updated, so access-date is always important. ~ J. Johnson (JJ) (talk) 21:36, 4 November 2015 (UTC)
This isn't about author versions, but the electronic version offered by the journal, e.g. doi:10.1111/ibi.12129. The PDF there is an accurate reflection of the print copy. They also tell you how to cite the article, and that invariably uses the date of print publication. Kanguole 12:05, 5 November 2015 (UTC)
Perhaps you took "pre-print" too narrowly? I was referring to the "electronic" versions that come out ahead of the print copy. Which is usually produced from the same source as the the print copy, and so are as identical as is possible at the time of publication. But sometimes post-publication corrections or revisions are necessary, which, of course, can be done only in the on-line ("electronic") version. Same with retractions. So while the official date of publication is usually that of the print version, any subsequent revision will be found only in the on-line version, which has its own date. ~ J. Johnson (JJ) (talk) 23:27, 5 November 2015 (UTC)
Journals typically allow authors to publish errata or even to retract their papers, but do you know of any that allow post-publication corrections or revisions to the online version? Kanguole 02:16, 6 November 2015 (UTC)
Journals, no. Newspapers, yes. And our citation formatting code treats both of those as the same sort of thing. —David Eppstein (talk) 03:54, 6 November 2015 (UTC)
Journals yes. In theory I think all of them. I have seen such in Science, maybe Nature, and more than one geology journal. Off-hand I don't recall any specific cases, but for an example see this Supporting Online Material Erratum from Science, where a post-publication revision was made. Others are readily found (search for "corrections and clarifications"). ~ J. Johnson (JJ) (talk) 22:47, 6 November 2015 (UTC)
That particular example is an update to the online supporting material rather than the paper. Regarding corrections and clarifications, it seems that they are applied to the HTML version, but the PDF version is retained unmodified, but a separate erratum is added. Kanguole 00:26, 7 November 2015 (UTC)
The erratum was added to the pdf, becoming part of it. If you download the Full Text (PDF) what you get says right across the top: "CORRECTED 1 AUGUST 2008; SEE LAST 2 PAGES". And in the erratum it says: The incorrect version of Fig. 3 has been published in both the online Science Express version and the printed version of the paper. The correct Fig. 3, ... is shown here." Anyone relying on the print version, the original on-line "Full Text (PDF)", or the Science Express version (published 14 Feb.) downloaded any time prior to around 1 August would have a discrepancy with the corrected version. In this case the discrepancy is small, but crucial revisions and even retractions are handled the same way. If I cite a paper that I know has been corrected I would even add a comment to that effect lest some WP editor relying on a print copy takes exception. ~ J. Johnson (JJ) (talk) 22:09, 7 November 2015 (UTC)
P.S. It looks like the pdf linked above is behind the pay-wall. If you are really want to see it try accessing it from a university library. Or send me an e-mail. ~ J. Johnson (JJ) (talk) 22:14, 7 November 2015 (UTC)

Citing a television episode without a title

I have a problem with this citation. The problem is caused by the fact the "Cite episode" template requires that the "title" and "series" parameters are filled in, but the episodes do not have individual episode names. Is there any way around this, or a more suitable template? Betty Logan (talk) 01:21, 7 November 2015 (UTC)

On the video, it says "Series 4 Episode 6" Use "Episode 6", "Episode #4.6" or "#4.6". Also, you can wikilink to Gordon Ramsay's F Word. Bgwhite (talk) 00:40, 8 November 2015 (UTC)

Missing "missing url"?

I was just editing Lotte Lenya to add the following text and citation:

[[Donovan]]'s 1968 song "[[Laleña]]" was inspired by Lenya.<ref name="AllMusic">{{cite web | last=Greenwald | first=Matthew | title=Lalena | website=AllMusic | accessdate=2015-11-08}}</ref>

which gave me an odd error: the accessdate failed to appear. I eventually figured out I'd left out the "url" (d'oh!), but why didn't I get the big, bold-red "missing url" in the reference list? I tried it on other cite-web uses and found only 3 factors so far:

It never showed the "missing url"
It only lost the accessdate argument, not date, website, or author (had no time for exhaustive examination)
It didn't matter where I put any argument

Could someone look into this? ~ Jeff Q (talk) 03:06, 8 November 2015 (UTC)

cs1|2 does not do big, bold-red error messages. The missing or empty |url= error message is hidden by default as is the |access-date= requires |url= error message. To see these messages, you must enable them. See Controlling error message display. I see two error messages from your example citation:
Greenwald, Matthew. "Lalena". AllMusic. {{cite web}}: |access-date= requires |url= (help); Missing or empty |url= (help)
—Trappist the monk (talk) 03:24, 8 November 2015 (UTC)

No author best practice?

The documentation specifies author=<!--Staff writer(s); no by-line.--> for a source with no credited author (I should think that the actual text in the comment is free, but the documentation doesn't say that).

In practice, as of today at least including this parameter or omitting all name information gives the same visible result as far as I can see. Example with and without the "author=<null, e.g. comment>" parameter: [1] [2]

With & without author parm

  1. ^ "Billie Fleming obituary". The Daily Telegraph. 30 May 2014. Retrieved 8 November 2015.
  2. ^ "Billie Fleming obituary". The Daily Telegraph. 30 May 2014. Retrieved 8 November 2015.

Question: is there a reason for specifying author= instead of simply omitting the author parameter? I would tend to say

if no author is credited, the author= parameter may be omitted, or it may be null with a clarifying comment for other editors such as author=<!--Staff writer(s); no by-line.-->

If I was sure of this I'd edit the documentation, but I'm not. If there is a consensus that this should be changed, could I ask that it be done if I don't happen to see it? Thanks. Pol098 (talk) 12:25, 8 November 2015 (UTC)

Omitting the author may lead a detail-oriented editor or GA/FA reviewer to go searching for an author in the future, for example if the article is being reviewed as part of the good article or featured article process. Making it explicit that there is no named author helps that future editor or reviewer. – Jonesey95 (talk) 17:04, 8 November 2015 (UTC)
Thanks, I thought something like that might be the case. I'd still suggest (assuming there's no special significance to "Staff writer(s); no by-line.") something like

if no author is credited, an empty author= parameter should be used, followed by an explanatory comment for other editors such as |author=<!--Staff writer(s); no by-line.-->|

Pol098 (talk) 21:55, 8 November 2015 (UTC)

metadata changes

Here are test cases for metadata using new code in Module:Citation/CS1. The code was rewritten to more closely reflect the type of template for which the module is creating the metadata. The biggest changes involve which metadata key-encoded values (kev) are included. In the current live version kevs that are not defined for the selected metadata format are included in the metadata. The sandbox version attempts to closely follow the standards and only include those kevs that are defined for the specified format.

In the live version, the value assigned to &rft.genre is article, book, bookitem, or preprint. In addition to those, the sandbox makes use of conference, report, and unknown. Many of the cs1 templates now produce &rft.genre=unknown where before they were &rft.genre=book.

There are separate sections for cs1 and cs2 templates. The templates in these sections are taken from their respective documentation or from article space. I think that all of the templates are covered. Did I miss any? Do you see metadata that doesn't make sense?

The standards that I used to make this change are available through this source:

"Registry for the OpenURL Framework - ANSI/NISO Z39.88-2004". OCLC. Retrieved 2015-09-27.

cs1

← click show to view metadata testcases for cs1 templates
  • {{cite arXiv}}
    • Sparling, George A. J. (2006). "Spacetime is spinorial; new dimensions are timelike". arXiv:gr-qc/0610068v1.
      • '"`UNIQ--templatestyles-0000027B-QINU`"'<cite id="CITEREFSparling2006" class="citation arxiv cs1">Sparling, George A. J. (2006). "Spacetime is spinorial; new dimensions are timelike". [[arXiv (identifier)|arXiv]]:<span class="id-lock-free" title="Freely accessible">[https://arxiv.org/abs/gr-qc/0610068v1 gr-qc/0610068v1]</span>.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=preprint&rft.jtitle=arXiv&rft.atitle=Spacetime+is+spinorial%3B+new+dimensions+are+timelike&rft.date=2006&rft_id=info%3Aarxiv%2Fgr-qc%2F0610068v1&rft.aulast=Sparling&rft.aufirst=George+A.+J.&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+9" class="Z3988"></span>
  • {{cite AV media}}
    • Fouladkar, Assad (Director) (May 15, 2003). Lamma hikyit Maryam [When Maryam Spoke Out] (Motion picture). Lebanon: Fouladkar, Assad.
      • '"`UNIQ--templatestyles-0000027E-QINU`"'<cite class="citation audio-visual cs1">Fouladkar, Assad (Director) (May 15, 2003). ''Lamma hikyit Maryam'' &#91;''When Maryam Spoke Out''&#93; (Motion picture). Lebanon: Fouladkar, Assad.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=unknown&rft.btitle=Lamma+hikyit+Maryam&rft.place=Lebanon&rft.pub=Fouladkar%2C+Assad&rft.date=2003-05-15&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+9" class="Z3988"></span>
  • {{cite AV media notes}}
    • Lewisohn, Mark (1994). "Making Anthology 1". Anthology 1 (booklet). The Beatles. London: Apple Records. p. 2. 34448.
      • '"`UNIQ--templatestyles-00000281-QINU`"'<cite id="CITEREFLewisohn1994" class="citation AV-media-notes cs1">[[Mark Lewisohn|Lewisohn, Mark]] (1994). [http://www.wikipedia.org "Making Anthology 1"]. [[Anthology 1|''Anthology 1'']] (booklet). [[The Beatles]]. London: [[Apple Records]]. p.&nbsp;2. 34448.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=unknown&rft.btitle=Anthology+1&rft.place=London&rft.pages=2&rft.pub=Apple+Records&rft.date=1994&rft.aulast=Lewisohn&rft.aufirst=Mark&rft_id=http%3A%2F%2Fwww.wikipedia.org&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+9" class="Z3988"></span>
  • {{cite book}}
    • Playfair, Major-General I.S.O.; Stitt, Commander G.M.S.; Molony, Brigadier C.J.C.; Toomer, Air Vice-Marshal S.E. (2007) [1st pub. HMSO:1954]. Butler, J.R.M. (ed.). Mediterranean and Middle East. History of the Second World War, United Kingdom Military Series. Vol. Volume I: The Early Successes Against Italy (to May 1941). Uckfield, UK: Naval & Military Press. ISBN 1-845740-65-3. {{cite book}}: |volume= has extra text (help); Unknown parameter |lastauthoramp= ignored (|name-list-style= suggested) (help)
      • '"`UNIQ--templatestyles-00000284-QINU`"'<cite id="CITEREFPlayfairStittMolonyToomer2007" class="citation book cs1 cs1-prop-long-vol">[[Ian Stanley Ord Playfair|Playfair, Major-General I.S.O.]]; Stitt, Commander G.M.S.; Molony, Brigadier C.J.C.; Toomer, Air Vice-Marshal S.E. (2007) [1st pub. [[HMSO]]:1954]. Butler, J.R.M. (ed.). ''Mediterranean and Middle East''. History of the Second World War, United Kingdom Military Series. Vol.&nbsp;Volume I: The Early Successes Against Italy (to May 1941). Uckfield, UK: Naval & Military Press. [[ISBN (identifier)|ISBN]]&nbsp;[[Special:BookSources/1-845740-65-3|<bdi>1-845740-65-3</bdi>]].</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Mediterranean+and+Middle+East&rft.place=Uckfield%2C+UK&rft.series=History+of+the+Second+World+War%2C+United+Kingdom+Military+Series&rft.pub=Naval+%26+Military+Press&rft.date=2007&rft.isbn=1-845740-65-3&rft.aulast=Playfair&rft.aufirst=Major-General+I.S.O.&rft.au=Stitt%2C+Commander+G.M.S.&rft.au=Molony%2C+Brigadier+C.J.C.&rft.au=Toomer%2C+Air+Vice-Marshal+S.E.&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+9" class="Z3988"></span> <span class="cs1-visible-error citation-comment"><code class="cs1-code">{{[[Template:cite book|cite book]]}}</code>: </span><span class="cs1-visible-error citation-comment"><code class="cs1-code">&#124;volume=</code> has extra text ([[Help:CS1 errors#extra_text_volume|help]])</span>; <span class="cs1-visible-error citation-comment">Unknown parameter <code class="cs1-code">&#124;lastauthoramp=</code> ignored (<code class="cs1-code">&#124;name-list-style=</code> suggested) ([[Help:CS1 errors#parameter_ignored_suggest|help]])</span>
  • {{cite conference}} (as book)
    • Fontani, Marco (10 September 2005). The Twilight of the Naturally-Occurring Elements: Moldavium (Ml), Sequanium (Sq) and Dor (Do). International Conference on the History of Chemistry. Lisbon. pp. 1–8. Archived from the original (doc) on 24 February 2006. Retrieved 8 April 2007.
      • '"`UNIQ--templatestyles-00000287-QINU`"'<cite id="CITEREFFontani2005" class="citation conference cs1">Fontani, Marco (10 September 2005). [http://web.archive.org/web/20060224090117/http://5ichc-portugal.ulusofona.pt/uploads/PaperLong-MarcoFontani.doc ''The Twilight of the Naturally-Occurring Elements: Moldavium (Ml), Sequanium (Sq) and Dor (Do)'']. International Conference on the History of Chemistry. Lisbon. pp.&nbsp;<span class="nowrap">1–</span>8. Archived from [http://5ichc-portugal.ulusofona.pt/uploads/PaperLong-MarcoFontani.doc the original] <span class="cs1-format">(doc)</span> on 24 February 2006<span class="reference-accessdate">. Retrieved <span class="nowrap">8 April</span> 2007</span>.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=conference&rft.btitle=The+Twilight+of+the+Naturally-Occurring+Elements%3A+Moldavium+%28Ml%29%2C+Sequanium+%28Sq%29+and+Dor+%28Do%29&rft.place=Lisbon&rft.pages=%3Cspan+class%3D%22nowrap%22%3E1-%3C%2Fspan%3E8&rft.date=2005-09-10&rft.aulast=Fontani&rft.aufirst=Marco&rft_id=http%3A%2F%2F5ichc-portugal.ulusofona.pt%2Fuploads%2FPaperLong-MarcoFontani.doc&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+9" class="Z3988"></span>
  • {{cite conference}} (as journal)
    • Liskov, Barbara; Zilles, Stephen (April 1974). Programming with abstract data types. ACM SIGPLAN Notices. Vol. 9, no. 4. pp. 50–59. doi:10.1145/800233.807045. {{cite conference}}: Invalid |ref=harv (help)
      • '"`UNIQ--templatestyles-0000028A-QINU`"'<cite id="CITEREFLiskovZilles1974" class="citation conference cs1">[[Barbara Liskov|Liskov, Barbara]]; Zilles, Stephen (April 1974). ''Programming with abstract data types''. ''ACM SIGPLAN Notices''. Vol.&nbsp;9, no.&nbsp;4. pp.&nbsp;<span class="nowrap">50–</span>59. [[doi (identifier)|doi]]:[https://doi.org/10.1145%2F800233.807045 10.1145/800233.807045].</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=conference&rft.jtitle=ACM+SIGPLAN+Notices&rft.atitle=Programming+with+abstract+data+types&rft.volume=9&rft.issue=4&rft.pages=%3Cspan+class%3D%22nowrap%22%3E50-%3C%2Fspan%3E59&rft.date=1974-04&rft_id=info%3Adoi%2F10.1145%2F800233.807045&rft.aulast=Liskov&rft.aufirst=Barbara&rft.au=Zilles%2C+Stephen&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+9" class="Z3988"></span> <span class="cs1-visible-error citation-comment"><code class="cs1-code">{{[[Template:cite conference|cite conference]]}}</code>: </span><span class="cs1-visible-error citation-comment">Invalid <code class="cs1-code">&#124;ref=harv</code> ([[Help:CS1 errors#invalid_param_val|help]])</span>
  • {{cite DVD notes}}
    • Terminator 2 Ultimate Edition DVD (Liner notes). James Cameron. Hollywood, California: Artisan Entertainment. 2000. FMD2402.{{cite AV media notes}}: CS1 maint: others in cite AV media (notes) (link)
      • '"`UNIQ--templatestyles-0000028D-QINU`"'<cite class="citation AV-media-notes cs1">''[[Terminator 2: Judgment Day|Terminator 2 Ultimate Edition DVD]]'' (Liner notes). [[James Cameron]]. Hollywood, California: [[Artisan Entertainment]]. 2000. FMD2402.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=unknown&rft.btitle=Terminator+2+Ultimate+Edition+DVD&rft.place=Hollywood%2C+California&rft.pub=Artisan+Entertainment&rft.date=2000&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+9" class="Z3988"></span><span class="cs1-maint citation-comment"><code class="cs1-code">{{[[Template:cite AV media notes|cite AV media notes]]}}</code>: CS1 maint: others in cite AV media (notes) ([[:Category:CS1 maint: others in cite AV media (notes)|link]])</span>
  • {{cite encyclopedia}}
    • Golden, Peter B. (2007a). "Khazar Studies: Achievements and Perspectives". In Golden, Peter B.; Ben-Shammai, Haggai; Róna-Tas, András (eds.). The World of the Khazars: New Perspectives. Handbook of Oriental Studies. Vol. 17. BRILL. pp. 7–57. ISBN 978-9-004-16042-2.
      • '"`UNIQ--templatestyles-00000290-QINU`"'<cite id="CITEREFGolden2007a" class="citation encyclopaedia cs1">[[Peter Benjamin Golden|Golden, Peter B.]] (2007a). [http://books.google.com/books?id=3ZzXjdyK-CEC&pg=PA7 "Khazar Studies: Achievements and Perspectives"]. In [[Peter Benjamin Golden|Golden, Peter B.]]; Ben-Shammai, Haggai; [[András Róna-Tas|Róna-Tas, András]] (eds.). ''The World of the Khazars: New Perspectives''. Handbook of Oriental Studies. Vol.&nbsp;17. BRILL. pp.&nbsp;<span class="nowrap">7–</span>57. [[ISBN (identifier)|ISBN]]&nbsp;[[Special:BookSources/978-9-004-16042-2|<bdi>978-9-004-16042-2</bdi>]].</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=bookitem&rft.atitle=Khazar+Studies%3A+Achievements+and+Perspectives&rft.btitle=The+World+of+the+Khazars%3A+New+Perspectives&rft.series=Handbook+of+Oriental+Studies&rft.pages=%3Cspan+class%3D%22nowrap%22%3E7-%3C%2Fspan%3E57&rft.pub=BRILL&rft.date=2007&rft.isbn=978-9-004-16042-2&rft.aulast=Golden&rft.aufirst=Peter+B.&rft_id=http%3A%2F%2Fbooks.google.com%2Fbooks%3Fid%3D3ZzXjdyK-CEC%26pg%3DPA7&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+9" class="Z3988"></span>
  • {{cite encyclopedia}}
    • "ARTICLE". TITLE. ENCYCLOPEDIA.
      • '"`UNIQ--templatestyles-00000293-QINU`"'<cite class="citation encyclopaedia cs1">"ARTICLE". ''TITLE''. ''ENCYCLOPEDIA''.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=bookitem&rft.atitle=TITLE&rft.btitle=ENCYCLOPEDIA&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+9" class="Z3988"></span>
  • {{cite episode}}
    • Lipton, James (host) (8 October 2007). "Billy Crystal, 2nd Visit". Inside the Actors Studio. Season 13. Episode 1307. Bravo.
      • '"`UNIQ--templatestyles-00000296-QINU`"'<cite id="CITEREFLipton2007" class="citation episode cs1">Lipton, James (host) (8 October 2007). [http://www.bravotv.com/Inside_the_Actors_Studio/guest/Billy_Crystal_-_2nd_Visit "Billy Crystal, 2nd Visit"]. ''Inside the Actors Studio''. Season 13. Episode 1307. Bravo.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=unknown&rft.btitle=Inside+the+Actors+Studio&rft.series=Season+13.+Episode+1307&rft.date=2007-10-08&rft.aulast=Lipton&rft.aufirst=James+%28host%29&rft_id=http%3A%2F%2Fwww.bravotv.com%2FInside_the_Actors_Studio%2Fguest%2FBilly_Crystal_-_2nd_Visit&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+9" class="Z3988"></span>
  • {{cite interview}} – Periodical is not set; | not part of metadata
    • Blackmun, Harry (April 5, 1994). "An Interview with Harry Blackmun" (Interview). Interviewed by Ted Koppel. {{cite interview}}: Unknown parameter |call-sign= ignored (help); Unknown parameter |city= ignored (|location= suggested) (help); Unknown parameter |program= ignored (help)
      • '"`UNIQ--templatestyles-00000299-QINU`"'<cite id="CITEREFBlackmun1994" class="citation interview cs1">[[Harry Blackmun|Blackmun, Harry]] (April 5, 1994). "An Interview with Harry Blackmun" (Interview). Interviewed by [[Ted Koppel]].</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=unknown&rft.btitle=An+Interview+with+Harry+Blackmun&rft.date=1994-04-05&rft.aulast=Blackmun&rft.aufirst=Harry&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+9" class="Z3988"></span> <span class="cs1-visible-error citation-comment"><code class="cs1-code">{{[[Template:cite interview|cite interview]]}}</code>: </span><span class="cs1-visible-error citation-comment">Unknown parameter <code class="cs1-code">&#124;call-sign=</code> ignored ([[Help:CS1 errors#parameter_ignored|help]])</span>; <span class="cs1-visible-error citation-comment">Unknown parameter <code class="cs1-code">&#124;city=</code> ignored (<code class="cs1-code">&#124;location=</code> suggested) ([[Help:CS1 errors#parameter_ignored_suggest|help]])</span>; <span class="cs1-visible-error citation-comment">Unknown parameter <code class="cs1-code">&#124;program=</code> ignored ([[Help:CS1 errors#parameter_ignored|help]])</span>
  • {{cite interview}} – Periodical is set by |work=
    • Gates, Bill. "Bill Gates Interview". Computer History Collection (Interview). Interviewed by David Allison. National Museum of American History, Smithsonian Institution. Retrieved April 10, 2013. {{cite interview}}: Unknown parameter |program= ignored (help); Unknown parameter |subjectlink= ignored (|subject-link= suggested) (help)
      • '"`UNIQ--templatestyles-0000029C-QINU`"'<cite id="CITEREFGates" class="citation interview cs1">Gates, Bill. [http://americanhistory.si.edu/comphist/gates.htm "Bill Gates Interview"]. ''Computer History Collection'' (Interview). Interviewed by David Allison. National Museum of American History, Smithsonian Institution<span class="reference-accessdate">. Retrieved <span class="nowrap">April 10,</span> 2013</span>.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=article&rft.jtitle=Computer+History+Collection&rft.atitle=Bill+Gates+Interview&rft.aulast=Gates&rft.aufirst=Bill&rft_id=http%3A%2F%2Famericanhistory.si.edu%2Fcomphist%2Fgates.htm&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+9" class="Z3988"></span> <span class="cs1-visible-error citation-comment"><code class="cs1-code">{{[[Template:cite interview|cite interview]]}}</code>: </span><span class="cs1-visible-error citation-comment">Unknown parameter <code class="cs1-code">&#124;program=</code> ignored ([[Help:CS1 errors#parameter_ignored|help]])</span>; <span class="cs1-visible-error citation-comment">Unknown parameter <code class="cs1-code">&#124;subjectlink=</code> ignored (<code class="cs1-code">&#124;subject-link=</code> suggested) ([[Help:CS1 errors#parameter_ignored_suggest|help]])</span>
  • {{cite interview}} – in a book
    • Trillin, Calvin (1992). "Calvin Trillin: Sausage Eating, Slothful Sweetheart". In Winokur, Jon (ed.). "The Portable Curmudgeon" (Interview). Interviewed by Jon Winokur. Plume. ISBN 0-452-26668-8. {{cite interview}}: Unknown parameter |subjectlink= ignored (|subject-link= suggested) (help)
      • '"`UNIQ--templatestyles-0000029F-QINU`"'<cite id="CITEREFTrillin1992" class="citation interview cs1">Trillin, Calvin (1992). "Calvin Trillin: Sausage Eating, Slothful Sweetheart". In Winokur, Jon (ed.). "The Portable Curmudgeon" (Interview). Interviewed by Jon Winokur. Plume. [[ISBN (identifier)|ISBN]]&nbsp;[[Special:BookSources/0-452-26668-8|<bdi>0-452-26668-8</bdi>]].</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=bookitem&rft.atitle=Calvin+Trillin%3A+Sausage+Eating%2C+Slothful+Sweetheart&rft.btitle=The+Portable+Curmudgeon&rft.pub=Plume&rft.date=1992&rft.isbn=0-452-26668-8&rft.aulast=Trillin&rft.aufirst=Calvin&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+9" class="Z3988"></span> <span class="cs1-visible-error citation-comment"><code class="cs1-code">{{[[Template:cite interview|cite interview]]}}</code>: </span><span class="cs1-visible-error citation-comment">Unknown parameter <code class="cs1-code">&#124;subjectlink=</code> ignored (<code class="cs1-code">&#124;subject-link=</code> suggested) ([[Help:CS1 errors#parameter_ignored_suggest|help]])</span>
  • {{cite journal}}
    • Viollet, Benoît; Andreelli, Fabrizio; Jørgensen, Sebastian B.; Perrin, Christophe; Geloen, Alain; et al. (January 2003). "The AMP-activated protein kinase α2 catalytic subunit controls whole-body insulin sensitivity". The Journal of Clinical Investigation. 111 (1): 91–8. doi:10.1172/JCI16567. PMC 151837. PMID 12511592. Retrieved 2012-11-17.{{cite journal}}: CS1 maint: numeric names: authors list (link)
      • '"`UNIQ--templatestyles-000002A2-QINU`"'<cite id="CITEREFViolletAndreelliJørgensenPerrin2003" class="citation journal cs1">Viollet, Benoît; Andreelli, Fabrizio; Jørgensen, Sebastian B.; Perrin, Christophe; Geloen, Alain; et&nbsp;al. (January 2003). [http://www.jci.org/articles/view/16567 "The AMP-activated protein kinase α2 catalytic subunit controls whole-body insulin sensitivity"]. ''The Journal of Clinical Investigation''. <b>111</b> (1): <span class="nowrap">91–</span>8. [[doi (identifier)|doi]]:[https://doi.org/10.1172%2FJCI16567 10.1172/JCI16567]. [[PMC (identifier)|PMC]]&nbsp;<span class="id-lock-free" title="Freely accessible">[https://www.ncbi.nlm.nih.gov/pmc/articles/PMC151837 151837]</span>. [[PMID (identifier)|PMID]]&nbsp;[https://pubmed.ncbi.nlm.nih.gov/12511592 12511592]<span class="reference-accessdate">. Retrieved <span class="nowrap">2012-11-17</span></span>.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=article&rft.jtitle=The+Journal+of+Clinical+Investigation&rft.atitle=The+AMP-activated+protein+kinase+%CE%B12+catalytic+subunit+controls+whole-body+insulin+sensitivity&rft.volume=111&rft.issue=1&rft.pages=%3Cspan+class%3D%22nowrap%22%3E91-%3C%2Fspan%3E8&rft.date=2003-01&rft_id=https%3A%2F%2Fwww.ncbi.nlm.nih.gov%2Fpmc%2Farticles%2FPMC151837%23id-name%3DPMC&rft_id=info%3Apmid%2F12511592&rft_id=info%3Adoi%2F10.1172%2FJCI16567&rft.aulast=Viollet&rft.aufirst=Beno%C3%AEt&rft.au=Andreelli%2C+Fabrizio&rft.au=J%C3%B8rgensen%2C+Sebastian+B.&rft.au=Perrin%2C+Christophe&rft.au=Geloen%2C+Alain&rft.au=Flamez%2C+Daisy&rft.au=Mu%2C+James&rft.au=Lenzner%2C+Claudia&rft.au=Baud%2C+Olivier&rft.au=Bennoun%2C+Myriam&rft.au=Gomas%2C+Emmanuel&rft.au=Nicolas%2C+Ga%C3%ABl&rft.au=Wojtaszewski%2C+J%C3%B8rgen+F.+P.&rft.au=Kahn1%2C+Axel&rft.au=Carling%2C+David&rft.au=Schuit%2C+Frans+C.&rft.au=Birnbaum%2C+Morris+J.&rft.au=Richter%2C+Erik+A.&rft.au=Burcelin%2C+R%C3%A9my&rft.au=Vaulont%2C+Sophie&rft_id=http%3A%2F%2Fwww.jci.org%2Farticles%2Fview%2F16567&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+9" class="Z3988"></span><span class="cs1-maint citation-comment"><code class="cs1-code">{{[[Template:cite journal|cite journal]]}}</code>: CS1 maint: numeric names: authors list ([[:Category:CS1 maint: numeric names: authors list|link]])</span>
  • {{cite mailing list}}
    • Perens, Bruce (June 6, 1996). "Debian Linux Distribution Release 1.1 Now Available". debian-announce (Mailing list).
      • '"`UNIQ--templatestyles-000002A5-QINU`"'<cite id="CITEREFPerens1996" class="citation mailinglist cs1">[[Bruce Perens|Perens, Bruce]] (June 6, 1996). [http://lists.debian.org/debian-announce/debian-announce-1996/msg00021.html "Debian Linux Distribution Release 1.1 Now Available"]. ''debian-announce'' (Mailing list).</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=unknown&rft.btitle=Debian+Linux+Distribution+Release+1.1+Now+Available&rft.date=1996-06-06&rft.aulast=Perens&rft.aufirst=Bruce&rft_id=http%3A%2F%2Flists.debian.org%2Fdebian-announce%2Fdebian-announce-1996%2Fmsg00021.html&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+9" class="Z3988"></span>
  • {{cite map}} standalone
    • Skelly Oil Company; Diversified Map Co. (1966). Highway Map of Oklahoma (Map). [1:1,500,000]. St. Louis: Diversified Map Co. § C11. OCLC 67708775.
      • '"`UNIQ--templatestyles-000002A8-QINU`"'<cite id="CITEREFSkelly_Oil_CompanyDiversified_Map_Co.1966" class="citation map cs1">Skelly Oil Company; Diversified Map Co. (1966). ''Highway Map of Oklahoma'' (Map). [1:1,500,000]. St. Louis: Diversified Map Co. §&nbsp;C11. [[OCLC (identifier)|OCLC]]&nbsp;[https://search.worldcat.org/oclc/67708775 67708775].</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=unknown&rft.btitle=Highway+Map+of+Oklahoma&rft.place=St.+Louis&rft.pub=Diversified+Map+Co.&rft.date=1966&rft_id=info%3Aoclcnum%2F67708775&rft.au=Skelly+Oil+Company&rft.au=Diversified+Map+Co.&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+9" class="Z3988"></span>
  • {{cite map}} in a book
    • Rand McNally (2013). "Michigan" (Map). The Road Atlas (2013 Walmart ed.). 1 in≈30 mi. Chicago: Rand McNally. pp. 50–51. Western Upper Peninsula inset. §§ C10–C14. ISBN 0-528-00626-6.
      • '"`UNIQ--templatestyles-000002AB-QINU`"'<cite id="CITEREFRand_McNally2013" class="citation map cs1">Rand McNally (2013). "Michigan" (Map). ''The Road Atlas'' (2013 Walmart&nbsp;ed.). 1&nbsp;in≈30&nbsp;mi. Chicago: Rand McNally. pp.&nbsp;<span class="nowrap">50–</span>51. Western Upper Peninsula inset. §§&nbsp;C10–C14. [[ISBN (identifier)|ISBN]]&nbsp;[[Special:BookSources/0-528-00626-6|<bdi>0-528-00626-6</bdi>]].</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=bookitem&rft.atitle=Michigan&rft.btitle=The+Road+Atlas&rft.place=Chicago&rft.pages=%3Cspan+class%3D%22nowrap%22%3E50-%3C%2Fspan%3E51&rft.edition=2013+Walmart&rft.pub=Rand+McNally&rft.date=2013&rft.isbn=0-528-00626-6&rft.au=Rand+McNally&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+9" class="Z3988"></span>
  • {{cite map}} in a journal
    • Colorado State Highway Department (July 1923). "New Map Showing the 8,880 Miles Which Comprise Colorado's Primary Highway System" (Map). Colorado Highways. Scale not given. 2 (7): 12–13. OCLC 11880590. Retrieved November 18, 2013 – via Google Books.
      • '"`UNIQ--templatestyles-000002AE-QINU`"'<cite id="CITEREFColorado_State_Highway_Department1923" class="citation map cs1">Colorado State Highway Department (July 1923). [http://books.google.com/books?id=czs5AQAAMAAJ&pg=RA10-PA12 "New Map Showing the 8,880 Miles Which Comprise Colorado's Primary Highway System"] (Map). ''Colorado Highways''. Scale not given. <b>2</b> (7): <span class="nowrap">12–</span>13. [[OCLC (identifier)|OCLC]]&nbsp;[https://search.worldcat.org/oclc/11880590 11880590]<span class="reference-accessdate">. Retrieved <span class="nowrap">November 18,</span> 2013</span> &ndash; via [[Google Books]].</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=article&rft.jtitle=Colorado+Highways&rft.atitle=New+Map+Showing+the+8%2C880+Miles+Which+Comprise+Colorado%27s+Primary+Highway+System&rft.volume=2&rft.issue=7&rft.pages=%3Cspan+class%3D%22nowrap%22%3E12-%3C%2Fspan%3E13&rft.date=1923-07&rft_id=info%3Aoclcnum%2F11880590&rft.au=Colorado+State+Highway+Department&rft_id=http%3A%2F%2Fbooks.google.com%2Fbooks%3Fid%3Dczs5AQAAMAAJ%26pg%3DRA10-PA12&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+9" class="Z3988"></span>
  • {{cite news}}
    • "Bellingham Police Arrest WWU Student in Melee". The Seattle Times. Associated Press. 2013-10-17. Retrieved 2013-10-17.
      • '"`UNIQ--templatestyles-000002B1-QINU`"'<cite class="citation news cs1">[http://blogs.seattletimes.com/today/2013/10/bellingham-police-arrest-wwu-student-in-melee/ "Bellingham Police Arrest WWU Student in Melee"]. ''The Seattle Times''. Associated Press. 2013-10-17<span class="reference-accessdate">. Retrieved <span class="nowrap">2013-10-17</span></span>.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=article&rft.jtitle=The+Seattle+Times&rft.atitle=Bellingham+Police+Arrest+WWU+Student+in+Melee&rft.date=2013-10-17&rft_id=http%3A%2F%2Fblogs.seattletimes.com%2Ftoday%2F2013%2F10%2Fbellingham-police-arrest-wwu-student-in-melee%2F&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+9" class="Z3988"></span>
  • {{cite newsgroup}}
    • A. S. Tanenbaum (January 29, 1992). "LINUX is obsolete". Newsgroup: comp.os.minix. Usenet: 12595@star.cs.vu.nl. Retrieved November 27, 2006.
      • '"`UNIQ--templatestyles-000002B4-QINU`"'<cite id="CITEREFA._S._Tanenbaum1992" class="citation newsgroup cs1">A. S. Tanenbaum (January 29, 1992). [http://groups.google.com/group/comp.os.minix/browse_thread/thread/c25870d7a41696d2/f447530d082cd95d?tvc=2 "LINUX is obsolete"]. [[Usenet newsgroup|Newsgroup]]:&nbsp;[news:comp.os.minix comp.os.minix]. [[Usenet (identifier)|Usenet:]]&nbsp;[news:12595@star.cs.vu.nl 12595@star.cs.vu.nl]<span class="reference-accessdate">. Retrieved <span class="nowrap">November 27,</span> 2006</span>.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=unknown&rft.btitle=LINUX+is+obsolete&rft.pub=comp.os.minix&rft.date=1992-01-29&rft_id=news%3A12595%40star.cs.vu.nl%23id-name%3DUsenet%3A&rft.au=A.+S.+Tanenbaum&rft_id=http%3A%2F%2Fgroups.google.com%2Fgroup%2Fcomp.os.minix%2Fbrowse_thread%2Fthread%2Fc25870d7a41696d2%2Ff447530d082cd95d%3Ftvc%3D2&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+9" class="Z3988"></span>
  • {{cite podcast}}
    • Josh Clark and Charles W. "Chuck" Bryant (December 9, 2014). "How The Hum Works". Stuff You Should Know (Podcast). Blucora. Retrieved 2014-12-10.
      • '"`UNIQ--templatestyles-000002B7-QINU`"'<cite id="CITEREFJosh_Clark_and_Charles_W._&quot;Chuck&quot;_Bryant2014" class="citation podcast cs1">Josh Clark and Charles W. "Chuck" Bryant (December 9, 2014). [http://www.stuffyoushouldknow.com/podcasts/how-the-hum-works/ "How The Hum Works"]. ''Stuff You Should Know'' (Podcast). [[Blucora]]<span class="reference-accessdate">. Retrieved <span class="nowrap">2014-12-10</span></span>.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=unknown&rft.btitle=How+The+Hum+Works&rft.pub=Blucora&rft.date=2014-12-09&rft.au=Josh+Clark+and+Charles+W.+%22Chuck%22+Bryant&rft_id=http%3A%2F%2Fwww.stuffyoushouldknow.com%2Fpodcasts%2Fhow-the-hum-works%2F&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+9" class="Z3988"></span>
  • {{cite press release}}
    • Roithmayr, Mark (February 5, 2007). "Autism Speaks and Cure Autism Now Complete Merger" (Press release). New York: Autism Speaks. Retrieved November 19, 2007.
      • '"`UNIQ--templatestyles-000002BA-QINU`"'<cite id="CITEREFRoithmayr2007" class="citation pressrelease cs1">Roithmayr, Mark (February 5, 2007). [http://autismspeaks.org/press/autism_speaks_can_complete.php "Autism Speaks and Cure Autism Now Complete Merger"] (Press release). New York: [[Autism Speaks]]<span class="reference-accessdate">. Retrieved <span class="nowrap">November 19,</span> 2007</span>.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=unknown&rft.btitle=Autism+Speaks+and+Cure+Autism+Now+Complete+Merger&rft.place=New+York&rft.pub=Autism+Speaks&rft.date=2007-02-05&rft.aulast=Roithmayr&rft.aufirst=Mark&rft_id=http%3A%2F%2Fautismspeaks.org%2Fpress%2Fautism_speaks_can_complete.php&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+9" class="Z3988"></span>
  • {{cite report}}
    • Rhode Island Roads (Report). Rhode Island Department of Public Works. 1956.
      • '"`UNIQ--templatestyles-000002BD-QINU`"'<cite class="citation report cs1">Rhode Island Roads (Report). Rhode Island Department of Public Works. 1956.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=report&rft.btitle=Rhode+Island+Roads&rft.pub=Rhode+Island+Department+of+Public+Works&rft.date=1956&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+9" class="Z3988"></span>
  • {{cite serial}}
    • Stern, Howard (host); Insane Clown Posse (guests) (1 September 2009). ICP on Howard Stern 9.1.09. The Howard Stern Show. Sirius Satellite Radio. Howard 100.
      • '"`UNIQ--templatestyles-000002C0-QINU`"'<cite id="CITEREFSternInsane_Clown_Posse_(guests)2009" class="citation serial cs1">[[Howard Stern|Stern, Howard (host)]]; [[Insane Clown Posse|Insane Clown Posse (guests)]] (1 September 2009). [http://www.insaneclownposse.com/media/interview/icp_howard_stern_090901.mp3 ''ICP on Howard Stern 9.1.09'']. ''[[The Howard Stern Show]]''. [[Sirius Satellite Radio]]. [[Howard 100 and Howard 101|Howard 100]].</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=unknown&rft.btitle=ICP+on+Howard+Stern+9.1.09&rft.series=%27%27The+Howard+Stern+Show%27%27&rft.date=2009-09-01&rft.aulast=Stern&rft.aufirst=Howard+%28host%29&rft.au=Insane+Clown+Posse+%28guests%29&rft_id=http%3A%2F%2Fwww.insaneclownposse.com%2Fmedia%2Finterview%2Ficp_howard_stern_090901.mp3&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+9" class="Z3988"></span>
  • {{cite sign}}
    • Michigan Historical Marker Program (February 18, 1956). Under the Oaks (Michigan Historical Marker). Jackson, MI: Michigan Department of Natural Resources. Retrieved July 25, 2010.
      • '"`UNIQ--templatestyles-000002C3-QINU`"'<cite id="CITEREFMichigan_Historical_Marker_Program1956" class="citation sign cs1">Michigan Historical Marker Program (February 18, 1956). [http://www.jacksonmich.com/markers/mark1.htm ''Under the Oaks''] (Michigan Historical Marker). Jackson, MI: [[Michigan Department of Natural Resources]]<span class="reference-accessdate">. Retrieved <span class="nowrap">July 25,</span> 2010</span>.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=unknown&rft.btitle=Under+the+Oaks&rft.place=Jackson%2C+MI&rft.pub=Michigan+Department+of+Natural+Resources&rft.date=1956-02-18&rft.au=Michigan+Historical+Marker+Program&rft_id=http%3A%2F%2Fwww.jacksonmich.com%2Fmarkers%2Fmark1.htm&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+9" class="Z3988"></span>
  • {{cite speech}}
    • King, Robert J. (25–29 October 1999). Arthur Phillip Defensor de Colónia, Governador de Nova Gales do Sul (Speech). V Simpósio de HistóriaMarítimo e Naval Iber-americano,. Ilha Fiscal, Rio de Janeiro, Brazil: Vancouver Island University. {{cite speech}}: Unknown parameter |trans_title= ignored (|trans-title= suggested) (help)CS1 maint: extra punctuation (link)
      • '"`UNIQ--templatestyles-000002C6-QINU`"'<cite id="CITEREFKing1999" class="citation speech cs1">King, Robert J. (25–29 October 1999). [http://web.viu.ca/black/amrc/index.htm?Research/Papers/PHILLIP2.HTM&2 ''Arthur Phillip Defensor de Colónia, Governador de Nova Gales do Sul''] (Speech). V Simpósio de HistóriaMarítimo e Naval Iber-americano,. Ilha Fiscal, Rio de Janeiro, Brazil: [[Vancouver Island University]].</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=unknown&rft.btitle=Arthur+Phillip+Defensor+de+Col%C3%B3nia%2C+Governador+de+Nova+Gales+do+Sul&rft.place=Ilha+Fiscal%2C+Rio+de+Janeiro%2C+Brazil&rft.pub=Vancouver+Island+University&rft.date=1999-10-25%2F1999-10-29&rft.aulast=King&rft.aufirst=Robert+J.&rft_id=http%3A%2F%2Fweb.viu.ca%2Fblack%2Famrc%2Findex.htm%3FResearch%2FPapers%2FPHILLIP2.HTM%262&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+9" class="Z3988"></span> <span class="cs1-visible-error citation-comment"><code class="cs1-code">{{[[Template:cite speech|cite speech]]}}</code>: </span><span class="cs1-visible-error citation-comment">Unknown parameter <code class="cs1-code">&#124;trans_title=</code> ignored (<code class="cs1-code">&#124;trans-title=</code> suggested) ([[Help:CS1 errors#parameter_ignored_suggest|help]])</span><span class="cs1-maint citation-comment">CS1 maint: extra punctuation ([[:Category:CS1 maint: extra punctuation|link]])</span>
  • {{cite techreport}}
    • Litvac, M. M. (1991). Image inversion analysis of the HST OTA (Hubble Space Telescope Optical Telescope Assembly), phase A (Technical report). TRW, Inc. Space and Technology Group. Bibcode:1991trw..rept.....L.
      • '"`UNIQ--templatestyles-000002C9-QINU`"'<cite id="CITEREFLitvac1991" class="citation techreport cs1">Litvac, M. M. (1991). ''Image inversion analysis of the HST OTA (Hubble Space Telescope Optical Telescope Assembly), phase A'' (Technical report). TRW, Inc. Space and Technology Group. [[Bibcode (identifier)|Bibcode]]:[https://ui.adsabs.harvard.edu/abs/1991trw..rept.....L 1991trw..rept.....L].</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=report&rft.btitle=Image+inversion+analysis+of+the+HST+OTA+%28Hubble+Space+Telescope+Optical+Telescope+Assembly%29%2C+phase+A&rft.pub=TRW%2C+Inc.+Space+and+Technology+Group&rft.date=1991&rft_id=info%3Abibcode%2F1991trw..rept.....L&rft.aulast=Litvac&rft.aufirst=M.+M.&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+9" class="Z3988"></span>
  • {{cite thesis}}
    • Serra, Xavier (1989). A System for Sound Analysis/Transformation/Synthesis based on a Deterministic plus Stochastic Decomposition (Ph.D. thesis). Stanford University. Retrieved 13 January 2012. {{cite thesis}}: Invalid |ref=harv (help)
      • '"`UNIQ--templatestyles-000002CC-QINU`"'<cite id="CITEREFSerra1989" class="citation thesis cs1">Serra, Xavier (1989). [http://mtg.upf.edu/node/304 ''A System for Sound Analysis/Transformation/Synthesis based on a Deterministic plus Stochastic Decomposition''] (Ph.D. thesis). Stanford University<span class="reference-accessdate">. Retrieved <span class="nowrap">13 January</span> 2012</span>.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Adissertation&rft.title=A+System+for+Sound+Analysis%2FTransformation%2FSynthesis+based+on+a+Deterministic+plus+Stochastic+Decomposition&rft.degree=Ph.D.&rft.inst=Stanford+University&rft.date=1989&rft.aulast=Serra&rft.aufirst=Xavier&rft_id=http%3A%2F%2Fmtg.upf.edu%2Fnode%2F304&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+9" class="Z3988"></span> <span class="cs1-visible-error citation-comment"><code class="cs1-code">{{[[Template:cite thesis|cite thesis]]}}</code>: </span><span class="cs1-visible-error citation-comment">Invalid <code class="cs1-code">&#124;ref=harv</code> ([[Help:CS1 errors#invalid_param_val|help]])</span>
  • {{cite web}} - when Periodical is set
    • "Registry for the OpenURL Framework - ANSI/NISO Z39.88-2004". OCLC. Retrieved 2015-09-27.
      • '"`UNIQ--templatestyles-000002CF-QINU`"'<cite class="citation web cs1">[http://alcme.oclc.org/openurl/servlet/OAIHandler?verb=ListRecords&metadataPrefix=oai_dc&set=Core:Metadata+Formats "Registry for the OpenURL Framework - ANSI/NISO Z39.88-2004"]. ''[[OCLC]]''<span class="reference-accessdate">. Retrieved <span class="nowrap">2015-09-27</span></span>.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=unknown&rft.jtitle=OCLC&rft.atitle=Registry+for+the+OpenURL+Framework+-+ANSI%2FNISO+Z39.88-2004&rft_id=http%3A%2F%2Falcme.oclc.org%2Fopenurl%2Fservlet%2FOAIHandler%3Fverb%3DListRecords%26metadataPrefix%3Doai_dc%26set%3DCore%3AMetadata%2BFormats&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+9" class="Z3988"></span>
  • {{cite web}} - when Periodical is not set
    • "Junior Lawyer of the Year 2012". Law Society of England and Wales. 2012. Retrieved 9 September 2015.
      • '"`UNIQ--templatestyles-000002D2-QINU`"'<cite class="citation web cs1">[http://www.lawsociety.org.uk/support-services/events-training/excellence-awards/2012-winners/junior-lawyer-of-the-year-2012/ "Junior Lawyer of the Year 2012"]. [[Law Society of England and Wales]]. 2012<span class="reference-accessdate">. Retrieved <span class="nowrap">9 September</span> 2015</span>.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=unknown&rft.btitle=Junior+Lawyer+of+the+Year+2012&rft.pub=Law+Society+of+England+and+Wales&rft.date=2012&rft_id=http%3A%2F%2Fwww.lawsociety.org.uk%2Fsupport-services%2Fevents-training%2Fexcellence-awards%2F2012-winners%2Fjunior-lawyer-of-the-year-2012%2F&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+9" class="Z3988"></span>

cs2

← click show to view metadata testcases for cs2 templates
  • {{citation}} - when Periodical is not set
    • Turner, Orsamus (1851), History of the pioneer settlement of Phelps and Gorham's purchase, and Morris' reserve, Rochester, New York: William Alling, OL 7120924W
      • '"`UNIQ--templatestyles-000002D6-QINU`"'<cite id="CITEREFTurner1851" class="citation cs2">Turner, Orsamus (1851), ''History of the pioneer settlement of Phelps and Gorham's purchase, and Morris' reserve'', Rochester, New York: William Alling, [[OL (identifier)|OL]]&nbsp;[https://openlibrary.org/works/OL7120924W 7120924W]</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=History+of+the+pioneer+settlement+of+Phelps+and+Gorham%27s+purchase%2C+and+Morris%27+reserve&rft.place=Rochester%2C+New+York&rft.pub=William+Alling&rft.date=1851&rft_id=https%3A%2F%2Fopenlibrary.org%2Fworks%2FOL7120924W%23id-name%3DOL&rft.aulast=Turner&rft.aufirst=Orsamus&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+9" class="Z3988"></span>
  • {{citation}} - when Periodical is set
    • Abdel-Rehim, A. M. (2006), "Thermal and XRD analysis of Egyptian galena", Journal of Thermal Analysis and Calorimetry, 86 (2): 393–401
      • '"`UNIQ--templatestyles-000002D9-QINU`"'<cite id="CITEREFAbdel-Rehim2006" class="citation cs2">Abdel-Rehim, A. M. (2006), "Thermal and XRD analysis of Egyptian galena", ''Journal of Thermal Analysis and Calorimetry'', <b>86</b> (2): <span class="nowrap">393–</span>401</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=article&rft.jtitle=Journal+of+Thermal+Analysis+and+Calorimetry&rft.atitle=Thermal+and+XRD+analysis+of+Egyptian+galena&rft.volume=86&rft.issue=2&rft.pages=%3Cspan+class%3D%22nowrap%22%3E393-%3C%2Fspan%3E401&rft.date=2006&rft.aulast=Abdel-Rehim&rft.aufirst=A.+M.&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+9" class="Z3988"></span>
  • {{citation}} - when Periodical is set by |encyclopedia=
    • Pyle, Andrew, ed. (2000), "Richard Sibbes", The Dictionary of Seventeenth-Century British Philosophers, vol. 2, Bristol: Thoemmes Press
      • '"`UNIQ--templatestyles-000002DC-QINU`"'<cite id="CITEREFPyle2000" class="citation cs2">[[Andrew Pyle (philosopher)|Pyle, Andrew]], ed. (2000), "Richard Sibbes", ''The Dictionary of Seventeenth-Century British Philosophers'', vol.&nbsp;2, Bristol: Thoemmes Press</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=bookitem&rft.atitle=Richard+Sibbes&rft.btitle=The+Dictionary+of+Seventeenth-Century+British+Philosophers&rft.place=Bristol&rft.pub=Thoemmes+Press&rft.date=2000&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+9" class="Z3988"></span>

—Trappist the monk (talk) 19:28, 24 October 2015 (UTC)

I would add that for the book COinS format we should not set rft.pages unless rft.genre=bookitem.
This is because |pages= combines two functions in these templates. For books it typically records the location of a statement being cites, whereas for articles in journals and chapters of books, it typically records the entire span of the article or chapter. Only in the latter case is it the same thing as rft.pages. Kanguole 14:37, 5 November 2015 (UTC)
I'm not exactly sure I understand what you're saying.
According to this, rft.pages is:
Start and end pages for parts of a book, e.g. "124-147". This can also be used for an unstructured pagination statement when data relating to pagination cannot be interpreted as a start-end pair, e.g. "A7, C4-9", "1-3,6". This data element includes the OpenURL 0.1 definition of "pages".
To me, the meaning of This data element includes the OpenURL 0.1 definition of "pages" isn't exactly clear. According to OpenURL 0.1 pages is:
Pages covered by an individual item in a bundle. The format of this field is 'spage-epage'
where 'bundle' and 'individual item' are the values assigned to rft.genre:
'bundle' is journal, book, conference
'individual item' is article, preprint, proceeding, bookitem
Which begets which? If |chapter= is not set then, rft.pages omitted even when |page= or |pages= is set and rft.genre=book? Or, does the existence of |page= or |pages= without |chapter= convert rft.genre from book to bookitem? I think that the former doesn't make much sense because a single page or multiple pages are a subset of a book. It seems silly to require our editors to always include |chapter= in {{cite book}} when they want to cite something on a single page of that book.
Although it isn't explicitly stated in OpenURL 0.1, the example at §6 shows &rft.spage=134 without an accompanying rft.epage. This could mean that we should use rft.spage when the meta-parameter Pages has a single value; use rft.spage and rft.epage when Pages has a simple page range; and rft.pages when Pages has something else. This is complicated by things like |at=Back cover or the misuse of a hyphen as a range separator instead of the proper ndash – which could explain why previous versions of the COinS code dump all page information into rft.pages.
—Trappist the monk (talk) 12:45, 6 November 2015 (UTC)
The example at §6 is a fragment to illustrate syntax rather than the meaning of tags.
As I said above, |page=/|pages=/|at= are used in the templates in two different ways:
  • If we're citing a whole item (e.g. a book), the page number(s) locate the specific statement that is relied upon.
  • If we're citing a part (e.g. an article in a journal, a contribution in a book or a paper in a conference proceedings), the page number(s) delimit the extent of the part. Specifying a particular page or pages within the article is done outside the template, or with short references.
OpenURL 0.1 also distinguishes these two types as bundles (e.g. genres book and conference) and individual items (e.g. genres article, bookitem and proceeding). As laid out in Table 2 of that document, only individual items should set the rft.pages; bundles should not. (Although OpenURL 0.1 has been superseded, the standard refers to it for the meaning of rft.pages.) So indeed I am saying is that in a book where |chapter= is not set, rft.pages should not be included in the COinS metadata, though the page number would still be in the visible text. There is no need for editors to change their practice.
While looking this up, I noticed another infelicity: a paper in a conference proceedings (e.g. the Liskov & Zilles example above) should have genre proceeding, not conference (which would mean the whole book). Kanguole 14:48, 6 November 2015 (UTC)
Perhaps the example at §6 is a fragment or perhaps not. How do we know? Do you have access to more definitive documentation that clearly shows that COinS does not support a single page reference?
Where is it documented that page ranges in cs1|2 delimit the extent of the part and that particular page [specification] is done outside the template? This, to me, is counter intuitive nonsense. An article or chapter title is sufficient to delimit the extent of that part. To also include a page range spanning the whole of the part is unnecessarily redundant and is akin to identifying total number of pages which cs1|2 does not do. If the purpose of a cs1|2 template is to consolidate and render all of the information necessary for a reader to locate, within a source, the information necessary to corroborate a wp article's statement, having the page number where that information may be found is better for the reader than listing all of the article's pages and leaving it to the reader to search for the relevant information. When the wp article uses short form referencing, page numbers are not required in the matching cs1|2 template and should not be included.
{{cite conference}} needs rethinking methinks which is beyond the scope of this conversation. Until that is accomplished, I'm inclined to leave the metadata as they stand. It might be tweaked so that rft.genre=proceeding when |title= and |journal= are set or when |title= and |booktitle= are set.
—Trappist the monk (talk) 11:33, 10 November 2015 (UTC)
I didn't say that COinS/OpenURL doesn't support a single page reference – there's no reason to think it doesn't. I did say
  • rft.pages was intended only for genres like article, proceeding and bookitem that represent part of a larger bundle, but not genres like conference and book that represent a whole bundle (Table 2 in the OpenURL 0.1 spec makes this clear).
  • In those cases, rft.pages holds the page range of the part (see the description of pages in the KEV format matrices; Table 1 in the OpenURL 0.1 spec says Pages covered by an individual item in a bundle).
The use of |pages= to delimit the extent of an article in a journal or a contributed chapter in a book is the common practice on Wikipedia, reflecting the habits of the world outside, and can be seen in the examples in {{cite journal}} and {{cite book}}. Most users of academic referencing would consider citations of these types to be incomplete without the page ranges for the parts. That leaves no way to indicate the specific paces referenced, unless one uses short references or additional text, an issue that has been noted many times. Kanguole 17:01, 10 November 2015 (UTC)
My understanding of the tradition of specifying the page range of the article being cited is that in mid-to-late 20th century if a library didn't have a journal that a patron requested, they would send a request to a library that did have it to make photocopies of the required pages and send them to the requesting library. The person making the photocopies might be any student who had a part-time job at the library, and might the student might not have the skill to decide what pages ought to be copied, so the citation would allow the student employee exactly which pages to copy. Jc3s5h (talk) 17:35, 10 November 2015 (UTC)
I am not trying to put words into your mouth that you did not speak. I am trying to parse apart just what it is that you are saying. When I suggested rft.spage as a solution to the single page problem, you wrote, rather assertively, that the example at §6 is a fragment to illustrate syntax rather than the meaning of tags. From which I infer, perhaps incorrectly, that you know, conclusively, that it is not permissible to use rft.spage alone, without an accompanying rft.epage and thus it is not possible to refer to a single page using COinS as it is currently defined. Hence, the reason for my question: Do you have access to more definitive documentation that clearly shows that COinS does not support a single page reference?
With regard to both of your bullet points, I understand that; I referenced the same thing from the standards docs in a previous post.
I am questioning the 'common practice' if there is such a thing. My position with regard to the examples at {{cite journal}} and {{cite book}} reflects your position with regard to the §6 example I quoted: those are simply bibliographic examples and are not definitive. The actual |page= and |pages= documentation (page & pages) says nothing about delimiting articles and chapters with page ranges. Sure, if you follow a doi or pmc or other link to a website, you will often see that there, the page range is included in the bibliographic information. But, bibliography and citation are not the same thing. For most uses in Wikipedia articles, we are writing citations where editors should be identifying the in-source location of the supporting text for the benefit of the reader. Where an editor is writing a bibliography, in-source location page numbers are not required and delimiting an article or chapter with start and end pages is merely redundant information.
I wonder if this 'common practice' of 'page-range-as-delimiters' arises because of tools like Wikipedia:RefToolbar/2.0 or User:Citation bot which can/will populate |pages= given a doi or pmid or the like. Editors assume the tool's results to be correct and do not edit the tool's results to correctly specify which page or pages support the Wikipedia article's text. These tools also produce consistent results to which editors grow accustomed so correct citations without a delimiting page range will then look 'odd' to them.
—Trappist the monk (talk) 18:30, 10 November 2015 (UTC)

VE messing up language parameter

VE is messing up the |language= parameter. It is adding en-US, en-GB, etc. Articles with this problem are ending up in Category:CS1 maint: Unrecognized language. Examples are [10] and [11]. I've filled ticket T117305.

Also of note, VE is adding nowiki tags inside references. For example, <ref><nowiki>{{cite ... }}</nowiki></ref>. A ticket on that was filed, mysteriously closed and we've reopened it again.

I haven't checked if Content Transcrapulator is doing the same problem. It and VE both use Parsoid, but different versions. So, one has to file two separate bug reports. As only a couple of our groups 40+ tickets have been fixed in 6+ months, so I don't expect this to be fixed anytime soon. Bgwhite (talk) 07:12, 31 October 2015 (UTC)

I thought that Monkbot or BattyBot had an approved task to sweep Category:CS1 maint: Unrecognized language for easy-to-fix errors like |language=español and like the one above, but I don't see that task in either bot's task list. My memory is failing me. – Jonesey95 (talk) 18:10, 31 October 2015 (UTC)
I have an AWB script that does that but haven't run it in a while. I'm doing other work elsewhere with AWB right now so I'll try to remember to run the language script when I'm done with that other task.
—Trappist the monk (talk) 19:01, 31 October 2015 (UTC)
Visual Editor is a complete mess and should be buried deep.
Having said this, wouldn't it make sense to add support for these standardized language codes to the |language= parameter and let the template translate them into something meaningful for display in the citation? It doesn't seem to be much more than adding a long look-up table with aliases. If the value is found in there, it gets replaced, otherwise left as is. In the long run, this would improve machine-readability and the reliable conversion of citations for usage in other language Wikipedias. --Matthiaspaul (talk) 17:01, 1 November 2015 (UTC)
The module uses a call to mw.language.fetchLanguageName () which apparently refers to this php list. That list appears to have all of the ISO 639-1 two-character language codes so it is a convenient way to map codes to readable names. IETF language tags can be rather complicated and as such I didn't want to venture down the path of dissecting that. It is possible that we could extend language code validation to include only ISO 3166-1 alpha-2 country codes. ISO maintains a list of currently assigned code elements so making a Lua look-up table wouldn't be difficult. Then, the test is: for any hyphenated language name in the case-insensitive form ll-cc, ll must be a valid ISO 639-1 code and cc must be a valid ISO 3166-1 alpha 2 country code.
I don't know if there is a list of 'valid' pairings of the items on either side of the hyphen: |language=pt-IS (Portuguese as spoken in Iceland) would pass the just-described test but doesn't make a lot of sense. It's probably not much of an issue but typos do happen. Still, the only thing that would be displayed would be the translation of the ISO 639-1 code (except for English which isn't displayed on en:WP.
—Trappist the monk (talk) 20:04, 1 November 2015 (UTC)
Sounds good to me. --Matthiaspaul (talk) 12:36, 2 November 2015 (UTC)
It is never a good idea to start pruning stored metadata just because one consumer is failing to accept something that it ought to. Andy Dingley (talk) 19:21, 3 November 2015 (UTC)
I don't see where it was suggested to prune any metadata - that would be a bad idea. But yes, |language= should be expanded to accept language codes, as I suggested as well.
--Matthiaspaul (talk) 00:13, 4 November 2015 (UTC)
[12] (and many others by Trappist the monk). That's how I first noticed this issue. Andy Dingley (talk) 16:19, 4 November 2015 (UTC)
I see, thanks. No good. I agree, when the full language specifier isn't known, it should still be accepted (if its format is correct). The code should then ignore the regional sub-variant and just use the main code. --Matthiaspaul (talk) 05:56, 5 November 2015 (UTC)

Since the time of first support for ISO 639-1 codes in |language=, cs1|2 has only supported the two-character code or the language's proper name. There has never been any representation anywhere that IETF language tags or similar extensions are supported. That VE ignores the documentation is not the fault of cs1|2.

I have tweaked Module:Citation/CS1/sandbox so that it ignores IETF language tags:

{{cite book/new |title=Title |language=pt-IS, English, fr-fr}}
Title (in Portuguese, English, and French).

—Trappist the monk (talk) 13:41, 10 November 2015 (UTC)

metadata and identifiers

cs1|2 includes the predefined identifiers, |arxiv=, |doi=, |jstor=, |isbn=, etc in the metadata. Most of these inclusions are wrong.

COinS provides keywords for |isbn= and |issn=: &rft.isbn and &rft.issn. Another keyword, &rft_id supports various forms of url. Which of these two mechanisms we use is specified in the id_handlers table in Module:Citation/CS1/Configuration. Each identifier has a table of stuff unique to that identifier, one bit of which is the COinS entry. When the value assigned to the identifier's COinS entry is info:..., code in Module:Citation/CS1 concatenates info:... and the identifier value and assigns the result to &rft_id. In all other cases, id_handlers[...].COinS is expected to hold something that looks like rft.jfm (the ampersand is added later). For these, the final metadata for |jfm=1234 eventually looks like this: &rft.jfm=1234.

But not all is well in metadata land. There are defined keywords for some of the identifiers that we support but not all. The rft.jfm example above is one-such that is not defined as a legitimate metadata keyword. Also, there are some like |asin= where id_handlers['ASIN'].COinS is set to info:asin. To use the info: uri, the domain name (asin in this case) must be registered at //info-uri.info.

So, in the sandbox I have made some changes:

  1. in Module:Citation/CS1/Configuration/sandbox:
    1. created the keyword pre which tells code in Module:Citation/CS1/sandbox to use id_handlers[...].prefix when creating &rft_id
    2. set id_handlers[...].COinS to nil for identifiers asin, ismn, and ol to keep them out of the metadata
    3. changed id_handlers['LCCN'].COinS from unsupported rft.lccn to supported info:lccn
  2. in Module:Citation/CS1/sandbox:
    1. modified COinS () to distinguish between id_handlers[...].COinS values of info:... and rft...

The identifiers that I have set to nil (asin, ismn, and ol) are problematic. There isn't a place like Special:BookSources that ismn can link to nor is there an external repository so ismn is not included in the metadata. The other two are more complicated.

An ol identifier produces a url path that varies with the value of the last digit of the identifier value ('A', 'M', or 'W' → '/authors/OL/', '/books/OL/', /'works/OL/') which is inserted between id_handlers['OL'].prefix and |ol=. The resultant url is id_handlers['OL'].prefix + '/authors/OL/' or '/books/OL/' or /'works/OL/' + |ol=. I think that it is possible to solve this problem by simply creating three handlers that replace the one that we use now.

Similarly, an asin url can have a variety of top-level domains (.com, .au, .br, .co.jp, etc); there is also a path specifier inserted between the tld and the |asin= value so the url is the concatenation of id_handlers['ASIN'].prefix + |asin-tld= or '.com' + '/dp/' + |asin=. I haven't noodled out a solution for this problem yet.

—Trappist the monk (talk) 14:08, 1 November 2015 (UTC)

Bump to keep this topic from being archived.

—Trappist the monk (talk) 13:00, 10 November 2015 (UTC)