Help talk:Citation Style 1/Archive 57

Url-access requires mouseover/hover for visibility
When the recent change was made deprecating the subscription and registration parameters, it was also a change from visible text to something that requires mouseover/or hover. Compare, for example, reference 1 in Anthochaera and reference 2 in "Girl (short story)". The first one, with the deprecated parameter, makes it clear at a glance that a subscription is required. The second one, however, requires interaction before one can see that a (paid) subscription is required.

This violates accessibility standards in the Manual of Style. Could it be changed back to visible text? BlackcurrantTea (talk) 06:57, 16 May 2019 (UTC)
 * The access icons and the deprecation of subscription and registration are the result of this rfc and this rfc. I suspect another rfc will be required in order to overturn one or both of the previous rfcs along with some sort of plan and / or design criteria for a replacement system.
 * —Trappist the monk (talk) 10:43, 16 May 2019 (UTC)
 * The access icons are invisible to me with images turned off (usual when I'm editing and often when I'm reading). Thanks for the links to the rfcs. I'll read through them when I have some more time to concentrate on that sort of thing. BlackcurrantTea (talk) 11:00, 16 May 2019 (UTC)
 * When turning off images, does your browser make any use of the alternate text on the images that it removes? − Pintoch (talk) 08:53, 19 May 2019 (UTC)
 * The images are implemented in CSS, so there is no alt text (one of the failings of background-image). --Izno (talk) 13:08, 19 May 2019 (UTC)

removing apostrophe markup in periodical and publisher parameters
In this conversation participants noted that editors sometimes add apostrophe markup to periodical and publisher parameters so that the values assigned to those parameter display in the way that the editors believe that they should display. In that conversation I noted that using the wiki markup in this way contaminates the metadata. I also noted that this use of wiki markup is another form of the gaming mentioned at this predecessor discussion.

So, I have tweaked the sandbox to strip apostrophe markup from the periodical and publisher parameters.

Before I made this change, I had not looked at how pervasiveness of these practices. Simple insource searches timeout:
 * publisher ~34k results
 * website ~2.6k
 * newspaper ~3k
 * journal ~1.2k
 * work ~8.3k (did not timeout)

The question now becomes: is this misuse of wiki markup sufficient to rise to the level of an error message or shall they be 'hidden' in maintenance cats?

—Trappist the monk (talk) 12:46, 7 May 2019 (UTC)
 * The use of italic markup in these parameters is pervasive. I suggest at least a maintenance category, though I'd be happy to have an error as well. --Izno (talk) 13:14, 7 May 2019 (UTC)
 * Can the error be restricted to new instances? If the error appears when someone is editing a section already using such a reference it will be confusing.  Jts1882 &#124; talk 13:45, 7 May 2019 (UTC)
 * No. Templates don't work that way; the error is an error whether it is old or it is new.  I would hope, yeah, I know, a forlorn hope, that when editors do see preexisting errors in a section that they are working on, they will take a few seconds and fix them.
 * —Trappist the monk (talk) 15:12, 7 May 2019 (UTC)

The vast majority of items in the search results above are errors, so we should probably have a way to find and fix them (aside from insource searches, which are not always reliable). That said, because I am a pain in the neck engineer type who always looks both ways before crossing a one-way street, I always try to find counterexamples and false positives. Here's one I came across in the wild (at Hainan):


 * Original url commented out so as not to cause horizontal scrolling

Another, from Insulin:

The sandbox version italicizes the Chinese journal title, which is undesirable, and I don't know of a way to prevent it. Maybe I am failing to read the documentation well enough. [A note on sample sizes: I found three such examples in the first page of 20 search results.] – Jonesey95 (talk) 17:24, 7 May 2019 (UTC)
 * Yeah, problematic. I suppose that the preferred answer is for editors to use English when available; see the English-language version of your first example which has a 'how to cite this article' blurb at the bottom.  I know, doesn't fix the problem.  Which means ...
 * script-&lt;periodical> and trans-&lt;periodical>? It may be that that these are the only way to have our cake, consume it, and retain our sylph-like forms.
 * —Trappist the monk (talk) 18:17, 7 May 2019 (UTC)
 * That's the solution I was thinking of as well, but I wanted to give the example some space to breathe before jumping to a proposed answer. (mmm, cake!) – Jonesey95 (talk) 18:37, 7 May 2019 (UTC)
 * That's the solution I was thinking of as well, but I wanted to give the example some space to breathe before jumping to a proposed answer. (mmm, cake!) – Jonesey95 (talk) 18:37, 7 May 2019 (UTC)

People are doing this in many cases because CS1|2 is not properly able to render output correctly so they are working around it. For example every style guideline on planet Earth says never capitalize CNN in citations. But that is exactly what CS1|2 does when placed in the work field. So people are trying to work around CS1|2's behavior. I would suggest determine what the problems are, why people are doing this, and fix that. For example not every value in work should be italicized. Until then covering over the symptoms is stop gap. -- Green  C  19:20, 7 May 2019 (UTC)
 * So much hyperbole. cs1|2 is a general purpose tool that does a fair job of correctly rendering most of what editors want to cite.  It will never be perfect for all citations all of the time.
 * I wonder if this change, supported by script-&lt;periodical> for non-Latin languages might prompt a definitive decision with regard to what should and what should not be italicized, which, as you will recall from WP:CITESTYLE, are allowed to have their own style. cs1|2, like it or not, intended or not, is and has its own style, part of which is to italicize the value assigned to the periodical parameters.  This has been true since very early in their development:
 * 7 December 2004
 * 4 February 2005
 * 15 November 2005
 * 8 March 2006 (this one also italicized publisher)
 * It occurs to me that much of what editors are squabbling about in the other conversation is three-letter acronyms: CNN, PBS, BBC, NPR. All uppercase letters.  That can be detected and extended to station call letters: WGBH-TV.  So, there is a possible automatic 'fix' (if a fix is required) that is simple to implement if it comes to that.
 * —Trappist the monk (talk) 22:52, 7 May 2019 (UTC)
 * There's also Rotten Tomatoes, Metacritic, and Box Office Mojo. Personally, I'm OK with italics. —BarrelProof (talk) 23:31, 7 May 2019 (UTC)
 * The lack of flexibility in italicizing the work value is the source of disputes like above, and also why the problem this thread is trying to resolve exists (in many cases). Checking for all-caps is one solution but imperfect there can be others as noted by BarrelProof. Three other solutions off-hand: turn off italics like no; a properties flag like WGBH-TV $i; or an optional work argument such as WGBH-TV. All of these are clumsy I admit but the first step is consider ideas. With WGBH-TV $i this mechanism could be applied to any argument optionally modifying default italics $i, bold $b, underline $u, etc.. as users wish. The last word would rarely begin with a '$' so it would be a safe metacharacter. -- Green  C  01:03, 8 May 2019 (UTC)
 * Further ideas, similar to '$i' use a template called where "csc" means "CS1|2 control", "itoff" means "italics off". The template does nothing but acts as a flag that CS1|2 detects and acts on eg.  . This has the advantage of staying within the existing template system so the "$i" method doesn't inject garbage data into existing bots and tools that don't expect meta-characters of that form. --  Green  C  01:13, 8 May 2019 (UTC)
 * Yeah, those are possibilities. cs1|2 does have some parameters that support the use-this-parameter-value-as-written   markup (issue, pages, title, vauthors, veditors).  Perhaps that should be applied to the periodical parameters so:
 * ((CNN))
 * would render as: CNN
 * Without that markup, apostrophe markup would be removed so:
 * CNN
 * would render as: CNN
 * —Trappist the monk (talk) 11:40, 8 May 2019 (UTC) 13:25, 8 May 2019 (UTC) 15:09, 8 May 2019 (UTC)
 * Oh that solution is fine. In fact rather than converting all cases of CNN to CNN, convert to ((CNN)) under the assumption this is what the editor originally intended anyway. For CNN we can't automatically determine if they meant to link to a website (italics) or a TV channel (non-italic). I can work on a document somewhere about when to use this method and why, for the periodical parameter, and link to it in the main docs. Further debates about it can take place there and CS1|2 is off the hook since it will be flexible to support italics or not. -- Green  C  17:09, 8 May 2019 (UTC)
 * I don't think that the module should attempt to guess editors' intent with respect to this rather heated debate. The module and the templates should simply do as we tell them to do.  We have told the module from its inception (and the templates from their early days) that periodical parameter values shall be italicized and that should not change.
 * Long ago, I wondered in these talk pages if the module should require the periodical templates to have a periodical parameter. At the time I was thinking about  but this could/should apply to all periodical templates.  Recalling this lead me to have a re-look at the COinS metadata support at Module talk:Citation/CS1/COinS.  You will see from that table (at  ) that publisher is only supported for book objects.  This means that the metadata for all of those periodical templates that use publisher to avoid italics are missing that important piece of information.  We cannot prevent the use of publisher in periodical templates (there was an RFC) but we can, and I think should, emit an error message when a periodical template does not have some form of periodical parameter.
 * While I was thinking about this, I looked at the parameters that are aliases of publisher. These are:
 * distributor – listed in Module:Citation/CS1/Configuration but not in Module:Citation/CS1/Whitelist; don't know what it was (if it was) used for; I propose to delete it
 * institution – shown in examples at but not otherwise documented
 * newsgroup – for
 * If we continue with the process we will:
 * ignore italic wiki markup in the &lt;periodical> parameters and publisher; the module shall emit an appropriate error message when it does this
 * add support for use-this-parameter-value-as-written  markup in &lt;periodical> parameters (publisher is never italicized)
 * add support for script-&lt;periodical> and trans-&lt;periodical>
 * add error message for periodical templates without periodical parameter (and attendant category and help text)
 * remove distributor
 * —Trappist the monk (talk) 12:56, 9 May 2019 (UTC)
 * Regarding #2 above, I still have not seen any examples where it is valid for &lt;periodical> values to ever *not* have italics. I could be misunderstanding this (and I agree this isn't something that needs to be demonstrated to my satisfaction, I'm just one voice on this), but if we allow  markup there we should also have valid example(s) of when to use it – especially with regard to anything that has url populated. Otherwise we are just kicking the can down the road and potentially causing the churning that  is correctly worried about above.One possible compromise (that may be non-trivial to implement, in which case please just ignore this suggestion) would be to disallow the   exception in &lt;periodical> anytime url has a value. - Paul T [//en.wikipedia.org/w/index.php?title=User_talk:Psantora&action=edit +]/C 17:35, 9 May 2019 (UTC)
 * My primary interest in this is to make sure that the metadata are not corrupted and are present when they should be. So if it takes use-this-parameter-value-as-written   to get editors to use the &lt;periodical> parameters instead of publisher because they want, for whatever reason, to have the periodical name in upright font, then at least the name gets into the metadata as it should do.
 * Why is the presence or absence of url important or distinguishing? url is required for  so you must be talking about the periodical parameters in, ,.
 * —Trappist the monk (talk) 17:57, 9 May 2019 (UTC)
 * The presence or absence of url is important because it forces the distinction of being a published work and therefore italicized as a result of the current guidelines. Per above: When any website is cited as a work, it is cited as a published work (by definition), not as a shop or server or corporate entity or whatever else the same name might refer to outside of a citation-to-published-work context, where it gets italicized.Here is a quote of the relevant guideline from MOS:ITALICTITLE:When any website is cited as a source, it is necessarily being treated as a publication, and in that context takes italics. Our citation templates do this automatically; do not abuse unrelated citation parameters, such as publisher, to evade italicization of online work titles in source citations. - Paul T [//en.wikipedia.org/w/index.php?title=User_talk:Psantora&action=edit +]/C 18:32, 9 May 2019 (UTC)
 * Whether a URL is present or not probably has nothing to do with any of this. The ITALICTITLE footnote quoted above doesn't imply otherwise. If you're citing an online source, it should have a URL so people can find it. It doesn't make it less or more of a published work. The fact that it can be cited at WP is what makes it a published work, since we do not cite anything other than published works (even our very limited citations of primary sources like one of Trump's tweets is citing it as a very short work that has been published). It's not the URL parameter that makes something a published work, it's the citation to it at all as a source. Simple proof: Many e-books have identical pagination to hardcopy versions (being either scans of the latter, or PDF/Kindle/whatever exports of the same desktop publishing files use to generate the latter). Per WP:SAYWHEREYOUGOTIT, if you are reading the hardcopy, your citation needs no URL, while if you're reading a Web-provided PDF version at the author's website, it does need one to indicate you are reading that electronically-distributed version even if the rest of the parameters are the same. If you are reading an Amazon-exclusive e-book version via its app for that stuff, then your cite should use some other method of indicating this (e.g. a specific ASIN in the id parameter or whatever). They are not italicized differently, and none of the three versions is less or more of a published work.  — SMcCandlish ☏ ¢ 😼  01:07, 10 May 2019 (UTC)
 * By that logic, the  markup should never be used (or work) in &lt;periodical>. I'm on board with that and have been arguing that point at length. However, allowing the   markup in &lt;periodical> is being pitched as a compromise so as to make sure that the metadata are not corrupted and are present when they should be in cases where the editor want[s], for whatever reason, to have the periodical name in upright font. My point is, if we are going to allow for that compromise, it should never work when a URL is present. - Paul T [//en.wikipedia.org/w/index.php?title=User_talk:Psantora&action=edit +]/C 01:33, 10 May 2019 (UTC)
 * I too have thought that there is no real need for the  markup if community resolution of the publisher/work/upright/italic squabbles determines that the values assigned to &lt;periodical> shall be rendered in italic font.  Anticipating that such a resolution will occur before the next module update seems a forlorn hope.  I do know that without that community resolution, the Upright Periodical-name Brigade will show up with their torches and their pitchforks and inflict drama on us.  I'd rather avoid that so the   markup, along with the other items in the TODO list make for correct metadata whilst the argument is settled.
 * If you have made a case for specific restrictions involving citations that have url set, I don't understand your point. Can you explain why it is that url is so important to you?
 * —Trappist the monk (talk) 11:47, 10 May 2019 (UTC)
 * If that is how you feel, perhaps we should "do the right thing" (not allow  in &lt;periodical> ever) and force the debate?To directly answer your question... the point is to better comply with MOS:ITALICTITLE, which specifically mentions websites in the passage I quoted above. If there is a url, then there is a link to a website and the &lt;periodical> should be italicized as explicitly stated by the guideline. (That passage in the guideline probably deserves its own shortcut - perhaps MOS:ITALICCITEWORK/MOS:CITEWORK, MOS:ITALICWORKCITE/MOS:WORKCITE, MOS:ITALICWORKREF/MOS:WORKREF, or simply MOS:ITALICWORK/MOS:ITALICCITE?  I created MOS:ITALICWEBCITE. ) This, in combination with error messages in #1 and #4 above, will suppress the use of publisher simply to avoid italics in cases where there is no url. In cases where there is a url, I think the rationale at MOS:ITALICTITLE is clear enough to at least focus any debate there instead of here if there is drama from the Upright Periodical-name Brigade. The guideline is very explicit: any website. Why make it easier to flout it?Furthermore, I still have not seen any example where it is correct to remove italics in &lt;periodical> and if we allow  markup there we should also have valid example(s) of when to use it.But, again, I understand that adding this bit of logic between url and   markup in &lt;periodical> may be non-trivial, and if it will significantly add to the complexity of the change then please ignore my suggestion. (And perhaps consider the first sentence in this reply instead?) - Paul T [//en.wikipedia.org/w/index.php?title=User_talk:Psantora&action=edit +]/C 13:53, 10 May 2019 (UTC)
 * By that logic, the  markup should never be used (or work) in &lt;periodical>. I'm on board with that and have been arguing that point at length. However, allowing the   markup in &lt;periodical> is being pitched as a compromise so as to make sure that the metadata are not corrupted and are present when they should be in cases where the editor want[s], for whatever reason, to have the periodical name in upright font. My point is, if we are going to allow for that compromise, it should never work when a URL is present. - Paul T [//en.wikipedia.org/w/index.php?title=User_talk:Psantora&action=edit +]/C 01:33, 10 May 2019 (UTC)
 * I too have thought that there is no real need for the  markup if community resolution of the publisher/work/upright/italic squabbles determines that the values assigned to &lt;periodical> shall be rendered in italic font.  Anticipating that such a resolution will occur before the next module update seems a forlorn hope.  I do know that without that community resolution, the Upright Periodical-name Brigade will show up with their torches and their pitchforks and inflict drama on us.  I'd rather avoid that so the   markup, along with the other items in the TODO list make for correct metadata whilst the argument is settled.
 * If you have made a case for specific restrictions involving citations that have url set, I don't understand your point. Can you explain why it is that url is so important to you?
 * —Trappist the monk (talk) 11:47, 10 May 2019 (UTC)
 * If that is how you feel, perhaps we should "do the right thing" (not allow  in &lt;periodical> ever) and force the debate?To directly answer your question... the point is to better comply with MOS:ITALICTITLE, which specifically mentions websites in the passage I quoted above. If there is a url, then there is a link to a website and the &lt;periodical> should be italicized as explicitly stated by the guideline. (That passage in the guideline probably deserves its own shortcut - perhaps MOS:ITALICCITEWORK/MOS:CITEWORK, MOS:ITALICWORKCITE/MOS:WORKCITE, MOS:ITALICWORKREF/MOS:WORKREF, or simply MOS:ITALICWORK/MOS:ITALICCITE?  I created MOS:ITALICWEBCITE. ) This, in combination with error messages in #1 and #4 above, will suppress the use of publisher simply to avoid italics in cases where there is no url. In cases where there is a url, I think the rationale at MOS:ITALICTITLE is clear enough to at least focus any debate there instead of here if there is drama from the Upright Periodical-name Brigade. The guideline is very explicit: any website. Why make it easier to flout it?Furthermore, I still have not seen any example where it is correct to remove italics in &lt;periodical> and if we allow  markup there we should also have valid example(s) of when to use it.But, again, I understand that adding this bit of logic between url and   markup in &lt;periodical> may be non-trivial, and if it will significantly add to the complexity of the change then please ignore my suggestion. (And perhaps consider the first sentence in this reply instead?) - Paul T [//en.wikipedia.org/w/index.php?title=User_talk:Psantora&action=edit +]/C 13:53, 10 May 2019 (UTC)
 * If that is how you feel, perhaps we should "do the right thing" (not allow  in &lt;periodical> ever) and force the debate?To directly answer your question... the point is to better comply with MOS:ITALICTITLE, which specifically mentions websites in the passage I quoted above. If there is a url, then there is a link to a website and the &lt;periodical> should be italicized as explicitly stated by the guideline. (That passage in the guideline probably deserves its own shortcut - perhaps MOS:ITALICCITEWORK/MOS:CITEWORK, MOS:ITALICWORKCITE/MOS:WORKCITE, MOS:ITALICWORKREF/MOS:WORKREF, or simply MOS:ITALICWORK/MOS:ITALICCITE?  I created MOS:ITALICWEBCITE. ) This, in combination with error messages in #1 and #4 above, will suppress the use of publisher simply to avoid italics in cases where there is no url. In cases where there is a url, I think the rationale at MOS:ITALICTITLE is clear enough to at least focus any debate there instead of here if there is drama from the Upright Periodical-name Brigade. The guideline is very explicit: any website. Why make it easier to flout it?Furthermore, I still have not seen any example where it is correct to remove italics in &lt;periodical> and if we allow  markup there we should also have valid example(s) of when to use it.But, again, I understand that adding this bit of logic between url and   markup in &lt;periodical> may be non-trivial, and if it will significantly add to the complexity of the change then please ignore my suggestion. (And perhaps consider the first sentence in this reply instead?) - Paul T [//en.wikipedia.org/w/index.php?title=User_talk:Psantora&action=edit +]/C 13:53, 10 May 2019 (UTC)


 * I have to concur with removal of bogus "give me lack of italics or give me death" apostrophe markup. It not only pollutes the meta-data, it's just more WP:IDHT / WP:1AM / WP:NOT / WP:POINT / WP:GAMING / WP:TE crap, in furtherance of "I think WP is Wrong to italicize electronic sources so I will use every weapon I can come up with to win" antics. Just follow MOS:TITLES and the templates' own documentation and behavior: major sources cited are italicized; minor works and sub-works get quotation marks; the medium is irrelevant.  — SMcCandlish ☏ ¢ 😼  01:07, 10 May 2019 (UTC)

1. ignore wiki markup
ignore italic wiki markup in the &lt;periodical> parameters and publisher; the module shall emit an appropriate error message when it does this

I chose the error message because, you know, clever editors will try  and (I suspect less likely)  to get round the do-not-use-wiki-markup strictures. I haven't (yet) implemented a mechanism to strip html tags from these parameters.

—Trappist the monk (talk) 19:11, 11 May 2019 (UTC)

2. support for use-this-parameter-value-as-written
add support for use-this-parameter-value-as-written  markup in &lt;periodical> parameters (publisher is never italicized)

In the case of ((Publisher)), both the apostrophe markup and the use-this-parameter-value-as-written markup are removed. When there is only use-this-parameter-value-as-written markup, what to do? To preserve the metadata, the markup is removed:

I suspect that this should be announced somehow. How?

—Trappist the monk (talk) 19:11, 11 May 2019 (UTC)


 * I do not want to support this item #2 whatsoever. I do not see anything convincing above to indicate that we should go down this path, and we already have strong MOS guidance to the contrary path. --Izno (talk) 22:09, 11 May 2019 (UTC)

3. add support for and
Before beginning this, it has been on my TODO list to add error reporting to the script-title etc parameters. I have done that in the sandbox. All of the script-&lt;parameter> parameters use / will use the same function:

All articles with these error messages will be collected in

As part of this change, I have added script-&lt;parameter> support for all of the chapter aliases:
 * script-contribution, script-entry, script-article, script-section

—Trappist the monk (talk) 14:19, 20 May 2019 (UTC)

Added support for new parameters script-journal, script-magazine, script-newspaper, script-periodical, script-website, script-work.

—Trappist the monk (talk) 11:04, 21 May 2019 (UTC)

4. add error message for periodical templates without periodical parameter
add error message for periodical templates without periodical parameter (and attendant category and help text)

—Trappist the monk (talk) 13:09, 17 May 2019 (UTC)

Unfit URLs
The guidance at Category:CS1 maint: Unfit url says "pages listed in this category should be checked to ensure that the unfit and usurped keywords are correctly applied". Then what? If checked and found to be correct is there another (undocumented) parameter to take the pages out of this category or are they doomed to populate this category forever? Nthep (talk) 18:02, 21 May 2019 (UTC)
 * Doomed. You might consider including a comment in the parameter to indicate review. --Izno (talk) 18:13, 21 May 2019 (UTC)
 * Seems a bit silly to have a maintenance category that can't be emptied. Perhaps new parameter values needed unfit-verified and usurped-verified? Nthep (talk) 20:27, 21 May 2019 (UTC)
 * A lot of the articles in that category come from a time when Cyberbot II was adding unfit to many cs1|2 templates that it touched. See dead-url=unfit_maintenance_category|this discussion. The bot operator discussion mentioned there is this dead-url=unfit|discussion.  The solution to that problem was to implement a new keyword  .  See dead-url=_keyword|this discussion.  That implementation, does nothing to evaluate and / or fix the articles in the category that were put there by the bot.
 * So what to do? We could create additional keywords ,  .  What then?  Drop these from  and add them to another maint cat? To a properties cat?  What instructions should editors be given that they aren't given now?  Similarly, what to do with articles in ?
 * —Trappist the monk (talk) 14:13, 22 May 2019 (UTC)
 * Why do they need to go in a maintenance category at all after checking? If the status of the dead URL has been checked then what purpose is gained by putting it into another category. Nthep (talk) 15:34, 22 May 2019 (UTC)
 * Who knows? Someone may find it useful – it isn't as though there is a cost to having such categories.  Maybe the presence of a maint cat will inspire some editor to improve the referencing for an article; or not.  This, I think, is the least important of the 'what-then' questions that I asked in my last post here.  Got answers for them?
 * —Trappist the monk (talk) 16:34, 22 May 2019 (UTC)
 * Ok, if we have keywords,   then use of these values removes the article from . Neither keyword adds the article to any other category.  If this behaviour is accepted then the current instructions to editors probably only need the instruction to replace the current keyword with   or   if the status is correct.
 * Sadly looks like a large manual checking exercise. Nthep (talk) 16:53, 22 May 2019 (UTC)
 * Sadly looks like a large manual checking exercise. Nthep (talk) 16:53, 22 May 2019 (UTC)

pages= parameter when there are more than 1,000 pages in a work
I came across an instance where something like "1,234–6,789" was input into a cite template and it rendered unexpectedly -> "pp. 1, 234–6, 789" as if there were 3 separate page ranges: "1", "234 to 236", and "789". This is contrary to the expected "pp. 1,234–6,789". Now, the mistake here (and fix) should be obvious - remove the comma, but there is nothing in the documentation to indicate that this would be a problem. Is this worth mentioning in the HELP:CS1 section or is it too obscure? The specific example I saw was in an academic journal that apparently is often over 1000 pages. - Paul T [//en.wikipedia.org/w/index.php?title=User_talk:Psantora&action=edit +]/C 02:55, 8 May 2019 (UTC)
 * Some journals start with a page 1 for the first page of the January issue and continue the numbering consecutively until the end of the year. In such a case, page numbers above 1,000 are common. The issue of the journal I happen to have at my fingertips starts on page 915, and that's for the April issue. Extrapolating to December, it'll end up with around 3,000 pages for the year (and I know of others that are much longer). My suggestion is different – just don't automatically insert spaces after commas. MOS:NUMRANGE does not discourage commas in numerical range expressions and MOS:DIGITS suggests to use them, and they seem likely to be used relatively often anyway. —BarrelProof (talk) 03:07, 8 May 2019 (UTC)
 * That makes way more sense. Thanks for the clarification on why the page numbers are so high! - Paul T [//en.wikipedia.org/w/index.php?title=User_talk:Psantora&action=edit +]/C 15:54, 8 May 2019 (UTC)

Illustration of the problem is above. – Jonesey95 (talk) 04:40, 8 May 2019 (UTC)
 * It is the responsibility of the module suite to render properly formatted citations as best it can given the broad variety of stuff it gets as parameter values. Editors will leave out spaces, will use hyphen instead of endash (and the other way round), will use semicolons, will leave out punctuation, will duplicate punctuation, ....  pages lists are supposed to be an endash-separated page range, a comma-separated list of individual pages, or a comma-separated list of individual pages and endash-separated page ranges.  It isn't really possible to for the module to know if 1,234–6,789 refers to a (completely unhelpful-to-readers) 5,555-page range or three individual elements: page, small page-range, page.  pages does support the use-this-parameter-value-as-written   markup so:
 * the  markup can apply to the whole of the parameter value or to individual elements – the second page in the list is hyphenated:
 * – second element is rendered as a single hyphenated page
 * without the  markup
 * – second element is rendered as an endash-separated page range
 * —Trappist the monk (talk) 11:02, 8 May 2019 (UTC)
 * to a (completely unhelpful-to-readers) 5,555-page range 1000% correct - I was giving an example of the phenomenon, not directly quoting what I saw. the use-this-parameter-value-as-written markup this is an obscure, but useful feature. I will use it to correct the incorrectly rendered references that prompted my comment.It may make sense to explicitly outline this "limitation"/"feature" at HELP:CS1. Is   mentioned/documented anywhere at HELP:CS1 or elsewhere? - Paul T [//en.wikipedia.org/w/index.php?title=User_talk:Psantora&action=edit +]/C 12:02, 8 May 2019 (UTC)Also note, this feature doesn't seem to work with the page parameter. - Paul T [//en.wikipedia.org/w/index.php?title=User_talk:Psantora&action=edit +]/C 12:35, 8 May 2019 (UTC)
 * is mentioned in the documentation for vauthors and veditors, for which it was originally developed; title got it as a result of this discussion; pages and issue got it as a result of this discussion.
 * Yet another claim that something-doesn't-work-but-I-can't-be-bothered-to-provide-an-example. Do you know how frustrating that is?  Why do you and other editors do that?
 * I don't think that I have said here that this feature applies to page though I did imply that  markup applied to page in another conversation – I'll fix that.  Module:Citation/CS1 treats the content of page as a single value.  Single values do not need to be massaged to get spacing right, do not need to have hyphens converted to endashes, etc.  cs1|2 does not automatically change p. to pp. though it will render digit-only pages value as p. &lt;digit(s)>.
 * —Trappist the monk (talk) 13:24, 8 May 2019 (UTC)
 * Please accept my apology. I didn't mean it to come across as a complaint, it was simply unexpected and I figured I should note it here. Here is the example:
 * Yet another claim that something-doesn't-work-but-I-can't-be-bothered-to-provide-an-example. Do you know how frustrating that is?  Why do you and other editors do that?
 * I don't think that I have said here that this feature applies to page though I did imply that  markup applied to page in another conversation – I'll fix that.  Module:Citation/CS1 treats the content of page as a single value.  Single values do not need to be massaged to get spacing right, do not need to have hyphens converted to endashes, etc.  cs1|2 does not automatically change p. to pp. though it will render digit-only pages value as p. &lt;digit(s)>.
 * —Trappist the monk (talk) 13:24, 8 May 2019 (UTC)
 * Please accept my apology. I didn't mean it to come across as a complaint, it was simply unexpected and I figured I should note it here. Here is the example:
 * —Trappist the monk (talk) 13:24, 8 May 2019 (UTC)
 * Please accept my apology. I didn't mean it to come across as a complaint, it was simply unexpected and I figured I should note it here. Here is the example:


 * I changed it to:


 * The  notation is not required for page, but it was confusing that the two parameters didn't work similarly in this instance. - Paul T [//en.wikipedia.org/w/index.php?title=User_talk:Psantora&action=edit +]/C 14:24, 8 May 2019 (UTC)
 * Do you know of any reason why page should support  markup?
 * The drawback to this 'solution', there always is something ..., is that when you tell the module to use-this-parameter-value-as-written, it does. For example your Babcock et al. (1992) citation uses a hyphen instead of an endash which would be the correct form and which the module would have supplied.
 * —Trappist the monk (talk) 15:07, 8 May 2019 (UTC)
 * The double-paren markup could be useful with the page parameter if the document has page numbers of the form chapter-page, such as "10-5". Maybe there is a different trick that permits that; I can't keep track of all the tricks in Wikipedia markup to prevent overly-helpful software from "correcting" correctly written character strings. Jc3s5h (talk) 15:18, 8 May 2019 (UTC)
 * Already doesn't do anything with that sort of page number:
 * so  markup not needed for this example.
 * —Trappist the monk (talk) 15:22, 8 May 2019 (UTC)
 * This just illustrates that when you take it upon yourself to correct any parameter, or family of parameters, for editor errors, you impose on all editors the burden of predicting whether their unusual but correct parameter value will be mangled or not. Jc3s5h (talk) 15:26, 8 May 2019 (UTC)
 * Thanks Ttm! Fixed. I have no specific example as to why ((...)) is necessary other than it could be confusing when compared to other references using pages. I was merely reporting my surprise (well, really ignorance). - Paul T [//en.wikipedia.org/w/index.php?title=User_talk:Psantora&action=edit +]/C 15:51, 8 May 2019 (UTC)
 * —Trappist the monk (talk) 15:22, 8 May 2019 (UTC)
 * This just illustrates that when you take it upon yourself to correct any parameter, or family of parameters, for editor errors, you impose on all editors the burden of predicting whether their unusual but correct parameter value will be mangled or not. Jc3s5h (talk) 15:26, 8 May 2019 (UTC)
 * Thanks Ttm! Fixed. I have no specific example as to why ((...)) is necessary other than it could be confusing when compared to other references using pages. I was merely reporting my surprise (well, really ignorance). - Paul T [//en.wikipedia.org/w/index.php?title=User_talk:Psantora&action=edit +]/C 15:51, 8 May 2019 (UTC)

May I ask, is the thousands separator necessary? Just add the page number(s) without any type of separator (I believe the math term is radix). 65.88.88.91 (talk) 18:58, 8 May 2019 (UTC)
 * WP:MOS requires a comma. --Izno (talk) 19:26, 8 May 2019 (UTC)
 * Yes, or a variety of space types, which seems to be the new trending norm in digit-grouping. My point was that this is a relatively minor issue, where neither the readability nor the integrity of the citation is affected by omitting the separator. There are other cases where MOS exceptions are made for CS1-specific formatting. I would think this would be non-controversial. 65.88.88.91 (talk) 19:34, 8 May 2019 (UTC)
 * The "obscure but useful feature" should be added to the documentation for this parameter, and all should then be well.  — SMcCandlish ☏ ¢ 😼  03:09, 10 May 2019 (UTC)
 * MOS:DIGITS accepts a 4-digit grouping without separators for page numbers and years specifically. 24.105.132.254 (talk) 16:17, 22 May 2019 (UTC)
 * Current wording at MOS:DIGITS:
 * An exception is made for four-digit page numbers or four-digit calendar years. These should never be grouped (not sailed in 1,492,  though  dynasty collapsed around 10,400 BC  or  by $13,727 AD$, Vega will be the northern pole star).
 * That text is a result of this and is a derivation of wording added to MOS:DIGITS at .  I didn't find any discussion for that.
 * So what does this mean to cs1|2? Anything?  Tweak the template docs to say something about comma separators in 4-digit page numbers?  If so, say what?
 * —Trappist the monk (talk) 17:12, 22 May 2019 (UTC)
 * If it is decided to adhere to current MOS:DIGITS, quoting from imaginary doc, "editors not separate 4-digit page/year numbers. They  separate 5+ digit pages/years" (in case someone cites a work from 12,000 BC. Though they might be other technical problems with that.) 65.88.88.69 (talk) 17:57, 22 May 2019 (UTC)
 * Scratch that. According to MOS:DIGITS 4-digit page/year numbers be separated. 65.88.88.69 (talk) 18:03, 22 May 2019 (UTC)
 * To answer the initial question raised by 65.88.88.91, that (removing the commas) was my temporary solution to fix the problem I found until I was pointed to the  markup here. Now that I see this is clearly settled at MOS:DIGITS as quoted by Ttm, I removed the extra code (and the commas) from the 4-digit page numbers/ranges at the page where I originally found this issue (but kept them both in the 5-digit references). It seems like an odd exception to me (especially when it is a range of numbers as opposed to a single page number), but I don't really have a huge preference one way or the other. I was just concerned with the ambiguous display where a range between two numbers suddenly looked like 3 separate groupings.Either way it is now fixed. It seems that the only thing left to do is make mention of this edge case (and helpful   markup feature) somewhere in the documentation. It would probably also be a good idea to reference the guidelines for comma separators in 4-digit page numbers as well. To that latter point, I think according to MOS:DIGITS 4-digit page/year numbers be separated works great. It is simple and to the point (probably could lose the caps and emphasis though). - Paul T [//en.wikipedia.org/w/index.php?title=User_talk:Psantora&action=edit +]/C 19:36, 22 May 2019 (UTC)
 * That is sensible. But, strictly for laughs (I think) let me be the devil's advocate and point out that ranges that jump an order are not resolved by MOS. Something like 9999–10,000 for example... or I presume the more common date range, example 11,000–8000 BC. Can't wait for the multi-megabyte discussion on the esthetics of that one. I mean I will literally not wait for that. 98.0.246.242 (talk) 19:52, 22 May 2019 (UTC)
 * Correction, it would have to be ((9999–10,000)) or you'd run into the same problem I did initially. And I also considered making that point about the ranges but decided against it. There is no reason to spell it out in the MOS until it becomes an issue. The MOS is already unwieldy enough as it is! But until then, I can't wait either. - Paul T [//en.wikipedia.org/w/index.php?title=User_talk:Psantora&action=edit +]/C 21:04, 22 May 2019 (UTC)
 * Correction, it would have to be ((9999–10,000)) or you'd run into the same problem I did initially. And I also considered making that point about the ranges but decided against it. There is no reason to spell it out in the MOS until it becomes an issue. The MOS is already unwieldy enough as it is! But until then, I can't wait either. - Paul T [//en.wikipedia.org/w/index.php?title=User_talk:Psantora&action=edit +]/C 21:04, 22 May 2019 (UTC)

In a string of digits: why isn't a comma followed by a space understood as splitting that string into separate strings (numbers), while a comma followed by a digit (no spaces) understood as the thousands separator? &diams; J. Johnson (JJ) (talk) 21:27, 22 May 2019 (UTC)
 * As I understand it? Inertia and existing convention (but I'm sure Ttm will articulate a much more comprehensive and useful reason than that). There are a slew of pages (and editors) out there and the responsibility of the module suite to render properly formatted citations as best it can given the broad variety of stuff it gets as parameter values. Editors will leave out spaces, will use hyphen instead of endash (and the other way round), will use semicolons, will leave out punctuation, will duplicate punctuation, ....To be clear, I agree with you that the presence or absence of a space after the comma should be enough to do this automatically... Maybe there is another angle/solution we're not seeing? - Paul T [//en.wikipedia.org/w/index.php?title=User_talk:Psantora&action=edit +]/C 22:13, 22 May 2019 (UTC)
 * This is not a matter of idle speculation. For instance, at Earthquake prediction there is a source (Kagan & Jackson, 1991) with five digit page numbers. In the full citation the page range is currently rendered as "96 (B13):21, 419–21, 431". In 2016 the same entry was rendered, correctly, as "96 (B13):21,419–21,431". So what changed? &diams; J. Johnson (JJ) (talk) 20:06, 23 May 2019 (UTC)
 * Probably, though I can't be sure, as a result of the changes made per this discussion.
 * —Trappist the monk (talk) 10:29, 24 May 2019 (UTC)
 * We could inspect the content of pages. If content of pages:
 * has 1 hyphen or dash
 * text preceding the hyphen or dash has:
 * 5 or 6 digits
 * no more than 1 comma
 * comma, if present:
 * is not followed by a space character
 * is positioned as a thousands separator (xx,xxx xxx,xx)
 * text following the hyphen or dash:
 * obeys same rules as text preceding the hyphen or dash
 * when stripped of commas, has greater numeric value than the numeric value of the preceding text
 * If those are the correct rules, we might could add something like this to function :
 * This fix, if implemented does not handle the four-digit to five-digit boundary-crossing case (xxxx–xx,xxxx) for which, as was mentioned earlier, there is no MOS guidance. Another issue: The example range given 21,419–21,431 can be legitimately interpreted as single-page, short-page-range, single-page because 419–21 is a legitimate way of writing 419–421; editors will write values for pages with and without proper spacing.
 * —Trappist the monk (talk) 15:35, 24 May 2019 (UTC)
 * Per WP:CIR: whitespace is an essential separator, and if an editor leaves that out it's the editor's fault. We don't expect the software to read the editor's mind to see where he might have meant to insert a space. &diams; J. Johnson (JJ) (talk) 22:15, 24 May 2019 (UTC) And while we might infer where a rushed, lame-brained editor has left out "to" (oops), that's for the editor to fix, not the s/w. &diams; J. Johnson (JJ) (talk) 18:30, 25 May 2019 (UTC)
 * I agree with JJ. I think the auto-spacing should be removed. If we really believe that editors can't figure out that commas should only be next to digits when there are large page numbers cited, then it should at-most be a maintenance message. I am skeptical, however. --Izno (talk) 03:17, 25 May 2019 (UTC)
 * Per WP:CIR: whitespace is an essential separator, and if an editor leaves that out it's the editor's fault. We don't expect the software to read the editor's mind to see where he might have meant to insert a space. &diams; J. Johnson (JJ) (talk) 22:15, 24 May 2019 (UTC) And while we might infer where a rushed, lame-brained editor has left out "to" (oops), that's for the editor to fix, not the s/w. &diams; J. Johnson (JJ) (talk) 18:30, 25 May 2019 (UTC)
 * I agree with JJ. I think the auto-spacing should be removed. If we really believe that editors can't figure out that commas should only be next to digits when there are large page numbers cited, then it should at-most be a maintenance message. I am skeptical, however. --Izno (talk) 03:17, 25 May 2019 (UTC)

cite citeseerx
We have a template. It doesn't have any documentation.

is treated like and  in that it supports a limited subset of the cs1 parameter set and, in the metadata, as a preprint citation, but is it? Our CiteSeerX article doesn't use the term 'preprint' so shouldn't citeseerx metadata specify  or possibly, something else?

—Trappist the monk (talk) 13:03, 23 May 2019 (UTC)
 * the fact that it's transcluded only once makes me think it's a useless template. Furthermore, the doi it lists is faulty and even on CiteSeerX the link to the document is a 404. – Finnusertop (talk ⋅ contribs) 23:51, 25 May 2019 (UTC)
 * You mean this one from Social media? Repeated here:
 * What am I missing? The link works for me.
 * I don't know if its a useless template. I would suspect that part of the not-used-very-much problem is that there is no documentation, it isn't listed with the other cs1|2 templates in  or  or anywhere else for that matter so no one knows that it exists.
 * —Trappist the monk (talk) 00:22, 26 May 2019 (UTC)
 * does anyone use it? AManWithNoPlan (talk) 01:31, 26 May 2019 (UTC)
 * The link to CiteseerX does work. But the download link on CiteseerX doesn't. And the doi is broken. – Finnusertop (talk ⋅ contribs) 22:47, 26 May 2019 (UTC)
 * A citeseerx 'doi' is not the same as a doi.org 'doi' so, of course, if you give the citeseerx doi to doi.org, doi.org will choke on it. Yeah, that download link doesn't work but if you click the pdf icon, it sends you to this pdf which looks to me like it is the article.
 * —Trappist the monk (talk) 23:04, 26 May 2019 (UTC)
 * Only ONE page uses this thing. AManWithNoPlan (talk) 02:11, 27 May 2019 (UTC)
 * Why so hostile? Editor Finnusertop has already noted  that the template is currently used in only one article.  Write some documentation for it.  Include it in  and .  Mention that it exists at the appropriate wiki projects.  If, after all of that, and some time for editors to use it, there is still only one transclusion, then perhaps we should take it to tfd.
 * —Trappist the monk (talk) 02:50, 27 May 2019 (UTC)
 * I am not hostile. More just concerned aver the proliferation of subtlety different templates.  Cite article, work, paper, document, conference, news, newspaper, book, journal, magazine, etc. AManWithNoPlan (talk) 03:47, 27 May 2019 (UTC)
 * proliferation? Five of the templates that you named are redirects to cs1 templates.  We have no control over editors creating whatever redirects that they want.  If you think that there are too many, then WP:RFD is the proper venue.  These are the redirects that you named, with year of creation and target:
 *  (2007) →
 *  (2010) →
 *  (2008) →
 *  (2006) →
 *  (2012) →
 * The others that you named with year of creation:
 * – 2006
 * – 2006
 * – 2005
 * – 2006 (as a redirect), 2015 as a template
 * – 2006
 * And, for completeness, the rest of the cs1|2 templates and year of creation:
 * – 2006
 * – 2005
 * – 2006
 * – 2017
 * – 2017
 * – 2005
 * – 2007
 * – 2006
 * – 2007
 * – 2007
 * – 2006
 * – 2006
 * – 2006
 * – 2008
 * – 2007
 * – 2006
 * – 2006
 * – 2006
 * – 2009
 * – 2004
 * – Citation
 * I don't see any proliferation trend here. The bulk of these templates were created between 2004 and 2009:
 * 2004 (1×), 2005 (3×), 2006 (13×), 2007 (4×), 2008 (1×), 2009 (1×)
 * The most recent creations were and, both created in 2017.
 * —Trappist the monk (talk) 13:20, 27 May 2019 (UTC)
 * Really, cite arXiv, cite bioRxiv, cite citeseerx and (a newly created) cite SSRN should all be merged into a cite preprint. &#32; Headbomb {t · c · p · b} 01:39, 31 May 2019 (UTC)
 * The most recent creations were and, both created in 2017.
 * —Trappist the monk (talk) 13:20, 27 May 2019 (UTC)
 * Really, cite arXiv, cite bioRxiv, cite citeseerx and (a newly created) cite SSRN should all be merged into a cite preprint. &#32; Headbomb {t · c · p · b} 01:39, 31 May 2019 (UTC)

Deprecate format
Since we're apparently doing deprecations this round, we might consider replacing format as well, with url-file-format or similar. I know there's an (old) discussion lying around about how ambiguous "format" is. --Izno (talk) 15:24, 1 June 2019 (UTC)
 * Find that discussion? I don't remember it ...
 * —Trappist the monk (talk) 15:43, 1 June 2019 (UTC)
 * That might take some time. One minute/hour/day ~ --Izno (talk) 16:02, 1 June 2019 (UTC)
 * The reason you do not remember is because you were uninvolved and it was off in a tiny corner of the world. :) Module talk:Citation/CS1/Feature requests was about having a format size and then DF suggested changing the name. I'm fairly certain we've had followup discussion but insource search is not finding my proposed name in the relevant namespaces. --Izno (talk) 16:14, 1 June 2019 (UTC)

deprecate |dead-url= and |deadurl=
This to follow up on this discussion (and the three previous discussions mentioned there); all of which has dragged on for far too long.

There are about 173,000 articles (astonishingly, the search did not time out) that use dead-url and deadurl.

Since there is a vague acceptance of url-status as a replacement, I am going to deprecate dead-url and deadurl and add support for url-status with appropriate keywords to replace  and   with   and.

In parallel with that I shall write a bot task to replace existing instances of these parameters.

—Trappist the monk (talk) 14:47, 1 June 2019 (UTC)


 * The deprecation and replacement looks like this:


 * Old values "yes" and "no" still work: not any more


 * the deprecated parameters still work:


 * —Trappist the monk (talk) 15:43, 1 June 2019 (UTC)

Phab for IABot --  Green  C  15:54, 1 June 2019 (UTC)

To clarify, we are increasing complexity from two possibles:
 * yes
 * no

To six possibilities:
 * yes
 * no
 * yes
 * no
 * dead
 * live

(plus bot: unknown, usurped and unfit and aliases without the dash) -- Green  C  17:00, 1 June 2019 (UTC)
 * No. During the deprecation period, dead-url and deadurl will work as they did previously except that templates that use those parameters will show the deprecated parameter error message.  At the same time, url-status must also be supported.  Because yes and no convey little or no meaning (much more 'no' meaning than 'little' meaning), I had not bothered with detecting those nonsense values.  But, since you have made the claim that doing this change will increase the complexity of the system, I have increased the complexity of the code to handle those nonsense parameter/keyword combinations – to be undone at a future update to the module.
 * —Trappist the monk (talk) 17:28, 1 June 2019 (UTC)
 * The 5.7+ million wiki articles is a universal shared base to every human editor and automated process, unlike a single CS1|2 Lua module which is maybe complex to the relatively few programmers who work with it. Thank you for eliminating two of the six. Editors are accomplished at making shorcuts (least number of keystrokes) so converting yes to yes would be a logical thing to do ie. the argument name has changed so change the argument name. I wouldn't advise removing a value check because if it can be done editors will do it, leaving it to others to fix the hard way: discovering the problem exists, starting BRFAs, writing bots to clean it up, requesting warning messages and tracking categories. --  Green  C  18:32, 1 June 2019 (UTC)
 * You're right, if it can be done editors will do it. But, you know, the sky would not have fallen if we did have six possibilities.  We suck at documenting this cs1|2 stuff but, I like to think that, were we implementing this change right-now today, we would have got the help-text more-or-less right at Help:CS1 errors so that those editors who are at least minimally conscientious, would not have gone astray littering the encyclopedia with crap (I suspect that most editors will ignore the error and wait for someone or someone's bot to fix it; that is, apparently, the most common response to cs1|2 errors).
 * there is no discovering the problem exists – that 'discovery', if it could be called that, is a natural consequence of the decision that we take here to deprecate dead-url and deadurl
 * the bot task that I mentioned at the top of this discussion is written
 * no point in starting a WP:BRFA yet because approval usually requires trial runs that can't be done without we first update the module suite which must wait for the resolution of the website italic rfc and the pmc autolink rfc. About the time that those are closed I'll start the brfa.
 * None of this seems to be leaving it to others to fix the hard way. In fact, leaving it to others to fix the hard way would be for us to do nothing except change the module suite.  Clearly, that isn't in the plan; never has been.
 * —Trappist the monk (talk) 23:35, 1 June 2019 (UTC)
 * I was not aware of Monkbot 15 (missed that sentence), that would basically resolve the concern I had. Once 15 gets approval, I plan on adding code to do the same in WaybackMedic's regular maintenance since in my experience even if all were eliminated today in 6 months there will be thousands more, via many routes (reverts to old revisions, copy-paste from elsewhere, force of habit, other tools and bots not yet changed, etc) - returning from the dead, so to speak, for many years. --  Green  C  01:22, 2 June 2019 (UTC)

link rot
In CS1|2 there are multiple URLs in a citation but space for only one archive. For example there can be a url and lay-url. Would it ever make sense to have lay-archive-url, or is it better to replace the URL inside lay-url with an archive URL? -- Green  C  19:39, 3 June 2019 (UTC)
 * I guess another possibility is addlarchives in which can support multiple archives. --  Green  C  12:23, 5 June 2019 (UTC)

Odd PMC error
appears to be valid, yet displays the following warning: Any ideas on what triggered this warning? Boghog (talk) 11:35, 18 May 2019 (UTC)
 * pmc is just digits. To detect too many digits (because of typo or whatever) there is a limit to the max value of the digits.  The limit value for the test is currently 6500000.  I will change that to 7000000.
 * —Trappist the monk (talk) 11:46, 18 May 2019 (UTC)
 * Thanks for the explanation and for fixing it. Boghog (talk) 13:46, 18 May 2019 (UTC)
 * Could we change it to 9999999 (or something similar) so we don't run into this problem again in a few years (especially since a lot of smaller wikis copy our templates)? Kaldari (talk) 16:12, 20 May 2019 (UTC)

fixed in the live module because nothing else changes in Module:Citation/CS1/Identifiers and because normal update won't happen until after the completion or the two rfcs on this page (here and here).

—Trappist the monk (talk) 10:28, 6 June 2019 (UTC)

icons and the modern skin
If I view this page with Chrome and use the modern skin, access and wikisource icons in these example citations are not displayed and, in the pdf example, the pdf icon is different from other skins:

Modern renders  and   urls differently:
 * → http://www.example.com – the generic external link icon
 * → https://www.example.com – a yellow lock icon

The doi link in the first example is a protocol relative link; modern renders those with the generic external link icon:
 * → [//doi.org/10.99999%2Fbogus.doi.article //doi.org/10.99999%2Fbogus.doi.article]

In the wikisource citation, Module:Citation/CS1 creates an  url to the wikisource article so that it can render the wikisource icon in the same way that access icons are rendered.

For those who do not use modern skin, follow this link to re-render this page using modern skin.

and for the curious, the other skins: Do we know why access and wikisource icons do not work with modern but do with the other skins? Where is the modern skin css?
 * Cologne Blue
 * MinervaNeue
 * MonoBook
 * Timeless
 * Vector (default)

—Trappist the monk (talk) 12:32, 10 June 2019 (UTC)
 * Probably related to the discussion at MediaWiki_talk:Common.css/Archive_18, when I removed the highly specific rules in our Common.css. On-wiki, mediawiki:modern.css; phabricator repo for Modern; main.css. It looks like the rules in Modern should have been updated when the rules in the other skins were on similar CSS the others skins have, to be less specific:
 * #mw_content probably should be updated to .mw-parser-output, as with the other skins. There's basically nothing we can do to fix this problem with those specificity on the elements those are on. --Izno (talk) 14:15, 10 June 2019 (UTC)
 * I've filed a task for it. Who knows how long it will be. --Izno (talk) 14:30, 10 June 2019 (UTC)
 * Thank you. According to, most icons were withdrawn by the end of January 2015; modern and monobook, apparently, excepted.
 * —Trappist the monk (talk) 15:04, 10 June 2019 (UTC)
 * —Trappist the monk (talk) 15:04, 10 June 2019 (UTC)

Redirects for discussion/Log/2019 June 1
Please comment. The outcome of this discussion could greatly impact our ability to cleanup articles. &#32; Headbomb {t · c · p · b} 18:33, 11 June 2019 (UTC)

cite map and |map-url-access=
Current version of Module:Citation/CS1 does not support map-url-access. It should. I found this citation at M-6 (Michigan highway):

Fixed I think, in the sandbox:

The usual error detection applies:

map-url-access only applies to map-url so is only used when map and map-url are used.

Ping Imzadi1979: you are, I think, our local expert on the use of this template, do you know of any cases where this new functionality falls on its face?

—Trappist the monk (talk) 19:41, 12 June 2019 (UTC)
 * I don't know of any, no.  Imzadi 1979  →   00:58, 13 June 2019 (UTC)

Cite letter
Is anyone watching Template talk:Cite letter? Should it perhaps be redirected here (after the content is copied over)? Andy Mabbett ( Pigsonthewing ); Talk to Andy; Andy's edits 00:00, 21 June 2019 (UTC)
 * There are five watchers. Because it is a wrapper template around, it is not a cs1 template so unless we intentionally decide to redirect  cs1|2 wrapper template talk pages here, we should not redirect Template talk:cite letter here.
 * —Trappist the monk (talk) 00:14, 21 June 2019 (UTC)
 * I note that 'Template talk:Cite news' redirects here. There is also no certainty that those five watchers remain active. It is five years since anyone responded to an issue raised on 'Template talk:cite letter'. What are the arguments for keeping it (and the talk page of any other such wrapper) as a stand-alone page? Andy Mabbett ( Pigsonthewing ); Talk to Andy; Andy's edits 10:09, 21 June 2019 (UTC)
 * is a cs1 template so its talk page should redirect here because enhancements or fixes to base cs1 templates are discussed here and fixed in Module:Citation/CS1. It is true that the five watchers may no longer be among the living.  I see no need to address enhancements to or fixes of wrapper templates here unless those discussions require changes in the module.
 * —Trappist the monk (talk) 11:31, 21 June 2019 (UTC)

Stop linking paper title to PMC
Is there a way to stop cite journal from linking the paper title to a PubMed Central URL generated from pmc in the absence of url? I cited a paper whose manuscript was on PMC but which was not otherwise freely available. I used the page numbers of the published version in footnotes, which I found preferable for obvious reasons, so it strikes me as incongruous that even though the article is explicitly referencing the published version, the title is linked to a pre-review manuscript. Removing pmc would disable the link, but that doesn't seem wise either because a free link to a version of the paper, even if not the most authoritative one, is definitely beneficial to readers.

While I'm at it, I don't really see the necessity of pmc standing in for url in the first place, given that a separate link is also provided and the open access is indicated by the padlock icon following the latter link. Do we need this feature? Even if so, shouldn't an editor at least be able to opt it out? Nardog (talk) 03:50, 16 May 2019 (UTC)
 * "I cited a paper whose manuscript was on PMC but which was not otherwise freely available." If it's an embargoed paper, use 201X-XX-XX'. If you just want a different URL than the PMC one, then just specify that URL in url instead. &#32; Headbomb {t · c · p · b} 04:45, 16 May 2019 (UTC)
 * No, not embargoed. And the published version is not available except behind a paywall. I can specify the same URL as DOI, but what would be the point of that? I want to disable the PMC link. Nardog (talk) 04:55, 16 May 2019 (UTC)
 * If the only free version is at PMC, and you want readers to have access to a free version, then the PMC link needs to be there, doesn't it? BlackcurrantTea (talk) 05:23, 16 May 2019 (UTC)
 * Yes, I just don't want the title of the paper to be linked to PMC. Nardog (talk) 05:24, 16 May 2019 (UTC)
 * Ah, right. Obviously I need another cuppa; I wasn't making the connection. Thanks for explaining. BlackcurrantTea (talk) 06:43, 16 May 2019 (UTC)
 * It is always good to provide an example so that we can see what you are seeing.
 * I would like nothing better than to remove that special-case pmc code. I did that once.  But then WP:MED rose up with their torches and pitchforks ...
 * I'm not enthusiastic about making yet-another-special-case for pmc. If you want us to remove current pmc auto-linking of title, you must get WP:MED to agree with that, or a sufficient consensus that does not include them.
 * —Trappist the monk (talk) 10:10, 16 May 2019 (UTC)
 * WP:MED does not WP:OWN the module. --Izno (talk) 12:46, 16 May 2019 (UTC)
 * Why is removing the auto-linking considered "making yet-another-special-case"? Isn't it rather removing one? Nardog (talk) 14:33, 16 May 2019 (UTC)
 * You asked for a way to stop cite journal from linking the paper title. Presuming that the auto-linking will remain, then some way to allow editors to disable the auto-linking is yet-another-special-case for pmc.
 * —Trappist the monk (talk) 14:46, 16 May 2019 (UTC)
 * If the content in the pages you are citing is not substantially/semantically different than the relevant section(s) of the pre-review version, then adding the pmc link benefits verification. You can quote the online paper's subheading as a pre-review copy, or quote any other part of the publication info that shows the paper is a pre-review copy. Or, add a link note to that effect after the citation. If there are semantic differences between the preliminary and the final version in the cited pages, I would leave the pmc out altogether. The citation is no longer reliable. 108.182.15.109 (talk) 13:13, 16 May 2019 (UTC)
 * Again, I'm only talking about the template automatically linking the title of the paper when pmc is given but url is not. I'm not talking about the utility of PMC as a whole. Nardog (talk) 13:47, 16 May 2019 (UTC)
 * I don't think you should compare pmc with url. One is a standard content identifier (akin to doi). The other is a locator/pointer. There are further differences between content ids such as pmc and classification/marketing ids such as isbn. The point is, is the verifiability of whatever you claim in wikitext helped by adding this parameter? This is the main point in adding citations in a project like Wikipedia. Otherwise it is just somebody blabbering at some internet site. 65.88.88.69 (talk) 19:54, 16 May 2019 (UTC)
 * Often PMC is the only free source. Even if it is not only the free source, what is the harm of including pmc?  At the same time, (pitch forks or not) IMHO pmc should never be linked because it leads to a MOS:SEAOFBLUE in the reference section. Readers are intelligent enough to follow a link, even if the title is not linked. This is especially true now that File:Lock-green.svg follows the PMC link. WP:MED is insulting the intelligence of the average reader. Boghog (talk) 19:00, 16 May 2019 (UTC)
 * I don't think you should compare pmc with url. One is a standard content identifier (akin to doi). The other is a locator/pointer. There are further differences between content ids such as pmc and classification/marketing ids such as isbn. The point is, is the verifiability of whatever you claim in wikitext helped by adding this parameter? This is the main point in adding citations in a project like Wikipedia. Otherwise it is just somebody blabbering at some internet site. 65.88.88.69 (talk) 19:54, 16 May 2019 (UTC)
 * Often PMC is the only free source. Even if it is not only the free source, what is the harm of including pmc?  At the same time, (pitch forks or not) IMHO pmc should never be linked because it leads to a MOS:SEAOFBLUE in the reference section. Readers are intelligent enough to follow a link, even if the title is not linked. This is especially true now that File:Lock-green.svg follows the PMC link. WP:MED is insulting the intelligence of the average reader. Boghog (talk) 19:00, 16 May 2019 (UTC)

Since some people are not getting the issue even after multiple clarifications, here is an example: displays as Notice the title of the paper is linked to PMC, even though url is absent. The only way to remove the link is to remove pmc, which, however, and of course, also removes the PMC link at the end. Nardog (talk) 05:02, 17 May 2019 (UTC)


 * I strongly support no longer linking the article title to the PMC; the link from the PMC is enough. What on earth is the point of duplicate links? And anyway, in this example, the most relevant link here is the doi, not the PMC. Peter coxhead (talk) 06:35, 17 May 2019 (UTC)
 * I agree, but others don't. Trappist has linked people arguing for duplicating the PMC link in the title; in this discussion, people argued for doing that for all free identifiers.  Kanguole 09:27, 17 May 2019 (UTC)
 * The functionality should indeed be extended to the other free identifiers for version of record, not removed for PMCs. &#32; Headbomb {t · c · p · b} 13:07, 17 May 2019 (UTC)
 * No. Just no.  Very often sources linked through identifiers are not free-to-read; title linked to a source with url is presumed to be free-to-read; readers expect that linked titles are free-to-read unless marked otherwise with an appropriate access icon.  When multiple identifiers are provided in the template, which one wins? (there must be a winner because title can only link to one target).  Who or what decides the priority of identifiers when more than one is provided?
 * Auto-linking of pmc should be removed and there's an end to it.
 * —Trappist the monk (talk) 13:24, 17 May 2019 (UTC)
 * Kanguole and Headbomb kind of accidentally bring up very astute points that go against this feature – in theory, promoting open-access links is great. But then, why single PMC out? Why not all free identifiers? But if we stopped singling PMC out, then how does the template decide which one to link the title to when multiple free identifiers are entered?
 * Further, oftentimes another identifier provides open access to a more reliable version than PMC. In that case, linking the title to PMC makes little sense. The more you consider the philosophy supposedly behind the auto-linking, the more reasonable it seems to drop it. Nardog (talk) 14:01, 17 May 2019 (UTC)
 * Just build a hierachy. PMC > DOI > Handle > and so on. url overides automatical linking. If you don't want the default, have doi or similar (e.g. doi as an override. &#32; Headbomb {t · c · p · b} 03:33, 18 May 2019 (UTC)
 * A DOI or Handle may or may not be free. So why should the title automatically be linked to those handles if a PMC is not present? And why should the title be linked to anything other than url?  These other parameters already generate their own links and with free, etc. can be marked as free access. Boghog (talk) 05:39, 18 May 2019 (UTC)
 * This. Nardog (talk) 13:35, 19 May 2019 (UTC)
 * Likewise for free and so on. Use whatever version of record is known to be free, following the hierarchy. If the default link is not desired (e.g. if the hierarchy is pmc>doi>hdl>bibcode>...), it could be overridden, either with https:... or with hdl or similar. &#32; Headbomb {t · c · p · b} 23:14, 23 June 2019 (UTC)
 * I would support an RFC on removing the special-casing. --Izno (talk) 03:39, 25 May 2019 (UTC)
 * I would support an RFC on removing the special-casing. --Izno (talk) 03:39, 25 May 2019 (UTC)

deprecate |lay-summary= and |laysummary=
lay-summary and laysummary are supposed to hold the url of a lay summary. We have lay-url which abides by the general rule that url-holding parameter names end with  (dead-url notwithstanding).

This insource search found about 4000 articles that have either of lay-summary and/or laysummary with or without assigned values.

Without objection, I shall deprecate these two parameters and write an awb script to rename lay-summary and laysummary to lay-url (or delete if empty).

—Trappist the monk (talk) 14:00, 1 June 2019 (UTC)


 * What if it's not a URL? :) --Izno (talk) 16:14, 1 June 2019 (UTC)
 * If the value assigned to any of lay-summary, laysummary, and lay-url is not a url, the module knows that and emits an error message:


 * —Trappist the monk (talk) 16:29, 1 June 2019 (UTC)
 * Yeah, get rid of those things. AWB/bot runs could clear the backlog and then these parameters fully removed by the next update. &#32; Headbomb {t · c · p · b} 23:29, 23 June 2019 (UTC)
 * Most are already gone. There are a few that may have survived or been added since the purge.  Those few that remain will collect in  after the next update
 * —Trappist the monk (talk) 23:43, 23 June 2019 (UTC)