Module talk:Citation/CS1/Archive 9

Archive 5

←

Archive 7

Archive 8

Archive 9

Archive 10

Archive 11

Archive 12

Date and year ranges

Why does {{Cite encyclopedia |title=dummy date=2000-2001}} create an error? Imho date=2000-2001 should be valid, and I think it used to be. Debresser (talk) 20:33, 14 December 2013 (UTC)

This is a topic that hasn't been fully discussed and there is a feature request to support it because year ranges are permitted by MOS:DATES.

The date checking is new so year ranges worked because they were never checked. My opinion: year ranges in citations are inappropriate. When using {{cite encyclopedia}}, an editor is usually citing an encyclopedia's article, perhaps a page or page range, and a volume of an encyclopedia that was published in a particular year. The WP:SAYWHEREYOUGOTIT ethos, in my mind, requires a modicum of specificity. If an encyclopedia was published across a range of years, 1885–1920 for example, it seems to me that the editor is obligated to state the year of the publication that was consulted to support the Wikipedia article text. To do otherwise indicates laziness on the part of the editor.

—Trappist the monk (talk) 21:20, 14 December 2013 (UTC)

I would disagree with you on this issue. In any case, {{Cite Jewish Encyclopedia}} disagrees with you. When will this feature request be implemented, or is it still being discussed? Debresser (talk) 22:21, 14 December 2013 (UTC)

Ok, let's look at {{cite Jewish Encyclopedia}}. Yes, the whole encyclopedia was published beginning with volume 1 in 1901 and ending in 1906 with volume 12. Apparently, this edition is collectively referred to as the 1906 edition. At {{cite Jewish Encyclopedia}} the examples given are to an article "Atonement, Day of":

1. Singer, Isidore; et al., eds. (1901–1906). "Atonement, Day of" . The Jewish Encyclopedia. New York: Funk & Wagnalls.
2.  Jastrow, Morris (1901). "Atonement, Day of". In Singer, Isidore; et al. (eds.). The Jewish Encyclopedia. Vol. 1. New York: Funk & Wagnalls. p. 1.

The other two examples at {{cite Jewish Encyclopedia}} are similar and illustrate the use of |noicon= so are not included here. In example 1, the template links to "Atonement, Day of" at Wikisource. The Wikisource transcription of the article is not dated, nor does it identify the specific source (volume, page, contributor, etc). From the Wikisource article, you can link to Jewish Encyclopedia where publication dates are listed as 1901–1905. This date range is not supported by any citations (the Wikisource Jewish Encyclopedia is very incomplete).

Were I citing the Wikisource transcription I might do it this way:

{{cite encyclopedia |encyclopedia=[[Jewish Encyclopedia]] |via=Wikisource |chapter=Atonement, Day of |chapterlink=:s:Jewish Encyclopedia/Atonement, Day of}}

→"Atonement, Day of". Jewish Encyclopedia – via Wikisource. {{cite encyclopedia}}: Unknown parameter |chapterlink= ignored (help)

In example 2, the template links to "Atonement, Day of" at a website called jewishencyclopedia.com. This too, is undated except that at the top of the page there is text that reads: The unedited full-text of the 1906 Jewish Encyclopedia. From this example, one might expect that "Atonement, Day of" is found on page 1 of volume 1 (of a website?) and was written by Morris Jastrow. There is a Jastrow mentioned in the article's bibliography but it's not clear that that Jastrow is Morris Jastrow.

Were I citing the jewishencyclopedia.com transcription I might do it this way:

{{cite web |website=Jewish Encyclopedia |title=Atonement, Day of |url=http://www.jewishencyclopedia.com/articles/2093-atonement-day-of |date=1906 |accessdate=2013-12-15}}

→"Atonement, Day of". Jewish Encyclopedia. 1906. Retrieved 2013-12-15.

If you go to the Internet Archive, you can find all of the 12 volumes of Jewish Encyclopedia. So, I looked up "Atonement, Day of". It's in volume 2 (not 1), begins on page 284 of that facsimile (not 1), and the contributor is Max L. Margolis (not Jastrow). Were I citing the Internet Archive facsimile I might do it this way:

{{cite encyclopedia |encyclopedia=[[Jewish Encyclopedia]] |publisher=KTAV Publishing House |via=Internet Archive |location= |date=nd |volume=2 |title=Atonement, Day of |last=Margolis |first=Max L. |editor-last=Singer |editor-first=Isadore |url=//archive.org/stream/jewishencycloped02sing#page/284/mode/2up |pages=284–289}}

→Margolis, Max L. (nd). "Atonement, Day of". In Singer, Isadore (ed.). Jewish Encyclopedia. Vol. 2. KTAV Publishing House. pp. 284–289 – via Internet Archive.

(Undated because I couldn't find a publication or copyright date in the volume 2 facsimile.)

Given all of this, it seems to me that {{cite Jewish Encyclopedia}} is rather desperately in need of an overhaul which it is in my mind to do.

If the point is to cite an article whether it is at Wikisource, or at jewishencyclopedia.com, or at Internet Archive, then I see no point in using date ranges because either the specific location of the source has a particular date or it is undated. If you must use a date, and you are consulting either Wikisource or jewishencyclopedia.com then the date should be 1906 (although |accessdate= might be a better choice for the latter). If you are consulting a physical copy of Jewish Encyclopedia, |date= should be the date of the volume you are consulting.

—Trappist the monk (talk) 13:23, 15 December 2013 (UTC)

I have seen many citation templates that use date ranges. So do sources often. And for good reason, as in the case of a several day conference. What it comes down to is that date ranges are a fact, both on Wikipedia and in the real world, and they need to be supported. Like it or not. :)

As a reply to what you say above. I think it is more correct to have a date range than no date at all, as you propose in your "how I would have done it" above. I'd rather see that done soon, than an overhaul of Template:Cite Jewish Encyclopedia, which everybody seems quite happy with. Debresser (talk) 14:46, 15 December 2013 (UTC)

I think it is more correct to have a date range than no date at all isn't a very persuasive argument because it amounts to little more than "because I like it." Can you at least say why you think this?

—Trappist the monk (talk) 16:54, 15 December 2013 (UTC)

Likewise, at Template:Egyptian parliamentary election, 2011 there is a source that uses a range: 22 - 28 December 2011. This should be allowed. Debresser (talk) 22:59, 14 December 2013 (UTC)

Who is making decisions on what is appropriate? Not it seems people who were involved in many of the PD templates?

@Debresser I have just put back month in to {{Cite Jewish Encyclopedia}} better it passes it through to to be handled at a lower level than that it kills it silently as then there is no way to tell how many articles are using it. I think you really should have discussed it on the talk page of the template before removing it.

@Trappist the monk you write "My opinion: year ranges in citations are inappropriate" be that as it may, if one does not know from which volume a citation comes then a date range is appropriate over the whole volume print. Indeed some of the templates, for things like the DNB calculate the year if the volume number is given, but if it is not then it puts in a year range. With the DNB the project is nearing completion on Wkisource and has all the facts such as author volume and page on each article, but many of the encyclopaedias do not. Therefore it is quite common for someone to have access to the text of an encyclopaedia without knowing the volume and therefore the precise year of publication. Besides some volumes are split into parts and difference parts may come out in different years.

BTW the month parameter is very useful for volumes that span a range of months but only one year. The span of months can be dropped in to the month parameter for visual reference leaving the year parameter to be used with the author or editor last name in a standard ref=harv manner. If the day and month range is such that the date parameter can not handle it then one is faced with two alternative. Either pass in a date and a year parameter (but that is subject to some good citizen removing the year parameter not realising its use with ref=harv or putting in a ref={{sfnRef}} which is more trouble than it is worth. -- PBS (talk) 22:52, 14 December 2013 (UTC)

Editors should be citing the source material as they know it to be. If the information is taken from a paper copy of DNB or Venn or Jewish Encyclopedia, then all of the normal information one expects from {{cite book}} should be in the citation. If the source is an electronic facsimile like Venn or Jewish Encyclopedia at Internet Archive or any number of works at Google Books, then one should include all of the information normally used with {{cite book}}. If the source is an electronic transcription like Wikisource or jewishencyclopedia.com or A Cambridge Alumni Database or Project Gutenberg then one should include all of the information normally used with {{cite web}} and |accessdate= is likely appropriate.

Date ranges do little to identify the specific location of the source material. In your example of the DNB, the date range that covers the period during which the individual volumes were published does little to identify the specific volume that an editor is citing. On the other hand, knowing the year of publication can narrow the field. But, I have to wonder, if an editor is stating some fact and supporting it with {{cite DNB}} citations but doesn't know the volume, then that editor should step back, and simply cite where he got the fact and not try to misapply {{cite DNB}}.

—Trappist the monk (talk) 16:54, 15 December 2013 (UTC)

PBS, you are right. I should have discussed this. In any case, as soon as the article that use it are fixed, it can (and as a deprecated parameter should) be removed. Debresser (talk) 23:02, 14 December 2013 (UTC)

I notice that you have done it for a lot of templates, have you checked them all before you did it and have you updated the documentation of all the templates to reflect you change? It seems to me that you need to write some code to check all the instances. The you need to change the documentation for each template, then run your code over very instance, check if combining month and year into the date parameter breaks date parameter, if not then combine them automatically if it does work out how you can fix it manually. Only after those steps have been taken should the templates be changed to stop passing through month parameters. -- PBS (talk) 23:11, 14 December 2013 (UTC)

I have not done this for other templates, to the best of my memory. If you see any, please write me on my talkpage. Debresser (talk) 23:37, 14 December 2013 (UTC)

(edit conflict)I'll get round to answering other issues raised above later.

1. A wrapper template can pass |date=, |month=, and |year= to {{cite encyclopedia}} which then passes them to Module:Citation/CS1
2. If |date=, |month=, and |year= are all passed from the wrapper through {{cite encyclopedia}} to Module:Citation/CS1 then:

   |date= becomes a new variable called Date

   |month= is discarded

   |year= is used for the |ref=harv anchor id

3. If |month= and |year= without |date= are passed from the wrapper through {{cite encyclopedia}} to Module:Citation/CS1 then:

   the module concatenates |month= and |year= into the new variable Date.

   |month= and |year= are then discarded

   the year portion of Date is used for the |ref=harv anchor id

4. If |date= without |month= and |year= is passed from the wrapper through {{cite encyclopedia}} to Module:Citation/CS1 then:

   |date= becomes the new variable Date

   the year portion of Date is used for the |ref=harv anchor id

This is an attempt a clarity. If I haven't succeeded, let me know.

—Trappist the monk (talk) 23:43, 14 December 2013 (UTC)

This I think is clear. Just to remind everybody that the issue of this subsection is to allow ranges of dates. It seems to be in practical use, based in at least some cases on sources. Debresser (talk) 01:28, 15 December 2013 (UTC)

This happens often with {{Cite conference}}, because many conferences last several days. Debresser (talk) 09:24, 15 December 2013 (UTC)

Citation Style 1 currently lacks it's own well-considered, well-known advice on publication dates. To form such advice, it makes sense to look at printed style guides, such as The Chicago Manual of Style (16th ed.). That guide has relevant guidance.

Sec. 14.151 on p. 772 indicates that "when an entire multivolume, multiyear work is cited, the range of dates is given (see 6.79)." If the work is not completed, the first year is given followed by an n-dash. Two examples given are:

Hayek, F. A. Contra Keynes and the Cambridge: Essays, Correspondence. Vol. 9 of The Collected Works of F.A. Hayek. Chicago: University of Chicago Press, 1998-.

Tillich, Paul. Systematic Theology. 3 vols. Chicago: University of Chicago Press, 1951–63.

Jc3s5h (talk) 17:10, 15 December 2013 (UTC)

It seems that your first example doesn't comply with the when an entire multivolume, multiyear work is cited clause. Volume 9 is clearly only part of The Collected Works of F.A. Hayek so the publication date of that volume is the appropriate date. For Tillich, a date range is appropriate and is in compliance with the multivolume, multiyear criteria.

—Trappist the monk (talk) 17:30, 15 December 2013 (UTC)

It's not my example, it's Chicago's example. You don't get to overrule Chicago. Furthermore, since I have proven that date ranges are accepted in citations by one of the most important citation styles, it is inappropriate for Wikipedia editors to decide to overrule Chicago on an obscure page about how a module is coded. It seems to me if you want to overrule Chicago you must first obtain consensus to do so through a widely-advertised RFC. Jc3s5h (talk) 17:44, 15 December 2013 (UTC)

Who said anything about overruling Chicago? Obtain consensus to overrule Chicago? We here at Wikipedia have no power over Chicago. You are reading something there that I did not write. I merely pointed out that the Hayek citation seems to violate Chicago as you quote it. Nothing more.

CS1 is not Chicago. CS1 is not ALA. Nor is CS1 any of the other style guides.

—Trappist the monk (talk) 18:19, 15 December 2013 (UTC)

Editors have been using CS1 for years. There has never been any guidance that I can find telling the users of these templates that they shouldn't have publication dates (whether using the date parameter or year parameter) that contain date ranges. In the absence of any rules to the contrary, we would expect editors to follow normal scholarly citation practices, and guides such as APA and Chicago are evidence of what normal scholarly citation practice is. In the absence of any CS1 rule to the contrary, a practice found in two major style guides is not an error. Jc3s5h (talk) 18:37, 15 December 2013 (UTC)

It seems APA Style largely agrees with Chicago. The 6th edition p. 185 states

*For several volumes in a multivolume work or several letters from the same collection, express the date as a range of years from earliest to latest (see Chapter 7, examples 23 and 65).

23...Koch, S. (Ed.). (1959-1963) Psychology: A study of science (Vols. 1–6). New York, NY: McGraw-Hill.

65...Allport, G. W. (1930-1967). Correspondence. Gordon W. Allport Papers (HUG 4118.10). Harvard University Archives, Cambridge, MA.

Since APA uses parenthetical citations, the details about which Allport letter was being cited would be contained in the in-line parenthetical citation.

Jc3s5h (talk) 17:56, 15 December 2013 (UTC)

To not loose my reply in the discussion, I'll post it here. I said that I like a range better than no date at all. Trappist the monk asked if this isn't the "I like" argument. Of course it is not. Having some information, in this case a range of a few years, is better than having no information at all. If I know a work was written from 1901-1906, e.g., I will at least understand it is not a contemporary work. Also, and this I can not stress enough, sources themselves often give a date range, like in the writings from a scientific conference e.g. If it is in sources, we should be able to allow for it. Debresser (talk) 20:44, 15 December 2013 (UTC)

Consider the hypothetical case of a journal published more than once a year, which uses neither volume nor issue numbers. The obvious unique identifier is the cover date, which might be shown as "January-April 2013", "May-August 2013", and "September-December 2013". Let's say we use the second one as a ref source. Do we put contrived dates like |date=May 2013 or |date=August 2013, or the truth |date=May-August 2013? --Redrose64 (talk) 21:03, 15 December 2013 (UTC)

Month ranges are supported already:

{{cite journal |journal=Journal of Foo |date=May-August 2013}}

Journal of Foo. May–August 2013. {{cite journal}}: Missing or empty |title= (help)CS1 maint: date format (link)

What needs to be added are valid day ranges, e.g. "5-11 December 2013" and valid year ranges, e.g. "1898-1900".

{{cite journal |journal=Weekly Journal of Foo |date=5-11 December 2013}}

Weekly Journal of Foo. 5–11 December 2013. {{cite journal}}: Missing or empty |title= (help)CS1 maint: date format (link)

{{cite web |website=Journal of lazy publishing dates |date=2005-2013|url=http://foo}}

"Web site with copyright range but no findable publishing date". 2005–2013. {{cite web}}: Check |url= value (help)CS1 maint: date format (link)

– Jonesey95 (talk) 21:47, 15 December 2013 (UTC)

I think most editors here agree that date and year ranges should be valid. Can this be implemented? Note, ranges may be indicated with a variety of dashed (regular, en-dash, em-dash). Debresser (talk) 16:40, 21 December 2013 (UTC)

Valid date ranges are what the documentation of the various templates say are valid. I haven't looked at all the templates, but Help:Citation style 1 says to use WP:DATESNO (which does not address date ranges). In addition, seasons, hyphenated seasons ("spring-summer") and dates in religious calendars are listed as valid. There is no description of how to write day, month, or year ranges. Should these proposed changes be the subject of a well-advertised RFC before implementation?

My position is if you don't have consensus for the documentation changes, or don't even know what the documentation changes will be, then you're not ready for implementation. Jc3s5h (talk) 17:12, 21 December 2013 (UTC)

WP:DATESNO addresses date range style in the third bullet point below the acceptable dates table. Date range style is also addressed at WP:DATERANGE and MOS:DOB; both of which are subsections of WP:DATESNO.

—Trappist the monk (talk) 18:08, 21 December 2013 (UTC)

Sorry, I missed that; day, month, and year ranges are indeed covered. Jc3s5h (talk) 18:15, 21 December 2013 (UTC)

So will the module start allowing it? Debresser (talk) 19:02, 21 December 2013 (UTC)

I second that. The rejection of year ranges by the validation has broken links to valid citations from {{harv}} and {{sfn}} in many articles. Kanguole 02:28, 26 December 2013 (UTC)

Extra text in |date=

Another example: in the article 163P/NEAT the date "2012-01-20 last obs". At date= to |type= be acceptable to remove citation error messages? I argue that "2013-03-03 (solution date)" would be a more appropriate date, but the principle is the same. Some sources don't have a traditional publication date found in the traditional place (top center of front page of newspaper, copyright page of a book, etc.) Thus one must be able to specify which of several reasonable publication dates the editor has decided to cite. Jc3s5h (talk) 18:54, 29 December 2013 (UTC)

Update to the live CS1 module week of 2013-11-03

Toward the end of this week I propose to update Module:Citation/CS1 to match Module:Citation/CS1/sandbox (diff) and Module:Citation/CS1/Configuration to match Module:Citation/CS1/Configuration/sandbox (diff). This update changes several things:

1. Added deprecated parameter tracking for deprecated parameters: Adds pages to Category:Pages containing cite templates with deprecated parameters when they contain the parameters |month=, |coauthor=, and |coauthors=
2. Extract common code from checkisbn() and issn() into new function is_valid_isxn(): Checkdigit calculation code for ISSN and for ISBN-10 is esentially the same so created a single function to do that
3. Migrate cite thesis: discussion
4. ISBN 13 checked for 978 and 979 prefixes: discussion
5. Migrate cite techreport: discussion
6. Date validation: discussion – by far the largest, this change checks dates for format compliance with MOS:DATE, checks date validity (no June 31, etc), allows year disambiguation in CITEREF identifiers when referenced authors have multiple works published in the same year without the need to use both |date= and |year=, and does not corrupt the COinS metadata.

—Trappist the monk (talk) 23:37, 4 November 2013 (UTC)

Done.

—Trappist the monk (talk) 13:15, 9 November 2013 (UTC)

Why deprecate coauthors it is useful parameter for those authors one does not wish to include in a short citation. I often use it for et all. If I am not to use if for that purpose what is the most elegant work around? -- PBS (talk) 23:04, 14 December 2013 (UTC)

Can you give an example of a citation where you have used |coauthors= to achieve a desired effect? We can probably show you how to use valid parameters to achieve the same effect. I use |displayauthors= when I want to show only a few authors and have "et al." added automatically. – Jonesey95 (talk) 23:06, 14 December 2013 (UTC)

It is difficult to find one, as I have not kept records of such edits. But here is a source: http://www.british-history.ac.uk/report.aspx?compid=117002 where coauthors would be useful. The point is I do not want to have to type in half a dozen or more authors when I can simply use coauthors=et all to do the same thing.

Take for example this citation with eight authors

{{citation |last1=one |last2=two |last3=thee |last4=four |last5=five |last6=six |last7=seven |last8=eight |year=2001 |title=Title}} one; two; thee; four; five; six; seven; eight (2001), Title generates CITEREFonetwotheefour2001

With displayauthors

{{citation |displayauthors=1 |last1=one |last2=two |last3=thee |last4=four |last5=five |last6=six |last7=seven |last8=eight |year=2001 |title=Title}} one; two; thee; four; five; six; seven; eight (2001), Title {{citation}}: Unknown parameter |displayauthors= ignored (|display-authors= suggested) (help) generates CITEREFonetwotheefour2001

With coauthors

{{citation |last1=one |coauthors=''et al'' |year=2001 |title=Title}} one (2001), Title {{citation}}: Unknown parameter |coauthors= ignored (|author= suggested) (help) generates CITEREFone2001

So displayauthors= and coauthors= generate similar looking output but the CITEREF generated is different -- Why add names to a reference that are not displayed when coauthors=et al is easier to type and does not cause complications with CITEREF? (WYSIWYG) -- PBS (talk) 17:53, 20 December 2013 (UTC)

Trying two things. I don't know how to show or see the CITEREF.

One author with displayauthors

{{citation |displayauthors=1 |last1=one |year=2001 |title=Title}}

one (2001), Title {{citation}}: Unknown parameter |displayauthors= ignored (|display-authors= suggested) (help) generates CITEREFone2001 (I don't know how to see the CITEREF)

One author with last2=et al.

{{citation |last1=one |last2=''et al.'' |year=2001 |title=Title}}

one; et al. (2001), Title {{citation}}: Explicit use of et al. in: |last2= (help) generates CITEREFoneet_al.2001 (I don't know how to see the CITEREF)

– Jonesey95 (talk) 18:53, 20 December 2013 (UTC)

You can determine a CITEREF by viewing the page source; search for

<span id="CITEREF

and it goes from there to the next double quote. Alternatively, fill in the parameters of {{harvid}} and sandbox it:

{{harvid|one|2001}} → CITEREFone2001

{{harvid|one|et al.|2001}} → CITEREFoneet_al.2001

I've filled them in above. One reason not to use et al. but instead supply all the authors and set |displayauthors= is so that all of them get added to the COinS metadata. --Redrose64 (talk) 23:11, 20 December 2013 (UTC)

{{harvnb|one|''et al.''|2001}} does generate "CITEREFoneet_al.2001" but not in the form that appears on this page it generates "CITEREFone.27.27et_al..27.272001" while {{citation |last1=one |last2=''et al.''|year=2001 |title=Title}} generates CITEREFoneet_al.2001 no italics in CITEREF. So the two do not match.

Why bother with embedding et al in the CITEREF when one can use coauthors=et all and bypass it? After all we have just established (below) that if one has five or more author parameters they CITEREF will not match the {[tl|harvnb}} use of the same author parameters. Even if that is fixed (and the italic problem is fixed), it seems to me better to use coauthors=et all as it means less parameters and therefore less chance of errors in typing in names of multiple authors that are visually obscured and therefore harder to check for spelling errors and typos. It is far less confusing for people to understand that any value in "coauthors" will be ignored as part of the ref=harv construction than trying to explain the intricacies of something they can not even see and with which errors which are clearly not widely known event to those who are interested in the subject and commenting here. -- PBS (talk) 00:23, 21 December 2013 (UTC)

Therefore I think that coauthors should be note be depreciated, and I would appreciate it if someone would indicate where the consensus was formed that it should be depreciated. -- PBS (talk) 13:37, 21 December 2013 (UTC)

CS1 does not have any particular guidance about how to treat institutional authors, for example, the National Institute of Standards and Technology. Should they be considered an author or a publisher. Naturally many editors over the years will have decided to treat institutional authors as authors. Thus, the coauthors parameter must continue to be supported to allow for the case where a publication is written by two or more institutions. Obviously last2 and first2 are not suitable parameters if the second author is an institution. Jc3s5h (talk) 13:52, 21 December 2013 (UTC)

@Jc3s5h: Couldn't you use |author2=National Institute of Standards and Technology instead? GoingBatty (talk) 15:50, 21 December 2013 (UTC)

There are so many misapprehensions on this page that I just don't know where they are all coming from; I've already dealt with some elsewhere on this page.

Putting italics into a surname will not break a CITEREF link, but those italics are unnecessary if the documentation is followed. Forget coauthors, and fill in as many |lastn=|firstn= pairs as there are individual authors. Institutional or corporate authors go in |authorn=. Set |displayauthors=1 if you want "et al." to be displayed after the first author. Set |ref=harv (unnecessary if you're using {{citation}}). Fill in {{harvnb}} as per its documentation with no more than four surnames. Save it; the links will work.

If you don't believe me, you can install User:Ucucha/HarvErrors to check quickly whether any of the links from {{harvnb}} are broken. --Redrose64 (talk) 19:58, 21 December 2013 (UTC)

Redrose64 you write "Putting italics into a surname will not break a CITEREF link". It is not that it is broken but that the harvard templates do include the italic symbols in CITEREF while {{citation}} does not. But because the output is hidden it seem even expedience users can find it confusing:

Here is an example to show that it does:
First long verified sentence with italics. Second long verified sentence with no italics. Notes References one; et al. (3001), Title {{citation}}: Check date values in: |year= (help); Explicit use of et al. in: |last2= (help) (created with: <nowik>{{</nowiki>citation |last1=one |last2=et al |year=3001 |title=Title}} )

Redrose64 you also write "Forget coauthors, and fill in as many |lastn=|firstn= pairs as there are individual authors". Why make more work with potential unseen errors when one can simply use coauthors to achieve the same or better results?

Also Jc3s5h there may well be times that one wants to list co-author institutions in the long citation, but not mention them in the short citation. For example William Cobbett Cobbett's parliamentary history of England] can include "Great Britain Parliament" as one of the authors, but usually if one is using harv inline citations one would usually write (Corbbett 1625, p. 152) and not (Corbbett & Great Britain Parliament, 1625, p. 152) nor (Corbbett & et al, 1625, p. 152); which is another reason for keeping the flexibility afforded by coauthors.

Also (Corbbett & et al 1625, p. 152) looks tacky one would usual write that (Corbbett, et al 1625, p. 152)

I want to encourage more editors to use the citation templates. Making it more difficult to use and less intuitive will not help convince those who currently do not use them (because they say the templates are more trouble than they are worth), and making them fill out fields that are not then displayed etc is not the way to go. -- PBS (talk) 14:24, 22 December 2013 (UTC)

My comment about "Putting italics into a surname will not break a CITEREF link" concerned the surnames in {{citation}}. But the point is this: if you fill in |lastn= of {{citation}}, and the unnamed parameters of {{sfn}} correctly, the link between {{sfn}} and {{citation}} is automatic. The |coauthors= parameter has never been involved in the construction of these links. --Redrose64 (talk) 14:50, 22 December 2013 (UTC)

which is why it is desirable to keep the coauthors parameter as it simplifies what is otherwise an unnecessary complication. Since we started this thread I have come across an example of the sort of thing I am talking about, an example with one author who would be cited in a (harvard) citation, but where one may wish to cite the institution in the full citation:

example: last=Finch, author2=English Court of Chancery, or coauthors=English Court of Chancery

A1 fact (Finch 1724, p. 404)( does not link) A2 fact (Finch & English Court of Chancery 1724, p. 404) (links) B fact (Finch 1725, p. 404) (links as expected) References {{Citation |last=Finch |first=Heneage (Earl of Nottingham) |author2=English Court of Chancery |displayauthors=1 |year=1724 |editor-first=William |editor-last=Nelson |title=Reports of cases decreed in the High Court of Chancery: during the time Sir Heneage Finch, afterwards earl of Nottingham, was lord chancellor. (1673-1680) |publisher=R. Gosling}} Finch, Heneage (Earl of Nottingham); English Court of Chancery (1724), Nelson, William (ed.), Reports of cases decreed in the High Court of Chancery: during the time Sir Heneage Finch, afterwards earl of Nottingham, was lord chancellor. (1673-1680), R. Gosling {{citation}}: Unknown parameter |displayauthors= ignored (|display-authors= suggested) (help) {{Citation |last=Finch |first=Heneage (Earl of Nottingham) |coauthors=English Court of Chancery |year=1725 |editor-first=William |editor-last=Nelson |title=Reports of cases decreed in the High Court of Chancery: during the time Sir Heneage Finch, afterwards earl of Nottingham, was lord chancellor. (1673-1680) |publisher=R. Gosling}} Finch, Heneage (Earl of Nottingham) (1725), Nelson, William (ed.), Reports of cases decreed in the High Court of Chancery: during the time Sir Heneage Finch, afterwards earl of Nottingham, was lord chancellor. (1673-1680), R. Gosling {{citation}}: Unknown parameter |coauthors= ignored (|author= suggested) (help)

Note that the year parameter is different 1724 and 1725. As an be seen displayauthors=1 does not have the desired affect instead it inverts the desired outcome (hiding authors in the long reference and requiring them in the short reference). -- PBS (talk) 18:18, 27 December 2013 (UTC)

Template:Harv#Large_numbers_of_authors explains how to achieve what appears to be your desired effect. It also allows editors to accurately display the existence of additional authors in the short footnote, which |coauthors= does not do.

example: last=Finch, author2=English Court of Chancery, or coauthors=English Court of Chancery

A1 fact (Finch et al. 1726, p. 404) (links after following instructions) A2 fact (Finch & English Court of Chancery 1726, p. 404) (no longer links since harvid is manually set, but if you want this result, just avoid using ref=harvid) B fact (Finch 1727, p. 404) (links as expected but does not indicate existence of additional authors) References {{Citation |last=Finch |first=Heneage (Earl of Nottingham) |author2=English Court of Chancery |displayauthors=1 |year=1724 |editor-first=William |editor-last=Nelson |title=Reports of cases decreed in the High Court of Chancery: during the time Sir Heneage Finch, afterwards earl of Nottingham, was lord chancellor. (1673-1680) |publisher=R. Gosling |ref = {{harvid|Finch et al.|1726}}}} Finch, Heneage (Earl of Nottingham); English Court of Chancery (1726), Nelson, William (ed.), Reports of cases decreed in the High Court of Chancery: during the time Sir Heneage Finch, afterwards earl of Nottingham, was lord chancellor. (1673-1680), R. Gosling {{citation}}: Unknown parameter |displayauthors= ignored (|display-authors= suggested) (help) {{Citation |last=Finch |first=Heneage (Earl of Nottingham) |coauthors=English Court of Chancery |year=1727 |editor-first=William |editor-last=Nelson |title=Reports of cases decreed in the High Court of Chancery: during the time Sir Heneage Finch, afterwards earl of Nottingham, was lord chancellor. (1673-1680) |publisher=R. Gosling}} Finch, Heneage (Earl of Nottingham) (1727), Nelson, William (ed.), Reports of cases decreed in the High Court of Chancery: during the time Sir Heneage Finch, afterwards earl of Nottingham, was lord chancellor. (1673-1680), R. Gosling {{citation}}: Unknown parameter |coauthors= ignored (|author= suggested) (help)

– Jonesey95 (talk) 19:34, 27 December 2013 (UTC)

Of course one can do it through manipulating the CITEREF with {{harvid}}, but just lays yet another level of complexity onto the mix which can be avoided by using coauthors. I think it is important that the interface is kept as simple as possible for inexperienced users as there is a very strong prejudiced against using templates by some very experienced editors and making the interface of citation templates more complexed than they need to be is a mistake, and for that reason I think that 1727 with the option of using coauthors= should be kept. -- PBS (talk) 13:12, 31 December 2013 (UTC)

CITEREF and harvnb and CITEREF and CS1

As a tangential point if there are more than 5 or more last=name then {{harvnb}} does not work because it allows five authors while {{citation}} only allows four.

{{citation |last1=one |last2=two |last3=three |last4=four |last5=five |last6=six |last7=seven |last8=eight |year=2001 |title=Title}} one; two; three; four; five; six; seven; eight (2001), Title generates CITEREFonetwothreefour2001

{{harvnb|one|two|three|four|five|six|seven|eight|2001}}one et al. 2001 generates |CITEREFonetwothreefourfive (NB no year)

-- PBS (talk) 17:53, 20 December 2013 (UTC)

{{harvnb}} does not allow five authors: it allows four plus a year - the documentation does state "Up to four authors can be given as parameters. (If there are more than 4 authors only the first 4 should be listed." Taking your last example and formatting it correctly, we have {{harvnb|one|two|three|four|2001}}one et al. 2001 generates |CITEREFonetwothreefour2001 --Redrose64 (talk) 22:59, 20 December 2013 (UTC)

Yes I am aware of how to work around it, but that is not really the point, at the moment there are two templates that are meant to share a common protocol (CITEREF) and if there are more than four authors they behave differently. As most editors will not be displaying the CITEREF value when editing a page and are unlikely to notice that documentation mentions this extremity, it would be much better if they handled five author parameters in the same way. -- PBS (talk) 23:53, 20 December 2013 (UTC)

Part of the problem is that the CS1 templates use named parameters: |last=, |lastn=, |date=, etc. {{sfn}} and the {{harv}} family don't use named parameters except for location specifiers |p=, |pp=, or |loc=. Because of that, {{sfn}} expects that editors will obey the rules and set the last parameter in the template to a year value that will match with the |date= value in the CS1 citation.

I suppose that we could change Module:Footnotes to check the value of the last positional parameter to make sure that it looks like a number and emit an error message if it dosn't. That seems a bit unnecessary to me because the HarvErrors script handles that quite adequately.

—Trappist the monk (talk) 01:19, 21 December 2013 (UTC)

That is not an elegant solution because someone may have rolled their own using {{SfnRef}}. I think it can be fixed in a more elegant way by looking at the number of unnamed parameters: If the number unnamed parameter >5 then ignore all but the first 4 and the last one. -- PBS (talk) 13:15, 21 December 2013 (UTC)

A sandbox version of {{sfn}}. This only changes the {{sfn}} portion of Module:Footnotes/sandbox.

{{sfn/sandbox|First|Second|Third|Fourth|Fifth|Sixth|Seventh|Eighth|Year}}

which yields an inline citation

with this CITEREF anchor id: CITEREFFirstSecondThirdFourthYear

References

This is what you are looking for?

—Trappist the monk (talk) 15:18, 21 December 2013 (UTC)

The documentation at {{sfn}} points out several other template names that can be used to perform the same function as sfn. For example, an inline cite might be coded ...wrote the group<ref name=JonesGang>{{harvnb|Jones |Cruthers|Peters |Chen |Ng |Phillips |2013}}</ref>. Clearly all the template names that serve the same purpose as sfn should work the same. Jc3s5h (talk) 16:02, 21 December 2013 (UTC)

{{harvnb}} doesn't take six authors, and nor does {{sfn}}. All of the {{harv}} group accept up to four surnames, one year, plus any one of |p= |pp= or |loc=. If used as per the documentation - that is, with no more than four surnames in the {{harvnb}} - the link to the {{citation}} works even if {{citation}} has 100 authors. Same goes for {{cite book}} and the other WP:CS1 templates, provided that you supply |ref=harv. The {{harvnb}} displays all the surnames if there are three or fewer, but if there are exactly four, it displays the first one only plus "et al." If you don't like {{citation}} to display 100 authors, just set |displayauthors=1 and it too will display one plus "et al." The linking between {{harvnb}} and {{citation}} will work, and there is no need for any "workarounds". --Redrose64 (talk) 19:40, 21 December 2013 (UTC)

@Trappist the monk I have only looked at the code and the result you published, and yes that looks like a fix for this problem, well done. I assume you will generalise that solution.-- PBS (talk) 13:21, 22 December 2013 (UTC)

No, please don't: it is a "solution" to a problem that does not exist. {{sfn}} is for Shortened footnotes, and the point about shortened footnotes is that they are short. --Redrose64 (talk) 14:20, 22 December 2013 (UTC)

The result does not alter the length but if fixes a potential problem. It is far better to fix it in code that rely on people reading the manual that may or may not be up to date. -- PBS (talk) 13:12, 31 December 2013 (UTC)

Coauthors

I wrote above "Therefore I think that coauthors should be not be depreciated deprecated, and I would appreciate it if someone would indicate where the consensus was formed that it should be depreciated deprecated." Will someone please provide the link. -- PBS (talk) 18:18, 27 December 2013 (UTC)

You are the only person who used the term "depreciated". --Redrose64 (talk) 20:44, 27 December 2013 (UTC)

If the coauthors parameter is used, an error category shows that says "Pages containing cite templates with deprecated parameters". So I think PBS is right here using the term "deprecated". Debresser (talk) 17:27, 28 December 2013 (UTC)

These are two different words with different meanings. Depreciated is the antonym of appreciated, but the term that applies here is deprecated. Something that has been deprecated is being replaced or discontinued without any judgment on its value. Imzadi 1979 → 17:42, 28 December 2013 (UTC)

Actually that is not so the meaning of deprecate in the OEDL: "To plead earnestly against; to express an earnest wish against (a proceeding); to express earnest disapproval of (a course, plan, purpose, etc.)." Until I looked it up I had always assumed that it was just a spelling difference between British and American English, my mistake. The OED goes on to say in a 1993 draft edition "More generally, to express disapproval of (a person, quality, etc.); to disparage or belittle. (Sometimes confused with depreciate.) ... Widely regarded as incorrect, though found in the work of established writers." -- PBS (talk) 12:48, 31 December 2013 (UTC)

Funny how the messenger and not the message is the subject of this thread. The point remains I do not think that coauthors should be deprecated. If there was ever a discussion on this subject in which a consensus was agreed could someone please indicate where in the archives it can be found. If no such discussion can be found then the message should be remove from the category mentioned by Debresser. -- PBS (talk) 12:48, 31 December 2013 (UTC)

Shortened month names

I seem to have noticed that shortened month names are treated as error by CS1. And I assume that this is because the module can't tell the difference between a date in a reference or a date outside a reference (and the more so between a date outside a reference, that should really have been a reference and not just a raw link). Is that correct? I would agree with continuing that behavior. Even recommend it. After all, the fact that short names are allowed doesn't mean that there is a problem with writing them out. I personally even find it preferable. Debresser (talk) 00:51, 31 December 2013 (UTC)

@Debresser: Shortened month names (e.g. "Jan", "Sep") are acceptable in the |date= parameter per WP:DATESNO and do not give a CS1 error. However, you will see CS1 errors for shortened month names with periods (e.g. "Jan.") or abbreviations with more than three letters (e.g. "Sept"). If you're seeing something different, please provide an example. Thanks! GoingBatty (talk) 01:04, 31 December 2013 (UTC)

Cite book with short month name. 30 Dec 2013.

Short month names are acceptable. Punctuation (a terminal period on the month, inappropriate comma placement, etc) is likely what you are seeing.

—Trappist the monk (talk) 00:58, 31 December 2013 (UTC)

I suppose so. Thanks again for being on top of things. Debresser (talk) 01:04, 31 December 2013 (UTC)

Also, I noticed that WP:MOSDATE mentions no full stops after the day, but where does it say that there should be no full stop after the month abbreviation? Debresser (talk) 01:09, 31 December 2013 (UTC)

Aha. I see this is mentioned in Wikipedia_talk:Manual_of_Style/Dates_and_numbers#Abbreviated_months_in_citations. And that the issue is as yet unresolved. Debresser (talk) 01:15, 31 December 2013 (UTC)

But contrary to WP:MOSDATE I notice that shortened month names are allowed not only in references. CS1 allows it in all citation templates, whether or not they are references. I suppose that is because the code can't differentiate? Wouldn't it be better to do it the other way around: make them all an error. Debresser (talk) 01:58, 31 December 2013 (UTC)

Could you please provide an example of an article where CS1 is not displaying an error because a citation template is not used as a reference, and shortened month names should not be used per WP:MOSDATE?

The only possible use of a CS1 template I can imagine that wouldn't be a reference would be an entry in a further reading list, and I can't see any reason to have different rules for reference lists vs. further reading lists. As for imposing stricter rules, this obscure talk page on the coding of a module is not the appropriate place to make such a proposal; it should be proposed where editors who use CS1 templates will see it. Jc3s5h (talk) 02:12, 31 December 2013 (UTC)

It could be a "Further reading" list. It could be a reference which is not a footnote. Sometimes editors forget to add the<ref>...</ref> tags, especially inexperienced editors.

I would not impose stricter 'rules'. I would propose that the module should mark them as errors. Because outside references that is what they are. That way they would be fixed. Just that alongside with that, they would be changed outside references as well. Which is not a problem in itself. Shouldn't discussion here be enough? If not, where then? Debresser (talk) 11:23, 31 December 2013 (UTC)

I strongly agree with Jc3s5h. Wider consensus that includes editors who use the templates must be obtained before making these types of changes.

The citations in further reading lists are exactly equivalent to reference lists. If an abbreviated month is not marked as an error in the later, it should not be marked in the former. Per WP:DATEFORMAT, abbreviated months are acceptable in references, tables, lists or areas where conciseness is needed. Hence there may be other situations where the use of abbreviated months is acceptable. Similar to the deprecated month parameter, why fix something that isn't broken? Boghog (talk) 12:32, 31 December 2013 (UTC)

It seems to me that "Jan." is preferable to "Jan" but in nearly all cases January is better. I tend to agree with Boghog unless there is a clear consensus (gained from a well advertised RfC in a predominate place) changes like these should not be made with bots. I was very surprised to see this list: User talk:GoingBatty#Additional date parameter errors for BattyBot to fix. Where is there a clear consensus for any of those proposed bot changes? Taking the first one as an example date= to |type= be acceptable to remove citation error messages? it involves less than six editors who do not agree, that is nowhere near enough to implement a bot change. -- PBS (talk) 13:30, 31 December 2013 (UTC)

The first proposed change will not be implemented unless there is consensus. That is why I posted a query at the relevant project's Talk page. Most of the others are clearly errors per the MOS. The MOS is a result of consensus decisions made on the MOS Talk page, as far as I know. If you would like to continue this discussion or discuss other changes proposed in that list, please do so at the original location. – Jonesey95 (talk) 14:38, 31 December 2013 (UTC)

The MOS is a guideline not policy, and there is an awful lot in the MOS for which there is little agreement, and which is contradictory over the pages of the MOS, so using the MOS as justification for bot changes is questionable unless it can be shown that there is a specific consensus for the change. But to give you one example in that list above that is clearly not following the MOS guideline (there are probably many more). Take number "6" changing months from "MMM." to "MMM" is contrary to the MOS which recommends full dates, so who has decided that this list of actions is desirable for a bot to do? -- PBS (talk) 17:02, 31 December 2013 (UTC)

As indicated above, WP:DATESNO (aka MOS:DATEFORMAT) clearly shows that "MMM" is acceptable in references. GoingBatty (talk) 18:54, 31 December 2013 (UTC)

date=undated

It seems that |date=undated and |date=no date generate errors, but |date=nd and |date=n.d. do not.

• "Example 1". undated. {{cite web}}: Check date values in: |date= (help)
• "Example 2". no date. {{cite web}}: Check date values in: |date= (help)
• "Example 3". nd.
• "Example 4". n.d.

How should we resolve these errors?

1. Allow |date=undated and/or |date=no date
2. Change them to |date=nd or |date=n.d. ("nd" and "n.d." seem less clear to me)
3. Remove them from citations (do they add any value?)
4. Something else?

Thanks! GoingBatty (talk) 19:51, 29 December 2013 (UTC)

They add value because it makes it clear that the editor who wrote the citation looked for a date but didn't find one, suggesting that subsequent editors might want to direct their efforts to some other area to improve, rather than searching for a publication date. It could also distinguish between an undated and dated version of the same publication, or between two works by the same author, one of which was dated and the other which was not dated. Jc3s5h (talk) 19:58, 29 December 2013 (UTC)

Agree with Jc3s5h that they should stay. I think that "nd" and "n.d." are unclear to a casual reader and would prefer "no date" and possibly "undated" to be allowed. It looks like both APA and Chicago say to use "n.d.", so now I'm down to just not liking it. – Jonesey95 (talk) 20:35, 29 December 2013 (UTC)

I agree that "nd" and "n.d." are awful and will only cause confusion; date=none is best. Johnuniq (talk) 21:46, 29 December 2013 (UTC)

"n.d." or "nd" is a standard abbreviation in The Chicago Manual of Style or the MLA style guide. If we don't want to use the abbreviation, then spell it out, but let's not re-invent the wheel here unless necessary. Imzadi 1979 → 00:41, 30 December 2013 (UTC)

We already call for an approximate citation date to be preceded with "c.", and one must be fairly familiar with scholarly writing to understand that. I think "n.d." is no more obscure than "c." Jc3s5h (talk) 00:59, 31 December 2013 (UTC)

If we allow all the above, we should also allow "unknown" and "N/A", e.g. And basically there is no limit to what you would end up having to allow. For that reason I would prefer to allow none of the above: nothing at all. If that would meet with strong opposition from editors who like the Chicago standards or other, as I would expect it to, then we should make a rule that only "n.d." or "nd" will be allowed, and say so clearly in WP:MOSDATE. Debresser (talk) 01:01, 31 December 2013 (UTC)

CS1 error does not display when citation is not displayed, but the category is applied

I had a devil of a time finding an "unnamed parameter" error in Hydraulic fracturing. The article was in the category, but the error was not displayed. I think I figured it out after a little detective work involving a text editor. Here's the citation in question. Note the "|DOI: 10.5339/qfarf.2013.EEP-070 " parameter, which should be "DOI = ", not "DOI: ". The reference appears within a {{reflist}} template and is apparently not used in the article. It is almost surrounded by an HTML comment, but it's missing one hyphen at the start. I don't know what to make of this.

<!-ref name="flaring">{{cite journal | url= http://www.qscience.com/doi/abs/10.5339/qfarf.2013.EEP-070 | title=Managing process flares due to abnorma-l situation via design of co-gen system of discontinuous sources |last1=Eljack|first1=Fadwa |journal = Qatar Foundation Annual Research Forum Proceedings |volume=2013, EEP 070 |DOI: 10.5339/qfarf.2013.EEP-070 |date=22 November 2013| accessdate = 2013-12-29 }}</ref-->

This citation renders as nothing, whether it is commented or not:

(nothing).

But the error category is applied nonetheless.

I don't know what can be done here, but it sure is going to be hard for editors to find errors in hidden citations when there is no error message displayed. I suppose since the category is hidden, only error-obsessed editors will care. For now, I applied the missing hyphen so that the citation would be completely commented out, which rightly removes the error category. I also could have fixed the DOI parameter, but this works for now. – Jonesey95 (talk) 05:43, 2 January 2014 (UTC)

That reference isn't listed by {{reflist|refs=}} because references aren't displayed if they don't have a matching <ref name= /> tag in the article text. Because the comment markup is incomplete the wikimedia processor can't match <!-ref name="flaring"> to a valid tag so ignores it.

Because the comment tag is incomplete, the CS1 template is processed normally which adds the page to the error category and would display the error message if the reference were displayed. Unfortunately, all of this stuff that prevents the citation's display is outside the bailiwick of Module:Citation/CS1.

—Trappist the monk (talk) 12:50, 2 January 2014 (UTC)

This problem, which I had never seen before today despite fixing hundreds of article in the unnamed parameters category, also appears to exist in LeSean McCoy. I haven't tracked down the error yet. – Jonesey95 (talk) 05:58, 2 January 2014 (UTC)

Someone manually added Category:Pages with citations using unnamed parameters. --  Gadget850 ^talk 05:05, 4 January 2014 (UTC)

Great catch. Something new under the sun. I have fixed CS1 errors in maybe 20,000 articles, and I hadn't seen that happen yet. – Jonesey95 (talk) 05:26, 4 January 2014 (UTC)

If the error is hidden for some reason, it should still show in the rendered HTML. I could not find it, so I searched for the category. --  Gadget850 ^talk 21:20, 4 January 2014 (UTC)

Error shown for valid lack of url parameter when contribution-url or chapter-url used, links on wrong fields

Archive URLs are marked as errors if there is no url= even where there is a contribution-url = or chapter-url=. In such cases when a valid URL is provided for contributor or chapter the lack of a url= is not an error, and should not be marked as such. There are cases where only a chapter, or contribution is available online without the entire work. Yes, it would be nice to have a URL for the entire work, but it is not an error for there not to be one. At a minimum, there should be a parameter to specify that it has been checked and the error should not be displayed.

Further, what field gets linked with which URL is wrong in some cases. In these cases the contribution-url = and chapter-url = links should be on what is displayed from the contribution = and chapter = parameters. The url= should be on the title=. If the archive-url is provided and deadurl=no is not present, the archive URL should be the link for the contribution or chapter.

Without archiveurl: Citation that uses contribution-url= no url=:    (good)
"The Contribution", The Title, July/Aug 2013 {{citation}}: Check date values in: |date= (help)

Citation that uses chapter-url = no url=:    (good)
"The Chapter", The Title, July/Aug 2013 {{citation}}: Check date values in: |date= (help)

Citation that uses contribution-url= with url=:    (good)
"The Contribution", The Title, July/Aug 2013 {{citation}}: Check date values in: |date= (help)

Citation that uses chapter-url = with url=:    (good)
"The Chapter", The Title, July/Aug 2013 {{citation}}: Check date values in: |date= (help)

With archiveurl:

Citation that uses contribution-url= no url=:    (title links to archive-url. Should link to nothing; contribution should link to archive-url; "the original" should link to contribution-url; shows error which is not actually an error, just a desire to have a URL for title)
"The Contribution", The Title, July/Aug 2013, archived from the original on 5 Aug 2013 {{citation}}: Check date values in: |date= (help)

Citation that uses chapter-url = no url=:    (title links to archive-url. Should link to nothing; chapter should link to archive-url; "the original" should link to chapter-url; shows error which is not actually an error, just a desire to have a URL for title)
"The Chapter", The Title, July/Aug 2013, archived from the original on 5 Aug 2013 {{citation}}: Check date values in: |date= (help)

Citation that uses contribution-url= with url=:    (title links to archive-url. Should link to url; contribution should link to archive-url; "the original" should link to contribution-url)
"The Contribution", The Title, July/Aug 2013, archived from the original on 5 Aug 2013 {{citation}}: Check date values in: |date= (help)

Citation that uses chapter-url = with url=:    (title links to archive-url. Should link to url; chapter should link to archive-url; "the original" should link to chapter-url)
"The Chapter", The Title, July/Aug 2013, archived from the original on 5 Aug 2013 {{citation}}: Check date values in: |date= (help)

With archiveurl and deadurl=no:

Citation that uses contribution-url= no url=:    (shows error which is not actually an error, just a desire to have a URL for title)
"The Contribution", The Title, July/Aug 2013, archived from the original on 5 Aug 2013 {{citation}}: Check date values in: |date= (help); Unknown parameter |deadurl= ignored (|url-status= suggested) (help)

Citation that uses chapter-url = no url=:    (shows error which is not actually an error, just a desire to have a URL for title)
"The Chapter", The Title, July/Aug 2013, archived from the original on 5 Aug 2013 {{citation}}: Check date values in: |date= (help); Unknown parameter |deadurl= ignored (|url-status= suggested) (help)

Citation that uses contribution-url= with url=:    (good)
"The Contribution", The Title, July/Aug 2013, archived from the original on 5 Aug 2013 {{citation}}: Check date values in: |date= (help); Unknown parameter |deadurl= ignored (|url-status= suggested) (help)

Citation that uses chapter-url = with url=:    (good)
"The Chapter", The Title, July/Aug 2013, archived from the original on 5 Aug 2013 {{citation}}: Check date values in: |date= (help); Unknown parameter |deadurl= ignored (|url-status= suggested) (help)

Thanks. Makyen (talk) 00:31, 15 January 2014 (UTC)

Thank you for these detailed citation examples. I have merged your |month= and |year= parameters to result in the same rendered citation, but without "deprecated parameter" errors that are displayed for some editors. Removing these error messages make it clearer where there are |archiveurl= messages. – Jonesey95 (talk) 05:46, 15 January 2014 (UTC)

No problem. Thanks for changing the depreciated parameters. I had cut & pasted the original citation and forgot to change them when cleaning it up to be more a readable example. Programming requires testing. Testing requires test cases to show what is happening both before and after changes. Without cases that show the issues it is difficult both to communicate and to find/fix issues.

In the final parts of my editing, I forgot to copy & paste the statement about the archiveurl error not being an error onto the first two occurrences. That has been corrected above. Basically, all four archiveurl errors above should not be displayed as errors (each has a primary URL specified).Makyen (talk) 08:30, 15 January 2014 (UTC)

HTML entity for n-dash

My sandbox experiments seem to indicate the new version of the module flags date ranges that use – as invalid dates, but ones that use a genuine n-dash are not flagged as errors. Jc3s5h (talk) 02:18, 15 January 2014 (UTC)

Let's try some here:

Cite journal comparison

Wikitext	{{cite journal|date=July-August 1996|journal=Journal of Examples|sandbox=yes|title=Journal article}}
Live	"Journal article". Journal of Examples. July–August 1996. {{cite journal}}: Unknown parameter |sandbox= ignored (help)CS1 maint: date format (link)
Sandbox	"Journal article". Journal of Examples. July–August 1996. {{cite journal}}: Unknown parameter |sandbox= ignored (help)CS1 maint: date format (link)
date range with hyphen

Cite journal comparison

Wikitext	{{cite journal|date=July–August 1996|journal=Journal of Examples|sandbox=yes|title=Journal article}}
Live	"Journal article". Journal of Examples. July–August 1996. {{cite journal}}: Unknown parameter |sandbox= ignored (help)
Sandbox	"Journal article". Journal of Examples. July–August 1996. {{cite journal}}: Unknown parameter |sandbox= ignored (help)
date range with {{ndash}}

Cite journal comparison

Wikitext	{{cite journal|date=July–August 1996|journal=Journal of Examples|sandbox=yes|title=Journal article}}
Live	"Journal article". Journal of Examples. July–August 1996. {{cite journal}}: Check date values in: |date= (help); Unknown parameter |sandbox= ignored (help)
Sandbox	"Journal article". Journal of Examples. July–August 1996. {{cite journal}}: Check date values in: |date= (help); Unknown parameter |sandbox= ignored (help)
date range with –

Cite journal comparison

Wikitext	{{cite journal|date=July–August 1996|journal=Journal of Examples|sandbox=yes|title=Journal article}}
Live	"Journal article". Journal of Examples. July–August 1996. {{cite journal}}: Unknown parameter |sandbox= ignored (help)
Sandbox	"Journal article". Journal of Examples. July–August 1996. {{cite journal}}: Unknown parameter |sandbox= ignored (help)
date range with typed endash

Any more we wish to try? – Jonesey95 (talk) 05:54, 15 January 2014 (UTC)

Additional case: Journal with volume beginning mid-year:

Cite journal comparison

Wikitext	{{cite journal|date=December 1995 – January 1996|journal=Journal of Examples|sandbox=yes|title=Journal article}}
Live	"Journal article". Journal of Examples. December 1995 – January 1996. {{cite journal}}: Unknown parameter |sandbox= ignored (help)
Sandbox	"Journal article". Journal of Examples. December 1995 – January 1996. {{cite journal}}: Unknown parameter |sandbox= ignored (help)
date range with typed endash, volume starts mid-year

Jc3s5h (talk) 16:45, 15 January 2014 (UTC)

Just to clarify: This additional case is an example of a valid date range (discussion above) that needs to be added to the module. The endash is not causing the error in this case. – Jonesey95 (talk) 17:14, 15 January 2014 (UTC)

RFC affecting valid dates

User:EEng has proposed removing the limitation that dates in the YYYY-MM-DD format be in the Gregorian calendar, and the corresponding range limitation making the first valid year 1583 and the last valid year 9999 (for that format). This change could affect date validation. I have started an RFC at WT:MOSNUM#RFC: Connection between ISO 8601 standard and YYYY-MM-DD date format. Jc3s5h (talk) 14:43, 26 January 2014 (UTC)

Should date validation allow "BC" and other eras?

It looks like the current date validation code in the CS1 module does not allow "AD", "BCE", and similar WP:ERA notations. It should, I believe.

Thoughts? Objections? Corrections? An example of actual usage in an article is Getae#Ancient. – Jonesey95 (talk) 06:49, 9 January 2014 (UTC)

Logical. Debresser (talk) 09:34, 9 January 2014 (UTC)

I think a better example is required; one where the editor actually put on the white gloves and consulted the ancient work. Those four citations are all referring to more-or-less modern translations of the ancient works – one facsimile and three transcriptions. WP:SAYWHEREYOUGOTIT applies.

—Trappist the monk (talk) 11:15, 9 January 2014 (UTC)

I agree, where used as a citation. I am also suspicious that the adding editors actually consulted the original versions here.

But, listing those texts would be valid in a bibliography or further reading list, and many of those are formatted with CS1 templates; including the original document would be a valid use. Perhaps we need a |circa= parameter to handle these cases, and especially where the exact date of a document is unknown. |circa= would bypass the date checking and allow additional text such as "c. 3rd century AD". --  Gadget850 ^talk 14:50, 9 January 2014 (UTC)

In this particular case, that functionality already exists in |origyear= which is, I think, the only date-holding parameter that is not date checked because explanatory text is recommended by the documentation. The Justin citation could be written this way:

{{cite book |last=Justin |authorlink=Justin (historian) |others=Trans. John Selby Watson |location=London |publisher=Henry G. Bohn |title=Trogi pompei historiarum philippicarvm epitoma |trans_title=Epitome of the Philippic History of Pompeius Trogus |url=http://www.forumromanum.org/literature/justin/english/index.html |date=1853 |origyear=c. 3rd century AD |via=Corpus Scriptorum Latinorum}}

→Justin (1853) [c. 3rd century AD]. Trogi pompei historiarum philippicarvm epitoma. Trans. John Selby Watson. London: Henry G. Bohn – via Corpus Scriptorum Latinorum. {{cite book}}: Unknown parameter |trans_title= ignored (|trans-title= suggested) (help)

(in this case, |origyear= is probably inappropriate because the linked works don't mention the 3rd century date.)

I'm not inclined to support the addition a new parameter for what is likely to be a very rare case. For these rare cases, a bibliographic entry could be hand crafted.

—Trappist the monk (talk) 15:55, 9 January 2014 (UTC)

Even if WP:SAYWHEREYOUGOTIT applies one may still need two citations. The first for where it was found and the second for the original source, so WP:SAYWHEREYOUGOTIT does not remove the need to handle cases with BC and other notations, such as the French revolutionary calendar and dates in both calendars eg in the Glorious Revolution, need some way of indicating if the source is dated in Gregorian or Julian calendar is needed, because contemporary British sources will be using the Julian calendar while Dutch sources will be using Gregorian. Suggesting that the long citations are hand crafted is not practical if short citations are in use in the article. -- PBS (talk) 11:12, 24 January 2014 (UTC)

I think PBS' post conflates two issues. The first is a modern source, such as Project Gutenberg, which republishes an older source. This can be handled by using the date parameter for the modern publication date, and the origyear for the original publication date. Since the format of origyear is not checked for validity, and is not used to link short footnotes to the full citation, anything could be put in there, such as "origyear = 1 July 1743 (Julian calendar)".

If the publication to be cited is the original paper (or stone, parchment, papyrus) publication, and it bears a non-Gregorian publication date, the software that links a {{sfn}} or {{harv}} template to the full citation will not accept dates with additional notations such as Julian calendar, BCE, AD, and so on. So extra parameters will have to be added to {{sfn}} or {{harv}} and the long citation will have to be hand-crafted with an anchor; making the date validation code less strict will not resolve the problem. Jc3s5h (talk) 12:12, 24 January 2014 (UTC)

Quite the contrary I am not conflating two things, the date of publication has nothing to do with WP:SAYWHEREYOUGOTIT. If WP:SAYWHEREYOUGOTIT is invoked then there are two citations to consider. In the case you give of Project Gutenberg and republishing then there will be original date and a republication date in which case WP:SAYWHEREYOUGOTIT is not relevant.

As to the second point. It has not been a problem on the past because {{harvid}} could be used as a work around, and as there was no error checking on the year or date field such methods worked perfectly well:

• {{cite book |author=Fred |year=200 BC |title=Smith |ref={{harvid|Fred|200 BC}}}}
• Fred (200 BC). Smith. {{cite book}}: Check date values in: |year= (help)CS1 maint: year (link)
  • {{harv|Fred|200 BC|p=10}}
• (Fred & 200 BC, p. 10)

It only now appears to be problem because error checking for "correct" formats is being applied to the date parameter. -- PBS (talk) 16:19, 24 January 2014 (UTC)

As far as the 200 BC source, I hadn't seen that particular workaround; I agree that workaround should be supported.

AS far as WP:SAYWHEREYOUGOTIT, the example in that section does not use a citation template:

8. Smith, John, Name of Book I Haven't Seen (Cambridge University Press, 2009), 1, cited in Paul Jones, "Name of Blog Post I Did Read".

Is there a method to create an equivalent citation using templates? Jc3s5h (talk) 16:57, 24 January 2014 (UTC)

Yes. I use it all the time for Darryl Lundy's website (for example here). Lundy is a classic case of an unreliable website (self published) containing references to reliable sources turning what would be an unreliable citation into a more reliable one. For the example you gave:

Extended content
A contentions fact. Notes References Jones, Paul (2014), Name of Blog Post I Did Read this source cites: Smith, John (2001), Name of Book I Haven't Seen, Cambridge University

-- PBS (talk) 18:41, 31 January 2014 (UTC)

That's clear enough. It differs from other style guides, which would typically combine these into a single citation. It would also be a challenge to alphabetize the reference list. Jc3s5h (talk) 18:50, 31 January 2014 (UTC)

I've been looking at Darryl Lundy's website a lot over the last week or so; I have one observation on Dermod O'Brien, 5th Baron Inchiquin, and that concerns the parameter |publisher=thepeerage.com - this should be |publisher=Lundy Consulting Ltd |work=The Peerage You could also put |location=Ngaio, Wellington, New Zealand or |location=Ngaio, Wellington --Redrose64 (talk) 18:55, 31 January 2014 (UTC)

Change to lua library

On February 18, the method mw.message.newRawMessage will be removed from scribunto mw.message library. This method is used in function substitute in Module:Citation/CS1. Check Tech/News/2014/07.--Moroboshi (talk) 20:46, 10 February 2014 (UTC)

mw.message.newRawMessage is not going away. What's going away are the text, escaped, parse, and parseAsBlock methods; also, tostring on a message will now behave as plain rather than as text. Anomie⚔ 13:03, 11 February 2014 (UTC)

Thanks for that, but what does it really mean? Especially: tostring on a message will now behave as plain rather than as text? The Lua reference manual is rather quiet on just what plain means when applied to messages. Is it different from the definition of plain that specifies how a pattern is to be interpreted? Are you saying that tostring() returns something other than a string when applied to messages? Surely that's a corruption of what tostring() is normally expected to do, isn't it?

Is there better documentation than the Lua reference manual?

—Trappist the monk (talk) 14:35, 11 February 2014 (UTC)

From what I comprehend from this (it's the reason for the deletion of raw message linked in the the Tech News) message:plain is the equivalent of the {{int:}} magic world, so it will not accept new message but only message of the mediawiki interface (I could get this wrong I never used it).--Moroboshi (talk) 17:01, 11 February 2014 (UTC)

PS I didn't notice Anomie comment, so maybe I was allarmed for nothing.--Moroboshi (talk) 17:08, 11 February 2014 (UTC)

@Trappist the monk: No, that's it. Feel free to improve it, but remember it's a reference manual and not a textbook.

The difference between plain and text is that the latter will expand templates and parser functions in the message, while the former merely substitutes the parameters. For example, mw.message.newRawMessage( '{{ns:$1}}', 4 ):plain() returns {{ns:4}} (which gets parsed to "Wikipedia"), while mw.message.newRawMessage( '{{ns:$1}}', 4 ):text() returns Wikipedia directly. The problem with :text() comes in that it doesn't count expensive function usage, doesn't include the expanded templates in "templates used in this page", and so on. Anomie⚔ 19:10, 11 February 2014 (UTC)

I just tried this function and I got {{ns:4}} unexpanded (note: the link are to it.wiki). Template, extension tag and parser function containted in the text returned from a invoke call are not processed, see Returning text in scribunto manual. However I dont think that Module:Citation use this feature (expansion of template, ecc...) so will be sufficent subsitute the :text call with a :plain call.--Moroboshi (talk) 19:45, 11 February 2014 (UTC)

Use frame:preprocess if necessary. Anomie⚔ 00:42, 12 February 2014 (UTC)

As an experiment, in Module:Citation/CS1/sandbox, I just replaced this line:

return args and tostring( mw.message.newRawMessage( msg, args ) ) or msg;

with this line:

return args and mw.message.newRawMessage( msg, args ):plain() or msg;

A brief bit of testing seems to indicate that the replacement works as well as the original. I don't think that we need to worry about expanding templates and such here because, templates are already expanded before Module:Citation/CS1 comes into play.

As for improving the Scributo extension documentation, I would - if, and here's the rub, I knew something about what it is that I'd be improving. Alas, I don't; hence my question about the availability of more complete documentation.

—Trappist the monk (talk) 00:59, 12 February 2014 (UTC)

Bare URL script error

Can anyone figure out what's going on in this template invocation from Angiotensin II receptor antagonist?

{{cite journal |author=Fogari R, Zoppi A, Corradi L, Lazzari P, Mugellini A, Lusardi P. 1998;46:467–71. food
rative effects of lisinopril and losartan on insulin sensitivity in the treatment of non diabetic hypertensive patients |journal=Br J Clin Pharmacol |year=1998|volume=46 |issue=5 |pages=467–71 |doi=10.1046/j.1365-2125.1998.00811.x |pmc=1873694}}

When it is run, I get a script error with the following traceback:

Lua error in Module:Citation/CS1 at line 222: Bare url found but origin indicator is nil or empty.
Backtrace:
[C]: in function "error"
Module:Citation/CS1:222: in function "externallink"
Module:Citation/CS1:1718: ?
(tail call): ?
mw.lua:558: ?

Only thing is, there is no URL in the template. I'm not familiar enough with the module to figure out the problem myself though. — Mr. Stradivarius ^{♪ talk ♪} 03:17, 13 February 2014 (UTC)

The script error problem has been fixed in the sandbox and when I update the live module in the next couple of days it will be fixed. The problem has to do with |pmc= which adds a "url" to the title (just a copy of the url in the PMC identifier link). The citation as a whole though, has a bigger problem: it's missing some stuff:

Fogari R, Zoppi A, Corradi L, Lazzari P, Mugellini A, Lusardi P. 1998;46:467–71. food rative effects of lisinopril and losartan on insulin sensitivity in the treatment of non diabetic hypertensive patients (1998). Br J Clin Pharmacol. 46 (5): 467–71. doi:10.1046/j.1365-2125.1998.00811.x. PMC 1873694 https://www.ncbi.nlm.nih.gov/pmc/articles/PMC1873694. {{cite journal}}: Missing or empty |title= (help)CS1 maint: multiple names: authors list (link) CS1 maint: numeric names: authors list (link)

—Trappist the monk (talk) 04:07, 13 February 2014 (UTC)

Ah, of course. Looking at the edit history, I see it was an IP test edit a couple of days ago that caused the error. Reverting it did the trick. And I'm glad to know that the sandbox has already been script-error-proofed. Thanks for your help. :) — Mr. Stradivarius ^{♪ talk ♪} 04:48, 13 February 2014 (UTC)

Update to the live CS1 module week of 2014-02-09

In about a week's time I intend to update these files from their respective sandboxes:

Module:Citation/CS1 (diff);

Module:Citation/CS1/Configuration (diff);

Module:Citation/CS1/Whitelist (diff)

The update makes these changes to Module:Citation/CS1:

1. Fixes cite journal script error that occurred when the citation had a |pmc= without |title=; (see "Script_error")
2. Migrate cite speech; (see Migrating cite speech)
3. Kerning for title and chapter leading and trailing single or double quote marks for quoted titles; (see Quote within title parameter)
4. Enhance month / season year date range to check for proper left to right time sequencing of month or seasons in the range; (see Month / season range order validation)
5. Streamline date validation; Add day range validation; (see Legitimate date range examples to add to the date checking part of the CS1 module)
6. Migrate cite podcast; (see Migrating cite podcast)
7. Add simple PMID error checking; (see PMID error flagging)
8. Refine DOI error check to catch trailing punctuation errors; (see doi subthread)

to Module:Citation/CS1/Configuration:

1. Added Draft and Draft Talk namespaces to uncategorized namespaces. [Jonesey95]
2. Add |event= and |eventurl as aliases of |conference and |conferenceurl= in support of {{cite speech}};
3. Add |host= as alias of |authors in support of {{cite podcast}};
4. Add simple PMID error checking;
5. Reflect change made to live version by Editor Smith609; remove U+200E (left to right mark) from category names;

to Module:Citation/CS1/Configuration:

1. Add |event= and |eventurl as aliases of |conference and |conferenceurl= in support of {{cite speech}};
2. Add |host= as alias of |authors in support of {{cite podcast}};

—Trappist the monk (talk) 12:55, 8 February 2014 (UTC)

Done.

—Trappist the monk (talk) 11:39, 15 February 2014 (UTC)

It doesn't seem to have fixed the year range breakage – the last two tests in test_citation still have an anchor of CITEREFLi, omitting the years. Kanguole 13:03, 15 February 2014 (UTC)

That was not part of the update; see item 4 under Module:Ciataion/CS1 above.

—Trappist the monk (talk) 13:09, 15 February 2014 (UTC)

That's a pity. Next time, perhaps? Kanguole 13:58, 16 February 2014 (UTC)

Spurious DOI errors caused by code update on Feb 15

It is apparently valid for a DOI to end in parentheses and some other punctuation. The new module code is flagging such DOIs as errors. The code in question is this, I believe:

if nil == id:match("^10%.[^%s–]-[^%p]$") then -- doi must begin with '10.', must not contain spaces or endashes, and must not end with punctuation

I believe that the "%p" is the problem.

Here are example of valid DOIs that are displaying error messages:

S.K. Park; P.Y. Julien (November 2008). "Case Study: Retrofitting Large Bridge Piers on the Nakdong River, South Korea". Journal of Hydraulic Engineering. 134 (8). American Society of Civil Engineers: 1639. doi:10.1061/(ASCE)0733-9429(2008)134:11(1639). Retrieved 2013-10-24. {{cite journal}}: |first3= missing |last3= (help); |first4= missing |last4= (help)

Wahl M, Sundaralingam M (1997). "Crystal structures of A-DNA duplexes". Biopolymers. 44 (1): 45–63. doi:10.1002/(SICI)1097-0282(1997)44:1<45::AID-BIP4>3.0.CO;2-#. PMID 9097733.

Feldman, K. S.; Smith, R. S. (1996). "Ellagitannin Chemistry. First Total Synthesis of the 2,3- and 4,6-Coupled Ellagitannin Pedunculagin". The Journal of Organic Chemistry. 61 (8): 2606–2612. doi:10.1021/jo952130+. PMID 11667089.

It might be valid to flag periods and commas as invalid DOI ending characters, but it looks like other punctuation may be acceptable. – Jonesey95 (talk) 16:29, 15 February 2014 (UTC)

Changed to accept all terminal punctuation except period and comma.

—Trappist the monk (talk) 17:32, 15 February 2014 (UTC)

The Numbering section of the DOI Handbook does not forbid ending a DOI in a comma or a period, but I hope that in practice, there are no valid DOIs that end in these characters. We will find out in the next few weeks as this new code adds articles to the error category.

I have found a few |doi= parameters with values that end in a period or a comma, and they were invalid. Removing the comma or the period fixed the problem and allowed them to resolve to the correct journal article when clicked. That shows that this new code has some value. – Jonesey95 (talk) 18:50, 15 February 2014 (UTC)

Preventing full stop following DOI in rendered citation from wrapping to a new line

This is an edge case that hardly affects anything, but I noticed today that a full stop ("period" in US English) punctuation mark following a DOI wrapped to the next line in a two-column reflist. If you adjust your browser window width, you may be able to make it happen. I have set up a sample article on which I can reproduce this problem at User:Jonesey95/sandbox2.

The final full stop was alone on the next line. That seems undesirable to me. I don't know if this happens only when there is a DOI (with its concomitant "external link" icon) or in other situations as well. It will be hard to troubleshoot, since column and window widths vary.

I haven't been able to make it happen with PMIDs. I have not experimented with other parameters after which a full stop appears. Feel free to edit my Sandbox2 page. – Jonesey95 (talk) 23:20, 15 February 2014 (UTC)

In the HTML, it looks like the rendered DOI link has a space between the closing "/a" HTML tag and the period. The PMID link does not. I haven't been able to figure out where this rendering happens. – Jonesey95 (talk) 07:29, 16 February 2014 (UTC)

I think that it's in Module:Citation/CS1, specifically function doi where we have

if nil == id:match("^10%.[^%s–]-[^%.,]$") then	-- doi must begin with '10.', must not contain spaces or endashes, and must not end with period or comma
		cat = seterror( 'bad_doi' );
	end
	return text .. inactive .. ' ' .. cat

The last line suggests to me that what gets output is the content of text, the content of inactive (which might be a null string), a single space and then the content of cat. Since cat is initialised to a null string, and might not be altered to seterror( 'bad_doi' ); this means that if there is no error in the DOI format, the last character output is a single space. I suggest that the lines in question be amended to

if nil == id:match("^10%.[^%s–]-[^%.,]$") then	-- doi must begin with '10.', must not contain spaces or endashes, and must not end with period or comma
		cat = ' ' .. seterror( 'bad_doi' );
	end
	return text .. inactive .. cat

that is, move the ' ' .. from its present position to a position two lines above. --Redrose64 (talk) 10:43, 16 February 2014 (UTC)

Editor Redrose64 has it sussed:

Cite journal comparison

Wikitext	{{cite journal|doi=10.1016/j.jcms.2011.10.026|journal=Journal}}
Live	Journal. doi:10.1016/j.jcms.2011.10.026. {{cite journal}}: Missing or empty |title= (help)
Sandbox	Journal. doi:10.1016/j.jcms.2011.10.026. {{cite journal}}: Missing or empty |title= (help)
without error

Cite journal comparison

Wikitext	{{cite journal|doi=10:1016/j.jcms.2011.10.026|journal=Journal}}
Live	Journal. doi:10:1016/j.jcms.2011.10.026. {{cite journal}}: Check |doi= value (help); Missing or empty |title= (help)
Sandbox	Journal. doi:10:1016/j.jcms.2011.10.026. {{cite journal}}: Check |doi= value (help); Missing or empty |title= (help)
with error

—Trappist the monk (talk) 11:27, 16 February 2014 (UTC)

This change works for me. I tried the sandbox version on my sandbox2 page, and there is no longer a space before the full stop. Let's keep this change and migrate it at the next reasonable opportunity. – Jonesey95 (talk) 15:42, 16 February 2014 (UTC)

Fixed in live version.

—Trappist the monk (talk) 22:52, 16 February 2014 (UTC)

Italics in citation title broken

(Previously discussed at the Village pump here). Italics within the title parameter for CS1 templates are borked for some reason. For example:

{{cite web | title=''Lorem ipsum'' NOTITALIC | publisher=Foo | work=Bar | date=December 0, 0000}}

Which used to output:

"Lorem ipsum NOTITALIC". Bar. Foo. December 0, 0000.

Instead generates:

"Lorem ipsum NOTITALIC". Bar. Foo. December 0, 0000. {{cite web}}: Check date values in: |date= (help); Missing or empty |url= (help)

Without template, for demonstration:

" ''Lorem ipsum NOTITALIC". Bar. Foo. December 0, 0000.

Whisternefet (talk) 15:52, 15 February 2014 (UTC)

Let's see how it behaves without the Lua module:

Cite web comparison

Wikitext	{{cite web|date=December 0, 0000|publisher=Foo|sandbox=yes|title=''Lorem ipsum'' NOTITALIC|work=Bar}}
Live	"Lorem ipsum NOTITALIC". Bar. Foo. December 0, 0000. {{cite web}}: Check date values in: |date= (help); Missing or empty |url= (help); Unknown parameter |sandbox= ignored (help)
Sandbox	"Lorem ipsum NOTITALIC". Bar. Foo. December 0, 0000. {{cite web}}: Check date values in: |date= (help); Missing or empty |url= (help); Unknown parameter |sandbox= ignored (help)

But the main forums for CS1 problems are Help talk:Citation Style 1 and Module talk:Citation/CS1. --Redrose64 (talk) 15:44, 15 February 2014 (UTC)

Tweaked your {{cite compare}} to add the sandbox.

—Trappist the monk (talk) 20:11, 15 February 2014 (UTC)

Hmm. The new behaviour matches the old for {{cite book}} and {{citation}} – I've been relying on it to avoid italicizing Chinese characters, which makes them hard to read. It seems the change is that in {{cite web}} the title and publisher are now italicized and the work isn't, when previously it was the other way round. Kanguole 17:08, 15 February 2014 (UTC)

The current live module is wrapping the first apostrophe with <span style="padding-left:0.2em;"></span>. That breaks the intended double apostrophe italic wikimarkup. The sandbox code now detects the double apostrophe and ignores it assuming that there is a matching pair that will close the italics.

—Trappist the monk (talk) 18:01, 15 February 2014 (UTC)

Confirmed. Fixed in the sandbox I think. There are a couple of issues here. Typographically, it is desirable to separate and opening double quote from an initial single quote:

{{cite book/new|chapter='Help!' |title=Red Riding Hood's encounter with the wolf}}

→"'Help!'". Red Riding Hood's encounter with the wolf.

and it is desirable to italicize text in a title

{{cite book/new|chapter=''Lorem ipsum'' NOTITALIC |title=Title}}

→"Lorem ipsum NOTITALIC". Title.

I think that I've fixed this. More testing to confirm that to come.

—Trappist the monk (talk) 17:18, 15 February 2014 (UTC)

Sounds good, thanks for the prompt response! Whisternefet (talk) 17:25, 15 February 2014 (UTC)

I think I made a suggestion to not italicize titles when 'language' is set to an Asian language. --  Gadget850 ^talk 01:02, 16 February 2014 (UTC)

Module:Citation/CS1/sandbox, {{cite book}}, {{cite journal}} and {{cite web}}:

Quoted titles with kerning

• ""Double quoted chapter"". "Double quotes at start and end of title".
• "'Single quotes at start and end of title'". Prestigious Journal.
• ""Double quote" at start of title".
• "Double quote at end of "title"".
• "'Single quote' at start of title".
• "Single quote at end of 'title'".

Intentional italic wikimarkup

• "Without italic wikimarkup for reference".
• "Italic wikimarkup at start and end of title".
• "Italic wikimarkup at start of title".
• "Italic wikimarkup at end of title".
• "Italic wikimarkup in the middle of title".

What about bold?

• "Bold wikimarkup at start and end of title".
• "Bold wikimarkup at start of title".
• "Bold wikimarkup at end of title".
• "Bold wikimarkup in the middle of title".

And to be sure I didn't break anything

• "Unquoted chapter". Unquoted title.
• "Unquoted title". Prestigious Journal.
• "Unquoted title".

And some likely mistyped titles

• ""Doubled double-quote at end of chapter""". "Fully double quoted title".
• "'Doubled single quote at end of title". Prestigious Journal.
• "Doubled single quote at start of title". Prestigious Journal.

I think that the kerning code properly recognizes wikimarkup for italics and bold. So, without objection, later today I will update the live version of Module:Citation/CS1 to match the sandbox.

After that, there is the issue of removing the wikimarkup from parameters that are included in the COinS because all of these single quotes are currently included in the metadata.

—Trappist the monk (talk) 12:36, 16 February 2014 (UTC)

Live version should be working correctly now.

—Trappist the monk (talk) 22:53, 16 February 2014 (UTC)

Still broken

Already reported about a month ago, YYYY-MM is a perfectly valid date in all relevant standards. –Be..anyone (talk) 14:48, 27 February 2014 (UTC)

Not broken. See Acceptable date formats table at MOS:DATESNO. The table does not include YYYY-MM.

—Trappist the monk (talk) 14:55, 27 February 2014 (UTC)

The claim "YYYY-MM is a perfectly valid date in all relevant standards" is not true. Look at most style guides, or any elementary school textbook about writing English. There are many standards that make no mention of this format, and specify other formats instead. Jc3s5h (talk) 15:17, 27 February 2014 (UTC)

Discussion and an RFC are ongoing at Wikipedia_talk:Manual_of_Style/Dates_and_numbers#Rfc:_Is_YYYY-MM_an_acceptable_date_format.3F_Part_4. – Jonesey95 (talk) 19:54, 27 February 2014 (UTC)

By my count it is at least Part 15. --  Gadget850 ^talk 21:20, 27 February 2014 (UTC)

Suggested check for invalid values in |authorlink=

This is a suggestion to check for invalid values in |authorlink=. The current documentation (this is from {{cite book}}) says: "authorlink: Title of existing Wikipedia article about the author—not the author's website; do not wikilink".

I sometimes see full URLs in the value of |authorlink=, and there are often wikilinked values in there. Can we flag characters that are invalid in the names of WP articles? There is a list of these characters at Wikipedia:Article_titles#Special_characters. It looks like we could also flag "http:" and "https:", since colons are not allowed in article titles, but we need to be careful about colons in legitimate interlanguage links like this:

Cite book comparison

Wikitext	{{cite book|author=Joseph de Carayon La Tour|authorlink=:fr:Joseph_de_Carayon-Latour|title=Le Chat|year=2009}}
Live	Joseph de Carayon La Tour [in French] (2009). Le Chat.
Sandbox	Joseph de Carayon La Tour [in French] (2009). Le Chat.

Ideas? – Jonesey95 (talk) 18:09, 25 February 2014 (UTC)

You don't have to include the URI scheme, and not including it is sometimes recommended to make it protocol relative. What must be included is the "//", which is a valid but probably rare Wikipedia title. --  Gadget850 ^talk 15:32, 27 February 2014 (UTC)

Cite book comparison

Wikitext	{{cite book|author=Joseph de Carayon La Tour|authorlink=//example.org|title=Le Chat|year=2009}}
Live	Joseph de Carayon La Tour (2009). Le Chat. {{cite book}}: Check |authorlink= value (help); External link in |authorlink= (help)
Sandbox	Joseph de Carayon La Tour (2009). Le Chat. {{cite book}}: Check |authorlink= value (help); External link in |authorlink= (help)

Maybe we could search for the invalid characters as well as "//" followed by "." in the authorlink value in order to eliminate some hypothetical false positives. – Jonesey95 (talk) 19:51, 27 February 2014 (UTC)

In Module:Citation/CS1/sandbox:

• example1; example2. FAIL: uri scheme in author link 2. {{cite book}}: Check |authorlink2= value (help); External link in |authorlink2= (help)CS1 maint: numeric names: authors list (link)
• example. FAIL: protocol relative url in author link 1. {{cite book}}: Check |authorlink= value (help); External link in |authorlink= (help)
• example. PASS: to show that I didn't break anything.

If this change is retained, errors will be categorized into Category:CS1 errors: authorlink.

This version only tests for the occurrence of '//'. —Trappist the monk (talk) 14:04, 28 February 2014 (UTC)

Suggestion for DOI validation: check for a forward slash

The Numbering section of the DOI Handbook says that "The DOI syntax shall be made up of a DOI prefix and a DOI suffix separated by a forward slash." I occasionally come across DOIs similar to "10.1038", with no forward slash or suffix value. DOIs without a suffix are incomplete, will not lead to the journal article being cited, and could be flagged as an error.

Is the lack of a forward slash something that we could check for and flag as an error? I suggest that we do so. Any objections? – Jonesey95 (talk) 05:43, 28 February 2014 (UTC)

Refined in the Module:Citation/CS1/sandbox:

"PASS: prefix/suffix". doi:10.1000/999. {{cite journal}}: Cite journal requires |journal= (help)

"FAIL: no forward slash". doi:10.1000999. {{cite journal}}: Check |doi= value (help); Cite journal requires |journal= (help)

"FAIL: no suffix". doi:10.1000/. {{cite journal}}: Check |doi= value (help); Cite journal requires |journal= (help)

The Numbering section of the DOI Handbook also notes that the characters that make up the doi name "can incorporate any printable characters from the legal graphic characters of Unicode." From this I assume that our proscription of endashes and terminal periods and commas may not be in strict adherence to the standard.

—Trappist the monk (talk) 13:14, 28 February 2014 (UTC)

Re the proscription of spaces, endashes, terminal periods, and terminal commas: I have been monitoring the doi error category as articles are swept into it by the new code, and I click on every DOI that is marked invalid in order to check our assumptions about these four rules. So far, 100% of the DOIs I have checked have indeed been invalid. In every case, removing the space, replacing the endash with a hyphen, or removing the terminal period or comma has resulted in the intended article. I have fixed about 125 articles with DOI errors since the new code went into effect; there were zero articles in the category before the code changed. I have found zero false positives from the new code. – Jonesey95 (talk) 19:21, 28 February 2014 (UTC)

PMC error check needed

As I'm cleaning up PMID errors, I am finding a number of PMC parameters that are invalid. The invalid ones typically take the form "PMC=PMC213456", like this:

Cite journal comparison

Wikitext	{{cite journal|doi=10.1186/1756-3305-7-45|first=Anita|issue=1|journal=Parasites & Vectors|last=Ale|pages=45|pmc=PMC3900737|pmid=24450957|title=Epidemiology and genetic diversity of Taenia asiatica: a systematic review|volume=7|year=2014}}
Live	Ale, Anita (2014). "Epidemiology and genetic diversity of Taenia asiatica: a systematic review". Parasites & Vectors. 7 (1): 45. doi:10.1186/1756-3305-7-45. PMC 3900737. PMID 24450957.{{cite journal}}: CS1 maint: PMC format (link) CS1 maint: unflagged free DOI (link)
Sandbox	Ale, Anita (2014). "Epidemiology and genetic diversity of Taenia asiatica: a systematic review". Parasites & Vectors. 7 (1): 45. doi:10.1186/1756-3305-7-45. PMC 3900737. PMID 24450957.{{cite journal}}: CS1 maint: PMC format (link) CS1 maint: unflagged free DOI (link)

Can we add a PMC parameter check that flags non-numeric characters, creates an error message, and puts the articles in a category? I believe that PMC IDs are all-numeric and currently run from 1 to about 4000000 (four million). Checking for one to seven numbers in a row with no other types of characters should probably do the trick (white space before or after the number is OK). I have been unable to find a spec for the PMC, however. Someone might have better web searching skills than I do. – Jonesey95 (talk) 04:52, 23 February 2014 (UTC)

Added to Module:Citation/CS1/sandbox. Will be categorized into Category:CS1 errors: PMC. I have set the limit at 4,000,000.

–Trappist the monk (talk) 14:52, 23 February 2014 (UTC)

For the record, I changed the limit to 5,000,000 because the number will go over 4,000,000 soon if it has not already. I gave us some breathing room. – Jonesey95 (talk) 14:46, 2 March 2014 (UTC)

CS1 errors: PMID not working quite right?

{{Cite_pmid/30147920}} displays the new pmid error, but it is not in the corresponding category. I have performed a null edit on the template, and it still does not join the category. I believe that the problem may be this line in CS1/Configuration:

category = '', --'CS1 errors: PMID',

I think there is some extra text in there that does not belong. Trappist the monk?

By the way, don't worry about the existence of this template. It exists because of a bug in Citation bot. If you delete the template, Citation bot will recreate it until the bug is fixed, so just leave it alone for now. – Jonesey95 (talk) 15:50, 15 February 2014 (UTC)

Yep, that one I missed. Fixed, I think.

—Trappist the monk (talk) 16:02, 15 February 2014 (UTC)

Invalid year doesn't generate error

In Hedingham Castle, the invalid year in the following citation does not generate an error:

Cite web comparison

Wikitext	{{cite web|accessdate=September 2011|author=Essex County Council|publisher=[http://unlockingessex.essexcc.gov.uk/uep/custom_pages/home_page.asp?content_page_id=48 Unlocking Essex's Past website]|ref=harv|title=SMR Number:6787 Hedingham Castle|url=http://unlockingessex.essexcc.gov.uk/uep/custom_pages/monument_detail.asp?content_page_id=89&monument_id=22310&content_parents=48|year=6787}}
Live	Essex County Council (6787). "SMR Number:6787 Hedingham Castle". Unlocking Essex's Past website. Retrieved September 2011. {{cite web}}: Check date values in: |accessdate= and |year= (help); External link in |publisher= (help); Invalid |ref=harv (help)
Sandbox	Essex County Council (6787). "SMR Number:6787 Hedingham Castle". Unlocking Essex's Past website. Retrieved September 2011. {{cite web}}: Check date values in: |accessdate= and |year= (help); External link in |publisher= (help); Invalid |ref=harv (help)

Should the logic be changed to throw an error if a four digit year does not start with a 1 or a 20? GoingBatty (talk) 02:36, 1 March 2014 (UTC)

A good idea. Years in the future should generate an error (unless someone can provide a counterexample from a real article). Maybe any year (or year within |date=) greater than the current year (can this be pulled from a system variable of some sort so that we can be picky but don't have to update it?) could be flagged as errors. An issue date can have next year's value in it (e.g. the January 2015 issue of a magazine, published and cited in November or December of 2014), so we might need to allow currentyear+1 to avoid false positives.

I expect that most years with unreasonable values will be typos (e.g. year=20014) or values intended for other parameters (e.g. year=1967654 instead of pmid=1967654). – Jonesey95 (talk) 04:34, 1 March 2014 (UTC)

I can give one case of a limited counter example. Rand McNally, in their infinite wisdom, released the 2014 edition of The Road Atlas in the middle of 2013 bearing a 2014 copyright date. As you also said, a magazine can run a month or so ahead on dates, thus crossing over the year "prematurely". I can't think of any other case unless the Rand McNally accelerates their schedule enough to get 2017's edition out in 2015... Imzadi 1979 → 05:07, 1 March 2014 (UTC)

In Module:Citation/CS1/sandbox I have implemented an experiment that checks |date=c. <year>, |date=<year> and |year=<year> to see if <year> is no further in the future than next year.

• good c. date. c. 2014.
• good c. date. c. 2015.
• bad c. date. c. 2016.

• good date. 2014.
• good date. 2015.
• bad date. 2016.

• good year. 2014.
• good year. 2015.
• bad year. 2016.

Shall I continue with this?

When this topic was first opened I did a quick test with the debug console using =os.date("Y"). At the time that call returned the current year. Today, when I added this test, that same function call returned Y. I have got round that with this: =os.date("*t").year which does return the current year. (os.date documentation)

—Trappist the monk (talk) 15:14, 7 March 2014 (UTC)

It has been pointed out that I sometimes fail to read and comprehend the manual: os.date("%Y") not os.date("Y").

—Trappist the monk (talk) 19:43, 7 March 2014 (UTC)

I think we should do this. I can't think of a valid reason why a year in a citation would be further in the future than next year. – Jonesey95 (talk) 15:19, 7 March 2014 (UTC)

Ok, so here are the rest of the currently supported date formats:

• good year. 2015a.
• bad year. 2016a.

• good date. 2015-12-15.
• bad date. 2016-12-15.

• good date. January 23, 2015.
• bad date. January 23, 2016.

• good date. January 23–27, 2015.
• bad date. January 23–27, 2016.

• good date. 14 April 2015.
• bad date. 14 April 2016.

• good date. 14–15 April 2015.
• bad date. 14–15 April 2016.

• good date. Spring–Summer 2015.
• bad date. Spring–Summer 2016.

• good date. June 2015.
• bad date. June 2016.

—Trappist the monk (talk) 18:18, 7 March 2014 (UTC)

Separator when set to none

• separator:controls the punctuation used to separate lists of authors, editors, etc. Defaults to a comma and space (, ); if the parameter is present, but blank, separator punctuation is set to the default; a space must be encoded as &#32;.

Default comma (OK)

• {{{citation |author=Ann Author |year=1901 |title=An old book |publisher=UCL}}
• Ann Author (1901), An old book, UCL {{citation}}: |author= has generic name (help)

set to stop (OK)

• {{{citation |author=Ann Author |year=1901 |title=An old book |publisher=UCL |separator=.}}
• Ann Author (1901), An old book, UCL {{citation}}: |author= has generic name (help); Unknown parameter |separator= ignored (help)

set to nothing (NOT OK: because there is no comma displayed -- the default).

• {{{citation |author=Ann Author |year=1901 |title=An old book |publisher=UCL |separator=}}
• Ann Author (1901), An old book, UCL {{citation}}: |author= has generic name (help); Cite has empty unknown parameter: |separator= (help)

It is annoying that this can not be set against a version because when it is fixed (or another version is put in place the output for these examples will change) however with the current version it seems that if the separator parameter is passed into {{citation}} without a value the citation output differs from when the separator parameter is not passed in. A feature or a bug? --PBS (talk) 20:56, 5 March 2014 (UTC)

Your "set to stop" example and execution don't seem to match.

Apparently, it has ever been thus. This comparison is between the current live module and the last {{citation/core}} version of the {{citation}} template.

Citation comparison

Wikitext	{{citation|author=Ann Author|publisher=UCL|title=An old book|year=1901}}
Live	Ann Author (1901), An old book, UCL {{citation}}: |author= has generic name (help)
Sandbox	Ann Author (1901), An old book, UCL {{citation}}: |author= has generic name (help)

—Trappist the monk (talk) 21:10, 5 March 2014 (UTC)

It's long-standing behaviour of {{citation}} that when |separator= is present but blank, the effect is different from the effect when that parameter is omitted entirely. --Redrose64 (talk) 21:51, 5 March 2014 (UTC)

(edit conflict) At a minimum, it looks like a documentation issue. From a logical standpoint having the behavior be different (" ") from the default (", ") is more reasonable. However, given the documentation is very clear that a blank parameter value uses the default (", "), we probably should determine when/if this changed. Depending on how long ago, there could be some old malformed citations with this parameter blank which showed as ", " at some time in the past. On the other hand, the difference is not that great in what is displayed. It could be reasonable to just change the documentation.

A question is what default behavior is appropriate for an empty |separator=. Should it use " ", or ", " as in the documentation. Using " " appears more reasonable to me. Ether way, when done, the documentation should reflect what actually happens. Assuming that this change happened a long time ago, we should probably just change the documentation. — Makyen (talk) 22:03, 5 March 2014 (UTC)

The problem with changing the default behaviour is that makes it different from the behaviour of other parameters, where a blank is treated as null and so setting them has no effect. It is also different behaviour from {{cite book}} etc:

• {{{cite book |author=Ann Author |year=1901 |title=An old book |publisher=UCL |separator=}}
• Ann Author (1901). An old book. UCL. {{cite book}}: |author= has generic name (help); Cite has empty unknown parameter: |separator= (help)

{{cite book}} etc also handles postscripts in a useful way:

• postscript: Controls the closing punctuation for a citation; defaults to a period (.); for no terminating punctuation, specify |postscript=none – leaving |postscript= empty has the same effect but is ambiguous. Ignored if quote is defined.

The problem with the way {{citation}} is working comes when wrapper template call {{citation}}

{{wrapper-template
{{citation
<!--fill out known parameters-->
|author=Ann Author
|year=1901 
|title=An old book 
|publisher=UCL
<!--pass in variable parameters-->
|pages={{{pages|}}}
|page={{{page|}}}
<!-- allow postscript and separator to be set to other values to match {{cite book}}} etc-->
|postscript={{{postscript}}}
|separator={{{separator|}}}
}}
}}

This fails as shown with {{citation}} it works with {{cite book}}.

In the past not setting parameters could be handled using the construct:

   
    |{{#if:{{{postscript|}}} |postscript  |HIDE_PARAMETER}}={{{postscript|}}}
    |{{#if:{{{separator|}}} |separator  |HIDE_PARAMETER}}={{{separator|}}}
  

But I have yet to persuade those that are editing CS1 code to add a parameter which does nothing to allow this to be done. The facility existed by default before CS1 was introduced (because all parameters not used were ignored), and I think it would help in writing wrapper templates if a specific do null parameter like HIDE_PARAMETER was put into the interface, to mimic the old interface. -- PBS (talk) 08:33, 6 March 2014 (UTC)

It is quite untrue to state "the facility existed by default before CS1 was introduced (because all parameters not used were ignored)". From Template:Citation (final pre-Lua version, 11:52, 7 September 2012‎):

  |Sep = {{#ifeq:{{{separator|{{{seperator}}}}}}|;|&#059;|{{{separator|{{{seperator|,}}}}}}}}
  |AuthorSep = {{#ifeq:{{{author-separator|}}}|;|&#059;|{{{author-separator|&#059;}}}}} 
  |NameSep = {{{author-name-separator|,}}} 

and from Template:Cite book (final pre-Lua version, 14:07, 9 December 2012):

|AuthorSep={{#ifeq:{{{author-separator|}}}|;|&#059;|{{{author-separator|&#059;}}}}} 
|NameSep={{{author-name-separator|,}}} 
|Sep={{#ifeq:{{{separator|{{{seperator}}} }}}|;|&#059;|{{{separator|{{{seperator|.}}} }}} }}

Here, &#059; is a semicolon and   is a space; and the construct {{{separator|{{{seperator ...}}} }}} permits |seperator= to be used as an alias for |separator=. Apart from that, what this means is that since two of the three lines (those for AuthorSep and NameSep) were equivalent, differing only in spacing, the action of |author-separator= for both {{citation}} and the Citation Style 1 templates was completely identical, as was that of |author-name-separator=. Specifically,

• AuthorSep (the characters used in between each distinct author) consisted of a semicolon and a space; the semicolon could be overridden by setting |author-separator= to any non-blank value. Here, if |author-separator= were present but blank, it was as if the parameter had been entirely absent.
• NameSep (the characters used in between lastname and firstname) consisted of a comma and a space, but only if |author-name-separator= was entirely absent. If it was present but blank, there was only a space in between lastname and firstname. If |author-name-separator= was set to any non-blank value, that would override the comma.

In the case of the third line (Sep), which sets the characters used to separate authors from title; title from publisher; (etc.), the behaviour did differ - but only to the extent that {{citation}} used a comma and the Citation Style 1 templates used a period. What happened was that if |separator= was entirely absent, a comma (or period in the case of CS1) plus a space was used; if |separator= was present, even if it was blank, then whatever it was set to overrode the comma (or period).

So there were two parameters - |author-name-separator= and |separator= - where the behaviour when blank was not the same as the behaviour when absent, and this behaviour was consistent whether {{citation}} or the Citation Style 1 templates were used. There may have been more than two; I've not checked. --Redrose64 (talk) 12:15, 6 March 2014 (UTC)

I have never been happy with the notion that an empty parameter does something different from a missing parameter. Such cases simply cause confusion and documentation problems. During the initial development of Module:Citation/CS1 I was able to persuade enough editors that we should make an empty |postscript= act the same as if it were not there and for those cases where it is desirable to have no separator, use |postscript=none. This topic gives me the opportunity to also make the same changes for |separator=. In Module:Citation/CS1/sandbox I have done so.

To do that, I have moved the default assignments of |postscript= (empty), |ref=harv, |separator=, (comma) from the {{citation}} template into the module.

{{citation/new}}:

• Ann Author (1901), no |separator= default (comma), UC {{citation}}: |author= has generic name (help)
• Ann Author (1901), empty |separator= uses default (comma), UC {{citation}}: |author= has generic name (help); Cite has empty unknown parameter: |separator= (help)
• Ann Author (1901), |separator=; (semicolon), UC {{citation}}: |author= has generic name (help); Unknown parameter |separator= ignored (help)
• Ann Author (1901), if |separator=none (nothing), UC {{citation}}: |author= has generic name (help); Unknown parameter |separator= ignored (help)

• Ann Author (1901), no |postscript= default (nothing), UC {{citation}}: |author= has generic name (help)
• Ann Author (1901), empty |postscript= uses default (nothing), UC {{citation}}: |author= has generic name (help)
• Ann Author (1901), |postscript=; (semicolon), UC; {{citation}}: |author= has generic name (help)
• Ann Author (1901), if |postscript=none (nothing), UC {{citation}}: |author= has generic name (help)CS1 maint: postscript (link)

Compare to {{cite book/new}}

• Ann Author (1901). no |separator= default (period). UC. {{cite book}}: |author= has generic name (help)
• Ann Author (1901). empty |separator= uses default (period). UC. {{cite book}}: |author= has generic name (help); Cite has empty unknown parameter: |separator= (help)
• Ann Author (1901). |separator=; (semicolon). UC. {{cite book}}: |author= has generic name (help); Unknown parameter |separator= ignored (help)
• Ann Author (1901). if |separator=none (nothing). UC. {{cite book}}: |author= has generic name (help); Unknown parameter |separator= ignored (help)

• Ann Author (1901). no |postscript= default (period). UC. {{cite book}}: |author= has generic name (help)
• Ann Author (1901). empty |postscript= uses default. UC. {{cite book}}: |author= has generic name (help)
• Ann Author (1901). |postscript=; (semicolon). UC; {{cite book}}: |author= has generic name (help)
• Ann Author (1901). if |postscript=none (nothing). UC {{cite book}}: |author= has generic name (help)

Also located a longstanding bug that ate the last character of a multi-character separator: |separator=&#059;.

• Ann Author (1901). if |separator=&#059;. UC. {{cite book}}: |author= has generic name (help); Unknown parameter |separator= ignored (help)

This same code snippet also ate one character of the last displayed parameter if |separator=none. I have put in a temporary fix for the |separator=none case and will address the larger issue of multi-character separators shortly.

—Trappist the monk (talk) 14:55, 6 March 2014 (UTC)

Longstanding bug fixed.

—Trappist the monk (talk) 16:13, 6 March 2014 (UTC)

@Redrose64 "It is quite untrue to state "the facility existed by default before CS1 was introduced (because all parameters not used were ignored)". " I think you have misunderstood what I wrote. I was referring to the last construct I posted where there is a parameter called "HIDE_PARAMETER". That parameter was swallowed silently by {{citation}} and {{cite book}} before the use of CS1 because no checking was done for parameters that were not used (as is usual in template code) Hence "because all parameters not used were ignored" -- the ones you mentioned were used and not were not ignored. Hence my statement, and just like shell scripting in UNIX I think it would be useful to have a null parameter (whatever it is called) to allow for script constructs like this:

|{{#if:{{{separator|}}} |separator  |HIDE_PARAMETER}}={{{separator|}}}

If such a null parameter exists then one does not need to know if the underlying citation template uses or does not use CS1. If you know of an elegant template script to replicate the use of HIDE_PARAMETER I would be interested to see it, because then parameters that are not set by the article do not need to be passed into sub templates that do not use them. -- PBS (talk) 16:32, 6 March 2014 (UTC)

The Lua-based cites ignore any empty HIDE_PARAMETER or such: I was not aware of using name "HIDE_PARAMETER=" to omit empty parameters, but the Lua-based cites were set early to ignore any empty parameter and not show error messages for unknown spelling if empty: {cite book|title=Book|HIDE_PARAMETER=}} gives: "Book. {{cite book}}: Cite has empty unknown parameter: |HIDE_PARAMETER= (help)" and allows any empty parameters to remain hidden in the output. -Wikid77 17:09, 13 March 2014 (UTC)

That is good news but I still it worth having a NULL parameter whatever it is called so that a value can be passed it that has no affect. As it allows a construction like this:

|{{#if:{{{page|}}} |page |HIDE_PARAMETER}}=[http://www.archive.org/stream/dictionaryofnati00leesuoft#page/{{Str number/trim|{{{page}}}}}/mode/1up {{{page|}}}]

Without that something like this is needed:

|page={{#if:{{{page|}}}| [http://www.archive.org/stream/dictionaryofnati00leesuoft#page/{{Str number/trim|{{{page}}}}}/mode/1up {{{page|}}}] }}

The problem with the workaround needed so that an unrecognised parameter is not passed into CS1, is that then one has to know what the underlying code is. If it is CS1 no problem because an empty value is passed in via page and ignored. But if the underlying module is another intermediate template it can break the code code because of the problems of this type of coding:

{{{page|{{{pages}}}}}}

the parameter "pages2 not being tested because "page" is set to an empty string. If one NULL parameter such as HIDE_PARAMETER (or NULL or whatever) exists (and is documented) then the problem is transparent from the point of of the template writer.

At the moment for example if one looks at the template {{Citation}} one has to be that if a template calls Citation then using passing in a blank field "inventor-surname=" will prevent that script testing for "inventor-last"

So for example:If I write a wrapper template that sets

   {{citation                                
   |inventor-surname={{{inventor-surname|}}} 
   |inventor-last={{{inventor-last|}}}       
   |title={{{title|}}}                       
   }}                                            

And then call it with the equivalent of:

   {{citation          
   |inventor-surname=  
   |inventor-last=Last 
   |title=A title      
   }}                   

Produces: A title {{citation}}: Cite has empty unknown parameter: |inventor-surname= (help); Unknown parameter |inventor-last= ignored (help) (no inventor-last parameter displayed and the citation script tries to call CS1 because the first test does not handle the empty "inventor-surname=" parameter (as CS1 would" but because inventor-last is set to a value CS1 displays it as an invalid value ).

This is why the construct with a NULL parameter is so useful. If the a null parameter exists then code like the below (for inventors from Scotland ):

   {{citation|                   
  |{{#if:{{{inventor-surname|}}} |inventor-surname |NULL}}=Mac{{{inventor-surname|}}} 
  |{{#if:{{{inventor-last|}}} |inventor-last  |NULL}}={{{inventor-last|}}}            
  |{{#if:{{{title|}}} |title  |NULL}}={{{title|}}}                                    
  }}                          

would be the same whichever method {{citation}} uses inside its code. At the moment one has to be aware if the parameter one is setting is going to call template coded or be passed in to CS1. It is the old classic problem layered software not being transparent to the application programmer a NULL parameter in the CS1 interface would go a long way to fixing such problems.

-- PBS (talk)

Empty separator ignored for hundreds of {cite_web} pages

When I developed Module:Citation/CS1 last year, I changed it to differ from {citation/core} and to ignore empty "separator=" and default to dot "." in {cite_web} because many people were copying all possible empty parameters into cites (in numerous pages) and leaving empty "separator=" to omit all extra punctuation in cites. When the Lua-based cites were first deployed, then {cite_web} put dot "." for all empty "separator=" cases, among over 50,000 pages (of the 2.2 million) which were autofixed for data separators, along with "pages=7" showing singular "p. 7" as autofixed to no longer show plural "pp." in thousands of pages. When using the {citation} templates, with empty "separator=" to hide comma ',' then perhaps people have actively added dots into each specific parameter "title=Page." or "author=Doe." or "series=BBC." because empty "separator=" has been omitting the automatic commas between data items in {citation} template calls, unlike default dots in {cite_book} or {cite_web} etc. -Wikid77 17:09, 13 March 2014 (UTC)

Lua function citation0 allows 90 more variables

Just in case, I have confirmed how the Lua Module:Citation/CS1 could support another 90 parameter names, in the data-formatter function citation0( ), before hitting Lua's limit of 200 local variables per function. Currently, the numbered author-name parameters, such as "last2=" to "last84=" are stored in array/tables and do not subtract from the 200-variable limit. Although 90 new parameter names will fit, attempting to add 95 more parameters into citation0() would be too many and cause "Script error" for all wp:CS1 cite templates. When a Lua script hits the 200-variable limit, the "Script error" stores the following message in the rendered HTML markup page:

"Lua error... at line 2276: function at line 977 has more than 200 local variables"

In many ways, although Lua is very fast, it is still somewhat of a "toy language" in the sense that it acts as a limited tool with novice-style restrictions, compared to a professional language which might allow more than 1,000 variable names in a function, plus auto-correct for errors and continue running with the prior 199 variables rather than crater at 200 names with a fatal "Script error". If needed, we should be prepared to redesign Lua modules to work within such minimal limits, and not be surprised with cramped restrictions. However, at this point, the additional capacity for 90 more parameter names should be sufficient. -Wikid77 (talk) 15:09, 13 March 2014 (UTC)

Why do we need 90 more parameter names? --Redrose64 (talk) 15:46, 13 March 2014 (UTC)

Many of the 23 {cite_*} forks had used more aliases for other parameters, but many are already handled; for example {cite_episode} had added 11 more parameter names: episodelink, serieslink, network, station, city, began, ended, season, seriesno, minutes, time, transcript, transcripturl (etc.). Those names were beyond the original core 43 major parameter names used by {cite_web} or {cite_book}, etc. Other alias names could be re-assigned to store in the prior variable names, keeping the total below 200 names in function citation0(). -Wikid77 17:33, 13 March 2014 (UTC)

I haven't looked at the remaining CS1 modules that need to be migrated, but a handful (under 10, I think) have been added for the most recent two that are in the Sandbox. I find it hard to imagine approaching 90 more. We should be all set. – Jonesey95 (talk) 16:39, 13 March 2014 (UTC)

The /sandbox version has been counted, allowing 90 variable names beyond those. -Wikid77 17:33, 13 March 2014 (UTC)

Legitimate date range examples to add to the date checking part of the CS1 module

This is a list of what appear (to me) to be legitimate date ranges that should be added to the CS1 module's date-checking code. Date ranges in these formats are allowable per MOSDATE and related MOS sections. I have provided examples from actual articles that cite actual publications, since I would prefer not to change the module based on WP:BEANS-like speculation.

1. "Nov 29 - Dec 12, 1997" from Welding Kumar
2. "December 2008-January 2009" from 1964 East Pakistan riots. The original publication describes the issue as "the December 2008 - January 2009 issue".
3. "25 July – 4 August 2007" from Jo Jo Zep.
4. "|date=11–17 August 2012" from Jodi Gordon and similar in Template:Egyptian parliamentary election.
5. "|date=August 11-17, 2012" and "|date=August 29 - September 5, 2012". I haven't found an example yet, but I expect they are out there for weekly publications in the U.S.
6. Year ranges in citations such as {{Cite AT}}, {{Cite DAB}}, {{Cite DCB}}, {{Cite DGRG}}, {{Cite DNB}}, {{Cite EB9}}, {{Cite Jewish Encyclopedia}}, {{Cite LL}}, {{Cite Togail Bruidne Da Derga II}}, and {{LarousseXIXe}}.
7. Another citation with year ranges: "| journal = Monumenta Serica | volume = 31 | year = 1974–75" in Middle Chinese. Monumenta Serica's volumes were published with year ranges; see this list of volumes for examples.
8. I don't know if this one is valid per MOS, but it matches the source and I've seen it a handful of times: "| date =Winter 1963/1964", from Template:Cite doi/10.2307.2F40198709. This date matches the date in JSTOR.

I would prefer to avoid the issue of different kinds of dashes, and dash spacing, for now. Let's just allow spacing and different kinds of dashes. A bot or AWB's general fixes might be able to fix the dashes without the module creating a large new batch of error messages. – Jonesey95 (talk) 17:31, 29 December 2013 (UTC)

I agree that there should be some valid way of expressing date ranges when used by the original publication. For some of those templates, the issue is that the |volume= parameter is missing. Once added, the template limits the date to one year. It would be helpful if the error message said that the volume was missing instead of stating there's an invalid date parameter. Or maybe add a tracking category to some of those templates that editors could then maintain. GoingBatty (talk) 18:01, 29 December 2013 (UTC)

Agree in general, with one exception. I think #1 should not be valid, because the names of the months should be spelled out. Debresser (talk) 18:46, 29 December 2013 (UTC)

MOS:DATEFORMAT says that the months do not need to be spelled out in references. GoingBatty (talk) 18:52, 29 December 2013 (UTC)

I don't see why the presence or absence of a |volume= should affect the validation of |date= - they are independent values. --Redrose64 (talk) 00:44, 30 December 2013 (UTC)

Let's look at this example from A. J. Humbert, which is in Category:CS1 errors: dates:

• {{DNB Cite|wstitle=Humbert, Albert Jenkins}} generates "Humbert, Albert Jenkins" . Dictionary of National Biography. London: Smith, Elder & Co. 1885–1900.

The error message is confusing because there is no |date= in this citation. It's not obvious that the way to remove the error is to add |volume=, as follows:

• {{DNB Cite|wstitle=Humbert, Albert Jenkins|volume=28}} generates Lee, Sidney, ed. (1891). "Humbert, Albert Jenkins" . Dictionary of National Biography. Vol. 28. London: Smith, Elder & Co.

My suggestion is that if we provide more clarity in the error message, it's more likely the issue will be resolved. GoingBatty (talk) 05:00, 30 December 2013 (UTC)

Plus, if there was an easy way to define the volume based off the |wstitle= parameter, it could be done by bot (e.g. If |wstitle= is between Aa and Ar add |volume=1, if between As and Be add |volume=2, etc.) GoingBatty (talk) 07:14, 30 December 2013 (UTC)

Why should adding |volume= limit the date to one year? How am I to cite an article in a multi-year volume like Monumenta Serica 31(1974–75)? (a real example that has been broken in live articles by this change) Kanguole 11:11, 30 December 2013 (UTC)

I don't think that what Editor GoingBatty is describing applies to Monumenta Serica. The issue is with {{cite DNB}} which is a wrapper template for {{cite encyclopedia}}. If an error message is to be emitted when |volume= is empty or omitted, it should be done by {{cite DNB}}. Module:Citation/CS1 does not and cannot know about the requirements of individual wrapper templates.

Alternately, {{cite DNB}} can be changed to leave |year= blank when |volume= is empty or omitted. There may be cases where leaving |volume= blank is appropriate. If these cases exist, then perhaps the special secret code word none could be detected so {{cite DNB}} leave both |year= and |volume= blank when they are passed to {{cite encyclopedia}}.

Enough. This should be discussed at the wrapper template and not here.

—Trappist the monk (talk) 12:46, 30 December 2013 (UTC)

OK, but references to that volume of Monumenta Serica (using {{citation}}) remain broken. Could that be fixed? Kanguole 12:57, 30 December 2013 (UTC)

Thanks for the pointer to Monumenta Serica. I have added it above, along with a link to a list of the journal's issues showing that some issues were printed with year ranges. This discussion was started with the intent of fixing the citation errors that you are seeing. Your contribution is valuable. – Jonesey95 (talk) 16:31, 30 December 2013 (UTC)

Please continue the conversation about {{cite DNB}} at Template talk:Cite DNB#CS1 errors when volume not included. GoingBatty (talk) 15:41, 30 December 2013 (UTC)

Two questions. 1. Why do we have to discuss this at other pages? This seems to be the centralized page for this discussion. 2. Where precisely does it say that month names may be abbreviated in references? Debresser (talk) 19:22, 30 December 2013 (UTC)

1. The |volume= discussion is a fork from the original question, which is asking whether the CS1 module should be changed to allow valid date ranges. It is a legitimate topic of discussion, but discussing it in full within this section muddies the waters.

2. Look at the fourth row of the first table in MOS:DATEFORMAT. The example date is "Sep 8, 2001". – Jonesey95 (talk) 11:34 am, Today (UTC−8)

1. Because {{cite DNB}} is not a CS1 citation and GoingBatty's possible solution to the issue of date errors resulting from the use or misuse of {{cite DNB}} citations involves changing {{cite DNB}} templates in article space. Those changes would not be made to the underlying {{cite encyclopedia}} nor to Module:Citation/CS1.
2. Acceptable dates table at WP:DATESNO.

—Trappist the monk (talk) 19:35, 30 December 2013 (UTC)

I am sorry for paying attention so badly. Debresser (talk) 23:39, 30 December 2013 (UTC)

So do I understand correctly that the date and year ranges will be allowed in the upcoming update of CS1? Debresser (talk) 23:43, 30 December 2013 (UTC)

Editor Jonesey95's item 4 and part of item 5 at top of thread using Module:Citation/CS1/sandbox:

• Pass: Day initial day-range. 12–13 June 1953.
• Pass: Day initial day-range (short). 12–13 Jun 1953.
• Pass: Month initial day-range. March 2–6, 2013.
• Pass: Month initial day-range (short). Mar 2–6, 2013.
• Fail: Day initial day-range (order). 22–13 June 1953. {{cite book}}: Check date values in: |date= (help)
• Fail: Day initial day-range (same). 22–22 June 1953. {{cite book}}: Check date values in: |date= (help)
• Fail: Day initial day-range (hyphen). 12–13 Jun 1953.{{cite book}}: CS1 maint: date format (link)
• Fail: Day initial day-range (spaced endash). 12 – 13 Jun 1953. {{cite book}}: Check date values in: |date= (help)
• Fail: Month initial day-range (order). June 22–13, 1953. {{cite book}}: Check date values in: |date= (help)
• Fail: Month initial day-range (same). June 22–22, 1953. {{cite book}}: Check date values in: |date= (help)
• Fail: Month initial day-range (hyphen). Jun 12–13, 1953.{{cite book}}: CS1 maint: date format (link)
• Fail: Month initial day-range (spaced endash). Jun 12 – 13, 1953. {{cite book}}: Check date values in: |date= (help)
• Fail: Month initial day-range (invalid end date). 22–29 February 1953. {{cite book}}: Check date values in: |date= (help)
• Fail: Month initial day-range (invalid end date). February 22–29, 1953. {{cite book}}: Check date values in: |date= (help)

—Trappist the monk (talk) 14:22, 29 January 2014 (UTC)

Editor Jonesey95's item 3 at top of thread using Module:Citation/CS1/sandbox:

• Pass:. 27 June – 3 July 1953.
• Pass: (short). 27 Jun – 3 Jul 1953.
• Fail: (order). 3 July – 27 June 1953. {{cite book}}: Check date values in: |date= (help)
• Fail: (same). 27 June – 27 June 1953. {{cite book}}: Check date values in: |date= (help)
• Fail: (hyphen). 27 June – 3 July 1953.{{cite book}}: CS1 maint: date format (link)
• Fail: (unspaced endash). 27 June–3 July 1953. {{cite book}}: Check date values in: |date= (help)
• Fail: (invalid start date). 31 June – 3 July 1953. {{cite book}}: Check date values in: |date= (help)
• Fail: (invalid end date). 29 January – 29 February 1953. {{cite book}}: Check date values in: |date= (help)

—Trappist the monk (talk) 12:30, 8 March 2014 (UTC)

Editor Jonesey95's item 1 and second part of item 5 at top of thread using Module:Citation/CS1/sandbox:

• Pass:. June 27 – July 3, 1953.
• Pass: (short). Jun 27 – Jul 3, 1953.
• Fail: (order). July 3 – June 27, 1953. {{cite book}}: Check date values in: |date= (help)
• Fail: (same). June 27 – June 27, 1953. {{cite book}}: Check date values in: |date= (help)
• Fail: (hyphen). June 27 – July 3, 1953.{{cite book}}: CS1 maint: date format (link)
• Fail: (unspaced endash). June 27–July 3, 1953. {{cite book}}: Check date values in: |date= (help)
• Fail: (invalid start date). June 31 – July 3, 1953. {{cite book}}: Check date values in: |date= (help)
• Fail: (invalid end date). January 29 – February 29, 1953. {{cite book}}: Check date values in: |date= (help)

This date format may not be permissible under WP:DATERANGE. I've started a discussion at WT:MOSDATE.

—Trappist the monk (talk) 14:06, 8 March 2014 (UTC)

Editor Jonesey95's item 2 at top of thread using Module:Citation/CS1/sandbox:

• Pass:. December 1952 – January 1953.
• Pass: (short). Dec 1952 – Jan 1953.
• Fail: (order). January 1953 – December 1952. {{cite book}}: Check date values in: |date= (help)
• Fail: (same year). December 1953 – January 1953. {{cite book}}: Check date values in: |date= (help)
• Fail: (hyphen). December 1952 – January 1953.{{cite book}}: CS1 maint: date format (link)
• Fail: (unspaced endash). December 1952–January 1953. {{cite book}}: Check date values in: |date= (help)
• Fail: (mismatch). Winter 1952 – January 1953. {{cite book}}: Check date values in: |date= (help)
• Fail: (mismatch). December 1952 – Spring 1953. {{cite book}}: Check date values in: |date= (help)

This one is a bit different. What about CITEREF and CITEREF disambiguation? CITEREF disambiguator is appended to the last (rightmost) year. For CITEREF, I have concatenated the year values with an endash separator:

• *'"`UNIQ--templatestyles-00000196-QINU`"'<cite id="CITEREFAuthor1952–1953a" class="citation book cs1">Author (December 1952 – January 1953a). ''Pass:''.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Pass%3A&rft.date=1952-12%2F1953-01&rft.au=Author&rfr_id=info%3Asid%2Fwiki.riteme.site%3AModule+talk%3ACitation%2FCS1%2FArchive+9" class="Z3988"></span> <span class="cs1-visible-error citation-comment"><code class="cs1-code">{{[[Template:cite book|cite book]]}}</code>: </span><span class="cs1-visible-error citation-comment"><code class="cs1-code">&#124;author=</code> has generic name ([[Help:CS1 errors#generic_name|help]])</span>; <span class="cs1-visible-error citation-comment">Invalid <code class="cs1-code">&#124;ref=harv</code> ([[Help:CS1 errors#invalid_param_val|help]])</span>

• Author (December 1952 – January 1953a). Pass:. {{cite book}}: |author= has generic name (help); Invalid |ref=harv (help)

—Trappist the monk (talk) 16:53, 8 March 2014 (UTC)

Editor Jonesey95's item 8 at top of thread using Module:Citation/CS1/sandbox:

• Pass:. Winter 1952–1953.
• Fail: (order). Winter 1953–1952. {{cite book}}: Check date values in: |date= (help)
• Fail: (same year). Winter 1952–1952. {{cite book}}: Check date values in: |date= (help)
• Fail: (not sequential). Winter 1951–1953. {{cite book}}: Check date values in: |date= (help)

CITEREF and CITEREF disambiguation:

• '"`UNIQ--templatestyles-0000019F-QINU`"'<cite class="citation book cs1">''Pass:''. Winter 1952–1953a.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Pass%3A&rft.date=1952%2F1953&rfr_id=info%3Asid%2Fwiki.riteme.site%3AModule+talk%3ACitation%2FCS1%2FArchive+9" class="Z3988"></span> <span class="cs1-visible-error citation-comment"><code class="cs1-code">{{[[Template:cite book|cite book]]}}</code>: </span><span class="cs1-visible-error citation-comment">Invalid <code class="cs1-code">&#124;ref=harv</code> ([[Help:CS1 errors#invalid_param_val|help]])</span>

—Trappist the monk (talk) 19:11, 8 March 2014 (UTC)

Thank you! This will help a lot with the CS1 dates category.

As for citeref, I would probably recommend that editors use a specified name for the harv reference rather than trying to finesse the year ranges, but having the module do something reasonable is good too. – Jonesey95 (talk) 19:42, 8 March 2014 (UTC)

Editor Jonesey95's item 6 at top of thread using Module:Citation/CS1/sandbox:

• Pass:. 1952–1953.
• Pass:. 873–1066.
• Fail: (hyphen). 1952–1953.{{cite book}}: CS1 maint: date format (link)
• Fail: (spaced endash). 1952 – 1953. {{cite book}}: Check date values in: |date= (help)
• Fail: (order). 1953–1952. {{cite book}}: Check date values in: |date= (help)
• Fail: (same year). 1952–1952. {{cite book}}: Check date values in: |date= (help)

CITEREF and CITEREF disambiguation:

• '"`UNIQ--templatestyles-000001A7-QINU`"'<cite class="citation book cs1">''Pass:''. 1952–1953a.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Pass%3A&rft.date=1952%2F1953&rfr_id=info%3Asid%2Fwiki.riteme.site%3AModule+talk%3ACitation%2FCS1%2FArchive+9" class="Z3988"></span> <span class="cs1-visible-error citation-comment"><code class="cs1-code">{{[[Template:cite book|cite book]]}}</code>: </span><span class="cs1-visible-error citation-comment">Invalid <code class="cs1-code">&#124;ref=harv</code> ([[Help:CS1 errors#invalid_param_val|help]])</span>

Editor Jonesey95's item 7 at top of thread using Module:Citation/CS1/sandbox:

• Pass:. 1952–53.
• Fail: (hyphen). 1952–53.
• Fail: (spaced endash). 1952 – 53. {{cite book}}: Check date values in: |date= (help)
• Fail: (not allowed). 873–80. {{cite book}}: Check date values in: |date= (help)
• Fail: (order). 1952–50. {{cite book}}: Check date values in: |date= (help)
• Fail: (same year). 1952–52. {{cite book}}: Check date values in: |date= (help)
• Fail: (not allowed). 1952–3. {{cite book}}: Check date values in: |date= (help)
• Fail: (ambiguous). 2002–04. {{cite book}}: Check date values in: |date= (help)

CITEREF and CITEREF disambiguation:

• '"`UNIQ--templatestyles-000001B1-QINU`"'<cite class="citation book cs1 cs1-prop-year-range-abbreviated">''Pass:''. 1952–53a.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Pass%3A&rft.date=1952%2F1953&rfr_id=info%3Asid%2Fwiki.riteme.site%3AModule+talk%3ACitation%2FCS1%2FArchive+9" class="Z3988"></span> <span class="cs1-visible-error citation-comment"><code class="cs1-code">{{[[Template:cite book|cite book]]}}</code>: </span><span class="cs1-visible-error citation-comment">Invalid <code class="cs1-code">&#124;ref=harv</code> ([[Help:CS1 errors#invalid_param_val|help]])</span>

—Trappist the monk (talk) 11:44, 9 March 2014 (UTC)

Brilliant. That looks like it covers the whole list above. Nice work. – Jonesey95 (talk) 20:01, 9 March 2014 (UTC)

It's nice that the coding might be completed, but the foundation is still falling apart. MOS still allows "Sept." "Feb." but the code doesn't. An RFC was conducted, and closure by an uninvolved editor was requested, but no one stepped up to close it. I insist that the one of the proponents of this change make a change to MOS from "Sept." "Feb." to "Feb" and make the change stick. Otherwise, periods after abbreviations and "Sept" should be allowed. Jc3s5h (talk) 20:32, 9 March 2014 (UTC) Modified 21:27 UT.

MOS still allows "Sept." but the code doesn't. Where?

—Trappist the monk (talk) 21:05, 9 March 2014 (UTC)

Sorry, I misremembered. The bullet is:

• Abbreviations for months, such as Feb. in the United States or Feb in most other countries, are used only where space is extremely limited.

Jc3s5h (talk) 21:28, 9 March 2014 (UTC)

Closure of the RFC is still pending. Patience, everyone. When the RFC is closed, the Module code will be adjusted accordingly, if necessary. – Jonesey95 (talk) 21:34, 9 March 2014 (UTC)

I think enough time has passed that we must recognize no uninvolved editor is going to step up and close the RFC. RFCs are not votes, but in this case, the arguments on both sides seem equally reasonable, so it reduces to a vote. There is unanamous agreement that WP:MOS and WP:MOSNUM should agree. On other issues, for cases where I can decipher the editor's opinion:

Question	Yes	No
Restrict abbreviations to 3 letters?	9	4
Permit period after abbreviation?	4	7

So the RFC has a majority of votes in favor of the restrictions currently enforced by the checking code, but the majority is probably not strong enough to support a change to either WP:MOS or WP:MOSNUM. I conclude there is no clear demonstration of consensus for the existing check and the existing check should be modified to allow "Sept" and periods after abbreviations. Jc3s5h (talk) 11:38, 23 March 2014 (UTC)

Being careful with ambiguous YYYY-XX date formatting

[– Jonesey95 (talk) created a subsection header for this, because it is a tangent to the original discussion in this thread.]

Hi, I've come here at the request of User:GoingBatty following from a change to a page I have been watching (Safety lamp). Briefly, another editor (User talk:Irwin24) added a citation and link to a publication which carries the date 1900-1901 on its front page ([1]). Irwin included "| date=1900-01" in the citation. Subsequently BattyBot came along and changed it to "January 1900".

The ideal might be to use the year parameter and to use four digit years as in "|year=1900-1901" (@GoingBatty: thanks for correcting it), but this does illustrate that inexperienced editors will

1. Use common English conventions
2. Possibly refer to MOS and see WP:YEAR and WP:MONTH

Note the caution on this page: "Talk pages in this namespace are generally not watched by many users"; inexperienced users are particularly unlikely to pick up on it. WP:YEAR specifically approves of YYYY-NN whilst WP:MONTH specifically bans YYYY-MM so on the basis both of practicality and of MOS compliance the bot ought to follow NNNN-NN => year range or do nothing. In any case, policy changes should flow from MOS to bot, not the other way around.

Would simply dropping in a tag and awaiting a human not be a better solution to ambiguities? In the case I have been involved with a human would have only taken seconds to see the correct interpretation. Not everything can be reasonably automated. Regards, Martin of Sheffield (talk) 15:11, 1 January 2014 (UTC) ~

The problem of abbreviated year ranges YYYY–XX and truncated year-initial dates YYYY–XX is nicely illustrated by your example. For a date where the initial four-digit year lies within the first 12 years of a century (2000–2011 for example), any two-digit value 01–12 can be construed to be either a year range (when the two-digit value is greater than the value or the last two digits in the preceding four-digit year) or a year followed by a numeric month. Outside of this period the ambiguity does not exist. You are right that WP:YEAR lists this type of year range as permissible but it is mute on the ambiguity exhibited by your example. I suspect that this is because WP:YEAR presumes that this style of date is also compliant with WP:MONTH. I have seen plenty of cases where these kind of dates are YYYY–MM (I know this because often a citation's |url= contains some form to YYYY MM DD type of information that matches the content of |date= / |year=.)

In your example, the title page and the table of contents imply to me that volume XXI covers the period 1900–1901. Looking at the title page of your example, one of the dates that appears most correct for the citation would seem to be the 1903 printing date. This table of contents page would seem to indicate that the presentation of the miner's lamp paper occurred on 13 April 1903. I would have cited the work this way:

{{cite book |editor-last=Brown |editor-first=M. Walton |last=Wood |first=W.O. |date=13 April 1901 |publicationdate=1903 |article=The Sussmann electric miners lamp |title=Transactions of the Institution of Mining Engineers |url=//archive.org/stream/miningengineer12goog#page/n232 |volume=XXI – 1900–1901 |pages=189–197 |location=Newcastle-upon-Tyne |publisher=Institution of Mining Engineers |via=[[Internet Archive]]}}

Wood, W.O. (13 April 1901). "The Sussmann electric miners lamp". In Brown, M. Walton (ed.). Transactions of the Institution of Mining Engineers. Vol. XXI – 1900–1901. Newcastle-upon-Tyne: Institution of Mining Engineers (published 1903). pp. 189–197 – via Internet Archive. {{cite book}}: Unknown parameter |publicationdate= ignored (|publication-date= suggested) (help)

With regard to simply dropping in a tag and awaiting a human: that is the purpose of the CS1 error messages and accompanying categories. Except for a few dedicated editors who make a point of fixing such errors, it seems that most editors ignore the error messages that are visible. This is why bots like BattyBot are so valuable; the bots will do the work that human editors are disinclined to do.

—Trappist the monk (talk) 16:36, 1 January 2014 (UTC)

Agreed with nearly all your points, and thanks for the legwork on the citation, I shall shamelessly steal it! Bots are useful, but as with all software are limited to what can reasonably be programmed into them. Software that can always handle all difficult boundary cases consumes so much effort to not be worth the return. In the present case is it actually so much of a problem if this particular form of ambiguous date is left as ambiguous? I would suggest better ambiguous than clearly wrong. Martin of Sheffield (talk) 19:30, 1 January 2014 (UTC)

I think that BattyBot's code could be adjusted to look for and fix YYYY-XX date formatting that was clearly not a year range. A regex like "[12]\d[2-9]\d-\d\d" would exclude years in the first two decades of a century (e.g. 1800-1819, 1900-1919, etc.) from being subject to modification by the code that looks for YYYY-MM formatting. You could probably get more specific to exclude just 1900-1911 from the year value, but I am not enough of a regex wizard to know how to do that. – Jonesey95 (talk) 21:33, 1 January 2014 (UTC)

I have stopped the bot temporarily to institute this change. GoingBatty (talk) 01:06, 2 January 2014 (UTC)

Code updated and posted at User:BattyBot/CS1 errors-dates, and the bot is back online. Thanks! GoingBatty (talk) 23:59, 2 January 2014 (UTC)

Foreign months and seasons

If one is citing a foreign article that has a date in the title, I presume that this change of concatenating the month to year means that while in the past month=foreign month name |year=2005 worked because the parser for {{harv}} ignored the month parameter month dates in foreign languages will now flag an error under date? It seems to me that makes more work for people altering articles to use citation templates because they will now have to translate months seasons etc when moving the information into a template, before they could simply place the untranslated month into the month parameter, leaving a note asking someone else to do the translation at a later date. -- PBS (talk) 10:59, 24 January 2014 (UTC)

Dates of refs to foreign language sources should always have the months translated. The month names in French are more-or-less the same as those in English; some, like Septembre, are so similar that the English speaker who has never seen written French might simply consider it a typo, since "e" and "r" are so close together on the keyboard. But how many people know what Ionawr means, what language it's in, or even that it's a month at all? --Redrose64 (talk) 13:40, 24 January 2014 (UTC)

The current CS1 module code concatenates |month= and |year= into |date= for output purposes if |date= does not exist. The module can use the year from that new |date= to generate a harv ref. A foreign-language month will produce an error and fail to output a year to the harv ref whether that month is in the |date= parameter or in |month=. Examples:

The error message is helpful. It alerts editors that there is a problem with the citation that needs to be fixed. If you don't know the English translation of the month, you can put the month and year into |date=, then add |year=, as in the middle example above.

Monkbot and BattyBot's task 25 have fixed many of these errors by merging |month= with |year= and by translating foreign-language months, respectively. If you see a foreign-language month that you don't know how to fix, feel free to post it here and we will work on it. – Jonesey95 (talk) 23:22, 24 January 2014 (UTC)

When month was a separate parameter using a month that was not recognised by date was not a problem as the year parameter still worked with Harv temples. What is the advantage of moving away from having a month parameter available of such cases so that the date can be put in by one editor and translated later by another editor who can translate them? -- PBS (talk) 18:18, 31 January 2014 (UTC)

Any answers? -- PBS (talk) 16:34, 5 March 2014 (UTC)

I believe that your questions above have been answered in detail above. Non-English months are an error that needs to be fixed; they are flagged as date errors and could probably be dealt with quickly by someone who knows how to do a database dump and post a list of the affected articles.

There is a workaround for your specific concern in the middle citation example above.

If you know of foreign-language months that need to be fixed in actual articles, please post them here and helpful gnomes will attempt to fix them for you. – Jonesey95 (talk) 18:15, 5 March 2014 (UTC)

Year ranges

Citation comparison

Wikitext	{{citation|authorlink=Li Fang-Kuei|first=Fang-Kuei|journal=Monumenta Serica|last=Li|others=Gilbert L. Mattos (trans.)|pages=219–287|postscript=.|sandbox=yes|title=Studies on Archaic Chinese|volume=31|year=1974–75}}
Live	Li, Fang-Kuei (1974–75), "Studies on Archaic Chinese", Monumenta Serica, 31, Gilbert L. Mattos (trans.): 219–287. {{citation}}: Unknown parameter |sandbox= ignored (help)
Sandbox	Li, Fang-Kuei (1974–75), "Studies on Archaic Chinese", Monumenta Serica, 31, Gilbert L. Mattos (trans.): 219–287. {{citation}}: Unknown parameter |sandbox= ignored (help)
Data validation fails, generating a CITEREF without the years.

Is there a plan to make year ranges work again? Kanguole 15:38, 27 February 2014 (UTC)

Coauthors

See Module talk:Citation/CS1/Archive 9#Coauthors No evidence has been given that there is a consensus to deprecate coauthors. -- PBS (talk) 17:20, 22 February 2014 (UTC)

As I do not think that this parameter is has "become obsolete or unnecessary." (for the reasons I have detailed before). I have made this edit. -- PBS (talk) 17:26, 22 February 2014 (UTC)

Module talk:Citation/CS1/Archive 9#Coauthors. TLDR. You want to start a new discussion, please reprise the rationale. --  Gadget850 ^talk 18:31, 22 February 2014 (UTC)

See my next comment below -- PBS (talk) 11:36, 23 February 2014 (UTC)

Because |coauthor= and |coauthors= are currently being treated as deprecated parameters, removing the help text about them does a disservice to editors who follow the (help) link. At all times, the help text should as best as possible, describe what has caused the error message and not leave editors guessing. For this reason, I shall revert the change to Help:CS1 errors#deprecated params.

There are several technical reasons why |coauthor= and |coauthors= have been deprecated, among them are these:

• |coauthor= and |coauthors= are not included in the COinS metadata nor included in the CITEREF ID:
  • {{cite book |author=Author |coauthor=Coauthor1, Coauthor2 |title=Title |ref=harv}}

  '"`UNIQ--templatestyles-000001F2-QINU`"'<cite id="CITEREFAuthor" class="citation book cs1">Author. ''Title''.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Title&rft.au=Author&rfr_id=info%3Asid%2Fwiki.riteme.site%3AModule+talk%3ACitation%2FCS1%2FArchive+9" class="Z3988"></span> <span class="cs1-visible-error citation-comment"><code class="cs1-code">{{[[Template:cite book|cite book]]}}</code>: </span><span class="cs1-visible-error citation-comment"><code class="cs1-code">&#124;author=</code> has generic name ([[Help:CS1 errors#generic_name|help]])</span>; <span class="cs1-visible-error citation-comment">Invalid <code class="cs1-code">&#124;ref=harv</code> ([[Help:CS1 errors#invalid_param_val|help]])</span>; <span class="cs1-visible-error citation-comment">Unknown parameter <code class="cs1-code">&#124;coauthor=</code> ignored (<code class="cs1-code">&#124;author=</code> suggested) ([[Help:CS1 errors#parameter_ignored_suggest|help]])</span>

• |coauthor= and |coauthors= require |author= or |last= in order to be displayed;
  • {{cite book |coauthor=Coauthor1, coauthor2 |title=Title}}

  Title. {{cite book}}: Unknown parameter |coauthor= ignored (|author= suggested) (help)

• |coauthor= and |coauthors= do not play nicely with |displayauthors=:
  • {{cite book |author1=Author1 |author2=Author2 |displayauthors=1 |coauthor=Coauthor1, Coauthor2 |title=Author1, Author2, Coauthors1 and 2 with displayauthors=1}}

  Author1; Author2. Author1, Author2, Coauthors1 and 2 with displayauthors=1. {{cite book}}: |author1= has generic name (help); Unknown parameter |coauthor= ignored (|author= suggested) (help); Unknown parameter |displayauthors= ignored (|display-authors= suggested) (help)CS1 maint: numeric names: authors list (link)

  • {{cite book |author1=Author1 |author2=Author2 |displayauthors=1 |author3=Coauthor1 |author4=Coauthor2 |title=Author1, Author2, Author3, Author4 with displayauthors=1}}

  Author1; Author2; Coauthor1; Coauthor2. Author1, Author2, Author3, Author4 with displayauthors=1. {{cite book}}: |author1= has generic name (help); Unknown parameter |displayauthors= ignored (|display-authors= suggested) (help)CS1 maint: numeric names: authors list (link)

• |coauthor= and |coauthors= do not play nicely with |lastauthoramp:
  • {{cite book |author1=Author1 |author2=Author2 |lastauthoramp=yes |coauthor=Coauthor1, Coauthor2 |title=Author1, Author2, Coauthors1 and 2 with lastauthoramp=yes}}

  Author1; Author2. Author1, Author2, Coauthors1 and 2 with lastauthoramp=yes. {{cite book}}: |author1= has generic name (help); Unknown parameter |coauthor= ignored (|author= suggested) (help); Unknown parameter |lastauthoramp= ignored (|name-list-style= suggested) (help)CS1 maint: numeric names: authors list (link)

  • {{cite book |author1=Author1 |author2=Author2 |lastauthoramp=yes |author3=Coauthor1 |author4=Coauthor2 |title=Author1, Author2, Author3, Author4 with lastauthoramp=yes}}*:Author1; Author2; Coauthor1; Coauthor2. Author1, Author2, Author3, Author4 with lastauthoramp=yes. {{cite book}}: |author1= has generic name (help); Unknown parameter |lastauthoramp= ignored (|name-list-style= suggested) (help)CS1 maint: numeric names: authors list (link)

The above ignores inconsistencies in style that are often introduced by editors who have used |coauthor= and |coauthors=. Part of the purpose of CS1 is to render citations in a consistent style which it can't do when free-form parameters like |coauthor= and |coauthors= are mixed with fixed-form parameters |author= and the |last= / |first= pairs.

I am sure that it is possible to make |coauthor= and |coauthors= work for all of these things, but I see no need to complicate the code when simpler and more reliable methods for handling author information are readily available and already work properly.

—Trappist the monk (talk) 19:39, 22 February 2014 (UTC)

@Trappist the monk: your write "At all times, the help text should as best as possible, describe what has caused the error message and not leave editors guessing. For this reason, I shall revert the change to Help:CS1 errors#deprecated params." The reason why I reverted is because if a few people add coauthors in the next few days when you run your script they will be changed and it will be easy to do. If however the advise remains in place and editors treat then as errors running batch jobs to remove coauthors then it becomes difficult to revert the changes. If someone alters coauthors to author2 or whatever and breaks {{harv}} links then such changes will be breaking internal links that work at the moment. Can you show me a section (with more than a handful of editors discussing it) where there is a consensus to deprecate this useful parameter? If not then the revert that you made either needs to be reverted until such a consensus is established or some indication needs to be made in the section that people should not take this advise as a reason to change any articles while it is under discussion.

@Trappist the monk: I an aware of all of that and I think that the utility of coauthors when coupled with the us of {{harv}} outweighs the advantages. I gave examples in Module talk:Citation/CS1/Archive 9#Update to the live CS1 module week of 2013-11-03 and I can reproduce similar ones if you or Gadget850 think it necessary to explain why I think that coauthors (and coeditors) are too useful to be depreciated. In the mean time: I think that coauthors should be not be deprecated -- or , and I would appreciate it if someone would indicate where the consensus was formed that it should be deprecated. -- PBS (talk) 11:36, 23 February 2014 (UTC)

@Trappist the monk: Unless you can show a consensus for removing coauthors parameter I am going to reinstate this edit. It seems to me that changes like this ought to go to an RfC in a noticeable place (for example the talk page of citations guideline, or village pump). -- PBS (talk) 16:54, 25 February 2014 (UTC)

What I said before still applies: Removing help text that addresses the reasons for a current error message does a disservice to editors or readers who follow the (help) link. Please don't take something away from them because you are angry with me.

–Trappist the monk (talk) 18:18, 25 February 2014 (UTC)

I am not angry, I am concerned that you are making edits such as this one where you explain in the edit history that "Fix CS1 deprecated coauthor parameter errors using AWB" yet and you are willing to revert edits to that section even though you have not shown that there is a consensus to depreciate the parameter coauthors. -- PBS (talk) 17:18, 1 March 2014 (UTC)

If someone asked me today for my opinion, I would support deprecation.

• |coauthor= doesn't appear in the COinS metadata. Just yesterday, I was reviewing a paper in a upper-level college English class where the student left out several coauthors and listed only the first author; that's certainly not an acceptable practice. Likewise, we should always give proper credit to all authors of a text, yet by omitting them from COinS, we don't fully credit them to both human and automated users.
• We have the full range of authorn/firstn/lastn parameters to individually list each author of a text, and by doing so, we ensure that the template uses the same semicolon separator between them consistently.
• If there are issues with {{harv}}, then that template needs to be updated to deal with the deprecation. The failure of one template to interact with another should not preclude us from improving this template family.

For the above reasons given by Trappist that I haven't duplicated here, I say deprecate and move forward. Imzadi 1979 → 20:06, 1 March 2014 (UTC)

I have to agree with Trappist and Imzadi1979 that we need to move forward and remove these parameters as they are confusing and misused in many cases. The author/first/last fields can cover all that coauthor is trying to do. Keith D (talk) 20:20, 1 March 2014 (UTC)

"|coauthor= doesn't appear in the COinS metadata." This is the tail wagging the dog why does it not appear in the "COinS metadata" who made that decision? Just yesterday, I was reviewing a paper in a upper-level college English class where the student left out several coauthors what has that got to do with this parameter? If there are issues with {{harv}}, then that template needs to be updated to deal with the deprecation, where is the conensus to depreciate it? The point is that coauthors make it easier to use {{harv}}, than other suggested solutions make it more complicated.

"we need to move forward and remove these parameters" Your sound like a Europhile and their instance on using metaphors for ever greater union "a step forward", "left behind in the station" etc. How is it a move forward if it makes using templates more complicated. The major problem with citation templates is that many people dislike them and persuading them to use them is difficult, making their usage more complicated is not "mov[ing] forward". Again I ask where is the consensus to deprecate coauthors? -- PBS (talk) 10:28, 2 March 2014 (UTC)

COinS stores each author name in the '&rft.au' key. We merge each 'last' and 'first' field to create the '&rft.au' key. There is no provision in COinS for a key to hold multiple authors. I have an overview of how we use COinS in the citation templates at Module talk:Citation/CS1/COinS. --  Gadget850 ^talk 13:32, 2 March 2014 (UTC)

And here is a live example:

• Rowe, Jason F.; Bryson, Stephen T.; Marcy, Geoffrey W.; Lissauer, Jack J.; Jontof-Hutter, Daniel; Mullally, Fergal; Gilliland, Ronald L.; Issacson, Howard; Ford, Eric; Howell, Steve B.; Borucki, William J.; Haas, Michael; Huber, Daniel; Steffen, Jason H.; Thompson, Susan E.; Quintana, Elisa; Barclay, Thomas; Still, Martin; Fortney, Jonathan; Gautier III, T. N.; Hunter, Roger; Caldwell, Douglas A.; Devore, David R. Ciardi Edna; Cochran, William; Jenkins, Jon; Agol, Eric; Carter, Joshua A.; Geary, John (February 26, 2014). "Validation of Kepler's Multiple Planet Candidates. III: Light Curve Analysis & Announcement of Hundreds of New Multi-planet Systems" (PDF). astro-ph.EP. Ithaca, New York: Cornell University Library. arXiv:1402.6534v1. Retrieved March 2, 2014. {{cite journal}}: External link in |journal= (help)

If you stuff the last 27 authors into 'coauthors', then the do not get injected into the COinS metadata. If we modify the module to inject 'coauthors' into a '&rft.au' key, then when the metadata is extracted, those 27 authors will be read as on author, creating a bibliographic mess. --  Gadget850 ^talk 13:46, 2 March 2014 (UTC)

For the reasons just mentioned by Editor Gadget850, it would seem that |authors=, an alias of |last=, |last1=, and |author=, should also be deprecated. Because the parameter name is plural, that says to editors, it's ok to stuff a bunch of names into |authors= in the same manner that editors stuff a bunch of names into |coauthor= and |coauthors=. And this then produces junk COinS metadata.

—Trappist the monk (talk) 14:22, 2 March 2014 (UTC)

What is junk is COinS metadata. Who uses this stuff anyway? What is very annoying are "first1, last1, first2, last2, ..." or "author1, author2, ..." parameters. If there are many authors, this can lead to very long citation templates that overwhelm the rest of raw wiki text. If COinS metadata is really that important, Module:Citation/CS1 could easily be modified to parse the author field contents to separate the authors. Depreciation Deprecation of the author parameter is a really bad idea that I strongly oppose. Boghog (talk) 14:56, 2 March 2014 (UTC)

The |coauthors= data is not output to COinS mainly because it is not in a consistent format - essentially, it's free-form text and so could contain anything, with the risk of metadata pollution.

It is a fallacy to state that coauthors make it easier to use {{harv}}: if anything, the converse is true. I have explained this before.

Please note that the term is "deprecate", not "depreciate". It's not a US/GB spelling difference - it's a different field, and a different concept - one is computing, the other accountancy. --Redrose64 (talk) 15:10, 2 March 2014 (UTC)

A frequently used author format is the Vancouver system where the authors are separated by a comma. It should be straight forward to scan the author field string and if it contains commas and no semicolons, split the string into separate authors.

I clearly am aware of the difference between deprecate and depreciate but I sometimes make typos. Sorry. Boghog (talk) 15:22, 2 March 2014 (UTC)

The problem with having all the names grouped into one parameter is splitting them back out, particularly if you need to determine programmatically where the last name/first name split is located. If names are allowed to be free-form in a particular parameter, just splitting them into individuals without a known inter-person separating character is difficult. Yes, most editors will use comma separation, or semicolon separation, but some will not. Some will write it "John Doe, Howard Issacson" others will write ""Doe, John Issacson, Howard", yet others will have "John Doe Howard Issacson", etc.

If you are also attempting to split the names into first/last: Given the worldwide variance in names it is effectively impossible to be 100% accurate in spitting first name/last name without human verification. You can do a good job that is right most of the time, but without knowing the heritage of any particular person one has to, effectively, guess. Even if you do know the heritage it is still easy to get it wrong on complex names, or one where the person's ancestor just decided to be different from the mainstream. Choosing to do this programmatically could also significantly increase code complexity depending on the limitations selected. Further, without some way for the editor to override the automatic determination you will always have people who are dissatisfied with how it is done. Keep in mind that you have to programmatically deal with last names like von Neumann, or full names such as José Carlos de Almeida whose last name might be "Carlos de Almeida", "de Almeida", or "Almeida" depending on his heritage ("Almeida" in this case).

We could then tell editors: OK. You can use a single parameter, but the string has to be in the format of: "Last, Fist M.; Last, First M.;...". But then what about "John Franks, Jr.". That's how the person happens to use their name, with the comma. Some editors are going to want to put that as "Franks, John Jr." and some as "Franks, Jr., John", and some as "Franks, John, Jr.". Alternately, from the example above: "T. N. Gautier III" which is in the metadata on the originating page as "Gautier III, T. N.". Assuming we need to break names into first/last, we could enable the use of a single grouped parameter, but would need to enforce strict formatting requirements.

Strict formatting requirements would be possible if the errors are displayed to the editor within all edit boxes and/or a bot deposits error reports for new errors onto the editor's talk page similar to what BracketBot does for broken syntax. Most editors are willing to accommodate requirements, but they need to know that the requirements exist and be reminded when they enter something that results in an error. Currently, errors are mostly displayed in the reference section of the page. This is a location which is invisible to editors when editing a section of the page. It is possible for the editor to make the reference section visible by temporarily adding a {{reflist}} tag to the section and previewing, but that is an extra step which most editors probably do not perform. Actually, a bot like CitationBot ReferenceBot exists would be quite helpful even without any other changes contemplated here. I know that I want to be informed when a citation I enter has an error. I expect that many other editors would appreciate being informed in such situations.

I agree that the |first1=, |last1=... parameters can overwhelm the rest of the wiki text. The "first1" and "last1" are nicely human readable, but lead to a large number of characters used where it could be represented with fewer. We could consider supporting a shorter alias, perhaps |f1= and |l1=? or |af1=, |al1= and |ef1= and |el1=? Those would consume 8, or 10 characters per name instead of the 15 currently used. Those numbers are compared to the minimum of 2 that would be needed for ";Last,First". To an extent, there is going to be an impact on the readability of the wiki text anytime there are a large number of authors. The above example with 28 authors is going to have an impact even if all of them are written in one parameter. The impact can be considerably less than it is currently, but it is still going to be there.

Yes, deprecated and depreciated are different. But if we deprecate a parameter, its value has certainly depreciated. Given that the words differ by only one character it is easy to mistype, misread, or misstate them. I recall making that typo/mistake multiple times myself. On the other hand, when I make a mistake I appreciate being corrected as I value accuracy. I know the comment wasn't directed towards me, but I had happened to notice a case of my misuse of the terms a short while ago when an old thread was archived from this page and a case last night in some code where I had mistyped an attribute name causing a potential bug. Thus, the issue happens to be on my mind 8-) and I am deprecating (multiple senses) my inaccurate use of depreciate.

As to deprecating |authors=, |coauthors=, and |editors=? (not previously mentioned in this discussion): If we do not support having multiple names in these parameters, then we should deprecate them. The parameter names being plural definitely states to editors that multiple names in these fields is the correct use. Having the |editors= parameter, but not the plural versions of authors and coauthors is a bad idea. Wikipedia editors will see the |editors= parameter and go looking for, or just try to use, the |authors= and |coauthors= parameters. At this time, I am not specifically voicing an opinion one way or the other on the deprecation of these parameters due to not knowing the impact on article pages or use within COinS (or the impact for supporting currently non-supported translations into COinS). I am voicing an opinion that whatever we end up with should be consistent throughout CS1, and across the various parameters to the templates. Ideally, it should be easy to use for editors and intuitively understandable to them. — Makyen (talk) 23:05, 2 March 2014 (UTC)

Makyen's comment is based on the idea that an author or editor must be an individual, and therefore, must have a first and last name. But CS1 states:

Editors should use an |author= organizational citation when the cited source, such as a committee report, specifically names an official body or a sub-unit of the publisher as the collective author of the work, e.g. |author=Commission on Headphone Safety or |author=Rules Sub-committee.

Thus |author= and |editor= cannot be deprecated.— Preceding unsigned comment added by Jc3s5h (talk • contribs) 00:36, 3 March 2014 (UTC)

You may be talking at cross purposes; if I understand Mayken's comment correctly, he proposed deprecating the plural forms ("authors" and "editors"), not the singular ("author" and "editor"). Choess (talk) 00:57, 3 March 2014 (UTC)

Section break

Just so we're all clear here: I am the editor who suggested that we should consider deprecating |authors= – the plural, not the singular. I think that we should expand that to include |editors= (again only the plural) and the numbered versions of those two: |authorsn= and |editorsn=. Why do we have numbered versions of the plural parameters anyway?

And, while we're talking about author-type parameters, do we really need |given=, |givenn=, |surname=, |surnamen=, |EditorGiven=, |EditorGivenn=, |EditorSurname=, and |EditorSurnamen=? I don't think that I've ever seen any of these in use. This set of parameters also lacks the -link and -mask parameters that accompany the |author= and |editor= parameters.

—Trappist the monk (talk) 01:27, 3 March 2014 (UTC)

There is a problem with names: many cultures have the family name as the first name, and index lists according to the first name. But just having |surname= and |given= with no intelligent system to deal with the problem doesn't help. Jc3s5h (talk) 02:23, 3 March 2014 (UTC)

@Jc3s5h: I clearly, to an extent, miscommunicated. As others mentioned, I did not intend to imply any desire to deprecate the singular form of either |author= or |editor= and at that time did not discuss |coauthor=. If deprecating either |author= or |editor= was suggested by someone else, I would certainly oppose it for the reasons which you mentioned above. Those parameters, and the numbered versions, are all used for entities which are not individuals and should remain available to do so. Perhaps, I should have added a sentence to my splitting example which mentioned non-individuals. I was already at wall-of-text size and didn't want to go there. However, it is something that does makes splitting from one larger free format grouped list even harder.

I do support deprecating |coauthor=. Given the numbered versions of |author=, |coauthor= appears superfluous. From the old archived discussion, there appears to be a use case where |coauthor= is being used to hide the additional authors from showing up in short-form citations. While I did not go through the old discussion in great detail, the ability to accomplish the goals desired with the use of |coauthor= appeared available without needing to use |coauthor=. The argument was put forward that not using it was harder. I did not see that, but could spend more time specifically looking for that issue in the discussion. My counter argument to that is that having the |coauthor= parameter is confusing to editors in general, rather than in the specific case. From the point of view of most editors, the parameter duplicates functionality available from the |author#= parameters. I believe keeping |coauthor= retains the confusion on the part of a larger set of editors than is justified by what appears to be a relatively small inconvenience, to a smaller set of editors who can accomplish their desired functionality in a different manner.

I would suggest tabling the |surname=/|given= discussion, or at least breaking it into a subheading. A large portion of the world thinks of names as |surname= and given-name rather than first/last. The use of neither set of the current parameters fully solves the issue. With given/surname one still needs to know which to display first, or if "surname, given-name" is correct, or is it "surname given-name"? With first/last one still needs sorting information. Without more information than is supplied just in these sets of parameters there are a significant number of cases that are not handled "correctly".

As to the |surname=/|given= (and the Editor versions) not having associated -link and -mask parameters. Assuming that the |surname=/|given= (etc) parameters are just aliases to first/last (etc), then they have just as much an association with the author/editor -mask and -link parameters as the first/last set does.

As I mentioned, for the plural versions: |authors=, |coauthors=, and |editors= I support either A) deprecating them, or B) our supporting multiple names (including non-individual entities) being contained within them. My impression is that truly supporting multiple names in those parameters is not a headache currently desired, and could only be reasonably done by adopting, and enforcing, a strict format for the names contained in the strings (e.g. something like "Doe, John R.;Gautier III, T. N.;U.S. Congressional Subcommittee on Agriculture", in other words a format that forces the editor to supply the first/last information, and multiple other issues which I am not going to begin to get into until and unless there appears to be a desire to support such.). I feel these parameters should not be retained without supporting multiple names because the plural versions inherently imply to a naive editor that they are intended to hold multiple names.

It appears my comment that it would be nice to have a bot to tell us about having made citation errors was a bit erroneous. There is such a bot: ReferenceBot. It appears that the mistakes I make in citations are not ones for which the bot checks, or I happened to see them and fix them prior to the bot getting around to telling me about them. It would still be nice to be able to routinely see what the citations look like (without having to temporarily add a {{reflist}}) when editing a page section. — Makyen (talk) 05:24, 3 March 2014 (UTC)

All this discussion is based on the assumption that generating COinS metadata is important. Could someone indicate why this is important? I understand why it is theoretically useful, but does anyone actually use this data? I have never heard an end user complain about corrupt metadata. I also would suspect that the number of Wikipedia editors far exceed the consumers of COinS metadata. Having more compact citation templates imbedded in the raw text of Wikipedia articles that avoids the clutter of "first1, last1, first2, last2, ..." parameters is a distinct advantage.

For a long time, the "author" and not "authors" parameter was (and still is) the recommended way to store multiple authors in a single field using the Vancouver system author format. This format is quite often used when there is a pmid. In these cases, the only meta data one needs is the pmid. The rest of the data can be downloaded from PubMed which is a more reliable source of bibliographic information than Wikipedia.

Finally no one has complained (except perhaps me ;-) that we have a free format date field that enforces a strict format. I see no reason why the same cannot be done with the author field. Boghog (talk) 06:40, 3 March 2014 (UTC)

Generating COinS metadata is not only important; it is used. For example, it allows people who use tools such as Zotero to extract the details about a cited work into such tools, and to add them to reading lists, perform library lookups or cite them in their own work. I use Zotero to transfer such details from one article to another, and keep a library of the works I've cited repeatedly. As an end user, I often complain, and more importantly work to fix, corrupt metadata. There has long been consensus to use COinS in Wikipedia. Regarding the wider issue; see data granularity. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:15, 3 March 2014 (UTC)

Generating COinS metadata is only important if it is used. My question is how often it is used. Are the number of meta data users anywhere close to number of Wikipedia editors? Boghog (talk) 14:20, 3 March 2014 (UTC)

I've already given an affirmative answer to your question about whether COinS is used. I'm not clear how your question about the relative numbers of editors is relevant; we write Wikipedia for our readers, not editors. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:34, 3 March 2014 (UTC)

Meta data is not useful in the abstract. It is only useful if there are users. Furthermore the relative number of meta data users and editors is highly relevant. If there are only a few meta data users and the extra clutter produced by parameters required to produce meta data is negatively impacting the productivity of editors, this will lead to less useful content for readers. Also to reiterate, if meta data is in fact that important, it should be possible to parse the author parameter to extract the individual authors. Boghog (talk) 15:18, 3 March 2014 (UTC)

@Gadget850, I think you missed a point I made. The debate here is not between how much information can be extracted but whether the interface is easy to use. For those who do not come from a computer science background (or have no reason to write programs to help complete work tasks) a function call with a set of arguments (whoops notice the jargon creeping in) template with multi optional named parameters is daunting. Many editors refuse to use citation templates and have a guideline that sides with them over consensus of whether to use them or not (WP:CITEVAR -- because the first citations added to articles tend not to use citation templates). So anything that makes using citation templates more difficult to use should be discouraged, as more metadata will be lost if articles do not use any citation templates, than the rare problems with citations that contain 27 authors.

As I see it coauthors has been around for years, and it makes certain tasks easier to do, particularly linking a {{harv}} template to citation templates. Let us use an example that I used before. I did not expect this section to grow as large as it has so I guess it is time for a recap.

With coauthors it is easy to set up an example where one wishes to ignore the authors included in coauthors.

example last=Finch, coauthors=English Court of Chancery

A1 fact (Finch 1724, p. 404) References {{Citation |last=Finch |first=Heneage (Earl of Nottingham) |coauthors=English Court of Chancery |year=1724 |editor-first=William |editor-last=Nelson |title=Reports of cases decreed in the High Court of Chancery: during the time Sir Heneage Finch, afterwards earl of Nottingham, was lord chancellor. (1673-1680) |publisher=R. Gosling}} Finch, Heneage (Earl of Nottingham) (1724), Nelson, William (ed.), Reports of cases decreed in the High Court of Chancery: during the time Sir Heneage Finch, afterwards earl of Nottingham, was lord chancellor. (1673-1680), R. Gosling {{citation}}: Unknown parameter |coauthors= ignored (|author= suggested) (help)

Here is an example that was suggested as a solution using the parameter displayauthors but as can be seen displayauthors=1 does not have the desired affect instead it inverts what coauthors does (hiding authors in the long reference and requiring them in the short reference).

example: last=Finch, author2=English Court of Chancery

A1 fact (Finch 1725, p. 404)( does not link) A2 fact (Finch & English Court of Chancery 1725, p. 404) (links) References {{Citation |last=Finch |first=Heneage (Earl of Nottingham) |author2=English Court of Chancery |displayauthors=1 |year=1725 |editor-first=William |editor-last=Nelson |title=Reports of cases decreed in the High Court of Chancery: during the time Sir Heneage Finch, afterwards earl of Nottingham, was lord chancellor. (1673-1680) |publisher=R. Gosling}} Finch, Heneage (Earl of Nottingham); English Court of Chancery (1725), Nelson, William (ed.), Reports of cases decreed in the High Court of Chancery: during the time Sir Heneage Finch, afterwards earl of Nottingham, was lord chancellor. (1673-1680), R. Gosling {{citation}}: Unknown parameter |displayauthors= ignored (|display-authors= suggested) (help)

The use of a second parameter to contain "et all" with italics does not work as expected with {{harv}} because CS1 strips the italics.

Here is an example using coauthors and et al
A long verified sentence with just one author. Notes References {{citation |last1=Anne Author |coauthor=et al |year=3001 |title=Title}} Anne Author (3001), Title {{citation}}: |last1= has generic name (help); Check date values in: |year= (help); Unknown parameter |coauthors= ignored (|author= suggested) (help)

Here is an example to show that italics in et al does not work as expected with 2 parameters
First long verified sentence with italics. Second long verified sentence with no italics. Notes References {{citation |last1=Anne Author |last2=et al |year=3001 |title=Title}} Anne Author; et al. (3001), Title {{citation}}: |last1= has generic name (help); Check date values in: |year= (help); Explicit use of et al. in: |last2= (help)

Also it has problems with the placement of an ampersand between the author and the et al normally one writes "Smith et al" not "Smith & et al". One can not work around the problem with displayauthors=1 because one has to have two parameters and that opens up the problems shown with "English Court of Chancery".

Extended content
First long verified sentence with. Notes References {{citation |last1=Anne Author |year=4001 |displayauthors=1 |title=Title}} Anne Author (4001), Title {{citation}}: |last1= has generic name (help); Check date values in: |year= (help); Unknown parameter |displayauthors= ignored (|display-authors= suggested) (help)

When we revived these examples last time it was suggested that one uses {{harvid}} to circumvent the problems, but that is another level of complexity for people who are already on a steep learning curve which coauthors bypasses. Is there another way to keep it as simple as using coauthors? -- PBS (talk) 18:35, 5 March 2014 (UTC)

You're simply repeating comments that you have put forward before; my replies to those still exist in the same places. --Redrose64 (talk) 19:28, 5 March 2014 (UTC)

• 'authors' and 'coauthors' are deprecated because the original intent was to stuff them with multiple names. When COinS was added years ago, this should have been deprecated then; now we are going though this process.
• Your second example correctly shows how to handle the first example.
• The CS1 templates strip any markup such as bold or italic, but apparently {{sfn}} does not, thus the mismatch between link and anchor.
• "et al." (which includes the period since it is an abbreviation) is not italicized by any of the templates and should not be italicized manually, as it is a well used term in English; see MOS:Ety. There have been one or two discussions on this.
• Please don't use the definition markup ";" for bold— it is a misuse of the markup and renders invalid HTML.
• You can break the double brace markup by placing a singular <nowiki /> tag in between the braces; see Help:Nowiki.

--  Gadget850 ^talk 00:57, 6 March 2014 (UTC)

I disagree on some points eg my second example does not "correctly shows how to handle the first example", as there is no display of "English Court of Chancery 1725" in the long reference. The whole point is that one may well wish to keep the short citation short and not include all the authors of the piece (but want to do so in the full reference). Whether or not it is desirable to include other names such as "English Court of Chancery 1725" in a short citation should remain an editorial choice, and making editors jump through complicated loops to do so is in my opinion not desirable, when coauthors makes it easier to do. -- PBS (talk) 20:52, 6 March 2014 (UTC)

I think I misunderstood. You want to suppress the number of authors in {{harv}} but use all authors in {{citation}}? Then you just need to set |ref= and use {{sfnref}}. Note that in this example, I changed the name to Finch1 so it won't link to the earlier example.

• A1 fact (Finch1 1724, p. 404)
• {{Citation |last=Finch1 |first=Heneage (Earl of Nottingham) |last2=English Court of Chancery |year=1724 |editor-first=William |editor-last=Nelson |title=Reports of cases decreed in the High Court of Chancery: during the time Sir Heneage Finch, afterwards earl of Nottingham, was lord chancellor. (1673-1680) |publisher=R. Gosling |ref={{sfnref|Finch1|1724}}
• Finch1, Heneage (Earl of Nottingham); English Court of Chancery (1724), Nelson, William (ed.), Reports of cases decreed in the High Court of Chancery: during the time Sir Heneage Finch, afterwards earl of Nottingham, was lord chancellor. (1673-1680), R. Gosling{{citation}}: CS1 maint: numeric names: authors list (link)

--  Gadget850 ^talk 21:44, 6 March 2014 (UTC)

Yes one can use the parameter harv to set it (and I often do), but that is a whole level of complexity that is not needed in this case if coauthors parameter is used. As I said earlier there are many editors who do not like to use citation templates and the more complicated the interface the more daunting it is for those on the margin who might otherwise be persuaded that the benefits of using citation templates out-ways the learning curve. If it is made too steep they are less likely to be convinced. -- PBS (talk) 07:57, 7 March 2014 (UTC)

What if we added |ref=first to use only the first name in the anchor? --  Gadget850 ^talk 17:20, 7 March 2014 (UTC)

If that kind of solution is to be proposed, perhaps a better name is |ref=harvn where n is a number 1, 2, or 3 that tells CS1 how many names to include in CITEREF. If there are less than n names in the citation, CS1 uses as many as are available.

—Trappist the monk (talk) 18:33, 7 March 2014 (UTC)

That is a better solution. --  Gadget850 ^talk 19:09, 7 March 2014 (UTC)

It seems to me that we are discussing specifics when the question I posed in the older thread and that was implicitly asked at the start of this thread is where is the consensus to deprecate coauthors? As no one has been able to point to an RfC or similar advertised discussion, I think it can be taken that there has been no such consensus, and until such a consensus is shown I do not think that coauthors should be depreciated. I think it is up to those who wish to change the interface to initiate such an RfC in a place such as the talk page of WP:CITE or at village pump with a balanced introduction of the advantages and disadvantages of deprecation, so that other disinterested editors can consider whether such a deprecation is to the benefit of the project -- PBS (talk) 07:57, 7 March 2014 (UTC)

As apparently there was never a consensus to depreciate coauthors, and it is now being used in such a way that modifications to citations that use it that it is breaking links between short and long citations . It is time to change the wording in Help:CS1 errors until such time as a well publicised RfC shows a consensus for depreciation of parameters such as coauthors. -- PBS (talk) 18:33, 22 March 2014 (UTC)

The error message description text at Help:CS1 errors must always reflect the actual meaning of the error messages as they exist in the present. To do otherwise, does a disservice to editors and readers who follow the help link to the descriptive text. So, no, the wording in Help:CS1 errors should not be changed.

—Trappist the monk (talk) 19:29, 22 March 2014 (UTC)

Then why not remove the error message from the code until such time as an RfC is held and agreement is reached to removed coauthors? There is no rush over these things

The only argument advance above is that the format of coauthors may be a problem. Yet the same problem can still exist if coauthors is removed here are two example:

• "|last=Caley|first=John, Henry Ellis and Bulkeley Bandinel, eds." (was in John de Mowbray, 1st Earl of Nottingham)
• "|last=Loughlin|first=Marie H., Sandra Bell and Patricia Brace, eds." (was in Barnabe Googe)

The editor who used that particular construction has over the last year and a half or so used the first parameter to include second authors and second editors in about 80 different combinations in over 500 articles. In doing this like with coauthors the short citations using the harv templates can link to the long citations using only one name. -- PBS (talk) 11:10, 23 March 2014 (UTC)