Jump to content

Help talk:Citation Style 1: Difference between revisions

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Browse history interactively
← Previous editNext edit →
Content deleted Content added
VisualWikitext
ClueBot III (talk | contribs)
Bots
1,333,092 edits
m Archiving 2 discussions to Help talk:Citation Style 1/Archive 10. (BOT)
Line 2,043: Line 2,043:


When archiveurl is set (and deadurl=yes), is there any reason to keep the access-date? It clutters the displayed ref with 3 dates, it's confusing and I don't see why the access-date would be needed since providing access-date to the archive is redundant with archivedate, and providing access-date to the original article is pointless since it's been replaced with an archive. Thanks. -- [[User:Green Cardamom|<font color="#006A4E">'''Green'''</font>]][[User_talk:Green Cardamom|<font color="#009933">'''C'''</font>]] 16:51, 28 December 2015 (UTC)
When archiveurl is set (and deadurl=yes), is there any reason to keep the access-date? It clutters the displayed ref with 3 dates, it's confusing and I don't see why the access-date would be needed since providing access-date to the archive is redundant with archivedate, and providing access-date to the original article is pointless since it's been replaced with an archive. Thanks. -- [[User:Green Cardamom|<font color="#006A4E">'''Green'''</font>]][[User_talk:Green Cardamom|<font color="#009933">'''C'''</font>]] 16:51, 28 December 2015 (UTC)

== URL parameter validation doesn't take port numberl into account ==

See for example at the first reference at [[Gudivada]]. Currently, it's throwing an error but if the port number is removed, it doesn't throw it. --[[User:Glaisher|Glaisher]] ([[User talk:Glaisher|talk]]) 12:44, 29 December 2015 (UTC)

Revision as of 12:44, 29 December 2015

WikiProject iconWikipedia Help B‑class High‑importance
WikiProject iconThis page is within the scope of the Wikipedia Help Project, a collaborative effort to improve Wikipedia's help documentation for readers and contributors. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks. To browse help related resources see the Help Menu or Help Directory. Or ask for help on your talk page and a volunteer will visit you there.Wikipedia HelpWikipedia:Help ProjectTemplate:Wikipedia Help ProjectHelp articles
BThis page does not require a rating on the project's quality scale.
HighThis page has been rated as High-importance on the project's importance scale.
For more talk pages, see Special:WhatLinksHere/Help talk:Citation Style 1.

|p-prefix= and |pp-prefix=

Because of the recent discussion involving page numbering, I have been looking at the mess that is page number handling in Module:Citation/CS1. There are two parameters |p-prefix= and |pp-prefix= that are, as far as I can tell, unused and are not documented. These parameters work in non-periodical cs1|2 templates but are ignored in periodical cs1|2. In these examples |pp-prefix=pgs.:

Title. pp. 13–40. {{cite book}}: Unknown parameter |pp-prefix= ignored (help) – cs1
Title, pp. 13–40 {{citation}}: Unknown parameter |pp-prefix= ignored (help) – cs2
"Title". Journal: 13–40. {{cite journal}}: Unknown parameter |pp-prefix= ignored (help) – cs1
"Title", Journal: 13–40 {{citation}}: Unknown parameter |pp-prefix= ignored (help) – cs2

Because they are not used and because it is the duty of the template to provide static text in cs1|2 citations, I propose to remove these parameters. Because they are unused, deprecation seems unnecessary. Is there any reason to keep them?

—Trappist the monk (talk) 16:28, 12 November 2015 (UTC)[reply]

If they are truly unused and undocumented, we should remove them from the code.
My experience with our recent transition of |month= and other parameters from deprecated to unsupported was that a few hundred articles were moved from the deprecated parameter category to the unsupported parameter category, despite all of our searching for |month=. The insource search does not reliably find all instances of the thing you are searching for.
That said, if we remove support for it, I'll be happy to clean up instances that may exist. – Jonesey95 (talk) 18:03, 12 November 2015 (UTC)[reply]

Now no longer supported:

Title. pp. 13–40. {{cite book}}: Unknown parameter |pp-prefix= ignored (help) – cs1
Title, pp. 13–40 {{citation}}: Unknown parameter |pp-prefix= ignored (help) – cs2

—Trappist the monk (talk) 12:51, 19 November 2015 (UTC)[reply]

citing contributed forewords, prefaces etc

This topic began at Foreword and branches from Moving forward to continue here so that discussion of implementation detail can be separate from whatever conversation continues there.

The model for this feature is this {{cite book}} armature:

{{cite book |contributor-last=Pynchon|contributor-first=Thomas|contributor-link=Thomas Pynchon|contribution=Introduction |last=Orwell |first=George |title=Nineteen Eighty-Four |location=New York |publisher=Plume-Penguin |date=2003 |pages=vii-xxvi}}

If the code is right, then Module:Citation/CS1/sandbox should produce citations that look like these hand crafted cites:

Pynchon, Thomas (2003). Introduction. Nineteen Eighty-Four. By Orwell, George. New York: Plume-Penguin. pp. vii-xxvi. (cs1)
Pynchon, Thomas (2003), Introduction, Nineteen Eighty-Four, by Orwell, George, New York: Plume-Penguin, pp. vii-xxvi (cs2)

The tests:

{{cite book/new |contributor-last=Pynchon|contributor-first=Thomas|contributor-link=Thomas Pynchon|contribution=Introduction |last=Orwell |first=George |title=Nineteen Eighty-Four |location=New York |publisher=Plume-Penguin |date=2003 |pages=vii-xxvi}}
Pynchon, Thomas (2003). Introduction. Nineteen Eighty-Four. By Orwell, George. New York: Plume-Penguin. pp. vii–xxvi.
{{citation/new |contributor-last=Pynchon|contributor-first=Thomas|contributor-link=Thomas Pynchon|contribution=Introduction |last=Orwell |first=George |title=Nineteen Eighty-Four |location=New York |publisher=Plume-Penguin |date=2003 |pages=vii-xxvi}}
Pynchon, Thomas (2003), Introduction, Nineteen Eighty-Four, by Orwell, George, New York: Plume-Penguin, pp. vii–xxvi

Since this is the first test, something is bound to be wrong. In this case, 'By' should be in lowercase in the cs2 version.

Contributor has the standard enumerated suite of name parameters and modifiers. et al is not supported. This facility is only available for {{cite book}} and {{citation}} (where |work= or aliases is not set). The module understands the common contribution titles 'afterword', 'foreword', 'introduction', and 'preface' and renders these upright without quotes. For contributions that are not any of these four, the contribution title is quoted:

"Contribution". Title. {{cite book}}: |contributor= has generic name (help); |contributor= requires |author= (help)

When |contributor= is set and |contribution= is not set the module emits an error:

"Chapter". Title. {{cite book}}: |contributor= has generic name (help); |contributor= requires |author= (help); |contributor= requires |contribution= (help)

Errors of this type will be categorized in Category:CS1 errors: missing contribution

Still to do:

  1. fix the casing of 'by'
  2. adjust the CITEREF anchor creation to use the contributor name list when |ref=harv
  3. adjust the metadata creation to use the contributor name list instead of the author list
  4. properly handle editor(s)
  5. tests to make sure that I haven't broken anything
  6. fix other things that I've no doubt overlooked

—Trappist the monk (talk) 23:41, 13 November 2015 (UTC)[reply]

Overlooked: most style guides do not invert the author(s) names after "by" or "in". ~ J. Johnson (JJ) (talk) 00:17, 14 November 2015 (UTC)[reply]
I presume that you are correct. However, cs1|2 from the days of {{citation/core}}, has rendered all |last= / |first=-defined name lists in last-first order. This change is consistent with that norm.
—Trappist the monk (talk) 12:02, 14 November 2015 (UTC)[reply]

The code for CITEREF anchors has been adjusted:

  • '"`UNIQ--templatestyles-00000063-QINU`"'<cite id="CITEREFPynchon2003" class="citation book cs1">[[Thomas Pynchon|Pynchon, Thomas]] (2003). Introduction. ''Nineteen Eighty-Four''. By Orwell, George. New York: Plume-Penguin. pp.&nbsp;vii–xxvi.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=bookitem&rft.atitle=Introduction&rft.btitle=Nineteen+Eighty-Four&rft.place=New+York&rft.pages=vii-xxvi&rft.pub=Plume-Penguin&rft.date=2003&rft.aulast=Pynchon&rft.aufirst=Thomas&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1" class="Z3988"></span> <span class="cs1-visible-error citation-comment"><code class="cs1-code">{{[[Template:cite book|cite book]]}}</code>: </span><span class="cs1-visible-error citation-comment">Invalid <code class="cs1-code">&#124;ref=harv</code> ([[Help:CS1 errors#invalid_param_val|help]])</span>
  • '"`UNIQ--templatestyles-00000065-QINU`"'<cite id="CITEREFLast2009" class="citation cs2">Last, First (2009), ''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.date=2009&rft.aulast=Last&rft.aufirst=First&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1" class="Z3988"></span>
  • '"`UNIQ--templatestyles-00000067-QINU`"'<cite id="CITEREFElast2009" class="citation cs2">Elast, Efirst, ed. (2009), ''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.date=2009&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1" class="Z3988"></span>

—Trappist the monk (talk) 13:46, 14 November 2015 (UTC)[reply]

And metadata as can be seen the the above examples.

—Trappist the monk (talk) 15:00, 14 November 2015 (UTC)[reply]

Editor fixed, I think. |orig-year= is included because I've tweaked how the meta-parameter Date is handled at that particular point in the code:

Pynchon, Thomas (2003) [1949]. Introduction. Nineteen Eighty-Four. By Orwell, George. Smithson, James; Beecham, Thomas (eds.). New York: Plume-Penguin. pp. vii–xxvi.

—Trappist the monk (talk) 16:26, 14 November 2015 (UTC)[reply]

Because the |contributor= / |contribution= pair is specific to book cites with a book author, detect and flag cites with |contributor= but without one of the |author= aliases:

"Contribution". Title. 2009. {{cite book}}: |contributor= has generic name (help); |contributor= requires |author= (help)

and flag cites that are not book cites:

"Contribution". Title. 2009. {{cite AV media}}: |contributor= ignored (help) ({{cite AV media}})
"Title". 2009. {{cite journal}}: |contribution= ignored (help); |contributor= ignored (help); Cite journal requires |journal= (help) ({{cite journal}} – |contribution= here treated as alias of |chapter=)

but {{cite book}} with |contribution= and |author=, no error:

Author (2009). "Contribution". Title. {{cite book}}: |author= has generic name (help)

Because there are multiple different errors, I've changed the category name to Category:CS1 errors: contributor.

—Trappist the monk (talk) 18:00, 14 November 2015 (UTC)[reply]

  • Millet, Eugène (1869). "Plans des salles du Musée de Saint-Germain". Promenades au musée de Saint-Germain. By Gabriel de Mortillet. catalogue illustré de 79 figures par Arthur Rhoné. Paris: C. Reinwald. p. 88.
This really is a useful solution to a long-standing problem. Great job! Aymatth2 (talk) 01:49, 16 November 2015 (UTC)[reply]
It is not good practice to use the sandbox versions of cs1|2 templates in article space. The sandbox can break at any time and remain broken for extended periods. I will also note that |others=catalogue illustré de 79 figures par Arthur Rhoné is a misuse of that parameter which purpose is to "record other contributors to the work ...", not for subtitles or descriptive text.
—Trappist the monk (talk) 11:52, 16 November 2015 (UTC)[reply]
  • I just wanted to try it out. Probably for Millet's bibliography it should be:
For Rhoné's bibliography it should be:
and for de Mortillet's bibliography is should be:
This seems consistent with the Harvard guideline for scholarly works, where the main person being cited goes to the front. I wonder if unrecognized types of contribution should be treated more like chapters, i.e. followed by "In"? Is there a way to make |pages=88 generate pp. 88 in a bibliography? Any idea when the new template will be released? Once again, this really is a big improvement. Aymatth2 (talk) 13:24, 16 November 2015 (UTC)[reply]
Non-standard contribution titles are treated like chapters in that they are quoted. If you mean that:
... |contributor=Contributor |contribution=Contribution |author=Author |title=Title |date=<date>|...
should render something like:
Contributor. "Contribution". In Title. By Author ...
then I see no real benefit.
I think that your Rhoné example is improper. Rhoné may have contributed the illustrations to de Mortillet's work, but there doesn't appear to be anything in that work with the proper title "Illustrations". |contribution= as currently supported is a title, not a class of things.
If you mean that you want |pages= to indicate the total number of pages, that goes against the long-defined and documented purpose of |pages= as an in-source locator; see Template:cite book#csdoc_pages.
I want to address a bug that I've found in the metadata handling of in-source locators. Since I'm there I will also see if I can address the issues raised in Help talk:Citation Style 1/Archive 10#Page display in journal could use improvement. So I don't know when I will update the live module.
—Trappist the monk (talk) 15:45, 16 November 2015 (UTC)[reply]
  • It is quite unimportant, but in this example the plans and illustrations are "in" the book. Aymatth2 (talk) 16:09, 16 November 2015 (UTC)[reply]
  • Then I am not sure how to represent Rhoné's role in the book in his bibliography, the list of works he contributed to. He is credited on the title page with having illustrated the book with 79 figures, presumably scattered throughout it, like this one. Taken together they represent a significant work, But the credit is not really a subtitle, more a description. Aymatth2 (talk) 16:09, 16 November 2015 (UTC)[reply]
  • Understood that in a citation, |pages= gives the location in the book. But in a bibliography, list of works by the author, number of pages is a fairly significant bit of information. Again, not sure how to represent it. Aymatth2 (talk) 16:09, 16 November 2015 (UTC)[reply]
Please do not interleave your comments in mine. I have moved them.
My objection to Rhoné also applies to Millet for the same reasons.
There seems to be a wide variety of ways that illustrator bibliographies are handled. I peaked at a few articles in Category:American children's book illustrators and Category:British children's book illustrators and didn't find much in the way of consistency except, that the illustrator is rarely listed in the bibliographic entry. In most cases that I saw, bibliographic entries were composed freehand.
Primary mission for cs1|2 is, and must remain, citation. That it can be used for bibliographies is a plus. But, that is why I mentioned elsewhere that someday we might use |mode= to tell Module:Citation/CS1 to treat the template contents as a bibliographic entry rather than as a citation.
—Trappist the monk (talk) 17:13, 16 November 2015 (UTC)[reply]
  • Both Rhoné and Millet are sometimes illustrators, sometimes authors.
A |mode= parameter could be useful. I would usually set it to |mode=bibliography. I almost always use {{sfn}} references that give locations in the sources and point to a list of source definitions. I often also list works by the subject of the article, so have two sections that list books and articles (by and about), both the same format. I would like both lists to give fairly complete bibliographic data. Mostly the stuff that does not fit elsewhere can go into |others=, but a clean way to cite the introduction would be useful – there is no good workaround.
Smith, Fred. Preface (2015). Poor alternative. Jane Doe. Penguin.
Thanks, Aymatth2 (talk) 20:24, 16 November 2015 (UTC)[reply]
... but a clean way to cite the introduction would be useful – there is no good workaround. Which is what this change does so I don't understand your point.
—Trappist the monk (talk) 10:39, 17 November 2015 (UTC)[reply]
There is a curious inconsistency in the ordering of elements in the following:
  • {{cite book/new |first=A. |last=Contributor |chapter=Chapter |editor-first=Ann |editor-last=Editor |title=Title |year=2000 }} yields
    Contributor, A. (2000). "Chapter". In Editor, Ann (ed.). Title. {{cite book}}: |last= has generic name (help)
  • {{cite book/new |first=Ann |last=Author |title=Title |year=2000 }} yields
    Author, Ann (2000). Title. {{cite book}}: |last= has generic name (help)
  • {{cite book/new |contributor-first=A. |contributor-last=Contributor |contribution=Contribution |first=Ann |last=Author |title=Title |year=2000 }} (newly introduced) yields
    Contributor, A. (2000). "Contribution". Title. By Author, Ann. {{cite book}}: |last= has generic name (help)
Kanguole 13:25, 4 December 2015 (UTC)[reply]
I'm not seeing any inconsistency. Perhaps that's because I wrote the code and see it doing what I expect from it. The last example should be following the contributor and author ordering shown in the MLA forms at Harvard Guide to Using Sources. The MLA form was chosen over APA because we use the static text 'in' to introduce the editor when there is a contribution.
Can you point out exactly what it is that you see as an inconsistency?
—Trappist the monk (talk) 13:54, 4 December 2015 (UTC)[reply]
It seems you have followed APA order (editor before title) in one case, and MLA order (title before author) in the other. For the purpose of distinguishing editors from authors, the prefix "in" is not a strong signal, as both cases refer to a contributed part of a book – indeed in both cases MLA omits the preposition while APA includes it. The explicit text (Ed.)/(Eds.) would be more effective (but we'd need to find and fix cases where people have already explicitly attached it to the name of the last editor). Kanguole 14:44, 4 December 2015 (UTC)[reply]
cs1|2 is neither APA nor MLA; for all that, cs1|2 isn't any of the published style guides. The APA-like ordering for 'In Editor. Title.' is not new to this version of the module's sandbox. I don't see that there is anything that is 'broken' here. Given that, I think that we should do nothing and allow the new feature to go live this weekend.
If there is an issue with the contributor-author-editor name-order, we should address it in its own discussion and then act accordingly.
—Trappist the monk (talk) 15:49, 4 December 2015 (UTC)[reply]
My point is that it is an arbitrary switching of styles between the two cases. As you point out, "In Editor. Title" has been used for some time, so it would be consistent to use "In Author. Title" for the new case. Kanguole 16:08, 4 December 2015 (UTC)[reply]

|volume=, |issue=, |page(s)= and cite magazine

which cs1|2 templates should support
|volume=, |issue=, |page(s)=?
template |volume= |issue= |page(s)=
{{citation}} Yes Yes Yes
{{cite arXiv}} No No Yes
{{cite AV media}} Yes No No
{{cite AV media notes}} No No Yes
{{cite book}} Yes No Yes
No No Yes
Yes Yes Yes
{{cite DVD notes}} No No Yes
{{cite encyclopedia}} Yes No Yes
{{cite episode}} No Yes No
{{cite interview}} Yes Yes Yes
{{cite journal}} Yes Yes Yes
{{cite magazine}} Yes Yes Yes
{{cite mailing list}} No No No
Yes No Yes
Yes Yes Yes
{{cite news}} Yes Yes Yes
{{cite newsgroup}} No No No
{{cite podcast}} No No No
{{cite press release}} No No Yes
{{cite report}} Yes No Yes
{{cite serial}} No No No
{{cite sign}} No No No
{{cite speech}} No No No
{{cite techreport}} Yes No Yes
{{cite thesis}} No No Yes
{{cite web}} No No Yes

This topic is a follow-on from Help talk:Citation Style 1/Archive 10#Page display in journal could use improvement.

In the sandbox, I have limited the journal-style page rendering to {{cite journal}}:

"Title". Journal. 23 (6): 101–130.

For {{citation}}, journal-style page numbering applies only when |journal= is set. For the other aliases of |journal=, the module uses the 'p.' and 'pp.' prefixes:

"citation with journal", Journal, 23 (6): 101–130
"citation with work", Work, vol. 23, no. 6, pp. 101–130

I have created Template:cite magazine/new which calls Module:Citation/CS1/sandbox. For {{cite magazine}}, the module will render the volume, issue, and page(s) as: 'vol. # no. # p. #'.

"Title". Magazine. Vol. 23, no. 6. pp. 101–130.

Other templates that use these parameters are unaffected by this change. But, that makes me wonder if we should be limiting the rendering of these parameters. The table is a list of templates and the parameters that I think that they should support. Opinions? Comments?

—Trappist the monk (talk) 15:07, 18 November 2015 (UTC)[reply]

{{cite web}} should support |page= / |pages=, as it does now. As for {{citation}}, am I the only one who sees the mixed output with the boldfaced volume, bracketed issue and prefixed page numbers as strange? Why wouldn't we completely switch that over to "vol. 23, no. 6, pp. 101–130"?
One last thought, but we should decide if there will be periods (for cs1) separating all of the entries in "vol. 23 no. 6. pp. 101–130." or not. As it is, there is no period after the volume number. Personally, even for cs1, I'd see these as connected items that should be treated as a logical group and separated by a comma and ended by a period. Imzadi 1979 → 23:32, 18 November 2015 (UTC)[reply]
@Imzadi1979: you may not be the only one that finds the "39(12):4–34" style strange, but it's an absolutely standard format in many (perhaps most) academic journals (Nature, for example). So it has to be supported here (given that the English Wikipedia doesn't impose a single citation style). Peter coxhead (talk) 10:59, 19 November 2015 (UTC)[reply]
I think the question was about the 23 (6), pp. 101–130 style.
—Trappist the monk (talk) 11:06, 19 November 2015 (UTC)[reply]
Ah, whoops, sorry. Then I agree with Imzadi1979, it does look odd. Peter coxhead (talk) 11:50, 19 November 2015 (UTC)[reply]
No, Peter coxhead, I don't find that original, truncated output strange at all, although I would personally prefer if cs1|2, as its own style, transitioned away from it under the guise of enhanced legibility for non-academic audiences. In the meantime though, {{citation}} shouldn't output something that's half that style and half the new style in certain use cases. Imzadi 1979 → 14:02, 19 November 2015 (UTC)[reply]
That isn't just a {{citation}} issue (pun not intended). The 'mixed' style occurs with just about all cs1 templates (even {{cite journal}} when |journal= or an alias is not set). Mostly this is because we don't limit the use of |volume= and |issue= as we should do. That is the purpose of the table: to codify which of |volume=, |issue=, and |page(s)= is appropriate for use with which cs1|2 templates.
—Trappist the monk (talk) 19:45, 19 November 2015 (UTC)[reply]
I'm inclined to agree that volume, issue and page should always be grouped together. As it is right now, that only happens with journal and map cites; all other cites can insert any or all of the meta-parameters Others, Edition, Publisher, and Agency between issue and page.
—Trappist the monk (talk) 11:50, 19 November 2015 (UTC)[reply]
Reports, techreports, and serials can have volumes. I have a vague recollection of even a conference report ("book") being issue in volumes. ~ J. Johnson (JJ) (talk) 00:10, 19 November 2015 (UTC)[reply]
I've tweaked the table as above except {{cite serial}} because its documentation says it is "used to create citations for broadcast programs". I don't see how |volume= is appropriate here.
—Trappist the monk (talk) 10:54, 19 November 2015 (UTC)[reply]
It seems to me that shows via DVD are often published in several sets (e.g. episodes 1-4, 5-8, etc...). Does it seem desirable to be able to delineate that, or is episode and format good enough? Presently, volume is used in that template, at least per the documentation, and that's the only plausible use I can see for volume. --Izno (talk) 12:19, 19 November 2015 (UTC)[reply]
Citing a DVD we should use {{cite AV media}}. Perhaps |volume= (or maybe a more meaningful alias) is appropriate. I've tweaked the table.
—Trappist the monk (talk) 12:30, 20 November 2015 (UTC)[reply]
Interesting. The documentation then fails to recognize that in publishing (etc.) the term serial is applied to any "publication in any medium issued under the same title in a succession of discrete parts, usually numbered (or dated) and appearing at regular or irregular intervals with no predetermined conclusion." (See also Serial (publishing).) Perhaps the intended of use of this template needs reconsidering, and the documentation corrected. ~ J. Johnson (JJ) (talk) 00:15, 20 November 2015 (UTC)[reply]
Perhaps you are thinking of |series= which I think is intended to meet the needs of citing serial publications.
The definition of {{cite serial}} could certainly be tightened. It is used to cite whole seasons of television programs, to cite individual episodes of programs, to cite a series of novels, and probably other things. At some other time and place we should probably consider revision of {{cite serial}}, {{cite episode}}, {{cite AV media}} to carefully define their use and minimize overlap, among other things.
—Trappist the monk (talk) 12:30, 20 November 2015 (UTC)[reply]
Perhaps you have it backwards? "Serial" seems to be the more general term, while your "whole seasons of television programs" is more generally called a series. It's bad enough if these templates were misnamed, but to double down on the error would only make WP citation even more inscrutable. ~ J. Johnson (JJ) (talk) 23:00, 20 November 2015 (UTC)[reply]
Do not blame me for the template {{cite serial}} and the parameter |series=. I had nothing to do with their creation. My previous post was merely a report of what I found when I looked at a few of the articles that transclude {{cite serial}}. Go look for yourself to see how it is used. Go look at its documentation to see how it is meant to be used.
—Trappist the monk (talk) 00:04, 21 November 2015 (UTC)[reply]
FWIW, my experience is that "series" is used to refer to an entire run of a show in the US (IOW, all ten seasons of Friends make up the series), while in the UK, there would have been be ten series of Friends. Rwessel (talk) 04:20, 21 November 2015 (UTC)[reply]
Trappist, I don't blame you for the templates being possible misnamed and/or misused. (If I want to blame you for something I will find something you actually did.) And I certainly agree that "carefully refin[ing] their use" would be good. I am a little concerned lest any such refinements lock-in past mis-directions. ~ J. Johnson (JJ) (talk) 23:13, 21 November 2015 (UTC)[reply]
Another quick thought, but I'm wondering if it would be possible to invoke the new output style in {{cite map}} if |work= is used instead of |journal=? Imzadi 1979 → 14:02, 19 November 2015 (UTC)[reply]
To be consistent, when |magazine=Magazine:
"Title" (Map). Magazine. Vol. 23, no. 6. pp. 101–130.
"Title" (Map). Magazine. Vol. 23, no. 6. Sheet 5.
"Title" (Map). Journal. 23 (6): 101.
"Title" (Map). Journal. 23 (6): Sheet 5.
Title (Map). Sheet 5.
—Trappist the monk (talk) 19:45, 19 November 2015 (UTC)[reply]

I have adapted Module:Citation/CS1/sandbox so that cs1|2 templates render |volume=, |issue=, and |page(s)= as specified in the above table. So that we don't clutter this page, here is a link to a version of my test cases page that shows all of the templates.

Also at the top of that page there are test cases for {{cite magazine}}. I have tweaked its support so that it properly renders lower case for cs2. Do we need punctuation between volume and number? between number and page? If so, what is it? Are we to render |volume=, |issue=, and |page(s)= all together as a group or allow the meta-parameters Others, Edition, Publisher, and Agency to separate |issue= from |page(s)=? If all as a group, where do they go? in the same position as |volume= and |issue= are now or in the same position as |page(s)= is now:

Title. Vol. Vol. Others (1st ed.). Location: Publisher. p. Page. {{cite book}}: |volume= has extra text (help); Unknown parameter |agency= ignored (help)CS1 maint: others (link)

—Trappist the monk (talk) 14:54, 21 November 2015 (UTC)[reply]

A conversation elsewhere caused me to discover a flaw. {{cite techreport}} uses |number=, usually an alias of |issue=, but in this template it is an alias of |id=. When both |id= and |number= are used, the error message in the live version doesn't render correctly. I have also fixed that:

Cite techreport comparison
Wikitext {{cite techreport|number=12345|title=Title}}
Live Title (Technical report). 12345.
Sandbox Title (Technical report). 12345.
Cite techreport comparison
Wikitext {{cite techreport|id=12345|title=Title}}
Live Title (Technical report). 12345.
Sandbox Title (Technical report). 12345.
Cite techreport comparison
Wikitext {{cite techreport|id=98765|number=12345|title=Title}}
Live Title (Technical report). 98765. {{cite tech report}}: More than one of |id= and |number= specified (help)
Sandbox Title (Technical report). 98765. {{cite tech report}}: More than one of |id= and |number= specified (help)

—Trappist the monk (talk) 20:16, 3 December 2015 (UTC)[reply]

@Trappist the monk: I'm still getting the "More than one of |id= and |number= specified" error message on Dynamic dispatch. I was trying to use id= (which is undocumented!) like with other citation templates, to link to CiteseerX. QVVERTYVS (hm?) 12:45, 10 December 2015 (UTC)[reply]
You should be getting that error because |number= is an alias of |issue= which neither of the parameter values TR-CS-94-02 and {{citeseerx|10.1.1.33.4292}} is. The simple solution is to move the {{citeseerx}} template outside of {{cite techreport}}:
{{cite techreport |title=Dynamic Dispatch in Object-Oriented Languages |first1=Scott |last1=Milton |first2=Heinz W. |last2=Schmidt |number=TR-CS-94-02 |institution=Australian National University |year=1994 |id=}} {{citeseerx|10.1.1.33.4292}}
Milton, Scott; Schmidt, Heinz W. (1994). Dynamic Dispatch in Object-Oriented Languages (Technical report). Australian National University. TR-CS-94-02. CiteSeerx: 10.1.1.33.4292
It would seem that the best long-term solution should be that we add citeseerx as a supported identifier (like |doi=, |isbn=, etc).
—Trappist the monk (talk) 13:55, 10 December 2015 (UTC)[reply]

update to the live cs1|2 module weekend of 5–6 December 2015

I propose to update the cs1|2 modules over the weekend of 5–6 December 2015. The changes are:

to Module:Citation/CS1

  1. bug fix in et al. detection; discussion
  2. bug fix in is_parameter_ext_wikilink(); discussion
  3. bug fix in nowrap_date(); discussion
  4. bug fix in |subscription= and |registration=; discussion
  5. |time= and |minutes= now redundant; wikilink and url checks for all |<param>-link= parameters; enhanced url validation; enhanced url error messaging; discussion
  6. detect non-printable characters; discussion
  7. proper date formatting for metadata; discussion
  8. improve metadata creation; discussion
  9. tweak first_set() to ensure that the list is read first-to-last;
  10. bug fix and revision of chapter-format error handling; discussion
  11. revise |language= handling so that IETF codes are accepted; discussion
  12. add support for foreword, preface, etc book cites; discussion
  13. bug fix: duplicate punctuation in author rendering; discussion
  14. convert extra pages error to redundant parameter error; discussion
  15. add support for {{cite magazine}}; revise vol/issue/page handling; discussion
  16. revise url detection and validation; discussion
  17. extra_text_in_page_check() not skipped when |nopp= is properly set; discussion
  18. bug fix in redundant parameter error messaging; discussion

to Module:Citation/CS1/Configuration

  1. remove extra font-size css from subscription/registration style;
  2. detect non-printable characters;
  3. add support for foreword, preface, etc book cites;
  4. convert extra pages error to redundant parameter error;
  5. |Ref= no longer supported; discussion
  6. |p-prefix= and |pp-prefix= no longer supported; discussion
  7. unhide deprecated parameter errors; discussion
  8. add support for {{cite magazine}}; revise vol/issue/page handling;
  9. messages entry for newsgroup, titletype;
  10. remove extra_pages error;

to Module:Citation/CS1/Whitelist

  1. add contributor suite of parameters; discussion
  2. |Ref= no longer supported;
  3. |p-prefix= and |pp-prefix= no longer supported; discussion

to Module:Citation/CS1/Date validation

  1. proper date formatting for metadata;

—Trappist the monk (talk) 16:20, 28 November 2015 (UTC)[reply]

Inserted omitted item 11 into Module:Citation/CS1 list.
—Trappist the monk (talk) 19:29, 1 December 2015 (UTC)[reply]
The sandbox version seems not to include |year= in the generated reference id:
  • {{cite book/new |title=Title |last=Author |first=A.N. |year=2000 |ref=harv }} yields CITEREFAuthor.
  • {{cite book/new |title=Title |last=Author |first=A.N. |date=2000 |ref=harv }} yields CITEREFAuthor2000.
Kanguole 13:25, 2 December 2015 (UTC)[reply]
Good catch, thank you. Fixed:
  • Author, A.N. (2000). Title. {{cite book}}: |last= has generic name (help); Invalid |ref=harv (help)
  • Author, A.N. (2000). Title. {{cite book}}: |last= has generic name (help); Invalid |ref=harv (help)
  • Author, A.N. (2000). Title. {{cite book}}: |last= has generic name (help); Check date values in: |year= / |date= mismatch (help); Invalid |ref=harv (help)
The problem was in a function called first_set() which is supposed to choose the first set item in a list of items. The existing code uses for _, var in pairs(list) do where list is some number of arguments. The existing function ignores unset arguments and returns the first set argument. The problem with that, is that the order of evaluation isn't guaranteed. Calling the function like this with both arguments set: first_set(ChapterUrl, URL) can and does return URL.
My attempt to fix that failed, as you discovered. That attempt used for i, var in ipairs(list) do which evaluates the list left-to-right, but quits when it discovers an unset argument. The anchor id code uses first_set(Year, anchor_year). When meta-parameter Date is not set, it gets the value of Year and Year is set to nil. Because Year is first in the list of arguments and because it is nil, first_set() returned nothing for the anchor id.
I have resolved that by changing to a while i <= count do form of loop control. This forces the function to evaluate every argument in the list in left-to-right order.
—Trappist the monk (talk) 16:56, 2 December 2015 (UTC)[reply]
 Done. These changes were implemented about seven hours before my time stamp here. – Jonesey95 (talk) 20:09, 5 December 2015 (UTC)[reply]

Journal article with introduction

@Trappist the monk: An unusual citation problem showed up with the article on Jean-Charles-Pierre Lenoir. It is related to #citing contributed forewords, prefaces etc. An article in a journal had an introduction by Robert Darnton followed by an annotated excerpt of Lenoir's unpublished memoirs. The journal gives both Darnton and Lenoir as authors, but the WP article cites only the introduction. The approach taken in the article was to cite like:

Darnton 1970, p. 534 harvnb error: multiple targets (2×): CITEREFDarnton1970 (help)

This does not give formal credit to Lenoir as uncited co-author, but the situation seems quite unusual, so it is presumably good enough.

The memoirs were eventually published as a book that included a lengthy discussion of Lenoir by Vincent Milliot, Un policier des Lumières. This was shown in the list of works by Lenoir as:

  • Milliot, Vincent; Lenoir, Jean-Charles-Pierre (2011). Un policier des Lumières followed by Mémoires de J. C. P. Lenoir, ancien lieutenant général de police de Paris, écrits en pays étrangers dans les années 1790 et suivantes. Seyssel: Champ vallon, impr. p. 1141. ISBN 978-2-87673-553-8.

In this case, the article did not cite Milliot, but only because his intro was not visible online. This is a reasonably common situation: an old book with a modern introduction that we want to cite. This is where |contributor= will be really useful (hint :~). Aymatth2 (talk) 17:20, 28 November 2015 (UTC)[reply]

For citations, we cite what we read. If a Wikipedia editor read an online source that did not include some material by Milliot, then Milliot shouldn't be mentioned by the Wikipedia editor. If a Wikipedia editor lists the works of an author, the Wikipedia editor should use reliable sources to compile the list, not other Wikipedia articles, because Wikipedia is not a reliable source. Jc3s5h (talk) 18:52, 28 November 2015 (UTC)[reply]
If the English Historical Review article contains annotated [excerpts] of Lenoir's unpublished memoirs and we are to assume that Darnton is the author of the annotations throughout, then I think the {{cite journal}} template as you've used it here is correct. Lenoir might be listed as |last2=. Because the excerpts are just that, excerpts, then Darnton isn't really making a contribution to Lenoir's work; rather, he is using Lenoir's work to support his own. The article is Darnton's. |access-date = not required for archived material; use |jstor=563194:
{{cite journal |ref=harv |title=The Memoirs of Lenoir, Lieutenant de Police of Paris, 1774-1785 |last1=Darnton |first1=Robert |journal=The English Historical Review |volume=85 |issue=336 |date=July 1970 |publisher=Oxford University Press |jstor=563194}}
Darnton, Robert (July 1970). "The Memoirs of Lenoir, Lieutenant de Police of Paris, 1774-1785". The English Historical Review. 85 (336). Oxford University Press. JSTOR 563194. {{cite journal}}: Invalid |ref=harv (help)
I must not be clever enough to figure out what it is that you are hinting at. The |contributor= / |contribution= support currently in the sandbox will give you what I think I understand you to want:
{{cite book/new |contributor=Milliot, Vincent |author=Lenoir, Jean-Charles-Pierre |contribution=Un policier des Lumières |title=Mémoires de J. C. P. Lenoir, ancien lieutenant général de police de Paris, écrits en pays étrangers dans les années 1790 et suivantes |location=Seyssel |publisher=Champ Vallon |year=2011 |isbn=978-2-87673-553-8}}
Milliot, Vincent (2011). "Un policier des Lumières". Mémoires de J. C. P. Lenoir, ancien lieutenant général de police de Paris, écrits en pays étrangers dans les années 1790 et suivantes. By Lenoir, Jean-Charles-Pierre. Seyssel: Champ Vallon. ISBN 978-2-87673-553-8.
I think that |publisher=Champ vallon, impr. is incorrect and should be |publisher=Champ Vallon or |publisher=Éditions Champ Vallon or |publisher=Les Éditions Champ Vallon (I don't have French so I can't say for sure; see website); I suspect that 'impr.' means print or printed. At worldcat, 'Champ vallon, impr.' is followed by a 2011 date.
—Trappist the monk (talk) 19:20, 28 November 2015 (UTC)[reply]
  • Darnton introduces and annotates the Lenoir excerpt, but the bulk of the text is Lenoir's, which is why the journal credits both of them. Still, the article is citing Darnton, so I think the citation format works. It is an oddball example. I do not see a need to support |contributor= in {{cite journal}} unless it is trivial to do so.
  • I add |accessdate= for anything I find on the web. I have no confidence that any website or archive will survive more than a few years.
  • Not a subtle hint – just wondering whether there are plans to make the sandbox version live. I keep coming across examples where I wish I could use the |contributor= parameter.
  • Worldcat, BnF etc. use "Seyssel : Champ vallon, impr.", meaning location=Seyssel; publisher=Champ Vallon; printed by the publisher. I like to show who printed it, since that could possibly affect pagination. Aymatth2 (talk) 01:34, 29 November 2015 (UTC)[reply]
Re making the sandbox version live: See the section above. That's what is meant by updating the module. – Jonesey95 (talk) 01:52, 29 November 2015 (UTC)[reply]

Cite journal and DOI vs. JSTOR

I just ran across what must be the grossest DOI yet constructed: 10.1641/0006-3568(2000)050[0262:osapct]2.3.co;2

Shoving this into {{cite journal}}'s |doi=… parameter looks, remarkably enough, to have worked just fine. However, for some journal articles, JSTOR uses the DOI as the "JSTOR number"; the stable address for a given article on JSTOR. And shoving that DOI into the |jstor=… parameter… did not go as well.

I tried following the code to see what might be up, but my Template/Module-fu is clearly too weak for the task. cite journal just #invokes CItation/CS1, and the only place there I find the string "jstor" is in a blacklist of unsupported params for {{cite arxiv}}. Help? --Xover (talk) 11:25, 30 November 2015 (UTC)[reply]

dx.doi.org translates or redirects doi identifiers to the url of the appropriate destination. Module:Citation/CS1 uri-encodes the |doi= value when it creates the doi link:
|doi=10.1641/0006-3568(2000)050[0262:osapct]2.3.co;2
https://dx.doi.org/10.1641%2F0006-3568%282000%29050%5B0262%3Aosapct%5D2.3.co%3B2
But, that encoding doesn't work for jstor which treats the '/' character as a path delimiter. Changing the uri-encoded doi identifier so that %2F becomes '/' makes a usable link:
https://www.jstor.org/stable/10.1641/0006-3568%282000%29050%5B0262%3Aosapct%5D2.3.co%3B2
The uri-encoding is necessary because the jstor value, in this case, contains [ and ] which mediawiki interprets as external link markup. To properly fix this problem, will require new code that excludes the virgule from the uri-encoding.
I will attend to this after the next update to the cs1|2 modules.
—Trappist the monk (talk) 12:54, 30 November 2015 (UTC)[reply]
Ah, thanks. The article in question has the jstor parameter commented out right now, so I'll just leave it like that until this is fixed. --Xover (talk) 13:11, 30 November 2015 (UTC)[reply]

What do I do with Journal date as March 2014? date=2014-03-01?

The citation templates are generated red text if day of month is not specified. Perhaps it would be nice to come to consensus for guidance on this situation and put it in the styleguide. Apologies if I was too blind not to find it. For now, I am forced to lie and say it is the first day of the month, though this seems improper. -J JMesserly (talk) 19:15, 30 November 2015 (UTC)[reply]

Huh? {{cite journal|journal=Journal|author=Author|title=Title|date=March 2014}} should work, and does: Author (March 2014). "Title". Journal. {{cite journal}}: |author= has generic name (help). The format YYYY-MM-DD is ok for accessdate but should not be used for publication date. —David Eppstein (talk) 19:51, 30 November 2015 (UTC)[reply]
J JMesserly, if you link to the article you are having trouble with, we can help you better. As indicated above, |date=March 2014 should work fine. – Jonesey95 (talk) 20:55, 30 November 2015 (UTC)[reply]
Another thing to keep in mind is that for the vast majority of articles I've ran across, giving just the year is more than sufficient. The few journals that publish at an interval that makes year insufficient usually also provide full dates for their issues. And on the other hand, you very likely can't really solve this problem while keeping the month-type precision, because some journals like to "date" their issues with a season (i.e. "Spring") rather than a specific month name (i.e. "April"). The point of this data in the citation is to aid the reader in locating the intended article, and not to be a complete repository of metadata about it: if you have authors, title, journal name, volume, issue, and year (plus a couple of DOI/JSTOR/PMID/Bibcode-style identifiers), the reader has a myriad ways to look it up at need; distinguishing on month or season (which is normally redundant with Issue number) is in practice never needed. Nice, but not necessary. --Xover (talk) 07:15, 1 December 2015 (UTC)[reply]
Thanks for both of your remarks. The citations for date= field are YYYY-MM-DD in that particular article, and in general I follow whatever date format style the article authors have chosen. I know that isn't a rule- just a guideline, but somehow I got tunnel visioned into wondering if there was some trick to do YYYY-MM that wouldn't freak out the citation template's correctness code. But I am snapped out of it now. Doing Month YYYY is better than lying. Thanks for talking me down off the ledge. J JMesserly (talk) 23:17, 3 December 2015 (UTC)[reply]

Cite sign

Template:Cite sign says to "Copy a blank version to use," as do all the cite template docs, except that unlike the others "cite sign" does not actually provide a blank version to use. Is this supposed to be auto-generated? How do we get this fixed? Kendall-K1 (talk) 03:18, 1 December 2015 (UTC)[reply]

Errata, or multiple DOIs

A suggestion: I've noticed that for some fields (e.g. astronomy, astrophysics), the publication of errata more or less alongside, but in a separate journal article (with separate DOI) from the original, is common. I've seen various ways people have tried to address this (putting them in separate cites for instance, or, in the immediate example, trying to stuff both DOIs into the same |doi=doi param separated by a plus sign), but they all strike me as slightly suboptimal. So I'm thinking it might be a good idea to have some explicit support for indicating an errata for a given cite.

The first-pass, version 0.1, of that might simply be an |errata=doi parameter that spits out a help text, similar to what |registration=y does, saying "Errata available".

I'm sure more sophisticated versions are also possible, but I don't really have a clear idea of what they'd be. I'm also sure Wikipedia can get by just fine using separate citations for the main article and erratum for a long while yet (Wikidata will, I'm sure, bring many changes in approach to this class of problems), but the current state of affairs just feels horribly inelegant.

Thoughts? --Xover (talk) 06:49, 1 December 2015 (UTC)[reply]

Can you give an example from a WP article? Does the errata page link to the original article?
You could put an errata link outside the citation but inside the <ref>...</ref> tags for now. – Jonesey95 (talk) 06:57, 1 December 2015 (UTC)[reply]
For reference, and also to illustrate why using separate refs (main + errata) for this, the citation that immediately precipitated this suggestion, is:
  • The LIGO Scientific Collaboration; Abbott, B.; Abbott, R.; Adhikari, R.; Ajith, P.; Allen, B.; Allen, G.; Amin, R.; Anderson, S. B.; Anderson, W. G.; Arain; Araya, M.; Armandula, H.; Armor, P.; Aso, Y.; Aston, S.; Aufmuth, P.; Aulbert, C.; Babak, S.; Ballmer, S.; Bantilan; Barish, B. C.; Barker, C.; Barker, D.; Barr, B.; Barriga, P.; Barton, M. A.; Bastarrika, M.; Bayer, K.; Betzwieser, J. (2008). "Beating the spin-down limit on gravitational wave emission from the Crab pulsar". Astrophys.J.:,; Erratum-ibid :L203-L204,2009. 683 (706): L45–L50. arXiv:0805.4758. doi:10.1086/591526+10.1088/0004-637X/706/1/L203.
Having up to 30 authors is not uncommon on articles in this field (I've seen similar in medicine too). As you can see the DOI link is broken here because the editors have attempted to put both DOIs into the parameter. The two correct links would be doi:10.1086/591526 and doi:10.1088/0004-637X/706/1/L203. In this particular case there is a backlink to the original article from the errata article, but this is not universal (depends entirely on the particular publisher). Incidentally, you can also see the Wikipedia editors have tried to shoehorn more information into various fields to account for the errata (in the |journal= parameter) which would be nice to be able to support in a structured way. --Xover (talk) 11:32, 1 December 2015 (UTC)[reply]
A nifty trick I learned at WikiConferenceUSA was how to list multiple OCLC control numbers in a single citation using |id={{oclc}}. For example, two possible OCLC numbers refer to a Michigan state highway map printed in December 1927: 12701195 and 79754957. By using |id= {{oclc|12701195|79754957}} in the citation, it lists both as: OCLC 12701195, 79754957. This trick works for three OCLC numbers as well. If {{doi}} had similar support, the same workaround would work here as well.
That said, a variation of that would work, putting the main DOI in |doi= and inserting the errata DOI into |id={{doi}}. I just don't know if that would be confusing or not. Imzadi 1979 → 07:01, 1 December 2015 (UTC)[reply]
Hmm. That reminds me of another issue. A lot of journals have multiple ISSNs; typically one for the print edition, and one for online access ("eISSN"). This would also be a nice thing to have directly supported in the Cite templates. This could either be something like |issn= and |eissn=, or |issnX=label (like for last1/first1, and with a label like "online" or "print"). --Xover (talk) 11:32, 1 December 2015 (UTC)[reply]
The cs1|2 templates are designed, intended, to render a citation for a single source. Adding functionality that stretches that definition should not be considered. In the Abbott, et al. example of a journal article and an erratum we have slightly different titles, possibly different authors, different volumes, different page numbers, different doi, different date, possibly different other stuff. If errata are worth citing, they should be cited properly.
I have thought about adding support for |eissn=. That identifier is supported in the metadata and it should be relatively easy to implement as a more-or-less-clone of existing issn code.
—Trappist the monk (talk) 13:24, 1 December 2015 (UTC)[reply]
My feeling is that we should not support issn as a parameter, because we should almost always not include issns in citations. The purpose of an issn is to disambiguate journals with ambiguous titles (the issn is an identifier for the journal, not for the paper within the journal) but most journal titles are not ambiguous and even for those that are, other parts of the citation (like publisher=) are better ways to disambiguate them. —David Eppstein (talk) 17:18, 1 December 2015 (UTC)[reply]
(re David) We need ISSNs as a structured identifier for the journal, for the same reason we need structured identifiers (DOI, JSTOR id, PMID, Bibcode, arXiv id, etc.) for articles, even though they are in principle redundant with the article title: humans and systems are imperfect, and specific circumstances have specific requirements. Having gone through ~500 articles over the last couple of weeks trying to fix broken citations I can tell you with absolute conviction and 100% certainty that such redundancy is critical for rescuing refs where there is either insufficient bibliographic information provided by the original editor, or where some external factor has rendered one of the identifiers unresolvable. An easy example: a cite using |url= to a transient address on jstor.org, and a DOI that is currently non-resolvable on doi.org, with very few other cite parameters filled in. If the original editor had botched the journal name (not infrequent), this cite would have been near impossible to salvage without an ISSN that can help you find the right journal to look up the volume/issue numbers in. For citations, redundancy is good! That our current ISSN search (unstructured search of Worldcat) is fairly limited is an argument to improve the search and indexing function, not dropping ISSNs. --Xover (talk) 19:03, 1 December 2015 (UTC)[reply]
(re Trappist) For the case where you're actually specifically citing something in the errata, yes, I agree, you should cite the errata separately. But for a lot of cases you perhaps just want to make readers aware that errata exists; possibly because you're not the original author of the Wikipedia article and can't easily tell whether the errata directly invalidates or modifies the statement the citation supports (I sure as heck can't tell in astrophysics articles). At the level we're often summarising, a cite's errata doesn't really need to necessitate changes in our article, but still be highly relevant to a reader's correct understanding. In other words, while I appreciate and agree with the purity of the design goal in principle, I think this may be one of those grey areas where making the box slightly more roomy is warranted. I don't think there is a critical need for this functionality in any short term, and we certainly should avoid letting cruft accumulate uncritically both in the template code and in ever more complex markup in articles, but, in my opinion, it's worthwhile enough to keep in mind for consideration slightly longer term, and it's not sufficiently incompatible with the defined scope of the citation templates to merit immediate dismissal. --Xover (talk) 19:03, 1 December 2015 (UTC)[reply]
Last week's Science has an interesting article on the hijacking of journal websites. One of the way this happens is by creating websites with deliberately ambiguous titles. While an ISSN won't help if the real website gets hijacked, they can help distinguish very similar names. Especially where an initial editor may be unclear or careless about a name. ~ J. Johnson (JJ) (talk) 00:03, 2 December 2015 (UTC)[reply]
ISSNs are also used for newspapers and magazines, not just journals. If I include the ISSN for a newspaper, especially for an article not available online, then the reader can locate a library that has that paper within its holdings. It may be redundant to a DOI or other identifier, but it's nice to be consistent about listing ISSNs. Imzadi 1979 → 00:51, 2 December 2015 (UTC)[reply]

Not-quite-right error message when last=, first=, and authors= all exist?

I found what looks like an erroneous error message in a citation in the wild:

Cite book comparison
Wikitext {{cite book|authors=Dick Dietrich|first=Joseph|isbn=978-0-89658-122-7|last=Arrigo|location=Stillwater, MN|pages=37–39|publisher=Voyageur Press|title=Louisiana's Plantation Homes: The Grace and Grandeur|year=1991}}
Live Arrigo, Joseph (1991). Louisiana's Plantation Homes: The Grace and Grandeur. Stillwater, MN: Voyageur Press. pp. 37–39. ISBN 978-0-89658-122-7. {{cite book}}: Unknown parameter |authors= ignored (help)
Sandbox Arrigo, Joseph (1991). Louisiana's Plantation Homes: The Grace and Grandeur. Stillwater, MN: Voyageur Press. pp. 37–39. ISBN 978-0-89658-122-7. {{cite book}}: Unknown parameter |authors= ignored (help)

The citation contains |last=, |first=, and |authors=, which is an error, but the error message strikes me as difficult for a civilian to understand. For the record, what I see in both the live cite book template and in the sandbox version is "More than one of author-name-list parameters specified".

The citation places the article in Category:Pages with citations having redundant parameters, which is correct. – Jonesey95 (talk) 03:28, 2 December 2015 (UTC)[reply]

There are three kinds of author-name-list: |authors=, |vauthors=, and |author=/|last=. This error message attempts to distinguish redundant author-name-lists from redundant aliases. There is also a version of this error message for the three kinds of editor-name-list.
Is there a better error message?
—Trappist the monk (talk) 11:58, 2 December 2015 (UTC)[reply]
I am hoping, though I expect the programming might be a challenge, for "More than one of authors= / last= parameters specified" or something similar, to guide editors toward identifying the problem better. – Jonesey95 (talk) 15:09, 2 December 2015 (UTC)[reply]
I have modified the help text to include this error message.
—Trappist the monk (talk) 18:38, 2 December 2015 (UTC)[reply]
Thanks. That works for me. – Jonesey95 (talk) 20:01, 2 December 2015 (UTC)[reply]

Discussion about use of authors= parameter

Except that the example above uses |authors= (the plural form), which invites stuffing multiple author names into a single parameter, and is an error in itself. And while we all understand (right?) that mulitiple |authorN= (or 'lastN') parameters with different values of N are not redundant, an inexperienced editor might reasonably read "More than one of author= ..." as precluding author1=, author2=, etc. I suggest something like "Use of author(n)= conflicts with a corresponding last(n)=." Not a complete enumeration of all possibilities, but less misleading, and the fine details can be explained at the Help. ~ J. Johnson (JJ) (talk) 20:57, 2 December 2015 (UTC)[reply]
|authors= is close to the right idea. All one needs to do is replace |authors= with |vauthors= Dietrich D, Arrigo J ;-) Mulitiple |authorN= parameters are needlessly redudant. Boghog (talk) 21:19, 2 December 2015 (UTC)[reply]
Right. :-) ~ J. Johnson (JJ) (talk) 21:40, 3 December 2015 (UTC)[reply]
Which results in the loss of the last name. Sometimes |authors= is correct. (Though IMO |authorN= is more correct because that also ensures good metadata--most correct IMO is of course the version which doesn't assume formatting i.e. |firstN= |lastN=.) --Izno (talk) 21:44, 2 December 2015 (UTC)[reply]
|vauthors= Dietrich D, Arrigo J also insures good meta data. The last name is not lost. Did you mean first name which is replaced by an initial? Boghog (talk) 03:56, 3 December 2015 (UTC)[reply]
Indeed, the first. --Izno (talk) 13:54, 3 December 2015 (UTC)[reply]
I allow (grudgingly) |vauthors= on the basis of the specified list of authors being in restricted format ("Vancouver style") that (if properly observed) permits recovery of the authors' last names. However, that does not apply to |authors=, which has no such format, and generally indicates a weak understanding of citation and/or sloppy usage. Indeed, use of |authors= (as well as |coauthors= should be deprecated, and warrants its own error message. ~ J. Johnson (JJ) (talk)
I also dislike |authors= for the same reasons. But I think the solution is a maintenance category rather than deprecation and an error message. The reason is that I think we should make it easy for new editors to start using the citation templates rather than formatting citations manually, and learning the minutiae of how to separate author names into lots of little separate parameters is one of the things that I think makes these templates not easy to use. —David Eppstein (talk) 22:37, 3 December 2015 (UTC)[reply]
I have added a subheader to this forked discussion, since it is about a topic other than the error message itself. If you think that |authors= should be treated in a new way, please start a separate thread. – Jonesey95 (talk) 01:22, 4 December 2015 (UTC)[reply]

We can't properly formulate an error message until we determine what the error is. And the example at the top, using |authors=, is handled differently than with |author=, |coauthor=, or |coauthors=:

Cite book comparison
Wikitext {{cite book|author=Dick Dietrich|first=Joseph|isbn=978-0-89658-122-7|last=Arrigo|location=Stillwater, MN|pages=37–39|publisher=Voyageur Press|title=Louisiana's Plantation Homes: The Grace and Grandeur|year=1991}}
Live Arrigo, Joseph (1991). Louisiana's Plantation Homes: The Grace and Grandeur. Stillwater, MN: Voyageur Press. pp. 37–39. ISBN 978-0-89658-122-7. {{cite book}}: More than one of |author= and |last= specified (help)
Sandbox Arrigo, Joseph (1991). Louisiana's Plantation Homes: The Grace and Grandeur. Stillwater, MN: Voyageur Press. pp. 37–39. ISBN 978-0-89658-122-7. {{cite book}}: More than one of |author= and |last= specified (help)
Cite book comparison
Wikitext {{cite book|coauthor=Dick Dietrich|first=Joseph|isbn=978-0-89658-122-7|last=Arrigo|location=Stillwater, MN|pages=37–39|publisher=Voyageur Press|title=Louisiana's Plantation Homes: The Grace and Grandeur|year=1991}}
Live Arrigo, Joseph (1991). Louisiana's Plantation Homes: The Grace and Grandeur. Stillwater, MN: Voyageur Press. pp. 37–39. ISBN 978-0-89658-122-7. {{cite book}}: Unknown parameter |coauthor= ignored (|author= suggested) (help)
Sandbox Arrigo, Joseph (1991). Louisiana's Plantation Homes: The Grace and Grandeur. Stillwater, MN: Voyageur Press. pp. 37–39. ISBN 978-0-89658-122-7. {{cite book}}: Unknown parameter |coauthor= ignored (|author= suggested) (help)
Cite book comparison
Wikitext {{cite book|coauthors=Dick Dietrich|first=Joseph|isbn=978-0-89658-122-7|last=Arrigo|location=Stillwater, MN|pages=37–39|publisher=Voyageur Press|title=Louisiana's Plantation Homes: The Grace and Grandeur|year=1991}}
Live Arrigo, Joseph (1991). Louisiana's Plantation Homes: The Grace and Grandeur. Stillwater, MN: Voyageur Press. pp. 37–39. ISBN 978-0-89658-122-7. {{cite book}}: Unknown parameter |coauthors= ignored (|author= suggested) (help)
Sandbox Arrigo, Joseph (1991). Louisiana's Plantation Homes: The Grace and Grandeur. Stillwater, MN: Voyageur Press. pp. 37–39. ISBN 978-0-89658-122-7. {{cite book}}: Unknown parameter |coauthors= ignored (|author= suggested) (help)

Which error are addressing? ~ J. Johnson (JJ) (talk) 22:18, 4 December 2015 (UTC)[reply]

None of these examples match the example I introduced at the top of this discussion section. Trappist explained the error, which is that of using multiple author lists simultaneously. The examples immediately above are redundant parameter errors, a different category of error.
The error I was addressing was the use of |authors= and |last= in the same citation, which generates an error message that I thought was unclear. Using those two parameters in the same citation is a syntax error, a parameter conflict that hides information that editors presumably want to display. Trappist has since modified the help text linked from the error message, and I am satisfied with that resolution.
After I expressed my satisfaction with that resolution, a new discussion, on a new topic, was begun. That topic was whether |authors= was a valid parameter. Hence the new subheading. – Jonesey95 (talk) 06:24, 5 December 2015 (UTC)[reply]
As I pointed out before, any kind of "More than one of [author] parameters" message can be reasonably interpreted as precluding use of author1=, author2=, etc. But if the use of |authors= is deprecated, than it can use the same message as |coauthors= (my last example), and we don't need to craft any kind of special message. There would still be a matter of author/last conflict, but that is not the example you presented. ~ J. Johnson (JJ) (talk) 21:20, 5 December 2015 (UTC)[reply]

Contributor when authors are not listed

The new |contributor= parameter is really useful. But while putting it into recently-started articles I found an oddball case with a collection of children's verse edited by Armand Got. François Albert wrote the preface. The BnF entry is here. The authors of the poems are not listed. If we try to cite Albert's preface using |contributor= we get an error:

  • {{cite book|ref=harv|title=La Poèmeraie: Anthologie moderne |contributor-first=François |contributor-last=Albert|contributor-link=François Albert|contribution=preface|others=A. M Gossez, foreword; Edmond Rocher, illustrations|location=Paris|publisher=libr. Gedalge|year=1927|editor=Armand Got}}
Armand Got, ed. (1927). "preface". La Poèmeraie: Anthologie moderne. A. M Gossez, foreword; Edmond Rocher, illustrations. Paris: libr. Gedalge. {{cite book}}: |contributor= requires |author= (help); Invalid |ref=harv (help)

A workaround is to use |chapter= as

  • {{cite book|ref=harv|title=La Poèmeraie: Anthologie moderne |author-first=François |author-last=Albert|author-link=François Albert|chapter=preface|others=A. M Gossez, foreword; Edmond Rocher, illustrations|location=Paris|publisher=libr. Gedalge|year=1927|editor=Armand Got}}
Albert, François (1927). "preface". In Armand Got (ed.). La Poèmeraie: Anthologie moderne. A. M Gossez, foreword; Edmond Rocher, illustrations. Paris: libr. Gedalge. {{cite book}}: Invalid |ref=harv (help)

The quotes around "preface" seem awkward; Albert's contribution is not really "in" the anthology, but precedes it; Armand Got is not shown as editor. A different workaround is to replace |editor=Armand Got by |author=Armand Got, ed.

  • {{cite book|ref=harv|title=La Poèmeraie: Anthologie moderne |contributor-first=François |contributor-last=Albert|contributor-link=François Albert|contribution=preface|others=A. M Gossez, foreword; Edmond Rocher, illustrations|location=Paris|publisher=libr. Gedalge|year=1927|author=Armand Got, ed.}}
Albert, François (1927). preface. La Poèmeraie: Anthologie moderne. By Armand Got, ed. A. M Gossez, foreword; Edmond Rocher, illustrations. Paris: libr. Gedalge. {{cite book}}: |author= has generic name (help); Invalid |ref=harv (help)

That does not look quite right either, and messes up the metadata. But these are minor quibbles. Maybe the |chapter= workaround is good enough. The scenario seems unusual. Aymatth2 (talk) 17:02, 5 December 2015 (UTC)[reply]

It seems to me that either an author or an editor should be required with contributor, i.e. the following should be accepted: {{cite book |editor-last=Got |editor-first=Armand |date=1927 |title=La poèmeraie : anthologie moderne |publisher=Gedalge |publication-place=Paris |contribution=Préface |contributor-last=Albert |contributor-first=François }}. Peter coxhead (talk) 17:21, 5 December 2015 (UTC)[reply]
  • I came across one case where there was a contributor but no author or editor. It was a program for a series of conferences with a preface by a named contributor, but with the person who assembled the program unnamed. The publisher was the group running the conference. Aymatth2 (talk) 17:47, 5 December 2015 (UTC)[reply]

Null character error message appearing in citations.

After latest module update? Currently looking @ {{interp}} syntax.

Markup Renders as 
{{cite book|title=Title|quote={{interp|this is}} ... a brief quote}}

Title. [this is] ... a brief quote

Markup Renders as 
{{cite book|title=Title|quote=a brief quote}}

Title. a brief quote

65.88.88.75 (talk) 20:49, 5 December 2015 (UTC)[reply]

Also with {{hdl}}. This behavior is new. Non-printable chars in these templates' code did not generate an error previously.
Markup Renders as 
{{cite book|title=Title|id={{hdl|00000/0000}}}}

Title. hdl:00000/0000.

65.88.88.75 (talk) 21:18, 5 December 2015 (UTC)[reply]

{{interp}} causes the cs1|2 invisible character error message because it has <nowiki>&#91;</nowiki> and <nowiki>&#93;</nowiki>. It isn't clear to me that the <nowiki>...</nowiki> tags are necessary since the html entities for the square brackets aren't wikimarkup. I think then, that {{interp}} is where changes should be made; not here.
<nowiki>...</nowiki> tags are also the culprit in the case of {{hdl}}. There, the first unnamed parameter or |id= is wrapped in <nowiki>...</nowiki> tags because handle system identifiers can be pretty much any printable character including characters that MediaWiki uses for markup:
{{#tag:nowiki|{{{1|{{{id}}}}}}}}
I wonder if cs1|2 should support hdl identifiers in the same way that it supports doi and others. Identifier syntax is defined here:
hdl identifier syntax
The <nowiki>...</nowiki> tags are problematic because they are converted to stripmarkers before Module:Citation/CS1 gets the template parameters. When the module creates metadata from template parameters, the stripmarkers are included. So, this
{{cite book |title=c<nowiki>|</nowiki>net}}
renders like this:
c|net.
and produces this metadata for &rft.btitle:
c%7FUNIQ--nowiki-00000019-QINU%7Fnet
Replacing, in this example case, <nowiki>|</nowiki> with &#124; is slightly better because it is possible for a metadata user to decode the percent-encoded characters in &rft.btitle=c%26%23124%3Bnet and arrive at what lies between 'c' and 'net'. That is not possible with the stripmarker.
—Trappist the monk (talk) 23:33, 5 December 2015 (UTC)[reply]

Is there a pending fix or workaround for this new wrinkle? Many citations use {{'}} or {{'s}} or <nowiki>'</nowiki> for a possessive titles like "The Force Awakens' BB-8" to avoid improper bold or italics which otherwise occurs (see citation 5 in this version of BB-8 (Star Wars)). Obviously {{em}} could be implemented in each one of these instances instead, but we're probably talking about hundreds (if not more) citations that now would need to be fixed. What's the reasoning behind the change??— TAnthonyTalk 07:54, 6 December 2015 (UTC)[reply]

So <nowiki> is now outlawed from citation parameters? This seems like a major change with likely many unwanted consequences. Where is the discussion that approved it? —David Eppstein (talk) 08:20, 6 December 2015 (UTC)[reply]
I think that the module is overreaching at this point and that we may need to comment out the "C0 control character" portion of the test while we experiment in the sandbox with how to get decent metadata while allowing reasonable formatting of parameter values.
We are also overdue for a robust page of testcases to catch weird stuff like this when we make changes to the sandbox. Anybody want to volunteer to start putting one together or building on an existing page? – Jonesey95 (talk) 08:29, 6 December 2015 (UTC)[reply]

I think that I have found a way around the <nowiki>...</nowiki> stripmarker issue:

Cite book comparison
Wikitext {{cite book|title=c|net}}
Live c|net.
Sandbox c|net.

This also makes for better metadata. With this change, the title in the metadata is:

&rft.btitle=c%7Cnet

—Trappist the monk (talk) 13:17, 6 December 2015 (UTC)[reply]

Checking to see if these sandbox changes improve {{interp}} and {{hdl}}:
Markup Renders as 
{{cite book/new|title=Title|quote={{interp|this is}} ... a brief quote}}

Title. [this is] ... a brief quote

Markup Renders as 
{{cite book/new|title=Title|id={{hdl|00000/0000}}}}

Title. hdl:00000/0000.

That looks better to me.– Jonesey95 (talk) 15:32, 6 December 2015 (UTC)[reply]
Not a good fix so I have undone it. If I wrap something in <nowiki>...</nowiki>, I expect that its contents won't be manipulated by any template or module, or by MediaWiki. For my simple example of wrapping a pipe, the fix worked well enough because once the template was parsed, the pipe is just a character. But, something like a url or a wikilink is manipulated by MediaWiki after the module returns. So writing this:
{{cite book |title=<nowiki>http://example.com</nowiki>}}
the fix would replace the strip markers with the url and then hand that off to MediaWiki which dutifully renders the url as an active link. Not good.
What this fix can do, if applied only to parameters made part of the metadata, is to keep the stripmarkers out of the metadata. Without the fix to the metadata code, the title metadata for this example template is:
&rft.btitle=%7FUNIQ--nowiki-0000002F-QINU%7F
and with the fix:
&rft.btitle=http%3A%2F%2Fexample.com
I've modified the invisible character test to look specifically for the nowiki stripmarker. If found, it is ignored (no error message) and the test continues. Delete characters are ignored when a stripmarker is detected but all of the other tests function normally. Stripmarkers introduced by <ref>...</ref> or other tags are marked as delete character errors:
{{cite book/new |title=Title<ref>A reference</ref> |quote=Some long rambling quotation.<ref>A reference</ref>}}
Title[1]. Some long rambling quotation.[2] {{cite book}}: ref stripmarker in |quote= at position 30 (help); ref stripmarker in |title= at position 6 (help)
—Trappist the monk (talk) 13:13, 7 December 2015 (UTC)[reply]
I wonder whether this broke |title=none

{{cite book|title=none}} produces none.

— Preceding unsigned comment added by 71.247.146.98 (talk • contribs) 23:56, 7 December 2015‎ (UTC)[reply]
{{cite book}} has never supported |title=none.
—Trappist the monk (talk) 00:15, 8 December 2015 (UTC)[reply]

In passing, since it was mentioned above: the hdl identifier used to be supported several years ago in the old {{citation/core}}. I've no idea why it was removed, but I suspect the identifier's native tolerance for characters incompatible with mediawiki. 72.43.99.130 (talk) 19:56, 8 December 2015 (UTC)[reply]

"Zero width space character" error when using ' and 's templates in citation

This is mentioned above, but it might get lost without its own subsection. When {{'}} or {{'s}} are used in citations to properly italicize part of a |title= or make the name of a work possessive within a |title=, a "zero width space character" error is displayed. The examples below use {{'}} and {{'s}}, respectively, in |title=:

Cite web comparison
Wikitext {{cite web|accessdate=9 May 2011|publisher=[[AllMusic]]|title=''<span class="nowrap" style="padding-left:0.1em;">'</span>64–'95'' Overview|url=https://www.allmusic.com/album/r727532}}
Live "'64–'95 Overview". AllMusic. Retrieved 9 May 2011.
Sandbox "'64–'95 Overview". AllMusic. Retrieved 9 May 2011.
Cite web comparison
Wikitext {{cite web|title=''Who's Next''<span class="nowrap" style="padding-left:0.1em;">'s</span> use in car commercials|url=http://www.example.com|work=Rolling Stone}}
Live "Who's Next's use in car commercials". Rolling Stone.
Sandbox "Who's Next's use in car commercials". Rolling Stone.

I don't have a suggested fix at this time.

p.s. It appears that the sandbox also capitalizes |Title= in the error message, which is not right. – Jonesey95 (talk) 15:49, 6 December 2015 (UTC)[reply]

If one believes {{'}}, then the error message that we're seeing should read 'zero width joiner', not 'zero width space' The code at {{'}} is:
&zwj; '
Zero width joiner wasn't one of the invisible characters that the module detected yet it was detecting zero width space. To see what is going on, I simplified the first example compare in this section:
{{cite book |title={{'}}64}}
'64.
I then highlighted and copied the title from the rendered citation and pasted it into the green box on this Unicode code converter website. I clicked the convert button just above the green box and goth this UTF-8 result:
E2 80 8D E2 80 8A 27 E2 80 8B 36 34
and this Unicode result:
U+200D U+200A'U+200B64
Six characters that should have been 4 characters. Reading the UTF-8 left to right:
E2 80 8D zero width joiner character (positions 1–3)
E2 80 8A hair space character (positions 4–6)
27 apostrophe (position 7)
E2 80 8B zero width space character (positions 8–10)
36 the '6' character (position 11)
34 the '4' character (position 12)
Replacing {{'}} in the simplified template with a an apostrophe and repeating the experiment:
{{cite book |title='64}}
'64.
gives:
27 36 34 (in UTF-8, 27 is the apostrophe, 36 is 6, and 34 is 4);
'64 (Unicode)
I don't know where the hair space and zero width space are coming from. They are not part of the module and not part of the template so someplace in MediaWiki?
—Trappist the monk (talk) 23:42, 6 December 2015 (UTC)[reply]
The hair space and the zero-width space are part of the template, apparently. Copy the template's wikicode into the Unicode converter including the semicolon and the left angle bracket. I get ;U+200A'U+200B<.
You can also see the zero-width space if you click to place your cursor next to the semicolon, then move to the right with the right arrow key. You will see that there is an invisible character after the apostrophe. – Jonesey95 (talk) 00:18, 7 December 2015 (UTC)[reply]
Well done. I hacked the {{'}} sandbox to replace the zero width and hair space characters with their numeric character reference equivalents. Using the sandbox in the simplified example:
{{cite book |title={{'/sandbox}}64}}
'64.
'"`UNIQ--templatestyles-00000128-QINU`"'<cite class="citation book cs1">''<span class="nowrap" style="padding-left:0.1em;">&#39;</span>64''.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=%2764&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1" class="Z3988"></span>
No error because there aren't any invisible characters when the module examines the content of |title=; what it sees is:
&zwj;&#x200A;'&#x200B;64
though that does bugger-up the metadata.
—Trappist the monk (talk) 01:22, 7 December 2015 (UTC)[reply]
Did that cause this?

{{cite news|title=none|newspaper=Newspaper}} now displays "none". Newspaper.

— Preceding unsigned comment added by 71.247.146.98 (talk • contribs) 23:56, 7 December 2015‎ (UTC)[reply]
No. |title=none is supported only by {{citation}} when using |journal= and by {{cite journal}}. |title=none allows cs1|2 to support a particularly brief form of abbreviated academic journal citation style.
—Trappist the monk (talk) 00:15, 8 December 2015 (UTC)[reply]
Just to add a bit on this style: I know it's popular in academic publications in some scientific disciplines but I don't like it. Using this style makes it much more difficult to search for the citation in e.g. Google scholar since the author names are usually not unambiguous by themselves. So I'm torn on supporting it here. On the one hand, as long as we don't mandate a single citation style we should allow anything reasonably consistent within an individual article. On the other hand, I don't want more editors thinking it's a good style and being encouraged to use it. —David Eppstein (talk) 00:21, 8 December 2015 (UTC)[reply]

I have modified the invisible character test so that it detects the transcluded value of {{'}} and added a test for hair space. When {{'}} is detected, it is ignored. The subsequent tests for zero-width joiner, zero-width space, and hair space are disabled when {{'}} is detected. Because {{'s}} uses {{'}}, that template's transclusion is also 'fixed'; see the comparisons at the top of this section.

—Trappist the monk (talk) 12:35, 8 December 2015 (UTC)[reply]

One of the problems with templates within cs1|2 templates is that they can and do bugger-up the metadata. The metadata for a title using {{'s}}:

|title=Title{{'s}}

looks like this:

&rft.btitle=Title%26zwj%3B%26zwj%3B%E2%80%8A%27%E2%80%8B%26zwj%3Bs

So, I've added a bit of code at the same place where we replace stripmarkers to remove or replace, as appropriate, certain html entities and invisible characters:

replace {{'}} with apostrophe character
replace &nbsp; entity with plain space
remove &zwj; entities
remove zero-width joiner and zero-width space characters
replace soft hyphen, horizontal tab, line feed, carriage return with plain space
replace hair space with plain space – not sure about this one; is it really a 'space' or a device to slightly tweak the position of the following character?

Now, the metadata for my example looks like this:

&rft.btitle=Title%27s

—Trappist the monk (talk) 14:27, 8 December 2015 (UTC)[reply]

Is this fixed? I see the errors at The Royals (TV series). Thanks.— TAnthonyTalk 07:04, 10 December 2015 (UTC)[reply]
Yes. In the sandbox.
—Trappist the monk (talk) 14:00, 10 December 2015 (UTC)[reply]

Spurious 'Check |url= value' error?

"A working url showing an error".

"The same url modified to suppress the error".

... but obviously this breaks the link. The issue seems to be that single-letter hostnames are rejected as invalid.

I have two more or less separate areas of concern:

  1. URI validity and validation.
    • Are single-letter hostnames valid? Possibly not, but the host concept in the URI spec is more general so this restriction on DNS host names may be irrelevant in general.
    • Regardless of their formal validity should cite ref validation accept them as valid? IMO yes, but I won't argue.
    • If cite ref should reject them what is the right way to handle the situation?
  2. Documentation at Help:CS1_errors
    • The warning links to documentation for a |url= scheme error not a |url= value error. Is this a distinct error message or has the documentation just fallen behind the current error text?
    • The documentation does not describe the hostname length limit.

It shouldn't matter, but for the record my real-world encounter with this issue was here. I hope that all makes sense.

TuxLibNit (talk) 01:46, 6 December 2015 (UTC)[reply]

As I read RFC 952 and RFC 1123, single letter domain names are not allowed. You would think that if they were, someone would have http://www.a.com but following that link leads nowhere. The i. portion of i.word.com is a sub-domain, not a hostname. User documentation can always be improved and almost always lags behind the tool. Point taken about the error message name and help-text mismatch; that's the documentation lag again.
—Trappist the monk (talk) 12:09, 6 December 2015 (UTC)[reply]
Thanks for your sandbox fix. I've updated Help:CS1_errors#bad_url to document the current temporary situation, more for the issue with relative references containing colons (potentially widespread in |archive-url=), than my obscure single letter name issue.
TuxLibNit (talk) 22:06, 6 December 2015 (UTC)[reply]
In what sense is "i.word.com" a single character, anyway? —David Eppstein (talk) 01:58, 6 December 2015 (UTC)[reply]
That's not, but the hostname, i, is. Rebbing (talk) 03:02, 6 December 2015 (UTC)[reply]
Nice write-up. I just had the same problem here. I think it's unreasonable for Cite to reject single-character hostnames: they're used by many popular websites (https://m.facebook.com comes to mind) and Cite's purpose is to link to resources, not to police standards. It looks like this could be cleared up by adding another clause to the if statement in is_domain_name:
<pre>
--- old/Module:Citation/CS1	2015-12-05 08:10
+++ new/Module:Citation/CS1	2015-12-06 01:48
@@ -209,7 +209,9 @@ local function is_domain_name (domain)
 	
 	domain = domain:gsub ('^//', '');											-- strip '//' from domain name if present; done here so we only have to do it once
 	
-	if domain:match ('^[%a%d][%a%d]+%.%a') then									-- two character hostname and tld
+	if domain:match ('^[%a%d]+%.%a') then										-- one character hostname and tld
+		return true;
+	elseif domain:match ('^[%a%d][%a%d]+%.%a') then								-- two character hostname and tld
 		return true;
 	elseif domain:match ('^[%a%d][%a%d%-]+[%a%d]%.[%a%d]') then					-- three or more character hostname.hostname or hostname.tld
 		return true;
</pre>
Rebbing (talk) 03:02, 6 December 2015 (UTC)[reply]

Getting the url check to work properly has been a challenge. I think that I have resolved this problem in the sandbox:

{{cite web/new |title=A working url (not) showing an error |url=http://i.word.com/idictionary/syzygy}}
"A working url (not) showing an error".
{{cite web/new |title=fail:single char hostname |url=http://a.com}}
"fail:single char hostname". {{cite web}}: Check |url= value (help)
{{cite web/new |title=pass: protocol relative with embedded url |url=//web.archive.org/web/20150928232230/http://transition.fcc.gov/pshs/services/911-services/}}
"pass: protocol relative with embedded url".

Find other templates that show an error for valid urls, edit the cite template to use the sandbox (append '/new' to the template name), click Show preview (do not save). Report any valid urls here.

—Trappist the monk (talk) 12:09, 6 December 2015 (UTC)[reply]

It shouldn't be done arbitrarily for at least ccTLDs without further investigation:
{{cite web/new |title=should-pass: Amazon China |url=http://z.cn}}
"should-pass: Amazon China".
Liangent (talk) 01:31, 9 December 2015 (UTC)[reply]
See also Single-letter second-level domain. This seems to overwhelmingly produce false positives and I suggest it is switched completely off in live templates until it isn't badly broken. Many confused editors are wasting time trying to get rid of these useless error messages. I examined around 30 cases from a search on "Check url= value" and didn't find a single case where the url was wrong. PrimeHunter (talk) 13:00, 9 December 2015 (UTC)[reply]
I have tweaked the test to recognize single-letter second-level domains when the URL:
uses a two-character TLD that could be a ccTLD (not checked to be a country code listed at https://www.iana.org/domains/root/db); or
has .org TLD; or
is i.net and q.net; or
is q.com, x.com, and z.com
also revised so any TLD of 2 or more letters is recognized to support gTLDs
"about.museum".
—Trappist the monk (talk) 15:54, 9 December 2015 (UTC)[reply]
According to the article, the following single letter GTLD names are in use: q.com, x.com, z.com, i.net, q.net, c.org, v.org, w.org, x.org, and the rest of the .org ones are available. Rwessel (talk) 16:20, 9 December 2015 (UTC)[reply]
I'm not sure what your point is. The sandbox code recognizes all of the domain names you listed.
—Trappist the monk (talk) 16:57, 9 December 2015 (UTC)[reply]
Nevermind, misread your list. Rwessel (talk) 17:02, 9 December 2015 (UTC)[reply]
I am worried that this test is too restrictive and will continue to result in false positives. There are tons of new TLDs. I find it hard to imagine that every domain registrar managing TLDs on this list will prohibit single-character second-level domain names. – Jonesey95 (talk) 21:22, 9 December 2015 (UTC)[reply]
URLs with port specified are still reported as invalid. Liangent (talk) 13:30, 13 December 2015 (UTC)[reply]
Examples? Please always do us the curtesy of providing examples when reporting problems.
—Trappist the monk (talk) 13:44, 13 December 2015 (UTC)[reply]
Port (computer networking)#Use in URLs gives http://www.example.com:8080/path/ as example:
"Title".
Real example from [1] (worked when :8080 was removed):
"The combinatorial algorithm for computing pi(x)". Dalhousie University. Retrieved 1 September 2015.
PrimeHunter (talk) 14:00, 13 December 2015 (UTC)[reply]
Ok, fixed in the sandbox I think:
{{cite web/new |title=The combinatorial algorithm for computing pi(x) |url=http://dalspace.library.dal.ca:8080/handle/10222/60524 |publisher=Dalhousie University |accessdate=2015-09-01}}
"The combinatorial algorithm for computing pi(x)". Dalhousie University. Retrieved 1 September 2015.
—Trappist the monk (talk) 14:35, 13 December 2015 (UTC)[reply]

Spurious 'Check |episodelink= value' error? in Template:cite episode

I'm note sure whether this might be related to the above discussion, but at Pan Am (TV series) I noticed a similar problem with |episodelink= in {{cite episode}} that has only appeared recently.[3] This error is appearing at multiple articles so it isn't a problem with the formatting of the citation in Pan Am (TV series). For example, all of the citations listed in Sheldon Cooper#References used to be fine. I'm not really up on Lua, but I'm wondering if the errors reported today might have something to do with recent changes to Module:Citation/CS1 by Trappist the monk.[2][3] --AussieLegend (✉) 06:07, 6 December 2015 (UTC)[reply]

Still at Pan Am (TV series), I noticed a citation that reported "zero width space character in |title= at position 58".[4] This is apparently caused by use of {{!}}, which I've seen used in many citations in the past, and which did not result in errors. In order to correct this error I've had to replace "''Pan Am''{{'}}s" with"{{em|Pan Am}}'s". I'm not sure whether this is a recently created problem, or just a coincidence. --AussieLegend (✉) 06:30, 6 December 2015 (UTC)[reply]

Yes AussieLegend, this issue with {{!}} is the same issue mentioned above in #Null character error message appearing in citations..— TAnthonyTalk 08:04, 6 December 2015 (UTC)[reply]
I'm guessing that allowing the "#" character as part of an |episode-link= value would fix the problem here. Here's a citation using a "#" character in |episode-link= using the sandbox code, which I have modified to allow the "#" character.[5] – Jonesey95 (talk) 08:22, 6 December 2015 (UTC)[reply]
Yes, that fix seems to work. It's something that is necessary because linking to individual episode entries is widely done in articles, including many outside the TV project. --AussieLegend (✉) 09:26, 6 December 2015 (UTC)[reply]
I poked through Category:CS1 errors: parameter link, which currently has 672 articles in it, and it looks like 90% or so of the articles in the category are there because of this change to the module. – Jonesey95 (talk) 17:13, 6 December 2015 (UTC)[reply]
Any chance the fix can be integrated into the official cite episode? Otherwise it'll have to be added to the help files. AngusWOOF (bark • sniff) 19:55, 6 December 2015 (UTC)[reply]
Yes. Fixes are typically tested in the sandbox before being moved to the live module. We are debugging some other changes that were introduced in the most recent set of updates. – Jonesey95 (talk) 21:07, 6 December 2015 (UTC)[reply]

References

  1. ^ A reference
  2. ^ A reference
  3. ^ "We'll Always Have Paris". Pan Am. Season 1. Episode 2. 2 October 2011. 05:56 minutes in. ABC. {{cite episode}}: Unknown parameter |episodelink= ignored (|episode-link= suggested) (help)
  4. ^ Watercutter, Angela (25 September 2011). "TV Fact-Checker: A Former Stewardess on Pan Am's Friendlier Skies". Wired. Retrieved 22 October 2011.
  5. ^ "We'll Always Have Paris". Pan Am. Season 1. Episode 2. 2 October 2011. 05:56 minutes in. ABC. {{cite episode}}: Unknown parameter |episodelink= ignored (|episode-link= suggested) (help)

Protocol-relative URLs to Internet Archive

Hello, in Hoseynabad, Jam the Template:IranCensus2006 generates a valid URL (atleast it works, inserting the URL directly in FF 42.0). Still CS1 marks this URL as "Check |archiveurl= value" (the same URL in the regular "url=" parameter also produces a similar warning message). Maybe that issue has already been mentioned somewhere else, but could someone have a look please? Should Internet Archive-URLs be protocol-relative to begin with? GermanJoe (talk) 18:10, 6 December 2015 (UTC)[reply]

This bug has been fixed in the sandbox code. When other debugging and testing is done, we will move the sandbox code to the live module. – Jonesey95 (talk) 21:10, 6 December 2015 (UTC)[reply]

See also WP:PRURL. -- GreenC 16:55, 28 December 2015 (UTC)[reply]

An essay which should probably be amended since a) Wikimedia only serves content on Wikipedia via HTTPS now and b) a number of sites quoted on said essay only want incoming links from HTTPS as well. --Izno (talk) 17:26, 28 December 2015 (UTC)[reply]

Delete "Pages with citations using conflicting page specifications" category?

I was about to tag Category:Pages with citations using conflicting page specifications with a speedy delete template, but I thought I would check here first. I think that the code has been changed to place these pages in the redundant parameter category. I gave the remaining articles in the "conflicting page" category a null edit to clear it out. – Jonesey95 (talk) 04:22, 7 December 2015 (UTC)[reply]

Date validation failing on leap days?

File:Tank Destroyer Forces (unofficial) logo.jpg hasn't changed since 2013, but it is suddenly showing a date error for |date=2012-02-29. There were no files in the date error category before the recent code updates. Here's a dummy citation to show the error:

Cite book comparison
Wikitext {{cite book|date=2012-02-29|title=Title}}
Live Title. 29 February 2012.
Sandbox Title. 29 February 2012.

It looks like the prose forms of the same date work fine, and YYYY-MM-DD works fine for non-leap-day dates:

  • Abbreviated month MDY: Title. 29 February 2012.
  • Abbreviated month DMY: Title. 29 February 2012.
  • Full month MDY: Title. 29 February 2012.
  • Full month DMY: Title. 29 February 2012.
  • YYYY-MM-DD for Feb 28, 2012: Title. 28 February 2012.
  • YYYY-MM-DD for Feb 29, 1900 (not a valid date): Title. 1900-02-29. {{cite book}}: Check date values in: |date= (help)
  • YYYY-MM-DD for Feb 29, 2000: Title. 1900-02-29. {{cite book}}: Check date values in: |date= (help)

It looks like maybe we stopped marking leap days as valid in YYYY-MM-DD format. Or something. – Jonesey95 (talk) 06:47, 7 December 2015 (UTC)[reply]

The problem is in function is_valid_date in Module:Citation/CS1/Date validation. The check 2==month only gives the expected result is month is a number. My guess is that it is still a string. My fix would be to put month = tonumber(month) (and similar for year and day) somewhere early on. Johnuniq (talk) 07:16, 7 December 2015 (UTC)[reply]
Done. Thanks for the tip.
—Trappist the monk (talk) 10:38, 7 December 2015 (UTC)[reply]

I cannot find the discussion for the non-printable character error category etc.

The link in § update to the live cs1|2 module weekend of 5–6 December 2015 is broken? 65.88.88.200 (talk) 15:35, 7 December 2015 (UTC)[reply]

Archive 9
—Trappist the monk (talk) 16:06, 7 December 2015 (UTC)[reply]

Date validation problem

There seems to be a problem with validation of 29 February 2012. Works fine for day & month first dates -
"ENGLISH". Otago Witness. 1 November 1879. Retrieved 29 February 2012.
"ENGLISH". Otago Witness. 1 November 1879. Retrieved 29 February 2012.

But gives an error for ISO style dates -
"ENGLISH". Otago Witness. 1 November 1879. Retrieved 29 February 2012.

Keith D (talk) 19:23, 7 December 2015 (UTC)[reply]

See two sections above. This has been fixed in the sandbox. – Jonesey95 (talk) 19:42, 7 December 2015 (UTC)[reply]

vertical format, positional parameters, and the invisible parameter test

I noticed this at {{Catholic}}. In the normal course of events, MediaWiki numbers positional parameters 1, 2, etc. Unlike 'named' parameters, positional parameters are not stripped of leading and trailing whitespace. Even though cs1|2 do not support positional parameters, if they are in the template, the module will at least look at them; this is where the ignored text error message arises. When a cs1|2 template is organized in vertical format, if there is a pipe followed by any amount of white space and then a newline, the positional parameter's content (the whitespace and the newline character) are evaluated by has_invisible_chars() which detects the line feed character and emits the error message: 

{{cite book
|title=Title
|
|     <!-- 5 space characters and a newline; this comment not visible to the module -->
}}
Title. {{cite book}}: Cite has empty unknown parameters: |1= and |2= (help)

I have fixed this in the sandbox I think:

Title. {{cite book}}: Cite has empty unknown parameters: |1= and |2= (help)

—Trappist the monk (talk) 20:37, 7 December 2015 (UTC)[reply]

So that's what was going on. I looked at {{Catholic}} and a couple other templates like it, played with a couple of them for a while, and then forgot to post a note here to ask what was going on with them. Nice work. – Jonesey95 (talk) 20:45, 7 December 2015 (UTC)[reply]

Another bad date issue

Hi, guys. I would like to cite a periodical that notes the issue as "Winter 1999-2000", however, I get the bad date error if I put that value in |date= or |year=. The same thing happens if I use a dash in "Winter 1999—2000". I assume that it is the notation of "Winter" that is the trouble here. Thoughts? Alternatives? Thanks! - Location (talk) 20:52, 7 December 2015 (UTC)[reply]

Use an endash:
{{cite book |title=Title |date=Winter 1999–2000}}
Title. Winter 1999–2000.
—Trappist the monk (talk) 20:58, 7 December 2015 (UTC)[reply]
It works! Thanks again! - Location (talk) 21:19, 7 December 2015 (UTC)[reply]

We are now flagging external links in |publisher= as an error. I have been unable to locate consensus discussion to start doing that.

Cite book comparison
Wikitext {{cite book|publisher=[http://www.example.com Publisher]|title=Title}}
Live Title. Publisher. {{cite book}}: External link in |publisher= (help)
Sandbox Title. Publisher. {{cite book}}: External link in |publisher= (help)

Can someone please enlighten me? – Jonesey95 (talk) 06:01, 8 December 2015 (UTC)[reply]

|publisher= was added to the list of parameters tested because of this discussion et seq.
—Trappist the monk (talk) 10:28, 8 December 2015 (UTC)[reply]

Guidance needed when URL is legitimate part of a title

We knew this day would come. This journal article legitimately has a URL in the title:

What should our guidance be? Should we recommend encoding one or more characters? – Jonesey95 (talk) 06:05, 8 December 2015 (UTC)[reply]

How about nowiki?
(with the C0 control character error going away sometime soon, I hope)? —David Eppstein (talk) 06:56, 8 December 2015 (UTC)[reply]
{{citation/sandbox}} whether correctly or not, does not use Module:Citation/CS1/sandbox. For that, use {{citation/new}}. Replacing {{citation/sandbox}} with {{citation/new}} and wrapping the url in |title= in <nowiki>...</nowiki> tags gives this:
—Trappist the monk (talk) 10:51, 8 December 2015 (UTC)[reply]

cite web and 2 URLs

Hello, I could use some help with parameters for cite web, when I want to include 2 different URLs in the citation. The specific citation is used in "Further reading" of Otto I:

The first URL leads to the specific document image, the second URL would be useful to point to the central login page of the image archive called "LBA" (for further research by interested readers). I have tried several parameter variations, but none of it really worked without an error message. Should I use a completely different cite template (or maybe none at all)? GermanJoe (talk) 20:49, 9 December 2015 (UTC)[reply]

Just noticed the publisher-related post a bit higher up. Still, any advice for the best handling of additional (non-spam) URLs in such citations would be appreciated. GermanJoe (talk) 21:13, 9 December 2015 (UTC)[reply]
In general, we recommend placing supplementary information outside of the cite template. In this case, you would place it after the end of the template. In the case of an in-line reference, you would place the information after the end of the template but before the closing ref tag. – Jonesey95 (talk) 21:18, 9 December 2015 (UTC)[reply]

Hdl problem

  • Kam, Ralph Thomas (2009). "Commemorating the Grand Army of the Republic in Hawaiʻi: 1882–1930". Hawaiian Journal of History. 43. Honolulu: Hawaiian Historical Society: 125–151. hdl:10524/12242.

How do I preserve the hdl template in the cite journal template? This is a problem that has recently popped up everywhere, so it might be a problem in a recent change. --KAVEBEAR (talk) 14:57, 10 December 2015 (UTC)[reply]

Null character error message appearing in citations.
—Trappist the monk (talk) 15:19, 10 December 2015 (UTC)[reply]
@Trappist the monk: I don't think I see a solution in that section. Also it doesn't make sense to individually change the entries in 900+ articles when the problem can be fixed by changing the template back to its original setting. --KAVEBEAR (talk) 15:32, 10 December 2015 (UTC)[reply]
@KAVEBEAR: there may be a simpler solution by changing some aspect of {{hdl}} so it doesn't emit the control character giving rise to the error in {{cite journal}}. Imzadi 1979 → 15:35, 10 December 2015 (UTC)[reply]
Can someone fixed that then? The question on Template talk:Hdl#Error message seems to have absolutely no responses, so can somebody who knows how to fix the problem just boldly change it so as to fix those 900+ articles.--KAVEBEAR (talk) 15:40, 10 December 2015 (UTC)[reply]
Don't change {{hdl}}. See Editor Jonesey95's 15:32, 6 December 2015 post in Null character error message appearing in citations.. The problem is fixed in the module sandbox.
—Trappist the monk (talk) 15:40, 10 December 2015 (UTC)[reply]
@Trappist the monk: The suggestion with the template:cite book/new above? That requires an editor to change all the cite journal template to cite book/new across 900+ articles. --KAVEBEAR (talk) 15:46, 10 December 2015 (UTC)[reply]
{{cite book/new}} is a version of {{cite book}} that uses Module:Citation/CS1/sandbox (all of the cs1|2 templates have matching /new templates). Do not use any of the /new templates in article space because they can and will break spectacularly and stay broken for unpredictable periods. Editor Jonesey95's post was a demonstration that the problem is fixed in the module sandbox. When the live module is updated the error messages should go away.
—Trappist the monk (talk) 16:01, 10 December 2015 (UTC)[reply]
Oh so it is just a matter of waiting for the update?--KAVEBEAR (talk) 19:03, 10 December 2015 (UTC)[reply]

Update to the live CS1 module weekend of 12–13 December 2015

I think that this weekend, I will update the live modules to take care the bugs I introduced:

to Module:Citation/CS1:

  1. bug fix: eliminate '#' as an illegal character in |<para>-link= tests; discussion
  2. bug fix: refine url testing to fix improper detection of single-character third and higher level domain names as an error; discussion
  3. bug fix: refine url testing to fix improper detection of single-character second level domain names as an error; discussion
  4. bug fix: refine url testing to fix improper detection of protocol relative urls that have a colon in the path portion; discussion
  5. bug fix: refine invisible character testing to ignore the invisible characters transcluded from {{'}} and to remove those characters from the metadata; discussion
  6. bug fix: refine invisible character testing to ignore the <nowiki>...</nowiki> stripmarkers and to replace the stripmarker with its content in the metadata; discussion
  7. bug fix: refine invisible character testing to ignore positional parameters; discussion

to Module:Citation/CS1/Configuration:

  1. invisible character test pattern adjustments
  2. invisible character error message improvements

to Module:Citation/CS1/Date validation:

  1. bug fix: restore proper leap-day detection for year-initial numeric formats; discussion

—Trappist the monk (talk) 15:16, 10 December 2015 (UTC)[reply]

I strongly support this quick update cycle. We appear to have tens of thousands of false positives out there, which is too high.
I think we also updated URL error detection to allow the underscore character:
Cite web comparison
Wikitext {{cite web|title=Title|url=http://www_foo.example.com}}
Live "Title".
Sandbox "Title".
Let's do it. – Jonesey95 (talk) 15:35, 10 December 2015 (UTC)[reply]
Agreed, given the large number of reports. --Izno (talk) 16:20, 10 December 2015 (UTC)[reply]

 Done. These changes have been implemented as of 12 December 2015. – Jonesey95 (talk) 14:54, 12 December 2015 (UTC)[reply]

Partial autofixing of cites

There are some major causes of cite errors (such as fix text "http" to be "url=http") which we could try autofixing and compare the results. For example, the easy ones:

  • The raw text "http..." or "//..." could become the "url=" if not already set (30% of pages).
  • Allow "accessdate" as 1-c "acessdate" or 1-s "accesdate" or spaced "access date".
  • Allow caps "Title=" for "title=" when people are thinking to capitalize words in Titles.
  • Accept "month=" with year when no "date=" parameter given.

Among the harder autofixes is the bar "|" in title which appears in 35% of cite errors:

  • Append the "|text" into the "title=" when specified, but note "[fix cite]".
  • Set "date=" from text spaced when "|date May 1999" or similar "accessdate 10 Dec 2015"
  • Set "title=" from text spaced when "|title This Book".
  • Set "first2=" or "last2=" from "|first2John" or "|last2Doe" etc.

Those basic autofixes could remove about 75% of pages (300 of 400 pages) from the current cite-error categories (see: WP:CS1CAT), but logged instead into some "Autofixed cite" categories. So, if we focus on just simple autofixes, then the more-difficult hand-fixes could be done (by hand) to the remaining 25% of cite errors. Eventually, I have found even bars "|" in a URL could be autofixed for common URL formats, where the risk is appending URL parts in the wrong order, but that could be autofixed much later next year.

Meanwhile, many popular pages have retained cite errors for weeks or months (see: "The Band Perry", 500 pageviews/day), because cites are left unfixed not by lack of thousands of pageviews, but because most people DO NOT KNOW how to fix a bar "|" as "{{!}}" for a bar in a title. Similarly, we could autofix text "http" as "url=http" to fix 30% of cite errors. Otherwise, the harder the cite error, the more weeks/months before it gets fixed. -Wikid77 (talk) 17:28, 10 December 2015 (UTC)[reply]

Nearly every day, I fix a dozen or three citation errors of the types listed above, and many more flavors, using User:Jonesey95/AutoEd/unnamed.js, an AutoEd script, and others like it in the same subdirectory. Anyone who wants to is welcome to copy and modify pieces of this script to create a bot that resolves unambiguous citation errors. Note that I run this script attended, and sometimes it produces false positives and other fun results, so bot code would need to be crafted more carefully than my regexes. – Jonesey95 (talk) 05:23, 11 December 2015 (UTC)[reply]
The show-stopper for Bot-based fixes (of Category:Pages_with_citations_using_unnamed_parameters) is the potential for "hyper-correction" of cite errors, while wp:autofixing cites would leave the internal cite markup as-is but inform cite gnomes by entries in new autofixed-page categories. An example of a hyper-correction might be "title=Election Results | Last Chance Recount" where the Bot autofix might add parameter "last=Chance Recount" for the pipe/bar "|" in the "title=" markup. However, because autofixing would reduce the cite-error categories, then some major articles could be spotted faster and hand-fixed sooner, such as the recent cite error in mega-page Template:J (pageviews 12,000/day) which became lost among hundreds of pages with unnamed parameters (until I fixed about 450 of those older pages). Of course, when most cite-errors are autofixed, then there is less need to rush to fix pages, because many cites are effectively "good enough" to free time to fix the really garbled cites which autofixing would abandon (and not link into autofixed-cite categories), such as the garbled Twitter-link cite in popular page "The Band Perry" (cite "Follow us: @rollingstone on Twitter") which remained unfixed for 2 months, sorted under "T" and hidden near the end of the unnamed-parameter category. Again, there is no need to rush-fix all cite errors, but rather find the mega-pages with cite errors seen thousands of times (or 1 million times) as in page "Cogito ergo sum" with cite errors left for 2.5 years. Meanwhile, we can set category-sort to "B" for "The Band Perry" (during the next 4 months), to keep it near the top of cite-error categories. -Wikid77 (talk) 23:30, 14 December 2015 (UTC)[reply]

what to do about <math>...<math> tags?

The <math>...</math> tag pair is sometimes used in cs1|2 citation templates to render formulae as part of a journal article title.

{{cite journal|last=Roy|first=Ranjan|year=1990|title=Discovery of the Series Formula for <math> \pi </math> by Leibniz, Gregory, and Nilakantha|work=Mathematics Magazine|publisher=Mathematical Association of America|volume=63|issue=5|pages=291–306}}
Roy, Ranjan (1990). "Discovery of the Series Formula for by Leibniz, Gregory, and Nilakantha". Mathematics Magazine. 63 (5). Mathematical Association of America: 291–306.

The problem is what we get for metadata from the current live module:

&rft.atitle=Discovery+of+the+Series+Formula+for+%7FUNIQ--math-00000007-QINU%7F+by+Leibniz%2C+Gregory%2C+and+Nilakantha

Clearly, that is broken because the content of the <math>...</math> tags is replaced with the nowiki stripmarker and so unintelligible to users of the metadata.

As part of the recent invisible character test fixes, I tweaked the metadata creation code to use mw.text.unstripNoWiki() to remove nowiki stripmarkers from parameter values before adding those values to the metadata. I discovered that the library function does not work as its documentation suggests that it should (see phab:T121085); mw.text.unstripNoWiki() also (inappropriately) unstrips <math>...</math> tags so using the current module sandbox we get this for article title metadata:

&rft.atitle=Discovery+of+the+Series+Formula+for+%3Cimg+class%3D%22mwe-math-fallback-image-inline+tex%22+alt%3D%22%5Cpi+%22+src%3D%22%2F%2Fupload.wikimedia.org%2Fmath%2F5%2F2%2F2%2F522359592d78569a9eac16498aa7a087.png%22+%2F%3E+by+Leibniz%2C+Gregory%2C+and+Nilakantha

which is hardly better, and percent decoded, is text and an <img /> tag:

Discovery of the Series Formula for <img class="mwe-math-fallback-image-inline tex" alt="\pi " src="//upload.wikimedia.org/math/5/2/2/522359592d78569a9eac16498aa7a087.png" /> by Leibniz%2C Gregory%2C and Nilakantha

The <img /> tag does contain an alt= attribute so we might take its value and replace the math stripmarker with it. An equation written as:

<math>r_i^2=(r_ir_j)^{k_{ij}}=1</math>

renders:

produces this alt text:

alt%3D%22r_%7Bi%7D%5E%7B2%7D%3D%28r_%7Bi%7Dr_%7Bj%7D%29%5E%7Bk_%7Bij%7D%7D%3D1%22

which, percent decoded, is:

r_{i}^{2}=(r_{i}r_{j})^{k_{ij}}=1

and which renders:

To my untrained eye, the two equations look the same.

Is there a better solution to this problem?

—Trappist the monk (talk) 20:53, 10 December 2015 (UTC)[reply]

I'm a little confused: are you discussing using the alt text to produce <math> code that gets run through the Wikimedia rendering engine again, or do you just want to use it to generate COINS metadata? In your example this seems to work but I worry that running math coding through Google translate to Kurdish and back (or whatever the local equivalent for the Wikimedia engine is) will not always be so clean. But if this is only going to affect COINS metadata, this seems like a good solution: who cares if it doesn't always work perfectly as long as it generates something meaningful rather than the current unhelpful text.
In general, Wikimedia math formula rendering is a total disaster and has been since Wikipedia started. I have a long blog post about what I see as the reasons for this [4] but basically they boil down to too much concern for how clean the semantics of the generated html markup is and not enough concern for whether it looks readable. In these specific cases, I would recommend using the {{math}} template series rather than <math>, (despite it being less clean semantically) for two reasons: (1) it more reliably generates mathematical formulae that both look like they should and match the surrounding text, and (2) to put more pressure on Wikimedia to make <math> actually usable if they want us to use it. So for your example, I would prefer to code it as
{{cite journal|last=Roy|first=Ranjan|year=1990|title=Discovery of the Series Formula for {{pi}} by Leibniz, Gregory, and Nilakantha|work=Mathematics Magazine|publisher=Mathematical Association of America|volume=63|issue=5|pages=291–306}}
Roy, Ranjan (1990). "Discovery of the Series Formula for π by Leibniz, Gregory, and Nilakantha". Mathematics Magazine. 63 (5). Mathematical Association of America: 291–306.
That doesn't really address your question about what to do about <math> but should be kept in mind to the extent that it affects citation formatting, since these templates are also going to appear in some citations.
One other thought: the Wikimedia engine does different things with <math> depending on your rendering preferences and what browser you use to view the page. E.g. it currently can generate math as bitmap images, TeX source, mathml, or svg, and it used to have an option to generate mathjax as well. Is this going to affect your metadata generation? Will it be a problem that different viewers see different metadata for the same citations? —David Eppstein (talk) 21:51, 10 December 2015 (UTC)[reply]
PS I found the example reference that uses your other example equation: the reference Coxeter 1935 in Coxeter group. Unfortunately, for this case, there is no easy way to replace the math markup with templates: the overlaid subscript-superscript pair and subscripted-superscript are too difficult to get right. So for now we're still getting the C0 character error in that article. I guess we'll have to wait for your fix to the template software to make that one go away. —David Eppstein (talk) 01:59, 11 December 2015 (UTC)[reply]
This question is about <math>...</math> tag markup and the metadata. The {{math}} markup brings its own set of problems because of included html and css.
I had forgotten about the math preferences. What that implies, is that the content of the <math>...</math> tags isn't rendered until the page is served to the reader because MediaWiki can't know beforehand the settings of the reader's math preferences. But, I think that the rest of the cs1|2 template has been rendered. So the problem becomes, how to get the original <math>...</math> tags content.
After the next module update, the metadata will hold the rendered <math>...</math> tags content according to the settings of the user who last saved the page. That is ugly, especially the SVG version. Each of the three optional renderings does include some form of text string that describes the equation so perhaps what I will do after the update is simply extract that from the rendering for use in the metadata.
—Trappist the monk (talk) 14:01, 11 December 2015 (UTC)[reply]

I have added code to Module:Citation/CS1/COinS that detects the three various flavors of html renderings of equations in <math>...</math> markup. From each of these, the code extracts a text string that represents the rendering. For PNG, the text is the value assigned to the <img /> tag's alt= attribute; for TeX, the contents between the '$ ' and ' $' substrings in the <span>...</span> tag; for SVG, the content of the <annotation>...</annotation> tag. Each of these extracted strings is slightly different but when they are put in <math>...</math> tags similar results are rendered:

r_i^2=(r_ir_j)^{k_{ij}}=1
PNG
r_{i}^{2}=(r_{i}r_{j})^{k_{ij}}=1
TeX
{\displaystyle r_{i}^{2}=(r_{i}r_{j})^{k_{ij}}=1}
MathML

The code then replaces the math stripmarker in the metadata with the extracted string. The code can handle multiple equations in a cs1|2 parameter. If there are rendering errors, the stripmarker is replaces with the text string 'MATH RENDER ERROR' so that metadata consumers know that an editor is ignoring the big bold red rendering error message (like that ever happens).

The above equation in the live and sandbox versions of {{cite book}} showing the metadata output:

{{cite book |title=<math>r_i^2=(r_ir_j)^{k_{ij}}=1</math>}}
.
'"`UNIQ--templatestyles-00000188-QINU`"'<cite class="citation book cs1">'''"`UNIQ--math-00000187-QINU`"'''.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=MATH+RENDER+ERROR&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1" class="Z3988"></span>
{{cite book/new |title=<math>r_i^2=(r_ir_j)^{k_{ij}}=1</math>}}
.
'"`UNIQ--templatestyles-0000018E-QINU`"'<cite class="citation book cs1">'''"`UNIQ--math-0000018D-QINU`"'''.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=MATH+RENDER+ERROR&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1" class="Z3988"></span>

—Trappist the monk (talk) 20:27, 17 December 2015 (UTC)[reply]

Latest change no longer reporting URL error

Hi, the latest change to the module appears to have removed the error checking for urls in |plublisher=. The previous change introduced error checking that would pick up things like |publisher=https://plus.google.com/101039533681786523418 and report an "External link in |publisher=" error. Is this intentional or have we made an incorrect change? Keith D (talk) 13:23, 12 December 2015 (UTC)[reply]

fixed
Title. https://plus.google.com/101039533681786523418. {{cite book}}: External link in |publisher= (help)
—Trappist the monk (talk) 14:43, 12 December 2015 (UTC)[reply]

Following the latest update affecting {{cite book}}.

Current: 

{{cite book|ref=harv|contributor-last1=Contributor-Last1|editor-last1=Editor-Last1|author-last1=Author-Last1|contribution=Contribution|title=Title}}

where

|ref=#CITEREFContributor-Last1


Proposal 1: 

{{cite book|ref=harv|contributor-last1=Contributor-Last1|editor-last1=Editor-Last1|author-last1=Author-Last1|contribution=Contribution|title=Title}}

where

|ref=#CITEREFany_one_enumerated_person (could be the enumerated contributor, editor, or author) so that {{harv}} could use any of those.

Or even

Proposal 2 

{{cite book|ref1=harv|ref2=harv|contributor-last1=Contributor-Last1|editor-last1=Editor-Last1|author-last1=Author-Last1|contribution=Contribution|title=Title}}

where

|ref1=#CITEREFany_one_enumerated_person (could be the enumerated contributor, editor, or author)

|ref2=#CITEREFany_one_enumerated_person (could be the enumerated contributor, editor, or author)

Again, {{harv}} should work with any.

Doable? 65.88.88.69 (talk) 19:52, 12 December 2015 (UTC)[reply]

I don't think so. The CITEREF anchor is really the id attribute of the <cite>...</cite> tags that enclose the rendered citation:
{{cite book |title=Title |author=Author |date=2004 |ref=harv}}
'"`UNIQ--templatestyles-00000195-QINU`"'<cite id="CITEREFAuthor2004" class="citation book cs1">Author (2004). ''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.date=2004&rft.au=Author&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1" class="Z3988"></span> <span class="cs1-visible-error citation-comment"><code class="cs1-code">{{[[Template:cite book|cite book]]}}</code>: </span><span class="cs1-visible-error citation-comment"><code class="cs1-code">&#124;author=</code> has generic name ([[Help:CS1 errors#generic_name|help]])</span>; <span class="cs1-visible-error citation-comment">Invalid <code class="cs1-code">&#124;ref=harv</code> ([[Help:CS1 errors#invalid_param_val|help]])</span>
The id attribute is supposed to be unique to the enclosing element.
—Trappist the monk (talk) 22:40, 12 December 2015 (UTC)[reply]
On the other hand, {{sfnref}} is your friend. So this is possible:
*{{harv|Black|2004|pp=20, 23}}
*{{harv|Red|2004|pp=3–4|ref={{sfnref|Black|2004}}}}
*{{harv|White2004|p=16|ref={{sfnref|Black|2004}}}}

{{cite book |author=Black |title=Title |editor=Red |contributor=White |contribution=preface |date=2004 |ref={{sfnref|Black|2004}}}}
which renders:
  • (Black 2004, pp. 20, 23) harv error: multiple targets (2×): CITEREFBlack2004 (help)
  • (Red 2004, pp. 3–4) harv error: multiple targets (2×): CITEREFBlack2004 (help)
  • (White2004, p. 16) harv error: multiple targets (2×): CITEREFBlack2004 (help)
White (2004). preface. Title. By Black. Red (ed.).
—Trappist the monk (talk) 18:39, 13 December 2015 (UTC)[reply]
This is not about the <cite> element but about the ref anchor. This ref anchor is a variable as far as <cite id> is concerned, so any relevant value will do. {{harvid}} is proof of concept. Somebody at some point thought to tie the ref anchor to author and its aliases, and failing that to editor. Since the relevant pool of values for the ref anchor expanded with definition of contributor (and translator), |ref= should follow suit and incorporate the new possible values for reference linking. 65.88.88.127 (talk) 18:58, 13 December 2015 (UTC)[reply]
To clarify, it is asked that |ref=harv should give more leeway to editors as to what harv may be. Right now it follows a fixed ruleset ("Author"-->"Editor"-->{{harvid}}). 65.88.88.127 (talk) 19:17, 13 December 2015 (UTC)[reply]
What Trappist is saying is that for technical reasons involving the way these things are coded into html, it is not possible for a citation to have more than one id. Right now you can change what that id is to whatever you want, using |ref=, but all harv links within an article must use the same id, and that can't be changed easily. —David Eppstein (talk) 19:44, 13 December 2015 (UTC)[reply]
I don't see what a variable for a module argument has to do with html elements. All that is asked is this: instead of |ref=harv being tied to the module argument "author" (and if no-author to "editor"), make it more flexible so that it can be any of the defined contributor arguments regardless of whether they exist in the citation or not. So {{harv}} can accept any of "author" "editor" or "contributor". That way people will not have to duplicate citations to the same material. A book citation that includes author/editor/contributor has already the complete information. Links to the citation (through {{harv}}) need not have a one-to-one relationship. 65.88.88.127 (talk) 20:03, 13 December 2015 (UTC)[reply]
Writing the html element is part of the purpose of translating the template wiki markup into html readable by a browser. All of the necessary bits pieces and parts of the html need to be in place at the time the module completes its task (nowiki and other stripmarker functions excepted).
Using {{sfnref}} as I demonstrated above allows three {{harv}} templates to link to one cs1|2 template so there aren't any duplicate citations of that single book.
—Trappist the monk (talk) 20:14, 13 December 2015 (UTC)[reply]

(edit conflict)

Then I do not understand what is is that you are asking.
The value assigned to the <cite>...</cite> id= attribute is defined by the |ref=harv keyword or by the value assigned to |ref=. {{sfn}}, {{harv}} and related templates, make wikilinks that jump to the <cite>...</cite> element that has a matching id= attribute.
{{harv|Green|2004|pp=20, 23}}
([[#CITEREFGreen2004|Green 2004]], pp.&nbsp;20, 23)<span class="error harv-error" style="display: inline; font-size:100%"> harv error: multiple targets (2×): CITEREFGreen2004 ([[:Category:Harv and Sfn template errors|help]])</span>
(Green 2004, pp. 20, 23) harv error: multiple targets (2×): CITEREFGreen2004 (help)
{{cite book |author=Green |title=Title |date=2004 |ref=harv}}
'"`UNIQ--templatestyles-0000019E-QINU`"'<cite id="CITEREFGreen2004" class="citation book cs1">Green (2004). ''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.date=2004&rft.au=Green&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1" class="Z3988"></span> <span class="cs1-visible-error citation-comment"><code class="cs1-code">{{[[Template:cite book|cite book]]}}</code>: </span><span class="cs1-visible-error citation-comment">Invalid <code class="cs1-code">&#124;ref=harv</code> ([[Help:CS1 errors#invalid_param_val|help]])</span>
Green (2004). Title. {{cite book}}: Invalid |ref=harv (help)
Module:Citation/CS1 looks at the lists of contributors, authors, and editors in that order (it does not consider translators). The first of those three lists that is not empty is used to make the CITEREF anchor. So, in the case where there is a contributor, an author, and an editor in the cs1|2 template, the CITEREF anchor uses the contributor name.
—Trappist the monk (talk) 20:06, 13 December 2015 (UTC)[reply]
Correct. And what is asked is, to be able to pick any of the 3 defined parameters as input for harv, non-exclusively.
The citation
{{cite book|ref=harv|contributor-last1=Contributor-Last1|editor-last1=Editor-Last1|author-last1=Author-Last1|contribution=Contribution|title=Title}}
Contributor-Last1. "Contribution". Title. By Author-Last1. Editor-Last1 (ed.). {{cite book}}: |author-last1= has generic name (help); Invalid |ref=harv (help)CS1 maint: numeric names: authors list (link)
can be linked to by 
{{harv|Contributor-Last1}}
as in (Contributor-Last1)
the same citation should be linked to by 
{{harv|Author-Last1}}
as in (Author-Last1)
because article context may require links pointing to the contributor and elsewhere in the same article, to the author.
To specify that the author is cited, one now must make an additional citation (duplicate) using {{harvid}} (or {{sfnref}}).
The change requested requires editing the module. I hope this is clear now?
65.88.88.60 (talk) 15:20, 14 December 2015 (UTC)[reply]
As we have been trying to tell you over and over, this cannot be done. It will not work. It has nothing to do with how the module is programmed. It is a fundamental limitation of the way internal links work on all web pages, that a link can only have one name. —David Eppstein (talk) 17:05, 14 December 2015 (UTC)[reply]
I'm sorry, I see nothing in local function anchor_id, local function extract_names or local function select_one of the module that disallows the proposal, or in any way affects http linking. Having multiple anchor-names for a single target is what is requested, and this is a well-established function. It seems like a simple matter of allowing links to be named according to any single entry in a pre-existing table rather than as a particular entry with a rigid ruleset. 72.43.99.130 (talk) 19:08, 14 December 2015 (UTC)[reply]
Perhaps you should go mock up a web page, with html code copied from a Wikipedia article but then modified to do what you want, to demonstrate for us that this can in fact be done. Because so far you have failed to convince. —David Eppstein (talk) 19:43, 14 December 2015 (UTC)[reply]
I have a different objection: what is the point? Can you give a real-life example where the proposed extension would actually solve a problem? Kanguole 19:17, 14 December 2015 (UTC)[reply]
I think it was stated above that this is a way to avoid duplicate citations. The example citation given above is complete. However, the present anchor scheme uses only the contributor-name for the ref-link. That is fine, when in the article context you are citing the contribution. But, if you want to cite the same work outside of the contribution, there should be a way to signal the reader that this is what you are citing. You can do this now with a user-created anchor ({{harvid}} or {{sfnref}}); or you can omit the contributor-name. Both involve duplicating the citation. Another solution is to pipe the CITEREF anchor:
[[#CITEREFContributor|Author]]
Clunky. 72.43.99.130 (talk) 19:43, 14 December 2015 (UTC)[reply]
A real-life example? Kanguole 19:45, 14 December 2015 (UTC)[reply]

https://en.wikipedia.org/wiki/Krishnamurti%27s_Notebook#CITEREFMcCoy2003

https://en.wikipedia.org/wiki/Krishnamurti%27s_Notebook#cite_note-rmc2003-2

https://en.wikipedia.org/wiki/Krishnamurti%27s_Notebook#cite_note-jk2003-pp5-9

I realize this is new, and as of the last time I looked |contributor= was not yet documented. But I believe you will get enquiries about this. 72.43.99.130 (talk) 19:57, 14 December 2015 (UTC)[reply]

Have you looked at {{harvc}}? This is the correct way to separate the citations of a contribution and a book.
If I understand correctly, what you want can be done. See the two references at the end of this sentence.[1][2]
What is necessary is to generate nested spans each with their own id to enclose the citation, one span for every possible short footnote link. Thus if Smith is the author and Brown the editor of a 2004 publication the generated citation would be enclosed in <span id="CITEREFSmith2004" class="citation"><span id="CITEREFBrown2004" class="citation">...</span></span>.
The disadvantages are:
  • precision of crossreference is lost: in my example {{sfn|Brown|2004}} should refer only to the book, not the entire citation
  • extra HTML would be generated that would almost always be unused
  • the chances of duplicate ids would be increased – editors would have to remember that "Brown 2015" can refer to the contributor, author or editor of a citation.
Peter coxhead (talk) 20:58, 14 December 2015 (UTC)[reply]

References

  1. ^ Smith 2004.
  2. ^ Brown 2004.
  • Smith, John (2004), "Some chapter", in Brown, Peter (ed.) Some book
I have used {{harvc}} in the past, to good effect I think, despite minor irritations (it doesn't display Contributor-Date like the {{harv}}/{{sfn}} series, it uses {{harvp}} display for |date= whether you like it or not etc.)
I honestly do not see what is the fuss with <span id>. If I understand correctly, you are saying that its input cannot be a variable. And there is no way around that? The relationship |ref=--><span id> is a cs1|2 programming convention, not an absolute requirement. A citation can allow |ref= to get its value from an array AND to also present a constant as input to <cite id>.
In any case, it was just an idea. No need for people to get all excited about it. But as mentioned: once |contributor= gets documented and used, users will want to know exactly what I'm asking.
Btw, in old (pre-sgml) bibliographic notation, the role was specified:
Contributor. Date. "Contribution". In (author)|(editor) Author|Editor. Title. Identifier.
65.88.88.127 (talk) 15:58, 15 December 2015 (UTC)[reply]
Discussing/explaining complex issues via text in talk pages is alway problematic in my experience, but I think the point that you are missing is that a citation is compiled into HTML only when it is created/changed. Adding a {{sfn}} template or whatever that is supposed to link to it won't change its HTML. So you would have to create every possible id in advance, as I tried to explain above. Peter coxhead (talk) 18:45, 15 December 2015 (UTC)[reply]
Yes, this was taken into account following Trappist's original response. The question became, must the Wikipedia reference anchor and the HTML citation id be one and the same in all cases. 65.88.88.69 (talk) 19:24, 15 December 2015 (UTC)[reply]

running out of time

This api call against Category:Pages with script errors returns a list of pages in the category that are also in article space. Two of which are these:

The first is an enormously long, unorganized list of cs1 templates (approximately 1190 of them). The second is not so long but at 700-ish is still pretty hefty. These two pages are not rendering properly because "The time allocated for running scripts has expired."

I copied the cs1 templates from List of aircraft to User:Trappist_the_monk/testcases and converted them all to use Module:Citation/CS1/sandbox (at the time, exactly the same as the live version). Then I clicked Show preview and then looked in the page source for the NewPP limit report. That report lists how much time is spent in Lua. I tweaked the sandbox to see what the report would show:

  1. sandbox unmodified – this is the baseline
    Lua time usage: 10.046/10.000 seconds
    Lua memory usage: 3.81 MB/50 MB
  2. invisible characters test disabled
    Lua time usage: 3.453/10.000 seconds
    Lua memory usage: 3.71 MB/50 MB
  3. the invisible character group tests disabled (list below)
    Lua time usage: 5.852/10.000 seconds
    Lua memory usage: 3.75 MB/50 MB
  4. a sanity check, this is the same test as the previous test except instead of Show preview, I clicked Save page
    Lua time usage: 5.852/10.000 seconds
    Lua memory usage: 3.75 MB/50 MB

This is the list of invisible character tests in the live module; the tests disabled for the sandbox test are marked:

replacement, '\239\191\189'
apostrophe, '&zwj;\226\128\138\039\226\128\139' – disabled in sandbox
apostrophe, '\226\128\138\039\226\128\139'
zero width joiner, '\226\128\141'
zero width space, '\226\128\139'
hair space, '\226\128\138'
soft hyphen, '\194\173'
horizontal tab, '\009'
line feed, '\010'
carriage return, '\013'
stripmarker, '\127UNIQ%-%-(%a+)%-[%a%d]+%-QINU\127'
delete, '\127'
C0 control, '[\000-\008\011\012\014-\031]' – disabled in sandbox
C1 control, '[\194\128-\194\159]' – disabled in sandbox
Specials, '[\239\191\185-\239\191\191]' – disabled in sandbox
Private use area, '[\238\128\128-\239\163\191]' – disabled in sandbox
Supplementary Private Use Area-A', '[\243\176\128\128-\243\191\191\189]' – disabled in sandbox
Supplementary Private Use Area-B', '[\244\128\128\128-\244\143\191\189]' – disabled in sandbox

Clearly running out of time is not good. Doing searches as a way to approximate what's out there, there aren't any errors attributable to the Specials, Private use area, Supplementary Private Use Area-A, or Supplementary Private Use Area-B. There are about 5300 C0 control character errors and about 1700 C1 control character errors. I expect C0 to drop significantly because a lot of those errors were the result of the zero-width space test seeing the ZWS character that is transcluded when editors use {{'}}. Because we are currently testing for the string of characters transcluded by {{'}} we avoid listing the ZWS as an error.

One more test:

5. same as test #3 but with C0 and C1 control tests enabled
Lua time usage: 6.774/10.000 seconds
Lua memory usage: 3.77 MB/50 MB

What to do, what to do? I'm inclined, for the time being, to modify the live module to continue the testing for all invisible characters except Specials, Private use area, Supplementary Private Use Area-A, and Supplementary Private Use Area-B. That will give editors and gnomes a chance to cleanup what's out there. We can easily disable C0 and C1 if it becomes apparent that these tests are taking too much time.

Opinions?

—Trappist the monk (talk) 20:12, 12 December 2015 (UTC)[reply]

If it is accepted that 1190(!) cite templates in an article is more desirable than running out of script-processing time, then let's go with Trappist's change above. Most of what I've come across in the error category are line feeds and replacement characters. Let's get those fixed while we play in the sandbox with search routines that are not as processing-time-intensive. – Jonesey95 (talk) 15:36, 13 December 2015 (UTC)[reply]
An intermediate (and clunky) solution would be to resolve C0/C1 tests per page rather than per citation. That is, once a C0/C1 character is found in any citation, the test stops, the citation is flagged, and the page is categorized. Not elegant but it may go some way around the problem until a real solution is found. 65.88.88.127 (talk) 19:09, 13 December 2015 (UTC)[reply]
Alas, no. One template cannot know what another template has discovered. For each cs1|2 template, Module:Citation/CS1 is started afresh. There is no mechanism by which it can leave notes to subsequent invokes.
—Trappist the monk (talk) 20:18, 13 December 2015 (UTC)[reply]
Editor Dragons flight has added a small bit of code that makes a big difference in how much time it takes to process User:Trappist_the_monk/testcases. In my tests, Lua time has dropped from 6.7-ish seconds to about 4.0 seconds (best was 3.252, worst was 4.925).
—Trappist the monk (talk) 11:54, 14 December 2015 (UTC)[reply]
  • Years ago I advised devs to increase Lua timeout to 15 sec & save template vars: I think it would be easy for the wp:developers to increase the Lua timeout limit from 10 to 15 seconds, as we discussed back in 2013 (remember the markup timeout limit was 60 seconds, compared to 10sec for Lua). IIRC the markup runtime could double (on a busy day) as 31sec could exceed 60sec timeout, but Lua runtime might vary 20% where an 8-second run became 10sec and killed the page reformat (because limit not 15sec). // As for "smart templates" which talk to each other through saved data, there is an mw:MediaWiki extension to save data, but might be expensive when used 1,000 times per page, and so the Lua might have to check and not save the count after perhaps count=50 or so, as I imagine reading the saved data count is much faster than storing the new count. By the way, we still get "wp:Edit conflicts" even though computer experts have developed "weave merge" algorithms to allow changing paragraph text while another user moves paragraphs on the page(!). Imagine a quick "selective revert" of 1 paragraph among dozens of valid changes in moved paragraphs, by weave-merge resolution. Computer technology is so far advanced beyond what WP is using today (cars which autobrake or auto-correct speed when a person runs into the street), but the more we discuss the concepts, then the better the chances for improvement here. -Wikid77 (talk) 23:52, 14 December 2015 (UTC)[reply]

can I use a piped link in |newspaper= in cite news? As there are several papers worldwide with the same name the paper is disambiguated by location which I don't really want to show in the citation. 109.146.155.143 (talk) 11:22, 13 December 2015 (UTC)[reply]

A piped link should work in cite news, although I don't think the pipe trick works.Nigel Ish (talk) 11:37, 13 December 2015 (UTC)[reply]
Pipe trick works:
{{cite news |title=Title |newspaper=[[Pipe (computing)|]]}}
"Title". Pipe.
—Trappist the monk (talk) 12:24, 13 December 2015 (UTC)[reply]
The pipe trick doesn't work anywhere inside <ref>...</ref> tags, though: Help:Pipe trick#Where it doesn't work. -- John of Reading (talk) 12:32, 13 December 2015 (UTC)[reply]
Right. We could probably work around that in the module but I suspect that would just further delay a real fix.
—Trappist the monk (talk) 13:00, 13 December 2015 (UTC)[reply]

An episode-link parameter value with both a # and parentheses is causing an error in this citation:

Cite episode comparison
Wikitext {{cite episode|airdate=Apr 23, 2010|city=Stockholm|episodelink=[[Talang 2010#Episode 4 (Oscarsteatern, Stockholm)]]|network=TV4-Gruppen|season=2010|series=Talang|serieslink=Talang (TV series)|station=TV4|title=Talang: Näcken|url=http://www.tv4play.se/noje/talang?title=nacken&videoid=976026}}
Live "Talang: Näcken". Talang. Season 2010. 23 April 2010. TV4-Gruppen. TV4. {{cite episode}}: Check |episodelink= value (help); Unknown parameter |city= ignored (|location= suggested) (help); Unknown parameter |episodelink= ignored (|episode-link= suggested) (help); Unknown parameter |serieslink= ignored (|series-link= suggested) (help)
Sandbox "Talang: Näcken". Talang. Season 2010. 23 April 2010. TV4-Gruppen. TV4. {{cite episode}}: Check |episodelink= value (help); Unknown parameter |city= ignored (|location= suggested) (help); Unknown parameter |episodelink= ignored (|episode-link= suggested) (help); Unknown parameter |serieslink= ignored (|series-link= suggested) (help)

There might be some other combination of parameters that causes this citation to give an error. The intended link works fine in article prose. – Jonesey95 (talk) 16:16, 13 December 2015 (UTC)[reply]

No, the error is because
|episodelink=[[Talang 2010#Episode 4 (Oscarsteatern, Stockholm)]]
removing wikilink markup:
"Talang: Näcken". Talang. Season 2010. 23 April 2010. TV4-Gruppen. TV4. {{cite episode}}: Unknown parameter |city= ignored (|location= suggested) (help); Unknown parameter |episodelink= ignored (|episode-link= suggested) (help); Unknown parameter |serieslink= ignored (|series-link= suggested) (help)
—Trappist the monk (talk) 16:41, 13 December 2015 (UTC)[reply]
trout Self-trout. Yep. My mistake. – Jonesey95 (talk) 17:20, 13 December 2015 (UTC)[reply]

breaking up Module:Citation/CS1

Module:Citation/CS1 is nearly 187,000 bytes big. For some time I have been contemplating splitting off certain bits of it into separate pages, much like I did for Module:Citation/CS1/Date validation.

To begin this task I have created Module:Citation/CS1/Utilities which will hold functions and tables that are common to multiple pages. Right now, it holds the error and categorization tables and the function is_set() because these things are/will be shared among the various modules.

I intend to create another page for the named identifiers (isbn, doi, etc) because the code for those identifiers is large, rarely modified, and unique to each identifier.

You should expect large red script error messages on this page though I will try to keep that to a minimum.

—Trappist the monk (talk) 17:43, 13 December 2015 (UTC)[reply]

The greater part of this is done. There are two new pages: Module:Citation/CS1/Identifiers and Module:Citation/CS1/Utilities. Identifiers holds all of the code that supports rendering and error checking of the named identifiers (isbn, doi, pmc, etc). Utilities holds code that is used by Identifiers, Module:Citation/CS1, and Module:Citation/CS1/Date validation.
The code that was moved from Citation/CS1 into these two new pages has not been modified so continues to function as before. There is new code that is required to link pages together.
I have also added code to Utilities that looks for global functions and variables. There should be none. If you see big red error messages that begin 'Tried to read nil global ...' or 'Tried to write global ...' let me know and I'll fix that.
I have not yet created sandbox versions of the new pages but will do so at the next update to the live module.
—Trappist the monk (talk) 13:25, 15 December 2015 (UTC)[reply]
And another: Module:Citation/CS1/COinS.
—Trappist the monk (talk) 20:03, 15 December 2015 (UTC)[reply]

Is it valid to have a full stop at the end of a fully qualified name in a URL?

I came across this citation with a URL error in a live article, and clicking the link works fine. Is it valid to have a full stop at the end of a host name in a URL?

Cite web comparison
Wikitext {{cite web|publisher=[[ABC3]]|title=All about ... Stephanie 'Hex' Bendixsen|url=http://abc.net.au./abc3/articles/s2748083.htm|work=ABC3 crew}}
Live "All about ... Stephanie 'Hex' Bendixsen". ABC3 crew. ABC3.
Sandbox "All about ... Stephanie 'Hex' Bendixsen". ABC3 crew. ABC3.

My vague memory of domain name formatting is that a full stop at the end of a fully qualified domain name is valid. – Jonesey95 (talk) 07:38, 14 December 2015 (UTC)[reply]

fixed.
—Trappist the monk (talk) 11:42, 14 December 2015 (UTC)[reply]
Why should that be accepted? RFC:1738#section-5 has
hostname = *[ domainlabel "." ] toplabel
domainlabel = alphadigit | alphadigit *[ alphadigit | "-" ] alphadigit
toplabel = alpha | alpha *[ alphadigit | "-" ] alphadigit
That is, period are separators between non-empty labels. Kanguole
The concept of a "rooted" FQDN terminated with a period exists in some places, e.g. RFC:1535. It is not widely used, but it is supported by some browsers / websites, for example Google and the ABC.net.au example above seem to accept the extra period and then silently remove it. Other websites, such as CNN.com, return an error message if you add an extra period. The real question is probably whether an FQDN with period might ever return valid content different from that without a period. I believe that is possible in principle, though I've never heard of anyone doing that. Dragons flight (talk) 12:15, 14 December 2015 (UTC)[reply]
So this syntax is not permitted by the URL specification (quoted above) and works or fails unpredictably on different browser/site combinations. That sounds like two good reasons to consider it an error. Kanguole 12:45, 14 December 2015 (UTC)[reply]
RFC:3986 which is the 2005 update to RFC:1738 says that a terminal period is allowed with the FQDN used in URLs. Dragons flight (talk) 12:57, 14 December 2015 (UTC)[reply]
DNS has always (iirc; it's been a while since I last looked at DNS in any depth) allowed a terminal period, and it means essentially only that this FQDN is definitely fully-qualified (no need to look in any configured search list for the resolver). Whether that's allowed usage in a URL is up to the RFC that defines URLs, and as per Dragons flight that's the case since RFC 3986. A dotted FQDN should not return different content from the dotless version (it's the same domain; much like the punycode/non-punycode variants of an IDN), but I imagine it would be entirely possible, technically, to misconfigure a webserver to distinguish between the two. However, I don't think that's a valid argument for anything much. So... at least to my mind, this module should accept a terminal period as an obscure-but-valid syntax for the server part of a URL. Fixing syntactically valid but non-functional URLs needs to be handled elsewhere (manual, by bot, etc.). On the other hand, I cannot imagine, and have never seen, a single case where a terminal period has been used deliberately in a URL; so if this module were to treat this as undesirable and emit an error as "best practice enforcement" I wouldn't object, and I very much doubt that very many would complain about it. --Xover (talk) 15:09, 14 December 2015 (UTC)[reply]
Agree. This is more of a DNS artifact. DNS resolvers always add the period at the end anyway (to signify the null "root" domain). However since the relevant RFCs and the applications based on them accept "relative" domain names (without the terminal period) there should not be any real issues. 72.43.99.130 (talk) 20:26, 14 December 2015 (UTC)[reply]
Thanks for the fix. As for never having seen it, you can see the one that brought me here in the Further reading section of this version of "Stephanie Bendixsen". The link works fine, as one would expect from a properly configured web server and intermediary domain name servers. – Jonesey95 (talk) 22:40, 14 December 2015 (UTC)[reply]

Cite episode query

What do we do when there are 2 dates supplied for something? Like a 'filming date' and a 'broadcast date' ? Like say http://www.cagematch.net/?id=1&nr=53243 which filmed 1 July 2010 but broadcast 18 July 2010. I figure broadcast but the film date seems notable info to include. Just add it outside the cite template? Ranze (talk) 06:03, 15 December 2015 (UTC)[reply]

The purpose of a citation is to help a reader locate the source. Choose the date that best comports with that purpose. Other editors of the article using {{cite episode}} may have an opinion regarding which of the two dates to use, so ask there. Alternately, if there is a WikiProject that coordinates similar articles, you might start a discussion at the WikiProject's talk page.
—Trappist the monk (talk) 11:45, 15 December 2015 (UTC)[reply]
Agreed with Trappist's comments, but I have one to add. Usually the date of significance for a non-video source is the date of publication. The analog of publication in your case would be the broadcast date. There is an option though to display both. |orig-year= is used to hold an original date for print sources. I've used it, to note the date a law was enacted when it wasn't published for another two years, as one example. So I don't see why you couldn't do something like: {{cite episode |date= 18 July 2010 |orig-year= filmed 1 July 2010 ...}}. Imzadi 1979 → 11:58, 15 December 2015 (UTC)[reply]

I came across this citation in the wild today:

Cite episode comparison
Wikitext {{cite episode|air-date=March 5, 2014|network=[[Fox Broadcasting Company]]|season=13|series-link=American Idol (season 13)|series=[[American Idol]]|title=Home|url=http://www.americanidol.com/recaps/episode/the-top-12---home}}
Live "Home". American Idol. Season 13. 5 March 2014. Fox Broadcasting Company. {{cite episode}}: Check |series= value (help)
Sandbox "Home". American Idol. Season 13. 5 March 2014. Fox Broadcasting Company. {{cite episode}}: Check |series= value (help)

|series= has a wikilink in it, and |series-link= is populated. Under those conditions, the citation does not render correctly. Should we detect some aspect of this condition as an error? – Jonesey95 (talk) 05:09, 16 December 2015 (UTC)[reply]

It's definitely an error. The question, to me, is the cost-benefit of detecting it. How common an error is it, and how easy is it to detect? —David Eppstein (talk) 05:31, 16 December 2015 (UTC)[reply]

Detecting this condition for |title= and |series= is pretty painless:

Cite book comparison
Wikitext {{cite book|title-link=American Idol (season 13)|title=[[American Idol]]}}
Live American Idol. {{cite book}}: Check |title= value (help)
Sandbox American Idol. {{cite book}}: Check |title= value (help)
Cite book comparison
Wikitext {{cite book|title-link=[[American Idol (season 13)]]|title=American Idol}}
Live American Idol. {{cite book}}: Check |title-link= value (help)
Sandbox American Idol. {{cite book}}: Check |title-link= value (help)
Cite book comparison
Wikitext {{cite book|title-link=American Idol (season 13)|title=American Idol}}
Live American Idol.
Sandbox American Idol.

And for author-editor-contributor-translator name-lists:

Cite book comparison
Wikitext {{cite book|author-link=[[Abraham Lincoln]]|first=Abe|last=Lincoln|title=Title}}
Live Lincoln, Abe. Title. {{cite book}}: Check |author-link= value (help)
Sandbox Lincoln, Abe. Title. {{cite book}}: Check |author-link= value (help)
Cite book comparison
Wikitext {{cite book|author-link=Abraham Lincoln|author=[[Abraham Lincoln]]|title=Title}}
Live Abraham Lincoln. Title. {{cite book}}: Check |author= value (help)
Sandbox Abraham Lincoln. Title. {{cite book}}: Check |author= value (help)
Cite book comparison
Wikitext {{cite book|author-link=Abraham Lincoln|author=Abraham Lincoln|title=Title}}
Live Abraham Lincoln. Title.
Sandbox Abraham Lincoln. Title.

—Trappist the monk (talk) 12:32, 16 December 2015 (UTC)[reply]

I'm thinking that all of these error conditions should emit the "check param-link value" category, even if the |author= value is what needs to be fixed. Does that make sense, or am I off track? I'll be happy to edit the Help text accordingly. – Jonesey95 (talk) 15:31, 16 December 2015 (UTC)[reply]
Not sure I understand what you're saying. When |author= is the parameter that needs to be fixed (as in the example where |author=[[Abraham Lincoln]] |author-link=Abraham Lincoln), that page is categorized into Category:CS1 errors: parameter link. Is that not correct?
Regardless, the help text will need to be edited to explain that wikilinks in a title-holding parameter are not allowed when the matching link-holding parameter has a value. In the case of author-, editor-, contributor-, and translator-name parameters, the error message parameter is fixed to the list name (author when the actual parameter used is |last=, etc).
—Trappist the monk (talk) 16:41, 16 December 2015 (UTC)[reply]
I didn't say that elegantly, did I? I tried the sandbox version of the |author=[[Abraham Lincoln]] |author-link=Abraham Lincoln citation in an article preview, and I couldn't get it to emit any category, so I just wanted to confirm here. It sounds like it is doing the right thing. Thanks. – Jonesey95 (talk) 17:19, 16 December 2015 (UTC)[reply]
From the |author=[[Abraham Lincoln]] |author-link=Abraham Lincoln compare above I copied the template and pasted it into Abraham Lincoln (because the link was there in the comparison), changed {{cite book}} to {{cite book/new}}, wrapped the template in {{code}}, clicked Show preview and got this:
<cite class="citation book">[[Abraham Lincoln]]. ''Title''.</cite><span title="ctx_ver=Z39.88-2004&rfr_id=info%3Asid%2Fen.wikipedia.org%3AAbraham+Lincoln&rft.au=Abraham+Lincoln&rft.btitle=Title&rft.genre=book&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook" class="Z3988"><span style="display:none;"> </span></span> <span style="font-size:100%" class="error citation-comment"><span style="font-size:100%" class="error citation-comment">Check <code style="color:inherit; border:inherit; padding:inherit;">|author-last1=</code> value ([[Help:CS1 errors#bad_paramlink|help]])</span></span>[[Category:CS1 errors: parameter link]]
The very last bit of that is the category.
A simpler way is to paste the template into Special:ExpandTemplates, change to {{cite book/new}} and click OK.
There is a {{cite book/sandbox}}; did you use that instead of {{cite book/new}}? It uses the live version of the module. Not sure why we keep it around.
—Trappist the monk (talk) 17:47, 16 December 2015 (UTC)[reply]

eissn, hdl, citeseerx

Because it was easy, I have added support for |eissn=:

Atema E, Mulder E, Dugdale HL, Briga M, van Noordwijk AJ, Verhulst S. "Heritability of telomere length in the Zebra Finch". Journal of Ornithology. eISSN 1439-0361. ISSN 0021-8375. LCCN 2005252102. OCLC 754654105.

Should we add support for Handle System (hdl) and or citeseerx?

—Trappist the monk (talk) 14:16, 16 December 2015 (UTC)[reply]

I support adding |hdl=. This value is frequently placed in |id=, and it would be nice to have a cleaner place to put it. – Jonesey95 (talk) 15:25, 16 December 2015 (UTC)[reply]

I've added hdl. It's pretty much just a clone of a portion of the doi code (which itself is an hdl).

{{cite journal/new |title=Title |journal=Journal |hdl=1808/3638}}
"Title". Journal. hdl:1808/3638.

We'll need a new error category Category:CS1 errors: HDL and new help text (most of which can by cloned from the doi help text).

—Trappist the monk (talk) 11:53, 17 December 2015 (UTC)[reply]

Regex help needed to replace line feed character in title=

I'm digging in to the invisible character category, and I am trying to add some regexes to the AutoEd script that I use for unsupported parameters and similar fixes. I have noticed that line feed characters are particularly prevalent, so I'm trying to create a regex to find a line feed character in |title= and replace it with a space. Here's what I have so far:

str = str.replace(/({{\s*[cC]it[ea](?:[^}{]*(?:\{\{[^}{]*}}[^}{]*)*))(\|\s*title\s*=.+)\n+(.+?(?=[\|\}]))/gi, '$1$2 $3');

This should translate to "Find a cite template without opening braces inside it, then find | followed by white space and then |title=, then find any characters until you get to one or more line feeds (\n+), then find more characters until you find a pipe or a closing curly brace. Replace it with everything you found except the line feed, which is replaced with a space character."

I am finding that my regex reaches too far if it finds a cite template without a line feed in it, going all the way to the end of a citation template and replacing the line feed at the end of the paragraph that contains the template. I think I need something after the first .+ and before the \n+ to tell my regex to act only if it finds a line feed before it finds a pipe or closing brace, but I haven't been able to manage it. Can anyone help? – Jonesey95 (talk) 07:25, 17 December 2015 (UTC)[reply]

I don't use your tool so I don't know if this will work for you. You might replace the .+ with [^\|\}]+ (consume one or more characters that are not in the set of | and }).
—Trappist the monk (talk) 10:52, 17 December 2015 (UTC)[reply]
That works great. I'm off to the races. Thanks. – Jonesey95 (talk) 20:17, 17 December 2015 (UTC)[reply]

I'm being my usual confused and probably dumb self here. In the external link error help text, I see:

This error occurs when any of the CS1 or CS2 citation title-holding parameters – |title=, |chapter=, |work=, |publisher= or any of their aliases – hold an external link (URL).

In the documentation for {{cite web}}, I see:

website: Title of website; may be wikilinked. Displays in italics. Aliases: work

My little brain comes to the conclusion that URLs in both |work= and |website= should display an error. That does not appear to be the case, however (the first cite web template uses |website= and the second one uses |work=, an alias of |website=; they are otherwise identical):

Cite web comparison
Wikitext {{cite web|first=Elizabeth|last=Stanton|title=Declaration of Sentiments|url=http://www.womensrightsfriends.org/pdfs/1848_declaration_of_sentiments.pdf|website=http://www.womensrightsfriends.org/}}
Live Stanton, Elizabeth. "Declaration of Sentiments" (PDF). http://www.womensrightsfriends.org/. {{cite web}}: External link in |website= (help)
Sandbox Stanton, Elizabeth. "Declaration of Sentiments" (PDF). http://www.womensrightsfriends.org/. {{cite web}}: External link in |website= (help)
Cite web comparison
Wikitext {{cite web|first=Elizabeth|last=Stanton|title=Declaration of Sentiments|url=http://www.womensrightsfriends.org/pdfs/1848_declaration_of_sentiments.pdf|work=http://www.womensrightsfriends.org/}}
Live Stanton, Elizabeth. "Declaration of Sentiments" (PDF). http://www.womensrightsfriends.org/. {{cite web}}: External link in |work= (help)
Sandbox Stanton, Elizabeth. "Declaration of Sentiments" (PDF). http://www.womensrightsfriends.org/. {{cite web}}: External link in |work= (help)

Here's the same URL in |publisher= in cite web and cite book:

Cite web comparison
Wikitext {{cite web|first=Elizabeth|last=Stanton|publisher=http://www.womensrightsfriends.org/|title=Declaration of Sentiments|url=http://www.womensrightsfriends.org/pdfs/1848_declaration_of_sentiments.pdf}}
Live Stanton, Elizabeth. "Declaration of Sentiments" (PDF). http://www.womensrightsfriends.org/. {{cite web}}: External link in |publisher= (help)
Sandbox Stanton, Elizabeth. "Declaration of Sentiments" (PDF). http://www.womensrightsfriends.org/. {{cite web}}: External link in |publisher= (help)
Cite book comparison
Wikitext {{cite book|first=Elizabeth|last=Stanton|publisher=http://www.womensrightsfriends.org/|title=Declaration of Sentiments|url=http://www.womensrightsfriends.org/pdfs/1848_declaration_of_sentiments.pdf}}
Live Stanton, Elizabeth. Declaration of Sentiments (PDF). http://www.womensrightsfriends.org/. {{cite book}}: External link in |publisher= (help)
Sandbox Stanton, Elizabeth. Declaration of Sentiments (PDF). http://www.womensrightsfriends.org/. {{cite book}}: External link in |publisher= (help)

But it works sometimes:

Cite web comparison
Wikitext {{cite web|publisher=http://stats.cfldb.ca|title=The Toronto Argonauts’ 1935 Season|url=http://stats.cfldb.ca/team/toronto-argonauts/1935/}}
Live "The Toronto Argonauts' 1935 Season". http://stats.cfldb.ca. {{cite web}}: External link in |publisher= (help)
Sandbox "The Toronto Argonauts' 1935 Season". http://stats.cfldb.ca. {{cite web}}: External link in |publisher= (help)
Cite web comparison
Wikitext {{cite web|accessdate=14 July 2012|author=Nick Warburton|date=June 2005|title=RICK JAMES AND THE MYNAH BIRDS|url=http://www.earcandymag.com/rrcase-mynahbirds-part2.htm|work=http://earcandymag.com}}
Live Nick Warburton (June 2005). "RICK JAMES AND THE MYNAH BIRDS". http://earcandymag.com. Retrieved 14 July 2012. {{cite web}}: External link in |work= (help)
Sandbox Nick Warburton (June 2005). "RICK JAMES AND THE MYNAH BIRDS". http://earcandymag.com. Retrieved 14 July 2012. {{cite web}}: External link in |work= (help)

Here's the above citation with a trailing slash in the |work= URL:

Cite web comparison
Wikitext {{cite web|accessdate=14 July 2012|author=Nick Warburton|date=June 2005|title=RICK JAMES AND THE MYNAH BIRDS|url=http://www.earcandymag.com/rrcase-mynahbirds-part2.htm|work=http://earcandymag.com/}}
Live Nick Warburton (June 2005). "RICK JAMES AND THE MYNAH BIRDS". http://earcandymag.com/. Retrieved 14 July 2012. {{cite web}}: External link in |work= (help)
Sandbox Nick Warburton (June 2005). "RICK JAMES AND THE MYNAH BIRDS". http://earcandymag.com/. Retrieved 14 July 2012. {{cite web}}: External link in |work= (help)

What am I missing this time? – Jonesey95 (talk) 18:44, 18 December 2015 (UTC)[reply]

Oh, do stop with the self-deprecation.
The problem, as you discovered, is the trailing slash; the parameter names in the error message are, I think, reported correctly. The function is_parameter_ext_wikilink() used a flawed snippet of code that didn't strip off an empty path. is_domain_name() then returned false because it expected the last character in the tld to be a letter. I've changed is_parameter_ext_wikilink() to use split_url() which should produce more reliable results.
—Trappist the monk (talk) 12:15, 19 December 2015 (UTC)[reply]
Thanks. That looks like it works as expected. – Jonesey95 (talk) 14:29, 19 December 2015 (UTC)[reply]

Automatic ISO conversion

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

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

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

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

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

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

—Trappist the monk (talk) 23:59, 20 December 2015 (UTC)[reply]

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

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

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

Clarify usage of publisher

I couldn't find anything in the archives that specifically and clearly addressed this question. Are cable TV channels and local TV stations considered publishers for CS1 purposes? Or, are their owning companies the publishers? There is a script being used to mass-change |work= and |website= for these entities to |publisher=, and this seems wrong to me. Either way, the template doc could use some clarification to avoid endless spinning between the two forms. ―Mandruss ☎ 19:02, 23 December 2015 (UTC)[reply]

In this RfC, Editor SMcCandlish wrote (at the bullet point 'Support italics') one of the better descriptions of just what it is that |work= is supposed to be. Perhaps that's helpful?
—Trappist the monk (talk) 19:30, 23 December 2015 (UTC)[reply]
I read it and need some interpretation as to this question. ―Mandruss ☎ 19:49, 23 December 2015 (UTC)[reply]
To add, there is actually no real context-based citation template doc. There is doc for cs1|2-wide parameters, with few exceptions. What little citation context does exist, is buried in the systemwide documentation. I assume that the context here is {{cite av media}}, {{cite episode}} and the like. Imo, in these cases the TV channels etc. should not be considered publishers, just like magazines or encyclopedias are not the publishers of their articles. 72.43.99.130 (talk) 19:39, 23 December 2015 (UTC)[reply]
For my purposes I'm interested primarily in the guidance at Template:Cite news and Template:Cite web, which share a description of |publisher=. It's that description that I feel needs clarification. ―Mandruss ☎ 19:49, 23 December 2015 (UTC)[reply]
Traditionally, a network or TV station would be considered a publisher, not a work, for citation purposes. In the case of TV, the work is the program. My oft-used example is this. 60 Minutes is a "television news magazine". It is rendered in italics as a work. Individual segments or episodes of that program are considered the analog to articles within a print magazine, so their titles are rendered in quotation marks. Broadcasting a TV program is the analog to publication, so CBS, as the network, is the publisher. In terms of the distinction between an individual TV station and the company that owns it, look at the distinction between a publishing house (Simon & Schuster) and one of its imprints (Charles Scribner's Sons) or the company that owns it (CBS Corporation). In that case, only the most specific entity needed to locate the source need be included. Imzadi 1979 → 20:09, 23 December 2015 (UTC)[reply]
I'm speaking of websites for the cable TV channels and local TV stations. If a news article at nytimes.com is correctly cited as |work=The New York Times, how can one oppose citing the article at CNN.com, containing equivalent reporting of the very same subject, as |work=CNN or |website=CNN? ―Mandruss ☎ 20:20, 23 December 2015 (UTC)[reply]
"cnn.com" might be a work, but "CNN" is still a publisher. The website lacks a name separate from that of its publisher, and in those cases, I would never list the name of the publisher as a work. In distinction, WLUC-TV has named its news website Upper Michigan's Source, and so I do list that as a work along with the station call letters and location in citations. Imzadi 1979 → 20:24, 23 December 2015 (UTC)[reply]
Then you would be in conflict with the |publisher= guidance at {{Cite news}} and {{Cite web}}: "Omit where the publisher's name is substantially the same as the name of the work". Following your reasoning we should code |work=nytimes.com, not |work=The New York Times. In my opinion the publisher of CNN.com is Turner Broadcasting System (or parent company Time Warner), and publisher should be omitted as largely irrelevant and unuseful in that context. Can you see a need for clarification here? ―Mandruss ☎ 20:26, 23 December 2015 (UTC)[reply]
The name of that website is the same as the name of their newspaper, The New York Times based on the usage of the same masthead (logo) between the two. CNN's website also shares the same logo as the network, implying the same situation, but to a different result as "CNN" the network is a publisher. However, WLUC-TV has three logos/names for its distinct entities: WLUC-TV (the NBC subchannel), WLUC-DT2/FoxUP (the Fox subchannel) and Upper Michigan's Source (their website). As for "CNN" vs. "Turner Broadcasting System", that's same relationship between Simon & Schuster and CBS Corporation, the corporate parent of the publishing house or "WLUC-TV" and "Sinclair Broadcast Group".
The guidance of which you speak relates to the traditional notion that the name of the publishing company behind a periodical publication is unnecessary for most citation purposes, especially where it is the same, or substantially (The New York Times vs. The New York Times Company") so to its publications. Imzadi 1979 → 20:44, 23 December 2015 (UTC)[reply]
We've had this debate before. The |work= parameter should be the name of the site, not the name of the web server hosting the site. The name of the CNN site is CNN, not cnn.com. —David Eppstein (talk) 20:47, 23 December 2015 (UTC)[reply]
Also, our guidance says that not all website names are rendered in italics. For websites that are the equivalent to a publication type traditionally rendered in italics (Wikipedia as an encyclopedia title, The New York Times as a newspaper title), we should continue to class them as works at the moment, but if a website title is the equivalent of something considered a publisher (CNN as a cable network, CBS News as a broadcast network division [but not The CBS Evening News with Scott Pelley]), then we'd render those as publishers. Maybe in the future other style guides like the Chicago Manual of Style will come to consider all website names as works, but they don't, and we don't, at the moment. Imzadi 1979 → 20:49, 23 December 2015 (UTC)[reply]
Even if you are correctly stating community consensus on this, and that's not at all clear to me, you're adding a ton of interpretation not present in the guidance, and that dearly needs fixing. That guidance, not the archives of this page, is where virtually all editors will go to determine the correct thing to do in these cases, as long as Wikipedia exists, and it is currently highly ambiguous. The average editor should not have to hunt down, parse, analyze, and synthesize widely dispersed wisdom in the archives. ―Mandruss ☎ 20:56, 23 December 2015 (UTC)[reply]
I think context is everything. What is it that is cited?
If what cited is an episode in a TV series at a certain channel, then:
|title=episode-title |work=series-name |publisher=station/channel-name
If what cited is a TV series at a certain channel syndicated/owned by some entity, then:
|title=series-name |work=station/channel name |publisher=station/channel owner/syndicator
As was stated above, there is very little guidance on context in the doc. Instead, it is more of a one-size-fits-all approach I think.
208.87.234.201 (talk) 14:29, 24 December 2015 (UTC)[reply]

Since it's so difficult for so many people to grasp the amount of editor effort wasted due to this lack of guidance, I'll now give up (again) trying to improve the situation for the sake of the project. It's far from the first time I've encountered this, but I've yet to fully learn the lesson. We shall continue to spin, working at about 60% efficiency, with ongoing acrimonious conflict out there in the real editing world, per Wikipedia tradition. Thanks. ―Mandruss ☎ 15:21, 24 December 2015 (UTC)[reply]

Red error for missing url parameter on cite web

Now that we see so many clear citation errors, I've been going around my projects cleanup listing and fixing them, and I've noticed one that's really difficult to find on large pages- "Web citation with no URL"; basically, when you use Cite web and the url parameter isn't filled in. This error does not produce any visible red text, it just adds the page to Category:Pages using web citations with no URL (as well is Category:Pages using citations with accessdate and no URL, when applicable). On a page with ~100 citation it can be hard to manually track down which one has the error; is it possible for the offending citation to emit red text like many of the other errors? --PresN 00:13, 24 December 2015 (UTC)[reply]

Cite web comparison
Wikitext {{cite web|accessdate=2015-12-23|first=First|last=Last|publisher=Pub|title=Title}}
Live Last, First. "Title". Pub. {{cite web}}: |access-date= requires |url= (help); Missing or empty |url= (help)
Sandbox Last, First. "Title". Pub. {{cite web}}: |access-date= requires |url= (help); Missing or empty |url= (help)
That error message is hidden. You can force a display of all error messages. See Controlling error message display.
—Trappist the monk (talk) 00:33, 24 December 2015 (UTC)[reply]
I presume that there's a reason why that error is hidden by default, since you obviously know about it, so I'll just use the css fix. Thank you! --PresN 02:36, 24 December 2015 (UTC)[reply]
Note that the category pages also say it's hidden by default and show the CSS. Maybe it's hidden because some editors use {{cite web}} when it isn't actually on the web, for example when they copy and adapt another citation. It still works in many such cases without having an error from the point of view of readers. PrimeHunter (talk) 03:23, 24 December 2015 (UTC)[reply]
This discussion ends in an RFC that hides certain error messages.
—Trappist the monk (talk) 04:00, 24 December 2015 (UTC)[reply]

year/date categorization fixes

I have fixed a couple of small bugs in year_date_check() in Module:Citation/CS1/Date validation/sandbox.

When |date= does not contain a recognizable year, the citation should not be categorized in Category:CS1 maint: Date and year

Cite journal comparison
Wikitext {{cite journal|date=June 3|journal=New York Times|last=Associated Press|title=Francois Genoud, Nazi Sympathizer, 81|url=http://query.nytimes.com/gst/fullpage.html?res=9C02E0DD1F39F930A35755C0A960958260|year=1996}}
Live Associated Press (June 3). "Francois Genoud, Nazi Sympathizer, 81". New York Times. {{cite journal}}: Check date values in: |date= and |year= / |date= mismatch (help)
Sandbox Associated Press (June 3). "Francois Genoud, Nazi Sympathizer, 81". New York Times. {{cite journal}}: Check date values in: |date= and |year= / |date= mismatch (help)

The pattern used to test for |date=YYYY-YY accepts a hyphen as separator so it matches the year and month portions of ymd dates. The test converts the YY to YYYY (using the century from the first year in the range). One of the years defining the range in |date= must match the value in |year= to add the citation to Category:CS1 maint: Date and year. In this case, the pattern matches |date=2003-04-29 returning 2003-04 which is then converted to 2003-2004. Since |year=2004 matches one of the years in the 'range', the citation is added to the maintenance category:

Cite news comparison
Wikitext {{cite news|accessdate=2009-09-15|archivedate=29 October 2009|archiveurl=https://web.archive.org/web/20091029064455/http://www.nytimes.com/ref/movies/1000best.html|date=2003-04-29|deadurl=no|publisher=[[New York Times]]|title=1,000 Greatest Movies Ever Made|url=http://www.nytimes.com/ref/movies/1000best.html|year=2004}}
Live "1,000 Greatest Movies Ever Made". New York Times. 29 April 2003. Archived from the original on 29 October 2009. Retrieved 15 September 2009. {{cite news}}: Unknown parameter |deadurl= ignored (|url-status= suggested) (help)CS1 maint: date and year (link)
Sandbox "1,000 Greatest Movies Ever Made". New York Times. 29 April 2003. Archived from the original on 29 October 2009. Retrieved 15 September 2009. {{cite news}}: Unknown parameter |deadurl= ignored (|url-status= suggested) (help)CS1 maint: date and year (link)

—Trappist the monk (talk) 13:02, 24 December 2015 (UTC)[reply]

??? Shouldn't |date= and |year= in the same citation be mutually exclusive? Or am I missing something? 208.87.234.201 (talk) 14:32, 24 December 2015 (UTC)[reply]
When it is necessary to disambiguate citations (two or more of an author's works cited in the same article), and when the article uses {{sfn}} or {{harv}}-family templates, a letter suffix is added to the year portion of |date= or |year=. For dmy and mdy date formats, |year= is redundant. For templates that use ymd date formats, inserting a disambiguator is not permitted (|date=2015a-12-24) so these templates use |year= with the disambiguator (|date=2015-12-24 |year=2015a).
It is permissible, as a carry-over from past practice, to use both |date= (in either dmy or mdy formats) and |year= with |year= having the disambiguator. When the cs1|2 templates used {{citation/core}} as the rendering engine, this was the only way that a full date could be rendered and at the same time support {{sfn}} and {{harv}} short-form citation linking.
—Trappist the monk (talk) 14:57, 24 December 2015 (UTC)[reply]
Ok, thanks. 208.87.234.201 (talk) 15:14, 24 December 2015 (UTC)[reply]

Any update on the collaboration parameter?

See Module talk:Citation/CS1/Archive 12#Let's add a collaboration parameter. for the discussion. Headbomb {talk / contribs / physics / books} 17:15, 25 December 2015 (UTC)[reply]

You might be able to do this now with |contributorn= and |contributionn=, which is presently undocumented on Help:CS1. --Izno (talk) 17:25, 25 December 2015 (UTC)[reply]
Thanks for the reminder that |contributor= hadn't yet been documented. I have hacked a bit of documentation for it at {{cite book}} and {{citation}}.
I don't think that |contributor= and |contribution= is an answer to the question posed at the start of this discussion.
—Trappist the monk (talk) 21:34, 25 December 2015 (UTC)[reply]
Sort of like this then?
Yao, W.-M.; et al. (Particle Data Group) (2015). "Using last/first". Journal.
Yao WM, et al. (Particle Data Group) (2015). "Using vauthors". Journal.
"Using authors". Journal. 2015. {{cite journal}}: Unknown parameter |authors= ignored (help)
"Without author parameter". Journal. 2015. – this should probably have an error message
If |collaboration= is set, et al. is automatically appended to the author name-list so |display-authors= is not required.
—Trappist the monk (talk) 23:18, 25 December 2015 (UTC)[reply]
Depends, some papers have one author, which speaks on behalf of a collaboration, e.g. arXiv:1511.00264 which should be cited as 'K. Stifter (CMS Collaboration)' (or some variation of it) without the et al.. Headbomb {talk / contribs / physics / books} 02:14, 26 December 2015 (UTC)[reply]
The majority of cases would have the et al. though. Headbomb {talk / contribs / physics / books} 02:16, 26 December 2015 (UTC)[reply]
Wouldn't you expect that papers authored by a collaboration are written by a small subset of collaborators and that the small subset does the writing on behalf of the whole collaboration?
—Trappist the monk (talk) 13:09, 26 December 2015 (UTC)[reply]

Many-to-one references and various plurality issues

[Continuing on, loosely, from the thread #Ref id related proposal above.]

Apologies for resurrecting this thread, and please indulge me as I perpetrate some thinking out loud to the general amusement or boredom of the indigents. I have no solutions or concrete proposals, so this is fairly literally just me thinking out loud in the hopes it may spur… something of some kind of use.

I've ran into this sort of issue a couple of times in my field and have so far not found a solution that doesn't in some way seem suboptimal. An example that illustrates the category of problem: Shakespeare's plays are published in critical editions, where a modern editor modernises the text and collates the extant sources for that play (typically one or more quarto editions and a folio edition), adds extensive explanatory notes to each line (literally every line of the play has one or more notes attached), etc. The edition also typically contain an "Introduction" that is really book-length on its own, and that contains an extensive discussion of the play (sources, its dating, textual issues and editions, critical reception, themes and motifs, notable performances and adaptations, etc.).

That is, for these editions what you're really citing is almost always the work of the editor, except in the few cases where you want to quote directly from the text of the play (e.g. "To be or not to be").

A typical citation would be something like (picked at random from Hamlet):

(Arden publishes all the plays in individual editions over decades, and when they've done them all they start over with a new "series"; we're currently on the "third series")

Just something so basic as the display here feels off: Shakespeare may strictly speaking be the "author", but the work we're citing in 99% of the cases is that of Thompson and Taylor, so having Shakespeare shown most prominently feels off. Adding to this, the first name in the citation determines where it's placed in the list of sources for the article, so in an equivalent example from King Lear, the edition edited by "Brode, Douglas" gets sorted under "Shakespeare, William". And then the final insult is that in use of the author—date reference templates (typically {{sfn}}), due to the way the link is generated, you'd have to use Shakespeare 2006 to refer to Thompson & Taylor's work. Not to mention the apparent incongruity of citing a work written by Shakespare in 2006 (~400 years after his death). The latter point also creates a barrier (increases cognitive load) for editors: when they actually mean to cite Thompson & Taylor they have to remember to write "Shakespeare" in the citation template.

The approach the WikiProject has currently landed on is to simply drop Shakespeare from the citation template and let it be inferred for readers (the style guide places all editions of the play in a separate subsection of the bibliography where all citations may be assumed to have an implicit |author=William Shakespare included. However this fails to capture that piece of metadata in order to achieve the desired visual rendering, which is, I hope everyone will agree, suboptimal.

An alternative approach would be, as suggested in the thread above, to leave |author=Shakespeare in the full citation and then use a custom link id so you can cite Thompson and Taylor but link to Shakespeare, but this gets really complicated real fast (and entirely defeats the purpose of using things like {{sfn}}).

A further problem, also mentioned above, which is very common in this area is citing chapters in a larger work. For instance, Cambridge University Press publishes a lot of Cambridge Guides to Shakespeare … on Film, on Screen, on Stage, etc.; that are edited collections of essays from multiple authors, where each chapter covers one aspect of whatever the topic of the overall book is. Needing to include an entry for each cited chapter in the bibliography is awkward (lots of duplication) and leads to inconsistent bibliographic details for the same work even with experienced and meticulous editors (I've had to clean up a lot of these in the FA drives for articles in the WikiProject's scope). Here the short citations are logical (you give the author of the chapter, not the editor of the overall work), so the problem is constrained to the bibliography.

And a final category of issue is citing a multi-volume work, where, as best I can tell, you have to include a full citation for each volume in the bibliography and then use YYYYa, YYYYb publication years to refer to them in short references. The exempli gratia here would be the (still current, even though published in 1923) standard reference work:

You could of course forego the |p= parameter to {{sfn}} and use |loc= with a manual specification that includes both page and volume instead, but this too seems suboptimal (forgoing a structured field for an unstructured one).

Now I don't really have any concrete proposals for this, and I doubt it can be solved in just Module:CS1 alone without also changing things like {{sfn}}, but I have a feeling that somewhere in all this there is a magic bullet that could solve these in a more elegant way; and I think there may be something lurking around the issue of multiple ways to refer to the same cite as the IP was suggesting above.

For instance, if one could include |author=Shakespeare but specify that we want the link target to be generated from the |editor= (without having to use |ref=harvid or similar) you'd solve a couple of the issues (at the expense of complexity in Module:CS1), but still be left with the problem of sometimes needing to actually cite Shakespeare. On the other hand, having multiple anchors (using nested span elements as suggest above, or some similar method) would allow both, but would generate bloated markup.

And neither way would address the issues of citing multiple chapters from the same work. If you add that concern to the mix we're talking something along the line of being able to specify all the chapters and their authors in a single full citation and having the anchors to link them from distinct short refs. I shudder at the mere thought of trying to implement that in Module:CS1, and finding a way to display that in the bibliography would require a part of the functionality to reside in javascript on the client side. At that point I suspect we're really talking about some hypothetical future where all bibliographic data is kept in Wikidata and the bibliography in any given article is dynamically generated based on queries to that.

Anyways, I can hold my nose and keep using the various workarounds we've come up with (and periodically clean up the various confusion introduced by random editors), but I wanted to air these thoughts out here in the hopes that better minds than mine could come up with better ways to solve the underlying problems, and that my thoughts might serve as useful data points when reasoning about how to design this system.

Regards, --Xover (talk) 10:25, 27 December 2015 (UTC)[reply]

Three issues, right?
  1. someway to have multiple anchor ids for a single cs1|2 template
  2. someway to list multiple chapters of a single edited work without duplicating all of the bibliographic details for each chapter
  3. someway to identify and link to the separate volumes of a single work without without repeating full bibliographic detail for each volume; {{sfn}} links to the appropriate volume somehow
Have I got this right?
  1. For this, it occurs to me that we might, as a first hack, allow |ref= to accept multiple keywords, perhaps: |ref=harv-ed, |harv-contrib=. Then if there are |author=, |editor=, and |contributor=, Module:Citation/CS1 would make its CITEREF anchor from whichever name-list is specified in |ref=. That then might be extended to accept multiple comma separated keywords so that second and third keywords caused the rendered citation to be wrapped in <span id=CITEREFnamelistYYYY>...</span>.
  2. Does {{harvc}} do what you want?
  3. I don't have a suggestion for this. Each volume in your example has its own ISBN so the templates differ by more than just volume number.
—Trappist the monk (talk) 11:46, 27 December 2015 (UTC)[reply]
I think you have the issues down right (at least at the "bulletpoint" level), provided I myself have them down right in my head (for which there is no guarantee). :-)
Your idea #1 at first blush sounds like a remarkably elegant solution to that issue (and, if I understood it right, also the IP's issue in the previous thread). It adds complexity, but (without being familiar with the code) at least manageable complexity; and given you've articulated it clearly and succinctly I'd say the odds are good that it fits within a clean design too (a good rule of thumb in my experience). I see no obvious gotchas with this beyond the complexity, except perhaps a theoretical risk of collisions with manually generated values for |ref= (which I think is very unlikely, and if any are in the wild must be very rare).
As for #2, {{harvc}} is one approach to this that represents a set of tradeoffs which happen to be ones I dislike more than the tradeoffs in the way we do it right now. It's an entirely valid approach, and will suit many editors just fine, but I dislike it enough that I don't consider it an option. This may of course be simply because I a) haven't looked at it enough to understand it fully (not unlikely), and b) my wishing for a unicorn that just isn't possible to have with the current Mediawiki infrastructure. Again, I suspect a lot of this kind of stuff ultimately depends on keeping citation data on Wikidata.
I can picture ways to approach #3, but none I'd necessarily suggest as good ways. For instance (and a bit off the cuff), we could have a setup like |volumeN-identifier=(1 or I or i or...), |volumeN-isbn=(…), and even possibly |volumeN-year=yyyy for things like (iirc) the ODNB which was published as a single work in multiple volumes which came out spread over decades. But I wouldn't go so far as to say I suggest this approach without thinking a lot more about it. But perhaps your gut feeling has better foundation, by knowing the code and clearly having a model for what this template/module/system is (my grasp of it is pretty fuzzy). --Xover (talk) 13:27, 27 December 2015 (UTC)[reply]
#1: to address the |author=William Shakespeare metadata issue when these templates are confined to a section of 'William Shakespeare's editions' where Shakespeare can be inferred as the author, |author-mask=0 works to hide |author= and this works
{{harvnb|Thompson|Taylor|2006|ref=CITEREFShakespeare2006}}
Thompson & Taylor 2006
#2: You don't say how you 'do it right now', nor do you identify the trade-offs that you don't like about {{harvc}}. It's hard to offer any better suggestions when this information is left out of the discussion.
#3: cs1|2 templates are designed (if one can use that term) to render a complete citation for a single work. If I understand your idea for |volumeN-identifier= and |volumeN-isbn=, then that seems like an attempt to squeeze multiple volumes into a single template so should not be considered. These constructs don't fix the problem of linking via {{sfn}} to the appropriate volume.
—Trappist the monk (talk) 14:20, 27 December 2015 (UTC)[reply]
Regarding #1, if there is a short reference "Name 2009, p. 45", readers will expect that to refer to an entry "Name, A. (2009) ..." in the list of cited works. You could make the link go to a different entry, but that would be surprising, and therefore best avoided. If different things are being cited, they need different citations, even though this involves repetition of the #2 kind. Kanguole 15:07, 27 December 2015 (UTC)[reply]
#1: Hmm. Clever, and a bit of a cheat, but it will certainly give the visual appearance that makes sense. However, anything requiring editors to manually construct a fragment identifier is a no-go in practice. Using citation templates is a struggle for many non-technical editors (and even for people with a technical background it's a bit of a chore). IOW, I think for this to work in practice would require the |ref=harv-ed support you outlined above.
#2: Well, as I mentioned I may not have sufficiently considered {{harvc}}, but my initial assessment is that its tradeoffs are toward exactly the wrong mix of duplication of bibliographic details and spreading information out among multiple templates. If I've understood it correctly (and that's not just a rhetorical caveat), it puts information (chapter author, chapter name) in a separate template that I consider strongly associated with the work (and hence should be in the main citation in the bibliography) and includes this information in the short citation which should ideally be just Name, Year, and Page. And on the other end it duplicates information from the main citation in its |in= parameter, with the duplication of effort to maintain and inherent risks of errors or letting the two get out of sync. But, of course, as I said, these are valid tradeoffs, they're just not ones I agree with. As for what I'm doing now I didn't mention it because it's essentially "nothing": for multi-volume works I list the volumes that are cited separately (and distinguish using |year=YYYYa).
#3: Hmm. That reasoning holds true only if one considers each volume to be a separate work; but in this case all four volumes make up a single work. They're split into volumes simply due to limitations of the printing process (somewhere around 500 pages printing gets increasingly expensive, and somewhere around 1000 pages they're unable to actually make it hold together for love or money). In popular works (fiction, say) there are pricing considerations and the ability to charge more when published in parts, but in this work (and most similar reference works) their only customers are institutional ones (with prices to match): I'd bet good money you will not find a single extant copy of the original edition of this particular work outside a well-stocked university library. In fact, the 2009 facsimile reprint (which is still expensive, but now priced so a normal private individual may conceivably want to buy it) probably only has separate ISBNs because they want to be able to sell individual volumes. In other words, I see no inherent conflict between limiting the CS1/2 templates to a single work, and including a multi-volume work with individual identifiers (which happen to be of the ISBN type) in it. Unlike, obviously, something like the Harry Potter series, where each "volume" is a separate work in a series. --Xover (talk) 16:52, 27 December 2015 (UTC)[reply]
PS. In the case I'm outlining here, sfn wouldn't need to link to different works: there's just one work so linking to it covers all four cases (volumes). However, sfn would need to support giving the volume in the rendered short citation (which you can do unstructured in |loc= today, but would probably be best handled by supporting a |volume= parameter in addition to |p=, neither of which affect the generated link). --Xover (talk) 16:57, 27 December 2015 (UTC)[reply]
#1: The argument that we shouldn't implement template features because these features are complex and difficult to understand, or because they require technical competence is not persuasive. Pretty much any article can be properly and adequately cited and referenced using the basic tools available in VE and RefToolBar. To do more sophisticated citing and referencing necessarily requires that editors have more sophisticated knowledge of the capabilities and nuances of the citing and referencing systems employed at en:wp. It is true that it would be easier to write |ref=harv-ed than to write:
{{harvnb|Thompson|Taylor|2006|ref=CITEREFShakespeare2006}}
or
{{harvnb|Thompson|Taylor|2006|ref={{sfnref|Shakespeare|2006}}}}
|author-mask=0 is not a cheat. It isn't commonly used but this insource: search shows that it is occasionally used. Another alternative is |display-authors=0 which might be easier to understand and is also occasionally used.
#2: compare this (from Romeo and Juliet):
  • Dawson, Anthony B. (2002). "International Shakespeare". In Wells, Stanley; Stanton, Sarah (eds.). The Cambridge Companion to Shakespeare on Stage. Cambridge: Cambridge University Press. pp. 174–193. ISBN 978-0-521-79711-5.
  • Gay, Penny (2002). "Women and Shakespearean Performance". In Wells, Stanley; Stanton, Sarah (eds.). The Cambridge Companion to Shakespeare on Stage. Cambridge: Cambridge University Press. pp. 155–173. ISBN 978-0-521-79711-5.
  • Holland, Peter (2002). "Touring Shakespeare". In Wells, Stanley; Stanton, Sarah (eds.). The Cambridge Companion to Shakespeare on Stage. Cambridge: Cambridge University Press. pp. 194–211. ISBN 978-0-521-79711-5.
  • Marsden, Jean I. (2002). "Shakespeare from the Restoration to Garrick". In Wells, Stanley; Stanton, Sarah (eds.). The Cambridge Companion to Shakespeare on Stage. Cambridge: Cambridge University Press. pp. 21–36. ISBN 978-0-521-79711-5.
  • Schoch, Richard W. (2002). "Pictorial Shakespeare". In Wells, Stanley; Stanton, Sarah (eds.). The Cambridge Companion to Shakespeare on Stage. Cambridge: Cambridge University Press. pp. 62–63. ISBN 978-0-521-79711-5.
  • Smallwood, Robert (2002). "Twentieth-century Performance: the Stratford and London companies". In Wells, Stanley; Stanton, Sarah (eds.). The Cambridge Companion to Shakespeare on Stage. Cambridge: Cambridge University Press. pp. 98–117. ISBN 978-0-521-79711-5.
  • Taylor, Gary (2002). "Shakespeare plays on Renaissance Stages". In Wells, Stanley; Stanton, Sarah (eds.). The Cambridge Companion to Shakespeare on Stage. Cambridge: Cambridge University Press. pp. 1–20. ISBN 978-0-521-79711-5.
to this: [Dawson 2002, pp. 174–193 harvnb error: multiple targets (2×): CITEREFDawson2002 (help), Gay 2002, pp. 155–173 harvnb error: multiple targets (2×): CITEREFGay2002 (help), Holland 2002, pp. 194–211 harvnb error: multiple targets (2×): CITEREFHolland2002 (help), Marsden 2002, pp. 21–36 harvnb error: multiple targets (2×): CITEREFMarsden2002 (help), Schoch 2002, pp. 62–63 harvnb error: multiple targets (2×): CITEREFSchoch2002 (help), Smallwood 2002, pp. 98–117 harvnb error: multiple targets (2×): CITEREFSmallwood2002 (help), Taylor 2002, pp. 1–20 harvnb error: multiple targets (2×): CITEREFTaylor2002 (help)]
#3: With each volume getting its own ISBN, I think that you have to treat each volume as a separate work. You could do this:
[Chambers V1 2009 Chambers V2 2009 Chambers V3 2009 Chambers V4 2009]
  • Chambers, Edmund Kerchever (2009). The Elizabethan Stage. New York: Oxford University Press.
    • volume 1; ISBN 9780199567485
    • volume 2; ISBN 9780199567492
    • volume 3; ISBN 9780199567508
    • volume 4; ISBN 9780199567515
—Trappist the monk (talk) 19:42, 27 December 2015 (UTC)[reply]

access-date with archiveurl?

When archiveurl is set (and deadurl=yes), is there any reason to keep the access-date? It clutters the displayed ref with 3 dates, it's confusing and I don't see why the access-date would be needed since providing access-date to the archive is redundant with archivedate, and providing access-date to the original article is pointless since it's been replaced with an archive. Thanks. -- GreenC 16:51, 28 December 2015 (UTC)[reply]

URL parameter validation doesn't take port numberl into account

See for example at the first reference at Gudivada. Currently, it's throwing an error but if the port number is removed, it doesn't throw it. --Glaisher (talk) 12:44, 29 December 2015 (UTC)[reply]

Retrieved from "https://en.wikipedia.org/w/index.php?title=Help_talk:Citation_Style_1&oldid=697279834"