Module talk:Citation/CS1/Archive 8

This is an archive of past discussions about Module:Citation. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Archive 5

Archive 6

Archive 7

→

Deprecated day and month

All of the CS1 templates contain a notice that lists these deprecated parameters:

Of these, |access-date= was recognized as a current parameter. I have moved it from the configuration sandbox argument map to the suggestions list. All of the others are recognized as unknown parameters except |day=.

I'm not sure what should be done with it. It's deprecated but is used in the code along with |month= and |year= to assemble a date. CS1 should be consistent. If |day= is deprecated, shouldn't |month= also be deprecated; both in favor of |date=?

—Trappist the monk (talk) 15:28, 16 April 2013 (UTC)

Previous discussion: Help talk:Citation Style 1/Archive 1#day. I think we could do away with |year= as well. When the templates were initially developed, #time function would give spurious output if you tried to process a year only as a date if it looked like a time— that was fixed in MediaWiki some time ago. -- Gadget850 (Ed)^talk 15:42, 16 April 2013 (UTC)

Parameter "month=" is for journals and "day=" completes a date: Both of those parameters have logical uses, and rejecting "day=" would just frustrate the year/month/day idiom for dates. Also, remember how "year=1995b" will override the year in "date=" to set "1995b" into anchor text for the Harvard referencing. -Wikid77 (talk) 15:46, 16 April 2013 (UTC)
Anything that goes in the date field is displayed as is. The key is in how the year is extracted to use in the anchor. All of these correctly extract the year:
- Drucker (2013). Book. {{cite book}}: Invalid |ref=harv (help)
- Drucker (May 2013). Book. {{cite book}}: Invalid |ref=harv (help)
- Drucker (2 May 2013). Book. {{cite book}}: Invalid |ref=harv (help)
- Drucker (May 2, 2013). Book. {{cite book}}: Invalid |ref=harv (help)
- Drucker (2013 2013). Book. {{cite book}}: Check date values in: |date= (help); Invalid |ref=harv (help)

but not these:

Drucker (23 2013). Book. {{cite book}}: Check date values in: |date= (help); Invalid |ref=harv (help)
Drucker (Flubtember 2013). Book. {{cite book}}: Check date values in: |date= (help); Invalid |ref=harv (help)

-- Gadget850 (Ed)^talk 17:00, 16 April 2013 (UTC)

The above list of Drucker cites was, I think, posted by Editor Gadget850.

I looked at {{cite journal}}. There, |month= is an available parameter but it looks like it is always combined with |year= to be used as |date=. Without |year= it is ignored. I am in favor of deprecating |month= and |year=. As an adjunct, I think that CS1 should report an error if |date= is malformed.

—Trappist the monk (talk) 16:33, 16 April 2013 (UTC)

Yes, that was me. And yes, we should do an error check on the date. We should do this one later if we intend to deprecate day, month and year. -- Gadget850 (Ed)^talk 17:00, 16 April 2013 (UTC)

Year and date are not actually handled identically. If both are given, date= is displayed, but year= is mapped in to the CITEREF. Hence:

{{cite journal |last=Drucker |title=My article|journal=My Journal |date=May 12, 2013 | year=2013c | ref=harv}}

Drucker (May 12, 2013). "My article". My Journal. {{cite journal}}: Invalid |ref=harv (help)CS1 maint: date and year (link)

has id="CITEREFDrucker2013c"

This is used by {{sfn}} / {{harv}} to reference works where the same author had more than one publication in a calendar year, thus creating links for Smith 2001a, Smith 2001b, etc. I think it would be hard to remove year without creating problems for usages like this. Dragons flight (talk) 18:10, 16 April 2013 (UTC)

Hmm, problematic, that. |date= and |year= are synonymous in the same way that |author= and |last= are synonymous. As such, both |date= and |year= in the same citation should cause a redundant parameter error. And you can't just set |date=16 April 2013c; it doesn't work, you don't get id="CITEREFDrucker2013c". And besides, it looks ugly, just as citations without |date= look ugly now when editors must set |year=2013c in order to appease the short footnote god (is the god short, or is the footnote short?)

|date= and |year= without |ref=harv → Redundant parameter error

|refyear= without |ref=harv → |refyear= requires |ref=harv

|year= without |date= → |year= deprecated, suggest |date=

A robot could be trained to sift through the articles to upgrade citations with |year= to either |date= or |refyear=.

Eschew inconsistency.

—Trappist the monk (talk) 19:08, 16 April 2013 (UTC)

It would be simpler to keep date and year. Editors who use these styles are accustomed to using date for the visual date and year for the anchor year. Regardless, date now accepts day-month-year, month-year and year with no issues, so day and month can be deprecated. I would not yank support yet. -- Gadget850 (Ed)^talk 19:54, 16 April 2013 (UTC)

That sounds like the we've-always-done-it-this-way-and-if-it-was-good-enough-for-my-grandfather-it's-good-enough-for-me argument. We are at a place where we can and should make changes to consolidate CS1 into a suite of citation tools that will serve well and long – until the next disruptive technology arises.

Yes it would be simpler, but what I've proposed doesn't, to my novice eye (that was a disclaimer), seem much different from what we've already done. We already deal with redundant parameters; we already handle suggested parameter names; with careful inspection, replacing |year= with |refyear= should be relatively painless.

Will there be pushback from the editing community? Could be, but if that occurs, I think that with careful explanation, the reasons will be accepted. Despite bleeding red all over thousands of articles, CS1 and those of you who are creating it, have not earned the undying enmity that might have been expected.

—Trappist the monk (talk) 22:31, 16 April 2013 (UTC)

I was taught the three Es: engineering, education, enforcement. The problem on Wikipedia is that there is no centralized way to do the education part. Once editors start doing something, they tend to keep doing it that way until something slaps them in the face and they have to change their methods (and it is pretty much that way in life). We can do a lot of the enforcement through engineering: error checking and messages is a major method. But, we don't have to change thing just to change them. The current methods work, but can use some improvement. I just don't see the need to change 'year'. If we keep 'date' as the main date and 'year' as either a year or a year descriptor, then we keep backwards compatibility and it is one more thing we do not have to enforce. Frankly, getting rid of 'day' and 'month' would be the bigger issues. We can start by deprecating them in documentation, and I will start that task. -- Gadget850 (Ed)^talk 17:51, 18 April 2013 (UTC)

Here's another of aphorism to go with your three Es: The quick is now, the dirty is forever.

Ok, how about this? Since we already have to extract a year from |date= when |year= is omitted, allow extra text in |date= that can serve as a year disambiguator. Put some restrictions on it: the disambiguator shall be no more than two characters, the first of which must be a letter; it shall directly follow the year portion of the date without intervening spaces so |date=2013cb-04-18 or |date=18 April 2013a6 or |date=April 18, 2013r. The year disambiguator is never displayed but is used with the year value extracted from |date= to create CITEREF.

Because |year= is synonymous with |date=, CS1 reports a redundant parameter error whenever both are used in the same citation. So that legacy citations continue to work, when |year= and |date= are present in the same citation with |ref=, CS1 will use |year= to create CITEREF. This ensures that short-footnote links aren't broken when |year= has a disambiguator. |year= is deprecated but allowed to remain usable – for the time being. Documentation reflects this deprecation.

This still permits us to deprecate |day= and |month=.

—Trappist the monk (talk) 00:20, 19 April 2013 (UTC)

'date' and 'year' are not aliases, they function separately, as expected:

Markup	Renders as
{{cite book \|last=Drucker \|title=Book \|date=May 2, 2013 \|year=2013c \|ref=harv}}	Drucker (May 2, 2013). Book. `{{cite book}}`: Invalid `\|ref=harv` (help)CS1 maint: date and year (link)

If 'date' and 'year' are both defined, then 'date' is shown and the anchor is formed from 'year'. In this example the visual date is May 2, 2013 and the anchor is CITEREFDrucker2013c. -- Gadget850 (Ed)^talk 00:13, 20 April 2013 (UTC)

I must be losing my ability to communicate.

You're right, because of the need for disambiguation, |date= and |year= aren't strictly symmetrical synonyms. We use |year= with |date= to disambiguate citations. When there is no need to disambiguate the citation, there is no need for both so, as is the case with |author= and |last=, CS1 should report a redundant parameter error. Are there any other reasons to use |year= with |date=?

The use of |year= as a citation disambiguator was a necessary response to limitations imposed by the MediaWiki #time function. This is legacy that need not be duplicated or preserved. #time returns an error or strips-off text that isn't part of the date parameter:

{{#time:Y|May 21, 2013c }} → 2013

{{#time:Y|21 May 2013c }} → 2013

{{#time:Y|2013c-05-21 }} → Error: Invalid time.

As an aside, how were citations disambiguated before the CS1 templates started using #time? Were they? Extraction of year from |date= was added to {{citation}} with this edit.

—Trappist the monk (talk) 14:48, 20 April 2013 (UTC)

Up until about a year ago, running a year only through #time:Y would sometimes result in a time of day, not the year, resulting in a time error and generating no year anchor. Thus the need for the separate 'year' parameter.

'year' is used as the year and as an anchor disambiguator. If we want to migrate to 'refyear', then we have to look for a year with an alpha suffix and move that to 'refyear', otherwise, move it to 'date'.

'day' and 'month' can safely be deprecated.

Is there any objection to changing the documentation now to deprecate 'day' and 'month' and to deprecate 'year' except as a disambiguator? This should be noted at Help talk:Citation Style 1. -- Gadget850^talk 12:58, 6 May 2013 (UTC)

But: 'date' does not generate the year anchor if a season is included:

Drucker (Fall 2013). Book. {{cite book}}: Invalid |ref=harv (help)

But it does work if the season is used in 'month':

Drucker (2013). Book. {{cite book}}: Invalid |ref=harv (help); Unknown parameter |month= ignored (help)

-- Gadget850^talk 13:01, 6 May 2013 (UTC)

The |day= parameter has been tracked as deprecated for a long time; and as far as I can tell, it has never been mentioned in Template:Cite book/doc. However, |month= is not deprecated and sees wide use. The reason that the anchor is not correctly generated for |date=Fall 2013 is because the {{#time:}} parser function expects a valid date. --Redrose64 (talk) 13:41, 6 May 2013 (UTC)

No objection to deprecating |day= and |month=. If we do, we should consider creating a deprecated parameters list and flagging those parameters where they occur so that these citations can be fixed.

Deprecate |year= and create new parameter |refyear= as I've described earlier in this thread. I would add one further argument, the meaning of |refyear= is more-or-less unambiguous. Ambiguity is a bad thing.

WP:SEASON seems to frown on the use of seasons for dates. And, if used in a citation, doesn't season actually belong in |issue= or |number= (presuming that and actual numeric issue identifier doesn't already exist – and which should be preferred)?

—Trappist the monk (talk) 14:10, 6 May 2013 (UTC)

I know this has come up before, and I have seen a season used in 'month'. This isn't a reason to not deprecate 'month'. But it does bring up the related issue that an invalid date causes the anchor to fail silently. I'm going to kick that one to the feature request. And even though 'day' has been deprecated for a long time, it is still parsed. -- Gadget850^talk 15:39, 6 May 2013 (UTC)

Looks to me like the value from |date=Fall 2013 is tested to see if it is an integer value between 0 and 2100. If not, something called lang.formatDate evaluates it. If Fall 2013 is not an acceptable date, then the test returns an empty string. This seems somewhat similar to the #time: issue.

—Trappist the monk (talk) 03:33, 7 May 2013 (UTC)

@Trappist: |year= is us\ed far too often to deprecate. As for WP:SEASON: If a publication dates itself by seasons, then that should be how we date it. We should not be putting parts of the date into a volume or issue number unless they really are parts of the volume or issue numbers. —David Eppstein (talk) 15:43, 6 May 2013 (UTC)

[Now why did they go and move the section edit button?] I specifically said deprecated precisely because year has been used a lot. Deprecated is vastly different from deleted. If a periodical solely identifies issues by season and doesn't have equivalent issue-numbers, then there is an issue (pardon the pun). Where there are issue-numbers in conjunction with season, the issue-number should be used in the citation because of WP:SEASON and WP:DATEFORMAT.

—Trappist the monk (talk) 21:27, 6 May 2013 (UTC)

I know the difference between deprecation and deletion and I stand by my statement that year is used far too often even to deprecate. It's useful to have years that don't parse as dates (e.g. for years like 1999a when there are two 1999 pubs by the same author and they need different harv reference links, or for years like 2000–2003, or whatever). And I don't want to encourage editors to change the many articles that use year parameters to something else, for no purpose. The templates are now fast. Having both year and date is not a problem that needs fixing. —David Eppstein (talk) 04:01, 7 May 2013 (UTC)

One of the issues discussed in this thread has been addressed. The 2013-09-02 version of Module:Citation/CS1/sandbox supports seasons in |date=. See Anchors from dates with seasons.

—Trappist the monk (talk) 11:15, 13 September 2013 (UTC)

Tracking use of language icons in language field

Would it be possible to have a method for tracking the usage of language icons in the language field? In particular, to help with correcting like this. Could probably be found by checking if the value passed matches >span class="languageicon". Thanks! Plastikspork _―Œ^(talk) 17:37, 14 September 2013 (UTC)

I don't have an absolutely, positively, for sure answer but I suspect it's possible. In fact, I've just been wondering if allowing templates like {{es icon}} to be specified as a value: |language={{es icon}} might not be a step toward better language support in the CS1 templates. The language icon templates like {{es icon}} call {{Language icon}} which adds the styling and categorization.

The translation of this simple citation: {{cite web |url=http://www.example.com |title=Example |language={{es icon}} }} is:

<span class="citation web">[http://www.example.com "Example"] (in <span class="languageicon" style="font-size:0.95em; font-weight:bold; color:#555;">(Spanish)</span>[[Category:Articles with Spanish-language external links]]).</span>

We might strip the styling and leave the language and its category and, voilà, the citation is categorized – there's a feature request that runs along those lines. Of course that "solution" is a quick and dirty solution and as we all know, the quick is now, the dirty is forever so I'm hesitant to do that.

Setting that aside, how would you want this to work? Detect and add a tracking category? Detect and strip everything but the language and then add tracking category? Show an error message? Something else I haven't thought of?

—Trappist the monk (talk) 20:13, 14 September 2013 (UTC)

Toward better language support

I have added to the sandbox, code that will allow editors to specify |language= using the two-character iso639-1 language codes. This, I think is the first step toward adding better language support to CS1. ~~Still to do with this bit is to add categorization à la {{es icon}}, {{de icon}}, {{fr icon}}, etc.~~

The iso639-1 code is case insensitive:

Cite book comparison
Wikitext	`{{cite book\|language=FR\|sandbox=yes\|title=Title}}`
Live	Title (in French). `{{cite book}}`: Unknown parameter `\|sandbox=` ignored (help)
Sandbox	Title (in French). `{{cite book}}`: Unknown parameter `\|sandbox=` ignored (help)

If the |language= value isn't recognized as an iso639-1 code, CS1 uses the value:

Cite book comparison
Wikitext	`{{cite book\|language=Squeamish\|sandbox=yes\|title=Title}}`
Live	Title (in Squeamish). `{{cite book}}`: Unknown parameter `\|sandbox=` ignored (help)CS1 maint: unrecognized language (link)
Sandbox	Title (in Squeamish). `{{cite book}}`: Unknown parameter `\|sandbox=` ignored (help)CS1 maint: unrecognized language (link)

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

Now categorizes citations in mainspace articles when the iso639-1 code is no 'en' (English). This behavior matches that of the {{xx icon}}/{{language icon}} templates. Pages are placed in the appropriate [[Category:Articles with <language>-language external links]].

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

|template doc demo=true does not exclude articles from subcategories of Category:Articles with incorrect citation syntax

Template:Cite_book says that "|template doc demo=true" is supposed to exclude templates from Category:Articles with incorrect citation syntax, but now that articles are being placed into subcategories, that appears not to work.

For example, Template:Cite rowlett/doc contains that parameter but the template exists in Category:Pages with citations having wikilinks embedded in URL titles, a subcategory of Category:Articles with incorrect citation syntax. According to the documentation, the intent of the parameter is that the template should not be placed in that error category. Did I explain this well enough for someone to make the CS1 module conform to the documentation, if it should indeed be fixed? – Jonesey95 (talk) 13:50, 13 September 2013 (UTC)

I don't think that this is the fault of Module:Citation/CS1. The parameter |template doc demo=true is not being passed to the underlying {{cite web}} by {{cite rowlett}}. Because {{cite web}} isn't getting |template doc demo=true it is correctly categorizing the error that it's seeing.

—Trappist the monk (talk) 14:10, 13 September 2013 (UTC)

So how can this problem be fixed? – Jonesey95 (talk) 23:24, 15 September 2013 (UTC)

You just need to pass the parameter through, like this. --Redrose64 (talk) 23:48, 15 September 2013 (UTC)

Nice. That seems to have done it. The /doc page needed a null edit, after which the article is not in the error category anymore. Thanks to both of you. – Jonesey95 (talk) 14:54, 16 September 2013 (UTC)

Hyphens

There's a function "hyphentodash" in this module that is, I guess, intended to "fix" user input errors where a Wikipedia editor types a page range like 1-25, not knowing that it should be properly formatted as 1–25. Often that's the right thing to do, but not always. I encountered a situation today where the page numbers ranged from 3-1 to 3-25 (that is, pages 1 to 25 of chapter 3 of.... For this type of page number, a hyphen should be used to separate the chapter part of the number from the page part of the number. Trying to format this as part of a {{citation}}, I had a very difficult time getting the hyphens to stay hyphens. I eventually ended up hiding them from the conversion by encoding them as - — is there a better way? Maybe the automagic conversion should recognize that something like |pages=3-1 – 3-25 doesn't look enough like the expected page range format for conversion to be safe? —David Eppstein (talk) 04:57, 19 September 2013 (UTC)

Perhaps note how "at=" or "page=" allows hyphens: It will be difficult to rework the hyphentodash() function to make "clever" become "cleverer" enough to realize "3-1" is not the start of a page range. Any URL in the page number (or volume) will stop hyphen-to-dash filtering. The use of &#45 is one option, but also remember parameter "at=" allows unfiltered page numbers, such as "at=pp. 3-1 to 3-25" and I recommend updating the doc-text to warn users how hyphens will be switched to dashes in "pages=" (not in "page=") but use "at=pp.__" to set the page number to an unfiltered range. Otherwise, this would be a complex problem to reach consensus for more clever detection of valid hyphens. Does a warning in the doc-text to use "at=pp.___" seem acceptable? -Wikid77 11:18, 19 September 2013 (UTC)

Documentation updated to recommend |at= in these cases.

—Trappist the monk (talk) 13:26, 19 September 2013 (UTC)

Accept language codes as well as language names

The {{#language}} parser allows us to support both language codes and language names without any conflict. In a template, the coding for that would be {{#ifeq: {{#language:{{{language|}}}}} | {{{language|}}} | {{{language|}}} | {{#language:{{{language|}}}}} }}, but I have no idea how to do that in Lua. (As an aside, I'm aware that that syntax is rather ugly, and have filed a bug to make it somewhat less so.) Still, I think this would be useful, and I'd very much appreciate if someone who knows their way around Lua could help out here. — PinkAmpers &^{(Je vous invite à me parler)} 21:39, 19 September 2013 (UTC)

I'm not sure if you're asking something or offering something. I'm an idiot sometimes so it might just be me. There is a Lua module Module:ISO 639 name that might be of interest to you.

—Trappist the monk (talk) 04:08, 20 September 2013 (UTC)

Anchors from dates with seasons

I have tweaked Module:Citation/CS1/sandbox so that seasonal dates may be used for anchors. This eliminates the need to include both |date= and |year= when |date= contains winter, spring, summer, or fall. These seasonal keywords must be followed by white space followed by the year. Because of how Lua works and how the code is written, combinations of these seasonal keywords may or may not work. That needs to be fixed. For the time being, single seasons do work.

{{#invoke:citation/CS1/sandbox |citation |CitationClass=journal |title=Title |date=Summer–Fall 2008 |ref=harv}}

{{cite journal}}: Empty citation (help)

'"`UNIQ--templatestyles-0000002F-QINU`"'<cite class="citation journal cs1"></cite> <span class="cs1-visible-error citation-comment"><code class="cs1-code">{{[[Template:cite journal|cite journal]]}}</code>: </span><span class="cs1-visible-error citation-comment">Empty citation ([[Help:CS1 errors#empty_citation|help]])</span>

Surely there is a more elegant way to accomplish this.

Are there other seasonal names that should be included in this list? Autumn comes to mind. Are there others?

—Trappist the monk (talk) 15:19, 28 August 2013 (UTC)

Because I have discovered an unrelated bug in another portion of Module:Citation/CS1, the playing around in the sandbox that is the topic of this thread have, for now, been reverted so that it isn't copied into the live version.

—Trappist the monk (talk) 01:01, 29 August 2013 (UTC)

That unrelated bug now having been fixed, there is a new version of the seasonal date detection code that, while a bit more complex, works better because it allows different styles of seasonal date: |date=Winter 2008, |date=Winter/Spring 2008, |date=Winter / Spring 2008, |date=Winter-Spring 2008, |date=Winter - Spring 2008. It isn't perfect, |date=Fallow 2008 will create an anchor. But, it's a step in the right direction.

—Trappist the monk (talk) 17:58, 2 September 2013 (UTC)

A bit of a tweak and now the code only recognizes the Winter, Spring, Summer, Fall, Autumn keywords. When more than one season stated, the seasons may be separated with spaces, a forward slash '/', a hyphen, or an ndash. Using – will not work.

—Trappist the monk (talk) 19:29, 2 September 2013 (UTC)

Regarding your question about the names of seasons: yes, I agree that we should have Autumn = Fall. Perhaps also Early and Late (as in: "Late 2007" or similar)? It Is Me Here ^{t / c} 14:45, 3 September 2013 (UTC)

How about Q1 2008, Q2 2008, Q3 2008 or Q4 2008 ? -- WOSlinker (talk) 12:31, 13 September 2013 (UTC)

I was just thinking something similar. Also, First Quarter, 1st Quarter, etc. But I was also wondering if this date style is very often used with sources? Is it?

—Trappist the monk (talk) 14:20, 13 September 2013 (UTC)

Done for seasons winter, spring, summer, fall, autumn.

—Trappist the monk (talk) 12:09, 21 September 2013 (UTC)

Update to the live CS1 module

Within the next couple of days 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:

Fixes a bug discussed at Help talk:Citation Style 1/Archive 3#Slight bugs with via= & subscription= where |via= improperly categorizes citations as requiring subscriptions when subscriptions may not actually be required;
Adds the ability to create CITEREF anchors from |date= parameters that contain a year preceded by a season (Winter, Spring, Summer, Fall, Autumn) so that citations using this style of date do not require the additional inclusion of |year= to make a correctly formatted CITEREF anchor. Discussion: #Anchors from dates with seasons
Changes the operation of the |PMC= identifier. This is discussed in Help talk:Citation Style 1#Template:Cite journal HTTP/HTTPS inconsistency. |PMC= was (and still is) unique among the identifiers. This parameter supports |embargo= which prevented an automatic |title= link when the date specified by |embargo= lay in the future. At the same time, the rendered PMC ignored the embargo. No other identifier automatically links |title= so that functionality is removed from PMC. While an embargo is in effect, the PMC identifier in the rendered citation is not linked.
A side issue that arose from the PMC discussion is that several of the identifier links were hard coded to use the http scheme. Where possible, those have been changed to protocol relative urls.
As a step toward better language support, |language= will accept ISO639-1 language codes and , when these codes are used properly categorize the page in a manner similar to {{xx icon}} / {{language icon}}.

—Trappist the monk (talk) 01:27, 19 September 2013 (UTC)

Great work. I especially like #5, which will allow the language parameter to be machine-readable. This should allow for more consistency and all manner of useful tricks. – Jonesey95 (talk) 04:07, 19 September 2013 (UTC)

Done.

—Trappist the monk (talk) 12:05, 21 September 2013 (UTC)

Another tracking category

Just wondering if it's work adding a tracking cateogry for where the 1 parameter starts with http. I've seen a few uses of Cite web where instead of using the url parameter, it is just missed out with {{cite web|http://wiki.riteme.site|title=Wikipedia}} -- WOSlinker (talk) 14:43, 21 September 2013 (UTC)

The citation that you give as an example is categorized into Category:Pages with citations using unnamed parameters and Category:Pages using web citations with no URL. Is that insufficient? Do you have a proposed category name?

—Trappist the monk (talk) 15:48, 21 September 2013 (UTC)

It was just a way to find some of the easier cites to fix from those large categories. Would only be for a temporary basis. -- WOSlinker (talk)

We could auto-correct an unnamed parameter with "http*:" or "//" as url, unless already has "url=" but there is a problem when auto-correcting to link blacklisted urls, such as "//www.examiner.com" or other websites which WP has been rejecting during edit-Save by the edit-filters. I suppose checking for prefix "//www.examiner." could prevent the blacklisted site from being linked. -Wikid77 (talk) 22:06, 21 September 2013 (UTC)

There are only 1,628 Article-space articles in Category:Pages with citations using unnamed parameters right now. Someone's been hard at work fixing articles in that category. We'll have it cleared out pretty soon; I'm finishing up Category:Pages with URL errors and will need a new category to work on soon, so I'll head over to this one. I don't see a need for a temporary category. – Jonesey95 (talk) 21:51, 25 September 2013 (UTC)

ISSN bug

Apparently there is a bug in the issn identifier code that also exists in the {{citation/core}} version. If the eight digit issn is divided into two four-digit groups separated by white space, the displayed result is twelve-digits in three four-digit groups where the groups are separated by white space but where the WorldCat link contains only the first four digits of the issn:

Cite journal comparison
Wikitext	`{{cite journal\|issn=0819 4327\|sandbox=yes\|title=Sustainable Tourism Plan for the Abrolhos Islands}}`
Live	"Sustainable Tourism Plan for the Abrolhos Islands". ISSN 0819-4327. `{{cite journal}}`: Cite journal requires `\|journal=` (help); Unknown parameter `\|sandbox=` ignored (help)
Sandbox	"Sustainable Tourism Plan for the Abrolhos Islands". ISSN 0819-4327. `{{cite journal}}`: Cite journal requires `\|journal=` (help); Unknown parameter `\|sandbox=` ignored (help)

An issn grouped with a hyphen (0819-4327) or not separated into groups of four digits (08194327) produces correct results.

—Trappist the monk (talk) 13:47, 22 September 2013 (UTC)

This is a known problem (it's come up before on talk pages, not necessarily this one, but it's certainly in the documentation) and the cause is simple. Consider that it's an external link:

[http://www.worldcat.org/issn/0819 4327 0819 4327]

External links cannot contain spaces; moreover, the Wikitext parser treats the first space as the delimiter between the link itself and the text to display. It's working as documented. --Redrose64 (talk) 14:45, 22 September 2013 (UTC)

This seems like something that might be worthy of a CS1 error category, similar to the "ISBN errors" category. And before that, a bot to clean up the existing ones, assuming that the solution is to simply remove the white space. – Jonesey95 (talk) 16:03, 22 September 2013 (UTC)

A hyphen would be better, since thet preserves the 4-4 grouping. --Redrose64 (talk) 16:53, 22 September 2013 (UTC)

There is a sort-of-fix in the sandbox. If the ISSN has a space, then the space is replaced with a hyphen; more than one space, then you get more than one hyphen; misplaced space, then you get a misplaced hyphen. It seems that the correct thing to do is to remove any and all spaces, check the check digit, and then reformat into correct groups.

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

Better fix. CS1/sandbox now strips spaces, hyphens, and ndashes from the |issn= value. It then makes a copy for display with a hyphen following the first four digits. CS1/sandbox also checks to make sure that the checksum is correct. If the ISSN contains characters other than the digits 0–9 or an X (in the checkdigit position) or if the checkdigit doesn't match the calculated checksum value, then CS1/sandbox emits an error message: Check |issn= value (help). If this code is retained, these errors will be categorized in Category:Pages with ISSN errors.

—Trappist the monk (talk) 14:20, 24 September 2013 (UTC)

Sounds good. This will result in better-functioning ISSNs than we have now, along with a group of articles to target for cleanup. – Jonesey95 (talk) 16:04, 24 September 2013 (UTC)

Formatting and validation of ISSN is a welcome incremental improvement. Sometimes I've seen misuse along the lines of |ISSN=online 1234-5678, print 1234-6789 etc., will the new logic handle these? Rjwilmsi 20:21, 24 September 2013 (UTC)

Yes. Any thing other than 8 digits after spaces, hyphens, or ndashes are stripped off will cause CS1/sandbox to emit the error message.

—Trappist the monk (talk) 20:59, 24 September 2013 (UTC)

Update to the live CS1 module week of 2013-10-06

Within the next handful of days 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:

ISSN error detection and formatting; discussion;
Expand the list of namespaces that are not categorized; discussion;
Tweak subscription / registration help message: (Help) to (help) to match style of other CS1 messages;
Trap coauthors without authors; discussion;
Hide error messages |accessdate= requires |url=, Missing or empty |url=, |format= requires |url=, |displayauthors= suggested, and |displayeditors= suggested; discussion;

—Trappist the monk (talk) 22:51, 7 October 2013 (UTC)

Done.

—Trappist the monk (talk) 10:38, 12 October 2013 (UTC)

Pages with URL errors

Although Category:Pages with URL errors states "Pages in the...MediaWiki talk...namespaces are not included in the error tracking categories", there are two MediaWiki talk archive pages in that category. Could someone please update this error? Thanks! GoingBatty (talk) 13:29, 16 October 2013 (UTC)

The change that excludes MediaWiki talk pages from the CS1 error categories was implemented on 12 October. It often takes weeks for such changes to percolate through the systems. You might try null edits to remove the pages from the category listing.

—Trappist the monk (talk) 13:38, 16 October 2013 (UTC)

Null edits don't work. The offending parameters are |url=examiner.com/article/important-research-for-leonberger-dogs-inherited-polyneuropathy-ipn and |url=(removed)pokerverdict.com/Poker-Players-Club/Focus/87433/november_nine_player_focus_ylon_schwartz.html it's complaining because neither begins http: or https: --Redrose64 (talk) 13:46, 16 October 2013 (UTC)

You're right, null edit doesn't work and it doesn't work because MediaWiki talk is not in the list of excluded namespaces. I'll fix that in the sandbox. At some point when I was expanding the list of excluded namespaces I determined that CS1 templates don't work there. Clearly they do.

—Trappist the monk (talk) 14:16, 16 October 2013 (UTC)

Thanks to both of you for looking into this so quickly! GoingBatty (talk) 14:35, 16 October 2013 (UTC)

Type parameter and cite press release and cite thesis

I am migrating {{cite thesis}} into Module:Citation/CS1/sandbox. {{cite thesis}} has a default type that is controlled by |degree=. If |degree= is empty or not used then type is set to (Thesis). Otherwise, type is set to (<degree> thesis). But, if |type= is present its value overrides the default. If |type= is present but empty then that prevents the display of the type value.

{{cite thesis |title=Title}} → Title (Thesis).

{{cite thesis |title=Title |degree=Masters}} → Title (Masters thesis).

{{cite thesis |title=Title |degree=Masters |type=Some other type}} → Title (Some other type).

{{cite thesis |title=Title |degree=Masters |type=}} → Title (Masters thesis).

I can imagine that there might be times when the default type doesn't suit a specific case – perhaps it is more appropriate to use the term dissertation so overriding the default type with |type=Dissertation is fitting. But is there a reason blank the type by setting |type=?

A similar case exists in {{cite press release}} except that there is only one default type.

Is there any reason to continue to support these? I can't think of any at the moment. I've said elsewhere that I don't think that empty parameters should have meaning. This is because so many templates do nothing with empty parameters. Having certain parameters that do something to the citation format when they are empty is inconsistent with the vast majority of parameter that do nothing when they're empty. If there is a reason to blank the the default type then we should be specifically setting |type=none. This functionality has been adopted for |postscript= and |ref=.

—Trappist the monk (talk) 14:48, 18 October 2013 (UTC)

Agree. I find it very confusing when an existent but empty parameter causes the citation to display differently from the same citation with that parameter missing. Empty parameters should have no effect on the display of a citation. In other words, I think that if "type=" or "type=" is present, the citation should work the same as when "type=" is missing.

Two sentences in the documentation should explain how to make the word "thesis" disappear. Something like: "Thesis" is shown in parentheses after the title. To suppress the word "thesis", set the "type=" parameter to "none", like this: (and then provide examples).

The only problem I see with this approach is that, if I understand you correctly, we would be changing the behavior of the cite thesis template as it currently exists. If there are cite thesis templates in use with empty type= parameters, they will change from showing the title alone to showing the title followed by (Thesis). – Jonesey95 (talk) 18:06, 18 October 2013 (UTC)

Because this is an undocumented "feature" in both {{cite thesis}} and {{cite press release}}, it may not be an issue.

—Trappist the monk (talk) 00:16, 19 October 2013 (UTC)

I've tweaked CS1/sandbox for {{cite thesis}} so that when |type=none the thesis annotation (type) is not displayed. But, when |type=<empty> the displayed citation is not altered:

{{cite thesis/new |title=Title}} → Title (Thesis).

{{cite thesis/new |title=Title |degree=Masters}} → Title (Masters thesis).

{{cite thesis/new |title=Title |degree=Masters |type=Some other type}} → Title (Some other type).

{{cite thesis/new |title=Title |degree=Masters |type=}} → Title (Masters thesis).

{{cite thesis/new |title=Title |degree=Masters |type=none}} → Title.

and also for {{cite press release}}:

{{cite press release/new |title=Title}} → "Title" (Press release).

{{cite press release/new |title=Title |type=Some other type}} → "Title" (Some other type).

{{cite press release/new |title=Title |type=}} → "Title" (Press release).

{{cite press release/new |title=Title |type=none}} → "Title".

—Trappist the monk (talk) 16:03, 26 October 2013 (UTC)

Deprecated parameter tracking cat

Added code to notice and flag the use of |coauthors=. This parameter has been deprecated so in CS1/sandbox its use is noted and Category:Pages containing cite templates with deprecated parameters added to the citation output. Obeys the same rules as other categories.

If and when other parameters are deprecated, a similar call to the deprecated_parameter() function is all that is required.

—Trappist the monk (talk) 11:43, 13 October 2013 (UTC)

Also added tracking for |month= and |day=.

—Trappist the monk (talk) 14:33, 30 October 2013 (UTC)

ISBN error check tweak

A discussion about ISSN error messages and this number masquerading as an ISSN 977-217605400-2 showed the Special:BookSources can be fooled by a 13-digit number which has a correct checkdigit. The number doesn't fool Magic Links. But, it could fool CS1.

So, I've tweaked the CS1/sandbox so that such a number in a |isbn= stands a better chance of being caught. Thirteen digit ISBNs begin with one of two prefixes: 978 or 979 so CS1/sandbox now checks to make sure that the ISBN 13 begins with one of those prefixes.

Title. ISBN 977-217605400-2. {{cite book}}: Check |isbn= value: invalid prefix (help)

Title. ISBN 978-1-896300-40-5.

Title. ISBN 979-10-90327-00-9.

—Trappist the monk (talk) 00:28, 29 October 2013 (UTC)

Suppress "displayauthors" and "displayeditors" error in Template space?

I believe that I have fixed all of the Templates that were showing "displayauthors" and "displayeditors" errors. Citation bot, which populates many of these templates, has been reprogrammed to populate citations using more than nine authors (I have seen it go to 30 authors).

At this point, any new templates that are created with either exactly nine authors or exactly four editors will display the CS1 error, even though the editors who create these new templates are choosing to enter exactly that many authors or editors. Any new nine-author templates created by Citation bot are created that way because the journal article has exactly nine authors.

I believe that the "displayauthors" and "displayeditors" errors should no longer be shown in Template space, since the error is intended to draw attention to citations for which the original journal article might have more than nine authors or four editors. Since all of those ambiguous situations have been resolved, can we disable this error message for the Template namespace? It should remain active for the Main namespace, although it could go away at some point once those articles are fixed.

Does that make sense? – Jonesey95 (talk) 23:10, 1 November 2013 (UTC)

I think you're making sense. At least I think I understand what you're asking for. Are there templates that use any of the CS1 templates that are still using {{citation/core}}? When those CS1 templates are converted to the Lua module, if there are any templates that use the newly converted CS1 template and that have exactly 9a/4e then we should be showing the error, shouldn't we?

If a decision is taken to hide the error for pages in template namespace, that is relatively easy to accomplish. I think.

—Trappist the monk (talk) 00:06, 2 November 2013 (UTC)

If I know how to use catscan correctly, there are 286 templates that use {{citation/core}}. It's possible that I don't understand transclusion well enough to get the whole set of them, though. I would be happy to check these templates, but if anyone created a new template using citation/core before Lua conversions are complete, I'd have to check them again. I'm thinking that this is enough of an edge case that we could turn off the error message after I check the templates. I can live with one or two ambiguous citations out there.

All of the above assumes that 286 templates is the right number. If it's really thousands, then we have to wait. – Jonesey95 (talk) 14:46, 2 November 2013 (UTC)

I gave this some more thought, and I think a change like this would be premature. Let's wait until conversion to Lua is complete, assuming that is in the works. I do believe, however, that these two error messages can eventually be eliminated, since they are intended to alert editors to their ability to use more authors. At some point, when all of the errors have been dealt with, any editor adding 9 authors or 4 editors will presumably be doing so intentionally, all of those authors/editors should display without an "et al.", and there should be no error category. – Jonesey95 (talk) 18:37, 2 November 2013 (UTC)

Sandbox

@Trappist the monk: I don't think you intended to include Module:Citation/CS1/Configuration/sandbox and Module:Citation/CS1/Whitelist/sandbox when you synced the main module from the sandbox in this edit? Anomie ⚔ 13:26, 9 November 2013 (UTC)

You're right. Thanks for pointing that out. I need to figure out how to automate that so that when the page name is Module:Citation/CS1 it loads Module:Citation/CS1/Configuration and Module:Citation/CS1/Whitelist but when the page name is Module:Citation/CS1/sandbox it loads the sandbox version of those pages. This is not the first time I, and other editors, have been bitten by this oversight.

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

I have a workable solution that is ugly, but may be of interest. Module:Convert is still not live (I've been derailed by some RL issues), but the template used to invoke it is {{convert/sandboxlua}} (which would be {{convert}} when the module is live), and {{convert/sandbox}} (no "lua") is used to invoke Module:Convert/sandbox. That template sets |sandbox=on, and searching the module for "config.sandbox" shows how it is used (the code is complicated by the fact that I have a test system for running on a local computer—ignore the is_test_run stuff). What this boils down to is that one template is used to invoke the normal modules, while a sandbox template invokes the sandbox modules. Johnuniq (talk) 02:56, 10 November 2013 (UTC)

Thanks for that tip.

—Trappist the monk (talk) 11:49, 10 November 2013 (UTC)

Date checking

I have added code to Module:Citation/CS1/sandbox and Module:Citation/CS1/Configuration/sandbox to check the validity of dates.

The new code expects dates to be in one of the standard formats approved by MOS:DATE: MMMM D, YYYY; D MMMM YYYY; MMMM YYYY; YYYY-MM-DD; YYYY. In addition, dates with three letter month abbreviations and dates with season instead of months are also accepted. ~~Dates with month or season ranges are not yet fully functional.~~ Dates are checked for spelling and to make sure that the date is a real date - 29 February 2013 is not a real date:

{{cite book/new |title=Title |date=February 29, 2013}}

→ Title. February 29, 2013. {{cite book}}: Check date values in: |date= (help)

When {{sfn}} and the {{harv}} family of short-form references refer to an author who has published multiple works in the same year, some form of disambiguation is necessary. The usual mechanism is to append a letter suffix to the value in |year=. In the past, this has required the use of both |date= and |year= where |year= (with the disambiguator) is used in the creation of the CITEREF identifier and |date= is used for display and for inclusion in the COinS metadata.

{{cite book/new |title=Title |date=October 22, 2013a |ref=harv}}

→ Title. October 22, 2013a. {{cite book}}: Invalid |ref=harv (help)

→

'"`UNIQ--templatestyles-0000005C-QINU`"'<cite class="citation book cs1">''Title''. October 22, 2013a.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Title&rft.date=2013-10-22&rfr_id=info%3Asid%2Fwiki.riteme.site%3AModule+talk%3ACitation%2FCS1%2FArchive+8" 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>

In the above, CITEREF is disambiguated while the COinS date parameter (&rft.date=October+22%2C+2013) is not. For the time being, |date= displays the date with a disambiguator if one is present. This can easily be changed. Opinions?

Citations with invalid dates are flagged with an error message and, when this code is implemented in the live version of CS1, will be added to Category:CS1 errors: dates.

It is expected that when this code is wrung-out, |year= will be superfluous and so should be deprecated. Citations then containing |year= will be added to Category:Pages containing cite templates with deprecated parameters.

Are there date-holding parameters that I've missed?

Is additional functionality needed? If so, what?

Comments and opinions invited.

—Trappist the monk (talk) 14:54, 22 October 2013 (UTC)

I do not agree that WP:MOS or WP:MOSNUM control date formats in citations (although Wikipedia talk:Manual of Style/Archive 128#Which guideline for citation style? shows there is no consensus about this). Since Citation Style 1 is now viewed to be a citation style, I think you should demonstrate that Citation Style 1 has already established the styles you plan to check for as the only acceptable date styles. If this is not already established an RFC should be conducted to decide if this should be the case.

Even if the normal date standard can be establised for Citation Style 1, we must bear in mind that the source, not the Wikipedia editor, decides how the date will be stated for a source. When readers are trying to find a source, they will have to compare the date stated in Wikipedia to the date stated within the publication, or in the library catalog, or the like. If a magazine chooses to date an issue "Mud season, 2013" there isn't a damn thing we can do about it, we will have to cite it as the Mud season issue as well. Jc3s5h (talk) 15:15, 22 October 2013 (UTC)

My thoughts, in order as they came to me, after reading this:

"Oh man, there are going to be tens of thousands of articles in this new category." There are a lot of XX/XX/YYYY dates out there, lots of typos, and all sorts of other madness. And I am someone who is supportive of these CS1 errors in general and has fixed many thousands of them.
"This makes sense, I guess, as long as MOS:DATE is accepted as a standard for citation dates."
"We really need to persuade someone to create a CS1Bot to fix these CS1 errors."

I expect that we will find some cases of dates used in date-holding parameters that turn out to be acceptable, even though they do not explicitly fit within the date formats above. We'll have to be flexible in accommodating those dates, and we may need to throw out this error-checking entirely or create a way to suppress it (as we do for "invalid" ISBNs). I can imagine a date field with a range of dates, for example, such as an issue of a magazine whose issue date is "March-April 2003" (it looks like you may be working on that) or "March 1-15, 2003. – Jonesey95 (talk) 15:34, 22 October 2013 (UTC)

@Jonesey95: Yeah, there could be a lot of date format errors. We won't know unless we look for them.

I suspect that MOS:DATE is the de facto date format standard. I haven't seen any indication in the citations that other editors have created to indicate otherwise.

Yep, a reliable robot could come in handy now and again.

An |ignore-date-errors=yes parameter is possible.

—Trappist the monk (talk) 00:43, 23 October 2013 (UTC)

@Jc3s5h: No one has ever said that CS1 is and ought to be all things to all people. It is a tool to be used to accomplish a task. If it isn't suitable to the task at hand then another tool should be used. What time I've spent dabbling in the citation brook, shows me that the vast majority of citations that are implemented with CS1 use the accepted date formats enumerated in MOS:DATE.

Yes, of course there are cases where a legitimate date format provided by a source fails the date check because it doesn't comply with MOS:DATE. Newspaper websites are rife with them, very often of the ambiguous day- or month-initial numeric type, often with a variety of inter-digit punctuation (./- take your choice). Almost always editors convert such legitimate dates to an unambiguous MOS:DATE compliant format. Maybe there are cases like your Mud season, 2013 example. In that case, CS1 isn't the appropriate tool, use another.

—Trappist the monk (talk) 00:43, 23 October 2013 (UTC)

Checking the validity of dates is a new idea, which you started on your own initiative. It looks like there will be tradeoffs: "Maybe there are cases like your Mud season, 2013 example. In that case, CS1 isn't the appropriate tool, use another." Well, maybe some people would prefer to enter any arbitrary value in the date parameter rather than having to manually format any entry in an article which has a date assigned by the publisher that does not fit the constraints of the date-checking code. Oh, by the way, if the article uses short footnotes or Harvard citations, the editor will have to figure out the tricks to replicate that functionality without using templates. Perhaps this discussion should continue for a while in this obscure place for a while, but at some point the tradeoffs will have to be presented to the community to see if they would prefer to forgo flexibility in entering dates, or forgo date format checking. Jc3s5h (talk) 00:59, 23 October 2013 (UTC)

Not a new idea actually. It's been on the feature request list since May.

—Trappist the monk (talk) 14:13, 23 October 2013 (UTC)

(edit conflict)

The parameter |airdate= is part of {{cite episode}} which is not yet converted to use the CS1 module. These appear to work:

{{cite book/new |title=Title |url=//example.com |accessdate=2013-01 -30}}

→ Title. Retrieved 2013-01 -30. {{cite book}}: Check date values in: |accessdate= (help)

{{cite book/new |title=Title |url=//example.com |archiveurl=//example.com |archivedate=30 June, 2013}}

→ Title. {{cite book}}: Check |archiveurl= value (help)

{{cite journal/new |title=Title |embargo=31 Junuary 2013 |pmc=1234}}

→ "Title". PMC 1234. {{cite journal}}: Cite journal requires |journal= (help); Unknown parameter |embargo= ignored (|pmc-embargo-date= suggested) (help)

{{cite journal/new |title=Title |laydate=31 September 15 2013 |pmc=1234}}

→ "Title". {{cite journal}}: Cite journal requires |journal= (help); Unknown parameter |laydate= ignored (help); Unknown parameter |layurl= ignored (help)

{{cite book/new |title=Title |publicationdate=October 22 2013}}

→ Title. October 22 2013. {{cite book}}: Check date values in: |publicationdate= (help); Unknown parameter |publicationdate= ignored (|publication-date= suggested) (help)

—Trappist the monk (talk) 15:37, 22 October 2013 (UTC)

Another date-holding parameter:

{{cite journal/new |title=Title |doi_brokendate=October 22 2013 |doi=10.12345}}

→ "Title". doi:10.12345. {{cite journal}}: Check |doi= value (help); Cite journal requires |journal= (help); Unknown parameter |doi_brokendate= ignored (|doi-broken-date= suggested) (help)

—Trappist the monk (talk) 11:34, 24 October 2013 (UTC)

I too am a bit uneasy about date checking; in principle it's a good idea, but in practice I'm not sure that it will work. There needs to be some way of over-riding the check (|checkdate=no perhaps). Some very old books have uncertain dates, for example, so may be given as "c. 1758". The recommended citation date for APweb, used widely as a source in plant articles, is "2001 onwards". I doubt that it's possible to check all the valid but rarely used date formats.

I'm also not sure why |year= has to be marked as deprecated when the changes are complete. It's very widely used in citations and will surely become quite harmless viewed simply as an alternative name for |date=. Peter coxhead (talk) 16:28, 22 October 2013 (UTC)

I don't want to derail this conversation but I think that the proper date for APweb is July 2012 (also part of the recommended citation). Yes, such dates as c. 1758 will fail the current date check. Are there lots of those?

We can consider |checkdate=no or |ignore-date-errors=yes or something similar.

|year= along with |month= and |day= were added to the CS1 templates because of issues arising from the {{#time:}} parser function. Those issues have long since been resolved. |year= has never been a true alias of |date=. They are aliases only in the sense that they can both carry the year portion of a date but they are otherwise not interchangeable. Deprecation does not mean deletion; the parameter will continue to exist but in the documentation it will be marked as deprecated and editors referred to |date=.

—Trappist the monk (talk) 00:43, 23 October 2013 (UTC)

The date checking logic always applies Gregorian logic, even for dates such as February 29, 1500, which predate the Gregorian calendar. I note that the RFC for keeping the date location consistent has not been implemented. Finally, some style guides, such as APA, call for stating explicitly that a publication does not bear a publication date by writing n.d.; for publications that are in press APA calls for giving the date as "in press". Since Help:Citation Style 1 is silent on these points, it is reasonable to expect editors have, and will continue, to use these notations if the are accustomed to using one of the citation styles that call for them. See User:Jc3s5h/Gregorian calendar for worked examples. Jc3s5h (talk) 16:37, 22 October 2013 (UTC)

Julian date checking can be added if there is sufficient need for it. Likewise, a |date=n.d. check can be added. What is the exact format of that? In other words, what variety of no-date |date= values are acceptable? Should it be displayed or treated as if |date= were empty? How should a no-date date be handled with respect to CITEFREF identifiers? with respect to the COinS metadata?

What does in press mean? Is it something that a reader can figure out without to much trouble? Or, is it a term of art that is best left out of CS1 citations?

—Trappist the monk (talk) 00:43, 23 October 2013 (UTC)

As far as Julian vs Gregorian is concerned, before 1582 a publication date will be Julian if it is any European calendar. From 1582 to about 1923, dates could be either Julian or Gregorian. Since the checker won't be able to tell, the easiest thing to do would probably accept a date if it is valid in either calendar.

For "n.d." the community should decide if they want the option of indicating that a publication date was looked for and not found. Since template users haven't discussed this before, there isn't an exact format, but the exact format in APA is n.d. It should be displayed, and should be entered in short footnotes and harvard templates as the date value. It should also be entered in parenthesis together with the author's name after the material supported by a citation when there is no automated linking between citations and bibliography entries. As far as COinS goes, I have no idea. I've looked around and have not found any clear specification about how this data should look.

In the world of paper publications, "in press" would be used when an author was referring to one of his own works that had been accepted for publication but not yet printed. It might also be used if an author had been given an advance copy of a work by a colleague. At first, it might seem that this would not be necessary in Wikipedia since we only use published sources. But with the Internet, there are numerous ways authors can pre-publish documents and make them available to the public, for example, on the author's own website. So even in Wikipedia the phrase could be useful to indicate a document is about to be published in a particular publication. Jc3s5h (talk) 01:22, 23 October 2013 (UTC)

I guess I'm not seeing a need for in press. If a work hasn't been published then it runs afoul of WP:RS. If the work has been published on the internet (and ignoring the application of WP:RS for this discussion) then |accessdate= applies if the web version of the document doesn't have a date.

—Trappist the monk (talk) 14:13, 23 October 2013 (UTC)

The key point is that there are legitimate formats other than "simple dates" used in citations, whether my two examples of "c. YYYY" and "YYYY onwards" or Jc3s5h's "n.d." and "in press". As another example, the Flora of North America website suggests citing as "1993+" (although I never do). I'm sure there are other examples of "non-dates". They are all likely to be rare, but generating red error messages for such cases is not an acceptable solution. Peter coxhead (talk) 09:21, 23 October 2013 (UTC)

A thought: Is there harm in implementing this as a hidden error message for everyone except those of us who choose to show all of these CS1 errors (through a js modification)? It would take a month or so for the job queue to wander through all of the articles and categorize them (as is happening with ISSN and coauthors errors now), at which point we would have an idea of the scale of the problem and the actual population of edge cases like the ones we are all coming up with above.

If we see that there are just a few edge cases, we can mark them as "ignore-date-errors" and update the documentation accordingly. If we see that there are tons of edge cases, we can change the CS1 module to accept those as valid date formats or scrap the date checking altogether. – Jonesey95 (talk) 12:02, 23 October 2013 (UTC)

That seems an excellent suggestion to me. Peter coxhead (talk) 12:27, 23 October 2013 (UTC)

Error messages can be hidden as several currently are. It occurs to me that an alternative to |checkdate=no or |ignore-date-errors=yes might |datenotes= which would inhibit the date check for |date=. The parameter could encourage editors to state why the |date= value should not be checked. I think that this would be more helpful to other editors than the simple |checkdate=no or |ignore-date-errors=yes.

—Trappist the monk (talk) 14:13, 23 October 2013 (UTC)

The principle of getting an idea of how large the problem is seems good. When it comes time to update the documentation, it should reflect the full range of what might be found in a proper date field, so anyone who is using the source code or the metadata for any automated purpose will know what to expect. Another principle, I think, should be to maximize the ability to make links from harvard citations and short footnotes by recognizing reasonably common date-like entries for purposes of making matching anchors, such as c. 2010, 1998a, or n.d. Jc3s5h (talk) 12:55, 23 October 2013 (UTC)

|datenotes= sounds reasonable to me. – Jonesey95 (talk) 00:12, 24 October 2013 (UTC)

Dates with month or season ranges are now supported:

{{cite book/new |title=Title |date=June - August 2013a |ref=harv}}

→ Title. June – August 2013a. {{cite book}}: Check date values in: |date= (help); Invalid |ref=harv (help)

→

'"`UNIQ--templatestyles-00000071-QINU`"'<cite class="citation book cs1">''Title''. June – August 2013a.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Title&rfr_id=info%3Asid%2Fwiki.riteme.site%3AModule+talk%3ACitation%2FCS1%2FArchive+8" 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">Check date values in: <code class="cs1-code">&#124;date=</code> ([[Help:CS1 errors#bad_date|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>

Accepted separators are space, hyphen, virgule, endash (but not –):

→ Space. June August 2013. {{cite book}}: Check date values in: |date= (help)

→ Hyphen. Autumn–Winter 2013.{{cite book}}: CS1 maint: date format (link)

→ Virgule. Spring/Fall 2013. {{cite book}}: Check date values in: |date= (help)

→ Endash. May–June 2013.

When an endash is used, it is converted to a simple hyphen in the COinS metadata. (illustrated in the first example of this post)

|date= accepts n.d. or nd. None of the other date-holding parameters accept a no-date date.

→ "No date". n.d. Retrieved n.d.. {{cite web}}: Check date values in: |accessdate= (help)

Julian dates are assumed before 1582 otherwise, Gregorian dates are assumed. Where the two calendars overlap, Gregorian is assumed. As a consequence, the Julian calendar dates 29 February 1700, 29 February 1800, and 29 February 1900, are flagged as errors.

→ Title. 29 February 1700. {{cite book}}: Check date values in: |date= (help)

—Trappist the monk (talk) 11:34, 24 October 2013 (UTC)

I suggest a category name of "CS1 errors: date format" instead of "CS1 errors: date". – Jonesey95 (talk) 14:48, 2 November 2013 (UTC)

Except that is isn't just about formats, I'd agree with you. But, since it also includes checking for real dates I think "CS1 errors: date" is a better name.

—Trappist the monk (talk) 15:01, 2 November 2013 (UTC)

Bug fix. Because of limitations in {{citation/core}}, in order to disambiguate Harvard style references when a cited author has multiple works in the same year, it is necessary to disambiguate the citations. This is typically accomplished by adding an alpha suffix to the year parameter in the {{sfn}} or {{harv}}-family templates. Then, similarly, |date= is used to display the date in the rendered citation and |year= with the disambiguating suffix is used to create the CITEREF anchor. This tweak to the code supports legacy CITEREF creation when citations contain both |date= and |year= with disambiguator. In these citations, |year= is used to create CITEREFs:

{{cite book/new |title=CITEREF from Year |ref=harv |year=1995a |date=3 May 1995}}

→CITEREF from Year. 3 May 1995. {{cite book}}: Invalid |ref=harv (help)CS1 maint: date and year (link)

'"`UNIQ--templatestyles-0000007B-QINU`"'<cite class="citation book cs1">''CITEREF from Year''. 3 May 1995.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=CITEREF+from+Year&rft.date=1995-05-03&rfr_id=info%3Asid%2Fwiki.riteme.site%3AModule+talk%3ACitation%2FCS1%2FArchive+8" 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><span class="cs1-maint citation-comment">CS1 maint: date and year ([[:Category:CS1 maint: date and year|link]])</span>

The CS1/sandbox version now allows disambiguation from |date=; something previously not possible:

{{cite book/new |title=CITEREF from Date |ref=harv |date=3 May 1995a}}

→CITEREF from Date. 3 May 1995a. {{cite book}}: Invalid |ref=harv (help)

'"`UNIQ--templatestyles-0000007F-QINU`"'<cite class="citation book cs1">''CITEREF from Date''. 3 May 1995a.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=CITEREF+from+Date&rft.date=1995-05-03&rfr_id=info%3Asid%2Fwiki.riteme.site%3AModule+talk%3ACitation%2FCS1%2FArchive+8" 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>

I have also changed the code so that when citations disambiguate with |date=, they do not display the CITEREF disambiguator in the rendered citation. It's not clear to me if this is best or if we should display the disambiguator.

—Trappist the monk (talk) 14:59, 3 November 2013 (UTC)

The disambiguator should be displayed both in the rendered short footnote and in the rendered full citation. One reason is to allow people reading a paper copy to connect the footnote to the full citation. Another reason is that this is the traditional approach in paper publications, school term papers, and the like, so people familiar with writing citations outside of Wikipedia will think something is broken if the disambiguator is not displayed. Still another reason is that short footnotes and parenthetical referencing are often chosen so the same source can be cited several times. As one reads through such an article, one becomes accustomed to the short form of the citation, and will actually begin to remember that McCarthy 2009a is his book about time, while McCarthy 2009b is his paper about time transfer. This is despite the fact that the disambiguators will change from article to article. Jc3s5h (talk) 16:22, 3 November 2013 (UTC)

I agree. Peter coxhead (talk) 10:59, 4 November 2013 (UTC)

|date= now shows disambiguator

—Trappist the monk (talk) 22:49, 4 November 2013 (UTC)

One more date-holding parameter that we might want to check is |year=. I just saw a year parameter with a fully-specified (and non-MOSDATE) date in it. I know that the idea is to deprecate |year=, but we could check |year= whether we eventually decide to deprecate it or not. – Jonesey95 (talk) 16:04, 6 November 2013 (UTC)

Added.

—Trappist the monk (talk) 19:22, 6 November 2013 (UTC)

Not so fast. If a check is added, documentation about what will pass or fail the check should be added at some appropriate place in the documentation. The present documentation at Help:Citation Style 1 says nothing about how to write a year, except that if dates are to be used with the ref=harv parameter the year range is 100 to present, and the year may have a disambuator appended with no space between the space and the disambuator. So what does the new check allow? Jc3s5h (talk) 20:49, 6 November 2013 (UTC)

Exactly that.

Title. 99. {{cite book}}: Check date values in: |year= (help)CS1 maint: year (link) → {{cite book/new |title=Title |year=99}}

Title. 150. → {{cite book/new |title=Title |year=150}}

Title. 2013. → {{cite book/new |title=Title |year=2013}}

Title. 2013a. → {{cite book/new |title=Title |year=2013a}}

Title. 1 January 2013a.{{cite book}}: CS1 maint: year (link) → {{cite book/new |title=Title |year=1 January 2013a}}

—Trappist the monk (talk) 21:04, 6 November 2013 (UTC)

Thanks for the details. I notice that approximate years such as c. 1997 are not supported, neither with the year parameter nor with the date parameter. Also, the datenotes parameter has not been implemented. Jc3s5h (talk) 21:37, 6 November 2013 (UTC)

Not sure we need a datenotes-like parameter until we've actually seen what sort of nonstandard dates there are out there. I suspect that this error checking will end up being used to generate a category for bots to run through fixing agreed problems, and others will be left there, rather than it being a category with an objective of zero pages. Rjwilmsi 22:04, 6 November 2013 (UTC)

Circa dates only applicable to |date= and |year= and only as c<dot><space><YYYY|YYY> with or without disambiguator:

Title. c. 150. → {{cite book/new |title=Title |date=c. 150}}

Title. c. 150. → {{cite book/new |title=Title |year=c. 150}}

Title. Retrieved c. January 2013. {{cite book}}: Check date values in: |accessdate= (help) → {{cite book/new |title=Title |url=//example.com |accessdate=c. January 2013}}

{{cite book/new |title=Title |ref=harv |date= c. 150a}}

→Title. c. 150a. {{cite book}}: Invalid |ref=harv (help)

'"`UNIQ--templatestyles-00000093-QINU`"'<cite class="citation book cs1">''Title''. c. 150a.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Title&rfr_id=info%3Asid%2Fwiki.riteme.site%3AModule+talk%3ACitation%2FCS1%2FArchive+8" 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) 01:25, 7 November 2013 (UTC)

Sorry about the false alarm on circa dates; I have some javascript that issues warnings when there is no short citation pointing to a full citation, and I was seeing so much red that I misread my test cases. Jc3s5h (talk) 04:09, 7 November 2013 (UTC)

Not a false alarm; circa dates weren't added to CS1/sandbox until yesterday.

If it's the javascript I think it is (which name and author I don't remember), I copied that code to my own javascript page and modified it so that the error messages were much shorter and in the same font size and color as the CS1 error messages.

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

Y FYI for those reading this in the archives, the above change went into effect on 9 November 2013. – Jonesey95 (talk) 05:57, 10 November 2013 (UTC)

Day ranges supported in new date checking code?

Are day ranges supported in the new date checking code? My reading of MOSDATE says that the following |date= format should be acceptable:

{{cite conference |last=Tholen |first=D. J. |title=Asteroid taxonomic classifications |booktitle=Asteroids II; Proceedings of the Conference |pages=1139–1150 |publisher=University of Arizona Press |date=March 8–11, 1988 |location=Tucson, AZ |url=http://adsabs.harvard.edu/abs/1989aste.conf.1139T |accessdate=April 14, 2008}}

Tholen, D. J. (March 8–11, 1988). "Asteroid taxonomic classifications". Asteroids II; Proceedings of the Conference. Tucson, AZ: University of Arizona Press. pp. 1139–1150. Retrieved April 14, 2008. {{cite conference}}: Unknown parameter |booktitle= ignored (|book-title= suggested) (help)

The same code using a hyphen instead of an endash:

{{cite conference |last=Tholen |first=D. J. |title=Asteroid taxonomic classifications |booktitle=Asteroids II; Proceedings of the Conference |pages=1139–1150 |publisher=University of Arizona Press |date=March 8-11, 1988 |location=Tucson, AZ |url=http://adsabs.harvard.edu/abs/1989aste.conf.1139T |accessdate=April 14, 2008}}

Tholen, D. J. (March 8–11, 1988). "Asteroid taxonomic classifications". Asteroids II; Proceedings of the Conference. Tucson, AZ: University of Arizona Press. pp. 1139–1150. Retrieved April 14, 2008. {{cite conference}}: Unknown parameter |booktitle= ignored (|book-title= suggested) (help)CS1 maint: date format (link)

If I'm missing something, let me know. The top citation above is a verbatim example from Template:Cite conference/doc. – Jonesey95 (talk) 01:36, 12 November 2013 (UTC)

Agree, date ranges do not seem to be supported by validator check, and should be supported as valid. Rjwilmsi 08:20, 12 November 2013 (UTC)

Date checking: is this supposed to work?

Take a look at |date= in the citation here: Template:2008 Summer Olympics United States men's volleyball team roster. The rendered dates look fine, but they fail the new CS1 module's date checking routine.

The citation looks like this:

{{cite web|url=http://www.nbcolympics.com/volleyball/news/newsid=151093.html#u+s+olympic+volleyball+team+named |title=USA indoor team announced |publisher=Nbcolympics.com |date={{dts|format={{{df|dmy}}}|2008|7|15}} |accessdate={{dts|format={{{df|dmy}}}|2009|6|13}}}}

and renders like this:

"USA indoor team announced". Nbcolympics.com. 15 July 2008. Retrieved 13 June 2009. {{cite web}}: Check date values in: |accessdate= and |date= (help)

Is this what is supposed to happen? I've never seen a date like this. – Jonesey95 (talk) 05:27, 12 November 2013 (UTC)

The validation does not seem to support subtemplates within the date fields. While it's not wrong to use subtemplates, I don't see in this example why the use of two templates per date is needed? Rjwilmsi 08:22, 12 November 2013 (UTC)

The date "{{dts|format={{{df|dmy}}}|2008|7|15}}" is only one template, and Special:ExpandTemplates shows that it results in:

02008-07-1515 July 2008

{{cite web}} never sees {{dts}}; instead, cite_web receives the above expansion. I see no reason for using dts in the above, and it should be regarded as an error (dts is for displaying dates in a sortable table). Johnuniq (talk) 09:15, 12 November 2013 (UTC)

Anything that is in the |date= value will be made part of the COinS metadata. Very few templates are safe for use in CS1 citations because they render extraneous stuff that is detrimental to the metadata.

—Trappist the monk (talk) 11:54, 12 November 2013 (UTC)

Author versus first?+last?

The COinS metadata produced when one uses author= produces duplicate entries when are parsed by Zotero. Anyone know if this is a problem and if it needs a fix. I am presuming that author= and the use of first?+last? pairs are mutually exclusive options. Shyamal (talk) 06:00, 7 November 2013 (UTC)

I don't know about your COinS issue, but yes, one of author/coauthor or firstn/lastn should be used (and only firstn/lastn if you intend to use ref=harv). —David Eppstein (talk) 07:00, 7 November 2013 (UTC)

When I use {{cite journal|author=Lastauth, firstname|year=2000|title=Blah|journal=Hah|volume=1|issue=2|page=3}} we emit

 ...
 rft.atitle=Blah&
 rft.au=Lastauth%2C+firstname&
 rft.aulast=Lastauth%2C+firstname&
 rft.date=2000&
 rft.genre=article&
 rft.issue=2&
 rft.jtitle=Hah&
 rft.pages=3&
 ...

Perhaps the rft.aulast without the rft.aufirst should not be produced in this case as rft.au is also parsed by Zotero leading to two author entries. Whereas we produce only one author entry (as expected) in Zotero when we use {{cite journal|last1=lname|first1=fname|year=2001|title=Blah blah|journal=Hah hah|volume=4|issue=5|page=6}}

 ...
 rft.aufirst=fname&
 rft.aulast=lname&
 rft.au=lname%2C+fname&
 rft.date=2001&
 rft.genre=article&
 rft.issue=5&
 rft.jtitle=Hah+hah&
 rft.pages=6&
 ...

I am not sure if this is a specification issue or a Zotero parser problem. Shyamal (talk) 09:51, 7 November 2013 (UTC)

Is this an issue that is causing Zotero to malfunction or is it simply something that you notice and consider undesirable? My reading of this document seems to indicate that multiple fields that contain redundant data are allowed so this condition shouldn't be breaking Zotero.

—Trappist the monk (talk) 13:45, 7 November 2013 (UTC)

I am not sure what it the cause is but it sure is undesirable. When Zotero takes in the first citation I provided and exports it back as a Wikipedia template it makes it {{Cite journal | volume = 1 | issue = 2 | pages = 3 | last = Lastauth | first = firstname | coauthors = Lastauth, firstname | title = Blah | journal = Hah | date = 2000 }}

I suppose that means Zotero is doing some splitting at commas and partly contributing to the mess up.

Shyamal (talk) 15:51, 7 November 2013 (UTC)

The current version of the CS1 code produces one &rft.aulast and, if |first= or its alias is present, one &rft.aufirst for the first author. CS1 also produces &rft.au for every author in the citation.

{{cite journal |last1=Last1 |first1=First1 |last2=Last2 |first2=First2 |last3=Last3 |first3=First3 |last4=Last4 |first4=First4 |title=Title}}

&rft.aufirst=First1

&rft.aulast=Last1

&rft.au=Last1%2C+First1

&rft.au=Last2%2C+First2

&rft.au=Last3%2C+First3

&rft.au=Last4%2C+First4

Because there is no |first= when the citation uses only |author#=, CS1 does not produce &rft.aufirst but does produce &rft.aulast (because |last1= and |author1= are aliases) along with a &rft.au for every author in the citation:

{{cite journal |author1=Last1, First1 |author2=Last2, First2 |author3=Last3, First3 |author4=Last4, First4 |title=Title}}

&rft.aulast=Last1%2C+First1

&rft.au=Last1%2C+First1

&rft.au=Last2%2C+First2

&rft.au=Last3%2C+First3

&rft.au=Last4%2C+First4

Is this the correct way for CS1 to function? I don't know though is does seem sort of pointless to have redundant data in the COinS metadata.

—Trappist the monk (talk) 17:35, 7 November 2013 (UTC)

Here is a test

Last1, First1; Last2, First2; Last3, First3; Last4, First4 (2000). "Title". somejournal.{{cite journal}}: CS1 maint: numeric names: authors list (link)

~~will post the screenshot of the Zotero parse for that in a moment.~~ It duplicates the first author as a fifth coauthor. Shyamal (talk) 12:34, 8 November 2013 (UTC) What is worse is that when Zotero is asked to export it back as a Wikipedia template it produces {{Cite journal | last = Last1 | first = First1 | coauthors = First2 Last2, First3 Last3, First4 Last4, Last1, First1 | title = Title | journal = somejournal | date = 2000 }} Now it seems like the first author gets repeated as a coauthor. This happens even when a single |author= is specified Shyamal (talk) 12:42, 8 November 2013 (UTC)

It isn't surprising that Zotero is parsing what CS1 gives it. That seems to me to be correct operation; it's merely displaying the data it was given. Nor is it really surprising that Zotero creates a citation that groups all of the &rft.au=Last1%2C+First1 though &rft.au=Last4%2C+First4 authors into |coauthors=. The deprecation of |coauthors= is a relatively recent event.

These remain unanswered: Should CS1 continue to create COinS author metadata in the way it currently does? Should it be changed? If it should be changed, how?

—Trappist the monk (talk) 13:43, 8 November 2013 (UTC)

If we skip the rft.aulast - Zotero behaves perfectly - additionally it takes a page snapshot which too fails if that entry is present! Whether that is a Zotero problem I do not know but if removing rft.aulast works with a few other citation managers - Mendeley? Endnote? I suppose it could be dropped out. Shyamal (talk) 02:34, 9 November 2013 (UTC)

rft.au=Last1%2C+First1&
rft.au=Last2%2C+First2&
rft.au=Last3%2C+First3&
rft.au=Last4%2C+First4&
'''rft.aulast=Last1%2C+First1&''' <--- can we drop this ??

Have tried the following change and it seems to work fine. However I do not know enough about key-value pairs and their usage in LUA as well as the rationale for the original code to examine what exactly the side-effects could be. Shyamal (talk) 10:21, 11 November 2013 (UTC)

    local last, first;
    for k, v in ipairs( data.Authors ) do
        last, first = v.last, v.first;
--  Commenting out this section fixes the problem
--  but why was it in use ? what condition is it actually needed in ?
--        if k == 1 then
--            if is_set(last) then
--                OCinSoutput["rft.aulast"] = last;
--            end
--            if is_set(first) then 
--                OCinSoutput["rft.aufirst"] = first;
--            end
--        end
        if is_set(last) and is_set(first) then
            OCinSoutput["rft.au"] = table.concat{ last, ", ", first };
        elseif is_set(last) then
            OCinSoutput["rft.au"] = last;
        end
    end

When you're done testing make sure you return the code to it's pre-test state so that the test changes don't inadvertently end up in the live version.

—Trappist the monk (talk) 12:44, 11 November 2013 (UTC)

Your change also broke the |displayauthor= code:

Cite book comparison
Wikitext	`{{cite book\|display-authors=2\|last2=Last2\|last3=Last3\|last4=Last4\|last=Last1\|sandbox=yes\|title=Title}}`
Live	Last1; Last2; et al. Title. `{{cite book}}`: Unknown parameter `\|sandbox=` ignored (help)CS1 maint: numeric names: authors list (link)
Sandbox	Last1; Last2; et al. Title. `{{cite book}}`: Unknown parameter `\|sandbox=` ignored (help)CS1 maint: numeric names: authors list (link)

—Trappist the monk (talk) 12:51, 11 November 2013 (UTC)

My bad there. Can anyone having Endnote check if all is well? Will see if I can get someone( or myself) to try Mendeley. Shyamal (talk) 14:24, 11 November 2013 (UTC)

Mendeley web importer test worked fine although it seems to have a problem (unrelated to this change) in failing to get the |page= parameter. Shyamal (talk) 15:38, 11 November 2013 (UTC)

The code that has evolved to become the code that you list above was originally added to Module:Citation - the forerunner of Module:Citation/CS1 at this edit by Editor Uncle G. You might want to ask Editor Uncle G about that code.

—Trappist the monk (talk) 18:16, 13 November 2013 (UTC)

I see two problems with the gestalt of this discussion, and I'm not sure there is a solution, because the problem was not thought about when the cite templates were invented.

Problem 1: Citation style 1 does not say what to do about corporate/group authors. Some printed style guides say a corporation or group is never an author, only a publisher, so the author should be omitted and the group that created the document be named as the publisher. Other printed style guides encourage listing the group as the author, and if there isn't a separate publisher, omitting the publisher name. Citation Style 1 doesn't say. We must assume some editors have listed groups as authors. Groups do not have first and last names, they just have names.

Problem 2: There is no global understanding of what a last name is. In conventional Anglo-Irish use, which has been adopted to a considerable degree in the US, a last name is a family name which is handed down through the generations. In China and Japan, for example, the first name is the family name. Icelanders and one-name celebrities don't have family names, because there is no name that is handed down through the generations. Yet, American government departments usually demand that if a person has only one name, the name be entered as a last name.

What we really want for citations is a most important index name, and a less important index name. The most important index name determines the order of bibliographies in alphabetical order, and the less important index name breaks ties. Unfortunately we have millions of citations that were written without any clear documentation about what to do in these cases. Jc3s5h (talk) 16:57, 19 November 2013 (UTC)

I agree that these are both real problems. For example, very important papers concerned with the classification of flowering plants were authored by the Angiosperm Phylogeny Group; it is explicitly suggested in the papers that the APG is cited as the "author". Citations in Wikipedia of these papers vary considerably. Chinese, Japanese and Korean names seem generally to be cited here in the order given in the source. Since journals vary in whether they use "surname first name(s)" or "first name(s) surname" for Eastern names, the same person can be found in different ways in different citations. There's another issue for Chinese names as well. Modern Chinese sources seem to hyphenate two-character first names, as e.g. here for Hao Shou-Gang. So I've cited this paper using |last=Hao |first=Shou-Gang, which outputs "Hao, Shou-Gang". However, in the standard index of plant authors here, he appears as "Hao, Shou Gang" with the standard abbreviation "S.G.Hao". So at Gumuia, his name appears one way in the taxobox and another in the references. Peter coxhead (talk) 18:24, 19 November 2013 (UTC)

Can this part of the discussion be moved to a different section? The original topic is about how CS1 formats names into COinS metadata.

—Trappist the monk (talk) 19:42, 19 November 2013 (UTC)

Proper mapping between two systems requires an understanding of the parameters in both systems. I'm not sure you can fix the mapping if you don't know what the parameters mean. Jc3s5h (talk) 21:22, 19 November 2013 (UTC)

AFAIK you can use |author=Whatever-Name-Format to retain the name as is, use organizations etc. without expecting names to follow the scheme of Europe and America. Shyamal (talk) 02:08, 21 November 2013 (UTC)

Deprecated year parameter?

Can someone point me to a discussion where a consensus was reached to deprecate the year parameter in {{cite journal}} templates? There was this previous discussion, but as far as I can see, there was no consensus reached there. Furthermore these talk pages come with an {{Visibility}} caution. This is not the best place to reach consensus. I agree with @David Eppstein:, the year parameter is used in far too widely to be deprecated and there is no need to do so. Boghog (talk) 07:05, 12 November 2013 (UTC)

|year= isn't deprecated, do you mean |month=? I agree that deprecating |month= does not seem appropriate. For a periodical year and month may be known, but there may be no concept of day to make a full date. Rjwilmsi 08:24, 12 November 2013 (UTC)

Apparently it was decide somewhere to deprecate both the |month= and |year= parameters (see for example this change). I think neither parameter should be deprecated. Boghog (talk) 10:43, 12 November 2013 (UTC)

If there are visibility concerns, perhaps moving this discussion elsewhere is in order.

|year= is not deprecated. There has been no discussion that I know of outside of the archived thread that Editor Boghog referenced, though there may be mentions of it here and there.

|day=, |month=, and |year= were, as I understand it, implemented because there were problems with the wikimedia parser and error returns from the #time parser function. The change was apparently first made in 2008 in {{cite journal}} but I haven't been able to find discussion about that.

Since the beginning, in the absence of |date=, {{citation}} and the CS1 templates concatenated |day=, |month=, and |year= into |Date= for use by {{citation/core}} which then displayed the concatenated date. |day= and |month= serve no other purpose. CS1 templates that use Module:Citation/CS1 do this same thing to maintain backward compatibility with existing citations in article space.

|year= in {{citation/core}}-based CS1 templates, is used to create disambiguated CITEREF anchors for the Harvard and {{sfn}} referencing system. The most recent change to Module:Citation/CS1 allows the creation of disambiguated CITEREF anchors from |date= rendering |year= unnecessary.

Deprecating these parameters does not mean that they will all-of-a-sudden stop working. They are no longer necessary for the proper operation of the CS1 templates because |date= can supply all of the needed date information.

—Trappist the monk (talk) 13:44, 12 November 2013 (UTC)

Thanks for the clarification. Based on edits like this, it appeared that both the month and year parameter were deprecated. Now I see that the only the ~~year~~ month parameter has been deprecated. I still question question the need to deprecate the month parameter, especially if editors are tempted to merge the year and month into a single date parameter. I see the merger possibly resulting in inconsistent rendering of the displayed date. I also see this deprecation resulting in a lot of unnecessary edits. Boghog (talk) 14:38, 12 November 2013 (UTC)

Umm, repeating myself: |year= is not deprecated.

I can see how having separate |day=, |month=, and |year= parameters might result in more consistent date rendering (provided that editors also are consistent in the use of spelling, abbreviation, punctuation, day and year numbering style, etc., which, judging by the number of pages listed at Category:CS1 errors: dates they are not). And of course it would then be necessary to introduce a new parameter, perhaps |dateformat=, to force the citation to comply with WP:STRONGNAT or the article's date style.

Better, I think, to let editors decide and just require that whatever dates they use comply with WP:MOSDATE.

—Trappist the monk (talk) 15:21, 12 November 2013 (UTC)

I made the edit in question. |month= is deprecated, and |year= does not accept days or months, so I used |date= to accommodate both parameters' values. Please let me know if you can think of a better way to keep the month while fixing the date error. Thanks. – Jonesey95 (talk) 15:43, 12 November 2013 (UTC)

That is correct, as I understand it: use |year= if you have only the number of the year, or use |date= if you have month or day information to include as well. It is no longer necessary to use both parameters in the same citation. I'm curious, do dates like "Summer 1967" parse? Because a lot of magazines are dated like that and it would be helpful to allow the date parameter to contain that while still parsing the year number for functions that need it. The citation looks ok with a date like that but that's not the same as being parsed properly. —David Eppstein (talk) 18:31, 12 November 2013 (UTC)

Within the citation templates that use Module:Citation/CS1, as far as I know, there is no need for separate |month= and |year= parameters. Also, as far as I know there are no functions that require a separate |year= parameter. If you know differently, please identify these needs.

The code that handles |date= accepts and understands dates with seasons and years (spring, summer, winter, autumn, fall) as well as season ranges (spring–summer, etc). Any dates in |date=, except ISO 8601, can be disambiguated with an alpha character for use with Harvard and {{sfn}} referencing. This is the primary reason that |year= is retained in {{citation/core}}-based templates.

I have discovered an oversight on my part. The concatenated date from |day=, |month=, and |year= is not checked and handled by the CS1 date checking code. These dates will appear to work correctly but their validity is not checked:

{{cite book |title=Title |day=31 |month=Jane |year=2013a |ref=harv}}

→Title. 2013a. {{cite book}}: Invalid |ref=harv (help); Unknown parameter |day= ignored (help); Unknown parameter |month= ignored (help) – should produce an error because there is no month Jane and June doesn't have 31 days

'"`UNIQ--templatestyles-000000B5-QINU`"'<cite class="citation book cs1">''Title''. 2013a.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Title&rft.date=2013&rfr_id=info%3Asid%2Fwiki.riteme.site%3AModule+talk%3ACitation%2FCS1%2FArchive+8" 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>; <span class="cs1-visible-error citation-comment">Unknown parameter <code class="cs1-code">&#124;day=</code> ignored ([[Help:CS1 errors#parameter_ignored|help]])</span>; <span class="cs1-visible-error citation-comment">Unknown parameter <code class="cs1-code">&#124;month=</code> ignored ([[Help:CS1 errors#parameter_ignored|help]])</span>

And, as you can see from the rendered html, the date in the COinS metadata is only the year portion of the date and it contains the CITEREF disambiguator which it should not.

—Trappist the monk (talk) 19:20, 12 November 2013 (UTC)

The argument advanced above why the month parameter has been deprecated because "they are no longer necessary for the proper operation of the CS1 templates" seems to be completely backwards. Having separate month and year parameters insures that the date is consistently rendered. Manual concatenation of the month and year template introduces the possibility that the dates within one article may be inconsistently rendered. IMHO that is a bad thing. It seems that the needs of the underlying scripting language are being put before the reason why the templates were created in the first place. Boghog (talk) 20:41, 14 November 2013 (UTC)

In answer to the very first question in this section, I found Module_talk:Citation/CS1/Archive_8#Deprecated_day_and_month. I was unable to find any other discussion in a search of likely archives. – Jonesey95 (talk) 21:46, 14 November 2013 (UTC)

Thanks for the link. One revealing question in that thread was "Will there be pushback from the editing community?". In answer to that question, I am pushing back and asking for an explanation. Boghog (talk) 22:00, 14 November 2013 (UTC)

Actually, no. The needs of the scripting language are not being put before the templates' raison d'être. I look at it as the needs of the editors being put before the needs of the templates. The template should not and does not care how the date is rendered in the article as long as the date provided by the editor comports with the requirements of MOS:DATE so that the code can extract the necessary bits, pieces, and parts required to do it's job.

If we are to keep |day=, |month=, and |year= for the sake of automated formatting as you suggest, then we will have to resurrect |dateformat= so that editors can specify the rendered date format in keeping with WP:CITE and WP:STRONGNAT. We should probably, for completeness sake, add a new parameter |season=. Even if we do this, nothing will ensure that the date format, citation-to-citation, will be consistent within an article. It isn't possible for CS1 templates to see an article's {{use dmy dates}} template for example, so Editor A might comply with {{use dmy dates}} but Editor B might not.

Should we then also look at all of the other dates used in CS1 citations? Consistency would suggest that other dates used in CS1 citations, |archivedate=, |laydate=, |accessdate=, |embargo=, etc. should also be handled the same way. I don't see editors making much use of separate day/month/year parameters for these anymore than I see them using individual day/month/year parameters for the main date.

I can't speak for any editor except myself, but I would much rather type |date=21 January 1986 than |day=21 |month=January |year=1986 |dateformat=dmy (21 characters vs 49 characters). If I get it wrong, spelling, punctuation, whatever, then the associated error message reminds me and I fix it.

In late 2008 and early 2009, perhaps you will remember this, editors experimented with automated date formatting where dates were converted to either dmy or mdy date format according to the state of |dateformat=. Apparently this did not go over well. Here is a brief history:

12 December 2008: DateFormat introduced to {{citation/core}} for |accessdate=
7 February 2009: DateFormat introduced to {{citation/core}} for |date=
10 February 2009: DateFormat removed (self-reverted within the hour); Related talk: Template_talk:Date#Argh!
10 February 2009: DateFormat replaced with {{citation/fixdate}}; Related talk: Template_talk:Citation/Archive 3#Year_bug
12 February 2009: Date formatting of any sort removed; Related talk: Template_talk:Citation/core/Archive 2#Please don't mess with editor's date format

—Trappist the monk (talk) 00:29, 15 November 2013 (UTC)

One can imagine a future time in which all date-holding parameters (e.g. date=, accessdate=, etc.) with dates in valid formats could be instructed to display dates either (a) according to a user's preference or (b) according to a dmy style chosen for the document or (c) both, with one setting overriding the other. To an extent, something like that was what some of the editors in the above threads were trying for.

In order to get to that future state, it would be ideal if (a) all date-holding parameters contained valid dates, and (b) all date-holding parameters contained the complete date to be displayed. Having |date= behave differently from all of the other date-holding parameters (i.e. |month= and |day= need to be coded for separately when formatting |date=) would be an impediment to smooth implementation of this future date-formatting utopia.

I know what you're thinking: "Jonesey95, are you going to smoke that whole thing, or are you going to pass it around?" Well, maybe I'm talking crazy, but I can dream, can't I? I think we are a LOT closer to this future state now — with the implementation of Lua modules for cite templates — than we were back in 2009.

Boghog: What is the case for keeping |month=, given that the Lua module can parse dates to see if they are valid? If consistent date formatting is the goal, I believe that including the month (and day) in |date= is one of two steps on the path, along with fixing inconsistencies flagged in Category:CS1 errors: dates.

Boghog: If consistency is your goal, are you hoping for |month= parameters for each of the date-holding parameters? – Jonesey95 (talk) 01:23, 15 November 2013 (UTC)

Thanks Trappist and Jonesey95 for the detailed explanations. However I am still not convinced that the month parameter needs to be deprecated. The primary argument for deprecating month seems to be that it is no longer needed to generate metadata. However the month and year parameters have have been implicitly used for quite some time to insure consistency in displayed dates, especially in articles where the citation templates have been generated using this widely used tool. That alone is reason enough not to deprecate the month parameter. Concerning journal articles, the publication year is usually sufficient, but including month is sometimes useful to establish priority between publications. Publication days are much less frequently used. Other date-holding parameters such as archivedate, laydate, and embargo are much less frequently used and therefore are less of a concern. Finally adding an accessdate to a journal article is not even appropriate.

I prefer to keep things as simple as possible. Hence I would oppose adding new month and day parameters to all the other date-holding parameters. At the same time, the month parameter has been widely used, and hence I believe it should be retained indefinitely for the sake of backwards compatibility. Concatenating year and month parameter values easily produces a valid date and the amount of code required for this concatenation is minimal.

If you insist that the month parameter should be deprecated, it would be better to first seek community support and also consensus on exactly what should replace it, and then have a bot systematically make the change throughout Wikipedia. Boghog (talk) 19:21, 17 November 2013 (UTC)

There is that insist word again.

Deprecation does not mean disallowed; |day= has been deprecated for a long time yet is still usable in CS1 citations. The |day=, |month=, and |year= parameters, as I understand it weren't added to support metadata. Something about Wikimedia's #time parser function returned an error message that could be avoided if the template concatenated the three |day=, |month=, and |year= parameters into a single date. Once the #time parser was fixed, |day= and |month= were no longer required; |year= still served as a short form reference disambiguator for {{harv}} and {{sfn}} referencing. With the most recent change to Module:Citation/CS1, the "need" for |year= is eliminated.

I am glad to not have to do individual day/month/year parameters for the remaining date-holding parameters.

—Trappist the monk (talk) 13:46, 18 November 2013 (UTC)

To summarize the above discussion, it appears that we both agree that the month parameter is deprecated but is still usable. My only request is to stop proactive removal of the month parameter from cite journal templates by "third party" editors without consulting the content creation editors. This proactive removal seems to be triggered by the Category:Pages_containing_cite_templates_with_deprecated_parameters.

The apparent paradox of favoring retaining the month parameter while eliminating the "first1, last1, first2, last2" parameters has not escaped me. I also note that the paradox is symmetrical. How does one justify removal of the month parameter while retaining "first1, last1, first2, last2, ..." parameters? The justification for retaining the former while eliminating the later is pragmatic. Including the month parameter increases the length of the cite journal template by at most only a few characters. If there are a large number of authors, including the the "first1, last1, first2, last2, ..." parameters can increase the length of the cite journal template by hundreds of characters. Boghog (talk) 19:23, 21 November 2013 (UTC)

Who favors eliminating "first1, last1, first2, last2" parameters? Where was this discussed? Please cut and paste a timestamp so the location in the talk page can be found.

Eliminating first1, last1, etc. is not equivalent to reformatting a date from month=November day=21 year=2013 into date=November 21, 2013. It is usually possible to automatically parse a full date into the component parts, if desired. It is not possible to automatically parse a string such as "Chen Teng-Bin" into first and last names. So eliminating first1, last1, etc. removes information. Jc3s5h (talk) 20:11, 21 November 2013 (UTC)

The link was supplied above. Just to clarify, I am not proposing that we eliminate "first1, last1, first2, last2" parameters. It is just that I prefer not to use them. Boghog (talk) 20:22, 21 November 2013 (UTC)

If you don't use them, you will be unable to use |ref=harv and the {{harv}} and {{sfn}} templates to make links from elsewhere to the citations. —David Eppstein (talk) 23:28, 21 November 2013 (UTC)

You can use {{cite ... | ref = {{sfnRef|YOURANCHORLINK}} }} I think. Shyamal (talk) 02:15, 22 November 2013 (UTC)

I never use |ref=harv and the {{harv}} and {{sfn}} templates either. Unnecessarily complicated. In the rare cases when I need to specify different page numbers from the same citation, I use {{rp}} instead. Boghog (talk) 13:31, 22 November 2013 (UTC)

checkisbn() fix

checkisbn() is the function that ensures that ISBNs are valid – ignoring the placement of hyphens which is a rather complex issue. The current live version of checkisbn allows non-isbn characters or punctuation in the isbn as long as the number is the correct length and the check digit is correct when these extraneous characters are stripped out.

Cite book comparison
Wikitext	`{{cite book\|isbn=1a2a3a4a5a6a7a8a9aX\|sandbox=yes\|title=Title}}`
Live	Title. ISBN 1a2a3a4a5a6a7a8a9aX. `{{cite book}}`: Check `\|isbn=` value: invalid character (help); Unknown parameter `\|sandbox=` ignored (help)
Sandbox	Title. ISBN 1a2a3a4a5a6a7a8a9aX. `{{cite book}}`: Check `\|isbn=` value: invalid character (help); Unknown parameter `\|sandbox=` ignored (help)

Fixed in the sandbox.

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

So are you saying that the ISBN-checking code will soon work in the same way that the current ISSN-checking code works? Only 0-9, X, and regular dashes will be permitted characters in ISBN parameter values? Have you considered permitting spaces (and rendering the ISBN without spaces)? Just asking for clarification. – Jonesey95 (talk) 21:09, 15 November 2013 (UTC)

As I understand it, the only permissible characters in an ISBN are the digits 0 through 9, the hyphen, and the uppercase X. Because of the complex mechanism that defines where hyphens are placed in an ISBN, I, and apparently the original author of checkisbn(), have chosen to assume that the editor adding the ISBN to a citation has correctly placed the hyphens. With ISSN, it was easy to always render the value correctly because the hyphen is always between the two 4-digit groups. Unlike ISSN, the ISBN code renders the editor's |isbn= value formatting without modification.

Because spaces are not part of the currently permissible character set, ISBNs containing spaces will fail checkisbn().

The thing that lead me to make this change was a whole series of ISBNs without formatting, no hyphens or spaces, but each had a trailing comma (|isbn=123456789X,). These should have failed checkisbn() because any validation code should check a parameter's value in its entirety.

—Trappist the monk (talk) 23:30, 15 November 2013 (UTC)

Thanks for the explanation. That makes sense. The checkissn code correctly finds ISSNs with commas at the end. I wrote a little AutoEd script to fix that error and a lot of other ISSN craziness and deployed it over the last few days. I was able to fix about 30% of the 1,100 or so ISSN errors. Most of the rest need manual intervention. – Jonesey95 (talk) 23:50, 15 November 2013 (UTC)

It is not a good idea to reject spaces in ISBNs. Many books have the ISBN printed with spaces where the hyphens "ought" to be, and that should not make them invalid: the ordinary person should be able to key in the ISBN exactly as it is printed, without fear of an error message simply because they didn't change spaces into hyphens. Similarly, the hyphenation pattern is a convenience to aid human readability, and has no significance in the identification of a book; misplaced hyphens are commonly encountered in the field, and so should not be rejected. The statement by Trappist the monk "the only permissible characters in an ISBN are the digits 0 through 9, the hyphen, and the uppercase X" is basically true, but only if qualified: "after removing any spaces and hyphens, the only permissible characters in an ISBN are the digits 0 through 9~~, the hyphen,~~ and the uppercase X". Also please note that the uppercase X is only valid in an ISBN-10 - not in an ISBN-13.

Cite book comparison
Wikitext	`{{cite book\|isbn=123 4567 89X\|sandbox=yes\|title=Title}}`
Live	Title. ISBN 123 4567 89X. `{{cite book}}`: Unknown parameter `\|sandbox=` ignored (help)
Sandbox	Title. ISBN 123 4567 89X. `{{cite book}}`: Unknown parameter `\|sandbox=` ignored (help)

—Trappist the monk (talk) 11:57, 4 December 2013 (UTC)

Relocation of date handling code

Code that handles various aspects of |date=, |year=, and |publicationdate= is rather scattered across the whole of the module. In the sandbox I have attempted to consolidate as much of that code into a single place as possible.

Legacy concatenation of |day=, |month=, and |year= into |date= has been moved ahead of the date validation code so that the result of the concatenation can be validated.

Cite book comparison
Wikitext	`{{cite book\|day=20\|month=November\|sandbox=yes\|title=Title\|year=2013}}`
Live	Title. 2013. `{{cite book}}`: Unknown parameter `\|day=` ignored (help); Unknown parameter `\|month=` ignored (help); Unknown parameter `\|sandbox=` ignored (help)
Sandbox	Title. 2013. `{{cite book}}`: Unknown parameter `\|day=` ignored (help); Unknown parameter `\|month=` ignored (help); Unknown parameter `\|sandbox=` ignored (help)

COinS metadata in current live version contains year with CITEREF disambiguator if present when it should contain the whole concatenated date without disambiguator:

Live:

'"`UNIQ--templatestyles-000000CC-QINU`"'<cite class="citation book cs1">''Title''. 2013a.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Title&rft.date=2013&rfr_id=info%3Asid%2Fwiki.riteme.site%3AModule+talk%3ACitation%2FCS1%2FArchive+8" 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>; <span class="cs1-visible-error citation-comment">Unknown parameter <code class="cs1-code">&#124;day=</code> ignored ([[Help:CS1 errors#parameter_ignored|help]])</span>; <span class="cs1-visible-error citation-comment">Unknown parameter <code class="cs1-code">&#124;month=</code> ignored ([[Help:CS1 errors#parameter_ignored|help]])</span>

New:

'"`UNIQ--templatestyles-000000CE-QINU`"'<cite class="citation book cs1">''Title''. 2013a.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Title&rft.date=2013&rfr_id=info%3Asid%2Fwiki.riteme.site%3AModule+talk%3ACitation%2FCS1%2FArchive+8" 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>; <span class="cs1-visible-error citation-comment">Unknown parameter <code class="cs1-code">&#124;day=</code> ignored ([[Help:CS1 errors#parameter_ignored|help]])</span>; <span class="cs1-visible-error citation-comment">Unknown parameter <code class="cs1-code">&#124;month=</code> ignored ([[Help:CS1 errors#parameter_ignored|help]])</span>

CS1 will use |publication-date= when |date= and |year= are omitted or left blank. That code has also been moved ahead of dates validation.

Cite book comparison
Wikitext	`{{cite book\|publication-date=12 March 2013\|sandbox=yes\|title=Title}}`
Live	Title. 12 March 2013. `{{cite book}}`: Unknown parameter `\|sandbox=` ignored (help)
Sandbox	Title. 12 March 2013. `{{cite book}}`: Unknown parameter `\|sandbox=` ignored (help)

As with the concatenated date, COinS metadata in current live version contains year with CITEREF disambiguator if present when it should contain the whole concatenated date without disambiguator:

Live:

'"`UNIQ--templatestyles-000000D6-QINU`"'<cite class="citation book cs1">''Title''. 12 March 2013a.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Title&rft.date=2013-03-12&rfr_id=info%3Asid%2Fwiki.riteme.site%3AModule+talk%3ACitation%2FCS1%2FArchive+8" 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>

New:

'"`UNIQ--templatestyles-000000D8-QINU`"'<cite class="citation book cs1">''Title''. 12 March 2013a.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Title&rft.date=2013-03-12&rfr_id=info%3Asid%2Fwiki.riteme.site%3AModule+talk%3ACitation%2FCS1%2FArchive+8" 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>

Erroneous concatenated and |publication-date= derived dates will produce error messages that don't accurately identify the failing parameter but rather identify |date= because |day= and |month= are not individually tested and |year= when promoted to |date= is unset. Similarly, |publication-date= is unset when promoted to |date=. Appropriate changes to the error message documentation will be needed to explain this condition.

Cite book comparison
Wikitext	`{{cite book\|day=20\|month=Novenber\|title=Title\|year=2013}}`
Live	Title. 2013. `{{cite book}}`: Unknown parameter `\|day=` ignored (help); Unknown parameter `\|month=` ignored (help)
Sandbox	Title. 2013. `{{cite book}}`: Unknown parameter `\|day=` ignored (help); Unknown parameter `\|month=` ignored (help)

Cite book comparison
Wikitext	`{{cite book\|publication-date=12 March 20l3\|title=Title}}`
Live	Title. 12 March 20l3. `{{cite book}}`: Check date values in: `\|publication-date=` (help)
Sandbox	Title. 12 March 20l3. `{{cite book}}`: Check date values in: `\|publication-date=` (help)

—Trappist the monk (talk) 13:14, 20 November 2013 (UTC)

Testing a scenario that I'm seeing a lot (separate entries for day, month, and year, but with |date= used for the day):

Cite book comparison
Wikitext	`{{cite book\|date=20\|month=November\|sandbox=yes\|title=Title\|year=2013}}`
Live	Title. 20. `{{cite book}}`: Check date values in: `\|date=` and `\|year=` / `\|date=` mismatch (help); Unknown parameter `\|month=` ignored (help); Unknown parameter `\|sandbox=` ignored (help)
Sandbox	Title. 20. `{{cite book}}`: Check date values in: `\|date=` and `\|year=` / `\|date=` mismatch (help); Unknown parameter `\|month=` ignored (help); Unknown parameter `\|sandbox=` ignored (help)

That looks right to me. – Jonesey95 (talk) 15:51, 20 November 2013 (UTC)

Writing this mostly to make sure my thinking is rational. It concerns the promotion of various dates. Year, Date, and PublicationDate are internal variable that receive values from |year=, |date= and |publication-date=.

Date is set from Year (first) or PublicationDate (second) when |date= not set. The source for Date (Year or PublicationDate) is then unset.

When Date is set from |date= it is superior to Year or PublicationDate. The rendered date, the year used in CITEREF, and the date used in the COinS metadata are all extracted from Date.

Currently, Year is the third alternate for OCinSoutput.Date. Once Year is promoted to Date, COinS_date holds a valid date (if the promoted Date is valid) so there is no need to set Year because OCinSoutput.Date will get its value from COinS_date. If the promoted Date is invalid, OCinSoutput.Date gets its value from the invalid Date. This seems wrong. Is it right to include an invalid date in the COinS?

Year is the first alternate for CITEREF. Year is promoted to Date when |date= is not set. From a valid Date, dates() extracts anchor_year which is the second alternate for CITEREF. It is necessary to keep Year when it is not promoted to Date (when both |date= and |year= are set) because this is the legacy case where Date is used to display the date in the rendered citation and Year is used to make the CITEREF (usually used when an author has multiple publications in the same year).

The same applies to PublicationDate if it is promoted to Date.

All of the above examples should still be working properly if what I've just written is true (and the changes made to CS1/sandbox are correct). Also this additional case where |date= and |year= are both set.

'"`UNIQ--templatestyles-000000EE-QINU`"'<cite class="citation book cs1">''Title''. 12 March 2013.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Title&rft.date=2013-03-12&rfr_id=info%3Asid%2Fwiki.riteme.site%3AModule+talk%3ACitation%2FCS1%2FArchive+8" 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><span class="cs1-maint citation-comment">CS1 maint: date and year ([[:Category:CS1 maint: date and year|link]])</span>

Ok, so either my thinking is skewed or the implementation is wrong. In the above examples, CITEREF isn't properly including the year for valid promoted dates.

—Trappist the monk (talk) 17:14, 20 November 2013 (UTC)

Implementation.

—Trappist the monk (talk) 18:07, 20 November 2013 (UTC)

More blather about date/year consolidation and promotion.

In the current code, PublicationDate is tested against Date and Year. If PublicationDate matches either of those, then PublicationDate is set to an empty string and not displayed in the rendered citation:

Cite book comparison
Wikitext	`{{cite book\|date=2013\|publication-date=2011\|ref=harv\|title=Title\|year=2012}}`
Live	Title (published 2011). 2013. `{{cite book}}`: Check date values in: `\|year=` / `\|date=` mismatch (help); Invalid `\|ref=harv` (help)
Sandbox	Title (published 2011). 2013. `{{cite book}}`: Check date values in: `\|year=` / `\|date=` mismatch (help); Invalid `\|ref=harv` (help)
example 1: no match; year used for CITEREF anchor so not displayed;

Cite book comparison
Wikitext	`{{cite book\|date=2013\|publication-date=2013\|ref=harv\|title=Title\|year=2011}}`
Live	Title. 2013. `{{cite book}}`: Check date values in: `\|year=` / `\|date=` mismatch (help); Invalid `\|ref=harv` (help)
Sandbox	Title. 2013. `{{cite book}}`: Check date values in: `\|year=` / `\|date=` mismatch (help); Invalid `\|ref=harv` (help)
example 2: publication date same as date

Cite book comparison
Wikitext	`{{cite book\|date=2013\|publication-date=2011\|ref=harv\|title=Title\|year=2011}}`
Live	Title (published 2011). 2013. `{{cite book}}`: Check date values in: `\|year=` / `\|date=` mismatch (help); Invalid `\|ref=harv` (help)
Sandbox	Title (published 2011). 2013. `{{cite book}}`: Check date values in: `\|year=` / `\|date=` mismatch (help); Invalid `\|ref=harv` (help)
example 3: publication date same as year

I believe that in examples 2 & 3 above, CS1/sandbox is correct in both while CS1/live is only correct in example 2.

—Trappist the monk (talk) 14:53, 21 November 2013 (UTC)

Deprecated parameter detection

I have changed the mechanism that is used to detect deprecated parameters. In CS1/live, deprecated_parameter() is called whenever a deprecated parameter is used. This works but does sort of clutter the code with calls to deprecated_parameter().

The live version of Module:Citation/CS1/Whitelist is a list of all of the parameters that CS1 recognizes. CS1 uses the whitelist to identify parameters that it doesn't recognize. CS1 scans the list of parameters in a citation and compares the citation's parameters against the whitelist.

Members of the whitelist have the form ['parameter name'] = true. All of the parameters are set to true. It seemed to me that we could set a parameter's value to false to indicate that the parameter is deprecated but still supported; and to nil to indicate that the parameter is not supported.

So, I've changed validate() to call deprecated_parameter() when a citation's parameter is listed in the whitelist as ['parameter name'] = false. This has an additional advantage in that some parameters might be missed because they aren't encountered in the code if another parameter is missing. |day= and |month= are missed by the current detection when |year= is not part of the citation.

Cite book comparison
Wikitext	`{{cite book\|day=22\|title=Title}}`
Live	Title. `{{cite book}}`: Unknown parameter `\|day=` ignored (help)
Sandbox	Title. `{{cite book}}`: Unknown parameter `\|day=` ignored (help)

—Trappist the monk (talk) 14:12, 22 November 2013 (UTC)

Another date check question

Just curious why month abbreviations with a period aren't acceptable, but abbreviations without a period are ok. They both seem to be acceptable per Wikipedia:MOS#Months and seasons Thanks! GoingBatty (talk) 02:48, 10 December 2013 (UTC)

Cite news comparison
Wikitext	`{{cite news\|date=Sep. 24, 1890\|newspaper=York Herald\|page=4\|title=Births, deaths, marriages}}`
Live	"Births, deaths, marriages". York Herald. Sep. 24, 1890. p. 4. `{{cite news}}`: Check date values in: `\|date=` (help)
Sandbox	"Births, deaths, marriages". York Herald. Sep. 24, 1890. p. 4. `{{cite news}}`: Check date values in: `\|date=` (help)

Cite news comparison
Wikitext	`{{cite news\|date=Sep 24, 1890\|newspaper=York Herald\|page=4\|title=Births, deaths, marriages}}`
Live	"Births, deaths, marriages". York Herald. Sep 24, 1890. p. 4.
Sandbox	"Births, deaths, marriages". York Herald. Sep 24, 1890. p. 4.

The standard I chose for date formats is MOS:DATEFORMAT. There, short month names do not have terminal periods.

—Trappist the monk (talk) 04:02, 10 December 2013 (UTC)

@Trappist the monk: - Aha! Thanks for the info. I posted a question at Wikipedia talk:Manual of Style/Dates and numbers#Abbreviated months in citations about the discrepancy between the two MOS pages. Thanks! GoingBatty (talk) 04:53, 10 December 2013 (UTC)

Update to the live CS1 module week of 2013-12-08

Toward the end of this week I propose to update Module:Citation/CS1 to match Module:Citation/CS1/sandbox (diff), Module:Citation/CS1/Configuration to match Module:Citation/CS1/Configuration/sandbox (diff) and Module:Citation/CS1/Whitelist to match Module:Citation/CS1/Whitelist/sandbox (diff). This update is, for the most part, bug fixes and minor enhancements:

Fix Script Error bug that occured when |doi_brokendate= did not contain a year value;
Fix doi() so that dois with invalid doi_brokendate categorize to "Pages with inactive DOIs" and not to "Pages with DOIs inactive since";
Change deprecated_parameter() to emit a single error message; (discussion}
Fix bug in checkisbn() that stripped-out non-isbn characters before validation so that ISBNs were declared good as long as the stripped (not displayed) version of the isbn passed the remaining tests; (discussion)
Year and PublicationDate promotion to Date consolidation; (discussion)
Change validate() and the whitelist to recognize deprecated parameters; (discussion)
Change pmc/url handling; (discussion)
Modify |encyclopedia, |title and |article parameter handling for cite encyclopedia; (discussion)

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

These are great improvements. Thank you for your continued diligent work, flexibility, and reasonable discussion of proposed changes.

Do you have support for day and year ranges on a to-do list somewhere? Examples of valid day and year ranges were provided in this discussion and this discussion. There are a few thousand articles that are displaying date errors due to MOSDATE-valid year ranges that are not viewed as valid by the module.

No hurry. I just want to make sure this one doesn't slip through a crack. – Jonesey95 (talk) 16:30, 8 December 2013 (UTC)

The number of pages in Category:CS1 errors: dates should drop by some 5000 because of changes I recently made to {{venn}} (now {{acad}}).

I've added this topic to Feature requests.

—Trappist the monk (talk) 17:32, 8 December 2013 (UTC)

Done.

—Trappist the monk (talk) 18:37, 14 December 2013 (UTC)

Date check

Hi, can the date check be modified to detect the absence of a space between the day and the month?

Cite news comparison
Wikitext	`{{cite news\|date=28June 1890\|newspaper=York Herald\|page=4\|title=Births, deaths, marriages}}`
Live	"Births, deaths, marriages". York Herald. 28June 1890. p. 4. `{{cite news}}`: Check date values in: `\|date=` (help)
Sandbox	"Births, deaths, marriages". York Herald. 28June 1890. p. 4. `{{cite news}}`: Check date values in: `\|date=` (help)

Keith D (talk) 18:16, 9 December 2013 (UTC)

Yes, that can be fixed; thanks for finding it. Because an update to the live module is pending, I won't be making any changes to the sandbox until after the update.

—Trappist the monk (talk) 18:59, 9 December 2013 (UTC)

Also this similar one, in case GoingBatty hasn't pointed it out:

Cite news comparison
Wikitext	`{{cite news\|date=June28, 1890\|newspaper=York Herald\|page=4\|title=Births, deaths, marriages}}`
Live	"Births, deaths, marriages". York Herald. June28, 1890. p. 4. `{{cite news}}`: Check date values in: `\|date=` (help)
Sandbox	"Births, deaths, marriages". York Herald. June28, 1890. p. 4. `{{cite news}}`: Check date values in: `\|date=` (help)

Oh heck, let's blow it out:

Cite news comparison
Wikitext	`{{cite news\|date=June 28,1890\|newspaper=York Herald\|page=4\|title=Births, deaths, marriages}}`
Live	"Births, deaths, marriages". York Herald. June 28,1890. p. 4. `{{cite news}}`: Check date values in: `\|date=` (help)
Sandbox	"Births, deaths, marriages". York Herald. June 28,1890. p. 4. `{{cite news}}`: Check date values in: `\|date=` (help)

Cite news comparison
Wikitext	`{{cite news\|date=28 June1890\|newspaper=York Herald\|page=4\|title=Births, deaths, marriages}}`
Live	"Births, deaths, marriages". York Herald. 28 June1890. p. 4. `{{cite news}}`: Check date values in: `\|date=` (help)
Sandbox	"Births, deaths, marriages". York Herald. 28 June1890. p. 4. `{{cite news}}`: Check date values in: `\|date=` (help)

So in general, make sure there's a space where there should be a space. – Jonesey95 (talk) 06:12, 13 December 2013 (UTC)

Checking for additional unreasonable dates

Take a look at this diff, at Line 1,591. The new bot code (in supervised testing) fixed the date error, but the accessdate is years into the future. I wonder if the CS1 module should check for unreasonable future dates. – Jonesey95 (talk) 06:08, 13 December 2013 (UTC)

Also, the code could check accessdate and archivedate years to ensure that they start with '199' (maybe), '200', or '201', since those are currently the only reasonable decades when those dates could occur. I think. There may be other date-holding parameters that should be limited to dates when WP existed. – Jonesey95 (talk) 14:19, 13 December 2013 (UTC)

It would seem that any future date is invalid for all date-holding parameters except |embargo=. I agree that |accessdate= and |archivedate= are invalid prior to 1990. Conceivably, |accessdate= is invalid prior to the Wikipedia launch date of 15 January 2001. Founding date for Internet Archive is 1996; for WebCite, 1997.

It is possible to detect these types of inappropriate dates.

—Trappist the monk (talk) 14:45, 13 December 2013 (UTC)

I have records of accessing http://webexibits.com/calendars and http://www.time.gov in 1999 in connection with work I was doing in preparation for Y2K. (The question was whether 2000 was a leap year; the kinds of sources typically found in a programmer's bookshelf conflicted, so it was necessary to search far and wide for a reliable source. If I remember correctly, I finally found copy of the Calendar (New Style) Act 1750. Presumably others also have information about how particular web pages (or even Gopher pages) appeared in the 1990s, and might have occasion to cite them on Wikipedia.

As for future dates, sometimes publishers begin selling a book in one year but list the copyright date (which is usually treated as the publication date) as the next year. Something like this happened with the Explanatory Supplement to the Astronomical Almanac 3rd ed., except that it does not carry a copyright notice (perhaps because much of it was prepared by employees of the US Naval Observatory in the course of their duties). Jc3s5h (talk) 15:02, 13 December 2013 (UTC)

I would not be quite as strict as Trappist proposes. I think near-future dates are OK, at least in |date=. For example, the "January 2014" issue of pretty much any monthly magazine is already in print, even though that date is in the future. I would propose starting by marking any publication dates more than a few months or even a year in the future as errors. That would give us some idea about how many of these malformed dates are out there and alert us to legitimate future dates that we might not be thinking of right now. We could then modify the code accordingly. WP:CRYSTAL may be relevant here. – Jonesey95 (talk) 23:24, 13 December 2013 (UTC)

distributor parameter?

Many of the doc pages say |distributor= is a parameter, (alias of |publisher=,) but it doesn't seem to work. The documentation should be updated, if it is no longer supported, but I asked here, first, in case it's a bug. —PC-XT+ 08:46, 13 December 2013 (UTC)

I see it in Module:Citation/CS1/Configuration, so I'm thinking it should be supported. It looks like function selectone, or maybe argument_wrapper may not be accepting it... —PC-XT+ 09:04, 13 December 2013 (UTC)

|distributor= is listed as one of the parameters that is made part of a citation's COinS metadata so in that context is listed on all of the CS1 documentation pages. Only {{cite sign}} lists |distributor= as an alias of |publisher=. |distributor= is not a parameter that is listed in Module:Citation/CS1/Whitelist which suggests that at some point a decision was taken to omit it.

Because it is only documented in {{cite sign}}, I'm inclined to deprecate it in favor of its more common alias |publisher=.

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

Thanks for the reply. Yes, {{cite sign}} was the only one that called it an alias, that I remember. The others only listed it next to publisher, and I missed any explanation of its use in metadata. We can replace it with |publisher=, then. —PC-XT+ 22:53, 13 December 2013 (UTC)

Date error reported incorrectly

Hi, there appears to be a problem with {{cite book}} reporting a date field error when |date= is not used.

Cite book comparison
Wikitext	`{{cite book\|first=Richard Stephen ‬\|last=Charnock\|page=76\|publisher=Houlston and Wright\|title=‪Local etymology: a derivative dictionary of geographical names‬\|url=http://books.google.com/books?id=apcmAAAAMAAJ\|year=1859‬}}`
Live	Charnock, Richard Stephen ‬ (1859‬). ‪Local etymology: a derivative dictionary of geographical names‬. Houlston and Wright. p. 76. `{{cite book}}`: Check date values in: `\|year=` (help)CS1 maint: year (link)
Sandbox	Charnock, Richard Stephen ‬ (1859‬). ‪Local etymology: a derivative dictionary of geographical names‬. Houlston and Wright. p. 76. `{{cite book}}`: Check date values in: `\|year=` (help)CS1 maint: year (link)

Keith D (talk) 00:44, 15 December 2013 (UTC)

The citation above has non-printing characters in |title=, |first=, and |year=. Those characters are causing the error message you are seeing. Here's the citation without the non-printing characters.

Cite book comparison
Wikitext	`{{cite book\|first=Richard Stephen\|last=Charnock\|page=76\|publisher=Houlston and Wright\|title=Local etymology: a derivative dictionary of geographical names\|url=http://books.google.com/books?id=apcmAAAAMAAJ\|year=1859}}`
Live	Charnock, Richard Stephen (1859). Local etymology: a derivative dictionary of geographical names. Houlston and Wright. p. 76.
Sandbox	Charnock, Richard Stephen (1859). Local etymology: a derivative dictionary of geographical names. Houlston and Wright. p. 76.

To find the characters, I pasted the whole citation above into a text editor and asked it to show me all of the spaces and other invisible characters. – Jonesey95 (talk) 01:00, 15 December 2013 (UTC)

(edit conflict) The problem here is that you have an invisible formatting character - known as U+202C - between the year and the next pipe.

Cite book comparison
Wikitext	`{{cite book\|first=Richard Stephen ‬\|last=Charnock\|page=76\|publisher=Houlston and Wright\|title=‪Local etymology: a derivative dictionary of geographical names‬\|url=http://books.google.com/books?id=apcmAAAAMAAJ\|year=1859}}`
Live	Charnock, Richard Stephen ‬ (1859). ‪Local etymology: a derivative dictionary of geographical names‬. Houlston and Wright. p. 76.
Sandbox	Charnock, Richard Stephen ‬ (1859). ‪Local etymology: a derivative dictionary of geographical names‬. Houlston and Wright. p. 76.

In your original, put the cursor between the "5" and the "9", highlight to after the pipe, press Delete and retype the "9" and the pipe. I found the character using Unicode Code Converter v7.05 - paste text into the green "Mixed input" box and click the Convert button above that. --Redrose64 (talk) 01:06, 15 December 2013 (UTC)

(edit conflict)The error message says that there is a problem with |date= because |year= is promoted to an internal variable called Date. Yeah, a better error message is in order.

—Trappist the monk (talk) 01:12, 15 December 2013 (UTC)

Trappist the monk, this error message said "Check date values in: |year=" (not |date=) until the sandbox was copied to the live module in the last day or so. (It said "Check date values in: |date=" when the problem was in the date parameter.) I looked through the diff but was unable to figure out which part of the code change caused this change. – Jonesey95 (talk) 15:30, 15 December 2013 (UTC)

Right, it did. In Module:Citation/CS1 search for "promote" (without quotes). This is where the separate parameters |day=, |month=, and |year= are lumped together into a dmy format variable called Date. About 20 lines further on is the function dates(). It gets a table of ['key']=value pairs one of which is ['date']=Date. When there is an error, the error message uses the ['key'], in this case ['date'], to identify the date-holding parameter that is in error.

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

Question about date range for magazines

Some magazines are published with date ranges, such as this reference from 12-hour clock:

Cite journal comparison
Wikitext	`{{cite journal\|accessdate=22 April 2012\|date=21–27 May 1983\|title=TVTimes\|url=http://forums.doyouremember.co.uk/threads/8061-TVTimes-magazine-21-27-May-1983-part1}}`
Live	"TVTimes". 21–27 May 1983. Retrieved 22 April 2012. `{{cite journal}}`: Cite journal requires `\|journal=` (help)
Sandbox	"TVTimes". 21–27 May 1983. Retrieved 22 April 2012. `{{cite journal}}`: Cite journal requires `\|journal=` (help)

Since the magazine cover shows "21–27 May 1983", should this really be considered an error? Thanks! GoingBatty (talk) 04:24, 15 December 2013 (UTC)

Sort pages per namespace

In the error category Category:Pages containing cite templates with deprecated parameters, is it possible to sort template namespace with a special dummy parameter, like ω, to make it easier to locate all the templates and fix them first?

The reason I ask is, obviously, because templates are transcluded, and errors in templates will have consequences on many other places, so they are the logical first place to start fixing the 250,000+ pages in this error category.

Compare the sorting per namespace in Template:Broken ref, where a dummy parameter is used for a few years already. Debresser (talk) 02:32, 9 December 2013 (UTC)

The Catscan tool is your friend, and the job you describe is essentially done. I use this custom catscan report to keep an eye on Templates with citation errors. I've fixed many thousands of them. The 100 or so that are left are pretty much not fixable, as far as I can see, but only a few (fewer than 20) actually cause errors to appear in articles when they are transcluded. In other words, there are errors in the template's own example of how the parameters are used, but when the templates are used in articles, they do not cause errors to appear in those articles.

An average of 10-20 templates appear in this report every week. Many of those are brand-new templates created by Citation Bot with exactly nine authors. Those articles need | displayauthors = 29 added to them (I can explain the reason for "29" in another discussion). Others are templates whose references have been updated with malformed citations. Still others are added by the job queue, or whatever it is that still adding articles to error categories after the newest ones were added on October 12.

I welcome a discussion on my Talk page (or here, if it won't bore everyone else) if you want to ask about specific templates that might be fixable. I can let you know the reasons why I haven't modified them to remove the errors yet. – Jonesey95 (talk) 03:23, 9 December 2013 (UTC)

I wasn't familiar with that interesting tool. I was sure that with so many pages in this error category, many thousands must be caused by just a few templates. So where did all these articles come from? When we checked for |day= and {{para|month}] only, a few years ago, there were only a few pages here. Its it because of the coauthor parameter then?

That nice tool regardless, is it perhaps still a good idea to add a sorting parameter, as described above? Debresser (talk) 04:49, 9 December 2013 (UTC)

I imagine that someone more clever than I could do a database dump and tell you how many articles contain |day=, |month=, |coauthors=, or the various combinations of those deprecated parameters.

I estimate that no more than a few thousand articles are caused by errors in templates at this point, and the vast majority of those will be "fixed" when the date-checking code is adjusted to allow pain-in-the-neck, relatively rare, but MOSDATE-valid date ranges in the form "1998–1999" or "18–24 December 2001". At this point, my experience over the past half year of fixing citations tells me that citation errors exist one by one because they were introduced one by one. Many, perhaps (guessing here...) 40-60%, will be fixable by bots, but a substantial portion will need to be fixed by hand.

I have no opinion on the proposed sorting parameter. – Jonesey95 (talk) 06:31, 9 December 2013 (UTC)

You'll see they can be fixed, and I will try to do just that now. I am very experienced in this kind of issue, just haven't worked in this field for a long time. See my contributions of today for a few fixes I already made and how I made them. Debresser (talk) 18:45, 14 December 2013 (UTC)

Nice work on the ones you have fixed so far. They look good to me. – Jonesey95 (talk) 20:44, 14 December 2013 (UTC)

Interesting idea, but I'm not sure it will work. If a CS1 template is wrapped within another template, the wrapper template is processed first. The result of that processing is the CS1 template. When the CS1 template is processed, it has no knowledge of any prior processing. A namespace query within the module will return the namespace of the current article, not the namespace of the wrapper template. All of this is simply hypothesizing on my part, I don't actually know if what I've written is true. I stand ready to be corrected.

—Trappist the monk (talk) 13:53, 9 December 2013 (UTC)

I think what the OP intends is that if, for example, an instance of {{cite book}} is included in a template which is then transcluded into many pages, each of those pages will turn up in the management category as well as the template, but only fixing the template will remove them all from the category: having the template appear in the category under a particular sort-code would therefore be useful to detect this kind of situation. However I think Jonesey95 has already thought of this, and their explanation of why this is not a panacea makes much sense. HTH HAND —Phil | Talk 14:47, 13 December 2013 (UTC)

I understand that, but Module:Citation/CS1 only sees what the wrapper template gives it. Module:Citation/CS1 does not see, and is not aware of, the wrapper template. The erroneous content that the wrapper-generated CS1 template gives to Module:Citation/CS1 is perceived to come from the CS1 template.

Some mechanism for wrapper templates to pass their identity to Module:Citation/CS1 through the CS1 template would be required so that Module:Citation/CS1 can categorize the page as Editor Debresser suggests. Lacking such a mechanism, Editor Jonesey95's catscan will have to suffice.

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

Code question

Resolved

accessdate={{{accessdate}}} should not be cause for an error category Category:CS1 errors: dates since it is legitimate code. Can somebody fix that? Debresser (talk) 18:48, 14 December 2013 (UTC)

Can you provide an example of where this is occurring?

—Trappist the monk (talk) 18:53, 14 December 2013 (UTC)

I circumvented the issue in this edit by adding <noinclude>...</noinclude> tags, and there are more templates with this same issue. Debresser (talk) 20:30, 14 December 2013 (UTC)

Hmm, no |accessdate= in that template. But, if that template is typical of the problem as you see it, it isn't so much an issue with Module:Citation/CS1 as it is with the wrapper template that passes its various parameters to the CS1 template. You can see the {{{id}}} in the url of older versions of {{SIDS-ref}} (example) because {{{id|}}} doesn't have a default value assigned to it; the default might be:{{{id|<default>}}}.

Your solution to the weird display is commonly applied.

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

You're right, it was date={{{date}}} in that example. Okay, I'll continue solving it thus. Debresser (talk) 21:02, 14 December 2013 (UTC)

Likewise date={{dts|format={{{df|dmy}}}|2012|7|25}} causes an error, as in {{2012 Summer Olympics women's football game C1}}, and there the addition of <noinclude>...</noinclude> tags didn't help. Do you have a solution? Perhaps there is something else I missed? Debresser (talk) 22:23, 14 December 2013 (UTC)

I solved that problem in the similar template: {{2012 Summer Olympics United States women's football team roster}} with this:

|accessdate={{date|2012-06-23|{{{df|dmy}}}}}

The problem with {{dts|format={{{df|dmy}}}|2012|7|25}} is that it adds a lot of stuff to a date field; stuff that shouldn't be passed on to the COinS metadata:

25 July 2012

Using {{date}}, doesn't do that:

{{date|2012-06-23|{{{df|dmy}}}}}

→23 June 2012

I also tweaked the documentation a bit, which see.

—Trappist the monk (talk) 22:58, 14 December 2013 (UTC)

Here's a diff that shows a change that Trappist the monk made to fix this problem. – Jonesey95 (talk) 23:03, 14 December 2013 (UTC)

Implemented on some templates. Thanks. Debresser (talk) 01:26, 15 December 2013 (UTC)

Code question 3

Resolved

Why should a code like year=18?? (like in Template:Cite Men-at-the-Bar) or even year=unknown result in an error. This is completely legitimate. Debresser (talk) 23:39, 14 December 2013 (UTC)

|date=nd is currently allowed for "no date", I believe. Since there are over 100,000 articles with date errors, I have been focusing on the ones that are clearly wrong and easily fixable. Collecting other possible allowable dates here on this page is a good idea, and we have been doing so. I suggest moving this question to a new section with a title that is more descriptive, like "Should '18??' and 'unknown' be allowable dates?" That will make it easier for someone to scrub through this page's archives to look for suggestions about changes to the date checking code. – Jonesey95 (talk) 00:19, 15 December 2013 (UTC)

Same with year=c.1736, which I found in Template:Blomefield-ref. Should also be legitimate. Debresser (talk) 04:27, 15 December 2013 (UTC)

Seems "c. YYYY" is yes accepted. Is this rule written down somewhere? Debresser (talk) 08:26, 15 December 2013 (UTC)

See below: "#Omit date validation as too complex". -Wikid77 07:08, 21 December 2013 (UTC)

Thanks for that. Debresser (talk) 16:29, 21 December 2013 (UTC)

Omit date validation as too complex

There are too many valid, but unusual, date formats to clog the cite templates and modules with obtuse, complex rules for date restrictions which then fail to display dates. It is just not cost-effective, when what users have actually complained about was a short name for "accessdate=" as perhaps "acdate=". Years can be just 2-digit, when the century is assumed, so the final year-end month is December 92-98, or December 02-08. Dates can have "c." (circa) or "UNK" (unknown) or "AFT" for after a date. Days could be multiple ranges, as a split-week event: June 3-4/7-8, 2011. So compare:

{cite book|title=AA|year=c.1856} - AA. c.1856. {{cite book}}: Check date values in: |year= (help)
{cite book|title=BB|month=May/June 1997} - BB. {{cite book}}: Unknown parameter |month= ignored (help)
{cite book|title=CC|year=AFT 1857} - CC. AFT 1857. {{cite book}}: Check date values in: |year= (help)CS1 maint: year (link)
{cite book|title=DD|date=December 92-98} - DD. December 92-98. {{cite book}}: Check date values in: |date= (help)
{cite book|title=Proceedings of Conference EE|date=June 3-4/7-8, 2011} - Proceedings of Conference EE. June 3-4/7-8, 2011. {{cite book}}: Check date values in: |date= (help)
{cite news|title=FF|date=3:45 pm, 1 May 2013} - "FF". 3:45 pm, 1 May 2013. {{cite news}}: Check date values in: |date= (help)

With "month=May/June 1997" then no date is shown, but formerly, {cite book/old |title=BB |month= May/June 1997} displayed " BB. May/June 1997. " For the COinS metadata, when a date/time seems too complex, then just extract a year as the date. Most of the date-validation problems should be ignored. In fact, just the user documentation, to explain what formats of dates are valid, versus invalid, would fill an entire page. Wikipedia is about writing the encyclopedia, not codifying a regulatory agency, at the expense of omitting "May/June 1997". -Wikid77 (talk) 07:08, 21 December 2013 (UTC)

I haven't tried printing MOS:DATEFORMAT, but you're right, it is probably more than one printed page long. Styling citations is complex, because there are so many possible variations. Happily, we don't have to write the documentation; the module is just making use of the current MOS. In answer to the specific citations above:

{cite book|title=AA|year=c. 1856} - AA. c. 1856.
{cite book|title=BB|date=May/June 1997} - BB. May/June 1997. {{cite book}}: Check date values in: |date= (help)
{cite book|title=CC|year= 1857|author=AFT} - AFT (1857). CC.
{cite book|title=DD|date=December 92-98} - DD. December 92-98. {{cite book}}: Check date values in: |date= (help)
{cite book|title=Proceedings of Conference EE|date=June 3-4/7-8, 2011} - Proceedings of Conference EE. June 3-4/7-8, 2011. {{cite book}}: Check date values in: |date= (help)
{cite news|title=FF|date=3:45 pm, 1 May 2013} - "FF". 3:45 pm, 1 May 2013. {{cite news}}: Check date values in: |date= (help)

AA: is fine ("c." needs a space after it, per WP:YEAR)

BB: is fine when you use |date= instead of |month=.

CC: I don't know what "AFT" means. If it is an author or a publisher, it should go in the appropriate parameter.

DD: What does "December 92-98" mean? December 92, 1898? December 1992–1998? December 1992 – December 1998? Please provide an example of an actual citation from an actual WP article that uses such a date. We try to work with real citations, not just WP:BEANS-like examples.

EE: Again, please provide an example of an actual citation from an actual WP article that uses such a date. In any event, the proceedings from a conference usually have a date of publication that is subsequent to the date of the conference itself; that is the date that should be used.

FF: I have not yet seen a citation that needs to cite a time of day. Can you provide an example from an actual WP article?

There are definitely date values marked as invalid right now that are valid per MOS:DATEFORMAT. We are discussing those on this page and collecting them for future revisions to the CS1 module. In the meantime, if the red error messages bother you, as you have stated in the past, you can remove or comment out the relevant line that you added to your CSS file. Let me know if you need help with that; I'll be happy to assist (sometimes the red error messages bug me too; that's why I'm working to fix them). – Jonesey95 (talk) 07:37, 21 December 2013 (UTC)

Re case FF: I think Reflinks looks for bare URLs in pages, and attempts to build a {{cite web}} to wrap around that. I believe that it retrives the page pointed to by the URL, and scrapes that for obvious stuff with which to populate params like |title= |author= and |date=. It often makes mistakes, which is why I never use it. These mistakes include: putting the date into |author=, or filling in |date= with both date and time. --Redrose64 (talk) 18:59, 21 December 2013 (UTC)

Reflinks makes plenty of mistakes, including failing to escape the | character in |author=, which puts articles into Category:Pages with citations using unnamed parameters. I use it occasionally, but only with a considerable amount of manual oversight. Many editors use it without checking its output, resulting in citation errors. With any luck, some of them will return to articles when the new ReferenceBot notifies them of their errors. – Jonesey95 (talk) 22:15, 21 December 2013 (UTC)

Technical assistance need in resolving error

Why should Category:Pages using citations with accessdate and no URL be an error category? If I access a book e.g., it would be completely normal that there is no URL. Debresser (talk) 23:40, 14 December 2013 (UTC)

I suggest moving this and any other new topics, like the ones above, to new sections at the bottom of this page rather than creating as a subsection of an unrelated discussion. Answering your question: read the help text at Category:Pages using citations with accessdate and no URL and the documentation for {{cite book}} at Template:Cite_book#URL. |accessdate= is specifically for URLs. – Jonesey95 (talk) 00:15, 15 December 2013 (UTC)

What in the word "accessdate" clarifies that this parameter is only for online sources? Although it does seem logical, being that books are less transient in nature. Debresser (talk) 01:31, 15 December 2013 (UTC)

Not just "less transient", but completely intransient (unless you live in North Korea). If you give sufficient details to identify an individual edition of a book, there is no need to show when you read that book. It's not as if the ink is volatile, causing the words to differ if you read the same edition of the book in ten years time.

Discussion pages - not just here but on Template talk:Cite book and several others - have gone over this issue several times before. They are in the archives.

It's been in the documentation for years that |accessdate= was only relevant if a url was given; the templates have also deliberately failed to display an access date when there was no URL to construct a link with. It's only in the last few months that an error has been displayed. --Redrose64 (talk) 09:30, 15 December 2013 (UTC)

Okay, then see see this edit. Before this edit we had an error category: Pages with citations having wikilinks embedded in URL titles, and after the edit we have Pages using citations with accessdate and no URL, and the only solution is using https://en.wikisource.org/wiki/ instead of |[[s:]]. But that doesn't work, because https://en.wikisource.org/wiki/{{{wstitle|}}} will break if there are spaces in |wstitle=. So, who knows a way out? Debresser (talk) 09:10, 15 December 2013 (UTC)

Day deprecated

Resolved

In this edit. I see the detection of month leading to an error category, and it says in the commentary that |day= is also deprecated. But where is the code that leads to detection of |day= as reason for an error category in the module? Debresser (talk) 12:11, 15 December 2013 (UTC)

That whole ugly mess has been replaced. Pretty much the first thing Module:Citation/CS1 does is to check every parameter that it receives against the list of allowed parameters in Module:Citation/CS1/Whitelist. There, each parameter is assigned a value: true, false, or nil. Acitvely supported parameters are set to true. Deprecated parameters are set to false. Parameters that are no longer supported are set to nil. Unrecognized parameters also return nil.

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

I see that now in the code. And I tested it, just in case. :) Thanks for your reply. Also, please see my suggestion above to make separate error categories for day/month and coauthors. Debresser (talk) 14:16, 16 December 2013 (UTC)

Another date check enhancement

Hi, can the date check be modified to detect the presence of a leading zero on the dates?

Cite news comparison
Wikitext	`{{cite news\|date=08 June 1890\|newspaper=York Herald\|page=4\|title=Births, deaths, marriages}}`
Live	"Births, deaths, marriages". York Herald. 08 June 1890. p. 4. `{{cite news}}`: Check date values in: `\|date=` (help)
Sandbox	"Births, deaths, marriages". York Herald. 08 June 1890. p. 4. `{{cite news}}`: Check date values in: `\|date=` (help)

Keith D (talk) 00:45, 15 December 2013 (UTC)

In my lexicon, leading zeros are the standard. Even if Wikipedia is otherwise, I don't think this qualifies as an "error". Fine if some bot would come along and "fix" this, but more than that would be an exaggeration, imho. Debresser (talk) 16:31, 21 December 2013 (UTC)

WP:BADDATEFORMAT specifically proscribes leading zeros in dates.

—Trappist the monk (talk) 17:55, 21 December 2013 (UTC)

Thanks for the link to the guideline. Nevertheless, I stick to my opinion that this does not make leading zeros into "error", as in Category:Articles with invalid date parameter in template. Does anybody think otherwise? Debresser (talk) 19:00, 21 December 2013 (UTC)

@Debresser: BattyBot is going through to remove the leading zeroes now before the red message is enabled. GoingBatty (talk) 19:36, 21 December 2013 (UTC)

Category:Articles with invalid date parameter in template is not a member of Category:Articles with incorrect citation syntax and not a category used by Module:Citation/CS1.

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

@Trappist the monk So it is probably Category:CS1 errors: dates? The point remains that I do not think it is reason for an error category. Debresser (talk) 21:42, 21 December 2013 (UTC)

@GoingBatty I am not sure that is possible. I thought the error category is immediate. Debresser (talk) 21:45, 21 December 2013 (UTC)

@Debresser: Sorry I wasn't clear. I meant there's a difference between putting an article in a hidden category versus displaying a red message for everyone to see. I agree with adding articles to the hidden category, but would prefer that the bot makes a first pass through the category before enabling the message for everyone. Hope this helps! GoingBatty (talk) 21:58, 21 December 2013 (UTC)

Is that at all possible? Debresser (talk) 22:34, 21 December 2013 (UTC)

@Debresser: Yes, it's possible and being done already. For example, although reference 3 in (143649) 2003 QQ47 includes |date=2006-04-27 last obs, there's no visible error message. You have to enable "Show hidden categories" in your preferences to see Category:CS1 errors: dates. See the text in Category:CS1 errors: dates for more info. GoingBatty (talk) 23:03, 21 December 2013 (UTC)

Suggestion - incorrect month capitalization

When the month is not capitalized, should the reference generate a date error, such as this reference from 2 Minutes to Midnight:

Cite journal comparison
Wikitext	`{{cite journal\|date=may 1992\|first=Anthony\|journal=Metal Attack "Iron Maiden Special"\|last=Noguera\|location=London\|publisher=Rock Team Publishing And Productions Ltd\|title=B-Side Or Be Dead}}`
Live	Noguera, Anthony (may 1992). "B-Side Or Be Dead". Metal Attack "Iron Maiden Special". London: Rock Team Publishing And Productions Ltd. `{{cite journal}}`: Check date values in: `\|date=` (help)
Sandbox	Noguera, Anthony (may 1992). "B-Side Or Be Dead". Metal Attack "Iron Maiden Special". London: Rock Team Publishing And Productions Ltd. `{{cite journal}}`: Check date values in: `\|date=` (help)

Thanks! GoingBatty (talk) 05:58, 15 December 2013 (UTC)

This has been fixed in the sandbox (not by me), as you can now see above. Good catch! – Jonesey95 (talk) 04:52, 17 December 2013 (UTC)

Cool - when it's added live, I'll expand User:BattyBot/CS1 errors-dates to fix them all. Thanks! GoingBatty (talk) 05:32, 17 December 2013 (UTC)

Why wait? User:BattyBot/CS1 errors-dates is already fixing space and leading zero errors that aren't currently caught by the live module so I see no reason not to also fix captialization as well.

—Trappist the monk (talk) 11:43, 17 December 2013 (UTC)

@Trappist the monk: I've updated the rules at User:BattyBot/CS1 errors-dates for this. Like the other rules you mentioned, the bot is not going to pick up most of these issues until the errors are live and the articles are included in the error category. GoingBatty (talk) 00:39, 18 December 2013 (UTC)

Escape hatch

I vaguely recall a discussion of adding a parameter to turn off error checking for a particular citation, for the case of seldom-used parameter values that are legitimate, but don't conform to the pattern that the checking code accepts. I'd like to know the status of this effort. It seems to me a few of the other threads are getting pretty deep into the weeds, and it might be time to say in a few cases "that value is so unlikely you should just add the DO NO CHECK parameter. Jc3s5h (talk) 14:40, 15 December 2013 (UTC)

I think we should collect a list of those potentially acceptable outliers in a section here as we fix the date errors. Since the date errors are still hidden by default (I believe), there is no hurry. Once we have a list of a dozen or so weirdos to discuss, we can discuss them all at once. That's my idea, anyway. – Jonesey95 (talk) 15:28, 15 December 2013 (UTC)

@Jc3s5h: - Another option is that those references could be changed so they don't use one of the CS1 templates. GoingBatty (talk) 15:59, 21 December 2013 (UTC)

We need a version of cites which work, despite the latest problems, more recent than the markup-based {cite_web/old}, such as for "month=May 1997":

{cite news | title=News BB|month=May 1997 } = "News BB". {{cite news}}: Unknown parameter |month= ignored (help)
{cite news/old |title=News BB|month=May 1997} = "News BB". May 1997.
{cite journal | journal=J Science |pmc=12345678 } = Script error
{cite journal/old|journal=J Science |pmc=12345678} = J Science. PMC 12345678. https://www.ncbi.nlm.nih.gov/pmc/articles/PMC12345678/.

The /old versions show the date or PMC, without dying. The Lua Module:Citation/CS1 has become such a twisted convolution of contorted features, during the past 6 months, that it is difficult to read and modify without generating many new errors. It is the age-old problem known as "creeping featurism" where the excessive changes have led to a state of "featured creepyism" as now Luasaurus citehorrorus with bizarre bugs. Let's find an older revision which worked and use that as the escape or lifeboat version, {cite_web/sos} or {cite_journal/sos}. -Wikid77 (talk) 08:37, 21 December 2013 (UTC)

@Wikid77: - BattyBot is now fixing many CS1 date errors, including converting |month=May 1997 to |date=May 1997. GoingBatty (talk) 15:59, 21 December 2013 (UTC)

GoingBatty suggests "another option is that those references could be changed so they don't use one of the CS1 templates." Writing a citation without a template in the same format that CS1 produces would be a bit of a burden for editors who are not used to it. If short footnotes are being used and one must replicate the linking from short citation to full citation, it becomes considerably more difficult. Jc3s5h (talk) 16:18, 21 December 2013 (UTC)

Date validation tweaks

In response to missing white space, leading zero, and capitalization suggested at #Date check, #Another date check enhancement, and #Suggestion - incorrect month capitalization. All of these should produce date errors (you have to have the errors turned on to see them):

Title. 8September2012. {{cite book}}: Check date values in: |date= (help)
Title. 8September 2012. {{cite book}}: Check date values in: |date= (help)
Title. 8 September2012. {{cite book}}: Check date values in: |date= (help)
Title. 08 September 2012. {{cite book}}: Check date values in: |date= (help)
Title. 8 september 2012. {{cite book}}: Check date values in: |date= (help)
Title. 8 sep 2012. {{cite book}}: Check date values in: |date= (help)

Title. September8,2012. {{cite book}}: Check date values in: |date= (help)
Title. September8, 2012. {{cite book}}: Check date values in: |date= (help)
Title. September 8,2012. {{cite book}}: Check date values in: |date= (help)
Title. September 08, 2012. {{cite book}}: Check date values in: |date= (help)
Title. september 8, 2012. {{cite book}}: Check date values in: |date= (help)
Title. sep 8, 2012. {{cite book}}: Check date values in: |date= (help)

Title. September-October2012. {{cite book}}: Check date values in: |date= (help)
Title. september-October 2012. {{cite book}}: Check date values in: |date= (help)
Title. September-october 2012. {{cite book}}: Check date values in: |date= (help)
Title. Spring-Summer2012. {{cite book}}: Check date values in: |date= (help)
Title. spring-Summer 2012. {{cite book}}: Check date values in: |date= (help)
Title. Spring-summer 2012. {{cite book}}: Check date values in: |date= (help)

And to prove that they work when properly spaced and capitalized:

Title. 8 September 2012.
Title. September 8, 2012.
Title. Sep 8, 2012.
Title. September October 2012. {{cite book}}: Check date values in: |date= (help)
Title. Spring - Summer 2012. {{cite book}}: Check date values in: |date= (help)

—Trappist the monk (talk) 22:56, 15 December 2013 (UTC)

Many thanks for all the work in adding these extra validation rules. Keith D (talk) 23:41, 15 December 2013 (UTC)

Well done indeed. In case it isn't clear from the code above, these changes have been made in the sandbox code, not in the live module. Sandbox changes are typically accumulated for a few weeks to a month and then copied over all at once. The last copy happened in the last couple of days, so the next one will probably happen in early or mid-January.

One note: I think the fifth "valid" one above ("September October 2012") is missing a required dash or slash of some sort and should be marked as invalid. – Jonesey95 (talk) 00:05, 16 December 2013 (UTC)

In the sandbox, I've removed spaces as allowable separators in month and season ranges. Right now, the allowed separators are hyphen, endash, and slash. It would seem that the only accepted separator is an unspaced endash per MOS:ENDASH. MOS:SLASH would suggest that use of a slash in date ranges is discouraged (and hyphens are right out).

Title. September–October 2012.{{cite book}}: CS1 maint: date format (link) (hyphen)
Title. Spring–Summer 2012. (endash)
Title. Spring/Summer 2012. {{cite book}}: Check date values in: |date= (help) (slash)

So, the question is: How strict should we be?

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

I think we're going to catch some flak if we flag hyphenated or slashed month or season ranges with red error messages. I recommend against flagging these as errors, especially since they are parseable. Can someone who knows how make it part of the AWB general fixes instead, and/or can the module automatically render an endash in otherwise valid dates? I would have the module render all three of the above date ranges (and other reasonable variations, like " - " [spaced hyphen] and "—" [emdash] and " / " [spaced slash]) with endashes and not report an error. – Jonesey95 (talk) 00:39, 18 December 2013 (UTC)

Since date check errors are hidden, no flak right? I agree that month or season separator repair can (should) be added to AWB general fixes. In the module, I would lean towards strict adherence to MOS:ENDASH so that we are anchored in the MOS and which makes it less likely that we'll be charged with flouting the standards.

—Trappist the monk (talk) 23:46, 20 December 2013 (UTC)

The hiding/re-hiding of some categories of error messages was done on the condition that they would eventually be exposed once all of the bot-fixable errors had been fixed. I would like to focus on running a bot through each category with hidden errors, getting the category as clean as possible, then exposing the errors so that editors do not continue to add as many problematic citations. I would prefer to avoid basing a decision on the fact that the error messages are hidden, since the intent, I believe, is to expose all of the error messages eventually.

There is a bit of a Catch-22 in my logic, however. If we do not flag these as errors, BattyBot will not know to look at those articles and try to fix them. Thinking.... Nope, I've got nothing. – Jonesey95 (talk) 00:34, 21 December 2013 (UTC)

BattyBot 25 picks pages in Category:CS1 errors: dates, regardless of whether the red error message is visible. GoingBatty (talk) 00:42, 21 December 2013 (UTC)

Right, but the discussion above is wondering whether to flag hyphenated date ranges with an error message. See above: "Right now, the allowed separators are hyphen, endash, and slash" but "the only accepted separator is an unspaced endash" (source: Trappist 2013). So BattyBot will not attempt to fix an article with "date=Sep/Oct 2005" because it is not currently in the error category. I might be too tired to explain this right. – Jonesey95 (talk) 00:47, 21 December 2013 (UTC)

WP:CITEVAR allows any consistent citation style to be used in an article. Help:Citation Style 1 is one such style, APA style is another example of an acceptable style. The Publication Manual of the American Psychological Association (6th ed.) on page 200 contains an example number 9, which gives the publication date as "2006, November/December". Therefore, the forward slash is an acceptable separator in citation dates in some Wikipedia articles. If you want to introduce a restriction that only allows the n-dash, this restriction should be placed in Help:Citation Style 1 and reiterated in the documentation of the various CS1 templates, because the restriction, if agreed to, only applies to CS1, not Wikipedia citations in general. Jc3s5h (talk) 01:11, 21 December 2013 (UTC)

I haven't been around long enough to know how WP:CITEVAR relates to MOS:ENDASH or MOS:DATEFORMAT. They appear to give conflicting information, with the MOS saying "dates should be in these formats only" and CITEVAR saying "use any format as long as it's consistent" (I exaggerate, but not much). Is there a page somewhere that explains this apparent conflict, which is probably a perennial question? Thanks. – Jonesey95 (talk) 02:19, 21 December 2013 (UTC)

The conflict was discussed but there was no resolution. Jc3s5h (talk) 02:34, 21 December 2013 (UTC)

Brutal. So I guess I'll modify my statement about flak above: We're going to catch flak if we go modifying citations that comply with WP:CITEVAR because we think MOS:ENDASH and MOS:DATEFORMAT should take precedence over WP:CITEVAR even though there is apparently no consensus for this idea, and there weren't even red error messages to make it look like we were fixing something that was broken. I guess I prefer to focus energy somewhere else, like on fixing the nearly 400K (and rising by the minute due to the slow job queue or whatever it is) errors that we already have.

I've received a lot of "Thank" notifications for fixing red errors in citation templates. I like catching those better than catching flak. – Jonesey95 (talk) 06:58, 21 December 2013 (UTC)

Yes, there are more than enough genuine date errors to sort out before we get into the subtleties of slashes and n-dashes. While I would like to have the concept of a limited set of valid date formats that doesn't match reality, so I think the practicality is that we may eventually have to switch the date validation round to look for specific errors only, and assume everything else is valid. Rjwilmsi 09:30, 21 December 2013 (UTC)

If you gain consensus, you could introduce a rule for the CS1 style that the separator in date ranges is an unspaced n-dash. Then you would be in compliance with WP:CITEVAR, because that rule would be part of the established style for the article. It really wouldn't be any different than making changes to articles that follow APA style when the 7th ed. of that book comes out. But as some have pointed out, there are many articles with indisputable errors that probably should be tackled first. Jc3s5h (talk) 17:28, 21 December 2013 (UTC)

"Script error"

While I was able to find and fix the problem, the message "Script error" was rather less diagnostic than it might have been. "Please provide |title=" might have been more useful. LeadSongDog come howl! 19:09, 20 December 2013 (UTC)

I don't see a script error when I click on either revision. Can you provide a link to a version of the page that shows "script error"? Thanks. – Jonesey95 (talk) 22:09, 20 December 2013 (UTC)

Prior previous revision lacked title in {cite_journal} with pmc: see rev.18:48, with {cite_journal} in cite #2, as follows:

Fatal cite: {cite journal |journal=J Clin Neurol |date=2009 March |volume=5 |issue=1 |pages=11–19 |pmc=2686891} → J Clin Neurol. 5 (1): 11–19. 2009 March. PMC 2686891 https://www.ncbi.nlm.nih.gov/pmc/articles/PMC2686891. {{cite journal}}: Check date values in: |date= (help); Missing or empty |title= (help)
With title: {cite journal |title=XX|journal=J Clin Neurol |date=2009 March |volume=5 |issue=1 |pages=11–19 |pmc=2686891} → "XX". J Clin Neurol. 5 (1): 11–19. 2009 March. PMC 2686891. {{cite journal}}: Check date values in: |date= (help)
Citing book: {cite book |journal=J Clin Neurol |date=2009 March |volume=5 |issue=1 |pages=11–19 |pmc=2686891} → . Vol. 5. 2009 March. pp. 11–19. PMC 2686891. {{cite book}}: |journal= ignored (help); Check date values in: |date= (help); Missing or empty |title= (help)

The Script error seems to come from "pmc=2686891" but note how {cite_book} would work to show PMC, while {cite_journal} is fatal. -Wikid77 (talk) 05:10, 21 December 2013 (UTC)

Error must come from new logic (really old logic that got added back) to wikilink the title using the PMC. Must be that the logic doesn't skip the link generation if there's no title to link. Rjwilmsi 09:34, 21 December 2013 (UTC)

Yep, that was it.

{{cite journal/new |journal=J Clin Neurol |date=March 2009 |volume=5 |issue=1 |pages=11–19 |pmc=2686891}}

→J Clin Neurol. 5 (1): 11–19. March 2009. PMC 2686891 https://www.ncbi.nlm.nih.gov/pmc/articles/PMC2686891. {{cite journal}}: Missing or empty |title= (help)

and with a title just to be sure the fix hasn't broken anything:

{{cite journal/new |journal=J Clin Neurol |date=March 2009 |volume=5 |issue=1 |pages=11–19 |pmc=2686891 |title=Title}}

→"Title". J Clin Neurol. 5 (1): 11–19. March 2009. PMC 2686891.

Restoring a line from the original version of the PMC code gives us an error message that I haven't seen before. Some documentation work is in order.

—Trappist the monk (talk) 11:58, 21 December 2013 (UTC)

Question about cite interview

Although this reference from the George Harrison article contains an |accessdate= with no URL, it does not display the accessdate or an error. Is this working as intended? Thanks! GoingBatty (talk) 06:03, 21 December 2013 (UTC)

Cite interview comparison
Wikitext	`{{cite interview\|accessdate=15 December 2013\|date=5 October 1975\|first=George\|interviewer=Alan Freeman\|last=Harrison\|program=61\|ref=harv\|title=Rock Around the World}}`
Live	Harrison, George (5 October 1975). "Rock Around the World" (Interview). Interviewed by Alan Freeman. `{{cite interview}}`: `\|access-date=` requires `\|url=` (help); Invalid `\|ref=harv` (help); Unknown parameter `\|program=` ignored (help)
Sandbox	Harrison, George (5 October 1975). "Rock Around the World" (Interview). Interviewed by Alan Freeman. `{{cite interview}}`: `\|access-date=` requires `\|url=` (help); Invalid `\|ref=harv` (help); Unknown parameter `\|program=` ignored (help)

{{cite interview}} is handled by {{citation/core}} so, yes, we should expect that these citations don't display the error messages.

There is a list of CS1 templates that generate error messages at Help:CS1 errors. The script error in the {{cite compare}} table is another clue that {{cite interview}} isn't yet converted to use Module:Citation/CS1

—Trappist the monk (talk) 10:56, 21 December 2013 (UTC)

Split day/month and coauthor(s)

Perhaps we could created two separate subcategories of Category:Pages containing cite templates with deprecated parameters, namely MonthDay and Coauthors to help editors working on the separate issues of month/day, coauthors and others. I would be willing to work on month/day, e.g., but not on coauthors. Debresser (talk) 18:44, 14 December 2013 (UTC)

Institution vs. publisher

I saw on Template:Cite techreport/testcases that in {{Cite techreport}} specifying both an |institution= and |publisher= leads to the Category:Pages with citations having redundant parameters error. I can very well imagine that the research of an institution is published by somebody else, likely closely related to the institution. So I don't think this is reason for an error category. Debresser (talk) 04:07, 15 December 2013 (UTC)