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

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)

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

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)

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

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:

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

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:

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)

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
|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
|publisher=       European Committee for Standardization   |original-publisher=       International Organization for Standardization 
|publisher-short= CEN                                      |original-publisher-short= ISO
|year= 1999                                                |original-date= 1996-06-15 
|language= en, fr, de                                      |original-language= en, fr
|id=  EN ISO 5456-3:1999                                   |original-id= ISO 5456-3:1996
|ref= EN_ISO_5456-3 
|ics= 01.100.10   |csnumber= 11503   |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 = "wikitext" 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)

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)

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:

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:

— 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=. -- Green C 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)

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)

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)

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. -- Green C 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. -- Green C 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. -- Green C 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). -- Green C 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. ^FBDB 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. -- Green C 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. -- Green C 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. -- Green C 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. -- Green C 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. -- Green C 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. -- Green C 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)

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)

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)