Help talk:Citation Style 1/Archive 57

This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

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)

In

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

{{cite web/new |title=Title |website=''Website'' |url=//example.com}}

"Title". Website. {{cite web}}: Italic or bold markup not allowed in: |website= (help)

'"`UNIQ--templatestyles-00000006-QINU`"'<cite class="citation web cs1">[//example.com "Title"]. ''Website''.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=unknown&rft.jtitle=Website&rft.atitle=Title&rft_id=%2F%2Fexample.com&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+57" class="Z3988"></span> <span class="cs1-visible-error citation-comment"><code class="cs1-code">{{[[Template:cite web|cite web]]}}</code>: </span><span class="cs1-visible-error citation-comment">Italic or bold markup not allowed in: <code class="cs1-code">&#124;website=</code> ([[Help:CS1 errors#apostrophe_markup|help]])</span>

{{cite book/new |title=Title |publisher=''Publisher''}}

Title. Publisher. {{cite book}}: Italic or bold markup not allowed in: |publisher= (help)

'"`UNIQ--templatestyles-0000000A-QINU`"'<cite class="citation book cs1">''Title''. Publisher.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Title&rft.pub=Publisher&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+57" class="Z3988"></span> <span class="cs1-visible-error citation-comment"><code class="cs1-code">{{[[Template:cite book|cite book]]}}</code>: </span><span class="cs1-visible-error citation-comment">Italic or bold markup not allowed in: <code class="cs1-code">&#124;publisher=</code> ([[Help:CS1 errors#apostrophe_markup|help]])</span>

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 | 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-<periodical>= and |trans-<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)

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. -- GreenC 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-<periodical>= for non-Latin languages might prompt a definitive decision with regard to what should and what should not be italicized in citations, 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:

cite web 7 December 2004

cite journal 4 February 2005

citation 15 November 2005

cite news 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 |workitalics=no; a properties flag like |work=WGBH-TV $i; or an optional work argument such as |iwork=WGBH-TV. All of these are clumsy I admit but the first step is consider ideas. With |work=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. -- GreenC 01:03, 8 May 2019 (UTC)

Further ideas, similar to '$i' use a template called {{csc|itoff}} 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. |work=WGBH-TV {{csc|itoff}}. 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. -- GreenC 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:

|website=((''[[CNN]]''))

would render as: CNN

Without that markup, apostrophe markup would be removed so:

|website=''[[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 |website=''[[CNN]]'' to |website=[[CNN]], convert to |website=((''[[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. -- GreenC 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 {{cite journal}} 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 rft.pub) 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 {{

cite techreport

}} but not otherwise documented

|newsgroup= – for {{cite newsgroup}}

If we continue with the process we will:

1. ignore italic wiki markup in the |<periodical>= parameters and |publisher=; the module shall emit an appropriate error message when it does this
2. add support for use-this-parameter-value-as-written ((...)) markup in |<periodical>= parameters (|publisher= is never italicized)
3. add support for |script-<periodical>= and |trans-<periodical>=
4. add error message for periodical templates without periodical parameter (and attendant category and help text)
5. 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 |<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 Mandruss 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 |<periodical>= anytime |url= has a value. - Paul^T+/_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 |<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 {{cite web}} so you must be talking about the periodical parameters in {{cite journal}}, {{cite news}}, {{cite magazine}}.

—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

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+/_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 |<periodical>=. I'm on board with that and have been arguing that point at length. However, allowing the ((...)) markup in |<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+/_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 |<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 |<periodical>= ever) and force the debate?

To directly answer your question... the point is to better comply with

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 |<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 |<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+/_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
  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 |<periodical>= parameters and |publisher=; the module shall emit an appropriate error message when it does this

'"`UNIQ--templatestyles-0000003C-QINU`"'<cite class="citation book cs1">''Title''. Publisher.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Title&rft.pub=Publisher&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+57" class="Z3988"></span> <span class="cs1-visible-error citation-comment"><code class="cs1-code">{{[[Template:cite book|cite book]]}}</code>: </span><span class="cs1-visible-error citation-comment">Italic or bold markup not allowed in: <code class="cs1-code">&#124;publisher=</code> ([[Help:CS1 errors#apostrophe_markup|help]])</span>

'"`UNIQ--templatestyles-00000043-QINU`"'<cite class="citation news cs1">"Title". ''Newspaper''.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=article&rft.jtitle=Newspaper&rft.atitle=Title&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+57" class="Z3988"></span> <span class="cs1-visible-error citation-comment"><code class="cs1-code">{{[[Template:cite news|cite news]]}}</code>: </span><span class="cs1-visible-error citation-comment">Italic or bold markup not allowed in: <code class="cs1-code">&#124;newspaper=</code> ([[Help:CS1 errors#apostrophe_markup|help]])</span>

I chose the error message because, you know, clever editors will try <i>...</i> and (I suspect less likely) <b>...</b> 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 |<periodical>= parameters (|publisher= is never italicized)

'"`UNIQ--templatestyles-0000004A-QINU`"'<cite class="citation book cs1">''Title''. ((Publisher)).</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Title&rft.pub=%28%28Publisher%29%29&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+57" class="Z3988"></span> <span class="cs1-visible-error citation-comment"><code class="cs1-code">{{[[Template:cite book|cite book]]}}</code>: </span><span class="cs1-visible-error citation-comment">Italic or bold markup not allowed in: <code class="cs1-code">&#124;publisher=</code> ([[Help:CS1 errors#apostrophe_markup|help]])</span>

'"`UNIQ--templatestyles-00000051-QINU`"'<cite class="citation news cs1">"Title". ''((Newspaper))''.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=article&rft.jtitle=%28%28Newspaper%29%29&rft.atitle=Title&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+57" class="Z3988"></span> <span class="cs1-visible-error citation-comment"><code class="cs1-code">{{[[Template:cite news|cite news]]}}</code>: </span><span class="cs1-visible-error citation-comment">Italic or bold markup not allowed in: <code class="cs1-code">&#124;newspaper=</code> ([[Help:CS1 errors#apostrophe_markup|help]])</span>

In the case of |publisher=((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:

{{cite book/new |title=Title |publisher=((Publisher))}}

Title. ((Publisher)).

'"`UNIQ--templatestyles-00000055-QINU`"'<cite class="citation book cs1">''Title''. ((Publisher)).</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Title&rft.pub=%28%28Publisher%29%29&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+57" class="Z3988"></span>

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 |script-<periodical> and |trans-<periodical>

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-<parameter>= parameters use / will use the same function:

All articles with these error messages will be collected in Category:CS1 errors: script parameters

As part of this change, I have added |script-<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=.

{{Cite news/new |title=Title |newspaper=Newspaper}}

"Title". Newspaper.

{{Cite news/new |title=Title |script-newspaper=zh:Script_Newspaper}}

"Title". Script_Newspaper.

{{Cite news/new |title=Title |newspaper=Newspaper |script-newspaper=zh:Script_Newspaper}}

"Title". Newspaper Script_Newspaper.

{{Cite news/new |title=Title |trans-newspaper=Trans_newspaper}}

"Title". [Trans_newspaper]. {{cite news}}: |trans-periodical= requires |periodical= or |script-periodical= (help)

{{Cite news/new |title=Title |newspaper=Newspaper |trans-newspaper=Trans_newspaper}}

"Title". Newspaper [Trans_newspaper].

{{Cite news/new |title=Title |script-newspaper=zh:Script_Newspaper |trans-newspaper=Trans_newspaper}}

"Title". Script_Newspaper [Trans_newspaper].

{{Cite news/new |title=Title |newspaper=Newspaper |script-newspaper=zh:Script_Newspaper |trans-newspaper=Trans_newspaper}}

"Title". Newspaper Script_Newspaper [Trans_newspaper].

—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)

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 |dead-url=unfit-verified and |dead-url=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 |dead-url=unfit to many cs1|2 templates that it touched. See this discussion. The bot operator discussion mentioned there is this discussion. The solution to that problem was to implement a new keyword bot: unknown. See 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 unfit-verified, usurped-verified. What then? Drop these from Category:CS1 maint: Unfit url 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 Category:CS1 maint: BOT: original-url status unknown?

—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 unfit-verified, usurped-verified then use of these values removes the article from Category:CS1 maint: Unfit url. 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 unfit-verified or usurped-verified if the status is correct.

Sadly Category:CS1 maint: BOT: original-url status unknown looks like a large manual checking exercise. Nthep (talk) 16:53, 22 May 2019 (UTC)

I came across an instance where something like "|pages=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

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: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+/_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 |pages=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:

{{cite journal |journal=Journal of Page Numbering |pages=((1,234–1,256)) |title=Title}}

"Title". Journal of Page Numbering: 1,234–1,256.

the ((...)) markup can apply to the whole of the parameter value or to individual elements – the second page in the list is hyphenated:

{{cite journal |journal=Journal of Page Numbering |pages=1,((234-1)),256)) |title=Title}}

"Title". Journal of Page Numbering: 1, 234-1, 256. – second element is rendered as a single hyphenated page

without the ((...)) markup

{{cite journal |journal=Journal of Page Numbering |pages=1,234–1,256 |title=Title}}

"Title". Journal of Page Numbering: 1, 234–1, 256. – 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 1(,)000% 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 or elsewhere? - Paul^T+/_C 12:02, 8 May 2019 (UTC)

Also note, this feature doesn't seem to work with the |page= parameter. - Paul^T+/_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. <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:

{{Citation
 |last1= Weaver |first1= C. E.
 |date= 1 December 1939
 |title= Metchosin volcanic rock in Oregon and Washington [abstract]
 |journal= [[Geological Society of America Bulletin]]
 |volume= 50 |issue= 12, part 2 |page= ((1,961))
 |doi=10.1130/GSAB-50-1945
}}

I changed it to:

{{Citation
 |last1= Weaver |first1= C. E.
 |date= 1 December 1939
 |title= Metchosin volcanic rock in Oregon and Washington [abstract]
 |journal= [[Geological Society of America Bulletin]]
 |volume= 50 |issue= 12, part 2 |page= 1,961
 |doi=10.1130/GSAB-50-1945
}}

The ((...)) notation is not required for |page=, but it was confusing that the two parameters didn't work similarly in this instance. - Paul^T+/_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:

{{cite book |title=Title |chapter=Chapter |page=10-5}}

"Chapter". Title. p. 10-5.

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+/_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 13727 AD, Vega will be the northern pole star).

That text is a result of this this discussion and is a derivation of wording added to MOS:DIGITS at this edit. 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 may not separate 4-digit page/year numbers. They must 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 MUST NOT 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 4-digit page/year numbers MUST NOT be separated works great. It is simple and to the point (probably could lose the caps and emphasis though). - Paul^T+/_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 |pages=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 |pages=((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+/_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? ♦ 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+/_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? ♦ 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 hyphen_to_dash():

local pre;
local post;

pre, post = mw.ustring.match (str, '^(%d%d%d?,?%d%d%d) *[%-–] *(%d%d%d?,?%d%d%d)$');

if pre then										-- pre is nil when no match
	local pre1 = pre:gsub(',', '');				-- strip commas
	local post1 = post:gsub(',', '');


	if tonumber (pre1) < tonumber (post1) then	-- left to right, lesser to greater
		return pre .. '–' .. post;				-- reassemble; use correct separator without space
	end
end

This fix, if implemented does not handle the four-digit to five-digit boundary-crossing case (|pages=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. ♦ 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. ♦ 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)

We have a template {{

{{cite citeseerx}} is treated like {{

—Trappist the monk (talk) 13:03, 23 May 2019 (UTC)

@Trappist the monk: 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:

{{cite citeseerx |last1=Lundblad |first1=Niklas |title=Privacy in a Noisy Society |citeseerx=10.1.1.67.965}}

Lundblad, Niklas. "Privacy in a Noisy Society".

CiteSeerX 10.1.1.67.965

.

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 {{Citation Style documentation/cs1}} or {{Citation Style 1}} 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)

@Trappist the monk: 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 (with this edit) that the template is currently used in only one article. Write some documentation for it. Include it in {{Citation Style documentation/cs1}} and {{Citation Style 1}}. 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:

• {{cite article}} (2007) → {{cite news}}
• {{cite document}} (2010) → {{cite journal}}
• {{
  cite newspaper}} (2008) → {{cite news
  }}
• {{
  cite paper}} (2006) → {{cite journal
  }}
• {{
  cite work}} (2012) → {{cite book
  }}

The others that you named with year of creation:

• {{cite book}} – 2006
• {{cite conference}} – 2006
• {{cite journal}} – 2005
• {{cite magazine}} – 2006 (as a redirect), 2015 as a template
• {{cite news}} – 2006

And, for completeness, the rest of the cs1|2 templates and year of creation:

• {{cite arXiv}} – 2006
• {{cite AV media}} – 2005
• {{cite AV media notes}} – 2006
• {{cite bioRxiv}} – 2017
• {{
  cite citeseerx
  }} – 2017
• {{cite encyclopedia}} – 2005
• {{cite episode}} – 2007
• {{cite episode}} – 2006
• {{cite mailing list}} – 2007
• {{cite map}} – 2007
• {{cite newsgroup}} – 2006
• {{cite podcast}} – 2006
• {{cite press release}} – 2006
• {{cite report}} – 2008
• {{cite serial}} – 2007
• {{cite sign}} – 2006
• {{cite speech}} – 2006
• {{
  cite techreport
  }} – 2006
• {{cite thesis}} – 2009
• {{cite web}} – 2004
• {{Citation}} – 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 {{cite bioRxiv}} and {{cite citeseerx}}, both created in 2017.

—Trappist the monk (talk) 13:20, 27 May 2019 (UTC)

Really, {{

b

} 01:39, 31 May 2019 (UTC)

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#Format size 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)

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 yes and no with dead and live.

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 T224807 -- GreenC 15:54, 1 June 2019 (UTC)

To clarify, we are increasing complexity from two possibles:

|dead-url=yes

|dead-url=no

To six possibilities:

|dead-url=yes

|dead-url=no

|url-status=yes

|url-status=no

|url-status=dead

|url-status=live

(plus bot: unknown, usurped and unfit and aliases without the dash) -- GreenC 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 |url-status=yes and |url-status=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 |dead-url=yes to |url-status=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. -- GreenC 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#Cite uses deprecated parameter |<param> 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).

1. 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=
2. the bot task that I mentioned at the top of this discussion is written
3. 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. -- GreenC 01:22, 2 June 2019 (UTC)

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? -- GreenC 19:39, 3 June 2019 (UTC)

I guess another possibility is |format=addlarchives in {{webarchive}} which can support multiple archives. -- GreenC 12:23, 5 June 2019 (UTC)

• Carroll LM, Gaballa A, Guldimann C, Sullivan G, Henderson LO, Wiedmann M (May 2019). "Identification of Novel Mobilized Colistin Resistance Gene mcr-9 in a Multidrug-Resistant, Colistin-Susceptible Salmonella enterica Serotype Typhimurium Isolate". mBio. 10 (3): e00853–19.
  PMID 31064835
  .

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)

@Boghog: 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)

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:

{{cite journal |title=Title |journal=Journal |url=http://www.example.com/Article |url-access=subscription |doi=10.99999/bogus.doi.article |doi-access=free}}

"Title". Journal.

doi:10.99999/bogus.doi.article. {{cite journal}}: Check |doi= value (help

)

{{cite wikisource|Sense and Sensibility|Jane Austen}}

Jane Austen. Sense and Sensibility  – via Wikisource.

{{cite book |title=Title |url=http://example.com/title.pdf}}

Title (PDF).

Modern renders http: and https: urls differently:

http://www.example.com → http://www.example.com – the generic external link icon

https://www.example.com → 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] → //doi.org/10.99999%2Fbogus.doi.article

In the wikisource citation, Module:Citation/CS1 creates an https: 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:

• Cologne Blue
• MinervaNeue
• MonoBook
• Timeless
• Vector (default)

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?

—Trappist the monk (talk) 12:32, 10 June 2019 (UTC)

Probably related to the discussion at MediaWiki_talk:Common.css/Archive_18#PDF_rules_(pt_1), 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 a.external {
	/* @embed */
	background: url( images/external.png ) center right no-repeat;
	padding-right: 13px;
}

#mw_content a.external[ href^='https://' ],
.link-https {
	/* @embed */
	background: url( images/lock_icon.gif ) center right no-repeat;
	padding-right: 16px;
}

#mw_content a.external[ href^='mailto:' ],
.link-mailto {
	/* @embed */
	background: url( images/mail_icon.gif ) center right no-repeat;
	padding-right: 18px;
}

#mw_content a.external[ href^='news:' ] {
	/* @embed */
	background: url( images/news_icon.png ) center right no-repeat;
	padding-right: 18px;
}

#mw_content a.external[ href^='ftp://' ],
.link-ftp {
	/* @embed */
	background: url( images/file_icon.gif ) center right no-repeat;
	padding-right: 18px;
}

#mw_content a.external[ href^='irc://' ],
#mw_content a.external[ href^='ircs://' ],
.link-irc {
	/* @embed */
	background: url( images/discussionitem_icon.gif ) center right no-repeat;
	padding-right: 18px;
}

#mw_content a.external[ href$='.ogg' ],
#mw_content a.external[ href$='.OGG' ],
#mw_content a.external[ href$='.mid' ],
#mw_content a.external[ href$='.MID' ],
#mw_content a.external[ href$='.midi' ],
#mw_content a.external[ href$='.MIDI' ],
#mw_content a.external[ href$='.mp3' ],
#mw_content a.external[ href$='.MP3' ],
#mw_content a.external[ href$='.wav' ],
#mw_content a.external[ href$='.WAV' ],
#mw_content a.external[ href$='.wma' ],
#mw_content a.external[ href$='.WMA' ],
.link-audio {
	/* @embed */
	background: url( images/audio.png ) center right no-repeat;
	padding-right: 13px;
}

#mw_content a.external[ href$='.ogm' ],
#mw_content a.external[ href$='.OGM' ],
#mw_content a.external[ href$='.avi' ],
#mw_content a.external[ href$='.AVI' ],
#mw_content a.external[ href$='.mpeg' ],
#mw_content a.external[ href$='.MPEG' ],
#mw_content a.external[ href$='.mpg' ],
#mw_content a.external[ href$='.MPG' ],
.link-video {
	/* @embed */
	background: url( images/video.png ) center right no-repeat;
	padding-right: 13px;
}

#mw_content a.external[ href$='.pdf' ],
#mw_content a.external[ href$='.PDF' ],
#mw_content a.external[ href*='.pdf#' ],
#mw_content a.external[ href*='.PDF#' ],
#mw_content a.external[ href*='.pdf?' ],
#mw_content a.external[ href*='.PDF?' ],
.link-document {
	/* @embed */
	background: url( images/document.png ) center right no-repeat;
	padding-right: 12px;
}

#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 Help talk:External link icons § Were these icons useful?, 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)

Please comment. The outcome of this discussion could greatly impact our ability to cleanup articles.

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

{{cite map |map-url = http://www.traillink.com/trail-maps/fred-meijer-m-6-trail.aspx |map = Fred Meijer M-6 Trail |title = TrailLink |publisher = Rails-to-Trails Conservancy |author = Google |access-date = September 19, 2010 |date = September 19, 2010 |url-access=registration }}

Google (September 19, 2010). "Fred Meijer M-6 Trail" (Map). TrailLink. Rails-to-Trails Conservancy. Retrieved September 19, 2010. {{cite map}}: |author= has generic name (help); |url-access= requires |url= (help)

Fixed I think, in the sandbox:

The usual error detection applies:

{{cite map/new |map=Map |map-url=//example.com |map-url-access=free}}

"Map" (Map). Title. {{cite map}}: Invalid |map-url-access=free (help)

{{cite map/new |map=Map |map-url-access=subscription}}

"Map" (Map). Title. {{cite map}}: |map-url-access= requires |map-url= (help)

|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)

@Trappist the monk: I don't know of any, no. Imzadi 1979 → 00:58, 13 June 2019 (UTC)

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 {{cite news}}, it is not a cs1 template so unless we intentionally decide to redirect all 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)

{{cite news}} 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)

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 |embargo=201X-XX-XX'. If you just want a different URL than the PMC one, then just specify that URL in |url= instead.

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

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:OWN the module. --Izno (talk

) 12:46, 16 May 2019 (UTC)

@Trappist the monk: 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

WP:MED is insulting the intelligence of the average reader. Boghog (talk

) 19:00, 16 May 2019 (UTC)

• Bannen, RM; et al. (2008). "Optimal design of thermally stable proteins". Bioinformatics. 24 (20): 2339–2343.
  PMC 2562006
  .

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.

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 |url=doi or similar (e.g. |auto-url=doi as an override.

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 |doi-access=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 |hdl-access=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 |url=https:... or with |auto-url=hdl or similar.

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)

|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 -url (|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.

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 Category:CS1 errors: deprecated parameters after the next update

—Trappist the monk (talk) 23:43, 23 June 2019 (UTC)