Help talk:Citation Style 1

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

Automatic ISO conversion[edit]

Forgive me if you've heard this one before, but I didn't see in the archives. I frequently add references to articles that are in both mdy and dmy formats and it's a pain in the ass to not have a template doing the format switching for me. This is to say that I would prefer to enter |date=2015-12-18 and have the template detect which format to use (either set within each individual {{cite web}} instance or by detecting some article-wide {{use dmy}} or the like). Is this possible or has it been discussed? I also ask because I'm working on a WP:Citoid browser extension. They're planning to stay in ISO 8601 and instead ask the local template creators to convert the dates, and this seems like the right choice. I use a citation manager for my more academic WP articles and it also spits out ISO format, meaning that I need to manually rewrite the dates or use {{date|2006-08-04|mdy}} around each instance. While page date style detection would be nice, at the very least, it'd be nice to do something like |dateformat=dmy rather than changing three date instances with the {{date}} template (publication date, access date, archive date). Thoughts? czar 19:19, 18 December 2015 (UTC)

Check out User:Ohconfucius/script/MOSNUM dates.js. He still hasn't implemented a "convert all dates in an article to the template version e.g. {{use dmy}}", but it's usually pretty easy to hunt that down on a page. --Izno (talk) 19:40, 18 December 2015 (UTC)
It is generally the case that a template cannot see the universe outside of its bounding {{ and }} so figuring out what the page style is may not be possible. On the otherhand, Scribuntu has this:
which can read the unparsed content of a page. A module can then search for a string, in this case, {{use xxx dates (where xxx is dmy or mdy). It could then render dates according to the page style. I can imagine, though, that this could be costly in terms of processing time or memory consumption so while doable, may not be practical for a large page with a large number of cs1|2 templates.
A date format parameter is certainly an option especially if Citoid is going to use a year-initial date format similar to ISO 8601. I expect that use of that tool will increase as more cs1|2 templates are created with VE which, as I understand it, makes use of Citoid.
Trappist the monk (talk) 13:28, 19 December 2015 (UTC)
At present, assuming we are using the cite xxx or citation templates {{use mdy}} sometimes applies to all the dates, sometimes it applies to the body of the article but not the citations, and sometimes it applies to the body and the publication dates but not the access and archive dates. (The dates that {{use mdy}} would be YYYY-MM-DD format.) So if the templates were to detect and act on {{use mdy}}, it would be first be necessary to propose at Help talk:Citation Style 1 (with notices in other appropriate places) that Citation Style 1 and 2 be changed to make all the dates in the article follow the same format. That would be jut fine with me, but good luck getting a consensus. Jc3s5h (talk) 14:29, 19 December 2015 (UTC)
There has repeatedly been a consensus that ISO dates may be used consistently for access and archive dates, regardless of the format of other dates in the article. So it would not be possible to automate conversion of these dates. Peter coxhead (talk) 15:38, 19 December 2015 (UTC)
Presumably, for the case where we create a new cs1|2 template parameter, |df= perhaps, and for it define certain keywords: dmy, mdy, ymd, dmy-all, mdy-all, ymd-all. Then, the -all keywords would cause the module to apply date formatting to all dates whereas the xxx keywords would not reformat access- and archive-dates.
Trappist the monk (talk) 16:15, 19 December 2015 (UTC)
@Trappist the monk, yes, I really like this |df= solution. (I'm not really interested in pushing for new standardization right now, just to have a method of converting ISO to dmy/mdy easily in my own work.) I would recommend, though, that |df=dmy rather than |df=dmy-all default to changing all three (publication, access, archive) dates to dmy because that's how most people will use it. I suppose that would make dmy-pub the option for only converting the publication date. What's the next step for this proposal? czar 16:53, 19 December 2015 (UTC)
I don't think a df parameter for cite xxx and citation would help. The whole idea is to have the template pick up the date format from information already in the article, rather than having a tool that adds the template figure out what date format(s) to use. So if the idea was to not standardize, and still allow the full range of options that are currently allowed, it is the {{use dmy}} and cousins that would have to change, maybe to something like {{use dmy | scope = s}}} where s = all, not-cites, or pub (pub would make the scope the publication date but not the access date or archive date). Any date specified by a cite xxx or citation parameter that didn't fall within the scope would be YYYY-MM-DD format. Jc3s5h (talk) 17:42, 19 December 2015 (UTC)
I don't think that a page-wide solution is still on the table here. In addition to a page-wide solution, Editor Czar also suggested |dateformat=dmy which is more likely to be acceptable to the editor community as you pointed out.
Trappist the monk (talk) 19:34, 19 December 2015 (UTC)
As a test, I added this code to Module:Citation/CS1/sandbox:
if not is_set (DF) then   -- if date format is not set in the template see if page has {{use xxx dates}} template
  local text = this_page:getContent();                  -- get the page content
  DF = text:match ('{{%s*[Uu]se%s*([Dd][Mm][Yy])') or text:match ('{{%s*[Uu]se%s*([Mm][Dd][Yy])') or text:match ('{{%s*([Dd][Mm][Yy])') or
       text:match ('{{%s*([Mm][Dd][Yy])') or '';
  DF = DF:lower();
The code fetches the unparsed page source and then searches for a match to any of the {{use ... dates}} templates and their redirects and sets meta-parameter DF to the specified format which it then sets to lowercase.
I checked to make sure that the code worked. It does. My next test was to render my testcases page but without adding a {{use ... dates}} template. The testcases page bombed with lua time-out errors. From this I conclude that this mechanism for page-wide date reformatting is impractical.
Trappist the monk (talk) 17:43, 21 December 2015 (UTC)
The cs1|2 date-holding parameters are: |access-date=, |archive-date=, |date=, |doi-broken-date=, |embargo=, |lay-date=, and |publication-date=.
Legitimate date formats are dmy, mdy, ymd, my, y, and various limited combinations of these in ranges. Except for ymd, m can be a full month name or three letter abbreviation. Also supported are seasons and certain named dates. It would seem that for any setting of |df=, the module should convert valid dates to the specified format. No conversions are done if there are any invalid dates because it simplifies things to know beforehand that the dates are in a valid format before converting them to another format.
Date ranges in ISO 8601-like format are not currently supported by WP:DATESNO so are not supported by cs1|2. If Citoid needs to specify a date range will it use the ISO 8601 format? If Citoid needs to specify a season, will it use ISO 8601 format? Is there an ISO 8601 format for seasons? What about dates outside of the Gregorian calendar; does Citoid support those? In what format? In a conversion, how do we specify use of abbreviated month names?
Trappist the monk (talk) 19:34, 19 December 2015 (UTC)
ISO 8601 date ranges can be somewhat convoluted, and imo pretty unappealing aesthetically. Auto-formatting of |access-date=, |archive-date=, and |doi-broken-date= into ISO 8601 through the discussed new parameter sounds like a good idea. For most readers, these dates would fall into the "too technical" category anyway, I think. (talk) 19:55, 19 December 2015 (UTC)
I left a note on the Citoid dev page about those questions, but would it be all right to start with a version of |df= that solely converts ISO to dmy/mdy? And then add other contingencies later? I'm sure Citoid is just working these things out now so the answers will come in time. When I have publications with date ranges (which aren't supported in the template by any means, last time I checked), I just use the first date of the range (November–December 2015 becomes November 2015). czar 23:42, 19 December 2015 (UTC)
Yes, if we do this we can certainly start with just ymd→dmy|mdy.
cs1|2 has supported date ranges in a variety of form for a long time:
{{cite book |title=Title |date=November–December 2015}}
Title. November–December 2015. 
Trappist the monk (talk) 00:32, 20 December 2015 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── Using |df=. Keywords are: dmy, dmy-all, mdy, mdy-all, ymd, ymd-all. The module will reformat single dates among dmy, mdy, and ymd. Ranges, seasons, proper-name dates are not supported. No reformatting if there are date errors.

{{cite book/new |title=Title |date=2015-12-20 |df=dmy}}
Title. 20 December 2015. 
{{cite book/new |title=Title |date=2015-12-20 |df=mdy}}
Title. December 20, 2015. 
{{cite book/new |title=Title |date=20 December 2015 |df=mdy}}
Title. December 20, 2015. 
{{cite book/new |title=Title |date=20 December 2015 |df=ymd}}
Title. 2015-12-20. 
{{cite book/new |title=Title |date=December 20, 2015 |df=dmy}}
Title. 20 December 2015. 
{{cite book/new |title=Title |date=December 20, 2015 |df=ymd}}
Title. 1582-12-20. 

|access-date= and |archive-date= are not converted unless the -all suffix is used with the |df= keyword:

{{cite web/new |title=Title |url=// |date=2010-12-20 |access-date=2012-07-14 |archive-url=// |archive-date=2011-06-04 |df=dmy}}
"Title". 20 December 2010. Archived from the original on 2011-06-04. Retrieved 2012-07-14. 
{{cite web/new |title=Title |url=// |date=2010-12-20 |access-date=2012-07-14 |archive-url=// |archive-date=2011-06-04 |df=dmy-all}}
"Title". 20 December 2010. Archived from the original on 4 June 2011. Retrieved 4 July 2012. 

Trappist the monk (talk) 23:59, 20 December 2015 (UTC)

(meta comment) It seems odd that there is no intra-article global variable facility. That would make this and other intra-article consistency a relative snap. Has it been established that such a facility has insurmountable technical obstacles? If not, perhaps we'd be better off, in the long run, putting our energies into helping that happen? ―Mandruss  04:50, 21 December 2015 (UTC)
  • @Trappist the monk, would you be opposed to swapping dmydmy-pub (or -single) and dmy-alldmy? I think dmy should default to changing all instances, as that will be the most likely use case. czar 05:31, 21 December 2015 (UTC)
The -all suffix is, I think, very clearly understood to mean exactly what it does. A -pub suffix pretty clearly applies to |date= and |publication-date= but not so clear for |doi-broken-date=, |embargo=, and |lay-date=. We must be able to accommodate WP:DATEUNIFY which allows access- and archive-dates in ymd format when all other dates are dmy or mdy so some mechanism is required to support that. I'm not opposed to changing but I do like the very clear an unambiguous nature of -all. Is there a better option than -pub?
While we're thinking about keywords, right now, the module unconditionally reformats to long month names. Do we need to have a mechanism to specify abbreviated month names? (supported in the module but currently hard-coded to reformat to long month names)
What about the case where |access-date= or |archive-date= is in a format different from the format specified in |df= and that format is not ymd:
|access-date=Mmmm dd, yyyy and |df=dmy
Should the module reformat |access-date= to ymd?
Trappist the monk (talk) 11:56, 21 December 2015 (UTC)
Should the module reformat |access-date= to ymd?
Even though I consistently use ymd for |access-date= and the like, I would not like to see any default formatting implemented without more inclusive discussion. To avoid possible future headaches. (talk) 18:34, 21 December 2015 (UTC)
When I asked Should the module reformat |access-date= to ymd? I meant it to be understood to mean reformat |access-date= and/or |archive-date= when present and using a date format different from ymd and different from the format specified in |df=. So, if |access-date=March 15, 2001 and |df=dmy, should the module reformat |access-date=2001-03-15? I asked this because WP:DATEUNIFY says that dates should be the same format except that access- and archive-dates may be in ymd format as long as the other dates are consistent. WP:DATEUNIFY does not allow for a mix of dmy and mdy dates.
Trappist the monk (talk) 23:12, 21 December 2015 (UTC)

If Citoid actually follows ISO 8601, they would format the date for the December issue of a 2011 magazine as 2011-12, which defies the Citing sources guideline. Jc3s5h (talk) 21:35, 21 December 2015 (UTC)

And also WP:MOSDATE#Ranges. --Izno (talk) 22:32, 21 December 2015 (UTC)
I personally wonder if this change is problematic from the Wikipedia:Date formatting and linking poll perspective. --Izno (talk) 22:31, 21 December 2015 (UTC)
What change? The additions of |df= and its attendant code? Reformatting |access-date= and/or |archive-date= as I described in my reply to IP Editor Automatic reformatting to comply with the {{use dmy dates}} family of templates? All or combinations of the above?
Trappist the monk (talk) 23:12, 21 December 2015 (UTC)
What changes would I find troublesome?
  • Making any change outside of a sandbox until either Citoid developers provide a citation that can be made to obey WP:Citing sources and Help:Citation Style 1, or the community agrees to make the necessary changes to "WP:Citing sources" and "Help:Citation Style 1".
  • Any change that would make existing hand-edited templates incorrect or confusing, such as one that uses 2011–12 to mean 2011 through 2012. (And neither editors nor readers are expected to be able to distinguish "–" from "-".
  • The citation or cite xxx templates converting Gregorian dates to Julian dates because a publication bears a Julian publication date and ISO 8601, which Citoid has apparently adopted, always uses Gregorian dates.
In view of the fact that Citoid is only handy for a limited range of citations, those with an identifier that it can use to generate a citation, and it is part of a high-risk project (Visual Editor) that may end up being a total flop, I'm inclined to think it's up to Citoid to find a way to work with the existing citation system, rather than altering the existing citation system to work with Citoid. — Preceding unsigned comment added by Jc3s5h (talkcontribs) 22 December 2015‎ (UTC)
@Jc3s5h, Citoid is only part of this. Even without Citoid, my citation manager (and most publisher RIS data I've found) exports dates in ISO format. This is about accommodating those formats instead of rewriting dates manually. czar 08:10, 22 December |2015 (UTC)
Please tell us (or me) more about your citation manager. In the mean time, we're still talking about a manual step; the editor adding the citation must look at the article, figure out the date format in general, and specifically the citation format for publication dates and the group access dates and archive dates, and add the proposed df parameter. I'm skeptical that this step will be performed. So I think we'll remain where we are today; people who would like consistent style in articles will have to run various scripts or bots to enforce such consistency, independent of editors who add content with no concern for consistent style, whether the new content be infoboxes, citations, or paragraphs in the body of the article.Jc3s5h (talk) 08:59, 22 December 2015 (UTC)
@Czar: I see that we have an article about RIS (file format) which in turn links to this specification. Considering that the specification allows for "Ancient Text" and that there is no mention of ISO 8601 or Julian or Gregorian calendar, and that the earliest supported year appears to be 1, we should infer that so long as dates were originally expressed either in the Julian or Gregorian calendar, whatever date appeared in the publication should appear in the citation, and it is up to the reader to figure out from context which calendar was used. The date format is NOT ISO 8601; the following are examples of RIS date formats:
YYYY/MM/DD/other info
If Citoid intends to rely on the RIS data, it would be a falsification to blindly convert YYYY/MM/DD to ISO 8601 format (that is, to just change the slashes to dashes without considering what the calendar is). Such falsifications are intolerable and Citoid must be banned if it persists in such falsifications.
If Citoid isn't willing to output the correct format for the article, it should output the RIS format (but completely suppress dates with "other info"). The templates could require that citations with slashes in the date contain a df parameter; any citation with slashes in the date and no rf parameter would be displayed with red warnings replacing the date. As for Citoid's plan to eventually use WikiData, the developers should demand WikiData provide a date type that is agnostic about whether the date is Julian or Gregorian, and agnostic about the time zone, since the RIS format is agnostic about these matters. Jc3s5h (talk) 10:07, 22 December 2015 (UTC)
The question was intended for Editor Izno, but I'll answer your points:
  • nothing we do here can compel Citoid developers to do anything; the code supporting |df= specifically requires all date-holding parameters to be error-free before those values are reformatted to the format specified in |df=
  • nothing in this change overrides an editor's decisions; hand-edited templates without |df= are rendered as is, warts, error messages and all; the module cannot rewrite wikitext
  • this change does not convert dates from one calendar to another; |df= only specifies how the date is rendered; cs1|2 emits an error message for dates in the YYYY-MM-DD style where YYYY is earlier than 1582 so for such a template |df= is ignored
Your post caused me to realize that there is a bug in the YYYY-MM-DD error checking code that emits and error message when |date=1582-MM-DD. I have fixed that in the sandbox. The current version of the |df= code will improperly reformat a dmy or mdy Julian date into ymd. I'll fix that.
Trappist the monk (talk) 11:24, 22 December 2015 (UTC)
@Trappist the monk: It is correct to flag all YMD dates with a year less than 1583 as an error. The rational behind the error message is that many readers will infer that YMD dates are ISO 8601 dates, and ISO 8601 requires consent of data exchange partners before expressing any year less that 1583. Jc3s5h (talk) 11:36, 22 December 2015 (UTC)
In this discussion we first addressed the issue of Gregorian and Julian calendars. In that discussion, the demarcation between the two is 1582. The documentation at Help:Citation Style 1#Dates and Check date values in: |param1=, |param2=, ... refers to 1582.
In this version of ISO 8601 (I don't have access to a current copy), 1582 is mentioned four times; 1583, none:
§3.11 Gregorian calendar – "... introduced in 1582 ..."
§ The Gregorian calendar (2×) – "The use of this calendar for dates preceding the introduction of the Gregorian calendar (i.e. before 1582) should only be done by agreement of the partners in information interchange."
§5.2.1 Calendar date – "Values in the range [0000] through [1582] shall only be used by mutual agreement of the partners in information interchange." (this seems to conflict with the others)
The Acceptable date formats table mentions 1583. Our Gregorian calendar article identifies 1582 as the year of introduction and also as the year of adoption by several countries.
For cs1|2, Julian or Gregorian only matters when determining the validity of a 29 February date.
Trappist the monk (talk) 13:18, 22 December 2015 (UTC)
When |df=ymd and the year portion of the source date is earlier than 1582, dates are not reformatted:
{{cite book/new |title=Title |date=December 20, 1582 |df=ymd}}
Title. 1582-12-20. 
{{cite book/new |title=Title |date=December 20, 1581 |df=ymd}}
Title. December 20, 1581. 
Trappist the monk (talk) 13:44, 22 December 2015 (UTC)
What about this:
{{cite book/new |title=Title |date=December 20, 1582 |df=ymd}}
Title. 1582-02-24. 
That is before the Gregorian calendar went into effect.
As for cs1|2 not carrying about dates other than February 29, the templates issue the "Check date values in: |date=" error message for dates earlier than 1 January 1583 if they are in the YYYY-MM-DD format, and should continue to do so because cs1|2 dates are supposed to comply with MOS:DATEFORMAT which says "Use yyyy-mm-dd format only with Gregorian dates from 1583 onward." Jc3s5h (talk) 14:10, 22 December 2015 (UTC)
I think that MOS:DATEFORMAT is wrong. The Gregorian calendar was adopted in 1582 so MOS:DATEFORMAT should permit 1582 ymd dates. You're right, cs1|2 also cares about ymd dates earlier than 1582. It has never cared about the exact date of adoption; neither has MOS:DATEFORMAT.
I think that this is a minor issue because: in general, numeric date formats are not much used in article text; because publication dates in citations, per MOS:DATEUNIFY, are supposed follow article date format or the format specified by a particular citation style; because MOS:DATEUNIFY permits ymd dates in access- and archive-dates, which both require |url= so cannot be meaningful earlier than the late 20th century. A simple insource: search using this pattern insource:/\| *\w*date *= *158[0-9]\-/, found no cs1|2 citations using ymd dates for the 1580s.
Trappist the monk (talk) 15:08, 22 December 2015 (UTC)
If you read Fred Brook's The Mythical Man Month you would have seen that the IBM System/360 Principles of Operation (or whatever it was called at the time) served as a contract between the operating system developers and the hardware developers. A hardware developer wasn't allowed to decide that a required machine instruction wasn't the best way to do it, and build hardware that did something else. I think MOS:DATEFORMAT should serve as a contract among readers, editors, and template developers. Templates should act like one would expect after reading MOS:DATEFORMAT, regardless if the template developer has some quibbles with MOS:DATEFORMAT. Among other things, this gives template developers an idea of what templates might need to change if MOS:DATEFORMAT changes. If this "contract" is ignored, and MOS:DATEFORMAT, the attitude will be "the templates are all over the map anyway, we'll just continue to ignore the mess". Jc3s5h (talk) 17:07, 23 December 2015 (UTC)
I have moved your comment out of my comment.
Of course, were this a hierarchical engineering department where nothing changes without there are reams of paperwork requesting approval from on high, then perhaps such a scheme as you describe might apply. Wikipedia is clearly not a hierarchical organization so there is no 'authority' vested in MOS:DATEFORMAT. We, among ourselves, decide. But you know all of this so I needn't restate it here.
Trappist the monk (talk) 19:55, 23 December 2015 (UTC)
  • Please tell us (or me) more about your citation manager. I use Zotero. Its default WP citation export defaults to ymd (I call this ISO because it's close enough, even if it's not exactly the spec) instead of dmy/mdy, which I think is fair enough. (I looked into this.) My options are to either write a custom WP citation style for each date format (dmy/mdy), which I think would be overkill, or to manually use {{date}} on each ymd date it spits out (which I would consider a very clunky solution). I don't think it matters that my citation matter ingests slashes between dates and converts them to dashes. All that matters is that I get my dates into the right date format for the article with less effort than I need to exert right now. czar 15:48, 22 December 2015 (UTC)
@Czar:Thanks, I have used Zotero too; I wasn't sure if you writing about a citation manager you use, or a citation manager you were creating. I'm sure there are many editors who never refer to any publication printed long enough ago that the publication date would be in the Julian calendar, and who feel no need to think about the possibility of non-Gregorian dates. Jc3s5h (talk) 16:48, 22 December 2015 (UTC)
  • @Trappist the monk and Jc3s5h, what's the next step in moving ahead with this basic |df= param that converts ymd → dmy/mdy (or vice versa, if you want to support it)? I think the other discussions can be worthwhile but I don't see them changing this basic functionality, and since it's apparently already coded in the /new template, I'd like to use it and get back to editing ASAP. czar 16:03, 23 December 2015 (UTC)
Not much happens all that quickly here, so perhaps you are destined for disappointment. Because it is the time for year's-end holidays, we may not have the eyeballs that normally keep us from going too far astray. The owners of those eyeballs should be given the opportunity to have their say. Assuming that there isn't implacable opposition, this change will probably go live sometime around mid-January 2016.
Trappist the monk (talk) 19:55, 23 December 2015 (UTC)
@Trappist the monk, how about now? czar 08:30, 7 January 2016 (UTC)
This is what I wanted to write at that conversation. It didn't come out right. Apparently that flow thing is not ready for primetime:
cs1|2 supports a subset of date formats allowed by the various sections of Wikipedia:Manual_of_Style/Dates_and_numbers#Dates.2C_months_and_years of which Wikipedia:Manual of Style/Dates and numbers#Ranges is a portion. DATESNO is a term often (mis)used to refer to the dates portion of that MOS page because it is a redirect to Wikipedia:Manual of Style/Dates and numbers#Unacceptable date formats. cs1|2 compliance with MOS is specified at Help:Citation_Style_1#CS1_compliance_with_Wikipedia.27s_Manual_of_Style.
cs1|2 do not support ISO 8601-like date-range-formats because MOS only supports YYYY-MM-DD single-date style. At present, cs1|2 will emit an error message if given a YYYY-MM-DD/YYYY-MM-DD range.
It is very common for periodicals to date issues according to season. How does Citoid report those dates? What about dates that are proper names? cs1|2 allows Christmas YYYY as a date because there are periodicals that use that date. How does Citoid report that kind of date?
I don't know how Citoid gets its dates. If Citoid only works with on-line publications where the date of the cited material is guaranteed to be Gregorian, then there is no issue. But, if Citoid can report dates in the Julian calendar then that may or may not be a problem.
Trappist the monk (talk) 10:41, 31 December 2015 (UTC)
The citoid service copies the date from the webpage that it is given. There are "translators" that tell citoid where the date is on the webpage. Originally, if the translator said that the date on Example.Com is two inches to the left of the first picture (or whatever the machine-reading equivalent of that is), then citoid returned whatever was two inches to the left of the first picture as the "date". When feasible, that's now being turned into a standard date format. When not feasible, then you get whatever is in the field that is labeled as a date according to the translator, including "Christmas YYYY" or "Second week of January 2015" or whatever (including foreign languages). Finally, if the date field is empty on the page, or the page has been re-designed and the translator hasn't been updated with information about the new HTML label for the date, then you'll get nothing (e.g., probably at the moment; that website used to return dates right down to the second, but now URLs there aren't returning dates at all).
With the exception of scanned hard copies of old periodicals or books, I would be surprised if you managed to find a URL to a reliable source whose date is before the creation of the world wide web, and astonished if you managed to find one that used the Julian calendar but shouldn't be listed according to the date printed in the publication. Whatamidoing (WMF) (talk) 22:59, 31 December 2015 (UTC)
I don't know the extent to which Citoid is currently implemented in the visual editor, but I tried the visual editor (without saving cnanges) and found that I had a choice of "Automatic" or "Manual" tabs. If one chooses the manual tab, there is no requirement to include a URL and the date is free-form. Jc3s5h (talk) 16:57, 31 December 2015 (UTC)
You can also fill out a citation template under the Manual tab. The "favorites" are listed there, but if you go to "Basic", you can insert any template you want (or use regular text, exactly as if you were typing the bibliographical details straight into the article). Whatamidoing (WMF) (talk) 22:59, 31 December 2015 (UTC)

Just realized that we never resolved the dmy, mdy, ymd, dmy-all, mdy-all, ymd-all situation. My preference would be to have dmy, mdy, ymd default to converting all three dates, because I would think continuity between all three is the common usage. So to accommodate those who do mdy/dmy for the pub date and ymd for the access/archive dates, we could use mdy-ymd and dmy-ymd. I think that would be fair. @Trappist the monk czar 02:44, 11 January 2016 (UTC)

Doesn't |df=dmy-ymd imply the possibility of |df=dmy-mdy or even |df=dmy-dmy or that date ranges could be formatted as 1 January 2016 – 2016-01-11. Yeah, I know, that last seems a bit of a stretch but editors are amazingly creative when it comes to misinterpreting how parameters are to be used. I guess I think that |df=dmy-all is to be preferred because of its simple clarity.
Trappist the monk (talk) 13:29, 11 January 2016 (UTC)
@Trappist the monk, I expect there to be much greater confusion when |df=dmy converts a single field instead of all fields. While it's nice to support editor choice to use ymd for the access/archive dates, it's far more common to see the same format used throughout the citation. Anyone looking for dmy-ymd (and who is familiar with that rule) will not be confused by that option, which they would expect to not be the default, but those who want dmy throughout will be confused when their param only changes the first of three dates. Eh? If I am unconvincing, a potential compromise could be to not use unhyphenated dmy/mdy/ymd at all and only use dmy-all and dmy-ymd or something along those lines. Appreciate your help with this czar 21:26, 17 January 2016 (UTC)
it's far more common to see the same format used throughout the citation – I've no idea what the situation is across the English Wikipedia as a whole, but in areas that I edit, YYYY-MM-DD seems to me at least as common for access/archive dates, if not more common. Peter coxhead (talk) 10:33, 18 January 2016 (UTC)
I imagine a tracking cat could get metrics on this, if necessary czar 05:37, 20 January 2016 (UTC)
@Trappist the monk, thoughts? And as much as I don't like the proposed param scheme, I'd really like to start using this param (in any form) as soon as possible, if that implementation is still scheduled to go through czar 05:00, 26 January 2016 (UTC)
This went live 16 January 2016 as announced.
Trappist the monk (talk) 13:19, 26 January 2016 (UTC)

Cite episode - series[edit]

In {{Cite episode}}, |series= is required. This causes problems when it is used for one-off programmes. Please make the parameter optional. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:48, 1 January 2016 (UTC)

That's like citing a book's chapter without naming the title of the book, isn't it? Doesn't 'episode' imply, by definition, that it is one of a collection or |series= of other 'episodes'?
{{cite AV media}} instead?
Trappist the monk (talk) 20:25, 1 January 2016 (UTC)
Logically, a one off programme may be considered a single-episode series; the cite episode template documentation opens with "This Citation Style 1 template is used to create citations for television or radio programs and episodes." (my emphasis; perhaps the template would be better named as "Cite broadcast"). Furthermore, {{cite AV media}} lacks several relevant parameters. [BTW, your sig still includes the blank line, about which I've written on your talk page more than once; I've fixed this instance, but please fix it at source, per WP:LISTGAP ]. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:39, 2 January 2016 (UTC)
Although I agree that {{cite episode}} may be too specific (along with {{cite DVD notes}}, etc.), I wouldn't call a one off programme "a single-episode series". Any more than a book is a "single-volume series". (talk) 20:34, 2 January 2016 (UTC)
I wouldn't call it one either - nor did I. I said "Logically, a one off programme may be considered a single-episode series" (emphasis added for clarity). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:19, 4 January 2016 (UTC)

Can anyone help to resolve this?? User:Trappist the monk? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 00:08, 19 January 2016 (UTC)

newsgroup addresses[edit]

With the changes to get url detection and validation correct, I broke the validation of |newsgroup=. The module makes an external link from the contents of |newsgroup= so:



[news:comp.sys.atari.8bit comp.sys.atari.8bit]

The module then tests news:comp.sys.atari.8bit to see if it is valid using the same code that validates URLs. But, the order of things in a newsgroup and a URL are reversed. Where the top level of the hierarchy for a URL, .com for example, comes at the end, the top level of the hierarchy for newsgroups comes at the beginning. The live module is seeing the digit in .8bit as a malformed TLD

Cite newsgroup compare
{{ cite newsgroup | newsgroup=comp.sys.atari.8bit | date=1987-05-12 | author=Harris, Neil | title=Re: Is Atari killing the 8 bit? | message-id=730@atari.UUCP | url=!original/comp.sys.atari.8bit/CHaivDd-Hy4/zNYxPzguppgJ | accessdate=27 January 2015 }}
Live Harris, Neil (1987-05-12). "Re: Is Atari killing the 8 bit?". Newsgroupcomp.sys.atari.8bit. Usenet: 730@atari.UUCP. Retrieved 27 January 2015. 
Sandbox Harris, Neil (1987-05-12). "Re: Is Atari killing the 8 bit?". Newsgroupcomp.sys.atari.8bit. Usenet: 730@atari.UUCP. Retrieved 27 January 2015. 

I've short-stopped the test so that when the scheme is news:, the rest of the newsgroup link must begin with a letter, may be followed by any combination of letters, digits, and dots, and must not end with a dot.

Does anyone know where the can find the real specification for newsgroup addresses?

Trappist the monk (talk) 12:59, 6 January 2016 (UTC)

Perchance, here ? (talk) 20:50, 6 January 2016 (UTC)
Excellent! That reference led to RFC5536 §3.1.4 which does have what I want. Module modified accordingly. Thank you.
Trappist the monk (talk) 22:01, 6 January 2016 (UTC)

@Trappist the monk: Is there a way to fix these newsgroup links:

... or should I just remove the parameter?

Wbm1058 (talk) 19:01, 13 January 2016 (UTC)

Nothing wrong with the first one except that perhaps it should also include its |message-id=1994Jun29.002412.4803@rivers:
Jim Hall (June 29, 1994). "PD-DOS project *announcement*". Newsgroupcomp.os.msdos.apps. Usenet: 1994Jun29.002412.4803@rivers. 
The second doesn't appear to be a usenet newsgroup. |newsgroup= is intended hold the value from the message's Newsgroups: header (comp.os.msdos.apps in the first example – see here). The template adds the news: scheme to make the complete url → news:comp.os.msdos.apps. |newsgroup=Freedos-devel doesn't produce a valid usenet newsgroup address so we get the error.
For the second example, perhaps {{cite mailing list}} should be preferred. Of course, you can always fall back on {{cite web}}.
Trappist the monk (talk) 21:10, 13 January 2016 (UTC)

Add exception? Do not find out where..[edit]

"registration: For online sources that require registration"->"For online sources that require (note, some allow to read a few articles, then not needed) registration". E.g. New Scientist, is that way, and people may not know/remember that it applies after looking up some articles. This may not even be the best example, as I'm not sure if I didn't see all of the first articles, I guess then this applies.. comp.arch (talk) 18:31, 11 January 2016 (UTC)

If I understand correctly you want to cite a source that allows limited access after which registration is required? I would not characterize this as a free-access source. I would set |registration=yes and add a note after the citation stating that open access is limited, using {{link note}} as in (limited open access). (talk) 19:27, 11 January 2016 (UTC)
No, limited access before registration. I'm not sure registration= is for that. I didn't check, I assume there is full access after the registration. Should such sites be labeled, as you might not need to register (that is offputting to many..) in case it's the first article at that site you are looking up. comp.arch (talk) 11:24, 12 January 2016 (UTC)
If a source will require registration at some uncertain future point, it is prudent to be rid of the uncertainty by bringing that future point to the present. It is better to make an error on the side of caution. That is why it was suggested to set registration and have a link note explaining that the registration requirement may be conditional or that free access may be temporary (a source that requires registration is not considered "free" even when it gives full access. You "pay" by providing information, which makes it an exchange, not a grant).
Or, you can lobby here for alternative parameter renderings such as "registration may be required", etc. (talk) 18:42, 12 January 2016 (UTC)

Template to use for TV guides[edit]

I have access to two TV guides provided to me by my TV distributor. The first is viewable on the TV and lists "Original air date" for programs. The second is viewable online and lists "First aired" for programs. These mean the same things and the date matches up, it's just a difference in formatting.

I am trying to use both of these guides as a reference to support the original air dates of a TV program called Little Charmers on the Canadian "Treehouse" channel. You can see the shots at where I wrote the key phrase overtop of the image.

The only thing is I do not know what template is best to use. A digital TV guide accessed via your TV interface is not example a "cite web" but what to call it? An encyclopedia? A report? A press release?

The online version of the guide I guess technically is on the web, but because viewing this version of the guide requires logging in (a simpler TV guide is viewable without logging in but does not convey detailed info like original air dates) it is not a URL I can simply give out to others or feed into Wayback Machine or something.

It is kind of like when someone will cite pubMed or something for a paper but the paper is only available to those who purchase it or have a subscription. Technically it is there but it is not available freely to all.

However since I took a screenshot of the program on it, I would like to convey it this way.

All I can think to do in this case is use archive-url and feed my IMGUR screenshot into that (to function as an archive) and put a simplified form of the URL in (minus my account number since that is sensitive information) as the original URL. I don't know any other way to put two URLs into a template.

Any other suggestions? (talk) 03:41, 14 January 2016 (UTC)

You might want to raise this topic at WT:TV. Editors there may be better able to assist you. It is perfectly legitimate to cite something behind a pay or registration barrier as long as that source qualifies as WP:RS.
Trappist the monk (talk) 11:42, 14 January 2016 (UTC)

Regards the web citation, using imgur in such a fashion is linking to a known (albeit good-faith) copyright violation. This is not an acceptable option. Link to the page dedicated to the guide as if you were logged in, and set |subscription=yes.

Regards the TV citation, {{cite episode}} or {{cite AV media}} seem acceptable, but I'd defer to WP:TV as suggested.

If you can for either of these two options, see if you can find a copy of TV Guide (American TV guide booklet; not sure if there's a Canadian equivalent or if it's the same publication) for the date. --Izno (talk) 12:18, 14 January 2016 (UTC)

We had TV Guide (Canada) which I remember getting as a kid but it stopped publication in 2006, I think distributors only use digital guides via the TV or their website nowadays. I regret not collecting it like that guy on Seinfeld when it comes to sourcing the air dates of certain old series I love. No help in sourcing series of the last decade or so though.

Seeing as how the episode itself does not list a debut date, the guide is the only source I can think of for this since most TV reviers are only giving the Nick dates for U.S. debuts even when they debut first in Treehouse in Canada. AV media sounds closer, did not know about the subscription thing. I guess the trouble is, if someone ever goes back and checks it, even if they did have a subscription, once the episode actually airs it will not be listed and 'original air date' will not be viewable unless they know where to locate a rerun so they can click on it. This is easy enough using the 'search' function on the TV to scroll a list and find the title you're looking for but not sure how easy it would be on the website. Also there's really no specific URL it's just a basic URL where you access your subscription-based guide.

Aside from the more extensive data (original air date) the subscription-guide also goes further into the future. The non-subscrubed guide for example when I checked last night stopped at Jan 21 while the sub-based one went up to around Jan 28. Will bring it up at the TV wikiproject as suggested. I have to wonder though: is it copyvio or fair use when we are simply showing a brief snapshot of a guide verifying the air date by a distributor? (talk) 20:21, 14 January 2016 (UTC)

If you can't do the equivalent by logging onto a website, then I think cite AV media would have to do. The postscript= parameter would outline all the steps you took to get to the information. Same issue if you have to cite content that is only accessible by an app. AngusWOOF (barksniff) 00:04, 15 January 2016 (UTC)

Order of (Map) and (PDF) in Cite map[edit]

I've noticed that in {{Cite map}}, PDF format maps cited with |title=, |map= and |map-url= will display "(Map) (PDF)", while those that can be cited with just |title= and |url= will display "(PDF) (Map)". I would have though that the order should be consistent. - Evad37 [talk] 03:20, 17 January 2016 (UTC)

Cite map compare
{{ cite map | url= | title=Title }}
Live Title (PDF) (Map). 
Sandbox Title (PDF) (Map). 
Cite map compare
{{ cite map | map=A Map | title=Title | map-url= }}
Live "A Map" (Map) (PDF). Title. 
Sandbox "A Map" (PDF) (Map). Title. 
Yep. Fixed in the sandbox.
Trappist the monk (talk) 11:01, 17 January 2016 (UTC)
Thanks - Evad37 [talk] 13:47, 17 January 2016 (UTC)

Access dates disappearing from citations when DOI or JSTOR etc. are set[edit]


access-date is not required for links to copies of published research papers accessed via DOI or a published book,
— Help:Citation Style 1#Access date

Where was the discussion to make the non-requirement obligatory? Apart from the fact that there is no such thing as a "stable" or "fixed" http link, it makes the continuous existence of doi-broken-date incomprehensible. Please restore to previous (and discuss first). (talk) 15:44, 18 January 2016 (UTC)

  1. The text you quote was added to Help:Citation Style 1 with this edit; the edit summary refers to the standard documentation used by all cs1|2 templates: Template:Citation Style documentation/url
  2. There, the first text that approximately equates to your quote was added with this edit. The edit summary refers to a discussion; perhaps this one.
  3. The text in your quote appears with this edit and has since remained unchanged except that a hyphen was added to the parameter name.
  4. |access-date= without |url= is an error. Detection of that error condition first appears in Module:Citation/CS1 with this edit. As a result of that edit, when |url= is not set and |accessdate= is set, the internal variable AccessDate is set to nil and so not displayed in the rendered citation. This functionality has not changed.
Trappist the monk (talk) 18:05, 18 January 2016 (UTC)
I don't understand the first 3 points above. I am not questioning the help text. I am questioning the fact that it differs from what is actually happening. Access date is not now allowed when these identifiers are set, even though the help text does not state that. It doesn't state that is disallowed as it happens now, only that it is not required.
[4.] |access-date= without |url= is an error
This is specious. Of course there is a url, it is masked behind the identifier. This brings up a new inconsistency. Either all links may be accompanied by an access-date or none should be. And I do believe that |access-date= co-existed peacefully with |jstor=, |doi=, etc. until the latest update. What happened?
And to repeat: no link is "stable". If there is such a thing, then the parameter |doi-broken-date= is superfluous. Which one will it be?
Was there a discussion about this? I don't seem to recall any. (talk) 21:10, 18 January 2016 (UTC)
I didn't say there wasn't a url; I said that |access-date= without |url= is an error. The requirement for |access-date= is that there must be a value assigned to |url=.
Here is a diff of the latest update to Module:Citation/CS1. Search for this string (you should not find it in the diff but will find it in the code):
Test if accessdate is given without giving a URL
Also, for completeness, search for that string in the live module and in the previous revision. Compare the code in the two versions. There was no change this long-standing code. (there will be next time because I'm going to clean up the extraneous --and comment)
If |access-date= is to apply to the identifiers as well as to |url= to which should it apply in the event that there are multiple identifiers? pmid, doi, pmc, zbl, isbn, ...? For scientific and medial articles, multiple identifiers are common. Are you suggesting that we need an access-date for each?
Certainly, nothing is ever perfect, so yeah, sometimes a doi breaks. I haven't spent any substantive time checking those dois with |doi-broken-date= to see if the broken parameter was added because the doi is truly broken or if the doi has a typo and the editor misdiagnosed the problem. There may be editors watching this page who can speak to that. If not, there's a research project for you.
I know that this access-date and identifiers topic has come up before. Search the archives of this page and you will likely find some.
Trappist the monk (talk) 22:37, 18 January 2016 (UTC)
Just to add my support for the status quo: yes, doi's sometimes don't work, but we don't want to have access dates for all the identifiers (jstor can be added to Trappist's list above), and there's absolutely no logic in having one for doi and not for the others. Peter coxhead (talk) 09:38, 19 January 2016 (UTC)
Will get back to this after I have time to go through the code (not just the main module but also the subroutines). I might be wrong, but I remember |access-date= coexisting with |doi= and |jstor=.
Prior discussions on access date are somewhat convoluted and largely inconclusive as far as I can tell.
If |access-date= is to apply to the identifiers as well as to |url= to which should it apply in the event that there are multiple identifiers? pmid, doi, pmc, zbl, isbn, ...? For scientific and medial articles, multiple identifiers are common. Are you suggesting that we need an access-date for each?
Depends on the accessed version, imo. If all identifiers point to the same version, only one date is needed. If identifiers point to different versions this should be made explicit, even when the different versions support the extract of the source cited in the Wikipedia page. (talk) 16:28, 19 January 2016 (UTC)
Will get back to this after I have time to go through the code (not just the main module but also the subroutines)
Or perhaps someone would be kind enough to direct me to the module(s) and code that suppresses |access-date= when certain identifiers are set. I am stating "certain" because this does not happen in the case of |isbn= or |issn= for example. (talk) 19:53, 19 January 2016 (UTC)
I'm confused. Here is a nonsense template; the issn and isbn are valid but not related; there is an access date without |url= which gives us the '|access-date= requires |url= (help)' error message and does not render the access date:
{{cite book |title=Title |issn=0028-0836 |isbn=123456789X |accessdate=2016-01-19}}
Title. ISBN 123456789X. ISSN 0028-0836. 
The meta parameter AccessDate is set to an empty string when the cs1 template is {{cite arxiv}} (line 2097) and it is set to an empty string as I described above (line 2355). That's it.
Trappist the monk (talk) 20:16, 19 January 2016 (UTC)
First, thank you.
Secondly, I was in error with my latest comment, and I thought I did strike it out, but I guess I didn't. I did find the routine in the main module, I quote loosely: if is_set(AccessDate) and not is_set(ChapterURL) then table.insert( z.message_tail, { set_error( 'accessdate_missing_url', {}, true ) } ); AccessDate = '';
As there are several remappings, and the porting to the new modules (and also new routines such as the DF stuff), it makes this slow going on my part. I will look into them. If anything turns up I will continue at the proper page, not here.
Cursorily looking at Module:Citation/CS1 and Module:Citation/CS1/Identifiers I don't see anything that contradicts what you say. It seems my memory was playing tricks with me. (talk) 20:52, 19 January 2016 (UTC)
The behaviour is correct. You don't need accessdates with static resources like jstor, bibcodes, and dois. Headbomb {talk / contribs / physics / books} 20:07, 19 January 2016 (UTC)
I dispute there is any http link that is "static". As far as identifiers go, even ISBNs change or are reassigned. But this was not my point. I think it is confusing to consider doi stable and also include doi-broken-date as an option. The other objection was probably a mistake on my part. (I thought identifiers and access dates coexisted in the previous version). (talk) 20:52, 19 January 2016 (UTC)
From the {{cite journal}} documentation: |doi-broken-date=: "Date the DOI was found to be non-working at". In my experience, this parameter is most often filled in by Citation Bot when it tries to look up the DOI and fails to find data. This typically happens (a) when the DOI is not and has never been valid, or (b) when the DOI is valid but the article has not been linked to the DOI database yet, often because it is new. I can't recall coming across a DOI that used to work at but has stopped working. In any event, the solution to getting it to work again is to report it to or and ask them to get it linked back up. |access-date= should not matter in this context, since the underlying journal article remains unchanged, unlike other web-based resources. – Jonesey95 (talk) 21:31, 19 January 2016 (UTC)
I did not suggest that broken DOIs are an everyday occurrence. But keep in mind that DOIs may link to material hosted at a 3rd party. For example, JSTOR also provides DOI links to material, sometimes in addition to JSTOR's own id scheme, sometimes not. Recently I came across a DOI for a journal's archive that was previously hosted at an information provider/aggregator. The hosting company decided to drop the journal archive, and as far as I know, nobody has picked it up yet (I did try to find out through My original complaint (which was partly wrong) had more to do with the confusing language at WP:CS1 and the incongruous (imo) existence of doi-broken-date. (talk) 22:07, 19 January 2016 (UTC)
It's not that the http link is static. It's that the source you are citing is. If I cite D. Sobral; et al. (2014). "Evidence for PopIII-like Stellar Populations in the Most Luminous Lyman-α Emitters at the Epoch of Reionization: Spectroscopic Confirmation". Astrophysical Journal 808 (2): 139. doi:10.1088/0004-637X/808/2/139.  , I'm referring to the article identified by the doi. This article will not change. You can come back 24 years from now and it will still be the same article. Accessdate are required for citing a web page. A scientific article is not a web page, although it may be hosted on one, so it does not require an accessdate. Headbomb {talk / contribs / physics / books} 22:16, 19 January 2016 (UTC)

────────────────────────────────────────────────────────────────────────────────────────────────────Surely, doi etc. is a link identifier? And if the link is not accessible or has changed, then access to the source is affected. If the link is wrong, effectively the source has changed: it is no longer there. Then, the citation as previously formatted is unverifiable. (talk) 15:03, 21 January 2016 (UTC)

Please re-read the responses above. The source has not changed and cannot change. It is a published journal article. |access-date= applies only to web-based sources whose content may change. – Jonesey95 (talk) 15:08, 21 January 2016 (UTC)
I am looking at a citation. It claims that something has been published in a journal. It may also claim that specific things in the article that includes the citation are in specific places at this published source. How am I to verify that? The journal may be obscure/otherwise hard to come by. If a link is given that points to a way of verifying the citation, then this is not a "convenience". It is necessary, in order to verify the claims of anonymous editors (as all Wikipedia editors are). One can reasonably say that then, and only then, do the cited claims become encyclopedic facts. For the person trying to verify all this, an inaccessible link means an inaccessible source, which makes the cited claims unverifiable. If there is an access date for a previously working link, it will give the enquiry a s suitable starting point. You can consider then whether information about the link's accessibility, state, and past history is important. (talk) 22:34, 21 January 2016 (UTC)
It is perfectly legitimate to cite a journal article with no online link at all. The link is only a courtesy to allow readers to find the journal online. The journal title, publication date and page numbers, and other print publication data (including ISSN if it's an obscure journal that would otherwise be hard to find) are the parts that are necessary for verification. —David Eppstein (talk) 23:02, 21 January 2016 (UTC)
Nobody disputes the legitimacy of doing the absolute minimum. Or the facility (as in ease) of adding citations that may be difficult to verify, or incorrect about the citation content, intentionally or unintentionally. This is not about the correct citation format, but about the content the citation is pointing to. Imo, the formatting guidelines (this page's parent) negatively affect verification in this case. (talk) 23:28, 21 January 2016 (UTC)
The access date of a mutable url is useful so that, when you look up a deadlink on, you can tell which of multiple different archived versions is the one you should be referring to. That argument is invalid for dois, because dois are not mutable: they are supposed to only ever refer to a single document, and the exceptions are rare enough that we don't need to worry about them much. In other words, this field is useless both for the binary question of whether a reference is or is not verifiable (which can be satisfied without any online link), and for the reader convenience in actually carrying out a verification (because there is no use the reader can make of the access date). —David Eppstein (talk) 00:25, 22 January 2016 (UTC)
I disagree, but I have nothing more to add to my position as stated in the comments above. (talk) 14:22, 22 January 2016 (UTC)

This page is way too complicated.[edit]

There are a ton of options that aren't even related to a series like chapters. Also parameters are divided by category which makes it difficult to figure out where the parameter is that you need. Isn't there a way to link from the parameter set to its explanation? I mostly make text and grammar corrections, or add sources, so I'm not a wikification genius. I'm sure someone out there knows how to do this. As more parameters are added to Wikipedia this pages become completely overloaded with information. Soon people won't want the hassle of citations. Just saying. MagnoliaSouth (talk) 12:28, 19 January 2016 (UTC)

I'm not sure that I understand your first sentence.
I think that you are suggesting that we should have some sort of list of all parameters with their definitions and some mechanism to cross-reference or index by some generic term. Am I close?
Yes, the cs1|2 templates are complex, have a lot of parameters, and the documentation at best, is lamentable. Your help in fixing that would be much appreciated.
Trappist the monk (talk) 12:39, 19 January 2016 (UTC)
A lot of the parameters do have anchors, these are normally of the form "csdoc_xxx", where xxx is the parameter name. For example: Template:Cite journal#csdoc_author; Template:Cite magazine#csdoc_date; Template:Cite book#csdoc_page; Template:Cite web#csdoc_url. Not all parameter names are covered in this way, there are too many aliases to do it sensibly. --Redrose64 (talk) 17:58, 19 January 2016 (UTC)

|language= parameter internationalization[edit]

On and off I've been working with editors at other-language wikis to adapt our module suite to their needs. As part of that I have discovered that the spoof required to properly render the ISO 639-1 code no is no longer required. Calls to mw.language.fetchLanguageName('no', 'en') now returns Norwegian as it should.

  • {{cite book/new |title=Title |language=no}}Title (in Norwegian). 

I have tweaked the language support code to get the current wiki's language code and name so that languages are rendered in the local wiki's language. These examples were taken from our language parameter code at the Bosnian wiki (bs:Modul:Citation/CS1/igralište – their sandbox):

  • {{cite book/new |title=Title |language=no}}Title (in norveški).
  • {{cite book/new |title=Title |language=nn}}Title (in norveški njorsk).
  • {{cite book/new |title=Title |language=nb}}Title (in norveški bokmal).
  • {{cite book/new |title=Title |language=en}}Title (in engleski).
  • {{cite book/new |title=Title |language=bs}}Title.
  • {{cite book/new |title=Title |language=bosanski}}Title.

the same examples here:

  • {{cite book/new |title=Title |language=no}}Title (in Norwegian). 
  • {{cite book/new |title=Title |language=nn}}Title (in Norwegian Nynorsk). 
  • {{cite book/new |title=Title |language=nb}}Title (in Norwegian Bokmål). 
  • {{cite book/new |title=Title |language=en}}Title. 
  • {{cite book/new |title=Title |language=bs}}Title (in Bosnian). 
  • {{cite book/new |title=Title |language=bosanski}}Title (in bosanski). 

Trappist the monk (talk) 11:50, 20 January 2016 (UTC)

Neat. I'm curious: Is the "in" part of the language description coincidentally the same in Bosnian and English, or is that part not internationalized yet? —David Eppstein (talk) 19:13, 20 January 2016 (UTC)
The 'in' part is handled by this line in bs:Modul:Citation/CS1:
return (" " .. wrap_msg ('language', name));
where 'language' is the index into the citation_config.messages table in bs:Modul:Citation/CS1/Configuration which contains this line:
['language'] = '(jezik: $1)'
wrap_msg replaces the $1 with the value of name. ("So that, as clear as is the summer's sun."—Canterbury; Henry V, Act 1, Scene 2)
In short, editors must translate the various static text for use in their wiki; this is one of the primary purposes of the Configuration module.
The Bosnian sandbox modules are slightly modified versions of the sandboxen so that is why my examples above used 'in' and not 'jezik:'. Date validation involving dots in odd places, dots required for month abbreviations except when they're not required is the primary issue with internationalization of the modules.
Trappist the monk (talk) 20:01, 20 January 2016 (UTC)
  • Thanks for fixing "language=cn" for China: I have been editing some Chinese text inside {cite_web}, so I needed "cn" for China as follows:
  • {{cite book/new |title=Title |language=cn}}Title (in cn). 
I'm not sure what code to use for China. Thanks again for taking time to add those major languages codes. -Wikid77 (talk) 01:23, 22 January 2016 (UTC)
If you follow the link in the error message, you'll get to List of ISO 639-1 codes, where you can do a find for "Chinese", which is "zh". – Jonesey95 (talk) 04:15, 22 January 2016 (UTC)

presentation tweaks[edit]

In Module:Citation/CS1/Configuration/sandbox we keep static text, usually html and css, that is applied to various portions of the rendered citation. I have just moved the <cite>...</cite> tag and COinS <span>...</span> tag code to there from Module:Citation/CS1/sandbox. This change does not effect how the citations render but is merely better coding practice. Some simple comparisons without and with |ref= set:

Title. 20 January 2016. 
<cite class="citation book">''Title''. 20 January 2016.</cite><span title="ctx_ver=Z39.88-2004&" class="Z3988"><span style="display:none;">&nbsp;</span></span>
Title. 20 January 2016. 
<cite id="CITEREF2016" class="citation book">''Title''. 20 January 2016.</cite><span title="ctx_ver=Z39.88-2004&" class="Z3988"><span style="display:none;">&nbsp;</span></span>

comparing live metadata to sandbox metadata:

<cite id="CITEREF2016" class="citation book">''Title''. 20 January 2016.</cite><span title="ctx_ver=Z39.88-2004&" class="Z3988"><span style="display:none;">&nbsp;</span></span>
<cite id="CITEREF2016" class="citation book">''Title''. 20 January 2016.</cite><span title="ctx_ver=Z39.88-2004&" class="Z3988"><span style="display:none;">&nbsp;</span></span>

Trappist the monk (talk) 18:51, 20 January 2016 (UTC)

Good. Yesterday, I saw the references to the sandbox while looking at the live module code and I was a bit mystified. (talk) 22:59, 20 January 2016 (UTC)

url again[edit]

In the Module:Citation/CS1/sandbox I have tweaked the code in split_url() to properly handle urls with queries (? delimiter) or fragments (# delimiter) but without paths (/ delimiter) :

Cite web compare
{{ cite web | | title=120° Parhelia | author= | accessdate=2009-03-08 | url= }}
Live "120° Parhelia" Check |url= value (help). Retrieved 2009-03-08. 
Sandbox "120° Parhelia". Retrieved 2009-03-08. 

Trappist the monk (talk) 13:38, 21 January 2016 (UTC)

Nice. (talk) 14:26, 22 January 2016 (UTC)

Cite gateway templates for French cites[edit]

The cite-gateway templates to other languages do not affect wp:CS1, but I am working on an actual {Lien_web} to auto-translate the myriad of French {Lien_web} parameters+dates into {cite_web} format. For example, our CS1 "url=" can be French "url=" (not "URL=") or "url texte=" or "lire en ligne=" to set the external link. Several new French pages have appeared here on enwiki, and I have tried to quickly hand-edit those pages, but too many wp:edit_conflicts wasted hours, and so the cite-gateway templates for French are needed to handle fr:Template:Lien_web and fr:Template:Ouvrage etc. The French also have subtitles as "sous-titre=" to append after title "<title> : <sous>" and similar for chapter as "sous-chapitre=" among a dozen other "new" parameters. The French cites also wp:autofix dates, such as "date=July 6, 2015" on French WP will auto-translate to show typical French date "6 juillet 2015" etc. -Wikid77 (talk) 01:36/01:38, 22 January 2016 (UTC)

I use an AutoEd script to make short work of copy-paste French (and other language) citation templates. I haven't been able to monitor the unsupported parameter category lately. Maybe a bot could do a daily pass through that category to translate foreign-language citations. My script should be easily portable to AWB. – Jonesey95 (talk) 04:19, 22 January 2016 (UTC)

Template alias {{Cite contribution}}[edit]

An alias of {{cite encyclopedia}}, and a useful one, imo. However it does not support |contributor= which seems counterintuitive. Any plans of adding the parameter to this? (talk) 14:41, 22 January 2016 (UTC)

"Check title= value" links to param-link error[edit]

I'm confused about the error messages here and how to fix them. I found this citation in Bayou Country.

Cite AV media notes compare
{{ cite AV media notes | last=Selvin | others=Creedence Clearwater Revival | id=FAN-30877-02 | titlelink=Bayou Country | first=Joel | type=CD booklet | publisher=[[Concord Music Group]] | year=2008 | authorlink=Joel Selvin | location=U.S.A. | url= | title=Bayou Country [Expanded Reissue] }}
Live Selvin, Joel (2008). Bayou Country [Expanded Reissue] (PDF) (CD booklet). Creedence Clearwater Revival. U.S.A.: Concord Music Group. FAN-30877-02 |url= missing title (help).  Check |title= value (help)
Sandbox Selvin, Joel (2008). Bayou Country [Expanded Reissue] (PDF) (CD booklet). Creedence Clearwater Revival. U.S.A.: Concord Music Group. FAN-30877-02 |url= missing title (help). 

I see "|url= missing title (help). Check |title= value (help)". There is a title, and the second help link leads to the param-link error explanation. I'm guessing it has to do with the single square brackets in the title parameter. – Jonesey95 (talk) 22:56, 22 January 2016 (UTC)

Yes, the brackets are causing the title value error but not the url error.
Cite AV media notes compare
{{ cite AV media notes | last=Selvin | others=Creedence Clearwater Revival | id=FAN-30877-02 | titlelink=Bayou Country | first=Joel | type=CD booklet | publisher=[[Concord Music Group]] | year=2008 | authorlink=Joel Selvin | location=U.S.A. | url= | title=Bayou Country Expanded Reissue }}
Live Selvin, Joel (2008). Bayou Country Expanded Reissue (PDF) (CD booklet). Creedence Clearwater Revival. U.S.A.: Concord Music Group. FAN-30877-02 |url= missing title (help). 
Sandbox Selvin, Joel (2008). Bayou Country Expanded Reissue (PDF) (CD booklet). Creedence Clearwater Revival. U.S.A.: Concord Music Group. FAN-30877-02 |url= missing title (help). 
I would guess that because there's a title link the url-title checker is going a little haywire:
Cite AV media notes compare
{{ cite AV media notes | last=Selvin | others=Creedence Clearwater Revival | id=FAN-30877-02 | first=Joel | authorlink=Joel Selvin | publisher=[[Concord Music Group]] | year=2008 | type=CD booklet | location=U.S.A. | title=Bayou Country Expanded Reissue | url= }}
Live Selvin, Joel (2008). Bayou Country Expanded Reissue (PDF) (CD booklet). Creedence Clearwater Revival. U.S.A.: Concord Music Group. FAN-30877-02. 
Sandbox Selvin, Joel (2008). Bayou Country Expanded Reissue (PDF) (CD booklet). Creedence Clearwater Revival. U.S.A.: Concord Music Group. FAN-30877-02. 
On an aside, I've removed the link from the article in question, since articles shouldn't have self-links (aside from navigation, etc.). --Izno (talk) 23:05, 22 January 2016 (UTC)
Thanks for the feedback and the suggestion about how to fix this instance of the problem, but I think the sandbox code might need to be adjusted. There are a number of articles that appeared in Category:CS1 errors: parameter link after the latest code update that seem to be false positives. – Jonesey95 (talk) 04:30, 25 January 2016 (UTC)
Square brackets are not allowed in article titles unless they are encoded as html entities (see WP:TITLESPECIALCHARACTERS). The module appears to be doing the wrong thing in this case. Because it is permissible to wikilink the value assigned to |title=, the intent was to reuse the code that finds the illegal characters in |<param>-link= to find the first [ of a wikilink when |title=[[link label]] and |title-link=article title from which the module would produce this illegal construct:
[[article title|[[link label]]]]
I have tweaked the module sandbox to explicitly look for the double leading square brackets of a wikilink in |title= (also applies to |series= when |series-link= is set as well as to the various other link/label pairs identified in the help text.
|title= cannot be linked simultaneously by both |title-link= and |url=. When both of the latter are present, |title-link= consumes |title= so |url= has no title-text for which it can be a link. This is a long-standing error message.
Trappist the monk (talk) 11:01, 2 February 2016 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── Meanwhile, to view this thread on a mobile-phone screen, I have wrapped the overlong url by inserting a hyphen into "assets/" as "assets-/" which no longer links to the actual webpage but is treated as valid URL format (and wraps on small-device screens). -Wikid77 (talk) 13:37, 8 February 2016 (UTC)

Reverted. If you have a problem with the template, the page you should be changing is Template talk:Cite compare. --Izno (talk) 15:34, 8 February 2016 (UTC)

Repetition in Cite magazine[edit]

{{Cite magazine}} displays a duplicated for. "This Citation Style 1 template is used to create citations for for articles in magazines and newsletters." SLBedit (talk) 00:01, 25 January 2016 (UTC)

@SLBedit: Fixed - thanks for pointing that out! GoingBatty (talk) 00:18, 25 January 2016 (UTC)

|editor= documentation[edit]

Editor ‎SMcCandlish added this to the |editor= documentation:

These parameters are for editors of collaborative printed works, such as multi-author anthologies. Wikipedia does not use them to indicate the managing editors of periodicals such as journals, newspapers, magazines, or news sites (this information is not needed in source citations). For editor-revisers of later editions of previously published unitary works, add any editors as authors, with an "(ed.)" annotation after their given names, e.g. |author2-last=Doe |author2-first=Jane (ed.); this will prevent formatting that implies the cited |chapter= in a |title= (for books), or the |title= in a |work= or |website=, is an isolated contribution contained within a multi-author work compiled by the named editor(s). None of these parameters should be used to add other, non-essential contributors who are not needed in citations, such as foreword authors or illustrators, only credited editors, revisers, and work-wide commentators.

I am on wikibreak and have no time to discuss right now so have reverted the addition and started this discussion. Please discuss.

My objection lies in the 'add any editors as authors, with an "(ed.)" annotation ...'. We should not be encouraging the improper practice of adding extraneous text to parameters that are part of the metadata nor should we misuse parameters in this way.

We can, and probably should disable |editor= when the template is {{cite journal}}, {{cite news}}, {{cite magazine}}. Foreword authors is supported in {{cite book}} with |contributor= and |others= serves for illustrators and other non-essential contributors.

Trappist the monk (talk) 13:49, 25 January 2016 (UTC)

That solution would work for some cases, but not for the main problem. I'm not trying to impose a permanent solution, just work around a problem that bites us really often. The number of misleading citations that imply that a chapter in a single-author book, in a revised edition with an author-posthumous editor, is just one author's minor contribution to an anthology, greatly outnumber the cases of metadata-extraneous "(ed.)" annotations. You've said before that any such editorial insertions can be used with square brackets, so just changing it to "[ed.]" is sufficient for my documentation to be correct. (And I already know that for some of these templates we have special parameters for other contributor types, and I still see editor parameters abused for this purpose frequently, so the documentation still needs to say not to use editors parameters for those.) I would prefer that this be fixed in some parameter-based way, that suppresses the "in" output when it's not wanted, but until that's implemented, what I documented (plus the square-brackets fix) is the most correct approach, because it's overwhelmingly more important that our citations be correct and be parsed properly by our own readers than that COinS metadata be perfect. That metadata is an afterthought, a convenience we provide for non-central purposes, and some of us are starting to think that directly implementing it in these templates is more trouble than its worth.

Almost every time I document a real, reader- or editor-affecting problem here and try to work around or fix it, I get shot down or ignored by the same one or two editors for whom COinS seems to be more important than WP:CITE, but who effectively totally control these templates. I've been a vocal supporter of CS1 for years, and would like to see CS2 eliminated, but over the last year and half I get increasingly inspired to go create a CS3 that looks almost identical to CS1, and has one consistent set of parameters, and no extraneous fiddly stuff. CS1 has turned into an enormous pile of "feeping creaturism", and hardly anyone can figure out how to use it effectively any longer. I've been here a decade, and these template still screw up my sourcing attempts at least once a week. I spend more time reading these templates' documentation than any others. I've reported more problems with these templates than any others. Fewer of them have been resolved than with any others. Given that people are not required to use any of our templates at all to insert citations, it would be a entirely valid approach to simplicity-fork this. If the principal and rather my-way-only maintainers of these templates don't want to see that happen, they need to be more responsive to problem reports, including paying attention to the details they report, and not dismissing them "oh well, you can do this complicated hack no one will remember nor understand when they encounter it", much less "we can't fix this because our precious metadata won't be ideal". Faaaaaack...  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  14:28, 25 January 2016 (UTC)

Where have I said that editorial insertions can be used with square brackets?
Yes, Wikipedia editors abuse |editor= and |author= to include names that are neither (sometimes with annotation; sometimes not). That will be a problem forever I'm afraid.
Yes, a parametric remedy is best. A couple of solutions occur to me off the top of my head: perhaps a modification of |mode= to accept additional keywords to control how the editor name list is rendered; perhaps alternate editor parameters that render in a certain way; perhaps some other parameter or parameter modification. Of these, I think that modifying |mode= is likely the better solution. Suggest other solutions.
Consumers of the metadata are also our own readers and though only a small minority of our own readers their right to quality information is the same as that of the majority.
Trappist the monk (talk) 13:13, 26 January 2016 (UTC)
We could also modify |display-editors= in some fashion; this would be my new favorite solution.
Trappist the monk (talk) 13:22, 26 January 2016 (UTC)
I agree that we need to be careful not to allow the metadata aspect of citation templates to prevent reasonable use within Wikipedia, but recommending something like |author2-first=Jane (ed.) can't possibly be a sensible way forward – it's simply a misuse of the parameters regardless of whether it generates misleading metadata. (@SMcCandlish: it's like using '' instead of {{em}} or <tt> instead of <code>, both of which you have rightly deprecated in the past. Parameters, like markup, should be used semantically.)
The purpose of a citation is not to record every last minute detail of the contributions of different people to the work, but to enable readers to find a source. The templates are over-complex partly because editors have been allowed to keep adding "features" which have nothing to do with their primary purpose, which, I repeat, is to provide sufficient information (and no more) to allow readers to locate the source. Peter coxhead (talk) 15:32, 25 January 2016 (UTC)
I agree with the purpose of citations. But I thought the topic here (CS1) is citation style. That is, after citation requirements have been agreed upon, how do we proceed with presentation?
Because there has been haphazard discussion on citation requirements elsewhere, discussion on requirements creeps into this forum. It shouldn't be so, imo. There should be a more organized discussion on citation design (discovering & implementing requirements) separately from the discussion on citation formatting (presentation). (talk) 20:19, 25 January 2016 (UTC)
  • I Oppose any attempt to remove editor from {{cite magazine}}, {{cite news}} etc. Many articles have no credited author, for example this one. --Redrose64 (talk) 19:54, 25 January 2016 (UTC)
    • Seconded. Oppose removal of editor from the templates mentioned. As an aside, most of the problems mentioned in the thread I believe could be resolved with better, clearer documentation. (talk) 20:24, 25 January 2016 (UTC)
    It is not the usual practice to give the editor name in this situation. CMOS recommends using the magazine name in such a case.
    The reason we name the editors of collections of contributions by several authors, or of an author's work, is because it helps the reader find the book, as that is how they are typically catalogued. That doesn't apply in the case of magazines or newspapers. Kanguole 22:19, 25 January 2016 (UTC)
  • Oppose changing the templates to remove the possibility of setting an editor. Although the editor or editorial board of most journal publications should not be cited, editors are occasionally useful for journals, for instance when citing a special issue or special section of a journal that has its own separate editors. Making the templates more rigid in what they accept has the cost of making more special-case citations that cannot be properly handled by the templates (pushing people to not use the templates at all) for only a very small benefit of catching a few unusual cases where people are citing things the wrong way. It's the wrong tradeoff to take. —David Eppstein (talk) 23:26, 25 January 2016 (UTC)
    • PS I also agree with Trappist's reversion of the change to the documentation: adding "(ed.)" to values of other parameters is the wrong way to do it and should not be encouraged. —David Eppstein (talk) 00:15, 26 January 2016 (UTC)
  • I also oppose any disablement of |editor= in journal, etc. However, note that such disablement is only TM's secondary comment, that the main point is regarding Mac's documentation change that editors can be cited as authors. I also oppose that change (effectively supporting TM's reversion), though as a possible work-around it might merit discussion. ~ J. Johnson (JJ) (talk) 23:46, 25 January 2016 (UTC)
    • Fine. You can keep your precious author/editor distinction (which is often artificial or tenuous; I have books where the author went from author to "editor" between editions, simply because someone at the publisher decided to make it that way). I can concede that in most cases it's a distinction we want to preserve, iff it actually affects the metadata accuracy in COinS (which is a rather blunt instrument). But that still leaves us with the question of what do in cases like what I outlined in my "rogue" documentation change.

      To address some of the comments above: For the record, I do not agree that the sole purpose of these citations is identifying the source so people can find it; that's the primary purpose. As anyone with any familiarity with academia knows, it also has a lot to do with proper attribution, credit where due. And this is actually important for WP-internal reasons, like being exact in our attribution of claims, especially primary ones.

      As someone commented above, yes, it is true that we do not cite managing editors of newspapers and such, except possibly under unusual circumstances. (When would we ever do that? Give a concrete example. Even if there's some kind of "Statement by the Editor" piece, the "editor" in that case is actually the author, and would be cited as such.) If you are adding the names of the general or managing editorial staff at a newspaper or journal as |editors, you are not doing citations right, you're engaging in WP:NOT#BIBLIOGRAPHY; it's exactly the same thing as giving the total page count, the address of the publisher, or hardback vs. paperback. This is not citation information. It looks superficially like attribution, but it's attribution for an organizational role, like adding a parameter for the owner of the newspaper, and its janitor. WP is not IMDb; we don't provide details on every single person associated with a "production" in any medium. That said, we s should not disable the parameter for any particular medium, since a particular piece may in fact have a direct, actual, credited-in-the-specific-piece editor who needs attribution (and whose editorial presence in the piece may considerably enhance its reliability, I might add). We don't need to kill the parameter, we need to clarify what not to do with it. That much of what I added to the docs should be restored.

      At any rate, it looks like me like neither of the issues I attempted to address in what I wrote in the doc page have been addressed. We do need to discourage the misuse of the editor field to identify corporate administrators, and we do need to distinguish between two different levels of revisers of an original author, especially when the intermediary one was a very significant contributor to the work. Many "editors" are actually posthumous co-authors, and may even be responsible for much more of the content than the original author, yet may themselves be retired from the project in question (or deceased) for some time, with some new editor (actually acting as an editor per se or a new layer of co-author). This sort of thing comes up very frequently in style guides, as just one topical example. What is presently called Fowler's Modern English has much less of H. W. Fowler's original content in it than people think (I know; I have the 1st ed., too). Same goes for the ones we call in short form Turabian and Hart's, and Gowers. Sometimes the editions with different editors are cumulative, sometimes they are not, and this can have actual RS implications – particular editors are more reputable than others, and even particular editions by the same editor may be (and this is not always chronological).  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  01:29, 9 February 2016 (UTC)

Just for clarification, the change that Editor SMcCandlish is discussing refers to how cs1|2 handles editors when |chapter= is set (1) and when it is not set (2):
  1. Darwin, Charles (1909). "Laws of Variation". In Eliot, Charles W. The Origin of Species. New York: P F Collier and Son. 
  2. Darwin, Charles (1909). Eliot, Charles W, ed. The Origin of Species. New York: P F Collier and Son. 
When chapter is set (1) cs1|2 makes it appear that Darwin is one of possibly several authors of an anthology edited by Eliot when, in fact, Darwin is the only author.
The question then is: how should we instruct cs1|2 to render |editor= using the form in (2) when |chapter= and |editor= are set and when |authorn= is/are the author(s) of the whole work?
The answer to the implementation question will determine, I think, how the documentation should be changed so perhaps that topic should be tabled until the implementation decision is taken.
Trappist the monk (talk) 13:43, 9 February 2016 (UTC)

Proposal: editor, cite encyclopedia[edit]

  1. Remove the text "in {{{editor}}}" from all templates except {{cite encyclopedia}}; keep the display of editor role (ed.) in all templates
  2. Rename {{cite encyclopedia}} into {{cite compilation}} (or similar); keep {{cite encyclopedia}} as an alias
  3. Activate {{{contributor}}} in proposed {{cite compilation}}
Thank you. (talk) 15:23, 26 January 2016 (UTC)
On first glance, that might actually do it, as long as there's not some new "you're abusing the metadata" complaint about using |contributor to deal with multiple levels of editor–co-authors. Is there any sort of potential fallout from this? Besides the obvious one: Many collaborative books (e.g. scholarly volumes of journal-style papers by different authors, under an editor [or plural] who is actually an editor, not a corporate functionary, like this [1]) are already coded in {{cite book}} with the expectation of the "in {{{editor}}} (editor)" output, not just "{{{editor}}} (editor)". I have to ask if there any actual harm at all in that drop-the-"in" conversion? While the "in" format (in one exact stylization or another) is very common, it's not universal. In a quick comparison of American citation styles (from Cite Right, Charles Lipson, 2006, and "Purdue OWL Citation Chart" 2014), there's a clear split between how to style an editor of a book when just citing the book, or a chapter by someone else in an edited book. I've summarized these, splitting the former from the latter with a "/", and giving some indication whether the editor citation starts a new sentence or not, and how it ends (the quotation marks are bracketing what I'm quoting, not part of the citation style):

MLA: "Ed. Kathleen A. Hauke." or "Hauke, Kathleen A., ed.," depending on edition / "In. [title], ed. Kathleen A. Hauke." or "[chapter]. [title]. Ed. Kathleen A. Hauke." (emphasis added – note the lack of "[i|I]n", and that's from the 2014 source), depending on edition
APA: "K. A. Hauke (Ed.)." / "In K. A. Hauke (Ed.),"
CMS: "Edited by Kathleen A. Hauke." / "In [title], edited by Kathleen A. Hauke,"
Chicago/Turabian: "Kathleen A. Hauke, ed.," / "[I|i]n [title], edited by Kathleen A. Hauke,"
AAA: "Kathleen A. Hauke, ed." / In [title]. Kathleen A. Hauke, ed."
CSE & AMA: "Hauke KA, editor." / In: Hauke KA, editor. [title]."
ACS: "Hauke, K. A., Ed.;" / "In [title]; Hauke, K.A., Ed.;"
AIP: "K. A. Hauke, editor," / ", in [title], edited by K. A. Hauke (...)."
Astro. (no single standard, but fairly consistent): ", ed. K. A. Hauke (...)" / ", in [title], ed. K. A. Hauke (...)."
Maths. (not consistent): "K. A. Hauke (ed.)," or "K. A. Hauke (ed.):" or "In: K. A. Hauke (ed.)," / ", in [title], K. A. Hauke, ed.," or "In: K. A. Hauke (ed.), [title]."
Bluebook & ALWD: "(Kathleen A. Hauke ed, ...)." / ", in [title] (Kathleen A. Hauke ed, ...)." (Bluebook italicizes in, ALWD does not).

So, all of these use some form of "in" except some editions of MLA. But at least that's proof it's not effectively mandatory to treat it this way. I've not yet gone through MHRA and other non-American sources on this question. I'm pretty sure there are more that do not expect an "in". Anyway, I actually need to verify that the 2014 Purdue source is correct on MLA dropping the "in". I actually just got the latest MLA guide last month, and have not perused it yet, but my eyes hurt, so I'll look into it later.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  02:51, 9 February 2016 (UTC)

There are differences in the roles of editors of single-author books and editors of works from multiple authors. In the latter case, the term editor often encompasses the work of a compiler (somebody who chooses who and why will be included in the work) and also somebody who often vets the contributions for relevance/topicality relative to the particular "compilation". Although a “compilation” editor (for lack of better term) may not be involved in fact-checking (esp. in science publications) s/he should have acquired a certain level of confidence regarding the veracity of the contributions. It seems that in many situations, a compilation editor does meaningful work, which affects the end-product. Less, or not at all so, with single-author books. So the text “in {{{editor}}}” would be justified in the former case. (talk) 20:57, 9 February 2016 (UTC)
I know there are differences; that's why I carefully showed how these citations styles specify the two distinct cases. [sigh]  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  14:41, 10 February 2016 (UTC)
In order not to have recurring useless discussion about style, the doc should make clear why the editor may be presented differently in {{cite book}} vs. the proposed {{cite compilation}}. It's not enough that we know. Letting all Wikipedia users know (through the doc) that there is a valid rationale behind the difference in formatting, would perhaps rid this page of unnecessary debate. (talk) 16:12, 10 February 2016 (UTC)

Category:Pages with reference errors[edit]

Does anyone know what errors put a page into Category:Pages with reference errors? List of Mystery Dungeon video games (and several others on my cleanup list) are in it, but nothing obvious is jumping out at me. I know you can get it by putting a "<ref/>" inside of a list-defined reference list, but that's not present here. --PresN 19:13, 26 January 2016 (UTC)

That one is most often added by MediaWiki. Most commonly among those cases, it's for the case where a named referenced is defined twice. I tried purging the article but it didn't seem to work, and for me also, nothing is jumping out. --Izno (talk) 19:27, 26 January 2016 (UTC)
Possibly, here. Because <ref> ... </ref> are inside a template ({{reflist}}), and some of the query strings include =, mainly for page numbers? An example would be
<ref name="MDSW1SNES">{{cite web |script-title=ja:株式会社スパイク・チュンソフト ゲームソフト 検索一覧 |publisher=[[Spike Chunsoft]] |url= |accessdate=2013-06-13 |language=Japanese |archiveurl= |archivedate=2014-03-16 |deadurl=no}}</ref> (talk) 20:20, 26 January 2016 (UTC)
See Help:Cite errors, which might help. – Jonesey95 (talk) 21:38, 26 January 2016 (UTC)
@Izno: After about an hour spent chopping bits out of the article and previewing, I eventually realised that List of Mystery Dungeon video games contained two different references named "MDSW1SNES". It is very unhelpful that there is no error message for this case. -- John of Reading (talk) 08:12, 27 January 2016 (UTC)
@John of Reading: It is normal for an error to be displayed in this case, and were I to hazard a guess, the error is not displayed because the references are list-defined. Might be worth opening a Phabricator task for it. --Izno (talk) 12:51, 27 January 2016 (UTC)
@John of Reading: Thank you very much for finding out what it was! Sorry you spent so long on it. I had discounted that possibility since I knew an error message popped up for it, though I guess just for non list-defined refs. --PresN 04:55, 28 January 2016 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── Yes, in my spare microseconds, noticed duplicate wp:reftag names are allowed under {Reflist|refs=} and no error msg upon edit-preview, but good to know triggered error category. The cite templates also categorize as unnamed parameter for blank "|<newline>|" but no msg there either. Wikid77 (talk) 14:00, 27 January 2016 (UTC)

I've filed a task at phab:T125074. --Izno (talk) 13:11, 28 January 2016 (UTC)

Perhaps the reason for the absence of the error message, is that it should be obvious to the contributor, i.e. the inline ref links will target the first anchor with the same name, and group all the invocations to the first reference with the particular name (WP:REFNAME). I suppose it is up to the contributor to notice that the inline links ignore the second named reference with the same anchor name before s/he commits the contribution. Not that an error message would be unhelpful. (talk) 13:53, 28 January 2016 (UTC)

Status of filtering square brackets in URLs[edit]

Are we planning to handle brackets in URLs? I found an article (at redirect "EAPPI") where the "url=" contains sets of single brackets ("[...]") and should be encoded by a Lua filter (as '%7b' and '%7d' values?). Apparently those are very rare inside a URL, but they should be filtered by the Lua module, some day. This problem goes back 15 years due to the poor design of the MediaWiki markup language which should have used 2-character tokens to denote an external URL link, such as with both angle+square brackets, "<[http:...]>" rather than just single brackets "[http...]" as now unable to include each ']' inside a URL address. Anyway, 15 years later, now the cite templates should handle "[...]" inside each URL parameter. -Wikid77 (talk) 11:37, 27 January 2016 (UTC)

Technically, unencoded single brackets are actually forbidden in the path part of a URL according to the URL specification. Of course, in practice anything is allowed provided that browsers and servers support it. Wikipedia also have issues with angle brackets ("<", ">") breaking urls. There might be other examples too. Dragons flight (talk) 12:39, 27 January 2016 (UTC)
The embedded brackets "[...]" are so rare, it can wait to be handled, along with other URL characters. -Wikid77 (talk) 14:00, 27 January 2016 (UTC)
Forbidden in the path part yes, but I think that they are legal in the query string. When used there they will still break the MediaWiki parsing: I have come across examples of such use in the past, occasionally when somebody posts to VPT with "why doesn't my URL work?". --Redrose64 (talk) 21:53, 27 January 2016 (UTC)

Here's an example of a URL containing square brackets (from Pass Me By (R5 song)) that does not render correctly:

Cite web compare
{{ cite web | publisher=Muzikkitabi | title=R5 Performs Pass Me By, Loud [Morning Show Toronto] 8/26/13 | accessdate=2012-09-13 | date=2012-09-08 | url=[Morning-Show-Toronto]-8-26-13 }}
Live [Morning-Show-Toronto-8-26-13 "R5 Performs Pass Me By, Loud [Morning Show Toronto] 8/26/13"]. Muzikkitabi. 2012-09-08. Retrieved 2012-09-13. 
Sandbox [Morning-Show-Toronto-8-26-13 "R5 Performs Pass Me By, Loud [Morning Show Toronto] 8/26/13"]. Muzikkitabi. 2012-09-08. Retrieved 2012-09-13. 

We should probably do something to either render this reasonably or flag it as an error. – Jonesey95 (talk) 03:41, 10 February 2016 (UTC)

Allowing blank parameters[edit]

Has anyone figured how to get the Lua code to accept blank parameters such as empty "|<newline>|" so it would not trigger unnamed-parameter category? It took me hours to realize that error condition, after they omit "url=" at "|http...." how a lone newline "{cite_web|  |...}" also triggered as a parameter with no '=' in the parameter. Everything is considered an error now (date "Feb." or "April/May" invalid??), and cite templates almost unusable now. -Wikid77 (talk) 14:13, 27 January 2016 (UTC)

Please provide an example citation. – Jonesey95 (talk) 14:30, 27 January 2016 (UTC)
Apparently it is fixed now, so a blank parameter can have a newline without triggering the unnamed-param category, but the hidden error categories do not update until after an edit is saved. -Wikid77 (talk) 15:19, 27 January 2016 (UTC)
The code was updated about ten days ago. It can take weeks for the job queue to refresh all of the articles to remove them from or add them to categories. – Jonesey95 (talk) 19:18, 27 January 2016 (UTC)

Second DOI for English translation[edit]

Many Russian mathematics journal articles have two DOIs, one for the original Russian article and a second one for its translation into English. Example:

(Also note that the Russian original is free online while the translation is paywalled.) Above, I am abusing the |id= parameter to link the translation. Is there or should there be a better way? —David Eppstein (talk) 21:48, 27 January 2016 (UTC)

Or just append the extra stuff after the citation template:
~ J. Johnson (JJ) (talk) 00:24, 28 January 2016 (UTC)
Right, that's what I actually did in the article where this came from. Using |id= was a later cleanup for here. But it would be nice if we could actually use the template to format the whole citation rather than having some of it spill over into freeform non-templated text. —David Eppstein (talk) 06:16, 28 January 2016 (UTC)
I agree. But this kind of problem doesn't happen too often, and it's easier to just slap something on then try to fine tune the tool for every possibility. ~ J. Johnson (JJ) (talk) 21:12, 28 January 2016 (UTC)
Why would we need, on en.WP, to provide a URL (etc.) to the Russian version if the English one is available? WP:NOT a document translation indexing service.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  14:38, 10 February 2016 (UTC)

Support for ArchiveURL ?[edit]

"Unknown parameter |ArchiveURL= ignored (|archiveurl= suggested)" WT? Good practice is to be liberal in what you accept and conservative in what you produce. See Robustness principle. It seems the sandbox version supports ArchiveURL differently from the live version. Can't believe that, even where the URL includes the date, we're still spitting out "Error: If you specify |archiveurl=, you must also specify |archivedate=."  :-( (Redirected here from Template talk:Cite web) Is the issue what User:SMcCandlish mentioned - a couple user "who effectively totally control these templates"? --Elvey(tc) 16:21, 28 January 2016 (UTC)

The former ("ArchiveURL" etc.) by design (not least since it eases cleanup bots' work), the latter ("date in URL") because there is no sensible way for the citation to spit out the date. --Izno (talk) 16:33, 28 January 2016 (UTC)
@Elvey: not all archived urls contain a date. If you can tell me what the date is for then we can talk. (For the record, it was archived on June 27, 2012). Imzadi 1979  17:51, 28 January 2016 (UTC)
@Imzadi1979: I use the "cached" date as the archivedate. In this case, it's June 28, 2012. GoingBatty (talk) 02:00, 29 January 2016 (UTC)
True. And less ambitiously: @Imzadi1979:You can't parse the date out of the archiveurls that do contain a date (which I think are the majority)? Surely you jest.--Elvey(tc) 02:07, 29 January 2016 (UTC)
You both missed the point. You can't parse a date out of a URL that doesn't have an embedded date, and I think it is quite beyond the scope of a template to retrieve an external webpage and parse that to return the archive date. Even if we attempted to parse URLs for dates, there would be a variety of formats in which they're embedded. In short, they need to be manually specified. (And with time zone differences, the date could be shifted slightly in any case.) Imzadi 1979  02:22, 29 January 2016 (UTC)

Exclude Wikipedia space from CS1 maint: Extra text[edit]

There are quite a few pages in Wikipedia space in Category:CS1 maint: Extra text. Instead of "fixing" these pages (many of which are archives), would it be better to exclude Wikipedia space from this category? Thanks! GoingBatty (talk) 02:32, 29 January 2016 (UTC)

My two cents: Wikipedia-space pages appear in the error categories as well. I have fixed hundreds and have never had a complaint. Note that you need to look carefully to see if the error is really a demonstration of an example. In that case, using |template-doc-demo=true may be appropriate to add.
Excluding all WP-space pages would exclude pages that are intended as help and how-to pages, as well as guidelines and policies. We wouldn't want to exclude those, I think. There may be a way to exclude archives, though, just as we have excluded template sandboxes and test case pages. – Jonesey95 (talk) 03:07, 29 January 2016 (UTC)
We can exclude archives. As originally proposed, the code would have excluded /[Aa]rchive and /[Ll]og pages. The original discussion is here.
Trappist the monk (talk) 14:15, 30 January 2016 (UTC)

website deprecated?[edit]

|website= is no longer shown as an alias for |work=. Are we deprecating website? Is there any discussion on that you can point me to? Thanks. ―Mandruss  08:47, 29 January 2016 (UTC)

No. Where are you looking? |website= shows as an alias at cite web.
Trappist the monk (talk) 12:18, 29 January 2016 (UTC)
Template:cite news#csdoc_workMandruss  12:38, 29 January 2016 (UTC)
Though the doc is in places confusing in its mentions of "website", it is proper not to use it as an alias of |work= in {{cite news}}. (talk) 14:11, 29 January 2016 (UTC)
And this wisdom is written where? If cite news supports it, the doc for cite news should say how it supports it. That's Software 101. ―Mandruss  14:47, 29 January 2016 (UTC)
I updated the documentation. – Jonesey95 (talk) 15:49, 29 January 2016 (UTC)
I don't see any update. ―Mandruss  15:58, 29 January 2016 (UTC)
@Jonesey95: It appears you updated Template:Citation Style documentation/work2, whereas Template:Cite news/doc#Periodical uses Template:Citation Style documentation/journal. GoingBatty (talk) 23:14, 29 January 2016 (UTC)
So I did. Silly me. I have updated both of them now. – Jonesey95 (talk) 02:39, 30 January 2016 (UTC)
Thank you. ―Mandruss  03:45, 30 January 2016 (UTC)
This is not a good guideline. {{cite news}} is for citing news sources. Websites are not news sources, they often are the medium news is delivered by a source. The source may be entirely online; it doesn't matter. If it is an online journal, use journal. If it is an online newspaper, use newspaper. There is a |type= parameter if you want to specify medium etc. Based on the latest change, I move to add |print= as an alias of |work= in {{cite book}}. (talk) 15:17, 31 January 2016 (UTC)
Of course web sites can be news sources. It's 2016. The documentation for cite news says "This Citation Style 1 template is used to create citations for news articles in print, video, audio or web." – Jonesey95 (talk) 17:40, 31 January 2016 (UTC)
Perfect confusion: "print, video, audio or web" is media. News sources are entities that distribute their product over a variety of media. The template is there to cite a news source. The absence of coherence and common sense surrounding the citation system is breathtaking. (talk) 18:44, 31 January 2016 (UTC)
Use {{cite news}} for e.g. The Huffington Post. --Redrose64 (talk) 19:52, 31 January 2016 (UTC)
|work==|magazine= |work=journal. In the absence of |work==|news-agency= or |work==|news-blog=. (talk) 20:01, 31 January 2016 (UTC)
As it says at Template:Cite news#Periodical: work: Name of the source periodical ... Aliases: journal, newspaper, magazine, periodical, website. Pick one, and don't worry if somebody alters it to one of the others, they're all equally valid. --Redrose64 (talk) 20:31, 31 January 2016 (UTC)
If they are all equally valid, they are superfluous. If they provide to editors semantic information, then the one more approximating the type of source (not the medium of the source) should be used. (talk) 22:29, 31 January 2016 (UTC)
The point is, if it's a newspaper that is available online, you can use |work= or |newspaper= or |website= - it really doesn't matter. If we tell people they must use only one of them, we will irritate a lot of people, not to mention all the hassle of sending a bot around to "fix" something that isn't broken. --Redrose64 (talk) 23:33, 31 January 2016 (UTC)
I don't want to force anyone into using any particular alias. But "website" does not belong in a listing that includes types of news sources. It is a medium-type, not a source-type. Nobody is citing websites with {{cite news}} (there's {{cite web}} for that), we are concerned with citing news sources (which may be online). If you want to cite the medium, use |type=web. If we are to add distribution media, then I think more aliases for "work" are forthcoming, such as |print=, |audio broadcast= etc. I'm sure this will make things even more complicated. (talk) 16:40, 1 February 2016 (UTC)
Nobody is citing websites with {{cite news}} - Light-years from reality. Tons of editors are doing exactly that, because they have read the first sentence at Template:Cite news, the table at Help:Citation Style 1#Templates, and other guidance elsehwere, and believe in following the guidance given.
I don't really care what's done here, provided the doc accurately describes what the software does. If the software changes, I'll adapt. ―Mandruss  17:00, 1 February 2016 (UTC)
You are saying that when you cite say, a NY Times article, the source is not the news provider (The New York Times), but a website ( that the provider is using to present the information. So that instead of |newspaper=New York Times the proper rendition should be | How does the latter qualify as a news source? Because the doc is confusing or wrong doesn't mean common sense has to be abandoned. The software does a decent job of formatting the citations. The doc is under par in several instances, especially where it sneaks novel (meaning non-discussed) citation guidelines disguised as citation formatting. (talk) 20:39, 1 February 2016 (UTC)
Many choose to code |website=The New York Times, in the opinion that "website" is not a synonym for "domain name". Many will defend to the death the notion that a web site is not a newspaper, since you can't hold it in your hands and turn the pages and it doesn't leave ink stains on your fingers, and so they refuse to use |newspaper= for web-published sources. There is no guidance as to these choices, nor any documented consensus that I'm aware of, hence conflicts such as this one.
Editors spend countless hours arguing about these matters, which make little or no difference in what the readers see, edit-warring and continually "correcting" others' work to no visible change, and they will continue to do so until the end of time, despite exhortations to stop. Thus my comments below.
I personally don't like coding domain names in citations.
I've found that common sense is very often a matter of opinion. ―Mandruss  22:14, 1 February 2016 (UTC)
I've long felt that aliases add unwarranted complexity and conflict (such as this) for no change to what readers see. That's what we're here for, by the way—what readers see. We could simply use |work= for a range of purposes as documented. But I realize it's probably many years too late for that to happen, so this is a pointless comment. ―Mandruss  20:24, 31 January 2016 (UTC)


I have added simple |oclc= checks to look for spaces. The code first removes any punctuation from the identifier value (WorldCat ignores punctuation in the identifier value) and then attempts to convert the value to a number which must be 1 or greater. Any non-digit characters the identifier value will cause the conversion to fail and the module will emit a bad oclc error message. These errors will be categorized in Category: CS1 errors: OCLC

At the time of this writing, this insource search string found 62 |oclc= values with letters:

insource:/\| *oclc *= *[A-Za-z]+/

None of the links that I checked were valid.

Trappist the monk (talk) 17:30, 2 February 2016 (UTC)

We could check for multiple OCLCs by limiting the number of digits. See this reference source for a rough OCLC specification. Something like this should not be valid:
Thoughts? – Jonesey95 (talk) 22:31, 2 February 2016 (UTC)
That documentation is rather vague. WorldCat specifically identifies the OCLC number in the Details box. The document implies, I think, that there are forms of OCLC that have prefixes. But, inclusion of the prefix in |oclc= causes WorldCat to return a page-not-found error. Simple testing seems to indicate that removing the prefix from the 'number' returns a page that matches the title in the citation.
We can limit the OCLC to 9 digits. If the numbers are sequential, then as I write this, the current top number is 936,401,218 so that leaves us 63,598,781 before the number rolls over to 10 digits. Perhaps we make the test smart enough to limit the number of digits according to any prefix it may have.
I'll work on this tomorrow.
Trappist the monk (talk) 02:03, 3 February 2016 (UTC)
My reading of the documentation was that some sources use a prefix of their own before the OCLC identifier, but the identifier itself is a whole number starting at 1 and getting close to 1 billion (US style: 1000000000, or one followed by nine zeroes). I think we should limit the OCLC check to ten digits (not nine, given the guidance at that page), greater than zero. – Jonesey95 (talk) 04:17, 3 February 2016 (UTC)

Rewritten. Since the oclc document specifies length as a function of the prefix, the code tests for length when a recognized prefix is present. For oclc without a prefix and for the prefix (OCoLC), length is constrained to 9 digits for the time being. This is much like the constraint we impose on |pmc= and |pmid=. Where prefixes are included in the |oclc= parameter value, they are stripped from the number and not displayed.

Prefix ocm requires 8 digits:

Title. OCLC ocm1234567 Check |oclc= value (help). 
Title. OCLC 12345678. 
Title. OCLC ocm123456789 Check |oclc= value (help). 

Prefix ocn requires 9 digits:

Title. OCLC ocn12345678 Check |oclc= value (help). 
Title. OCLC 123456789. 
Title. OCLC ocn1234567890 Check |oclc= value (help). 

Prefix on requires 10+ digits:

Title. OCLC on123456789 Check |oclc= value (help). 
Title. OCLC 1234567890. 
Title. OCLC 12345678901. 

Prefix (OCoLC) requires 1+ digits without leading zeros (constrained to 9 digits):

Title. OCLC (OCoLC)01 Check |oclc= value (help). 
Title. OCLC 1. 
Title. OCLC 123456789. 
Title. OCLC (OCoLC)1234567890 Check |oclc= value (help). 

OCLC without prefix 1 to 9 digits:

Title. OCLC 1. 
Title. OCLC 0001. 
Title. OCLC 123456789. 
Title. OCLC 1234567890 Check |oclc= value (help). 

Unrecognized prefix:

Title. OCLC bob12345678 Check |oclc= value (help). 

Punctuation between two oclc numbers:

Title. OCLC 12345678,2345 Check |oclc= value (help). 

Space between two oclc numbers:

Title. OCLC 12345678 2345 Check |oclc= value (help). 

Trappist the monk (talk) 12:58, 3 February 2016 (UTC)

Looks good. Nice work. – Jonesey95 (talk) 15:09, 3 February 2016 (UTC)


It seems the number of works with dual numbers (print & electronic ISBN) or just an eISBN (when published solely as e-books) is increasing. (talk) 20:37, 2 February 2016 (UTC)

Apparently, there is no such thing.
Trappist the monk (talk) 20:48, 2 February 2016 (UTC)
Some publishers are using the term anyway (in edition notices of both print and digital books), but the acronym is not important. How to differentiate, if need be? It seems to me that digital versions of books increasingly differ from print versions, sometimes with "enhanced" features. If eISSN is justified, "eISBN" (or whatever) should be considered. (talk) 01:29, 3 February 2016 (UTC)
Not necessary per WP:SAYWHEREYOUGOTIT. Just use the ISBN of what you're actually reading. If you want to add a note that it's also available in a different-medium edition with a different ISBN, you could do so between the template and the </ref>. Largely unnecessary. For some books, there may be 5 or more ISBNs, depending on whether its hardback, paperback, trade paperback, spiral-bound, e-book, etc., and maybe additional ones depending on whether the UK or US or India office printed it, etc. There's no point in including all this info, per WP:NOT#BIBLIOGRAPHY.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  14:34, 10 February 2016 (UTC)
The question was about specifying that there may be substantially different editions based on medium-type. Is it enough to add e.g. |type=e-book and |edition=digital (or similar) to a citation of an e-book that has additional features not in the print editions? Or is an additional signifier along the lines of eISSN to be considered? (talk) 16:23, 10 February 2016 (UTC)

Interaction with <poem> blocks[edit]

It seems that <poem> blocks are processed before templates, meaning that {{cite journal}} and {{cite book}} only work inside them if they go all on one line. See this revision of "Lightbulb joke" for example - refs 3 and 4 are treated as plain wikitext. If you remove the newline before the first pipe, you get some weird errors about delete characters. There are no delete characters in the wiki text. Hairy Dude (talk) 01:26, 5 February 2016 (UTC)

I have "fixed" that article by removing the line breaks, but it looks like this is a limitation of the poem tag. I recommend raising the issue at Help talk:Wiki markup, since it may effect other templates used inside of the poem tag as well. – Jonesey95 (talk) 01:43, 5 February 2016 (UTC)

Need {cite_page} to link "url=" to page[edit]

I am thinking to create a simple template, {cite_page} to ignore "title=" & "publisher" and just show "Author (year). p. [url page]." as a short cite for optional link page+url. However, the template could also show "volume=" so the cite could link a page within different volumes of the same author/year book. The benefit would be to morph multiple refs to the same book, but different pages, to be {cite_page} with optional "url=" link to each page (rather than link to title). Recent timing tests show the simple markup cite templates (without Lua) now run over 800/second and use perhaps 300 bytes (rather than Lua's 1,000-1,600 per cite, as 4x title+url length) of the wp:post-expand include size (limit 2,000MB). Would that kind of short cite need CoINS metadata? -Wikid77 (talk) 17:04, 5 February 2016 (UTC)

What's wrong with using the existing {{sfn}} and its cousins?
Here's a short cite, linking to page 34 of an article, hosted on[1]
The real source is a Time magazine article, fully cited using |ref=harv.[2]


  1. ^ Baker 2013, p. 34.
  2. ^ Baker, Aryn (2013). "Syria's Breaking Bad: Are Amphetamines Funding the War?". Time. ISSN 0040-781X. Retrieved 2016-02-05. 

— Preceding unsigned comment added by Jonesey95 (talkcontribs) 17:16, 5 February 2016‎

──────────────────────────────────────────────────────────────────────────────────────────────────── While the use of "{{sfn|Baker|2013|p=[ 34]}}" is great for people who think of parameters that way, it is very, very different from "author=" plus "year=" plus "url=" & "pages=" etc. Again, the benefit would be to easily morph multiple refs to the same book, but different pages, to be {cite_page} with optional "url=" link to each page (rather than link to title). Typically, we see repeated:

  • {cite book |author=John Doe |title=Book |year=2011 | |publisher=Acme}
  • {cite book |author=John Doe |title=Book |year=2011 | |page=14}
  • {cite book |author=John Doe |title=Book |year=2011 | |pages=34-36}
  • {cite book |author=John Doe |title=Book |year=2011 | |pages=67}

So to fix all the repeats, just change each extra "cite book" to be "cite page" and instantly done. No need to explain Harvard referencing with the mandatory parameter "|ref=harv" and no need to omit "author=" or "year=" or "url=" or "pages=" (etc.); the template could just ignore "title=" (or "publisher") to show the short cites. Fixing repeated references would become a matter of seconds per article, with no worry of misspelling the author's names or putting wrong year. New users would see {cite_page} as having similar parameters to the other cites they wrote in the page. -Wikid77 (talk) 17:48, 5 February 2016 (UTC)

How is a reader to know that "Baker 2013 p. 34" is a reference to the full Baker 2013 citation without a link to the full citation? Showing just "Author (year). p. [url page]." makes it difficult for the reader to locate the source if there is not a clear link to that full source in the article. Harvard referencing provides that full link.
Maybe a sandbox example page would be a good way of explaining how your proposed way is better than the documented way of doing this that is standard and has existed for a while. – Jonesey95 (talk) 18:03, 5 February 2016 (UTC)

Perhaps pages+page combined as page of pages[edit]

In the Category:Pages_with_citations_having_redundant_parameters, I have cleared all old entries from months ago, and left new entries to show a growing set of examples of recent redundant parameters. Previously, over 80% of entries had been pages+page, but 2nd most were author2+last2 (or similar). For the vast majority, as pages+page, the common fix is to show "page of pages" where many people think "pages=" is the total (similar to French "pages totales=" in fr:Template:Ouvrage but not in fr:Template:Lien_web). If the cites auto-combine as "page of pages" then over 80% of former "redundant" parameters will be valid now, and in viewing prior revisions of those pages, such as in old talk-pages. We would simply state in the CS1 documentation, "when pages+page cite shows page of pages" (or such), and that would remove those numerous pages+page errors from cites. -Wikid77 (talk) 17:18, 5 February 2016 (UTC)

All of those edits are relatively new; I have cleared out that category many times over the past year or more. They appear to be caused by editors who misread or do not read the documentation, which clearly states "pages: A range of pages in the source that supports the content. Use either |page= or |pages=, but not both. ... do not use to indicate the total number of pages in the source."
Showing "page x of xxx" would require consensus to change the documentation for the CS1 templates. – Jonesey95 (talk) 17:25, 5 February 2016 (UTC)
Or are caused by Citation bot. --Izno (talk) 17:30, 5 February 2016 (UTC)


In keeping with my post at Wikipedia_talk:COinS#Language metadata pollutes COinS, and because this page has more watchers, I have moved this conversation from Module_talk:Citation/CS1/Feature_requests#Language to here.

At Feature requests#Language, Editor OwenBlacker wrote

Is it possible to reinstigate discussion on this change? At the moment, providing human-readable language tagging is done (as Jonesey95 pointed out on 20 December 2013) and COinS-tagging means that we can't use {{lang}} within CS1 templates (like {{cite book |title={{lang|es|La Casa de Mi Padre}} |trans_title=My Father's Home |author=Will Ferrell |language=es }}) because it would pollute the machine-readable data; we need to use {{cite book |title=La Casa de Mi Padre |trans_title=My Father's Home |author=Will Ferrell |language=es }} instead. What would be great would be to change the output markup so that this example above goes from rendering (without the COinS):

<cite class="citation book">Will Ferrell. <i>La Casa de Mi Padre</i> [<i>My Father's Home</i>] (in Spanish).</cite>
to rendering
<cite class="citation book">Will Ferrell. <i lang="es" xml:lang="es">La Casa de Mi Padre</i> [<i>My Father's Home</i>] (in Spanish).</cite>
for example. This would allow assistive technologies correctly to identify the language of the title (and, for example, user CSS to style text differently according to language). Alternatively, rather than assuming that the title (and only the title) will match the language, new parameters could be added such as |title_lang=, |chapter_lang= and |journal_lang=, for example.

I'm entirely open to discussing the details, as I've just made these up on the spot, but in principle this feels like something we could make work, no?  :o)

OwenBlacker (Talk) 14:32, 7 February 2016 (UTC)

Is xml:lang="..." required? Wikipedia pages are <!DOCTYPE html>.

It occurs to me that one way to address this might be to support certain parameters that look like this: |title-es=, |chapter-de=, etc where the language code suffix is the appropriate ISO 639-1 code. This will require that we make changes to validate(), argument_wrapper() (this one is problematic because it is not at all documented and is not easily understood), and certainly others.

We would ignore the English versions: |title-en=, etc.

What do we do when |script-title= is also set? If both |script-title= and |title= are set, |title= is supposed to hold the transliteration of the original title so its language specifier, if provided, must be the same as the specifier in |script-title=. If the language is specified for one of |script-title= or |title= but not both, what do we do then?

Trappist the monk (talk) 16:44, 7 February 2016 (UTC)

Using |script-title= overloaded to hold the lang code of the title, or a new |title-lang=, seems more sensible than a number of new parameters. I have a preference for the latter. --Izno (talk)
StackExchange on xml:lang. My read is that, since we're serving Html5, we don't need xml:lang. --Izno (talk) 17:29, 7 February 2016 (UTC)
We also need parameters for identifying the language of other items IMO e.g. |work-title-lang=. --Izno (talk) 17:34, 7 February 2016 (UTC)
Not sure I quite understand this. How would you overload |script-title= to hold the language code of |title=? Like this?:
{{cite ... |title=La Casa de Mi Padre |script-title=es: |...}}
The purpose of my suggestion was to avoid creating new parameters; we have enough of them now. If we can figure out how to modify or tag existing parameters and still recognize, programmatically, when they are valid, that seems a better solution for editors who will use them. If we can make this work for |title= then it should extend to other 'title' holding parameters as well. Which leads me to the additional question, what about authors:
{{cite book |first=Guðrún Eva |last=Mínervudóttir |author-link=Guðrún Eva Mínervudóttir |title=Fyrirlestur um hamingjuna |trans-title=Lecture on Happiness |isbn=9789979865773 |location=Reykjavík |publisher=Bjartur |date=2000 |language=is}}
Mínervudóttir, Guðrún Eva (2000). Fyrirlestur um hamingjuna [Lecture on Happiness] (in Icelandic). Reykjavík: Bjartur. ISBN 9789979865773. 
and this is a simple example, author and title are the same language. What about for journals? For journals, internationally disparate authors are common. Perhaps we just don't go there.
I agree that xml:lang does not apply to us, but I thought that the question should be asked since the Editor OwenBlacker specifically included it in the example cite.
Trappist the monk (talk) 18:30, 7 February 2016 (UTC)

It was a stray thought tossed out that might solve the issue of "what to do when script is also specified". Don't worry too much if an implementation doesn't jump out at you--we have two others to consider (but which include the issue).

I think we should attempt not to confuse the issue of having a title in a different language than the default and the issue of having a title at all, which is why I prefer |title-lang=es + |title= to |title-es=. The former can presumably also re-use the language checking utility we have in |language= without change. There is also the issue of duplicate parameteres that User:Citation bot chokes on (reported already as a bug) as-it-is as well as updating other scripts to consider |title= and |title-es= as duplicates.

I think it's trivial to indicate that a certain work's/section's/whatnot's title may be in a particular language in the citation; I'm unsure if the same can be said about personal names. Besides the case of psuedonyms (which, at best, we can indicate are in a particular script), is the name "Steven" in Swedish, English, or Spanish? So I'd be disinclined to agree to an |author-lang= or similar. --Izno (talk) 18:49, 7 February 2016 (UTC)

The relevant section of the HTML5 spec is The lang and xml:lang attributes, in particular the paragraph beginning "Authors must not use the lang attribute in the XML namespace on HTML elements in HTML documents." In this context, "the lang attribute in the XML namespace" means xml:lang=something. Therefore, as MediaWiki serves HTML, we must not add the xml:lang= attribute to a <i> tag. --Redrose64 (talk) 21:33, 7 February 2016 (UTC)
Concur.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  14:30, 10 February 2016 (UTC)

Cite web - source code[edit]

Is there a way to cite a URL in a way that clicking the link will instead of loading the webpage as HTML instead directly bring up its source code?

I would like to do this because a page displays some information about characters when viewed live, but when I created an archived copy there is some kind of object error which prevents its display, even though it shows up just fine when viewed live.

This happens at if you 'view source' on the archive you can see the titular character Wally's age is given as "six year old". You can see it displays as intended in the live version but the archived version gets an error which prevents people from being able to check it.

If we cannot view text directly on an archive due to problems like this, is there some way to include a note hen using template:cite web that people should 'view source' to search for a quote if the quote does not display in the archive like it did when live? (talk) 13:17, 8 February 2016 (UTC)

Place a note in the reference after the closing curly braces of the cite template. – Jonesey95 (talk) 15:07, 8 February 2016 (UTC)

Suppressing unnecessary archive-urls[edit]

It would be nice to have some option to pre-emptively archiveurl things but without having any archive-related stuff appear in the rendered citation at all, either with a particular dead-url value to suppress it, or better yet, having display suppressed by default any time dead-url=no. Having archive-related stuff appear when it is not needed is cruft that badly bloats references sections when pre-emptive archiving of Web sources is done article-wide. It's bad enough that I put all my pre-emptive archive-url and archive-date parameters inside HTML comments; it adds 7 characters of edit-mode cruft per cite, versus a big bunch of it visible to everyone when left un-commented-out.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  00:32, 9 February 2016 (UTC)

This should not be difficult. I did and then reverted a simple test to prove that a tweak to the code that handles the case of |dead-url=no worked as you described (no archive output). I'm not sure that |dead-url=no is the best parameter value to use to suppress the archive output. The historic definition means that the |url= is still assigned to |title= and 'Archived' in the archive out put is linked:
{{cite web |title=Title |url=// |archive-url=// |archive-date=2016-02-08 |dead-url=no}}
"Title". Archived from the original on 2016-02-08. 
We already have unfit and usurped which keep the archive text output but don't link to the original url:
{{cite web |title=Title |url=// |archive-url=// |archive-date=2016-02-08 |dead-url=unfit}}
"Title". Archived from the original on 2016-02-08. 
Adding another keyword to handle this particular case shouldn't be a problem. Provide an appropriate keyword.
Trappist the monk (talk) 01:04, 9 February 2016 (UTC)
Nominate hidden. It may be more intuitive to change |dead-url= to |url-state=. (talk) 14:53, 9 February 2016 (UTC)
I could go with "hidden". But having the display off by default would be better. We can have a bot check for dead links and turn the display on for cases that need it.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  14:29, 10 February 2016 (UTC)

Italics in publisher[edit]

May we use italics in |publisher= when it is a newspaper? SLBedit (talk) 00:49, 9 February 2016 (UTC)

What's wrong with using |newspaper=? E.g.
  • {{cite news|title=Headline|date=February 8, 2016|newspaper=[[Los Angeles Times]]|publisher=[[Tribune Publishing]]}}
  • "Headline". Los Angeles Times (Tribune Publishing). February 8, 2016. 
(although I would normally omit the publisher in this case). —David Eppstein (talk) 00:54, 9 February 2016 (UTC)
I normally use {{cite web}} when using a source from a newspaper's website. SLBedit (talk) 01:06, 9 February 2016 (UTC)
I'm not sure why you should: it's a newspaper, regardless of whether you are reading the print or online version, just like en e-book is still a book and an online scientific journal is still a journal. But if you insist, you can use |work=:
  • {{cite web|title=Headline|date=February 8, 2016|work=[[Los Angeles Times]]|publisher=[[Tribune Publishing]]}}
  • "Headline". Los Angeles Times. Tribune Publishing. February 8, 2016. 
David Eppstein (talk) 01:15, 9 February 2016 (UTC)
Yes, |work= (alias for |website=) adds italics. SLBedit (talk) 02:59, 9 February 2016 (UTC)
What is the reason for {{cite web}} to display a website's name in italics? SLBedit (talk) 03:07, 9 February 2016 (UTC)
cs1|2 take their styling cues from standard published style guides like MLA, APA, CMOS. No doubt, we've made certain styling decisions ourselves, but in general, cs1|2 is guided by those established style guides. 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.
Trappist the monk (talk) 12:37, 9 February 2016 (UTC)
The answer to your question is: no you may not use italics in |publisher=. Markup and static text in rendered citations is the duty and obligation of the template. The cs1|2 templates provide a machine readable version of the rendered citation as metadata. By adding extraneous markup and text to parameter values, you corrupt that metadata. This is documented in all of the cs1|2 templates at, for example, Template:Cite_web#COinS.
Trappist the monk (talk) 01:19, 9 February 2016 (UTC)
Okay. SLBedit (talk) 02:59, 9 February 2016 (UTC)
Also, do not confuse publisher with publication. Newspapers are publications; they have publishers. --Redrose64 (talk) 12:03, 9 February 2016 (UTC)
Which in many cases take the same name as their publication. --Izno (talk) 13:15, 9 February 2016 (UTC)
In reality, not exactly (nitpick). Publishers have designations (Inc., Ltd.) etc. It is a convention not to include these in citations which sometimes makes publication-title=publisher-name. (talk) 14:58, 9 February 2016 (UTC)
That's why the wording here says "substantially" the same.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  14:26, 10 February 2016 (UTC)
A recent discussion on this page showed that, while there are strong opinions, there is no documented community consensus on the use of |publisher= in a news context. I welcome anyone to go to a more public venue and try to establish such a consensus. ―Mandruss  15:27, 9 February 2016 (UTC)
  • Agreed with David. Using {{cite web|title=Aliens Invade Roswell|...||publisher=''[[Los Angeles Times]]''}} is an abuse of the parameters. If you insist on drawing a distinction between the online and print editions (this should only be done when an article appears in one but not the other, or when it appears in different form in one vs. the other), do {{cite news|title=Aliens Invade Roswell|...|work=[[Los Angeles Times]]|edition=online}}: Doeh, Janet (April 1, 2016). "Aliens Invade Roswell". Los Angeles Times (online ed.).   — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  14:24, 10 February 2016 (UTC)

Why should I use {{cite news}} for news and articles available on a newspaper's website if those articles are different from the (printed) newspaper itself? (I'm not discussing an online edition of a printed newspaper.) SLBedit (talk) 18:28, 10 February 2016 (UTC)

I don't know, maybe because they are news? ―Mandruss  19:06, 10 February 2016 (UTC)
Web news. SLBedit (talk) 19:36, 10 February 2016 (UTC)
News nonetheless. Perhaps you wish to propose {{cite webnews}}, since {{cite news}} is clearly not up to the task. Before you do that, see WP:BIKESHED. ―Mandruss  19:39, 10 February 2016 (UTC)
But a source from a newspaper's website is not always news. SLBedit (talk) 22:49, 10 February 2016 (UTC)
For that source, {{cite web}} would probably be more appropriare. That doesn't mean you can't use {{cite news}} for the items that are news. You don't have to use the same template for everything on a given site. ―Mandruss  22:55, 10 February 2016 (UTC)
Okay. SLBedit (talk) 23:00, 10 February 2016 (UTC)
{{cite news}} says, right at the top,
This Citation Style 1 template is used to create citations for news articles in print, video, audio or web.
Nothing in that sentence prevents it from being used for a news story on a newspaper's website. If you don't want to use the |newspaper= parameter, you can use |work= or |website=, as I explained above at 23:33, 31 January 2016. --Redrose64 (talk) 00:03, 11 February 2016 (UTC)
What should I use for a magazine that is part of a newspaper? I'm inclined to use {{cite magazine}} with |newspaper=, which is an alias for |magazine=. SLBedit (talk) 00:59, 11 February 2016 (UTC)
My answer depends on one factor, if that magazine is a nationally printed or recognizable item that's inserted in a paper, like Parade, versus something specific to a single paper. For the former, I'd cite the magazine with no reference to the enclosing paper as it wouldn't matter which paper that included it was consulted. In the latter case, I'd probably cite it as a department of the enclosing paper since you'd need to find that specific paper to find that magazine. Things like The New York Times Book Review, which are recognizable as their own publications would probably fall into the former case as well. Imzadi 1979  10:12, 11 February 2016 (UTC)
I would do it the other way round - you're citing a news source, so use {{cite news}} and since it's not the actual newspaper but its magazine, use e.g. |magazine=The Sunday Times Magazine. --Redrose64 (talk) 14:24, 11 February 2016 (UTC)
Agree with Imzadi1979. Most newspaper "magazines" cannot be purchased/subscribed to/searched-for independently, and therefore they cannot be verified independently of the enclosing newspaper. So they should not be cited independently. Most newspaper publishers in my experience call them their newspaper's "magazine section". The proper citation would be: {{cite news|department=Magazine|newspaper=Newspaper}}. (talk) 15:25, 11 February 2016 (UTC)
The magazine (yes, it's printed "magazine" in the cover) I'm referring to is like a supplement, it cannot be bought separately. It came with the newspaper. I don't have the newspaper anymore, but I know its issue number, which is also printed in the magazine's cover. SLBedit (talk) 18:50, 11 February 2016 (UTC)

By far the most important things about citations are:

  1. To facilitate verifiability. Give the reader a link they can click on to verify the information. And it's nice if the rendered citation looks neat and professional, too.
  2. To help combat link rot. When the link for a source goes dead, it's easier to find its new location (if any) if the cite contains information beyond the URL, such as title, author names, date, etc.

As long as your cite satisfies those two goals, the rest is trivial detail. Make some attempt to follow whatever guidance is given in the doc. Where something is not covered in the doc, or the doc is ambiguous, use your best judgment. Many of the things we agonize over make no difference in what the reader sees, so we should cease agonizing over them. Even when they make a difference in what the reader sees, it's usually a minor formatting difference that is meaningless to most readers.
My opinions. ―Mandruss  01:33, 11 February 2016 (UTC)

author-link effciency[edit]

It would be helpful if |author[N]-link=y would auto-grab values from the author/first/last[N] parameters and use them. About 80% of the time, no disambiguation or other alteration is needed (unless you use one of those awful citations styles that force the use of initials, which should be banned on WP, but that's another matter).  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  14:04, 10 February 2016 (UTC)

This would cover our article references in a sea of red links. Is that desirable? Most authors do not pass notability criteria. – Jonesey95 (talk) 14:27, 10 February 2016 (UTC)
It's only if |author-link=y is coded. ―Mandruss  14:30, 10 February 2016 (UTC)
How about having the author-link not display if no target is found? Just a little more run-time overhead. ~ J. Johnson (JJ) (talk) 19:47, 10 February 2016 (UTC)
But the same benefit would apply to other parameters that can accept wikilinks. So the first thing we'd see would be a thread saying, hey, if we have this cool autolinking feature for |author-link=, why not |work= and its aliases? And so on. Hard to justify saying yes to one and no to the rest, hard to justify the overhead to do all of them, in my opinion. Slippery slope, Unintended consequences. ―Mandruss  19:52, 10 February 2016 (UTC)
This proposal makes absolutely no sense. To reinforce what Jonesey said above, 99.9% of authors currently or will ever have a Wikipedia page devoted to them. Implementing this proposal would convert the reference section of many articles into a sea of red. Also the |author-link=y parameter makes no sense. If you are going to the trouble of using that, why not just use |author-link= as it was originally intended and only use it if and only if the corresponding page exists? (For the remaining 0.1% of authors that do have articles, it would be simple enough for a bot to create systematic redirects from the Vancouver style author name to the target article so that we can avoid that awful first1, last1, ... parameter bloat, but that's another matter ;-) Boghog (talk) 20:25, 10 February 2016 (UTC)
To link author names in |vauthors=, use |author-linkn= where n is that author's position in the |vauthors= list. Same is true for |veditors=. Bots to create redirects not needed.
Trappist the monk (talk) 20:37, 10 February 2016 (UTC)
Completely agree that bots are not needed (see below). Boghog (talk) 21:07, 10 February 2016 (UTC)
Implementing this proposal would convert the reference section of many articles into a sea of red - No reading of SMcCandlish's proposal suggests such an outcome. No reading of J. Johnson's proposal suggests such an outcome. Both mentions of "sea of red" have been unfounded. I assumed that Jonesey95 simply misread the proposal, but to continue saying that is puzzling to me.
I assume the point of SMcCandlish's proposal is that |last=Ishihara|first=Shintaro|author-link=Shintaro Ishihara is significantly more difficult and time-consuming for the average, non-techy user than |last=Ishihara|first=Shintaro|author-link=y, as well as being a case of data redundancy/duplication. It has a small upside and no downside that I can see, aside from the one-time developer effort, and a small bit of feature creep. ―Mandruss  20:50, 10 February 2016 (UTC)
OK, I misread the original proposal, but I still think it doesn't make any sense. Works "80% of the time" is a non starter. In addition, there are numerous ways that an the title of an author could be spelled and authors with the same name are a frequent occurrence. It is simpler and more reliable for an editor to locate and link the author's article than relying on an automatic procedure that will frequently be wrong. Boghog (talk) 21:09, 10 February 2016 (UTC)
The proposal assumes that the editor would first check to see if the article's title is an exact match for first+last. The only difference would be what they code. They wouldn't use the feature in cases where it wouldn't work. The 80% number is the proposer's guesstimate of the proportion of cases where it would work. ―Mandruss  21:14, 10 February 2016 (UTC)
Assumptions concerning editor behavior are dangerous. An editor would have made a conscious decision to use the |author-linkn= and is more likely to have checked the target of the link. An editor using |authorn-link=y may assume that it would work without checking. Boghog (talk) 21:33, 10 February 2016 (UTC)
A fair point. A competent editor would check for a redlink, but not all editors are that competent. At least we're now on the same page as to what the proposal means. ―Mandruss  21:38, 10 February 2016 (UTC)
I don't like this idea. No automatic system will be able to determine if the linked-to article is the right one. Consider Diana Ross (author) - how is the system going to know that the disambiguator is necessary to distinguish from the Motown singer? --Redrose64 (talk) 00:23, 11 February 2016 (UTC)
The system doesn't determine that, the editor does. As I've said, the editor would not code |author-link=y unless they have checked and determined that the correct article's title is a match for first+last. At least that's how the proposal intends for it to work. ―Mandruss  00:30, 11 February 2016 (UTC)

date=, year= mismatch[edit]

Hi there. In this edit I overcame a date=/year= mismatch error but I do not feel this is a proper edit to really fix the error. What is the correct fix? The papers were re-released in 2010 and written in 1914. Ping me back. Cheers! {{u|Checkingfax}} {Talk} 04:42, 11 February 2016 (UTC)

I don't think it was the correct fix. Your cite uses |date=28 January 1914 which appears to refer to the date of the lecture that is Chapter 12. Generally, |date= is the publication date. The template identifies Cambridge University Press as publisher but links to the Bartleby version. The Bartleby version is dated April 2000. According to WorldCat and GoogleBooks, the ISBN is for a 2008 Cambridge publication. Were I seeking the exact source that you are citing, I would be at a loss since I cannot extract the reality, the WP:SAYWHEREYOUGOTIT, from this collection of mismatched facts. Choose one source, and cite that. Since the Bartleby appears to support the article text, I would rewrite the cite this way:
{{cite book |last1=Quiller-Couch |first1=Sir Arthur |title=On the Art of Writing: Lectures Delivered in the University of Cambridge, 1913–1914 |edition=Online |url= |access-date=3 March 2012 |date=2000 |orig-year=1916 | |chapter=XII. On Style |chapterurl= |at=¶6}}
Quiller-Couch, Sir Arthur (2000) [1916]. "XII. On Style". On the Art of Writing: Lectures Delivered in the University of Cambridge, 1913–1914 (Online ed.). ¶6. Retrieved 3 March 2012. 
Trappist the monk (talk) 11:15, 11 February 2016 (UTC)