Help talk:Citation Style 1

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

update to the cs1|2 module suite weekend of 20–21 April 2019

I propose to update the cs1|2 module suite sometime on the 20–21 April 2019 weekend. The changes are:

to Module:Citation/CS1:

• support auto-date-formatting (discussion)
  • requires update to User:Ohconfucius/script/MOSNUM_dates.js from User:Trappist the monk/script/MOSNUM_dates.js (this is a blocking requirement) Y
  • {{use dmy dates}} and {{use mdy dates}} documentation update suggested
• support |transcript= for {{cite AV media}} (discussion)
• add |display-contributors= and |display-translators=, refactor et al check (discussion)
• move et al and editor markup patterns to Module:Citation/CS1/Configuration
• make editorship of a work explicit when used with an authored work (discussion)
• move missing pipe from maintenance to error; display where the missing pipe is (discussion)
  • move explicit et al from maintenance to error
  • detect et al in |editors=
  • better error messaging
  • Category:CS1 errors: missing author or editor moves to Category:CS1 errors: missing name
• tweak is_pdf() to detect html entity fragment delimiter (discussion)
• support single letter second-level domain names for .today tld (discussion)

to Module:Citation/CS1/Configuration:

• support auto-date-formatting
• move |host= from alias of |authors= to alias of |last= (discussion)
• add uz for |script-title=
• move et al patterns, editor_markup_patterns from main module
• move missing pipe from maintenance to error; display where the missing pipe is
• move explicit et al from maintenance to error
• tweak etal patterns (discussion)

to Module:Citation/CS1/Whitelist:

• allow numbered |host#= parameters
• deprecate |subscription= and |registration= (discussion)
• support |displayauthors in limited_basic_arguments list (discussion)

to Module:Citation/CS1/Date validation:

• support auto-date-formatting

to Module:Citation/CS1/Identifiers:

• detect presence of mw:Extension:Wikibase_Client/Lua (discussion)
• more accurate inactive DOI category (discussion)

—Trappist the monk (talk) 15:37, 14 April 2019 (UTC)

Required auto date formatting interface protected edit request made.

—Trappist the monk (talk) 16:17, 14 April 2019 (UTC)

Subscription

@Trappist the monk: Why are subscription= and registration= now deprecated? Where was the discussion to make them deprecated? Who determined they were not of use to specify that a subscription is required to access the full version of an article or journal? You linked to a discussion, where you only said you would be removing it without justifying why. Shouldn't this have been a consensus matter? Ss112 15:07, 20 April 2019 (UTC)

@Ss112: They are deprecated in favor of |url-access=. See Help:CS1#Registration or subscription required and subsections. --Izno (talk) 15:14, 20 April 2019 (UTC)

The problem with |subscription= and |registration= is that they are vague, non-specific parameters. Functionality of these two parameters with greater specificity is provided by |url-access= and related parameters. It is, unfortunately, all too common for editors to use these parameters for urls other than |url=. It is legitimate for a citation to have, for example, both |url= and |section-url=; one source may be behind a paywall while the other source is not (they don't have to link into the same domain); it is not possible for |subscription= and |registration= to specify which is which but |url-access= and |section-url-access= can.

Replacement of words, which as most of the users of Wikipedia can read English, are useful to most users with one of a series of tiny almost identical icons of which the meaning isn't at all clear is a terrible idea, which makes the reference harder to read and understand. And defacing articles with unsightly error messages to try and force this reader- and editor-unfriendly system on articles is a worse idea. This change should be reverted.Nigel Ish (talk) 20:10, 24 April 2019 (UTC)

I'll get round to updating the help text in a bit.

—Trappist the monk (talk) 15:22, 20 April 2019 (UTC)

@Trappist the monk: In the future, perhaps we can migrate the parameters before deprecating them. One editor just flat out removed a previously non-ambiguous use of "subscription".—Bagumba (talk) 01:13, 21 April 2019 (UTC)

Do I understand that you are volunteering for that migration task next time we have a deprecation? If so, then great; keep an eye on this talk page (though I don't anticipate that we will be deprecating anything anytime soon). It appears to me that Editor Mill 1 didn't properly understand what deprecation means but I see that you and another editor provided appropriate guidance so those problems caused by Editor Mill 1 have been resolved. Thank you for that.

There really is no pre-deprecation step in our process of abandoning a parameter. After the decision is taken to abandon a parameter in favor of something better or more useful, the first step is deprecation. The parameter still works. For me, it is preferable that we show an error message for these two parameters so that editors who care about an article can review their sources and perhaps replace restricted sources with something better that doesn't lurk behind a paywall. That is better than any old someone doing a drive-by edit with awb or some other script (and yeah, that will happen).

—Trappist the monk (talk) 10:34, 21 April 2019 (UTC)

@Trappist the monk: My bad. I mistook deprecated for removed.—Bagumba (talk) 10:49, 21 April 2019 (UTC)

Trappist the monk, is there some middle ground that I'm not aware of between |subscription= / |registration= and |url-access=? What I mean is, since the former are deprecated, it means that, for example, a journal cited without a URL but with a DOI parameter can no longer include any indication (that I'm aware of) that says the source requires a subscription. JSTOR, for example, requires a subscription, but without the URL included, |url-access= gives a "requires URL" error. Hopefully that made sense -- and apologies if this has been addressed and I missed it. – Broccoli & Coffee ^{(Oh hai)} 20:05, 26 April 2019 (UTC)

Sources linked through identifiers, |jstor=, |doi=, etc typically lie behind a paywall. Because that is the normal case, we do not highlight that norm so cs1|2 does not support subscription / registration icons for those identifiers. For the occasional cases where the identifier-linked source is free-to-read, use |doi-access=free and the like. |url= is the opposite; sources linked by |url= (and |chapter-url= and aliases) are normally free-to-read. When they are not, |url-access=subscription (also registration and limited) can be used.

—Trappist the monk (talk) 20:46, 26 April 2019 (UTC)

Thanks, that does make sense. – Broccoli & Coffee ^{(Oh hai)} 21:23, 26 April 2019 (UTC)

Parameter: |subscription

Deprecated? When? Where? Why? All these things I am yet to know! But seriously, what's the story? ——SerialNumber54129 19:26, 22 April 2019 (UTC)

I think that this is answered at Help talk:Citation Style 1#update to the cs1|2 module suite weekend of 20–21 April 2019.

—Trappist the monk (talk) 19:36, 22 April 2019 (UTC)

Interesting discussion—about a lack of discussion! :p ——SerialNumber54129 09:53, 23 April 2019 (UTC)

The linked conversation was a very brief summary. There was an RFC the closing summary of which says:

• Aspect B3 (Deprecating/eliminating/supporting old and new systems): There is a clear preference to Deprecate the old system.

|subscription= and |registration= are the 'old system'.

—Trappist the monk (talk) 13:59, 23 April 2019 (UTC)

Broken citation module

Tracked in Phabricator
Task T221625

Screenshot of the error

The citation plugin in VE seems to be broken at this time. Adding a plain URL (such as this one) to the Citoid field or to a regular (manual) citation template field results in the following error:

Lua error in Module:Citation/CS1/Configuration at line 458: attempt to index local 'content' (a nil value)").

Please fix this, this may affect every Wikipedia user trying to add a reference in visual editing mode.--DarTar (talk) 03:03, 23 April 2019 (UTC)

It appears that the problem only occurs when creating a new page. Editing an existing page seems to work just fine.--DarTar (talk) 04:37, 23 April 2019 (UTC)

I tested this locally, the bug in the preview seems to have been introduced by the most recent change here as reverting it fixes it: https://en.wikipedia.org/w/index.php?title=Module%3ACitation%2FCS1&type=revision&diff=893307475&oldid=879151028 Mvolz (WMF) (talk) 08:00, 23 April 2019 (UTC)

Looks like the issue is that there is no mw.title.getCurrentTitle():getContent() when a page is being created; but that is checked in the function get_date_format in Module:Citation/CS1/Configuration to figure out the date format (this feature was indeed added in the last update). Galobtter (pingó mió) 08:05, 23 April 2019 (UTC)

I abhor ve so don't use it. If I create a new page in main space and add a simple {{cite book}} template to that page using the wikisource editor and preview that new page, no error. That suggests to me that the problem isn't with this module suite but rather it is with ve, with the preview mechanism, or with Scribunto. Just because this module reveals the problem does not make it the source of the problem.

We can, I suspect, mask the problem by writing:

local content = mw.title.getCurrentTitle():getContent() or '';

but that is possibly just a mask and not a proper fix. —Trappist the monk (talk) 11:34, 23 April 2019 (UTC)

It looks like VE is passing a page title value when generating the rendering, so there may be an issue with Parsoid passing the right context to Lua. Investigating that issue might take a while, so in the meantime we should apply the or ''; fix. ESanders (WMF) (talk) 14:11, 23 April 2019 (UTC)

The underlying issue is tracked as phab:T221625. ESanders (WMF) (talk) 14:18, 23 April 2019 (UTC)

So I misread that as a missing title, but actually getContent() is getting the full wikitext content of the page. I imagine this is expected behaviour in the Lua module that pages that don't exist, or haven't been previewed yet, return 'nil' for getContent. As VE is rendering these previews async against the last saved version of the page, this gadget should handle the case where getContent() returns nil. ESanders (WMF) (talk) 14:24, 23 April 2019 (UTC)

Answered at phabricator.

—Trappist the monk (talk) 15:10, 23 April 2019 (UTC)

Deprecated subscription=

This section gives cryptic advice, and my efforts to follow that advice generated more errors in the citation. Template:Cite news#Deprecated gives a list of odd-looking terms in place of url= when subscription=yes had been used for a newspaper citation. In specific, in the Natzweiler-Struthof article on the concentration camp, there is a ref to the New York Times of 10 Oct 1945, title=Kramer persists in denying guilt. It had an error message because it used the subscription=yes parameter. Now I have a subscription to the New York Times, so I do not know what a person sees who does not have one, if they click the link. I tried using article-url-access= for the New York Times article, and that generated error messages saying accessdate needs url, among other messages. As far as I understand, the New York Times does still require a subscription for much access to its articles; I know it was counting articles for me in 2018, and I had exceeded the count so access was blocked, and thus I decided in early 2019 to get a subscription. Can someone please expand the table at Deprecated to say when those various parameters need to be used? It is not obvious to me. I do not want to test each one in succession to learn that. Now the reference uses url= for the link to the image of the old article and generates no error messages as to format. Should I be adding a template with subscription required, from Template:Subscription required? --Prairieplant (talk) 03:46, 24 April 2019 (UTC)

en.wiki readers who do not have subscriptions to The New York Times see a prompt for subscriber credentials and a link to purchase a subscription.

The access date and other errors happened at this edit which replaced |url= with |article-url-access= in a citation that was not the 1945 NYT article (the result). The |xxx-url-access= parameters are not replacements for |xxx-url= but are, instead, replacements for |subscription= and |registration=.

Here is the original New York Times citation with |subscription=:

{{cite news |title=Kramer Persists in Denying Guilt |url=http://timesmachine.nytimes.com/timesmachine/1945/10/10/issue.html |subscription=yes |accessdate=19 September 2015 |work=The New York Times |issue=Vol. XCV, No. 32,036 |publisher=The New York Times Company |date=10 October 1945 |page=8}}

"Kramer Persists in Denying Guilt". The New York Times. No. Vol. XCV, No. 32, 036. The New York Times Company. 10 October 1945. p. 8. Retrieved 19 September 2015. {{cite news}}: |issue= has extra text (help); Unknown parameter |subscription= ignored (|url-access= suggested) (help)

The |xxx-url-access= parameters each match a |xxx-url= parameter. Your example citation doesn't use |article-url= because that parameter is not supported by {{cite news}}:

{{cite news |title=Kramer Persists in Denying Guilt |article-url=http://timesmachine.nytimes.com/timesmachine/1945/10/10/issue.html |accessdate=19 September 2015 |newspaper=The New York Times |date=10 October 1945 |page=8}}

"Kramer Persists in Denying Guilt". The New York Times. 10 October 1945. p. 8. Retrieved 19 September 2015. {{cite news}}: |article-url= ignored (help)

The example citation does use |url= so the proper access parameter is |url-access=

{{cite news |title=Kramer Persists in Denying Guilt |url=http://timesmachine.nytimes.com/timesmachine/1945/10/10/issue.html |url-access=subscription |accessdate=19 September 2015 |newspaper=The New York Times |date=10 October 1945 |page=8}}

"Kramer Persists in Denying Guilt". The New York Times. 10 October 1945. p. 8. Retrieved 19 September 2015.

Yeah, documentation can always be made better. If you see a way to improve our documentation please do so.

—Trappist the monk (talk) 11:42, 24 April 2019 (UTC)

Trappist the monk Thank you! I can remember that, a parameter in place of subscription, but includes url, and use it in another article that has a ref to the Oxford Dictionary of National Biography. I have never put anything before url, so xxx-url is wholly new to me. I think simple examples for the common places with subscription =yes would help. showing that the lock icon will appear in the ref on the page people read would be very helpful. My reaction was to take things away until the error message went away. I am most familiar with newspapers with limits, and now the Oxford Dictionary of National Biography, and just a few others encountered as I found them. --Prairieplant (talk) 12:39, 24 April 2019 (UTC)

Although it needs to be rewritten to bring it more in line with cs1|2, for ODNB, there is {{cite ODNB}}.

—Trappist the monk (talk) 13:07, 24 April 2019 (UTC)

Trappist the monk I would never find that example when I am hunting down how to fix an error message. Perhaps someone could go into the template that makes the table about the Deprecated, and arrange it so that it is clear that the word registration or subscription FOLLOWS the new parameters? It was confusing in the first place to see url and it does not mean the url itself, rather a sideways reference to the url. It took the conversation with you for me to see that it is written above the |url-access to have one of those two words follow the brand new parameter (new to me, anyway). When there are too many choices, for me, it would be helpful to show the exact order in the Deprecated box, what to use now, that is, url-access=subscription. This is a reversal of the order so long used, and I had no idea this topic was under discussion until error messages popped up in articles. Those are all my ideas. --Prairieplant (talk) 11:52, 25 April 2019 (UTC)

The deprecated parameter table is defined at Help:CS1 errors because it is transitory; once the deprecation period ends that table will be cleared until the next time we deprecate something. Feel free to edit that table. The basic subscription/registration documentation is at Template:Citation Style documentation/registration. Feel free to edit that.

For a very long time I have said that |dead-url= should be renamed to something else because the value that it takes is not a url but a keyword. I have never gotten much support for renaming it to something else, perhaps because I haven't yet found a better name; yeah, we could flip it to |url-dead= but that just doesn't sound write. This parameter, I think, is the only one like that. Got a suggestion for that?

—Trappist the monk (talk) 12:22, 25 April 2019 (UTC)

I think I have suggested |url-state= with possible values dead, live, and possibly also the HTML response #s (e.g. 404) which would enable machine checking (ru.WP allows HTML responses). Current values would be deprecated but could be bot-trivially replaced. --Izno (talk) 15:02, 25 April 2019 (UTC)

Previous conversations that suggest |url-state= or |url-status=:

Help talk:Citation Style 1/Archive 11#Suppressing unnecessary archive-urls

Help talk:Citation Style 1/Archive 19#deprecate |dead-url=?

Help talk:Citation Style 1/Archive 42#Correct usage of dead URL?

—Trappist the monk (talk) 15:30, 25 April 2019 (UTC)

|isdead-url= ? Nthep (talk) 16:21, 25 April 2019 (UTC)

Sorry, but I don't think that is a good name because in cs1|2, all url-holding parameters have names that end with -url. It is this that makes |dead-url= a poor name (editors regularly give that parameter the dead url as a value) and why so far, in my opinion, |url-status= might be preferred. We use |dead-url= for a variety of things so if possible we should retain the current keywords unfit, usurped, and bot: unknown (we would have to replace yes and no with dead (default) and live. Thank you for the suggestion. Got any others?

—Trappist the monk (talk) 23:20, 25 April 2019 (UTC)

I strongly concur with that, and would favor "url-status" as less ambiguous than "url-state" ("state" has too many other meanings). Having |dead[-]url= end with "url=" causes other problems, e.g. when cleaning up citations for consistency and readability: a mass change done to all the actual URL-providing parameters in the page ends up having to be reversed for the dead-url case.  — SMcCandlish ☏ ¢ 😼  20:37, 3 May 2019 (UTC)

Self transclusion

Why do the cite templates cause a page to transclude itself? Examples:

• Help talk:Citation Style 1
• User:Redrose64/Sandbox14

--Redrose64 🌹 (talk) 22:30, 25 April 2019 (UTC)

Module:Citation/CS1/Configuration has this at line 456:

local content = mw.title.getCurrentTitle():getContent() or '';				-- get the content of the article

The documentation for the getContent() title object says:

• getContent(): Returns the (unparsed) content of the page, or nil if there is no page. The page will be recorded as a transclusion.

Only way that I know of for a template to see what is outside the boundaries of its enclosing {{ and }}. This was done to support auto date formatting.

—Trappist the monk (talk) 23:03, 25 April 2019 (UTC)

This sounds expensive. Very expensive. If an article (such as Alodia) has 53 cite templates, that means that 54 copies of the article are being parsed in order to obtain one tiny setting. The article is 80,871 bytes, so it works out at over 4 MB. --Redrose64 🌹 (talk) 23:09, 25 April 2019 (UTC)

@Redrose64: That's not true; the parsing is in a mw.loadDataed submodule, so it only happens once per page. * Pppery * _{has returned} 23:15, 25 April 2019 (UTC)

See the auto date formatting discussion above. There I show that this mechanism while not cost-free, is very inexpensive.

—Trappist the monk (talk) 23:24, 25 April 2019 (UTC)

Trappist the monk, 200 ms difference with a 505 reference article. Impressive. —CYBERPOWER (Chat) 23:52, 25 April 2019 (UTC)

While I would like to take the credit for that, I cannot – I just implemented it after Editor Erutuon reminded me how Lua data tables work.

—Trappist the monk (talk) 23:58, 25 April 2019 (UTC)

Well regardless of whether you'd like to take credit or not, I want to thank you for making the change here! I'm ecstatic to not have to add |df=mdy-all/|df=dmy-all to a whole bunch of citations anymore!! - Paul^T+/_C 19:54, 6 May 2019 (UTC)

Vcite templates

Are templates like Template:Vcite2 journal and Module:ParseVauthors still necessary now that Module:Citation/CS1 natively supports a |vauthors= parameter? * Pppery * _{has returned} 23:25, 25 April 2019 (UTC)

I would say that these are no longer needed but you should ask Editor Boghog whose projects those were.

—Trappist the monk (talk) 23:30, 25 April 2019 (UTC)

I also agree that the template is no longer needed, but at the same time, I would like to preserve the rationale for the |vauthors= parameter. Any suggestions for how to do this? Boghog (talk) 17:48, 26 April 2019 (UTC)

As a subsection of Help:Citation Style 1#Authors?

—Trappist the monk (talk) 17:55, 26 April 2019 (UTC)

I would honestly prefer not to keep that rationale around on official documentation. Vauthors is really more of a hack to get medical Wikipedia authors on board; we'd prefer full names using |first= and |last= (and name author format parameter as desired) to allow reusers to pick whatever citation method they prefer, and having full names in the metadata/wikitext is the only way to do so. The "there's too many in the wikitext" was never a reasonable argument for me, and especially shouldn't be now given LDR (which can see mixed use in rarer cases where there are e.g. 50 authors). --Izno (talk) 18:54, 26 April 2019 (UTC)

The vast majority of the citations that use |vauthors= are also stored in the PubMed database. Wikipedia is not a reliable source for citation data as it frequently contains errors. It is much more reliable to down load citation data from PubMed and there are many convenient tools for doing so. Why is it necessary to store full first names in Wikipedia when it can easily (and more reliably) be obtained from PubMed if needed? Also many don't like LDR as it splits up the text from the sources that support the text.

|vauthors= is not a hack, but a very efficient way to store author data that reduces wiki text clutter. It also enforces consistency in how first names are displayed. Boghog (talk) 07:11, 27 April 2019 (UTC)

How first names (or any part of the names) are displayed is one thing (and I can accept that being editor optionable); storing the author metadata is different. I'm with Izno on this: full names, properly parsed ("last" name on which collation is done, and the rest as "first" name), should be standard.

I don't see how |vauthors= is "a very efficient way to store author data that reduces wiki text clutter." The "efficiency" of typing a few less characters is fairly insignificant in the broader context, and questionable in view of the loss of information. And wikitext clutter can be greatly reduced by not putting full citations into the text. (LDR is not the only alternative.) ♦ J. Johnson (JJ) (talk) 20:05, 27 April 2019 (UTC)

Fewer characters is more efficient. Furthermore, if you are not going to display full first names, why store them? The implication is that you might want to reuse the citations elsewhere and display full first names. However Wikipedia is not a reliable source for citation data. Better to copy the |pmid= and download the data from PubMed using one of the many tools available tools for this purpose. If we ever switch to a system where citations are retrieved from Wikidata, and if a particular citation is also stored in a reliable database such as PubMed, the data will be harvested from PubMed, not Wikipedia. Other alternatives such as WP:HARV are complex to set up and maintain. Harvard might make sense sense when a few sources are cited many times, but much less sense when most sources are cited only once. Boghog (talk) 04:00, 28 April 2019 (UTC)

Vcite format is very annoying when one is trying to determine which references by people named RS Smith are actually relevant for an article on Ruth S. Smith (who should probably have an article, by the way). Putting the longer author name into the template parameters and hiding it because reasons is at least better than not having it there at all. And the "efficiency" of typing fewer characters is bogus: you should be getting the bib data from a database of some sort, not typing it all again by hand, or else you're going to introduce lots of mistakes. —David Eppstein (talk) 04:51, 28 April 2019 (UTC)

|vauthors= is mainly used for biomedical citations indexed by PubMed. One probably would not be using |vauthors= with an author like Ruth S. Smith who is a librarian. |first= doesn't necessarily make it any easier finding an author since there are few restrictions on what is stored there. Wtih |vauthors=, the author format is at least consistent. Finally the efficiency has nothing to do with the number of characters typed. Of course, one would download the sources from a database like PubMed using ref tool bar, citoid, or similar tool. The efficiency has to do with the number of characters stored in the raw wiki text. Boghog (talk) 05:52, 28 April 2019 (UTC)

I'm not certain that the librarian Ruth S Smith is the same as the heavily-cited academic author Ruth S Smith, but that's not important. If I search Wikipedia for "Smith Ruth" or "Ruth S. Smith" or "Ruth Smith" I will probably find all of the instances that are the ones I'm looking for, and only a few off-topic hits. If I search for "Smith RS" who knows how many irrelevant things will turn up instead. And number of characters stored??? Are you out of your mind, or merely innumerate? The number of characters we're spending on this discussion alone probably outranks all the bytes you've supposedly saved in all of the articles you've written. And a single image file would be many times that. Maybe you need to go read WP:NOTPAPER again. —David Eppstein (talk) 06:33, 28 April 2019 (UTC)

Searching for authors with a common name such as Smith is not trivial, even when the full first name is included. A search for "Ruth Smith"~2 (proximity search allowing up to two words in between, order of words unimportant) returns 299 hits, a large majority of which are off-topic. A search for Smith RS, may not find what you are looking for either, but at least the list of hits that one must wade through is much shorter. The issue with efficiency is not the storage of characters, but rather trying to edit raw wiki text which is imbedded with bloated citation templates that make it more difficult to find the text you are trying to edit. WP:NOTPAPER also states there is an important distinction between what can be done, and what should be done. Boghog (talk) 07:38, 28 April 2019 (UTC)

I suspect that all of this back and forth over the good and bad of Vancouver-style is somewhat pointless. Yeah, in Candide's best of all possible worlds, all cs1|2 authors would be in |firstn= / |lastn= but, alas, that ideal world is not this world. I've just made an awb pass through 25k of the 30k articles that populate Category:CS1 maint: Multiple names: authors list. I was plucking off the low hanging fruit, some of which was conversion of Vancouver-style name-list assignments in |author=, |authors=, and |last= to |vauthors=.

Editors at en.wiki will write Vancouver-style name-lists so it seems prudent to me to acknowledge that, stop squabbling, document the advantages and the disadvantages in a common place, and then get on with life.

—Trappist the monk (talk) 18:39, 28 April 2019 (UTC)

Agree. Now, back to my original point; it is clear than these templates are not needed, shall I list them at TfD? * Pppery * _{has returned} 19:13, 28 April 2019 (UTC)

I don't see why not. Editor Boghog did agree that the template and module are no longer needed and can copy off the rationale to someplace and someone else can put the counter-rationale. Instances of {{vcite2 journal}} need to be renamed to {{cite journal}}.

—Trappist the monk (talk) 19:32, 28 April 2019 (UTC)

And TfD started. * Pppery * _{has returned} 19:48, 28 April 2019 (UTC)

Efficiency is always a proportion. Simply typing "fewer characters" at the outset is not "more efficient", because here it is also less information. It is arguable that the decrease of typing effort is less than the decrease of information, and therefore vcite style is less efficient (more effort relative to the information). And this is without factoring in any additional effort required further on. If people want vcite style, fine, but "more efficient" is a poor reason for doing so. ♦ J. Johnson (JJ) (talk) 19:54, 28 April 2019 (UTC)

Repeating what I wrote above, the reason is not to reduce typing. The reason is to reduce the size of bloated citation templates in the raw wiki text that make it more difficult to find text you are trying to edit. We will have to agree to disagree on the necessity of storing full first names. Time to move on. Boghog (talk) 01:16, 29 April 2019 (UTC)

If this bothers you, you could move the inline citations into the references block, so that the text in the article body becomes readable at source-code level again and the references can be easily maintained independent of the article body.

I hate it when I run into truncated or incomplete references. Wikipedia is WP:NOTPAPER...

People claiming "efficiency" often overlook that their efficiency often creates inconveniences or extra work for others...

--Matthiaspaul (talk) 18:51, 30 April 2019 (UTC)

Within the scope of Vancouver style citation format (a widely used style in biomedical journals) there is no truncation of information. The citation is complete. There is no need to add the full first name of the authors. In fact, doing so to an article where the Vancouver style authors has already been established would be a violation of WP:CITEVAR. Please note that citevar covers both how the citation is rendered as well as how the citation data is stored. Boghog (talk) 14:51, 1 May 2019 (UTC)

My remark was meant more generally, also regarding the habit of some to abbreviate journal names etc. Only providing an abbreviated first name may be allowed by the style guide but it is nevertheless backwards-oriented in an electronic encyclopedia on a planet with close to 8 billion humans and information travelling around the globe in seconds. Just like short passwords can be cracked in fractions of a second, abbreviated names are just no longer cutting it when it comes to reliably identifying an author. Ambiguity hinders interested readers when they try to find out more about an author and/or the topic. It is nice to emulate external style guides, but we are Wikipedia and moving forward we should not be shy to define our own rules if they serve our purposes better. --Matthiaspaul (talk) 20:54, 3 May 2019 (UTC)

If you are replying to me, as it appears by where you chose to place your comment, then you are arguing with the wrong person. I have made no comments at all regarding efficiency in this discussion.

—Trappist the monk (talk) 20:39, 28 April 2019 (UTC)

Yes, and sorry; my comment could have been indented better. My comment was regarding Boghog's "efficiency" argument. To which he responds that his point is not efficiency in typing, but clutter in the wikitext. And there I will agree that full citations in the text obscure the text. But the answer to that is not to make some very minimal reduction in the length of the full citation, but to move all full citations to their own section. The problem doing that is it requires the use of short-cites of some form, such as done with Harv templates, which is anathema to some editors. So I would say (in response to Pppery's query) that |vauthors= is not necessary, except as a slight (very slight, and even misguided) accommodation to the sensibilities of some editors. Mind, I am not necessarily against such accommodations, but we should be clear on why we do so. ♦ J. Johnson (JJ) (talk) 19:59, 29 April 2019 (UTC)

I was not asking whether |vauthors= was necessary, only whether it was necessary to have special templates for it when the main template already supported it. * Pppery * _{has returned} 20:03, 29 April 2019 (UTC)

Indeed. And then the discussion slid into the rationale for the vauthors parameter. ♦ J. Johnson (JJ) (talk) 21:14, 29 April 2019 (UTC)

I agree that the separate templates are not necessary, and concur strongly with Izno ("vauthors is really more of a hack to get medical Wikipedia authors on board; we'd prefer full names using |first= and |last="). If Boghog's point is de-hyperbolized, it is correct that WP:CITEVAR permits use of Vancouver or any other citation style, and that changing the style at an article with an established and consistent citation style is discouraged, without a consensus discussion first. (CITEVAR is often misinterpreted as a "once a style it set, it cannot be changed rule", and is nothing of the sort; worse, it's even misconstrued as a "whoever set the style in the first major edit has more say in how the article should develop, moving forward" rule, which is just flatly against WP:OWN] and WP:EDITING policies). However, this doesn't mean we need stand-alone templates for Vancouver citation formatting, or even that CS1/CS2 should support any parameters relating to that citation style, though I don't think there's any real harm in the latter.

I'm honestly skeptical of the underlying rationale, though. It simply cannot be true that medical academics and other professions will quit Wikipedia in a huff if we do not bend over backwards to make it easy to use a citation style some of them prefer (actually, mostly Americans, and in particular fields), or even allow it at all. These people are entirely accustomed to either conforming to the house style sheets of the publications they submit papers to, or having it conformed for them. As a long-term test, I've been normalizing Vanc. author names to |last=|first= and compliant with MOS:INITIALS every time I have some time to spare and I encounter an article with Vanc. cites that are not used consistently; in about 5 years of this, I've been reverted a grand total of twice. (I got the change to stick in one of those cases by pointing out that article wasn't consistently using the style and did not have that style in its first non-stub version; in the other I conceded because that article did originate with Vanc. style, and the non-consistent cites in the page were recent additions.) So, the idea that if you change Vanc. cites to typical WP ones all Hell is going to break loose is patently false.

Anyway, no one is forced to use these templates, and a CITEVAR "universal permissiveness" about Vanc. and all other cite styles doesn't translate to required work on the WP:CS1 end; any doctor or lab researcher can insert Vanc.-style cites all they want, manually. We shouldn't be providing tools that make it easy to use confusingly divergent cite styles; WP is for readers, not for writers, much less writers with particular field-specific style manuals on their desks.
 — SMcCandlish ☏ ¢ 😼  21:00, 3 May 2019 (UTC)

But you have not stated why it is necessary to include first full names. we'd prefer is not a reason. The pros and cons have discussed ad nauseam above. Divergent styles, as long as they are documented is not confusing. The Vancouver system is not primarily American. It was established by the International Committee of Medical Journal Editors (ICMJE). Time to move on. Boghog (talk) 06:33, 4 May 2019 (UTC)

Old NASA ADS is retiring this summer: change Bibcode URLs to new UI?

The old-style NASA ADS (now often referred to as "ADS Classic") is being retired this summer in favour of the "New" ADS. At the moment, the Bibcodes in this template resolve to ADS Classic (e.g. 2007A&A...474..653V points to http://adsabs.harvard.edu/abs/2007A&A...474..653V) whereas I think the new URL is https://ui.adsabs.harvard.edu/abs/2007A%26A...474..653V (which for me autoforwards to .../abstract). I'm not sure if links to ADS Classic will auto-forward after it retires but the infrastructure is already in place to point to the new ADS UI.

To be clear, the change is from http://adsabs... to https://ui.adsabs...

I realise this will change about a bagazillion hyperlinks across Wikipedia so please verify everything I've said, as I might be mistaken!

Warrickball (talk) 07:20, 12 April 2019 (UTC)

Before doing mass replacements we should understand whether the old URLs will redirect to the new ones or vanish outright.

Also, the new website you linked requires JavaScript and sends the users' personal identifying information to at least 5 third-party companies, so it's a distinct regression from the current one... Is it an option to link the PDF directly, with URLs such as https://ui.adsabs.harvard.edu/link_gateway/2007A%26A...474..653V/EPRINT_PDF ? Nemo 11:43, 12 April 2019 (UTC)

No, that it not an option, since most entries do not have PDFs. AManWithNoPlan (talk) 15:38, 1 May 2019 (UTC)

The adsabs site linked by the Bibcode entry now has a warning at the top that it is deprecated in May and is going way in October of this year. They provide two links to alternatives. Praemonitus (talk) 14:56, 1 May 2019 (UTC)

If I understand that warning, it applies to searches at adsabs. |bibcode= causes cs1|2 to link to the adsabs page associated with the identifier, not to a search form. If you have information to the contrary, please provide more detail.

—Trappist the monk (talk) 15:10, 1 May 2019 (UTC)

I believe that you understand wrong. Reading the technical details seems to imply that the entire old site is going away, since they are working on refactoring databases, etc. People who did not use CS1/CS2 templates will have all their links break. AManWithNoPlan (talk) 15:44, 1 May 2019 (UTC)

It would be appropriate to automatically fix as many links as possible so that they use a template and the bibcode. However, I think we should stick with the old website as long as it's alive. The new one is not yet ready for prime time: it's very slow, requiring over 2 MiB in JavaScript, to the point it can fail to load altogether on slower connections. I see there's a notice they're hiring a front-end developer, so we can probably wait for it to improve before the old version is retired. Nemo 16:23, 1 May 2019 (UTC)

The edit needed to the template is very small. We should have it standing by (only adding "ui." to the URL I think), and then change it once the website is fast or when we run out of time. AManWithNoPlan (talk) 16:35, 1 May 2019 (UTC)

Please feel free to make the appropriate edit(s) in the module sandboxes. It can be deployed with the next revision of the modules-proper. --Izno (talk) 21:55, 1 May 2019 (UTC)

updated in the sandbox:

Cite journal comparison

Wikitext	{{cite journal|bibcode=2007A&A...474..653V|date=November 2007|first=F|issue=2|journal=Astronomy and Astrophysics|last=van Leeuwen|pages=653–664|title=Validation of the new Hipparcos reduction|volume=474}}
Live	van Leeuwen, F (November 2007). "Validation of the new Hipparcos reduction". Astronomy and Astrophysics. 474 (2): 653–664. Bibcode:2007A&A...474..653V.
Sandbox	van Leeuwen, F (November 2007). "Validation of the new Hipparcos reduction". Astronomy and Astrophysics. 474 (2): 653–664. Bibcode:2007A&A...474..653V.

—Trappist the monk (talk) 23:02, 1 May 2019 (UTC)

Response from ADS staff

I sent an e-mail to the ADS e-mail contact link on the web site with the following questions. I received a very quick response (on May 3, 2019) from Kelly Lockhart at ADS, who agreed to let me post their response. The intro and the numbered questions are mine, as I sent them. The indented quoted answers are Kelly's unedited responses:

(My intro:) There is a conversation going on at a Wikipedia discussion page about the new ADS web site. If any of you are able to respond with clarification there, that would be helpful. You can also e-mail me directly with a response (and permission to post it, if possible).

1. Can the new site be used without JavaScript? Many of Wikipedia's readers prefer to disable, or are unable to use, JavaScript.

Kelly wrote: "The site in general, including searching, cannot be used without JavaScript. However, we're working on implementing some faster-loading static pages specifically for links directly to abstract pages, which would cover most of the Wikipedia links. If a user doesn't have JavaScript enabled, they'd be able to view these pages and click on links to the PDFs hosted by arXiv and publishers, but wouldn't be able to click on some of the other links on the page or use other features of the site like the search bar."

2. It is claimed in the discussion that the new site "sends the users' personal identifying information to at least 5 third-party companies". Some clarification on that claim would be helpful.

Kelly wrote: "From talking with our front-end developer, there are three classes of external sites that requests are being sent to: CDNs, Google Analytics, and recaptcha.net. No personal data is being sent to the CDNs; they just help speed up site loading time, especially for non-US users. Blocking them is fine but will likely slow down loading speed. Google Analytics can safely be blocked without affecting site performance, for users who are uncomfortable with it. The call to recaptcha.net is to supply reCAPTCHAs for our user registration form and our feedback form, for those who have Google blocked, and shouldn't pass on any private data. Users should be able to safely block those calls, if they're not planning on using the account registration or feedback forms."

3. Why are the new pages so large? Is there a lightweight option? Wikipedia has readers from around the world, many of whom are on limited data plans.

Kelly wrote: "The development work outlined in #1 should be helpful to these users as well. We've also worked on unbundling the JavaScript a bit, so the entire site isn't being loaded at once. If a user has JavaScript enabled but clicks on one of these static page links, the JavaScript bundle necessary to run just that page fully loads in the background. If they click to a different page, other necessary JavaScript would be downloaded at that point."

4. Will the old URLs continue to work, or will we have to change our (155,000+) links to the old URLs? (Not a hugely daunting task for most of the links, since they are linked via a Wikipedia "template" and so can be changed with a few keystrokes, but it would be nice to have backwards compatibility.)

Kelly wrote: "The URLs will continue to work, though I'd still recommend updating the links when you're ready. For your planning purposes, we're planning on deprecating the site in the next couple weeks; practically, that means we're going to make it harder for current users to conduct new searches on the site, but we'll leave existing abstract pages alone. We're retiring the site in Q3 (we're saying October right now), but in actuality we'll just be taking down the search pages and user accounts. Existing abstract page links will still work indefinitely, though they'll likely redirect to the equivalent pages in the new system at some point in the future."

End of message. The e-mail address to which I wrote was ADS Help, adshelp@cfa.harvard.edu. – Jonesey95 (talk) 14:46, 9 May 2019 (UTC)

Thank you for doing that.

—Trappist the monk (talk) 14:54, 9 May 2019 (UTC)

Perennial italics debate is recycling again

FYI

 – Pointer to relevant discussion elsewhere.

Please see Talk:Mueller Report#Publisher versus work or website in citation template.  — SMcCandlish ☏ ¢ 😼  05:47, 2 May 2019 (UTC)

Note that this discussion has continued, and led to a new section below on clearly defining examples for the |work=/|website= and |publisher= parameters. - Paul^T+/_C 19:50, 6 May 2019 (UTC)

Needs to support "no title"

Editing Epigonion § Virtual Epigonion just now, I found a dead link that was formatted simply as an external link, labeled with descriptive text

https://en.m.wikipedia.org/wiki/Special:MobileDiff/895131482

Thnidu (talk) 06:12, 2 May 2019 (UTC)

You mean |title=none? It is supported, but only for references that don't try to link something to the title. Where else do you think the link should go in such cases? —David Eppstein (talk) 06:30, 2 May 2019 (UTC)

@David Eppstein: Oops, I fell asleep in the middle of entering that, and I'm barely awake now. I'm going to turn out the light as soon as I have posted this bit.

I'm talking about the title parameter in the citation, not the title of any Wikipedia entity; I didn't know there was any way or reason to link to that! Anyhow, title= none just gives us

"none". John Doe (1992)...

Here is what I meant to have there:

--------

While editing Epigonion § Virtual Epigonion just now, I found a dead link that was formatted simply as an external link, labeled with descriptive text. I found an archive copy in the Wayback Machine and set up a proper citation for it, with all the information that was available. The linked page was nothing but an MP3 with the usual layout for playing it. (It was about three times as long as described in the text, but I covered that in the edit summary.) This "page" had no text: it was an .mp3 file, not .html, .pdf, or any other type used for text, and so it had no title.

This cite template requires a "title=" parameter and throws an error if there is none. After a couple of failed workarounds, I put a no-break space ( ) for the title and added "(no title)" at the end of the ref, outside the template call.

There should be a better way to handle such situations, and it should be documented in the template doc. Leaving the title parameter empty (title= ) only triggers the error message. My trick worked, but it would be better to have an explicit indication in the template that there is no title, not just in the ref. title=  displays as title= , which isn't very clear, and any visible text there, like title=(none), could be the actual title of a page. Maybe notitle= true would be good, generating [no title] at the start of the citation, where the title would normally be but without the quotation marks. --Thnidu (talk) 09:06, 2 May 2019 (UTC)

What is recommended in most printed style guides is to create a descriptive title, and not provide any distinctive typography for the title. So while an article title is surrounded by double quotes, and a book title is in italics, a descriptive title would be ordinary upright type with no quotation marks. But the citation templates do not support this. Jc3s5h (talk) 12:16, 2 May 2019 (UTC)

There has been previous discussion that did not go anywhere.

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

|title=none works only for {{cite journal}} IIRC. Journal: Journal.{{cite journal}}: CS1 maint: untitled periodical (link); Magazine: "none". Magazine.. --Izno (talk) 20:21, 2 May 2019 (UTC)

Hunting backwards from your archived url lead me to this page where you will find "Middle age piece (G. Dufay) played on 4 recostructed Epigonions, wooden resonant structure, plucked and hammered strings". G. Dufay is presumably Guillaume Du Fay. It would seem then that the citation might be rewritten as:

{{cite web |url=http://www.astraproject.org/examples/dufay.mp3 |title=Middle age piece (G. Dufay) played on 4 recostructed Epigonions |format=MP3 |website=ASTRA Project on the Grid |archiveurl=https://web.archive.org/web/20090317213850/http://www.astraproject.org/examples/dufay.mp3 |archivedate=2009-03-17}}

"Middle age piece (G. Dufay) played on 4 recostructed Epigonions". ASTRA Project on the Grid. Archived from the original (MP3) on 2009-03-17.

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

Rather than dwell on previous discussions having questionable cases in them, and failing to come to consensus, we should probably try to just come to a consensus on it. I agree that there are various times when it is legitimate to cite a source that has no explicit or conventional title, and that various external citation style manuals have arrived at solutions for these, the most common possibly being a square-bracketed something, like "[untitled]", though the descriptive approach jc3s5h mentions may also be well-attested, and possibly viable here (although I can imagine some editors coming up with "that's original research" objections). I agree with Trappist that such things (square-bracketed or not) shouldn't receive quotation-mark or italic markup, since they're not actual titles. And that would likely require some hard-coded special |title= and |work= keywords, e.g. |title=n.t. to match |date=n.d.

Speaking of that, can we please get |date=n.d. changed to report "undated" instead of regurgitating the literal string "n.d."? It's a MOS:ABBR problem, in that it has no <abbr>...</abbr> markup nor a wikilink, and is ambiguous at best and just a meaningless two-letter acronym to the average reader.
 — SMcCandlish ☏ ¢ 😼  12:26, 3 May 2019 (UTC)

Fixed {{para}} templates in your post.

It seems that there are a couple of possibilities: a description might be one and an incipit might be another. Both |description= and |incipit= might do as aliases of |title= but without styling or with unique styling. Not sure how difficult that would be to implement.

|date=n.d. and |date=nd is a different topic. If you wish to pursue that, please start a new conversation.

—Trappist the monk (talk) 13:56, 3 May 2019 (UTC)

Where I have run into this situation I have used either "(unknown)" or "(no title)". Perhaps, it would have been better to use square brackets as they are typically used for editorial remarks. Both are very unlikely to be actual titles (in particular with square bracket), so we should be reasonably safe to use them as keywords for special cases. We can still decide how to render them for display purposes, but the title should either not be put into metadata or be replaced by "-----" or nbsp for this purpose.

Alternative, if someone wants to use a descriptive alias they could use the title=((description)) syntax, which is also very unlikely to be conflictive with an actual title. The template could strip off the brackets for display and display the alias without italics and quotes. Not sure if the description should be used as metadata or replaced by "-----" or nbsp as well.

--Matthiaspaul (talk) 20:12, 3 May 2019 (UTC)

Let's apply the KISS principle, and stick with square brackets, which also agrees with WP:MOS on markup of editorial additions.  — SMcCandlish ☏ ¢ 😼  21:30, 3 May 2019 (UTC)

Maybe not the best choice because |trans-title= and |trans-chapter= (and aliases) render in square brackets. The module needs some sort of mechanism to tell it that this 'title' should be treated differently from a normal title. Such a mechanism should be user friendly so parameters that are aliases of |title= still might be the best overall simple solution.

—Trappist the monk (talk) 00:32, 4 May 2019 (UTC)

Or we could use the established ((...)) syntax in the |title= parameter to tell the template that it should not pass on the title into metadata, but just display it as a description (without the brackets, of course) unless the description would match one of a few special keywords for unknown or no title, which could be written as ((unknown)) or ((no title)), and then special cased in the code to substitute the value in the output with whatever we can agree on to indicate "no title". This has the advantage that the output can be changed centrally if we would want to change the way no title gets indicated in the future. --Matthiaspaul (talk) 19:54, 6 May 2019 (UTC)

I'm not sure that we should overload that ((...)) operator. It has a meaning: "use this parameter value as written". For |title= that functionality was added as a result of this conversation. And, yeah, it isn't documented but it should be. I don't have any better suggestions than the two parameters I mentioned above; I don't think that we should be supporting citations without some sort of title; at minimum, when the source really doesn't have a title we could be using |description=Not titled which would render that 'non-title' without italics or quotation marks. I suspect that the |title=none supported by {{cite journal}} (or {{citation}} when |journal=<journal name>) runs afoul of citation consistency when other non-journal citations must have a title.

—Trappist the monk (talk) 23:07, 6 May 2019 (UTC)

Possible exception to para others maintenance message

{{Cite AV media notes}} uses |others= for the artist, and liner notes often do not have a credited author. Here's an example of the template used with |others= and without |last=/|first=:

Cite AV media notes comparison

Wikitext	{{cite AV media notes|others=Lady Gaga and Bradley Cooper|publisher=Interscope Records|title=A Star Is Born|type=Credits from Liner notes|year=2018}}
Live	A Star Is Born (Credits from Liner notes). Lady Gaga and Bradley Cooper. Interscope Records. 2018.{{cite AV media notes}}: CS1 maint: others in cite AV media (notes) (link)
Sandbox	A Star Is Born (Credits from Liner notes). Lady Gaga and Bradley Cooper. Interscope Records. 2018.{{cite AV media notes}}: CS1 maint: others in cite AV media (notes) (link)

Should we suppress this maint message for {{Cite AV media notes}}? – Jonesey95 (talk) 07:31, 2 May 2019 (UTC)

I guess the first question that I have is: Should |others= be used in this way? The documentation for |others= at {{cite AV media notes}} reads:

• others: To record other contributors to the work, including illustrators. For the parameter value, write Illustrated by John Smith.

In this case the work is the media notes. Did Gaga and Cooper contribute to the media notes in a substantive way? If they did, then they should be listed as authors. If not, and the media notes are the work of an anonymous PR person at Interscope Records, then Gaga and Cooper should be omitted from the citation. If we don't know who created the media notes, we should not guess. When we cite a magazine article about a concert given by Gaga and Cooper, we don't include them in the {{cite magazine}} template; why do it in {{cite AV media notes}}?

—Trappist the monk (talk) 13:40, 2 May 2019 (UTC)

I am open to a different usage. The template's custom documentation, under "Brief instructions", indicates that |others= should be used for "Artist, producers, etc."

It does seem strange to me, however, not to cite the artist for media notes, primarily as a way of helping the reader find the right source. For example, if I were citing the liner notes for a CD or LP whose formal title was "Symphony Number 3" or "Violin Concerto No. 1", I would want some way of giving more information about the composer or performer in order to guide the reader to notes for the right recording. I suppose the year and the label are potential disambiguators, but it is a lot easier on the reader to indicate that the recording was of a Beethoven concerto performed by the London Philharmonic. I don't know the right answer, but one primary purpose of citations is to help the reader find the original source. – Jonesey95 (talk) 14:18, 2 May 2019 (UTC)

I agree that the documentation for {{cite AV media notes}} says what it says. I wonder if those recommendations are correct and proper. The definition of |others= says nothing about disambiguation. The use of |others=Lady Gaga and Bradley Cooper suggests that Gaga and Cooper contributed to the media notes. Sure, they contributed to the media and I would be very surprised if their names did not appear on the media notes's cover so were I citing media notes I would probably use the words on the front cover of the notes for the citation's title. Just reaching into my box of CDs, here is Close to the Bone by Old Blind Dogs. Because the cover of the media notes reads, top to bottom:

Old Blind Dogs

Close to the bone

I might write something like:

{{cite AV media notes |title=Old Blind Dogs: Close to the Bone |year=1993 |publisher=Lochshore}}

Old Blind Dogs: Close to the Bone (Media notes). Lochshore. 1993.

I have a fair collection of classical recordings and don't know that I've ever seen one that doesn't have the composer and performers listed on the cover.

I suspect that there is a WikiProject that cares about these kinds of citations. Perhaps they should be invited into this conversation?

—Trappist the monk (talk) 15:25, 2 May 2019 (UTC)

I concur with Trappist on this (in his first post above; I don't have an opinion on what is most common on classical CD covers, or whether a wikiproject will have something to say about the OP's question). There appear to be conflicting instructions at one page, to use |others= for "Artist, producers, etc.", without qualification and clarification as is found in other documentation about this parameter (i.e. suggesting, sensibly, that this parameter is not used in lieu of author parameters, but is an additional parameter for, well, others). This actually brings up something I was just about to try to address here, anyway, and will do so in a thread below: the problem of increased forking of the citation template docs.  — SMcCandlish ☏ ¢ 😼  12:00, 3 May 2019 (UTC)

Error and maintenance category names updated in sandbox for capitalization consistency

A minor change, but possibly worth a discussion: I have updated two error category names and many maintenance category names to make the capitalization of the category names consistent. These changes would go into effect with the next module update, and existing categories would need to be renamed or moved (or just deleted and recreated, whatever makes the most sense). – Jonesey95 (talk) 08:06, 2 May 2019 (UTC)

The category links in Help:CS1 errors will need to be revised.

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

Since we're considering doing this, we should consider also extending Category:CS1 maint names to Category:CS1 maintenance names e.g. 'CS1 maint: ignored ISBN errors' -> 'CS1 maintenance: ignored ISBN errors'. --Izno (talk) 13:13, 5 May 2019 (UTC)

Website field

SMcCandlish imperfectly replaced "website" with "work"? I still think "website" should be the correct name of the field as this is cite web, not cite news. But because of his edit, now whenever I edit a ref via ProveIt or add a new one via the citations toolbar, the field "website" is treated as a separate field from work (whereas they were previously one). Can someone please now merge these two fields perfectly? --Kailash29792 (talk) 09:43, 3 May 2019 (UTC)

If you are going to mention an editor by name, courtesy requires you to ping that editor. Because you didn't, I shall: pinging SMcCandlish.

I think that I have restored the canonical form |website= with this edit. I don't use ProveIt or ve so someone else will have to test that change.

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

So what is the actual technical issue here? How is updating the template documentation having any affect on some external tool? I think by now most of us have noticed that editors are leaning increasingly toward using |work= instead of the custom aliases it has at various templates (|website=, |journal=, |magazine=, |newspaper=, etc.), for consistency, concision, ease of conversion between templates, and so on. We should be able to update the template docs to display (and thus encourage) use of |work=, and to mention the variant aliases only in passing, as legacy options. Having a tool like ProveIt treat |work= and |website= as separate things was the diametric opposite of the intended and expected results (and frankly seems like really bizarre behavior on the part of that tool – a problem to fix on that end).  — SMcCandlish ☏ ¢ 😼  11:45, 3 May 2019 (UTC)

Unfortunately, TemplateData is bad idea. It attempts to combine the function of tool control (ve primarily, though, no doubt, other lesser lights) with the function of template documentation. I don't know how well TemplateData performs as tool control, but it sucks when it comes to template documentation. Because the two functions are intertwined in some inexplicable ways, changing the 'documentation' can, as OP notes, have detrimental side effects.

I think by now most of us have noticed ... You know, whenever I hear or read anything that remotely sounds like "I'm sure that we can all agree ...", that is when I start to think: "no, we do not all agree ..."; it's the contrarian in me. So, I tried a couple of simple searches.

There are, at present, ~318k articles using {{cite web}} templates. I did two searches looking for {{cite web}} using:

|website= ~120k articles (timed out)

|work= ~128k articles (timed out)

Because both searches timed out, results are wholly unreliable and inconclusive. To get an accurate measure of |website= v. |work= in {{cite web}} perhaps we need someone who can hunt through a recent database dump or we need to modify the cs1|2 modules to add properties cats for {{cite web}}. I suppose that we ought to also include the other periodical aliases (|journal=, |newspaper=, |magazine=, |periodical=, |encyclopedia=, |encyclopaedia=, |dictionary=, |mailinglist=) and perhaps create maintenance cats for those. This (timed out) search for |newspaper= in {{cite web}} found ~8k articles.

—Trappist the monk (talk) 13:30, 3 May 2019 (UTC)

A lot to cover, so this will be a bit long. TemplateData: I thought that was being migrated to WikiData anyway. I did understand that it could be used for tool configuration/control, but it's still strange to me that inverting the relationship between |website= and |work= had the exact effect that was reported above. My intent was certainly not to fork these parameters into separate entities, much less necessitate the creation of redundant categories!

I understand your "contrarian me" reaction, but I'm not making an "everyone agrees" point. On WP it's never true that everyone agrees on anything! Ha ha. Rather, I'm observing a trend and trusting that others have been observant enough to pick it up as well. I've been okay for years with the templates being documented as having parameters like |website= and |newspaper=, and barely mentioning |work=; I really didn't care much.

But some of what I've noticing more and more over about the last three years are the following: There's been a sharp increase in constructions like {{cite news|work=Foo News|...}} and {{cite web|work=The BarBaz Blog|...}}. If you convert an entire article to use the consistent and concise construction, virtually never will anyone will revert you (probably only at an obscure-topic WP:FA that has an effective WP:OWNer), because the change is generally seen as an improvement; but if you go the opposite direction, replacing |work= with things like |website= and |magazine=, a revert is much more likely, as WP:MEATBOT-style change that is not helpful in any way to anyone. People actually complain about |website=, etc., and label them pointless, confusing, and so on (I ran into that again just yesterday as part of the perennially recycling argument about italicization of work names when the source is electronic; the forcefulness of the complaints about the different and longer-named parameter aliases (e.g. "|work= or one of its pointless aliases (website, newspaper, etc)" – from someone who's actually on the opposite side from me on the matter actually under discussion over there) was what inspired me to look into normalizing toward |work=. I picked a single template to do this with as a test run, and it's interesting that no one objected about the substance/intent of the change, only the unexpected effect it had on one tool, from the TemplateData part of that edit. A major source of misuse of parameters (especially work titles in |publisher= and |via=) is confusion about which parameter is for what; the more differently named parameters there are, the harder it is for people to make sense of them and memorize them. The trend toward |work= is natural for more generalized reasons, too, familiar to those who spend a lot of time in discussions at WP:P&G pages and in WP:TFD: concision is generally a virtue, and consistency almost always is one in such matters. WP:CREEP is a problem, whether it's happening in P&G pages or template documentation; instructions are instructions, and the more we have and the more variant they are, the harder it is to become an editor and remain one who knows how things work and should work. For many years we've been increasingly normalizing similar templates to have identical parameters (for editor sanity, for codebase sharing, and for direct merger of redundant templates). So, I'm in no way surprised at the favoring of |work= over time.

Part of my "job" as a P&G editor, a TemplateEditor, a PageMover, and a gnome in general is to normalize how stuff works to match what the community is doing/expects, what the operational consensus is, whether people have had fighty RfCs about it or not. I'm actually pretty good at this; given the large amount of that work I do, quite boldly, I would have been topic-banned from such activities, or just indeffed, long ago if I were technically incompetent at it, were just implementing my own or some WP:FACTION's preferences, or were simply terrible at gauging what the ground-truth consensus is.

Anyway, yeah, I would expect searches like the ones you did to time out, because there are millions of instances. I don't think such stats would be useful even if they could be gathered, because of legacy use and other skew. They'd only be informative if they could be gathered completely and compared at least as granularly as month to month. Even then, there's the fait accompli bias that most of the templates' documentation encourages the use of the variant, long-winded parameter aliases. And we'd need some way to exclude results from tools hard-coded to use particular parameter names. However, the fact that the results you were able to get out of the searches, before the timeout, showed |work= with a marginal lead anyway despite being virtually hidden in the documentation is telling.
 — SMcCandlish ☏ ¢ 😼  20:33, 3 May 2019 (UTC)

I have not noticed whether or not editors are currently using |work= more than |website= – but then I just don't pay much attention to that kind of stuff. I had thought that if the searches returned something useful that would be a simple way to gauge a trend if one exists by taking an initial sample now and over the next some-number of months take additional samples. This same can be accomplished by creating properties cats (relatively easy to do I think), or by hunting through database dumps (more difficult according to Editor GreenC).

After |website= was added to Module:Citation/CS1/Whitelist (this edit 9 April 2013) we went through a spate of confusion, anger, ... (pic your emotion). Since then, there has been little or no discussion here about |work= being preferred over |website=. Much of that previous discussion was about either of these parameters rendering in italics.

The original rational for |website= in the cs1|2 module suite seems to have arisen from this feature request. I didn't find discussion that necessarily supports that particular feature request but there is this and a long section of a much longer section (you rose in opposition in that latter conversation).

—Trappist the monk (talk) 23:41, 3 May 2019 (UTC)

I'm not sure reviewing that old history is useful today (and I eventually, even on that page, was convinced to "support adding |website= as, and only as, synonymous with |work=". It's not a issue of whether |website= exists, but of whether we "advertise" the consistent parameter or the divergent ones more. And, secondarily, what needs to be done to favor |work= without breaking a tool and causing it to treat them as separate parameters rather than one parameter with a |website= alias.  — SMcCandlish ☏ ¢ 😼  09:11, 4 May 2019 (UTC)

For me, because I would not favor |work= over any of the 'periodical' parameters (|journal=, |magazine=, |newspaper=) in their respective cs1 templates and {{citation}}, so I would not favor |work= over |website= in {{cite web}} or {{citation}}. The periodicals that I read or refer to in everyday conversation are journals, magazines, newspapers; these are the common English terms for those things. I don't think that I've ever referred to a magazine or newspaper as a work except here in the context of these templates. When I visit some website, I'm visiting a website, not a work. Yeah, all of these things are 'works' but that is a jargon-ish term that I think is useful as a fall-back in certain cases (media other than newspapers in {{cite news}} for example).

en.wiki prefers commonly recognizable names for article titles and other things, why should these templates counter that preference by preferring jargon over a common name for parameters that it uses?

—Trappist the monk (talk) 12:04, 4 May 2019 (UTC)

Just a question of complexity having to remember different argument names for use in different citation templates - once you remember "work" it should universally work. It's easier to remember one argument name, work is intuitive. Not everyone will agree with that there are arguments both ways. Ultimately I put more emphasis on reduction of complexity because it is an existential threat to the project, putting a damper on attracting new users and burning out old over the long run - a small forcing to be sure but something that is controllabe. -- GreenC 12:58, 4 May 2019 (UTC)

Using the name of a thing as it is named in common, every day, English language adds unacceptable complexity? I have a hard time wrapping my poor little brain around that. Complexity for whom? I have been trained throughout my lifetime to think of a magazine as a magazine, a newspaper as a newspaper, a website as a website. Learning that such things lump to the term 'work' was a new concept to me when I first came to Wikipedia. I would not be surprised to learn that most new editors experience something similar. If we promote |work= as the primary parameter name for {{cite web}} and the periodical cs1 templates, then, were I again a novice, I would have to look that up to see how to use that parameter. If I were a newby and citing a journal or a website, I suspect that I'd catch-on more quickly with parameter names that reflect the thing that I'm actually citing.

Existential threat? Can you point us to research that shows that template complexity – more to the point, cs1|2 complexity – has detrimentally effected new-editor attraction and older editor retention?

—Trappist the monk (talk) 14:59, 4 May 2019 (UTC)

It's easier to remember 1 thing, learned one time, then to remember 5 different ways depending on context. This is evident, most people default to 2 or 3 cite templates most of the time, mostly cite web, rather than learn the family of cite templates and their argument names. The issue of complexity and retention was probably studied during development of VE since it was supposed to make Wikipedia more accessible to non-technical users, this was a major push, and I expect they did so because of feedback. I wouldn't take it personally that CS1|2 is somehow at fault, it's better than any alternative, but it's part of the larger picture of increasing complexity across Wikimedia. This problem is not even unique to Wikimedia, Windows and Apple were supposed to hide OS complexity so that more people could use computers. I am a unix command-line person, but also recognize most people are not that vested. -- GreenC 01:04, 5 May 2019 (UTC)

Sure, learning one new thing instead of five new things might be easier. But since I already know the five things, learning an un-intuitive new thing that overrides the five intuitive things is to me adding complexity. I don't imagine that new editors sit down and read the cs1|2 template docs. If they muddle their way into the ve add-a-template editor and type cit into the add-a-template text box, ve will offer them a handful of templates. For me it offers:

{{citation}}, {{cite}}, {{cite web}}, {{cite book}}, {{cite news}}, {{cite journal}}, {{cite av media}}, {{cite episode}}, {{cite encyclopedia}}, {{cite av media notes}}, {{cite press release}}

If they use the wikisource editor, then they are offered:

{{cite web}}, {{cite news}}, {{cite book}}, {{cite journal}}

I haven't tried the hybrid editor so I don't know what editors are offered there. I suspect that these offered-subsets of the cs1|2 templates account for the preponderance of citation templates that editors use simply because these are the templates offered and because {{cite web}}, {{cite news}}, {{cite book}}, {{cite journal}} answer the majority of editors's citation needs.

—Trappist the monk (talk) 12:27, 5 May 2019 (UTC)

Sounds like when I worked in the IT dept of a large company about 20 years ago, and they brought in a bunch of kids straight out of University to write the Next Big Project. They were all talking about methods, actors and broadcasting to such an extent I wondered if they all came from drama school, instead of (as they claimed) a decent computer science faculty. The new software never did work, and was abandoned after three wasted years. No, magazines are magazines and I have something like 900 back numbers of The Railway Magazine to show that. --Redrose64 🌹 (talk) 00:01, 5 May 2019 (UTC)

There is one example I can think of where |website= and |work= would be useful as seperate parameters. Fossilworks is a website that uses the Palaeontogy Database (the work?), which also can be accessed from its own website. This is usually handled |publisher= parameter for one of them, which doesn't seem right.   Jts1882 | talk  13:09, 4 May 2019 (UTC)

You don't offer any specific examples here but an insource: search for "Palaeontogy Database" did not find that string in use in article space. Perhaps you meant 'Paleobiology Database'? There are about 7k hits for that. A similar insource: search for Fossilworks also found about 7k hits. If the url is pointing to fossilworks.org then |website=Fossilworks is appropriate; if to paleobiodb.org then |website=The Paleobiology Database is appropriate. We shouldn't astonish readers by writing citations that name one source but link to another.

—Trappist the monk (talk) 14:59, 4 May 2019 (UTC)

Apologies both for wrong database name and lack of examples. I was going to add examples but had to leave unexpectedly. You can find several examples using |work=Paleobiology Database|publisher=Fossilworks in this search. I think the reason it was done this way is that the fossilworks website requests that both the database and their gateway website are given in citations. There are some examples of other ways that this has been attempted.   Jts1882 | talk  15:59, 4 May 2019 (UTC)

We cite wherever we read the info, not what is requested of us by external entities (even if it isn't just a "cite this database" kind of page). --Izno (talk) 16:10, 4 May 2019 (UTC)

Fair enough, we cite where we read it, but the example in WP:SAYWHEREYOUGOTIT also gives the original source in the form "Original Source cited by What I Read". Most of the time we read online versions of a journal, but we still give the details of the printed volume. What I am looking for is the best way the give both the actual work (the paleobiology database) and where I read it (fossilworks). One method often used is to set |publisher=fossilworks but this doesn't seem an accurate use of publisher and the website should be the one italicised.   Jts1882 | talk  10:50, 6 May 2019 (UTC)

I have to agree with Editor Izno here. And, the How should I cite Fossilworks FAQ does not describe citations of individual records.

I looked through the first dozen or so of the search results. What I found was an amazing lack of consistency. In most cases, the title in the citation was not the title of the entry at fossilworks (close sometimes, but not that close) for example from Lion, this:

{{cite web|url=http://fossilworks.org/bridge.pl?a=taxonInfo&taxon_no=162281|title=''Panthera leo atrox''|last=|first=|date=|work=[[Paleobiology Database]]|format=|accessdate=2012-03-11}}

"Panthera leo atrox". Paleobiology Database. Retrieved 2012-03-11.

leads to a fossilworks entry titled: †Uncia atrox Leidy 1853 (lion) which only shares the atrox part – yeah, Panthera leo atrox is an alt form but it isn't the entry's title so readers (like me) are surprised when they land at †Uncia atrox Leidy 1853 (lion) on Fossilworks (not Paleobiology Database). We should not surprise readers. This one, from Giraffe shows that links to the paleoboidb.org url get remapped to fossilworks:

{{cite web|url=http://paleodb.org/cgi-bin/bridge.pl?action=checkTaxonInfo&taxon_no=42695|title=Giraffa (giraffe)|publisher=[[The Paleobiology Database]] |accessdate=2016-09-13}}

"Giraffa (giraffe)". The Paleobiology Database. Retrieved 2016-09-13. – and yep, different title (this time not found as an alt at the database entry and not at The Paleobiology Database.

I could go on but won't. Perhaps those articles would be better served were there a {{cite fossilworks}} template that would wrap an appropriate cs1|2 template to handle all of the constant stuff like the website name etc and give the citations some form of consistency. That won't fix the big problem of citation titles that don't match the database entries but it would be a step in the right direction. I can help if the cognizant wikiproject wants to implement an appropriate template.

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

This is something I plan to do. As you have seen there is incredible inconsistency in how the citations are made. The Giraffa one is unusual as the url is a hybrid using the fossilworks web service function with a paleobiology database url. The paleobiology database item would normally use this url. So how should this be handled? The Paleobiology Database is the actual work, so |work=Paleobiology Database is appropriate. Using the PB database as the work and just referencing fossilworks in the url is the kind of surprise we should be avoiding. A number of the examples use |publisher=fossilworks but this seems inappropriate. |via= is another possibility but that seems to be used for archive services and sites like JSTOR.

This general question of how to best cite taxonomic databases and the gateway websites comes up quite often and will more in future. WoRMS is another website that provides access to a variety of separate databases, some of which it curates or shares curation, others it hosts, and some it mirrors. A good citation should give both the source of the material and where it was accessed. A database parameter might be useful for use with websites serving as gateways to various databases. Then it could be tied with the |access-date= and produce output of the form "Retrieved from the Paleobiology Database on 6 May 2019" while using |website=fossilworks.   Jts1882 | talk  10:50, 6 May 2019 (UTC)

It has taken a bit of time for me to, I think, untangle this. http://paleodb.org/ and http://fossilworks.org/ urls link to a database at Macquarie University.^FAQ1 https://paleobiodb.org/classic/... urls link to a database held at University of Wisconsin–Madison.^FAQ2 Two separate databases. There is at least a one-way sync from the UW database to the Macquarie database^FAQ2 – there is no mention of data sync in the other direction.

Because there are two different databases, I think that including the 'Paleobiology Database' name in Fossilworks citations serves only to confuse because a database that isn't the fossilworks 'Paleobiology Database' exists under the name of 'Paleobiology Database'. Which one do you mean?

—Trappist the monk (talk) 15:12, 6 May 2019 (UTC)

SMcCandlish, please don't think I am trying to be your enemy. If you think "work" should be the main field, please do so. But not in a way that makes website a separate field. --Kailash29792 (talk) 13:45, 3 May 2019 (UTC)

Exactly! I'm having a "Whaaat?" reaction myself, because there wasn't a reason that I was aware of to expect such a result, and I've never encountered one before, even after years as a TemplateEditor doing fairly complicated work (though I don't do much on the Module/LUA side). If someone proposed (again) to make them separate parameters on purpose, I would oppose (not just because it's rehash, but on the merits of the idea, or rather the lack of them). It's not actually clear to me how this result was possible, because I simply changed the things the TemplateData said should be treated as aliases (including |work=) of |website= to instead be treated as aliases (including |website=) of |work=. I'm guessing there was some kind of tiny syntax error in what I did in the TemplateData block, or I'm missing information about what that third-party tool is doing with that information in its own codebase.  — SMcCandlish ☏ ¢ 😼  20:33, 3 May 2019 (UTC)

The regex method won't work because there are embedded templates like {{date}} it will stop matching on the first "}", and there are cite templates with empty arguments that were copy-pasted in and not a good reflection of usage, and Elasticsearch considers the search too expensive. It would require parsing the dump taking into count these factors. I can do this, but it would take some work, so only if really needed. -- GreenC 15:18, 3 May 2019 (UTC)

As noted above in my long-ass post, I doubt such stats would be useful, due to various forms of skew.  — SMcCandlish ☏ ¢ 😼  20:33, 3 May 2019 (UTC)

Cite template docs forking (sometimes badly) – we need to use the transcludes more and separate docs less

There is increasing inconsistency between the various loci of our cite template documentation. In some cases (e.g. for |year=) various pages have been long out of step with each other. We have too much of it separately maintained (and often basically unmaintained) in too many places, like Help:CS1, Help:CS1 errors, Template:Citation Style documentation, and each template's documentation page, and probably other places, too. Some of these are pulling the same documentation via transclusion, which is a good thing, while others are separate documentation, which is increasingly WP:CFIing in confusing and unhelpful ways. E.g., the discrepancy in the treatment of |year= at these pages (I think I managed to resolve that today) is almost certainly the primary proximal cause of editors continuing to use |year=YYYY despite its deprecation (except in one very, very specific circumstance) in favor of |date=YYYY half a decade ago at a least. (Another cause is tools that have not been updated and which are hard-coded to use |year=. Sometimes authors of these tools are surprisingly stubborn in refusing to update their code to comply with current WP:CS1 documentation, or WP:MOS changes, or anything else, which I think is a form of WP:BOTPOL failure, though I would try discussion/persuasion several more times before making some kind of dramaboard issue out of it.)

There are more such "documentation forks" (I think WP:CFI needs another section for that concept), and I hadn't even noticed the one reported here a few threads above, where |others= is mis-documented at one page as just being for "authors, producers, etc." without any qualification, while another more accurately describes this as an adjunct to other biographical parameters, not a replacement for them, but for additional parties that don't fit into an author, editor, translator, or other specific bio parameter.

Maybe we need some kind of "map" of all the documentation, from which we can figure out how to transclude more and separately [fail-to-]maintain less.
 — SMcCandlish ☏ ¢ 😼  12:14, 3 May 2019 (UTC)

In the time that I have been participating in this project, there have been many and many a complaint about the quality of the cs1|2 documentation. When I ask those complainers if they know how to make the documentation better to please do so, almost invariably, I am met with silence. We need a champion, a St George to go out and slay the documentation dragon. Are you our champion?

—Trappist the monk (talk) 13:41, 3 May 2019 (UTC)

In part, in theory. I have the will, but my WP time is more constrained than it once was, and the thread just above this indicates that there are some gaps in my relevant knowledge. The purpose of my opening this thread wasn't to complain, but to outline the nature of the problem and see about jointly coming up with a "roadmap" for resolving it. It likely isn't an issue that needs a single champeen.  — SMcCandlish ☏ ¢ 😼  19:28, 3 May 2019 (UTC)

Trappist, that argument at best misses the point. Your work is very much appreciated, you've helped me personally a lot, but when editors complain that the documentation is in adequate, it's because they tried to do something that didn't work because it's not written. The editor changing the code should update the documentation right after to reflect how the template works. Asking other editors who know only part of the code to go and update it should not be how any template works and will never work and will always be met with silence. --Gonnym (talk) 22:16, 3 May 2019 (UTC)

I get your point, but you know that the absolute worst of all possible documentation is that which was written by the developer. Why? Because the developer knows what it does so writes incomplete, insufficiently detailed, overly detailed in the wrong areas, ... This is why there are technical writers who have editors overseeing what it is that they write. That isn't perfect either but its a damn sight better that the stuff that developers churn out.

I am more than willing to assist when necessary in the improvement of the cs1|2 documentation but I should not be the author because I am too close to the code. There is a ton of documentation in the code, and every new thing that I have added to the module suite since I started working on it has been discussed here, usually with examples, so there is a lot of raw material for writers to harvest.

—Trappist the monk (talk) 00:45, 4 May 2019 (UTC)

One obvious (to me at least) thing that should be done is to cleanup Help:Citation Style 1. For the most part, it seems a page without a purpose. It transcludes some documentation from Template:csdoc ( § Identifiers), includes what appears to copies some of the csdoc text (§ Registration or subscription required is more-or-less a text copy derived from this (or similar) version of the 'official' csdoc documentation), and has other documentation not in csdoc (the three subsections of § Dates for example). Should this help page be a clone of csdoc or should it hold explanatory text that expands upon the documentation in csdoc? Should it be something else?

—Trappist the monk (talk) 16:05, 5 May 2019 (UTC)

The n.d. keyword for undated sources

About |date=n.d. (I think |date=nd also works), can we please get this changed to report "undated" or perhaps "no date" instead of regurgitating the literal string "n.d."? It's a MOS:ABBR problem, in that it has no <abbr>...</abbr> markup nor a wikilink, and is ambiguous at best and just a meaningless two-letter acronym to the average reader. Would also be nice if it accepted "undated" as input.  — SMcCandlish ☏ ¢ 😼  21:07, 3 May 2019 (UTC)

The first mention of n.d. I think occurs in this conversation. There was some talk about undated in this discussion.

—Trappist the monk (talk) 00:24, 4 May 2019 (UTC)

Protected edit request on 5 May 2019

Bibcode access on the http://adsabs.harvard.edu/abs/ site is now complaining about oncoming deprecation.

• Change the bibcode prefix from http://adsabs.harvard.edu/abs to https://ui.adsabs.harvard.edu/abs Artoria2e5 🌉 02:04, 5 May 2019 (UTC)

  We are aware of this upcoming change and have made the sandbox work correctly. See the above discussion. --Izno (talk) 02:51, 5 May 2019 (UTC)

Could the explanation of Subscription or registration required be made more clear

In cite journal, it is not clear to me, reading the instructions, which parameter I have to change if I want to add the access level. The current description only tells which access levels are in use, not how to use them: Four access levels can be used: . Could somebody who understands this improve the description? Thanks! Femke Nijsse (talk) 09:08, 5 May 2019 (UTC)

Agreed. This seems to be yet another geeky change that we non-geeks have no chance of understanding or implementing. I've got literally thousands of articles watchlisted that now have red error messages relating to this and have no idea what to do. - Sitush (talk) 09:17, 5 May 2019 (UTC)

Since neither of you actually identify specifically what it is that you find confusing or inscrutable or lacking, its hard for me to know how to improve the documentation. Still, I have had a go at it, which see.

If this is sufficient, great; if not, please say, in detail, what needs to be explained more fully.

I have discovered an oversight. |contribution-url-access= is not recognized as a legitimate parameter. Fixed in the sandbox:

Cite book comparison

Wikitext	{{cite book|contribution-url-access=subscription|contribution-url=//example.com|contribution=Contribution|title=Title}}
Live	"Contribution". Title.
Sandbox	"Contribution". Title.

for the nonce, |chapter-url-access= will work because the two are aliases.

I have a bot request pending that should properly fix the majority of deprecated |subscription= and |registration= uses.

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

I think this is quite helpful, thanks! I now understand how to add to an article that registration or subscription is needed. I don't understand when to add the free parameter though. What are 'named identifiers', and why those documents are assumed not free? Femke Nijsse (talk) 20:49, 5 May 2019 (UTC)

Named identifiers that support |<identifier>-access= are: |bibcode=, |doi=, |hdl=, |jstor=, |ol=, and |osti=. These can (when the source is free-to-read, link directly to the source. There are a lot of other named identifiers; some are always free-to-read (listed in the doc) but most of the others are either behind a paywall or registration barrier, or are metadata about the source (|pmid= is one such).

This citation is from Climate sensitivity:

{{cite journal|author=Previdi|first=M. |display-authors=etal |date=20 June 2013 |title=Climate sensitivity in the Anthropocene |journal=Quarterly Journal of the Royal Meteorological Society |volume=139 |issue=674 |pages=1121–31 |bibcode=2013QJRMS.139.1121P |citeseerx=10.1.1.434.854 |doi=10.1002/qj.2165}}

Previdi, M.; et al. (20 June 2013). "Climate sensitivity in the Anthropocene". Quarterly Journal of the Royal Meteorological Society. 139 (674): 1121–31. Bibcode:2013QJRMS.139.1121P. CiteSeerX 10.1.1.434.854. doi:10.1002/qj.2165.

If you follow the doi link, you will see right at the top under the journal title block: 'Free Access'. Because of that, |doi-access=free should be added to the template:

{{cite journal|author=Previdi|first=M. |display-authors=etal |date=20 June 2013 |title=Climate sensitivity in the Anthropocene |journal=Quarterly Journal of the Royal Meteorological Society |volume=139 |issue=674 |pages=1121–31 |bibcode=2013QJRMS.139.1121P |citeseerx=10.1.1.434.854 |doi=10.1002/qj.2165 |doi-access=free}}

Previdi, M.; et al. (20 June 2013). "Climate sensitivity in the Anthropocene". Quarterly Journal of the Royal Meteorological Society. 139 (674): 1121–31. Bibcode:2013QJRMS.139.1121P. CiteSeerX 10.1.1.434.854. doi:10.1002/qj.2165.

Publishers appear to be getting better at labeling journal articles that are free-to-read, but not every such article is labeled. If you can read the whole thing, though, chances are it is free-to-read and should be marked as such with the appropriate access-indicator parameter.

—Trappist the monk (talk) 22:15, 5 May 2019 (UTC)

I appreciate the attempt to improve things but I'm still not getting it. The documentation seems to imply that if I continue to use the subscription parameter with "yes" then no error should be generated but in fact it causes an ugly "deprecated parameter" message that has a generic help link. I've been trying things out using preview etc and am getting nowhere so deliberately introduced an error at the Babaria article just now - see this diff. The sources are all paywalled JSTOR stuff. Can anyone sort it out, please, because it is driving me daft - newbies struggle with the "old" templated system but the changes in the last couple of years are coming close to driving me away from this project, so lord knows what newbies think of it. I hate seeing red warning messages all over my nicely crafted articles, and having to go round in circles updating the things every time there is a change. - Sitush (talk) 16:17, 9 May 2019 (UTC)

Deprecated parameters still work as they should. But, because they are deprecated, they will stop working (and you'll get the red unrecognized parameter error message). The deprecated error message shows interested editors that they need to take some action to replace the deprecated parameters and they categorize the article so that a disinterested bot or gnome can delete, replace, fix the deprecated parameter.

Identifier access parameters are not replacements for identifier parameters. Identifier access parameters are used with identifier parameters to indicate that the source linked by the identifier is free-to read. If the source linked by the identifier is not free-to-read, then omit the identifier access parameter.

So, this template from Babaria:

{{cite journal |last=Brown |first=Mark |title=Ethnology and Colonial Administration in Nineteenth-Century British India: The Question of Native Crime and Criminality |journal=The British Journal for the History of Science |volume=36 |issue=2 |year=2003 |pages=201–219 |jstor-access=4028233 |subscription=yes}}

Brown, Mark (2003). "Ethnology and Colonial Administration in Nineteenth-Century British India: The Question of Native Crime and Criminality". The British Journal for the History of Science. 36 (2): 201–219. {{cite journal}}: |jstor-access= requires |jstor= (help); Invalid |jstor-access=4028233 (help); Unknown parameter |subscription= ignored (|url-access= suggested) (help)

should be rewritten (|jstore-access= omitted because the source is behind a paywall or registration barrier):

{{cite journal |last=Brown |first=Mark |title=Ethnology and Colonial Administration in Nineteenth-Century British India: The Question of Native Crime and Criminality |journal=The British Journal for the History of Science |volume=36 |issue=2 |year=2003 |pages=201–219 |jstor=4028233}}

Brown, Mark (2003). "Ethnology and Colonial Administration in Nineteenth-Century British India: The Question of Native Crime and Criminality". The British Journal for the History of Science. 36 (2): 201–219. JSTOR 4028233.

If you think that the help text linked by the error messages is wrong, incomplete, misleading, whatever, please say what you think is the problem. You wrote: The documentation seems to imply that if I continue to use the subscription parameter with "yes" then no error should be generated. Where did you read that?

—Trappist the monk (talk) 16:41, 9 May 2019 (UTC)

@Sitush: Hmm. Does this help:

There was an RfC (or was it two?) about how and when to indicate access restrictions (or lack of them). That RfC didn't quite settle all the issues, but it did establish some principles. One is that access should not be indicated at the level of the citation as a whole (as |subscription=yes does): it should be indicated per link (|url=) or identifier (|doi=, |jstor=, etc.), because some of these may be free to access and some may be paywalled even if it is the same article. The RfC also decided that links and identifiers have a default assumed access level: |url= is by default assumed to be free to access, while |jstor= is by default assumed to be paywalled. And, crucially, the assumed default access level should not be explicitly indicated!

Thus, if your ciitation has an |url= that is free to access, or a |jstor= that is paywalled, there should be no access indicator on the citation (at all). If, on the other hand, you have |url= that is paywalled, or a |jstor= that is free to access, you can indicate this with |url-access=subscription and |jstor-access=free.

Personally I dislike this approach and disagree with the outcome of the RfC, but that was the result. To mimic the effect of the now-deprecated |subscription=yes parameter you have to add the template {{subscription required}} outside the citation template (but typically somewhere inside the ref tag or similar). I don't recommend you do so as this will inevitably become a poiint of contention eventually; but if you feel strongly about this issue (in WP:CITEVAR terms) then that is the workaround that's available. --Xover (talk) 17:04, 9 May 2019 (UTC)

Got it, thanks. Sorry if I sound annoyed - I'm not, just frustrated. I got the info about the subscription thing from the link you provided above, which is this and says, inter alia, "Setting |registration= or |subscription= to any value other than y, yes, or true will generate an error message." - Sitush (talk) 17:02, 9 May 2019 (UTC)

Addendum: so now, using the JSTOR thing for paywalled stuff, the reader gets no prior indication that it *is* paywalled? They just potentially waste a click to find out? - Sitush (talk) 17:05, 9 May 2019 (UTC)

That is indeed the case now, yes. Readers are presumed to just know that JSTOR links are paywalled unless otherwise indicated. --Xover (talk) 17:12, 9 May 2019 (UTC)

Thanks for your explanation above - we had an edit conflict there. - Sitush (talk) 17:15, 9 May 2019 (UTC)

(edit conflict) That sentence is at the end of the Ambiguous access parameters section where |subscription= and |registration= are clearly marked as deprecated. Those two parameters still function but accept only a limited number of values: yes, y, true. Any other value is rejected and the template emits an invalid parameter value. This is not the error message that you were seeing with |subscription=yes; cf:

{{cite journal |title=Title |journal=Journal |subscription=yes}}

"Title". Journal. {{cite journal}}: Unknown parameter |subscription= ignored (|url-access= suggested) (help)

{{cite journal |title=Title |journal=Journal |subscription=no}}

"Title". Journal. {{cite journal}}: Unknown parameter |subscription= ignored (|url-access= suggested) (help)

Because most sources linked by named identifier parameters lie behind paywall or registration barriers, readers will soon learn that those links are not free-to-read. Including a red or gray access icon with every such named identifier link is overkill (especially in scientific and medical articles where it is common to find multiple named identifiers in citation after citation after citation; in essence, a sea of red. Instead, we elected to highlight those identifiers that defy the norm. When |doi= links to a free-to-read journal article, that doi should be highlighted (with |doi-access=free) so that readers know that it is free-to-read. The same, in the opposite sense applies to sources linked by |url= – free-to-read unless otherwise stated.

—Trappist the monk (talk) 17:40, 9 May 2019 (UTC)

Categorization of registration/subscription

Right now, |subscription= and |registration= cause categorization of pages; see in Module:Citation/CS1/Configuration:

	['subscription'] = '<span class="cs1-subscription">(Subscription required (<span title="The site requires a paid subscription to access this page.">help</span>))</span>' ..
		'[[Category:Pages containing links to subscription-only content]]',
	
	['registration']='<span class="cs1-registration">(Registration required (<span title="The site requires registration to access this page.">help</span>))</span>' ..
		'[[Category:Pages with login required references or sources]]',

Do we want to do the same with the Access parameters? I did not see anywhere that this categorization occurs. --Izno (talk) 13:18, 5 May 2019 (UTC)

I don't know. But, if we do, they should be properties cats that are distinct from Category:Pages with login required references or sources (shared with {{registration required}}) and Category:Pages containing links to subscription-only content (shared with {{subscription required}}). Perhaps Category:CS1 sources limiting access, Category:CS1 sources requiring registration, and Category:CS1 sources requiring subscription.

—Trappist the monk (talk) 13:56, 5 May 2019 (UTC)

better |xxx-url-access= error reporting

I've tweaked Module:Citation/CS1/sandbox so that the error messages emitted when something is not right with the |xxx-url-access= parameters, show the name of the actual parameters involved:

Cite book comparison

Wikitext	{{cite book|article-url-access=subscript|article=Article|chapter-url=//example.com|title=Title}}
Live	"Article". Title. {{cite book}}: Invalid |article-url-access=subscript (help)
Sandbox	"Article". Title. {{cite book}}: Invalid |article-url-access=subscript (help)

and aliasing still works:

Cite book comparison

Wikitext	{{cite book|article-url-access=subscription|article=Article|chapter-url=//example.com|title=Title}}
Live	"Article". Title.
Sandbox	"Article". Title.

—Trappist the monk (talk) 18:06, 5 May 2019 (UTC)

Examples of how to use the templates

The example given of saying to use "|website=The New York Times", not "|website=The New York Times |publisher=The New York Times Company" is nearly worthless because it is too obvious. Are the following examples correct and supported by a strong consensus?

• I find an article at cnn.com, a website self-identified as "CNN" on its heading banner, so I should use "|website=CNN" and not use |publisher=.
• I find an article at bbc.co.uk, a website self-identified as "BBC" on its heading banner, so I should use "|website=BBC" and not use |publisher=.
• I find an article at abcnews.com, a website self-identified as "ABC News" on its heading banner, so I should use "|website=ABC News" and not use |publisher=.
• I find an article at npr.org, a website self-identified as "NPR" on its heading banner, so I should use "|website=NPR" and not use |publisher=.
• I find an article at pbs.org, a website self-identified as "PBS" on its heading banner, so I should use "|website=PBS" and not use |publisher=.
• I find an article at wgntv.com, a website self-identified as "WGN" or "WGN TV" or "WGN 9" on its heading banner, so I should use "|website=WGN-TV" (or similar) and not use |publisher=.
• I find an article at ap.org, a website self-identified as "AP" or "Associated Press" on its heading banners, so I should use "|website=Associated Press" and not use |publisher= and not use |agency=.
• I find an article at reuters.com, a website self-identified as "Reuters" on its heading banners, so I should use "|website=Reuters" and not use |publisher= and not use |agency=.

These explicit examples would be much more helpful to readers than the trivial NYT example. These sites and similar ones account for a very large number of citations. It is evident from the discussion at Talk:Mueller Report that not everyone is interpreting the current guidance in a manner consistent with those examples. For most of these examples, some people seem to think that |website= should not be used, and |publisher= should be used instead.

—BarrelProof (talk) 01:39, 6 May 2019 (UTC)

The main difference is one is italic. Think of that way. Typically one would not italic "PBS" because that is the name of a corporate entity, but you might pbs.org since that is the name of a product or work owned by the publisher PBS. -- GreenC 03:53, 6 May 2019 (UTC)

These examples do not involve using "pbs.org" in the template – that is just the domain name of the place I said I found an article, and I'm not advocating to use that in the template. If I understand correctly, using that in the template is already discouraged in the guidelines – people should use the name of the site, not its web address ("On websites, in most cases 'work' is the name of the website"). Are you saying that you think the example usage that I gave is not correct? The question is not about "pbs.org"; it is about whether "[[PBS]]" should be put into "work" or should be put into "publisher" instead. Which one of those are people supposed to use? My understanding is that people are supposed to use |work= and not use |publisher= in that example, based on language such as that saying "The 'publisher' parameter should not be included ... where it would be the same or mostly the same as the work." That seems to say that "work" is primary and "publisher" something secondary that is only to be included when substantially different from the name of the work/website (e.g. if the PBS website was published by some other substantially different entity). It sounds like you may disagree. Whichever is the case, we should provide relevant examples so that people have some guidance about what to do. I do not see adequate examples currently to clearly describe what is the recommended practice for any of the above examples. —BarrelProof (talk) 04:09, 6 May 2019 (UTC)

My understanding has been that the names of websites are italicized in citations. I've understood that that is different from how the MoS says to refer to websites in text. It's kind of weird, but there's lots of weird things on Wikipedia. A domain name is not the name of the website. It should be more clear in the instructions, or maybe I'm wrong. In that case it's very unclear. SchreiberBike | ⌨  04:43, 6 May 2019 (UTC)

BarrelProof, anything in the |work= will render italicized by the citation template. Things that are italicized are names of newspapers, TV shows (PBS Newshour), magazines, websites (pbs.org, etc.. but names of companies are not italicized they belong in the |publisher=. Thus PBS, Associated Press, Reuters are all names of publishers ie. not italic. The instructions are saying to use the more specific if available eg. |work=PBS NewsHour vs |publisher=PBS but if all you have is "PBS" (ie. you don't know which PBS show) then it belongs in the |publisher= field because "PBS" is not the name of a work, it is a publisher and should not be italic. -- GreenC 05:00, 6 May 2019 (UTC)

There seems to be constant confusion over "publication" vs "publisher", and some people find it difficult to appreciate the difference. The publication is the thing that you buy, the name you use when asking at the counter of a shop or library; the publisher is the person or organisation that you instruct your solicitors to sue when the publication has libelled you. The publisher is of much less use than the name of the publication when obtaining a source for the purposes of verifying a claim made in one of our articles. Of course, if one of our articles libels you, and you can trace it from our article back to its source, that being a similarly-untrue statement made in a publication, you may then need the name of the publisher in order to serve a writ. But you can get that from the small print at the bottom, it doesn't need to be in our cite template.

In the case of Associated Press and Reuters, these are not likely to be the names of publishers, but far more likely to be news agencies, and as such should go in the |agency= parameter. --Redrose64 🌹 (talk) 08:56, 6 May 2019 (UTC)

True but if the source link is direct (eg. the Reuters website) do you still use |agency=? One could get a 3-credit-hour undergrad class in CS1|2 usage. -- GreenC 15:27, 6 May 2019 (UTC)

I find the |agency= documentation to be somewhat lacking (is anyone surprised at that?):

• agency: The news agency (wire service) that provided the content; examples: Associated Press, Reuters, Agence France-Presse. May be wikilinked if relevant.

I have always thought that |agency= only comes into play when a cited news article was written by an author for the agency but is published in an unrelated source (typically a newspaper); the author is not employed by the paper. It would seem that the simple rule is: use |agency= when an agency is named in a news article's byline. I don't know of any other reasons to use |agency=. Are there any?

—Trappist the monk (talk) 16:15, 6 May 2019 (UTC)

Exactly (and see also Trappist's point elsewhere in here about |agency= not even being part of the emitted COinS metadata). If you are citing ap.org, the work is Associated Press (the website by that title, though some might prefer to give it as AP.org), and the publisher is also Associated Press (and should be omitted as redundant if you give that longer name in the title). The |agency=} parameter simply doesn't apply unless some other news publisher has used AP as a news agency. I'm not sure why anyone has difficultly like this. It's like not being able to understand that a doctor might also be a golfer, or that Wolfgang Puck is a person and also a trademarked brand name associated with that person. That said, making the docs clearer would be a good idea. PS: With |agency=, there often is no known author (no by-line), so it's not really about who the author works for, it's about what entity had primary editorial control over the piece, creation credit for it, and responsibility for the research behind (and any errors in) the piece. Newspapers often barely skim much less fact-check or revise what they reprint from newswires.  — SMcCandlish ☏ ¢ 😼  22:03, 6 May 2019 (UTC)

What a tempest... Re: a parenthetical point made by SMcCandlish in that other conversation:

({{cite book}} is an exception, in which the title and work parameters are aliases, and the param. for a sub-work is |chapter=)

Conceptually maybe; in actuality, no. Aliasing implies a certain interchangeability: |work= can be interchanged with |journal= or |website=, for example. But, you cannot interchange |title= and |work= in {{cite book}} nor can you interchange |article= (a |chapter= alias) for |title= in {{cite magazine}} or any of the other periodical templates – perhaps, were we writing these templates from scratch we would do it differently ... but, alas, we are saddled with heritage.

I wonder if OP's list might be recast as a set of recommendations under Help:Citation Style 1 § Work and publisher; maybe as a table or some such. I find the original list above to be too fraught with emotion. We have also seen heated discussions along these same lines with regard to Rotten Tomatoes and Metacritic haven't we? Perhaps the recommendation list could include those and similar.

—Trappist the monk (talk) 16:15, 6 May 2019 (UTC)

I didn't actually know that |work= would still not function as an alias of |title= in {{Cite book}}. Thought we fixed that a long time ago. That should probably be implemented, along with ability to use |article= for |work= in the periodical templates. What we have now is a weird mishmash of of |work= |mostly= functioning as the italicized title of major/main work, with one exception, plus a mostly functioning set of more descriptive aliases for the quotation-marked title of the minor/sub-work on a publication-type basis, with several exceptions. The incompleteness of the alias mapping, the seemingly accidental exceptions, is likely a major source of common confusion about how to use the parameters.  — SMcCandlish ☏ ¢ 😼  22:27, 6 May 2019 (UTC)

I think I'm hearing people say that when the name of the website would not normally be italicized in text, that we then don't use the name of the website, but we refer to them as a publisher. I think I can understand the rationale for that when referring to CNN or PBS, but what about something like:

• "910127.00 – 7289 – Monostoecha semipectinata – (Hulst, 1898)". North American Moth Photographers Group. Mississippi State University. Retrieved May 6, 2019.

There, we have the name of a website, which would not normally be italicized in text and the name of the publisher. Doesn't that mean that we italicize the names of websites in citations even when we don't italicize them in text? I have no strong feelings about this, but that is how I've interpreted the guidelines. SchreiberBike | ⌨  17:51, 6 May 2019 (UTC)

I wonder if we need another parameter name, such as |plainfontwebsite= or |websiteorganization=, although that's getting complicated. Your example could also hypothetically use "|publisher=North American Moth Photographers Group |via=Mississippi State University". —BarrelProof (talk) 18:25, 6 May 2019 (UTC)

I think the example above is perfectly fine with |website=North American Moth Photographers Group and |publisher=Mississippi State University. Not to complicate things, but I fear that |via= (and apparently |agency=) is a whole other (hopefully slightly less) complicated mess. - Paul^T+/_C 19:27, 6 May 2019 (UTC)

Don't the cs1|2 templates have enough parameters? Let's not invent new parameters for this or any other problem until we've pretty much exhausted all other possible solutions.

—Trappist the monk (talk) 21:42, 6 May 2019 (UTC)

We don't "need" (and shouldn't have) a way to cite works without italicizing them. 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. If someone wants to change MOS:TITLES to have an "except when the source is electronic" exception, go propose one at WT:MOSTITLES (I predict a WP:SNOW close against the idea; it's not like we haven't been over this before).  — SMcCandlish ☏ ¢ 😼  22:03, 6 May 2019 (UTC)

I'm primarily focused on {{cite news}} and {{cite web}} rather than {{cite book}}. MOS:ITALICTITLE says that the names of "news sites with original content should generally be italicized (Salon or HuffPost)." All of my above examples fit the description of "news sites with original content". However, none of those examples have italic titles on the linked articles about them on Wikipedia. A key issue seems to be when the name of the website/work is the same as the name of the organization that produces it (and seems more like the name of the organization than the name of its publication). Some people (e.g., Psantora, Mandruss, Starship.paint and GreenC) seem to think that in such a case, we should use "publisher" and not "website/work", to prevent the name from being rendered in italics. Others (e.g., SMcCandlish, and at least until a few days ago, myself and SchreiberBike) seem to think that we should just use "work" and not use "publisher" in such cases. Then there are also cases like Rotten Tomatoes, Metacritic, and Box Office Mojo, as noted by Trappist the monk – another complication perhaps based on the idea of not being "original content". Anyhow, I currently see two overall basic schools of thought:

1. "Pick the parameter name based on whether italics should be applied to it or not" (e.g., use "publisher=[[CNN]]" and leave "website" unused), versus
2. "Always use the 'work' parameter, and only include 'publisher' if it is different from the name of the work and seems necessary" (e.g., use "website=[[CNN]]" and leave "publisher" unused).

—BarrelProof (talk) 18:25, 6 May 2019 (UTC)

Re 'Others (e.g., SMcCandlish, and at least until a few days ago, myself and SchreiberBike) seem to think that we should just use "work" and not use "publisher"' – It's not a matter of what you or I think, but a matter of what the guidelines say. The publisher is optional and should be omitted when redundant with the work title.  — SMcCandlish ☏ ¢ 😼  22:03, 6 May 2019 (UTC)

If we can just add these examples explicitly to the guidelines, I will be satisfied. Without the examples, there will continue to be confusion over these very common cases. —BarrelProof (talk) 23:25, 6 May 2019 (UTC)

One additional complication: I've seen editors use double-apostrophes in the work/website value to turn off the italics per the article title, as |website=''[[CNN]]''. Yes, this actually works.

Look, I don't particularly care which way we go, what I care about is that editors are on the same page so we're not doing what I call "churning": i.e. working against each other, continuously "correcting" others' work, often without even being aware that others are "correcting" ours, never approaching site-wide consistency. That is an utter waste of editor resources, yet we do it all the damn time in dozens of areas like this. The only way to achieve that is to (1) get clear community consensus, and (2) make the instructions clear and easily accessible to all editors. ―Mandruss ☎ 18:46, 6 May 2019 (UTC)

Well said. Yes, I've seen |website=''[[CNN]]'' also, but not very often, and I thought it was just some amateurish attempt to fight against the established system rather than being an approved practice. In addition to the churning problem and site-wide inconsistency, there are many articles with inconsistent citation formatting within a single article; that makes Wikipedia seem sloppy and unprofessional. —BarrelProof (talk) 18:57, 6 May 2019 (UTC)

Given |website=CNN as an example: According to the MLA, CNN should never be italicized as it is a television or radio station. This guide says do not italicize CNN in citations. The AP Style Guide does not italicize CNN. etc.. So I don't understand the second school of thought. There's no rationale basis for an italic CNN. This is probably why people add |website=''[[CNN]]'' because on the one hand they recognize it should not be italic but on the other they believe |website= is the correct field since they are referring to the news channel (publication) and not the company (publisher). -- GreenC 19:15, 6 May 2019 (UTC)

GreenC, since you referenced these "sources" below:

• According to the MLA, In MLA style, you should use the title of a Web site as it appears on the site and italicize it as you would any independent work.
• "This guide" refers to penandthepad.com, some random site that is not any authority on the matter.
• The AP Style Guide (I think you mean AP Stylebook) you linked is actually an outdated (from 2008) undergraduate course guide supposedly citing the AP guidelines.

Regardless of what any external style guide says, Wikipedia has its own Manual of Style that takes precedence. - Paul^T+/_C 19:27, 7 May 2019 (UTC)

(edit conflict)In response to the ping above, I've been thoroughly convinced to change my position by the prior conversation (andthough I haven't gotten a chance to express this yet there yet).) that, in In almost every case, the more specific |website=/|work= should be used, regardless of whatever is expected for normal italicization in prose/article titles for the (presumably wikilinked) entity in question. The entity is being cited as some kind of publication in the reference and as such the entity should be italicized as is standard for the cite templates. (Yes, including PBS, Associated Press,^* Reuters,^* CNN,^† Rotten Tomatoes, Metacritic, and Box Office Mojo.)

^*: These two, and other similar entities, should probably use the even more specific |agency=.Clarification, |agency= should probably only be used when "AP" or "Reuters" content is published by someone other than them directly. In those cases where the citation is directly to/from their own sites, |website= should be used over |agency= by the same logic that we don't need the same information repeated in the |work= and |pubilsher= parameters. (But I may be missing a subsequent situation if the authorship is in question as well as the work/publisher.)

^†: In these cases CNN is being cited as CNN.com, the website, not the television or radio station.

Having said that, I 100% echo Mandruss above: The only way to achieve that is to (1) get clear community consensus, and (2) make the instructions clear and easily accessible to all editors. and I think SMcCandlish has made (very productive) changes to some of those instruction pages to work towards point 2. Point 1 is clearly controversial based on the repeated debates about the current ambiguity on this topic, but I'm hopeful that by the end of this one there will finally be that consensus so that any future discussions can be handled quickly and easily (or at least more quickly or easily). - Paul^T+/_C 19:27, 6 May 2019 (UTC)

@Psantora: by the end of this one Is it your view that a consensus in this non-RfC, relatively low-visibility discussion will be (or should be) sufficient "community consensus"? ―Mandruss ☎ 20:07, 6 May 2019 (UTC)

Likely not. But a man can dream. Seriously though, reasonably, how wide of a discussion beyond here is needed? A pointer here from WP:VP/P, WT:MOS, or WT:CS might be a good idea, but it seems somewhat excessive. This is a minorrelatively obscure discussion about italicization and template metadata. Sure, it has a wide impact in the sense that many editors (myself included) currently misunderstand/misunderstood how to apply it, but this really is a clarification of an existing policy/guideline. I don't think anyone is proposing anything radically new here - just to clarify the examples so that there is less (ideally no) ambiguity. - Paul^T+/_C 20:21, 6 May 2019 (UTC)

@Mandruss: Clearly, my dreams for by the end of this one have crumbled into dust ... obscure topic or not. Add another tally for someone (me) supporting a proper RfC on this topic. I think we have a half-dozen supporters for it in this discussion alone. - Paul^T+/_C 18:20, 9 May 2019 (UTC)

I'm not really interested in being part of this squabble. But ... I think (and have done for some time now) that |website=''[[CNN]]'' should not be supported by Module:Citation/CS1. Similar wiki markup in |publisher= should also not be supported. The documentation in all of the cs1|2 templates states that editors should not use wiki markup in those parameters that contribute to the template's metadata (see for example Template:Cite web#COinS). Wiki markup is permitted in |title= because titles like the moth cite above, need to render the scientific name correctly so the module suite removes the markup before the title is added to the metadata. Adding wiki markup to |work= (and aliases) or |publisher= (and aliases) to modify how the citation renders is gaming the system in much the same way as simply swapping |work= for |publisher= or the other way round.

You will note that |agency= is not one of those parameters that is made part of the citation's metadata. Using that parameter in the belief that it is a more specific form of work only means that the rendered metadata does not include the work. Those who consume these citations via the metadata get, as a result, an incomplete citation that is missing an important piece of information. Don't do that to those cousumers.

—Trappist the monk (talk) 20:12, 6 May 2019 (UTC)

Agreed on both points. (I think I amended my comments on |agency= to reflect a part of your latter point while you were writing your comment.) - Paul^T+/_C 20:28, 6 May 2019 (UTC)

Yep, you did. Thanks.

—Trappist the monk (talk) 21:42, 6 May 2019 (UTC)

Paul, what you are saying goes against all reliably sourced style guides, and common sense. Of course we can do whatever we want, but your proposal is against the grain of how the rest of how the world does citations. Nobody italicizes CNN, or WNYU-FM, etc.. it's silly and looks bizarre. -- GreenC 22:06, 6 May 2019 (UTC)

A few short days ago, I would have agreed with you. You are right: CNN, when referring to the company or TV station/network is *not* italicized. But, in a reference, when we are citing the "work" "CNN.com", it should be italicized. - Paul^T+/_C 00:16, 7 May 2019 (UTC)

@Psantora: Yes for CNN.com because it is a publication/work, but you said In almost every case, the more specific |website=/|work= should be used, regardless of whatever is expected for normal italicization in prose/article titles (emphasis added). This is justified by The entity is being cited as some kind of publication in the reference and as such the entity should be italicized as is standard for the cite templates. The problem is that people often don't use the name of the publication, they use the name of the publisher (CNN vs. CNN.com). This is permissible and allowable. If they choose to specify the publisher, CNN belongs in the |publication= because CNN is not italic. We encourage people to use a more specific |work= field, but it's not required. The problem is when someone adds |work=CNN it's a contradiction (a publisher name in the work field). That is really the source of the problem (as noted by others elsewhere), confusion over the difference between a publisher and publication. If we encourage editors to always use |work= even when the value string is not a publication (per your emphasized text above) this would be a mistake both in how the text is displayed ie. italic when it shouldn't be, and assuming editors don't actually mean or want the publisher as the better choice. -- GreenC 15:58, 7 May 2019 (UTC)

Right again, GreenC... but, see WP:COMMONNAME. "CNN.com" can easily be referred to as "CNN" as in "I'm going to look up that article at CNN", where the "dot com" after "CNN" can be omitted without any confusion. There is no contradiction, just technicalities. As for regardless of whatever is expected for normal italicization in prose/article titles, it is specifically regarding being cited as some kind of publication in the reference and as such the entity should be italicized as is standard for the cite templates. Anything that is being used as a reference, by definition, is itself a publication. - Paul^T+/_C 16:14, 7 May 2019 (UTC)

Well, everything is italicized because it is a publication is a simple rule, but too simple. It would only work if one is using the name of a publication (PBS NewsHour vs. PBS), and only then if the publication is meant to be italicized, not all publications are. CNN, PBS etc. refer to a channel and are not italicized (style guidelines linked above specific to this). Reality is more difficult both in terms of what counts as a publication and when publications are italicized. Ideally a more specific italic work name is used, but if not available we use the publisher name. In cases like CNN this is a problem because CS1|2 has no mechanism for a non-italic work (other than the hack work=''[[CNN]]''), a best practice might be to use |publisher=CNN in these cases, which is accurate. -- GreenC 17:17, 7 May 2019 (UTC)

(edit conflict)Now we are going in circles.

• Re: CNN, PBS etc. refer to a channel those terms can also refer to a website - a publication - and, when part of a reference, should have italics.
• Re: a non-italic work that is an oxymoron - any work by definition and by design will have italics because it refers to a publication.
• Re: other than the hack work=''[[CNN]]'' this "hack" is a bug that is being fixed; don't do this.
• Re: use |publisher=CNN in these cases, which is accurate no, it is not, as explained in many different ways above.

Off the top of my head, the only way to correctly have |publisher=[[CNN]] is if CNN published a "work" (somewhere other than "CNN.com") where it was not obviously made by CNN (i.e. "CNN", "Cable News Network", etc. is not included in the title of the work) or if CNN published an actual, physical book. - Paul^T+/_C 18:25, 7 May 2019 (UTC) (In such cases, you would have both |publisher=[[CNN]] *and* |work=<the name of the work>. It would *never* be correct to have |publisher=[[CNN]] all on its own without a more specific |work=.) - Paul^T+/_C 18:46, 7 May 2019 (UTC)

Paul, it is incorrect all publications are italicized. I gave sources, CNN is never italicized in citations. Where is your source for the assertion that all publications are italicized? Look if it comes down to an RfC, reliable sources will take priority vs. user opinion. It looks like you came up with this idea because CS1|2 is inflexible and must italicize the work field, and from that you back tracked and came up with the notion that all publications must be italic "by definition" ie. how CS1|2 is coded! As if CS1|2 source is authoritative. There is no definition that says all publications are italic (other than in the Lua source code), every style guideline says just the opposite. -- GreenC 19:07, 7 May 2019 (UTC)

Well, frankly, you are mistaken. See my comments above regarding your "sources" (and one to support my "assertion" as well). - Paul^T+/_C 19:27, 7 May 2019 (UTC)

So even if I were to agree all website names are italicized per the MLA link you provided, there are times when linking to CNN because it was on TV (not the website), and the same MLA guideline you are citing (8th edition) says do not italicize TV channels. Your MLA source supports what I said, publications are not always italicized. This is the key point, |work= always italicizes, which is not always correct behavior. -- GreenC 02:00, 8 May 2019 (UTC)

there are times when linking to CNN because it was on TV (not the website) Please give an example of that where it would be a valid source as part of a {{cite web}} or {{cite news}} reference. All the examples we are talking about here are regarding links to articles on websites, which are all works/publications and should be italicized. A TV channel is not a publication. - Paul^T+/_C 02:35, 8 May 2019 (UTC) (A TV show/program on the other hand, would be considered a publication and *surprise* italicized.) - Paul^T+/_C 02:42, 8 May 2019 (UTC)

Also note, the source you keep referencing is specifically about using the term in prose as part of an essay, not in a cited reference as part of an encyclopedia:

Do you use italics when mentioning the name of a television channel or radio station in an essay?

No, you should not italicize the names of television channels or radio stations. The show originally aired on Cartoon Network. She listed to the weather report on WCBS this morning.

Just something to keep in mind. - Paul^T+/_C 12:12, 8 May 2019 (UTC)

Lol your MLA source says nothing about encyclopedia citations, either. URLs are not required with {{cite news}}, not everything broadcast is available on the Internet. The name of the show would be nice but not everyone provides it, nor is it always true there is a show name. Look I'm done with the pedantry, users need the flexibility to determine italics or not and there is a solution, moving on. -- GreenC 17:29, 8 May 2019 (UTC)

It isn't "[my] MLA source", I am simply using the resource you are citing to show a contradiction and support the point that the part you cited does not apply to the situation we are talking about. "My source" (if that is what you want to understand) is WP:ITALICWEBCITE, the relevant guideline here. The point is that anything that can be used as a valid source (and not be WP:OR) necessarily is a "published work" and therefore would by definition get italics. That is why I'm asking for an example where when linking to CNN it would be correct not to italicize "CNN". If there is a single example out there I have yet to see it, because in all cases it, by definition, needs to be a "published work" (publication) and therefore gets italicized. - Paul^T+/_C 13:34, 15 May 2019 (UTC)

I think the primary and correct name for that website is "CNN", not "CNN.com". What is displayed on the website itself is just "CNN". The <title> tag on the site contains "CNN - Breaking News, Latest News and Videos" (no ".com"). It's hard to find "CNN.com" anywhere on that site (although I did find it on a subpage, where most people would not look). —BarrelProof (talk) 18:02, 7 May 2019 (UTC)

Should we settle this in an RFC? A definitive outcome is really needed... any other suggestions? starship.paint (talk) 09:05, 7 May 2019 (UTC)

I think we should consider whether editors should recognize, and maybe even fix, the use of the <title> tag by the website. In the aforementioned PBS case, their website contains <title>PBS: Public Broadcasting Service</title>. So that's the title of their website; they said so.

But sometimes websites use the title tag in a way that doesn't make much sense as a title; in that case, should we look at the overall layout of the website and take a guess at what the publisher wants the title to be? Jc3s5h (talk) 11:36, 7 May 2019 (UTC)

We should already not be blindly following HTML website <title> tags, and we should not always use "what the publisher wants the title to be" (since that would end up with junk like embedded non-neutral promotional slogans and multiple exclamation marks and all-caps formatting). People need to look at the site and make a judgment call as to what title is proper for it. In the case above, I would personally think that either "PBS" or "Public Broadcasting Service" would be acceptable, but not "PBS: Public Broadcasting Service". The <title> tag content on the CNN website is "CNN - Breaking News, Latest News and Videos", and we don't want that. —BarrelProof (talk) 14:02, 7 May 2019 (UTC)

The cite web template documentation now says: " • website: Title of website; may be wikilinked. Displays in italics. Aliases: work". There's no understanding in the documentation of putting the name of the website anyplace but |website=.

Fixes that involve putting the name of the website in some place other than |website= are bad adaptations that break the system. It destroys the usefulness of COinS metadata and confuses future editors.

It seems to me that we need to decide if the names of websites should be italicized in citations. Right now it seems that some are arguing that we should because |website= is an alias of |work= even though we wouldn't normally italicize them in text. Many are saying that we should not, so as to be in compliance with the MoS.

After that decision is made, then we need to figure out the technical fix; perhaps they should not be aliases. I can't imagine any solution that would not involve a huge amount of rework that could be partially automated (but my imagination is limited). Another option is to change the MoS to italicize websites. SchreiberBike | ⌨  19:21, 7 May 2019 (UTC)

Re: "Another option is to change the MoS to italicize websites": As far as these example websites are concerned, the MOS already says to generally italicize their names. MOS:ITALICTITLE says that the names of "news sites with original content should generally be italicized (Salon or HuffPost)." —BarrelProof (talk) 20:53, 7 May 2019 (UTC)

Attempt to conclude

I'd like to see a conclusion on this. I know it's been talked about before and no resolution has been reached, but Wikipedia looks best when it's consistent. Should the names of websites in citations be italicized?

Thoughts:

• Based on MOS:ITALICTITLE, in regular text websites should be italicized when they are "online magazines, newspapers, and news sites with original content".
• At MOS:ITALICWEBCITE, it says: "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."
• What about the idea that CNN, CBS, etc. are news websites and organizations. It could be that we would italicize them in the context of being a website (a work produced by the publisher of the same name), but not as a company, network, etc.
• Does it matter if the reference is created by one of the cite templates or is just wiki text?
• Would this apply to websites in External links sections?

 SchreiberBike | ⌨  06:12, 14 May 2019 (UTC)

The first two points do not contradict each other, as far as I can tell:

• In prose, CNN is 99% of the time referring to the organization and should be in plain text.
• In a reference, CNN is 100% of the time referring to something that has been published and therefore should be italicized.
• I think that is the point you are trying to make in the 3rd bullet.
• Ideally, all references will use the cite templates so that the proper metadata is applied to them and that they take advantage of the dead link features to archive the content being used as a reference.
• For the final point, I'm fairly certain that the "published publication" bit in point 2 above would apply and therefore would be italicized for the same reason.

Having said all that. I have been convinced that having a proper RFC is going to be necessary to get wide enough acceptance despite these points already being supported by the policy/guidelines you mentioned above. - Paul^T+/_C 12:42, 14 May 2019 (UTC)

Potential RfC

Please participate in developing a neutrally worded request for comment about the italicization of the names of websites in citations and references at User:SchreiberBike/Workspace/Italics of websites in citations and references. This is intended to be an effort to write an RfC.

To talk about the wisdom of an RfC, please comment below. Thank you. SchreiberBike | ⌨  05:01, 15 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.

{{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-000000AF-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" 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-000000B3-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" 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):

Cite journal comparison

Wikitext	{{cite journal|accessdate=March 5, 2017|doi=10.11922/csdata.170.2015.0029|format=pdf|journal=''<span title="Chinese-language text"><span lang="zh-Hans">中国科学数据2016年第2期</span></span>''|script-title=zh:海南岛鲸类搁浅记录数据库（1993 ～ 2015 年）|url=http://old.csdata.org/finalPDF/31/.pdf|year=2016}}
Live	海南岛鲸类搁浅记录数据库（1993 ～ 2015 年） (pdf). 中国科学数据2016年第2期. 2016. doi:10.11922/csdata.170.2015.0029. Retrieved March 5, 2017. {{cite journal}}: Italic or bold markup not allowed in: |journal= (help)
Sandbox	海南岛鲸类搁浅记录数据库（1993 ～ 2015 年） (pdf). 中国科学数据2016年第2期. 2016. doi:10.11922/csdata.170.2015.0029. Retrieved March 5, 2017. {{cite journal}}: Italic or bold markup not allowed in: |journal= (help)

Original url commented out so as not to cause horizontal scrolling

Another, from Insulin:

Cite journal comparison

Wikitext	{{cite journal|authorlink1=Chen-Lu Tsou|first1=Chen-lu|issue=6|journal=''生命科学''[Chinese Bulletin of Life Science]|language=zh-hans|last1=Tsou|pages=777–79|script-title=zh:对人工合成结晶牛胰岛素的回忆|trans-title=Memory on the research of synthesizing bovine insulin|volume=27|year=2015}}
Live	Tsou, Chen-lu (2015). 对人工合成结晶牛胰岛素的回忆 [Memory on the research of synthesizing bovine insulin]. 生命科学[Chinese Bulletin of Life Science] (in Simplified Chinese). 27 (6): 777–79. {{cite journal}}: Italic or bold markup not allowed in: |journal= (help)
Sandbox	Tsou, Chen-lu (2015). 对人工合成结晶牛胰岛素的回忆 [Memory on the research of synthesizing bovine insulin]. 生命科学[Chinese Bulletin of Life Science] (in Simplified Chinese). 27 (6): 777–79. {{cite journal}}: Italic or bold markup not allowed in: |journal= (help)

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 SMcCandlish 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+/_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, 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 |<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 |<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 WP:IDHT / WP:1AM / WP:NOT#ADVOCACY / 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)

Notes

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

Cite book comparison

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

'"`UNIQ--templatestyles-000000E3-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" 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>

Cite news comparison

Wikitext	{{cite news|newspaper=''Newspaper''|title=Title}}
Live	"Title". Newspaper. {{cite news}}: Italic or bold markup not allowed in: |newspaper= (help)
Sandbox	"Title". Newspaper. {{cite news}}: Italic or bold markup not allowed in: |newspaper= (help)

'"`UNIQ--templatestyles-000000EA-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" 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)

Cite book comparison

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

'"`UNIQ--templatestyles-000000F1-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" 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>

Cite news comparison

Wikitext	{{cite news|newspaper=((''Newspaper''))|title=Title}}
Live	"Title". ((Newspaper)). {{cite news}}: Italic or bold markup not allowed in: |newspaper= (help)
Sandbox	"Title". ((Newspaper)). {{cite news}}: Italic or bold markup not allowed in: |newspaper= (help)

'"`UNIQ--templatestyles-000000F8-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" 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-000000FC-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" 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:

Cite book comparison

Wikitext	{{cite book|chapter=Chapter|script-title=ar:|title=Title}}
Live	"Chapter". Title. {{cite book}}: Invalid |script-title=: missing title part (help)
Sandbox	"Chapter". Title. {{cite book}}: Invalid |script-title=: missing title part (help)

Cite book comparison

Wikitext	{{cite book|chapter=Chapter|script-chapter=No Prefix Script-Chapter|title=Title}}
Live	"Chapter" No Prefix Script-Chapter. Title. {{cite book}}: Invalid |script-chapter=: missing prefix (help)
Sandbox	"Chapter" No Prefix Script-Chapter. Title. {{cite book}}: Invalid |script-chapter=: missing prefix (help)

Cite book comparison

Wikitext	{{cite book|chapter=Chapter|script-title=en:Invalid Prefix Script-Title|title=Title}}
Live	"Chapter". Title Invalid Prefix Script-Title. {{cite book}}: Invalid |script-title=: unknown language code (help)
Sandbox	"Chapter". Title Invalid Prefix Script-Title. {{cite book}}: Invalid |script-title=: unknown language code (help)

Cite book comparison

Wikitext	{{cite book|contribution=Contribution|script-contribution=xx:Invalid Prefix Script-Contribution|script-title=ar:Script Title|title=Title}}
Live	"Contribution" xx:Invalid Prefix Script-Contribution. Title Script Title. {{cite book}}: Invalid |script-contribution=: invalid language code (help)
Sandbox	"Contribution" xx:Invalid Prefix Script-Contribution. Title Script Title. {{cite book}}: Invalid |script-contribution=: invalid language code (help)

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)

Cite journal comparison

Wikitext	{{cite journal|title=Title}}
Live	"Title". {{cite journal}}: Cite journal requires |journal= (help)
Sandbox	"Title". {{cite journal}}: Cite journal requires |journal= (help)

Cite news comparison

Wikitext	{{cite news|title=Title}}
Live	"Title".
Sandbox	"Title".

Cite magazine comparison

Wikitext	{{cite magazine|title=Title}}
Live	"Title". {{cite magazine}}: Cite magazine requires |magazine= (help)
Sandbox	"Title". {{cite magazine}}: Cite magazine requires |magazine= (help)

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

pages= parameter when there are more than 1,000 pages in a work

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 HELP:CS1#Pages 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+/_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+/_C 15:54, 8 May 2019 (UTC)

Cite journal comparison

Wikitext	{{cite journal|journal=Journal of Page Numbering|pages=1,234–1,256|title=Title}}
Live	"Title". Journal of Page Numbering: 1, 234–1, 256.
Sandbox	"Title". Journal of Page Numbering: 1, 234–1, 256.

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#Pages. Is ((...)) mentioned/documented anywhere 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 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 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)

Citing norms and standards

Coming from {{citation}}, there seems to be neither any documentation on how to cite a formal norm or standard with a number, optional part number and release date, issued by one of the (inter)national standardization bodies like ISO, CEN/CENELEC (EN), IEC, IEEE, ETSI, EBU, ANSI, BS, DIN, JIS etc. nor any support for those identifiers in the code, only IETF RFCs are supported by a special parameter {{{rfc}}} (used as {{{input1}}} in {{Citation/identifier}}).

I could probably use generic {{{id}}}, but I wish there was a way to make it simpler and generate more harmonized formatting. I found {{cite ISO standard}}, which seems very limited, and tried to add something similar to the respective sandbox by introducing a new identifier iso. I would like to see some general advice and automation.

Standards are reliable sources, of course, but only few are available for free, which makes them less popular references. On the other hand, several standards do have a distinguished Wikipedia article, e.g. ISO 9, or provide a redirect to a more generic description of their topic, e.g. Romanization of Cyrillic. The following mockup is overly verbose, but it shows metadata that could be used. — Christoph Päper 10:07, 8 May 2019 (UTC)

{{cite standard
|publisher= European Committee for Standardization
|publisher-short= CEN
|original-publisher= International Organization for Standardization 
|original-publisher-short= ISO
|title= EN ISO 5456 — Technical drawings — Projection methods — Part 3: Axonometric representations 
|standard= EN ISO 5456
|part= 3
|category= Technical drawings 
|topic= Projection methods 
|subject= Axonometric representations
|original-date= 1996-06-15 
|year= 1999
|language= en, fr, de
|original-language= en, fr
|original-id= ISO 5456-3:1996
|id= EN ISO 5456-3:1999
|ics= 01.100.10
|csnumber= 11503
|ref= EN_ISO_5456-3 
|work item= CSF01073
|url= https://standards.cen.eu/dyn/www/f?p=204:110:0
|original-preview= https://www.iso.org/obp/ui#iso:std:iso:5456:-3:ed-1:v1:en
|original-purchase= https://www.iso.org/standard/11503.html
}}

I changed <source>...</source> to <pre>...</pre> to get this page out of Category:Pages with syntax highlighting errors.

As I said at that other conversation, if you think that there is sufficient need for this template, write it. I suspect that, as you have written it here, {{cite standard}} is too specialized for cs1|2 so will need to be its own template. Of the 23 parameters listed above, only 8 are supported by cs1|2 and one of those, |subject=, has a different meaning from how you would use it. A wrapper template around a cs1|2 template is likely to be insufficient though starting small with a wrapper might help you to understand how best to handle the various parameters and the formatting headaches that you will encounter.

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

The whole "short"/"original" is not interesting for a citation. Cite the document referenced. The below is more reasonable in this regard.

{{cite standard
|publisher= European Committee for Standardization
|title= EN ISO 5456 — Technical drawings — Projection methods — Part 3: Axonometric representations 
|standard= EN ISO 5456
|part= 3
|category= Technical drawings 
|topic= Projection methods 
|subject= Axonometric representations
|year= 1999
|language= en, fr, de
|id= EN ISO 5456-3:1999
|ics= 01.100.10
|csnumber= 11503
|ref= EN_ISO_5456-3 
|work item= CSF01073
|url= https://standards.cen.eu/dyn/www/f?p=204:110:0
}}

--Izno (talk) 12:10, 8 May 2019 (UTC)

The original publisher, original title, original date, and original standard number are quite useful for some standards. I don't think there is any widely used style manual that covers all that, so I would probably just write a free-form description of the standard. Jc3s5h (talk) 14:35, 8 May 2019 (UTC)

I found a section, 14.259 "Standards", in The Chicago Manual of Style 17th ed. They suggested including

• Name of the organization (alphabetize by name of organization, even if that is also the publisher)
• title (in italics)
• edition, or other identifying number or label
• publication information
• URL, if consulted online

This example is provided:

National Information Standards Organization. Bibliographic References. ANSI/NISO Z39.29-2005. Bethesda, MD: NISO, approved June 9, 2005; reaffirmed May 13, 2010.

Considering the variability of procedures among different standards organization, including different procedures for approving translations in other than the original language, I'm not sure this would be amenable to automation. Jc3s5h (talk) 15:36, 8 May 2019 (UTC)

@Trappist the monk: you didn't need to change <source>...</source> to <pre>...</pre> - just add the lang=moin attribute, the absence of which was causing the error category. --Redrose64 🌹 (talk) 23:06, 8 May 2019 (UTC)

{{Cite book}} or {{Cite web}} are what we usually use for these, depending on the publication method. Much of the excessive detail included above isn't citation information at all, but descriptive matter more appropriate for in-text treatment of the standard and its history. Even if some of it could be neccessry or at least useful for identifying and finding the source (the purpose of a citation), there is no requirement that everything of that nature that could be included about a source be inside a template with its own dedicated parameter. There's nothing wrong with a structure of <ref ...>{{cite book |... }} Additional info here.</ref>, and we use this all the time. I've cited many standards and specs in my time, and in every single case an existing citation template was sufficient, sometimes with an andditional note like this before the </ref> closure. You can also do two templates in one ref to template-out a current and original version, but per WP:SAYWHEREYOUGOTIT we generally have no rationale for doing this in a citation. I generally only do it when I have, on hand, two different versions of the same work (e.g. American ed. from one publisher, and British one from another, with a divergent title and pagination), with identical relevant text, where one is going to be more convenient for some readers, and the other more convenient for different readers.  — SMcCandlish ☏ ¢ 😼  03:03, 10 May 2019 (UTC)

Julian Gregorian uncertainty

Archie Mountbatten-Windsor ... I can't see a good reason for this. All the best: Rich Farmbrough, 19:39, 8 May 2019 (UTC).

Unless its the 1917 London Gazette citation... I have documented all the anomalies in the London Gazette's dating, which are far more confusing than simply Julian-Gregorian, but there is certainly no J-G issue by in 1917. All the best: Rich Farmbrough, 19:44, 8 May 2019 (UTC).

FYI:

1. • 1665-1714 run from March to March.
   • 1715 starts in March and ends in December.
   • 1716-1722 run January to December.
   • 1723 runs January to the following March,
   • 1724-1751 run from March to March.
   • 1752 runs March to December (corresponding to the Calendar (New Style) Act 1750 changes).
   • 1753 onward run January to December.

All the best: Rich Farmbrough, 19:49, 8 May 2019 (UTC).

Please give a permalink to the version that had the problem. Please give a link to the maintenance category, since it isn't mentioned on the help page associated with this talk page, and nobody can remember the names of all these maintenance categories.

The problem with Gregorian Julian uncertainty is that the cite xxx templates emit metadata which must be in ISO 8601 format, which in turn must be Gregorian. If it's before October 1582, it's certain to be a Julian date so the metadata can be suppressed. If it's after 1923, it's almost certain to be Gregorian, because that's when the last country, Greece, switched from Julian to Gregorian. (Other countries switched to Gregorian after that, but they were switching from substantially different calendars like Islamic that couldn't be used with cite xxx templates anyway).

The template doesn't know when various countries switched, and doesn't consider the location of the publication. If it's in the range 1583 to 1923 (you could look up the exact dates in the template) it's ambiguous. I don't know of any way to indicate to the module that the date is indeed a Gregorian date, so we'll just have to live with the entry in the maintenance category. Jc3s5h (talk) 20:06, 8 May 2019 (UTC)

I think there has been discussion about perhaps adding a |calendar= (displayed or no--I'd lean to no) which would allow someone a) to override the maintenance category and b) make it obvious to followers on that the source cited is near-definitively under a certain calendar. --Izno (talk) 20:17, 8 May 2019 (UTC)

I don't see any value in the maintenance category if there is not an active program to resolve the issue. Unless some constructive proposal can be brought forward, we should remove this. We make no undertakings about the metadata, therefore caveat lector applies.

All the best: Rich Farmbrough, 22:32, 8 May 2019 (UTC).

Author mask

Can anyone please help me with this little problem. For instance on Grant Allen I want to replace one book in the list (1898 - Flashlights etc.) by a cite-book-template (I promise I'll do all the others when I have a little bit spare-time!). But I don't manage to put this orderly in the list. If I use "author-mask=1", it keeps a dash, if I use "author-mask=0", it puts the date behind the title, and publisher etc. How can I fix this? Can I use the cite-book-template, and not make a mess of the list? Thanks, --Dick Bos (talk) 09:21, 10 May 2019 (UTC)

When you use |author-mask=1 the template renders the citation as if there is an author whose name is —. When you use |author-mask=0 the template renders the citation as if there is no author. If we rewrite your template without the author information (as if there were no author) we get:

{{cite book |date=1898|title=Flashlights on Nature: a popular account of the life histories of some familiar insects, birds, plants, etc. |others=with 150 illustrations by [[Frederick Enock]]|location=London|publisher=Grant Richards|id={{OCLC|153673491|show=all}}}}

Flashlights on Nature: a popular account of the life histories of some familiar insects, birds, plants, etc. with 150 illustrations by Frederick Enock. London: Grant Richards. 1898. OCLC 153673491 (all editions).{{cite book}}: CS1 maint: others (link)

which is the same rendering as your version with |author-mask=0:

Flashlights on Nature: a popular account of the life histories of some familiar insects, birds, plants, etc. with 150 illustrations by Frederick Enock. London: Grant Richards. 1898. OCLC 153673491 (all editions).

If the purpose of the list at Grant Allen § Books is to emphasize the chronology over the title, then perhaps it is better to add the bibliographic detail in <ref>...</ref> tags at the end of each title.

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

Missing pipe?

I'm pretty sure ref 26 in OpenFlow should display a missing pipe error. Am I off? --Izno (talk) 16:48, 10 May 2019 (UTC)

Here's a copy of the cite template, for the record:

Cite web comparison

Wikitext	{{cite web|title=OpenFlow security: Does OpenFlow secure software-defined networks?url=http://searchsecurity.techtarget.com/answer/OpenFlow-security-Does-OpenFlow-secure-software-defined-networks}}
Live	"OpenFlow security: Does OpenFlow secure software-defined networks?url=http://searchsecurity.techtarget.com/answer/OpenFlow-security-Does-OpenFlow-secure-software-defined-networks". {{cite web}}: Missing or empty |url= (help)
Sandbox	"OpenFlow security: Does OpenFlow secure software-defined networks?url=http://searchsecurity.techtarget.com/answer/OpenFlow-security-Does-OpenFlow-secure-software-defined-networks". {{cite web}}: Missing or empty |url= (help)

At this writing, it shows a "missing or empty url=" error, but not a "missing pipe" error. – Jonesey95 (talk) 17:30, 10 May 2019 (UTC)

That's because you're too fast. It does now

The function missing_pipe_check() looks for a string of letters, digits, and spaces that immediately precede an = in a parameter value. Two tests are performed. The first requires a space character followed by a letter followed by any combination of letters and digits, followed by 0 or more space characters, and then the =. The second test is the same test except that the leading spaces are omitted and the letters must begin at the start of the parameter value (an empty parameter holding a parameter that is missing its pipe: |url=url=http://....

'%s+(%a[%a%d]+)%s*='

'^(%a[%a%d]+)%s*='

This can, I think, be somewhat improved. The obvious improvement is to include the hyphen that is common to cs1|2 parameters:

{{cite book |title=Title |author=Author author-mask=1}}

Author author-mask=1. Title. {{cite book}}: |author= has generic name (help); Missing pipe in: |author= (help)CS1 maint: numeric names: authors list (link)

The above should note that author-mask is missing its pipe but doesn't because of the hyphen that isn't part of the test

Another improvement might be to use a frontier pattern instead of requiring a space character in the first test:

'%f[%a](%a[%w%-]+)%s*='

Frontier patterns are sort of like \b in regex in that they identify a boundary. The revised test requires a character that is not a letter, followed by a letter, followed by any combination of letter, digit, and hyphen characters, followed by 0 or more space characters, and the =. Sandbox tweaked:

Cite book comparison

Wikitext	{{cite book|author=Author author-mask=1|title=Title}}
Live	Author author-mask=1. Title. {{cite book}}: |author= has generic name (help); Missing pipe in: |author= (help)CS1 maint: numeric names: authors list (link)
Sandbox	Author author-mask=1. Title. {{cite book}}: |author= has generic name (help); Missing pipe in: |author= (help)CS1 maint: numeric names: authors list (link)

—Trappist the monk (talk) 17:52, 10 May 2019 (UTC)

I have undone part of the fixes described above. Because urls. Google books urls have ?id=.... which the frontier pattern matches so we would get a missing pipe error for every google books url used in a cs1|2 template (a lot). I have to think more about how this might be solved.

—Trappist the monk (talk) 16:24, 13 May 2019 (UTC)

Not sure if this would be the same but webcitation.org/4576hkdf?url=http://example.com and some other archive sites use ?url=. -- GreenC 18:37, 13 May 2019 (UTC)

Yeah, pretty much any cs1|2 parameter name might be prefixed with one of the query string delimiters. The only characters that we know won't be part of a url are space characters. The test is imperfect and perhaps it shall remain that way. In a previous discussion on this topic, it was noted that false detection does occur. That was during the time that this code did not produce an error message.

—Trappist the monk (talk) 22:44, 13 May 2019 (UTC)

Hyphenation in page/pages

Compare |page=1-10

• Smith, J. (2000). "Title". Journal. 123 (123): 1-10.

with |pages=1-10

• Smith, J. (2000). "Title". Journal. 123 (123): 1–10.

They should output the same thing. Headbomb {t · c · p · b} 23:59, 13 May 2019 (UTC)

No.

|page= assumes that whatever you give it is a single page so does not render |page=1-10 with a dash but retains the hyphen ': 1-10' (or p. 1-10).

In general, |pages= assumes that whatever you give it is multiple pages so does render |pages=1-10 with a dash instead of the hyphen ': 1–10' (or pp. 1–10). There is an exception for |pages=: when the assigned value is a single number (digits only), |pages=10 will render with the single-page prefix (if appropriate) as ': 10' (or p. 10).

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

But consider this citation:

• Kleinschmidt, Kirk A., ed. (1989). The ARRL Handbook for the Radio Amateur. Newington CT: American Radio Relay League. p. 4-10.

The hyphen in the citation matches what is printed in the book. Jc3s5h (talk) 00:27, 14 May 2019 (UTC)

Except that pretty much every tool out there converts those to |pages=, and the vast, vast majority of cases mean |pages= rather than |page=. The correct way to prevent this is to be explicit as detailed in Help:CS1#pagehyphen. Headbomb {t · c · p · b} 01:19, 14 May 2019 (UTC)

Then pretty much every tool out there is doing the wrong thing. Without the tool actually looks into the source pagination as it is written on the page, and makes an unequivocal determination that the editor was wrong when writing |page=5-6, then the tool should not fix the pagination in the citation to read |pages=5–6.

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

It's simple probabilities. Hyphenated pages are exceeding rare. Page ranges are exceedingly common. These automated/semi-automated conversions have false positive rates well below 1%, and likely well below 0.1%. Headbomb {t · c · p · b} 14:46, 14 May 2019 (UTC)

A useful query for finding easy-to-fix date errors

For those of you interested in finding and fixing date errors, here's a useful query. It finds articles that are in both Category:CS1 errors: dates and Category:Pages using citations with accessdate and no URL. The articles often have a variety of misapplied template parameters, so you can fix a bunch of errors in one visit. The query currently returns 554 articles.

There is no simple explanation of how to fix each of the articles, since WP editors are endlessly creative in how they make mistakes, but feel free to post here if you have any questions about a specific article. – Jonesey95 (talk) 15:17, 14 May 2019 (UTC)

The same in search form for easy use with e.g. AWB. (I've been getting results out of the et al category before they actually appear on the category page using incategory: searches.) --Izno (talk) 15:21, 14 May 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 |embargo=201X-XX-XX'. If you just want a different URL than the PMC one, then just specify that URL in |url= instead. 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)

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

• {{cite journal |last=Bannen |first=RM |display-authors=etal |date=2008 |title=Optimal design of thermally stable proteins |journal=Bioinformatics |volume=24 |issue=20 |pages=2339–2343 |doi=10.1093/bioinformatics/btn450 |pmc=2562006}}

displays as

• Bannen, RM; et al. (2008). "Optimal design of thermally stable proteins". Bioinformatics. 24 (20): 2339–2343. doi:10.1093/bioinformatics/btn450. 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. 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 |url=doi or similar (e.g. |auto-url=doi as an override. 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 |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)

I would support an RFC on removing the special-casing. --Izno (talk) 03:39, 25 May 2019 (UTC)

Minor month range formatting bug (I think) with "use mdy dates" template

This one took me a while to figure out. This version of my sandbox shows a citation template that appears to have the date range properly formatted. This version shows a citation in which the date range has extra spaces in the month range, contrary to MOS. The citation is the same in both versions; the difference is the use of the {use mdy dates} template. – Jonesey95 (talk) 05:04, 16 May 2019 (UTC)

Fixed in the sandbox. See Special:Permalink/897333793.

—Trappist the monk (talk) 10:27, 16 May 2019 (UTC)

Looks right to me. Thanks for the quick update, and I'm glad it wasn't too tricky. – Jonesey95 (talk) 10:44, 16 May 2019 (UTC)

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)

Incorrect links

In cite encyclopedia, the link for the article gets assigned to the work as a whole, rather than the article linked. Example: Morris Jacob Raphall note 1. It is totally beyond me to fix it. deisenbe (talk) 02:22, 18 May 2019 (UTC)

@Deisenbe: use |contribution-url= to link a |contribution= within the template. Additionally, I also fixed the one citation flagging an error by listing and linking the second page number to the clipping for that page. Imzadi 1979 → 02:44, 18 May 2019 (UTC)

Italics of websites in citations and references – request for comment

Should the names of websites in citations and references always be italicized? Please respond beginning with: Italic or Upright. There is an additional section below for discussion and alternatives.

The text above, and the notifications and headings below were proposed on this page with this edit. SchreiberBike| ⌨  04:42, 18 May 2019 (UTC)

The following pages have been notified

• Help talk:Citation Style 2
• Template talk:Citation
• Wikipedia talk:Citing sources
• Wikipedia talk:Citation templates
• Wikipedia talk:Manual of Style
• Wikipedia:Village pump (policy)

Responses

• It depends Websites that are more functional and less creative like IMDB should not be italicized, while those that provide long form content of its own creativity should be. --Masem (t) 05:52, 18 May 2019 (UTC)

  This commentary on IMDB is annoying. There is significant creative effort (perhaps invisible) that goes into creating any website, much less one so large and developed as e.g. IMDB. Second, IMDB in specific has tons of user-generated content--that's why we don't treat it as a reliable source. Those people generating that content aren't contributing to some minor work. It is a major work they are contributing to. Major works get italics. Even a site like Metacritic still has a ton of work to have transcribed scores for works (magazines) that are not online. So the notion that e.g. Metacritic is also undeserving of being called a major work annoys me to no end. --Izno (talk) 07:09, 18 May 2019 (UTC)

  Sure, IMDB has effort behind it, but its not the type of "creative writing" effort that we normal see in books, magazines, newspapers and long-form websites. Its more a database first and foremost. And sure, maybe not the best example, but even with Metacritic, Rotten Tomatoes, etc. those still are database sites first and foremost and thus are treated without Italics. --Masem (t) 16:32, 18 May 2019 (UTC)

  Which is a completely arbitrary distinction. These are still websites, still created by some amount of creative effort. A designer or several took the time to make it look, feel, and read the way it does. That's something to italicize, because it's still a publication. "It depends" -> No, it basically doesn't. If you are citing it for the fact it has published something of interested, then it is de facto a publication and should accordingly be italicized (much as SMC says below). --Izno (talk) 18:27, 18 May 2019 (UTC)

  Fundamentally, someone still published the website. They put in the significant work to provide some information to the public. That e.g. Metacritic is a database does not mean there was no work done for it. The reason there are even database rights in e.g. the EU is because they recognize that the act of creating a database might have significant efforts associated with it. To go on and publish it? Yes, yes very much so it is a long work. --Izno (talk) 18:39, 18 May 2019 (UTC)

• Yes, always italicize. A) We have MOS guidance that indicates major works should be italiziced. Period and end of story. Arbitrary distinctions of "it functions as this in this context" simply aren't necessary, and are essentially sophistry where used. They add unnecessary complexity to our understanding of what it is that we are talking about when we're talking about a source. Where the MOS does not require items be italicized, we are free to do as we please, essentially, as this is a dedicated citation style on Wikipedia. B) It decreases the complexity of the templates. That's good for new and old hands alike. Further, we would have to hack around the arbitrary desires of some small subset of users to support non-italics. (Some of whom do so based on external style guidance. That is not our MOS. Our MOS about italics can be found at MOS:ITALICS.) Who really shouldn't care. The templates take care of the styling, and are otherwise a tool so that we don't need to care. The simpler we make them accordingly, the better. As long as it doesn't affect a great many sensibilities (and I've seen little evidence that it does, not having been reverted on many, if any pages, where I've converted publisher to work or website), then we should italicize. This is molehill making. -Izno (talk) 06:58, 18 May 2019 (UTC)
• No, only if the name of a film, newspaper, magazine, etc. normally italicized. Wikipedia itself is a website and, as a wiki, is not italicized. IMBD is a viewer-edited site and is not italicized. Etc. Randy Kryn (talk) 09:58, 18 May 2019 (UTC)

  If someone cited WP as a source (not on WP itself, obviously, per WP:CIRCULAR), then it should be italicized. How to cite the Manx cat article at another encyclopedia: "Manx Cat", Encyclopædia Britannica, [additional cite details]. How to cite the corresponding article here: "Manx Cat", Wikipedia, [addl. details]. What's happening here is confusion of citation style with other style, like how to refer to something in running text. As a wiki, a form of service and a user community, most other publications are apt to refer to Wikipedia without italics, because they're addressing it as a wiki (service/community), not as a publication. But even in running text it would be entirely proper to use italicized Wikipedia when treating it as a publication per se, e.g. in a piece comparing Wikipedia versus Encarta accuracy and depth of coverage about Africa, or whatever.  — SMcCandlish ☏ ¢ 😼  12:30, 18 May 2019 (UTC)

• It depends. If the title can be found, word-for-word, on the web site (not necessarily in the HTML title attribute) then it should be italicized. If no suitable title can be found on the website and a description is used instead, the text in the title position should be upright, without quotes, and with no special typographic treatment; a case can be made for enclosing it in [square brackets]. Jc3s5h (talk) 11:39, 18 May 2019 (UTC)

  With no allowances for WP:COMMONNAME (policy)? - Paul^T+/_C 06:06, 19 May 2019 (UTC)

  Some purposes for providing a title are to allow a reader to search for the site in case of a dead link, and to confirm the reader has arrived at the correct site once a connection is made. If a description has to be used instead of an actual title, not putting the descriptive title in italics will put the reader on alert to not expect to find the exact text on the website. Jc3s5h (talk) 13:33, 19 May 2019 (UTC)

  I'm sorry. This is a hypothetical on a hypothetical that can lead to confusion for the main point of this RfC. Can you give a specific example of what you mean? I know wgbh.org (with |work= pointing to any of WGBH-TV/WGBH Educational Foundation/WGBH (FM), depending on the context of the citation) was used in the past, but I don't think that is exactly what you mean. - Paul^T+/_C 16:01, 19 May 2019 (UTC)

• Yes, italic, the same way we've always done it, for all actual website titles (which are sometimes, though increasingly rarely domain names in form), in citations. No sensible rationale has been provided for changing this. In short, continue to follow MOS:TITLES. This has nothing to do with whether it should be italicized in running prose; that depends on whether the site is primarily seen as a publication (Salon, TechCrunch, or something else, like a service, shop, forum, software distribution channel, or just a corporate info page. In a citation it is and only can be a publication, in that context. WP does not and cannot cite anything that is not a publication (a published source), though of course TV news programs and other A/V content count as publications in this sense; the medium is irrelevant. The citation templates automatically italicize the work title; always have, and should continue to do so (while sub-works, like articles, go in quotation marks, same as newspaper articles, etc.). If you cite, say, Facebook's usage policy in an article about Facebook-related controversies, you are citing |title=Terms of Service|work=Facebook, a published source (a publication); you are not citing a corporation (that's the |publisher=, but we would not add it in this case, as redundant; similarly we do just |work=The New York Times, not |work=The New York Times|publisher=The New York Times Company).

  None of this is news; we've been over this many, many times before. The only reason this keeps coming up is a handful of individuals don't want to italicize the titles of online publications simply because they're online publications. I have no idea where they get the idea that e-pubs are magically different; they are not. In Jc3s5h's scenario, of a site that is reliable enough to cite but somehow has no discernible title (did you look in the <title>...</title> in the page source? What do other sources call it?), the thing to do would be |work=[Descriptive text in square brackets]; not square-bracketing it (whether it were italicized or not) would be falsifying citation data by making up a fake title; any kind of editorial change or annotation of this sort needs to be clear that it's Wikipedia saying something about the source, not actual information from the source itself. Another approach is to not use a citation template at all, and do a manual citation that otherwise makes it clear you are not using an actual title.
   — SMcCandlish ☏ ¢ 😼  12:30, 18 May 2019 (UTC)

• What we're doing now is correct When citing a website as a work (e.g. |work=, |website=, |newspaper=, etc...), they are italicized . If they are cited as publishers (via |publisher=), they are not. This is how it is, and this is how it should be. Headbomb {t · c · p · b} 13:45, 18 May 2019 (UTC)

  To clarify, are you advocating ignoring do not abuse unrelated citation parameters, such as |publisher=, to evade italicization of online work titles in source citations from MOS:ITALICWEBCITE? (This is an honest question, reading your comment I can see multiple answers to it.) - Paul^T+/_C 06:06, 19 May 2019 (UTC)

  MOS:ITALICWEBCITE says: "Website titles may or may not be italicized depending on the type of site and what kind of content it features." We don't have to make a black and white choice this RfC is presenting. |work= can be either italic or not, "depending on the type of site and what kind of content it features", per the MOS. -- GreenC 20:07, 21 May 2019 (UTC)

  That is refering to prose, not citations. Also, that quote is from further up in the MOS:ITALICTITLE section. MOS:ITALICWEBCITE is specifically the last part of that section dealing with citations. - Paul^T+/_C 15:16, 22 May 2019 (UTC)

• Sometimes The |work= field shows italic, the |publisher= doesn't and you choose which is the best option. SMcCandlish says this RfC is about a small minority of users who dislike italic website names; I have no idea. However I have seen other users say this is about something else, namely that when citing content using {{cite web}} one should always use |work= and never use |publisher=. They arguue everything with a URL on the Internet is a publication and therefore italic. But this argument neatly covers over a complex reality that exists, it is not always right to italicize. Users need flexibility to control who is being credited and how it renders on the page without being forced to always italicize everything and anything with a URL. -- GreenC 14:17, 18 May 2019 (UTC)
  • Almost always the name of the website is the name of the (immediate) publisher; for example, CNN (the website; alternatively CNN.com) has this at the bottom: (C) 2019 Cable News Network. Turner Broadcasting System, Inc. Now, you could make the choice to do Last, First (1 January 2001). "Title". CNN. or you can do Last, First (1 January 2001). "Title". CNN. CNN. or you can do Last, First (1 January 2001). "Title". CNN. TBS. The middle one duplicates information and is also how the vast majority of websites are provided. So that's why we say basically say never to use publisher. It is correct to say that everything on the internet is a publication (you use the "Publish" button to save things onwiki, right? It's a publication when you create a webpage and make it available to other people). Anyone arguing otherwise is clearly so far into edge case territory that they probably should not be using these templates for their citation(s)... --Izno (talk) 18:34, 18 May 2019 (UTC)

    The above is what I mean about a small number of users with a radical plan to eliminate usage of |publisher= when citing anything on the Internet, and always italicizing, be it WGBH-TV or IMDB. -- GreenC 00:26, 19 May 2019 (UTC)

    @GreenC: I'm not following your argument here. Izno doesn't here appear to be arguing against |publisher= as such; but rather is noting that in the typical case it will be redundant with the work (|website=). I am a firm proponent of providing publisher information (cf. the recent contentious RfC on that issue) and even I very much agree that writing, in effect, that CNN publishes CNN or that The New York Times is published by The New York Times Company is pretty pointless. And conversely, I notice some of the outspoken opponents of providing publisher information are in this RfC arguing in favour of the consistent use of italics for the work. I absolutely believe there are some cases where it would be correct to give |publisher= instead of |website= (and obviously there are many where giving both would be appropriate); but in terms of the question in this RfC, I think Izno is correct to dismiss those as edge cases that do not have a siignificant bearing on whether or not to italicize |website=/|work=/etc.

    But your original message caught my attention for a different reason: it implies that there is a need for local (per-article) judgement on italicizing or not the |work=/|website=/|newspaper=/etc. Are you saying there is a CITEVAR issue here? I am sympathetic to the view that stylistic consistency should not be attempted imposed through technical means (whether by bot or by template) if the style choice is at all controversial (in those cases, seek consistency through softer means, such as style guides). But I can't quite see that italization of the work in itself is in any way controversial, and this RfC doesn't affect the option to choose between |website=, |publisher=, or both in those cases when those are otherwise valid options (one can disagree on when exactly those are valid options; but for the sake of discussion let's stipulate that such instances do exist). I, personally, wouldn't have batted an eye if you cited something on cnn.com or nyt.com that was part of the corporate information (investor relations, say) rather than the news reporting as {{cite web|publisher=CNN|url=…}}. Others would disagree, of course, but that issue is not affected by whether or not |work= is italicized. --Xover (talk) 04:47, 19 May 2019 (UTC)

  • "The |work= field shows italic, the |publisher= doesn't and you choose which is the best option." No; read the templates' documentation, Help:CS1, and MOS:TITLES. The work title is required; the publisher name is optional, only added when not redundant, and rarely added at all for various publications types (e.g. newspapers and journals; most websites don't need it either since most of them have a company name almost the same as the website name). No one gets to omit |work= as some kind of "give me non-italicized electronic publications or give me death" WP:GAMING move.  — SMcCandlish ☏ ¢ 😼  05:08, 19 May 2019 (UTC)
• Italicize work/website when title is present, as we do now. As other people have already stated, this is not qualitatively different than a chapter in a book or an article in a journal or magazine, all of which follow the same convention of italicizing the larger collection that the title appears in. —David Eppstein (talk) 19:05, 18 May 2019 (UTC)
• Yes italics, no change from how we currently cite. Cavalryman V31 (talk) 21:01, 18 May 2019 (UTC).
• Italics (ideally using |<periodical>= in a citation template) are required when citing any published work, which, by definition, includes all websites. We have direct WP:MOST (a WP:MOS guideline) guidance on this topic at MOS:ITALICWEBCITE, which is directly backed up by three policies (WP:V, WP:NOR, and WP:NOT). Quoting from there:

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.

To be clear, this has nothing to do with how websites should be presented in prose and only refers to citations.

Also, there is clearly ambiguity on this point as evidenced by the range of opinions on this matter presented here, but the purpose of this RfC is to attempt to gain clear community consensus in support of our established guidelines and policies. Once gained, we can then clarify the instructions as much as possible so that this consensus is clearly communicated and easily accessible to all editors. The issue right now is that many, many people are (reasonably) misunderstanding the existing guidance on this point.

Up until a few weeks ago, I was included in the group of editors that was misunderstanding these guidelines. I urge everyone to read the above guideline carefully. Try to look at it without any existing bias and seriously consider changing your opinion (not an easy task, I know!) if there is a conflict with the above. Thanks, - Paul^T+/_C 22:19, 18 May 2019 (UTC)

• All of that text was added earlier this month with the stated aim of dissuading editors from de-italicising in cite template parameters. I can't see how it can now be cited as proof that the practice is disallowed, any more than if I or someone else had chosen to add guidelines supporting the practice (or went and added them now). Nor do I see that those policies directly support the idea at all. JG66 (talk) 23:21, 22 May 2019 (UTC)

  It isn't my responsibility to defend SMcCandlish's addition there (or to dispute your removal of it), but my interpretation of what he did with those edits was to bring the points into one place so as to clarify existing convention. I don't agree that this represents a change in the spirit of the MOS. - Paul^T+/_C 15:00, 23 May 2019 (UTC)

  Yep.  — SMcCandlish ☏ ¢ 😼  21:01, 25 May 2019 (UTC)

• Italics—but if the website lacks a name independent of its publisher, then there's no need to invent a name for a citation just to fill in that parameter of the citation template; the publisher in |publisher= will be sufficient. 22:41, 18 May 2019 (UTC) — Preceding unsigned comment added by Imzadi1979 (talk • contribs) 22:42, 18 May 2019 (UTC)

  Already covered this above, twice. Can you provide an example of an actual reliable-source website with no name?  — SMcCandlish ☏ ¢ 😼  05:13, 19 May 2019 (UTC)

• Per WP:CITESTYLE, "nearly any consistent [(i.e. internally within an article)] style may be used … [including] APA style, ASA style, MLA style, The Chicago Manual of Style, Author-date referencing, the Vancouver system and Bluebook." Unless we want to make an exception to that like we do for dates due to special circumstances, this is really a moot matter. If this discussion only regards how this specific template will render such things, then that needs to be made clear. — Godsy ^(TALK_CONT) 01:34, 19 May 2019 (UTC)

  This is at Help talk:Citation Style 1, so it's already clear what the scope is. If you're at an article is consistently using manual citations in some wacky style that, say, puts work titles in small-caps and italicizes author surnames (or whatever), then that same style would be applied in that article to electronic publications. (That said, any citation style that confusing is a prime candidate for a change-of-citation-style discussion on the article's talk page, per WP:CITEVAR).  — SMcCandlish ☏ ¢ 😼  05:13, 19 May 2019 (UTC)

• Italics, with some caveats. Websites are works, so should generally be italicised where there's an official website title. Where there isn't, or where an unofficial title is being used, they should not be italicised. Publishers of websites (eg the BBC) should never be italicised. All of this simply follows the general principles for all forms of citation, and I disagree that the question of whether there's significant creative input into the work is a factor. Espresso Addict (talk) 02:49, 20 May 2019 (UTC)

  You're almost there. To follow on your example, what is the name of the website BBC.co.uk? Isn't it "BBC" (or "BBC News", depending on the actual page) and therefore shouldn't citations from bbc.co.uk have italicized |work=[[BBC]] or |work=[[BBC News]], depending on context? - Paul^T+/_C 03:09, 20 May 2019 (UTC)

There isn't a single website name. www.bbc.co.uk has no obvious title; www.bbc.co.uk/news is BBC News; www.bbc.co.uk/sport is BBC Sport; and so on. The publisher is the BBC. Espresso Addict (talk) 04:31, 20 May 2019 (UTC)

Actually, in this example, there would be just one website, the one suffixed with the top-level domain. That is the work. Anything that comes after the slash is a "chapter" in that work, or a "department". If there is a prefix like news.bbc.co.uk (that is to say a subdomain), then that should be listed as the work, since such subdomains have their own hierarchy. I believe this treatment corresponds to both the technical and the functional aspects. 72.43.99.130 (talk) 13:40, 20 May 2019 (UTC)

• Italics, how we've always done it (or should have always done it). Kaldari (talk) 16:06, 20 May 2019 (UTC)
• It depends MOS:ITALICTITLE says that only websites with paper equivalents (The New York Times, Nature, etc) and "news sites with original content" should be italicized. Personally, however, I never italicize news websites that don't have paper equivalent or aren't e-magazines (BBC, CNN, etc). Brandmeister^talk 10:06, 21 May 2019 (UTC)

  That is true for mentions in the prose, but not for citations. MOS:ITALICTITLE also says (at MOS:ITALICWEBCITE) When any website is cited as a source, it is necessarily being treated as a publication, and in that context takes italics. (See above for the full quote and direct references to policies backing it up.) This is very clear guidance on the subject. - Paul^T+/_C 15:16, 22 May 2019 (UTC)

  Looks like it was removed as an undiscussed addition, also MOS:ITALICWEBCITE redirects to general Wikipedia:Manual of Style/Titles, not to specific section. That addition, if proposed, should gain consensus first. Anyway personally I don't see a compelling reason to format ref names differently compared to prose. Brandmeister^talk 22:04, 22 May 2019 (UTC)

  Yes, it was removed (see below), though I have a feeling the removal will also be disputed (hopefully it doesn't fork this discussion unnecessarily). The text is directly quoted above as well and it is directly supported by quotes from policies. References have different formatting from prose for all kinds of reasons. Our personal preferences aren't really supposed to enter into it when guidance is clear. - Paul^T+/_C 22:28, 22 May 2019 (UTC) Oh, and the shortcut currently points to the full WP:MOST page because the anchor was also removed. I'll have to think about whether it needs to be retargeted or not. Maybe here at #ITALICWEBCITE (at least while the discussion is ongoing)? - Paul^T+/_C 22:31, 22 May 2019 (UTC)

• It depends. Per comments above by Masem and Randy Kryn. As an article writer here, I'm looking to ensure there's consistency between what appears in the text and in a citation: I wouldn't italicise AllMusic, IMDb, Metacritic, Rock's Backpages, etc, in prose, so it seems fundamentally wrong to italicise those names when they appear in a source. And not that we would be citing it in many (any?) articles, but Wikipedia itself is a good example. JG66 (talk) 14:25, 21 May 2019 (UTC)

  This is directly contrary to MOS:ITALICWEBCITE (see directly above). Citations can be (and often are) formatted differently than running prose. - Paul^T+/_C 15:16, 22 May 2019 (UTC)

  It's only "directly contrary" to MOS:ITALICWEBCITE because SMcCandlish bloody added the text there on 2 May!! JG66 (talk) 15:28, 22 May 2019 (UTC)

  It is probably not a good idea to outright remove it while we are in the middle of this discussion. Any chance you'll self-revert? - Paul^T+/_C 21:12, 22 May 2019 (UTC)

  I'm afraid not, and I think it's not a good idea that the text was added there. After all, you're repeatedly citing it as an MOS guideline supported by policy, when in fact another editor has simply invented the guideline. JG66 (talk) 23:21, 22 May 2019 (UTC)

• Italics. For purposes of citation, it's a publication, even if it's online. Putting it in Roman instead would make the publication name blend into the other metadata elements, making it harder to read. —{{u|Goldenshimmer}} (they/their)｜😹｜✝️｜John 15:12｜☮️｜🍂｜T/C 18:09, 22 May 2019 (UTC)
• Leaning toward Italics: It should be as easy as possible to write citations, and people shouldn't be gaming the system with tricks for special font formatting or using |publisher= instead of |work= when they cite some websites (which can also cause metadata to be mixed up). If I find something on the CNN website, I should be able to just use "|website=[[CNN]]", and the same for citing the website for ABC News, BBC, NPR, PBS, WGN-TV, Associated Press, Reuters, Metacritic, Rotten Tomatoes, Box Office Mojo, Salon, Wired, HuffPost, The New York Times, etc. Writing citations should be dirt simple, and these sort of references are extremely common. If we don't do that, it seems difficult to figure out what rule we would follow instead. (e.g., if it seems like the name of an organization, don't italicize it, and if it is a content aggregator without original content, don't italicize it? – that seems unlikely to be advice that editors can consistently follow in practice.) —BarrelProof (talk) 05:21, 23 May 2019 (UTC)

  No one is gaming the system. Template:Cite web allows both work= and publisher= parameters, depending on source, and lists some websites (National Football League, International Narcotics Control Board, etc) in straight format, not italics. This is because CNN, International Narcotics Control Board or National Football League are not the same type of work as Encyclopedia of Things, Nature, etc. They are authority organs rather than paper publishers and this is consistent with MOS:ITALICTITLE. Brandmeister^talk 09:41, 23 May 2019 (UTC)

  Except that those "authority organs" publish a website. When a publication is cited, it is by definition a major work and therefore take italics per MOS:ITALICTITLE (and the policy cited in #ITALICWEBCITE, before it was removed). Using |publisher= instead of |work= when citing those publications just to change formatting conflates them and pollutes the usefulness of those separate fields. (Semi-off-topic question, is there a page where the metadata created by the citation templates is explained? Having that information explicitly spelled out somewhere might be useful to this discussion as well.) - Paul^T+/_C 10:33, 23 May 2019 (UTC)

  Per current guideline, only "online magazines, newspapers, and news sites with original content should generally be italicized". Websites in general are not listed among "Major works". Otherwise various organizations (UN, NBA, etc), referenced in corresponding official websites, would also be treated as "works", which is nonsensical. The change of that guideline part apparently begs for talkpage discussion, because it was reverted. Brandmeister^talk 11:51, 23 May 2019 (UTC)

  You are quoting a point that only applies to running prose. No one is disputing that (the bit about how the guideline applies to prose). Anything that is a published work, which includes every website, and is used as a citation, which requires complying with WP:V, WP:OR, and WP:NOT, qualifies as a "major work" and is therefore italicized per WP:MOST. You are conflating the "various organizations" with the websites they publish, which are published works when used in a citation as described earlier. - Paul^T+/_C 15:00, 23 May 2019 (UTC)

  WP:MOST makes no distinction between running prose and references for that matter (which is why |publisher= does not italicize by default, unlike |work= which does). Also, treating prose and refs differently may introduce WP:CREEP and is counter-intuitive. Italicizing all website names through default italicizing ref parameter may look like making things easier, but if it ain't broke, don't fix it. Brandmeister^talk 15:52, 23 May 2019 (UTC)

  (edit conflict)

  Module talk:Citation/CS1/COinS may be helpful. The table there is generally accurate but a bit out of date (newer preprint templates not mentioned, etc). For the purposes of cs1|2, {{citation}} when any of the |work= aliases have assigned values, {{cite journal}}, {{cite magazine}}, {{cite news}}, and {{cite web}}, Module:Citation/CS1 treats these as 'journal' objects. Pertinent to this discussion, |publisher= is not made part of the COinS metadata for journal objects. When editors write cs1|2 citations with 'website names' in |publisher= to avoid italics, those who consume the citations via the metadata do not get that important piece of information. This is a large part of the rationale for the pending change that requires periodical cs1 templates to have a value assigned to a |work alias= (see this discussion and the implementation examples).

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

  Thanks, this is helpful. I'll dig into it when I have some more time. - Paul^T+/_C 15:00, 23 May 2019 (UTC)

  My understanding is that the identification of the published work is considered more fundamental, at least for metadata purposes, than the name of the publisher of the work. The guidelines say that identifying the publisher is unnecessary if it is basically just redundant or obvious once the name of the work is known. This is completely straightforward when the work is The New York Times and the publisher is The New York Times Company. When publishers use their organization name as their website's name, it does seems a bit more awkward, but in my view, that what they have chosen to do – they chose what title to use for their published work, and we should just follow their choice. The CNN organization has chosen to entitle its website (i.e., its published work) as "CNN" (using italics here not because they do that, which they don't, but rather because that is how we ordinarily format the titles of works, and MOS:TM says not to imitate logo styling). I think it is too complicated to second-guess this choice they have made. If we want to cite their published work, and they have chosen the title "CNN" for their publication, we should just refer to their published work as "CNN". Otherwise, we would need to make some judgment call in every case between whether the name of the website seems more like the name of their publication or seems more like the name of their organization, and do something different in the two cases. I think that's too complicated. It would get even more complicated if we also start trying to do something different depending on whether they are publishing original content or not (e.g. Metacritic), and I don't even understand the rationale for not wanting to italicize some names – some of those sites are publishing original content, not just using what has already been published elsewhere. Anyhow, my understanding is that the intent of the parameter names is not primarily for font formatting. Choosing to fill in different parameters for font formatting purposes is what I referred to as "gaming the system", because I believe the parameter names were not really intended for that purpose. The parameter names are |work= and |publisher=, not |italicname= and |uprightname=. I suppose I might not object if someone wants the templates to support some additional parameter type like |uprightsitename=, but I think that's too complicated to expect it to be broadly understood and applied consistently. —BarrelProof (talk) 19:47, 23 May 2019 (UTC)

  I've noticed that when pointed to WP:MOST, italics supporters say it doesn't apply to refs, only to prose, but when this guideline suits their agenda, they say websites are "major works". Either one does not treat websites as "major works", because current WP:MOST does not apply to them (in which case they remain upright) or he/she respects current WP:MOST, which does not advise to italicize all websites. Seriously, double standards. Brandmeister^talk 07:05, 25 May 2019 (UTC)

• Italics per SMcCandlish, and as I'm not seeing any compelling reason to make such a tiresomely complicated yet small change throughout all our citations. — Bilorv (he/him) _(talk) 19:46, 24 May 2019 (UTC)
• Italics – I will never understand the distinction people try to make between online sources and print publications. Maybe that made sense in the 1990s but increasingly publications originate as web-only, or previously print publications cease printing and move to all-digital. I also fail to see the problem with italicizing a domain name if that's the best "title" for the publication. If a website includes the material you are citing, obviously it is serving as a publication and, as such, should be italicized. It also seems like it would circumvent a LOT of edit wars to simply declare all websites are "major works" and their names should be italicized as such in article prose, because the current weirdness of "well what kind of website is it?/what types of information does it contain/provide?" is such a stupid time sink. And that in turn would help avoid the whole "do we italicize website titles in citations?" debate, too. —Joeyconnick (talk) 20:04, 24 May 2019 (UTC)
• Italics: I think the names of websites should be italicized. Right now we are only talking about italicizing them in citations, but I think in the long run we will italicize them at all times. Like other things we italicize, they are named works with a publisher and subparts. This is not now common but such things move slowly and websites are relatively new. For now, I would favor italicizing the names of websites in citations/references and in external links. They are published sources.
  I'd be completely comfortable saying that the name of the website is CNN or CNN.com which is published by CNN. CNN is a company which has a TV channel, a network, a publisher and a website. It publishes a bunch of TV programs and films. It also publishes a website called CNN or CNN.com. When we cite something from that website it should be italicized. SchreiberBike | ⌨  23:50, 24 May 2019 (UTC)
• Italics. In CS1, sources such as websites are italicized, parts of sources such as webpages are quoted, and publishers such as domain owners are in plain text. This has been the consensus, and seems to be working well. 24.105.132.254 (talk) 16:42, 26 May 2019 (UTC)
• Generally italics, but it depends - per SMcCandlish, but there are times that italics aren't needed and shouldn't be required --DannyS712 (talk) 05:39, 27 May 2019 (UTC)
  • Per SMcCandlish? Can you double-check that? I believe SMcCandlish was italicize (always), not it depends. —BarrelProof (talk) 13:06, 27 May 2019 (UTC)

Discussion and alternatives

• My impression is that much of the time when people list |website= in citations, they really mean |newspaper= (for newspapers that publish online copies of their stories), |magazine= (ditto), |publisher= (for the name of the company that owns the website rather than the name that company has given to that specific piece of the company's web sites), or even |via= (for sites like Legacy.com that copy obituaries or press releases from elsewhere). Newspaper and magazine names should be italicized; publisher names should not. Once we get past those imprecisions in citation, and use |website= only for the names of web sites that are not really something else, I think it will be of significantly less importance how we format those names. —David Eppstein (talk) 06:32, 18 May 2019 (UTC)

  I agree that people frequently use the wrong parameter and that this should be cleaned up, but it doesn't really address the root issue here. There's a tiny minority of editors engaged in kind of "style war" against italicizing the titles of online publications, and it's not going to stop until this or another RfC puts the matter to rest. There is nothing mystically special about an electronic publication that makes it not take italics for major works and quotation marks for minor works and sub-works, like every other form of publications, even TV series/episodes, music albums/song, and other A/V media.  — SMcCandlish ☏ ¢ 😼  12:30, 18 May 2019 (UTC)

Odd PMC error

PMC 6509194 appears to be valid, yet displays the following warning:

• 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. doi:10.1128/mBio.00853-19. PMC 6509194. 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)

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

cite citeseerx

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

{{cite citeseerx}} is treated like {{cite arxiv}} and {{cite biorxiv}} 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 rft.genre=article or possibly, something else?

—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, {{cite arXiv}}, {{cite bioRxiv}}, {{cite citeseerx}} and (a newly created) {{cite SSRN}} should all be merged into a {{cite preprint}}. Headbomb {t · c · p · b} 01:39, 31 May 2019 (UTC)

RfC on linking title to PMC

Currently if |url= is not specified, then the title of an article generated by a CS1 template is linked to the |pmc= link. Should we continue to include this link or should we remove it? Boghog (talk) 05:51, 25 May 2019 (UTC)

Include link

• The link is very useful because not everybody knows how to navigate the publication IDs or what the green link means. It's also easy to override whenever the PMC link is not the preferred final destination. In 99,9 % of cases, the PMC link is the best possible because it's official, open access and technically high quality (fast, no bloatware, no cookies or JavaScript required etc. etc.). Nemo 10:24, 27 May 2019 (UTC)
  • The link is very useful because not everybody knows how to navigate the publication IDs Delicious baloney (I actually detest baloney). My expectation, and what I think the more reasonable one is, is that if the user has URLs in the citation, he'll follow each of them (either in turn or separately) until he can access a free source. (And if there is no free source, then he will rarely access any of them as requiring extraordinary effort for anyone but the most-serious researcher.) PMC link is the best possible because it's official, open access and technically high quality None of which we care about for the purposes of a rendered citation. (Well, perhaps open-access, but that's not sufficient to duplicate a link from one place to another.) what the green link means The average reader has a browser which can display the title of the link, which is set to 'free access', when the green is present. He'll figure it out eventually. --Izno (talk) 13:57, 27 May 2019 (UTC)
    • I believe you can find many examples on wiki of me saying that I believe our readers are smarter than that... but this isn't one of them. Normal people really have no idea what those things are and don't click on them. Try it out some time. Show a Wikipedia article to your neighbors and ask them what they think all those numbers at the end are there for. Don't be surprised if the answer is something that amounts to "Nuttin' that's got anything to do with me".
      Nemo, I understand that the PMC articles are usually "author accepted article versions" (i.e., the thing that they're going to publish), but not technically the "official" version (which has the journal's official formatting style, etc.). WhatamIdoing (talk) 22:53, 27 May 2019 (UTC)
      • Without wishing to appear quarrelsome, the average reader doesn't have a browser that displays the title. The majority of pageviews now come from mobile devices, so the most probable reader has no mouse to hover over a link. --RexxS (talk) 02:53, 28 May 2019 (UTC)
• Keep What is wrong with making it easy to open a fully readable version? Doc James (talk · contribs · email) 00:23, 28 May 2019 (UTC)
• Keep link from title I believe most readers are most likely to follow a link from the article title. It's what they are used to doing on Wikipedia, and my contention is that the link from the title should be the best link we can offer the reader. If it's the same link as the PMC, then redundancy is fine: either one will do. But only today I came across a PMC that had an updated/amended later version available as free access on the journal site, and that should be the resource linked to from the title, because it's slightly better than the PMC. Either version would serve to verify the article content, but we should offer the reader the best source we can, and that's not always the PMC. I see no good reason to have the title unlinked when |url is unspecified; if the PMC is available then it is the best we have to offer and should be linked from the title as well. --RexxS (talk) 02:53, 28 May 2019 (UTC)
• Keep link from title and use the same logic for all other identifiers with free full text, such as |arXiv= or |doi= with |doi-access=free. In this way, the discrepancy between PMC and the other identifiers is resolved. As a reader, clicking on the title is more natural than having to click on an id. − Pintoch (talk) 09:42, 28 May 2019 (UTC)
• Keep and consider expanding to other parameters if they identify free-to-read urls. Changing this would be a major breaking change for articles that have been for years written without a url= link to the PMC. Readers expect article titles to be URLs if they can read them. Hieroglyphics at the end of the citation are impenetrable to normal folk. The proposal offers no benefits to the reader at all. It makes it less likely they will know they can read the source and less likely that they will read the source. See below for my comment on "duplication". -- Colin°^Talk 13:37, 29 May 2019 (UTC)
• Keep and expand functionality to other free versions of records (e.g. when |doi-access=free/|bibcode-access=free etc.). Headbomb {t · c · p · b} 23:38, 1 June 2019 (UTC)

Remove link

• Remove as redundant to the |pmc= link. The pmc link is now followed by a "green/open padlock icon" which makes it clear that the source is free to read. Redundantly linking titles to pmc links creates a counter productive sea of blue in reference sections. Boghog (talk) 05:51, 25 May 2019 (UTC)
• Support removal – redundant; no more reason to link to |pmc= than, say, |jstor=; confusing. Peter coxhead (talk) 06:07, 25 May 2019 (UTC)
• Remove as redundant. Imzadi 1979 → 06:10, 25 May 2019 (UTC)
  • Making the PMC parameter not link will not reduce redundancy, but increase it. People will start adding links to the url parameter so that users can more easily find the link, especially as it's recommended to link a full text. Nemo 10:31, 27 May 2019 (UTC)
    • That's an assumption of user behavior without any evidence yet whatsoever. I'd expect that such people will use the URL field regardless of whether the PMC field is filled. (On the note of duplicate links, I would presume that Citoid adds the majority or entirety of duplicate links for identifiers, not the average editor.) --Izno (talk) 13:53, 27 May 2019 (UTC)
• Regardless of the merits of icons etc., this is inconsistent behavior. Identifiers should be placed in the identifiers section, and the links thereto should be relegated to that section. If someone is intent on reading some paper of interest, they're going to click every URL they can to see which will provide the easiest access; the suggested subtle cue that the URL is free if the title is linked seems like a false starting position (it's often or perhaps usually-to-mostly not--see our widespread linking to Google Books). Remove the extraneous link. --Izno (talk) 13:00, 25 May 2019 (UTC)
  • The policy is that the url parameter should normally contain freely accessible URLs. It's trivial to remove the URLs which don't comply with this. Nemo 10:31, 27 May 2019 (UTC)
    • No, it's assumed that when the URL does it holds something freely accessible. It does not require the duplication of a link from elsewhere in the citation. Certainly, I would be careful about tossing the word "policy" around when there is nothing of the sort whatsoever that is "policy". --Izno (talk) 13:49, 27 May 2019 (UTC)
      • The convention is that the link from the title is the "best" link we have to offer, because it's the most obvious to be followed. It is quite likely to be free access, as that's the principal factor in judging what's "best". It may or may not be a duplicate of another link in the citation, but omitting it on grounds of "redundancy" does a disservice to the reader: "redundant" =/= "not useful". --RexxS (talk) 03:08, 28 May 2019 (UTC)
• Remove as above. Masum Reza^📞 10:26, 27 May 2019 (UTC)
• Remove the alternative linking of the title to the pmc url. Despite the unssupported statements of Nemo and Doc James, I do not see that any case has been presented for retaining this alternative linking. And I find the statement that "not everybody knows how to navigate the publication IDs" a bit ludicrous. ♦ J. Johnson (JJ) (talk) 00:52, 28 May 2019 (UTC)
  • I've presented a case that the link from the title should be the "best" link we can offer the average reader. If readers know they can click on the title, certain that none of the other links will be better, we can eliminate the need for the average reader to have to work out which of the other coded links is best to follow. Do you want to reconsider? --RexxS (talk) 03:08, 28 May 2019 (UTC)

    No. I think your argument (above) that the title should link to the best source has some merit. But: 1) Per other editors (such as WhatamIdoing [above] and Boghog [immediately following]) I don't see that PMC is always best. 2) "Best" should be a matter for the involved editor to determine and set; I don't accept that PMC as default should be built into the software. ♦ J. Johnson (JJ) (talk) 23:19, 28 May 2019 (UTC)

    • The assumption is that the PMC is the best available link is not always true. Sometimes only the pre-publication version is stored on PMC and the original publisher has posted the final open access version that is easier to read. The automatic title link to PMC can be oven ridden by |url= but this requires the editor to insert this link which is not always done. To make matters worse, citoid often inserts |url= completely oblivious to whether it is free or not. An open/green padlock always follows the specific PMC link, so it should be obvious to the average reader that the PMC link is free. Boghog (talk) 03:44, 28 May 2019 (UTC)
      • But the assumption that the PMC link is the best is true most of the time, and that makes it a good default value for the title link – at the very least, it's guaranteed to be free. In the minority of cases when it isn't the best link, that's when we use the |url parameter to override it. Just because that's not always done doesn't stop it being the best solution. The behaviour of citoid in inserting spurious urls shouldn't be a factor deciding whether to link the title from PMC or leave it blank, as citoid's choice for |url would produce the same result in either case. --RexxS (talk) 04:43, 28 May 2019 (UTC)
        • Why is it necessary to include a redundant link in the title? Because readers can't see the open/green padlock? I think you are underestimating the average reader. Boghog (talk) 08:38, 28 May 2019 (UTC)
          • Why is it necessary to remove a useful link from the title? Readers know that if they click the link from the title, they'll most likely get the best version of the source we can deliver to them. That's how it's been for a long time, and I think you're underestimating the power of habit. If there's an open/green padlock then there's a free version, and the link from the title will be at least as good as that. No need to check multiple links until they get the best one; we serve it up on a plate (the title) for them. --RexxS (talk) 17:24, 28 May 2019 (UTC)
            • You keep using the word "best". That's not what this link represents. It is the "most-open", at best. The link to the DOI or whatnot is the "most authoritative" and could just as trivially be the preferred link. (Best is value-laden and we don't need that to be value-laden here.) In this case, it may not be the best because there may be a both free-as-in-libre and free-as-in-beer identifier which also happens to be one of the other identifiers. (Rare, but possible.) That would clearly be "the best". --Izno (talk) 17:55, 28 May 2019 (UTC)
              • I do keep using the word "best", because it's the appropriate word, and it's exactly what the link from the title represents. When multiple links occur, we are perfectly capable of picking one that is most likely to be the one an average reader will benefit most from following, and the title link is available for that purpose. Free access, full text, updated, and so on are all factors and we can order them as we see fit (usually that order). The fact that PMC will usually tick the first two boxes makes it the most likely candidate for "best link", and that's why it's copied into the title link in the absence of a link to override it (the |url=). If you don't like the word "best", just mentally substitute "most beneficial for the reader". The reasoning remains unchanged and unchallenged. There is never any good reason not to present the reader with a link from the title, unless the source simply doesn't exist online. --RexxS (talk) 19:21, 28 May 2019 (UTC)
• Remove the automatic linking as it is redundant and misleading. As discussed above, the auto-linking leads to falsely suggesting that the PMC version is the authoritative one when a reviewed and published version is available, whether behind a paywall or not. When the published version is not freely available anywhere, yet the article is referencing the published version, the title link is utterly inappropriate. When the DOI provides free access to the published version, one can override the PMC link by putting the URL the DOI redirects to in |url=, but that again is redundant and leads to WP:SEAOFBLUE, when |doi-access=free will do.

  It is inconsistent that PMC is being singled out as the only source that automatically links the title in the absence of |url=. But if we expanded this feature, determining the priority of sources would be a nightmare. The editor who inserts the template should be able to decide which part of the citation is linked where. Nardog (talk) 10:07, 28 May 2019 (UTC)

  Well said. Peter coxhead (talk) 15:26, 28 May 2019 (UTC)

• Remove links. We should only link versions that are either authoritative, or explicitly chosen by editors as the choice to link via the |url= parameter. The people commenting that "pubmed is obviously the best link" presumably work in a field covered by pubmed; for many other fields, pubmed coverage is sporadic, random, and unhelpful. In astronomy, maybe ads/abs (bibcode) is the best link; maybe in mathematics it is mathscinet (mr). I don't think we should be in the business of picking and choosing when there are multiple ids like this to link to. I would not be strongly opposed to doi links, because they are almost always authoritative, but even for those I prefer the current system of linking them only through the id. —David Eppstein (talk) 20:02, 28 May 2019 (UTC)

Discussion

See also #Stop linking paper title to PMC

The proposal is poorly stated. When |url= is non-empty it is used to link the title. The proposal appears to be: don't use |pmc= for that purpose when |url= is empty. I don't see that any "link" (or link parameter?) is being removed. It's more like a link using pmc is not created in the first place. But this is not quite certain. ♦ J. Johnson (JJ) (talk) 22:09, 25 May 2019 (UTC)

Taking an example given above by Nardog of a citation using |pmc= but not |url=:

• {{cite journal |last=Bannen |first=RM |display-authors=etal |date=2008 |title=Optimal design of thermally stable proteins |journal=Bioinformatics |volume=24 |issue=20 |pages=2339–2343 |doi=10.1093/bioinformatics/btn450 |pmc=2562006}}

currently displays as

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

The proposal is that the article title should not be linked in this situation (but the doi and PMC identifiers should still be), so in comparison with the current implementation, one copy of the link would be removed from the generated HTML. Kanguole 22:35, 25 May 2019 (UTC)

(edit conflict) A title link to |pmc= is created if |url= is empty. The removal proposal is not to link the title to |pmc=. Boghog (talk) 22:51, 25 May 2019 (UTC)

So what you are proposing is: to remove the functionality of using the pmc link as an alternate title link. (Essentially: not creating a 'title->pmc' link in the first place.) Right? ♦ J. Johnson (JJ) (talk) 18:07, 26 May 2019 (UTC)

Correct. Boghog (talk) 19:26, 26 May 2019 (UTC)

I think the concern about duplicate is misplaced. In the case where a URL is supplied and to the official journal article, then the DOI link takes one to the same place. So in fact the title link is nearly always duplicating another link. Both the DOI and PMC ID are, textually, part of a full citation text, so we wouldn't eliminate them. I think the convention of having the title link to freely available editions of the article is a fine one to retain. -- Colin°^Talk 13:47, 29 May 2019 (UTC)

But many editors wouldn't supply a URL that is pointed to by the DOI. Useful URLs are alternatives to a DOI link, e.g. to a copy on the authors' website or in ResearchGate. Peter coxhead (talk) 16:13, 29 May 2019 (UTC)

The frustrating thing about this feature is that there's no way to opt it out. Even if the outcome of this turns out to be "keep", surely an option to turn it off wouldn't be controversial, or would it? Nardog (talk) 16:20, 29 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 -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)

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

Cite book comparison

Wikitext	{{cite book|archive-date=2015-05-19|archive-url=//example.com/Archive|title=Title|url-status=dead|url=//example.com/Original}}
Live	Title. Archived from the original on 2015-05-19.
Sandbox	Title. Archived from the original on 2015-05-19.

Cite book comparison

Wikitext	{{cite book|archive-date=2015-05-19|archive-url=//example.com/Archive|title=Title|url-status=live|url=//example.com/Original}}
Live	Title. Archived from the original on 2015-05-19.
Sandbox	Title. Archived from the original on 2015-05-19.

Cite book comparison

Wikitext	{{cite book|archive-date=2015-05-19|archive-url=//example.com/Archive|title=Title|url-status=usurped|url=//example.com/Original}}
Live	Title. Archived from the original on 2015-05-19.{{cite book}}: CS1 maint: unfit URL (link)
Sandbox	Title. Archived from the original on 2015-05-19.{{cite book}}: CS1 maint: unfit URL (link)

Cite book comparison

Wikitext	{{cite book|archive-date=2015-05-19|archive-url=//example.com/Archive|title=Title|url-status=unfit|url=//example.com/Original}}
Live	Title. Archived from the original on 2015-05-19.{{cite book}}: CS1 maint: unfit URL (link)
Sandbox	Title. Archived from the original on 2015-05-19.{{cite book}}: CS1 maint: unfit URL (link)

Cite book comparison

Wikitext	{{cite book|archive-date=2015-05-19|archive-url=//example.com/Archive|title=Title|url-status=bot: unknown|url=//example.com/Original}}
Live	Title. Archived from the original on 2015-05-19.{{cite book}}: CS1 maint: bot: original URL status unknown (link)
Sandbox	Title. Archived from the original on 2015-05-19.{{cite book}}: CS1 maint: bot: original URL status unknown (link)

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

Cite book comparison

Wikitext	{{cite book|archive-date=2015-05-19|archive-url=//example.com/Archive|title=Title|url-status=yes|url=//example.com/Original}}
Live	Title. Archived from the original on 2015-05-19. {{cite book}}: Invalid |url-status=yes (help)
Sandbox	Title. Archived from the original on 2015-05-19. {{cite book}}: Invalid |url-status=yes (help)

Cite book comparison

Wikitext	{{cite book|archive-date=2015-05-19|archive-url=//example.com/Archive|title=Title|url-status=no|url=//example.com/Original}}
Live	Title. Archived from the original on 2015-05-19. {{cite book}}: Invalid |url-status=no (help)
Sandbox	Title. Archived from the original on 2015-05-19. {{cite book}}: Invalid |url-status=no (help)

the deprecated parameters still work:

Cite book comparison

Wikitext	{{cite book|archive-date=2015-05-19|archive-url=//example.com/Archive|dead-url=no|title=Title|url=//example.com/Original}}
Live	Title. Archived from the original on 2015-05-19. {{cite book}}: Unknown parameter |dead-url= ignored (|url-status= suggested) (help)
Sandbox	Title. Archived from the original on 2015-05-19. {{cite book}}: Unknown parameter |dead-url= ignored (|url-status= suggested) (help)

Cite book comparison

Wikitext	{{cite book|archive-date=2015-05-19|archive-url=//example.com/Archive|dead-url=true|title=Title|url=//example.com/Original}}
Live	Title. Archived from the original on 2015-05-19. {{cite book}}: Unknown parameter |dead-url= ignored (|url-status= suggested) (help)
Sandbox	Title. Archived from the original on 2015-05-19. {{cite book}}: Unknown parameter |dead-url= ignored (|url-status= suggested) (help)

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

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