Wikipedia

Help talk:Citation Style 1/Archive 46

< Help talk:Citation Style 1
Latest comment: 6 years ago by Izno in topic Work and publisher wikilinks
Archive 40←Archive 44Archive 45Archive 46Archive 47Archive 48→Archive 50

Proposal: make ref=harv the default for CS1

Latest comment: 6 years ago32 comments11 people in discussion

Prompted by Headbomb in another discussion, I propose that |ref=harv be made the default for CS1 (it's already the default for CS2). It has no visible effect unless you're running a non-standard user script (and if you do, you probably want this behaviour anyway); no downsides, tradeoffs, or obviously relevant failure modes that I can see; makes CS1 and CS2 more consistent; and has the upside that it enables {{sfn}}-type short citation linking by default, and it enables said non-default user scripts to do sanity checking on cites for those who desire it (or for bots and other automated tools should a need for that arise). In other words, as best I can tell, it's all upside and should be entirely uncontroversial. --Xover (talk) 08:10, 26 July 2018 (UTC)

Would this effect other ways of using |ref (for example |ref=harvid...)Nigel Ish (talk) 10:10, 26 July 2018 (UTC)
In {{citation}}, editor-provided |ref= values override the harv default; were this proposal to be adopted (at the moment, I stand opposed), the default |ref= value in cs1 templates would also be overridden by editor-provided |ref= values.
—Trappist the monk (talk) 12:09, 26 July 2018 (UTC)
There are those who believe that bibliographic lists of the type linked into by the {{harv}} and {{sfn}} templates should be written in cs2 style. Particularly, as I understand it, they object to the dot separator character that is used by cs1.
Once upon a time, all cs1|2 templates that used {{citation/core}} created an id attribute for use in the citation's enclosing <cite>...</cite> tags whenever |ref= had a value or, when not set, the template had authors and a date. Support for |ref=harv was added to {{citation/core}} with this edit. This edit to {{citation}} set |ref=harv as the cs2 default. These changes were made as the result of this discussion which led to this discussion and the determination that cs2 would automatically set |ref=harv and cs1 would not.
—Trappist the monk (talk) 12:09, 26 July 2018 (UTC)
Sigh. I wish I had been aware of that discussion, because as the maintainer for the W3C Markup Validation Service at the time I can explain at length why any arguments there based on error messages from the validator are nonsense (Fullstop touches on the essence). In the interest of brevity, let me just mention that this family of templates right now generates invalid markup in a way that is significantly more relevant than the duplicate IDs (hint: HTML5 defines the content model for the cite element in a way that is… nonintuitive).
However, what I am not clear on is why the situation is different for CS2 than for CS1. Is there some difference in behaviour for CS2, that I am not aware of, that prevents it from generating duplicate IDs? If not, why are duplicate IDs ok in CS2 but not in CS1?
I also don't understand what relevance the formatting differences between CS1 and CS2 have to the question of whether to generate an ID by default. I mean, yes, there are zealots editors with strongly held opinions—presumably on both sides—but I can't imagine why they would care about whether a ref ID is generated by default.
In any case, apart from the validation errors argument (which I understand but assert is not a valid argument), I am failing to see the arguments against making it default. Could someone elucidate? --Xover (talk) 15:41, 26 July 2018 (UTC)
If I remember correctly (and without trawling the archives for verification) it is for historic reasons. Long before Lua coded templates, some people who wanted to use short inline citations with long citations in a reference section and created {{harv}} and {{citation}} specifically to link the two and hence the ref parameter defaulted to "on". Those who developed {{cite book}} et al, did not consider that a priority (often because the templates were placed between ref...tag pairs) and did not implement it. The parameter was added later and for the type of problems discussed in this section it defaulted to off. When the Lua module was implemented those defaults were carried over into the new code. -- PBS (talk) 11:08, 16 August 2018 (UTC)

It should be on by default. It's a real pain in the ass to set manually, and uses go way beyong WP:LDR style. You have have something like

This is a thing.[1] This is another thing.[2]

  1. ^ Lagesen, Vivian Anette (January 2008). "A Cyberfeminist Utopia?". Science, Technology, & Human Values. 33 (1): 5–27. doi:10.1177/0162243907306192.
  2. ^ See Figure 4 in Lagesen 2008.

vs

This is a thing.[1] This is another thing.[2]

  1. ^ Pfaffenberger, Bryan (29 July 2006), ""If I Want It, It's OK": Usenet and the (Outer) Limits of Free Speech", The Information Society, 12 (4): 365–386, doi:10.1080/019722496129350
  2. ^ See Pfaffenberger 2006, p. 382 in particular.

It makes no sense to force editors to go through extra hoops to support the first case, but allow the second case.Headbomb {t · c · p · b} 19:14, 26 July 2018 (UTC)

Any questions of cs1 style or cs2 style seem irrelevant, as this proposal (as In understand it) makes no change to the formatting of a citation, only in the details of the anchor. Being only a default, it would make no difference in any explicit use of |ref=.

I am inclined to support, but perhaps Trappist would enlighten us with why he currently opposes the proposal. ♦ J. Johnson (JJ) (talk) 20:05, 26 July 2018 (UTC)

Nine years ago, editors at {{citation/core}} believed that something was amiss when both cs1 and cs2 templates auto-set |ref=harv. They took the decision that they took in response to that problem. I was not there then, the environment was entirely different then, cs1|2 were in their infancy then. At this time I am not willing to say that they were wrong. For nine years thousands of editors have apparently been content with that long-ago decision.
The CITEREF id is an imperfect identifier because is isn't guaranteed to be unique to a rendered citation (this is why others in the related discussion complain about the lower-case-alpha-character-as-disambiguator). I am most concerned that were we to auto-set |ref=harv in all cs1|2 templates there will be some large quantity of articles where {{harv}} and {{sfn}} templates link to other than their intended targets. Untangling that kind of a mess is akin to figuring out which of several <ref name="same name" /> tags belongs to which definition when you have <ref name="same name">some sort of reference content</ref> but you also have <ref name="same name">reference content of a different sort</ref>. Broken reference links and pissed-off editors are, I think, to be expected.
—Trappist the monk (talk) 00:02, 27 July 2018 (UTC)
This is a chicken and egg problem and a law of laziness. CS2 supports |ref=harv natively, so people who wants to use {{harv}} are told to use CS2 so they don't have to deal with CS1's non-native support. Whatever clashes this would create can easily be found via scripts and html inspectors, but those would be rare, or there would be other problems to fix on top of that. If they used CS1, nothing changes. If they used CS2, then either then don't use {{harv}} or already have |ref=harv enabled. Or they use a mix of CS1 and CS2 that needs to be fixed anyway. Headbomb {t · c · p · b} 00:09, 27 July 2018 (UTC)
I don't see a reason why not to turn |ref=harv on by default for CS1 since it is on for CS2. Imzadi 1979 → 02:46, 27 July 2018 (UTC)
Hmm. I find this argument (Trappist's) to be a compelling one: there is an existing consensus, that has stood for nine(ish) years without a lot of complaints, and the proposed change is imperfect in a technical sense. This is definitely cause for taking the time to consider the issue thoroughly before making any kind of change. So, in that light, let me perpetrate some "reasoning out loud" here…
The main problem being brought up in the original discussion, and part of the reason adduced for hesitation on that implementation here, is the likelyhood of having multiple citations with identical author—date values, which will generate duplicate |ref= values, which in turn will end up as the same id attributes on more than one HTML element. The relevant standards (HTML 3.2 through 4.01, and the DOM spec post-HTML5) all require that the value of id be unique within a document, and the net result is that validation tools like the W3C Markup Validation Service will flag the duplicate id's as errors. Actual implementations (i.e. web browsers; i.e. Chrome, IE, Opera, Safari, JAWS, etc.) will silently ignore the error (and always have), and use the first found id (in DOM order) as the target.
This is because duplicate id attributes are a matter of syntax and is well-contained: it affects nothing but those elements who have duplicate id attributes (unlike unclosed elements, mismatched quote marks, improperly nesting or overlapping elements, etc., which does have run-on effects on document parsing) and it is an error in non-rendered syntax elements, so it is not visible to users. That is: the existence of duplicate id attributes cause no problems in themselves, unless you are specifically using those specific id attributes for something further.
However, those issues are mere symptoms. The actual problem we have exists at the semantic level: we have short citations that are ambigious because they cite author—date and we have multiple works by author on date. You can't (easily) catch this problem with software tools (they're much better at syntax then semantics), but it is the actual root cause problem. This is a problem that requires manual effort to resolve, and as a side effect will resolve the minor syntax errors that were at issue in the original discussion. That is, I conclude that I disagree with the premise of the original discussion: it focussed on the symptom (and an essentially benign one) rather then the underlying problem, and the underlying problem is not affected either way by the proposed remedy.
As a corollary, though I assert we should not worry overmuch about generating duplicate id attributes, they do of course need to be fixed when they occur. But this is best done through tracking categories, bot flagging, and concerted cleanup efforts. The status quo hides the problem by not generating those id attributes.
The other major side of this is impact and failure modes. All changes carry some measure of risk, so let's say we turned on |ref=harv as default today. What's going to happen from the perspective of readers and editors and visible article content (I've addressed the technical syntax issues above)? ← Not a rhetorical question; do please answer it!
  • Articles using {{citation}} and articles using explicit |mode=cs2 are unaffected.
  • Articles using full cites inline gain id / link targets, but since they're not used the article is unaffected.
  • Short cites using {{sfn}} (et al) that were dangling (pointing at full references that do not have |ref= set) will start working.
  • Full cites with an explicit |ref= set are unaffected (including |ref=none).
  • In articles (using {{sfn}} and full cites in a bibliography and the bibliography has full cites with a mix of those with |ref= set and those without it and there is one such pair (with/without) that has identical author—date information and the one without |ref= occurs before the one with it) the existing link from {{sfn}} to the author—date will begin pointing at the wrong full cite.
    • The {{sfn}} short cites in that article intended for the other full cite (the one without |ref=) were already pointing at the wrong full cite.
    • The absence of the link target for one of the full cites is here hiding a problem: the short cites are ambigious and only happenstance gives the (false) appearance that they are working.
  • Citation pairs with {{sfn}} and full references without |ref= can now be checked by user scripts (like HarvErrors) and problems flagged.
  • Full references without |ref= for which there is no {{sfn}} pointing at it (i.e. possibly an uncited work that should be removed) can be detected and flagged by user scripts (like HarvErrors).
  • Other failures from the change, or from the status quo?
Based on this I see no significant negative impact except in edge cases; that do not simply make visible an existing problem; and that should not be fixed in any case. So my conclusion, unless someone comes up with other issues, is that we definitely should turn on |ref=harv by default. But we should perhaps actively solicit a bot to flag articles where duplicate IDs occur with a tracking category so that they can be fixed (perhaps WP Check Wikipedia might be a good venue for that?). --Xover (talk) 07:56, 27 July 2018 (UTC)
Regarding tracking, I have filed phab:T200517. --Izno (talk) 14:00, 27 July 2018 (UTC)
You are right. That is a lot of words.
  • yes, {{citation}} templates and templates using |mode=cs2 are not affected
  • yes, articles without short cites are not affected
  • perhaps; we cannot know with certainty that previously unconnected short cites will magically connect correctly because we cannot know why the unconnected short cites were not already properly connected
  • yes, cs1|2 templates with |ref= set to anything but harv are not affected
  • there is no requirement that short cites must link only to cs1|2 templates that are part of a 'bibliography' so any 'new' ID that exists anywhere within the rendered page and that matches a previously existing ID may become the incorrect target of an exiting short cite
    • not really, because after auto-setting |ref=harv, nothing has been clarified; all of the same-ID short cites will point to one cs1|2 template; some of those short cites will link to the correct cs1|2 template, the others will not; we will have exchanged one variant of the problem for another variant of the problem
    • yes, ID ambiguity is the fundamental flaw
  • it is not wrong to place cs1|2 templates anywhere within an article; cs1|2 templates are commonly used to list an author's published works and may or may not include full bibliographic detail but because of their position in the article may become incorrect short cite targets if we auto-set |ref=harv
The status quo hides the problem by not generating those id attributes. If the fundamental problem here is the ambiguity of CITEREF IDs, it seems to me that the status quo doesn't 'hide' the problem (nor does it solve the problem) but is doesn't exacerbate the problem by creating more ambiguous targets.
Based on this I see no significant negative impact except in edge cases; that do not simply make visible an existing problem; and that should not be fixed in any case. What? Why should the problem not be fixed? Does your sentence read as you intended it to read?
—Trappist the monk (talk) 14:31, 27 July 2018 (UTC)
That is a lot of words. My apologies. As I wrote: thinking out loud. Does your sentence read as you intended it to read? Sorry. Too many negative clauses. I meant that the errors should be fixed regardless, and that the proposed change would simply make them visible/detectable and thus more likely to be fixed.
However, despite (or because of?) my wordy explication, it seems I've failed to communicate my point correctly. The underlying problem here is not the ambiguity of CITEREF IDs (that's a mere implementation detail). Rather, the real problem is that John Smith wrote two journal articles in 1984 and I've failed to distinguish them. The reason I've failed to do so may be that I've looked at the article's title or other bibliographic detail and thought that was sufficient, or it may be that I added one and another editor added the other, or… Whatever the reason, I've created the problem that when I use parenthetical referencing, citing (Smith 1984, p. 32) is ambigious.
When I change the article to use {{cite journal}} and {{sfn}} this problem becomes detectable because the CITEREF ID generation algorithm is working within the bounds of that referencing style: it exactly replicates the problem that was already there. In other words, generating duplicate CITEREF IDs is correct from a technical point of view; it's failing to distinguish between Smith's two 1984 articles (1984a and 1984b) that is the problem, and it's caused by the human editors failing to correctly implement the author—date (wetware) algorithm.
However, I hadn't considered non-reference uses of cs1|2 templates, possibly because I routinely use |ref=none for these for other reasons (see thread above). It's certainly a complicating factor, and a significant negative impact of the proposed change. Not sure I'm persuaded that it's a big enough negative impact that it makes the total tradeoff untenable, but it certainly adds weight to that side of the equation. --Xover (talk) 15:53, 27 July 2018 (UTC)
Addendum: On further reflection I am convinced that the impact of non-reference uses of cs1|2 templates if |ref=harv was made the default is sufficiently large that this question isn't something we should decide with a local consensus here. (That's in addition to the other negative effects that I consider relatively lesser drawbacks.) It affects a large number of articles, and in a way that is likely to lead to "angry editors with pitchforks" scenarios. I am still of the opinion that |ref=harv should be the default, but I now think getting there will take a community-wide RfC; and one that is properly cast so that it will stick, with a minimum of drama, and as few hurt feelings as possible. But throwing a proposal here and drafting a site-wide RfC are different ballgames, and I wouldn't want to embark on the latter solo. Are the other editors who participated in this thread interested / willing to help out drafting an RfC for this? Trappist the monk: would you still be opposed to this if it has support from a community-wide RfC? I mean, this change would definitely have associated breakage, and an RfC wouldn't prevent that (it just prevents the pitchforks when stuff does break). I consider the breakage a reasonable tradeoff and the associated (manual, mostly) cleanup surmountable, but it's a point on which one may easily disagree, and I wouldn't want an RfC to act as a "trump card" in that discussion. --Xover (talk) 06:40, 28 July 2018 (UTC)
[W]ould you still be opposed to this if it has support from a community-wide RfC? You ask that question as if I have some sort of veto power here. My position with regard to any RFC outcome is irrelevant. So what if I oppose or support, when the community have spoken, the community have spoken.
—Trappist the monk (talk) 19:32, 28 July 2018 (UTC)
Well, no, but I'm asking whether the existence of a supportive outcome from a community RfC would affect your position on the change? I got the impression, perhaps erroneously, that your opposition was in part founded on the risk of a "angry editors with pitchforks" scenario occurring. If the change is backed by RfC, that would significantly alleviate this concern, and so perhaps also your stance on the proposed change? --Xover (talk) 06:21, 29 July 2018 (UTC)
My comment about pissed-off editors is simply idle speculation about a possible future and is not an armature upon which I hang my opinion. Broken reference links is the point of that sentence. I am more concerned about this change suddenly breaking some number of articles that worked correctly before the change because we will have exchanged one form of 'broken' for another form of 'broken' and all because CITEREF IDs cannot be automagically truly unique to each cs1|2 template and its paired short refs.
—Trappist the monk (talk) 11:16, 29 July 2018 (UTC)
  • Support. I started out using CS2, did a lot of Harvard referencing, and didn't have to think about ref=harv. I loaded the HarvErrors script a long time ago. Overtime, I've edited many articles using the more common CS1 templates, and now I use CS1 by default, but I don't take any side on the commas or periods debate. Even articles using CS1 templates will use plain text Harvard referencing, so I"ve inserted many {{harvnb}} and |ref=harv to make the linkage. And I've played the 1981abc game. I've also turned off the implicit CS2 |ref=harv in many Further reading sections. So it's been use |harv= one way for CS1 and the opposite way for CS2.
    I support Izno's analysis. If an article has ambiguous references, it would be good to discover that problem and fix it. It will have a down side for me because the HarvErrors script will raise more red flags, but that might be a good thing in the long run. Glrx (talk) 19:35, 27 July 2018 (UTC)
  • Support. Just to be clear. ♦ J. Johnson (JJ) (talk) 22:43, 5 August 2018 (UTC)
  • Support. An instance of this discussion just broke out independently in Template talk:Cite EB1911 ({{Cite EB1911}} uses CS1) because Gog the Mild noticed that its interaction with {{sfn}} results in the second click not jumping to the citation itself. You'd have to add "ref=harv" to a use of this template, unlike {{EB1911}} which provides a default (that template is intended to attribute a verbatim from a PD source and uses CS1). I guess it would help if we had noted that in the template's doc. PBS pointed out that this {{PD source}} versus {{Cite PD source}} pattern has many instances, and they would all have to be changed for consistency, which is why I like this top-down approach. Anyway, a few more points:
    • I dispute that editors "have...been content" with this (mis)behavior of dangling sfn-type links (which, again, require two clicks to show the error, which itself is a mere absence of behavior). It's a subtle thing to test when you edit a page, easily missed.
    • Instances of same-author, same-year are quite rare, and in the cases I have seen editors have already handled it with the a/b suffix.
    • I don't see the problem with generating an unused citation link target. It isn't an error not to link to it. The {{Cite source}} family are often used in ==Further reading== or ==External links==.
    • Just to take the {{Cite EB1911}} template as an example, there are about 430 articles that should have ref=harv and don't, probably because editors (OK, mostly me) were never aware of the issue. I'd be happy for a top-down fix, because spending time on such a subtle error is about #2,319 on my priority list. David Brooks (talk) 16:58, 15 August 2018 (UTC)
  • @David Brooks Just a note on your bullet point "**I don't see..." If you place "importScript('User:Ucucha/HarvErrors.js');" into "user:/DavidBrooks/common.js file" you will see the errors. -- PBS (talk) 10:55, 16 August 2018 (UTC)
  • I Support this change, (indeed I would support changing all the common CS1 templates to {{citation|mode=CS1}}). So given the snow here I suggest that someone implements a RfC in an appropriate place (eg Wikipedia:Village pump (proposals)). If it is done please inform the people who have taken part in this debate. As an aside: if this proposal is implemented a bot script will need to be run to add ref=none to all instances where CS1 templates are used in in ==Further reading== or ==External links== to remove cases of false positives. Also depending on how wrapper scripts around CS1 templates are written this may have an affect on some scripts. -- PBS (talk) 10:55, 16 August 2018 (UTC)
    @PBS: Unless I misunderstand the intent, I think you suggest adding ref=none only if there are no actual references (sfn, harv) elsewhere in the body. Also, the section name is a semantic issue, not syntactic. I think past editors have been pretty promiscuous about where to stick these full citation templates. There are also some nonstandard section titles that should probably also be addressed. David Brooks (talk) 13:24, 16 August 2018 (UTC)
    "Further reading" and "External links" are specifically for non-referenced sources (WP:APPENDIX). As to other section names that is another issue. But, if this change is made, then I think that for all CS1 templates in those two sections the parameter "ref=none" ought to be added, whether or not there are currently any {{harv}} type templates in the article. -- PBS (talk) 13:36, 16 August 2018 (UTC)
    Spamming |ref=none serves pretty much no purpose (does |ref=none even have a use?) and would never fly. And it runs pretty much counter to why we'd want |ref=harv to be default in the first place. Headbomb {t · c · p · b} 13:29, 16 August 2018 (UTC)
    On the one hand, editors who have incorporated User:Ucucha/HarvErrors.js into their javascript page in order to make citation errors more obvious might want to have full citations that are not intended to be the target of short citations to not show a warning; I haven't tested to see if |ref=none will accomplish this.
    On the other hand, if there were a full citation in the "Further reading section" with |ref=none, and an editor decided to move it to the "Works cited" section and cite it, it wouldn't work until the editor realized the |ref=none needed to be removed. Jc3s5h (talk) 13:38, 16 August 2018 (UTC)
    I use this all the time with {{Citation}} in "Further reading" sections. If this change is made to the template core, and if the parameter is not added, then there are possibilities of breaking citation links in articles becomes a possibility. For example if a book in a "Further reading" section happens to have the same author and date as one used in the "References" section ... . -- PBS (talk) 13:48, 16 August 2018 (UTC)
    Editor PBS wrote: I would support changing all the common CS1 templates to {{citation|mode=CS1}}. Explain that please?
    —Trappist the monk (talk) 13:56, 16 August 2018 (UTC)
    I fail to see why we have {{cite book}} {{cite web}} etc when we could simply have one wrapper around all the same core used for all such citations, and we already have {{citation}} to do that job. AFAICT apart from the handling of ref=harv (which this section is discussing changing) the only difference is the formatting between the parameters which is handled by the mode parameter. eg:
    • (1a cite book) Smith, Fred. The Blue Book. London: Cheesecake.
    • (2a citation with mode=CS1) Smith, Fred. The Blue Book. London: Cheesecake.
    • (1b cite book with mode=CS2) Smith, Fred, The Blue Book, London: Cheesecake
    • (2b citation) Smith, Fred, The Blue Book, London: Cheesecake
    Having only one template would simplify the documentation and also simplify it conceptually for editors new to using citation templates. For example deciding if a book on the internet should be referenced by using {{cite book}} or {{cite web}} would go away, as they would just select the parameters that best describes the citation (as is done now with {{citation}}). -PBS (talk) 18:41, 16 August 2018 (UTC)
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)
This is going off topic so I have moved my answer down to a more appropriate section. -- PBS (talk)

CSS for citation templates

Latest comment: 6 years ago31 comments4 people in discussion

Template styles has been enabled on en.wiki so I've begun experimenting with it. I have created Module:Citation/CS1/style.css and added rules that apply the access indicator icons in place to the normal external link icon. The distinct advantage to this is that the wrapping issue that has plagued us (url on one line and the icon on the next) is solved.

Cite book comparison
Wikitext {{cite book|pmc=12345|title=Title|url-access=subscription|url=//example.com}}
Live Title. PMC 12345.
Sandbox Title. PMC 12345.
Cite book comparison
Wikitext {{cite book|pmc=12345|title=Title|url-access=limited|url=//example.com}}
Live Title. PMC 12345.
Sandbox Title. PMC 12345.

We should think about this and spend some time getting the rules right. I don't know how many other wikis have template styles. If only a few have it, then perhaps we should not use this here because these modules are used on a lot of other wikis.

—Trappist the monk (talk) 12:13, 20 July 2018 (UTC)

Apparently, TemplateStyles will be enabled on all wikis 9 August 2018; see phab:T199909.
—Trappist the monk (talk) 11:35, 21 July 2018 (UTC)
I saw the edits made to the module sandboxes today. I have some light feedback:
  1. In keeping with the naming convention at WP:TemplateStyles, recommend moving the page to use "styles.css" rather than "style.css". (Aside: I have submitted a task for allowing creation of stylesheets in the module namespace.)
  2. Load the CSS using Lua rather than adding a TemplateStyles invocation at each page. Per my discussion with Anomie on phabricator, that would require frame:extensionTag. There is some other code there that Anomie provided for a helper function.
--Izno (talk) 16:13, 1 August 2018 (UTC)
/style.css moved to Module:Citation/CS1/styles.css. We should probably create a sandbox version of that file so that we can play around with it and not disturb the citation rendering in article space. Alas, we can't follow the convention of Module:Citation/CS1/styles.css/sandbox so I propose that we should use Module:Citation/CS1/styles-sandbox.css.
I have implemented the frame:extensionTag in Module:Citation/CS1/sandbox and removed the <templatestyles /> tag from {{cite book/new}}.
—Trappist the monk (talk) 12:16, 3 August 2018 (UTC)
@Trappist the monk: There is a current discussion regarding sandbox naming at WT:TemplateStyles#Sandbox naming convention to which you may be interested in contributing. --Izno (talk) 12:21, 3 August 2018 (UTC)
I have modified Module:Citation/CS1/sandbox so that is uses Module:Citation/CS1/sandbox/styles.css, newly created. Module:Citation/CS1/styles.css is now protected in keeping with the protection level of the live cs1|2 modules (even though, at the moment, the live modules do not use templatestyles).
—Trappist the monk (talk) 16:18, 17 August 2018 (UTC)

Headbomb hides the a.external arrow

  Moved from User talk:Trappist the monk § CSS for citation templates

Could you have a way of having those icons display if we suppress external link icons normally? I can only see them if I disable this. Maybe this could be done via a different class, like external-access, or some other way that would let us suppress the normal external link icons, but keep the access ones? Headbomb {t · c · p · b} 00:23, 20 July 2018 (UTC)

I am not a css expert so I don't know if what you want can be accomplished. I don't even know if the rules in Module:Citation/CS1/style.css are properly formed. As I understand it, rules marked by !important override any other applicable rules regardless of when those rules occur.
The rendered html for the title link of this template:
{{cite book/new |title=Title |url=//example.com |url-access=subscription}} → Title.
looks like this:
<span class="cs1_lock_subscription"><a rel="nofollow" class="external text" href="//example.com"><i>Title</i></a></span>
Your rule:
a.external { background:none !important; padding:0 !important;}
unconditionally overrides the template style css because !important. I don't know where class external is defined (it isn't in MediaWiki:Common.css) perhaps it is possible to override something there?
When your rule is enabled, do you see the pdf icon here: [1]
—Trappist the monk (talk) 12:13, 20 July 2018 (UTC)
Nope, PDF icon is hidden, and that's the way I like it, since it's redundant with (PDF) that's automatically appended. Headbomb {t · c · p · b} 20:22, 20 July 2018 (UTC)
Avoid the use of important. It basically defeats the purpose of Template Styles. As for external, that class is applied by MediaWiki core to any external link (when not provided for by an inter-site link like [[example:example]]--I am not sure what class those links get). --Izno (talk) 14:51, 20 July 2018 (UTC)
Indeed, !important is a cop-out - usually it's better to increase the specificity of the selector. Imagine if all rules used !important and you needed to override one - there are no levels of importance, nothing that is treated as "more important than !important". --Redrose64 🌹 (talk) 18:39, 20 July 2018 (UTC)
Well !important works. You're free to suggest alternatives that also work, because I have no idea what "increasing the specificity" means, or would look like. Headbomb {t · c · p · b} 20:22, 20 July 2018 (UTC)
In a rule like 
a.external {
  background: none !important;
  padding: 0 !important;
}
the part before the opening brace is the selector. A selector like a matches all <a>...</a> elements; a selector like .external matches all elements belonging to the class external, and the selector a.external matches all <a>...</a> elements belonging to the class external. Since this third one matches on two conditions which must both succeed, this is more specific than either of the selectors a or .external used alone. See Calculating a selector's specificity. The !important annotation artificially boosts the specificity in a manner that is difficult to override. See Cascading. --Redrose64 🌹 (talk) 22:41, 20 July 2018 (UTC)
Seems like this is pretty much what [2] this rule was. Specifically matching a.external. What I'm asking for here is a way of not matching the access locks, while still matching the other useless icons. If !important gets in the way of that, it's easy enough to remove I suppose, but that still leaves the problem of matching (or not matching) the locks. 03:12, 21 July 2018 (UTC)
Perhaps someone with a better grasp of the intricacies of css can see how this sort of works and can tweak it so that it does: 
a.external:not(.cs1_lock_free) {
  background: none;
/*  padding: 0;
*/
}
For me, and my browser, the above hid the normal external link icon but showed all of the access icons; I would have expected only the green access icon to be displayed. Without padding: 0;, there is a significant gap between the link and the next text character where the default external link icon would be were it displayed. If background: none; why the space? If I uncommented padding: 0;, the lock icons moved left to overlap the text. Text adjacent to the blank external link icon also moved left to fill the blank space so that the text renders nicely.
—Trappist the monk (talk) 12:21, 21 July 2018 (UTC)
@Trappist the monk: Wouldn't ".cs1_lock_free" only apply to the free lock? If not, that should probably be renamed to .cs1_access_locks or just cs1_locks. Headbomb {t · c · p · b} 14:21, 21 July 2018 (UTC)
The 
a.external:not(.cs1_lock_free)
was an experiment. I expected that the only visible icon would be the green; all others I expected to be hidden. That expectation was not met because, for me, only the normal external link icon was hidden; subscription and free icons were displayed.
—Trappist the monk (talk) 14:52, 21 July 2018 (UTC)
@Izno: any feedback on how to hide the regular external link icons without hiding the access locks icons? Headbomb {t · c · p · b} 16:17, 1 August 2018 (UTC)
I do not. I haven't given the problem any significant thought though. I don't really understand who it is you are trying to do this thing for or why that should matter to all of us. :) --Izno (talk) 16:39, 1 August 2018 (UTC)
@Izno: What I'm trying to do is hide the pointless external link icons, like you have at the end of [3], but keep the external link access locks icons that would be added by this. This hides/enables ALL external link icons, both the pointless ones and the useful access locks. What I want a way of hiding only the pointless ones / displaying only the useful ones. Headbomb {t · c · p · b} 17:02, 1 August 2018 (UTC)
I'm actually a bit surprised that the above CSS works to hide any of these since the class cs1_lock_free is not on the a element but on a surrounding span. So in that regard, I think the CSS is wrong. You probably want span:not(.cs1_lock_free)/* add other not selectors here by appending more :not(selector) */ a.external {background: none;}. Give that a try. --Izno (talk) 14:01, 5 August 2018 (UTC)

@Izno: This doesn't do a thing. Headbomb {t · c · p · b} 17:22, 5 August 2018 (UTC)

Actually, it hides the red+blue/grey locks (green is visible) of the sandbox. So that's sort of progress, but in the opposite direction. I want those displayed (red+grey+green), and the rest hidden. Headbomb {t · c · p · b} 17:27, 5 August 2018 (UTC)
Read and review the CSS comment I left. See MDN where they chain the nots together. --Izno (talk) 17:59, 5 August 2018 (UTC)
I can chain the nots, but that still won't hide the things I want it to hide: the external link icons that are not the access locks. Headbomb {t · c · p · b} 18:26, 5 August 2018 (UTC)
I can't see another way to deal with it then besides duplicating the locks CSS into your skin's CSS page of choice and placing it after the line which removes the arrows. --Izno (talk) 18:53, 5 August 2018 (UTC)
Alternatively, I don't see why you can't use Ttm's CSS directly. Even if it doesn't work as he expects, that will also take care of the issue if the behavior in your browser is the same as his. --Izno (talk) 18:55, 5 August 2018 (UTC)
Because that TtM's CSS doesn't hide the external links icons. Headbomb {t · c · p · b} 19:01, 5 August 2018 (UTC)
Switching gears, how about some sort of CSS logic that instead of being written with a sort of "if not (css_class), hide icons" logic, it would be written with a "hide all icons, but if (css_class), display them" logic instead?
Alternatively, I'd be fine with "duplicating the locks CSS into your skin's CSS page of choice and placing it after the line which removes the arrows.", but I don't know how to do that.Headbomb {t · c · p · b} 19:03, 5 August 2018 (UTC)
You just copy and paste the block of CSS for the locks into your CSS page anywhere after the bit of CSS that sets a.external {display:none}. This way, of course, you can also change the image of interest. --Izno (talk) 19:55, 5 August 2018 (UTC)
"copy and paste the block of CSS for the locks into your CSS page anywhere after the bit of CSS that sets a.external {display:none}", again, I don't know how to do that. I don't even know where to find that CSS, it's a LUA mess.Headbomb {t · c · p · b} 19:58, 5 August 2018 (UTC)
The styles page should probably be added to the main documentation; you can find it at Module:Citation/CS1/styles.css. --Izno (talk) 20:32, 5 August 2018 (UTC)

Page parameter of {{cite speech}}

Latest comment: 6 years ago2 comments2 people in discussion

While the page parameter is referenced in the documentation for {{cite speech}}, it doesn't appear to be working for me.

Milbank, Alison (2017). Subversive Orthodoxy (docx) (Speech). Liverpool: Diocese of Liverpool. Retrieved 14 June 2018.

{{cite speech |last=Milbank |first=Alison |author-link=Alison Milbank |year=2017 |title=Subversive Orthodoxy |url=http://www.liverpool.anglican.org/userfiles/files/Events/2017/Subversive%20Orthodoxy%20-%20Alison%20Milbank.docx |format=docx |location=Liverpool |publisher=Diocese of Liverpool |page=2 |access-date=14 June 2018}}

Am I doing something wrong here? 142.160.89.97 (talk) 06:25, 18 August 2018 (UTC)

I don't think so. In November 2015 we limited the use of |volume=, |issue=, and |page(s)=; {{cite speech}} supports none of those though there apparently wasn't any discussion as to the why of that particular decision (discussion). I suspect that when I made the initial post and created the first version of the table I specified no pages for {{cite speech}} because normally a speech would be published as part of some larger enclosing work. A requirement of WP:RS is that there must be an archived copy of something cited (Wikipedia:PUBLISHED) so one cannot attend a speech presentation and then cite that presentation because the words have disappeared in the instant that they were spoken and cannot be recovered. But, you can cite the proceedings of the event if the speech is included in those proceedings. The proceedings will likely have page numbers. No one contradicted that guess so it remains as I first specified it.
For this "Subversive Orthodoxy", apparently a talk given at a conference, two options appear to me. One is to switch to {{cite conference}} perhaps like this:
{{cite conference |last=Milbank |first=Alison |author-link=Alison Milbank |date=20 May 2017 |title=Subversive Orthodoxy |url=http://www.liverpool.anglican.org/userfiles/files/Events/2017/Subversive%20Orthodoxy%20-%20Alison%20Milbank.docx |format=DOCX |conference=Ken Leech Conference |location=Liverpool |publisher=Diocese of Liverpool |page=2 |access-date=14 June 2018}}
Milbank, Alison (20 May 2017). Subversive Orthodoxy (DOCX). Ken Leech Conference. Liverpool: Diocese of Liverpool. p. 2. Retrieved 14 June 2018.
The other, because the talk is hosted on a website, is to use {{cite web}}:
{{cite web |last=Milbank |first=Alison |author-link=Alison Milbank |year=2017 |title=Subversive Orthodoxy |url=http://www.liverpool.anglican.org/userfiles/files/Events/2017/Subversive%20Orthodoxy%20-%20Alison%20Milbank.docx |format=DOCX |website=The Diocese of Liverpool |page=2 |access-date=14 June 2018}}
Milbank, Alison (2017). "Subversive Orthodoxy" (DOCX). The Diocese of Liverpool. p. 2. Retrieved 14 June 2018.
Pedantically, one might argue that {{cite web}} is the best choice here because a speech is a minor work (MOS:ITALIC and MOS:NOITALIC).
—Trappist the monk (talk) 11:24, 18 August 2018 (UTC)

Suppression of periods at end of title

Latest comment: 6 years ago9 comments3 people in discussion

Some templates like {{Tropicos}} and {{ThePlantList}}, which create citations of database entries on species of plants, offer the option of including the taxonomic authority, which is appended after the taxon name in the |title= parameter of the citation template. Taxonomic authority abbreviations often end in a period. The module seems to remove the period in some cases, but not in others:

  1. {{Tropicos|18401640|Allium canadense|L.}}
  2. {{ThePlantList |id=gcc-86968 |taxon=Ageratina riparia |authority=(Regel) R.M.King & H.Rob.}}
    ↓
  3. "Allium canadense L.". Tropicos. Missouri Botanical Garden. (title displays as "Allium canadense L": period removed)
  4. "Ageratina riparia (Regel) R.M.King & H.Rob.". The Global Compositae Checklist (GCC) – via The Plant List. Note that this website has been superseded by World Flora Online (title displays as "Ageratina riparia (Regel) R.M.King & H.Rob.": period not removed)

More examples can be found by searching hastemplate:"ThePlantList" insource:"authority" insource:/\{\{ *ThePlantList *\|[^\}]+?authority *= *[^|}]+?\.[|}]/ (or replace ThePlantList with Tropicos).

This is an error: the abbreviation for Carl Linnaeus is L., not L. This will sometimes prevent someone from finding the name of the taxonomic authority (if they get it from the citation and not from the taxobox), because the author search on IPNI.org seems to pay attention to periods (though not to letter case). It returns Carl Linnaeus when I search for the standard form L. or l., but returns no results for L or l.

Given that the module has some way of deciding whether to retain the period at the end, is there a way to make it always retain the period, so that taxonomic authority abbreviations are displayed correctly? — Eru·tuon 22:05, 18 August 2018 (UTC)

Duplicate terminal characters. Argh! It is a headache. In the vast majority of cases, the content of |title= should not have terminal punctuation and for those vast majority of cases the module gets it right:
{{cite web |title=Title with terminal punctuation: no dot inside the quote marks. |url=//example.com |website=Website}}
"Title with terminal punctuation: no dot inside the quote marks". Website.
When I came to this project, the mechanisms for assembling citation fragments and handling of duplicate terminal punctuation already existed in more-or-less the form that it has today; the primary difference is that I attempted to document what it does. And then added it to the list of stuff to revise.
It is no simple task and perhaps it isn't possible to fully answer the issue. Generally, terminal punctuation should be removed but in the case of a title that ends with an initialism or initial, the text 'U.S.A.' or Linnaeus' 'L.', for example, that title should retain its terminal punctuation; a generic title should not. I'm not sure how to distinguish an authority like '(Regel) R.M.King & H.Rob.' which should retain its terminal punctuation from a complex title that shouldn't have terminal punctuation.
The obvious short-term (or perhaps longer) fix that I suspect you have already noodled out is to do text replacement in {{Tropicos}} and {{ThePlantList}} where authorities ending with '.' are passed into cs1|2 with the '.' replaced with the equivalent html entity: &#46; which gives:
{{Tropicos|18401640|Allium canadense|L&#46;}}
"Allium canadense L.". Tropicos. Missouri Botanical Garden.
{{ThePlantList |id=gcc-86968 |taxon=Ageratina riparia |authority=(Regel) R.M.King & H.Rob&#46;}}
"Ageratina riparia (Regel) R.M.King & H.Rob.". The Global Compositae Checklist (GCC) – via The Plant List. Note that this website has been superseded by World Flora Online
—Trappist the monk (talk) 00:09, 19 August 2018 (UTC)
HTML hex codes are bad. A templated solution would be better. {{period}} would be better. Headbomb {t · c · p · b} 01:06, 19 August 2018 (UTC)
I figure there's no way to make the module more sophisticated about what is and what isn't an abbreviation, or at least it would be a headache because |title= can contain so many different things. What would be more useful here is a parameter to tell the module to retain the period at the end of the title (if present). Not sure what it would be called: |retain-final-period=yes? That would then be turned on in {{Tropicos}} and {{ThePlantList}}, because there a final period in the title can only be from the |authority= parameter (if the input is correct).
I did consider replacing the final period with the HTML character reference and it works, but it seems like a hack and it is probably a better practice to be explicit to the template about what the actual goal is. — Eru·tuon 07:35, 19 August 2018 (UTC)
You will have noticed that there is a bug in the terminal character removal code which I have fixed:
Cite web comparison
Wikitext {{cite web|publisher=[[Missouri Botanical Garden]]|title=''Allium canadense'' L.|url=http://www.tropicos.org/Name/18401640?projectid=0|website=[[Tropicos]]}}
Live "Allium canadense L." Tropicos. Missouri Botanical Garden.
Sandbox "Allium canadense L." Tropicos. Missouri Botanical Garden.
Cite web comparison
Wikitext {{cite web|title=''Ageratina riparia'' (Regel) R.M.King & H.Rob.|url=http://www.theplantlist.org/tpl1.1/record/gcc-86968|via=[[The Plant List]]|website=The Global Compositae Checklist (GCC)}}
Live "Ageratina riparia (Regel) R.M.King & H.Rob". The Global Compositae Checklist (GCC) – via The Plant List.
Sandbox "Ageratina riparia (Regel) R.M.King & H.Rob". The Global Compositae Checklist (GCC) – via The Plant List.
Perhaps you are right about some sort of something to retain terminal punctuation, I would suggest that might be the doubled parentheses as is done for |vauthors= which, for that parameter, means: use-this-name-as-written. {{ThePlantList}}, for example would create:
|title=((''Ageratina riparia'' (Regel) R.M.King & H.Rob.))
meaning use-this-title-as-written:
Cite web comparison
Wikitext {{cite web|title=((''Ageratina riparia'' (Regel) R.M.King & H.Rob.))|url=http://www.theplantlist.org/tpl1.1/record/gcc-86968|via=[[The Plant List]]|website=The Global Compositae Checklist (GCC)}}
Live "Ageratina riparia (Regel) R.M.King & H.Rob." The Global Compositae Checklist (GCC) – via The Plant List.
Sandbox "Ageratina riparia (Regel) R.M.King & H.Rob." The Global Compositae Checklist (GCC) – via The Plant List.
—Trappist the monk (talk) 10:21, 19 August 2018 (UTC)
@Trappist the monk: You added the 'space-letter-dot' pattern exception, but you should also add 'dot-letter-dot' exception if you can. This would catch cases like 'U.S.A.' or "Review of Agents of S.H.I.E.L.D.". Headbomb {t · c · p · b} 12:33, 19 August 2018 (UTC)
That exception is already in place is it not?
Cite web comparison
Wikitext {{cite web|title=Review of Agents of S.H.I.E.L.D.|url=//example.com|website=Website}}
Live "Review of Agents of S.H.I.E.L.D." Website.
Sandbox "Review of Agents of S.H.I.E.L.D." Website.
Can you provide an example where the exception is not handled properly?
—Trappist the monk (talk) 12:43, 19 August 2018 (UTC)
Ah well if it's already in place, nevermind. Just didn't see it in the code. Headbomb {t · c · p · b} 12:48, 19 August 2018 (UTC)
@Trappist the monk: I like the double-parenthesis solution. It's a good idea not to add another parameter for such a simple thing. — Eru·tuon 18:55, 20 August 2018 (UTC)

TemplateStyles (any?) templates in CS1

Latest comment: 6 years ago7 comments3 people in discussion

I think I already know the answer, but I'll throw the question out there.

"C++ reference for basic_string". Cppreference.com. Retrieved 11 January 2011. {{cite web}}: templatestyles stripmarker in |title= at position 19 (help)

^ has the template {{mono}} in it, which I converted to use TemplateStyles. The module complains because it gets a stripmarker that it doesn't know what to do with (but which does seem to successfully style the text basic_string?). This matters in the context of a title, because titles are put into COINS.

Similarly, the edit I made to {{paragraph break}} to use TemplateStyles was reverted. That was used almost exclusively in the quote parameter, which is not put into COINS.

There may be other templates in the wild inside of CS1 templates where the use of TemplateStyles will cause some grief without a change to this module.

Some questions:

  1. Is the use of {{mono}} here okay? What about the use of {{paragraph break}} in a quote parameter? Elsewhere?
  2. What about x random template being used which might be upgraded to use TemplateStyles?
  3. If the answer to those questions is yes, what do we need to do to a) display the style intended by the template while b) providing good metadata to COINS as appropriate?

--Izno (talk) 02:06, 17 August 2018 (UTC)

Neither of {{mono}} and {{paragraph break}} should be used in |title= or other parameters that are made part of the COinS metadata because the the template expansion includes html that is not part of the cited work's title. In most cases, cs1|2 does not / cannot know that a title contains an expanded template. I can imagine that templates might be coded so that, under certain conditions, the template might expand only to plain text in which case its use in cs1|2 templates would be acceptable. There are certain templates that will render a plain url when an appropriate parameter is set, for example.
I have never thought that |quote= was a good idea – if something is worth quoting, quote it in the article and then cite the quotation. My desire to see that parameter go away is a forlorn cause. cs1|2 inspects the content of every parameter used in the template for stripmarkers and other invisible characters. One might argue that it would be proper to exempt |quote= from some of this inspection.
—Trappist the monk (talk) 09:52, 17 August 2018 (UTC)
I would so argue at least for |quote=, that the module should allow at least the TemplateStyles strip marker to pass through unimpeded (and unwarned about), regardless of other invisible characters. (I think expanding an exemption like that to other parameters would definitely need some careful thought, in case the COINS specification is ever updated, we would want to avoid some future pain and agony.) --Izno (talk) 13:44, 17 August 2018 (UTC)
I've tweaked the module sandbox to allow template styles in |quote= more to prove the concept than as an endorsement of that philosophy. I briefly also exempted |quote= from the \n test so that silliness like {{paragraph break}} is unnecessary but have undone that because implied <p>...</p> doesn't belong inside <cite>...</cite> – the <div>...</div> tags added by {{paragraph break}} don't belong inside <cite>...</cite> either. I have to wonder though: should we really be supporting elaborate formatting in a parameter that ought to be a simple quotation from the source (if it should exist at all)? If special formatting is necessary, then quote it, format it, and cite it in the article.
Cite book comparison
Wikitext {{cite book|quote=<span class="monospaced">mono-spaced text</span> not mono-spaced text|title=title}}
Live title. mono-spaced text not mono-spaced text
Sandbox title. mono-spaced text not mono-spaced text
—Trappist the monk (talk) 15:03, 17 August 2018 (UTC)
I have no opinion on the original question, but I want to point out that there may be uses of |quote= that have nothing to do with content. I have used it previously to quote the source's metadata (such as items from the edition page, or from publisher annotations, or from back matter etc.) that clarify citation items pertinent to wikitext. Such "quotes" cannot be really be used with in-source parameters. In the absence of |note= or any other parameter covering such publication metadata, |quote= can be a ready alternative. I am quoting the source; just not its content. 65.88.88.75 (talk) 18:43, 18 August 2018 (UTC)
We might also want to think about allowing templatestyles stipmarkers in |id= (not included in the COinS metadata because it can be a free-form mishmash of who-knows-what). This morning I updated {{Catalog lookup link}} to use Module:Catalog lookup link which supports the cs1|2 access icons using Module:Citation/CS1/styles.css. That template is wrapped by several identifier templates. I tweaked {{ERIC}} which is sometimes used in |id= which led me to discover this issue so I'll be reverting all of those updates until we take a decision about |id=.
—Trappist the monk (talk) 15:08, 18 August 2018 (UTC)
|id= added:
Cite journal comparison
Wikitext {{cite journal|id=[[Education Resources Information Center|ERIC]] <span class="id-lock-free" title="Freely accessible">[https://eric.ed.gov/?id=12345 12345]</span>|title=Title}}
Live "Title". ERIC 12345. {{cite journal}}: Cite journal requires |journal= (help)
Sandbox "Title". ERIC 12345. {{cite journal}}: Cite journal requires |journal= (help)
—Trappist the monk (talk) 13:07, 21 August 2018 (UTC)

Restrict |class= to new arxiv identifiers

Latest comment: 6 years ago3 comments2 people in discussion

These

should throw an error message. |class= should only be used with |arxiv=YYMM.NNNN / |arxiv=YYMM.NNNNN formats per Template:Cite arXiv#Usage. Headbomb {t · c · p · b} 20:06, 24 July 2018 (UTC)

@Trappist the monk: this should be fairly easy to implement. If |arxiv=/|eprint= doesn't start with a number, |class= should be empty. Headbomb {t · c · p · b} 15:19, 1 August 2018 (UTC)
where |class= is allowed:
{{cite arXiv/new |last=Leinster |first=Tom |date=2007 |title=The Euler characteristic of a category as the sum of a divergent series |eprint=0707.0835 |class=math.CT}}
Leinster, Tom (2007). "The Euler characteristic of a category as the sum of a divergent series". arXiv:0707.0835 [math.CT].
where |class= not allowed and not present:
{{cite arxiv/new |arxiv=hep-ph/9409360 |last1=Choi |first1=J |title=Sphalerons in the Standard Model with a real Higgs singlet |year=1994}}
Choi, J (1994). "Sphalerons in the Standard Model with a real Higgs singlet". arXiv:hep-ph/9409360.
where |class= not allowed but present:
{{cite arxiv/new |arxiv=hep-ph/9409360 |last1=Choi |first1=J |title=Sphalerons in the Standard Model with a real Higgs singlet |year=1994 |class=hep-ph}}
Choi, J (1994). "Sphalerons in the Standard Model with a real Higgs singlet". arXiv:hep-ph/9409360. {{cite arXiv}}: |class= ignored (help)
where |class= not allowed but present + malformed |arxiv=:
{{cite arxiv/new |arxiv=hep-ph/9409360r |last1=Choi |first1=J |title=Sphalerons in the Standard Model with a real Higgs singlet |year=1994 |class=hep-ph}}
Choi, J (1994). "Sphalerons in the Standard Model with a real Higgs singlet". arXiv:hep-ph/9409360r. {{cite arXiv}}: |class= ignored (help); Check |arxiv= value (help)
—Trappist the monk (talk) 17:25, 21 August 2018 (UTC)

Category:Pages using duplicate arguments in template calls

Latest comment: 6 years ago5 comments3 people in discussion

Why are user pages added to this category when the cite template is inside <nowiki> tags? · · · Peter (Southwood) (talk): 07:55, 21 August 2018 (UTC)

Module:Citation/CS1 does not add pages to Category:Pages using duplicate arguments in template calls; that is done by some process of MediaWiki. Templates and modules cannot know when they are called with duplicate parameters – the last one of the duplicates (reading left-to-right) is the only one of the duplicates that templates and modules receive from MediaWiki. Also, cs1|2 templates wrapped in <nowiki>...</nowiki> tags are not 'executed' so there is no need to detect duplicate parameters.
—Trappist the monk (talk) 09:11, 21 August 2018 (UTC)
Pbsouthwood, when you have a question like this, it is always helpful to link to a page where we can see an example of the behavior you are describing. – Jonesey95 (talk) 18:33, 21 August 2018 (UTC)
Jonesey95, I have not seen it myself, I am drawing the conclusion from what I have been told by another user who gave the reason for editing a template on one of my user subpages as a response to the template having duplicate arguments and therefore getting the page added to the mentioned category. The template was inside nowiki tags. I was assuming that I was given correct information. The edit where the template was changed is here.
The explanation given by Trappist the monk makes sense to me, which is why I asked. Based on that, there would have been no cause to edit the templates for the reason given. Perhaps the person was mistaken, but then how did my userpage get listed?
@Wikid77:, perhaps you could explain the situation leading to your edit better.
category:Pages using duplicate arguments in template calls does exist, so something is populating it. · · · Peter (Southwood) (talk): 19:23, 21 August 2018 (UTC)
Knight's Forensic Pathology has two |edition= parameters; that template was not inside <nowiki>...</nowiki> tags.
—Trappist the monk (talk) 19:45, 21 August 2018 (UTC)

Add ResearchGate identifer

Latest comment: 6 years ago6 comments3 people in discussion

insource:/researchgate\.net/ reveals ~13000 hits here. We should have a new parameter

or perhaps

Headbomb {t · c · p · b} 13:38, 11 August 2018 (UTC)

My impression is ResearchGate versions of articles are pre-press, or even pre-submission. Do we really want to add IDs for such articles, since they are essentially self-published? Jc3s5h (talk) 15:13, 11 August 2018 (UTC)
Most I ran into are published or postprint versions of some kind. But either way, it would be better to have |researchgate=268149509 than |url=https://www.researchgate.net/publication/268149509_The_First_Americans_A_Review_of_the_Evidence_for_the_Late-Pleistocene_Peopling_of_the_Americas. It's possible to have preprints on RG, but that's no different than supporting |citeseerx=/|ssrn= which can also be any of pre-, post-, and published versions. Headbomb {t · c · p · b} 15:34, 11 August 2018 (UTC)
Articles at Research Gate are "self-published" in the sense that they are uploaded by the authors, but often those are copies of articles published by elsewhere. They are by no means limited to pre-press, and I have found RG to be a valuable source of materials not otherwise readily available. At the very least it provides a list of an author's work, which can be extremely useful in tracking down other articles, and even other authors. Such a link would be very useful.
However, there are other sites with a similar mission and function (such as Orcid), which are equally valuable. A question for us to consider is: should we have (1) individual link parameters for each? Or (2) a generic link parameter?
A generic parameter could rely on specific templates to generate a suitable identifier/link, collecting them immediately after an author's name. Or perhaps have just one icon with a pop-up list of the different links. Either way, the cs1 code would not be encumbered with the details, and possible maintenance needs, of the actual links, and would not require further work to additional identifiers. ♦ J. Johnson (JJ) (talk) 18:50, 18 August 2018 (UTC)
We have a generic ID parameter in |id=, but that's bad for widespread identifiers because we lose the benefits of a dedicated parameter. And ORCID is pointless clutter that only belongs in WikiData. Headbomb {t · c · p · b} 19:38, 18 August 2018 (UTC)
How is a link to an ORCID page any more "pointless clutter" than a link to ResearchGate? ♦ J. Johnson (JJ) (talk) 00:59, 25 August 2018 (UTC)

PMID error messages

Latest comment: 6 years ago3 comments3 people in discussion

PMID errors are reproted when the PMID > 30000000, but PMIDs greater than this are now being issued; see https://www.ncbi.nlm.nih.gov/pubmed/30069046. The code generating the error message should be increased to a greater threshold.

Martin (Smith609 – Talk) 06:32, 27 August 2018 (UTC)

The limit is currently set at 32000000. Where did you see a pmid error? The example pmid that you provided works correctly:
{{cite journal |title=Title |journal=Journal |pmid=30069046}}
"Title". Journal. PMID 30069046.
—Trappist the monk (talk) 09:02, 27 August 2018 (UTC)
The error was at Lung. It was caused by a nbsp after the PMID, fixed by Headbomb. › Mortee talk 18:41, 27 August 2018 (UTC)

Template fix

Latest comment: 6 years ago2 comments2 people in discussion

Hi, I came across the following use of this template, in which the date 16 February 2017 renders incorrectly:

"מורן אטיאס קיבלה אזרחות אמריקנית". 16 February 2017. Retrieved 28 August 2018.

The issue was fixed when I added the |language= parameter (for Hebrew):

"מורן אטיאס קיבלה אזרחות אמריקנית" (in Hebrew). 16 February 2017. Retrieved 28 August 2018.

Can someone troubleshoot this? Thanks!— TAnthonyTalk 16:45, 28 August 2018 (UTC)

The template is not broken. Hebrew is a right to left language; the digits 0–9 are promiscuous – they will be treated by browsers as right-to-left or left-to-right according to the browser's own direction algorithm. Your fix 'worked' because the rendered language annotation is English which is left-to-right so the date digits are also treated as left-to-right. Using |script-title= in place of |title= for right-to-left text along with |language= is the preferred solution because |script-title= causes Module:Citation/CS1 to wrap the right-to-left text in appropriate html markup (here |language= omitted):
{{cite web |url=http://www.mako.co.il/entertainment-celebs/local-2017/Article-48adbc8d3464a51006.htm |script-title=he:מורן אטיאס קיבלה אזרחות אמריקנית |date=16 February 2017 |access-date=28 August 2018}}
<bdi lang="he" >מורן אטיאס קיבלה אזרחות אמריקנית</bdi>
מורן אטיאס קיבלה אזרחות אמריקנית. 16 February 2017. Retrieved 28 August 2018.
—Trappist the monk (talk) 17:32, 28 August 2018 (UTC)

New parameter that does nothing bot-deny

Latest comment: 6 years ago35 comments5 people in discussion

Let's add a new parameter |bot-deny=, which can then be used by bots to skip specific citations. The values would be |bot-deny=yes or |bot-deny=BotName1, Botname2, .... All the template would need to do here is simply ignore the parameter entirely and not throw an error message. Headbomb {t · c · p · b} 15:43, 21 August 2018 (UTC)

We currently have {{cbignore}} which is used by IABot and WaybackMedic (and anyone else) to communicate messages to the bots, mainly to tell it to ignore the archive link only. It would still be needed for non-CS1|2 cases (and it needs to be renamed - "cb" is the old name of Cyberbot II before it was renamed IABot). A general bot ignore is not insignificant given the large installed base of bots that need to be updated and verified working each time a bot is made. Also how does it impact tools and libraries like AWB, PWB, Perl and Python libraries etc. which claim to be exclusion compliant. And how to deal with non-CS1|2 citations. A lot of work and coordination has to be done with stake holders. It might also be a good idea to get wider community input from one of the vpumps that this is even an idea people want to see done, possible areas of trouble, ideas for implementation. -- GreenC 16:34, 21 August 2018 (UTC)
Well, we can document that it's up to individual bots to support it, and we could list those bots that support it here (perhaps in that case we could have a white-list of bots than can be denied by this method). The idea is that citation-focused bots could be denied specific citations, rather than entire pages. I know it would be immensely useful for User:Citation bot, and I'd certainly make use of it in User:Bibcode bot. I'd love for User:CitationCleanerBot/User:JCW-CleanerBot to fully support it, but they're AWB-based bots, and that would be tricky to do. It'd be pretty easy to treat it as a {{Bots|deny}} alternative though. Headbomb {t · c · p · b} 16:42, 21 August 2018 (UTC)
Posted a notice at WP:BOTN and pinged a couple of people for feedback. Headbomb {t · c · p · b} 16:48, 21 August 2018 (UTC)
Do you think it's best to have two systems (CS1|2 argument + template for non-CS1|2) or one system (template for all)? Do you think it's best that the template be new, or modify one of the existing ones like {{bots}} or {{cbignore}}? Looking at the bigger picture of "bots blocked from editing citations", rather than "bots blocked from editing CS1|2 citations only". -- GreenC 17:01, 21 August 2018 (UTC)
Granularity is good when it comes to bots where it makes sense to have that granularity. If a page has 200 citations, and a bot screws up 1 of them because of some cornercase stuff, should we deny the bot from operating on the other 199 where it's handling them just fine? Or let it handle the 199 citations it can, and deny it the one it can't. {{Bots}} is the hammer, it'd still work, but |bots-deny= would be the scalpel. Headbomb {t · c · p · b} 17:13, 21 August 2018 (UTC)
Of course, there is the problem that it's not only CS1|2 but all citations that you want to scalpal, correct? If so, do you think it's best to have two systems (CS1|2 argument + template for non-CS1|2) or one system (template for all)? Do you think it's best that the template be new, or modify one of the existing ones like {{bots}} or {{cbignore}}? -- GreenC 17:25, 21 August 2018 (UTC)
If you ask the same question, you'll have the same answer. Headbomb {t · c · p · b} 17:26, 21 August 2018 (UTC)
Your not answering the questions, something else I never said. -- GreenC 17:31, 21 August 2018 (UTC)
A template can be used to 'scalpel' individual citations regardless if it's a CS1|2 or free-form citation (that is, all types of citations not just CS1|2). This template scalpel can be created by modifying the existing {{bots}} or {{cbignore}}. -- GreenC 17:37, 21 August 2018 (UTC)
Modifying {{bots}} will not yield any scalpel-like effect, since it applies to the whole page. Likewise, {{cbignore}} will cannot be associated with specific citations for a vast class of bots because it's outside the template that's to be left untouched. Headbomb {t · c · p · b} 19:47, 21 August 2018 (UTC)
That's a good point, outside the template requires a bot capable of parsing whole refs. Thank you for answering the question why it would make sense to have two systems (bot-deny and block templates like cbignore), it is a valid reason to consider. {{bots}} could be modified, so it either applies to the whole page or individual cites, using argument options to control its meaning as one idea - or create a new template just for the scalpel'ing. You are right bots that do whole ref parsing are less common, but they tend to edit more articles than those limited to CS1|2 templates because of the larger pool of articles, and are long-term bots vs. periodic AWB runs (I'm estimating). -- GreenC 21:33, 21 August 2018 (UTC)

I'm leaning toward opposing the whole concept. In general, an editor should be able to write a citation using any consistent style, using the template documentation if it uses one of the families of citation templates, or any well-know style manual if that's what the article has adopted. The editor shouldn't have to warn some bot (that hasn't been written at the time the citation is composed) about some somewhat unusual situation in the template, such as alphanumeric page numbers, Julian calendar publication dates, a nom de plume for an author, or whatever. The existence of the proposed template or parameter could be used as an excuse by one of those bot authors who likes to over-automate everything that the burden of preventing false positives should be on article editors, who should mark anything that would cause a false positive. I say no; if a bot author can't prevent excessive false positives with citations as they have been historically been written, scrap the bot.

(I know that technically, a consistent ad-hoc style is allowed that is unique to the article, but that's impractical because no one knows how to add a source of a different kind than those already in the article.) Jc3s5h (talk) 20:07, 21 August 2018 (UTC)

This has got nothing to do with citation styles. Bots just can't deal with GIGO scenarios very well. User:Bibcode bot isn't worth scrapping because ADSABS contains a 0.03% error rate (or whatever it is). Likewise User:Citation bot isn't worth scrapping because of a cornercase GIGO behaviour. Going, well "if you fuck up one of the citations, you shouldn't touch any of them" is cutting off your nose to spite your face. Headbomb {t · c · p · b} 20:17, 21 August 2018 (UTC)
I have actually seen what you are describing, where a bug is so intractable or "rare" it's easy to tell the occasional complaint to solve it with a block as the solution. This is both good and bad, it gives the bot operator time to solve it, but also creates a moral hazard that it never gets resolved. On the flip side, there will be editors who automatically add bot blocks to every citation they make thus creating another kind of hazard. I don't think either of things would be very common though, and should weigh lightly in the con column. -- GreenC 21:33, 21 August 2018 (UTC)
No one's going around adding {{Bots}} to a slew of articles just because, so I don't see why it'd be an issue here. Headbomb {t · c · p · b} 22:45, 21 August 2018 (UTC)
With {{Bots}} there are 5700 transclusions it is somewhat manageable with high visibility and importance. But with inline bot-blocks there is lower visibility and lower importance (a single cite). There could be 10s or 100s of thousands instances. The blocks may have good intentions today, but create problems in the future when important new bots are made. Maybe if inline blocks specify a bot(s), not be given a blank check for all current and future bots forever. -- GreenC 01:46, 22 August 2018 (UTC)
I agree with Jc3s5h: it should not be incumbent on the editors to deflect mis-behaving bots. And I have no qualms about foregoing some dubious or marginal benefit if a bot keeps running across my toes. ♦ J. Johnson (JJ) (talk) 22:49, 21 August 2018 (UTC)
Well by doing so, you would, as an editor, be deflecting a misbehaving bot. But realistically, this is something bot ops would themselves add to the citation most of the time, since they know when it's a GIGO case, and when it's a bug than can (and should) be fixed. Headbomb {t · c · p · b} 23:02, 21 August 2018 (UTC)
"[T]his is something bot ops would themselves add to the citation most of the time"? I find that to be a novel concept. But in that mode, how about a "bot-notice" (or "poison-pill" or "exceptional-case" or some such) parameter, carrying a 7 or 8 digit id which the bot can lookup in its own list of cases requiring special handling? ♦ J. Johnson (JJ) (talk) 01:38, 22 August 2018 (UTC)
Don't really understand what you're proposing here. This is a simple solution, that would work for several bots relatively easily. |bot-deny=DeniedBot. Bot coders can add |bot-deny=DeniedBot<!--Error Code: 12345678--> if they want to have such an error id. Headbomb {t · c · p · b} 02:57, 22 August 2018 (UTC)
It's very simple. Instead of leaving it solely to the editors to wave-off bots that might screw-up some special case, with only the sole option of "deny! go away! don't do anything here!", we could have a parameter that is a warning, including an id or code for this particular special case. If the bot does does not recognize this particular case, it should leave it alone. On the other hand, the bot could have a list of cases that need to be handled in a special way, and (presuming that the special handling is acceptable) it may proceed. It's not a total denial/exclusion, but a warning of a special case, where proceeding is conditional and even negotiable. ♦ J. Johnson (JJ) (talk) 20:47, 22 August 2018 (UTC)
Which is, you know, exactly what |bot-deny= would do. Headbomb {t · c · p · b} 20:59, 22 August 2018 (UTC)
No, not the same. In my understanding "deny" means denied: don't mess with this, absolutely, period. What I am suggesting is more of a caution sign, a notice of a special case, where you (presumably the bot) may proceed if you recognize the special case and the specific handling expected. It could also be taken as a warning: if you have been here before, and got slapped down, it would be best to skip this case unless and until some concurrence on proper handling as been reached. This is a conditional "denied, unless ...." Big difference. ♦ J. Johnson (JJ) (talk) 00:52, 25 August 2018 (UTC)
What would be the use of that? And by what logic would a bot be able to determine that it didn't fuck it up? That's the point of deny. It tells the bot don't touch that one, for whatever reason. Headbomb {t · c · p · b} 01:05, 25 August 2018 (UTC)
A bot doesn't "know" anything. But if I have some special case which your bot screws up, then you and I would have a discussion about how to deal with it. If we come up with a mutally satisfactory way of handling that special case you add that "logic" to your bot's inventory of such responses. Or you just flag it as "leave it alone". The point is that I don't (in this hypothetical case) necessarily mind if you and your bot try to do a right thing in a special case. And I won't mind if you come back and do what is right for that case. The point is that it can identify special cases, and allows for a more nuanced response than "absolutely allow" or "absolutely deny" without the editors having to go head-to-head in every case. ♦ J. Johnson (JJ) (talk) 20:12, 26 August 2018 (UTC)
Which is...exactly the point of |bot-deny=. Headbomb {t · c · p · b} 20:26, 26 August 2018 (UTC)
You just said (comment before last): "That's the point of deny. It tells the bot don't touch that one, for whatever reason" (emphasis added).(ith which I even concur.) What I am suggesting is something else – call it |bot-caution= or |special-case= or whatever – that warns of a possible problem if you proceed. As I said before: not the same. ♦ J. Johnson (JJ) (talk) 20:52, 27 August 2018 (UTC)
"Warns of a problem if you proceed?" And how would a bot handle that? Not proceed because there's a problem if they do, or proceed, and cause a problem, which defeats the purpose of the so-called warning in the first place. Headbomb {t · c · p · b} 21:20, 27 August 2018 (UTC)
Have I not already explained this to you? As I said before: the first time your bot screws with my citation we have a discussion, and either a) we come up with a better response, or b) not. Subsequently, when your bot encounters this warning it can either a) proceed with the mutally acceptable response, or b) it leave this case alone. Why is this so hard to understand? Do you not understand the nature of a conditional response? ♦ J. Johnson (JJ) (talk) 01:54, 28 August 2018 (UTC)
"a) proceed with the mutally acceptable response" = the bot is fixed and no longer needs to be denied, or "b) it leave this case alone." = the bot is denied. Why is that so hard to understand. Headbomb {t · c · p · b} 02:05, 28 August 2018 (UTC)
I'd like to think you finally understand, but I sense you that you do not. Anyway, this isn't going anywhere; I'm out of here. ♦ J. Johnson (JJ) (talk) 23:13, 28 August 2018 (UTC)
  • I honestly don't see much of a point in the new parameter. I'm certainly not going to add that support to IABot, after having just rewritten the engine that handles processing cite templates. There exists a template, I created, that other bots can use too, {{cbignore}}, aka Cite Bot Ignore. The documentation describes how to use it, and any opted-in bot can look for it to know that the cite should be ignored entirely. IABot does this already.—CYBERPOWER (Around) 02:40, 22 August 2018 (UTC)
Ahh so that's what CB means. -- GreenC 19:24, 22 August 2018 (UTC)

Actually, you can ignore this whole thing. Putting a comment in most template names will prevent bots from messing with them entirely. Headbomb {t · c · p · b} 03:31, 29 August 2018 (UTC)

Latest comment: 6 years ago5 comments5 people in discussion

Can someone please define what makes a work or publisher "relevant" or "notable" (implying having an article isn't enough) enough to wikilink? I'm asking for both news and books, specifically. Is it the relevance of the source to the article subject, or the relevance of the source itself, or something else? Also, it says that the work or publisher "may be wikilinked if relevant", but is it actually preferred? I notice that a lot of the given examples do not have wikilinks. --Gius85 (talk) 21:46, 30 August 2018 (UTC)

In general wikilinking to the publisher's en.wiki article does not assist a reader in locating a copy of a source published by that publisher. There may be an argument for wikilinking to a lesser-known publisher's article as a way of establishing the reliability of the cited source.
—Trappist the monk (talk) 10:26, 31 August 2018 (UTC)
I think most publishers and publications are ipso facto notable enough to link (and having an article—vs. a redlink—makes it even more so); and I routinely wikilink publishers and journal/newspaper/magazine names because, IMO, it provides crucial context for assessing the source's reliability etc., and because it helps disambiguate which of several possibly ambigious names are meant. I've run across a few publishers with names (usually of imprints) that are either identical or sufficiently close to be confusing, and for publication names this is relatively common. It also helps link an imprint name with the actual publisher. To pick the first (not the best) example I can think of: Tor Books is an imprint of Tom Doherty Associates, which is owned by St. Martin's Press, which is a subsidiary of Macmillan Publishers, which is ultimately owned by Holtzbrinck Publishing Group (and through weird merger arrangements, I think their level in the hierarchy has switched at least once: Macmillan used to be on top once). That's not uncommon in publishing, and any and all levels of that chain may have / don't have wikipedia articles, be the relevant imprint, own the relevant imprint, be the relevant imprint for some but not all editions, and so forth. If I can reliably determine the actual publisher for a work (mostly for books) I will usually wikilink it. I also tend to completely ignore WP:OVERLINK in "References" or "Publications" sections (mostly because I consider the links metadata, but those sections aren't really prose and I don't think the guidance in OVERLINK covers the situation well). And, of course, in all these points I suspect consensus—to the degree it exists at such specificity—is against me. So… my advice is to do as I do, but you might get less disagreements if you do the exact opposite. Not that I've had complaints directly, but I've seen discussions touch on it elsewhere. --Xover (talk) 10:49, 31 August 2018 (UTC)
I'm in the Xover camp here. Wikilinking journals and publishers is usually more good than bad. The only place I wouldn't do it systematically is in lists of works (e.g. Bibliography), where I would only link the first instance per WP:OVERLINK, but in <ref></ref>, I pretty much Wikilink everything. WP:REDLINKS here are good. Headbomb {t · c · p · b} 11:55, 31 August 2018 (UTC)
Though I don't personally link everything, I am sympathetic to the above, and can point to a separate benefit: reference tooltips should probably each have their own links so that the reader can immediate investigate or understand the above. --Izno (talk) 16:58, 31 August 2018 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Help_talk:Citation_Style_1/Archive_46&oldid=1086690765"