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-00000030-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://en.wikipedia.org|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)