Help talk:Citation Style 1

From Wikipedia, the free encyclopedia
Jump to navigation Jump to search

Citation templates
...in conception
...and in reality

Contents

Archived title[edit]

Can somebody please create a CS1 maintenance error message for when the title of a citation template is "Archived copy"? Since no webpage is named this, but we still have over 100,000 such hits (Special:Search/insource:/title\=Archived copy/). This should be tracked and worked on, to replace with the real webpage title, manually or with a bot. (tJosve05a (c) 21:44, 23 July 2018 (UTC)

Based on this edit (a sample size of one), it looks like you might want to file a bug with InternetArchiveBot. – Jonesey95 (talk) 00:22, 24 July 2018 (UTC)

"Archived copy" is standard wording used by multiple tools/bots in the same situation of not being able to determine the title, so it's easy to track with a search. If users will tackle it manually or with AWB by all means create a tracking category. Ideally it would be done by a specialized title bot since there are likely endless edge cases to deal with when extracting title data. -- GreenC 02:02, 24 July 2018 (UTC)

I have added case-insensitive detection of this title to Module:Citation/CS1/sandbox and added a new maintenance category to Module:Citation/CS1/Configuration/sandbox:
{{cite web/new |url=http://www.numa.net/expeditions/u-21_1.html |title=Archived copy |access-date=2 November 2008 |archive-url=https://web.archive.org/web/20081227004917/http://www.numa.net/expeditions/u-21_1.html |archive-date=27 December 2008}}
"Archived copy". Archived from the original on 27 December 2008. Retrieved 2 November 2008.CS1 maint: Archived copy as title (link)
'Archived copy' is not recognized as an 'invalid' title when |archive-url= is not set:
{{cite web/new |url=http://www.numa.net/expeditions/u-21_1.html |title=Archived copy |access-date=2 November 2008}}
"Archived copy". Retrieved 2 November 2008.
Trappist the monk (talk) 12:17, 30 July 2018 (UTC)
@Trappist the monk: Looks good! Anyway to implement this live? (tJosve05a (c) 18:10, 20 August 2018 (UTC)

@Trappist the monk: - it appears "Archive copy" is also being used. -- GreenC 12:31, 23 September 2018 (UTC)

tweaked:
"Archive copy". Archived from the original on 27 December 2008. Retrieved 2 November 2008.CS1 maint: Archived copy as title (link)
Trappist the monk (talk) 12:46, 23 September 2018 (UTC)
??? This is a web page citation. The particular web page has a title, all one has to do is look at the source: <title>Story of the U-21 </title>. Conveniently, this is also the cited web page's rendered heading. The documentation for {{cite web}} is clear on this (Template:Cite Web#Title). The fact that the encapsulating archive page has its own (html) title is irrelevant. The underlying archive is what is cited. The technical detail that this is an archived copy is handled elsewhere in the citation. The citation in question is not edited correctly, and "Archived copy" should not be used when the title is available. 108.182.15.109 (talk) 14:07, 5 October 2018 (UTC)
"All one has to do.." makes the assumption title data is clean, accurate and ready to be cut and pasted into a Wikipedia citation. There are all sorts of crazy things in the <title></title>. There was a title bot (forget name) that did this and left an inline comment the title was created by bot, and more often than not those titles need manual cleanup. For some reason the bot owner is no longer operating it. Point is, title bots are not trivial and require a fair amount of effort to watch over. It's beyond the scope of other bots and tools to individually create their own title bot routines, not even considering the network I/O overhead of polling each link when they might not otherwise need to. If you want to help by creating a title bot that would be awesome but not if it's pasting in title data blindly, it should be looking for edge cases and building up a system to detect and fix repeatable problems. -- GreenC 14:36, 5 October 2018 (UTC)
I think you misunderstood the point I was making. The cited citation is malformed. This has nothing to do with bots. Editors should be given the correct guidance: when the title of a webpage is not obvious, they should look at the source, and specifically search for the <title> element. Internet Explorer (the browser I am using right now) has a "Page" dropdown menu in the Command toolbar, that includes a "Properties" option. When you click this, the title of this page as I edit it ("Editing Help talk:Citation Style 1 (section) - Wikipedia") is right at the top. I'm not saying that IE should be used. But a diligent editor is supposed to look at this, just as they are supposed to look at a book's or journal's front and back matter for edition/copyright info, etc. etc. A citation with "Archived copy" as title should not be "fixed" to conform with cs1 presentation. It should be flagged so that editors are alerted that something is amiss. Because I think that an automated routine to fix this is more likely to mess things up. Another option is to substitute the (visible) top heading for the webpage's title, even if this is technically incorrect. Although this may not be the way pages are indexed (and therefore retrieved) by software looking for the webpage's metadata, it would be sufficient for humans looking for the page's data. 72.43.99.138 (talk) 14:57, 6 October 2018 (UTC)
It's true that "Archived copy" doesn't flag or notify users to fix the missing title. Would you suggest a different wording, or red warning message, or populate a tracking category? -- GreenC 15:13, 6 October 2018 (UTC)

Remove |class= from non-cite arxiv templates[edit]

This is an arxiv-specific parameter, which is only useful when citing the preprints version. The only template that should support/display it is {{cite arxiv}}, or {{citation}} if no other identifiers are declared. Headbomb {t · c · p · b} 13:15, 24 July 2018 (UTC)

Are you sure? Shouldn't |class= be supported in {{cite journal}} when it has |arxiv=? Isn't what you really want a restriction that rejects |class= when |arxiv= is not present? But isn't |class= already ignored when |arxiv= is not present?
Trappist the monk (talk) 13:51, 24 July 2018 (UTC)
Basically the only reason for |class= to be presented is when you cite the preprint as a preprint, since it gives you an idea of the moderation involved with it (general physics is the unfiltered shove-all repertoire where crank/junk ends up, although not all general physics is crank/junk). Once it's been reviewed, the version of record takes precedence over the arxiv version, so that information is pointless. Headbomb {t · c · p · b} 14:09, 24 July 2018 (UTC)
With the restrictions that you suggest, is there any real reason to support the notion of using {{citation}} to cite an arxiv paper? Because arxiv papers have not been published, there is no 'journal' or other periodical to tell {{citation}} how to render |title=. Without a periodical type parameter, {{citation}} renders |title= in italic font:
{{citation |vauthors=Abdurakhmanov UU, etal |title=Observation of Gaussian pseudorapidity distributions for produced particles in proton-nucleus collisions at Tevatron energies |arxiv=1807.01234 |class=nucl-ex}}
Abdurakhmanov UU, et al., Observation of Gaussian pseudorapidity distributions for produced particles in proton-nucleus collisions at Tevatron energies, arXiv:1807.01234 [nucl-ex] Cite uses deprecated parameter |class= (help)
Of course, editors will make up something though the better solution is:
{{cite arxiv |mode=cs2 |vauthors=Abdurakhmanov UU, etal |title=Observation of Gaussian pseudorapidity distributions for produced particles in proton-nucleus collisions at Tevatron energies |arxiv=1807.01234 |class=nucl-ex}}
Abdurakhmanov UU, et al., "Observation of Gaussian pseudorapidity distributions for produced particles in proton-nucleus collisions at Tevatron energies", arXiv:1807.01234 [nucl-ex]
I think that the problem then reduces to:
if {{citation}} and |journal=<not set> and |arxiv=<set> then
error: |arxiv= ignored
elseif {{citation}} and |journal=<set> and |arxiv=<set> and |class=<set> then
error: |class= ignored
elseif not {{cite arxiv}} and |class=<set> then
error: |class= ignored
There is one other conditional that I can think of because the final published article may have been included in a book or conference proceeding:
elseif {{citation}} and |chapter=<set> and |arxiv=<set> and |class=<set> then
error: |class= ignored
Trappist the monk (talk) 15:30, 24 July 2018 (UTC)
"is there any real reason to support the notion of using {{citation}} to cite an arxiv paper?" The only one I can think of would be for CS2 style (although here the title would be italicized, rather than quoted, and that's I believe wrong). I usually convert those to {{cite arxiv |mode=cs2}} when I can, so bots interact with them better. Also keep in mind that conference proceedings/book chapters can have arxiv links too, not only journals. |arxiv= should never be ignored. |class= should be, but only when the citation can be determined to be the version of record. IMO the best way to do that is to check for any other version-of-record identifiers in {{citation}} (so not CiteSeerX or SSRN), and kill |class= in any other {{cite xxx}} templates. Checking for journal/chapter would also likely be very efficient, so that could be certainly be a simpler alternative. I'd put this in a (hidden) maintenance category, rather than an (visible) error category. Headbomb {t · c · p · b} 19:54, 24 July 2018 (UTC)
[The] title would be italicized, rather than quoted... Yeah, that's why I asked if using {{citation}} to cite an arXiv preprint makes any sense. I don't think it does because the rendering is incorrect as is the template's metadata: &rft.genre=bookinstead of &rft.genre=preprint.
Do we have a list of cs1|2 supported identifiers that are version-of-record identifiers?
Trappist the monk (talk) 14:16, 1 August 2018 (UTC)
AFAICT, arxiv/biorxiv/citeseerx/ssrn are not versions of records. The others are either exclusively (ISBN) or dominantly (DOI) versions of records, or just irrelevant (ISSN). Headbomb {t · c · p · b} 15:12, 1 August 2018 (UTC)
These are the supported identifiers broken up into groups as I understand them. Of the identifiers that are not version-of-record there is a group that is preprints, reviews, self-published sources, etc, and another group that is mostly catalog-like identifiers:
cs1|2 identifiers
version-of-record not version-of-record other
DOI, HDL, ISBN, ISMN, JSTOR, PMC, RFC, USENETID ARXIV, BIORXIV, CITESEERX, JFM, MR, OSTI, SSRN, ZBL ASIN, BIBCODE, EISSN, ISSN, LCCN, OCLC, OL, PMID
USENETID included here for completeness though it is only properly supported by {{cite newsgroup}}
Is this a correct categorization of these identifiers?
Trappist the monk (talk) 13:21, 22 August 2018 (UTC)
cs1|2 identifiers
Version of Record[1] Preprints[2] Other[3]
DOI, ISBN, ISMN, JSTOR, LCCN, PMC, PMID, USENETID,[4] RFC ARXIV, BIORXIV, CITESEERX, SSRN ASIN, BIBCODE, EISSN, HDL, ISSN, OCLC, OL, JFM, MR, OSTI, ZBL
  1. ^ Usually, e.g. there are bioRxiv dois, ResearchGate dois, etc.
  2. ^ Usually, e.g. CiteSeerX is sometimes updated to host a published version.
  3. ^ Some are vendor-specific (ASIN), some are often but not always VoRs (BIBCODE), some are material related to a published version (ISSN, MR, JFM, ZBL), some are VOR/preprints hosted on a specific server (OSTI, HDL), and some are links to specific catalogues (OCLC).
  4. ^ USENETID included here for completeness though it is only properly supported by {{cite newsgroup}}
@Trappist the monk: Updated the table. Headbomb {t · c · p · b} 13:55, 22 August 2018 (UTC)
Restored my original table as a point of comparison for when I can return to this topic later.
Trappist the monk (talk) 14:30, 22 August 2018 (UTC)
I have hacked Module:Citation/CS1/sandbox so that it emits an error message for the last three of the conditions I identified above:
{{citation/new |arxiv=1705.01263 |class=hep-ph |title=Title}} – no error message; {{citation}} used as a pseudo-cs2 version of {{cite arxiv}} (has malformed title)
Title, arXiv:1705.01263 [hep-ph] Cite uses deprecated parameter |class= (help)
{{citation/new |arxiv=1705.01263 |class=hep-ph |title=Title |journal=Journal}}
"Title", Journal, arXiv:1705.01263 [hep-ph] Cite uses deprecated parameter |class= (help)
{{citation/new |arxiv=1705.01263 |class=hep-ph |title=Title |encyclopedia=Encyclopedia}}
"Title", Encyclopedia, arXiv:1705.01263 [hep-ph] Cite uses deprecated parameter |class= (help)
{{citation/new |arxiv=1705.01263 |class=hep-ph |title=Title |chapter=Chapter}}
"Chapter", Title, arXiv:1705.01263 [hep-ph] Cite uses deprecated parameter |class= (help)
{{cite web/new |arxiv=1705.01263 |class=hep-ph |title=Title |url=//example.com}}
"Title". arXiv:1705.01263 [hep-ph]. Cite uses deprecated parameter |class= (help)
{{cite arxiv/new |author=Author |arxiv=1705.01263 |class=hep-ph |title=Title}} – no error message because {{cite arxiv}} and |class= used properly
Author. "Title". arXiv:1705.01263 [hep-ph].
There is, I think a better way than the special exception code that I wrote for this (and special exception code is generally bad and should be avoided when possible). |class= is a member of the basic_arguments whitelist which makes it available to all cs1|2 templates. Because |class= applies only to preprint sources, and only when |arxiv= or |eprint= is set, and because {{citation}} does not render |title= in the correct format without it also has a |work= alias or a |chapter= alias (both indicative of publication), I believe that there is no reason for {{citation}} to act as a pseudo-cs2 version of {{cite arxiv}}. Deleting |class= from the basic_arguments whitelist will give the Unknown parameter ... error without the need for special exception code.
While not discussed, and presumably not contemplated, there is a similar issue with |biorxiv= and |citeseerx= where {{citation}} will not correctly render preprints with these identifiers when |work= or |chapter= aliases are not set. Again, {{citation}} should not be used as a pseudo-cs2 versions of the {{cite biorxiv}} and {{cite citeseerx}} templates. We have |mode=cs2 for that.
Trappist the monk (talk) 14:52, 24 August 2018 (UTC)

there having been no further discussion, |class= as a parameter accepted by all cs1|2 templates is deprecated. The special exception code in Module:Citation/CS1/sandbox is deleted.

Trappist the monk (talk) 10:45, 15 September 2018 (UTC)

I just recently noticed this change due to the deprecation error note showing up while editing the upcoming "Recent research" feature for The Signpost, Trappist the monk and Headbomb. I usually include the |class= parameter whenever also using |arxiv= in {{cite journal}} or {{cite conference}}. With the deprecation now implemented, the error shows up in prior issues of "Recent research" where it is triggered. I can probably clean that up without much trouble, since I am the only one who added them as far as I am aware. I am posting here, however, because I noticed something that might be relevant and worthwhile to consider. Your input is appreciated.
Specifically, I often come across arXiv citations being formatted using {{cite journal}}, likely because {{cite arXiv}} is a far more obscure template among the CS1 templates and because it is far more restricted in its parameters. Many editors may also not understand why it matters to use the correct citation template, or otherwise think {{cite journal}} is just the catch-all template one uses for scientific articles. I know the differences, but that is because I regularly cite in CS1, have spent many hours reading the documentation, and have experimented with the templates enough to understand them better than the documentation sometimes documents. That is likely not the case for some editors, especially those with only a basic grasp on MediaWiki markup.
It is my understanding that |class= has been deprecated in non-{{cite arXiv}} CS1 templates because the purpose of that parameter is to provide some indication of "the moderation involved with" the preprint when citing "the preprint as a preprint". Given that preprints are frequently cited as preprints using {{cite journal}} or some other non-{{cite arXiv}} CS1 template, does the current deprecation of |class= conflict with the whole purpose of using the parameter?
Lastly, I apologize for having not brought this up earlier. As I said above, I only recently discovered this occurred due to the deprecation error message and I do not usually check this page (but probably should do so more often). —Nøkkenbuer (talkcontribs) 20:11, 30 September 2018 (UTC)
This, I think is the only question that you asked: Given that preprints are frequently cited as preprints using {{cite journal}} or some other non-{{cite arXiv}} CS1 template, does the current deprecation of |class= conflict with the whole purpose of using the parameter? No. The cs1|2 templates are confusing; there are lots of them and there are even more parameters. The use of error messaging is one way to educate those who use these templates (because you know, even when it's good, no one reads the documentation – except perhaps you – and the cs1|2 documentation is only just marginally adequate). The purpose of |class= is not to support improper use of the cs1|2 templates but rather, to lend credence to cited preprints using the only template that we have for that purpose. For a long time I have believed that |journal= should be a required parameter for {{cite journal}}. That, to me just seems like a no-brainer. I did not get any traction with that idea when I last raised it. Imposing that requirement might address arXiv citations being formatted using {{cite journal}}.
Trappist the monk (talk) 22:04, 30 September 2018 (UTC)
Thank you for your input, Trappist the monk. It's entirely reasonable and I think justifies the deprecation; this change does not seem as such a loss to me now. —Nøkkenbuer (talkcontribs) 05:46, 1 October 2018 (UTC)

Preference for period or comma as separator in templated citations[edit]

This section is related to the above thread, #Proposal: make ref=harv the default for CS1.

I assert that the present use of periods vs. commas as separators in templated citations evolved over time, and a discussion of what pattern would be most pleasing, with an audience of those who used or developed {{citation}} and those who used or developed the cite xxx family of templates has never happened.

I suggest that if such a discussion had occurred before thousands (or is it millions) of these templates were in place, the consensus would have been something like the following.

External style guides such as APA style and The Chicago Manual of Style usually use the comma as the field separator in footnotes and endnotes (hereinafter called endnotes because Wikipedia articles are not divided into pages, in the sense that pages exist in paper books and journals). Many of these styles, such as APA style, do not provide for endnotes at all; only parenthetical references to an alphabetical list of works cited are provided for.

In external style guides, the entries in the alphabetical list of works cited use periods as the field separator.

It is less jarring for Wikipedia to follow external customs to the extent possible. Therefore, articles that only use endnotes should use the {{citation}} template, or if that template does not work well with a particular source, the appropriate member of the cite xxx template with |mode=cs2 set. If this advice were followed, most invocations of {{citation}} would have no need for the anchor.

Articles that use an alphabetical list of works cited would use the period as the field separator and parenthetical citations would use the cite xxx family and would need |ref=harv or a manually set ref value on every entry in the list.

Articles that use numbered citations generated with {{sfn}}, which in turn link to an alphabetical list of works cited, would use a comma as a separator in the numbered citations (e.g. "Howse 1997, ch. 4.", with "Howse 1997" being a link). These articles would use the period as the field separator in the list of works cited, and would need |ref=harv or a manually set ref value on every entry in the list. Jc3s5h (talk) 16:38, 26 July 2018 (UTC)

This proposal appears to force the use of one particular citation format, (i.e. CS2) and is completely against the spirit of WP:CITEVAR, which does not even specify that templates be used. Nigel Ish (talk) 17:08, 26 July 2018 (UTC)
If I've reignited any sectarian struggles here, please slap me with several trouts as needed. That wasn't my intent (as I hoped was obvious from my flippant phrasing on the issue). But so that it's clear where I stand, to the degree that's relevant, I cannot quite bring myself to care about what punctuation to use or the specific order of various bibliographic details within a full citation, or other such minor formatting issues. I do care quite strongly about short inline citation + alphabetical list of full references (aka. a bibliography), and that the two should be linked (or at least linkable). I also believe parentethical referencing (i.e. without <ref>...</ref> tags) should be actively avoided. I also believe WP:CITEVAR as it stands saves us from a lot of drama in the short and medium term, but that it's possible the reverse is true in the longer term. In any case, I truly believed my proposal above was independent of the "preferred citation style" issue, and I still don't see how making |ref=harv the default intersects with that issue. Or have I missed some faction that actually argues that {{cite book}}/{{cite journal}} without |mode=cs2 should be actively forbidden in works cited / bibliography lists (i.e. that they should be explicitly unlinkable)? --Xover (talk) 17:42, 26 July 2018 (UTC)
"I also believe WP:CITEVAR as it stands saves us from a lot of drama in the short and medium term, but that it's possible the reverse is true in the longer term." – This isn't even in doubt. It's already come true. But it will have to get much worse before the community will find the will to do anything about it.  — SMcCandlish ¢ 😼  16:14, 27 July 2018 (UTC)
Someone in the previous discussion seems to have said that the citation template (rather than the cite x series) should be used for Bibliographies and the like for reasons (which don't appear to be error related. As far as I could see, the error seems to be to do with ref templates generating duplicate ids - which are normally solved by using mangled years (i.e. 2003a, 2003b etc) or putting something in the ref= field. The more technically knowledgeable who can decipher the technobabble in the previous discussions will presumably be able to explain things better.Nigel Ish (talk) 18:13, 26 July 2018 (UTC)
My take from the thread above this one, and the discussions linked to from that thread, is that some people think it's bad to have duplicate IDs in the same article even if they don't cause an actual ambiguity, because it's invalid HTML. These IDs are, under the covers, HTML anchors. The links generated by <ref>, {{sfn}}, and harvard citations all rely on anchors, but of these, only <ref> generated links are guaranteed to be unique.
Some folks did some counting, and found that {{citation}} tended to be used with {{sfn}} or harvard citations, so making ref=none the default for {{citation}} would create lots of problems. But cite xxx tended to not be used with {{sfn}} or harvard citations, so most of those pages didn't need ref=harv. Also, historically, ref=harv hadn't been available for cite xxx, so affectionados of those templates weren't used to paying any attention to whether IDs were unique, so changing the default to ref=harv would start generating lots of non-unique IDs that people had never thought about before. Jc3s5h (talk) 19:01, 26 July 2018 (UTC)
Seems like a rather different discussion, but yes, we should avoid duplicate IDs. The entire point of an id (even before it was ever used for anchoring – that used to only be the name attribute) is to be unique.  — SMcCandlish ¢ 😼  16:14, 27 July 2018 (UTC)
This seems a bit misguided. If I were to ask a question, it would probably be "should we continue to have two separate citation styles by default, or should one or the other be moved to the other mode by default"? You would probably get as much acrimony but would have a definitive answer to "do we actually want two" instead of this particular question... --Izno (talk) 17:35, 26 July 2018 (UTC)
In short, I favor comma as a separator in endnotes and periods as a separator in alphabetical bibliographies. Jc3s5h (talk) 17:57, 26 July 2018 (UTC)
Re your initial commentary: TLDR. As to your succinctly stated preference: sure, suit yourself. Add |mode=cs2 or |mode=cs1 as desired. However, if you are thinking of having that enforced by the software: no way! ♦ J. Johnson (JJ) (talk) 19:27, 26 July 2018 (UTC)
Either way, it's a moot point, do what the hell you prefer, and follow WP:CITEVAR when you get into debates about which to use. Headbomb {t · c · p · b} 19:43, 26 July 2018 (UTC)
If I were in charge, I'd merge the two styles (use comma separators and end each in a period unless |postscript=; or similar is individually set to run two citations in the same footnote), or I'd clarify that there is some sort of footnote/endnote vs. bibliography context like CMOS referencing where one style is used for one and the other style is used in the other case. Imzadi 1979  02:45, 27 July 2018 (UTC)
Oh crap, not this again. Unwatching - notify me if you need me. --Redrose64 🌹 (talk) 09:11, 27 July 2018 (UTC)
  • "Do we collectively want multiple citation styles?" – possibly not. "Could we agree on one style?" – definitely not. End of subject. Peter coxhead (talk) 09:33, 27 July 2018 (UTC)
    We can, however, have the cite templates do sensible things by default. They mostly seem to already. Given the complexity, it'll never be 100% perfect by every criterion. E.g., Johnson, P.; Chan, S., eds. doesn't make much sense; Johnson, P.; Chan, S. (eds.) would be better. Yet, a string like this is usually followed by a parenthesized date, so it would result in Johnson, P.; Chan, S. (eds.) (1998), which is arguably worse that the comma-eds. situation in the original.  — SMcCandlish ¢ 😼  16:14, 27 July 2018 (UTC)
  • Jc3s5h's OP premise is faulty. There is no magical split between foot/end note style and bibliography style universally, even if there is for some particular publishers. Every issuer of a citation "standard" has chosen different typography and punctuation, and they're just all in conflict. Even within a discipline, sub-disciplines may use radically different citation style (e.g. cultural anthropology and archaeology, for an example that was the bane of my undergrad years).

    The best approach for our citation style defaults is to match natural English as much as possible. A citation is a non-sentence but sentence-like clause, similar to the typical image caption or list item. Ergo, we should use commas when practical, semicolons to separate material containing its own commas; semicolons between logically more separate things (e.g. author info; title info; publisher and location info), and use other punctuation as has become conventional across many citation styles, e.g. Location: Publisher with a colon, and (YYYY) parenthesized dates. Close the entire thing with a period (full point). Taking this approach will obviate annoying typographical gaffes like "Something something. pp 12–34". And pointless "full-stopping" like a machine gun after each little bit of data.

    When I encounter unpunctuated plain-text cites, and don't feel like templating them, I do this (to make up a rather maximal example): McNabb, J. P.; Heinz, Franziska (May 2011); [URL_here "Venting of blast doors to de-vulcanize flux capacitors"]; in Bluto, Jane; Fisk, P. J. (eds.); ''Neo-Boltospherical Spectroscopy'', "Studies in Arcturophasic Spectra" series, vol. 4, revised ed., pp. 12–34; Bumswaddle-on-Dee, England: University of Chickenham; via Google Books; ISBN: whatever, DOI: whatever, OtherID: whatever; accessed: date here. The date is often in another place in the order, though; many people put it toward the end, and if I'm going to move stuff around, I might as well template it. A good case could be made for using colons between the author(s) and paper/chapter title, and between the editors(s) and periodical/edited-volume title. (This would be my logical preference, but it looks nothing like what the cite templates do, so I don't impose it.) And "accessed: date here, via Google Books" would be better, but I'm basing this off examples I encounter where GB is often mis-credited as the publisher, so I look up the real one and insert it in-place. Regardless, other than for abbreviations like initials and "pp.", there is no reason for a "." anywhere is this until the end.

    However, because of the complexity of cite templates and the way they move stuff around depending on which parameters have data, making any changes to them in such a regard would be challenging, and would require a lot of testing with different templates and different bits of present and omitted data.  — SMcCandlish ¢ 😼  16:14, 27 July 2018 (UTC)

    Would not the full stops function as stronger separators of information, like the semi-colons are doing compared to the commas? The full stops can indicate stronger relationships between the data by grouping together strings using semi-colons and commas. Basically, what I am not understanding is your opposition to the use of periods in citations outside of abbreviations and such. —Nøkkenbuer (talkcontribs) 07:56, 16 August 2018 (UTC)
  • If we were to have one template for all citations eg {{citation}}, then there is no reason to stop at just 2 modes we could add in CSVCAN and scrap the dedicated vancouver templates. There can be a many styles as wanted (groan), including ones the mimic the well know external (to Wikipedia) styles. This is the major advantage of citation templates over hand-rolling citation. It would be quite easy to set the default to whatever was the most common style (at the moment CS1), but still allow the editors of the articles to override that style in an article by setting the mode parameter to something else. The point about the mode switch is it should mean that debates like the one initiated by Jc3s5h at the start of this thread become redundant. Also if there were more modes that mimicked styles like APA and CMS it might persuade of those who are anti-citation-templates to start using them, or at least not be so anti-templates. -- PBS (talk) 19:14, 16 August 2018 (UTC)

Headbomb asked me a question about only using {{citation}} in place of all the "cite ..." templates. Copied from the section #Proposal: make ref=harv the default for CS1:

Because different types of citations need to be handled differently, and presenting strong and recognizable "default" parameters names matter. What should you use to cite a book in {{citation}}? Is is |title=? Is that |work=? But if |work= is the title of a book, how can it be the title of a journal, rather than the title of the article? All of those things have answers, but they're complex. {{cite arxiv}} makes it clear which parameters you need to use when citing an arxiv preprint, and which you don't need to bother with. Same for cite journal vs cite book. Headbomb {t · c · p · b} 19:01, 16 August 2018 (UTC)

To answer your question Headbomb, I would use "title". But then I have a lot of experience so I know what I am doing if I am using the {{citation}} template. It seem to me that you are suggestion it is easier for an inexperienced template user to decide first on what it is that they are citing and then choose an appropriate template. I suggest is is simpler to have one template and one set of documentation (if needs be a table of what to use for what would be appropriate). The problem for editors new to citation templates is not the obvious case, but the one on the edge. For an online dictionary should one use {{cite book}} {{cite encyclopaedia}} or {{cite web}}? What should an editor to use for a book on at the website of Internet Archive {{cite web}} or {{cite book}}? What about a chapter of a book at the website of Electric Scotland? Another example are the books of journals often annuals, or books of magazines which are online (something that will only grow over time); how does an editor decide whether to use {{cite book}}, {{cite journal}}, {{cite magazine}} or {{cite web}}? If there is only one template like {{citation}} then there is only one set of documentation and if a set of parameters does not seem to fit then it is relatively easy to look for ones that do. With separate templates how does one choose the most appropriate for edge case? -- PBS (talk) 08:26, 17 August 2018 (UTC)

Regarding updation[edit]

Is the new update in Citation/CS1 working? Adithyak1997 (talk) 19:11, 26 July 2018 (UTC)

Do you mean the 10 June 2018 update? Are you seeing something that you think is not working properly?
Trappist the monk (talk) 00:05, 27 July 2018 (UTC)

Polluting COinS with markup[edit]

Do we have:

  1. A list of parameters affected by doing things like parameter=<em>Foo</em> {{sc|Bar}} [[Baz]]?
  2. A list of exactly what kinds of markup cause these problems, and which (like HTML character entities) do not?

 — SMcCandlish ¢ 😼  15:24, 27 July 2018 (UTC)

A list of cs1|2 parameters that contribute to COinS metadata is transcluded into every cs1|2 template doc page from Template:Citation_Style_documentation#COinS.
cs1|2 templates have the responsibility to render parameter values so that citation presentation is consistent among cs1|2 templates. Because the templates have the responsibility, there should be little call for editors to add markup to cs1|2 parameters. There are exceptions to that: common wiki italic markup can / should be used in title-holding parameters to distinguish scientific names, for example. Module:Citation/CS1/COinS removes all wiki apostrophe markup from title holding parameters before the title is included in the COinS metadata. Wikilinks are permitted because Module:Citation/CS1/COinS strips off the markup and uses only the label portion of the wikilink (if in the form [[target|label]]) or just the target portion (if in the form [[target]]).
For a while, we were plagued by cs1|2 templates that had {{'}} or {{'s}} templates in title-holding parameters so Module:Citation/CS1/COinS strips the html stuff that results from those templates and replaces them with a single apostrophe (') or 's. No-break space (&nbsp;) entities, tab, line feed, carriage return, and hair space (U+200A) characters are each replaced with a single space character. Zero-width joiner entities (&zwj;), zero-width joiner, zero-width space, and soft hyphen characters (except when any of these are used in Indic script text) are all stripped without replacement.
At one time, before MediaWiki broke math stripmarker handling (T121085) in Scribunto, Module:Citation/CS1/COinS could decode the various math markup and render an understandable text version (essentially, the alt= image attribute text from the image that is rendered in place of the math markup). Since MediaWiki broke it, Module:Citation/CS1/COinS now replaces math strip markers with 'MATH RENDER ERROR' text so that we don't percent encode the strip marker text which would look like gibberish to COinS consumers; of course, 'MATH RENDER ERROR' isn't very helpful to those consumers either. Perhaps someday, MediaWiki will repair the damage they have done; I'm not going to hold my breath for that.
Certainly some html markup is desirable in title-holding parameters. There are cases where the <sub>...</sub> and <sup>...</sup> tags should be used (chemical and element names, simple math text, etc). Those are currently passed into the COinS (as is any of the markup that hasn't been stripped). There may be other specific cases where html markup is desirable, but for the most part, I think that such markup should not be used in cs1|2 parameters whether those parameters are made part of COinS or not.
Trappist the monk (talk) 18:36, 27 July 2018 (UTC)
In the same order:
  • Re "transcluded into every cs1|2 template doc page" – Okay. I wanted to make sure this was the total list, and not partial (i.e., depending on which template page you're looking at, the way the rest of the documentation subtly changes).
  • I'm relieved that wiki-apostrophe italics (and bold?) will work fine; what about other non-HTML-tag wiki markup? I'm not sure much would be used, but it's worth knowing for sure.
  • I'm not sure I understand the links part. It seems to suggest that |chapter=[[Politics and the English Language]] and (for journal or news) |title=[[When Zombies Attack!: Mathematical Modelling of an Outbreak of Zombie Infection]], and (for book) |title=[[On the Origin of Species]] are okay, yet the templates usually seem to throw link-in-title errors about this. The more general case of |work=[[The New York Times]], and other things that resolved to |work=, like |journal= and |website=, do seem to work.
  • If {{'}} and {{'s}} are being filtered out, might want to do that with {{"'}}, etc. As I reported earlier, people are definitely using them in title parameters and removing them all would be a massive hassle. Being able to use them would actually make the refs material easier to read.
  • "line feed, carriage return ... characters are each replaced with a single space character" has not been my experience at all; the template instead throw a loud warning about linefeeds in the title, which makes no sense to me since HTML is whitespace-agnostic.
  • "of course, 'MATH RENDER ERROR' isn't very helpful to those consumers either" – True, but they're readable by us, so we can at least try to do something manually.
  • "I'm not going to hold my breath for that." No kidding. I've been waiting over a decade for some basic bugs to be fixed.
  • "Certainly some html markup is desirable in title-holding parameters. There are cases where the <sub>...</sub> and <sup>...</sup> tags should be used.... Those are currently passed into the COinS" – So, COinS will literally receive E=mc<sup>2</sup>? If that's not a severe problem on the COinS side, then I'm not sure what the dividing line is supposed to be.
  • It would be nice if some specific HTML was stripped, namely all the presentation and semantic markup tags like <u>, <em>, <code>, etc. I see these in titles frequently. What's the process for proposing something specific? I really have little awareness of where the "guts" of this system lives and who is managing it and where.
  • "I think that such markup should not be used in cs1|2 parameters whether those parameters are made part of COinS or not." Well, why? It's nice that we're supplying COinS for people who might use it, but the central purpose of our cites is for WP readers, so making the material accurate and readable for them is the no. 1 priority. I really don't like not being able to use <code>...</code> in titles of various technical citations; some of them are difficult to interpret without it.
Anyway, thanks for the clarifications so far. I'll try revising MOS:TITLES#Typographic conformity again to better account for some of this.  — SMcCandlish ¢ 😼  19:49, 27 July 2018 (UTC)
PS: What you've said above seems to contradict the docs transcluded into Template:Citation Style documentation#COinS, in at least two (contiguous) places: "Also, HTML entities, for example &nbsp;, &ndash;, etc, should not be used in parameters that contribute to the metadata. Do not include Wiki markup '' (italic font) or ''' (bold font) because these markup characters will contaminate the metadata." Is the doc simply outdated?  — SMcCandlish ¢ 😼  19:56, 27 July 2018 (UTC)
I'm shocked. Shocked! to find that the documentation sucks.
  • I think that those listed parameters are all, but as noted, the documentation sucks and often lags far behind the implementation.
  • yeah, bold markup is supported in cs1|2 title holding parameters though perhaps it shouldn't be. Surely we should support necessary markup, but bold in citation renderings except where applied by the template is, I think, mere decoration
  • wikilinks in titles are allowed (all of those cases you illustrate will work as long as |url= is not set. MediaWiki does not know what to do if you simultaneously try to make an external link and a wikiling of the same text. When you attempt that in cs1|2, Module:Citation/CS1 links |title= with the value assigned to |url=, shows the wiki markup and an error message; You get the same results when you simultaneously set |title=, |title-link=, and |url=.
  • there is no reason for editors to be using {{"'}} and the like in cs1|2 templates; Module:Citation/CS1 has built-in kerning
  • those characters are removed from a copy of the parameter value before it is added to the metadata; the error message is there so that editor know to remove these extraneous characters from the wikisource
  • yes, COinS will get the <sup>...</sup> tags. The dividing line for me is simple, legitimate, html tags; that means no styling, no attributes, no classes, etc because that stuff is presentation information for a specific application (en.wiki) which may be (likely is) inappropriate for other applications; there has been little discussion about this and no action taken except to flag a bunch of templates as inappropriate for use in cs1|2 templates; arguably, rtl languages should be have markup; there has been very little discussion on that topic
  • everything related to cs1|2 from complaints to rfcs should happen here on this talk page
  • it is the duty and obligation of the cs1|2 templates to style rendered citations because consistent styling is important to editors at en.wiki; for that reason, there should be no need to markup anything except titles so that these titles comply with MOS and the common renderings of mathematical, chemical, and scientific terms and names; no doubt that there are other things that might be acceptably marked up.
Trappist the monk (talk) 20:17, 28 July 2018 (UTC)

Stop using journal style for book volumes[edit]

It's fine that journal volume and issue info come out as things like "5 (11)", but this isn't appropriate for books, which should be rendered "vol. 5". The journal style doesn't even make much sense in the (frequent) case of no issue number. It's the very juxtaposition of the bold volume and the parenthetical issue that makes the format easily parseable.  — SMcCandlish ¢ 😼  16:21, 27 July 2018 (UTC)

Honestly I think we should just ditch the special, not-parsed-by-anyone-except-journal-readers, bold and parentheses and actually provide the abbreviations in all cases, as {{cite magazine}} does presently. That's somewhere on my to do list... --Izno (talk) 18:00, 27 July 2018 (UTC)
I strongly support that idea (full "vol. 5, no. 11" style) but wasn't sure I should propose it, since the academical editors around here might revolt. At bare minimum, I want it back for non-serial publications, especially books, but it should also be done for videos and some other stuff that aren't magazines, journals, or newspapers.  — SMcCandlish ¢ 😼  19:22, 27 July 2018 (UTC)
I also support the idea, firstly because its much more intuitive, and also because on Wikipedia, we are much more likely to mix references of different types in articles, so clearer and more consistent presentation is better.Nigel Ish (talk) 19:56, 27 July 2018 (UTC)
  • Support for books; indifferent for journals. Art of Programming vol. III is clear, but Art of Programming III is odd. Glrx (talk) 21:11, 27 July 2018 (UTC)
"Support"? Is there a definite proposal on the table?
As an aside I remind everyone that journal volume numbers are very significant and warrant bolding, while book (and other) volumes are not always appropriately rendered with "vol." ♦ J. Johnson (JJ) (talk) 22:58, 27 July 2018 (UTC)
Well, it looks like there's two proposals: 1) implement "vol." for books and such, and 2) do that plus also implement "vol." and "no." for periodicals. I'd support the latter as first choice and former as second, though I'd only intended to propose the former.

If there's a case where a book "volume" is not expressible with "vol." then that's probably the wrong parameter, since it's not actually a volume. If there is some case where it is the right parameter and "vol." still somehow couldn't apply (examples please), then we can use a "vol." label-suppressing parameter. Easy fix. Next, being significant doesn't equate to "warrants bolding". If the "5 (11)" style is used, it seems to make sense to bold the volume there, and this style is seen in some off-site citation formats, but it is not the only style, and it's geeky, so why not just do "vol. 5, no. 11"? It's understandable to more people, is not confusing with either volume or issue don't apply, and there are no readers who prefer "5 (11)" style who are unfamiliar with or won't understand the other style, while reverse is not true.

 — SMcCandlish ¢ 😼  23:20, 27 July 2018 (UTC)

Anyone that doesn't understand how to parse "Some Journal, 5 (11)" probably isn't up to mucking around in a journal environment in the first place, so that problem hardly arises. As to "vol. 5, no. 11": why abbreviate? Why not go for the whole hog with "volume 5, number 11"? One answer: excess packaging– i.e., clutter – for the information presented. Even though we are not subject to the same space constraints as (say) a journal, full citations can get long, and succinctness is not a sin. ♦ J. Johnson (JJ) (talk) 20:34, 28 July 2018 (UTC)
You appear to be saying that anyone who doesn't have an academic background and so isn't familiar with academic reference formatting, shouldn't be looking at references at all. If references aren't for the readers, who are they for?Nigel Ish (talk) 11:48, 29 July 2018 (UTC)
No, I am not saying that, not at all, and certainly not what anyone should or shouldn't be looking at. What I am saying is that anyone doesn't understand what "5 (11)" means probably is not looking into journal references in the first place. If someone lacking an "academic background" should follow a citation back to a journal source I think most people will quickly figure out the convention. If not, then they probably also lack understanding that "no." is an abbreviation for "number" (I was a little surprised to learn that–back in the 8th grade), which is the same as "issue number" or just "issue", and perhaps we should have such abbreviations wikilinked to an explanation. ♦ J. Johnson (JJ) (talk) 21:16, 30 July 2018 (UTC)
  • Support for books, not for journals, at least at this moment. Headbomb {t · c · p · b} 12:49, 28 July 2018 (UTC)
  • I generally prefer fewer abbreviations, and more clarity, so would go with volume and number as first choice, vol. and no. as second choice. We want people who are not familiar with the systems to find the reference as easily as possible. · · · Peter (Southwood) (talk): 12:11, 29 July 2018 (UTC)
For "find[ing] the reference as easily as possible" a direct link is generalliy preferred and sufficient, and all those other niggling descriptive details can be ignored. Lacking such a link the reader will likely be faced with more daunting challenges than not having a volume number explicitly labelled as such.
BTW, please note that I am talking about journals, not newspaper or popular magazines, for which "vol." and "no." are conventional. In that regard I am fine with not "using journal style for book volumes". (And when did we start doing that?) Note also that is is precisely for the purpose of finding (within the citation) as easily possible the volume number that they are bolded. ♦ J. Johnson (JJ) (talk) 21:38, 30 July 2018 (UTC)
Journal style for book volumes was implemented at this edit to {{cite book}}, at the time, still a stand-alone template, and at this edit to {{citation/core}}, about four months later. {{Citation}} had been using {{citation/core}} for more than a year by that time.
Trappist the monk (talk) 22:20, 30 July 2018 (UTC)
Note that cite news also uses the numbers without label style, like cite book and cite journal. Should newspapers and the like follow the cite magazine styling or the cite journal styling?Nigel Ish (talk) 17:16, 12 August 2018 (UTC)
  • Support. This is so confusing on books. I suspect many put the volume in the title parameter instead, and that's not good for the metadata. Even I've done it sometimes. – Finnusertop (talkcontribs) 10:24, 25 September 2018 (UTC)
    • Putting the volume in the title can be difficult to avoid, in cases where the volume has its own separate subtitle (the Knuth example discussed above) or for when a multi-volume book is also part of a book series and has a volume number (or multiple volume numbers) in the series that are different from the numbers of volumes within the book. —David Eppstein (talk) 10:33, 25 September 2018 (UTC)

Permit access-date in absence of a URL[edit]

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.
(non-admin closure) The result is by consensus Yes, keep the current practice. Plus, the instructions about citing web sources are quite clear: "Access date" is the full date when the content pointed to by URL was last verified to support the text in the article; requires URL. Emphasis on the last sentence.
The objections against the current practice are indisputably well meaning. Supporters of retaining the Access Date in the absence of a URL invoke policies such as WP:AGF and essays such as WP:HIJACK but those are irrelevant: Citation highjacking can be amended easily and quickly by re-adding extant, live references, while the value of information in an article should be weighed on its own, i.e. the Wikipedia user searching for information is not interested in the good faith, assumed or not, of previous editors.
Jonesey95 pointed out that a no-URL access date "shows a diligent reader where to look at archive.org to check a source that may have changed since the access-date." However, an online search is an online search and the date when a web source was last accessed, even if the date accepted is correct (i.e. not a mistake), is not a significant factor in online-source search.
Objections regarding technical difficulties, such as the adjustment of bot functions, can be discounted since bots are here to assist human editors in their work and not to shape the work. The Gnome (talk) 08:00, 29 September 2018 (UTC)


Should use of |access-date= in citations (indicating the last date at which the source was checked as verifying the claims for which it was cited) be treated as an error and removed from citations that do not have a URL?  — SMcCandlish ¢ 😼  04:36, 28 July 2018 (UTC)

Comments[edit]

  • No. Somehow we've lost the |access-date= in {{Cite book}}. This is a terrible idea. At this point, probably the outright majority of book citations (or at least new ones being added) are via Google Books or otherwise have a URL. The |access-date= tells us something important: The date at which someone verified [or indicated they verified] that the source cited is a source for the claim[s] appearing in front of that citation. This is one of the ways we can detect WP:Citation hijacking. Keep in mind also that what is available at Google Books or some other site might change at any time; just because a snippet view with the content needed was visible on 29 March 2007 doesn't mean it is now. If someone goes to verify the claim and can't find it in the online material, they're apt to delete the claim or put {{failed verification}} on it, when it may in fact really be in that book, just not visible right now at that particular |via='s URL. If the access-date is also from 2007 or so, this is an indicator that we may need to check the print source. If the access-date is yesterday, then it's probably sourcing falsification.  — SMcCandlish ¢ 😼  19:20, 27 July 2018 (UTC)
    John Smith (2003). Title. p. 8. Retrieved 20 February 2011. works for me. Headbomb {t · c · p · b} 19:22, 27 July 2018 (UTC)
    I must be losing my mind. I just had it fail for me within the hour. Will see if I can replicate it.  — SMcCandlish ¢ 😼  19:58, 27 July 2018 (UTC)
    Ah, it's failing when there is no URL: John Smith (2003). Title. p. 8. |access-date= requires |url= (help). This is still arguably undesirable, because the date info tells us when someone looked at this data and confirmed it as sourcing the claim. I guess it's not a fatal problem, since it remains in the wikisource, but I've seen well-meaning but boneheaded gnomes remove it as "inapplicable" and it's tiresome to have to revert them again and again. Maybe the doc should be updated to say to leave the "silent parameter" there as an anti WP:HIJACK tool.  — SMcCandlish ¢ 😼  20:06, 27 July 2018 (UTC)
    Done [1]. This is a good compromise. Don't actually need the a-dates to be rendered in absence of a URL, but people shouldn't be nuking them either.  — SMcCandlish ¢ 😼  20:12, 27 July 2018 (UTC)
    if this change is agreed then the tracking category Category:Pages using citations with accessdate and no URL and the section at Help:CS1_errors should be deleted as being of no use and/or contradictory to the change you've just made. Nthep (talk) 20:25, 27 July 2018 (UTC)
    If I am not mistaken it was removed because the archive bot doesn't work for them and gives us dead links if there is an access date.--Moxy (talk) 20:20, 27 July 2018 (UTC)
    So, fix the bot. Agreed that the material at Help:CS1 errors should change. Category:Pages using citations with accessdate and no URL can stay; not all maintenance categories are about errors and indicate a backlog; many of them (e.g. all our redirect classification categories) are useful for other things. This one in particular could be used for periodically re-checking for online versions of things to provide URLs, and can be sifted through for, e.g., erroneous uses of {{cite web}} without the required URL parameter, and so forth and so on.  — SMcCandlish ¢ 😼  23:10, 27 July 2018 (UTC)
    Alright, so Izno's reverted me here [2] with a claim there's a "general consensus" against the idea. I don't believe this is true at all. I've been involved in most of the previous discussion of this and it's the same handful of bot-oriented people who oppose the idea, and who never respond substantively to the content-editorial concerns. This is a WP:STONEWALL, a WP:FALSECONSENSUS. It's been tiresome for a long time. "The bot won't handle it the way want yet" is a reason to upgrade the bot. The tech tail does not wag the editorial, content verification dog.  — SMcCandlish ¢ 😼  00:05, 28 July 2018 (UTC)
  • Yes, keep current behavior. Can you explain how having an access-date but no URL for a book source is in any way useful? What information is it supposed to convey to other editors (since it will be invisible to readers)? How is this in any way an anti-hijacking measure? If editors are checking whether a diff hijacked a reference, how will looking at this date help them? Are you expecting people who add an updated claim from the same reference, in a way that looks like it could be hijacking but isn't, to understand your cryptic countermeasure and update the access-date in order to reassure you that they're on the up-and-up? Why do you think they will know or care to do that? —David Eppstein (talk) 00:27, 28 July 2018 (UTC)
    My understanding is that |access-date= exists to show when a web page was verified as supporting a specific claim. Since web pages can change, the access-date shows a diligent reader where to look at archive.org to check a source that may have changed since the access-date.
    Books, journal articles, and other sources that exist in a revision-controlled world (e.g. edition or version numbers are almost always explicitly changed when the document is changed) do not need an access-date, because they (presumably) do not change. – Jonesey95 (talk) 00:35, 28 July 2018 (UTC)
    I agree broadly with these points. --Izno (talk) 00:55, 28 July 2018 (UTC)
  • Accessdates without URL should absolutely be removed. User_talk:CitationCleanerBot/Archive_1#Accessdates outlines why in details, but it largerly mirrors Jonesey/Izno/David Eppstein's points from above. Books are fixed resources, accessdates are completely pointless for them when there is no url (and even with them they are pretty near pointless). Headbomb {t · c · p · b} 01:29, 28 July 2018 (UTC)
The obvious problem with this analysis is that it's our own content that is more likely to change than any URL, very frequently resulting in WP:HIJACK. This is a massive hassle to track down, and is made much easier with an access date: you simply go directly to that date in the page history; on a busy page this can save a tremendous amount of time digging around trying to figure out when a cite was first added. This verifiability boosting effect has nothing to do with URLs. It's weird to me that people aware that the parameter can serve one function seem blind to the fact that it can serve another which is also important. Seems a bit like denying that italic markup can be used for anything but titles of works and "therefore" that its use for genus and species should be banned. Heh.  — SMcCandlish ¢ 😼  05:26, 28 July 2018 (UTC)
You cannot hijack a non-websource, so again, |access-date= makes no sense when there's no URL. Headbomb {t · c · p · b} 00:31, 30 July 2018 (UTC)
He is referring to the phenomenon where some editor adds new claims in front of an existing footnote so that it looks like the new claim is sourced when it isn't. He wants to abuse access-date to somehow detect this problem. I think this is a mistaken attempt at a solution (because it only works if everyone who adds new claims also knows to adjust the access-dates, and if the people who want to insert claims without taking the effort to source them don't also learn to adjust the access-dates to make their changes stick). But it's not a non-problem. —David Eppstein (talk) 01:43, 30 July 2018 (UTC)
  • Keep current behavior. I don't know anything about a bot and certainly would not argue that a bot shouldn't be fixed, were that the objection. :) I am just asserting "'accessdate requires URL' because the accessdate is for the URL" has been the use of the parameter since 2009 in Citation/core. The warning was added in 2013 during conversion to Lua (and categorization somewhere later). --Izno (talk) 00:43, 28 July 2018 (UTC)
  • Opening this as an RfC since I'm being revert warred on dispute tags trying to draw additional eyes and minds to the discussion.  — SMcCandlish ¢ 😼  04:36, 28 July 2018 (UTC)
    Since you retroactively turned our conversation into an RfC (not generally a good idea), I've retroactively edited my comment to add a boldfaced word at the start that makes clear my position. —David Eppstein (talk) 04:49, 28 July 2018 (UTC)
    I did as well. And RfC stuff happens this way all the time. No one cares, as long as the question is clear. :-)  — SMcCandlish ¢ 😼  05:21, 28 July 2018 (UTC)
    @SMcCandlish: But the question isn't clear (see David Eppstein's mis-clarification in edit history), and it too narrowly focusses on your Google Books use case to the detriment of issues such as that brought up by Masem. What you're really asking about is the semantics of |access-date= (which is a wide issue worth debating properly), but you've phrased it as a question about a simple technical issue. The issue isn't |url= or no URL, it's ephemereal source or not. --Xover (talk) 06:17, 28 July 2018 (UTC)
  • Yes—continue to treat the access date as an error for offline sources. Access dates in citations exist to give a known date for a source published without an explicit date, or to confirm a date when a source of an ephemeral nature was accessed. Fixed sources, like printed materials, do not need such a thing. Imzadi 1979  05:35, 28 July 2018 (UTC)
  • Oppose I am sure that there are electronic resources that you cannot provide a direct URL to the resource (or enough of one to meet WP:V) which do get updated over time, so the access date is important for those resources. There's likely only a handful of such cases, but they still exist. --Masem (t) 05:42, 28 July 2018 (UTC)
  • Keep present behaviour – the access date relates to the material located at the URL, and is inappropriate for sources with no URL – it's not to verify when the editor checked, but to indicate which version of a possibly changing web page was accessed. Peter coxhead (talk) 06:34, 28 July 2018 (UTC)
  • Yes, keep present behavior. The RFC question asserts that this date represents "the last date at which the source was checked as verifying the claims". However, I don't think that is entirely true. It seems to me that – in actual practice, and not withstanding the OP's past efforts to change it – it represents the last recorded date at which the URL was known to be working (i.e., both not a dead link and also still leading to the cited source). There is no point in recording a "URL still working as of" date when there is no URL. Also, NE2 seems to have originated this idea and may want to comment on whether this idea seemed descriptive of actual practice, or if it might have been a bit of hopeful thinking. I don't think that I've ever seen anyone treat this date as meaning that the source had been checked; if so, then we should never put {{verify source}} after any citation that contains an access date (because that allegedly means that some actually already did verify every single one of those citations with access-dates, right? Well, I'd say no, myself, but I'd also change the help docs to be clearer that it doesn't mean that). WhatamIdoing (talk) 06:49, 28 July 2018 (UTC)
    • A slightly more specific response than yes/no:
      • If a URL is not present, the access-date should not display. It should not necessarily display an error when |url= is empty, as the relevant "URL" might be one of the identifiers. I don't really care whether bots or AWB scripts keep or remove them.
      • If a real date is present, I think that the access-date generally does not need to display. I don't care what date you looked up something on Google Books; I care when the book was published. However, it's possible that the ideal varies by source type: display for cite web and cite news, but not for cite book and cite journal.
      • Nobody should treat access-date as meaning that the cited source and the current wikitext claim were checked for being the related. The meaning of access-date is that you could access the cited source at that time. It is not a verified-on-date.
You should especially not treat access-date as meaning verified-on-date when the URL leads to identifier records such as worldcat.org or paywalled sources (e.g., most scientific journal articles). Those URLs rarely verify the content directly, even though they are valuable links. WhatamIdoing (talk) 16:06, 28 July 2018 (UTC)
Well, the access-date parameter indicates the date that the source was last checked, so in a way it gives you both the date that the URL was last live, and the date when the resource at that URL was consulted for the article. Otherwise, what's the point of a parameter that says a given URL was live when the content at that URL isn't relevant anymore? – Uanfala (talk) 16:17, 28 July 2018 (UTC)
No, it doesn't indicate the date that the source was "last checked". It indicates "a day" (perhaps only rarely "the last day", since these dates are not usually updated) when the source was "accessed" and determined to be present at that URL. There is a significant difference between "The citation says that this is the 'About Us' page at example.com, and I found that it was indeed the 'About Us' page for that website" (which is what that date means) and "I went to this page, and not only is this the URL to the 'About Us' page still working, I scrolled through the whole 'About Us' page just to make sure that it still says that Alice Expert is their Chief Expertise Officer".
As for why that's relevant, WP:Link rot is a problem with sources that aren't web-only and endlessly mutable (such as 'About Us' pages). It's also a problem with URIs to pages whose content will reliably be preserved somewhere, such as newspaper articles and government records. (Remember all the problems we had with editors adding links to news.yahoo.com links, all of which expired after a couple of weeks?) WhatamIdoing (talk) 05:30, 1 August 2018 (UTC)
Well, if that were the way this parameter is most commonly used on wikipedia, then it would be either misleading or at best entirely useless, and should be deprecated altogether. But that's not how editors normally use it and it's not how it is supposed to be used, see for example how documention of Template:Cite_ web#URL: defines access-date: "Full date when the content pointed to by url was last verified to support the text in the article". – Uanfala (talk) 12:40, 2 August 2018 (UTC)
  1. A date-of-last-working-URL isn't entirely useless, as it gives editors a chance to figure out which dates to focus on, if they're trying to find an archived copy of the link. It's probably also useful to the occasional reader. I expect people to be less surprised if a URL marked "Retrieved 1 January 2006" (NB: not "Checked" or "Verified" or anything like that – just "Retrieved") doesn't work, compared to a URL marked "Retrieved <yesterday>".
  2. The idea that it represents an editor (i.e., any editor after the person originally adding it) carefully determining that "the source actually verifies X" rather than "the source is present at this URL" appears to be wishful thinking. I don't think that I have ever seen anyone update these dates in a citation and say that they checked to make sure that the source truly supported the content; have you? However, I have seen editors check that a link is working/leads to the expected source more than a few times. Probably sometimes it's both (e.g., when the title of an article is sufficient to verify the content), but I've never seen someone mention doing both. WhatamIdoing (talk) 06:43, 4 August 2018 (UTC)
Well, if editors need a chance to figure out which dates to focus on when recovering a dead link, then what they actually need it is the date when the relevant text was found at the URL, not the date when that URL had any text whatsoever. As for the situations where editors update the access date, these are really rare: typically during large rewriting of articles (and hence when the sources have been consulted). Yes, I've seen editors fiddle with the access dates without bothering to check if the text there is actually the same text as the one used for the article, but that has been in the context of careless use of tools (like reFill, which very suggestively does not change the dates by default), but these editors have normally stopped when it was pointed out to them how citations work. Now, in light of the quotation from the template documentation above (sorry for not coming up with this earlier), it seems that your view is at odds with the way these templates are meant to work. If you would like to change the way they're supposed to work, you might want to make a an independent proposal to that effect. – Uanfala (talk) 09:21, 5 August 2018 (UTC)
  • Comment: I'm not sure about using accessdates for sources without a URL, although I have done it and don't see it as problematic. But, like SMcCandlish, I do prefer to use accessdates for book sources. As seen in this brief 2016 discussion, Sangdeboeuf (then known as Coconutporkpie) told me, "Template:Cite book states that this parameter is 'Not required for linked documents that do not change. For example, access-date is not required for links to copies of published research papers accessed via DOI or a published book, but should be used for links to news articles on commercial websites'." I told Sangdeboeuf that "like various other editors, I use accessdates for book sources...just like I add URLs or quotes for book sources; it's my style, and I do not intend on changing it." Checkingfax agreed with me, stating, "If a cite book template contains a URL I absolutely include an accessdate too. The cite book template example above provided by a Diff 'does' include a URL so for sure I would include an accessdate too. I used to include accessdates for all book cites but I have backed down. For one thing, if you include an accessdate and the cite does not already include a URL, then there will be a big red error code in the references section stating 'reference error: accessdate= requires url= (see: help)'. Books are not subject to WP:Link rot, but URLs to books are, and so books with URLs need accessdates too." In this 2017 discussion, we see that Trappist the monk, who deals with a lot reference cleanup, is against accessdates for books. He stated, in part, "The pu[r]pose of an access date is to identify the date on which an ephemeral source was consulted. For those sources that have nil chance of changing from one day to the next (books; encyclopedia; journal, newspaper, magazine articles; any on-line something with a doi, etc.) access dates are unnecessary, do not benefit the reader, and add to the clutter that is the reference section. For ephemeral sources (web pages, on-line news articles, etc), an access date is important because it allows the reader to hunt down an archived copy of the page as it was on the access date. [...] If it is necessary to determine when you added a cs1|2 template to an article, there is a tool to help you. At the top of every article's history page is a link Revision history search. For example: say that you want to know when you added the Ferri's Clinical Advisor 2013 template. Copy the title (best from the wiki source because the template or browser may have modified the what you see), go to the history page and click the history search link and paste the title into the 'Search for' box. Click the 'Start' button and get the result." Since then, I have employed Trappist the monk's style of no accessdate for book sources (using the vauthors template). Flyer22 Reborn (talk) 08:46, 28 July 2018 (UTC)
  • Yes, keep present behavior Under Verfiability policy, verifiability is not the same as access per Wikipedia:Verifiability#Access to sources. It's not 'verify date', it is 'access date' -- we should not have called it 'access date', if we wanted, 'verify date'. As a matter of practice, it is almost certain that when editors read the source again, they do not update the access date, so it is not last verification, it is about when the web-address was 'accessed' (and that is all it is). -- Alanscottwalker (talk) 09:42, 28 July 2018 (UTC)
  • Conditional treat lack of URL as correct. If someone can explain a plausible scenario where someone would use a changable computer source as a citable reliable source in Wikipedia, but that source is not accessible through a URL, then I will support having an access date with no URL, and rendering this access date in the article. Hypothetically I could imagine a room at a special library or government office where the public can go and look something up with terminals that are not connected to the Internet, or some sort of mobile phone app that lets you look stuff up but there is no URL. So can anyone give a real life scenario where something like that could happen? Jc3s5h (talk) 11:13, 28 July 2018 (UTC)
  • Create a new parameter - Having a parameter that tells us when someone last checked to see whether a citation actually supports the content is useful... but that is not the purpose of the “access date” parameter. The solution is to create a new parameter. Blueboar (talk) 12:31, 28 July 2018 (UTC)
    There is zero need for such a parameter. The words in books don't change when you put them away. Headbomb {t · c · p · b} 12:43, 28 July 2018 (UTC)
    The words in books don't change, but the text in our articles (supposedly supported by the book/website) does. SMcC is approaching this from the text side ... not the source side. He isn't really talking about the date that the source was added to the citation ... but the date that the text of our article was last checked against the source. Blueboar (talk) 22:11, 28 July 2018 (UTC)
    Ignoring the fact that this rationale has been refuted doesn't magically make it unrefuted. Repeat: The obvious problem with this analysis is that it's our own content that is more likely to change than any URL, very frequently resulting in WP:HIJACK. This is a massive hassle to track down, and is made much easier with an access date: you simply go directly to that date in the page history; on a busy page this can save a tremendous amount of time digging around trying to figure out when a cite was first added. This verifiability boosting effect has nothing to do with URLs. It's weird to me that people aware that the parameter can serve one function seem blind to the fact that it can serve another which is also important.  — SMcCandlish ¢ 😼  14:29, 28 July 2018 (UTC)
    There is a tool that allows one to find when a bit of wikicode was added so there is no loss. And can you depend on the access-date being what you expect because users may put when they accessed the book (2 years ago), not the date they added the citation which is what you're after and conceptually not the same as access-date. -- GreenC 14:56, 28 July 2018 (UTC)
    There's no need for a new parameter when this one works fine. It does not render when there's not URL, so it doesn't do anything confusing. Its presence in the wikicode, however, preserves the last verification date with is only something a editor doing WP:V checking is going to care about or see.  — SMcCandlish ¢ 😼  14:29, 28 July 2018 (UTC)
  • Keep current behaviour per User talk:CitationCleanerBot/Archive 1#Accessdates and above, since this is now a formal RFC. To recap, books and other offline resources are unchanging, it does not matter when you read the book, the words printed in it are no different in 2008 than in 2018. But also if you put a |access-date=28 July 2018 today, if someone finds a free link to the book in 2 years, and puts that up, then you'll have a wrong access-date suddenly display. There is zero benefit to anyone to know that Bob read a book on a specific date, it's the same book today as it was then. Access-dates only make sense you have url to go with them. Headbomb {t · c · p · b} 12:41, 28 July 2018 (UTC)
  • Comment - While such a parameter seems irrelevant for paper sources as the physical copy which is seen doesn't change - could this be relevant for ebooks and the like, as these might be subject to some sort of updates/changes after they have been initially downloaded?Nigel Ish (talk) 14:08, 28 July 2018 (UTC)
    Ebooks can have revision numbers. However a |accessdate= wouldn't help since it's still unknown what revision number is being referred to. In those cases, where revision matters, one should signify the ebook revision number.
  • Yes, keep current behavior It's confusing to use |access-date= for immutable sources, or sources that change according to revision ID (see comment above). -- GreenC 14:49, 28 July 2018 (UTC)
  • Yes, treat it as an error. Access dates should not be added to books; what date an editor read a book is irrelevant. Regarding other citation templates used for online sources, we need a URL for an access date to make sense. An access date is the date on which the URL was accessed. SarahSV (talk) 15:37, 28 July 2018 (UTC)
    • Do you have any estimate about how often a digital-only book might get updated/changed? The access date for a paper source (whether books or other media) is irrelevant, but I wonder whether some ebooks should be treated the same as a website. WhatamIdoing (talk) 06:46, 4 August 2018 (UTC)

The above discussion is preserved as an archive of the debate. Please do not modify it. No further edits should be made to this discussion.

Links to citation bot, revisited[edit]

Let's revamp the functionality. In {{cite arxiv}}, when you have an incomplete citation (missing mandatory parameters), you have (the rather outdated)

whereas in {{cite journal}}, you have something like

Let's streamline the functionality to look like

  • <normal output> when all mandatory parameters are present
  • <normal output> + <bot message> when one or more mandatory parameters are missing

This would look something like

This should be rather straightforward to code, when something mandatory is missing, append —&nbps;[https://tools.wmflabs.org/citations/process_page.php?edit=toolbar&page={{FULLPAGENAMEE}}&slow=1 Attempt to fix with Citation bot]. This will also streamline {{cite arxiv}} rather than make it the exception.

Headbomb {t · c · p · b} 17:53, 28 August 2018 (UTC)

Looking at Module:Citation/CS1/Configuration, it seems the way to go would be something like a botfixable = true in (for example)

    accessdate_missing_url = {
        message = '<code class="cs1-code">|access-date=</code> requires <code class="cs1-code">|url=</code>',
        anchor = 'accessdate_missing_url',
        category = 'Pages using citations with accessdate and no URL',
        botfixable = true
        hidden = true
         },

which would append —&nbps;[https://tools.wmflabs.org/citations/process_page.php?edit=toolbar&page={{FULLPAGENAMEE}}&slow=1 Attempt to fix with Citation bot] after (help) Headbomb {t · c · p · b} 01:19, 3 September 2018 (UTC)

@Trappist the monk: this would be a pretty hugely helpful addition. If you can implement the 'botfixable = true' part, I can sync the sandbox to keep which errors are bot-fixable with current bot functionality. Headbomb {t · c · p · b} 01:23, 3 September 2018 (UTC)
Why? If the bot can fix these kinds of errors, there are whole long lists of them at Category:Pages with citations lacking titles and Category:Pages using citations with accessdate and no URL; turn the bot loose on the category pages. Those articles that remain in those categories after the bot runs have completed would not be aided by this proposed change.
Trappist the monk (talk) 13:43, 3 September 2018 (UTC)
Three reasons. The first is that the bot still makes too many mistakes to be unleashed on 100000+ pages without review. The second is that category runs still require manual activation, and will often crash 100-200 articles in when the bot encounters something like a badly-formed DOI. And third, even if all the bugs were fixed, and continuous runs were possible, it would still take months to clear the categories. There is no drawback to letting editors trigger the bot manually to get ahead of the queue, like we do for {{cite arxiv}}. Headbomb {t · c · p · b} 13:57, 3 September 2018 (UTC)
The crash is fixed. The othet reasons still stand. AManWithNoPlan (talk) 03:44, 22 September 2018 (UTC)
  • I see no reason not to activate this again. (tJosve05a (c) 01:31, 9 November 2018 (UTC)
  • As long as we show those red messages in the view mode, I think it's useful to add a link which helps people fix them with little effort. If/when they can be fixed automatically, we could as well stop showing them out of the edit preview and just use tracking categories. But we're not there yet. Nemo 12:10, 14 November 2018 (UTC)

Category:Pages using citations with accessdate and no URL[edit]

This category has been processed by User:GreenC bot/Job 5 per previous discussion. There's not much else that can effectively be done by bot. Per the RFC from 2013, the bot has fixed "resolvable instances" or a little over 50%. Recommend the remainder display a red notice, to manually find and fix. -- GreenC 00:05, 6 September 2018 (UTC)

Yes! I concur. The other two error categories should also be unhidden:
Category:Pages using citations with format and no URL
Category:Pages using web citations with no URL
Trappist the monk (talk) 00:35, 6 September 2018 (UTC)
Absolutely support all three messages being enabled. Thank you so much, GreenC, for finally taking on this task. Having a bot run through the category was a necessary condition for enabling the error message. – Jonesey95 (talk) 03:56, 6 September 2018 (UTC)
I'd only support enabling those if we added links to Citation bot to facilitate cleanup. Headbomb {t · c · p · b} 17:35, 16 September 2018 (UTC)
Until Citation bot has the long list of bugs fixed and has been well tested to determine how useful it is in this scenario of missing URLs, I wouldn't support that proposal. In the meantime, that proposal shouldn't hold up this one as they are not dependent on one another. The community shouldn't have the warning messages withheld, they can begin fixing the problems immediately the old fashioned way. -- GreenC 14:20, 18 September 2018 (UTC)
It works fine in those cases. Only case we need to handle differently are those with {{cite web}}, that one shouldn't have the bot link. The bot behaves correctly by leaving cite web alone, but since it's leaving cite web alone, the link adds nothing in that the case. Everywhere else the bot is fine on those errors (and many more). Headbomb {t · c · p · b} 14:37, 18 September 2018 (UTC)
The bot doesn't limit itself to the cites it can fix error-free. Also, not a fan of inline bot/tool advertisement, it opens a can of worms. Anyone else want their bots/tools to have inline adds? If the tool was well established and working without many errors and could fix most cases maybe it would be different. -- GreenC 20:17, 18 September 2018 (UTC)
1) We already do it for {{cite arxiv}} 2) we do it in plenty of other situations, e.g. [disambiguation needed]. And the bot works well without many errors as is. Headbomb {t · c · p · b} 20:39, 18 September 2018 (UTC)
Is there a testcase page that demonstrates the bot is working correctly and is able to make fixes for this? What percentage of cases is it able to fix est.? -- GreenC 21:26, 18 September 2018 (UTC)

I set one up... but the bot failed to do anything. Either there's a regression, or I was confusing this with an AWB functionality. I filed a bug report at here, and those usually get done in a few days. We can have a mockup in the sandbox for now, and pull it down if the bug hasn't been fixed live update time. Headbomb {t · c · p · b} 23:23, 18 September 2018 (UTC)

Yeah I'd like to see you approve enabling the warning messages, show evidence that the bot works, and then see if the community supports adding it to the sandbox. I'm still not convinced it's a good idea, but maybe you can convince me. -- GreenC 01:29, 19 September 2018 (UTC)
Support enabling all three error messages. And I agree with GreenC regarding the orthogonal issue of a link to Citation bot. --Xover (talk) 17:54, 19 September 2018 (UTC)
unhidden in /sandbox.
Trappist the monk (talk) 10:55, 23 September 2018 (UTC)

Field for UK National Archives[edit]

What would be the appropriate property for a doc reference in the UK National Archives. This is an example of the the ref:[3] scope_creep (talk) 21:57, 9 September 2018 (UTC)

@Scope creep: I'm not sure anyone understands your question. Perhaps {{cite document}} will help you? --Izno (talk) 14:33, 16 September 2018 (UTC)

Rewrite npr.org links[edit]

Links such as https://www.npr.org/sections/thetwo-way/2014/04/21/305688602/alaska-oks-bill-making-native-languages-official currently redirect to an interstitial https://choice.npr.org/index.html?origin=https://www.npr.org/sections/thetwo-way/2014/04/21/305688602/alaska-oks-bill-making-native-languages-official at least for EU users. Why not rewrite all of them to the lightweight version https://text.npr.org/s.php?sId=305688602, which seems preferable from all perspectives for all our users anywhere? Getting the 9 (?) digit ID from the full URL seems easy. --Nemo 10:53, 10 September 2018 (UTC)

Because that is not the function of these templates. You can modify the links in wikisource by writing an awb or similar-tool script or by building a bot to do that.
Trappist the monk (talk) 11:13, 10 September 2018 (UTC)
The NYT had something like this for years, then it didn't work and we were left having to convert to the long form. Of course the opposite can also occur from long to short. Probably best not fix until broken. -- GreenC 12:52, 10 September 2018 (UTC)
Yes, which is a good reason to avoid making such changes in the wikitext when they can be handled centrally by the template. --Nemo 15:07, 15 September 2018 (UTC)
It's not in this template's domain to change the provided URL. Basically, it's out of scope. --Izno (talk) 15:33, 15 September 2018 (UTC)
Agreed regarding "don't fix what isn't broken". Interstitial suck, but they aren't the end of the world. --Izno (talk) 15:47, 10 September 2018 (UTC)
The links *are* broken. The interstitial goes to the main page https://text.npr.org/ . --Nemo 15:07, 15 September 2018 (UTC)
The links above are not broken for me, whether via the direct interstitial link you provided or the link directly to the news source. You may have some tool or extension which is preventing you from using the link meaningfully. --Izno (talk) 15:33, 15 September 2018 (UTC)
Can you clarify what you're doing? Do you click "Decline and visit plain text site" and end up on the right page? From the HTML it's hard to see how you could get such a result: <a class="user-action user-action--text" id="textLink" href="https://text.npr.org">Decline and Visit Plain Text Site</a> (and I don't see any JavaScript redirection either). --Nemo 12:05, 16 September 2018 (UTC)
Well, I missed that you are seemingly in the EU. Friday I was actually able to visit the interstitial but today I'm automatically redirected (I'm not sure I have ABP at work currently--might be the reason). For the interstitial, I did not see any option to access the plain text link, only to proceed to the article (or the other alternative to leave the page I think). Either way, I've found that one way to work around this kind of issue is to access the same page on archive.org, for which we have good reason to provide a link anyway. I usually use this kind of thing to get around registration/pay walls. --Izno (talk) 14:29, 16 September 2018 (UTC)

Wikidata identifier[edit]

Would it not be useful to have a parameter "Wikidata" as an identifier? We now have OCLC, ISBN, doi, jstor, etc. etc. but not an easy way to link to the Wikidata-item (if any exists). It would be of great help, for instance, to directly check if a text, or info about a text, is available anywhere on Wikipedia/Wikisource etc. --Dick Bos (talk) 05:07, 12 September 2018 (UTC)

@Dick Bos: You may want to search the archives, as your suggestion has been talked about before. --Izno (talk) 14:31, 16 September 2018 (UTC)
@Izno: Thank you very much for this suggestion. I found this and this discussions. If I understand things well, I can use the parameter "id={{Wikidata|Q38197781}}", if I want to link to Wikidata. Am I right? --Dick Bos (talk) 07:44, 17 September 2018 (UTC)

Handle vs DOI (non-10. prefix warning)[edit]

Example on Jerome Guillen#Further reading:

  • "Studies of the dynamics of dry-friction-damped blade assemblies". doi:2027.42/131660 Check |doi= value (help).

This works as expected, but gives the Check |doi= value warning because the Handle does not start with the DOI-specific 10.NNNN prefix. Is there a preferred solution for this, and where would be the best place to document the solution? —Sladen (talk) 10:25, 17 September 2018 (UTC)

Use the correct identifier; in this case |hdl=:
{{cite paper|title=Studies of the dynamics of dry-friction-damped blade assemblies|hdl=2027.42/131660}}
"Studies of the dynamics of dry-friction-damped blade assemblies". hdl:2027.42/131660.
Trappist the monk (talk) 10:45, 17 September 2018 (UTC)

Pages using a web archive URL in the url field[edit]

Example. My bot does fix. They are somewhat common, editors are often misinformed about how to add archives. Is there a tracking category to find when the |url= contains a web archive URL? -- GreenC 18:33, 17 September 2018 (UTC)

This may not actually be a mistake - if the archive page is where the editor has originally seen the content.Nigel Ish (talk) 18:49, 17 September 2018 (UTC)
Archive.org in |url= is occasionally correct; for example magazines archived there. --Izno (talk) 20:03, 17 September 2018 (UTC)

|display-translators=[edit]

At On Horsemanship I tried to change "Various translators" to "Ashley Cooper et al" only to find "et al" was removed. I can't add all translators because they're not all credited in the source (there are four credited plus "and others"). The error from adding explicit "et al" says to use |display-authors= instead, but that has no effect. There is a |display-editors= parameter for editors, but no |display-translators=. Is there any particular reason for this? Hairy Dude (talk) 13:37, 18 September 2018 (UTC)

Relative lack of need. As far as I know this one cs1 template is the only one that has required |display-translators= support. I'll at adding that support.
Trappist the monk (talk) 15:12, 18 September 2018 (UTC)

Provide a link to the named identifiers[edit]

Under the Parameters > COinS heading the help template states that:

COinS metadata is created for these parameters

...

any of the named identifiers (|isbn=, |issn=, |doi=, |pmc=, etc)

It was not clear to me where to look for a full list of these identifiers (in my case I had a SKU ID and wanted to check if there was a parameter for this).

I think a link to Help:CS1_errors would suffice? The help template is protected though, so I can't add the link. Does this seem like a good addition?

VeraqueVeritas (talk) 19:35, 20 September 2018 (UTC)

That same template page: §Identifiers.
Trappist the monk (talk) 22:07, 20 September 2018 (UTC)

update to the live cS1|2 module weekend of 29–30 September 2018[edit]

I intend to update the live modules over the weekend of 29–30 September 2018

changes to Module:Citation/CS1:

changes to Module:Citation/CS1/Configuration:

  • withdraw support for |in= as a |language= alias
  • updated locks; discussion
  • implemented Module:Citation/CS1/styles.css
  • detect and categorize 'Archive copy' titles
  • remove hack for phab:T29786
  • |class= not supported with oldest arxiv identifier format; discussion
  • update OSTI URL; discussion
  • last 3 hidden error messages unhidden; discussion

changes to Module:Citation/CS1/Whitelist:

  • withdraw support for |in=
  • deprecate |class as basic parameter; discussion
  • deprecate |ASIN-TLD= (uppercase version); discussion

changes to Module:Citation/CS1/Identifiers:

  • |class= not supported with oldest arxiv identifier format

changes to Module:Citation/CS1/COinS:

Trappist the monk (talk) 11:50, 23 September 2018 (UTC)

Cite and q element styling[edit]

I'm not sure we need to duplicate the CSS for the q and cite elements locally, since I don't expect those declarations to be removed from Common.css. Either way, I think this is some CSS that we can add later if we ever remove it from Common.css.
cite.citation {
	/* Reset italic styling set by user agent (only for cs1|2 templates; the
	reason for the .citation qualifier) */
	font-style: inherit;
}

q { /* Straight quote marks for <q> */
	quotes: '"' '"' "'" "'";
}
--Izno (talk) 15:53, 23 September 2018 (UTC)
That code is there for all of the other wikis that use the cs1|2 modules (as the comment in Module:Citation/CS1/styles.css points out); en.wiki's common.css is not shared by all wikis.
Trappist the monk (talk) 16:51, 23 September 2018 (UTC)
Yes, that's true. However, that still introduces duplication with Common.css--readers at other wikis will now need to know to style their q and cite elements in both places otherwise they risk having disparate styles. --Izno (talk) 15:49, 29 September 2018 (UTC)

Citation-comment[edit]

@Izno re: this edit and this edit, are you sure? Class citation-comment is undefined so that editors may show or hide cs1|2 error messages using their own personal css (vaguely documented at Help:CS1_errors#Controlling_error_message_display; and certainly not to turn error messages green.
{{cite book/new |title=}}Empty citation (help)
Trappist the monk (talk) 15:36, 29 September 2018 (UTC)
Yeah, I saw that the class was being used slightly differently than I had interpreted it, just before you left a message. I created a new .cs1-maint to take the color and the display declaration and style. That should probably be refactored to use /Configuration since it is more like the error messages which are already captured there. That's a bit above my skill level though right now. --Izno (talk) 15:45, 29 September 2018 (UTC)
Multiple authors. Missing or empty |title= (help)CS1 maint: Uses authors parameter (link). <- fixed, and the example above.
There also seems to be a really minor bug here where a space at the end gets injected into the maintenance span. We probably didn't know it was there because of Tidy; Remex doesn't strip internal space from HTML, which is why it is showing up.. --Izno (talk) 16:01, 29 September 2018 (UTC)
You are write that presentation for maintenance messages should be in /Configuration so I have done that. The space that you were seeing was a simple hack so that multiple maintenance messages were properly separated when rendered. That is now fixed in the sandbox:
Multiple authors (2018). Title.CS1 maint: Uses authors parameter (link) CS1 maint: Date and year (link).
Trappist the monk (talk) 16:28, 29 September 2018 (UTC)

How do I format this date?[edit]

I have a reference whose correct publication date (according to JSTOR, changed only by conversion from hyphens to en-dashes) is "Fall–Winter 1988–1989". This results in a "Check date values" error message. How to format this date so that it is both accurate and non-complaining? (Noting in particular that "Fall 1988 – Winter 1989" would mean something different or at the least much more ambiguous, so is not sufficiently accurate.) —David Eppstein (talk) 21:13, 28 September 2018 (UTC)

Help:Citation Style 1 indicates the template does not support season ranges. So live with the false error message, or don't use citation templates. Jc3s5h (talk) 14:42, 29 September 2018 (UTC)
Where does H:CS1 say that?
{{cite journal |title=Title |journal=Journal |date=Fall–Winter 1988}}"Title". Journal. Fall–Winter 1988.
Trappist the monk (talk) 11:55, 30 September 2018 (UTC)
Or provide the actual date of publication. Or use another parameter. Or put that information outside of the template explicitly. Or put it in a comment in the date field. Lots of ways to work around it. This particular scenario has showed up before. --Izno (talk) 15:28, 29 September 2018 (UTC)
You can also use the |issue= parameter to give the "cover" issue date description above and use |date=1988 to specify when it was actually published. – Jonesey95 (talk) 16:10, 29 September 2018 (UTC)
So the consensus is: the template is incapable of formatting the date correctly? That's...helpful to know, I suppose. Is there a good reason why we don't have a workaround for "I know this really is a valid date even though it doesn't parse"? —David Eppstein (talk) 19:35, 29 September 2018 (UTC)
Elsewhere you rose in opposition when I suggested a form of markup that would instruct the module to accept this-input-as-written. So, no there is no such 'workaround'. You might write that date as |date=Fall–Winter 1988.
Trappist the monk (talk) 11:55, 30 September 2018 (UTC)
On an aside, this has been discussed here and a discussion linked therein as well. --Izno (talk) 21:39, 30 September 2018 (UTC)

Repeat linking of works/publications[edit]

Hello all, this is something I've wondered for awhile and have not been able to find a consensus/answers to, but I was curious as to whether or not a publication should be recurrently linked within the reference section of an article. In other words, for example, if ref. 1 of an article is Entertainment Weekly, is it necessary to re-link the publication in subsequent references from the same work? I've personally avoided this as I find it to be obtrusive when looking at the reference section as a whole (far too many Wiki links to the same publication), but this could be a biased perspective given that I am a frequent editor—it may prove useful for casual readers to have immediate linked access to the publication when hovering over individual footnotes as they read. I am unsure about how to handle this. Thank you. --Drown Soda (talk) 20:29, 29 September 2018 (UTC)

Standard (i.e., not just Wikipedia) citation practice is that every source used ("cited", "referenced", etc.; the terminology here is quite confused) in an article should have exactly one "full citation", with all of the bibilogrpahic details as my be useful in finding and identifying the source. On Wikipedia these full citations are most often created using a {{cite xxx}} or {{citation}} template. The most common practice on WP is to drop them into a note (footnote) created using <ref>...</ref> tags in the text. But you may note that many articles will collect all these full citations into their own section.
Your "repeat linking" question is commonly seen in the form of "how to 're-use' citations". There are two ways to do this. Most commonly seen at WP is the use of "named-refs", where a note – typically containing a full citation – is made to appear in more than one place. This implies having each full citation in its own note, and is what leads to those irksome strings of note links (e.g.: [1][7][27][15]...).
In the rest of world there are many ways of citing a source more than once. The most common way is to use the last name of the author (or authors) and year of publication, to link to the full citation. The easiest way to do this on WP is with the {{harv}} family of templates. And that is all I have time for now. ♦ J. Johnson (JJ) (talk) 00:23, 30 September 2018 (UTC)
@J. Johnson: your comments don't answer the OP's question as I read it at all. @Drown Soda: if multiple citations all come from the same publication, Entertainment Weekly is the name of the magazine/website being cited in footnote 1 and then cited in footnotes 3, 9 and 12, then I'd personally only wikilink to the article on the magazine in the first note and leave it unlinked in the others. Imzadi 1979  01:14, 30 September 2018 (UTC)
Well, I read the question slightly differently, there being some ambiguity in the meaning of "works/publications". Yet another example of why I am often askng for more precision in what people mean. ♦ J. Johnson (JJ) (talk) 00:10, 2 October 2018 (UTC)
@J. Johnson: I meant just that, as publisher/work are different fields in citation templates. The repeated wiki-linking of these was mainly what I was referring to. --Drown Soda (talk) 04:28, 2 October 2018 (UTC)
The term "references" is best avoided as having too many possible meanings, which are rarely (ever?) specified. E.g., where you said "subsequent references from the same work", "same work" implies a single source, and "subsequent references" thus suggests repetition of a single full citation. Which, as I explained at the outset, is wrong. Okay, so what you really meant (I gather) is wikilinking of data, such as the name of a publication, name of the publisher, place of publisher or publication, name of a work ("Encyclopedia Brittanica"), author's name, etc., that shows up more than once in a set of full citations to different sources. Well, that is good question; see below. ♦ J. Johnson (JJ) (talk) 21:49, 2 October 2018 (UTC)
@Imzadi1979: Thanks--this was what I felt made most sense. It seems my question was misunderstood by several other commenters here. I've been on Wikipedia for years and know how to use citation templates, name them in the reference brackets, etc. My question had to do with wikilinking publications in citations more than one time (i.e. suppose an article references three different articles from The New York Times—do I wikilink The New York Times in each citation, or only the one that first appears?). Linking the publication in every single citation overwhelms the reference section in my opinion and results in excessive links, but as I said, I am not sure there has been a consensus on this among editors. --Drown Soda (talk) 01:40, 30 September 2018 (UTC)
There was some discussion of this earlier this year at a venue marginally more appropriate than this one. --Izno (talk) 06:34, 30 September 2018 (UTC)
The rough consensus I'm seeing out of these discussions is actually (surprisingly to me) to link everything, always and then modify that with common sense: publication location should normally not be linked by the same rationale that place names should generally not be linked in prose; dates and years should not be linked as with in prose; author names, publishers, and works should not be redlinked unless the relevant datum is fairly clearly notable; and so forth. I've been practicing that for a long time but with the expectation that someone would eventually jump down my throat for it; but the discussion linked above, and a previous discussion here, suggests that the rough consensus among the parts of the community participating in those discussions is mainly in favour of linking. There will be disagreements on details, certainly, and local consensus still decides for any given article; but I think the general guidance now is to link all the most important parameters (title, author, publisher, publication) that have Wikipedia articles, and to not redlink any of them unless the target is clearly notable. --Xover (talk) 07:38, 30 September 2018 (UTC)
@Xover: I was wondering about consensus on it as well; my only hang-up is that it leaves the reference section full of multiple wikilinks to the same page, which is not acceptable in the body of the article. --Drown Soda (talk) 04:28, 2 October 2018 (UTC)
@Drown Soda: The consensus I'm seeing in these discussions is that the references are not article prose and thus the usual concerns for OVERLINK do not apply. And I agree with that: "sea of blue" doesn't really matter in the references because it's a list of metadata, not prose that needs to be readable primarily. --Xover (talk) 08:17, 2 October 2018 (UTC)
I generally agree with Xover. First choice would be to restructure the citation scheme so a work only appears once in the reference list. But if that seems too complex to the editors who maintain the article, the second choice would be to link it every time, because when the reader arrives at the reference list, the reader is only focused on the source that supports the claim of interest; the reader probably isn't going to read the entire reference list and so will not be aware the publisher is linked somewhere else. Jc3s5h (talk) 14:08, 2 October 2018 (UTC)
Jc3s5h: it appears you are under the same misunderstanding I was. He wasn't asking about repeat citations of a given work, but duplicate wikilinking (to articles) of data (names of publications, etc.) that is used multiple times. I don't believe there is any "citation scheme" where one could (for instance) "reference" (cite?) the New York Times only once. But check out 2014_Oso_mudslide#References, where the articles from several newspapers are listed under the newspaper, and the name of the paper can be wikilinked independently of any of the included citations.
I generally agree with Xover, except that I am usually too lazy to wikilink everything. ♦ J. Johnson (JJ) (talk) 21:59, 2 October 2018 (UTC)
@J. Johnson: I wasn't quite sure what the OP was referring to. The various methods of completely combining citations, or using a mixture of short and full citations, can reduce, but not eliminate, the repetition of certain facts, such as Oxford University Press being a publisher, or that University Science Books is located in Mill Valley, California. Using these techniques for brevity can reduce the number of wikilinks, but not always reduce them to one wikilink per Wikipedia article. I personally do not routinely link publishers or publisher locations, but I might if the Wikipedia article adds information about a publisher or place that isn't common knowledge. (For example, from its name, many readers might not guess that Cooper Union is a college.)

Work parameter and format of other parameters[edit]

The documentation says

When set,work changes the formatting of other parameters: [...] location and publisher are enclosed in parentheses.

Recently, making this edit, I observed that this does not seem to be the case. My citation was:

{{cite paper|url=https://fas.org/sgp/crs/natsec/R44137.pdf|title=Naval Station Guantanamo Bay: History and Legal Issues Regarding Its Lease Agreements|date=November 17, 2016|work=[[Congressional Research Service]]|publisher=[[Federation of American Scientists]]}}

Producing:

"Naval Station Guantanamo Bay: History and Legal Issues Regarding Its Lease Agreements" (PDF). Congressional Research Service. Federation of American Scientists. November 17, 2016.

Wtmitchell (talk) (earlier Boracay Bill) 08:57, 1 October 2018 (UTC)

This rfc removed parentheses from the publisher rendering. I've tweaked the documentation.
Trappist the monk (talk) 09:46, 1 October 2018 (UTC)

Separators in |language= parameter[edit]

When |language= contains two values, in the output they are separated with " and ".

  • {{cite book|title=Title |language=fr,de}}
  • Title (in French and German).

When it contains three or more values the final two are separated with ", and ".

  • {{cite book|title=Title |language=fr,de,it}}
  • Title (in French, German, and Italian).

There is not an option to modify or translate the separators in Module:Citation/CS1/Configuration. However, it contains two local messages ['parameter-final-separator'] = and ['parameter-pair-separator'] = which would be useful in this case. Is it possible to enable these local messages in |language=? I regularly update CS1 modules in el.wikipedia.
Αντιγόνη (talk) 19:06, 7 October 2018 (UTC)

Thanks for pointing out that omission. Fixed in the sandbox using cfg.messages['parameter-pair-separator']:
{{cite book/new |title=Title |language=fr,de}}
Title (in French and German).
{{cite book/new |title=Title |language=fr,de,it}}
Title (in French, German, and Italian).
Trappist the monk (talk) 19:38, 7 October 2018 (UTC)
Thank you for your fast response, I would like to insist in using ['parameter-final-separator'] or equivalent syntax though. I omitted to mention earlier that in greek (el), perhaps in other languages too, comma is not placed before "and", not only in pairs but also in longer lists. Therefore, the correct output in greek would be:
  • {{cite book|title=Title |language=fr,de,it}}
  • Title (in French, German and Italian).
I think that ['parameter-final-separator'] or equivalent message would allow greater flexibility to satisfy both cases, with or without comma before "and", by modifing it accordingly.
Αντιγόνη (talk) 21:28, 7 October 2018 (UTC)
ok. done.
Trappist the monk (talk) 22:29, 7 October 2018 (UTC)

ndash entity in pages parameter[edit]

Trying

{{cite journal|journal=Journal|title=Title|pages=10&ndash;24|first=A.N.|last=Author|year=2018}}

(note: I actually tried it with the ndash entity but I had to expand out the ampersand into an amp entity to get it to be visible as an entity inside the nowiki) I expected to see the same result as if the ndash entity were replaced by an actual en-dash character, namely

Author, A.N. (2018). "Title". Journal: 10–24.

but instead it was spelled out:

Author, A.N. (2018). "Title". Journal: 10&ndash, 24. (live template)
Author, A.N. (2018). "Title". Journal: 10&ndash, 24. (substituted in case the live template gets fixed)

Would it be possible to fix this, please? I don't use the ndash entity much myself as I have a Mac keyboard on which the dashes are easy to type, but it's a convenient alternative spelling for editors who use other systems, and it works most of the time but not here where we need en-dashes so frequently. (And in fact I found this in someone else's markup while editing an article, rather than by randomly experimenting myself.) I think the problem is that the semicolon that terminates the entity is getting misinterpreted as normal punctuation and replaced by a comma, which makes the rest of the entity stop looking like an entity to browsers that see the resulting markup. —David Eppstein (talk) 05:47, 9 October 2018 (UTC)

fixed in the sandbox:
{{cite journal/new|journal=Journal|title=Title|issue=10&ndash;24|first=A.N.|last=Author|year=2018}}
Author, A.N. (2018). "Title". Journal (10–24).
The code that converts hyphens to endashes splits the |page= and |issue= parameter values at commas and semicolons (because editors do use semicolons where commas should be used). &mdash; and &ndash; entities are now converted to their respective characters before the split.
Trappist the monk (talk) 10:00, 9 October 2018 (UTC)
Thanks for the quick work! —David Eppstein (talk) 16:31, 9 October 2018 (UTC)
It appears to be broken at the moment. XOR'easter (talk) 18:33, 27 October 2018 (UTC)

Definitely it was broken when I looked at a couple of articles today. This needs to get fixed, since there are probably over a million occurrences of – in Wikipedia articles. Michael Hardy (talk) 00:09, 12 November 2018 (UTC)

@Trappist the monk: Are you aware that this is not fixed? Michael Hardy (talk) 19:44, 12 November 2018 (UTC)
Aye, of course; I fixed the issue in the sandbox as noted above.
Except for when the cs1|2 modules emit strong red error messages or evince some other sort of fatal error, it has been the practice here to accumulate multiple tweaks, modifications, fixes, enhancements, etc. and then update the cs1|2 module suite all in one go (the last update).
Trappist the monk (talk) 22:46, 12 November 2018 (UTC)

"Dashes in the ISBN are optional"[edit]

They are hyphens, not dashes. Pleas correct. — Mikhail Ryazanov (talk) 09:41, 9 October 2018 (UTC)

Can you show a live example of what you mean?
Trappist the monk (talk) 10:03, 9 October 2018 (UTC)
The complaint was about the documentation (now fixed). Kanguole 11:07, 9 October 2018 (UTC)

Regressions: advice request[edit]

In Russian Wikipedia, {{cite journal}} is used mainly in translated articles. Its current ruwiki version is a slightly edited many-years-old version of the enwiki template. I was going to replace it with the current enwiki version based on the CS1 family of modules, but it turned out that along with many improvements it would cause some regressions. Here is a random sample of cite_journal transclusions in ruwiki; left — current ruwiki version, right — current enwiki version. As can be seen, there are 4 main issues:

  • error regarding unrecognized language and tracking categories for sources in particular languages with mixed English-Russian names;
  • "month" is ignored and emits an error;
  • "access-date" requires "url" and emits an error;
  • "coauthors" is ignored and emits an error.

The last point is particularly painful because the main problem with the current ruwiki version of this template is that it ignores parameters like first1, last1, etc. So we end up with not showing author lists when using either of the two versions (but in different cases).

Of course, it is the responsibility of the ruwiki community to deal with this issue. All I wanted to ask is an advice about the best way to deal with these regressions. Some bot run? Some config edits? Something else?

--colt_browning (talk) 12:30, 9 October 2018 (UTC)

None of your primary issues are 'regressions', as in, unintended changes. All of them were deliberate. (I see some other deltas, such as quotation marks, that look like they are because you have not set up your configuration/styles modules all the way.)
  1. Templates with |month= and |year= (if not also |day=) can be botted to |date= (as in, |date=(day) month year). Others should probably be case-by-case fixes.
  2. Many times this is due to a non-web resource, or a web-resource with a permanent ID of some sort (e.g. |doi=), having been accessed on that date, which is not the purpose of that parameter. Those cases can be botted. The others should be case-by-case cleaning.
  3. |coauthors= is preferably split to |authorn= or first/lastn. If that's a pain point (say your coauthors are separated inconsistently), |authors= is also available.
You ECd with me so my bullets refer only to the later 3. --Izno (talk) 14:05, 9 October 2018 (UTC)
Thanks. I didn't mean to criticize; I didn't mean that these changes were regressions when they were introduced here; I meant that they would become regressions in ruwiki if we just replace the old version with the new one. --colt_browning (talk) 14:20, 9 October 2018 (UTC)
No worries--it was clear from context you didn't meant to criticize :). --Izno (talk) 14:46, 9 October 2018 (UTC)
I don't see an error regarding languages. Do you have an example of that? --Izno (talk) 14:10, 9 October 2018 (UTC)
Category: CS1 maint: Unrecognized language. It is caused by samples No. 4, 18, 70, where the name of the language is given instead of its code. --colt_browning (talk) 14:20, 9 October 2018 (UTC)
You might be able to look through the history of this talk page and the history of edits to the module pages in order to pick out an intermediate version of the template that is more forgiving. |coauthors=, for example, was deprecated but still supported for a while, and then after a long while, support was removed entirely. I think that |month= went through the same transition, but it's been a while. You'll have to look back in the edit history, where changes to the module pages and sandbox pages are listed in comments. – Jonesey95 (talk) 14:23, 9 October 2018 (UTC)
(edit conflict)
Yikes! that is old.
I guess that step one is for the ru.wiki community to decide that they want to upgrade to the cs1|2 module suite and that they want to do it for all of the cs1|2 templates. Seems silly to me to retain the old old old wikitext versions of some templates but use new for others.
The unrecognized language issue occurs because at ru.wiki, the code expects the value assigned to |language= to be Russian orthography or ISO 639-1 code (Latn script); instead of |language=French, write: |language=французский or |language=fr. One of the things that I have thought to do is to tweak the language parameter code so that it first tests the language value against the local language list. If that fails ('French' not found in the ru.wiki language list), try again with the English language list. If you go ahead with this project, it will be a useful test-bed for this idea.
We elected to deprecate and remove |month= and |day= because too many date parameters are too many date parameters; because Lua is much more capable than parser functions and wikitext; because we had no need for such data granularity (and if we develop such a need, the component parts of a date can easily be extracted from a whole date). Editors here wrote AWB scripts that trolled through one or more of the error categories and rewrote |day=, |month=, |year= into |date=. Were it me, I would do the same at ru.wiki.
Our documentation here has always associated |access-date= with |url= as a date that the citing editor confirmed that the source linked by |url= supported the text our article. Identifier sources, doi, pmc, etc are 'permanent' so will not be changing unlike many web-based sources.
We elected to deprecate and remove |coauthor= and |coauthors= because cs1|2 produces COinS metadata; because too many author parameters are too many author parameters; editors here ignored the plural / singular distinction. COinS does not have support for multiple names in a single key/value pair – COinS expects the name of one author for each instance of &rft.au so none of the authors listed in either of |coauthor= and |coauthors= was included in the metadata. For this same reason, the value assigned to the plural |authors= is also not included in the metadata. Converting |coauthor= and |coauthors= to |authorn= (not to |authors=) required several AWB scripts (to find and fix the low-hanging fruit) and a lot of manual fixes. This is the most difficult of the tasks ahead of you because human names are endlessly variable as are the ways that editors choose to represent those names in cs1|2 templates.
If after reading all of that you still wish to proceed, I would strongly recommend that you do a careful and complete translation of Help:CS1 errors. I don't know if it is possible but if it is, import the entire Category:CS1 category because all of those sub-categories are intimately tied to the cs1|2 templates and to Help:CS1 errors. Import rather than copy because there are a lot of category pages so if it can be done all in one go, do that. In ru:Module:Citation/CS1/Configuration at a minimum, translate the error messages and the ['help page label'] value so that general editors in the ru.wiki community who don't have English can understand what all of that red text means.
When you 'flip-the-switch', regardless of how much advance warning you have given, there will be angry editors. There is no getting away from that.
If you need help with technical issues or you see places where the cs1|2 internationalization support can be improved, give a shout. Good luck.
Trappist the monk (talk) 14:24, 9 October 2018 (UTC)
Thank you very much! --colt_browning (talk) 14:43, 9 October 2018 (UTC)

New stripmarker error in Template:Ford1922[edit]

There is a new stripmarker error in Template:Ford1922, a template that has not been edited for almost a year. Should this be fixed in the template or in the CS1 modules? Thanks. – Jonesey95 (talk) 04:41, 10 October 2018 (UTC)

Misuse of |postscript= is the problem in each of these. I would guess these are also causing lint errors on their respective pages. --Izno (talk) 05:15, 10 October 2018 (UTC)
That fix works for me. Thanks. – Jonesey95 (talk) 08:18, 10 October 2018 (UTC)

Url-access parameter for Cite encyclopedia – Reason missing from full parameter list?[edit]

Anyone know? May I add it? I would not have even known it was an option except saw the icon used and was digging around in the code. Are there other parameters that are excluded? Reason for those? Thanks, Peacedance (talk) 21:33, 10 October 2018 (UTC)

Probably because I / we suck at documentation. Any help that can be had making the cs1|2 documentation better is gratefully accepted.
Trappist the monk (talk) 22:15, 10 October 2018 (UTC)

Urgent: Dash errors[edit]

  • <pre>{{cite journal |last=Smith |first=J. |year=1948–1950 |title=Foobar |journal=Whatever |pages=1654–1055}}</pre>

Renders as

  • Smith, J. (1948–1950). "Foobar". Whatever: 1654&ndash, 1055. Check date values in: |year= (help)

Rather than

  • Smith, J. (1948–1950). "Foobar". Whatever: 1654–1055.

@Trappist the monk:.Headbomb {t · c · p · b} 21:24, 11 October 2018 (UTC)

Help talk:Citation Style 1#ndash entity in pages parameter
Trappist the monk (talk) 21:38, 11 October 2018 (UTC)
Well, this should be deployed now, not in weeks. Thousands if not hundreds of thousands of citations are now borked. Headbomb {t · c · p · b} 21:48, 11 October 2018 (UTC)
10000 Galobtter (pingó mió) 07:33, 12 October 2018 (UTC)
That's articles. Multiple citations per articles increase the count. Headbomb {t · c · p · b} 23:03, 13 October 2018 (UTC)

Hacking around templatestyles and T205803[edit]

FYI, I changed Template:Philippine census reference to (1) call "Template:Philippine census reference/strip" to strip the templatestyles from the citation template output, and (2) add the templatestyles back outside of the reference tag. this is a total hack workaround for T205803 which was triggered when templatestyles were added to Module:Citation/CS1. clearly this is a fragile hack fix since it relies on the format and position of the ocins (specified in Module:Citation/CS1/Configuration) and the fact that the templatestyles is at the end. so, please let me know if you have a better solution or if T205803 is fixed so I can undo my changes. Frietjes (talk) 16:18, 13 October 2018 (UTC)

Update, since this is a broader problem, I have implemented something in Module:Citation/CS1/templatestyles, which appears to work as well, but seems to be less fragile. Frietjes (talk) 14:15, 14 October 2018 (UTC)
So a patch was uploaded but not merged which I expect will come on the WP:THURSDAY software deployment. --Izno (talk) 16:47, 14 October 2018 (UTC)
excellent, once that is merged, I will orphan the module and have it deleted. until that happens, Category:Pages with duplicate reference_names is becoming more useful (down from over 5K entries yesterday). Frietjes (talk) 17:34, 14 October 2018 (UTC)
A similar issue with {{Certification Table Entry}} has resolved itself, so the patch may already be live. --Muhandes (talk) 15:24, 17 October 2018 (UTC)
looks like the patch has been merged, so I have removed the hack from the ca. 9 templates that were using it. it could be useful to keep the hack module around in case, or we could probably just delete it. Frietjes (talk) 23:46, 18 October 2018 (UTC)
Since you're the one who made significant contributions, you can submit it for author-only CSD. I'd support that. --Izno (talk) 00:50, 19 October 2018 (UTC)

Broken templates[edit]

{{Inflation/fn}} was apparently broken by a change to Module:Citation/CS1 on 29 September. Can we revert it until we have a fix? Hawkeye7 (discuss) 22:54, 13 October 2018 (UTC)

At least a few other templates were affected, too. -- Mikeblas (talk) 01:55, 14 October 2018 (UTC)

{{Inflation/fn}} was not broken by the 29 September update to the cs1|2 module suite. Rather, the problem lies with the MediaWiki software. I said as much at Template_talk:Inflation/fn#duplicate_reference_definitions, a discussion to which you both have contributed. This is not the place to fix a problem in the MediaWiki code. Reverting the last module suite update will not repair the underlying problem, only mask it. —Trappist the monk (talk) 10:39, 14 October 2018 (UTC)

You're saying that there was a change to the MediaWiki software on that date which should be reverted? Hawkeye7 (discuss) 19:44, 14 October 2018 (UTC)
No. MediaWiki was flawed before the 29 September 2018 module update but no one knew it. The module update revealed the flaw. I am saying that the proper solution is to fix MediaWiki, which apparently has been done and is just waiting for review and implementation; see §Hacking around templatestyles and T205803.
Trappist the monk (talk) 20:06, 14 October 2018 (UTC)
I have a bug fix request in Phabricator that is over six months old now. Changes to MediaWiki code are potentially highly disruptive. We should neither expect nor rely on MediaWiki changes, especially if we can handle it here. Hawkeye7 (discuss) 20:36, 14 October 2018 (UTC)
Aye, sometimes phabricator is just like that black hole at the back of the laundry where single socks go; I have one there from June 2016. But so what? That doesn't change the fact that the correct place to fix this problem is at MediaWiki.
Trappist the monk (talk) 22:56, 14 October 2018 (UTC)
It seems like the course of action followed was to make a change that identified an issue in MediaWiki, then leave the broken code in place, blaming MediaWiki. That leaves the site broken. Do I have it right? If no, what am I missing? If so, how is that really what's best for the site and its users? -- Mikeblas (talk) 09:51, 15 October 2018 (UTC)
MediaWiki enabled TemplateStyles at en.wiki 19 July 2018. On that same day I created what would become Module:Citation/CS1/styles.css and started this discussion. Between then and the 29 September update we modified the cs1|2 modules and styles.css to move inline style from the modules into styles.css (where it belongs). More than two months after TemplateStyles was enabled, we implemented it. On that day you noticed that {{Inflation/fn}} produced duplicate reference definition errors. I learned of the problem on 30 September and on that day diagnosed the problem which caused you to open phab:T205803. Also that day and on 1 October, developers at MediaWiki confirmed the problem. One of them created a fix that was uploaded for review on 14 October which some here believe will deployed 18 October.
The broken code is not in TemplateStyles and is not in cs1|2 but is in MediaWiki's mw:Extension:Cite/Cite.php (the prospective fix).
You can use the word blame if you'd like. I prefer to think that we diagnosed a problem and notified the cognizant people who have done whatever it is that they do to confirm the diagnosis and create a remedy. Yes this problem manifests itself in a way that causes grief for certain templates. Editor Frietjes has applied a clever hack to {{Inflation/fn}} and to a handful of other templates. Still, the cs1|2 modules are used on about 3.8 million pages. For the vast majority of those pages, this problem is not a problem.
Trappist the monk (talk) 11:26, 15 October 2018 (UTC)

Edit request for Template:Cite book[edit]

Under Edition, series, volume in Template:Cite book, the edition parameter allows only for abbreviation to "ed." when in fact the word is often abbreviated to "edn" in British English, and in World English, eg according to oxforddictionaries.com. Could the template please be amended to allow for edn (no period). Thank you. JG66 (talk) 04:46, 14 October 2018 (UTC)

|edition= takes, as input, a text string to which is appended a space character and the static abbreviation 'ed.' (with a dot). There is no facility in cs1|2 to support any specific variety of English. To accommodate this request would require some sort of new parameter or some special encoding of the value assigned to |edition= to tell cs1|2 to use 'edn' instead of 'ed.' when rendering.
Trappist the monk (talk) 11:08, 14 October 2018 (UTC)
@Trappist the monk: Many thanks for your reply. How would I go about trying to achieve that, do you know? Should I request the special encoding directly from a template editor, for instance? JG66 (talk) 11:28, 14 October 2018 (UTC)
The cs1|2 module suite sandboxen are open to all; requests not needed. All you need is a consensus for the change.
Trappist the monk (talk) 13:12, 14 October 2018 (UTC)
Why couldn't the lua pattern for validating |edition= be set to allow both "ed." and "edn"? Galobtter (pingó mió) 12:03, 14 October 2018 (UTC)
The 'validation' pattern doesn't validate anything. It is looking for extraneous text that is often included in the value assigned to |edition=: 'ed', ed.', 'Ed', 'Ed.', 'edition', 'Edition' because this text is redundant to the 'ed.' static text that cs1|2 appends to the value prior to rendering. Of course, the 'validation' can be bypassed when the last three characters of the |edition= value are 'edn'; that is the sort of special encoding I was thinking about.
Trappist the monk (talk) 13:12, 14 October 2018 (UTC)
OK ... And the talk page for that module suite Module:Citation/CS1/sandbox leads right back here. I confess I'm utterly hopeless with all things template-ory. My request for a change – that is, the allowance for a second option ("edn") – is based on English language variation. I'm not sure what lengths one needs to go to achieve consensus on this sort of an issue. Does anyone object to such a change being made? I'm envisioning something that an editor could select to trigger "edn" over the default "ed.", but it wouldn't be binding beyond that. JG66 (talk) 14:06, 14 October 2018 (UTC)
I have these objections:
  1. I see this as a path to inconsistent citation formatting; British English speakers may (unconsciously or no) use the 'edn' form in an article otherwise using the 'ed.' form; conversely, other English-variant speakers ...
  2. it's yet one more niggling detail for editors to argue about
  3. as far as I can tell, this is the only case where there appears to be a difference for English language variation so allowing editors to override this one parameter's static text is inconsistent with all other static text
  4. this would be a special-case; special-cases are to be discouraged because they deviate from the norm
  5. British English speakers apparently understand what 'ed.' means in cs1|2 templates
  1. 'ed.' has been in {{citation}} since its creation
  2. 'ed.' has been in {{cite book}} since it was modified to use {{citation/core}}
  3. I cannot find mention of 'edn in the archives of this page nor in the archives of Template talk:Citation
Trappist the monk (talk) 15:50, 14 October 2018 (UTC)
I agree with your objections; I don't see the need for the inconsistency here. (Just was a bit confused what you were saying regarding "special encoding") Galobtter (pingó mió) 16:00, 14 October 2018 (UTC)
Right, Trappist, but do you actually write articles at all, or just template away? Because, as someone who does write (and only does that here), I can say one doesn't give a crap about templates, just as readers don't, as long as the information appears on screen correctly.
I've provided a link to show that "edn" is the acceptable abbreviation for edition in British English (and other varieties), according to one very well known source; it's not the only acceptable abbreviation, I'm sure. All your objections seem to come from a mindset whereby the answer's no, now what's the question? I'm not surprised there's no mention of "edn" in the archives – I've contributed here for over six years, got used to an American bias and default for most things, and only now have decided to try to do something about this particular issue. "Yet one more niggling detail for editors to argue about" – of course it's not, it's an option that can be selected in a particular variance of English and only then. JG66 (talk) 16:19, 14 October 2018 (UTC)
What you and I do here is entirely immaterial. If you [don't] give a crap about templates, you are to free construct citations by hand.
The claim that "edn" is the acceptable abbreviation for edition in British English might be better phrased 'an acceptable abbreviation'; see the 'ed.' entry at your very well known source. [What's] the question? The one you posed: Does anyone object to such a change being made? I accept that there may be an American bias at en.wiki. For those editors who believe that consistency between citations in an article is important, anything that makes one citation's format different from another citation's format (beyond the obvious citing of different sources) has been and will continue to be a point of contention – that was amongst the reasons that we implemented |mode= (so that cs1 templates render in the same manner as cs2 and visa versa) and |df= (so that all dates in a citation render in the specified format).
Trappist the monk (talk) 17:30, 14 October 2018 (UTC)

Removed support for 'interviewers'[edit]

I have removed support from the sandbox module for |interviewers= as Category:CS1 maint: Uses interviewers parameter‎ has been empty for some time (and spurred by a comment Ttm made when he added support for enumerated interviewers).

  • Current: "Title" (Interview).
  • Sandbox: "Title" (Interview). Unknown parameter |interviewers= ignored (help)

The category can be deleted when the sandbox is next deployed. --Izno (talk) 04:54, 15 October 2018 (UTC)

That would be this comment?
Trappist the monk (talk) 12:07, 15 October 2018 (UTC)
Indeed. --Izno (talk) 12:54, 15 October 2018 (UTC)

Template: Cite journal - Mistaken use of attribute "Volume"[edit]

I encountered a very far-spread problem with the use of the "volume" parameter of this template. According to the docs, the parameter expects an entry like "Volume four", "Vol. 4", "Band VII", etc. If anything shorter than 4 characters is entered, this is printed in bold text in the citation, to mark the mistake.

Nearly all uses of the template seem to ignore this. The result is a host of Volume descriptors, that are nothing but bold printed numbers. This could lead to misunderstandings and confusion among users trying to find the cited journal article. For an impression of the extent of the mistaken use, look at Candide#Sources, for example. Or really any article citing lots of journals.

On IRC, Huon proposed to change the code so that a regular error message is produced instead of just bolding the too short entry. This would prevent future mistaken use. If considered important enough, perhaps the existing countless issues of mistaken use should also be fixed. 2.247.243.131 (talk) 16:17, 17 October 2018 (UTC)

I think that you are mistaken. The bolding that you describe is not to be understood as an indication of error; it is simply the style that is applied to |volume= values that are shorter than five characters.
Trappist the monk (talk) 16:24, 17 October 2018 (UTC)
Ok, my mistake then. Are you sure that this is according to an existing convention that most users can understand? 2.247.243.131 (talk) 16:26, 17 October 2018 (UTC)
It is the convention that cs1|2 has used for journal cites for a very long time, in fact, the bolding was present in the very first version of {{cite journal}}.
Trappist the monk (talk) 16:30, 17 October 2018 (UTC)
For more context, some outside style manuals call for the volume number of a journal to bolded. Volume numbers usually start at 1 the year the journal is founded, and go up by 1 each year. If the volume parameter is short, it's assumed to follow this convention, and gets bolded. If it's long, the template assumes the convention is something the template doesn't understand, and the value is not bolded. Jc3s5h (talk) 16:44, 17 October 2018 (UTC)

ndash not working suddenly[edit]

Suddenly &ndash; is not being recognized within cite template page ranges. For example, go to Phineas Gage and search the text ndash in the rendered page. Unless I'm losing my mind this is new. EEng 10:09, 20 October 2018 (UTC)

EEng, see this and this discussions above Galobtter (pingó mió) 10:12, 20 October 2018 (UTC)
Sleep-deprivation has dulled my mental faculties just now. Is it being fixed or not? EEng 10:21, 20 October 2018 (UTC)
It's fixed in the sandbox but the change has not been synced to the main template as of yet. (changes are made in batches every now and then by Trappist the monk) Galobtter (pingó mió) 10:32, 20 October 2018 (UTC)
Which just shows how ridiculous the syncing schedule is. This is something that should have been deployed as soon as it was fixed, and should still be deployed ASAP. Tens of thousands of articles are broken because of 'oh let's wait till the next update in [0-6 months]'. Headbomb {t · c · p · b} 15:49, 20 October 2018 (UTC)
Yes. XOR'easter (talk) 18:36, 27 October 2018 (UTC)

Script title without a title has no quotation marks[edit]

I don't think this is deliberate (maybe it is?) but a script title without a title has no quotation marks:

{{Cite web |last=Белый |first=Антон |date=September 1, 2014 |website=[[Igromania]] |script-title=ru:Игры, которым не нужен игрок |url=https://www.igromania.ru/article/25527/Igry_kotorym_ne_nuzhen_igrok.html |archive-url=https://web.archive.org/web/20170224013506/https://www.igromania.ru/article/25527/Igry_kotorym_ne_nuzhen_igrok.html |archive-date=February 24, 2017 |dead-url=no}}

-> Белый, Антон (September 1, 2014). Игры, которым не нужен игрок. Igromania. Archived from the original on February 24, 2017.

It probably should. --Izno (talk) 19:45, 21 October 2018 (UTC)

I think that was a deliberate choice. cs1|2 does not apply markup to the value assigned to |script-title= so that it is distinct from the value assigned to |title=. Compare {{cite book}} with {{cite web}}:
{{cite book |script-title=Script Title |title= Title |trans-title=Trans Title |url=//example.com}}Title Script Title [Trans Title].
{{cite web |script-title=Script Title |title= Title |trans-title=Trans Title |url=//example.com}}"Title" Script Title [Trans Title].
At the time this parameter was created, it is not obvious that we considered the |script-title=-absent-|title= use-case though I have a vague memory of at least thinking that non-Latin scripts don't need markup because they are distinct from Latin scripts.
The development discussion is here and continued here.
Trappist the monk (talk) 22:37, 21 October 2018 (UTC)
I agree that the case where both are set was clearly conceived. A lot of the discussion in that conversation seems to focus on the problem of italics (especially the east Asian languages) rather than the problem of quotation marks, which I'm not sure is a problem. (Maybe for consistency it's an issue.) Is Cyrillic text not supposed to use script-title?
On an aside, I am not really sure why {{cite report}} gets a special case in the relevant section of code (that's around line 2900). I would guess those titles should be marked up either as italics or as quoted, not neither. We have a preference for the transliterated title of a report (quotation marks), which is bizarre. The relevant discussion was in archive 6. I'd support removing the special case in favor of the quotation marks. --Izno (talk) 01:22, 29 October 2018 (UTC)

Template:Noitalic causing CS1 error in citation templates[edit]

Here is a search showing instances of "work={{noitalic" (I get about 450 results in article space). The use of {{noitalic}} in CS1 templates has caused COinS metadata errors for a while, and after the last template update, it causes a red error message, "templatestyles stripmarker in |work= at position 1". Someone with access to AWB should be able to make quick work of these errors.

There are also about 230 of these errors in |publisher=, and about 930 uses overall, if my insource search is working properly. – Jonesey95 (talk) 14:05, 23 October 2018 (UTC)

It kind of looks like all of them could be removed. --Izno (talk) 14:32, 23 October 2018 (UTC)
And I'd use the more permissive check for whitespace and redirects. Some of those may be false positives in CS1 templates but it's more inclusive overall. --Izno (talk) 14:36, 23 October 2018 (UTC)
I've done those that were {{noitalic|{{lang|...}}}} in |authorn=, |journal=, |publisher=, |website=, and |work=.
Trappist the monk (talk) 16:09, 23 October 2018 (UTC)
Okay but how are you supposed to force non-italic script then? Like, Chinese characters really shouldn't be italic in something like
Ijima, I. (1897). "Revision of Hexactinellids with Discoctasters, with Descriptions of Five New Species". 日本動物學彙報. 1: 53–59.
And while admittedly "hacky", what's the better way have something which isn't a title (and thus shouldn't be italicized) in the title field, as there's no option to have no |title=. Or must the title be redundantly supplied?
Armstrong, L. E. (1934). "The Phonetic Structure of Somali". Mitteilungen des Seminars für orientalische Sprachen zu Berlin. 37 (Abt. III, Afrikanische Studien): 116–161. [Reprinted. Farnborough: Gregg. 1964. hdl:2307/4698.]
Umimmak (talk) 17:36, 24 October 2018 (UTC)
At the moment there isn't a good answer to the first issue. There has been relatively little discussion about what would probably be the best solution, |script-journal=, |script-magazine=, |script-newspaper=, |script-website=, |script-work=, and perhaps others. See these that I found recently in the archives:
For the second issue, writing cs1|2 templates like this:
{{cite book|title=Reprinted|date=1964|publisher=Gregg|location=Farnborough|hdl-access=free|hdl=2307/4698}}
is poor practice that should not be continued; the citation when considered in isolation (as it might be when consumed by reference management software) is wholly incomplete lacking in the fundamentals of proper title and author. You can visually hide the author information and note that 'this' citation is a reprint by by writing:
{{cite book |last1=Armstrong |first1=L. E. |display-authors=0 |title=The Phonetic Structure of Somali |type=Reprint |date=1964 |orig-year=1934 |publisher=Gregg |location=Farnborough |hdl-access=free |hdl=2307/4698}}
The Phonetic Structure of Somali (Reprint). Farnborough: Gregg. 1964 [1934]. hdl:2307/4698.
While the author's name does not appear visually, it is still available in the citation's metadata:
<cite class="citation book">''The Phonetic Structure of Somali'' (Reprint). Farnborough: Gregg. 1964 [1934]. [[:en:Handle System|hdl]]:<span class="cs1-lock-free" title="Freely accessible">[//hdl.handle.net/2307%2F4698 2307/4698]</span>.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=The+Phonetic+Structure+of+Somali&rft.place=Farnborough&rft.pub=Gregg&rft.date=1964&rft_id=info%3Ahdl%2F2307%2F4698&rft.aulast=Armstrong&rft.aufirst=L.+E.&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1" class="Z3988"></span>'"`UNIQ--templatestyles-00000151-QINU`"'
Trappist the monk (talk) 18:34, 24 October 2018 (UTC)

Wrapper template as a solution to IUCN Red List URL changes[edit]

Due to a recent change in the URLs for the IUCN Red List website, there's been a proposal to enhance the functionality of the supposedly-deprecated {{IUCN}}-family of templates to handle this, and potentially future, changes to IUCN URLs. I have a few questions that I think people here are well equipped to answer:

  1. Given the documentation at {{IUCN}}, is there any guideline to not use wrapper templates to CS1 templates? The reason the doc reads as it does (i.e. use {{Cite journal}} instead of {{IUCN}}; re-ping to WolfmanSF, who originally placed the text in 2015) might just be due to the way the IUCN handles their site, and by their recommendations, or there might also be an underlying WP movement away from wrappers and towards using CS1 directly. I just want to eliminate the latter as a possibility, if that's indeed not the case.
  2. The enhanced functionality of the wrapper template would be to construct the correct URL from composite wrapper-template parameters, namely |doi= and/or |page=, which take the necessary text from the DOI and use it to form the URL, as intended by the IUCN. My problem (and perhaps it's only my problem) is that old values of |url=, which are currently dead in both the wrapper and CS1 templates, will be ignored, and, instead, the wrapper will pass the automatically-generated URL to {{Cite journal}} or {{Cite web}}. This produces a disconnect between the citation text (the, unfortunately, dead URL) and the displayed text (a functioning URL). The old |url= can be removed to solve this secondary problem, but I would prefer to simply update the hard-coded URLs, if possible.

So, while useful, something about this doesn't seem Kosher to me, especially since how this fix is decided will determine whether or not we expand, or we continue to curtail our usage of, {{IUCN}}-family templates. At the very least I think it deserves a discussion wider than WikiProject level.   ~ Tom.Reding (talkdgaf)  15:58, 24 October 2018 (UTC)

I support the use of wrapper templates for all the major taxonomic databases and the like, since there's a history of some of them changing URLs without implementing redirection (e.g. the World Checklist of Selected Plant Families did this, so it's not just the IUCN). One point I would make is that it's essential to have |mode= in the wrapper, at least to select between CS1 and CS2, to maintain a consistent citation style as per the MoS. Peter coxhead (talk) 16:08, 24 October 2018 (UTC)
I am not aware of any guideline that discourages the creation and use of wrapper templates. There are lots of them and they are the reason I wrote Module:Template wrapper. I do not follow your old url / new url description. Real life example? For Editor Peter coxhead, the current {{IUCN}} template has |mode=; that same template rewritten to use Module:Template wrapper would get the |mode= functionality gratis.
Trappist the monk (talk) 16:19, 24 October 2018 (UTC)
Old (dead): https://www.iucnredlist.org/details/13922/0
Temp (alive for the short-term): http://oldredlist.iucnredlist.org/details/13922/0
New (alive for the "long-term"): https://www.iucnredlist.org/species/13922/45199653, where 45199653 is taken from the DOI http://dx.doi.org/10.2305/IUCN.UK.2016-1.RLTS.T13922A45199653.en, available at both the 'Temp' and the 'New' links.   ~ Tom.Reding (talkdgaf)  16:27, 24 October 2018 (UTC)
My problem (and perhaps it's only my problem) is that old values of |url=, which are currently dead in both the wrapper and CS1 templates, will be ignored, and, instead, the wrapper will pass the automatically-generated URL to {{Cite journal}} or {{Cite web}}. This produces a disconnect between the citation text (the, unfortunately, dead URL) and the displayed text (a functioning URL). The old |url= can be removed to solve this secondary problem, but I would prefer to simply update the hard-coded URLs, if possible.
If you are rewriting the {{IUCN}} template doesn't that, sort of by definition, remove the old, dead |url= value and replace it with the new, living |url= value? This:
| url = http://www.iucnredlist.org/details/{{{id|{{{ID|}}}}}}
gets replaced with something perhaps like this:
| url = https://www.iucnredlist.org/species/13922/{{#invoke:string|match|s={{{doi|}}}|pattern=%u(%d+)%.%a+$|plain=false|nomatch=error}}
So where then, is the disconnect?
Is the issue that instances of {{IUCN}} in article space may not have |doi= so until they get |doi= you want to modify the old, dead |url= value into the temp |url= value unless |doi= is present (and has a value) in which case you want to use |doi= to make a new |url= value? Even if this is the case, I still don't see the disconnect.
Trappist the monk (talk) 17:01, 24 October 2018 (UTC)
Removing the old does make the situation a bit better, and will prefer the use of {{Cite journal}}, which I think is more appropriate, over {{Cite web}}. If a user would want to use a different URL, then the |url= parameter would be rendered useless in the wrapper; but perhaps that will be an unlikely scenario, and can be discussed at the template/WikiProject level, if needed.
Separately, each of my 2 points aren't a real obstacle, but together they were too many 'ifs' for me to feel comfortable. Also, I spent some time converting from {{IUCN}}-type templates to {{Cite journal}} per the template's own recommendations, so I prefer there be at least some respect given to that direction; but as long as there's strong agreement in either direction, and no major issues, I'm fine with it.   ~ Tom.Reding (talkdgaf)  19:19, 24 October 2018 (UTC)
If a user would want to use a different URL, then the |url= parameter would be rendered useless in the wrapper Really? In the wrapper, wouldn't this use the editor's url over the url constructed by the wrapper?
| url = {{{url|https://www.iucnredlist.org/species/13922/{{#invoke:string|match|s={{{doi|}}}|pattern=%u(%d+)%.%a+$|plain=false|nomatch=error}}}}}
Trappist the monk (talk) 19:48, 24 October 2018 (UTC)
Nothing has been implemented yet, but yes, that behavior was suggested at Wikipedia talk:WikiProject Tree of Life#IUCN References. I didn't mean it to sound like that behavior would be a direct result of any wrapping, just that it was a tentatively described "feature" (one that may not even be implemented, especially if removing the old, dead, |url= happens in the same edit).   ~ Tom.Reding (talkdgaf)  21:36, 24 October 2018 (UTC)
Why does the doi url not work? http://dx.doi.org/10.2305/IUCN.UK.2016-1.RLTS.T13922A45199653.en
I was going to suggest that because you have a doi, |url= is superfluous – it is in the normal case, but if iucn is not going to support doi any longer then, yeah, I guess you have to rewrite the url.
{{cite journal |author1=Sillero-Zubiri, C. |author2=Do Linh San, E. |last-author-amp=yes |year=2016 |title=''Mungos gambianus'' |journal=[[The IUCN Red List of Threatened Species]] |volume=2016 |page=e.T13922A45199653 |doi=10.2305/IUCN.UK.2016-1.RLTS.T13922A45199653.en |doi-access=free}}
Sillero-Zubiri, C. & Do Linh San, E. (2016). "Mungos gambianus". The IUCN Red List of Threatened Species. 2016: e.T13922A45199653. doi:10.2305/IUCN.UK.2016-1.RLTS.T13922A45199653.en.
Trappist the monk (talk) 22:06, 24 October 2018 (UTC)
My assumption is that the failure of doi urls is an oversight by the IUCN. The use of doi as permanent links was part of their reasoning that they should be cited as a journal and the reason for preferring {{cite journal}} on Wikipedia. So hopefully the IUCN and IDF will communicate and fix the issue. Although if the IUCN want to encourage people to link to the new site they might not want the doi updated to the old site. If they don't fix it this week the latter may be the case.   Jts1882 | talk  16:51, 25 October 2018 (UTC)
The IUCN doi links now work again, pointing to the new website.   Jts1882 | talk  14:27, 29 October 2018 (UTC)

Global templates[edit]

I'm looking at phab:T121470 and wondering whether this might reduce some of the maintenance hassles around these popular citation templates. It's hard to set them up, and then most of the small wikis never update their code again. If they do, then a straight copy of the enwiki templates means that they lose anything (e.g., parameter names) that they translated into the local language.

The global template system would require some dev work (maybe a year's worth of work), and then the template would have to be "marked for translation", to steal a phrase from Extension:Translate. So that's extra work for the template editors. On the other hand, once that happened, you could push an update once, and it would update all the wikis at the same time (well, all the wikis that wanted to use the global template system, but that's probably most of them).

What do you think? (Please ping me. I'd really appreciate it.) Whatamidoing (WMF) (talk) 17:28, 25 October 2018 (UTC)

Removal of publisher and publisher location[edit]

Why is the bot removing the publisher and publisher location for a cite journal template at [4]?--Sturmvogel 66 (talk) 23:39, 27 October 2018 (UTC)

This page is not the home of Citation bot. Instead, see this discussion.
Trappist the monk (talk) 00:00, 28 October 2018 (UTC)
And because this is pointless and useless information that violates every style guide on how to do journal citations. If an exception exist (like hacking a cite web into a cite journal for... whatever reason) you can tell the bot to leave that citation alone. Headbomb {t · c · p · b} 01:13, 28 October 2018 (UTC)

Cite AV Media doesn't show title-link[edit]

Example {{cite AV media | author=Yuyama Kunihiko|date=2012-07-14 | script-title=ja:劇場版ポケットモンスター ベストウイッシュ キュレムVS聖剣士 ケルディオ|trans-title=Pokémon the Movie: Kyurem vs. the Sword of Justice|title-link=Pokémon the Movie: Kyurem vs. the Sword of Justice|language=ja | publisher=OLM, Inc.}}


Result: Yuyama Kunihiko (2012-07-14). 劇場版ポケットモンスター ベストウイッシュ キュレムVS聖剣士 ケルディオ [Pokémon the Movie: Kyurem vs. the Sword of Justice] (in Japanese). OLM, Inc. --minhhuy (talk) 04:25, 31 October 2018 (UTC)

Fixed in the sand box I think:
Yuyama Kunihiko (2012-07-14). 劇場版ポケットモンスター ベストウイッシュ キュレムVS聖剣士 ケルディオ [Pokémon the Movie: Kyurem vs. the Sword of Justice] (in Japanese). OLM, Inc.
Trappist the monk (talk) 09:40, 31 October 2018 (UTC)

Cite Map with translated title[edit]

I'm a bit confused on how I should use Template:Cite map with |map=, |map-url= and |trans-title= as I can't get a translated title to work with these.

  • If I add these 3, I get |trans-title= requires |title=.
  • If I change |map= to |title=, I get |map-url= missing title.
  • If I then also change |map-url= to |map=, I get |access-date= requires |url=.
  • If I try replacing |trans-title= with |trans-map=, I get Missing or empty |title=.

Any suggestion on how to use Cite Map with these fields? --Gonnym (talk) 09:22, 31 October 2018 (UTC)

If you are citing a sheet map (a stand-alone map) then you must use |title=, |trans-title=, and |url=. When you are citing a map that is part of a larger work, |map=, |trans-map=, and |map-url= apply; these are akin to |chapter=, |trans-chapter=, and |chapter-url= in a {{cite book}} template. See the examples at {{cite map}}.
Trappist the monk (talk) 09:53, 31 October 2018 (UTC)
The example I was following is the last one in the "Maps contained within larger works" examples - which is the only example given for an online map (which is not Google or Bing). Please note that I did what you wrote but still got an error, see my last bullet point. Also, if you'd like to test it - take the example from the list and add "trans-map" ({{Cite map |author = [[OpenStreetMap]] contributors |date = 26 November 2011 |map = E.T. Seton Park |map-url = http://www.openstreetmap.org/?lat=43.70891&lon=-79.34334&zoom=15&layers=M&way=25480325 |work = OpenStreetMap |access-date = 26 November 2011 |trans-map=test}}) --Gonnym (talk) 10:01, 31 October 2018 (UTC)
You changed |title= to |work= which is not an alias of |title=. Restoring the example and adding |trans-map=:
Cite map compare
{{cite map |map=E.T. Seton Park |trans-map=test |title=OpenStreetMap |access-date=26 November 2011 |date=26 November 2011 |author=[[OpenStreetMap]] contributors |map-url=http://www.openstreetmap.org/?lat=43.70891&lon=-79.34334&zoom=15&layers=M&way=25480325}}
Live OpenStreetMap contributors (26 November 2011). "E.T. Seton Park" [test] (Map). OpenStreetMap. Retrieved 26 November 2011.
Trappist the monk (talk) 10:33, 31 October 2018 (UTC)
I didn't change anything, as I just used the only example shown for a web generated map. I just tried to make sense of the examples as the documentation doesn't even address |trans-map=, and |trans-title= doesn't even say that using |work= is incorrect. Regardless, thanks for clearing this up. --Gonnym (talk) 11:04, 31 October 2018 (UTC)
Right, you didn't; mea culpa. The documentation sucks, everyone complains that the documentation sucks yet those who complain never do anything but complain and never help to make it better. The example's code-view did not match the example's rendered view. I've fixed that.
Trappist the monk (talk) 11:37, 31 October 2018 (UTC)
I tend to fix stuff I understand and stay clear from those I don't. I've used mostly cite web all these years and if you ask me what does anyone of the params I've never used, I'll have no idea. For me the cite template doc always felt like a huge wall of text and I either stay completely clear or just Ctrl+f to find a specific word. --Gonnym (talk) 11:54, 31 October 2018 (UTC)

cite wikisource[edit]

Because of discussion here, I made some changes to Module:Template wrapper/sandbox (discussed here). I was looking for something a bit more complex that could be a test-bed for ideas the the IUCN template inspired and settled on {{cite wikisource}} because, when wrapped in Module:Template wrapper for |_template=cite book, it has some parameters (|at=, |chapter=, |publisher=, |title=) that are native both to {{cite wikisource}} and to the working template {{cite book}}.

I think that I have resolved all of the issues that would allow rewriting {{cite wikisource}} to use Module:template wrapper with {{cite book}} except for one: {{cite wikisource}} adds wikisource icons to |chapter= and |title= by prefixing the content of |chapter= or |title= with [[File:Wikisource-logo.svg|12px|class=noviewer|alt=Wikisource link to]]&nbsp; (which it should not be doing because that corrupts the citation's metadata.

There may be a solution. cs1|2 adds access icons to externally linked |title=, |chapter=, various identifiers. I created wikisource icon css in Module:Citation/CS1/sandbox/styles.css and tried wrapping the content of |chapter=[[wikisource:On_the_Origin_of_Species_(1859)/Chapter_VII|Chapter_VII Instinct]] with an appropriate <span>...</span> tag. That worked but didn't work because the icon overlaid the last word of the chapter rendering. I think that this is because the icon image is positioned according to the right-side boundary of the chapter text (the right-most " mark). There may still be a solution there; I imagine that we might add n number of &nbsp; characters sufficient to allow proper placement of the icon or perhaps, there is some slick css trick that I don't know about that would do the same.

The solution that I did come up with is to convert [[wikisource:On_the_Origin_of_Species_(1859)/Chapter_VII|Chapter_VII Instinct]] to https://en.wikisource.org/wiki/On_the_Origin_of_Species_(1859)/Chapter_VII which uses the space occupied by the normal MediaWiki external link icon (as we do for access icon's):

{{cite book/new |title=On the Origin of Species by Means of Natural Selection, or the Preservation of Favoured Races in the Struggle for Life |chapter=[[wikisource:On_the_Origin_of_Species_(1859)/Chapter_VII|Chapter_VII Instinct]] |location=London |publisher=John Murray |date=1859 |last=Darwin |first=Charles}}
Darwin, Charles (1859). "ChapterVII Instinct" . On the Origin of Species by Means of Natural Selection, or the Preservation of Favoured Races in the Struggle for Life. London: John Murray.

Compare {{cite wikisource}}:

{{cite wikisource |plaintitle=On the Origin of Species (1859) |chapter=Chapter VII |location=London |publisher=John Murray |date=1859 |last=Darwin |first=Charles}}
Darwin, Charles (1859). "Wikisource link to Chapter VII". On the Origin of Species (1859). London: John Murray. Wikisource. 

There is a long-standing feature request to add {{cite wikisource}} to the cs1|2 module. I don't think that we should do that but adding a little support to the cs1|2 module that allows the icon and also moves {{cite wikisource}} away from {{citation/core}} is probably a good thing.

Trappist the monk (talk) 15:01, 5 November 2018 (UTC)

I support moving {{cite wikisource}} away from using {{citation/core}}, since it is antiquated and not maintained. Is there a page of testcases that show how the template looks now versus how it looks in a sandbox version using the wrapper? I'd be happy to look at it and provide feedback. Have you considered placing a note at Template talk:Cite wikisource? I would do so for you, but you usually have a plan in mind, so I will defer to you. – Jonesey95 (talk) 17:25, 5 November 2018 (UTC)
No page of test cases yet for this particular change to the cs1|2 module. You can see comparisons of the live and Module:template wrapper/sandbox versions of {{cite wikisource}} at Template:cite wikisource/testcases. I still have to figure out how to support wikisource interwiki links in |title= and in |title-link= within cs1|2 templates before I'll be ready to broach the topic at Template talk:cite wikisource. I don't know if this change should be constrained to {{cite book}} or if there are other cs1|2 templates that should support this feature.
Trappist the monk (talk) 18:32, 5 November 2018 (UTC)
Tweaked the code to add wikisource icon to the rendered title when |title= is linked through |title-link=:
{{Cite book/new |title=On the Origin of Species by Means of Natural Selection, or the Preservation of Favoured Races in the Struggle for Life |titlelink=wikisource:On_the_Origin_of_Species_(1859)|location=London |publisher=John Murray |date=1859 |last=Darwin |first=Charles}}
Darwin, Charles (1859). On the Origin of Species by Means of Natural Selection, or the Preservation of Favoured Races in the Struggle for Life . London: John Murray.
I have also inserted a single space character between the ends of chapter and title renderings to move the icon so that it doesn't directly abut the text. The wikisource icon is a tad larger than the access icons (12px v 9px).
edit:
and when |title= holds an interwiki link:
{{Cite book/new |title=[[wikisource:On_the_Origin_of_Species_(1859)|On the Origin of Species by Means of Natural Selection, or the Preservation of Favoured Races in the Struggle for Life]] |location=London |publisher=John Murray |date=1859 |last=Darwin |first=Charles}}
Darwin, Charles (1859). On the Origin of Species by Means of Natural Selection, or the Preservation of Favoured Races in the Struggle for Life . London: John Murray.
Trappist the monk (talk) 12:25, 6 November 2018 (UTC) 14:59, 7 November 2018 (UTC)
Personally, I'd drop the icon and have the template add |via=Wikisource. {{AASHTO minutes}} cites Wikisource (for one of its minutes) or Commons (for the rest, for now), and we even added a |v-link= to turn on a wikilink to the entry in the underlying |via=:
  • Special Committee on U.S. Route Numbering (June 26, 1985). "Route Numbering Committee Agenda" (Report). Washington, DC: American Association of State Highway and Transportation Officials – via Wikisource.
  • Special Committee on U.S. Route Numbering (June 26, 1985). "Route Numbering Committee Agenda" (Report). Washington, DC: American Association of State Highway and Transportation Officials – via Wikisource.
In any case, we don't add icons when a copy of a source is hosted on Commons, so I don't see why Wikisource is anything special. Imzadi 1979  12:56, 6 November 2018 (UTC)
I agree that |via=[[Wikisource]] is more correct than concatenating [[Wikisource]] onto the end of |publisher= as {{cite wikisource}} does now.
Wikilinks and interwiki links are so similar in appearance as to make them indistinguishable to the casual reader; especially in isolation. Compare:
wikilink color
interwiki link color
external link color
the icon clearly indicates to the reader that a wikisource link is not a link to a page at en.wiki. Because {{AASHTO minutes}} uses {{cite web}}, it must be given a value in |url= which causes MediaWiki to apply the external link icon thereby distinguishing it from wikilinks and interwiki links.
Trappist the monk (talk) 14:59, 7 November 2018 (UTC)

Digression on usage[edit]

This is not really relevant to purposes in the thread above, where {{cite wikisource}} is just a use case for changes to Module:template wrapper, but…

I don't think a {{cite wikisource}} template makes sense. Wikisource doesn't publish original works, it just reproduces existings works. These works can be books, journals, magazines, newpapers, or encyclopedias (or, of course, parts like chapters, articles, entries, etc.). What Wikipedia cites is the original work, it just happens that we cite the copy extant on Wikisource. This is analogous to databases like Questia, JSTOR, or Project MUSE, and what we have |via= for.

In view of that, perhaps a better approach would be a |wikisource-link=title parameter as a convenience shortcut for [[:s:title]] syntax, and possibly also triggering the display of the Wikisource logo (analog here to the external link icon). --Xover (talk) 12:46, 6 November 2018 (UTC)

You might be right. If you think that the template should be deleted, or you are wondering if its documentation should restrict its use, I recommend posting at both Template talk:Cite wikisource and Wikipedia talk:WikiProject Wikisource to see if you get any response. Each of those pages has fewer than 30 watchers, however, so you might not get much. – Jonesey95 (talk) 13:17, 6 November 2018 (UTC)
I agree, and was thinking about this yesterday. I am very bothered by it. :) --Izno (talk) 19:19, 6 November 2018 (UTC)
I'm not sure that I agree. There is no requirement that citation templates of any stripe be used only for original-work publishers. Were that the case then {{Gutenberg book}} (basically a fork of a 2007-ish version of {{cite book}}) should be disallowed because Project Gutenberg just reproduces [existing] works. That template uses this construct to link to a Project Gutenberg title:
[[gutenberg:2383|''The Canterbury Tales and Other Poems'']]
The Canterbury Tales and Other Poems
That pseudo-interwiki construct must be documented someplace but a quick-search didn't locate the documentation. Anyone know where it is? Are there others like it?
I do agree that {{cite wikisource}} should be using |via=.
Trappist the monk (talk) 14:59, 7 November 2018 (UTC)
meta:interwiki map. --Izno (talk) 17:38, 7 November 2018 (UTC)
Well, I don't generally mind specific-source templates, for convenience and consistency, but there is an argument to be made that since Wikisource is, itself, not a reliable source, we should not have a template that suggests that we cite it as an authority. But I suppose that argument runs afoul of the second corollary to Spaf's first axiom of Usenet ("Arguing about the significance of newsgroup names and their relation to the way people really think is equivalent to arguing whether it is better to read tea leaves or chicken entrails to divine the future.").
A more practical issue, however, is that Wikisource contains all kinds of sources: if, for example, {{cite wikisource}} wraps {{cite book}} the output (including metadata AIUI) will be incorrect for a magazine, and so forth. Hence the thought that if we want various special behaviours for citations to works that are reproduced on Wikisource then those behaviours are better triggered by specific parameters (like the mentioned |wikisource-link= example above) on the main citation templates than by the invoking template. Or perhaps |via= should accept magic words (i.e. |via=Wikisource) that trigger such behaviour? --Xover (talk) 08:49, 8 November 2018 (UTC)
The documentation for {{cite wikisource}} doesn't explicitly say that the template is to be used solely for books though book-only is implied by the examples it shows. You are correct that, at present, books are all that it supports. We could easily change {{cite wikisource}} to use {{citation}} so that rendering and metadata are determined by the content of the periodical parameters |newspaper= and |magazine=. Here is a newspaper cite using {{cite news}}:
{{cite news/new |last=Wells |first=H. G. |title=Heroic Airmen are Key to Victory |title-link=s:Heroic Airmen Are Key To Victory |newspaper=Daily Mail |date=9 August 1918}}
Wells, H. G. (9 August 1918). "Heroic Airmen are Key to Victory" . Daily Mail.
and again, this time using {{citation}}:
{{citation/new |last=Wells |first=H. G. |title=Heroic Airmen are Key to Victory |title-link=s:Heroic Airmen Are Key To Victory |newspaper=Daily Mail |date=9 August 1918}}
Wells, H. G. (9 August 1918), "Heroic Airmen are Key to Victory" , Daily Mail
Here is a book cite using {{cite book}}:
{{Cite book/new |title=Sentido y sensibilidad |titlelink=s:es:Sentido_y_sensibilidad |last=Austin |first=Jane}}
Austin, Jane. Sentido y sensibilidad .
same again using {{citation}}:
{{citation/new |title=Sentido y sensibilidad |titlelink=s:es:Sentido_y_sensibilidad |last=Austin |first=Jane}}
Austin, Jane, Sentido y sensibilidad 
In a new version of {{cite wikisource}} using {{citation}} we would preset |mode={{{mode|cs1}}} so that the citations render in the same style as legacy {{cite wikisource}}. I have tested these changes in {{cite wikisource/sandbox}} but not yet implemented them.
Trappist the monk (talk) 13:01, 8 November 2018 (UTC)
Further, {{cite wikisource}} has |class= which can be set to one of the various values supported by {{citation/core}} (these aren't defined anywhere except in the various cs1|2 templates that directly call Module:Citation/CS1). This search would seem to indicate that article space has some 400ish instances of {{cite wikisource}} that include some form of |class=, most of them |class=dictionary; this contrary to the template doc that says:
  • class: The CSS class for the citation; use only when this template is used as a metatemplate; do not use directly when making citations in the article namespace.
Not sure why that stricture. Regardless, with the exception of setting the the css class for the rendering's enclosing <span>...</span> tag, |class= appears be exclusively used in the mind-numbing mess that feeds {{citation/core}}'s |At= parameter so doesn't, apparently, drive the correct use of the template's metadata or rendering.
Trappist the monk (talk) 16:28, 8 November 2018 (UTC)

Add |software parameter to Template:cite map[edit]

The cite map template is missing a single parameter to be able to fully cite GIS maps. From this website, it seems like it is recommended to cite the software package used to create the map. -Furicorn (talk) 19:10, 6 November 2018 (UTC)

Last/First, First/Last[edit]

Could somebody add an option to cite book to display the author's first name before the last name? Kurzon (talk) 08:15, 9 November 2018 (UTC)

Names are hard. Use |author=. – Jonesey95 (talk) 08:35, 9 November 2018 (UTC)
No. It's customary for any citation style, inside or outside Wikipedia, to specify when the first name should be written first, and when the family name should be written first, and for everyone to follow whatever the specification is. There is no reason to create an option to make it easier for editors to deviate from the standard chosen for Citation Style 1. Jonesey95, I believe |author= is best used for corporate authors, where the terms last name and first name do not apply. Jc3s5h (talk) 11:04, 9 November 2018 (UTC)
Unfortunately, we have WP:CITEVAR here at en.WP, which means it's up to local consensus (or the article's "first major contributor") to determine how citations look in a given article. If an editor or WikiProject wants to implement CMOS's "First Last, First2 Last2, and First3 Last3" or "Last, First, First2 Last2, and First3 Last3" (ugh) style in a consistent way using CS1 templates, |author= makes that possible. You might not like it, but that's CITEVAR for you (p.s. I don't like it either, but I'm not going to die on that hill.) – Jonesey95 (talk) 11:12, 9 November 2018 (UTC)
Yes, but this is the Citation Style 1 talk page, so we are talking about an article where this family of templates has been chosen, and therefore the last, first name order has been chosen. Just as if Chicago Manual of Style footnotes without a bibliography had been chosen, in which case the order would be first last. And I believe it's just incorrect to use Citation Style 1 templates to implement a citation style that departs from the documentation at this page and the individual templates that make up the style; by no it's firmly established that CS1 is a style, not just a set of tools. If you want to use your chisel as a screwdriver at your home, go ahead, but don't use CS1 to implement Chicago style. Jc3s5h (talk) 11:21, 9 November 2018 (UTC)
(edit conflict) I am sympathetic to Jc3s5h's viewpoint, but the consensus is against it. Even the CS1 Template:cite book documentation disagrees: "author: this parameter is used to hold the complete name of a single author (first and last) or to hold the name of a corporate author. This parameter should never hold the names of more than one author." (emphasis added). This text was added more than two years ago, to no objections; it had been a de facto practice for many years before that. – Jonesey95 (talk) 13:39, 9 November 2018 (UTC)
I will also use |author= with Asian names, because I am dumb and how Asian names are in the west versus the east versus wherever the cited author is from is hard. --Izno (talk) 13:24, 9 November 2018 (UTC)
This was discussed recently, at some length, in archive 45. --Izno (talk) 13:23, 9 November 2018 (UTC)
I still support adding |af=, failing that, hacks are valid. Or use |author1=/|author2=/... Headbomb {t · c · p · b} 15:35, 9 November 2018 (UTC)
When did "first and last" get added? Just how much attention did that get? Apparently not enough for any COinS fans to complain about degrading the metadata. This needs looking into.
The CMS "footnotes without a bibliography" example Jc3s5h provides is the special case of individual full citations at the foot of a printed page, where they are laid out in European-centric "normal" order. I believe all style guides recommend having lists of citations sorted by the lexicographic key, which is normally the first author's surname ("last name"). (Where styles differ is whether co-authors should have their names inverted. The general and accepted practice here is to invert the co-authors' name same as the first author's name.)
Kurzon: why do you want this option? Is it a purely personal preference, or is there some kind of problem that needs addressing?
The MOS is where we say that certain consistencies of "style" are strongly preferred (even to the point of being required). That WP:CITEVAR allows some latitude in some areas doesn't give editors carte blanche elsewhere. Largish lists (such as sources) need to be sorted (so they can be readily scanned by the reader), with the sort key (such as last name) at the head of each entry. This is so standard that deviation would be confusing. (Surely no one is proposing to sort by an author's first name. Right?)
Mixing first and last names into |author= is bad enough where we are familiar enough with the names to distinguish them, but even worse for unfamiliar names. We need this last/first metadata, and the editor adding a source should sort out the name parts, and put them into the proper parameters. ♦ J. Johnson (JJ) (talk) 23:37, 9 November 2018 (UTC)

I don't like using |author= because the harv template can't use that parameter. Kurzon (talk) 08:38, 10 November 2018 (UTC)

When to disambiguate and wikilink place/location[edit]

place: Geographical place of publication; generally not wikilinked; omit when the name of the work includes the location; examples: The Boston Globe, The Times of India. Displays after the title. Alias: location

{{cite book}}'s documentation could use some clarification on wikilinks and disambiguation. In the case of:

Sure, I wouldn't link New York City, but Oakland, California, is not a major city—when should the place/location be linked? And regardless of whether it's linked, should we use the full disambiguated article title, or would it be sufficient to link as Oakland and Princeton? czar 16:21, 20 October 2018 (UTC)

bump (not watching, please {{ping}}) czar 13:42, 9 November 2018 (UTC)
@Czar: maybe other editors have different practices, but in general I never wikilink locations in citations since I can't imagine a situation where a reader sees a citation and really wants to know more about a particular city in the context of it being the location of a publishing house for one of an article's sources. And I add state/province/country if it really needs disambiguating (for example, CMoS 17 has Cambridge, MA: MIT Press but Cambridge: Cambridge University Press) or if I don't think the average reader would know where a particular city would be (although perhaps I have higher expectations for the general reader since I would think everyone knows where Princeton is but CMoS 17 gives Princeton, NJ: Princeton University Press). Obviously Wikipedia house style is different from Chicago, but If the city of publication may be unknown to readers or may be confused with another city of the same name, the abbreviation of the state, province, or (sometimes) country is usually added probably works as general advice. For your Princeton example, it seems omit when the name of the work includes the location takes care of that anyway since where else would Princeton University Press be if not Princeton so |location= probably isn't even necessary. Just my $0.02 on this. Umimmak (talk) 21:28, 12 November 2018 (UTC)

Using access-date and archive-date[edit]

Is there any benefit to using both archive-date and access-date when there is an archived url? I have been told in the past to remove the "access-date" field when adding a link to an archived version, which makes logical sense to me, but another editor recently restored all the access-date text. It seems like unnecessary cluttering of the references, but I would like to know if this has been decided already?  Mr.choppers | ✎  01:17, 13 November 2018 (UTC)

I provide one or the other, not both, as indeed it is superfluous (given that your archive page reflects the web page as it stood on the access date--not always or necessarily the case for web pages which change frequently--but in that case, you probably wouldn't want the archive page). --Izno (talk) 02:56, 13 November 2018 (UTC)
What is the rationale for including both access and archive dates. It makes citations hard to read and messy. If an archive only exists for a certain date, the access-date is useless. If the archive matches the access-date, it is useless. If the archive verifies the cited fact, the access-date is useless. -- GreenC 04:12, 13 November 2018 (UTC)

Move development to GitHub?[edit]

Is it just me who feels that its rather pathetic that this wonderful project has been limited due to it being completely on-wiki, when most serious software development these days take place on dedicated platforms like GitHub? Are there any reasons why we are keeping this here?

The CS1 modules appear to be almost entirely written and maintained by one single editor since around 2013 (though undeniably he has done a great work at that). But there is no collaboration taking place. All edits are saved with the edit summary "sync from sandbox" and the sandbox edits themselves don't have any edit summaries at all. I note that changes are still being recorded through other means, but its nothing like the commit history available on version control systems like git.

The recent issue with ndashes has been brought up brought up four times. The fix, though promptly done by Trappist the Monk, is still in the sandbox and hasn't been deployed. Edits are made in the sandbox and deployed in batches to main module once in a while by the Monk. This wiki-based workflow is quite inferior to the sophisticated pull request mechanism we have on git. Using a system like GitHub, everything is a whole lot easier. Commit messages are helpful in allowing multiple coders to collaborate (which isn't taking place here, and I don't it's due to lack of interested programmers). When two people working on forks make changes to different parts of a same file, the git software merges both versions automatically - the sort of stuff that here would be need to fixed by the nasty process of manually copy-pasting the correct code blocks from both versions.

Moving the development work to GitHub (and having a bot to sync changes from the github repo to the wiki) would help new coders who wish to help out on this project. This is the way popular gadgets and tools like Twinkle, wikEd, AFCH script, etc are written and maintained. SD0001 (talk) 18:49, 13 November 2018 (UTC)

Well one big difference is that changes to CS1|2 require community consensus. The sandbox changes are announced, then time is given for comment before they are committed. Also the sandbox changes are not even made until there is some initial discussion with no serious objection. The idea is to give lots of time for editors to discover the proposal and comment and not move fast (unless it's an urgent bug). Also since the template has millions of instances the Module can't be updated frequently or it interferes with backend services (someone more knowledgeable can comment on details of this). -- GreenC 19:03, 13 November 2018 (UTC)
I have collaborated multiple times. :) As for syncing, the reason that it is not often synced is because many pages are affected and we try to avoid causing the job queue to be sad. I would have no issue with a mini-RFC to release the module to correct the dash issue if you think that is necessary (I think it might be). Maybe what we should really have is a discussion about how often we should release this module set. --Izno (talk) 20:04, 13 November 2018 (UTC)
GitHub is not free software, so it would be against Wikipedia's values to force people to use it. Wikimedia offers compliant git hosting facilities, but as noted above this is not a matter of technical tools, rather it's about decisions on release speed etc. Nemo 12:16, 14 November 2018 (UTC)
@SD0001: I'm unclear on the basis for you're complaint. Have you ever been denied the opportunity to collaborate here? Has anyone been denied? Can you give a concrete example to show how this project has been limited due to it being completely on-wiki?
I have some, not a lot, but some experience with github. In my use of it I have always had sufficient permissions so that I did not have to do pull requests to implement my changes to the code. Were we to migrate cs1|2 to github, someone or a group of designated someones, would need to serve as the gatekeeper(s) for pull requests from contributors who do not have the requisite permissions. At github, there is no facility to test changes so we would still require some sort of sandboxing here. At en.wiki, any admin can edit the live modules; the sandboxen are open to any and all editors.
Trappist the monk (talk) 13:17, 14 November 2018 (UTC)