Jump to content

Help talk:Citation Style 1/Archive 4

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 1Archive 2Archive 3Archive 4Archive 5Archive 6→Archive 10

Vancouver system authors

Concerning Template:Cite journal/doc, to get Vancouver system formatted authors one must add:

  • | authorformat = vanc | author-separator=, | author-name-separator =  

to the {{cite journal}} template (see this discussion). Alternatively one can use a single author parameter. I have updated the documentation accordingly. Boghog (talk) 22:08, 21 November 2013 (UTC)

As before, why use a CS1 template for Vancouver? We already have a Citation Style Vancouver series. If you insist on the CS1 module, then it would simple to create a new series. --  Gadget850 talk 16:43, 30 November 2013 (UTC)
Also as discussed before, the vcite templates are no longer maintained nor were they ever widely used. Today, fewer than 300 articles transclude {{vcite journal}}. The new cite journal templates that are based on the CS1 module are much faster, hence one of the primary reasons for using the vcite templates is no longer valid. I suppose that we could create new Vancouver citation templates based on the CS1 module, but some have expressed strong opposition to forking citations in the past (see for example the enormous controversy surrounding the cite_quick templates. Hence I would like to avoid forking templates if possible.
What is widely used are {{cite journal}} templates with a single author parameter with Vancouver system author formatting. A single parameter option (e.g., "authorformat = NLM") which in turn sets "| authorformat = vanc | author-separator=, | author-name-separator =  " has been previously requested, but as far as I know, never implemented. On a related issued, I have also requested that pass through parameters be added to the {{cite doi}} and {{cite pmid}} templates so that these templates could optionally render authors in the Vancouver style. Boghog (talk) 17:45, 30 November 2013 (UTC)
The problem is that follow on authors who don't understand the purpose of those parameters have no idea that you are not using standard CS1. If you use Vancouver for journals, shouldn't you use the same for books and the rest in the same article? But I am tired of arguing for consistency. Perhaps there is a reason the Vancouver templates are not well used? --  Gadget850 talk 18:30, 30 November 2013 (UTC)
Editors see how the citations are rendered and will also see that using a different set of parameters in different citation templates produces inconsistent citation formats. A single authorformat parameter should not be that hard for editors to understand. I agree that formatting should be consistent for all citations within one article including books. But this does not present any special problem since {{cite book}} also supports either a single author parameter or alternatively authorformat, author-separator, and author-name-separator parameters. Vancouver templates are not used because they are no longer needed. The primary reason for using the Vancouver templates was for performance, not formatting. With the new CS1 module, there is no longer a significant performance advantage to the Vancouver templates. Editors that prefer the Vancouver system authors use a single author parameter in the regular citation templates. Boghog (talk) 20:17, 30 November 2013 (UTC)
You truly think that other editors will realize that a different citation style is in use by examining the parameters and values? --  Gadget850 talk 00:03, 1 December 2013 (UTC)
No, they will first notice that there is a difference in how they are formatted and then investigate why. Alternatively the editors that first established the citation format for the article will step in and modify the parameters so that the citations are consistently formatted. Boghog (talk) 00:06, 1 December 2013 (UTC)
I appreciate your naivete. --  Gadget850 talk 00:58, 1 December 2013 (UTC)
Don't underestimate the intelligence of editors. Also you don't seem to understand WP:CITEVAR. Boghog (talk) 05:00, 1 December 2013 (UTC)
I understand CITEVAR and it is crap. I guess that what it does not say is use a consistent citation style within an article.Regardless, I'm not going to change your mind, so do whatever you want. --  Gadget850 talk 12:41, 1 December 2013 (UTC)
"... what it does not say is use a consistent citation style within an article" – False. What CITEVAR does say is "If the article you are editing is already using a particular citation style, you should follow it". Hence CITEVAR does encourage using a consistent citation style within an article. CITEVAR is a content guideline that has been adopted by community consensus. Boghog (talk) 16:03, 1 December 2013 (UTC)
Concur. "Consistent citation style within an article" is sprinkled in several places. But really Gadget850, help us out: use <sarc> tag as needed. --Lexein (talk) 17:24, 1 December 2013 (UTC)
OK. Now: Is Citation Style 1 the same as Vancouver Style? --  Gadget850 talk 18:33, 1 December 2013 (UTC)
Objection your Honor! Asked and answered (see previous discussion). ;-) Boghog (talk) 19:22, 1 December 2013 (UTC)
Overruled. You started a new discussion.--  Gadget850 talk 19:25, 1 December 2013 (UTC)
To summarize what I wrote before, a variant of the Vancouver style (produced by User:Diberri's Wikipedia template filling tool) is widely used in the WP:MED and WP:MCB projects. Furthermore the use of Diberri's tool is mentioned (but not required) in MEDMOS and MCBMOS. This variant only modifies the display of the author list and uses the default display of journals produced by {{cite journal}}. While this style does not match the full Vancouver system format (the only other significant difference is the placement of the date), it still is a format that is widely used in Wikipedia articles and therefore per WP:CITEVAR should be supported. I also wanted to point out that the "authorformat = vanc" is only a partial implementation of the Vancouver style for the display of the author names as it only converts first names to initials. Hence the syntax of "authorformat = vanc" as it is currently implemented is misleading. Logically if "authorformat = vanc" is set, it should also apply the Vancouver convention to the punctuation used within (no comma) and between authors (comma). Boghog (talk) 20:42, 1 December 2013 (UTC)

Or, as I have suggested before, create a new set of templates that call these parameters. You also won't have to monitor and fix follow on edits for the next few decades. --  Gadget850 talk 19:27, 2 December 2013 (UTC)

That is easy:
  • {{vcite2 journal |last=Bannen |first=RM |last2=Suresh |first2=V |last3=Phillips |first3=GN Jr |last4=Wright |first4=SJ |last5=Mitchell |first5=JC |year=2008 |title=Optimal design of thermally stable proteins |url=http://bioinformatics.oxfordjournals.org/cgi/content/full/24/20/2339 |journal=Bioinformatics |volume=24 |issue=20 |pages=2339–43 |doi=10.1093/bioinformatics/btn450 |pmc=2562006 |pmid=18723523 }} →
  • Bannen, RM; Suresh, V; Phillips, GN Jr; Wright, SJ; Mitchell, JC (2008). "Optimal design of thermally stable proteins". Bioinformatics. 24 (20): 2339–43. doi:10.1093/bioinformatics/btn450. PMC 2562006. PMID 18723523.
However that is something that I would not normally use. I would continue to the the normal cite journal template with a single author parameter. Where it would be used is with passthrough parameters to {{cite doi}} and {{cite pmid}}. Boghog (talk) 21:47, 2 December 2013 (UTC)
  • The cite quick controversy was about creating templates that duplicated the CS1 functionality, not doing enough testing to ensure style compatibility, then pushing them onto articles without discussion. While the concept was good, some of the implementation and a lot of the discussion was poor. And we knew that Lua was coming on board soon, which quickly made the whole issue moot.
  • The problem is that many templates have been created independently with a variety of styles that use similar naming schemes (Cite *) that many editors use via copy/paste. The use of citation/core was the first real effort to standardize templates into a formalized style, followed by the codification of CS1 and the update of several popular citation templates to incorporate that style.
  • If I were doing it over again, I would have pushed for renaming the templates to reflect a common style- CS1 book, CS1 journal, etc.
  • It is certainly valid to use or create templates for citation styles. You want to use the CS1 style to create a variant for medical-related articles. Whether you use the use the existing templates or create new ones, you are forking the style. If you want to create 'medcite journal' or whatever as a Vancouver-like fork of CS1, then I don't see an issue, and indeed see benefits. You can create all the templates you need, update the documentation modules as needed and create a comprehensive style guide. The Lua CS1 modules have enough power to accommodate many variant styles, although this should be used judiciously.
--  Gadget850 talk 16:30, 7 December 2013 (UTC)

Looking for trans_title for {{cite encyclopedia}}

In the documentation for {{cite encyclopedia}}, specifically Template:Cite_encyclopedia#Title, |trans_title= is repeated, appearing once under |title= and again under |encyclopedia=. I believe that I have identified two problems.

1. |trans_title= goes with |title= or |article=. There does not appear to be a way to provide a translation of the title of the encyclopedia itself.

2. The "Pages with citations using translated terms without the original" error appears when there is a translated title and |article= is used instead of |title= (|article= is an alias of |title=).

I believe that there should be a parameter allowing #1 above to work. It is possible that such a parameter exists but that the documentation is unclear (to me).

I also believe that the presence of a valid |article= should prevent the error message in #2 from appearing.

Some examples:

A citation where |trans_title= is intended to translate |encyclopedia=:

{{cite encyclopedia|ref=harv|last=Bricka|first=Carl Frederik|authorlink=Carl Frederik Bricka|encyclopedia=[[Dansk biografisk leksikon|Dansk biografisk Lexikon, tillige omfattende Norge for tidsrummet 1537–1814]]|trans_title=Danish Biographic Lexicon, including Norway for the period 1537–1814|url=http://runeberg.org/dbl/9/0067.html|edition=1st|year=1895|volume=IX|pages=65–71|article=Niels Kaas}}
Bricka, Carl Frederik (1895). "Niels Kaas". [[Dansk biografisk leksikon|Dansk biografisk Lexikon, tillige omfattende Norge for tidsrummet 1537–1814]]. Vol. IX (1st ed.). pp. 65–71. {{cite encyclopedia}}: Invalid |ref=harv (help); URL–wikilink conflict (help); Unknown parameter |trans_title= ignored (|trans-title= suggested) (help)

The same citation, using |title= instead of |article=:

{{cite encyclopedia|ref=harv|last=Bricka|first=Carl Frederik|authorlink=Carl Frederik Bricka|encyclopedia=[[Dansk biografisk leksikon|Dansk biografisk Lexikon, tillige omfattende Norge for tidsrummet 1537–1814]]|trans_title=Danish Biographic Lexicon, including Norway for the period 1537–1814|url=http://runeberg.org/dbl/9/0067.html|edition=1st|year=1895|volume=IX|pages=65–71|title=Niels Kaas}}
Bricka, Carl Frederik (1895). "Niels Kaas". Dansk biografisk Lexikon, tillige omfattende Norge for tidsrummet 1537–1814. Vol. IX (1st ed.). pp. 65–71. {{cite encyclopedia}}: Invalid |ref=harv (help); Unknown parameter |trans_title= ignored (|trans-title= suggested) (help)

Am I doing it wrong, which happens a lot, or have I found one or more bugs? – Jonesey95 (talk) 15:35, 3 December 2013 (UTC)

|article= is an alias of |chapter=, not of |title=. It will give you the same type of citation as your second example . But, that seems wrong because "Danish Biographic ..." is not a translation of Niels Kaas. So, it does look like you've found a bug. Comparing old to live:
Cite encyclopedia comparison
Wikitext {{cite encyclopedia|article=Niels Kaas|encyclopedia=Dansk biografisk|trans_title=Danish Biographic}}
Live "Niels Kaas". Dansk biografisk. {{cite encyclopedia}}: Unknown parameter |trans_title= ignored (|trans-title= suggested) (help)
Sandbox "Niels Kaas". Dansk biografisk. {{cite encyclopedia}}: Unknown parameter |trans_title= ignored (|trans-title= suggested) (help)
Cite encyclopedia comparison
Wikitext {{cite encyclopedia|encyclopedia=Dansk biografisk|title=Niels Kaas|trans_title=Danish Biographic}}
Live "Niels Kaas". Dansk biografisk. {{cite encyclopedia}}: Unknown parameter |trans_title= ignored (|trans-title= suggested) (help)
Sandbox "Niels Kaas". Dansk biografisk. {{cite encyclopedia}}: Unknown parameter |trans_title= ignored (|trans-title= suggested) (help)
—Trappist the monk (talk) 16:05, 3 December 2013 (UTC)
Additional information to confuse us more, here is the markup from {{cite encyclopedia/old}}:
|Title={{{encyclopedia|{{{title|}}}}}}
|TransTitle={{{trans_chapter|}}}
|TransItalic={{{trans_title|}}}
|IncludedWorkTitle={{{title|{{{article|}}}}}}
Clearly, in the case of {{cite encyclopedia}}, |article= is an alias of |title=. That isn't the case in Module:Citation/CS1:
['Chapter'] = {'chapter', 'contribution', 'entry', 'article', 'section' }
|chapter= is not supported by {{cite encyclopedia/old}}.
–Trappist the monk (talk) 16:41, 3 December 2013 (UTC)
You are seeing an old bug in the old cite encyclopedia. I discussed it a few times in that 'title' was assigned to two different meta-parameters, but there was no consensus on a solution. Which also meant that the documentation was odd in the aliases. --  Gadget850 talk 17:15, 3 December 2013 (UTC)
Cite encyclopedia comparison
Wikitext {{cite encyclopedia|article=Article|encyclopedia=Encyclopedia|title=Title|trans_chapter=TransArticle|trans_title=TransTitle}}
Live "Article". Title. Encyclopedia. {{cite encyclopedia}}: Unknown parameter |trans_chapter= ignored (|trans-chapter= suggested) (help); Unknown parameter |trans_title= ignored (|trans-title= suggested) (help)
Sandbox "Article". Title. Encyclopedia. {{cite encyclopedia}}: Unknown parameter |trans_chapter= ignored (|trans-chapter= suggested) (help); Unknown parameter |trans_title= ignored (|trans-title= suggested) (help)
Cite encyclopedia comparison
Wikitext {{cite encyclopedia|article=Article|encyclopedia=Encyclopedia|trans_chapter=TransArticle|trans_title=TransTitle}}
Live "Article". Encyclopedia. {{cite encyclopedia}}: Unknown parameter |trans_chapter= ignored (|trans-chapter= suggested) (help); Unknown parameter |trans_title= ignored (|trans-title= suggested) (help)
Sandbox "Article". Encyclopedia. {{cite encyclopedia}}: Unknown parameter |trans_chapter= ignored (|trans-chapter= suggested) (help); Unknown parameter |trans_title= ignored (|trans-title= suggested) (help)
Cite encyclopedia comparison
Wikitext {{cite encyclopedia|encyclopedia=Encyclopedia|title=Title|trans_chapter=TransArticle|trans_title=TransTitle}}
Live "Title". Encyclopedia. {{cite encyclopedia}}: Unknown parameter |trans_chapter= ignored (|trans-chapter= suggested) (help); Unknown parameter |trans_title= ignored (|trans-title= suggested) (help)
Sandbox "Title". Encyclopedia. {{cite encyclopedia}}: Unknown parameter |trans_chapter= ignored (|trans-chapter= suggested) (help); Unknown parameter |trans_title= ignored (|trans-title= suggested) (help)
Cite encyclopedia comparison
Wikitext {{cite encyclopedia|article=Article|title=Title|trans_chapter=TransArticle|trans_title=TransTitle}}
Live "Article". Title. {{cite encyclopedia}}: Unknown parameter |trans_chapter= ignored (|trans-chapter= suggested) (help); Unknown parameter |trans_title= ignored (|trans-title= suggested) (help)
Sandbox "Article". Title. {{cite encyclopedia}}: Unknown parameter |trans_chapter= ignored (|trans-chapter= suggested) (help); Unknown parameter |trans_title= ignored (|trans-title= suggested) (help)

I think that I conclude from this series of comparisons that Module:Citation/CS1 isn't too badly broken, if it's broken at all. The {{citation/core}} version of {{cite encyclopedia}} is flawed so using it as a reference is problematic but I've used it here to show that the Module is fundamentally correct. If we are are to "fix" anything, it might be to alias |encyclopedia= and |title= for {{cite encyclopedia}} – if an editor needed |article=, |title=, and |work= then {{cite book}} can be used.

Aliasing |encyclopedia= and |title= for {{cite encyclopedia}} will also improve the metadata because then the encyclopedia's title will be included.

From the above comparisons, I've discovered that Editor Jonesey95's example citation can be properly rendered:

{{cite encyclopedia|ref=harv|last=Bricka|first=Carl Frederik|authorlink=Carl Frederik Bricka|title=[[Dansk biografisk leksikon|Dansk biografisk Lexikon, tillige omfattende Norge for tidsrummet 1537–1814]]|trans_title=Danish Biographic Lexicon, including Norway for the period 1537–1814|url=http://runeberg.org/dbl/9/0067.html|edition=1st|year=1895|volume=IX|pages=65–71|article=Niels Kaas}}
→Bricka, Carl Frederik (1895). "Niels Kaas". [[Dansk biografisk leksikon|Dansk biografisk Lexikon, tillige omfattende Norge for tidsrummet 1537–1814]]. Vol. IX (1st ed.). pp. 65–71. {{cite encyclopedia}}: Invalid |ref=harv (help); URL–wikilink conflict (help); Unknown parameter |trans_title= ignored (|trans-title= suggested) (help)

This is how it would render if we alias |encyclopedia= and |title= for {{cite encyclopedia}}.

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

Further head scratching:

This issue basically involves three parameters: |encyclopedia=, |title=, and |article=. Set or not set gives eight possible combinations:

  1. none are set which is pointless
  2. |article=
  3. |title=
  4. |title= and |article=
  5. |encyclopedia=
  6. |encyclopedia= and |article=
  7. |encyclopedia= and |title=
  8. |encyclopedia= |title=, and |article=

Nothing wrong with combinations 2, 3, 4, and 8. For the rest, if, within reason, we re-map parameters to positions of greater specificity, then for:

Case 5: |encyclopedia= maps to |title=
Case 6: |encyclopedia= maps to |title=
Case 7: |title= maps to |article= and |encyclopedia= maps to |title=

When |title= maps to |article=, |trans_title= maps to (and overwrites) |trans_chapter=.

I've tweaked the sandbox code so now we get this (|url= and |chapterurl= added to make sure that they follow their proper title parameters):

Cite encyclopedia comparison
Wikitext {{cite encyclopedia|encyclopedia=Encyclopedia|trans_title=TransTitle|url=//example.com}}
Live Encyclopedia //example.com. {{cite encyclopedia}}: Missing or empty |title= (help); Unknown parameter |trans_title= ignored (|trans-title= suggested) (help)
Sandbox Encyclopedia //example.com. {{cite encyclopedia}}: Missing or empty |title= (help); Unknown parameter |trans_title= ignored (|trans-title= suggested) (help)
Case 5
Cite encyclopedia comparison
Wikitext {{cite encyclopedia|article=Article|chapterurl=//chapterurl.org|encyclopedia=Encyclopedia|trans_chapter=TransArticle|trans_title=TransTitle|url=//example.com}}
Live "Article". Encyclopedia. {{cite encyclopedia}}: External link in |chapterurl= (help); Unknown parameter |chapterurl= ignored (|chapter-url= suggested) (help); Unknown parameter |trans_chapter= ignored (|trans-chapter= suggested) (help); Unknown parameter |trans_title= ignored (|trans-title= suggested) (help)
Sandbox "Article". Encyclopedia. {{cite encyclopedia}}: External link in |chapterurl= (help); Unknown parameter |chapterurl= ignored (|chapter-url= suggested) (help); Unknown parameter |trans_chapter= ignored (|trans-chapter= suggested) (help); Unknown parameter |trans_title= ignored (|trans-title= suggested) (help)
Case 6
Cite encyclopedia comparison
Wikitext {{cite encyclopedia|chapterurl=//chapterurl.org|encyclopedia=Encyclopedia|title=Title|trans_chapter=TransArticle|trans_title=TransTitle|url=//example.com}}
Live "Title". Encyclopedia. {{cite encyclopedia}}: External link in |chapterurl= (help); Unknown parameter |chapterurl= ignored (|chapter-url= suggested) (help); Unknown parameter |trans_chapter= ignored (|trans-chapter= suggested) (help); Unknown parameter |trans_title= ignored (|trans-title= suggested) (help)
Sandbox "Title". Encyclopedia. {{cite encyclopedia}}: External link in |chapterurl= (help); Unknown parameter |chapterurl= ignored (|chapter-url= suggested) (help); Unknown parameter |trans_chapter= ignored (|trans-chapter= suggested) (help); Unknown parameter |trans_title= ignored (|trans-title= suggested) (help)
Case 7

This tweak fixes Editor Jonesey95's first example:

{{cite encyclopedia|ref=harv|last=Bricka|first=Carl Frederik|authorlink=Carl Frederik Bricka|encyclopedia=[[Dansk biografisk leksikon|Dansk biografisk Lexikon, tillige omfattende Norge for tidsrummet 1537–1814]]|trans_title=Danish Biographic Lexicon, including Norway for the period 1537–1814|url=http://runeberg.org/dbl/9/0067.html|edition=1st|year=1895|volume=IX|pages=65–71|article=Niels Kaas}}
Bricka, Carl Frederik (1895). "Niels Kaas". [[Dansk biografisk leksikon|Dansk biografisk Lexikon, tillige omfattende Norge for tidsrummet 1537–1814]]. Vol. IX (1st ed.). pp. 65–71. {{cite encyclopedia}}: Invalid |ref=harv (help); URL–wikilink conflict (help); Unknown parameter |trans_title= ignored (|trans-title= suggested) (help)

—Trappist the monk (talk) 14:02, 5 December 2013 (UTC)

Wow, how did we get into this mess? I am definitely still confused about |title=, |chapter=, and |article=, and the existing documentation is not helping me. Should these two citations behave in the same way?
Cite encyclopedia comparison
Wikitext {{cite encyclopedia|article=Article|encyclopedia=Encyclopedia|trans_title=TransTitle|url=//example.com}}
Live "Article". Encyclopedia. {{cite encyclopedia}}: Unknown parameter |trans_title= ignored (|trans-title= suggested) (help)
Sandbox "Article". Encyclopedia. {{cite encyclopedia}}: Unknown parameter |trans_title= ignored (|trans-title= suggested) (help)
Case 6 with article name in "article" but no trans_chapter
Cite encyclopedia comparison
Wikitext {{cite encyclopedia|encyclopedia=Encyclopedia|title=Article|trans_title=TransTitle|url=//example.com}}
Live "Article". Encyclopedia. {{cite encyclopedia}}: Unknown parameter |trans_title= ignored (|trans-title= suggested) (help)
Sandbox "Article". Encyclopedia. {{cite encyclopedia}}: Unknown parameter |trans_title= ignored (|trans-title= suggested) (help)
Case 7 with article name in "title" but no trans_chapter
Do we know what the usual usage is for the parameters in {{cite encyclopedia}}? Are people using |title= for the article title? I expect they are either using |title= or |article=, but those two parameters are apparently not equivalent. We might be able to make a very nice change to the template if we could first get a bot to substitute appropriate parameter names in existing articles and templates that use {{cite encyclopedia}}. Maybe.
First draft of a set of steps that might get us out of this mess (definitely needs debugging and testing and more complexity):
  1. Change all |title= to |article=
  2. Change template to alias |title= to |encyclopedia= (mirroring {{cite book}}, since encyclopedias are books)
  3. Make |trans_title= apply to |encyclopedia=
  4. Introduce |trans_article= for translated article names (it would be equivalent to |trans_chapter=)
  • How do we detect trans_titles that are translations of article names?
I'm sure there are four bad ideas in there. Please help refine my idea or otherwise show ways in which it is no good. – Jonesey95 (talk) 23:05, 5 December 2013 (UTC)
How did we get here? I've heard that it's the result of multiple authors writing each of the twenty or so CS1 templates. Editor Gadget850 did yeoman's work in cleaning up the mess that was {{citation/core}}. This issue was one that didn't get resolved. See his comment above regarding the snippet of code from {{citation/core}}.
I look at |article= (an alias of |chapter=) as the citation element with the smallest scope. This is reflected in its leftmost position in the rendered citation. Next is |title= and then finally |encyclopedia=. When |article= isn't present, the next "larger" parameter, |title= gives its value to |article=; the now vacant |title= gets its value from |encyclopedia=. In this way we adjust to what we've been given and produce a more-or-less sensibly rendered citation. Is it optimal? Probably not. Were we designing {{cite encyclopedia}} anew, we might choose to have only |encyclopedia= and |article=. It would make things simpler.
So, with regard to your two examples and whether they should behave the same way: No, they should not, and do not. In your first example, we have |article= and |encyclopedia=. Since there is no |title=, |encyclopedia= gives up its value to |title=. Because |title= did not give its value to |article=, |trans_title= will not give up its value to |trans_chapter=. Similarly, in your second example, |title= gives its value to |article=, |trans_title= gives its value to |trans_chapter=, and |encyclopedia= gives its value |title=. "So that, as clear as is the summer's sun," explains that. (Quoted bit from Shakespeare, Henry V, Act 1, Scene 2)
I don't know how {{cite encyclopedia}} is used. You'll forgive me if I'm a bit skeptical about getting a robot to do anything and do it reliably. I remember that not too long ago there were assertions made that a "bot remedy [was] in hand"; assertions that seem to have been unfounded.
Is there a mess? Certainly there is in the documentation; as it is now, it's no wonder there is confusion. For the rest of your enumerated list of steps to a solution perhaps that is best undertaken in a different thread so that we don't derail?
—Trappist the monk (talk) 01:35, 6 December 2013 (UTC)
Usual usage? That will be based on the established (pre-lua) documentation at [1]. Clearly |encyclopedia=Encyclopaedia is self explanatory. As |article= is an alias for |title=, it is simplest to eschew it and simply use |title= and |trans_title= in reference to the cited article. Any use of |title=Encyclopaedia is simply an error, that should be corrected if found, to |encyclopedia=Encyclopaedia. Doing so should not create any problems. LeadSongDog come howl! 02:29, 6 December 2013 (UTC)
The link to the older version of the {{cite encyclopedia}} documentation is pretty much the same as the current documentation because of how the CS1 documentation is structured. All of the CS1 templates share bits, pieces, and parts from {{Citation Style documentation}} which transcludes multiple other templates that contain the actual documentation for the various parameters.
Except for the case of citations like the one that opened this discussion, I might agree with the rest of your comment. Clearly, in that case, it is necessary to have the name of the encyclopedia associated with |title= so that |trans_title= can be used and the two rendered properly in the template's output.
—Trappist the monk (talk) 12:17, 6 December 2013 (UTC)
Not at all. There's no excuse for disrupting all the articles which use this template just for the sake of a few added citations. It would be quite legitimate and much less disruptive to use the existing parameter: |— Preceding unsigned comment added by LeadSongDog (talk • contribs) 14:49, 6 December 2013‎ (UTC)
Signed the apparently incomplete comment above by Editor LeadSongDog.
—Trappist the monk (talk) 16:28, 6 December 2013 (UTC)
Don't get hung up on the documentation: in the old template, 'title' is an alias for both 'encyclopedia' and 'article' and can certainly give odd output. All of the other templates use 'title' for the main work title and 'chapter' or an alias for the included title. The best solution would be to make 'encyclopedia' and 'title' aliases and make 'article' and 'chapter' aliases and have a bot fix the 68k articles. --  Gadget850 talk 23:41, 9 December 2013 (UTC)
Strongly Agree with Gadget850's recommendation here, hence my proposed actions in "First draft of a set of steps..." above. I think that having "title" be an alias for more than one parameter in some sort of if/then setup is WAY too confusing for me, let alone for your typical non-citation-format-obsessed editor. And it would be hell to document.
My only quibble with Gadget850's statement immediately above is that {{cite journal}} uses "title" for an academic article's title, while "journal" (aka "work") is the title of the larger encompassing work containing the item represented in "title". I don't foresee changing that setup any time soon; certain wikiprojects would explode. – Jonesey95 (talk) 00:09, 10 December 2013 (UTC)

Title

Reflecting upon Jonesey95's last comment, I checked the use of 'title' in all the templates. They are split between using 'title' for the main work or the included work; {{cite news}} uses it for both conditionally. This doesn't change the issue that the way {{cite encyclopedia}} uses 'title' is wrong. --  Gadget850 talk 14:04, 10 December 2013 (UTC)

suggestion for new arg to ((cite web)) template

This suggestion is for Template:Cite web. There is a quote= parameter for use when giving an exact quotation from the source. There is also a laysummary= arg which is used to point to a URL, and is a synonym for layurl.

  Unless I'm misunderstanding something, there is no provision for adding additional text, which is an on-the-spot summary, or perhaps a paraphrase (if it is partial rather than full). Suggest that there be a new arg or two, which permit these things to happen, plus a generic one for explanatory/disclamatory(sp?)/similar text of purposely-unspecified nature.

  1. paraphrase=
  2. tenWordSummary=
  3. misc=

Hope this helps. 74.192.84.101 (talk) 19:58, 9 December 2013 (UTC)

  p.s. The particular use-case here is for a high-school athletics program, which from time to time wins awards at the state championship level, for the dozen different sports they compete in. I would like to have a reference using ((cite web)) which points to the story about the championship, and then specify the traditional details like this.

misc= Game was played 2013-02-01 against $otherTeam in $namedStadium of $whateverTown, final score $n to $m.

That level of detail is mind-numbing for inclusion in the main body as prose... there, I would just say "2013 Boys Golf State Champs" or something similarly brief.

  I realize that I could create the necessary references without using ((cite web)), and include my additional disclaimer-text... but the article already exists, and is already using ((cite web)). I'm just trying to push the overly-detailed stuff into a footnote-sort-of-area, where it belongs. Thanks for any suggestions on the best way forward. 74.192.84.101 (talk) 19:58, 9 December 2013 (UTC)

p.s. After going back to the article, it finally dawned on me, and I realized that one can use (ref) ((cite web)), miscTextHere (/ref) ... so my problem is solved. Maybe a link from the ((cite web)) helpdocs, to the (ref)(/ref) helpdocs, which presumably mention how to add miscellaneous trailing text? Danke. 74.192.84.101 (talk) 20:02, 9 December 2013 (UTC)
As far as I know, the solution you found is the only one that exists. I don't find it satisfying, since the text is not structured in any way and therefore we do not have a way to present it differently in the rendered reference/citation by changing the {{cite web}} rendering code. I feel slightly unclean after I just leave text lying around between the closing curly brackets and the closing ref tag, but what other options are there? Anyone? – Jonesey95 (talk) 21:12, 9 December 2013 (UTC)
The purpose of the citation is to enable the reader to locate the source. Content belongs in the article body. --  Gadget850 talk 23:23, 9 December 2013 (UTC)
Ref tags can also be used for footnotes containing text that is relevant but not worthy of inclusion in the main body of an article. The above editor is essentially combining a citation with a footnote, a practice that is used in academic texts. – Jonesey95 (talk) 00:02, 10 December 2013 (UTC)
Those are explanatory notes and usually separate from citations. --  Gadget850 talk 00:59, 10 December 2013 (UTC)

Title vs article in Cite encyclopedia

As User:Debresser/Sandbox shows, the title and article parameters are treated the same by {{Cite encyclopedia}}, unless they are given both, in which case the title parameter is italicized. The documentation on Template:Cite_encyclopedia/doc#Title says that title and article are aliases. Could somebody please explain this seeming contradiction, and propose how to change the documentation or the template accordingly. Debresser (talk) 02:08, 11 December 2013 (UTC)

Scroll up a bit for a long discussion of this very problem. – Jonesey95 (talk) 04:01, 11 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:

  1. Fix Script Error bug that occured when |doi_brokendate= did not contain a year value;
  2. Fix doi() so that dois with invalid doi_brokendate categorize to "Pages with inactive DOIs" and not to "Pages with DOIs inactive since";
  3. Change deprecated_parameter() to emit a single error message; (discussion}
  4. 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)
  5. Year and PublicationDate promotion to Date consolidation; (discussion)
  6. Change validate() and the whitelist to recognize deprecated parameters; (discussion)
  7. Change pmc/url handling; (discussion)
  8. Modify |encyclopedia, |title and |article parameter handling for cite encyclopedia; (discussion)

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

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

Auto-formatting dashes in page numbers

It appears that the templates now convert any hyphens in page numbers. I had to use the code for a hyphen in this edit to get them to appear as hyphens again. (Environmental impact studies tend to use hyphenated pagination for the chapter and the page number within the chapter.) I understand that people don't always use a dash for page ranges, but it seems to be very counterintuitive to resort to codes like this when a hyphen is correct, and I had to dig to find the code which isn't documented, and instead the documentation says to use at... :( Imzadi 1979 → 20:52, 13 December 2013 (UTC)

Honestly, who cares? It has always been a complete mystery to me why some people are so hung up on the differences between hyphens and various supposedly different sorts of dashes. To the casual reader they are all the same. A complete and, in my view, absurd waste of time and effort. -- Alarics (talk) 21:43, 13 December 2013 (UTC)
Mostly I don't have much sympathy for all the hyper-correctness about dash-like marks. But if an electronic document has pages numbers that contain a particular mark, its kind of nice to get it right, so someone using the source can cut from the citation and paste into whatever kind of find command is available in the electronic reading environment. Jc3s5h (talk) 21:55, 13 December 2013 (UTC)
I believe the way to avoid having your correct hyphens replaced is to specify the page number using at=p. 1-1 instead of putting a hyphen in the |page= parameter. – Jonesey95 (talk) 23:18, 13 December 2013 (UTC)
(edit conflict)Only for |pages=. A hyphenated page number in |page=1-1 like the one in your example is not converted to an endash:
{{cite book |title=Title |page=1-1}} → Title. p. 1-1.
{{cite book |title=Title |pages=1-1}} → Title. pp. 1–1.
Using &#8209; in hyphenated page numbers corrupts the COinS metadata.
—Trappist the monk (talk) 23:33, 13 December 2013 (UTC)
Hyphenated page numbers are often converted to endashed page numbers by bots and scripts that believe the numbers are page ranges. – Jonesey95 (talk) 23:37, 13 December 2013 (UTC)
I wonder if there is a way to "escape" a hyphen so that CS1 and the various robots can distinguish intentional hyphens like this case where the hyphen is appropriate. And, what about hyphenated page ranges? 1-1–1-3 for example. Double hyphens: 1-1--1-3? Some other character? Of course, it's easy enough to detect and replace &#8209; with a hyphen but that string is more difficult to type that a couple of hyphens.
Ideas?
—Trappist the monk (talk) 23:48, 13 December 2013 (UTC)
Whatever solution should be coordinated with User:Citation bot; that's where I found the code because that bot will replace a hyphen with a dash... Imzadi 1979 → 00:58, 14 December 2013 (UTC)
There are a number of editing tools that will convert HTML entities to standard ASCII characters, so that is not a real solution. --  Gadget850 talk 20:00, 14 December 2013 (UTC)

Honestly, I'm on the fence about all of this. On one hand, I appreciate that the correct dash can be hard to type, and that people are ignorant (some intentionally) of good typography, so the concept of the templates correcting a hyphen to a dash is nice. However, in this case, such a concept does actual harm since hyphenated page numbers are not a totally obscure concept. I think given those harms, the template should not attempt the autocorrection, and we should deal with educating people or just wikignoming dashes into place as needed. Imzadi 1979 → 16:41, 15 December 2013 (UTC)

The cite templates do not convert hyphens to dashes in |page=page number parameters. Bots like Citation Bot, and scripts that use AWB and similar fixes, sometimes convert hyphens to dashes in that parameter. In other words, WP currently behaves like the latter suggestion ("just wikignoming dashes into place"), with the exception that the scripts and bots are unable to distinguish between a proper hyphen in a page number like "3-1". Hence the suggestion to put hyphenated page numbers into |at=. – Jonesey95 (talk) 20:45, 15 December 2013 (UTC)
Well, sort of. Module:Citation/CS1 does change hyphens to endashes when hyphens are encountered in |pages= (the plural).
—Trappist the monk (talk) 20:57, 15 December 2013 (UTC)

Documentation question regarding deprecated month parameter

Since |month= has been deprecated, should Help:Citation Style 1#Dates be update, similar to Template:Cite web#Deprecated does? Thanks! GoingBatty (talk) 06:20, 16 December 2013 (UTC)

Done.
—Trappist the monk (talk) 12:56, 16 December 2013 (UTC)

nsbp allowed in dates?

I haven't done much digging into the articles in the new date error category, but I came across one today that looked like a false positive. The date format was: |accessdate=September 23, 2011 in the article Mel Pearson. Should non-breaking spaces be allowed where spaces are allowed in valid date formats? MOS:DATEFORMAT is not explicit on the issue.

I can see why someone would put non-breaking spaces into a date like this, but it seems overly fancy to me. – Jonesey95 (talk) 23:02, 27 November 2013 (UTC)

Even though &nbsp; is legitimate html, to CS1 it is just extraneous text. If CS1 is working correctly, there should be no need for editors to add markup that effects the display of the rendered citation (external links and wikilinks excepted, and then only in certain circumstances). On my list of things to do is to insert &nbsp; in appropriate places in dates, in time, and perhaps elsewhere.
—Trappist the monk (talk) 00:48, 28 November 2013 (UTC)
The script for standardising date formats automatically removes non-breaking spaces from dates, so I presume they are frowned upon. -- Alarics (talk) 10:14, 29 November 2013 (UTC)
Hopefully, in the fullness of time, the template will insert nbsp when needed in dates, and we'll be able to remove all explicit nbsp from the parameter values. However, template doesn't do that yet, so for the moment we should leave these be otherwise some editors who spend time putting in these nbsp will complain. Rjwilmsi 12:13, 29 November 2013 (UTC)
What script is that? MOS:DATEFORMAT seems to be mute on &nbsp; in properly formatted dates except within date ranges. Here's a rather long discussion about &nbsp; in citations which I have not yet had the time to read. Perhaps that will be helpful.
—Trappist the monk (talk) 14:47, 29 November 2013 (UTC)
The script I was referring to is User:Ohconfucius/script/MOSNUM dates. -- Alarics (talk) 09:41, 30 November 2013 (UTC)
I like that script very much. It does strip &nbsp; out, but I've only spotted nbsp in two articles in 2 or 3 places; these are easily reinserted manually if needed, because the script automatically does "Show Changes" after it runs. See WP:NBSP for the prime advice about &nbsp; - it's pretty conservative, suggesting use in a limited way only where absolutely needed. To me, stray HTML which stops me from searching for plain dates while editing is just invalid wikitext. May I suggest {{nowrap}} ({{nowrap| 2 November 1823}}) rather than fussing with &nbsp; ? --Lexein (talk) 20:33, 30 November 2013 (UTC)
Really, the only part of a date that would need a non-breaking space or a nowrap is the month and day portions. A year can stand alone as a discrete unit, but the number for the day of a month depends on the month for meaning just as the numerical portion of a measurement depends on its unit. Imzadi 1979 → 20:59, 30 November 2013 (UTC)
I've changed my example to suggest that the year also conveys meaning - wouldn't allowing the year to break obscure that meaning, if only for a moment? --Lexein (talk) 21:05, 30 November 2013 (UTC)
Remembering that this page and this discussion is about Citation style 1, {{nowrap}} has no place in a CS1 citation template. When I suggested that one of the things on my my todo list is to insert &nbsp; in appropriate places in dates, in time, and perhaps elsewhere, I meant that Module:Citation/CS1 would do that to the template output and not in the wikitext that an editor sees.
I'm inclined to agree with Editor Imzadi1979 that for the MOS approved date formats, the first space gets replaced with &nbsp; and the remainder of the date can break at the second space:
30&nbsp;November 2013
November&nbsp;30, 2013
June&nbsp;– July 2013
And for ISO 8601 dates, the hyphens are replaced with non-breaking hyphen &#8209;:
2013&#8209;11&#8209;30
Alternately, these same sections of the dates can be wrapped: <span class="nowrap">30 November</span> 2013
This latter is arguably more technically correct because we're discussing presentation not content.
—Trappist the monk (talk) 23:16, 30 November 2013 (UTC)
What about metadata? --  Gadget850 talk 00:56, 1 December 2013 (UTC)
As I understand it, Trappist is suggesting the output as displayed, not the metadata and not the wikicode input, would have the substitutions made to prevent the undesirable line breaking. Imzadi 1979 → 01:01, 1 December 2013 (UTC)
Yeah, that.
—Trappist the monk (talk) 01:14, 1 December 2013 (UTC)
Hello, I was pointed here by GoingBatty. I use {{nowrap}} for dollar figures and dates in film articles, but Batty's bot was removing it per CS1. I am trying to get a grasp on the technical detail here. Is it not possible to ensure non-breaking spaces for dates without running afoul of CS1? Trappist the monk, can you explain what you mean by the template output and not the wikitext? Just wondering what I need to do personally. Erik (talk | contribs) 16:13, 20 December 2013 (UTC)

(edit conflict)This issue only applies to the use of {{nowrap}} or &nbsp; within a Citation Style 1 template. Here is a simple {{cite book}}:

{{cite book |title=Title |date=20 December 2013}}

It renders like this:

Title. 20 December 2013.

When Module:Citation/CS1 processes the template the output (which the Mediawiki code will convert to a displayable page as HTML) looks like this:

'"`UNIQ--templatestyles-00000072-QINU`"'<cite class="citation book cs1">''Title''. 20 December 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-12-20&rfr_id=info%3Asid%2Fwiki.riteme.site%3AHelp+talk%3ACitation+Style+1%2FArchive+4" class="Z3988"></span>

If you hunt through that tangle of stuff you will find the date in the COinS metadata: &rft.date=20+December+2013

Here is what the {{nowrap}} template output looks like:

<span class="nowrap">20 December 2013</span>

Now, if we change our original {{cite book}} template to use {{nowrap}} in |date={{nowrap|20 December 2013}}:

{{cite book |title=Title |date={{nowrap|20 December 2013}}}}

It renders like this:

Title. 20 December 2013. {{cite book}}: Check date values in: |date= (help)

When Module:Citation/CS1 processes the template the output looks like this:

'"`UNIQ--templatestyles-00000078-QINU`"'<cite class="citation book cs1">''Title''. <span class="nowrap">20 December 2013</span>.</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%3AHelp+talk%3ACitation+Style+1%2FArchive+4" 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>

If you hunt through that tangle of stuff you will find the corrupted date:

&rft.date=%3Cspan+class%3D%22nowrap%22%3E20+December+2013%3C%2Fspan%3E

And that is the problem. Presentation information should not be included in CS1 parameter values because that information ends up in the COinS metadata because when external referencing tools read the date value they get non-date text.

Use {{nowrap}} all you want in your article's text but leave it out of your CS1-based citations Handcrafted citations, because they don't generate machine readable metadata can use {{nowrap}}. Have I answered your questions?

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

Trappist the monk, your edit on 30 November indicated that ISO 8601 [sic] dates would be displayed with non-breaking hyphens. I would think that anyone under the delusion that the English Wikipedia has adopted ISO 8601 would expect a date that appears to be in that format to be in exactly that format, with every single character specifically endorsed in the standard. Can you cite the paragraphs in the ISO 8601 standard that endorses the non-breaking hyphen? If not, it would be safer to stick with nowrap. Jc3s5h (talk) 17:17, 20 December 2013 (UTC)

In the comments to which you refer, I was speculating on possible solutions to the wrapping issue. I probably should have used a term somewhat akin to year initial dates. I also wrote that I thought that the better solution is to wrap displayable dates in a no wrap span because wrapping is presentation, not content.
—Trappist the monk (talk) 17:29, 20 December 2013 (UTC)
The discussion above did not result in any changes to the way that the CS1 module formats citations, as far as I can tell. The discussion explored some ways that the module might present dates in a way that optimized wrapping (or not wrapping). I think that changing that presentation format would best be done through a discussion at WT:MOS.
The short answer to Erik's question is that formatting markup in citation date parameters causes problems with external tools that parse those citations, so that markup is automatically flagged as an error by the module. If editors think that citation dates should universally be formatted with some combination of non-breaking spaces, that issue should be raised at WT:MOS. – Jonesey95 (talk) 18:46, 20 December 2013 (UTC)

Master of the Rolls references http://oxforddnb.com

Excuse my bad english. Hello looking for Master of the Rolls I see many problems with the link to http://oxforddnb.com. F.e.: {{cite web |url=http://oxforddnb.com/view/article/16040?&docPos=1&backToResults=list=yes|group=yes|feature=yes|aor=3|orderfield=alpha |title=Oxford DNB: Langton, John |year=2004 |publisher=Oxford University Press |accessdate=18 November 2009}}

  • "Oxford DNB: Langton, John". Oxford University Press. 2004. Retrieved 18 November 2009. {{cite web}}: Unknown parameter |aor= ignored (|author= suggested) (help); Unknown parameter |group= ignored (help); Unknown parameter |orderfield= ignored (help)

The term between url and title are parameters from the oxforddnb.com but cite web are interpreted there as parameters from cite web. Could someone looking for this? With best regards --Markus S. (talk) 14:05, 13 December 2013 (UTC)

The errors occur because the |url= value contains the pipe symbol "|" which Wikipedia templates use to identify parameters. To fix these citations, replace the pipe symbols in the |url= with {{!}}:
{{cite web |url=http://oxforddnb.com/view/article/16040?&docPos=1&backToResults=list=yes{{!}}group=yes{{!}}feature=yes{{!}}aor=3{{!}}orderfield=alpha |title=Oxford DNB: Langton, John |year=2004 |publisher=Oxford University Press |accessdate=18 November 2009|subscription=yes}}
→"Oxford DNB: Langton, John". Oxford University Press. 2004. Retrieved 18 November 2009. {{cite web}}: Unknown parameter |subscription= ignored (|url-access= suggested) (help)
—Trappist the monk (talk) 14:25, 13 December 2013 (UTC)
or just truncate the url at http://www.oxforddnb.com/view/article/16040 The additional parameters all seem to relate to having searched ODNB for this entry so aren't relevant for a direct link from WP. NtheP (talk) 14:36, 13 December 2013 (UTC)
Thanks for the Help :) The references are fixed. --Markus S. (talk) 15:20, 13 December 2013 (UTC)
I'm looking for former versions and I see that untill December 2012 this parameters don't make any problems. Were some fixes in the last month in the template or in the wiki-software? --Markus S. (talk) 06:15, 17 December 2013 (UTC)
Former versions of what? The use of the pipe symbol within |url= values has always caused problems because the Wikipedia software uses it to separate a template's parameters. The change from markup-based {{citation/core}} to Lua-based Module:Citation/CS1 processing allowed us to detect malformed citation parameters. That change was made this year.
—Trappist the monk (talk) 11:29, 17 December 2013 (UTC)
Former version of Master of the Rolls. I'm searching for this because I doesn't understand this malformed references. And with your answer is this now okay. Thanks for this. --Markus S. (talk) 13:21, 17 December 2013 (UTC)

Template:Cite court

Should {{cite court}} be added to Template:Citation Style documentation/cs1, Help:Citation_Style_1#Templates, etc.? It Is Me Here t / c 12:54, 17 December 2013 (UTC)

No. Citation Style 1 templates are characterized by their common use of either {{citation/core}} or Module:Citation/CS1. {{cite court}} uses neither.
—Trappist the monk (talk) 13:16, 17 December 2013 (UTC)
Is there some kind of roadmap for converting such templates to CS1? Is the plan to have them all using CS1 eventually? It's just that, my thought is, if these templates get listed alongside {{cite news}} and so on at Template:Citation Style documentation/cs1, they will gain more prominence and so editors will be more likely to use them. It Is Me Here t / c 13:54, 17 December 2013 (UTC)
As far as I know, there is no such plan. If it is the collective judgement that a particular citation template would benefit from conversion to CS1, editors are, of course, welcome to do that.
—Trappist the monk (talk) 14:38, 17 December 2013 (UTC)
{{cite court}} uses the US Bluebook style. Previous attempts to incorporate it into CS1 were rebuffed- see {{cite court}} talk. I am not aware of any legal citation templates that use the CS1 style. --  Gadget850 talk 15:54, 17 December 2013 (UTC)

New ReferenceBot notifying editors when they cause certain CS1 errors

This is a note, in case it hasn't come to the attention of the editors here, that there is a new bot, User:ReferenceBot, that is notifying editors when they place an article in one of a handful of reference error categories. It works in almost the same way as User:BracketBot, adding a notification to the editor's Talk page letting them know that their edit appears to have caused a reference error.

ReferenceBot currently checks the following categories for new articles once per day:

Those categories were chosen because they are currently (or recently) free of problem articles. This means that editors who revert to previous versions of articles will not be accused of introducing an error unless they revert an article to a state before the citation errors were fixed.

I am hopeful that this new bot will help keep the emptied CS1 categories from refilling quite so fast, allowing us to focus on fixing longstanding errors instead of trying to keep up with the new ones.

Here are a few diffs that show ReferenceBot's messages to editors: URL error, cite error, missing references list, unnamed parameter error. – Jonesey95 (talk) 20:09, 18 December 2013 (UTC)

@Jonesey95: Does the bot also check Category:Pages with URL errors? Thanks! GoingBatty (talk) 02:10, 23 December 2013 (UTC)
Yes. I have added it above, but it was already in the bot; you can see a typical notification in the "URL error" link above. Thanks for catching that. – Jonesey95 (talk) 06:00, 23 December 2013 (UTC)

Extra newspaper parameters

Some newspaper citations, such as the one added in this edit, referring to The Times, have values for issue and column. Should {{Cite news}} have equivalent parameters? If not how else should they be entered? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:25, 22 December 2013 (UTC)

Like this?
{{cite news|title=Local Authorities And Cremation |date=31 August 1928 |newspaper=[[The Times]] |at=p. 9 col E |issue=44986}}
→"Local Authorities And Cremation". The Times. No. 44986. 31 August 1928. p. 9 col E.
Use |at= for page and column, |issue= for the issue number, change date to dmy format, no |accessdate= because no |url=.
—Trappist the monk (talk) 17:46, 22 December 2013 (UTC)
(edit conflict)There's a {{cite news}} version of {{Cite newspaper The Times}} to be found at {{Cite newspaper The Times/sandbox}} which I guess what the edit you've seen is trying to emulate and the sandbox may solve. NtheP (talk) 17:49, 22 December 2013 (UTC)
Ha! That was me. I'd completely forgotten about that.
—Trappist the monk (talk) 17:54, 22 December 2013 (UTC)

Thank you. The existing parameters which you use are not in the toolbar dialogue which I used, and the access date is generated automatically by that tool uses. Can these bugs be addressed? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:29, 22 December 2013 (UTC)

I'm sure that the tool's bugs (if they are bugs and not an intentionally limited subset of the {{cite news}} template) can be addressed. I suspect that here is probably not the best place to accomplish that. Surely there is a talk page for your tool?
—Trappist the monk (talk) 20:40, 22 December 2013 (UTC)
As I understand it, the only reason the special Times template (of which I disapprove) includes those parameters is because issue and column are part of the Times Archive's special way of citing itself. These features are not usually included in newspaper citations in the real world, and I don't think they should be included in "cite news" generally. They are not necessary. Things are complicated enough already. -- Alarics (talk) 21:52, 22 December 2013 (UTC)

Icon templates in language parameters

When the icon templates (e.g. {{sv icon}}) are used in the |language= parameter, we see references like this:

I believe that the Reflinks tool is the primary way these templates are ending up in citations. Although I contacted Dispenser about this almost two years ago, it's still making the same error. Should the citation templates be fixed to display the references properly when the icon templates are used, or should I submit a bot proposal to fix these? Thanks! GoingBatty (talk) 17:05, 26 December 2013 (UTC)

Let's not hold our breath for Reflinks to get fixed. There a a zillion bug reports and some very long-standing bugs.
The documentation for the language parameter clearly states that templates should not be used, and that statement has been in the documentation for almost two years (the statement was added to {{cite web/doc}} on Feb 15, 2012, AFAICT), so it should be uncontroversial to have a bot that replaces "language={{sv icon}}" with "language=sv". The bot would need to operate on an ongoing basis, since Reflinks will keep creating these links, and the fix should probably be included in the AWB common fixes.
What are the potential bugs in a simple replacement regex like "language=\{\{([a-z][a-z]) icon\}\}/language=\1" ? (I am not a professional regex writer, so that could be totally wrong.) Note that a few of the xx icon templates use a three-letter language code, e.g. {{ace icon}}, which yields (in Acehnese). We would also need to ensure that replacements happened only within citations, not within infoboxes and other places where "language={{sv icon}}" might be valid.
I am also OK with having the CS1 module automatically render the language in plain text if that is simpler overall. It would give editors immediate feedback, though it's a bit opaque and confusing, since when I add a template to an article, I expect to see that template rendered. – Jonesey95 (talk) 17:33, 26 December 2013 (UTC)
We still have 11 CS1 templates that use {{citation/core}}, not the Lua CS1 module. --  Gadget850 talk 17:53, 26 December 2013 (UTC)
Reflinks always suggests {{cite web}}, so I would guess most of the issues would be within this template. However, the tool allows the user to change it to a template that uses {{citation/core}}. GoingBatty (talk) 18:21, 26 December 2013 (UTC)

Check ISO 639-1

On a related note, {{Check ISO 639-1}} may be of interest; see discussion at Wikipedia:Lua requests/Archive 3#Language of native names. Perhaps a similar approach could be used to catch instances such as those discussed above? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:38, 26 December 2013 (UTC)

Question about displaying error messages

Category:CS1 errors: dates states "While most of the Citation Style 1 error messages are visible to all readers, some remain hidden." How much flexibility do we have with displaying error messages for this particular category? Is it all or nothing, or can we get more granular than that, such as displaying some error messages for dates that can't be fixed by bot? Thanks! GoingBatty (talk) 17:42, 26 December 2013 (UTC)

A few months ago, there was a hue and cry on this page or a similar one (I'll dig it up if you're interested) about the red messages that had recently been exposed. At that point, all CS1 error messages were displayed by default (some of them only recently). After a discussion, the consensus was to re-hide the most recently revealed messages until a bot could go through the categories and fix the bot-fixable errors.
My takeaway from that discussion is that once a bot has fixed all of the fixable error messages in a category, the consensus was that we should unhide the error messages for that category so that editors would know there were errors and possibly try to fix them. This involves changing a "hidden" variable's value from "yes" to "no" (or something equivalent) in the CS1 module's code. I don't think there is further granularity at this point; a given category's message is either hidden or visible to regular editors/readers who have not modified their CSS files.
Trappist the monk will be able to correct any errors in the above paragraphs. – Jonesey95 (talk) 21:44, 26 December 2013 (UTC)
Currently there is only one error message for date checking. We would have to add separate error checking for "dates that can't be fixed by bot". First, you would have to define and differentiate it. --  Gadget850 talk 22:29, 26 December 2013 (UTC)

Procedure when author is "Staff"

I'm looking at a Featured List nomination and some of the refs are credited to "Newsarama Staff" as this is what is given as the author. My understanding is that in this case the author field should just be empty, but I wanted to be sure before I advise the candidate to enact this. Darkwarriorblake (talk) 20:39, 29 December 2013 (UTC)

I agree. "Staff" is never a useful piece of information. The reader can surely take it as given that, if no specific author is mentioned, the author belongs to the staff of the source in question. -- Alarics (talk) 09:51, 30 December 2013 (UTC)
I concur. Same goes for "team", "editors", etc. --Lexein (talk) 11:52, 30 December 2013 (UTC)
See Help:Citation Style 1#Authors where is included this example:
|author=<!--Staff writer(s); no by-line.-->
—Trappist the monk (talk) 13:17, 30 December 2013 (UTC)
I disagree with the suggestion of leaving it blank, or even a hidden comment clarifying it. This has come up as an issue in several GAN's I've ran early, where the reviewers questioned who the author was when the field was left blank. I see no harm in informing the reader that the author was staff directly and not a possibly-unreliable guest contributor (as can be the case with many websites).--Kung Fu Man (talk) 02:53, 31 December 2013 (UTC)
Better than leaving the field blank is to delete it altogether. -- Alarics (talk) 10:15, 31 December 2013 (UTC)
@Kung Fu Man: If any of those GANs involved articles where the author field was commented out as above, could you please provide links to those discussions, so we can invite the reviewers to join the discussion here? Thanks! GoingBatty (talk) 16:38, 31 December 2013 (UTC)

Do not blank or remove unless there is a local consensus to do so (on the talk page of the article). Although there is no harm in a editor making a bold edit to a page, this is not a job for a bot or a user running a semi-automated script such as AWB (as that is potentially disruptive and not bold unless there has been an RfC with many participants to gauge the consensus on this -- eg an RfC at village pump). Usually "author=...staff..." should be left alone, particularly as it is an link field to {{harvnb}} and similar templates. -- PBS (talk) 12:00, 31 December 2013 (UTC)

@PBS: Thanks for continuing the conversation here. If you have an example where "author=...staff..." is included in {{harvnb}} or a similar template, could you please post it here so we can review it together? Thanks! GoingBatty (talk) 16:38, 31 December 2013 (UTC)

I think this is a symptom that grows out of the history of CS1. It originally was kinda sorta modelled on APA and MLA, but never had a style manual of its own. Now it is being regarded as a separate style, but many issues that have been decided in more established styles have never been considered for CS1. In the case of an institutional that is both the author and publisher (or stated another way, the name of the individual author(s) is/are not given), there is no guidance about which of these options should be adopted:

  1. List the institution as the author and omit the publisher
  2. List the institution as the author and list the publisher as "author"
  3. Omit the author and list the institution as publisher
  4. Put some generic word like "staff" for the author and list the institution as publisher.

If one of these options is to be selected, a well-advertised RFC should be conducted. Jc3s5h (talk) 17:13, 31 December 2013 (UTC)

A fifth option, especially considering that the input value(s) of the parameters are emitted as metadata would be to redundantly list the institution as both author and publisher. Imzadi 1979 → 02:38, 1 January 2014 (UTC)
This fifth option is similar to how I handle maps and their cartographers. For some, a different company drew the map for publication by the entity that actually issued it, but in other cases, the publisher drew it. So you'd get:
  • 1936 Official Michigan Highway Map (Map). Scale not given. Cartography by Rand McNally. Michigan State Highway Department. June 1, 1936. § B10. {{cite map}}: Check date values in: |date= (help)
  • State Transportation Map (Map). 1 in:15 mi / 1 cm:9 km. Cartography by MDOT. Michigan Department of Transportation. 2012. § B10.
The publisher and cartographer are each credited, so there's no real reason we couldn't double up by crediting some works authored by the same corporate entity that published it by redundantly listing said entity as both the author and publisher where appropriate. Of course, if there is a specific office or committee that can be attributed, then more specific group should be used instead. Imzadi 1979 → 08:51, 1 January 2014 (UTC)
  • I find that "Staff" is entirely appropriate for citing news stories where the author is given as "staff" or "Times staff" or "our correspondent". It does provide information, just not as much as a specific name. "Staff" is not appropriate when the document is in fact a corporate utterance, then the corporate name is appropriate for the author. See OCLC's 110 Main Entry–Corporate Name (NR)] course down the page for the definition. But just because an entity publishes a book or article, does not mean that it is a corporate utterance. Take a look at Resource Description and Access (RDA) or the earlier AACR2, your library should have a copy. Let's not reinvent the wheel. Or more to the point, let us not make things more difficult than necessary. --Bejnar (talk) 07:48, 1 January 2014 (UTC)
  • I notice the advice about adding an HTML comment in the author parameter when no individual author (or group or institution that isn't identical to the publisher, journal, or newspaper) was added 16 December 2011 with this edit by User:SMcCandlish. This change was never discussed on this talk page; the first talk page comment is dated 23 December 2011.
I also notice that the template where this question is most likely to arise, {{cite news}}, does not repeat this advice. Thus I consider the advice to not have been properly advertised and discussed. Jc3s5h (talk) 18:45, 2 January 2014 (UTC)
As far as I know, there is nothing that requires that discussion must accompany edits made in Wikipedia. Were that a requirement, nothing would ever be done. Can you direct me to a policy or guideline that mandates advertisement and discussion before changes, like the edit to which you refer?
—Trappist the monk (talk) 22:45, 2 January 2014 (UTC)
I don't claim every change requires discussion. But considering that the help:Citation Style 1 page isn't widely followed now, and was followed even less in 2011, and that now that people have finally noticed the advice, there are a variety of points of view being expressed, I don't think the notice and discussion were adequate for this particular piece of advice. Jc3s5h (talk) 23:38, 2 January 2014 (UTC)

Question about bot edits

As PBS alluded to above, I started using my bot to make edits such as |author=Staff to |author=<!-- Staff --> based on the conversation here, and this previously approved request. My bot was temporarily blocked, and two editors would like me to revert each of the edits. I'm happy to do so, but concerned that other people will be equally concerned about the mass reversion. Instead of acting hastily, I'd like to take a moment and discuss it here and then take the appropriate action. Thanks! GoingBatty (talk) 17:34, 31 December 2013 (UTC)

The previous consensus seems reasonable enough to me notwithstanding that only three editors commented at the time. Sure, there's no real "harm" to including it just like there's no real harm in eating cardboard. I fail to see the problem in removing |author=staff, as I also see little point in having something so seemingly useless apparently for the sake of populating an empty field. However, I would reserve final comment until PBS demonstrates just how/where it's "useful" to include it.  Ohc ¡digame! 22:04, 31 December 2013 (UTC)
@User:Ohconfucius: Can you explain why or how your edit apparently vandalized Editor GoingBatty's post?
—Trappist the monk (talk) 22:18, 31 December 2013 (UTC)
I have verified in my sandbox that the {{sfn}} template (and I presume other Harvard-related templates) works when the parameter "author = Staff" is used with cite journal. So if anyone has set up short footnotes or Harvard citations relying on the author being "Staff", removing the author parameter will break those citations. Jc3s5h (talk) 23:05, 31 December 2013 (UTC)
  • All that means is that the harvard template expects that field to be populated. It makes the assumption that use of the template is appropriate, although it may not be. it also assumes that there is no better data to put into.that field. -- Ohc ¡digame! 11:14, 1 January 2014 (UTC)
I, at least, have done that with Harvard style. --Bejnar (talk) 08:06, 1 January 2014 (UTC)
There are ways to link a short footnote to the corresponding full citation without using an author, but a bot wouldn't be able to do that, so a bot should not going around destroying working citations just because Ohconfucius prefers to not use "Staff" for the author parameter. Jc3s5h (talk) 14:09, 1 January 2014 (UTC)

Three people on a projectwide issue, on a rarely watched Help talk: page, is not consensus sufficient to run a bot to remove something from hundreds of articles. The onus to demonstrate consensus sufficient to run such a bot is on the bot operator, not on the people "complaining" about the bot edits; yes, BAG should have caught this, but its failure to do so does not excuse the bot operator from this important responsibility. Bots should not be used to win disputes over reference formatting. --Rschen7754 08:18, 1 January 2014 (UTC)

Also, this is the wrong forum for this sort of discussion: in order for it to actually apply, it needs to be part of WP:MOS. --Rschen7754 08:21, 1 January 2014 (UTC)
Actually, I disagree. Our MOS is silent on defining a citation style for use in the articles, deferring to the usage of a citation style defined elsewhere. Since MLA style has its stylebook, and Chicago has its book, the guidelines for how to handle "Citation Style 1" are this page. Imzadi 1979 → 08:51, 1 January 2014 (UTC)
However, this page cannot mandate a particular style, as it is not a guideline and has not been established through the consensus of the greater Wikipedia community. --Rschen7754 08:58, 1 January 2014 (UTC)
Actually, in a sense, it can. This page defines what is CS1. The problem is that the definition hasn't caught up to real-world usages and considerations, as the above discussion shows. Our MOS defines the in-house style used when writing Wikipedia articles, except the in-house style used for citation formatting. On that topic, it punts. Editors are then free to use APA, MLA, Chicago, Vancouver, Bluebook, or our editor-created CS1 or CS2 styles, among others. All the MOS says is that the application of a particular citation style be consistent. Imzadi 1979 → 09:03, 1 January 2014 (UTC)
But it cannot prohibit or mandate the use of certain fields, however, across Wikipedia. --Rschen7754 09:08, 1 January 2014 (UTC)
It doesn't need to be part of MOS to apply. Bot operations are done upon WikiProject instructions and template instruction all the time.
As |author=<!-- Staff --> has been part of the {{cite news}} doc for at least five years, it is pretty much codified. With its long history, I see no problem in BAG approving this.
The problem arises when the real world (people not following cite news' instructions for legitimate reasons) vs what is written conflicts. Nothing new. This discussion is dead in the water until the above discussion is revolved. No reason to revert bots edits *if* the above discussion keeps the docs the way they are. Bgwhite (talk) 08:54, 1 January 2014 (UTC)
Wrong, see Jc3s5h's message above about broken internal citations. Can the bot selectively restore those? --Bejnar (talk) 09:17, 1 January 2014 (UTC)
I can write my own "guidelines" in some tucked away page in the Help: namespace, but as long as there's no consensus behind these guidelines, they're useless. I do not see the appropriate level of consensus for such a bot run that would have such far-ranging effects, over many WikiProjects and subject areas. --Rschen7754 09:05, 1 January 2014 (UTC)
  • Templates cannot be designed to cover all eventualities, so there's more to editing than just blindly using templates. It still makes little sense to me when i see "staff" or "editor" or "admin" in the author parameter. -- Ohc ¡digame! 11:14, 1 January 2014 (UTC)
  • On another bot issue, I just saw an example of cite web where the byline was "admin", i.e. the site admin, and that's what the editor used in the template. BattyBot deleted the author information. this edit. --Bejnar (talk) 09:17, 1 January 2014 (UTC)
  • I agree with Rschen7754's statement "Three people on a projectwide issue,..."
  • I strongly disagree with User:Imzadi1979's statement "Actually, in a sense, it can. This page defines what is CS1." CS1 is really just an implementation of what was here before and there has to be consensus for change and a change that involves many pages across whole spectrum of articles needs to be done only after an RfC is held in a prominent place and is widely advertised. -- PBS (talk) 13:06, 1 January 2014 (UTC)
  • Re the comment about {{cite news}} then just change it for those articles that use staff in that template, although I think that is a mistake as documentation does not have to compile and so the documentation my not affect what people do.

As to the use of staff in the author field linked to harvnb is a tricky thing to search, however a search "BBC staff" returns Battle of Worcester as the first example of using "BBC staff" with harvnb/sfn. -- PBS (talk) 13:06, 1 January 2014 (UTC)

I have proposed the approval of BattyBot 24 be revoked. Jc3s5h (talk) 14:26, 1 January 2014 (UTC)

Reversion of bot edits

Happy New Year, and thank you all for your input on this important matter. While I don't see any examples of where any of the bot's edits actually broke any citations with {{sfn}} or similar templates, the fact that it COULD do so is very troubling. Therefore, I will be manually reverting each of the bot's edits that commented out "Staff". I will also post all of BattyBot's find and replace rules at Jc3s5h's proposal for further discussion. Thanks! GoingBatty (talk) 21:23, 1 January 2014 (UTC)

Note that when I am reverting the bot's edits, I am stating in the edit summary per discussion at Help_talk:Citation_Style_1#Procedure_when_author_is_"Staff", so curious editors can come join this discussion. GoingBatty (talk) 22:30, 1 January 2014 (UTC)
I'm about halfway done with the reversions, although some were already done by Bejnar, Rschen7754, PBS, Imzadi1979, Dough4872, Awardgive, and Kung Fu Man. It was interesting to see that while those editors involved in improving articles related to US roads were likely to have reverted the edits, some articles related to space or UFC had editors make subsequent changes without restoring "Staff". I wonder how many people will be reverting my reversions. I also noticed that a few editors were inspired to change "Staff" to a more descriptive value.
This section started with Darkwarriorblake asking about |author=Newsarama staff in regards to a Featured list nomination. The bot changed 11 articles to |author=<!--Newsarama staff-->. None of these edits have been reverted by other editors. Based on the conversation in Featured list discussion, I'd like to let these edits stand, unless someone who works in comics-related articles would like me to revert them. Any objections? GoingBatty (talk) 02:44, 2 January 2014 (UTC)
 Done - 697 reversions. GoingBatty (talk) 04:29, 2 January 2014 (UTC)
  • My !vote is to include staff writer. If the source itself provides "staff author" we should mirror what the source says. It's difficult to know why or how end users will use that information but it's presumptuous to assume it is useless or not needed, otherwise why did the source include it. As well, Wikipedia readers may interpret a blank author field as a lazy or incomplete citation - it's often unclear why the author field is blank - including "staff writer" resolves any question. -- GreenC 03:49, 2 January 2014 (UTC)
    A lot depends on whether there is known editor. In the case of {{EB1911}} as most of the articles do not have a specific author then just leaving it blank means that the editor Chisholm can be user for {{harv}}. In the case of the Economist it is their policy not to include authors of their articles, but the chief editor may not always be known to the person citing the article, in which case "Economist staff" is useful. Also selecting on the word "staff" leads to the bizarre case were if an editor uses the construct "author=National Heritage" its OK, but if they use "author=National Heritage staff" it is not. -- PBS (talk) 11:27, 2 January 2014 (UTC)
  • I notice the advice about adding an HTML comment in the author parameter when no individual author (or group or institution that isn't identical to the publisher, journal, or newspaper) was added 16 December 2011 with this edit by User:SMcCandlish. This change was never discussed on this talk page; the first talk page comment is dated 23 December 2011.
I also notice that the template where this question is most likely to arise, {{cite news}}, does not repeat this advice. Thus I consider the advice to not have been properly advertised and discussed. Jc3s5h (talk) 18:45, 2 January 2014 (UTC)

Migrating cite speech

I have begun migrating {{cite speech}} from {{citation/core}} to Module:Citation/CS1. A parameter unique to {{cite speech}} is |event=. This parameter is assigned to the {{citation/core}} parameter |Series=. This seems odd to me. In many respects, {{cite speech}} is similar to {{cite conference/old}}. A difference is that the {{cite conference/old}}-unique parameter |conference= is assigned to the {{citation/core}} parameter |Other=.

From {{citation/core/doc}}:

  • |Other= Other details to be inserted in a particular place.
  • ⊗ |Series= series of which this periodical is a part.

(⊗ indicates a parameter included in the citation's COinS metadata)

It seems that the roughly analogous parameters |event= and |conference= should have been using the same {{citation/core}} parameter which I think should have been |Other=. I think this because in the context of {{cite speech}} and {{cite conference}} the two unique parameters serve much the same purpose.

With that in mind, I have, in Module:Citation/CS1/Configuration/sandbox and Module:Citation/CS1/Whitelist/sandbox added parameters |event= and |eventurl= as aliases of |conference= and |conferenceurl=. When compared with the current {{citation/core}}-based {{cite speech}}, the Module:Citation/CS1/sandbox version of {{cite speech}} renders slightly differently as can be seen in this comparison:

Cite speech comparison
Wikitext {{cite speech|date=December 9, 1948|event=Third regular session of the United Nations General Assembly|first=Eleanor|last=Roosevelt|location=Paris, France|title=On the Adoption of the Universal Declaration of Human Rights|url=http://www.americanrhetoric.com/speeches/eleanorrooseveltdeclarationhumanrights.htm}}
Live Roosevelt, Eleanor (December 9, 1948). On the Adoption of the Universal Declaration of Human Rights (Speech). Third regular session of the United Nations General Assembly. Paris, France.
Sandbox Roosevelt, Eleanor (December 9, 1948). On the Adoption of the Universal Declaration of Human Rights (Speech). Third regular session of the United Nations General Assembly. Paris, France.

When |event= is not included in the citation, the new renders the same as the old. See the testcases for more.

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

All of the test cases look reasonable. Nice work. I think that locating "(Speech)" after the title makes more sense than after the event. The modifier "(Speech)" applies to the title. The event itself is not the speech. Does that make sense? – Jonesey95 (talk) 16:19, 30 December 2013 (UTC)
I don't remember my rationale for this when I updated speech to core, but this looks good. --  Gadget850 talk 16:50, 30 December 2013 (UTC)
Ok. I've tweaked Module:Citation/CS1/sandbox to unconditionally set the local variable TitleNote (normally assigned the value provided by |department=) to hold the text string " (Speech)" (without quotes but with the leading space). Since |department= is used by {{cite news}}, I suspect that this won't be a problem.
—Trappist the monk (talk) 18:42, 30 December 2013 (UTC)
That looks good. I suspect I updated Cite Speech to core before I discovered TitleNote, which makes more sense. --  Gadget850 talk 18:48, 30 December 2013 (UTC)
You know, it's looking like the Wikimedia software has it in for me. Yet again, one of my postings has removed one of yours. Sigh. I've restored your 2013-12-30T16:50 posting.
—Trappist the monk (talk) 19:11, 30 December 2013 (UTC)

Quote within title parameter

When a quote is used for the title of an article, as in this reference from Love and Affection, the single quotes butt right up against the automatically generated quotation marks.

  • {{cite web|author=Birch, Helen|title='I prefer birdsong to chatter'|url=http://arts.guardian.co.uk/features/story/0,,1627347,00.html|work=[[The Guardian]]|date=3 November 2005|accessdate=7 April 2008}}
  • Birch, Helen (3 November 2005). "'I prefer birdsong to chatter'". The Guardian. Retrieved 7 April 2008.

Is it acceptable to use {{'-}} and {{-'}} to add a bit of space between them, as I did below, or does that mess up the COinS output? Is this documented anywhere?

  • {{cite web|author=Birch, Helen|title={{-'}}I prefer birdsong to chatter{{'-}}|url=http://arts.guardian.co.uk/features/story/0,,1627347,00.html|work=[[The Guardian]]|date=3 November 2005|accessdate=7 April 2008}}
  • Birch, Helen (3 November 2005). "'I prefer birdsong to chatter'". The Guardian. Retrieved 7 April 2008.

Thanks! GoingBatty (talk) 15:39, 31 December 2013 (UTC)

Doing so makes the COinS data for the title look like this:
&rft.atitle=%3Cspan+style%3D%22padding-left%3A0.2em%3B%22%3E%26%2339%3B%3C%2Fspan%3EI+prefer+birdsong+to+chatter%3Cspan+style%3D%22padding-right%3A0.2em%3B%22%3E%26%2339%3B%3C%2Fspan%3E
when it should look like this:
&rft.atitle=%27I+prefer+birdsong+to+chatter%27
This issue of quote marks, either as single or double is one of those things on my todo list. Module:Citation/CS1 should detect leading and trailing quote marks and insert the appropriate markup in the displayed version of the title when the title would normally be quoted.
So, the answer to your question is: no, don't add {{'-}} and {{-'}} to CS1 |title=.
—Trappist the monk (talk) 15:53, 31 December 2013 (UTC)
(edit conflict)Do we need the single quotes here? We already allow for refactoring titles to a point, such as all caps to title case. If quotes are included, I would rather see the module add the spacing by checking for opening and closing quotes, single quotes and apostrophes. --  Gadget850 talk 16:03, 31 December 2013 (UTC)
Answering Gadget850: The quotation marks here are part of the original title of the article, so yes, they are appropriate. A similar, clearer example title might be something like " 'I only kissed her,' says wife accused of adultery", where the original title already has quotation marks in it.
Answering the original query: I often use &thinsp; to separate multiple quotation marks in articles; I expect that messes up the COinS data as well. I look forward to having the module be able to insert a little space without editors having to do it manually.
  • {{cite web|author=Birch, Helen|title=&thinsp;'I prefer birdsong to chatter'&thinsp;| url=http://arts.guardian.co.uk/features/story/0,,1627347,00.html|work=[[The Guardian]]|date=3 November 2005|accessdate=7 April 2008}}
  • Birch, Helen (3 November 2005). " 'I prefer birdsong to chatter' ". The Guardian. Retrieved 7 April 2008.
– Jonesey95 (talk) 16:31, 31 December 2013 (UTC)
I expect that messes up the COinS data as well. Yep: &rft.btitle=%26thinsp%3B%27I+prefer+birdsong+to+chatter%27%26thinsp%3B
—Trappist the monk (talk) 16:44, 31 December 2013 (UTC)
Module:Citation/CS1/sandbox, {{cite book}}, {{cite journal}} and {{cite web}}:
And to be sure I didn't break anything:
  • "Unquoted chapter". Unquoted title.
  • "Unquoted title". Prestigious Journal.
  • "Unquoted title".
And some likely mistyped titles:
  • {{cite book/new |title="Fully double quoted title" |chapter="Doubled double-quote at end of chapter""}}
  • {{cite journal/new |title='Doubled single quote at end of title'' |journal=Prestigious Journal}}
  • {{cite journal/new |title=''Doubled single quote at start of title'' |journal=Prestigious Journal}}
  • {{cite web/new |title=''Double single-quote" at start and end of title'' |url=//example.com}}
—Trappist the monk (talk) 14:48, 1 January 2014 (UTC)
I've been following the MOS quote nesting rule so that the outer quotes in the title itself are single, etc., to take account of the enclosing double quotes we add. Is this wrong? I find the above examples with repeated double quotes typographically clumsy. --78.43.79.189 (talk) 19:33, 2 January 2014 (UTC)
I agree, the pairs of double quotes does look odd. I'm inclined, though, at least for now, to let editors decide how they want to handle quote nesting. Perhaps if I'm feeling ambitious, I'll tackle getting nested quotes to work according to the MOS. For the time being, I think that kerning the quote marks, regardless of pairing, is an improvement.
—Trappist the monk (talk) 22:29, 2 January 2014 (UTC)
Thanks. Your inclination sounds fine! Parsing the nesting quotes would be "quite interesting" but probably not justified. It is good and thorough to test all combinations as you have, but any examples in the documentation should be MOS-conformant. Perhaps we can have a link to MOS:QUOTEMARKS and at least one conformant example in the CS1 documentation? --78.43.79.189 (talk) 23:47, 2 January 2014 (UTC)

Cite DNB

{{Cite DNB}} is returning Help:CS1 errors#bad_date in examples like this - Hayton Castle - presumably because no volume is specified and the default otherwise is a date range. Anyway round this? NtheP (talk) 21:58, 1 January 2014 (UTC)

I followed the Wikisource link. At the top of the page it says volume 34. I have no reason to believe that it isn't volume 34 so:
{{cite DNB|wstitle=Lowther, Richard |volume=34}}
Lee, Sidney, ed. (1893). "Lowther, Richard" . Dictionary of National Biography. Vol. 34. London: Smith, Elder & Co.
—Trappist the monk (talk) 22:28, 1 January 2014 (UTC)
that fixes this example but I was talking about the general case where |volume= isn't specified. NtheP (talk) 23:00, 1 January 2014 (UTC)
@Nthep: I hope we get an answer at Template talk:Cite DNB#CS1 errors when volume not included. GoingBatty (talk) 00:29, 2 January 2014 (UTC)

The general case is being discussed at Module_talk:Citation/CS1. – Jonesey95 (talk) 02:28, 2 January 2014 (UTC)

Trappist the monk if you want to fix cases such as {{cite DNB|wstitle=Lowther, Richard |volume=34}} then all power to you, but if you do then please include the author and page numbers as well:
However this is not really a fix for this page as it uses both {{cite DNB}} {{DNB}}. Here is a more elegant solution (but even that does not go far enough as the in-line citations need breaking down into specific page numbers and not a page range).
This is type of fix is easy in the case of "cite DNB" as just about all of it is on wikisource with page numbers on display. However for others encyclopaedias it is more difficult and time consuming take for example s:1911 Encyclopædia Britannica/Aix, it not include page numbers, for that you have to go and look at a source like this Encyclopædia Britannica/Aix and see here s:Wikisource:Bot_requests#Volume_information_for_CE1913 for an examle where the volume and article information on Wikisource is known to be inaccurate.
What I have proposed on template talk:Cite DNB is that we create another category for where the volume parameter is not set, that will allow us to see how large this problem is, and make it easier to monitor. -- PBS (talk) 12:22, 2 January 2014 (UTC)

For {{cite DNB}}, one conversation in one place please.

Moved to Template talk:Cite DNB

—Trappist the monk (talk) 13:21, 2 January 2014 (UTC)

Deprecated month parameter AWB script

I have created a simple AWB script to attack the largest of the CS1 error categories. The script concatenates |day=, |month=, and |year= when they are adjacent to each other in CS1 citations. The script concatenates them into a single |date=DD Mmmm YYYY parameter at the end of the citation; this is the format that Module:Citation/CS1 uses. The script is set to use Category:Pages containing cite templates with deprecated parameters.

The script does not do error checking (User:BattyBot/CS1 errors-dates is already doing that so I see no reason to duplicate that effort), it simply captures the content of the various parameters and lumps them together.

There has been enough testing to convince myself that the most common arrangement of the date parameters, |month= and |year= in that order, is working reliably. Editors don't seem to place these parameters in the reverse order – at least I haven't seen it more than once or twice in the limited testing I've done. I have yet to encounter the three parameter (|day=, |month=, |year=) case in any order.

Feel free to use and improve the script, perhaps it can be robotized.

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

@Trappist the monk: Since your suggestion resolves the error without changing the format of the date, I've added a new rule to User:BattyBot/CS1 errors-dates to also cover this.
Cite web comparison
Wikitext {{cite web|day=4|month=June|title=DMY test|url=http://wwww.google.com|year=2004}}
Live "DMY test". 2004. {{cite web}}: Unknown parameter |day= ignored (help); Unknown parameter |month= ignored (help)
Sandbox "DMY test". 2004. {{cite web}}: Unknown parameter |day= ignored (help); Unknown parameter |month= ignored (help)
Thanks! GoingBatty (talk) 03:29, 17 December 2013 (UTC)
@Trappist the monk: It appears your script doesn't add in commas for Mmmm dd yyyy format - see this edit. GoingBatty (talk) 02:28, 18 December 2013 (UTC)
True. But, it isn't intended to be making any fixes other than to move parameter values from |day=/|date=, |month=, and |year= into |date=<day/date> <month> <year>. I don't see much point in duplicating the function adequately handled by BattyBot 25‎.
—Trappist the monk (talk) 11:17, 18 December 2013 (UTC)
It may be necessary to do some bare minimum checking. This set of parameters from Arab Gas Pipeline:
|date=13/11/2012|month=11|year=2012
concatenates into:
|date=13/11/2012 11 2012
—Trappist the monk (talk) 12:18, 18 December 2013 (UTC)

Status

Status of converting this simple script to a robot to troll through Category:Pages containing cite templates with deprecated parameters:

  1. I'm relatively sure that the script is working properly. I've made some 1000–1500 supervised edits with it.
  2. Because I don't have a bot account and because the name of the account I would like was once used, I have initiated a usurpation request which should be settled 5 January 2014.

—Trappist the monk (talk) 13:06, 30 December 2013 (UTC)

BRFA.

—Trappist the monk (talk) 14:50, 4 January 2014 (UTC)

Discussion

Community consensus includes not only template maintainers, but also those that use templates to create article content. The deprecation of the month parameter has not been discussed outside template talk pages. Hence there is no broad consensus to deprecate this parameter. I will open up a discussion here shortly requesting wider community input. In the meantime, I request that bots hold off on automated replacement of the month parameter in {{cite journal}} templates. Boghog (talk) 06:54, 19 December 2013 (UTC)

Thank you for posting here. You have already been listened to. As was already explained in the bot request, month/year pairs will not be combined by the bot unless |date= (or |day=) is already present and contains a single number, indicating that the editor intended to show a day, month, and year. When a day is intended to be shown, the month parameter cannot be used, because the day parameter has been deprecated for a long time. The change above concatenates a day, month, and year into a date parameter. – Jonesey95 (talk) 14:26, 19 December 2013 (UTC)
I have failed to clearly state what it is that this script does. This script is separate and apart from Editor GoingBatty's robot script. This script is intended to concatenate |date= or |day= with |month= and |year= into |date= when all three are adjacent to each other in the CS1 template. Also, when |date= or |day= are not present, the script concatenates adjacent |month= and |year= into |date=.
—Trappist the monk (talk) 14:53, 19 December 2013 (UTC)
OK, thanks for the clarification. If there is no |date= or |day= parameter present, I question why it is necessary to concatenate adjacent |month= and |year= parameters. The |month= parameter has been widely used for a long time without problem. Furthermore concatenation increases the chances for inconsistency in the way dates are rendered. Finally it will create a lot of unnecessary edits. Why fix something that isn't broken? Boghog (talk) 16:25, 19 December 2013 (UTC)
I suggest that it might be best to open a separate, formal discussion about the month parameter. There have been a few discussions in scattered locations. Bring all of those discussions together in a new location, link to previous discussions, state your case with examples of how joining month and year may cause harm, ask for discussion, and be open to reasoned arguments. – Jonesey95 (talk) 16:50, 19 December 2013 (UTC)
|day= was also used for a long time as were various flavors of |accessdate=; we seem to have survived the withdrawal and consolidation of those parameters. How does concatenation of |month= with |year= increase the chances of rendered date inconsistency?
—Trappist the monk (talk) 17:16, 19 December 2013 (UTC)
We have survived the consolidation of |day= and |accessdate= in {{cite journal}} templates because they are rarely used. Specifying the day on which a journal article was published is overkill. Hence citation template filling tools such as WP:REFTOOLS and Diberri's Template filler do not even support the day parameter. Journal articles, after they are published almost never change, hence specifying an access date for a journal article generally does not make sense. In contrast |month= and |year= are frequently used. Consolidating the month with year into a single free format date parameter allows editors to specify "January 2014" or "2014 January", hence the possibility of inconsistency. Finally no one has provided a clear and concise explanation for why this deprecation necessary. How is the month parameter causing harm? Boghog (talk) 02:14, 3 January 2014 (UTC)
"date=2014 January" would generate an error message: Author (2014 January). "Title". {{cite web}}: |author= has generic name (help); Check date values in: |date= (help)
I suggest that it might be best to open a separate discussion thread about the month parameter. Having a discussion about the month parameter in this thread will be confusing, since the thread is about an AWB script. There have been a few discussions in scattered locations. Bring all of those discussions together in a new location, link to previous discussions, state your case with examples (preferably from actual citations in actual articles) of how joining month and year may cause harm, ask for discussion, and be open to reasoned arguments. (p.s. I fixed a typo in your post above, since that particular typo has led to tangents in the recent past.) – Jonesey95 (talk) 05:58, 3 January 2014 (UTC)
I am questioning the need for this particular AWB script, so how could having this discussion here possibly be confusing?
I am open to reasoned arguments. The problem is no one has provided a compelling argument for the deprecation. What harm is it causing? Please answer the question. The advantage of using using separate month and year parameters insures that month will always be displayed before year while merging the parameters into a single date parameter introduces the possibility of inconsistent formatting. Boghog (talk) 12:09, 3 January 2014 (UTC)
I have no interest in rewriting what I've written before on this same topic both in this forum and in Module talk:Citation/CS1. But, I will restate one point that somehow seems to be misunderstood: Deprecated does not mean deleted. |day=, for example, has been deprecated for a long time yet, when used, is still concatenated with |month= and |year= to form the displayed dmy format date. You are free to continue to use any and all of these three parameters and will be able to do so for the foreseeable future.
—Trappist the monk (talk) 13:45, 3 January 2014 (UTC)
Great! But then why is the parameter being proactively removed from existing citations by scripts and bots? Boghog (talk) 14:12, 3 January 2014 (UTC)
Journals themselves almost never include month or day in reference lists (see a list of representative examples below). The year, volume, issue, and page number is sufficient to unambiguously identify an article. Furthermore the year parameter has not be deprecated. If year, month, volume, issue, and page are all specified, it would be much cleaner to remove the month parameter entirely and leave the year parameter untouched.
List of representative citation styles used in scholarly journals (data obtained from EndNote):
Extended content
Please note that not a single one includes month or day of publication. Boghog (talk) 14:06, 3 January 2014 (UTC)
Articles in journals of that sort mostly cite other journals, with the occasional book or conference thrown in. But Wikipedia often cites magazines and newspapers, which may not have volume and issue numbers, and if they do, they are not as widely used as the date for citation purposes. Also note that cite journal, cite magazine, and cite news are all essentially synonyms, so many citations to magazines and newspapers may be made with the cite journal template.
Why don't you go back to all those style guides and see how they recommend citing a newspaper or magazine? Let me do one for you, the APA style (6th ed, p. 200, example 8)
Clay, R. (2000, June). Science vs. ideology: Psychologists fight back about the misuse of research. Monitor on Psychology, 39(6). Retrieved from http://www.apa.org/monitor/
Jc3s5h (talk) 14:30, 3 January 2014 (UTC)
The issue is the deprecation of the month parameter within the {{cite journal}} template. I have no issue with date parameters in {{cite news}}. If someone is citing a news paper article, they really ought to be using {{cite news}} and not {{cite journal}}. Boghog (talk) 14:34, 3 January 2014 (UTC)
Just to be clear, my preference is not to deprecate the month parameter in the first place. Furthermore if someone has included the date parameter in a cite journal template from the beginning, I have no objection. My only objection is proactive merging of month and year parameters into a single date parameter. Boghog (talk) 14:43, 3 January 2014 (UTC)
Leaving cite news aside, cite magazine is now a redirect to cite journal. If an editor wanted to cite the magazine Monitor on Psychology in an article that used CS1 she would have to use cite journal. If she were wondering whether to include the month in the date, and looked to the Publication Manual of the American Psychology Association for guidance, the answer would clearly be yes, she should include the month. Therefore your post incorrectly characterized the position of the APA manual. Jc3s5h (talk) 14:54, 3 January 2014 (UTC)
Thanks for pointing out this exception. I now agree that removing the month parameter entirely is bad idea. Again, my only objection is merging month with year into a single date parameter. The fact that citations to magazine articles often require month strengthens the argument not to deprecate the month parameter. Boghog (talk) 15:14, 3 January 2014 (UTC)

Bot to fix CS1 date errors

This is a note to say that a bot has been proposed that would fix CS1 date errors. See Wikipedia:Bots/Requests for approval/BattyBot 25. – Jonesey95 (talk) 04:56, 6 December 2013 (UTC)

FYI, this bot has been approved and is now running. I will direct any questions I receive to this page for further discussion. GoingBatty (talk) 14:28, 20 December 2013 (UTC)
Good. As of this moment, Category:CS1 errors: dates has 130,513 pages.
—Trappist the monk (talk) 14:54, 20 December 2013 (UTC)
BattyBot has gone through a little more than half the articles in the category, and has made 27,000+ edits. As of this moment, Category:CS1 errors: dates has 117,210 pages. Once it finishes the first pass, I'll look at some of the pages that it didn't update, add more rules and run again. GoingBatty (talk) 07:50, 27 December 2013 (UTC)
BattyBot has completed its first pass through the category, and has made 48,000+ edits. As of this moment, Category:CS1 errors: dates has 104,176 pages. I've updated the bot's code to fix more dates (with suggestions from Jonesey95) and now it's making a second pass. GoingBatty (talk) 01:56, 4 January 2014 (UTC)
The bot is finding and fixing a ton of errors in this pass. That's good. I just looked at a random sample of about 100 articles at the beginning of the alphabet, i.e. the articles through which the revised BattyBot has made a second pass. When I looked at a sample of articles after the bot's first pass a few days ago, I found that maybe 50-60% of errors were still bot-fixable via simple regular expression searches. In this second sample, I estimate that the bot-fixable portion is more like 10-15%. We're reaching a point of diminishing returns.
I estimate that about a third of the remaining erroneous dates were in an ambiguous format like "05/07/2003" or "2012.04.09" (i.e. human intervention is needed); about a fifth of them were valid date ranges like "5-11 December 2001" or "1999-2000" (i.e. the module code needs updating); another tenth (or so) were bot-fixable; and the rest were one-off nuttiness that needs human intervention.
I think that after this bot run, we could 1. compile a new list of errors for the bot to fix; 2. change the module code to allow valid date ranges; and 3. change the module code to make the error message visible after posting a notification to this effect in a highly visible location, since it will appear on 30,000+ articles. – Jonesey95 (talk) 04:46, 4 January 2014 (UTC)
@Jonesey95: Agreed with this proposed process, but you don't have to wait for the bot to finish run #2 to let me know if you find more date formats you think the bot could handle. Thanks! GoingBatty (talk) 14:29, 4 January 2014 (UTC)
BattyBot has completed its second full pass through the category (plus extra pages as I tweak the bot rules), and has made 71,000+ edits. As of this moment, Category:CS1 errors: dates has 87,921 pages. GoingBatty (talk) 04:55, 11 January 2014 (UTC)

Agency parameter

{{Cite press release}} has a parameter 'agency' for the press agency thru which the release is made, but this parameter is not even listed in the documentation for this template. Is there a reason to omit it, or should it be added promptly? DES (talk) 08:31, 6 January 2014 (UTC)

It would be better to abolish it as unnecessary. -- Alarics (talk) 11:30, 6 January 2014 (UTC)
It was added when the template was converted to the Lua module. I don't see any issue with it being included. --  Gadget850 talk 14:06, 6 January 2014 (UTC)
It is not unnecessary. It can be a significant element of metadata in such cases. i am going to add it to the documentation. DES (talk) 23:34, 8 January 2014 (UTC)
I concur that |agency= is important: it's closer to the original source, regardless of publisher or work published in. Here, it is closer in meaning to "publicity agency", as opposed to news agencies or wire services like U.S. UP/API and French AF. --Lexein (talk) 07:50, 13 January 2014 (UTC)

Does accessdate always need URL?

I'm used to seeing the |accessdate= requires |url= in citations for books and magazines where the reference has no link to an external web site, which I understand. However, if a citation has a |doi= parameter to link to an external web site, should it then be OK to include the accessdate? See Photoredox catalysis references 23 and 24 for examples. Thanks! GoingBatty (talk) 02:57, 7 January 2014 (UTC)

It's an example of where a presumably published immutable source, such as a journal (and unlike a website), does not get an accessdate because the content would always be the same regardless of when one accesses it. DMacks (talk) 03:12, 7 January 2014 (UTC)
I've asked this before, on this page I believe, and gotten the same answer. |doi=, |pmid=, and |pmc= all render as URLs that link directly to the source, or at least to an abstract of it. |pmc= even links a URL to the article's title.
Previous discussions here: March 2013, April 2013 at the Village Pump (LONG), August 2013.
In each of the above discussions, the idea of commenting out the accessdate parameter was brought up. Note that, as far as I can tell (disclaimer: I am often wrong), the accessdate is displayed only if the URL is present, so commenting out the accessdate will not remove rendered information from articles. Commenting out the accessdate will leave the information in the citation as a clue for editors who might want to locate a missing URL or a missing publication date. Apparently, people sometimes remove non-working URLs, leaving the accessdate in place. The accessdate gives a clue about which version of an archived page to include in the citation. – Jonesey95 (talk) 03:58, 7 January 2014 (UTC)
The criterion should be whether the URL parameter is populated. This parameter may be a link to a mutable webpage and so requires an accessdate. A generated URL based on the DOI, PMC or similar identifier is intended to link to an immutable target, so does not require an accessdate.LeadSongDog come howl! 18:03, 7 January 2014 (UTC)

Migrating cite podcast

I have begun migrating {{cite podcast}} from {{citation/core}} to Module:Citation/CS1. {{cite podcast}} looks to be a minor variant of {{cite web}} with a default |type=Podcast and an additional parameter |host=, an alias of |author=.

Because a podcast is an online resource, it seems to me that the citation is required to include |url=. We can create a whole new error message and category or we can choose to add pages with malformed {{cite podcast}} templates to Category:Pages using web citations with no URL which in Module:Citation/CS1/sandbox I have done.

{{cite podcast/new |title=Title |host=Host |date=27 Sep 1995}}
→Host (27 Sep 1995). "Title" (Podcast). {{cite podcast}}: Missing or empty |url= (help)

The error message help text will need to be tweaked if this part of the migration is retained.

Opinions?

—Trappist the monk (talk) 12:53, 11 January 2014 (UTC)

IMHO, for defunct podcasts, requiring URL is fine as long as there's some way to indicate that the podcast has gone offline and the URL is no longer "live". Example: http://deadpodcast.com vs http://livepodcast.com. Precedent: we presently intentionally "deadlink" malware links in hand-made refs, by removing or hidden-commenting the URL. --Lexein (talk) 13:54, 11 January 2014 (URC) (struckthrough --14:11, 12 January 2014 (UTC))
This looks good. When I updated podcast, I copied it from web. I also cleaned up all the templates before Lua was introduced so that you can easily compare them to non-Lua book or web. --  Gadget850 talk 14:57, 11 January 2014 (UTC)
{{dead link}}? How is a defunct podcast so different from a defunct text-based website that it (the defunct podcast) requires a separate mechanism to indicate its dead or defunct status?
—Trappist the monk (talk) 14:27, 11 January 2014 (UTC)
I retract chunks of my comment: we have |archiveurl=, so the problem is essentially solved if there's an archive. (My bad: the display of dead urls so that they're not clickable is actually a separate issue, and is not relevant to this discussion, so, sorry.) --Lexein (talk) 14:11, 12 January 2014 (UTC)

Thoughts on COinS

There are two main reasons why articles end up in Category:CS1 errors: dates: a date that doesn't conform with MOS:DATEFORMAT or extra text in a date field. The latter should be fixed because it causes problems with COinS. However, when someone clicks the Help link next to the Check date values error, it takes them to Help:CS1 errors#bad date, which only mentions the first issue. Should this be updated with a layman description of COinS and instructions to remove the extra text from the date field?

Also, I've seen many templates nested within CS1 templates, such as:

|work=[[Billboard (magazine){{!}}Billboard]]
|author={{aut|Clendinnen, Inga}} (see Xelha)

If these cause COinS issues, should they be removed, and should the template documentation be updated to state why they should not be used inside citation templates?

Should this information also be added to Help:Citation Style 1? Thanks! GoingBatty (talk) 15:00, 11 January 2014 (UTC)

Please turn this thread into a Request for Comment and advertise it in appropriate places. Since the statement about not adding explanatory text to parameters was added to Help:CS1 without discussion at a time when Help:CS1 was very obscure indeed, I feel this point needs ratification by the community. Jc3s5h (talk) 15:30, 11 January 2014 (UTC)
Parameters that become part of the COinS metadata are stripped of wikilink markup so that only the displayed portion of the wikilink (Billboard, in your example) becomes part of the COinS. This is done so that editors can wikilink various portions of the citation to accompanying Wikipedia articles.
{{aut}} should not be used in CS1 citations and there is a note in the template documentation that so states.
The documentation at Help:CS1 errors can always be improved. The error message help text does mention extraneous text but I have added further explanatory text.
Similarly, Help:Citation Style 1 can always be improved. I suspect that it should be rewritten so that it becomes more like a style guide. As it is, it seems to parrot the content of the various template documentation pages so offers little in the way of complete explanations and guidance. It's on my list of things to do.
—Trappist the monk (talk) 15:49, 11 January 2014 (UTC)
(edit conflict)
{{!}} is transcluded as a pipe, so it doesn't hurt anything; but it can certainly be replaced with a pipe as using the template doesn't fix anything. The Lua module injects only the piped text into the metadata.
{{aut}}, which redirects to {{smallcaps}} does inject HTML into the CoiNS metadata; this is documented on the template page. The Lua module does support |authorformat=scap but we have never discussed use. --  Gadget850 talk 15:52, 11 January 2014 (UTC)--  Gadget850 talk 15:52, 11 January 2014 (UTC)
Thanks everyone for the quick replies. I guess the RfC should be on the to do list before turning on the error message for everyone to see. Glad that {{!}} doesn't hurt anything, and sorry for missing the instructions at Template:Smallcaps. GoingBatty (talk) 16:29, 11 January 2014 (UTC)

Template:Cite AV media notes

If Template:Cite AV media notes "is used to create citations for liner notes from albums, DVDs, CDs and similar audio-visual media.", why have Template:Cite music release notes ("is used to create citations for the cover notes, booklet, liner notes, etc. of a music release (album or single).") and Template:Cite DVD-notes ("is used to create citations for DVD liner notes and booklets.")? It seems the "type" (or "format") parameter in Cite AV media notes can be used to specify "Release notes", "Liner notes", "CD insert notes", "DVD booklet", etc. Perhaps add these to the description section:

  • type: Provides additional information about the media type of the source; format in sentence case, e.g., CD insert notes, album liner notes, DVD booklet, etc. Displays in parentheses following the title. Defaults to Media notes.
Aliases: type, format

—Ojorojo (talk) 19:24, 11 January 2014 (UTC)

See Wikipedia:Templates for discussion/Log/2013 July 18. The first step would be to deprecate the other two templates, then migrate them. --  Gadget850 talk 19:28, 11 January 2014 (UTC)

Help with template: website?

In the website parameter.should one add the actual website, such as www.norfolkmills.co.uk when the full URL is http://www.norfolkmills.co.uk/Windmills/mileham-postmill.html , or when there is no clear official name for the site, just make up a name such as "Norfolk windmills," which is informative, but would provide little help if the link went dead. Edison (talk) 21:38, 17 December 2013 (UTC)

Looks to me like it should be |website=Norfolk Mills. See Norfolk Mills.
—Trappist the monk (talk) 21:58, 17 December 2013 (UTC)
What should be entered for the "website" parameter for http://www.ecastles.co.uk/mileham.html ? "Castles and fortifications of England and Wales"? Is it correct to append "website" to the chosen website name, or is that understood? Edison (talk) 22:11, 17 December 2013 (UTC)
Yep, |website=Castles and Fortifications of England and Wales (fortifications should be capitalized). No need to say that it's a website just as there is no need to say that On the Origin of Species is a book or that The Lancet is a journal.
—Trappist the monk (talk) 22:59, 17 December 2013 (UTC)
Should these be put in the publisher parameter instead, so the output isn't italicized? Thanks! GoingBatty (talk) 23:52, 17 December 2013 (UTC)
CS1 in general italicizes the larger work and quotes the smaller work. These are {{cite book}}, {{cite journal}}, {{cite encyclopedia}}:
"Chapter 1". A Famous Book.
"The Pedant: Insufferable Snobs Past, Present, and Future". The Journal of Pretentious Snobbery.
"The Paradox of Knowing Everything about Nothing". The All-encompassing Encyclopedia of Little Known and Mostly Useless Facts.
I think of the website <title> as something akin to a book title, or a journal title, or the name of an encyclopedia. The website <title>, Norfolk Mills or Castles and Fortifications of England and Wales in Editor Edison's examples, is then properly italicized. The name of the page addressed by |url= is more-or-less synonymous with the book's chapter name or the journal's or encyclopedia's article name.
—Trappist the monk (talk) 01:27, 18 December 2013 (UTC)
Thanks a lot for the insights. On random article patrol I constantly find raw URLs and I'd rather fix'em than just tag'em. But it is best to use cite web with the correct inputs. Edison (talk) 01:45, 18 December 2013 (UTC)
@Trappist the monk: WP:ITALICS states:
  • "Website titles may or may not be italicized depending on the type of site and what kind of content it features. Online magazines, newspapers, and news sites with original content should generally be italicized (Salon.com or The Huffington Post). Online encyclopedias and dictionaries should also be italicized (Scholarpedia or Merriam-Webster Online). Other types of websites should be decided on a case-by-case basis.
What criteria do you suggest to use when making the case-by-case basis decisions? Thanks! GoingBatty (talk) 01:51, 18 December 2013 (UTC)
If we're talking about website titles in CS1 templates then I do as I illustrated with Editor Edison's examples above. Help:Citation Style 1#Work and publisher may be helpful. If we're talking about website titles in article text, to which I think WP:ITALICS primarily applies, then I have no opinion that I will express here because that topic is outside of CS1's bailiwick.
—Trappist the monk (talk) 11:32, 18 December 2013 (UTC)
I can follow the logic/reasoning behind the move, but can't say that I agree with it. By looking at it in such a way defines the virtual property as a separate category of work that is in practice undistinguishable from the organisation. That distinction is way too abstract and fine for much of our audience, which consists of our lay editors and readers, and will result in no end of confusion. That logic may be accepted widely in the long run, but we should not meanwhile pioneer the definition of websites as "works" that ought to be italicised, quite contrary to how the outside world looks at it, and contrary to our own style guidelines. -- Ohc ¡digame! 03:19, 17 January 2014 (UTC)

Should we use both website and publisher tags? Wouldn't these be the same thing 99% of the time? Hcobb (talk) 21:22, 10 January 2014 (UTC)

  • I'm extremely unhappy that |website= is [the italicised] alias for "|work=". The confusion that is caused is real. There's certainly no point in using both, particularly when they are one and the same organisation behind it. Otherwise, we would have the same result but rendered with conflicting formatting – "Norfolk Mills, Norfolk Mills" in the example given above. We see that problem here, where all websites are italicised contrary to what's stated at MOS:ITALIC, which states that these should be on a case by case basis. The problem for websites is that most tend not to be italicised. Some are dynamic and many are static and the first point of contact for any given organisation. It's a frontspiece and not considered a mouthpiece, like a company journal. Yet by aliasing |website= to |work=, we implicitly declare that all websites generate original content and ought thus be italicised. Just take the example above, or the Microsoft website: these would be respectively rendered in the citation as "Norfolk Mills" and "Microsoft", whereas under usual conditions, these would never be italicised. If, however, we populate the |website= field with "norfolkmills.co.uk", it is immediately clear the information came from the website itself. But either way both instances would be incorrectly italicised. It doesn't make it right to italicise "norfolkmills.co.uk" irregardless, but it would not be "wrong" in any event to have 'Norfolk Mills' and 'Microsoft' as "publisher". It would have made much more sense aliasing it to |publisher=. -- Ohc ¡digame! 02:54, 17 January 2014 (UTC)

Month / season range order validation

In Module:Citation/CS1/sandbox I have enhanced the month / season range validation to require that the order in which the months or seasons appear in a citation is left to right, earliest to latest in time.

Month range order:

  • Pass: months are in proper order. February–March 2013.
  • Error: months are the same. June–June 2013. {{cite book}}: Check date values in: |date= (help)
  • Error: months not in proper order. December–March 2013. {{cite book}}: Check date values in: |date= (help)
  • Error: season / month pair. Spring–March 2013. {{cite book}}: Check date values in: |date= (help)
  • Error: month / season pair. December–Summer 2013. {{cite book}}: Check date values in: |date= (help)

Season range order:

  • Pass: seasons are in proper order. Autumn–Winter 2013.
  • Pass: seasons are in proper order. Summer–Fall 2013. – fall and autumn are synonymous
  • Pass: seasons are in proper order. Winter–Spring 2013. – this case unique to seasons because winter overlaps the new year boundary
  • Error: seasons are the same. Spring–Spring 2013. {{cite book}}: Check date values in: |date= (help)
  • Error: seasons not in proper order. Summer–Spring 2013.

Single season validation code changed so test single seasons:

  • Pass. Winter 2013.
  • Pass. Spring 2013.
  • Pass. Summer 2013.
  • Pass. Fall 2013.
  • Pass. Autumn 2013.
  • Error: capitalization. spring 2013. {{cite book}}: Check date values in: |date= (help)
  • Error: spelling. Sprong 2013. {{cite book}}: Check date values in: |date= (help)

—Trappist the monk (talk) 17:55, 2 January 2014 (UTC)

Thanks for doing this. Will you also be considering the date ranges proposed at Module_talk:Citation/CS1#Legitimate_date_range_examples_to_add_to_the_date_checking_part_of_the_CS1_module (specifically #1-5)? Thanks! GoingBatty (talk) 02:07, 4 January 2014 (UTC)
This change was the result of an experiment to see how to check other date ranges for proper left to right, earliest to latest, in time order. The experiment was inconclusive because I saw an easier way to do the comparisons for month/season ranges.
—Trappist the monk (talk) 10:53, 4 January 2014 (UTC)

Because WP:DATESNO specifies unspaced enadashes as the proper separator for date ranges like Month–Month year, I have changed Module:Citation/CS1/sandbox so that a hyphen or solidus separator will be caught as an error. Both BattyBot 25 and Monkbot 1 make this repair to dates they encounter.

—Trappist the monk (talk) 15:30, 13 January 2014 (UTC)

Testing in my sandbox seems to indicate that if a genuine n-dash is used, all is well, but if the &ndash; HTML entity is used, it is flagged as an error. I don't think this is appropriate, both due to the difficulty of typing a genuine n-dash, and the difficulty of distinguishing an n-dash from other dash-like marks in the edit window.

An additional point I was testing, but was stopped by the HTML entity problem, was testing whether a date such as "December 2230 – January 2231" for a journal which publishes issue 1 in the middle of the calendar year. Jc3s5h (talk) 15:21, 14 January 2014 (UTC)

CS1 doesn't really adopt a date format after all

The "Dates" section says "Dates formats per WP:DATESNO." That is a short cut to section 2.4, "Dates and years" section of the Manual of Style/Dates and numbers. One of the subsections is 2.4.1.4, "Consistency", which says:

* Publication dates in article references should all have the same format. Although nearly any consistent style may be used, avoid all-numeric date formats other than YYYY-MM-DD.

This text is present to allow for the fact that printed style guides might call for a different date format than what is suggested for the article body by MOS and MOSNUM.

So the intend of the statement in this help page was to apply the MOSNUM rules for article bodies, tables, and other places where space is limited, to CS1 citations. But by referencing a large section that includes the exemption for printed style guides, those limitations were not really adopted after all. I suggest the help page either be revised to point to more specific subsections, or the desired text be copied to this help page. Jc3s5h (talk) 23:33, 12 January 2014 (UTC)

I have made a change to CS1 indicating that the phrase "Although nearly any consistent style may be used" does not apply to CS1. Jc3s5h (talk) 17:08, 14 January 2014 (UTC)
Perhaps my brain isn't up to the task, but I see no such invalidation and cannot see how the line you've quoted prevents CS1 from adopting the date formats spelled out at WP:DATESNO. Nothing in that quote refers to any style, CS1 included. The line you quote only serves to notify editors that date format citation-to-citation should be consistent. Nothing more, nothing less.
The line of text that you have added to Help:Citation Style 1#Dates does not clarify anything for anyone. Had you revised Help:Citation Style 1#Dates to point to more specific subsections rather than editorialize, I would not have objected. As it is, I must object.
—Trappist the monk (talk) 22:26, 14 January 2014 (UTC)

The way the DATESNO shorcut is placed, it includes all of the following subsections: 

3.4 Dates and years

    3.4.1 Formats
        3.4.1.1 Acceptable date formats
        3.4.1.2 Unacceptable date formats
        3.4.1.3 Consistency
        3.4.1.4 Strong national ties to a topic
        3.4.1.5 Retaining existing format
    3.4.2 Era style
    3.4.3 Julian and Gregorian calendars
    3.4.4 Ranges
    3.4.5 Uncertain, incomplete, or approximate dates
    3.4.6 Linking and autoformatting of dates

It may not be obvious by reading the guideline, but reviewing the talk page history will reveal that "Although nearly any consistent style may be used..." to include the possibility that the style adopted for citations in a particular article may specify a date format different from the acceptable date formats listed near the beginning of DATESNO. A specific example is that APA style calls for publication dates to be written like "2014, January 14". Since CS1 is adopting its own date style, which is intended to be what the same as what is allowed in article text, tables, and areas where space is limited, the "escape clause" for printed style guides does not apply.

Maybe a way to describe what is allowed is:

Dates formats per WP:DATESNO:[Note 1]CS1 citations may use the same date formats that are allowed in article text; some view citations as areas where space is limited, so date formats allowed for tables may also be used. See WP:DATESNO. Further points:...

Jc3s5h (talk) 23:00, 14 January 2014 (UTC)

Better. Perhaps:
CS1 may may use any of the date formats permitted in the Table of acceptable date formats.
(this assumes that the table there has that caption; which it should do if for no other reason than accessibility by those who use screen readers)
By being more specific, I think that the need to describe what some people think becomes superfluous. Also the direct link to WP:DATES#Acceptable date formats removes the need to See WP:DATESNO.
As date ranges come online, we will have to carefully consider how to apply the rules at WP:DATES#Ranges. For example, nonbreakable spaces and nonbreakable hyphens should not be used with CS1 templates. While CS1 doesn't currently support wrap protection, it will (at least I intend it to do that). Presentation is the job of the template processor not the content provider.
Have you considered writing a CS1 style guide? You seem to have a unique interest in that realm so perhaps you might commandeer Draft:CS1 style guide and give it a go?
—Trappist the monk (talk) 00:48, 15 January 2014 (UTC)
I have revised my revision in line with what Trappist the monk suggested. I also removed the point that implied the YYYY-MM-DD format shouldn't be used for publication dates because there is no consensus for that restriction (although I personally have no use for that format in encyclopedia articles). Jc3s5h (talk) 18:17, 15 January 2014 (UTC)

Advisors on thesis

Any suggestions as to a good way to record someone's thesis advisor? {{cite thesis}} doesn't have anywhere, and it really doesn't fit with {{{editor}}} and the like. Maybe suitable fields could be added? —Phil | Talk 18:16, 16 January 2014 (UTC)

You can use |others=. Would an advisor write any part of the thesis? --  Gadget850 talk 18:31, 16 January 2014 (UTC)
The proper place to name the advisor is an article about the author of the thesis. This information does not belong in a citation to a thesis in other articles. —David Eppstein (talk) 18:59, 16 January 2014 (UTC)

Consistency within "work" and "publisher" fields

I have just made an edit to the help page that, whilst not completely doing away with any ambiguity, reduces it. The problem arises with the instruction to omit "The" unless where it would cause ambiguity. My preferred solution is for the data in such fields to mirror the WP namespace which the subject occupies. We would thus use "The Boston Globe" or "The Miami Herald" throughout any given article, to avoid awkward piping, or instances where citations would alternately show the two above as well as "Boston Globe" or "Miami Herald". -- Ohc ¡digame! 03:33, 17 January 2014 (UTC)

I agree, I have long thought the present instruction is wrong. In my view, practice should reflect what the newspaper calls itself, i.e. what does it say on the masthead. Thus for instance in the UK it should be The Daily Telegraph but just Daily Mail, which has no "The" on its masthead. In the US, it is The New York Times, but just Los Angeles Times without a "The". -- Alarics (talk) 08:44, 17 January 2014 (UTC)

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

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

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

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

Done.
—Trappist the monk (talk) 13:16, 9 November 2013 (UTC)
As far as I can tell, articles are still being brought into the new categories based on these changes. The job queue, or whatever it is that sweeps through all of the articles doing the equivalent of null edits, hasn't made it through all of the articles in the last 40 days. {{Anápolis weatherbox}}, for example, just popped into Category:CS1 errors: dates in the last 12 hours, along with six other weatherbox templates. Don't assume that the new categories currently contain all articles with the errors. The older categories appear to be stable.
Items 1 and 6 above are the source of the vast majority of additions to the CS1 error categories. – Jonesey95 (talk) 15:09, 19 December 2013 (UTC)
Articles are still being added to the CS1 date error and CS1 deprecated parameter error categories, more than 60 days after the module was changed. Don't assume that the new categories currently contain all articles with the errors, and don't be discouraged when the number of articles in the deprecated parameter category keeps rising. Editors are not adding deprecated parameters at that rate; the job queue is just catching up. – Jonesey95 (talk) 14:45, 5 January 2014 (UTC)
I'm not holding my breath, but it looks like articles may have stopped flowing into these two "new" categories. They were coming in at a fast clip, thousands a day, sometime last week, but I don't think I've seen any new ones since January 18. So it took 70 days for the job queue to recategorize all of the articles, unless there is a batch sitting in a corner somewhere that hasn't been touched. – Jonesey95 (talk) 18:27, 21 January 2014 (UTC)
On January 11, Category:CS1 errors: dates had 87,921 pages (see below). Right now it has 95,030 pages - that's an addition of about 700 per day. Ugh! GoingBatty (talk) 02:32, 22 January 2014 (UTC)
I think it pretty much stopped on January 18, though, so it was more like 1,000 per day for a week, then 10-50 a day since then. I believe that the low-speed additions are manual edits. The dates category could use another BattyBot run, maybe with disputed code commented out. – Jonesey95 (talk) 20:52, 22 January 2014 (UTC)
I hope you're right. Now there are 95,070 articles, which is in line with your stats. I made a commitment to not run the bot task until the RFC was done, so I'm going to honor that. I've been doing some work to find more things the bot can fix, and manually fix articles that require human research. Hope the CS1 code can be updated soon to ignore valid date ranges. GoingBatty (talk) 23:20, 22 January 2014 (UTC)

Bot to fix ISBN errors?

After the success of BattyBot 25, which has made over 71,000 edits and removed at least 40,000 articles from Category:CS1 errors: dates, I am inspired to propose another CS1 error category to be fixed by a bot. I think Category:Pages with ISBN errors is ready for a pass by a competent find-and-replace bot.

Here's a list of error types I have seen in that category. They are numbered manually for ease of discussion. All links are to actual instances of erroneous |isbn= parameters in actual articles.

  • 1. "|isbn=ISBN 978-1907475689" from Elizabeth Báthory in popular culture. Note the extra "ISBN" before the number.
  • 2. "|isbn=ISBN 9780773532861." from Elena Cornaro Piscopia. Note extra ISBN and final period; both should be removed.
  • 3. "|isbn= unknown" from Embouchure. I propose removing "unknown" entirely, since it provides no information that helps a reader locate the source. The bot could also comment it to be more conservative.
  • 4. "|isbn=978-0-226-53431-2 (hbk.)" from Emery Molyneux. Maybe comment out the extra text in case it is somehow useful to someone.
  • 5. "|isbn=0-8304-1580-7, 9780830415809" from Epic film. This is a very common construction in this category. The first ISBN should be removed, leaving only the second one, which will start with "97". Note that valid 10-digit ISBNs may have an "X" at the end. Otherwise, only numbers, hyphens, and spaces are valid characters (I believe).
  • 6. "|isbn=0-912483-99-7;" and "|isbn=0-7475-4213-9," from Electronic music. Note trailing punctuation.
  • 7. "|isbn = 0‐7637‐3823‐9" from Ergotism. These are apparently not hyphens. All non-hyphen dashes should be replaced by hyphens.
  • 8. "|isbn=1-85153-214-5." from Eriophyes inangulis. Trailing period.
  • 9. "|ISBN=0-903413-88-4)" from Ethel R. Harraden. Note trailing punctuation. Also note that "ISBN=" or "isbn=" are both valid parameter names.
  • 10. "| isbn = 978-0-415-77200-6 (hardback)" from Ethics of care. Comment out any text in parentheses. I believe that I have also seen "(paperback)" and variations of "(on-line)".
  • 11. "|isbn=ISBN0252030060" from Ethnographic film. A slight variation on #1 above. I expect there are also instances of "|isbn=ISBN:0252030060", although I haven't run across any yet.

Comments? Questions? Objections? Dope slaps? I suppose since there are only 9,000 articles in the category, someone might be willing to run through it with an AWB script based on the above errors instead of going to the trouble of creating a bot and getting it approved. I do not have access to the technology required to run AWB. – Jonesey95 (talk) 05:49, 14 January 2014 (UTC)

Here is a rule for #1 and #2 (also picks up trailing comma, semicolon, and right parenthesis):
Find: ({{\s*[Cc]it(?:e|ation))([^}]+)(\s*\|\s*isbn\s*=\s*)ISBN\s*([\d\-X]+)[\.,;\)]?(\s*\|[^}]*)
Replace: $1$2$3$4$5
And a slight variant for #6:
({{\s*[Cc]it(?:e|ation))([^}]+)(\s*\|\s*isbn\s*=\s*)([\d\-X]+)[\.,;\)]?(\s*\|[^}]*)
Replace: $1$2$3$4$5
Do you want access to AWB? I'm pretty sure that if you do, you could have it.
—Trappist the monk (talk) 12:30, 14 January 2014 (UTC)
And for #3:
Find: ({{\s*[Cc]it(?:e|ation))([^}]+)(\s*\|\s*isbn\s*=\s*unknown)[\.,;\)]?(\s*\|[^}]*)
Replace: $1$2$4$5
And #11 (with or without trailing punctuation) should be picked up by the same rule that catches #1 and #2.
—Trappist the monk (talk) 12:53, 14 January 2014 (UTC)
For #4 and #10:
Find: ({{\s*[Cc]it(?:e|ation))([^}]+)(\s*\|\s*isbn\s*=\s*)([\d\-X]+)(\s*\([\w\s]+\))(\s*\|[^}]*)
Replace: $1$2$3$4<!--$5-->$6
For #5:
Find: ({{\s*[Cc]it(?:e|ation))([^}]+)(\s*\|\s*isbn\s*=\s*)[\d\-X]+,\s*(97[89][\d\-]+)(\s*\|[^}]*)
Replace: $1$2$3$4$5
Numbers 8 and 9 should be caught by the rule that catches #6.
—Trappist the monk (talk) 13:24, 14 January 2014 (UTC)
Better rule for #5:
Find: ({{\s*[Cc]it(?:e|ation))([^}]+)(\s*\|\s*isbn\s*=\s*)([\d\-X]+,\s*)(97[89][\d\-]+)(\s*\|[^}]*)
Replace: $1$2$3<!--$4-->$5$6
Since the script hides extraneous parenthetical text w=that may be of value, similarly, the ISBN10 might also be of value.
Is there a need for a reverse order version of this rule: |isbn=ISBN13, ISBN10?
Not sure what to about #7. Dashes can be properly located just about anywhere in an isbn ...
I'll publish a settings file that has all of these rules in a bit.
—Trappist the monk (talk) 13:46, 14 January 2014 (UTC)
The rules above may be obsolete. Here is the current settings file.
Yes, there is a case for |isbn=ISBN13, ISBN10. The rule for it is in the settings file.
—Trappist the monk (talk) 14:39, 14 January 2014 (UTC)
Is the tail end of these regexes right? I use ([\}\|]) to indicate that I'm looking for one and only one of those two characters.
Re "Is there a need for...", I have been trying to be conservative in detecting only strings that I actually see.
Re "Dashes can be properly located...", good point. We could simply remove all non-hyphen dashes, unless GoingBatty knows of a way to replace them exactly where they reside. – Jonesey95 (talk) 14:43, 14 January 2014 (UTC)
@Trappist the monk: Thanks for your kind words about BattyBot 25. However, there have been several editors who did not appreciate the edits, as can be seen at my bot's talk page, my talk page, and the RFC at Wikipedia talk:Manual of Style‎‎. I'm willing to set up a bot task for this as well, but suggest we take the following approach:
  1. Ensure all ISBN related documentation is up to date. (This may already be done.)
  2. Develop simple documentation about WP:COinS to educate editors on the importance of having accurate data in the citation parameters, and not having extra data in the parameters. I appreciate the editors who have responded to recent questions about COinS metadata, and that would be good information to gather for the documentation.
  3. Open an RFC for ISBN format, citing the information in #1 and #2 above.
  4. Based on the results of the RFC, tweak the rules for the error category, if needed.
  5. We collaborate on what the bot should - and should NOT - change. Also involve with the WP:CHECKWIKI folks, who have several tests to identify ISBN errors.
  6. I would then request bot approval, referencing everything above.
Thanks! GoingBatty (talk) 18:01, 14 January 2014 (UTC)
Redirecting credit for compliments regarding BattyBot 25 to Editor Jonesey95 ...
I am not all that convinced that this particular task requires all of the work necessary to become a bot. But, if one were to proceed with that goal in mind, the steps you've outlined are certainly appropriate. I have tweaked Check |isbn= value and checked Help:Citation Style 1 and {{csdoc}} for obvious errors.
For quite a while, each of the individual CS1 template pages have had text discussing COinS. For those templates that use Module:Citation/CS1 I have separated that text into its own separate section; see for example {{cite web#COinS}}.
—Trappist the monk (talk) 15:48, 15 January 2014 (UTC)
We may also want to involve whoever maintains Special:BookSources. They appear to have implemented ISBN cleaning code that works just fine when ISBNs contain preceding or trailing text. It would be useful to have a copy of the strings that they remove, since they have no doubt encountered many more oddball strings than are listed above.
Related: as a result of their cleaning code, clicking on most of the ISBNs in the above citations works just fine. There may be some editors who argue that if the link works fine, it's pointless for a bot to mess with it. That's where the COinS explanation comes in. – Jonesey95 (talk) 18:18, 14 January 2014 (UTC)
ISBN 978-1907475689 is a magic link and is processed by Parser.php. The CS1 templates don't use magic links; they only work above because they are plain text. --  Gadget850 talk 22:51, 14 January 2014 (UTC)

Clarifying: If I use "|isbn=9780773532861." in a citation, I get a link that includes a trailing period. When I click on it, I am taken to Special:BookSources, but the trailing period has been stripped away in the search box, even though it was in the URL. It looks like that link may be handled by Parser.php or equivalent code (thanks for the link). Looking at the Parser.php code may be helpful. It looks to me, as non-Perl hacker, that the code is extracting just the leading numbers, spaces, and dashes, in these lines of code: 

01266                ISBN\s+(\b                  # m[5]: ISBN, capture number
01267                     (?: 97[89] [\ \-]? )?   # optional 13-digit ISBN prefix
01268                     (?: [0-9]  [\ \-]? ){9} # 9 digits with opt. delimiters
01269                     [0-9Xx]                 # check digit
01270                     \b)

...and then removing the spaces and dashes and converting "x" to "X" when it fills the Search box: 

01310             # ISBN
01311             $isbn = $m[5];
01312             $num = strtr( $isbn, array(
01313                 '-' => '',
01314                 ' ' => '',
01315                 'x' => 'X',
01316             ));

Here's a citation that has a malformed ISBN but results in a successful search at Special:BookSources:

Author. Title. ISBN 978-0-226-53431-2 (hbk.). {{cite book}}: |author= has generic name (help); Check |isbn= value: invalid character (help)

Note that the URL includes the extraneous text, but somehow the ISBN in the search box is stripped of that text (possibly by Parser.php?). Clicking the Worldcat search link for that book works fine. An |isbn= parameter with two ISBNs does not work, however:

Author. Title. ISBN 0-8304-1580-7, 9780830415809. {{cite book}}: |author= has generic name (help); Check |isbn= value: invalid character (help)

Drawing tentative conclusions from all of this rambling: the code that leads from a cite template to Special:BookSources does a good job of ignoring extraneous text (and also non-hyphen dashes, it appears). It may or may not help us fix these malformed ISBNs. – Jonesey95 (talk) 23:59, 14 January 2014 (UTC)

Found it. SpecialBooksources.php does some cleanup as well. --  Gadget850 talk 10:28, 15 January 2014 (UTC)
I'm happy to add starting ISBN, endash not hyphen and trailing punctuation fixes to AWB genfixes. The multiple ISBN, format in brackets and free-text issues are not something that I think are sufficiently clear cut to put in AWB genfixes. Rjwilmsi 17:07, 15 January 2014 (UTC)
That would be great. I think adding 1, 2, 6, 7, 8, 9, and 11 above should be uncontroversial. They are all either a leading and extraneous "ISBN" (with no space, a space, or a colon following), non-hyphen dashes (I think there are at least three kinds of non-hyphen dashes), or trailing punctuation (I have seen [,.;)] ). Anything else should wait for an RfC to gain consensus, since they may be at least mildly controversial. – Jonesey95 (talk) 17:28, 15 January 2014 (UTC)
Can you clarify please? What do you mean by starting ISBN? Legal separators in an ISBN are simple hyphens and simple spaces. ISBNs without separators should be left as they are because the positioning of the separator has meaning depending on the adjacent digits.
—Trappist the monk (talk) 17:31, 15 January 2014 (UTC)
By "leading 'ISBN'" I mean examples 1, 2, and 11 above, where the letters "ISBN" appear in the parameter value before the numbers and dashes. – Jonesey95 (talk) 17:43, 15 January 2014 (UTC)
Sorry, that question was for Editor Rjwilmsi, but thanks for the answer.
—Trappist the monk (talk) 18:05, 15 January 2014 (UTC)
Logic is now in AWB genfixes and I've run through the ISBN errors category and made about 1000 edits I think. It looks like it took just under 1000 pages out of the category. Rjwilmsi 11:01, 25 January 2014 (UTC)
Brilliant! There are now 7,333 articles in the category, down from about 9,000. I did notice that one of the edits removed the text "ISBN" from a parameter that read something like "|isbn=ISBN=978...", leaving behind an extra "=". I fixed that article, but a tweak to the AWB genfixes might be in order. To be clear: AWB did not introduce a new error, it just changed one kind of error to another kind. – Jonesey95 (talk) 17:13, 25 January 2014 (UTC)

pmc with no title

can we make this return a "missing title" error? currently {{cite journal|pmc=2693255}} returns a script error. Frietjes (talk) 16:24, 17 January 2014 (UTC)

Markup Renders as 
{{cite journal|pmc=2693255}}

. PMC 2693255 https://www.ncbi.nlm.nih.gov/pmc/articles/PMC2693255. {{cite journal}}: Cite journal requires |journal= (help); Missing or empty |title= (help) 

{{cite journal|pmid=2693255}}

. PMID 2693255. {{cite journal}}: Cite journal requires |journal= (help); Missing or empty |title= (help) 

{{cite journal|jstor=2693255}}

. JSTOR 2693255. {{cite journal}}: Cite journal requires |journal= (help); Missing or empty |title= (help) 

{{cite journal|pmc=2693255|url=http://www.example.com}}

. PMC 2693255 http://www.example.com. {{cite journal}}: Cite journal requires |journal= (help); Missing or empty |title= (help) 

{{cite journal|pmc=2693255|title=Title}}

"Title". PMC 2693255. {{cite journal}}: Cite journal requires |journal= (help) 

{{cite journal|pmc=2693255|url=http://www.example.com|title=Title}}

"Title". PMC 2693255. {{cite journal}}: Cite journal requires |journal= (help)

It certainly does. --  Gadget850 talk 19:49, 17 January 2014 (UTC)
I'm guessing this is due to a recent change (back to pre-Lua behavior) in which the title is linked to the PMC URL unless |url= is specified. Displaying the PMC and a missing title error seems like the expected behavior. I added a clarifying example above, with a URL. I also added one with a title and a PMC, and one with title, URL, and PMC. – Jonesey95 (talk) 20:47, 17 January 2014 (UTC)
I dont think that a wrong (or what it is) PMC value is expected to give a script error. I think it should be fixed. Christian75 (talk) 15:23, 18 January 2014 (UTC)
Yes, this is a bug. A PMC without a title parameter should give a missing title error, not a script error. – Jonesey95 (talk) 04:54, 19 January 2014 (UTC)
The script error bug was fixed in the sandbox 2013-12-21.
—Trappist the monk (talk) 12:17, 27 January 2014 (UTC)
Should we roll the sandbox changes into the live module? There are some useful changes in there, and it's been about six weeks since the last update. I would support it. (Although if Trappist has the energy to work on date ranges in the short term, I'd be willing to wait.) – Jonesey95 (talk) 15:30, 27 January 2014 (UTC)
  • Use {cite_journal/old} until fixed: Many parameters will work correctly in the old, markup-based versions of the CS1 cite templates. So, "pmc=" works and also "month=June" as well:
However, even {cite_book/old} cannot format "isbn=ISBN-10: 1234567890" and repeats "IBSN ISBN-10: 1234567890". -Wikid77 (talk) 18:06, 20 January 2014 (UTC)
no need to use an old template in articles, when there are zero transclusions of this bug in article space (see Category:Pages with script errors). Frietjes (talk) 18:19, 20 January 2014 (UTC)
Using the old template is not a good workaround, because someone will just have to go back and change it back once this script error bug is fixed. A better workaround is to fill in the title parameter, and other parameters if you want. – Jonesey95 (talk) 19:23, 20 January 2014 (UTC)

Misleading date field

The full Cite Journal template is misleading. It asks for year, month, date, in that order. I and many others interpreted this as asking for the year month and day of publication. That is not the case, as date is apparently supposed to be the full date and is the only field shown in the cite if present.. See, for example, Necrotizing enterocolitis where I just added a cite, which I then fixed. Other references there still show a similar mistake, and I presume this is true in many many articles. One possible fix would be to assume a two-digit date is not valid and show the year instead.--agr (talk) 00:28, 21 January 2014 (UTC)

Where are you being asked for the month parameter? What button or link are you clicking? |month= is clearly listed as deprecated in the documentation at Template:Cite journal#Date. – Jonesey95 (talk) 00:57, 21 January 2014 (UTC)
My guess would be the RefToolbar. --  Gadget850 talk 01:21, 21 January 2014 (UTC)
I turned on the Reftoolbar in my Preferences, and it asks for "Publicate date" in each of the different reference types. ArnoldReinhold, can you help us identify the thing you are clicking on? We may be able to get it fixed. Thanks. – Jonesey95 (talk) 04:01, 21 January 2014 (UTC)

Cite book: total number of pages

Right now, some pages are, incorrectly, using the template's pages= field to indicate the total pages in the work, rather than for a specific page range citation.
Is there a different template these pages should be using, or could total_pages= be a field here?
99.247.1.157 (talk) 21:00, 22 January 2014 (UTC)

I don't believe there is any existing parameter to give the total number of pages. It is not customary, either in Wikipedia, or in citations in other publications, to give the total number of pages in a book; I think you would have convince the Wikipedia community there is a good reason to add this information. Jc3s5h (talk) 00:10, 23 January 2014 (UTC)
Correct. Editors who use the parameters for the total number of pages are confused. --  Gadget850 talk 00:19, 23 January 2014 (UTC)

Use of initials

I and some others are on a drive to improve the utility of the {Cite doi} family of templates. One thing that would help would be if templates allowed greater flexibility in the formatting of output, something that I believe the Lua language now allows. Is it possible to create a parameter that allows authors' forenames to be truncated to their initials, such that if a template {Cite journal | last = Smith | first = John} would output "Smith, John", a template {Cite journal | last = Smith | first = John | author-initials = yes} would output "Smith, J." (but "Smith, John" in the metadata)? This would allow Cite Doi templates to store authors full names where possible, but allow pages to present the data in these templates in a fashion consistent with the formatting of other references already on that page.

Thanks!

Martin (Smith609 – Talk) 19:56, 27 January 2014 (UTC)

{{cite journal |title=Title |last=Smith |first= John Brown |authorformat=vanc}}
→Smith, John Brown. "Title". {{cite journal}}: Cite journal requires |journal= (help); Unknown parameter |authorformat= ignored (help)
—Trappist the monk (talk) 20:06, 27 January 2014 (UTC)
I believe that the cite doi sandbox (and documentation) contains a proposed edit by Boghog that adds a passthrough of the authorformat=vanc parameter in the cite doi template (although it uses "van=yes", confusingly, when it should probably use "authorformat=vanc" for consistency). Take a look at the documentation at {{Cite doi}} to see where that has been added. – Jonesey95 (talk) 21:44, 27 January 2014 (UTC)
I hope you are not assuming that a simple Lua program is capable of correctly abbreviating full names to initials. For instance, I have a co-author whose full first name is Jean-Claude and who insists that the correct abbreviation of this name is J.-Cl. — should we expect a program to be able to find this? As another example, Russian names are often abbreviated to match their Cyrillic rather than Latin orthography; e.g. "V. Ya. Propp". I very much like the idea of separating the data from the format and allowing different articles that use different citation formats to share their data, but if we want to abbreviate names properly then the data should store both the unabbreviated and abbreviated forms of the name rather than expecting to be able to derive one from the other. The same thing is true for journal abbreviations. —David Eppstein (talk) 22:05, 27 January 2014 (UTC)
Using the same |authorformat=vanc parameter name in {{cite pmid}} and {{cite journal}} is a bad idea since the parameter produces some what different output in the two cases. As discussed here and here, what is confusing is that {{cite journal}} |authorformat=vanc parameter is only a partial implementation of the Vancouver author format. The full Vancouver author implementation should also remove commas between the last name and first initials and replace the semi colon that separates authors with a comma (To get closer to the "Vancouver-like" style, one needs to add author-separator and author-name-separator parameters: | authorformat = vanc | author-separator=, | author-name-separator = &#32; ). Finally as David Eppstein has pointed out, authorformat=vanc doesn't abbreviate properly hyphenated names. Lua program does support regular expression search and replace, hence it should be able to correctly abbreviate hyphenated names.
IMHO, the best solution is to implement a more complete implementation of the Vancouver style author format (including properly abbreviating hyphenated names) directly in Module:Citation/CS1. This would also reduce the number of {{cite pmid}} passthrough parameters. Boghog (talk) 03:52, 28 January 2014 (UTC)
Hyphenation can be handled with a little care as you say. Weird rules like "Jean-Claude is abbreviated J.-Cl. rather than J.-C." are less clear. —David Eppstein (talk) 03:58, 28 January 2014 (UTC)
Perhaps these unusual cases (and as the Russian example illustrates, they are not entirely uncommon) could be handled by the implementation of an 'author#-initialization' parameter that would trump the automatic determination produced through authorformat=vanc? Or perhaps there is a regular expression that would handle the unusual cases?
The ultimate goal is to be able to produce any desired output format by passing parameters to the Cite PMID or Cite DOI templates. Martin (Smith609 – Talk) 09:34, 28 January 2014 (UTC)
I think it requires too much additional knowledge of the subject to be done with a regular expression. E.g. If someone is named "Yuri", that doesn't inform us whether he primarily spells his name with Cyrillic letters (which should be abbreviated "Yu." in transliteration) or with Latin letters ("Y."). —David Eppstein (talk) 16:39, 28 January 2014 (UTC)

Examples

I started Help:Citation Style 1/Examples. The intent is to show how to cite various sources. --  Gadget850 talk 00:14, 29 January 2014 (UTC)

|In= parameter

Hi. Apparently, {{Cite journal}} accepts an |in= parameter but I can't find any documentation for it. Any idea? Best regards, Codename Lisa (talk) 08:41, 27 January 2014 (UTC)

It is an alias for 'language'. It has never been documented and I have never seen it used, but it has been supported by the templates for years. --  Gadget850 talk 09:33, 27 January 2014 (UTC)
Really!? I saw it once used as "|in=Computerworld" and I myself recently used it in Compiler article to write "|in=Computer (magazine)" because the manual citation had an "in" parameter. But its rendering struck me as odd. I had a hunch and I thought I should ask.
Best regards,
Codename Lisa (talk) 11:27, 27 January 2014 (UTC)
Should |in= be deprecated and eventually removed given that it is rarely used, that it is relatively easy to misinterpret its meaning, and that it lacks documentation?
—Trappist the monk (talk) 14:05, 27 January 2014 (UTC)
It seems confusing. I would support its deprecation. Can we get a count of how many times it is used in all CS1 templates? And if we deprecate it, we should advertise the discussion. – Jonesey95 (talk) 15:32, 27 January 2014 (UTC)
Support. Per the examples, it is confusing. If and when we add more language support, misuse will cause errors. --  Gadget850 talk 17:35, 27 January 2014 (UTC)
I support too. This wasn't my intention when I asked the question but it is a wise move. Best regards, Codename Lisa (talk) 17:45, 27 January 2014 (UTC)
It was a good question. Looking at Module:Citation/CS1/Configuration, under the section "Aliases table for commonly passed parameters" there are several aliases that are not documented. Need to see what is documented and what is used. We could move 'in' from Module:Citation/CS1/Configuration to Module:Citation/CS1/Suggestions— it would then give an error and suggest 'language'. --  Gadget850 talk 18:52, 27 January 2014 (UTC)

Same issue with 'number'

We were having a similar conversation elsewhere about the |number= parameter; it would be good to get feedback on whether that is a useful alias for 'issue' or should similarly be deprecated. Incidentally, it's worth pinging User talk:Citation bot when a parameter is deprecated; it's relatively easy to modify the bot to replace the deprecated parameter. Martin (Smith609 – Talk) 08:05, 31 January 2014 (UTC)
BibTeX uses number= where our templates use issue=. So it's an easy enough mistake to use one in place of the other when typing in templates by hand, and seems harmless enough to keep working. But I wouldn't complain about a bot going through and changing them all to the main parameter. So deprecated but not removed seems like the right level for the number= parameter to me. —David Eppstein (talk) 08:27, 31 January 2014 (UTC)
Great. I've updated the doc accordingly. Martin (Smith609 – Talk) 10:30, 1 February 2014 (UTC)
|number= is specifically used with {{Cite techreport}}. --  Gadget850 talk 20:57, 2 February 2014 (UTC)
Just to further muddy the water, |number= in {{cite techreport}} is simultaneously an alias of |id= and of |issue=.
—Trappist the monk (talk) 22:02, 2 February 2014 (UTC)

I rise to object. Editor Smith609 is using the above discussion (three posts, two editors – prior to Editor Gadget850's edit which occurred as I wrote this) as a sufficient statement of consensus to deprecate |number= as an alias for |issue= (this edit and edit summary, this edit). So that we are all clear, I am generally in favor of deprecating parameters that simply duplicate the functionality of other parameters. However, as an editor has mentioned in the |in= discussion above (and of which this conversation is a subthread), such intent to deprecate should be properly announced, advertised, and discussed before action is taken. Until such time as these things have been accomplished, |number= should remain as it is, an active and allowed parameter.

—Trappist the monk (talk) 21:29, 2 February 2014 (UTC)

|number= has not been deprecated in any discussion, as far as I know. We have already had enough arguments about parameters being declared deprecated without a full, advertised discussion. Let's not repeat familiar mistakes. Smith609, please undo your edits until there is consensus. – Jonesey95 (talk) 05:44, 3 February 2014 (UTC)
Well please undertake whatever bureaucracy is necessary to document the parameter properly and establish whether the correct behaviour for a bot is to (1) replace 'number' with 'issue' (2) not. Martin (Smith609 – Talk) 08:06, 3 February 2014 (UTC)
Shall I update the documentation to say number is an alias of issue? The bot needs to do (2) and support both parameters. We do this in AWB genfixes. Rjwilmsi 08:13, 3 February 2014 (UTC)

PMID error flagging

I have come across many templates that include an incorrect PMID (example: 30036011). As far as I can tell, PMIDs are issued sequentially; therefore it would be easy to flag any template with an eight-digit PMID as erroneous, in the same way that the parameter doi_brokendate identifies citations with a misformatted doi. Would someone with knowledge of LUA be able to implement this? (Ping me on my userpage if you need more input from me, as I don't often check my watchlist.) Thanks! Martin (Smith609 – Talk) 19:30, 27 January 2014 (UTC)

Pubmed has had 8 digits in use for some time, e.g. PMID 23757186 from July 2013. Could check 9 or longer as invalid, and also (if not done already) validate that value of PMID field is only a number (no punctuation or alpha characters) without leading zeros. Rjwilmsi 19:39, 27 January 2014 (UTC)
25000000 is invalid, so perhaps the cut-off point could be 30000000, to be updated in ~10 years when PMID reaches this point? I have seen a lot of invalid PMIDS in the range 30000000-39999999, and it would be useful if these could be flagged automatically to users. Martin (Smith609 – Talk) 19:53, 27 January 2014 (UTC)
Yes. Is there a minimum number?
—Trappist the monk (talk) 20:07, 27 January 2014 (UTC)
PMID 1 exists, PMID must be a positive integer. So validate range 1 to 30000000? Rjwilmsi 20:32, 27 January 2014 (UTC)

It would seem that PMIDs are issued in blocks unless, just coincidentally, I happened to hit on the magic time when PMID 24399999 has been issued but PMID 24400000 has not. Regardless, in Module:Citation/CS1/sandbox, simple PMID validation:

"Pass: within allowed range". Journal. PMID 1.
"Pass: within allowed range". Journal. PMID 30000000.
"Fail: outside allowed range". Journal. PMID 0. {{cite journal}}: Check |pmid= value (help)
"Fail: outside allowed range". Journal. PMID 30000001.
"Fail: punctuation". Journal. PMID 30,123,456. {{cite journal}}: Check |pmid= value (help) – valid in a sense (because the |PMID=30,123,456 is treated as multiple PMIDs by pubmed) but for CS1 purposes invalid
"Fail: non-digit". Journal. PMID 300000O. {{cite journal}}: Check |pmid= value (help)
"Pass: leading zeros ok". Journal. PMID 00030000.

If this change proceeds, pages that contain PMID errors will be categorized into Category:CS1 errors: PMID; the error message for the time being is not hidden. Help text needs to be written.

—Trappist the monk (talk) 15:27, 1 February 2014 (UTC)

Thanks. I can write the help text, ping me when it needs to be done (& tell me where to write it). On a related matter, would it be possible to extend the |doi= validation mark any DOI ending in a full stop as invalid (common error)? Thanks Rjwilmsi 09:42, 2 February 2014 (UTC)

doi subthread

In Module:Citation/CS1/sandbox:

—Trappist the monk (talk) 17:44, 2 February 2014 (UTC)

Tweaked so that any spaces in the doi identifier are detected as errors:

—Trappist the monk (talk) 00:53, 3 February 2014 (UTC)

Thanks, that's good. Also, if not done already, it would be good to detect use of any endashes (–) as errors as well please, fairly common problem that hyphens are converted to endashes by insufficiently intelligent dash formatting scripts. Rjwilmsi 08:16, 3 February 2014 (UTC)
Will these be added to Category:CS1 errors: doi? It should be easy for Citation Bot to watch this category and make any easy corrections. Martin (Smith609 – Talk) 08:42, 3 February 2014 (UTC)
Since the beginning, pages with doi errors have been placed in Category:Pages with DOI errors. Do we need a separate category for doi errors detected by Module:Citation/CS1?
—Trappist the monk (talk) 12:13, 3 February 2014 (UTC)
The existing category should do the job. I've been out of the loop a while so didn't catch that it existed. Martin (Smith609 – Talk) 07:23, 4 February 2014 (UTC)
Tweaked so that en dashes are detected as errors:
—Trappist the monk (talk) 12:20, 3 February 2014 (UTC)
Depending on how far you want to go, you could confirm with JSTOR that their DOIs will all be of the 10.2307/(\d+) form mapping to http://www.jstor.org/stable/$1 (Perl re-s). ie "Pass". Journal. doi:10.2307/2225023. JSTOR 2225023.
My preference would be to replace such DOIs with the jstor parameter... RDBrown (talk) 02:02, 4 February 2014 (UTC)
Many doi values that look like they should work with JSTOR do not. 10.2307/JSTORID is invalid for many JSTOR IDs, unfortunately. I sent them a message through their web site last week, but I haven't heard anything from them. – Jonesey95 (talk) 05:04, 4 February 2014 (UTC)
The problem is that in theory, each article should have a unique DOI; thus if an article is assigned a DOI by its publisher and then archived in JSTOR, the publisher's DOI should be the valid DOI and JSTOR should not issue it with a second. I seem to recall that this theoretical state is not always upheld, however. Martin (Smith609 – Talk) 07:23, 4 February 2014 (UTC)

Requested parameter for citation templates: "chapter-author"

Can a new parameter (or series of parameters), possibly called "chapter-author" (with alias "note-author"), please be created?

I often cite chapters or footnotes by author X in books by authors Y edited by X or Z, and there is no simple way to do this with the citation templates.

Using a real example:

I wish to cite Jacob Freimann's introduction to Nathan ben Judah's early 14th-century book Mahkim in Freimann's 1909 edition of that work, thus:

  • Freimann, Jacob. "Editor's introduction". pp. xi–xv. {{cite book}}: Missing or empty |title= (help) In Nathan ben Judah (1909). Freimann, Jacob (ed.). Mahkim.

As of now, I must type 

* {{cite book |last=Freimann |first=Jacob |chapter=Editor's introduction |title= |pages=xi–xv}}
In {{cite book |author=Nathan ben Judah |year=1909 |editor-last=Freimann |editor-first=Jacob |title=Mahkim}}

using two citation templates to get the desired result.

Spent examples

Were I to type 

* {{cite book |last=Freimann |first=Jacob |chapter=Editor's introduction |pages=xi–xv |year=1909
 |editor-last=Freimann |editor-first=Jacob |title=Mahkim}}

or 

* {{cite book |last=Freimann |first=Jacob |chapter=Editor's introduction |pages=xi–xv |year=1909
 |editor=Nathan ben Judah |title=Mahkim}}

It would result in

  • Freimann, Jacob (1909). "Editor's introduction". In Freimann, Jacob (ed.). Mahkim. pp. xi–xv.

or

  • Freimann, Jacob (1909). "Editor's introduction". In Nathan ben Judah (ed.). Mahkim. pp. xi–xv.

which are both ridiculous and misleading.

I would like to be able to type 

* {{cite book |chapter-author-last=Freimann |chapter-author-first=Jacob |year=1909
 |chapter=Editor's introduction |pages=xi–xv |author=Nathan ben Judah |editor-last=Freimann |editor-first=Jacob |title=Mahkim}}

to get the same result as the two-template solution.

Similar problems present themselves when citing footnotes by the editor to a new edition of a classic work, for example, to cite Alban Krailsheimer's notes to Victor Hugo's The Hunchback of Notre-Dame, I typed 

* {{cite book |last=Hugo |first=Victor |title=Notre-Dame de Paris
 |editor-last=Krailsheimer |editor-first=Alban |page=555, note to p. 288 |isbn=9780191593673}}

to get

  • Hugo, Victor. Krailsheimer, Alban (ed.). Notre-Dame de Paris. p. 555, note to p. 288. ISBN 9780191593673.

which does not make it clear that Krailsheimer is the author of the notes, but there is no simple way of citing it the way it should be, as in the example before.

Is this possible?

Thanks in advance, הסרפד (call me Hasirpad) 00:04, 28 January 2014 (UTC)

Use {{cite encyclopedia}}. --  Gadget850 talk 01:56, 28 January 2014 (UTC)
Thanks, but I don't see how that helps; {{cite encyclopedia}} only allows for two "levels" of authorship, as {{cite book}} and most other similar templates do. The examples I used require three levels of authorship (so to speak): chapter author, work author, and work editor. הסרפד (call me Hasirpad) 02:02, 28 January 2014 (UTC)
Markup 
{{cite encyclopedia |editor-last=Hugo |editor-first=Victor |title=Footnotes |encyclopedia=Notre-Dame de Paris |last=Krailsheimer |first=Alban |others=Alban, Krailsheimer (ed.) |page=555, note to p. 288 |isbn=9780191593673}}
Renders as Krailsheimer, Alban. "Footnotes". In Hugo, Victor (ed.). Notre-Dame de Paris. Alban, Krailsheimer (ed.). p. 555, note to p. 288. ISBN 9780191593673.

--  Gadget850 talk 12:12, 28 January 2014 (UTC)

Thank you indeed, very interesting! For that matter, {{cite book}} and {{cite journal}} (and all other citation templates?) also have the |others= parameter. This is definitely preferable to my "homemade" two-template solution—though this is apparently not the parameter's intended function and looks artificial (in wikicode, that is), and it would be nice if such citations could be coded intuitively. הסרפד (call me Hasirpad) 13:58, 28 January 2014 (UTC)
You can do the same with {{cite book}}— it is |encyclopedia= that adds the text "in". With the Lua templates, most parameters work in each of the templates, but we only document the ones applicable to the intent of the particular template. --  Gadget850 talk 17:59, 28 January 2014 (UTC)
I mean that were I to replace |title= and |encyclopedia= with, respectively, the somewhat more intuitive |chapter= and |title=, I would also have "in". הסרפד (call me Hasirpad) 20:00, 28 January 2014 (UTC)
I'm not convinced that using {{cite encyclopedia}} is appropriate. The book is Notre-Dame de Paris, the book is not an encyclopedia, and the book's author is Victor Hugo. The particular edition being cited was translated and editorial material written by Alban Krailsheimer. Readers who wish to check the source may be confused by such a citation that lists Krailsheimer as the author and both Krailsheimer and Hugo as the editors. Instead, perhaps craft the citation as you would any other citation with particular attention to in-source location:
Markup 
{{cite book |last=Hugo |first=Victor |authorlink=Victor Hugo |title=Notre-Dame de Paris  |editor-last=Krailsheimer |editor-first=Alban |at="Explanatory Notes". p. 555, note to p. 288 |isbn=0-19-283701-X |date=1999 |origyear=1993 |url=http://books.google.com/books?id=SN3Rhip342cC&pg=PA555}}
Renders as Hugo, Victor (1999) [1993]. Krailsheimer, Alban (ed.). Notre-Dame de Paris. "Explanatory Notes". p. 555, note to p. 288. ISBN 0-19-283701-X.
My example citation refers to the facsimile available at google books for illustrative purposes.
—Trappist the monk (talk) 12:55, 30 January 2014 (UTC)
Trappist the monk: thank you for your reply.
I agree that {{cite encyclopedia}} is inappropriate, but, as I wrote above, the same functionality exists in {{cite book}}. I also agree that using |editor= and |others= alongside each other is misleading to the wikicode reader (and potential editor, who might "fix" things and break references).
However, your recommended rewording of the "footnotes" citation does not seem ideal. Firstly, I distinctly remember style guides recommending the form that Gadget850 and I used. Also, this is not an option when citing material other than footnotes, such as the "foreword" or "introduction" ("Freimann") example above. Even when citing footnotes, your version can be ambiguous; for example:
Without being familiar with Waite's edition of Lévi's The History of Magic, would you know whether Waite edited (in this case, translated) Lévi's own annotated book, or perhaps Waite annotated his translation of Lévi's work? Worse yet is the case when the three "levels of authorship" are populated by three distinct authors/editors; using a real example (written without templates, of course):
  • Metzger, David (1992). "The Sefer ha-Ḥinnukh and Its Author". In Aaron ha-Levi of Barcelona. Sefer ha-Ḥinnukh. Weiss, Y. Y. (ed.). pp. 7–10.
How would code this with the available citation templates? It doesn't seem possible without contrived workarounds, such as my ugly two-template version, or Gadget850's pseudo-editor and pseudo-others version. הסרפד (call me Hasirpad) 20:30, 30 January 2014 (UTC)
If a style guide recommends a particular form for a particular kind of citation and if the article's editors have chosen that citation style for the article, then CS1 may not be appropriate and one shouldn't try to shoehorn the particular style into CS1. CS1 is an amalgam of different styles but is none of them. It is a general purpose citation tool that suits the needs of a large number of editors and their citation requirements, and as such, will never be suitable for every citation need.
Editors are not required to attribute authorship; rather, they are required to WP:SAYWHEREYOUGOTIT. Simply doing as you have done with your Lévi example fulfills that requirement. Wikipedia articles are not academic papers where the provenance of each detail must remain clear, but rather, are summaries of a topic referenced to numerous more complete treatments.
I have no suggestions for your Metzger et al citation. I don't know the structure of the work; I can't tell if Aaron ha-Levi of Barcelona is a person or a title or something else.
—Trappist the monk (talk) 11:42, 31 January 2014 (UTC)
Trappist the monk: Regarding my reference to style guides, you misunderstood my point. I am well aware that Wikipedia has no house style, but all citation styles usually agree on what information is ultimately given, and Wikipedia is usually in accordance.
As for attributing authorship: WP:SAYWHEREYOUGOTIT is the minimum, but I think most editors would consider full attribution of authorship good practice, and in some cases not doing so can be confusing—as is the case in this with the Lévi/Waite example. (Lévi and Waite disagree on whether electrical lights existed in the 13th century, and to the uninitiated reader Lévi seems to be contradicting himself, or to be much less credulous in his footnotes than in the main text.)
As for the Metzger example, here it is rendered in ordinary English: ...David Metzger's article "The Sefer ha-Ḥinnukh and Its Author", pages 7–10 in Y. Y. Weiss' 1992 edition of Aaron ha-Levi of Barcelona's Sefer ha-Ḥinnukh. How would you word that CS1-style? (As it happens, Metzger believes—as do all scholars since the early 20th century—that Aaron ha-Levi of Barcelona was not the author of Sefer ha-Ḥinnukh, whatever Wikipedia's 1906 article writes, but I called it "Aaron ha-Levi of Barcelona's Sefer ha-Ḥinnukh" following bibliographic tradition, as the Library of Congress' catalog does.)
I intend to soon restate the problem and its possible solutions more clearly; tomorrow, or perhaps tonight (EST) if I have the time.
הסרפד (call me Hasirpad) 04:25, 2 February 2014 (UTC)
There are times when a tool is not the right tool – a hammer can be used to drive a screw or set a staple, but using a screwdriver or stapler would be more approriate. CS1 is a good tool for most citations; it is not and cannot be a good tool for all citations.
—Trappist the monk (talk) 13:47, 2 February 2014 (UTC)

Gadget850, thank you again for your patient advice (though I haven't finished testing your patience yet). Incidentally, my compliments for your {{markupv}} template; I find it both practical and aesthetically pleasant.

Meta-question: is this the correct venue for proposed modification of citation templates? I still want to revise my original proposal (having noticed a serious logical flaw, and I have other citation issues that I think need fixing; where should I post? (There seems to be, despite the 100+ page watchers, only one regular respondent here—you—so I must be in the wrong place for consensus-building. הסרפד (call me Hasirpad) 02:13, 30 January 2014 (UTC)

This is a good venue for proposed modification of Citation Style 1 templates. There are more of us here than just Gadget850. – Jonesey95 (talk) 03:55, 30 January 2014 (UTC)
My apologies—but it does seem that way when one skims through this page. הסרפד (call me Hasirpad) 20:30, 30 January 2014 (UTC)

Revised proposal: alternate to |editor=

|editor= is, in my opinion, the root of the problem—the term editor itself is ambiguous, and the parameter that bears its name also does double duty.

The editor of a journal, book with chapters by multiple authors, or encyclopedia is the primary author of that work as a whole and should appear after In..., while the editor of a book of ordinary structure, with one (or several) author(s) responsible for most of the book, is of secondary importance and should always be marked as ed. and not be prefixed by In....

While |editor= executes it "book-mode" well when the |title= parameter is used alone

Markup Renders as 
{{cite book |last=Doe |first=John |year=2014 |title=Foo |editor-last=Doe |editor-first=Jane}}

Doe, John (2014). Doe, Jane (ed.). Foo.

when |chapter= or |article= is used with |title=, |editor= shifts to "journal-mode"
Markup Renders as 
{{cite book |last=Doe |first=John |year=2014 |chapter=Bar |title=Foo |editor-last=Doe |editor-first=Jane}}

Doe, John (2014). "Bar". In Doe, Jane (ed.). Foo.

and the author and editor are assigned to the chapter and book respectively.

Further, in the examples I gave in my original post above (Freimann, Krailsheimer, Metzger), |editor= is doubly problematic: its journal-mode is needed to generate In..., but prefixed to an author who is not the editor in the book-sense, and, once used, is not available to providing a book-mode editor.

I think the trouble could be avoided if one of the following solutions could be implemented (of course, I know nothing about their technical feasibility, so this may be ridiculous)

  • (Workaround) Create an alias for |editor= to be used when the main author, that is, the author who is listed as the work's primary author, is not the editor—|main[n]-last= and |main[n]-first=, say? The actual editor could be included in |other=, per the second half of Gadget850's solution.
    This would at least not confuse future editors.
  • Create a set of parameters, |main[n]-last= and |main[n]-first=, that would behave like |editor= does now, but which would induce (?) |editor=, when used, to retain its "book-mode" function.
  • If the above is not feasible or acceptable, at the very least I would recommend adding Gadget850's solution (both halves) to the CS1 documentation.

Gratefully yours, הסרפד (call me Hasirpad) 05:19, 4 February 2014 (UTC)

Extra data in date entry

Why does the COinS section of the Template:Cite Web page say that explanatory or alternate text is not allowed? I sometimes add '(updated)' when a page only shows the date it was last updated (and not the date of original production), as this is more accurate but was reversed. See query I raised (with example) at talk page. What problem is being caused by having the 'updated' text added. Eldumpo (talk) 20:02, 1 February 2014 (UTC)

Module:Citation/CS1, the engine that processes {{cite web}} citations creates COinS metadata from several parameters, |date= being one. The date metadata for this very simple citation:
{{cite web |title=Title |url=//example/com |date=1 February 2014}}
looks like this:
&rft.date=1+February+2014
The parameter &rft.date= tells external referencing software that the value (1+February+2014) is a date. If |date= in a CS1 citation contains information other than a date, that information is included in the COinS metadata and is likely meaningless to the external referencing software. The purpose for the resrictions stated in the COinS sections of the various template documentation is to help keep the metadata clean and uncorrupted for the users of these external referencing tools.
—Trappist the monk (talk) 20:22, 1 February 2014 (UTC)
Thanks for your response although I note you say that the presence of a non-date is 'likely' to be meaningless, so has this not been confirmed? What exactly do users of the external referencing tools do with the data. Is their usage important enough that we should exclude the use of 'updated' to Wikipedia readers, so they are not able at a glance to see that the date listed is not the true date originally of the source. Eldumpo (talk) 08:18, 2 February 2014 (UTC)
Editors put a great variety of extra text in the various CS1 template fields from relatively simple plain-text to templates that emit large amounts of CSS, wiki-formatting, etc. For example, we have seen stuff like this:
|date={{dts|1776|July|4}}
and the resulting COinS data for date then looks like this:
&rft.date=%3Cspan+style%3D%22display%3Anone%3B+speak%3Anone%22+class%3D%22sortkey%22%3E01776-07-04%3C%2Fspan%3E%3Cspan+style%3D%22white-space%3Anowrap%3B%22%3EJuly+4%2C+1776%3C%2Fspan%3E
Readers who use external referencing tools are no less (and no more) important than readers who use their eyes. We should not present information in a way that is a benefit to one but is a detriment to the other.
—Trappist the monk (talk) 13:21, 2 February 2014 (UTC)
But not allowing the use of 'updated' (or other appropriate extra information) is a loss of functionality to readers. So how does this COinS data look if the 'updated' text is used? Eldumpo (talk) 23:13, 2 February 2014 (UTC)
I'm not convinced that adding text to a date to indicate that it's an updated-on date has much meaning – especially for {{cite web}}. Web pages are notorious for lacking dates and for having dates that are clearly out of date. This is why we have |accessdate= to record the date that an editor consulted an ephemeral source that at a particular point in time supported the article. There is no need to note that the date on a web page is an updated-on date or a copyright date or some other kind of date. It is just a date that may or may not be correct. Use |accessdate=; should the web page go 404, this is the date that editors will be using when attempting to recover the source from an online archive.
The COinS metadata for |date=2 February 2014 (updated) is: &rft.date=2+February+2013+%28updated%29. Pretty straight forward, pretty sure that a reasonably adept external tool should be able to recover the date from that. But, the proscription against extraneous stuff in CS1 citation parameters applies to all parameters from which COinS metadata are assembled. Most of those parameters contain free form text – they don't adhere to the strict format requirements of things like dates by the very nature of their content (titles, author names, publishers, and the like). Allowing extraneous text in some parameters but not in others is a recipe for garbage metadata because editors will forget which parameters can hold ancillary text and which cannot.
—Trappist the monk (talk) 00:07, 3 February 2014 (UTC)
My interpretation of WP:SAYWHEREYOUREADIT is that you should cite that you read the version dated "29 November 2012", so users that want to independently validate the information in the article can find the appropriate version of the web page. I don't see that knowing whether that was the initial date of the web page or an updated date makes a difference. GoingBatty (talk) 14:11, 3 February 2014 (UTC)
If a reader isn't concerned that the web page was misrepresented, but rather is interested in whether the web page was likely to have been updated to account for current events, it would be helpful to know when the web page was updated, rather than when the web page was last read. Perhaps a parameter could be provided, date-description, which describes the date and is inserted between the date and the ending punctuation for the date. Jc3s5h (talk) 16:48, 3 February 2014 (UTC)

The key point for the source in question (RSSSF) is that they were not listing the original date, but only the updated date, so it does not seem unreasonable to try and follow that. They clearly see it is significant to note when it was updated so why not pass that on to readers? Given that the COinS results are noted as being acceptable in this instance why can't the template section describing COinS state that exceptions are allowed only when clearly set out, and then under the date section state there that certain text is allowed? The suggestion by Jc35 could be a compromise; allow a separate field for when there is an updated entry at a source - it is useful for readers to know at a glance the date/details of when the information was posted. Eldumpo (talk) 23:05, 3 February 2014 (UTC)

Is there a way to add an open-ended comment to a citation?

I'm citing multiple topographic maps available online in support of a series of geographical articles. If I want to add an open-ended phrase or sentence to the cite that doesn't necessarily fit a predefined category, how can I do this? LADave (talk) 23:28, 1 February 2014 (UTC)

Examples so we know what it is you mean?
—Trappist the monk (talk) 00:27, 2 February 2014 (UTC)
Relevant parameters might include |quote= (for text taken from the source and copied for convenience into the reference), |id= (for identification numbers that don't already have their own separate parameter), or |postscript= (for any text you want to appear at the end of the citation). For that matter, it's also possible to write text after the actual citation template. —David Eppstein (talk) 00:58, 2 February 2014 (UTC)
|postscript= is terminating punctuation, and shows in the COinS metadata as such. Just place any desired text between the terminating }} and the closing </ref>. --  Gadget850 talk 01:45, 2 February 2014 (UTC)
After reflection, I realized |postscript= doesn't show in COinS. --  Gadget850 talk 12:42, 2 February 2014 (UTC)
Well, but if you're using {{harv}}-style linking from the article text to the references, stuff inside |postscript= will be highlighted when the reader clicks on a reference name, but stuff after the closing brackets of the template won't be. —David Eppstein (talk) 02:00, 2 February 2014 (UTC)
|ps= (short for postscript) is part of {{harv}} is not the same as |postscript= which is part of a CS1 citation. Let us not confuse the two.
—Trappist the monk (talk) 03:43, 2 February 2014 (UTC)
You are the one confusing the two, not I. I mean the postscript parameter of the citation template. If you use postscript for some nontrivial text, that text will be part of the region highlighted when you click on the harv link. If you write the text after the brackets instead, it will not be highlighted. —David Eppstein (talk) 04:04, 2 February 2014 (UTC)
Example please. --  Gadget850 talk 12:34, 2 February 2014 (UTC)
Some text.[1][2] Click preceding superscript [2] then click Example 2 link.

References

  1. ^ "Example 1". Some explanatory text.
  2. ^ Example 2.
—Trappist the monk (talk) 12:58, 2 February 2014 (UTC)
From {{cite web}} at Display options"
  • postscript: Controls the closing punctuation for a citation; defaults to a period (.); for no terminating punctuation, specify |postscript=none – leaving |postscript= empty has the same effect but is ambiguous. Ignored if quote is defined.
Using |postscript= to hold nontrivial text, while possible to do, is not contemplated nor specifically supported by the parameter's definition nor by the underlying Module:Citation/CS1 (it does not provide proper inter-parameter termination or spacing in the rendered citation). The highlighting differences you describe are not within the scope of CS1. That topic is better taken up elsewhere.
—Trappist the monk (talk) 12:58, 2 February 2014 (UTC)

The highlighting is done through CSS. The cite template wraps the citation in <span class="citation">...</span>. The CSS span.citation:target causes the content of the <span> to be highlighted when it is a target from a link— any text outside the span would not be highlighted. This works whether or not the citation template is inside a <ref> or not.

The CSS ol.references causes the content of <ref>...</ref> tags to be highlighted when targeted in the output of reflist markup ({{reflist}} or <references />— this is independent of the citation span highlighting.

If you have a cite template inside a <ref> tag you technically highlight it twice, but is is the same color so it shows the same.

Markup Renders as 
{{harv|author|2014}}
* {{cite book|author=author |title=title |year=2014 |ref=harv}} Comment after citation.

(author 2014)

  • author (2014). title. {{cite book}}: |author= has generic name (help); Invalid |ref=harv (help) Comment after citation.
<ref>{{cite book|author=author2 |title=title |year=2014}} Comment after citation.</ref>
{{reflist|close=1}}

[1]

  1. ^ author2 (2014). title. {{cite book}}: |author= has generic name (help)CS1 maint: numeric names: authors list (link) Comment after citation.

The highlighting is a convenience that helps readers to find the matching citation. Since the accompanying text is not part of the citation, then I don't see an issue if it highlights it or not. --  Gadget850 talk 20:51, 2 February 2014 (UTC)

Quotes

The quote_field probably needs more precise guidelines. Right now it says that "relevant text quoted"; however, this leaves some grey zone what relevant means. In case of Hydraulic fracturing, Environmental impact of hydraulic fracturing and Environmental impact of hydraulic fracturing some references use very extensive quotes. The most drastic is probably the following:

"Shale has a radioactive signature – from uranium isotopes such as radium-226 and radium-228 — that geologists and drillers often measure to chart the vast underground formations. The higher the radiation levels, the greater the likelihood those deposits will yield significant amounts of gas. But that does not necessarily mean the radioactivity poses a public health hazard; after all, some homes in Pennsylvania and New York have been built directly on Marcellus shale. Tests conducted earlier this year in Pennsylvania waterways that had received treated water—both produced water (the fracking fluid that returns to the surface) and brine (naturally occurring water that contains radioactive elements, as well as other toxins and heavy metals from the shale)—found no evidence of elevated radiation levels...Conrad Dan Volz, former scientific director of the Center for Healthy Environments and Communities at the University of Pittsburgh, is a vocal critic of the speed with which the Marcellus is being developed—but even he says that radioactivity is probably one of the least pressing issues. ‘If I were to bet on this, I'd bet that it's not going to be a problem,’ he says."

For a references that kind of quotation seems to be too extensive and creates also copyrights issues. Any suggestion how to deal with this issue? As I said, probably some clarification in the template guidelines is needed. Beagel (talk) 17:09, 4 February 2014 (UTC)

In this specific case, each of the sources seems to be available online, so a lengthy quote is rather redundant. There is always the issue of link rot over time. Much of what I see here is used to amplify the content— if it is this pertinent, then the content should be expanded.
Quotes should be short, very relevant, and have a purpose.
Where the source does not have a proper page— such as some eBooks —short quotes may also be used to locate the in-text material that is being cited.
--  Gadget850 talk 17:19, 4 February 2014 (UTC)
Interesting. A "scientific director" who thinks radium-226 is a uranium isotope? Or a bad quotation? Not really on topic here though. LeadSongDog come howl! 01:56, 5 February 2014 (UTC)

Way of finding {{web|...}}

Hi,

I discovered, by committing a desperation move, while adding an archive URL to an external link on Corita Kent that 

{{web |...}}

with the same same parameters as 

{{cite web |...}}

would work.

It would be nice if the real description of that template was easy to find while searching. Because this page is easy to find while searching, it might be nice to add a link from here.

ArthurDent006.5 (talk) 02:28, 6 February 2014 (UTC)

{{web}} is simply a redirect to {{cite web}} so they are the same thing.
—Trappist the monk (talk) 02:48, 6 February 2014 (UTC)
I expect a lot of bots and tools won't recognize it as a cite template. There are only a handful of articles using it. When I get some time, I am going to RfD it and migrate the existing links. Probably need to check other templates for non-useful redirects. --  Gadget850 talk 16:34, 6 February 2014 (UTC)
Note the redirect's history: it was originally a redirect to {{db-web}}, and was then boldly retargeted to {{cite web}} for being inconsistent with the db- family of templates; it was not created out of a perceived need for an alternate citation template, so no one is likely to miss it. הסרפד (call me Hasirpad) 17:08, 6 February 2014 (UTC)
Now at RfD. --  Gadget850 talk 18:53, 6 February 2014 (UTC)

Translator

This has probably been discussed before, but is there a reason that there isn't a field for translators? Style guides like Turabian and APA recommend specifying translators in full citations. Thanks. Parsecboy (talk) 15:43, 6 February 2014 (UTC)

I think |others= is specifically meant for translators and the like. הסרפד (call me Hasirpad) 15:50, 6 February 2014 (UTC)
Correct. There is no COinS metadata for translators, illustrators and the like, so we haven't seen the need for separate parameters. As currently documented in each template:
others: To record other contributors to the work, such as Illustrated by John Smith or Translated by John Smith.
--  Gadget850 talk 19:01, 6 February 2014 (UTC)
Fair enough, I guess since you can just type in whatever you want in "others=" there's no real reason to go through the trouble of adding specific fields. Thanks for the answer. Parsecboy (talk) 15:10, 7 February 2014 (UTC)

Categorization and inconsistencies between "cite" and "language icon" templates

Hello,

I have reported an issue between {{cite}} templates and {{language icon}} templates at Wikipedia talk:Manual of Style/Linking#Categorization and inconsistencies between "cite" and "language icon" templates. Place Clichy (talk) 14:53, 8 February 2014 (UTC)

I responded on the original page, but this discrepancy makes me wonder whether the CS1 template should use the same source for language names that the xx icon templates use, namely {{ISO 639 name}}, rather than maintaining a separate, forked list in CS1/Configuration. – Jonesey95 (talk) 15:45, 8 February 2014 (UTC)

Co-publisher needed

How do one enter a co-publisher info in {{Cite book}}? It's needed in Mann–Whitney U#Further reading, first item. Data pieces have been named publisher2 and location2, but that seems wrong...
Compare http://www.ams.org/mathscinet-getitem?mr=1604954
CiaPan (talk) 17:26, 9 February 2014 (UTC)

Which edition did you consult? There are two ISBNs— I haven't looked, but I expect they represent the London and New York editions. --  Gadget850 talk 18:04, 9 February 2014 (UTC)
I think your guess is correct; see this catalog entry. הסרפד (call me Hasirpad) 18:14, 9 February 2014 (UTC)
I don't understand why you suggest I did (or should) consult any edition. I didn't. I just noticed the page is one of Pages with citations using unsupported parameters and Pages containing cite templates with deprecated parameters and tried to fix the error. When I failed and found in the template's doc there's no such parameters, I decided to ask here. Didn't need any edition to ask how to mention both of them. --CiaPan (talk) 22:15, 9 February 2014 (UTC)
The CS1 templates are designed to identify a single source. Because there are two publishers and two ISBNs, perhaps the correct way to repair this citation is to create one citation for each publisher; or, since both of the ISBNs at WorldCat and Google identify Arnold as the only or as the first of two publishers, simply do one citation listing Arnold as the publisher. Alternately, another option is to create a hand-crafted citation that meets your needs (CS1 being a general purpose tool that is suitable for may but not all tasks).
—Trappist the monk (talk) 23:09, 9 February 2014 (UTC)

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

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

Module:Citation/CS1 (diff);
Module:Citation/CS1/Configuration (diff);
Module:Citation/CS1/Whitelist (diff)

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

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

to Module:Citation/CS1/Configuration:

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

to Module:Citation/CS1/Configuration:

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

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

Done.
—Trappist the monk (talk) 11:40, 15 February 2014 (UTC)

Garbled italics in title

The handling of italics (or bold), at the start/end of a webpage title, no longer works as it did in the early Lua versions for {cite_web}:

In mid-March 2013, the Lua {cite_web} would show title "Italics More Text" for italics at the start of a webpage title, and italics mid-title will still work. Meanwhile, I have noted to use i-tag format: '<i>...</i>' at start/end of title, so this new bug has a work-around until a bugfix can be tested. -Wikid77 (talk) 17:36/17:45, 16 February 2014 (UTC)

Module talk:Citation/CS1/Archive 9#Italics in citation title broken. --  Gadget850 talk 18:03, 16 February 2014 (UTC)
Hi. I still fail to grasp the issue. Is it fixed? Or am I not properly understanding your intent? Best regards, Codename Lisa (talk) 00:51, 17 February 2014 (UTC)
I can't speak for Editor Gadget850, but to answer the question about the garbled italics, I think it's fixed as I think can be seen from the current state of Editor Wikid77's examples.
—Trappist the monk (talk) 01:15, 17 February 2014 (UTC)
Thanks for clarification. What made the understanding more difficult was the fact that Wikid77 had – in good faith, I am sure – resorted to using strange markup instead of a pair of <nowiki>...</nowiki> tag. So, I couldn't tell whether single quote–space–single quote sequence meant to represent itself or a single quote–single quote sequence, as a way of suppressing wikimarkup. Best regards, Codename Lisa (talk) 14:15, 17 February 2014 (UTC)

Indicating file size for large PDF

When the URL parameter points to a large PDF, is there a way to indicate the file size, so the person reading can make an informed decision about whether to click the link and how long they may have to wait for it to download? Nurg (talk) 01:25, 22 February 2014 (UTC)

Not logical to single out PDFs. Some PDF files are smaller than some image files. If we are going to do this is should be only for files (of any file type) above a given size (to be decided upon). But anyway is this still a relevant consideration nowadays? Would have made more sense in the early days perhaps than it does now. -- Alarics (talk) 10:40, 22 February 2014 (UTC)
You can put the size in the 'format' field- it does not render in the COinS metadata, so we can be fairly free here. I am curious as to what you consider large. --  Gadget850 talk 11:19, 22 February 2014 (UTC)
Not to suggest that this was recommended practice, but I put the size in the format field in a citation at Taquan Air three years ago and no one has complained:
Unscintillating (talk) 12:11, 22 February 2014 (UTC)
Another solution to the problem is to not link to the PDF at all, but rather link to the Google cache, as in this example from Richard Conn Henry:
Unscintillating (talk) 12:21, 22 February 2014 (UTC)
That is an ugly citation. And its not the real title of the document. --  Gadget850 talk 19:01, 22 February 2014 (UTC)
If there is a concern about the large size of a linked file, using |format=PDF, 1.6MB or similar should be sufficient. The format should still be explicitly stated because not all URLs end in .pdf nor can/will all browsers display the icon if the URL does end in the appropriate file extension. Additionally, that icon lacks any sort of alternate text (as far as I know) to alert users of screen readers or other adaptive technology of the icon's intended meaning. In short, a little redundancy is a good thing. Imzadi 1979 → 19:59, 22 February 2014 (UTC)

"Work and publisher" issues

In section Work and publisher there are several issues. Numbered items below are taken directly from Help:Citation Style 1#Work and publisher.

  1. A leading "The" can usually be left off a website, unless confusion might result.
    • This needs to be harmonized with the instructions at WP:CITEHOW, template:cite news and all the other cite templates, which make no mention of this alleged rule.
    • I disagree at least in the case of news websites such as The Huffington Post.
    • The word may should replace can here.
  2. For periodicals, it is conventional in citations (not running prose) to omit a leading "The" for publications with multi-part names (|newspaper=San Francisco Chronicle and |journals=Astrophysical Journal but |newspaper=The Nation) unless ambiguity would result.
    • San Francisco Chronicle is an invalid example of this alleged rule because this newspaper's name does not being with The. A better example of this alleged rule would be |newspaper=New York Times, because that newspaper's name does begin with The.
    • This needs to be harmonized with the instructions at WP:CITEHOW, template:cite news and all the other cite templates, which make no mention of this alleged rule.
    • I don't think this alleged rule is well known or respected, because I have edited many hundreds if not thousands of articles inserting The before New York Times, Washington Post, Jerusalem Post, Wall Street Journal, and others; I've seen other editors do likewise; I note this in my edit summary, e.g. ''The'' New York Times; nobody has ever commented that I needn't or shouldn't make this change and I've never noticed the change being reverted.
  3. Many journals use highly abbreviated titles when citing other journals (e.g. "J Am Vet Med" for "Journal of the American Veterinary Medical Association") because specialists in the field the journal covers usually already know what these abbreviations mean. Our readers do not, so these abbreviations should always be expanded.
    • This needs to be harmonized with the instructions at WP:CITEHOW and template:cite journal, which make no mention of this alleged rule.
    • This alleged rule is not well known or respected. I have seen thousands if not tens of thousands of Wikipedia articles that use such abbreviations with or without {{cite journal}} and I have observed no trend toward expanding these abbreviations.
  4. publisher: the name of the company that actually published the source. The field should not include the corporate designation such as "Ltd" or "Inc.", unless some ambiguity would result or the company is usually known with that designation even in everyday use.
    • I agree; if this is a rule, the instructions at WP:CITEHOW and at the citation templates should reiterate the rule.
  5. The "publisher" parameter can be included even where it would be the same or mostly the same as the work/site/journal/etc., for example:
    |work=Amazon.com    and   |publisher=Amazon
    |newspaper=The New York Times    and   |publisher=The New York Times Company
    • I vigorously disagree with this and routinely remove the |publisher= parameter when it duplicates the work. It does not provide any useful information to "inform" the user in citations that The New York Times is published by The New York Times Company, or that the Journal of the American Chemical Society is published by the American Chemical Society. Such |publisher= parameters should always be omitted.
    • The word may should replace can here if this alleged rule is allowed to remain.
  6. Location
    • It should specify that the |location= parameter should be used when the location is part of the common name but not the actual name of a newspaper. For example, the newspaper commonly known as the New York Daily News is actually Daily News (New York) and can be entered with |newspaper=Daily News |location=New York, which yields Daily News (New York).

—Anomalocaris (talk) 10:42, 23 February 2014 (UTC)

I have been mulling over style issues for a while. If this is to actually be an actual citation style, then we need to go though and expand and clean the documentation. We actually have two sets of documentation: Help:Citation Style 1 and {{Citation Style documentation}} which is used to build the documentation pages for each template.
WP:CITEHOW is an overview of citing sources and not a comprehensive style guide.
My opinions:
  1. There is no need to remove articles such as the. We are not short of storage.
  2. Ditto.
  3. We are an encyclopedia. Our target audience is the general public, not professionals who would immediately understand these abbreviations. Wikipedia:Make technical articles understandable touches on this. The issue is prevelant in medical and legal articles.
  4. Agree. The inclusion of publisher is to identify the source.
  5. Agree. If the publisher is implied in the publication name, then it is redundant.
  6. Agree. The purpose of location is to identify the source. If the it is implied in the publication name, then it is redundant (The New York Times). If it clarifies the publication then it is useful (Daily News (New York)).

--  Gadget850 talk 11:26, 23 February 2014 (UTC)

WP:CITEHOW MUST NOT be edited to agree with Citation Style 1. CS1 is a separate style, and only one of many that may be used in Wikipedia articles. CITEHOW is a section in WP:CITE, which allows any consistent style. Jc3s5h (talk) 13:13, 23 February 2014 (UTC)
In my view, the "publisher" parameter should always be left blank or deleted in the case of mainstream newspapers, whether or not the name of the publisher is similar to that of the newspaper. It is the "location" parameter which uniquely defines the newspaper. The "publisher" parameter is meant only for obscure or long-defunct publications where there might be doubt as to which publication is meant.
Also, I agree that there is no point is dropping the "The" from "The New York Times" and other papers whose title on the masthead includes "The". -- Alarics (talk) 19:55, 23 February 2014 (UTC)

Publication date is a range

In cleaning up the CS1 messages "check date=" I encounter this situation. Old code says |date=2007–2009 (ndash used, not by entity). I could not find in MOS:DATEFORMAT that that is incorrect, still the CS1 message appears. I also met |date=2007– for publication. My question is: is that date (period) non-MOS, wrong, or to be tricked around? (This question was raised some months ago when this date issue was in development; I don't recall a solution more a sort of postponement/see individual cases). -DePiep (talk) 11:18, 26 February 2014 (UTC)

The earlier talk started November 2013 and is now in archive. -DePiep (talk) 11:27, 26 February 2014 (UTC)
YYYY–YYYY ranges not currently supported by Module:Citation/CS1 (and that includes open ended ranges like your |date=2007– example).
—Trappist the monk (talk) 11:41, 26 February 2014 (UTC)
Thanks. Could the helppage reflect this and suggest a workaround? -DePiep (talk) 14:11, 26 February 2014 (UTC)
The workaround is to ignore MOS-valid date ranges that cause an error until date ranges are supported by the module. Remember that these date errors are exposed only to those editors who have chosen to see them, so they are only bothering a few gnomes.
I have updated the Help page text accordingly. – Jonesey95 (talk) 18:02, 26 February 2014 (UTC)
OK. -DePiep (talk) 18:10, 26 February 2014 (UTC)

subst?

Can this be subst'ed ? I'm trying to put some citations onto wikimedia.org.uk (where the templates aren't installed or maintained) and expected to be able to subst: them into me en:WP sandbox (see User:Andy Dingley/sandbox), then copy the results over. Instead it just leaves the wikitext 

{{#invoke:Citation/CS1|citation
|CitationClass=journal
}}

Andy Dingley (talk) 10:55, 26 February 2014 (UTC)

I have no experience with subst'ing. If I understand your question, you want a wiki-markup version of the citation – the template's output to the wikimedia parser. You can get that by wrapping the citation template in a {{code}} template:
{{code|1={{cite book |title=Head First HTML with CSS & XHTML |author=Basham, Sierra & Bates |publisher=O'Reilly |date=2004 |isbn=0-596-10197-X }}}}
which gives:
'"`UNIQ--templatestyles-0000014E-QINU`"'<cite id="CITEREFBasham,_Sierra_&amp;_Bates2004" class="citation book cs1">Basham, Sierra & Bates (2004). ''Head First HTML with CSS & XHTML''. O'Reilly. [[ISBN (identifier)|ISBN]]&nbsp;[[Special:BookSources/0-596-10197-X|<bdi>0-596-10197-X</bdi>]].</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Head+First+HTML+with+CSS+%26+XHTML&rft.pub=O%27Reilly&rft.date=2004&rft.isbn=0-596-10197-X&rft.au=Basham%2C+Sierra+%26+Bates&rfr_id=info%3Asid%2Fwiki.riteme.site%3AHelp+talk%3ACitation+Style+1%2FArchive+4" class="Z3988"></span>
The contents of <span class="citation book">...</span> is your citaion:
Basham, Sierra & Bates (2004). ''Head First HTML with CSS & XHTML''. O'Reilly. [[International Standard Book Number|ISBN]] [[Special:BookSources/0-596-10197-X|0-596-10197-X]].
→Basham, Sierra & Bates (2004). Head First HTML with CSS & XHTML. O'Reilly. ISBN 0-596-10197-X.
—Trappist the monk (talk) 11:33, 26 February 2014 (UTC)

Subst'ing can be done with dummy parameter

The Lua-based wp:CS1 cite templates could be updated to allow wp:subst'ing, to store the formatted citation in place of template calls, using:

{{{{{zz|safesubst:}}}#invoke:citation/CS1|citation|CitationClass=journal}}.

The parameter name "zz" is a dummy name to avoid problems with a blank-named parameter containing "safesubst:" but could be some other rare name such as "∞" or such. I have created a version, as Template:Cite_journal/subst, to allow further testing before updating the major live templates to reformat the 2.3 million affected pages. Note the stored results of the test below:
Test {cite_journal/subst}:

  • Markup: {{subst:cite journal/subst |last=Doe|first=John |last2=Dooe|first2=Jane |editor=staff |title=Academic Paper|journal=Science|page=1435-39|volume=5|issue=7|date=4 May 2013}}
  • Result: Doe, John; Dooe, Jane (4 May 2013). "Academic Paper". In staff. Science 5 (7): 1435-39. 

Recall how a CS1 cite template also stores the cryptic COinS metadata internally at the end of each cite, as a titled span-tag: <span title="ctx_ver=Z39.88-2004...> (etc.), which would no longer match a hand-updated citation unless also hand-updating the span-tag. I apologize for not putting safesubst in the original Lua-based cite templates, earlier, when I completed writing Module:Citation/CS1 last year. All the sideshow problems with the wp:VE debacle, and the lost edits caused by forced https protocol, and numerous Wikipedia database failures (etc.) have delayed real improvements. -Wikid77 (talk) 16:44, 26 February 2014 (UTC)

Differences for display-authors documentation actual function

There is a difference between all three of the documentation for |display-authors= on Help:Citation Style 1#Display options, Template:Cite web/doc, and the actual function.

Help:Citation Style 1#Display options: States that the number of authors displayed when published is limited to 9 by default.

Template:Cite web/doc: States that all authors are always displayed except in the case where there are exactly 9 authors and then only 8 are displayed. The documentation is actually on: Template:Citation Style documentation/doc which is transcluded into teh documentation for multiple other CS1 templates.

The actual template: Displays all authors up to at least 28:[1]

Same citation, but with |display-authors=5[2]

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

My normal default would be to change the documentation to reflect what the template actually does. However, it is not clear to me if the current behavior is what is desired, or if there is a bug (i.e |display-authors= not being set to 8 by default) which should be fixed. Is the template currently operating the way that is intended (i.e. no default limit on the number of authors displayed)? I have not tested if the number of editors is operating in a similar manner. — Makyen (talk) 11:50, 2 March 2014 (UTC)

The citations above are working as they should be. The documentation at Help:Citation Style 1#Display options describes operation for those CS1 templates still using {{citation/core}}. What you need to do is fix Template:Citation_Style_documentation/display so that it displays appropriate text depending on where it is transcluded. For {{citation/core}}-based templates it should display the default of 8 text; for Module:Citation/CS1-based templates it should display the all authors default text; and for cases like Help:Citation Style 1#Display options, it should display an appropriate combination of both.
—Trappist the monk (talk) 12:18, 2 March 2014 (UTC)
The documentation shown in {{cite web}} describes the function of |display-authors= in that template and in all others that use Module:Citation/CS1 (see table in Help:Citation Style 1). These templates display all authors unless there are exactly 9 authors or display-authors is set.
I have looked at the documentation, and it is set up such that if it is transcluded on doc pages for templates that use Module:Citation/CS1, it shows the correct text. If it is transcluded on doc pages for templates that use {{citation/core}}, it shows the correct text. It does not show the correct text on the Help:Citation Style 1 page, because that page is intended to show documentation for both types of template, but only the citation/core text is shown. I expect that this dual-documentation problem exists throughout the Help page, and the page would need a complete rewrite to be accurate in explaining how both types of template work.
I can't figure out an elegant way to proceed. One brute force way would be to use a nested if statement saying "if lua, show this; if non-lua, show this; else show this new combined text." We would have to label the non-lua templates and recode all of the documentation subpages, I believe. I could be wrong about any of this, since I showed up a little late to this lua party. – Jonesey95 (talk) 14:43, 2 March 2014 (UTC)
That is exactly what I have done for other parameter sets; see Template:Csdoc#author. I'm rather busy at the moment, but I will get to it when I can. --  Gadget850 talk 23:48, 2 March 2014 (UTC)

e-Books, redux

Is this still the status quo regarding citing location in e-Books, such as Kindle stuff? I've just downloaded a book that is in Kindle format but the article uses {{sfnp}} I can supply some "proper" page numbers because small chunks of the printed version are available online ... but the vast majority is not. With hindsight, I should have paid the extra few quid & bought the physical version: live and learn! - Sitush (talk) 13:25, 4 March 2014 (UTC)

REF cited once, but has two pointers in REFlist

Please have a look at https://wiki.riteme.site/w/index.php?title=Berlin-Sch%C3%B6neberg_station&oldid=598265855 and https://wiki.riteme.site/w/index.php?title=Berlin_Feuerbachstra%C3%9Fe_station&oldid=598255926

The REFs made by "cite journal" in the reflist are referred to only once in the text itself, but in the finished article, there are two pointers a, and b each for each entry in the References list. How come? How to fix it? --L.Willms (talk) 21:24, 5 March 2014 (UTC)

Changing REF to ref fixes the problem, why I've no idea. Nthep (talk) 21:36, 5 March 2014 (UTC)
(e/c) I changed ref to ref, and it seems the problem has been fixed... though it's unclear why. - Purplewowies (talk) 21:40, 5 March 2014 (UTC)
Interesting. It appears that if you use List-defined references and capitalize any character within ref in the defined reference inside the list, then Cite adds extra backlinks. I will file a bug report later today. --  Gadget850 talk 11:22, 6 March 2014 (UTC)
The wonderworld of computer programming. Thanks for the changes to "Nthep". I'm not sure, but I think that I had used capitalized spelling of REF in earlier edits in other articles. But my memory might cheat me. Anyway, I now to know how to avoid that strange feature. --L.Willms (talk) 15:36, 6 March 2014 (UTC)
The bug only shows up when you use it inside LDR refs. While HTML allows upper or lower case tags (but recommends lower case), you must remember that <ref> is a parser tag that resembles HTML but works very differently. See Template talk:Reflist#Capitalized <ref> causes extra backlink. --  Gadget850 talk 15:41, 6 March 2014 (UTC)

Why is there a proscription against wikilinks in author parameters? CS1 templates that use Module:Citation/CS1 don't seem to have a problem with wikilinked authors; the display is correct, and the COinS metadata aren't corrupted. The same is true of the remaining CS1 templates that use {{citation/core}} except that none of those templates produce COinS metadata:

  • {{cite book |title=Title |author=[[Abraham Lincoln|Lincoln, A]]}}
    • Lincoln, A. Title.
    • '"`UNIQ--templatestyles-0000015B-QINU`"'<cite id="CITEREFLincoln,_A" class="citation book cs1">[[Abraham Lincoln|Lincoln, A]]. ''Title''.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Title&rft.au=Lincoln%2C+A&rfr_id=info%3Asid%2Fwiki.riteme.site%3AHelp+talk%3ACitation+Style+1%2FArchive+4" class="Z3988"></span>
  • {{cite interview |title=Title |author=[[Abraham Lincoln|Lincoln, A]]}}
    • Lincoln, A. "Title" (Interview).
    • '"`UNIQ--templatestyles-0000015F-QINU`"'<cite id="CITEREFLincoln,_A" class="citation interview cs1">[[Abraham Lincoln|Lincoln, A]]. "Title" (Interview).</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=unknown&rft.btitle=Title&rft.au=Lincoln%2C+A&rfr_id=info%3Asid%2Fwiki.riteme.site%3AHelp+talk%3ACitation+Style+1%2FArchive+4" class="Z3988"></span>

—Trappist the monk (talk) 13:36, 9 March 2014 (UTC)

  • Wikilinked author names complicate author lists last/first or ref=harv: So, the general method has been to have everyone use "authorlink=" and allow "ref=harv" to build the span-tag id from the "last=" and "year=". It is also difficult to get users to wikilink lists as "Last, First". However, Lua could auto-extract the last name from a wikilinked author name (when "ref=harv" is used), by detecting the leading double-bracket "[[" and parsing "Hernando de Soto" and auto-capitalizing as "De Soto". Currently, I am finding a similar problem where several users think a URL must have outer "[__]" as in url=[http__] and so the autofix of URLs requires removal of outer brackets in such URLs, then log the page in a tracking category. It is interesting to see how some new users think all URLs must be specified in "[__]" where some even enclose the whole "[url=http]" which creates a parameter named "[url" as an unknown keyword. Fortunately, there are fewer than 200 such urls, and Lua is very fast when resetting a URL=string.sub(URL,2,-2), without "[__]" in those rare cases. For {citation/core}, we could autofix URLs by invoking Lua Module:String to extract the center from regex '%[*(.*)%]*' or similar. -Wikid77 (talk) 20:15, 9 March 2014 (UTC)
    • The citation/core versions don't strip the markup when generating COinS, which is why we still document 'author-link'. And the only way to include the author link like this is to use 'author'. This doesn't play well with shortened footnotes, as the link for your example would be "Lincoln, A", which is nonstandard. --  Gadget850 talk 22:24, 9 March 2014 (UTC)
It isn't clear to me that {{citation/core}} is generating COinS. When I look at the html source for this page, I don't see any COinS for the {{cite interview}} citations.
—Trappist the monk (talk) 23:27, 9 March 2014 (UTC)
Should we manually format with proper author links and avoid this template until it is ready to search for and automatically find matching authors? Hcobb (talk) 21:35, 9 March 2014 (UTC)
Please elaborate, I don't understand what it is that you are asking.
—Trappist the monk (talk) 22:11, 9 March 2014 (UTC)
I should clarify. I meant my question to be specifically about |author=, |authors=, |authorn=, etc, not the divided author-name parameters |last=, |first=, |author-last=, |author-first=, etc.
I don't think that |ref=harv is the reason. Here are two references one to {{cite book}}[1] which uses Module:Citation/CS1 and the other {{cite interview}}[2] which uses {{citation/core}}. Both of these citations are the same citations as above to which I've added |ref=harv and |year=1865a/b.

References

  1. ^ Lincoln, A 1865a.
  2. ^ Lincoln, A 1865b.
—Trappist the monk (talk) 22:11, 9 March 2014 (UTC)
I had forgotten that COinS was removed from core due to performance issues. We should be able to restore it now, and I will start that discussion. And again, shortened footnotes use only the author last nem for the in-text cite. --  Gadget850 talk 13:22, 10 March 2014 (UTC)
I guess I would suggest not restoring COinS to {{citation/core}} simply because as time goes by, there are fewer and fewer templates that will be using it – {{cite interview}} is next up to abandon {{citation/core}} (which see).
Yes, the author's last name is intended for use with shortened footnotes. But, because |author=, |authors=, and |author1= are aliases of |last= and |last1=, it is possible to use any of the |author=-type parameters with shortened footnotes. I suspect that we can trap citations without |lastn= and with |ref=harv to prevent use of |author=-type parameters for CITEREF creation.
—Trappist the monk (talk) 13:46, 10 March 2014 (UTC)
We have discussed {{cite wikisource}} here— it uses {{citation/core}}, but is not well used and includes some oddball parameters. Then we have {{cite IETF}}, which again uses core, but also includes a bunch of specific parameters. I started a discussion at core, and we can continue there. --  Gadget850 talk 14:27, 10 March 2014 (UTC)

Shouldn't we just drop "|last=" and insert a wikilink to a person page instead? Then the template can wander over yonder and fetch the proper formatting of the person's name from their own page. Hcobb (talk) 13:27, 10 March 2014 (UTC)

I must be an idiot, but I still don't understand what it is that you are asking.
—Trappist the monk (talk) 13:46, 10 March 2014 (UTC)

Migrating cite interview to Module:Citation/CS1/sandbox

I think that I have finished migrating {{cite interview}} to Module:Citation/CS1/sandbox. See Template:Cite interview/testcases.

The sandbox versions differ slightly from the live version where Module:Citation/CS1 renders certain parameters in different positions and adds punctuation not provided by the {{citation/core}} version.

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

Is it really an error to not have a title for an interview? The Gene Simmons interview, for example (which I recommend to everyone), doesn't really have a title that could be cited. A WP editor would have to make up something better than "Interview with Terry Gross", which seems unreasonable to me.
Coming to the point: should we suppress or display the "url without title" error for {cite interview}? I would suppress it. – Jonesey95 (talk) 19:53, 10 March 2014 (UTC)
For your particular example, I would use "Leader and bassist of the band Kiss, Gene Simmons" per NPR, just as it is used in the Terry Gross article. --  Gadget850 talk 20:18, 10 March 2014 (UTC)

Approximate year

I thought it was agreed that approximate years, in the form |year=c. 2009, was allowed. I note, however, that this no longer works (see the source by Time Service Dept. in Coordinated Universal Time, which no longer connects the inline cite to the bibliography. Jc3s5h (talk) 13:41, 23 February 2014 (UTC)

Fixed using {{sfnref}}. There may be another way. – Jonesey95 (talk) 14:45, 23 February 2014 (UTC)
Fixed in Module:Citation/CS1/sandbox.
Time Service Dept. (c. 2009). "Leap Seconds". United States Naval Observatory. Retrieved 17 July 2011. {{cite web}}: Invalid |ref=harv (help)
—Trappist the monk (talk) 16:14, 23 February 2014 (UTC)
What is now allowable in the date field? --  Gadget850 talk 18:18, 23 February 2014 (UTC)
When an approximate year is specified, the form is: c.<space>year<CITEREF disambiguator> where year is a three or four digit number, the first digit of which must be in the range 1–9 (100–9999); and where <CITEREF disambiguator> is an upper or lower case letter (A–Z and a–z). Approximate years may be specified with either |date= or |year=.
—Trappist the monk (talk) 18:41, 23 February 2014 (UTC)
Of course c.<space> and <CITEREF disambiguator> are optional. Either or both may be omitted. Or that's how it ought to work. Also, the year range limitation only applies if one wants automatic linking from a parenthetical citation or short footnote to the bibliography entry. If the editors of an article aren't using the feature, years outside that range could be used. Jc3s5h (talk) 19:14, 23 February 2014 (UTC)
Years outside the 100–9999 range are not valid regardless of the use of the circa prefix or the CITEREF disambiguator. This constraint is a holdover from the limitations imposed by the #time parser function. As far as I know, there has been no determination made to extend this range.
—Trappist the monk (talk) 19:34, 23 February 2014 (UTC)
Help:Citation Style 1 says nothing about accurate dates not being allowed. It does say that the date formats in the acceptable date format table of WP:DATESNO are allowed. That table says nothing about a limit on the date range. Obviously WP:DATESNO must allow for the representation of every possible date. Help:Citation Style 1 says nothing about limiting the date range in all cases, only that the automatic linking won't work if the date is outside the indicated range. So if there was ever a discussion saying this limitation is OK in general, that limitation never made it into Help:Citation Style 1. Jc3s5h (talk) 19:47, 23 February 2014 (UTC)
I see this was discussed at Module talk:Citation/CS1/Archive 9#Should date validation allow "BC" and other eras? and the majority of editors seemed to accept the idea of entering whatever date was correct, even if it was before 100.

external links in page parameters

Corrupted COinS metadata occurs when editors place external links in any of the |page= parameters. To fix this, I have added a small bit of code to Module:Citation/CS1/sandbox that extracts the page number strings from the |page= value and uses the extracted data for COinS. If this change is retained, editors may freely add external links in any of the page parameters.

Of course there is a caveat: When the value assigned to |pages= contains the square brackets, hyphens are not converted to endashes as they would be if the page range was not part of a url. I have a vague memory of a conversation that resulted in this restriction, but I suspect that it is imposed because the replacement code would indiscriminately replace hyphens in a url with an endash which would break the url. I'll give some thought to fixing this.

  • Page number without external link. p. 45.
    • {{cite book/new |title=Page number without external link |page=45}}
    • '"`UNIQ--templatestyles-0000016C-QINU`"'<cite class="citation book cs1">''Page number without external link''. p.&nbsp;45.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Page+number+without+external+link&rft.pages=45&rfr_id=info%3Asid%2Fwiki.riteme.site%3AHelp+talk%3ACitation+Style+1%2FArchive+4" class="Z3988"></span>
  • Page number with external link. p. 24.
    • {{cite book/new |title=Page number with external link |page=[http://www.example.com 24]}}
    • '"`UNIQ--templatestyles-00000170-QINU`"'<cite class="citation book cs1">''Page number with external link''. p.&nbsp;[http://www.example.com 24].</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Page+number+with+external+link&rft.pages=24&rfr_id=info%3Asid%2Fwiki.riteme.site%3AHelp+talk%3ACitation+Style+1%2FArchive+4" class="Z3988"></span>
  • Page numbers with mixture of linked and unlinked. pp. 24, 28–32, 57, 77–80, 106.
    • {{cite book/new |title=Page numbers with mixture of linked and unlinked |pages=24, [http://www.example.com 28–32], [http://www.example.com 57, 77–80], 106}}
    • '"`UNIQ--templatestyles-00000174-QINU`"'<cite class="citation book cs1">''Page numbers with mixture of linked''. pp.&nbsp;24, [http://www.example.com 28–32], [http://www.example.com 57, 77–80], 106.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Page+numbers+with+mixture+of+linked&rft.pages=24%2C+28-32%2C+57%2C+77-80%2C+106&rfr_id=info%3Asid%2Fwiki.riteme.site%3AHelp+talk%3ACitation+Style+1%2FArchive+4" class="Z3988"></span>
  • Page numbers with mixture of linked and unlinked and different urls. pp. 24, 28–32, 57, 77–80.
    • {{cite book/new |title=Page numbers with mixture of linked and unlinked and different urls |pages=[http://www.example.com 24], 28–32, [//example.org 57, 77–80]}}
    • '"`UNIQ--templatestyles-00000178-QINU`"'<cite class="citation book cs1">''Page numbers with mixture of linked and unlinked and different urls''. pp.&nbsp;[http://www.example.com 24], 28–32, [//example.org 57, 77–80].</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Page+numbers+with+mixture+of+linked+and+unlinked+and+different+urls&rft.pages=24%2C+28-32%2C+57%2C+77-80&rfr_id=info%3Asid%2Fwiki.riteme.site%3AHelp+talk%3ACitation+Style+1%2FArchive+4" class="Z3988"></span>
  • No page number value.
    • {{cite book/new |title=No page number value}}
    • '"`UNIQ--templatestyles-0000017C-QINU`"'<cite class="citation book cs1">''No page number value''.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=No+page+number+value&rfr_id=info%3Asid%2Fwiki.riteme.site%3AHelp+talk%3ACitation+Style+1%2FArchive+4" class="Z3988"></span>

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

Tweaked to support page numbers that are alpha and alphanumeric.

  • Roman numeral and alphanumeric page numbers. pp. i, iii–vii, A-2.
    • {{cite book/new |title=Roman numeral and alphanumeric page numbers |pages=[http://www.example.com i, iii–vii, A-2]}}
    • '"`UNIQ--templatestyles-00000180-QINU`"'<cite class="citation book cs1">''Roman numeral and alphanumeric page numbers''. p.&nbsp;[http://www.example.com i, iii–vii, A-2].</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Roman+numeral+and+alphanumeric+page+numbers&rft.pages=i%2C+iii-vii%2C+A-2&rfr_id=info%3Asid%2Fwiki.riteme.site%3AHelp+talk%3ACitation+Style+1%2FArchive+4" class="Z3988"></span>

—Trappist the monk (talk) 17:16, 14 March 2014 (UTC)

  • Dashes in page numbers are optional: Remember how some page numbers should retain hyphens, such as page "B-19" or similar in newspapers, and so the auto-adjustment of page-number dashes in "pages=" is just a courtesy to users who can hand-edit to use dashes if wanted. For that reason, singular option "page=B-19 — B-21" can be used to retain hyphens. Otherwise, I would not worry about hyphens in page-number ranges because over 94% of real-world sources tend to use hyphens everywhere (except new Britannica), and when other punctuation is used, then slash is far more common than dashes, such as in "pp. 5/7-8" or dates "May/June 1976" etc. The COinS metadata has been used by Bots to check for deadlinks and insert title, or archiveurl and archivedate (as in User:DASHBot), but I am not sure if page number is checked by Bots very much. -Wikid77 (talk) 17:37, 15 March 2014 (UTC)

Migrating cite DVD-notes to Module:Citation/CS1/sandbox

Because I'm in the process of migrating {{cite AV media notes}} to Module:Citation/CS1/sandbox and because {{cite DVD-notes}} has certain similarities, I've started migrating {{cite DVD-notes}} as well. (testcases)

During this migration, as it is with {{cite AV media notes}}, I'm wondering if we should make certain changes:

  1. rename {{cite DVD-notes}} to {{cite DVD notes}} to get rid of the hyphen – it is the only CS1 template that uses a hyphenated name
  2. |format= – in most CS1 citations, |format= has a specific definition: the file format of an online resource (pdf, xls, mpeg, etc). The {{citation/core}} version of the template tests the value assigned to |format=. If |format=Liner notes then, the value is not displayed. I guess this is because |type= is assigned a default value of Liner notes – no sense in having both |format= and |type= display the same thing. Because |format= specifies the format of an online resource, it is interesting that the basic skeletons in the documentation don't include |url=. Until the template was converted to {{citation/core}}, online accessible DVD notes were not supported by this template. I propose to deprecate this peculiar functionality of |format=; before migrating to Lua, replace |format= with |type= in existing citations; and add documentation to support the use of |url=.
  3. |director= – it isn't clear to me why this parameter is available. Sure, a director may have written the DVD's notes and should be credited as the author. But I see no reason for a special parameter here. For comparison, in {{cite AV media notes}}, |artist= is an alias of |others= (as I think about it now, it isn't really clear why that is). |director= is an alias of |author=. I propose to deprecate |director= in favor of the standard suite of |author= parameters.
  4. |titleyear= – this parameter is an alias of |origyear=. It isn't clear to me what it is that this parameter is supposed to be doing – the name itself doesn't offer any real clues. It appears that editors are using |titleyear= to document the original release year of the DVD subject (see the testcases for examples). I think that this is a misuse of the parameter which should be the original publication year of the notes. I propose to deprecate |titleyear= in favor of |origyear=.
  5. |publisherid= – I propose to deprecate |publisherid= because it is simply a long-winded form of |id=.

Alternately, as was suggested in the discussion about migrating {{cite AV media notes}}, we might merge {{cite DVD-notes}} into {{cite AV media notes}}; a subject that I will address in another post.

I will be adding a note about this migration to the projects notified for the {{cite AV media notes}} migration.

—Trappist the monk (talk) 14:27, 12 March 2014 (UTC)

I've been looking at some uses and have found several where 'publisherid' is an ASIN, thus 'asin' should be used; but it will take eyes on to fix those, so updating to 'id' is a first step. Some of the oddball parameter use is because I updated the original template to citation/core while trying to maintain backward compatibility. I agree that it is time to update the use. --  Gadget850 talk 14:43, 12 March 2014 (UTC)
I just found one with an ISBN so there you go. I've updated item 2 in the list above to replace |format= with |type=. None of the pages I looked at, were using |format= to identify the online format (makes sense since I haven't found any that use |url= ...). I have an AWB script that will do much of this work.
—Trappist the monk (talk) 17:54, 12 March 2014 (UTC)
I agree with all of the above, with the same recommendation I made in the section above. Let's get as much fixed before migration to Lua so that there are as few red error messages as possible. – Jonesey95 (talk) 05:28, 13 March 2014 (UTC)
Please merge; the AV template is intended to be used when citing DVD liner notes; the mroe specific template is therefore redundant. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:23, 23 March 2014 (UTC)

Documentation changed according to items 1–5 above with these exceptions:

3. |director= – may or may not be the author of the note and so similar to |artist= in {{cite AV media notes}}; deprecated in favor of |others= like |artist= in {{cite AV media notes}}; makes it easier to deprecate {{cite DVD notes}} in favor of {{cite AV media notes}}.

New:

6. Default type changed from "Liner notes" to "Media notes" (same as {{cite AV media notes}})

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

One of the common errors is providing URLs in the |authorlink= parameter, which produces malformed links - how about catching this as a CS1 error? GregorB (talk) 19:02, 22 March 2014 (UTC)

Good idea. I posted a similar idea at Module_talk:Citation/CS1/Feature_requests#Detect_and_report_wikilinks_in_author_parameters. – Jonesey95 (talk) 20:15, 22 March 2014 (UTC)
Yep, such a good idea that you have suggested it before. There is a version of the check in the sandbox.
—Trappist the monk (talk) 23:19, 22 March 2014 (UTC)
Sigh. I must be getting old. Thanks. – Jonesey95 (talk) 04:03, 23 March 2014 (UTC)

Fixes that bots could take on

Here's a list of fixes that a bot should be able to take on. I come across these frequently. I have numbered them manually for ease of discussion. These are similar to fixes suggested by Wikid77 above.

1. Change {cite web|http} to {cite web|url=http} in Category:Pages with empty citations and Category:Pages with citations using unnamed parameters. Many errors in these two categories are of this specific type, and they should be very easy to fix.

2. Change |translator= to |others=... (translator) in Category:Pages with citations using unsupported parameters.

3. Fix ISBN errors in Category:Pages with ISBN errors as described in Help_talk:Citation_Style_1/Archive_4#Bot_to_fix_ISBN_errors.3F. This may require an RFC first.

4. Fix articles in Category:Pages with citations having bare URLs using some sort of Reflinks-like tool. These fixes will have to be run by hand using a script rather than a bot, since experience with Reflinks has shown that pulling data from web pages requires human oversight.

5. I keep coming back to Category:Pages using citations with accessdate and no URL and not knowing what a good fix would look like. Commenting out accessdates in those citations is tempting, but the error is sometimes a symptom of another error (like #1 above). We may have to clear out Category:Pages using web citations with no URL first.

More? – Jonesey95 (talk) 17:48, 5 March 2014 (UTC)

Let me know when there's consensus that these errors should be corrected (perhaps a post to my user page?) and I'll modify Citation Bot to address 1 & 2 (and others if there's a clear way of how to). Martin (Smith609 – Talk) 18:12, 5 March 2014 (UTC)
I believe #1 could be automatically fixed by a bot. Regarding #2, there is some discussion on adding a |translator=-like property, but so far no consensus to do so. It would be nice to have a bot fix ISBN errors as in #3. I've seen bad bot-generated titles around, some including pipes (|) for instance. There may be a good way to automatically do #4, though, filtering the title. For #5, I recently had a discussion with an IP about accessdates. I often have commented them out, if I thought a url was left out, but there are times when they aren't needed at all. If there is a proper date for the work, the accessdate is most likely redundant. To start, a bot could run through all the pages, deleting accessdates if there is no url and a properly formatted MOS date prior to (or the same as) the accessdate. That would reduce the log some, because people who fill in accessdates for printed material often fill in the date of the work as well. (That's my observation, anyway.) —PC-XT+ 04:16, 24 March 2014 (UTC)
Many editor tools auto-fill |accessdate= with the current date irrespective of whether |date= is populated or not. If this behaviour could be amended, suppressing the addition of |accessdate= where |date= is already stated, the number of new cases would likely rapidly plummet. One such widely-used tool is Reflinks. There are others. 79.67.241.244 (talk) 11:58, 24 March 2014 (UTC)
But Reflinks works with online sources that actually do have meaningful accessdates, so nothing wrong with its behavior.
I've fixed a lot of refs where accessdate was provided without URL, and I don't think I've ever encountered a case where simply deleting the accessdate would not be a proper fix. Still, it is tricky, but there is a simple heuristics: if there's accessdate without URL, and the template is {{cite book}}, it is safe to do it (barring #1 above, which can be fixed beforehand). GregorB (talk) 12:17, 24 March 2014 (UTC)
Stating the retrieval date of a date-stamped online newspaper or journal article adds unnecessary clutter to the reference. Where the publication date is stated, there is no need to state the retrieval date. If editors are stating the retrieval date instead of the publication date then perhaps more guidance is needed. -- 79.67.241.244 (talk) 13:02, 24 March 2014 (UTC)
I'm not aware of a guideline to omit accessdates if date is provided. I tend to always provide |accessdate=, even with |date=. The only exception I can think of right now is e.g. Google Books: the content that is pointed to is not going to change in a meaningful way, nor it is going to go offline (well, hopefully), so I suppose there is no scenario in which |accessdate= could prove useful. Still, what you say does make a lot of sense to me: undated online content might change, so we use |accessdate= to indicate which version of the webpage was used; dated content, however, shouldn't change, so it doesn't really matter when we accessed it. This might even be an argument to say that accessdate should be mandatory if no date is provided, although introducing this would create a hellish backlog... GregorB (talk) 13:56, 24 March 2014 (UTC)
Thanks for the discussion, everyone. Deleting |accessdate= automatically is probably acceptable in {{cite book}} templates and in {{cite journal}} templates where a |doi= or other identifier is present, since those sources are unlikely to change.
I think that in other templates, commenting out |accessdate= is better than deleting it. For example, a {{cite web}} template with no URL will generate a different CS1 error; someone trying to fix that error may find it useful to see the accessdate that was entered by a previous editor. – Jonesey95 (talk) 14:17, 24 March 2014 (UTC)
Some say that, for web pages with archiving forbidden in robots.txt, accessdates in addition to dates can be useful to help determine the likelihood of a dead url coming back. (In this case, a date range is specified, from date to accessdate. This seems to suggest that we should update these particular accessdates for accurate records, though.) There may be other uses for accessdates, besides specifying the version referenced, though I don't know of any. I do think deleting them for books and journals with specific identifiers would be fine. For others, comment them out if in doubt, since the bot will likely not have the capacity to notice if they may be used. (I am sure that in most cases, they are unused.) —PC-XT+ 04:48, 25 March 2014 (UTC)

Migrating cite AV media notes to Module:Citation/CS1/sandbox

I'm migrating {{cite AV media notes}}, more commonly {{cite album notes}}, to Module:Citation/CS1/sandbox. (testcases)

During this migration, I'm wondering if we should make certain changes:

  1. |format= – in most CS1 citations, |format= has a specific definition: the file format of an online resource (pdf, xls, mpeg, etc). Here, in {{cite AV media notes}}, |format= is mapped to |type=. This usage prevents legitimate uses like |format=pdf for an online copy of the media notes in Adobe Acrobat format. I propose to deprecate |format= as an alias of |type=.
  2. |albumtype= – if I understand correctly, the purpose of {{cite AV media notes}} is to make reference to "liner notes from albums, DVDs, CDs and similar audio-visual media" (emphasis mine). It is not the purpose of {{cite AV media notes}} to make reference to the album, DVD, CD, etc that the notes discuss (that is for {{cite AV media}} to do). When |albumtype=single, {{cite AV media notes}} changes the format of the citation title from italic to normal and quotes the title: Title → "Title". This, presumably, because individual song titles are quoted, not italicized. But, {{cite AV media notes}} cites the notes, not the song, so this functionality is inappropriate in this template. For this reason, I propose to deprecate |albumtype= and the functionality of |albumtype=single.
  3. |albumlink= – similar to |albumtype=, |albumlink= implies that this citation refers to the album, DVD, CD, etc that the notes discuss. I think that this is misleading. Editors can wikilink the title or use |titlelink= to create a citation where the title links to a related Wikipedia article. Because |albumlink= is essentially an alias of |titlelink=, I propose to deprecate |albumlink=.
  4. |publisherid= – I propose to deprecate |publisherid= because it is simply a long-winded form of |id=.

Items 1 & 4 above also occur in {{cite DVD-notes}} which, when its time comes, should have similar changes made.

As part of these proposals, if carried, I shall change the documentation and then run an AWB script or three to implement the changes to the source templates.

Opinions? WikiProject Albums, WikiProject Discographies, and WikiProject Songs, have been invited. Who else should be invited into this discussion?

—Trappist the monk (talk) 16:45, 11 March 2014 (UTC)

Looks good to me. As to {{cite DVD-notes}} (355 uses), I recommend we migrate it to {{Cite AV media notes}} (5952 uses). --  Gadget850 talk 17:31, 11 March 2014 (UTC)
It appears that there are only a few significant differences between {{cite AV media notes}} and {{cite DVD-notes}}. In {{cite DVD-notes}}:
  • |director= is an alias of |author=
  • the default value for |title= is Liner notes
  • there is some peculiar markup for format
  • |titleyear= is an alias of |origyear=
So, yeah, I agree. But {{cite DVD-notes}} isn't really the purpose of this thread.
—Trappist the monk (talk) 18:44, 11 March 2014 (UTC)

I agree with all four points made by Trappist the monk. To avoid creating a new batch of error messages, I recommend changing all of the deprecated parameters in existing instances of {{cite AV media notes}} to the new supported parameters, or commenting out parameters that will not have a new equivalent. Is that what is proposed in the note about using AWB? – Jonesey95 (talk) 20:09, 11 March 2014 (UTC)

Before the migration to Module:Citation/CS1/sandbox, an AWB script can change |format= to |type= (#1), change |publisherid= to |id= (#4), and delete |albumtype= and its value (#2). We would need to edit {{cite AV media notes}} before the AWB run so that {{cite AV media notes}} accepts either |titlelink= or |albumlink=. Then, the AWB script can replace |albumlink= with |titlelink= (#3).
Except for attendant documentation, I think that this is all that needs doing.
—Trappist the monk (talk) 21:49, 11 March 2014 (UTC)
AWB script ready; {{cite AV media notes/sandbox}} now accepts either |albumlink= or |titlelink=. (testcases)
—Trappist the monk (talk) 23:21, 11 March 2014 (UTC)

I clicked through a random sample of 30 or so articles that transclude this template to see which projects they are a part of. Based on that, here are some other groups to invite to this discussion: WikiProject Musicians, WikiProject Film, WikiProject Rock music, WikiProject Video games. – Jonesey95 (talk) 20:18, 11 March 2014 (UTC)

Invited.
—Trappist the monk (talk) 20:45, 11 March 2014 (UTC)

There having been no further discussion, I have changed the documentation and the {{citation/core}}-based template according to items 1–4 above. I have made two additional adjustments:

5. |artist= – simply a unique alias of |others= so I have deprecated it in favor of |others=
6. |notestitle= – a unique alias of the more common parameter |chapter= which already has four aliases; deprecated it in favor of |chapter=

I will run my AWB script against Special:WhatLinksHere/Template:Cite_AV_media_notes shortly.

—Trappist the monk (talk) 12:44, 23 March 2014 (UTC)

Trappist the monk, In item 6 above, did you mean to say that you have "deprecated it in favor of |chapter="? – Jonesey95 (talk) 17:21, 23 March 2014 (UTC)
yep.
—Trappist the monk (talk) 17:24, 23 March 2014 (UTC)

Anything sending complex templates to the bin is to be applauded. Thank you! - David Gerard (talk) 17:52, 23 March 2014 (UTC)

I noticed a link to this page from several articles I watchlist. Can somebody explain all of the above in plain English? Why are we doing this? What advantage does it give editors? Module:Citation/CS1/sandbox might as well be gobbledegook. We need citations to be as simple and as easy to use as possible, and stop this culture of coming down like a ton of bricks to newbies who don't understand them. The main change seems to be changing "artist" to "other". Not really an obvious change from my point of view - CDs have "artists", they don't have "others"! Ritchie333 (talk) (cont) 12:50, 24 March 2014 (UTC)

Editors fill out a Citation Style 1 (CS1) template in an edit window. Right now there are two mechanisms that translate the template and its data into the rendered citation that readers see. The two mechanisms are {{citation/core}} and Module:Citation/CS1. The first is old-style Wikimarkup, and the second is the more modern Lua scripting language. The big name CS1 templates ({{cite web}}, {{cite book}}, {{cite journal}}, etc) have already been switched from {{citation/core}} to Module:Citation/CS1. It is now time to switch {{cite AV media notes}}.
This switchover is part of a long-ongoing process to unify all of the CS1 templates from some 21 individual templates, each doing its own formatting and rendering, to a common base where all of the CS1 templates share common rules for formatting, parameter names, etc. Common rules and parameter names do, in fact, make the whole suite of templates easier to use and understand.
The reason for changing |artist= to |others= is because this particular template is about citing the printed notes that accompany a CD, a cassette, an LP, etc – not about citing the accompanying CD, cassette, or LP for which, editors should use {{cite AV media}}. In general, the author of the notes is not the artist who made the music or video; if the artist is the author, then there is |author= to serve that purpose.
Can you show evidence of where I have pursued the culture of coming down like a ton of bricks to newbies who don't understand them?
—Trappist the monk (talk) 14:40, 24 March 2014 (UTC)

The initial AWB run is complete. During that I found one other change that I implemented. Apparently, at some time, |bandname= was a legitimate alias for |artist=. So, I have replaced that parameter where it occurred. Because I started replacing |bandname= sometime after I started the AWB run, I'll rerun my script to see if I missed |bandname= in pages that were changed before I found it.

—Trappist the monk (talk) 14:53, 24 March 2014 (UTC)

I also found some with |director= as an alias for |artist=.

—Trappist the monk (talk) 15:11, 24 March 2014 (UTC)

... and |mbid= which I'm just deleting because in 2009, editors determined that that identifier wasn't appropriate. (Discussion here and here)

—Trappist the monk (talk) 19:55, 24 March 2014 (UTC)

Bold/non-bold volume parameter doc issue, or bug

I encountered an issue with |volume=. It appears that it is displayed bold unless the argument contains non-alphanumeric characters. In addition, if it is not bold a period is used as a separator. Examples: [1] [2] [3] [4] [5] [6] [7] [8] [9]

  1. ^ ln, fn (1 April 1971). "title". journal. 1. 3914: 1–2.
  2. ^ ln, fn (1 April 1971). "title". journal. 1. (nbr. 3914): 1–2.
  3. ^ ln, fn (1 April 1971). "title". journal. 1. VI: 1–2.
  4. ^ ln, fn (1 April 1971). "title". journal. 1. Z VI: 1–2.
  5. ^ ln, fn (1 April 1971). "title". journal. 1. test: 1–2.
  6. ^ ln, fn (1 April 1971). "title". journal. 1. (test): 1–2.
  7. ^ ln, fn (1 April 1971). "title". journal. 1. te(s)t: 1–2.
  8. ^ ln, fn (1 April 1971). "title". journal. 1. te[s]t: 1–2.
  9. ^ ln, fn (1 April 1971). "title". journal. 1. te$st: 1–2.

I did not see the behavior documented anywhere. At a minimum, the documentation should include the conditions under which it is not bold and doesn't use the period. I'm not sure if this is the intended operation, so I have not just changed the docs. — Makyen (talk) 23:05, 20 March 2014 (UTC)

Displays non-bold over 4 characters: Years ago, there was a request to not bold "vol 3" and so the length is checked for 5 or longer, to omit the bolding, but it can be forced by triple tic-marks: volume='''vol 3'''. -Wikid77 20:19, 23 March 2014 (UTC)
Which corrupts the volume metadata by wrapping it in %27%27%27. --  Gadget850 talk 22:57, 23 March 2014 (UTC)
The template documentation pages are up to date.
  • volume: For one publication published in several volumes. Displays after the title and series fields; volume numbers should be entered just as a numeral (e.g. 37). Volume values that are wholly digits, wholly uppercase Roman numerals, or fewer than five characters will appear in bold. Any alphanumeric value of five or more characters will not appear in bold. In rare cases, publications carry both an ongoing volume and a year-related value; if so, provide them both, for example |volume=IV / #10.
--  Gadget850 talk 23:28, 20 March 2014 (UTC)
Bold text is a function of length. If the value assigned to |volume= is greater than four characters long, then Module:Citation/CS1 inserts the separator character (either the default period or the character specified by |separator=) followed by the volume. When four characters or less, CS1 omits the separator character and displays volume in bold font.
—Trappist the monk (talk) 23:53, 20 March 2014 (UTC)
Thank you both. Great; so I was not discriminating enough in trying different test cases 8-).
@Gadget850:The documentation displayed to users is not correct. The text you quoted was not displayed on any of Help:Citation Style 1, Template:Cite web or Template:Cite journal. None of those pages have any mention of the possibility that |volume= will not be displayed bold. Help:Citation Style 1 and Template:Cite journal say that if you want it not to be bold, then include it in the |title=. Template:Cite web has no documentation at all as to the function of |volume=. In fact, on Template:Cite web the text "volume" only exists once and that is in the section on COinS data.
It appears that a large amount of work has gone into creating the framework for the documentation to be easily switched between lua/non-lua. A brief glance indicates that a lot of the work to do so was done by you, Gadget850. Thank you.
After adding |lua=yes to every occurrence of {{csdoc}} in Template:Cite journal/doc, it appears the only thing on which it made a difference was |volume=. Sorry I happened to pick up one the one thing that was off. That still leaves handling both types in Help:Citation Style 1 and some amount of documentation in Template:Cite web.
Floating an idea: Maybe it would be a good idea to have a separate, centralized CS1 template documentation page which is either almost completely transcluded into each of the templates, or each template documentation tells people to go there via a link. That way the documentation in each template concentrates on how it is different from the base, standard template, while not having to restate each piece of the documentation. Having them have to restate each piece, even though each piece is individually transcluded, makes the documentation less easy to maintain than having the basic standard documentation in a single page. — Makyen (talk) 02:35, 21 March 2014 (UTC)
We could add volume to the {{cite web}} documentation, but why would you use volume for a web page? With the Lua updates, most parameters now work on every template, but we only document the parameters that are applicable. And yes, a lot of work needs to be done on documentation. --  Gadget850 talk 08:26, 21 March 2014 (UTC)
Anyone know why the 'series' separator does not show when 'volume' is four characters? --  Gadget850 talk 15:11, 21 March 2014 (UTC)
Because that is how the code in Module:Citation/CS1 is written. It is easy to fix and doing so would make module citation match core citations. Shall I fix it?
Cite book comparison
Wikitext {{cite book|sandbox=yes|series=Series|title=Title|volume=vol}}
Live Title. Series. Vol. vol. {{cite book}}: |volume= has extra text (help); Unknown parameter |sandbox= ignored (help)
Sandbox Title. Series. Vol. vol. {{cite book}}: |volume= has extra text (help); Unknown parameter |sandbox= ignored (help)
—Trappist the monk (talk) 15:16, 21 March 2014 (UTC)
Yep, I figured it was in the code. I was looking for the rationale. And I just checked the old core as well and it did not do it that way, so I think this is a bug that should be fixed. --  Gadget850 talk 16:18, 21 March 2014 (UTC)
I don't know what the rational was, or if there even was a rational. Could have simply been an oversight. Fixed in the sandbox.
—Trappist the monk (talk) 17:08, 21 March 2014 (UTC)

Support making volume display consistently, regardless of content or length. I trust Trappist to make it work right. – Jonesey95 (talk) 17:17, 21 March 2014 (UTC)

Minor history here. All I've done is add the separator character so that it follows whatever the last parameter is before volume. It is still true that if the |volume=value has more than four characters, it will not be in bold font.
Cite book comparison
Wikitext {{cite book|sandbox=yes|series=Series|title=Title|volume=MMXIV}}
Live Title. Series. Vol. MMXIV. {{cite book}}: Unknown parameter |sandbox= ignored (help)
Sandbox Title. Series. Vol. MMXIV. {{cite book}}: Unknown parameter |sandbox= ignored (help)
—Trappist the monk (talk) 18:58, 21 March 2014 (UTC)
Thanks for hunting down that link. I read it, and the embedded link within that section (which goes to Archive 2). I did not see a justification for a four-character limit, which seems too short. I understand that a twenty-character bold volume name might be a bit garish, but six or seven characters of bold seems reasonable. At this point we might need some examples from real articles of longer-than-four-character volume names that are not bold, but should be. – Jonesey95 (talk) 06:01, 22 March 2014 (UTC)
Years ago, there was a request to not bold "vol 3" and so the length is checked for 5 or longer (length of "Vol" +space+digit) to omit the bolding; but it can be forced as bold by triple tic-marks: volume='''vol 3'''. -Wikid77 20:19, 23 March 2014 (UTC)
I've been wondering if the bold / no bold determination should be made on content rather than length. For example: |volume=23 and |volume=MCMLXXXVIII should be bold font but |volume=3rd Crusade should be normal font. So if the value for |volume= contains only digits or uppercase roman numerals then bold; else normal.
These mock-ups demonstrate how this style might look:
ln, fn (1 April 1971). "title". journal. 1. MCMLXXXVIII: 1–2.
ln, fn (1 April 1971). "title". journal. 1. 3914: 1–2.
ln, fn (1 April 1971). "title". journal. 1. 3rd Crusade: 1–2.
—Trappist the monk (talk) 12:14, 22 March 2014 (UTC)
  • Checking volume length was easiest method and insert dot: In cases where a volume number includes letters, such as volume "23a" (or "B-2"), then the 4-character limit has worked well to not bold "vol 4" but instead bold "B2" or "98-c". As mentioned above, the bolding becomes garrish, or glaring, with longer words, and even volume 48, as "XLVIII" could be a quieter "XLVIII" and no one would overlook it as being the volume number.
  • Cite journal:       "Paper 5". My Journal. 8c. May 2013.
  • Cite journal/new: "Paper 5". My Journal. 8c. May 2013.
  • Cite journal/new: "Paper 5". My Journal. Series X. 8c. May 2013.
Only inserting the dot at length 5 had fixed most volume titles, without disturbing journal volumes which should not have a preceding dot. -Wikid77 20:19, 23 March 2014 (UTC)
What? I do not understand what you wrote. And, what was the purpose of this edit? Why should we treat |volume= differently when it follows |series=?
—Trappist the monk (talk) 23:31, 23 March 2014 (UTC)
  • Avoid dot between journal name and volume: This is about the common typesetting convention, in technical journals, to show the volume number bolded, with no separator after a journal name: Journal 67, which has been used in wp:CS1 style for years. However, when "series=" is used, between journal name and volume, then the separator (dot "." or comma) is added by {cite_journal/old}, and hence the module /sandbox has been changed to match that. -Wikid77 (talk) 00:28, 24 March 2014 (UTC)
But why only |series=? What about the other parameters that are rendered between |journal= and |volume=? And, perhaps more importantly, why are |volume= and |issue= separated from |journal=? There is some sense in separating |volume= from |journal= when |series= is set because that implies that |journal= is volume n of the |series=. Why should any other parameter be placed between |journal= and |volume=?
For {{citation}} and {{cite journal}}, if a periodical parameter is set (dictionary, encyclopaedia, encyclopedia, journal, magazine, newspaper, periodical, website, work) then, in this order and if set, these parameters are rendered between the periodical and volume parameters:
format, type, scale, series, language, cartography, edition, publisher, agency
For all other citations, these parameters are rendered between the periodical and volume parameters:
format, type, scale, series, language
—Trappist the monk (talk) 12:15, 24 March 2014 (UTC)

Just a quick thought for discussion, but can we eliminate the boldface completely? It's not used in APA, MLA or Chicago-style citations (the non-WP styles I've had to use the most in college), so I don't see why we would need to retain it. Imzadi 1979 → 01:04, 25 March 2014 (UTC)

I have reverted all changes to this part of Module:Citation/CS1/sandbox while this discussion continues so that the update to the live module can proceed.

—Trappist the monk (talk) 12:10, 25 March 2014 (UTC)

Physics articles with 30+ authors

Citation bot helpfully came along and filled out some references at Neutrino[2]. This has caused some problems with some physics papers with very many authors belonging to collaborations. Originally the first author had et al and the name of the Collaboration

N. Agafonova et al. (OPERA Collaboration) (2010). "Observation of a first ντ candidate event in the OPERA experiment in the CNGS beam". Physics Letters B. 691 (3): 138–145. arXiv:1006.1623. Bibcode:2010PhLB..691..138A. doi:10.1016/j.physletb.2010.06.022.

after citation bot came along it added the first 30 of the 100+ actual authors

N. Agafonova et al. (OPERA Collaboration); Aleksandrov; Altinok; Ambrosio; Anokhina; Aoki; Ariga; Ariga; Autiero; Badertscher; Bagulya; Bendhabi; Bertolin; Besnier; Bick; Boyarkin; Bozza; Brugière; Brugnera; Brunet; Brunetti; Buontempo; Cazes; Chaussard; Chernyavsky; Chiarella; Chon-Sen; Chukanov; Ciesielski; et al. (2010). "Observation of a first ντ candidate event in the OPERA experiment in the CNGS beam". Physics Letters B. 691 (3): 138–145. arXiv:1006.1623. Bibcode:2010PhLB..691..138A. doi:10.1016/j.physletb.2010.06.022.

setting |display-authors=1 looks odd as there are two copies of et al.

N. Agafonova et al. (OPERA Collaboration); et al. (2010). "Observation of a first ντ candidate event in the OPERA experiment in the CNGS beam". Physics Letters B. 691 (3): 138–145. arXiv:1006.1623. Bibcode:2010PhLB..691..138A. doi:10.1016/j.physletb.2010.06.022.

Is there a way of getting this to display OK without having to remove all the co-authors, which I'm reluctant to do as it means deleting data. I'm thinking there may be a case for a |collaboration= parameter or a way of suppressing the et al.--Salix alba (talk): 14:00, 25 March 2014 (UTC)

The only information in an author parameter should be an author name. The reason for this is that whatever text and wiki markup is in an author parameter gets copied into the citation's COinS metadata. So, don't put ''et al.'' (OPERA Collaboration) in an author parameter. The CS1 templates will give you a properly formatted et al. with |displayauthors=n. Consider using |others=OPERA Collaboration:
{{cite journal |author=N. Agafonova |others=OPERA Collaboration |displayauthors=1 |year=2010 |title=Observation of a first ν<sub>τ</sub> candidate event in the OPERA experiment in the CNGS beam |journal=[[Physics Letters B]] |volume=691 |issue=3 |pages=138–145 |arxiv=1006.1623 |bibcode=2010PhLB..691..138A |doi=10.1016/j.physletb.2010.06.022 |last2=Aleksandrov |last3=Altinok }}
→N. Agafonova; Aleksandrov; Altinok (2010). Observation of a first ντ candidate event in the OPERA experiment in the CNGS beam. Vol. 691. OPERA Collaboration. pp. 138–145. arXiv:1006.1623. Bibcode:2010PhLB..691..138A. doi:10.1016/j.physletb.2010.06.022. {{cite book}}: |journal= ignored (help); Unknown parameter |displayauthors= ignored (|display-authors= suggested) (help)
—Trappist the monk (talk) 14:50, 25 March 2014 (UTC)
Yes I've thought of using the |others= but this puts the (OPERA Collaboration) in the wrong place, after the title. If you look at the various places these appear the group needs to bind tightly to the authors. For example arxiv[3] has
"N. Agafonova et al. (OPERA Collaboration) Title"
--Salix alba (talk): 18:18, 25 March 2014 (UTC)
Then I think you're going to be disappointed. CS1 is a general purpose citation tool that satisfies a large number of citation needs. It is not, never has been, and never will be the perfect tool for all applications. (If I knew how to create such a tool, I certainly wouldn't be doing it here for free.) There are going to be citation needs like yours that are outside of the tool's capability.
There is however, an undocumented and unsupported possibility – if you use this, be forewarned that it might one day produce unexpected results. Set all of the |author= parameters as you should normally do; set |others=N. Agafonova; et al. (OPERA Collaboration); set |displayauthors=0:
{{cite book |author=N. Agafonova |others=N. Agafonova; et al. (OPERA Collaboration) |displayauthors=0 |year=2010 |title=Observation of a first ν<sub>τ</sub> candidate event in the OPERA experiment in the CNGS beam |journal=[[Physics Letters B]] |volume=691 |issue=3 |pages=138–145 |arxiv=1006.1623 |bibcode=2010PhLB..691..138A |doi=10.1016/j.physletb.2010.06.022 |last2=Aleksandrov |last3=Altinok }}
→N. Agafonova; Aleksandrov; Altinok (2010). Observation of a first ντ candidate event in the OPERA experiment in the CNGS beam. Vol. 691. N. Agafonova; et al. (OPERA Collaboration). pp. 138–145. arXiv:1006.1623. Bibcode:2010PhLB..691..138A. doi:10.1016/j.physletb.2010.06.022. {{cite book}}: |journal= ignored (help); Unknown parameter |displayauthors= ignored (|display-authors= suggested) (help)
—Trappist the monk (talk) 19:30, 25 March 2014 (UTC)

Update to the live CS1 module week of 2014-03-23

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

Module:Citation/CS1 (diff);
Module:Citation/CS1/Configuration (diff);
Module:Citation/CS1/Whitelist (diff)

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

  1. Add PMC error checking; (discussion)
  2. Fixed a circa year date validation bug; (discussion)
  3. Add url in |authorlink parameter error checking; (discuassion and discussion)
  4. Expand DOI error checking; (discussion)
  5. Fix longstanding bug that broke citation terminal punctuation if the value assigned to |postscript= is multicharacter (like html entities); Moved citation template's default assignments for |separator=, |postscript, and ref=harv from the invoking template into the module; Added support for |postscript=none; (discussion)
  6. Limit acceptable years in dates to current year+1; (discussion)
  7. Expand date validation; all allowable date formats should now be supported; (discussion)
  8. Migrate cite interview; (discussion)
  9. Move date validation code into a separate page Module:Citation/CS1/Date validation;
  10. Extract page numbers from external wikilinks in any of the |page=, |pages=, or |at= parameters for use in COinS; discussion)
  11. Add lccn error detection; (discussion)
  12. Migrate cite AV media notes; (discussion)
  13. Migrate cite DVD notes; (discussion)

to Module:Citation/CS1/Configuration:

  1. PMC error checking;
  2. url in |authorlink parameter error checking;
  3. Move |postscript= and |separator= default initialization into Module:Citation/CS1/sandbox;
  4. Add subject and subject link for cite interview migration;
  5. Add artist, albumlink, albumtype, notestitle, publisherid for cite AV media notes migration;
  6. Add lccn error detection;
  7. Delete albumtype; merge deprecated parameters albumlink, artist, director, notestitle, publisherid, titleyear as aliases of other parameters; remove these parameters after 1 October 2014;

to Module:Citation/CS1/Whitelist:

  1. Add subject and subjectlink for cite interview migration;
  2. Add artist, albumlink, albumtype, notestitle, publisherid for cite AV media notes;
  3. Invalidate albumtype; deprecate artist, albumlink, director, notestitle, publisherid, titleyear; these last to be invalidated after 1 October 2014;

—Trappist the monk (talk) 11:53, 25 March 2014 (UTC)

Corrected item 5 for Module:Citation/CS1 to read: Added support for |postscript=none;

—Trappist the monk (talk) 12:54, 25 March 2014 (UTC)

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

Bots edit-warring on hand-fixed cites

It has taken a while to confirm the bizarre introduction of invalid parameters by Bots, but it has happened in numerous pages, such as dif834 in article:
     • "Premenstrual syndrome (edit | talk | history | protect | delete | links | watch | logs | views)
During that edit, the only "title=" parameter was incorrectly fubarred to be "duplicate_title" and required yet another hand-edit to correct a Bot ruining more pages with such crap. -Wikid77 (talk) 15:43, 30 March 2014 (UTC)

@Wikid77: Have you reported the incorrect edit to the bot owner? GoingBatty (talk) 21:48, 30 March 2014 (UTC)
I reported this bug on Citation Bot's Talk page, along with a suggested cause and a suggestion for how to change the bot's behavior in this case. – Jonesey95 (talk) 00:11, 31 March 2014 (UTC)
The bot is seemingly confused because |url= is missing. -- 79.67.241.242 (talk) 22:14, 31 March 2014 (UTC)

Chapter with book/volume and series

Another leftover problem, postponed last year to speed markup-to-Lua transition, is the formatting of a chapter, with a book and volume, in a book-series.

  • {cite book |last=Doe |title=This Book |series=Series of Books}} → Doe. This Book. Series of Books.
Cite book comparison
Wikitext {{cite book|author=[[Edward N. Trifonov]]|chapter=Making sense of the human genome|location=Albany, New York|pages=69–77|publisher=Adenine Press|series=Human Genome Initiative and DNA Recombination; Proceedings of the Sixth Conversation in the Discipline Biomolecular Stereodynamics|volume=Vol. 1|work=Structure and Methods|year=1990}}
Live Edward N. Trifonov (1990). "Making sense of the human genome". Human Genome Initiative and DNA Recombination; Proceedings of the Sixth Conversation in the Discipline Biomolecular Stereodynamics. Vol. Vol. 1. Albany, New York: Adenine Press. pp. 69–77. {{cite book}}: |volume= has extra text (help); |work= ignored (help); Missing or empty |title= (help)
Sandbox Edward N. Trifonov (1990). "Making sense of the human genome". Human Genome Initiative and DNA Recombination; Proceedings of the Sixth Conversation in the Discipline Biomolecular Stereodynamics. Vol. Vol. 1. Albany, New York: Adenine Press. pp. 69–77. {{cite book}}: |volume= has extra text (help); |work= ignored (help); Missing or empty |title= (help)

Now that we have time to discuss this, I think the obvious format should be quoted "Chapter" followed by italic book+volume (Book, Vol. 1), then followed by italic book-series (Series of Books) after the volume id, not before volume as displayed all last year. Across Wikipedia, many book series are displayed as italicized, which I think is the common format, but I have not discussed series format much before now. To assist transition, if a series name is hard-coded italic, then that could be left as-is while plain series names are italicized by the Lua processing. -Wikid77 23:28, 2 April 2014 (UTC)

Do you have examples of style guides (APA, Chicago, etc.) that provide guidance on how to format chapter/book/series/volume citations? The CS1 does not follow any one style guide, but it is often useful to adopt or adapt an accepted style that an organization has thought through and worked on for many years. – Jonesey95 (talk) 18:05, 3 April 2014 (UTC)

Editors using only 'first', not 'last'.

I have recently stumbled across a couple of editors who have been adding references for years, and who always put the author full name in |first= and either completely omit the |last= parameter or include it but leave it blank. This means the author name doesn't show up in the reference.

Is there a bot that can go fix these? Having said that, many of the references also need other types of clean up at the same time, e.g. here (and still not finished). -- 79.67.241.229 (talk) 08:52, 3 April 2014 (UTC)

I do not think citations with this error are bot-fixable. There is too much variation. I put in a feature request a while ago. – Jonesey95 (talk) 17:26, 3 April 2014 (UTC)
I have added code to Module:Citation/CS1/sandbox to detect when there is a mismatch between |lastn= and |firstn= (or their aliases).
  • Last1, First1; Last2. first3 without last3. {{cite book}}: |first3= missing |last3= (help)CS1 maint: numeric names: authors list (link)
  • Last1, First1; Last2 (eds.). editor-first3 without editor-last3. {{cite book}}: |editor-first3= missing |editor-last3= (help)CS1 maint: numeric names: editors list (link)
In general, the code that assembles the author and editor names lists, searches the template for |lastn=, |firstn=, |lastn+1=, |firstn+1=, |lastn+2=, etc. until |lastn= and |firstn= are both not found. When both are not found it could be that we've got all of the names, or that there is a hole in the list. We can't yet tell the difference so if there is a hole in the list, it will not be detected:
  • Last1, First1; Last3, First3. last3/first3 without last2/first2. {{cite book}}: Missing |author2= (help)CS1 maint: numeric names: authors list (link)
If retained, this error will categorize in Category:CS1 errors: last first mismatch
—Trappist the monk (talk) 12:18, 4 April 2014 (UTC)
That seems very helpful. As I continue fixing references I never cease to be amazed at the very many creative ways people have filled in templates, often completely disregarding the documentation and abandoning common sense. Your new code is also likely to uncover many cases where citation bot has added only last names or added only first names and this is something that it appears to have been doing for years when authors are listed in the (co)author(s) parameter. -- 79.67.241.229 (talk) 12:51, 4 April 2014 (UTC)
Citations with only last names are not invalid because |lastn= and |authorn= are aliases. As far as I know, there is no way for the code to determine if |lastn= or |authorn= is missing a |firstn=. The only case that this code catches is |firstn= without its numerically matching |lastn= or |authorn=.
—Trappist the monk (talk) 12:57, 4 April 2014 (UTC)
Understood this catches "first without last" errors. Several editors as well as citation bot have created many of those. -- 79.67.241.229 (talk) 13:22, 4 April 2014 (UTC)
This looks great. I'll work up some test cases. Does anyone have an idea to make the category name clearer while still keeping it short? Off the top of my head: "CS1 errors: author or editor name mismatch". "CS1 errors: missing author or editor name". This latter category name could eventually be used to include not just the "first name only" case, but also the "hole in the list" case where there is "author1, author2, author4, author5", if that code can be developed. – Jonesey95 (talk) 13:14, 4 April 2014 (UTC)

And a bit of a tweak and:

Cite book comparison
Wikitext {{cite book|author5=Author5|author=Author1|last3=Last3|title=Author 1, 3, & 5 without author 2 & 4}}
Live Author1; Last3; Author5. Author 1, 3, & 5 without author 2 & 4. {{cite book}}: |author= has generic name (help); Missing |author2= (help); Missing |author4= (help)CS1 maint: numeric names: authors list (link)
Sandbox Author1; Last3; Author5. Author 1, 3, & 5 without author 2 & 4. {{cite book}}: |author= has generic name (help); Missing |author2= (help); Missing |author4= (help)CS1 maint: numeric names: authors list (link)

—Trappist the monk (talk) 21:43, 4 April 2014 (UTC)

Examples

Cite book comparison
Wikitext {{cite book|author5=Author5|author=Author1|last3=Last3|title=Author 1, 3, & 5 without author 2 & 4}}
Live Author1; Last3; Author5. Author 1, 3, & 5 without author 2 & 4. {{cite book}}: |author= has generic name (help); Missing |author2= (help); Missing |author4= (help)CS1 maint: numeric names: authors list (link)
Sandbox Author1; Last3; Author5. Author 1, 3, & 5 without author 2 & 4. {{cite book}}: |author= has generic name (help); Missing |author2= (help); Missing |author4= (help)CS1 maint: numeric names: authors list (link)
Cite book comparison
Wikitext {{cite book|first1=First1|first2=First2|last2=Last2|title=First 1, First+Last 2}}
Live Last2, First2. First 1, First+Last 2. {{cite book}}: |first1= missing |last1= (help)CS1 maint: numeric names: authors list (link)
Sandbox Last2, First2. First 1, First+Last 2. {{cite book}}: |first1= missing |last1= (help)CS1 maint: numeric names: authors list (link)
Cite book comparison
Wikitext {{cite book|author5=Author5|first1=First1|first2=First2|last2=Last2|title=First 1, First+Last 2, Author5}}
Live Last2, First2. First 1, First+Last 2, Author5. {{cite book}}: |first1= missing |last1= (help)CS1 maint: numeric names: authors list (link)
Sandbox Last2, First2. First 1, First+Last 2, Author5. {{cite book}}: |first1= missing |last1= (help)CS1 maint: numeric names: authors list (link)
Cite book comparison
Wikitext {{cite book|author5=Author5|first1=First1|first2=First2|last1=Last1|last2=Last2|title=First+Last 1, First+Last 2, Author5 (should produce error but does not?)}}
Live Last1, First1; Last2, First2. First+Last 1, First+Last 2, Author5 (should produce error but does not?).{{cite book}}: CS1 maint: numeric names: authors list (link)
Sandbox Last1, First1; Last2, First2. First+Last 1, First+Last 2, Author5 (should produce error but does not?).{{cite book}}: CS1 maint: numeric names: authors list (link)
Cite book comparison
Wikitext {{cite book|first2=First2|first3=First3|last3=Last3|title=First 2, First+Last 3}}
Live Last3, First3. First 2, First+Last 3. {{cite book}}: |first2= missing |last2= (help); Missing |author2= (help)CS1 maint: numeric names: authors list (link)
Sandbox Last3, First3. First 2, First+Last 3. {{cite book}}: |first2= missing |last2= (help); Missing |author2= (help)CS1 maint: numeric names: authors list (link)
Cite book comparison
Wikitext {{cite book|first2=First2|first3=First3|last2=Last2|last3=Last3|title=First+Last 2, First+Last 3}}
Live Last2, First2; Last3, First3. First+Last 2, First+Last 3. {{cite book}}: Missing |author1= (help)CS1 maint: numeric names: authors list (link)
Sandbox Last2, First2; Last3, First3. First+Last 2, First+Last 3. {{cite book}}: Missing |author1= (help)CS1 maint: numeric names: authors list (link)
Cite book comparison
Wikitext {{cite book|coauthors=Coauthors|first2=First2|first3=First3|last2=Last2|last3=Last3|no-tracking=true|title=First+Last 2, First+Last 3, Coauthors}}
Live Last2, First2; Last3, First3. First+Last 2, First+Last 3, Coauthors. {{cite book}}: Missing |author1= (help); Unknown parameter |coauthors= ignored (|author= suggested) (help)CS1 maint: numeric names: authors list (link)
Sandbox Last2, First2; Last3, First3. First+Last 2, First+Last 3, Coauthors. {{cite book}}: Missing |author1= (help); Unknown parameter |coauthors= ignored (|author= suggested) (help)CS1 maint: numeric names: authors list (link)
Cite book comparison
Wikitext {{cite book|first1=First1|first3=First3|first4=First4|last1=Last1|last3=Last3|last4=Last4|title=First+Last 1, First+Last 3, First+Last 4 (out of order)}}
Live Last1, First1; Last3, First3; Last4, First4. First+Last 1, First+Last 3, First+Last 4 (out of order). {{cite book}}: Missing |author2= (help)CS1 maint: numeric names: authors list (link)
Sandbox Last1, First1; Last3, First3; Last4, First4. First+Last 1, First+Last 3, First+Last 4 (out of order). {{cite book}}: Missing |author2= (help)CS1 maint: numeric names: authors list (link)
Cite book comparison
Wikitext {{cite book|first1=First1|first3=First3|first4=First4|last3=Last3|title=First1, First+Last 3, First4 (out of order)}}
Live Last3, First3. First1, First+Last 3, First4 (out of order). {{cite book}}: |first1= missing |last1= (help); |first4= missing |last4= (help); Missing |author2= (help)CS1 maint: numeric names: authors list (link)
Sandbox Last3, First3. First1, First+Last 3, First4 (out of order). {{cite book}}: |first1= missing |last1= (help); |first4= missing |last4= (help); Missing |author2= (help)CS1 maint: numeric names: authors list (link)
Cite book comparison
Wikitext {{cite book|coauthors=Coauthors|first1=First1|first3=First3|first4=First4|last3=Last3|no-tracking=true|title=First1, First+Last 3, First4 (out of order) with Coauthors}}
Live Last3, First3. First1, First+Last 3, First4 (out of order) with Coauthors. {{cite book}}: |first1= missing |last1= (help); |first4= missing |last4= (help); Missing |author2= (help); Unknown parameter |coauthors= ignored (|author= suggested) (help)CS1 maint: numeric names: authors list (link)
Sandbox Last3, First3. First1, First+Last 3, First4 (out of order) with Coauthors. {{cite book}}: |first1= missing |last1= (help); |first4= missing |last4= (help); Missing |author2= (help); Unknown parameter |coauthors= ignored (|author= suggested) (help)CS1 maint: numeric names: authors list (link)

The above examples were added by Jonesey95. – Jonesey95 (talk) 15:33, 5 April 2014 (UTC)

With regard to the "should produce error but does not?" example: The code searches through the template's parameters for author parameters (and their aliasese) in numerical order starting with 1 (|author=, |author1=, |last= |last1=, and the other aliases). The code stops searching when it doesn't find |authorn= and it doesn't find |authorn+1=. So, in the example, the code found |last1= and |last2=, but didn't find |last3= and didn't find |last4= so it concluded that there are no more authors.
—Trappist the monk (talk) 15:57, 5 April 2014 (UTC)

Date validation: Winter YYYY–YY

New test for the special case: Winter YYYY–YY.

  • Pass: Sequential years. Winter 2004–05.
  • Fail: Same year. Winter 2004–04. {{cite book}}: Check date values in: |date= (help)
  • Fail: Not sequential years. Winter 2004–07. {{cite book}}: Check date values in: |date= (help)
  • Fail: Not sequential years. Winter 2004–03. {{cite book}}: Check date values in: |date= (help)

—Trappist the monk (talk) 10:28, 6 April 2014 (UTC)

Nice catch. I saw one of those in the last few days while I was fixing another category of error, and I forgot to copy the citation to my sandbox to troubleshoot it. – Jonesey95 (talk) 15:41, 6 April 2014 (UTC)

Should quote chapter when title and journal

I think there is still an old 3-way bug for "chapter=" when using both title/journal, which I neglected to fix when first developing the Module:Citation/CS1 last year. As I interpret the issue, a "chapter=" should always be quoted and then force "title=" into italics. However, note the following in {cite_journal}:

Cite journal comparison
Wikitext {{cite journal|EditorGiven1=J.S.|EditorSurname1=Hollingsworth|chapter=Trilobite Biostratigraphy and Sequence Stratigraphy of the Upper Dyeran (traditional Laurentian "Lower" Cambrian) in the southern Great Basin, USA|first=Mark|journal=Museum of Northern Arizona Bulletin|last=Webster|number=67|title=Cambrian Stratigraphy and Paleontology of Northern Arizona and Southern Nevada|year=2011}}
Live Webster, Mark (2011). "Cambrian Stratigraphy and Paleontology of Northern Arizona and Southern Nevada". Museum of Northern Arizona Bulletin (67). {{cite journal}}: |chapter= ignored (help); Unknown parameter |EditorGiven1= ignored (help); Unknown parameter |EditorSurname1= ignored (help)
Sandbox Webster, Mark (2011). "Cambrian Stratigraphy and Paleontology of Northern Arizona and Southern Nevada". Museum of Northern Arizona Bulletin (67). {{cite journal}}: |chapter= ignored (help); Unknown parameter |EditorGiven1= ignored (help); Unknown parameter |EditorSurname1= ignored (help)

In the above example, "Trilobite Biostratigraphy" is just one chapter in the larger topic (book), Cambrian Stratigraphy and Paleontology..., which would cover all life forms of the Cambrian Period. Perhaps always quote a chapter title? I was too tired last year (still am) to test all major combinations with title+journal/work, and I neglected to fix that. It is a minor problem, but some PhD users might expect it fixed in the next Lua release. -Wikid77 (talk) 20:38, 9 March 2014 (UTC)

  • Problem is setting Chapter italic when Periodical+Title set: The problem can be fixed, in 2 places, by not quoting the Title text and not italicizing Chapter name, as done here:
        if is_set(Periodical) and is_set(Title) then
            Chapter = wrap( 'italic-title', Chapter ); --DO NOT DO THIS!!
            TransChapter = wrap( 'trans-italic-title', TransChapter );
        else
            Chapter = kern_quotes(Chapter);
            Chapter = wrap( 'quoted-title', Chapter );
            TransChapter = wrap( 'trans-quoted-title', TransChapter );
        end
Instead, always quote the Chapter name, by: Chapter = wrap( 'quoted-title', Chapter). Plus fix "if is_set(Periodical) then" to also check Chapter, as:
        if is_set(Periodical) and not is_set(Chapter) then
            Title = kern_quotes (Title);
            Title = wrap( 'quoted-title', Title );
            TransTitle = wrap( 'trans-quoted-title', TransTitle );
        elseif inArray(config.CitationClass, ...)
By adding the restriction "and not is_set(Chapter)" then the logic will naturally decide to italicize the book's Title as well as the "journal=" Periodical. Hence, that fixes the problem, without altering other issues about the quoted/italic titles. -Wikid77 (talk) 23:55, 10 March 2014 (UTC)
Update: I have noticed several articles with similar use of 3 parameters about chapters, book/magazine titles, and collections or series. Hence, this issue should be fixed in the current Lua /sandbox version. -Wikid77 18:00, 8 April 2014 (UTC)

Accesswalls

Proposal: Replace |subscription= and |registration= with a new |access=.

Rationale: There are at least five, probably more, types of access restriction, and more may develop in the future.

Syntax:

  • |access=sub (or |access=subscription) = subscription (paid registration) required
  • |access=reg (or |access=registration) = free registration required
  • |access=fee = per-access or per-item fee required
  • |access=abstract = free abstract, but fee required for access to complete content
  • |access=audience = access restricted to defined (e.g. academic or professional institution) audience

This will also obviate any need to have code trying to determine which existing parameter supercedes the other, and other potential future complications.  — SMcCandlish ☺ ☏ ¢ ⚞(Ʌⱷ҅̆⚲͜ⱷ^)≼  14:55, 24 March 2014 (UTC)

I rather like this idea. What I don't like is the parameter name: |access= is too close to |accessdate=. Perhaps |permission=? I have bulleted your syntax.
What is |access=subscription?
—Trappist the monk (talk) 15:08, 24 March 2014 (UTC)
I get what you mean about |accessdate=, but |permission= is longwinded. {{pra|access|subscription}} was a typo for {{para|access|subscription}}. All of them require some form of registration, so perhaps |register=.  — SMcCandlish ☺ ☏ ¢ ⚞(Ʌⱷ҅̆⚲͜ⱷ^)≼  16:28, 24 March 2014 (UTC)
  • I fear that this further complicates the edit window, and the likely input errors when people don't know what too fill in. That's why binary yes/no is good. While these differences exist, I'd like to understand on a practical level what you feel the benefits to the project of this fractioning of the type of access. -- Ohc ¡digame! 15:16, 24 March 2014 (UTC)
  • I'm not sure if the complexity is worth the value to readers and editors. One problem is this sort of thing tends to change fairly rapidly, compared to the frequency with which reference lists are maintained. There are also some problem with the details of the proposal. A particular entry might be available at no additional fee to those affiliated with a particular institution, a paid subscription might be available, and the item might be available for one-time access. Another problem that an item with "access restricted to defined (e.g. academic or professional institution) audience" is not published and so shouldn't be cited in Wikipedia. Jc3s5h (talk) 15:40, 24 March 2014 (UTC)
  • My concern is that it's already fragmented into a code mess for paid and unpaid accesswalls, with the further complication that some forms of paywall are not subscription-based, but one-time purchases. An alternative idea to what I first proposed is to merge the two existing options into one simplified parameter, and not distinguish at all between the paid types of accesswall: Perhaps a |register= or |wall=, with one value paid and opposite value free, with any other value (e.g. y) defaulting to "paid".  — SMcCandlish ☺ ☏ ¢ ⚞(Ʌⱷ҅̆⚲͜ⱷ^)≼  16:32, 24 March 2014 (UTC)

Revised proposal: Perhaps a |register= or |wall=, with one value paid and opposite value free, with any other value (e.g. y) defaulting to "paid". The problem with the current code that it assumes that paywalls are subscription based when this is often not true.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  21:02, 13 April 2014 (UTC)

Unhiding hidden error messages

Right now, there are seven error message that are hidden from editors who have not chosen to make all error messages visible. These are

hidden CS1 error messages
error message category number of pages in category
|accessdate= requires |url= Category:Pages using citations with accessdate and no URL 0
Check date values in: |param1=, |param2=, ... Category:CS1 errors: dates 245
Cite uses deprecated parameters Category:Pages containing cite templates with deprecated parameters‎ 0
|displayauthors= suggested Category:Pages using citations with old-style implicit et al. 0
|displayeditors= suggested Category:Pages using citations with old-style implicit et al. 0
|format= requires |url= Category:Pages using citations with format and no URL 0
Missing or empty |url= Category:Pages using web citations with no URL 0

Any reason why at least some of these shouldn't be unhidden at the next Module:Citation/CS1 update?

—Trappist the monk (talk) 17:17, 5 April 2014 (UTC)

My two cents: If I recall correctly, in the discussion that resulted in these errors being hidden, it was agreed that they would be hidden in a particular category until the bot-fixable errors had been fixed. Neither Bot nor AWB work has been applied to the "accessdate", "displayeditors", "format", or "missing url" categories. Please correct me if I am wrong. We may decide as a group that one or more of these categories is not fixable by bots (I'm looking at you, "missing url").
The "date" and "deprecated parameters" categories have been traversed by bots to fix some of the problems therein, but they both need more work by bots. Those bots are either returning from RFC-induced hiatus soon (BattyBot Task 25, are you out there?) or awaiting BRFA approval (Monkbot's various tasks). Once those bots make a couple of passes through those two categories, we should expose the remaining error messages.
The "displayauthors" category has been traversed by Citation Bot, which has fixed as many errors as it can. The category is down from about 10,000 entries to under 500. I think that error should be displayed.
The "displayeditors" category is awaiting an update to Citation Bot's code, which has been requested via a bug report. – Jonesey95 (talk) 22:14, 5 April 2014 (UTC)
I believe many of the "cite web with missing URL" entries are likely to be references where a dx.doi.org URL has been bot replaced by a |doi= parameter and the template was not changed to the more appropriate "cite journal" version, or whatever, at the same time. Likewise for many of the "format requires URL" errors. I might be wrong though.

Where a bot removes |url= it should also remove other parameters that can only be present if |url= is present. -- 79.67.241.229 (talk) 23:11, 5 April 2014 (UTC)

Cite web or accessdate without URL

Currently, using the cite web template requires a url or an error message is issued to those who have the messages turned on. Likewise a URL is expected whenever the accessdate parameter is present. But I came across an edit where an editor had added information from a source behind a paywall. I might face the same problem; I have access to some paywall sources through my library, but the access is explained by library personnel as clicking on a link on the library home page, then giving the password, and then searching for the source. If I give the URL from my address bar at the time I'm viewing the source, and then try that URL from a different computer, I get a page asking for a userid and password, but no one at the library seems to know the userid. So it would be rather useless to provide the URL.

It seems to me we should provide some advice about this situation. If the paywall operator is reliable and we viewed an exact copy of a paper publication, I suppose we could just give the information about the paper publication that we viewed online, and not mention that we viewed it online. But if the source is an electronic-source, subject to silent revision, we should provide an access date. What, then, do we use as a URL? The homepage of the paywall operator?

Courtesy also comes into play. If the paywall operator has in some way given support to the writing of the article, for example, by giving accounts to selected Wikipedia editors, or to another charity, it might be appropriate to acknowledge in some way that the information was accessed through the paywall. Jc3s5h (talk) 17:47, 5 April 2014 (UTC)

I believe this is why we have |subscription=yes. I could be misunderstanding you or just plain wrong, though.
I think it makes sense to provide the URL. Using {{cite web}} without a URL at all doesn't make sense. If it's a web-based source, it should have a URL. If your research librarian has access to the source, someone else's research librarian may have that same access. A reader who is desperate to locate that source can show the URL and other citation content to a savvy librarian and ask for help.
If another editor can provide a more open URL for the same source, that editor can do so, which will benefit readers.
Long-winded TL;DR part of this answer: In any event, these categories are like some of the other CS1 error categories, in that we have (or had) suppositions about the proportion of errors that were of one type or another. The steps in determining how to deal with the category, in my experience, are (1) do a bunch of edits and make a mental checklist of the sorts of errors you find and how to fix them, (2) if possible, develop scripts or bots to make common fixes, (3) run through the whole category and fix the straightforward problems using scripts or hand-editing, (4) examine the remaining citations to determine if the module code needs to be changed, to ask for a consensus-based way to fix the remaining errors, (5) modify documentation to help editors make fewer errors, and (6) recruit ReferenceBot to notify editors who create new entries in the category. – Jonesey95 (talk) 00:44, 6 April 2014 (UTC)
The parameter subscription=yes is fine if the url will bring a scriber to the source. But if the url won't bring a subscriber to the source, then the url is useless. Jc3s5h (talk) 02:37, 6 April 2014 (UTC)
Is there a "permanent URL" link at the place where the source is? - Purplewowies (talk) 03:51, 6 April 2014 (UTC)
The paywall operator is Gale; I took a closer look at the URL in the address bar while viewing the text of the sources. I discovered what the userid of my libary is, I also found that the library's userid is embedded in the URL. There are differences in the URL when the source is revisited, so there are no permantent URLs. Jc3s5h (talk) 13:20, 6 April 2014 (UTC)
  • Some paywalls allow partial viewing to verify intro: There are currently cites using some paywall urls which will display part of the linked webpage, to at least verify the intro of the article matches the cite, and in some cases, the partial intro section contained the text needed to verify the sourced text. So, as with the general rules, "less is more" and we should remove any preconceived restrictions about paywall access, as with users who purposely leave out some author first-names perhaps to simplify listing extra authors as just "last3=" and "last4=" etc. We need to avoid further "instruction creep" by omitting unusual rules which have also cluttered the template documentation with more wp:rulespam. -Wikid77 (talk) 18:22, 8 April 2014 (UTC)

Date v. Year on drop down cite book template in edit window toolbar

I see from discussions above that "date" and "year" have been discussed. At some point, the standard "year" was dropped from the Cite Book template and replaced with "date". Ergo, when one uses the drop down template on the edit window toolbar, "date" is the only option available. This creates citation error issues with functions such as Shortened footnotes that only work correctly with years. After using the template, the user then has to manually change the word "date" to "year" for that to work. A big pain in the behind if an editor is creating an article with a hundred or so citations. And not every editor has enough experience to know it needs to be changed. If they don't manually correct it, the errors remain in referencing until such a time as another editor happens to run AWB, or just stumbles across it and manually corrects it. Or not. Can we please include "year" as a standard "fill in the blank" on the cite book template?— Maile (talk) 13:19, 8 April 2014 (UTC)

That isn't how it is supposed to work. {{cite book}} is handled by Module:Citation/CS1. In that module, the year portion of a CITEREF anchor is extracted from either |date= or |year=, when both are present, the year portion of the CITEREF anchor comes from |year=. If the value in |date= is invalid, then the year is not added to CITEREF.
Can you give me an example of where this is failing?
—Trappist the monk (talk) 13:40, 8 April 2014 (UTC)
I understand you want examples. Why was "year" removed from the templates? Was it causing a conflict? Mindful, that I am specifically talking about the cites used in conjunction with templates for SFN, Harvrefs, etc.
Please refer to Help:Shortened_footnotes#Date. The in-text cite should include only the year. The full citation may include the year only or the full date. Most citation templates will extract the year from a full date to form the anchor. If both a date and a year are included, then the date is displayed, but the anchor is formed from the year. Regardless of what that says, the cite templates do not pull the year from a full date with shortened footnotes.
Even before "year" was removed, if I tried to use shortened footnotes with only "date", it essentially told me the SFN is not pointing to anything in the bibliography. I cannot give you a specific example right now. And you might need to install User:Ucucha/HarvErrors to see the error messages. But even without that installed on your .js, if you are looking at a reference section with shortened footnotes template, when you click on one of them, they are supposed to jump to the cite in the bibliography section. If they don't, it's an error. Whether it's supposed to or not, not having "year" will trigger an error. SFN and Harvrefs have "year", and if the cites don't have "year", SFN and Harvrefs don't know what to look for and point to nothing. I have run across this innumerable times. — Maile (talk) 14:13, 8 April 2014 (UTC)

My experience has been the opposite. Using something like |date=2001 or |date=3 May 2002 within cite templates has worked fine for me in conjunction with {{sfn}} (use only the year within the sfn template). That's why we're hoping for examples, so that if there is a subtle bug, we can fix it.

I have the HarvErrors script installed, so if you point me to an article where this is not working, I'll take a look at it.

Here's an example[1] of a shortened footnote[2] that uses the year from a date.[3]

References

  1. ^ Brown 2004.
  2. ^ Xavier 2006, p. 43.
  3. ^ Smith 2001, pp. 60–80.

Sources

  • Brown, Philip (2004). Title. {{cite book}}: Invalid |ref=harv (help)
  • Smith, William (2 May 2001). Title. {{cite book}}: Invalid |ref=harv (help)
  • Xavier, John (June 2006). Title. {{cite book}}: Invalid |ref=harv (help)

These three footnotes all work perfectly for me. – Jonesey95 (talk) 14:29, 8 April 2014 (UTC)

Interesting. Next time I run across this, I'll post the example here. In the meantime, no one answered my question of why "year" was removed from the templates. — Maile (talk) 14:35, 8 April 2014 (UTC)
|year= has not been removed from any of the CS1 templates. It is still a valid and active parameter.
—Trappist the monk (talk) 14:39, 8 April 2014 (UTC)
Do you use the edit window Toolbar that has a drop down for the cite template? Year disappeared from cite book (or Book citation) template when accessed from that drop down. Where "Year" used to be, it now says "Date". "Show extra fields" does not have "Year". Cite web has "Year". Neither cite news nor cite journal has "Year", however I never used "Year" with those, so maybe they never had it. — Maile (talk) 17:35, 8 April 2014 (UTC)

Maile,in the "Preferences" window that can be accessed by clicking "Preferences" at the top of the page, in the editing tab, there are two relevant check boxes, "Show edit toolbar (requires JavaScript)" and "Enable enhanced editing toolbar". Which of these do you have checked? ???? — Preceding unsigned comment added by Jc3s5h (talk • contribs)

I have them both checked. But the one I'm referring to is RefToolbar/2.0. The "cite" selection in the upper right is what hides or displays the template drop down on the left. And in response to IP below, my concern is not the layout of anything except the disappearance of "year" on the cite book selection. That's a fairly recent change. I would say within the last few weeks. — Maile (talk) 18:07, 8 April 2014 (UTC)
The layout of those form fields is terrible, still contains deprecated stuff like coauthors and has absolutely no clarity on when to use last/first and when to use author. Most of the forms have little or no support for multiple authors. A number of essential fields are also hidden away behind the "show extra fields" button. -- 79.67.241.252 (talk) 17:48, 8 April 2014 (UTC)

Thanks, everyone, for the detailed detective work. It looks like the proper venue for continuation of this discussion is Wikipedia_talk:RefToolbar/2.0, since the toolbar, not the cite templates themselves, is presenting a limited set of parameters to editors.

Again, if anyone sees a citation using |date= that does not properly link to an sfn or harv template, feel free to post a link to an article or a sandbox test case here. – Jonesey95 (talk) 22:37, 8 April 2014 (UTC)

I don't really see a need to fracture the discussion. |year= was removed from the toolbar because it is supposedly redundant to |date=. Is it not? Mr.Z-man 23:39, 8 April 2014 (UTC)
I believe |year= is surplus to requirements as I explained at the other conversation.
—Trappist the monk (talk) 00:55, 9 April 2014 (UTC)
I temporarily turned on "Show edit toolbar (requires JavaScript)" and "Enable enhanced editing toolbar". I found that the toolbar provided a mechanism to insert free-form footnotes. It also provided a way to insert citation template footnotes. It did not provide a mechanism to insert a reference list entry ready-to-go with short footnotes or Harvard citations. Before the toolbar citation would be usable, the editor would have to remove <ref> and </ref> and add |ref=harv. Perhaps the non-working cases that user:Maile66 complained about were a result of the editor not correctly modifying the output of the toolbar. Jc3s5h (talk) 13:30, 9 April 2014 (UTC)

So that people know: AWB currently changes parameter |date= to |year= in all citation templates when the value of the parameter is only a year as part of the General Fixes. This means that thousands of articles have been changed to using |year= instead of |date=. If this is not what CS1 desires, the general fixes need to get changed. — Makyen (talk) 02:25, 11 April 2014 (UTC)

Proper use of parameter?

Is this how the |website= or |work= parameter was envisaged to work? If not, what can be done about it? -- Ohc ¡digame! 02:33, 9 April 2014 (UTC)

I don't think so. Thanks for fixing it. The documentation for |website= in {{cite web}} and for |work= in Help:Citation Style 1 says nothing about urls in this parameter. I don't think that it would be too hard to add error checking for urls in these parameters as we've done for urls in |authorlink=.
—Trappist the monk (talk) 12:35, 9 April 2014 (UTC)
It's easy enough to build in a rule to strip the url down to domain name for |work= and |publisher=, but I fear an avalanche of false positives if I include "website" in the regex. -- Ohc ¡digame! 06:34, 10 April 2014 (UTC)
The documentation states "title of website" and I think that is pretty clear. --  Gadget850 talk 12:39, 10 April 2014 (UTC)

It appears that external link icons will be removed in the next update. The PDF icon is set locally by a rule in MediaWiki:Common.css and there is discussion on removing it. See MediaWiki talk:Common.css#External links icons removed. I bring it up here, as many editors believe the icons are added by the templates. --  Gadget850 talk 12:43, 10 April 2014 (UTC)

Discussion of |accessdate= in another location

There is a discussion regarding |accesdate= at Help_talk:CS1_errors#Accessdate.

—Trappist the monk (talk) 11:01, 13 April 2014 (UTC)

Exact use for place/location?

I am currently having a small dispute with Sitush (talk · contribs) over whither the |location= / |place= field in {{cite news}} is meant to show the physical publication location of the newspaper (Sitush) or the dateline (my position). Sitush has cited Template:Cite news#Publisher as a source, but the description is ambiguous. I feel that Sitush's interpretation is meant more for {{cite book}}. Can someone settle this?--Auric talk 16:52, 13 April 2014 (UTC)

Consistency. If it were as you suggest then "location" for a book would be, for example, the house (cafe, in the case of J. K. Rowling!) where the author wrote the book but in fact it is always the location of the publisher. Location can always be ascertained for place of publication of newspaper stories, defaulting to the first-named if there are several, but the place of submission is often not given. - Sitush (talk) 17:03, 13 April 2014 (UTC)
The place of submission is usually given in the dateline.--Auric talk 17:08, 13 April 2014 (UTC)
I'd dispute that, too. More often than not, it is not given at all. - Sitush (talk) 17:26, 13 April 2014 (UTC)
Hence "usually".--Auric talk 17:41, 13 April 2014 (UTC)
No, "usually" means that more often than not it is in the dateline; I'm saying the opposite. - Sitush (talk) 17:47, 13 April 2014 (UTC)
We agree then. --Auric talk 18:02, 13 April 2014 (UTC)
I give up. You seem to be being deliberately obtuse now, sorry. - Sitush (talk) 18:12, 13 April 2014 (UTC)
No, I said that "The place of submission is usually given in the dateline", using usually to indicate that sometimes it is not. You replied, saying "More often than not, it is not given at all.", which means the same thing. Hence, we agreed.--Auric talk 18:24, 13 April 2014 (UTC)
(edit conflict) Traditionally, the location of a newspaper is given when it is not contain in the name of the newspaper. This is to aid a reader in finding a copy of that specific newspaper in library archives. The dateline for an article is practically useless for this purpose because it will vary from article to article within the same paper
To take an example from my hometown area, The Daily News is a newspaper published in Iron Mountain, Michigan, here in the US. There is also The Daily News that is published in Bowling Green, Kentucky, and The Daily News from Galveston, Texas. If I were to cite an article from the Iron Mountain paper that had a dateline of either Bowling Green or Galveston, readers would be confused as to which publication is the source of the cited article. What if the dateline listed was instead "Marquette, Michigan", which has no paper called The Daily News (the paper there is The Mining Journal)?
I hope this helps. Imzadi 1979 → 17:10, 13 April 2014 (UTC)
And Help:Citation_Style_1#Work_and_publisher.
—Trappist the monk (talk) 17:14, 13 April 2014 (UTC)
(edit conflict)Now I'm even more confused. As I understand it, the dateline is the location from where the article is submitted to be published in a newspaper. It has nothing to do with the location of the newspaper it is published in. Many newspapers use stringers for this purpose. --Auric talk 17:19, 13 April 2014 (UTC)
You've got the basic concept of a dateline correct, but in terms of citing an article, that location is not helpful for a reader to find a source. If I told you that the dateline location for an article is "Marquette, Michigan" for an event of national importance, and the newspaper is called The Daily News, would you look for the article in The Daily News published in Iron Mountain, Bowling Green, or Galveston? It could even be the Daily News from New York, which doesn't include the The in its name.
Just like for a book, the location given in a citation is the place of publication. If you're citing something like The New York Times, however, the location can be omitted because it is contained in the name of the newspaper. Imzadi 1979 → 17:45, 13 April 2014 (UTC)
(edit conflict)Actually, as I now understand it, the dateline is a holdover from the years of print-only newspapers, used to indicate that a story was created at or near the location of the event and was thus more accurate. The lack of a dateline would indicate that it was created at the newspaper offices. A reach-around is the use of news agencies and stringers. --Auric talk 17:58, 13 April 2014 (UTC)
I'm starting to think that maybe a |dateline= field could be added to prevent confusion.--Auric talk 18:27, 13 April 2014 (UTC)
We already have a way to handle both: |publication-place= vs. |location=. Compare:
  • Pepin, John (April 12, 2004). "Frost Causes Gas Leaks". The Mining Journal. Marquette, MI. p. A1.
  • Pepin, John (April 12, 2004). Written at Ishpeming, MI. "Frost Causes Gas Leaks". The Mining Journal. Marquette, MI. p. A1.
Adding both properly indicates the dateline location of "Ishpeming, MI" while still disambiguating the newspaper to "Marquette, MI". Imzadi 1979 → 18:37, 13 April 2014 (UTC)

Getting this discussion back to the question at hand, I pulled my copies of the APA and MLA style guides plus The Chicago Manual of Style.

  • APA: the 6th ed. is silent on including locations for periodicals.
  • MLA: "If the city of publication is not included in the name of a locally published newspaper, add the city in square brackets, not italicized, after the name: 'Star Ledger [Newark].' For nationally published newspapers (e.g. Wall Street Journal, Chronicle of Higher Education), you need not add the city of publication." (7th ed., §5.4.5, p. 141)
  • CMOS: "A city name, even if not part of the name of an American newspaper, should be added, italicized along with the official title. The name (usually abbreviated) of the state, or in the case of Canada, province may be added in parentheses if needed." It then gives a list of names with "but Oregonian (Portland, OR)" and then "For such well-known national papers as the Wall Street Journal or the Christian Science Monitor, no city name is added." (16th ed, §14.210, pp. 741–2)
  • AP Stylebook: "Capitalize the in a newspaper's name if that is the way the publication prefers to be known. ... Where location is needed but is not part of the official name, use parentheses: The Huntsville (Ala.) Times. (33rd ed., p. 140)

Our CS1 templates separate the name and location of a newspaper like the MLA style or the last example from CMOS. Both style guides ignore the dateline location because it won't help a reader find the source; datelines are specific to the article, they vary from article to article within the same newspaper, and are not going to help distinguish between two papers of the same name. Imzadi 1979 → 18:37, 13 April 2014 (UTC)

Ahhh, now I begin to understand. Thanks for clearing that up. The dateline is probably for the benefit of the newspaper then, not the reader, to help distinguish between articles with the same name. --Auric talk 18:59, 13 April 2014 (UTC)
Not really. "A dateline should tell the reader that the AP obtained the basic information for the story in the datelined city" is how the Associated Press describes it (AP Stylebook, 33rd ed., p. 57). The dateline is only going to appear inside a paper once you find the article to give the reader information about the article, but if you're going off a citation, you'll need to find the right paper called The Daily News first. Imzadi 1979 → 19:19, 13 April 2014 (UTC)
Okay, I see. Thanks for the clarification.--Auric talk 19:31, 13 April 2014 (UTC)

Work parameter (Template:Cite news)

I'm sure I'm not the only one here that has this problem. It seems that most of the people using this template do not understand the difference between the 'publisher' parameter and the 'work' parameter. The result is that many templates are filled out incorrectly, with the 'publisher' parameter filled instead of the more appropriate 'work'. Is there any way we could clarify this, perhaps by renaming the 'work' parameter to something more obvious? It is annoying to have to fix templates that have filled out incorrectly merely because of the vagaries of the parameters. RGloucester — ☎ 17:50, 13 April 2014 (UTC)

The aliases for |work= are |newspaper= or |magazine=. The documentation clearly says that |publisher= is for the company that publishes something and that |work= is for the name of the name of the published work. I don't know why people will get that the publisher is a company in the case of a book, but get confused on newspapers. Maybe they forget that an article is published in the Daily News and not published by the Daily News. I also find the same confusions with television networks like CBS (the publisher) and individual programs like 60 Minutes (the published "work" of the network). With the alternate parameter names already in place, I think the only way forward is to educate people and just fix their errors. Imzadi 1979 → 18:48, 13 April 2014 (UTC)
Yes. There's really no excuse for not acting like one cannot tell the difference between Apple Records and The Magical Mystery Tour. The only template code suggestion that might help is to add a |publishingco= parameter as an equivalent of |publisher= and change the documentation to stop mentioning the latter.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  20:48, 13 April 2014 (UTC)
I'd support that change. The parameter would be longer, but at least it would make it absolutely clear that 'publisher' is not the same thing as the 'work' it was published in. RGloucester — ☎ 13:59, 14 April 2014 (UTC)
To be clear, I also support such a change, as the nominator-of-sorts. This template already uses long-winded parameter names, so it's not a big deal. I'd like it if it also supported |pubr= for those of us with borderline carpal tunnel syndrome, but whatever. I know we can't keep adding duplicate parameters indefinitely.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  09:17, 16 April 2014 (UTC)

Need help fixing unsupported parameters

As the Bots continue to mangle major articles by inserting invalid parameters, we still need more people to help fix a few more pages, each day, to fix "DUPLICATE_" or "unused_data=" or other invalid parameter names. See category:

Remember, it is possible to navigate the category by URL question-suffix "?from=Ra" to display pages beginning at letters "Ra" or such. Try to scan through the list to fix major pages first (or semi-major, with 100+ pageviews per day); I just fixed page "Pluto" again, as major pages scarred with glaring red-error messages give the appearance that the "keepers of the 'pedia" are unable to correct major errors in major pages. Many invalid parameters date back over 1-3 years, before the wp:CS1 Lua-based cites were installed to show cite messages. Any help, even edit a few pages per day, will help reduce the backlog of 3,400 scarred pages, growing larger every day. -Wikid77 16:03, 30 March, 11:18, 2 April 2014 (UTC)

If these improper edits are still happening, why are the bots not blocked? Why is it not the responsibility of the bot owners to fix all damage before the bots are unblocked? Jc3s5h (talk) 16:21, 30 March 2014 (UTC)
I think Bot errors are rare. -Wikid77 11:18, 2 April 2014 (UTC)
@Wikid77: Could you please give some examples of bots that "continue to mangle major articles" where you (or someone else) has reported the error to the bot owner and the bot owner has not made the appropriate changes? Thanks! GoingBatty (talk) 21:51, 30 March 2014 (UTC)

Coming here after seeing discussion on Jimbo's talk page: I'm happy to help gnoming away, but it would be great if there could be a priority list of the high hit-rate articles within the 3315 in the category.

And a question: why do some of the articles in Category:Pages with citations using unsupported parameters seem to be sorted by their DEFAULTSORT, and others not? See, under "Pa": "Richard Phipson" followed by "Phoenix Jones": both have DEFAULTSORTS, so Jones should be appearing under "J". At the end of "M" we have Málaga though it has a DEFAULTSORT of "Malaga", while Öreryd is sorted correctly by its DEFAULTSORT of "Oreryd" What's happening? (My instinct is to look at this category for articles which need other work such as adding a DEFAULTSORT or checking whether "Foo (whatnot)" is correctly linked from "Foo", to do this while sorting out the citation problem, but I'm puzzled by the inconsistent treatment of defaultsorts.) PamD 14:20, 1 April 2014 (UTC)

Just scan the category sections ("?from=Ta") for obvious major articles; otherwise, fixing 5 pages is equivalent to a page read 100x per day. -Wikid77 11:18, 2 April 2014 (UTC)
I'll commit to fixing 30 to 50 of these per day until the category is done. Who else is in? If we can do 200 per day, we can clear out the category in a couple of weeks. – Jonesey95 (talk) 15:04, 1 April 2014 (UTC)
I'm fixing 10-20 per day, while copy-editing. -Wikid77 11:18, 2 April 2014 (UTC)
@PamD: Articles are placed in these error categories via Template:Broken ref. The coding in that template currently sets the category sort key to the page name, thus overiding any DEFAULTSORT in the article. These categories contain a mixture of people and non-people categories, so maybe a sort by surname wouldn't work too well. -- John of Reading (talk) 16:16, 1 April 2014 (UTC)
@John of Reading: but the weird thing is that they're sorting inconsistently, some by the Defaultsort and others by the page title. Your note doesn't explain how Öreryd files in the Os and Richard Phipson in the Ps. PamD 17:46, 1 April 2014 (UTC)
Tracked in Phabricator
Task T40435
@PamD: Yes, my attempted answer was rubbish! The difference is that some of the entries are generated by citations inside <ref>...</ref> tags and some are not. bugzilla:38435 says that the DEFAULTSORT gets ignored when the category is generated via a reference and the DEFULTSORT statement is below the reflist. There's an example at User:John of Reading/Sandbox. In one of my test categories, the page is sorted under "Z", matching the DEFAULTSORT, and in the other it is sorted under "J", ignoring the DEFAULTSORT. -- John of Reading (talk) 18:35, 1 April 2014 (UTC)

I don't know of a way to provide a list of high-hit-rate articles in a given category, but I can provide a catscan report listing Featured Articles that have CS1 errors. There are currently 2,687 such articles. There are 26 Featured Articles in the "unsupported parameter" category. – Jonesey95 (talk) 20:40, 1 April 2014 (UTC)

|coauthor= is deprecated but still supported so that's not how a page gets added to Category:Pages with citations using unsupported parameters.
—Trappist the monk (talk) 10:19, 2 April 2014 (UTC)
Somehow I didn't finish my thought. There are three bots now in WP:BRFA and a fourth on the way that will, I hope make a dent in the 99,000ish pages in Category:Pages containing cite templates with deprecated parameters.
—Trappist the monk (talk) 10:46, 2 April 2014 (UTC)
After sampling a few pages, 'unused_data' and 'DUPLICATE_xxx' added by Citation bot is probably the most common. Then we have a number of totally oddball parameters such as 'isbn2', 'opening', 'book', 'ref name', 'digitalised', 'issues', 'paragraph', 'producer', 'newsen', 'refname', 'nbv accessdate' and 'rev'; two references on one page use 'date-of-publication', 'title-of-website' and 'sponsor'. --  Gadget850 talk 10:37, 2 April 2014 (UTC)
Agree, quite a lot originating from the citation bot (that is, existing error that the bot marked in a particular way) and a mixture of other stuff. Please consider expanding Wikipedia:AutoWikiBrowser/Rename template parameters where appropriate, then we can more easily keep this category clean in future. Rjwilmsi 11:30, 2 April 2014 (UTC)
I have fixed a few hundred of these articles, and Trappist the monk has cleaned up most of the low-hanging fruit (a few thousand articles) using an AWB script. Most of what is left are the "oddballs" referred to above. I believe that Citation Bot no longer adds "unused_data" to citations, but it is currently adding "DUPLICATE_XXX" (legitimately pointing out duplicate parameters that need attention from a human editor) and "eprint". The latter is an unsupported parameter; a bug report has been submitted.
The category should be empty in 2-3 weeks, after which we will be able to watch for patterns in what is newly added to the category, notify editors using ReferenceBot, and take other steps to reduce the future growth of the category. Keep up the good work, everygnome! – Jonesey95 (talk) 18:16, 2 April 2014 (UTC)
 Done As of 13:08, 15 April 2014 (UTC) this category was cleared of all pages which I believe should be changed. I went back through it again at about 03:03–04:27, 16 April 2014 (UTC) and cleaned the additional 5 which had been added to the category.
I just ran through it again (03:09, 19 April 2014 (UTC)). There were 18 additional pages added. The errors on these 18 pages included:
6x Mistyped parameter names
1x "=" in parameter value instead of after parameter.
6x URL bad/no quoting of |
1x URL bad/no quoting of [
4x misunderstanding parameters (e.g. splitting access date into multiple parameters (year/month/day))
1x wrong separator between words within parameter name. "access date"
1x title bad quoting of |
1x title/chapter/book confusion
2x excess text
15–20x (4 pages, probably 15-20 parameter names were wrong) parameter names in foreign language (Spanish)
1x multiple uses of same parameter name
10x incorrect capitalization of parameter names
There are 168 pages remaining in the category. However, none of them appear to be ones which should be changed. All appear to be archives, testcases, etc. I am using the following regular expression for the name criteria to filter them out:
[Aa]rchive|Articles for|Mediation Cabal|requests for arbi|Filled requests|Deletion review|Deletion review|Categories for discussion|Featured article candidates/Featured log|Files for deletion|Requests for arbitration|Suspected sock puppets|Wikipedia Signpost|Autofixing cites|Bots/Requests for approval|Centralized discussion/Citation discussion|Featured article candidates/Navenby|testcases|regression tests|sandbox
I fixed 2,000, or so, pages. A significant number of the specific substitutions I determined are appropriate to put as standard template parameter name replacements within AWB for most citation templates. This will include all of the non-English parameter names for which I determined direct substitutions. Determination was done by a combination of translation and investigating the actual parameter names used in templates on various language Wikipedias. These determinations are far from comprehensive, but included all such which I encountered while making changes. I will try to work up a list of them and get them in as default substitutions for AWB. Doing so will, hopefully, help keep the quantity of pages in this category low. If anyone else has specific substitutions which are always correct (i.e. do not require human verification), they can be added to the set that AWB routinely fixes.
However, the large majority of the rules (regular expressions) I used do not fit with that method of correction, or are inappropriate for unattended substitution without additional logic to check for erroneous corrections. Examples of such are regular expressions to replace within parameter names many/most 2 erroneous characters errors, any adjacent character swap, replacement of "|" characters in URLs and titles when the following text was obviously not a parameter, etc. Most of these could be included in a bot with a bit of logic for determining that the correction is valid. — Makyen (talk) 04:16, 19 April 2014 (UTC)

No more red-error messages

Tracked in Phabricator
Task T7984
Tracked in Phabricator
Task T23798
Tracked in Phabricator
Task T56906
  • No more red-error messages: After years of showing various types of the red-error messages to all users via Template:Convert or the wp:CS1 cite templates, the evidence is conclusive that such messages do not cause readers to fix pages when left for months/years (or viewed over 300,000 times, as page "Vladimir Putin" in 5-13 March 2014), and even several experienced editors have edited many pages leaving red-error messages still visible for the year. There was even an RfC to re-hide such red-error messages in the wp:CS1 cites as being a distraction for the readership. Therefore: After years of trying to get people to fix pages by showing numerous, clarified, red-error messages with help-page links of how-to explanations, the whole tactic of showing red-error messages has been shown to be a total failure of communication to get problems fixed in pages. In fact, numerous editors have fixed many cite errors faster by following the tracking categories and searching for "unknown parameter" or such, rather than viewing pages until a red message appears somewhere. Hence, the red-error messages can capture a reader's attention, but they do not cause readers to fix the errors which should be handled by Bots or by autofixing instead, to clear errors in recent updates and archives and talk-pages, all with the same rapid autofixing. -Wikid77 (talk) 18:53, 8 April 2014, 05:49, 10 April 2014 (UTC)
If I see a red error message as I preview an edit, especially if I have just caused the error message to appear, I usually fix it before saving the page. Error messages should be shown when previewing a page otherwise the amount of errors may rapidly increase. On one page, I recently fixed a number of invalid |authorlink= parameters. However, as an experiment to see how long it would take, I left six references needing the document title to be filled in. It took 68 edits from 45 different users (and around 60 000 pageviews) before someone fixed four of the titles. The other two remain broken. -- 79.67.241.252 (talk) 19:19, 8 April 2014 (UTC)
The supposition that editors are unwilling to fix red error messages because people do not do so over a large number of edits to a page is flawed. The issue is not that having red error messages is a failure. It is that there is a failure to display such errors at the time when they can and would be fixed. Such errors are not shown anytime only a section of the page is edited and previewed. In order to see those errors you have to either be editing the entire page, specifically looking for the error, or have set up and enabled Anomie's Ajax Preview which shows references while previewing a section. Further, even when just reading a page in order to see the errors one has to go looking for them.
How many readers/editors scroll through the sometimes huge list of references just to read them? I know I do not. If I am reading a page and am interested in a reference, I just move the mouse to hover over that specific reference link. A popup window then shows that reference and that reference only. I then click within that popup to go to the reference. While reading, rarely do I actually click on the reference tag to visit the entire reference list.
There is a discussion at VPP at which Wikid77 has raised this issue within the context of a larger question. There are multiple tracked bugs, some of which will certainly be fixed which will at least partially, address this issue. Getting the word out about the existence of Anomie's Ajax Preview to editors will probably also help. — Makyen (talk) 22:12, 8 April 2014 (UTC)
Just for the record, I believe that red error messages sometimes cause editors to fix article references. I am presenting just as much conclusive evidence as was presented by the original poster. – Jonesey95 (talk) 22:24, 8 April 2014 (UTC)
Many of those cases could be autofixed, with no need to edit the page, and no need to issue a red-error message. Where the cite data is undecipherable, then a simple note "[fix cite]" plus a link to a severe-error cite category would be sufficient. By autofixing the cites, then the severe cases can be isolated to separate categories, to enable faster fixing by cite experts. However, I do see not a problem with a lead zero "0" in a date "07 May" and 50,000 such dates could be autofixed to show "7 May" without a red message. -Wikid77 07:27, 9 April 2014 (UTC)
As above, the date errors are a straw man. Date error messages are not displayed to readers unless they have specifically changed their preferences to show those errors. I'm trying to engage in discussions about this opportunity under an assumption of good faith, and I have provided actual data about articles above. Unqualified assertions that "Many of those cases could be autofixed..." and "evidence is conclusive..." without data are not helpful in advancing this discussion. I am willing to be persuaded, but so far I have seen nothing to persuade me that efforts in the autofix direction are better than the current system of fixing with bots and human editors. – Jonesey95 (talk) 13:10, 9 April 2014 (UTC)
  • Evidence of failure of red-errors to fix pages: As evidence, note how page "Theta" had shown "Unknown parameter 'book=' ignored " for 5 months (since rev. Nov 2013), but the cite error was left during 151,000 pageviews. Today, I fixed page "Modern Healthcare" which had a flood of 7 red-errors (from years ago) viewed over 4,800 pageviews (see old: rev-4839), where "_accessdate=" was appended after 7 agency names. Other pages also exemplify the problem: a page can be viewed thousands of times, while updated many times, but a red-error message does not cause readers to fix the error, so don't show it. -Wikid77 05:49/15:05, 10 April 2014 (UTC)
  • Autofixing author, title, url or extra data: Remember, while the red-error messages have been left in pages for months/years during 2013-2014, the current autofixing can handle many previously garbled cite parameters; compare:
  • {{cite web |tittel=Title |work=Essays |lats=Doe |first=John |date 3 May 2011 |pages=3--4|ACME Print|web=http://z |edit1-lasst=Smith |editor1-first=Jane |paragraph=6 |lociation=London}}
autofix: {{User:Wikid77/cite web/auto|tittel=Title |work=Essays |lats=Doe |firstr=John |date 3 May 2011 |pages=3--4|ACME Print|web=http://z |edit1-lasst=Smith |editor1-first=Jane |paragraph=6 |lociation=London}}
current: Essays. pp. 3--4. {{cite web}}: |editor1-first= missing |editor1-last= (help); |first= missing |last= (help); Missing or empty |title= (help); Missing or empty |url= (help); Text "ACME Print" ignored (help); Text "date 3 May 2011" ignored (help)
Note the extensive autofixing of title (from "tittel="), author ("lats="), url ("web"), date ("date 3 May") and editor ("edit1-lasst"), plus showing "paragraph: 6" to allow a reader to check the cite to verify the sourced text against paragraph 6. -Wikid77 (talk) 07:05, 10 April 2014 (UTC)
Not this again. You've raised autofixing at the village pump as noted above, at Template talk:Location map, at Wikipedia:Autofixing cites and its talk page , at User talk:Jimbo Wales‎ twice and here once before. Meanwhile your template has been thoroughly discussed and userfied without redirect. Nowhere has there been any support for your solution. It's gone well beyond the bounds of forum shopping already. Please give it a rest.--JohnBlackburnewordsdeeds 21:39, 10 April 2014 (UTC)
Why would multiple "fix" notes, and mangled punctuation, as in "pp. 3–4. [fix date][fix cite]; ACME Print; [fix title];" that hardly anyone will ever notice and fix, be preferable to a red note that attracts the attention of gnomes? There may not be many of us, but its pretty uncommon for me to edit an article (that even bothers to cite sources <sigh>) and not check some citations for cleanup. I have to agree the suggestions everywhere Wikid77 raises this issue that the "smarts" involved in his code are better suited to a bot or AWB script or something that people can use to go fix things. "Fixing" them by making guesses as to the intent and then adding more "fix me" notes is throwing the baby out with the bathwater. Or trying to drown more babies in the same bath, or something.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  20:54, 13 April 2014 (UTC)
Because autofixing provides several advantages: The autofixing is preferable to a red note because it removes that distracting note while auto-correcting the cite to show author, title, url-link, date (etc.), with no need for a gnome or other user to alter the cite for years or decades, and as such, the small note "[fix cite]" is indeed a minor reminder that the cite parameters have been adjusted. In many cases, the issue of "making guesses" is a no-brainer, and the autofixed correction is obvious due to typical misspellings of parameters, but the great benefit with that is the detection of mangled phrase parameters, as a separate category, to help focus human effort on fixing garbled cites which require expertise, while hundreds of trivial typos are autofixed and do not need human intervention to cite the intended source document. In cases where human editing is rejected, such as in archived AfD or Arbcom discussions, then the autofixed cites will link to suggested sources without altering the archived page history. As for "throwing the baby out with the bathwater" (no), instead the autofixing is more like automated draining of a bathtub by pulling the plug, with indoor plumbing, rather than hauling a washtub to be emptied. In general, autofixing is a type of automated technology, to make citing sources easier, with instant correction of typos. -Wikid77 (talk) 21:50, 19 April 2014 (UTC)
No it doesn't provide several advantages, as has been explained to you many times. But we've had the discussion and consensus was to userfy, and so to not use autofixing. Since then you've been pushing this almost continuously and got little interest and even less support. Please drop it.--JohnBlackburnewordsdeeds 22:13, 19 April 2014 (UTC)

circa

At present, the citation templates does not seem to recognise "circa" and abbreviations thereof, and throws these up as cs1 date errors. What does the template recognise, if at all? Or what can we do about these? -- Ohc ¡digame! 03:21, 17 April 2014 (UTC)

"c. " should work (letter c, full stop, space), like this:
Cite book comparison
Wikitext {{cite book|author=Author|date=c. 1894|publisher=Publisher|title=Title}}
Live Author (c. 1894). Title. Publisher. {{cite book}}: |author= has generic name (help)
Sandbox Author (c. 1894). Title. Publisher. {{cite book}}: |author= has generic name (help)
This usage conforms with WP:DATEOTHER, which is part of the MOS. – Jonesey95 (talk) 04:07, 17 April 2014 (UTC)
In that case, per ISO/WCAG accessibility guidelines, the HTML should be <abbr title="circa">c.</abbr>_ (my underscore represents your space). The template {{abbr}} may be used to achieve this. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:44, 17 April 2014 (UTC)
Which would then corrupt the &rft.date with the {{abbr}} HTML. --  Gadget850 talk 09:49, 17 April 2014 (UTC)
And it exposes the strip markers and causes a date error.
Markup Renders as 
{{cite book |title=Title |date={{abbr|c.|circa}} 1900}}

Title. c. 1900. {{cite book}}: Check date values in: |date= (help); Unknown parameter |template doc demo= ignored (|no-tracking= suggested) (help)

'"`UNIQ--templatestyles-0000025A-QINU`"'<cite class="citation book cs1">''Title''. <abbr title="circa">c.</abbr> 1900.</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%3AHelp+talk%3ACitation+Style+1%2FArchive+4" 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>}}

--  Gadget850 talk 09:53, 17 April 2014 (UTC)
And it looks like any inclusion of #tag or a template that includes it causes the strip marker issue. I'm not knowledgeable enough about Lua to be able to break this down and properly characterize it. --  Gadget850 talk 12:56, 17 April 2014 (UTC)
What about the template {{circa}} which is what WP:DATEOTHER suggests as the way of displaying approximate dates? Nthep (talk) 13:06, 17 April 2014 (UTC)

The shortcut above, WP:DATEOTHER, is incorrect; it is associated with the level 4 heading "Ranges" heading in MOSNUM (not MOS). The correct heading is "Uncertain, incomplete, or approximate dates". Jc3s5h (talk) 13:12, 17 April 2014 (UTC)

Same thing:
Markup Renders as 
{{cite book |title=Title |date={{circa}} 1900}}

Title. c. 1900. {{cite book}}: Check date values in: |date= (help); Unknown parameter |template doc demo= ignored (|no-tracking= suggested) (help)

'"`UNIQ--templatestyles-0000025F-QINU`"'<cite class="citation book cs1">''Title''. <abbr title="circa">c.</abbr> 1900.</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%3AHelp+talk%3ACitation+Style+1%2FArchive+4" 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>}}

If we are going to use this, we need to include it in the CS1 module. --  Gadget850 talk 13:18, 17 April 2014 (UTC)
Presumably, we could then use Lua to strip the markup and substitute the word "circa" in the COinS data? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:48, 18 April 2014 (UTC)
Not a Lua programmer, but the simplest way would be to inject the date field (ca. 1900) into COinS as is and parse the "c." into the abbr markup. --  Gadget850 talk 18:42, 18 April 2014 (UTC)
Not sure where you mean to do that parsing; but why not put the word in full in COinS? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:12, 18 April 2014 (UTC)

Unless it is required by WP:DATESNO, which it doesn't seem to be, is this functionality necessary?

—Trappist the monk (talk) 19:54, 18 April 2014 (UTC)

It may not be part of WP:DATESNO, but marking up abbreviations as above is part of WCAG. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:12, 18 April 2014 (UTC)
In fact the first line of the WP:DATESNO section on uncertain dates mentions {{Circa}}; I've posted a suggestion on the talk page about strengthening that recommendation. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:18, 18 April 2014 (UTC)

date errors

What should I do with cases like "|date=undated"? Outright removal would probably be simplest. But correct? -- Ohc ¡digame! 04:46, 2 April 2014 (UTC)

|date=n.d. is accepted by the CS1 module. Like this:
Author (n.d.). Title. {{cite book}}: |author= has generic name (help)
That's what I would recommend. Another choice would be to comment it out so that anyone editing the article would know not to look for a date in vain. I would not remove it entirely, lest you send someone on a wild goose chase that results in reinsertion of "undated". – Jonesey95 (talk) 05:05, 2 April 2014 (UTC)
Looks like |date=n.d. needs to be added to the documentation.
Given that we explicitly recommend:
  • |author=<!--Staff writer(s); no by-line.-->
  • |publisher=<!--Unspecified by source.-->
Having a comment in addition might not be a bad idea. It could save someone some time checking. — Makyen (talk) 08:22, 2 April 2014 (UTC)
When changing from "undated" to "n.d." be sure to check for Harvard citations or short footnotes that need to change to match. This would apply whether the Harvard citations or short footnotes were done with templates ({{harv}} or {{sfn}} or manually. Jc3s5h (talk) 11:24, 2 April 2014 (UTC)
Can the full stop after the brackets be suppressed when {n.d.) is used as (n.d.). looks a bit silly. Nthep (talk) 22:09, 19 April 2014 (UTC)
We have the same situation regarding editions, formats/types:
  • Doe, John (n.d.). Book of Examples (2nd ed.). Anytown: Example Press.{{cite book}}: CS1 maint: year (link)
  • Doe, John (2013). A Study of Examples (Thesis). Collegetown: University.
  • "Michigan" (Map). The Road Atlas. Rand McNally. 2013. p. 50.
I don't see this as a problem since we terminate sections of the citation with a period, regardless if the content within parentheses contains a period or not already. Imzadi 1979 → 00:06, 20 April 2014 (UTC)
Alternately, use nd instead.
—Trappist the monk (talk) 00:24, 20 April 2014 (UTC)
One of the style manuals that inspired the citation templates was APA style, which does call for "(n.d.)." Jc3s5h (talk) 00:59, 20 April 2014 (UTC)
nd produces a CS1 error. Regardless of the APA style guide, to my British eyes, a period after parentheses which terminate with a period looks out dated and overly formal. Nthep (talk) 18:22, 20 April 2014 (UTC)
{{cite book |title=Title |date=nd}}
→Title. nd.
No error. Example please?
—Trappist the monk (talk) 18:38, 20 April 2014 (UTC)
No error there but why has it not parenthesised the (non)date? Nthep (talk) 19:15, 20 April 2014 (UTC)
{{cite book |title=Title |author=Author |date=nd}}
→Author (nd). Title. {{cite book}}: |author= has generic name (help)
Date in parentheses when following |author=. Still no error. So where are you seeing errors? Can you show an example where nd produces a CS1 error?
—Trappist the monk (talk) 19:28, 20 April 2014 (UTC)
Can't find it again, probably a preview error on my part. Thanks for the clarification. Nthep (talk) 21:06, 20 April 2014 (UTC)

Need to accept free-form dates

At this point, we can begin to allow free-form dates, such as "undated" or "late October 2011" and change the Lua software to bypass date-format checking when the date seems to be free-form. Recall that the Lua-based cites were purposely kept limited, from last year, in an effort to speed the markup-to-Lua transition from {Citation/core} within a 6-week period, leaving rare cite forks (and complex parameters) for later, which is now. The expansion of such new features should be tested in a separate version (not the main /sandbox version). -Wikid77 (talk) 22:35, 2 April 2014 (UTC)

I don't quite recall the reasoning. Can you provide a link to the discussion?
Since there seems to be no hope of distinguishing free-form dates from gibberish, the only way I can imagine your proposal working is to recognize a date in an improper form and issue a warning that it should be changed to an acceptable date; any entry not recognized as a date in an improper form would be assumed to be a free-form date and allowed. For example, "July 4th, 1776" could be recognized as a date in improper form. Jc3s5h (talk) 23:14, 2 April 2014 (UTC)
The use of free-form dates is a common practice, and could be detected by some trigger words such as "late" or "early" or "before" (etc.), or perhaps by words which do not match misspelled month names. In the above case, "4th" beginning with digit "4" could be excluded as a non-alphabetic word, but would match a Lua regex pattern for digit-plus-th as pattern "%dth". -Wikid77 23:28, 2 April 2014 (UTC)
Please provide data to back up your assertions about the commonness of the use of free-form dates. At this writing, there are 108,000 articles in Category:CS1 errors: dates. What fraction of those use free-form dates?
I think it makes more sense, since the date error messages are not displayed to readers unless they have specifically changed their preferences to show those errors, to leave the system as is until the category can be scrubbed by bots and bot-like editors, followed by human editors, who can find and fix the vast majority of cases that are actual date errors. In my experience, the vast majority of errors in the category are (a) valid date ranges that need an en dash or other punctuation fixes (many of these are bot-fixable), (b) newly-acceptable date ranges that need a null edit to remove the error category, (c) dates that are bot-fixable and just waiting on closure of an RFC about month abbreviations, and (d) dates of the form XX/XX/YY or XX/XX/YYYY.
I just clicked on a random sample of 50 articles in the category and found the following: 5 bot-fixable date ranges, 8 valid ranges needing a null edit, 18 fixable by BattyBot task 25, 8 of the form XX/XX/YY(YY) or XX.XX.YY(YY), 10 other dates needing human attention, and 1 free-form date ("YYYY-present"). So that's one free-form date out of an admittedly small sample of 50 articles, 31 bot-fixable or already-valid dates, and 18 dates needing human attention. If that scales, we're looking at about 2,000 free-form dates. Let's have this discussion again when the category is in the 10,000-article range.
A null edit of the whole category would cut the article count substantially, I believe. I don't know of any easy way to accomplish that. – Jonesey95 (talk) 23:54, 2 April 2014 (UTC)

Allow uppercase parameter names

After this whole past year of the Lua-based cites, I think it is time to allow uppercase names for several major parameters, including "Title=" & "Date=" & "Publisher=" & "Accessdate=" (etc.). The successful use of capital "Author=" has shown the feature to be workable, as well as perhaps leading some people to imagine capital "Title=" should work as well. The data seems to show 10% of spelling errors are capital-letter parameters, although the percentage might be higher due to the obvious quick fix for a even newcomer to use lowercase when an error message is seen. To simplify implementation, perhaps start with just 10 major parameters where the capital letter would be allowed.

Although the unknown parameters have been fixed among the 10,000 articles with "unsupported" parameters, the prior usage can be estimated from checking the user-space pages, as with a search:
• Google Search: "Unknown parameter" "date ignored" site:wiki.riteme.site
In several prior cases, the problem has been capital "Date=" as an irksome glitch which prevented the date from appearing in a formatted cite. Anyway, because the long-term use of capital "Author=" has not caused major problems, then allowing a capital letter in 10 other major parameters should work well. -Wikid77 18:13, 15 April 2014 (UTC)

This kind of tolerance of mixed case doesn't sound crazy to me. Clearly I'm in a devil's advocate mood today. Does anyone know the rationale behind allowing only lower-case letters in most parameters? Is there some programming-related reason that (some) parameters need to be case-sensitive? Why should the parser care whether someone writes |author=, |Author=, |AUTHOR=, or even, perversely, |AuthoR=? I'm just asking. If there's a reason, it would be helpful to understand it. – Jonesey95 (talk) 19:00, 15 April 2014 (UTC)
See below: "#No significant overhead for major capital names". -Wikid77 (talk) 17:18, 19 April 2014 (UTC)
In the old template, we would have had to case change each and every parameter. This would have added more overhead to an already resource intensive template. I had a fix for the double periods issue, but it added way to much overhead.
We have any number of bots working citation templates that we must consider before making a change of this magnitude. And lower case parameters are the defacto standard. --  Gadget850 talk 19:39, 15 April 2014 (UTC)
Having bots do it (very easy for them to spot, quick to hopefully do) seems much more sensible than a programming fix, which will marginally make the code more complex. Only marginally but added up across every reference in every article there's bound to be some impact. All for fixing a few dozen/hundred/thousand errors. If bots do it once fixed it's fixed, and can stay fixed with periodic bot patrols.--JohnBlackburnewordsdeeds 20:05, 15 April 2014 (UTC)
Right, this would add a terrible amount of overhead to the template, and would make some pages fail (there's a limit to how many templates and parser functions one page can call). MediaWiki really needs some way to set "this wiki's parameters are case-insensitive by default" and "in this code, flip the case-sensitive bit until we say stop".  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  09:01, 16 April 2014 (UTC)
Browsing through the search above, the first ten search pages are user and talk pages. The few articles I sampled don't have this error, as they were fixed but still show in Google's search cache. I don't see a huge problem. --  Gadget850 talk 10:10, 16 April 2014 (UTC)
That's because gnomes have diligently fixed all of those articles over the past few months (the error category was emptied yesterday!) and User/Talk/etc. pages are not included in the CS1 error category. – Jonesey95 (talk) 13:07, 16 April 2014 (UTC)
I wanted to see what it would be like to edit a page with all-uppercase parameter names, so I temporarily created this. Click the edit button at the top of the left hand column. To me it is not at all pleasant and quite a lot like being shouted at. -- 79.67.241.227 (talk) 13:11, 16 April 2014 (UTC)
I'm not convinced that this is an issue. For a time, there were a large number of {{cite music release notes}} templates in article space with capitalized parameters. Because that template is handled by {{citation/core}}, the capitalized parameters weren't displayed. I've fixed that with an AWB script and I've fixed thousands of capitalization errors in Category:Pages with citations using unsupported parameters. That category is essentially empty now.
I would rather see more consistency than less. It's my experience that for the vast majority of templates, parameter names are case sensitive and that the default state is lowercase. Without there being a significant clamor for case insensitive parameter handling, we should stick with lowercase.
Along the lines of consistency, I think, and have said before that we should standardize on parameter name separator characters and style. We have parameters that don't use a separator; parameters that use underscores, hyphens, spaces; parameters that are capitalized, lowercase, uppercase, and CamelCase. Where separators are used, the hyphen is by far the most commonly used. While we could allow spaces in place of visible-character separators, I think that it is helpful to readers to visibly connect the various parts of a parameter name so that it looks like a whole unit and not separate words.
Similarly, where parameter names are run-together collections of whole or partial words, there should be a length limit before requiring the inclusion of separator characters. CamelCase names may be easier to parse, but out of all of the parameters currently in use, only a few have that form. As words get longer they get harder to parse, and it's harder to find typographical errors because these 'words' don't appear in everyday writing so your browser's spell checker declares most parameter names to be misspellings even when they are spelled correctly. Perhaps the limit should be 10 characters so: |accessdate= but not |ignoreisbnerror=; |trans-title= or |transtitle= but not |trans_title=; parameter names that naturally occur in English are not subject to this requirement: |encyclopedia=.
Because it is common practice to capitalize initialisms, ISBN, DOI, etc., these types of parameter names (the identifiers) are, and should continue to be, allowed. Documentation, however, should not use the capitalized versions.
So, I propose that we:
  1. deprecate underscores and spaces as parameter name separators in favor of hyphens
  2. deprecate unseparated parameter names of 10 or more characters in favor of hyphen separated names
  3. deprecate CamelCase parameter names in favor of lowercase; hyphenate as required above
  4. deprecate Capitalized parameter names in favor of lowercase; hyphenate as required above
To implement this in Module:Citation/CS1 is for the most part trivial. The cleanup afterward will require a bot or AWB script to troll through Category:Pages containing cite templates with deprecated parameters to repair individual citations. I am prepared to do that task.
—Trappist the monk (talk) 13:38, 16 April 2014 (UTC)
As someone that has often typed |trans-title= without thinking, I support your proposal for parameter names to include hyphens, not underscores, not spaces, not CamelCaps and not capitalised. When inconsistency is allowed, it becomes harder to spot inconsistent things that are real errors. Of course, bots that edit references should be able to read aNyCase and allow for space or underscore where hyphen should be and then re-emit the corrected reference parameter names as all lower case with hyphens. It would be nice to see a requirement for space to the left of each pipe as a bare minimum so that word-wrap also has a fighting chance of working properly. -- 79.67.241.227 (talk) 16:51, 16 April 2014 (UTC)
I strongly support unifying the way we concatenate words in parameter names. When a user is typing a parameter name they should not have to think "Now is this the one that is joined with a '_', or is it nothing, nothing with camelCase, or a normal one with '-'"?
We should decide on one method and make it such that from the user's point of view that method always works. It should work without consideration for how long the parameter is, or any other consideration. Given that there are a large number of hyphen separated names, I would second the suggestion that we choose that method. If we want to also have aliases for shorter parameter names where no separator is used, that is reasonable. An example would be that |access-date= could also be used as |accessdate=. For shorter parameter names it may be easier to type without the hyphen. However, the user that does not have detailed familiarity with the template should not have to know that words in certain parameter are joined in a particular way. One way of joining words should always work.
Making this change would reduce confusion on the part of users and result in a template that is a bit more user-friendly. — Makyen (talk) 06:39, 21 April 2014 (UTC)

No significant overhead for major capital names

After years of allowing both lowercase and uppercase id parameter names (such "isbn=" and "ISBN="), there has been no significant overhead incurred by allowing just one alias for a dozen parameters. The major problem with {{Citation/core}} had been allowing 'surname1' up to 'surname9' or 'given9' as 18 extra aliases which were almost never used, compared to use of capital 'Date=' or 'Publisher'. Also, each various camel-case or mixed spelling (such as 'AccessDate' or 'AutHOR') would be cumbersome to handle in the {Citation/core} while almost never used in live articles. Fortunately, the parameters where people tend to use a capital letter are still rare, including: Title, Chapter, Last, First, Date, Publisher, Accessdate, or Author. Hence, if perhaps 10 major parameters were accepted with a capital letter, then there would be fewer cite errors, while no significant overhead in processing just those extra spellings (similar to 'issn' or 'ISSN'). Although wp:autofixing cites would also handle the capital-letter format, those would still be logged into a tracking category which would expand the total list of pages with invalid parameters. Instead by treating the major capital-letter forms as valid (similar to valid 'Author' during 2013), then the size of a tracking category would be reduced. -Wikid77 (talk) 17:18, 19 April 2014 (UTC)

Log dates over 24 characters as long dates

To solve the problem of misjudging free-form dates or "{{circa}} 1950" as being invalid dates (when actually valid), then I suggest any date over 24 characters long (longer than "September 16-29, 1150 BC") should be logged into a non-error tracking category, and not tagged with a "Check date values" message using a CSS class. The Template:Circa inserts an abbr-tag as "<abbr title="circa">c.</abbr>" which is 29 characters, longer than 24 and hence could be skipped when checking for valid date format. Otherwise, there are too many date formats which need to be allowed, such as the need to allow dates in years BC:

  • {cite web |title=BC Years |date=November 20, 31 BC} → "BC Years". November 20, 31 BC. {{cite web}}: Check date values in: |date= (help); Missing or empty |url= (help)

When a tracking category is flooded with errors for valid dates, then it makes it more difficult to spot the pages which contain actual invalid dates. -Wikid77 (talk) 19:12, 19 April 2014 (UTC)

As noted above, {{circa}} injects HTML into the COinS metadata, so it should be detected as invalid. --  Gadget850 talk 02:18, 20 April 2014 (UTC)
  • Lua can instantly remove any span-tag or abbr-tag: Before storing the COinS metadata, we can use the Lua regex gmatch() function to remove any circa <abbr> tag (or span-tag) and store only the "c." portion in the COinS. For "{{circa}} 1850" see result:
  • {{#invoke:String|match|pattern=<.*>(.*)<.*> |s=<abbr title="circa">c.</abbr> 1850 |plain=0 }}{{#invoke:String|match|pattern=.*>(.*)$ |s=<abbr title="circa">c.</abbr> 1850 |plain=0}}
    → c. 1850
I have run several timing tests to confirm how Lua's internal gmatch() function is extremely fast, and could remove the HTML abbr-tag or span-tag instantly, leaving only the plain text in the COinS metadata. -Wikid77 (talk) 12:12, 20 April 2014 (UTC)
We should not use Lua to change <abbr title="circa">c.</abbr> to c. in COinS; if anything it should change it to circa Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:33, 20 April 2014 (UTC)
We should not use {{circa}} or any other template inside a CS1 template. If the functionality is worthwhile, then we should build it into the CS1 module. -  Gadget850 talk 13:23, 20 April 2014 (UTC)
Why not? It's a perfectly reasonable thing for an editor to expect to be able to do. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:44, 20 April 2014 (UTC)
Pigsonthewing's question goes against the philosophy of the date checker: popular date expressions are OK and everything else is wrong. For example, the date checker considers "before 1924" to be wrong, even though it could be perfectly valid. Jc3s5h (talk) 13:49, 20 April 2014 (UTC)
Pigsonthewing@ We have no control over other templates. If the functionality is valid, then we should include it in the CS1 module where we can ensure it works proper with COinS. Otherwise we have to add a check for each and every template that might be included and injects HTML/CSS: {{smallcaps}} (functionality now in CS1), {{registration required}} (functionality now in CS1), {{subscription required}} (functionality now in CS1), {{asiantitle}}, {{start date}}, and others. --  Gadget850 talk 15:07, 20 April 2014 (UTC)
I wouldn't argue that we should do so for check for each and every template that might be included, (other than to strip away such HTML), but we should do so for those which add meaning or value to a citation; as in this case. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:26, 20 April 2014 (UTC)
That rather suggests that the date checker is in error. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:26, 20 April 2014 (UTC)

HTML classes

We've previously discussed using HTML classes to make our citations more easily parseable (Representatives of Zotero, for example, have said that if we publish and apply such a schema, then Zotero will parse it. ). The suggestion then was "Once this module is debugged and implemented, then we can look at adding this feature". Shall we now do so? A proposed list of class names is at Wikipedia:WikiProject Microformats/citation. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:19, 20 April 2014 (UTC)

Zotero already uses the COinS metadata— what is different or missing? --  Gadget850 talk 16:53, 20 April 2014 (UTC)
Among other things, it offers higher granularity and more features than COinS (the date the ref was accessed, for instance), and extensibility, which the earlier method lacks. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:31, 20 April 2014 (UTC)

Rethinking accessdate

During testing of an AWB script to 'fix' accessdate CS1 errors (more), I began wondering if we shouldn't be rethinking |accessdate=, its application, and the rules for its use. So, some of the questions that I think need answering are:

  1. Is |accessdate= correctly defined in terms of:
    a. its meaning?
    b. rules that govern when to use it?
    c. rules that govern when to display it?
  2. Are the definitions above correctly and adequately documented?
  3. Are we correctly handling citations that have |accessdate= but don't have |url=?
    1. No? What should we be doing with these citations?
  4. Do we need a bot to sift through Category:Pages using citations with accessdate and no URL?
    Yes?
    1. What should the bot fix?
    2. What constitutes a fix?

I'm sure that there are other questions but these are enough for now.

—Trappist the monk (talk) 20:02, 14 April 2014 (UTC)

Good questions. To help with answering question 1, here's the current text from CS1 template documentation that explains |accessdate=
  • accessdate: Full date when original URL was accessed; use the same format as other access and archive dates in the citations; requires url. Do not wikilink. Not required for web pages or linked documents that do not change; mainly for use of web pages that change frequently or have no publication date. Can be hidden or styled by registered editors.
Some thoughts:
  • It seems clear enough to me, but is it "correctly defined"?
  • I was unable to find an explanation of when the value of |accessdate= is actually displayed, except for the oblique "requires url".
  • There is no reference to date verification.
  • I believe that we are handling these citations as documented, though the documentation could be made more explicit.
  • I believe that the bot should fix the citations described at Help_talk:CS1_errors#Accessdate in rules 1–8 by commenting out |accessdate=. – Jonesey95 (talk) 20:44, 14 April 2014 (UTC)
|accessdate= is only displayed when |url= has a value.
—Trappist the monk (talk) 00:03, 15 April 2014 (UTC)
Does the module only look at |url=, or are other places where a URL might be found considered?
Here is a non-exhaustive list of places where a URL might be found:
URL positions:
  • bare URLS in, or next to the citation (some are placed next to citations; yep, not the way it is supposed to be, but it is done)
  • |url=
  • |chapterurl=
  • |chapter-url=
  • |contributionurl=
  • |contribution-url=
  • |archive-url=
  • |layurl=
  • |website= (Yep, again not supposed to happen, but it does)
  • |deadurl= (Yep, again not supposed to happen, but it does)
  • commented out URLs
  • Any parameter in which the editor has placed a URL. example:
Fortescue, Sir John William (1915), A history of the British army, vol. 4 part 2, Macmillan and company, pp. 889–890 {{citation}}: |access-date= requires |url= (help) [Note: This example links to a source which should not be changing, but other citations link to changeable content.]
Keep in mind that all it takes is a missing | character and the |url= is actually in some other parameter.
Technical note: The module should be changed to have one piece of code that determines if a URL is present and set a flag variable. Errors are also inappropriately generated about the lack of |url= for the presence of |archiveurl= when a |chapterurl= or |contributionurl= is present. Probably also the case for |layurl=, but I have not tested that one. — Makyen (talk) 02:03, 15 April 2014 (UTC)
From the beginning, |accessdate= has only applied to |url=. A primary requirement in the original development of Module:Citation/CS1 was to keep its functionality the same as that of {{citation/core}}. Now that most CS1 templates have migrated from {{citation/core}} to Module:Citation/CS1 that requirement may be eased.
Would you have an access-type date for all of your list of urls when there are multiple occurrences in a citation? If only one |accessdate=, to which in your list of urls should it apply if there are multiples but not |url=? What about the automatic urls associated with the module-supported identifiers (bibcode, doi, pmid, etc)?
Anything inside HTML remark tags in a CS1 citation is not visible to Module:Citation/CS1. To change that behavior would require a change to Wikimedia parser. So, the commented out URLs item on your list doesn't apply.
—Trappist the monk (talk) 10:45, 15 April 2014 (UTC)

Concerning Template:Csdoc#url, it generally makes no sense to include an accessdate in a journal citation, even if a url is present. Articles that are published in journals must by definition have been published on a specific date and with rare exceptions, the content is frozen and does not change over time. If a publication does not have an original publication date (year + volume + issue + page number), it wasn't published in a journal. With or without a url, I generally delete accessdates in cite journal templates on sight. Hence if a journal citation contains an accessdate without a url, I think the accessdate can be safely be deleted. Boghog (talk) 20:50, 14 April 2014 (UTC)

Bohog's comment is true of print journals. However, cite journal has long been a synonym for cite news. Both news outlets and journals are now online, so there is a greater potential for changes to content, especially for news media. Another issue is that editors may not think to use cite web rather than cite journal when citing material on a journal website that is not a "paper", for example, a style guide for the journal. Jc3s5h (talk) 21:54, 14 April 2014 (UTC)
Given that it appears people have not, and will not, follow the link to the other discussion, I am re-posting an edited version of comments I made there (it is a bit TL;DR 8-) ):
I object to |accessdate= being deleted on any citations.
  1. I regularly use access date information, even those on material which is supposedly unchanging (e.g. books, PMID, DOI, etc). |accessdate= provides a hint as to when the citation was entered on the page. Generally, this means that the person who added the citation believed that the reference supported the text at that point. While this may, or may not, be accurate, I routinely use access dates to prioritize which references need to be checked to verify that article content is still supported by the citation. Using it in this way is, of course, imperfect. However, there really is just not enough time in existence to do all the checking which really should be performed. This is one piece of information which can be used to help determine where to spend limited time.
  2. I have also found that |accessdate= is useful in attempting to determine to what a reference actually is referring. We all know those references that have inaccurate or corrupted information. Sometimes the citation is copied from page to page with errors/vandalism – I recently fixed one that had the same error on 34 pages across 7 wikis which appeared to be the result of copying a vandalized citation. All information we have, including |accessdate=, is potentially valuable in such situations. In that specific instance having the |accessdate= helped me identify which citations had been copied from page to page and which were valid. This would have taken much longer without |accessdate=.
  3. |accessdate= can provide a hint as to the time-frame of the actual date of the reference when that is not included with the citation.
  4. It also can be used to eliminate some possibilities of what the reference is (A citation can't refer to a reference created after that date).
  5. |accessdate= is also useful as one of the quick sanity checks for a citation: Is |accessdate= before |date=? If so, that citation needs to be checked.
  6. In addition, I have used |accessdate= as an indicator that someone has merely copied a reference from one page to another. This can indicate that the person may have not bothered to read the actual reference which may imply that a closer examination of if the reference actually supports the text is appropriate. If the |accessdate= does not closely match the date when the citation was added to the page this can indicate that the citation was not actually checked by the editor who put it in the article.
Let's not delete the information just because some people feel it is not useful, to them, on a citation that is correctly formatted, not corrupted by vandalism and has not been copied from page to page.
Why is having an access date actually bad in any of these situations? Is it just that people feel it is not useful, for them right then? It's not like we have a limited amount of space on a page and we need to trim all information which is not critical.
I see no reason to consider that having an |accessdate= without a URL is inherently an error, let alone that the |accessdate= should be deleted for that reason. I can understand the converse of a URL without access date being an error. I can understand not requiring an access date for most references without a URL (i.e. ones which refer to physical objects).
It is not reasonable to consider it an error to have an access date when the reference does not have a URL where other information in the citation implies that what is being referenced is not primarily on the web. In such case, the access date is information that is helpful in some situations, but not required. It is reasonable to give a warning that someone should check the citation and verify that a URL is not supposed to be there and disable the warning (perhaps with something similar to |ignore-isbn-error=true). Alternately, just have the module not flag having an |accessdate= without a URL to be an error if there is a valid ISBN, DOI, or other ID that leads directly to a permanent, unchanging reference.
The existence of the "error" is not to indicate that having the access date is wrong. It is to indicate that having an access date makes it likely that the person forgot to enter a URL when a URL is what is being referenced. The solution to citations being erroneously classified as this type of "error" is not to get rid of the access date information. The solution is to change the module so that it does not report most of the cases mentioned in the list of tasks (elsewhere), where additional information that the module has (e.g. valid ISBN, DOI, etc.) indicates that a URL should not be required. Additionally, there should be a way to directly inform the module that a specific instance has been checked and |accessdate= without a URL is not something that needs further attention (e.g. a |no-url-is-ok=true)).
It appears to me that people may be coming at this from the wrong point of view: See error..."fix" in easiest way possible. The easiest solution for an editor is to remove the |accessdate=. For us, there are more appropriate ways to solve a large quantity of these "errors". I think one reason people are concentrating on removing |accessdate= is that the text of the "error" leads their thinking in that direction. The "error" should have different text which concentrates on the lack of a URL, not the presence of |accessdate=. The error text should be something along the lines of: "Is there a missing URL? Add |no-url-is-ok=true if URL is not missing." instead of what is currently displayed.
All of the templates are increasingly used to refer to online versions of documents instead of physical copies. They are (all?) used to actually refer to websites with and without URLs being included. It would only be reasonable to comment out/delete |accessdate= if you can actually verify that there is enough valid data to indicate that the source really is a physical paper copy of an article. Doing so in such instances would ignore the other uses for |accessdate= data.
For a large portion of citations currently in the error category, the right solution is for the module to not report the missing URL error when enough information is there to indicate a valid physical source, or "permanent" electronic location information (e.g. valid ISBN, valid DOI, valid arXiv, etc.). The module should also be changed to: 1. have a parameter which can be added to the citation to indicate that a URL is intentionally not present; 2. report the "error" in a manner that more clearly indicates that the issue is a potential lack of a URL, not the presence of |accessdate=. — Makyen (talk) 02:03, 15 April 2014 (UTC)

I'll attempt a partial answer to the questions in Trappist's post that began this thread. An accessdate should be specified for content that was obtained from a source that is accessible through the World Wide Web, and similar protocols (for example, Gopher) if and only if the source

  1. lacks a publication date OR
  2. is likely to disappear and be difficult to locate OR
  3. is likely to be altered

The first choice for the URL is the URL that is visible in the browser address bar while reading the source. If this isn't feasible, for example, with a pdf, the second choice is a URL that will download the source, will display download instructions, or which contains a link which can be clicked to download the source. Third chhoice: if the procedure for accessing the source is more complex (for example some paywalls), the URL should be a page from which the source can be navigated to; after the close of the CS1 template (but before the &ltref> element, if applicable) the navigation directions should be given. Jc3s5h (talk) 12:27, 15 April 2014 (UTC), clarified 13:22 UT.

To clarify, do you mean:
  • lacks a publication date OR is likely to disappear and be difficult to locate OR is likely to be altered
or do you mean:
  • (lacks a publication date AND is likely to disappear and be difficult to locate) OR is likely to be altered
or do you mean:
  • lacks a publication date AND (is likely to disappear and be difficult to locate OR is likely to be altered)
Not sure I understand your apparent exception for pdf files unless by that you mean the exception for those browsers that spawn Adobe reader either as a plugin or as a separate program. If that's the case, then, is it not true that the url of the pdf can be obtained with a right mouse click on the pdf link and then by choosing 'Copy link address' or some such similar action?
—Trappist the monk (talk) 13:13, 15 April 2014 (UTC)
I mention pdf files as a type where the URL of the file may not be visible while viewing the file. This would also often apply to Microsoft Word and Microsoft PowerPoint files. Jc3s5h (talk) 13:24, 15 April 2014 (UTC)
Is it necessary for a reader to see the file's url while viewing the file? And still, isn't it true that for a file not directly displayed by the browser, the file's url is available with a right mouse click on the file's link in the referring page? For example, there are pdf links on this PMC search results page. If I want the url of the pdf file for the article "By any name, female–female competition yields differential mating success", I can right click on the pdf link and get this url: https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3199164/pdf/arr111.pdf.
This same applies to any non-native file type, right?
How does all of this apply to rethinking |accessdate=?
—Trappist the monk (talk) 14:18, 15 April 2014 (UTC)
Maybe I didn't word my post as well as it could be worded. The parameters, the automatic warnings, and any bots making fixes should all be in agreement. Much of what I wrote is intended as advice to an editor about which URL to include in a citation; if one URL will display the source directly while another will lead to a page where it could be downloaded by clicking a link, the former is preferable. From the display and bot-fixing point of view, we should hesitate to hide or remove the accessdate if we don't know what kind of source we are dealing with. Maybe it's a paywall where it's impossible to give a URL that will lead directly to the source; the editor didn't know what to do so left out the URL. A later editor may be able to supply a URL that is somewhat helpful. Jc3s5h (talk) 14:53, 15 April 2014 (UTC)
The issues about paywall sites are another reason to drop all restrictions about "accessdate=". -Wikid77 17:21, 15 April 2014 (UTC)

Opinions of accessdate restrictions

I think enough objections have been raised, above and in prior discussions, to reach a consensus now about the "accessdate=" parameter. Reply below. -Wikid77 17:21, 15 April 2014 (UTC)

  • Support removing accessdate restrictions: Limiting accessdate has not worked. The day someone noted a URL can be linked within a page number, I knew immediately the accessdate should have no restrictions and always be shown. The alternative would be new parameter "show_accessdate_you_moron = true" and that would only confirm the contempt which many people feel about accessdate, when one angry user noted we should just offer an abbreviation instead, such as "acdate=". Always beware how intelligent people are judging Wikipedia, and try to act smarter, quicker. -Wikid77 (talk) 17:21, 15 April 2014 (UTC)
Unsure exactly what you are proposing but if removal of text "Not required for web pages or linked documents that do not change; mainly for use of web pages that change frequently or have no publication date." then I am in favour of deleting that phrase from the document and allowing it to be used without such restriction. Trying to enforce this is just ridiculous. Keith D (talk) 18:03, 15 April 2014 (UTC)
It sounds like Wikid77 and Keith D are in favor of displaying the value of |accessdate= in all cases and eliminating the current error message. Please correct me if I am misstating your position.
That leads me to wonder what harm would come from doing that. If someone wants to provide an accessdate for a book they found at the library, does that do any harm? I can't think of any. It may be extraneous information, but anyone who is looking at references on Wikipedia knows that they are going to run into all sorts of information that they do not need in order to locate the cited source. – Jonesey95 (talk) 18:52, 15 April 2014 (UTC)
One of the reasons that accessdates are everywhere is the result of click-through editing using Reflinks: some editors simply run it and click 'save' without amending anything. It always adds an accessdate. I wish editors would instead archive the reference and add archiveurl and archivedate instead. I find no use for knowing that a newspaper article published and archived on the same day was also accessed on the same day. Of course it was! -- 79.67.241.227 (talk) 20:22, 15 April 2014 (UTC)
Style guide that recommends access dates for reading a book? Anyone? --  Gadget850 talk 20:49, 15 April 2014 (UTC)
If one reads a first edition tome by a long-dead author, and then cites in WP what it says, the date on which it's read is entirely irrelevant. And it would be ludicrous to say that such a date was in any way meaningful. -- Ohc ¡digame! 02:24, 16 April 2014 (UTC)
  • Oppose I entirely endorse what 79.67.. said. This is an encyclopaedia, where the object is to be useful within meaningful confines. We should not go down the road of allowing something merely because it's "harmless". Despite the instructions urging restraint, we've already gone some way down the road in ubiquitous use of access dates without truly questioning their utility or labouring under some misguided notion of the potential use which few actually explore. This is something that automated tools like Reflinks have a lot to answer for.

    Whilst some editors might feel rather clever in second-guessing by applying logical and coherence checks, these checks are often not very determinant on the error. Do I want to spoil their fun? Hell no. But we need to remember access dates add an additional dimension that occupies a lot of server storage space whilst being, IMHO, rather shallow. This encyclopaedia, being a wiki, is prone to all sorts inconsistencies. Errors and vandalism happen and are often corrected by others. Maintaining these access dates is more trouble than is worth, as one can just as easily (or not) find alternatives or archived cites without them. OTOH, having these gives a false sense of security that a link can be found with a little diligence. Access dates are not palliatives for poor referencing practices. They should be removed in favour of urging editors to preemptively or systematically archive. -- Ohc ¡digame! 01:51, 16 April 2014 (UTC)

  • Support within reasons; maybe we need some limitations but more lax ones. Accessdates can be useful for non-web sources. Any source that may change should have an accessdate. Accessdates can also be used to indicate when a source was checked vs. when others sources were checked or when some other thing happened, and this can be useful information in determining whether source verification has been completed (i.e., in relation to a WP:V/WP:RS-related cleanup or dispute tag or discussion on talk page. Not all hardcopy sources have known publication dates. If someone has added a totally pointless accessdate , thenthat can be removed, and if there's an alleged reason for putting it back (maybe it wasn't as pointless as thought), that's a matter for discussion at that article, not a "never ever do this" decision made on some "Help talk:"-namespace page that only about ten of us pay any attention to.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  09:14, 16 April 2014 (UTC)
  • "Any source that may change" is not a reliable source. "Access dates are not palliatives for poor referencing practices" make me reconsider the concept of access date altogether. --  Gadget850 talk 12:54, 16 April 2014 (UTC)
  • The fact that a source may change does not reflect on its reliability, so long as the source exercises appropriate editorial control over changes. Jc3s5h (talk) 13:10, 16 April 2014 (UTC)
  • The APA style guide specifies that with online sources, the reference needs either a DOI or a URL with accessdate. Legal citations to online sources in Bluebook format use an access date with the URL. MLA now just specifies that if a referenced source is online, no URL is listed, but the accessdate is listed after "Web" as the descriptive label. Chicago doesn't require access dates, and instead it suggests archiving copies of sources, but it does allow them where publishers or instructors require them. But as SMcCandlish says, the entire online world is not ruled out, not by us nor by the various guides to citations. Imzadi 1979 → 04:35, 23 April 2014 (UTC)

Cite web cite not displaying properly

Resolved

I've stumbled across a bit of a problem on the article William Wigginton. One of the cites, for {{cite web}} is refusing to display, or rather, displaying as code.--Auric talk 04:53, 21 April 2014 (UTC)

Fixed. I'm not sure how or why. I replaced the hard return between "cite" and "web" with a space. I thought all white space was supposed to be treated the same, but maybe not. – Jonesey95 (talk) 05:19, 21 April 2014 (UTC)
No, not all whitespace is treated the same. One of the issues we had with "unknown parameters" in citation templates was that a variety of different Unicode spaces were used within or around parameter names in some citations and not recognized as whitespace. Mostly those were the use of a hard-coded non-breaking space. In this instance, it was a standard LF (0x0A) character. It appears that while a LF is considered whitespace on either side of the template name, it is not considered such within the name of the template. — Makyen (talk) 06:03, 21 April 2014 (UTC)
Similar problem occurs if a newline gets copied inside a parameter value, such as title or url. ~ J. Johnson (JJ) (talk) 21:24, 21 April 2014 (UTC)
We can potentially fix those problems. We can't fix it in the template name as it occurs before the template is invoked. --  Gadget850 talk 22:48, 21 April 2014 (UTC)
So is "cite web" a distinct template, not a "web" variant of "cite"? ~ J. Johnson (JJ) (talk) 23:39, 21 April 2014 (UTC)
@J. Johnson: The answer to your question is a bit more complex than you are probably intending to ask. Yes, {{cite web}} is a separate template. Except for redirects, each citation type is a separate template. However, most such either invoke or call two base sets of functionality. The newer set of functionality is based on a Lua module. Templates such as {{cite web}} invoke that module. Some citation templates still use the older wiki-template based citation code. There is a third type used for a few types of citations where a bot will go out and collect the information for the citation and create a template with the information filled in which is then transcluded into the citing page. All of those are ultimately based on the Lua module once the bot builds the template to transclude. There is a list of the General use citation templates indicating which base functionality is being used.
@Gadget850: It is not clear to me that such problems should be handled within the module. The number of occurrences is relatively low and easily fixed in the page. Once we start "fixing" such things in the module it is an ever growing list of things to "fix". We have already cleared out the "unknown parameter" category. The extra processing is probably not worth it moving forward. — Makyen (talk) 00:56, 22 April 2014 (UTC)
Thanks, Mayken. I was wondering how much of that had been changed. ~ J. Johnson (JJ) (talk) 22:43, 22 April 2014 (UTC)
  • CS1 cites already rejoin split newline data: There has been some misunderstanding, but for over a year, the Lua wp:CS1 templates have been autofixing cites which have newlines (LF) in data, but not newlines within the template name "{cite web}". For example, note a title on 4 lines:
  • {cite web |title=Title
    Broken
    into
    Four Parts |author=Joe Fixit |date=Another day of autofixing}}
    →

           Joe Fixit (Another day of autofixing). "Title Broken into Four Parts". {{cite web}}: Check date values in: |date= (help); Missing or empty |url= (help); line feed character in |title= at position 6 (help)

When I first developed the Lua-based CS1 cites, several types of autofixing were added, such as non-plural pages "pages=4" shows as "p. 4" not "pp." or removing double-dots between parameters. The filter to remove newlines in titles was added soon after. Although handling all these issues has been detailed work, the results are amazing, such as wikilinking "location=[[Washington, D.C.]]" and still getting only one dot separator after the "D.C." text because the Lua module checks for end-dot (or other separator) inside a wikilink. -Wikid77 (talk) 11:16, 22 April 2014 (UTC)

Status of autofixing cites

I have been updating topic above "#Should autofix more cites" but I wanted to note some recent issues. Although the use of autofixing will retro-correct cites in archived pages (especially wp:AfD's which admins want left unchanged) and fix all prior revisions of any page, the auto-corrections have reached perhaps 200 issues and will take more time to discuss. Please understand, the whole prior tactic of issuing red-error messages for cites was never my intention, but by allowing them into Lua cites for a whole year (April 2013-2014), we gained extensive evidence that those messages do not cause users to fix "9,000" articles, which had to be hand-fixed by a special backlog drive to clear 8,500 of them by mid-April 2014. Now, we see perhaps 12 new "unknown parameter" pages left each day (366/month, ~4,400/year), to be hand-fixed or else thousands of people see red messages. However, at this point, we are spotting the trends for new unknown parameters, where perhaps 10% are bad accessdate as "acesdate" or "access date" or "accessed" (etc.) and many are capital-letter form (invalid "Publisher="). Before release of autofixing, more users need to understand to search for "[fix cite]" and "[fix url]" rather than "Unknown parameter |xx= ignored". The next step would be partial rollout for use of autofixing in some types of cites, such as {{cite encyclopedia}} or such. However, I expect more weeks of discussion and stronger autofixing, such as to handle invalid:
"| urlhttp://xxx.com/index.php?zz=123&arg=en"   as if   "url="
Long-term, we need to expect many more editors to write invalid cites every day, but not yet, because currently the editor base of Wikipedia is in a slight decline, perhaps due to strange user-interface changes (https, login redesign, 2-style Frankenfonts with Liberation Sans, etc.) or users leaving who cannot post more adverts. However, many users keep joining despite all the forced wp:VE or login problems, and autofixing will allow more new users to write invalid cites but still get workable results. That's the brief status so far. It will take time to transition. -Wikid77 (talk) 10:40, 22 April 2014 (UTC)

I plan to recruit ReferenceBot in the next month or so to notify editors who leave unsupported parameter errors, along with "coauthors without author", redundant parameter, PMC, and PMID errors. I am waiting for the redundant parameters category to be cleared (in the next couple of days) and for the job queue to stop adding new articles to the new PMC and PMID categories. Of the 27 error categories, 14 have been cleared, and four have fewer than 500 articles with errors, so they should be easy to clear and keep clear. That leaves nine categories to focus new ideas and energy on. – Jonesey95 (talk) 14:36, 22 April 2014 (UTC)
"coauthors without author" should perhaps read "coauthors is deprecated, use last/first or author" There are still many editors adding references with the coauthors attribute. -- 79.67.241.210 (talk) 17:14, 22 April 2014 (UTC)
I was referring to Category:CS1 errors: coauthors without author, which has been cleared out recently. Now that the category has been cleared, ReferenceBot will be able to notify the 2–4 editors per week who add a citation containing this error.
I forgot to mention above that we have eliminated over 50,000 articles from Category:Articles with incorrect citation syntax in the last month, since the most recent code update. The total number of articles shown on that page was about 299,000 on March 23, 2014, and it's down to 253,000 today (April 22). (I estimate over 50,000 articles eliminated because the code changes have added at least a few thousand new articles.) That is great progress. – Jonesey95 (talk) 18:09, 22 April 2014 (UTC)

CS1 Advisories

The functionality afforded by using templates is great but there are a number of template generators and bots which continue to produce deprecated parameters or make amendments that are, or soon will be, unnecessary.

I'd like to suggest creating a Help:Citation_Style_1/Advisories page, where salient points can be listed (and can link to more detailed stuff where necessary). This would be aimed at bot operators and at coders working on producing template generators. It would simply be a clear list of changes they may need to be aware of so they can amend the functionality of their systems. Template changes would be easy to find without having to trawl through the huge amounts of template documentation looking for things that may have changed.

Some examples to kick off:

  • The |month= and |day= parameters are deprecated. Monkbot is cleaning up remaining cases. The |date= parameter can handle full or partial dates. Processes should be amended to no longer generate the deprecated parameters.
  • Bots should no longer swap |date=1999 over to |year=1999.
  • Bots should no longer swap |trans-title= over to |trans_title=. The hyphenated version is currently an acceptable alias and may?/will? at some point become the "default".
  • The |coauthor= and |coauthors= attributes are deprecated. Processes should be amended to no longer generate the deprecated parameters. Use |last=|first= or |author=.
  • When handling a |url= ending .pdf or .doc it is useful to add the appropriate |format=PDF or |format=DOC parameter.
  • For human readability of template code and sensible word-wrapping, please ensure there's a space before each |pipe when emitting refactored template code.

The idea is to avoid producing more stuff that needs to be fixed, and avoid doing work that is currently unnecessary or which will need to be undone when a future planned change is made to the template workings.

Discuss... -- 79.67.241.210 (talk) 17:09, 22 April 2014 (UTC)

I've just updated Wikipedia:AutoWikiBrowser/Rename template parameters so AWB bots will no longer swap |trans-title= over to |trans_title=. It would be very helpful to have a list of the valid parameters and aliases for each citation template. GoingBatty (talk) 03:09, 23 April 2014 (UTC)
The best list of CS1 (Lua module) parameters I know of is at Module:Citation/CS1/Whitelist. – Jonesey95 (talk) 04:29, 23 April 2014 (UTC)

Requesting help with CS1 date error

In the Benzodiazepine dependence article, there's a CS1 date error that I can't seem to fix:
{{cite journal |author=Professor Lader |coauthors=Professor Morgan, Professor Shepherd, Dr Paul Williams, Dr Skegg, Professor Parish, Dr Peter Tyrer, Dr Inman, Dr John Marks (Ex-Roche), Peter Harris (Roche), Tom Hurry (Wyeth) |editor1-first= |editor1-last= |editor1-link= |date=30 October 1980 – 3 April 1981 |title=Benzodiazepine Dependence Medical Research Council headquarters, Closed until 2014 - Opened 2005 |publisher=[[National Archives]] |location=England |url=http://nationalarchives.gov.uk/catalogue/displaycataloguedetails.asp?CATLN=6&CATID=7798554&j=1 |format=PDF }} generates:

This seems to be valid per MOS:DATEFORMAT#Ranges but still generates an error. What am I missing? Thanks! GoingBatty (talk) 15:39, 26 April 2014 (UTC)

Similar to an error reported by Editor Jonesey95. Fixed in the sandbox.
—Trappist the monk (talk) 16:25, 26 April 2014 (UTC)
Demonstrating the sandbox fix:
Cite journal comparison
Wikitext {{cite journal|author=Professor Lader|coauthors=Professor Morgan, Professor Shepherd, Dr Paul Williams, Dr Skegg, Professor Parish, Dr Peter Tyrer, Dr Inman, Dr John Marks (Ex-Roche), Peter Harris (Roche), Tom Hurry (Wyeth)|date=30 October 1980 – 3 April 1981|format=PDF|location=England|no-tracking=true|publisher=[[National Archives]]|title=Benzodiazepine Dependence Medical Research Council headquarters, Closed until 2014 - Opened 2005|url=http://nationalarchives.gov.uk/catalogue/displaycataloguedetails.asp?CATLN=6&CATID=7798554&j=1}}
Live Professor Lader (30 October 1980 – 3 April 1981). "Benzodiazepine Dependence Medical Research Council headquarters, Closed until 2014 - Opened 2005" (PDF). England: National Archives. {{cite journal}}: Cite journal requires |journal= (help); Unknown parameter |coauthors= ignored (|author= suggested) (help)
Sandbox Professor Lader (30 October 1980 – 3 April 1981). "Benzodiazepine Dependence Medical Research Council headquarters, Closed until 2014 - Opened 2005" (PDF). England: National Archives. {{cite journal}}: Cite journal requires |journal= (help); Unknown parameter |coauthors= ignored (|author= suggested) (help)
That looks like it works. The deprecated parameter error is still there for |coauthors=, of course. – Jonesey95 (talk) 20:17, 26 April 2014 (UTC)

Time for a real CS1 style guide?

Of late there seem to have been several discussions that relate to various template parameters and the styling of rendered citations:

All or most of these issues could / should be answered by a proper style guide. Instead, what we get are a lot of short-term conversations that ultimately produce nothing. As we are now, we have documentation distributed across the various CS1 templates and help pages. The documentation is often out of date with respect to CS1's actual implementation and does not serve as a style guide because it can't. I know that there are editors out there who are familiar with published style guides (I'm not one of them) who could write a style guide for CS1. That guide would then direct further development of Module:Citation/CS1 into the tool that it really is capable of being.

Isn't it time we had such a guide? This is no short term project. Every citation type, every parameter, every bit of functionality, should be taken apart, examined and if found worthy, included in the style guide that details its use.

—Trappist the monk (talk) 12:32, 22 April 2014 (UTC)

Before enabling the CS1 errors: dates messages (or any of the other hidden messages) for everyone to see, I agree that a proper style guide should be in place which addresses those errors and their resolution. GoingBatty (talk) 14:16, 22 April 2014 (UTC)
It would be easier to start with a printed style guide and write a supplemental guide explaining which rules in the printed guide have been changed. For example, if we started with "APA Style" we could say that it has been extended to endnotes rather than being restricted to Harvard references, article titles are in double quotes rather than plain, the article title is linked to the web site of the article if available, etc.
This approach would allow the CS1 style to benefit from discussions of the printed style guide outside of Wikipedia, for example, the blog at the APA style website. Jc3s5h (talk) 14:22, 22 April 2014 (UTC)
Writing a supplement as you describe requires free and open access to the particular version of the established style guide that the supplement modifies. Any editor must be able to read that original and the supplement. CS1 is not APA, nor Chicago, nor any other but is, as I understand it, some combination of those with ideas of our own tossed in. This would seem to make it more difficult to pick one to modify but perhaps it's possible.
You're the expert here on APA, how closely does what amounts to style in CS1 match APA?
—Trappist the monk (talk) 17:05, 22 April 2014 (UTC)
I don't think there is a requirement that the base style guide be freely accessible, although it would be preferable. The more popular guides have many free websites that summarize them. The biggest differences between APA and CS1, in my view:
  • APA covers both the body of an article, and the citations; CS1 only covers citations.
  • APA only describes parenthetical referencing, while CS1 applies to endnotes only, short endnotes with bibliography, and parenthetical referencing
  • APA has some details of how elements of the citation are to be written that are not specified in CS1; for example, article titles are plain and have sentence case. Also, author first and middle names are always initials in APA style.
  • APA publication dates are in the format "(2014, April 22)."
  • In APA the date always follows the authors; if there are no authors, the title is the first element and is immediately followed by the date.
  • Since APA is designed for paper, the URLs from which documents were retrieved are written out rather than being hyperlinks.
  • There are element order conventions for many situations. The order is similar but not identical to CS1. If we wanted, we could make some minor changes in the order of elements to match APA, without requiring any parameter changes.
As for other style guides, Chicago Manual of Style has pretty much the same options (endnote only, short endnotes and bibliography, parenthetical referencing) as CS1, but the order of elements are quite a bit different. Also, the date format for journals and newspapers is pretty strange.
The Modern Language Association style is based on parenthetical referencing, where the author and shortened titile (not the year) are put in the parentheses. That would be a huge change. Jc3s5h (talk) 18:53, 22 April 2014 (UTC)
I've been taking some undergraduate classes, and all of my professors/instructors have recommended the Purdue Online Writing Lab (OWL). I purchased copies of the current editions of the APA, MLA and Chicago style guides, but Purdue OWL or the official websites are just as good for consultations. Imzadi 1979 → 19:03, 22 April 2014 (UTC)

So, perhaps I really don't know what it is that I want. Scanning through the MLA and APA sections at Purdue OWL tells me how to manually construct various types of citations. With CS1, there is no manual construction, the templates and Module:Citation/CS1 do that for us.

—Trappist the monk (talk) 11:22, 23 April 2014 (UTC)

As noted, the issue with APA, Chicago and others is that the manuals are copyrighted. We really need to start from scratch and create our own open style. The current display of citations is different enough from published styles that it should not be an issue. We already have a MoS that covers other styles; we need to work on only citation style here. We need to deconstruct the current documentation and recodify it.
A major issue is that many editors and projects use the CS1 templates, but add their own spin, such as first name initials, smallcaps names, and many more variations. This muddles CS1 as a style. We will never have internal consensus on a house style— any consistent style will have to be imposed from above.
--  Gadget850 talk 12:13, 23 April 2014 (UTC)
Copyright is not an issue, except for those who insist on getting the information from the horse's mouth, and decide to buy the printed style guide. Copyright only applies to the words that are used in the style manual to explain the style; copyright does not apply to the ideas. We can explain the same style points in Wikipedia that a printed style guide explains; we just can't use the same wording to explain it. And of course, fair use still applies, so the occasional phrase or example from a printed style guide can be quoted so long as it falls under the fair use doctrine. Jc3s5h (talk) 15:29, 23 April 2014 (UTC)
We need to not adopt some third-party, paper-based citation standard. We've evolved our own for good reasons. If there's any justice in the world, it'll even spread off of WP.

I strongly concur that we do need such a guide. I have no objection to basing the overall gist of our style on some other one, but like all of WP:MOS, it should be a synthesis of several, guided by actual mainstream usage, and with every point focused on what is best for our readers, not for editors much less particular camps of them.

Some of the style problems of various off-WP citation style guides, just off the top of my head and in 5 minutes or less:

  1. Failure to italicize the titles of major works (books, journals, TV shows, albums).
  2. Failure to double-quotation-markup titles of minor works (chapters, articles, episodes, songs).
  3. Forcing of all titles to sentence case, when WP should either leave them alone or (probably preferably) change them all to title case (except in foreign languages that do not use title case, like French).
  4. Boldfacing of volume numbers instead of using the word "Volume" or "Vol." (an accessibility problem among other things).
  5. Using even more cryptic markup like 32.7:234, which varies between fields and off-WP "authorities", and is user-hateful jargon, vs. Vol. 32, No. 7, p. 234.
  6. Confusing reversal of given-name and family-name order, after first author as in Lopez, Maria; John Samuels.
  7. Reduction of all middle names to initials.
  8. Reduction of everything but surnames to initials.
  9. Worse yet, doing so without period/stops/dot: Frehley, IP.
  10. Even worse yet, doing so without commas Frehley IP.
  11. Use of SMALL CAPITALS for various conflicting purposes (first author's family name, all author family names, titles of one sort or the other, etc.).
  12. Use of inconsistent date formats.
If I were to sit down and pore over the major citation styles again, I'm sure I could quadruple that list in a hour or two, but a complete catalog of academic citation styles' "sins" isn't the point here, just an illustration that there are lots of them and that our style has evolved to avoid them, though imperfectly – I think some template may still be boldfacing volume numbers, and we do nothing at all to even encourage proper name handling instead of stuff like "Frehley IP".  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  22:28, 27 April 2014 (UTC)

Migrating cite music release notes to Module:Citation/CS1/sandbox

Because it is similar to {{cite AV media notes}} I'm beginning to think about how to migrate {{cite music release notes}} to Module:Citation/CS1/sandbox.

I'm thinking that changes similar to those made to {{cite AV media notes}} apply here:

  1. |type= – provides functionality similar to |albumtype= as described at Migrating cite AV media notes, item 2. Here, |type= has been repurposed to control the format of |name=. When |type= is set to any value, the value in |name= is rendered in quotations; otherwise the value is rendered in italic font. Presumably, this is because individual song titles are quoted, not italicized. Because {{cite music release notes}} cites the notes, not the song or album, this undocumented functionality is inappropriate in this template. I propose to remove this functionality from {{cite music release notes}} and so free |type= for use consistent with the other CS1 templates.
  2. |Format= – not the same as |format=, this undocumented parameter is an alias of |type= which is not supported in the normal way; see above. Another, also undocumented parameter, |titletype=, is also an alias of |type=. I propose to deprecate |Format= because it is so similar to |format= (which has the specific definition of online resource file format) and deprecate |titletype= because it is undocumented. Both of these shall be deprecated in favor of |type= and I shall change the default value from "Release notes" to "Media notes" so that it is the same as {{cite AV media notes}}.
  3. |name= – an alias of |series= is used in place of |title= which places the "title" of the notes in a nonstandard position when the citation is rendered. While supported, |title= is remapped to be an alias of |chapter= though this functionality is not documented. I propose to restore the normal sense of |title= and deprecate |name= in favor of the restored |title= consistent with all other CS1 templates.
  4. |artist= – simply a unique alias of |others=, which is not currently supported, so I propose to deprecate it in favor of |others= as was done in {{cite AV media notes}}.
  5. |pid= – I propose to deprecate |publisherid= because it is simply an undocumented alias of |id=.

As I did with {{cite AV media notes}}, I will modify the template, tweak the documentation, and then create an AWB script to make appropriate changes to the templates in article space.

I think that once these changes are made, another AWB script can rename the templates in article space from {{cite music release notes}} to {{cite AV media notes}} and so accomplish the migration without having any effect on Module:Citation/CS1. A redirect would handle any new instances of {{cite music release notes}}.

—Trappist the monk (talk) 13:22, 26 March 2014 (UTC)

This all sounds straightforward to me. Would you consider notifying relevant Wikiprojects, as you did with the last migration? – Jonesey95 (talk) 15:23, 26 March 2014 (UTC)
Did that already.
—Trappist the monk (talk) 15:51, 26 March 2014 (UTC)

I have tweaked the {{cite music release notes/sandbox}} (testcases – such as they are) and have an AWB script to run after I update {{cite music release notes}}. I have added code to the script to fix capitalization. In a surprising number of these cites, the parameters are capitalized, so for who knows how long, these citations have not been fully rendered. I have also added code to change |albumlink= to |titlelink= because I have found them in the wild. Though neither are supported in the current or sandbox versions, |titlelink= is supported by {{cite AV media notes}} to which all of these {{cite music release notes}} will eventually migrate.

I have found several instances of citations like the second example on the template's documentation page. This example should be {{cite journal}} not {{cite music release notes}}. Sigh. And, those that I did find seem to also put the journal's volume and issue number in |id=. Perhaps I'll see if I can make yet another script that will tease apart the contents of |id= and just fix these.

—Trappist the monk (talk) 19:42, 26 March 2014 (UTC)

I was going though {{cite music release notes}} a while back and found the same issue where other templates should have been used. I think there were some also uses of oddball parameters that were never coded. --  Gadget850 talk 15:34, 27 March 2014 (UTC)
Turns out that there were only about twenty of those citations that referenced Film Score Monthly and I have fixed them. Today or tomorrow I'll update the {{cite music release notes}} from {{cite music release notes/sandbox}} and start my AWB script working on adapting the article space templates.
—Trappist the monk (talk) 15:55, 27 March 2014 (UTC)
So is there now no longer any way to control the format of |name=? I ask because {{Cite music release notes}} is often used to cite the release notes for singles, and it conflicts with our manual of style if the name of any single referenced in this way can only be formatted in italics, rather than in quotation marks. A Thousand Doors (talk | contribs) 22:50, 30 March 2014 (UTC)
The purpose of {{cite music release notes}} is to cite print material. The title of the printed notes may be the same as the title of a single, but it is still a print document, separate and apart from the single, so the template treats it that way.
You do, I think, point out a shortcoming that exists in {{cite AV media}} which is supposed to be the proper template for citing singles, albums, video, etc. There is no mechanism available to render the title of a single in quotes. I'll have a look at that and see what can be done about it.
—Trappist the monk (talk) 23:25, 30 March 2014 (UTC)

Having remembered that I want to finish this, within the next couple of days I will run an AWB script to rename existing instances of {{cite music release notes}} to {{cite AV media notes}}. Once that is complete, I'll make {{cite music release notes}} a redirect to {{cite AV media note}} and do documentation cleanup.

—Trappist the monk (talk) 12:22, 26 April 2014 (UTC)

Some tweaks to the case sensitivity of the script, or a follow-on script, may be needed. See the unsupported parameter errors resulting from this edit, this edit, and probably more. If you are done converting these templates, you could probably focus on Article-space pages in the unsupported parameter category. – Jonesey95 (talk) 04:59, 30 April 2014 (UTC)
There were a small number which could have been handled a bit better in this transition, but nothing significant/major. I recall having to change some in earlier passes through the "unsupported parameters" category. Mostly I noticed it because it has some unique parameter usage which required special-casing a couple of the regex replacements I was using. most of my notice of it was the need to refine what I was doing to account for uniquely permitted parameter names. There are multiple templates where this sort of thing was the case. On this set I did not check, but it is possible that the most recent problems existed prior to the transition.
However, the Category:Pages with citations using unsupported parameters is once again cleared. If I recall correctly, there were 21 new pages in the category. At least 20%, if not more, were due to vandalism. At least one appeared to be erroneously not in the category earlier: the unknown parameters existed on the page from 2012. — Makyen (talk) 10:40, 30 April 2014 (UTC)
In {{cite music release notes}}, |name= equated to |title=, not |author=. Similarly, |PID= in these templates equated to |id= and not to |pmid=. |type= should be deleted and then |Format= becomes |type=. If there were other {{cite music release notes}} citations that your script fixed, you might want to revisit them. I have fixed the two that Editor Jonesey95 identified.
—Trappist the monk (talk) 12:36, 30 April 2014 (UTC)
In March when I started all of this, I ran an AWB script that modified instances of {{cite music release notes}} by changing parameter names and fixing capitalization. Apparently I didn't get them all.
I did just run a script over the content of Category:Pages using citations with format and no URL because I noticed that other {{cite AV media notes}} citations in pages that were edited by my rename script were misusing |format=. The script fixed about 120 of them.
—Trappist the monk (talk) 11:17, 30 April 2014 (UTC)

Done, I think.

—Trappist the monk (talk) 11:41, 30 April 2014 (UTC)

Someone did a revert on Bette Davis Eyes, but I fixed it. Looks like you missed Say Somethin' (Mariah Carey song). I will fix the navboxes. --  Gadget850 talk 16:04, 30 April 2014 (UTC)
Good, thanks. Carey is fixed.
—Trappist the monk (talk) 16:23, 30 April 2014 (UTC)

For phased releases of new version

This is a Lua technical note. Due to the massive use of the wp:CS1 cite templates, an upgrade runs over 6-7 weeks to deploy the smallest change into any article. Meanwhile, if a change is needed immediately, it would be faster to hand-edit it into a cite. Instead, if the Lua modules were partially released in phases, then many articles (perhaps 100,000) could get the upgraded cite templates within 2-3 days (15-20x faster). As an example, if the cite templates were changed to invoke the new Lua modules only when parameter "last2=" is used, then that would cause many major articles to have the update perhaps 20x faster. See proposed markup: 

{{#if: {{{last2|}}}
| {{#invoke: Citation/CS1/new|citation|CitationClass=web}}
| {{#invoke: Citation/CS1|citation|CitationClass=web}}<!--old version-->
}}

In this proposed case, the early release of the new Module:Citation/CS1/sandbox would be copied into Module:Citation/CS1/new, and then only pages with parameter "last2=" (about 124,000 pages) would have the new features within 3 days, while the remainder of the 2.1 million pages (with CS1 cites) would be reformatted over the 6-7 week period (perhaps after re-checking the results of the 3-day early release). In cases where another page needed immediate update, then setting one cite as "last2=&nbsp;" would cause that page to be reformatted within the 3-day period. Currently, we have occasional complaints that a problem, fixed in the /sandbox version weeks ago, is still annoying users due to the 2-3 month delay in upgrading all 2.1 million pages for a new feature. Because major pages tend to need new features, and major pages tend to use parameter "last2=" then the rapid 20x faster results could be applied in the targeted articles, as if the MediaWiki software had been improved to work much faster. The initial change to such partitioned cite templates would require a total reformat of all 2.1 million pages for 6-7 weeks, and then afterward the 3-day partial release would be possible. Meanwhile, hand-editing of cite formats is still the best method to get instant results in a limited set of pages. -Wikid77 (talk) 16:28, 27 April 2014 (UTC)

This seems excellent in every way, other than maybe the side effect that the "guinea pigs" being sort of tested on in the fast 3-day window are also most likely to be the major articles, but I guess that can't be helped.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  04:44, 28 April 2014 (UTC)
The guinea-pig aspect is lessened... by the quick ability to re-deploy a last-minute fix, within a 3-day reformat period. I think the developers have noted how a last-minute fix (even deployed within a day) will re-reformat the prior pages but also override the prior change for pages not yet reformatted (during the initial 3-day period), as a combined 4-to-5-day reformat, not always 6 days total. In contrast, with a 7-week reformat then a last-minute-fix might delay a re-reformat (fixing a glitch) until late during the 7 weeks, although each straggler could use a wp:null edit to force each page to reformat the glitch within a minute. With the Lua-based Template:Convert, the reformat of 550,000 pages took over 20 days (from 11 December 2013), and improvements have slowed to a crawl as leaving bugs for over 5 months now (where nonsense range 105–106 °F (41–41 °C) formerly showed 40.6–41.1 °C, rather than the nonsense "41-41" same result for different numbers 105/106). When it's not "wiki" then it is "slowki" with very slow improvements. -Wikid77 (talk) 10:14, 28 April 2014 (UTC)
Works for me. Glad someone is on this.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  23:14, 28 April 2014 (UTC)
This sounds like a nightmare from a diagnostic and troubleshooting standpoint. A purge or null edit of an article would either invoke the current (old) version of the template or the new version of the template, but you would have to scan the whole article for an instance of |last2= (or whatever) in order to figure out which one it was using. Ugh.
Wouldn't it be easier to set up a null-edit bot, job queue job, or something equivalent, to perform periodic (daily? weekly?) null edits on the most popular articles?
Or, and I know I'm talking crazy now, what would it take to eliminate the root problem, which is that it takes two months for articles to be fully recategorized when the CS1 citation templates are updated? Is there a bugzilla bug for this issue, or is everyone resigned to the circumstance that two months is how long changes take to propagate? I, for one, am not resigned to that state of things, but I don't know enough WP history to understand why the situation exists. – Jonesey95 (talk) 03:11, 29 April 2014 (UTC)
New CS1 versions could be just weeks ahead of old: I think the MediaWiki developers are trying to design a new, faster type of multiple wp:Job_queue structure, auto-reformatting some major articles every day, but such software redesigns tend to take many months/years. The reason partitioned templates would work, to solve this cite-reformat problem, is because mainly the complex cites, with unusual parameters, tend to need new features/upgrades, and triggering a partial release by "last2=" (or also "author2=") would tend to reformat pages with complex cites. Also note: both the main release and the partial release could actually be the same revision of the CS1 cites, but the pages using "last2/author2=" would be reformatted weeks sooner then all pages using the main release of the CS1 Lua modules. The general principle is this: if a 20-times-shorter list of pages to reformat, plus the long list, are both processed at the same speed, then the shorter list will finish 20x times faster than reformatting all pages in the long list. Hence, the major pages (using last2/author2) would be re-rendered ~20x sooner than today's CS1 cites. In fact we might tend to release the partial release just 7-14 days sooner than the full, main release of the CS1 Lua modules. That is how we could reduce confusion between the features provided with last2/author2 cites versus all the other cites: keep the partial and main CS1 versions similar, within a few weeks of each other. However, we would definitely need to keep a formal release schedule, including feature/bug issues resolved by each particular release. By comparison, today's complexity is the uncertainty of whether a major article has yet been reformatting to display the current CS1 cites, or is still "in the queue" to be reformatted 7 weeks later. It would be great to look for last2/author2 and know whether the page would be updated within 3 days (or 50 days, as usual now). -Wikid77 17:18, 30 April 2014 (UTC)
Retrieved from "https://wiki.riteme.site/w/index.php?title=Help_talk:Citation_Style_1/Archive_4&oldid=1064542092"