Jump to content

Help talk:Citation Style 1

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by 24.105.132.254 (talk) at 16:10, 19 January 2020 (→‎This passage in the documentation: Not quite.). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

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

spam black list and archive urls

There is a discussion: Wikipedia:Village pump (technical) § Possible interaction of spam blacklist and citation archival-url. Apparently, the spam blacklist can be triggered by a url embedded in an archive.org snapshot url (and presumably in other achive urls that include the original url). This presents a problem to editors who try to fix cs1|2 template citations. One solution described at the aforementioned discussion is to percent encode the original url in the archive url; this:

https://web.archive.org/web/20091002033137/http://www.example.com/

becomes this:

https://web.archive.org/web/20091002033137/http%3A%2F%2Fwww.example.com%2F

I have hacked on Module:Citation/CS1/sandbox and implemented this solution. Here for |url= and |title=:

{{cite book/new |title=Title |url=http://www.example.com |archive-url=https://web.archive.org/web/20091002033137/http://www.example.com/ |archive-date=2009-10-02 |url-status=unfit}}
Title. Archived from the original on 2009-10-02.{{cite book}}: CS1 maint: unfit URL (link)
'"`UNIQ--templatestyles-00000023-QINU`"'<cite class="citation book cs1">[https://web.archive.org/web/20091002033137/http://www.example.com/ ''Title'']. Archived from the original on 2009-10-02.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Title&rft_id=http%3A%2F%2Fwww.example.com&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1" class="Z3988"></span><span class="cs1-maint citation-comment"><code class="cs1-code">{{[[Template:cite book|cite book]]}}</code>: CS1 maint: unfit URL ([[:Category:CS1 maint: unfit URL|link]])</span>

and here for |chapter-url= and |chapter=:

{{cite book/new |chapter=Chapter |chapter-url=http://www.example.com |title=Title |url=http://www.example.com |archive-url=https://web.archive.org/web/20091002033137/http://www.example.com/ |archive-date=2009-10-02 |url-status=unfit}}
"Chapter". Title. Archived from the original on 2009-10-02.{{cite book}}: CS1 maint: unfit URL (link)
'"`UNIQ--templatestyles-00000027-QINU`"'<cite class="citation book cs1">[https://web.archive.org/web/20091002033137/http://www.example.com/ "Chapter"]. [http://www.example.com ''Title'']. Archived from the original on 2009-10-02.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=bookitem&rft.atitle=Chapter&rft.btitle=Title&rft_id=http%3A%2F%2Fwww.example.com&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1" class="Z3988"></span><span class="cs1-maint citation-comment"><code class="cs1-code">{{[[Template:cite book|cite book]]}}</code>: CS1 maint: unfit URL ([[:Category:CS1 maint: unfit URL|link]])</span>

This code looks for the original url (|url=) in the archive url (|achive-url=). If found, the achive url is split at the beginning of the embedded original url. The embedded original url is then percent encoded and the two parts rejoined to make a new archive url. The same is true when |chapter= and |chapter-url= are set, and |chapter-url-status=unfit (or usurped).

For now this applies to all 'unfit' and 'usurped' urls. Presuming we keep this, I wonder if we ought not have another keyword for |url-status=; perhaps blacklisted. A separate maintenance category might also be in order.

Keep? Discard? Opinions?

—Trappist the monk (talk) 17:00, 3 October 2019 (UTC)[reply]

I think this is as much an acceptable solution as any, at least as long as archive services do not disallow percent-encoding referrals for whatever weird reason. A social rather than technical issue may arise from editors who may wonder why a blacklisted url displays in the first place. 72.43.99.130 (talk) 18:37, 3 October 2019 (UTC)[reply]
... editors who may wonder why a blacklisted url displays in the first place. I think that's not an issue because the title is not linked to the blacklisted url but to a (presumably) good snapshot of the website page before it was blacklisted. I presume here that the editor who chose the archive url did so in good faith and that the archived source does, indeed, support the Wikipedia article's text. I suppose that the argument might be made that a blacklisted url is a blacklisted url whether it's archived or not. Still, to your point, using |url-status=unfit or |url-status=usurped disables the link to the original url in the rendered citation.
—Trappist the monk (talk) 19:12, 3 October 2019 (UTC)[reply]

Never mind. I have reverted this change per the linked discussion.

—Trappist the monk (talk) 22:30, 3 October 2019 (UTC)[reply]

Regarding this:

I suppose that the argument might be made that a blacklisted url is a blacklisted url whether it's archived or not.

I think that shouldn't be an issue. We should distinguish between these two cases:
  1. The url (or domain) was always malware/spam; it was never suitable for a reference, and still is not.
  2. The url (or domain) started off as a good source, but is malware/spam now.
One strength of having an archive in the first place, is that it can help us deal with case #2, and provide a good copy of an url back before it changed. This may be an argument for different handling of the two cases above, which may imply different values for |url-status.
I am not certain what your expectations were about how editors should employ the values unfit and usurped , given that the CS doc for url has little to say about them. But we could, I suppose, assign (or reassign) the usurped value to case #2: that is, "The url was good once (and the archive may still retain a copy), but it isn't good anymore", which goes along with one set of display possibilities including a displayable |archive-url. That might leave unfit to cover case #1, with a different set of display characteristics (including forbidding |archive-url, if it was always bad). Or, if that's not what you intended unfit to be, then perhaps some new value (forbidden, blacklist, or whatever) to indicate that this was never a usable url and the |archive-url should be suppressed if there is one.
Whatever the case (and even if nothing changes wrt to those two values), the documentation should be updated to clearly explain these two values, and how they should be used. I'm okay with not having it updated now, especially if the usage or meaning of these values is in flux, but once things shake out, there should be a clear and thorough explanation. (If you want help editing some doc for it when the time is right, feel free to issue a request on my Talk page, and I'll be happy to help.) Mathglot (talk) 02:44, 5 October 2019 (UTC)[reply]

Original discussions about parameter values unfit and usurped are at:
Neither of those discussions consider blacklisted urls.
There were subsequent discussions with regard to parameter values:
With regard to your statement:
The url (or domain) was always malware/spam; it was never suitable for a reference, and still is not.
It has been pointed out that percent-encoding the original url in an archive url may be used to mask a cite that has always been malicious. That is also true of archive sites that support url shortening – create an archive copy of the malicious site at archive.today, use the shortened url to avoid the blacklist (until one of the bots that lengthens shortened urls arrives to lengthen it). As an aside, when these lengthening bots attempt to save an article that now has a blacklisted url embedded in an archive url, what happens?
I suppose that when archive urls link to malicious archives, the whole archive url can be blacklisted (presumably with sufficient flexibility that such blacklisting catches all archive urls regardless of timestamp). If there is a specific archive timestamp that can be shown to not be malicious, then an editor could possibly petition whomever does this sort of thing to white-list that particular archive. The question then becomes, how do we mark such white-listed archive urls?
For me, I understand unfit and usurped to mean that the url links to:
  • unfit – link farm or advertising or phishing or porn or other generally inappropriate content
  • usurped – new domain owner with legitimate content; original owner with legitimate content unrelated to the originally cited url's content
Yep, there is no bright line separating the two but, as can be seen from the original discussions of these parameter values, we struggled to get even these because the waters, they are muddy.
And I repeat myself yet again: if you can see how the documentation for these templates can be improved, please do so.
—Trappist the monk (talk) 14:34, 5 October 2019 (UTC)[reply]
lengthening bots .. what happens? - I believe there is a flag to exempt bot accounts from being blocked on save. I prefer to get blocked to manually fix. My bot also decodes encoded schemes in the path/query portion so the filters are not bypassed. IMO re whitelisting, it is often a matter of judgement/opinion and also double jeaporady since the original blacklisting presumably had a consensus discussion, it opens every blacklisted URL up to a new potential consensus discussion. This is a loophole for users to get past blacklists and overhead to manage. -- GreenC 22:10, 5 October 2019 (UTC)[reply]
usurped – new domain owner with legitimate content; original owner with legitimate content unrelated to the originally cited url's content
I assumed usurped to be closer to hijacked? If there is a new, properly registered owner (publisher) did any usurpation take place? 72.43.99.138 (talk) 15:42, 6 October 2019 (UTC)[reply]
When I use a word,' Humpty Dumpty said in rather a scornful tone, 'it means just what I choose it to mean — neither more nor less.
Look up usurp in Wiktionary, the free dictionary.
I think that these definitions of usurped, unfit, and possibly other values of |url-status need solid, agreed-upon definitions. Just from the point of view of English usage, never mind specialized wiki vocabulary, usurped is much more like what IP 72 stated. The sense of a new domain owner with legit content is nothing like most native English speakers would imagine, I don't think, when seeing the word usurped.
To me, your definition is a bit more like what would apply to a word like, repurposed, or reassigned, or repositioned or perhaps some word from marketing vocab when one company buys another's superannuated property, if there is such a word. The term usurped does not seem appropriate for the meaning you assume for it. This all needs further airing out, before the spam blacklist wrinkle, which is an edge case of the broader problem, can even be discussed. I have a feeling that there may be a need for at least one, perhaps two more values for |url-status to cover the different meanings that we seem to be alluding to for it, and trying to cram into two few values. Mathglot (talk) 23:12, 9 October 2019 (UTC)[reply]
Just wanted to be clear about one point: I don't think we need new values, just for the sake of new values; there's not need to distinguish every possible thing that could happen with an url. But, when they should be handled differently by the software, then, yes: we do need values for those cases. When the confusion surrounding the current meanings of usurped and unfit are settled, I suspect we will find that we will need at least one more value, in order to assign it to different handling in the software, and I think the spam blacklist case may be one such example. Mathglot (talk) 23:19, 9 October 2019 (UTC)[reply]
If you don't like the definitions that I offered above, write better definitions. I did write above: ...as can be seen from the original discussions of these parameter values, we struggled to get even these... Yeah, we know that these parameter keywords are less than optimal so there is no real need to spend a lot of words telling us what we already know. Suggest better definitions and / or suggest better keywords.
—Trappist the monk (talk) 12:43, 10 October 2019 (UTC)[reply]
For domain names that are not trademarked, |url-status=reassigned would be imo a good option to clarify there is a new registrant. Obviously trademarked domains (like say, newyorktimes.com) would not normally lapse, so in these cases |url-status=usurped would be more accurate. 72.43.99.138 (talk) 13:55, 11 October 2019 (UTC)[reply]
I agree with 72.43.99.138. — UnladenSwallow (talk) 17:25, 11 October 2019 (UTC)[reply]

Italics of websites in citations and references – request for comment

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.
An overall consensus exists here that names of websites in citations/references should be italicized, generally in line with current practices. Limited exceptions to italicizing were discussed by some, however no clear consensus emerged on this point. Steven Crossin Help resolve disputes! 15:49, 26 August 2019 (UTC)[reply]

Amended close - based on two different users approaching me regarding the wording of the RFC above, I am amending my close, and directing the users involved here to re-advertise the follow up question on scope.

I do continue to find, as per the wording of the RFC question, a consensus exists to italicize the names of websites in citations/references. However, based on a review of the discussion, the scope to which this consensus should be applied is unclear. While the discussion was advertised widely on many citation pages, and the wording of the question may seem to imply a site-wide change, the location of this discussion, and comments in this discussion, may seem to indicate this consensus should only apply to this template. For that reason, I'm holding a subsequent discussion for 30 days so the community can conclusively determine the breadth of the application of this discussion, as it could be cut both ways here. Steven Crossin Help resolve disputes! 13:18, 6 October 2019 (UTC)[reply]


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)[reply]

The following pages have been notified

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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
  • 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)[reply]
  • 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)[reply]
    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)[reply]
  • I don't think there are necessity of italicizing. References and something like that, can be written by bold texts or adjusting size. There is another way to do that kind of activity.-Sungancho951025
  • 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)[reply]
    With no allowances for WP:COMMONNAME (policy)? - PaulT+/C 06:06, 19 May 2019 (UTC)[reply]
    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)[reply]
    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. - PaulT+/C 16:01, 19 May 2019 (UTC)[reply]
  • 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)[reply]

  • 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)[reply]
    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.) - PaulT+/C 06:06, 19 May 2019 (UTC)[reply]
    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)[reply]
    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. - PaulT+/C 15:16, 22 May 2019 (UTC)[reply]
  • 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)[reply]
    • 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)[reply]
      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)[reply]
      @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)[reply]
    • "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)[reply]
  • 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)[reply]
  • Yes italics, no change from how we currently cite. Cavalryman V31 (talk) 21:01, 18 May 2019 (UTC).[reply]
  • 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,[a] 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.

  1. ^ Relevant policies (emphasis in originals):
    • WP:Verifiability: "all material must be attributable to reliable, published sources.... Articles must be based on reliable, independent, published sources with a reputation for fact-checking and accuracy. Source material must have been published.... Unpublished materials are not considered reliable.... Editors may ... use material from ... respected mainstream publications. [Details elided.] Editors may also use electronic media, subject to the same criteria."
    • WP:No original research: "The phrase 'original research' (OR) is used on Wikipedia to refer to material – such as facts, allegations, and ideas – for which no reliable, published sources exist."
    • WP:What Wikipedia is not: New research must be "published in other [than the researchers' own] venues, such as peer-reviewed journals, other printed forms, open research, or respected online publications".
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, - PaulT+/C 22:19, 18 May 2019 (UTC)[reply]
  • 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)[reply]
    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)[reply]
  • 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 (TALKCONT) 01:34, 19 May 2019 (UTC)[reply]
    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)[reply]
  • 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)[reply]
    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? - PaulT+/C 03:09, 20 May 2019 (UTC)[reply]
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)[reply]
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)[reply]
  • Italics, how we've always done it (or should have always done it). Kaldari (talk) 16:06, 20 May 2019 (UTC)[reply]
  • 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). Brandmeistertalk 10:06, 21 May 2019 (UTC)[reply]
    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. - PaulT+/C 15:16, 22 May 2019 (UTC)[reply]
    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. Brandmeistertalk 22:04, 22 May 2019 (UTC)[reply]
    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. - PaulT+/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)? - PaulT+/C 22:31, 22 May 2019 (UTC)[reply]
  • 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)[reply]
    This is directly contrary to MOS:ITALICWEBCITE (see directly above). Citations can be (and often are) formatted differently than running prose. - PaulT+/C 15:16, 22 May 2019 (UTC)[reply]
    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)[reply]
    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? - PaulT+/C 21:12, 22 May 2019 (UTC)[reply]
    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)[reply]
  • 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)[reply]
  • 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)[reply]
    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. Brandmeistertalk 09:41, 23 May 2019 (UTC)[reply]
    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.) - PaulT+/C 10:33, 23 May 2019 (UTC)[reply]
    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. Brandmeistertalk 11:51, 23 May 2019 (UTC)[reply]
    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. - PaulT+/C 15:00, 23 May 2019 (UTC)[reply]
    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. Brandmeistertalk 15:52, 23 May 2019 (UTC)[reply]
    (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)[reply]
    Thanks, this is helpful. I'll dig into it when I have some more time. - PaulT+/C 15:00, 23 May 2019 (UTC)[reply]
    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)[reply]
    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. Brandmeistertalk 07:05, 25 May 2019 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
    • Per SMcCandlish? Can you double-check that? I believe SMcCandlish was italicize (always), not it depends. —BarrelProof (talk) 13:06, 27 May 2019 (UTC)[reply]
      • It depends in that some online entities are not italicized in running prose, being generally of the character of a service or some other non-publication, in typical-use context. If we cite them in a source/reference citation, however, we are only ever citing them as one kind of thing: a publication (a published source), so in a citation the italics belong there.  — SMcCandlish ☏ ¢ 😼  17:23, 12 June 2019 (UTC)[reply]
  • Italics per SMcCandlish. Malcolmxl5 (talk) 06:33, 26 June 2019 (UTC)[reply]
  • Italics When I cite something I read on https://www.nbc.com, I am not citing the network because the network is on television. Something I saw on television is not my source. I am citing the website which is a periodical and just so happens to share a name with the network. The publisher is "NBCUniversal". The "website=" is the proper parameter to use in this example. I don't see why non-periodical should be treated differently. They are a body of creative work and should be italicized similar to a book, a television series, or art. Misusing "publisher=" is not acceptable no matter how long that has been the status quo. Rotten Tomatoes is published by Fandango. AllMusic is published by RhythmOne. <publisher> is different from <work>.--- Coffeeandcrumbs 04:31, 28 June 2019 (UTC)[reply]
  • I've only just been made aware of this RfC, so I'm afraid I'm weighing in late. No italics for non-periodicals When we cite The New York Times, we give The New York Times in the footnote, and not NYTimes.com. Because NYTimes.com is merely a delivery system. What we're citing is the news-gathering expertise of The New York Times. So likewise when we cite NBC News, the website NBC.com is just a delivery system. We're not citing the IT guys and website administrator — we're citing the professional journalists and editors of NBC News.
Same with institutions: The British Board of Film Classification is not a print/online book, magazine or newspaper. No one italicizes it or Dept. of Commerce or The Academy of Motion Picture Arts and Sciences. Why would we? And Rotten Tomatoes and Box Office Mojo are databases, not books or periodicals, and likewise are never italicized, by themselves or by their Wikipedia articles. What's the upside of Wikipedia using an eccentric style?
Modern Language Association (MLA) italicizes websites in footnotes. However, neither Associated Press (which eschews italics for quote marks) nor the Chicago Manual of Style (as explained here italicizes websites. (There are about 16 or 17 citation styles in more-or-less regular use, incidentally, if we really want to go through them all.) So it's not like there's any consensus in the broader world outside Wikipedia for italicizing websites. Differentiating between books / periodicals and organizations / institutions / databases is more in line with the real world and offers clarity and specificity, two things an encyclopedia at its best provides.--Tenebrae (talk) 05:13, 29 June 2019 (UTC)[reply]
It would be more productive to actually address the point about why we don't cite "NYTimes.com:" than to engage in ad hominen attacks on those who disagree with you. As for "following trends", an encyclopedia does what's best for clarity and specificity, regardless of passing "trends".--Tenebrae (talk) 15:40, 29 June 2019 (UTC)[reply]
Hey, Tenebrae, been awhile. Good to talk with you again! As for what specific points to address, please see the opinion and other posts by SMcCandlish, as I agree with it on these issues. So if you must beat someone up about it, that's the editor to mangle, because it (SMcCandlish) is always throbbingly controversial. !>) By following trends, I did not mean "passing trends", but instead those lasting ones that ultimately resulted in how external resources and Wikipedia apply the use of italics in the present day. Paine Ellsworth, ed. put'r there  01:53, 30 June 2019 (UTC)[reply]
And I think it's you who needs to "get with the program". You've linked to an RfC on the use of italics in article titles, but the issue here is whether titles of sites that are not italicised in regular text should be italicised in citations. You appear to be a fan of italicisation for the sake of it. JG66 (talk) 16:25, 29 June 2019 (UTC)[reply]
I'm a little confused since I'm saying just the opposite, as a matter of fact. If we're citing a periodical or book, whether online or printed, yes, italicization is standard. But if we're citing a company, then no. The argument that we should cite NBC.com for an NBC News citation or NYTimes.com for a The New York Times citation seems eccentric and non-standard. --Tenebrae (talk) 00:02, 30 June 2019 (UTC)[reply]
You are misstating my point. The news website that belongs to NBCUniversal is not named NBC.com. It is called NBC News and is published by a division of the same name. I would never put a .anything outside the |URL= . Two entities that belong to the same company can share the same name. In this case, there are two entities of different types: a publication (NBC News) and a publisher (NBC News division of a parent company NBCUniversal). We disambiguate them by italics. Using the proper parameter also allows it to be machine-readable. --- Coffeeandcrumbs 09:13, 4 July 2019 (UTC)[reply]
@Tenebrae: Pretty sure that Editor JG66 was not replying to you (who did not link to an rfc) but to Editor Paine Ellsworth. I am removing the indent that you added with this edit.
—Trappist the monk (talk) 00:10, 30 June 2019 (UTC)[reply]
Tenebrae: Sorry, I could have made it clearer. It is as Trappist the monk says. JG66 (talk) 04:44, 30 June 2019 (UTC)[reply]
Thank you, JG66, for thoroughly misunderstanding what I wrote, although that's probably as much my fault as yours. I think I've been with the program for many years, as I've been involved in many italics discussions and have learned much about the changes over the years in external style guides as they pertained to the applications of italics. I've always sought to improve Wikipedia's italic stylings in line with those external resources. The link I gave was just an illustration, an example, a gentle reminder that before then and since, editors have worked hard to get the policy and guidelines updated to their present not-too-shabby condition where italics are concerned. As for being some kind of fan of italics just for the sake of it, I really could care less. My only concern is whether or not this encyclopedia is consistent with other reference works in its application of italics. Paine Ellsworth, ed. put'r there  01:42, 30 June 2019 (UTC)[reply]
Thanks for the shout-out, Paine Ellsworth. I've been away mostly since it's just these types of discussion that cause me to. As I'd mentioned, the widely used Chicago Manual of Style, for one, does not italicized websites, so this issue is not a question of Wikipedia being 'consistent with other reference works" — it is consistent with other reference works. Just not the one you prefer (MLA).
There is a valid, extremely useful distinction to be made between books / periodicals and institutions, companies and other organizations. I find the always-italics reductivism perplexing. By the arguments presented here ("I'm not citing NBC News but NBC.com), then virtually nothing would ever be non-italicized, since all companies have websites. By these arguments, we'd never cite the British Board of Film Classification but only bbfc.co.uk. We'd never cite Box Office Mojo but boxofficemojo.com. We'd never cite Johnson & Johnson but jnj.com. I think most people would find this eccentric and anti-intuitive. NBC News is not italicized, and placing it in a "website=" field that would italicize it and Dept. of Commerce and Johnson & Johnson, etc. goes against logic and common sense.--Tenebrae (talk) 12:51, 30 June 2019 (UTC)[reply]
That's more of a discussion of how to use the template. In those cases, you would use both website/work and publisher in the template. publisher=Johnson & Johnson |website=jnj.com. It would really be the same if they published a monthly journal of their own. publisher=Johnson & Johnson |work= JJ's Journal Alaney2k (talk) 14:04, 30 June 2019 (UTC)[reply]
jnj.com is not the name of the website; it is a shortened URL which a user can type into almost any browser address bar. The website has a name which happens to be the same as the name of the company that publishes it. So it would be |website=Johnson & Johnson |publisher=Johnson & Johnson. But in the same way we would not write |work=The New York Times |publisher=The New York Times Company, we would not list the Johnson & Johnson twice. Therefore, we arrive at simply |website=Johnson & Johnson. I will give you another example to demonstrate my point. NASA has many website including https://images.nasa.gov/. When citing this webiste as a source, I would not use |website=images.nasa.gov |publisher=NASA because the website has a name NASA Image and Video Library. This is a website and not a physical library. Several NASA centers contribute to it and is entirely contained online. Again here, the name of the publisher is superfluous so we also arrive at simply |website=NASA Image and Video Library. --- Coffeeandcrumbs 08:48, 4 July 2019 (UTC)[reply]
  • Italics. While there are some inconsistencies with some common usage, I think most of the issue is the misuse of the template. We should be trying to use both work/website and publisher so that we are completely informative. Italicizing the work distinguishes the two nicely when reading. Alaney2k (talk) 14:04, 30 June 2019 (UTC)[reply]
I think when the citation already links to jnj.com that it's redundant to additionally say jnj.com. It addition to being redundant, this would simply add links to a commercial concern. What is the user-benefit of helping a company by adding twice as many links to it as the citation needs? --Tenebrae (talk) 14:58, 30 June 2019 (UTC)[reply]
Maybe it's important to know (for inexperienced editors) or at least gently remember (the rest of us) that using the markup for italics in the |website= parameter eliminates the italics in the end result. For example, when one uses |website=''jnj.com'' in the citation code, it comes out upright, as in:  jnj.com. So is the solution you seek 1) to eliminate the italics in the parameter or 2) to educate editors in its correct usage? Paine Ellsworth, ed. put'r there  17:10, 30 June 2019 (UTC)[reply]
I completely agree with you, Paine — I was, in fact, doing that for things like Rotten Tomatoes that are not italicized. But I believe I read somewhere in this discussion that such Wiki markup in templates adversely affects the metadata. If that's incorrect, then, yeah, I think we're reaching a middle ground.
Another possibility is to have a template called something like "Cite company" or "Cite organization", where NBC, Rotten Tomatoes etc. would not be italicized. But that's probably a separate discussion.--Tenebrae (talk) 22:14, 30 June 2019 (UTC)[reply]
  • Italics per SMC. CThomas3 (talk) 05:08, 15 July 2019 (UTC)[reply]
  • Italics Normally we use "publisher" for something like NASA. "website" is only ever used for a uri, e.g. |website=astrology.org.au If there is a publisher, website is not used; it is avoided whenever possible. "work" is never used for a newspaper; "newspaper" is always used instead 9and gives you italics), and we don't bother with publisher for newspapers, journals, magazines etc "work" is also generally avoided. However, for a TV site like CNN, we use publisher.|publisher=CNN Hawkeye7 (discuss) 06:41, 15 July 2019 (UTC)[reply]
    "website" is only ever used for a uri – this is simply not true; read the discussion above, especially the explanations by SMcCandlish. |website= is an alias of |work=, and should be used in the same way, as it is in citation-generating templates like {{GRIN}}, {{WCSP}}, etc. Peter coxhead (talk) 14:59, 15 July 2019 (UTC)[reply]
  • Italics per SMC. I entirely agree that editors should not be "abus[ing] unrelated citation parameters, such as |publisher=, to evade italicization of online work titles in source citations" because I see it happen all too often, and I don't think this should have been removed from MOS:T either. I don't understand why some editors will go out of their way to avoid using a parameter that italicises something as if it's "wrong". Ss112 08:48, 21 July 2019 (UTC)[reply]
Well, because it indeed might be wrong. Rotten Tomatoes, for instance, is not italicized.--Tenebrae (talk) 00:18, 7 August 2019 (UTC)[reply]

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)[reply]
    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)[reply]
    We might have common ground: I don't think any of us disagrees that books and periodicals, whether in print or online, should be italicized: Salon, Newsweek, etc. It's when the cite is to an organization like the British Board of Film Classification or NBC News or Rotten Tomatoes that are not books or periodicals, and are not normally italicized.--Tenebrae (talk) 22:19, 30 June 2019 (UTC)[reply]
    It's been a couple of days, and this seems the correct section, "Discussion and alternatives", to talk about middle ground. Paine Ellsworth suggested that for non-italicized companies and organizations, like NBC News and Rotten Tomatoes, that we simply do wiki-markup to de-italicize the website= field. Or, we could have an additional template called something like "Cite company" or "Cite organization", where NBC, Rotten Tomatoes etc. would not be italicized. Surely a workable, practical compromise can be reached, as is the goal of consensus. --Tenebrae (talk) 21:39, 3 July 2019 (UTC)[reply]
    Also — and as a journalist this strikes me as obvious, though it just occurred to me this might not be so to the general public — there is a critical distinction between publications (italicized), which fall under the rules of journalistic standards, practices and ethics, and companies and organizations like Sears or Rotten Tomatoes or Amtrak (not italicized), which are not obligated to follow journalistic standards, practices and ethics.--Tenebrae (talk) 19:49, 11 July 2019 (UTC)[reply]
    Sorry, but no. You think a reference to something published on the NBC News website should not use italics? How about The National Enquirer and The Daily Mirror and the Weekly World News? (Those publications don't seem to feel obliged to "follow journalistic standards, practices and ethics", so should we not use italics for those too?) Are you suggesting we use italics as an indicator of reliability? —BarrelProof (talk) 12:11, 14 July 2019 (UTC)[reply]
    You're making my point: There is no one-size-fits-all solution, because publishing, broadcasting and the web are, like humans, complex. Saying everything should be italicized is just such an impractical, one-size-fits-all solution.--Tenebrae (talk) 00:20, 7 August 2019 (UTC)[reply]

*Wait: An editor in this discussion unilaterally changed the MOS page to his preferred version after this discussion began? That editor, who unilaterally did this on 22 May, needs to restore the status quo to what it was as of 18 May when this discussion began. We don't just change MOS pages without consensus, and the fact we're discussing this shows there's no consensus. We don't just change the MOS, then come back to a discussion and say, "Well, look what the MOS says, I'm right!" Jesus Christ. --Tenebrae (talk) 13:48, 9 August 2019 (UTC)[reply]

  • Instead of hyperbole, perhaps it would be a good thing for you to:
    1. identify the editor whom you accuse of this malfeasance
    2. identify which of the many MOS pages was modified
    3. link to the actual edit
    —Trappist the monk (talk) 14:18, 9 August 2019 (UTC)[reply]
    It already was identified: At least one other editor, JG66, noted this SMcCandlish edit here not long after it happened, and somehow the comment got buried and missed in this avalanche. JG66 even included the link to the actual edit, which is this one.
    Just want to note that hyperbole means "extreme exaggeration". Stating factually that an editor in this discussion unilaterally changed the MOS page to his preferred version after this discussion began is literally not hyperbole.--Tenebrae (talk) 17:03, 11 August 2019 (UTC)[reply]
    Editor SMcCandlish's edit to MOS:TITLE occurred on 2 May 2019. Isn't that 16ish days before the 18 May 2019 start-date of this RfC? Perhaps the claim that [an] editor [SMcCandlish] in this discussion unilaterally changed the MOS page to his preferred version after this discussion began (emphasis in original) is not correct?
    —Trappist the monk (talk) 22:08, 11 August 2019 (UTC)[reply]
    My apologies: Both the other editor and I must have scanned "2 May" as "22 May" in our minds. I've struck out my comments.
    That said, the 2 May edit still appears to have been done unilaterally without discussion. One editor "clarified" the MOS to his personal preference without talk-page consensus. That still is not right — and it remains a fact that italicizing EVERYTHING, even company names that are never italicized, is an extremist eccentricity not in mainstream footnoting.--Tenebrae (talk) 17:21, 21 August 2019 (UTC)[reply]

Closing

There have been no edits on this topic in the last ten days. Is there any objection if I refer this to Wikipedia:Administrators' noticeboard/Requests for closure? Thank you. SchreiberBike | ⌨  00:08, 7 June 2019 (UTC)[reply]

Are you in a hurry? If you force a conclusion to this rfc tomorrow, nothing would happen here because we is still have to conclude the pmc rfc. You might as well let this one run its full time.
—Trappist the monk (talk) 00:30, 7 June 2019 (UTC)[reply]
@Trappist the monk: Any objection to closing now? I'm not clear on why there is an advantage to wait until the pmc rfc is ready to close. Thanks, SchreiberBike | ⌨  22:37, 27 June 2019 (UTC)[reply]
I did not mean to imply that this rfc closure should wait until the pmc rfc is closed. I did not / do not see any need for an early closure. Now that the rfc has expired, of course it can be closed. Don't expired rfcs end up on some list somewhere to be formally closed?
—Trappist the monk (talk) 23:02, 27 June 2019 (UTC)[reply]
Close requested here. SchreiberBike | ⌨  02:52, 28 June 2019 (UTC)[reply]
That was a full month ago. Just adding a comment here to prevent auto-archiving. —BarrelProof (talk) 02:10, 3 August 2019 (UTC)[reply]
Another two weeks. Just adding another comment here to prevent auto-archiving. —BarrelProof (talk) 23:36, 19 August 2019 (UTC)[reply]
The above discussion is preserved as an archive of the debate. Please do not modify it. No further edits should be made to this discussion.

Follow up discussion - scope of application of italics in citations RFC

All, based on the last RFC where I determined a consensus (#Italics of websites in citations and references – request for comment), I am holding a subsequent discussion to definitively determine how widely this should be applied, whether to all citation templates or a more limited scope. Please provide your thoughts below. I will close this discussion after 30 days. Steven Crossin Help resolve disputes! 13:18, 6 October 2019 (UTC)[reply]

Note: This is not a discussion to re-debate whether italicisation should occur, as that was already determined in the previous discussion, but to determine where this should apply only. Steven Crossin Help resolve disputes! 19:40, 6 October 2019 (UTC)[reply]

The following pages have been notified:

—Trappist the monk (talk) 14:18, 6 October 2019 (UTC) (initial list) 11:32, 9 October 2019 (UTC) (+WP:CENT)[reply]

This RfC arises from this discussion at closer's talk page.

—Trappist the monk (talk) 14:30, 6 October 2019 (UTC)[reply]

Follow up responses

  • clarification needed - I assume we are just talking about CS1 template here. If so, a lot depends on which citation style our CS1 template is based upon. Different styles present websites in different ways (some italicized, some not). So which style guide is the template based on? Blueboar (talk) 15:47, 6 October 2019 (UTC)[reply]
    @Blueboar: The exact question is whether the earlier discussion applied to all references to websites, whether it applied to something lesser (e.g. as used in CS1/2), or something even smaller than that. I find it hard to believe that it would be something lesser than CS1/2 based on the discussion and context, but someone may argue such. --Izno (talk) 18:11, 6 October 2019 (UTC)[reply]
  • Italics in cs 1/2 templates - per the RFC discussion above. 72.43.99.138 (talk) 15:08, 6 October 2019 (UTC)[reply]
  • {{Cite web}} only. The location of the discussion, Help:Citation Style 1, put editors on notice that the RFC only applied to that style. {{Cite web}} is the only template in that style I know of that calls for giving the title of the website as such. Furthermore, to avoid false metadata {{Cite web}} should only be used for periodicals, so it should not be used for other websites. Jc3s5h (talk) 15:13, 6 October 2019 (UTC)[reply]
    Furthermore, to avoid false metadata {{Cite web}} should only be used for periodicals, so it should not be used for other websites. This is a different discussion. Let's keep on topic. 72.43.99.138 (talk) 15:17, 6 October 2019 (UTC)[reply]
  • CS 1/2 only, but only web site / work, not publisher. Some discussion since the first RFC has attempted to extend the italicization to publishers (that is, organizations, not collective groups of web pages) in the absence of a web site / work parameter, and that is incorrect. This should only apply to CS1 and CS2 per WP:CITEVAR. —David Eppstein (talk) 16:52, 6 October 2019 (UTC)[reply]
    I don't think I've seen anyone claim that |publisher= should italicize anything. --Izno (talk) 18:11, 6 October 2019 (UTC)[reply]
    No but some have argued that when a website has no title, the publisher's name should be used as |website= and be italicized, which is, indeed, italicizing the publisher's name. – Levivich 18:13, 6 October 2019 (UTC)[reply]
    Which is also a different discussion. --Izno (talk) 18:19, 6 October 2019 (UTC)[reply]
  • Rerun this RFC from scratch – and this time advertise it on CENT. The proposal should be clear about what will change if it passes. So "Should websites always be italicized" isn't a great question. A better one would be, "Should we make change X to the MOS", or "Should we make change X to the citation template code", or something concrete like that. We need to differentiate between an MOS-style guideline directive, and a hard change to code. We also need to differentiate between work= and publisher= as discussed above. In my view, the scope of the existing RfC is nil because of the procedural flaws. – Levivich 17:48, 6 October 2019 (UTC)[reply]
    @Levivich: The original proposal was listed on CENT. Please don't make this about whether it was advertised; that was not the question asked. --Izno (talk) 18:08, 6 October 2019 (UTC)[reply]
    Where? I couldn't find it. – Levivich 18:12, 6 October 2019 (UTC)[reply]
    @Levivich: Review the link provided in my response. --Izno (talk) 18:14, 6 October 2019 (UTC)[reply]
    I didn't see it at first but now I see it. It should be advertised clearer on CENT. For example, the CENT advertisement was "Italics of websites in citations", and not the clearer, "Should website names always be italicized?" or the even clearer, "Should {{cite web}} always require a website name, which is always italicized?" – Levivich 18:16, 6 October 2019 (UTC)[reply]
    Not per the guidelines established on Template:Centralized discussion#Style. If you take a minute to review the history of that template, the intent is to be short and sweet. I used the title the discussion was started under (for better or worse). --Izno (talk) 18:19, 6 October 2019 (UTC)[reply]
    Added to WP:CENT
    —Trappist the monk (talk) 11:30, 9 October 2019 (UTC)[reply]
  • CS1/2 templates only. I think that's obvious from the context in which the question was asked. Were it to have been asked elsewhere (say, WT:MOS or WT:CITE), it might reasonably have been interpreted to mean all citations/references, but here, I do not think that was the case. --Izno (talk) 18:14, 6 October 2019 (UTC)[reply]
  • No, the titles of websites (if they have a title; most don't) should not be italicized. Where they lack a title, the URL should not be italicized. But whether or not website titles are italicized, in no circumstances should the publisher be used as the website title and italicized. That is, the title of https://www.supremecourt.gov/ is not "Supreme Court of the United States" or, even worse, Supreme Court of the United States. That site doesn't have a title. The website's publisher is the Supreme Court of the United States, and that should never be italicized. Ditto with World Health Organization, BBC News, CNN, etc.
    The Chicago Manual of Style says: "Titles of websites mentioned or cited in text or notes are normally set in roman [not italicized], headline-style, without quotation marks." Their examples include Project Gutenberg and Wikipedia. If the website has a printed counterpart, it is italicized along with the printed version, e.g. Encyclopaedia Britannica Online. Where websites have no formal title, use a short form of the URL, e.g. Apple.com, not italicized. See The Chicago Manual of Style, section 8.191, pp. 538–539. SarahSV (talk) 18:49, 6 October 2019 (UTC)[reply]
    Just a reminder, the purpose of this discussion is to decide how to apply the determined consensus in the previous RFC, not to debate the outcome. Steven Crossin Help resolve disputes! 19:44, 6 October 2019 (UTC)[reply]
    Steven, I wonder whether the previous RfC delivered a clear-enough consensus. We generally don't italicize websites. Wikipedia, for example, isn't italicized; nor are Facebook, Twitter, etc. Why italicize them only in citations? Our style choices should be consistent, at least within the same article. SarahSV (talk) 22:20, 6 October 2019 (UTC)[reply]
    I agree with Levivich that the RfC needs to be rerun. Wikipedia:Manual of Style/Titles does not support italicizing all websites: "Website titles may or may not be italicized depending on the type of site and what kind of content it features." Online newspapers, for example, are italicized. Other types of site are not. It needs to be decided on a case-by-case basis, making sure that each article is internally consistent. It makes no sense to write "Wikipedia" without italics throughout an article, then force people to use italics in a citation, but only if a template is used. SarahSV (talk) 22:37, 6 October 2019 (UTC)[reply]
I agree that we shouldn't be challenging the previous outcome in this RfC, since it's not the question being asked. With that said, an important distinction getting missed is when a website is being cited as a publication for the material it supports; that's when italicization should be invoked (according to the outcome above). Simply stating "Wikipedia" or "Facebook" in running text to reference the company or entity they represent places the website name in a different context. And in regard to the Chicago MoS perpective, keep in mind that the MLA format does support italics in citations. The inconsistency you're pointing out already exists outside of Wikipedia. --GoneIn60 (talk) 06:44, 12 October 2019 (UTC)[reply]
  • Rerun the RfC. CS1/2 templates. Specifically, |website= for all templates and |work= for the {{cite web}} template. So, for example, Apple is a company that publishes websites Apple (apple.com), Apple Support (support.apple.com), Apple Developer (styled  Developer ; developer.apple.com), etc. — UnladenSwallow (talk) 19:32, 6 October 2019 (UTC) Update: After thinking more about the problem, I agree with the other commenters that this RfC needs to be rerun. — UnladenSwallow (talk) 00:31, 7 October 2019 (UTC)[reply]
  • Rerun RfC per Levivich. Failing that, the italicization requirement should apply only to |website= in CS1 templates, and that parameter should not be required. Nikkimaria (talk) 00:27, 7 October 2019 (UTC)[reply]
  • Apply broadly: So, let's see if I am getting this wrong. 😜 You've asked people and they've told you. If the majority of the participants had a constraint in mind, they'd have told you. AFAIK the italicization helps identify the citation component, not the role and the object of the work. flowing dreams (talk page) 05:03, 7 October 2019 (UTC)[reply]
No, the reverse is true. Italicization in citations is semantic (Chicago, the city, vs. Chicago, the musical). It is not there to make a citation component stand out visually. — UnladenSwallow (talk) 09:01, 7 October 2019 (UTC)[reply]
LOL. I never said "to make a citation component stand out visually". I said "helps identify the citation component", which is a semantic role. You gave a very good example for it: "Chicago" is a publication location, "Chicago" is a published work. flowing dreams (talk page) 09:53, 7 October 2019 (UTC)[reply]
Oops. Sorry for misunderstanding you. I now get what you were saying: italicization is there to help us find the website title in a citation, not to tell us the type of the website (blog, web app, social media platform, etc.). — UnladenSwallow (talk) 20:30, 7 October 2019 (UTC)[reply]
  • Apply to CS1 only: It just occurred to me that it is meaningless to conduct an RFC about the italicization of website names across several styles unless we know for sure that all those styles have vague italicization requirements. And there is no evidence to suggest that people interested in styles other than the citation style 1 have participated in the original RFC. flowing dreams (talk page) 09:40, 9 October 2019 (UTC)[reply]
  • italicize |website= in CS1/2 templates – I did not participate in the original discussion, but I do follow this talk page, which is used for discussion of these templates. When someone proposes here that a certain kind of citation should look like X, or that a certain combination should be forbidden, they are understood to be talking about the behaviour of these templates. I understand that other pages are used for discussing the MOS, and no change to the wording of MOS was proposed here. Kanguole 08:45, 7 October 2019 (UTC)[reply]
  • Rerun the RfC. Alternately, apply this only to the CS1/2 templates — While this was posted at CENT, such a major, major change to Wikipedia got only a couple dozen editors responding, if that. Discussions for adminship, for example, get five times as many editors commenting. Make no mistake, this is essentially a site-wide change: "Cite web" is being used more and more throughout Wikipedia since even editors adding magazine or newspaper citations often figure, "Well, it's on the web." That means the de faco Wikipedia house style italicizes company and institution names, which no mainstream footnoting format does. Without a corresponding "cite organization" template that does not automatically italicize company and institution names, italicizing websites in CS1/2 is essentially mandating an eccentric house style. That means a cite from the National Oceanic and Atmospheric Administration comes out as National Oceanic and Atmospheric Administration — misleadingly making it seem like a magazine such as National Geographic. I think something this big requires more input than the small number of editors at this relatively obscure technical page.--Tenebrae (talk) 16:06, 7 October 2019 (UTC)[reply]
    Exactly. The New York Times (www.nytimes.com) is an online news outlet and should be italicized. Google Docs (docs.google.com) is a web app and should not be italicized (apps are not italicized, as opposed to games). It follows that {{cite web}} must use manual italicization. I don't think it's such a big problem. The rules for applying italics can be put in the description of the website parameter. — UnladenSwallow (talk) 21:20, 7 October 2019 (UTC)[reply]
    IMHO, Google Docs must never appear in |website=. It belongs to |via=. Such is the case for GitHub: The repo name goees into |work=. flowing dreams (talk page) 11:55, 9 October 2019 (UTC)[reply]
Generally, yes. However, the web app name will be listed in |website= for pages like "About", "Help", "Subscription plans", etc. — UnladenSwallow (talk) 18:32, 9 October 2019 (UTC)[reply]
Oh, I see. In that case, your reference to Google Docs would be analogous to referring to an appliance's manual as opposed to referring to the appliance itself. In this case, the page to which you are linking is not an app, so, per your own criterion, definitely italize it.
But as I said, italicization has semantic meaning. This is important because |work=, |publisher= and lots of other parameters are optional. There is no telling if the citation has them. The italicization is your only clue. flowing dreams (talk page) 07:10, 10 October 2019 (UTC)[reply]
the page to which you are linking is not an app, so, per your own criterion, definitely italize it I never said app/not-an-app was my criterion. I simply offered two examples: an online news outlet (which are always italicized) and a non-game web app (which are never italicized). There are many other types of websites which may or may not be italicized. But that doesn't matter. What matters is that there are two types of websites that disagree on italicization. Therefore, we can't apply italicization automatically and must leave the decision to the template user.
You argue that Google Docs would never (or almost never) appear in |website=, so it's a bad example. Fine, let's take another example: Federal Reserve Economic Data (fred.stlouisfed.org). Certainly you would agree that it goes into |website= (and Federal Reserve Bank of St. Louis goes into |publisher=). And yet, it is always cited as FRED (no italics). There are many more examples like that. — UnladenSwallow (talk) 00:36, 11 October 2019 (UTC)[reply]
Humph. This is getting more and more complicated without any benefit. Nah. I'd say italicize all works, be it book, film, play, or app. flowing dreams (talk page) 06:54, 11 October 2019 (UTC)[reply]
This is not getting more and more complicated. I've provided you with two examples of websites: one that is italicized and one that is not. You've discarded the second example on the basis that it should always go into |publisher=, so I've replaced it with another example of a website that is not italicized.
So now we have The New York Times (www.nytimes.com) that is italicized and FRED (fred.stlouisfed.org) that is not italicized. This means that the decision on italicization should be left to the template user.
Nah. I'd say italicize all works… Wikipedia follows the existing norms as much as possible. If we wanted to keep things simple, we wouldn't have non-breaking spaces, en dashes, em dashes, etc. — UnladenSwallow (talk) 17:13, 11 October 2019 (UTC)[reply]
I said "complicated and without benefits". And you're not here to follow the existing norm; you're here to change existing norm on millions of articles. If Wikipedia wanted to follow existing norms, CS1 would have never been invented. By the way, you keep saing "FRED is not italicized". Not italicized by who? flowing dreams (talk page) 08:02, 12 October 2019 (UTC)[reply]
It's not italicized by any mainstream source whatsoever. Neither is Fannie Mae or Freddie Mac. As for "I'd say italicize all works" ... well, why? You're not giving any reason for having Wikipedia citations go outside the mainstream with some eccentric citation style used nowhere else. --Tenebrae (talk) 18:18, 27 October 2019 (UTC)[reply]
No, you didn't say "complicated and without benefits". You said This is getting more and more complicated without any benefit, which implies that "this" is: (1) getting more and more complicated; (2) does so without any benefit. I have addressed part (1), demonstrating to you that nothing is "getting more complicated"; in fact, the level of complexity is staying exactly the same as it was in my original comment: there are websites that are italicized and there are websites that are not italicized. you're not here to follow the existing norm I will decide for myself why I'm here, thank you. you keep saing "FRED is not italicized". Not italicized by who? Obviously, I'm referring to existing practice. As I've told you several comments back: "And yet, it is always cited as FRED (no italics)." Are you being intentionally obtuse? If you think I'm wrong, please demonstrate a variety of newspapers/magazines where FRED is cited as FRED (italicized). Except you can't. Because I've checked it thoroughly before posting my comment. You can continue to muddy the waters, or you can face the reality that in existing newspapers/magazines some types of websites are italicized (newspapers, journals, magazines, blogs, webcomics, etc.) and other types of websites are not (TV channels, radio stations, databases, company websites, etc.). See MOS:ITALICTITLE. — UnladenSwallow (talk) 05:53, 14 October 2019 (UTC)[reply]
Whoa! Whoa! Whoa! "Obtuse" is a personal attack. And "existing practices" is still a weasel word. FYI, not only I can face the reality, I can stare in said reality's eyes and tell it: "Hey, existing reality! I reject you, because you cannot justify your existence!" I've already done so to gender discrimination. If necessary, I'll do it to unhelpful italicization of components. flowing dreams (talk page) 07:37, 14 October 2019 (UTC)[reply]
  • Steven Crossin, please offer an alternative title to this discussion so that it more accurately reflects citation practice. Citations do not italicize anything. They usually emphasize the most pertinent element, traditionally - though not exclusively - by using slanted type. Both the original RFC and this discussion keep applying the misnomer of "italics" which is solely a typographical convention and does not reflect the underlying semantic meaning. 24.105.132.254 (talk) 22:29, 7 October 2019 (UTC)[reply]
    "website=" in "cite web" automatically italicizes and does not allow manual override such as wiki markup. --Tenebrae (talk) 21:24, 8 October 2019 (UTC)[reply]
  • Rerun the RfC and notify more widely. Template styles should follow the Wikipedia:Manual of Style/Titles which has a defined position on use of italics for websites (essentially being: it depends). If an overall change of style is being considered then it should be considered in that forum rather than for a specific template that users would naturally expect to follow the conventions defined in the Manual of Style. 203.10.55.11 (talk) 02:34, 11 October 2019 (UTC)[reply]
  • Rerun the RfC. You can't just overturn Wikipedia:Manual of Style/Titles without even advertising the RfC there. Kaldari (talk) 23:22, 11 October 2019 (UTC)[reply]
    • The RfC didn't "overturn" anything. The wording on this particular thing at MOS:TITLES has just been confused and unclear for a long time (until MOS:ITALICTITLE); to the extent that the depending-upon-publication-type stuff could be interpreted as applying to citations (rather than use in running prose), it would not actually reflect WP practice, which has been to italicize these work names in citations, automatically, for 10+ years now.  — AReaderOutThataway t/c 22:36, 20 October 2019 (UTC)[reply]
  • Preferably rerun the RFC; at the very most, current consensus only allows for italics in cs 1/2 templates. Notwithstanding Steven Crossin's (understandable) request that the focus here be kept on-point, the fact remains that many editors are strongly opposed to italicising each and every website title, and/or that publisher= cannot be used instead to avoid italicising organisations in cite web. It seems to me it's a case of template managers/editors seeking to squeeze different scenarios into one tidy category – whether that's through obsessiveness or a touch of control-freakery I don't know. But, as was raised in the RfC, and has been added to or alluded to here by the likes of David Eppstein, Levivich and SarahSV, it's not a case of one-size-fits-all. I'm a professional book editor, and have been for far too many years, and the idea that an organisation has to be treated as a "work" in the interest of defining a component of the citation is, well, utterly ridiculous. AllMusic, Official Charts Company, Metacritic, Supreme Court of the United States, World Health Organization, BBC News, etc, are never italicised in regular text and need not be in a citation. (No reader's going to go: "Aaargh, you've lost me ... how do the words 'BBC News' relate to the rest of the information in that source?")
To return to the question raised here: CS1/2 currently prohibits adhering to a pretty fundamental point in British English style, which is that abbreviations such as eds, nos and vols don't require a full stop/period. In the past – I think it was with regard to the "eds" issue, if not the option to use "edn" for "edition" (which, I'd say, is also preferred in Brit English) – the response here was that editors are "welcome" to write the entire citation manually and so avoid having to conform to what they consider to be a contentious CS1/2 requirement. In the same spirit, and given the scope of the RfC anyway, editors should not be required to apply italicisation outside of CS1/2 and should be able to write the cite manually or find another way that presents the information correctly. JG66 (talk) 02:42, 17 October 2019 (UTC)[reply]
  • Italicize in citations (and there is no difference in this regard between CS1 and CS2, or manually-laid-out citations). Whether to italicize in running text or not depends on whether the site is primarily like a published work (e.g. Salon or IMDb) or primarily something else (just advertising/support material like Microsoft.com, or a forum/social-networking service like Facebook). The "Rerun the RfC" stuff is patent WP:FORUMSHOPPING, an "I didn't get the result I wanted" complaint. The original RfC was widely enough advertised and ran long enough to assess consensus, and given that italicizing these in citations is already enforced by the templates and has been that way for over a decade, the "don't italicize" stuff is not a question about what consensus is, but an attempt to overturn already well-established consensus (an attempt that has failed numerous times, not just above).  — AReaderOutThataway t/c 22:23, 20 October 2019 (UTC); rev'd. 06:29, 22 October 2019 (UTC)[reply]
  • Italicize in CS1|2—the original forum for the RfC was on the talk page for the CS1|2 templates. As such, it should be a clear principle that the results of the RfC would be confined to those templates. There is no need to rerun the RfC. Imzadi 1979 → 15:45, 22 October 2019 (UTC)[reply]

Follow up discussion

  • Comment Do you think there is any mileage in scrapping the "Cite web" template altogether, and creating a "Cite organization" in its place that does not italicise? The citation style is drawn from real-world application (i.e. the website name for a newspaper would be italicised, but for an organization it would not be) so Cite web seems to be encouraging standardisation where it does not exist. If you had to choose between Cite news, Cite book, Cite journal, Cite organization etc then the stylisation issue would take care itself. This would seem to be a fairly straightforward solution so what am I missing? Betty Logan (talk) 18:18, 10 October 2019 (UTC)[reply]
I think you may be confusing prose style with citation style. Because both are styles does not mean they have the same functionality. Citations style their content towards verifiability. One way this is accomplished is by emphasizing the source, in this case, the website, so that the reader knows immediately where to start looking. It has nothing to do with application of a prose style, neither does it have to follow the referring document's style whether that is MOS or anything else. And don't overlook the fact that use of these templates (actually, the module they are based upon) is entirely voluntary. Any citation/citation style will do, as long as is consistent within the document. 65.88.88.69 (talk) 21:03, 10 October 2019 (UTC)[reply]
I am not confusing prose and citation style. I have never italicised a company/corporation name in a citation in my professional work either. For example, if you are citing something on the BBC's website you do not italicise the "BBC" in the citation. The BBC's website is not a publication called the "BBC", it is a publication by the BBC. This is generally the norm for websites. I can think of several counter-examples: if you were citing something in the AFI Catalog you would italicise the "AFI Catalog" in the citation because it is a publication by the American Film Institute. In this capacity it functions as an online encylopedia/ebook and could be cited using an appropriate template. In the case of citing something on the AFI's general website it would be beneficial to have a "corporation" template that does not italicise the company name. The "cite web" template is promoting a standardisation where one does not really exist. Betty Logan (talk) 00:56, 11 October 2019 (UTC)[reply]
The template has a |publisher= field. That is where the publishing entity (in most cases the domain owner/registrant) should be inserted. The BBC publishes bbc.com. The latter would be the source. Sources (works) should stand out, one of the reasons being that they may include a lot of other stuff, most of it mysterious to the average Wikipedia reader. The emphasis applied on the source field through italics has nothing to do with whether the source is a website or anything else. 72.43.99.138 (talk) 14:05, 11 October 2019 (UTC)[reply]
Respectfully, there has just been an RFC that was in favor of italicizing. In that light of that RFC, this suggestion lacks pertinence. Clearly, the community sees value in distinguishing the name of the work from the name of the subwork and the publisher. If I may add, re-running the RFC reminds me of some of questionable political actions I hear about these days: The election in a state or nation does not go in favor of the ruling party, so they re-run the election over and over again. flowing dreams (talk page) 11:45, 12 October 2019 (UTC)[reply]
RFCs are WP:NOTAVOTE, they are a tool for determining community opinion. Consensus on Wikipedia has never locked in a vote, chiefly because as the participants in a debate change so can opinion. Betty Logan (talk) 09:17, 14 October 2019 (UTC)[reply]
That's not what I see. RFCs are based on majority votes. In Wikipedia, minority valid concerns are ignored. In consensus-based decision making, all valid concerns are addressed. flowing dreams (talk page) 09:27, 14 October 2019 (UTC)[reply]
See WP:WHATISCONSENSUS#Not a majority vote, WP:NOTDEMOCRACY and Wikipedia:Consensus#Consensus can change (the latter two are both policies). Betty Logan (talk) 09:36, 14 October 2019 (UTC)[reply]
And here is my contribution to the consensus-building process: No! Your suggestion is egregious and without benefits, both in its own rights and in the fact that discrimination in italicization is egregious and without benefits. First, because you are operating under the wrong impression that the only websites besides news websites are organizations' websites. Not so. Second, you don't seem to have a functional reason for not italicizing certain websites. In fact, no one here seems to have. Any "reason" I see here is very arbitrary. flowing dreams (talk page) 10:13, 14 October 2019 (UTC)[reply]
Betty Logan is absolutely correct in that RfCs are not decided on by number of votes. That's not her "suggestion" but Wikipedia policy. You are completely wrong, per policy, in saying, "In Wikipedia, minority valid concerns are ignored."
As for your other points, you seem to be ignoring multiple editors in both this discussion and the closed RfC saying flat out that the names of organizations (companies, institutions) are not italicized in any mainstream footnoting style — for the very good reason of not conflating them with magazines and other periodicals. The National Oceanic and Atmospheric Administration is not National Oceanic and Atmospheric Administration, as if it were National Geographic. Having Wikipedia adopt a fringe, eccentric footnoting style makes us look like an outlier and does nothing to enhance our credibility. --Tenebrae (talk) 16:01, 15 October 2019 (UTC)[reply]
My dear esteemed colleague Tenebrae, you are being awfully forceful here. And I fear we have digressed from the discussion of a proposal for "Cite organization". I do accept that it is partly my fault. (Actually, I have nothing else to add to it, so I can bow out.) I'd be glad to have you and dear Betty in my personal talk page to talk about merits of italicizing in citations or about the de jour and de facto status of Wikipedia's consensus policy. But this thread is already a hot zone. Let's keep other hot topic out of it. flowing dreams (talk page) 08:14, 16 October 2019 (UTC)[reply]
And incidentally, I find it odious that you compare this valid, by-the-book discussion as somehow illegitimate in the same way Trumpers try to deny the constitutionality of the impeachment process or recounts. ("The election in a state or nation does not go in favor of the ruling party, so they re-run the election over and over again.") That Trumpian position holds no water in either the political world or in a Wikipedia discussion. --Tenebrae (talk) 16:05, 15 October 2019 (UTC)[reply]
You seem to be commenting about one of those nations/states who have voided their election when it did not go according to the plan. (I'd probably look up Trumpian later.) In the meantime, we can focus on the fact that I don't see why Steven Crossin suddenly decided to void the RFC, without drawing any anologies to real-world politic situations. flowing dreams (talk page) 08:14, 16 October 2019 (UTC)[reply]
Re: "Do you think there is any mileage in scrapping the "Cite web" template altogether, and creating a "Cite organization" in its place that does not italicise?" – Absolutely not. It is not possible to cite "an organization" (or individual) on Wikipedia, only a published work. See MOS:ITALICWEBCITE and all the policy it cites on this matter (or see it here if someone's been editwarring against it again). 06:38, 22 October 2019 (UTC) — Preceding unsigned comment added by AReaderOutThataway (talk • contribs) 06:38, 2019 October 22 (UTC)
That guideline did not exist 6 months ago and is indirect contravention of WP:CITESTYLE, so I certainly won't be observing it. Betty Logan (talk) 22:03, 22 October 2019 (UTC)[reply]
Contrary to User:AReaderOutThataway's claim, I can find nothing in MOS:ITALICWEBCITE that says we italicize the names of organizations such as companies and institutions in citations. Nothing.--Tenebrae (talk) 18:28, 27 October 2019 (UTC)[reply]
I didn't suggest you would (cf. straw man). Read it again, please. You can't cite "an organization". You have to cite something published. If that's a major work (not a minor one like just an article), it's italicized per MOS:TITLES, and the templates do this automagically. The organization itself goes in the |publisher= parameter, which does not italicize. No one here is confused by that, surely not you either, so trying to make it seem like I'm suggesting italicizing organization names is disingenuous.  — AReaderOutThataway t/c 20:27, 29 October 2019 (UTC)[reply]
Of course we can cite "an organization." It's done all the time hundreds of thousands of citations around the world: Doe, Jane. "Report on Apollo 11 [link]". NASA. Accessed Jan. 1, 2010. In no real-world scenario would "NASA" be italicized.--Tenebrae (talk) 21:34, 30 October 2019 (UTC)[reply]
This should be done the other way around. Don't require the use of |work= (or |website=, |newspaper=, etc.) in {{cite web}} if |publisher= is present, but create a new template, {{cite periodical}}, that does require a periodical parameter. --Ahecht (TALK
PAGE) 19:56, 28 October 2019 (UTC)[reply]
I think a "Cite organization" template is an excellent idea. As you say, it's drawn from real-world application, whereas Cite web seeks to impose "standardisation where it does not exist" (or, imo, standardisation for the sake of it). JG66 (talk) 01:04, 31 October 2019 (UTC)[reply]

What to do about ISBN-10s

10-digit ISBNs have been deprecated since about 2007 and should be replaced by 13-digit ISBNs (now called just "ISBNs") wherever found. Conversion is a simple task (prepend "978-" and calculate a new check digit).

Correct grouping of the other digits (based on "group" and "publisher" identifier lengths) is quite a bit more complicated and would require some kind of periodically updated table.

I do have a javascript that accurately does both of these things while editing, so it could probably be converted to a lua module to do them while rendering instead. And I do mean a separate module, not just a new feature in {{cite book}}. That way it can also replace the contents of the standalone {{ISBN}} template, which currently looks dreadful.

If the above sounds like too much of a cosmetic execution-timesink (I suppose I'd need to create the module first and see how badly it performs), we could resort to tracking categories to fix the input rather than the output:

  • A maintenance category when the number of digits is 10 and should be converted to 13.
    • This would be in addition to the error category when the number of digits is neither 10 nor 13.
  • A maintenance category whenever (digits == 10 && hyphens != 3) || (digits == 13 && hyphens != 4), because these are sure to be wrong.

Note that detecting ISBNs with the correct number of hyphens at incorrect positions would probably be nearly as expensive as actually fixing them, so they would be neglected in the latter strategy. ―cobaltcigs 02:46, 8 November 2019 (UTC)[reply]

I guess I disagree with your premise that 10-digit ISBNs...should be replaced by 13-digit ISBNs (now called just "ISBNs") wherever found. A 10-digit isbn in a book printed in 1982 is and forever shall be a 10-digit isbn. Editors at en.wiki are admonished to WP:SAYWHEREYOUGOTIT. Part of that is accurately recording bibliographic details from the book that they are being citing. If the isbn on the title page of the book is 10 digits, use 10 digits in the citation, don't convert it to 13 digits. See the cs1|2 isbn documentation.
—Trappist the monk (talk) 03:05, 8 November 2019 (UTC)[reply]
citation bot does the conversion IF the year is 2007 or later. That way we follow the say where you got it rule. In defense of isbn13 in older books, it COULD be thought of as adding area codes to older phone numbers—it is a stretch. AManWithNoPlan (talk) 03:39, 8 November 2019 (UTC)[reply]
IPv4 → IPv6 seems like a better analogy. ―cobaltcigs 20:47, 8 November 2019 (UTC)[reply]

The ponderous tome I linked to above says (emphasis mine): 

All new ISBN assignments are based on ISBN-13. If a 10 digit ISBN is 
found on the resource, it should be converted to a 13 digit number, 
following the rules set out later in this section, before being 
encoded into the URN framework. According to the rules of the ISBN 
standard, such conversion does not create a new ISBN for the book, 
but a new representation of the existing ISBN.  
[...]
The ISBN in thirteen digit form is defined by the ISO Standard 
2108-2005 and later editions. It was previously referred to as 
“ISBN-13” to distinguish it from “ISBN-10”, but since all ISBNs are 
now valid only in the 13 digit format and ISBN-10 is deprecated, 
ISBN-13 should be referred to as “ISBN”, although in this document 
ISBN-13 is  used for the sake of clarity.

Note that it very clearly says "all ISBNs" and not "ISBNs of books published in or after 2007" and that there is no reference to any "grandfather clause" or continued validity of ISBN-10s for any duration of time after 2007.

I do know Google Books (surely a more popular "where you got it" source than physical books anymore) info shows both 10- and 13-digit ISBNs, without regard to year of publication and without indicating which of them was ever printed on a physical book. Of course, according to the above document, they could have stopped displaying ISBN-10s (or recognizing them for search) twelve years ago without violating any standards. And since Google Books is an order of magnitude more popular than anything else on the Special:BookSources list, Wikipedia and the rest of the world would have immediately followed suit, if only they had done that. ―cobaltcigs 04:49, 8 November 2019 (UTC)[reply]

I find it difficult to get worked up about this cosmetic difference that has no effect on the verifiability of sources or readers' ability to find books when there are hundreds of pages with actual ISBN problems on them. – Jonesey95 (talk) 05:21, 8 November 2019 (UTC)[reply]
That document is about how isbn's are or should be used in the context of Uniform Resource Names. cs1|2 does not use urns so the requirements of that document do not apply here.
—Trappist the monk (talk) 12:08, 8 November 2019 (UTC)[reply]
Also, conversion is not simply a matter of prepending "978" to an ISBN. The prefix may also be 979 or in the future, something else. The ISBN registrar for the United States has a conversion tool but it is for US & Australia ISBNs only, see About ISBN (notice section on 979) and Converter. 72.43.99.138 (talk) 15:06, 8 November 2019 (UTC)[reply]
ISBNs starting with prefixes other than 978- will have no 10-digit equivalent. ―cobaltcigs 20:01, 8 November 2019 (UTC)[reply]
Did I miss something? I did not see any such statement. To quote from Bowker (the "About ISBN") link above, "A 10-digit ISBN cannot be converted to 13-digits merely by placing three digits in front of the 10-digit number. There is an algorithm that frequently results in a change of the last digit of the ISBN". So I assume this means there may be potentially a problem with the check digit in a text-based replacement. 98.0.246.242 (talk) 20:48, 8 November 2019 (UTC)[reply]
  • Every 13-digit ISBN beginning with 978- corresponds to exactly one deprecated ISBN-10.
    • "Corresponds to" means both forms refer to the same book publication and share a substring of 9 "significant" digits.
    • These 9 are followed by a final check digit, which is calculated differently depending on which form and will differ about 91% of the time.
  • Every 13-digit ISBN beginning with 979- corresponds to… no other number at all.
  • Every 13-digit ISBN beginning with any other prefix… doesn't exist yet. Hopefully nobody still uses ISBN-10s at such future time.
  • The "algorithm" is not as complicated as you may fear.
Hope this clears up some confusion. ―cobaltcigs 22:42, 8 November 2019 (UTC)[reply]
No, not really. But imo this discussion is becoming non-relevant as far as citations are concerned. As was stated before, editors should cite what they consult. If they consult a source with a 10 digit ISBN, then that is what belongs in the citation. If one feels so strongly about ISBN-13s, they should:
Find a source with a published ISBN-13
Verify the wikitext claim (previously supported by an ISBN-10 source) based on the new source
Replace and rewrite the citation based on the newly consulted source
What should not be done is replacing an ISBN-10 with an ISBN-13. These are marketing ids assigned to publishers by the proper agencies. Personally, I would reject any citation with a Wikipedia editor-manufactured ISBN-13 as original research or misdirection. Conversions of ISBN-10s are supposed to be done (and published) by the entities the ISBN's are assigned to. It is not up to Wikipedia to provide such service.
Not relevant to the above, are the various assignations. First, a straight text replacement is not the right way to go about it. Secondly, conversion tools, and their respective algorithms, seem specific to geographical areas. It is also not clear to me if outside the US "979" prefixes have not been used to replace ISBN-10s. In non-US materials, I have seen non-book ISBN-10s replaced by 979-prefixed ISBN-13s (sorry I have no real-world example handy). It would be perhaps relevant for citations to provide for an International Article Number (EAN) id, since that is what ISBN-13 is purported to align to. 108.182.15.109 (talk) 14:54, 9 November 2019 (UTC)[reply]
The above should be amended, as according to the latest edition of the ISBN Users' Manual (2017), "ISBN is now fully compatible with GTIN-13" (7th ed., p. 10, find it here). So I suppose that it would be a Global Trade Item Number id rather than an EAN that could be added if needed. 24.105.132.254 (talk) 18:39, 9 November 2019 (UTC)[reply]
  • Math is not original research, especially not when the agency issuing these numbers has published very specific instructions for performing said math. The result is as deterministic as an MD5 hash. It just happens to be 5 lines of code and not 109. Here's another tool that does the exact same math. Using that is not original research either.
  • Here are Google Books data examples from 1972 and from 2017, both of which show (mathematically!) equivalent 10- and 13-digit ISBNs side-by-side. Choosing the longer one in both cases, for the sake of consistency and forward compatibility, is not original research either.
  • There will eventually come a day when some of the hundreds of databases shown at Special:BookSources will cease to recognize 10-digit ISBNs. This will probably coincide with the assignment of 979s in the United States (when the confusion begins affecting people whose opinions matter). At that point our only choice will be to unlist certain book sources or quickly convert numbers to continue using them.
  • Here's a French children's book with a 979- ISBN and no short form next to it, because 979 ISBNs are not convertible to a 10-digit format and exist only in a 13-digit format. Any replacement such as you describe would have to be a bonehead error, or the intentional re-assignment of a whole new ISBN to an old edition of a book (not any conversion at all). Any claim that one of the latter two things routinely happens would be original research. Hopefully it's all just a false memory.
  • Do you read many books from France, South Korea, and/or Italy? Serious question.

―cobaltcigs 20:01, 9 November 2019 (UTC)[reply]

This is not how citations work. They involve published material from reliable secondary sources. ISBNs are legally issued and assigned identifiers through organizations established for this purpose. Even when the use of the conversion tools is allowable by third parties, the result would be unacceptable in a citation. The officially (by publishers) converted ISBNs have to be assigned by the ISBN agencies, like any other ISBN, and the source officially published with that ISBN. Anyone else doing a conversion and publishing it as an "ISBN" is doing OR as far as citations are concerned. Never mind wading into legally dubious territory. And that is assuming the algorithms don't change in the meantime.
We have no way of knowing if or when, book-source databases stop recognizing anything. The data is already entered and structured. There is no rule that says ISBN-10 should not be listed in such databases, nor that it should be replaced by ISBN-13. In contrast, book-marketing databases (including publisher databases) are told by the International ISBN Org. to no longer quote ISBN-10s, but this is irrelevant.
Additionally ISBNs have country codes irrespective of language. Different English-speaking countries may have different ISBN structures. The allocation of ISBNs is not cut and dried either. An educational music work could have been legally assigned an ISBN-10, and could be additionally assigned a 979 ISBN-13. A commercial music work would not have been assigned an ISBN-10, but perhaps an ISMN. Now however it can be assigned a 979 ISBN, since all these ids are compatible with GTIN-13, the new standard that is subsuming them.
And who says that anything involving math cannot be OR? It's not just how you arrive at the numbers, but also how and why you use the results. 24.105.132.254 (talk) 20:51, 9 November 2019 (UTC)[reply]
Anyway, ISBNs are so frustratingly unreliable in Wikipedia. How often I seen metadata for an ISBN be out of sync with the metadata in the cite book template (year/publisher). This can happen for a number of reasons, but mainly books have multiple years of publication and multiple publishers such as the co. name vs. imprint name vs. later editions. So someone may put the original year of publication in |year= while using the ISBN of their in-print edition which might be 20 years later. Then how do you know which edition it is? One could assume the ISBN is correct, but I've seen people and scripts add missing ISBNs to templates without a clear indication they are choosing the one intended, and not just the most recently published in-print edition. Particularly by people pushing links to bookseller sites for a certain edition. -- GreenC 19:53, 8 November 2019 (UTC)[reply]
Isn't this more of a behavioral issue. There are many admonishments in various help pages for editors to cite what they actually consult. If the consulted online link refers to a different edition than the one originally consulted to write the citation, such information is relevant and should be included somewhere, maybe in a link note. 98.0.246.242 (talk) 20:56, 8 November 2019 (UTC)[reply]
Also when you see a plural | pages = parameter followed by only one page number, there's a 90% chance it's the last page (often intentionally blank). ―cobaltcigs 21:19, 8 November 2019 (UTC)[reply]

This thread is full of obviously wrong information. Some quick facts. All books with and isbn10 have an isbn13 — it’s automatic. It does not mean that it is printed in the book obviously. The EAN for a book is the isbn13. The GTIN 13 for a book is the isbn13 number. Lastly converting an isbn10 to isbn13 is easy: just add the prefix and change the check digit. AManWithNoPlan (talk) 18:53, 9 November 2019 (UTC)[reply]

Well, none of the above are facts, quick or otherwise, according to the official ISBN manual or the official ISBN issuing authorities. I suggest you go back and check. 24.105.132.254 (talk) 20:51, 9 November 2019 (UTC)[reply]
Since you (24.105.132.254) are unwilling to do even a basic google search to see that you are wrong, here are the links. https://www.isbn.org/about_ISBN_standard and https://en.wikipedia.org/wiki/International_Standard_Book_Number#ISBN-10_to_ISBN-13_conversion all isbn10's have an isbn13 equivalent. https://en.wikipedia.org/wiki/International_Standard_Book_Number#EAN_format_used_in_barcodes,_and_upgrading and https://www.barcoding.com/blog/bookland-13-ean-13-and-isbn-numbers-one-in-the-same/ All ISBN13 are EAN. All ISBN's a GTIN https://en.wikipedia.org/wiki/Global_Trade_Item_Number#Format_and_encodings AManWithNoPlan (talk) 00:52, 10 November 2019 (UTC)[reply]
Since I was the one who originally used these links on this discussion I know very well what they are about, and the background. 72.89.161.42 (talk) 02:22, 10 November 2019 (UTC)[reply]
  • I normally copy the ISBN from the indicia of the book. If it's an ISBN-10, a Bot will convert it to an ISBN-13. It did have an instance where the ISBN-10 in the book was incorrect; libraries had filed it both under the incorrect number and the correct one. After a discussion, it was agreed to substitute the ISBN-13. However, we have detected hoaxes based on invalid ISBNs. Hawkeye7 (discuss) 20:21, 9 November 2019 (UTC)[reply]
If you add anything that is not published at the source, it makes for an invalid citation. I thought this was clear. How can you "cite" something that is not there? 24.105.132.254 (talk) 20:54, 9 November 2019 (UTC)[reply]
The point is that even though the ISBN13 in not in the book, it is still a proper way to refer to the book. Just like journals from 1800 with DOIs and ISSNs and Such . AManWithNoPlan (talk) 23:41, 9 November 2019 (UTC)[reply]
Only if the later assignations have been published by reliable sources. If they have been concocted by Wikipedia bots or by anyone else they are not citable material. 72.89.161.42 (talk) 02:22, 10 November 2019 (UTC)[reply]
Agree keep ISBN10 there is a better chance of matching the book with other databases which may or may not respected unpublished/concocted ISBN13s -- GreenC 14:27, 18 November 2019 (UTC)[reply]
  • While it is true that ther is a 1-to-1, fixed mapping between ISBN-10s and 978- ISBN-13s, In the spirit of "say where you got it, books published before, roughly, 2005, should always use the ISBN-10, and no bot or editor should be converting these to ISBN-13s, unless citing to a newer edition. DES (talk)DESiegel Contribs 08:06, 9 December 2019 (UTC)[reply]
I second this. Unfortunately, CitationBot was doing just this for months without approval and despite complaints.
If the other ISBN is known as well, the alternative ISBN can be added as additional parameter |id={{ISBN|1234567890123}} (it would be even better, if the |isbn= parameter would accept two values rather than only one). On a practical level the two ISBNs are not actually redundant, as both might be used as text search patterns by users, and listing only one of them, users searching for ISBNs in articles may unfortunately fail to find a referenced book due to the embedded checksum (this is why stores almost always list both ISBNs in order to not miss any possible hits). --Matthiaspaul (talk) 22:27, 23 December 2019 (UTC)[reply]

To regular editors of the {{cite book | ... }} template, that have write privileges

To this template, to the section/box entitled "Most commonly used parameters in horizontal format", for each of the examples for which this does not appear, please at least add:

  • | page = | pages =

If one of these do not appear in every example, lack of importance might be inferred, which is contrary to WP policies and guidelines.Then, please add any other standard, important field that is normally needed (better empty fields in an example, than the field to be missing). Please, take onto account the preference of WP writers for web-accessible sources (and the fact of inevitable url demise). That is, consider whether every example book citation template should also present:

  • | url = | url-status = | archive-url = | archive-date = | access-date =

and possibly:

  • | doi = | doi-broken-date =

Finally, in my opinion, at least one further example would be helpful, that of a two-author book with two editors, that is a part of a series, that has an original publication date that is old, and a recent publication date of a newer edition, that is available both in hardcopy, and in a digital paginated form. Add to this access date, and the fields based on the expectation that the url/doi will die.

All from me. Just aiming for no {{cite book | ... }} example to lack a page number, and for all to have needed url fields, and after than, hoping for an example that has essentially everything that is generally needed for citing scholarly secondary academic sources (which is our aim, I understand), Cheers. 2601:246:C700:9B0:A57B:85B4:7889:AE7D (talk) 15:42, 9 December 2019 (UTC)[reply]

While I tend to agree about page numbers, book citations are primarily to the printed text, and a URL to a convenience copy is in no sense required, still less a DOI, which msot books do not have. Even an ISBN is not required, and for older books there may not be one. url-status and the various archive parameters are not required even for {{cite web}} much less for {[tl|cite book}}. We should not imply that an online version is expected, much less required. DES (talk)DESiegel Contribs 18:40, 24 December 2019 (UTC)[reply]

New url-status needed: content-missing

We might need a new url-status value (or two); maybe something like content-missing or no-data, for urls which are not dead, not usurped, not unfit (per discussions here and here), but which bring up the correct website, display readable content on the page like a containing header and footer with the expected website boilerplate there, but with the "meat and potatoes" portion in the middle blank, missing, or otherwise not able to verify the content of the article.

Example: this page should (and at one time, did) have the results of the Brazilian presidential election of 2002 (and others, via radio button) but no longer does; instead, the central frame of the website is an empty gray box. None of the current |url-status= values express the fact that this url still belongs to the owner, still comes up, but contains no useful information capable of verifying content in a Wikipedia article. (In this case, the internet archive doesn't help; among 67 captures at Archive.org, it's no better (spot-checked a few). But that won't always be the case.)

I wish I had a better example, where the current website was a gray box, but Archive.org still had a valid capture showing the original page with complete data present (which I expect is a more common case), because that would be easier to deal with: the linked title should go to the archived page in that case instead of the url value; i.e., the action is similar to the status=dead-url, except "dead" is inaccurate since the original url is still live, just useless. In the example I gave, the action should actually be different, with the title being in plain-text, unlinked. It may be we need two new statuses then:

  • url-status=content-missing – url is live and identifiably the correct page but needed data is absent; archive is good: link the title to the archive.org capture
  • url-status=content-inaccessible – url is live and identifiably the correct page but needed data is absent; archive either doesn't exist, or exists but also has missing data: unlink the title.

The actions required by these two cases may match actions associated with already existing values, and in that sense the new values (action-wise) are aliases of existing values. That would be a win for implementation, but the option of having new values would still be valuable in giving a clear and proper name to the cases. For example, the action for the first bullet is equivalent to the action for |url-status=dead; but imho it would be confusing to use the word "dead" for this case merely to elicit the proper action when the url in that case is so clearly not dead, and would confuse citation template users no end. Thanks, Mathglot (talk) 07:06, 11 December 2019 (UTC)[reply]

Isn't this already covered by |url-status=unfit? —David Eppstein (talk) 07:09, 11 December 2019 (UTC)[reply]
Did you read the discussions linked at "here and here" in the first sentence? Mathglot (talk) 07:12, 11 December 2019 (UTC)[reply]
Sure, but I don't see anything there that would make it not fit this case. Although less harmful than being hijacked by malware, I'd say that a blank page still meets the description of "generally inappropriate". And if a url is not working any more, I don't see the point in putting effort into a fine-grained classification of exactly the manner in which it is not working. —David Eppstein (talk) 08:22, 11 December 2019 (UTC)[reply]
As near as I can tell from the wandering path taken by unfit and usurped (see this comment by Trappist above), the actions don't match; but I could be mistaken. Also, the url is working, and it's decidedly not a blank page; it is identifiably the correct page. That's the whole point. Mathglot (talk) 08:35, 11 December 2019 (UTC)[reply]
Pinging @Izno and Mindmatrix: Mathglot (talk) 07:17, 11 December 2019 (UTC) and @Jonesey95, Jc3s5h, and GoingBatty:. updated by Mathglot (talk) 08:15, 11 December 2019 (UTC)[reply]
The document at that URL is functionally broken. It should return a 404 or even a 500 if it were coded properly, so I'd consider it "dead" and it's certainly "unfit". Nemo 11:14, 11 December 2019 (UTC)[reply]
|url-status= has no meaning to cs1|2 without the citation also has |archive-url=. Because what en.wiki cares about is source content, this citation is as good as dead. I was going to suggest that {{failed verification}} might be added to a citation with that url but that template requires at 4 that "the source still contains useful information on the topic". The example url does not meet that requirement. The advice at {{failed verification}} when the source has "no relevance to any part of the article" is to delete the citation and add {{citation needed}}. The url may once have supported the article text (we don't know but WP:AGF, it did). Marking the citation with {{dead link}} will, I think, bring it to the attention of IABot or others which will dutifully find one of the several archived empty snapshots at archive.org, add |archive-url=, delete {{dead link}}. No benefit there.
Perhaps what is needed is not a change to cs1|2 but some sort of new template that occupies the space between {{dead link}} (because the link isn't) and {{failed verification}} (because no "useful information on the topic"). Until a new source can be found, we want to continue to say that once-upon-a-time this article text was sourced but now cannot be verified due to a form of link rot; perhaps: {{content missing}} (surely there is a better name); something that would not cause IABot and friends to add useless blank snapshots but would serve as a flag for editors who might be induced to find a working or archived source as a replacement.
—Trappist the monk (talk) 13:49, 11 December 2019 (UTC)[reply]
Trappist, I like your suggestion, and your comments about the in-between world. And like you, I had also considered various things, including definitely the {{failed verification}} idea, which however didn't seem quite enough all by itself. I like your idea of a new template. And again, I agree that surely there must be a better name; I tried to think of some, and just couldn't come up with a good one yet; I thought about all sorts of things about missing middles, like bagels and donut holes and taxidermy and Mayan sacrifice and 'data eviscerated' but none of those seem serious or appropriate or suggestive enough; and the last few sound ominous. Maybe a new, optional param attached to {{failed verification}}? Although, if we could come up with a good name for the param, then we'd have the name for the new template. The other reason I like your suggestion, is because it avoids having to complicate an already complicated situation here.
I'd like to hear from others, to see what they think. If there is consensus for a new template along the lines of what you suggest, then the CS1 doc for url-status should certainly mention it, so that folks attempting to code a {{citation}} and running into this situation, could be guided to the template, rather than performing contortions with {{citation}} or using improper values of url-status. Mathglot (talk) 22:58, 11 December 2019 (UTC)[reply]
If the link does not verify the citation, and there is no archive link proving otherwise, the link should be removed. Whether such original link at some point did verify the citation is irrelevant. Citations must verify in real time, not at some point in the past or the future. There is no assumption of good faith here: the link either helps to verify the citation or it doesn't. This is not an unfit url, the parameter itself is unfit for inclusion. I remember a fairly extensive discussion on this issue not too long ago. Again, my comments only concern urls without counterparts in reliable archives. 24.105.132.254 (talk) 21:17, 12 December 2019 (UTC)[reply]

Usually called a soft 404. They should be status 404, but the site is poorly maintained, it reports 200 even though the original page no longer exists or works (redirects to homepage is common). They are difficult to detect with automated processes. The best action is treat as dead. -- GreenC 01:30, 13 December 2019 (UTC)[reply]

I've recently ran into a similar situation trying to verify some references from Indian and US newspapers, which only display a message like "we are currently not providing access or use of our website/mobile application to our users in Europe". Probably, this is down to the General Data Protection Regulation (GDPR/DSGVO). I was considering to use |url-status=usurped, but then used |url-access=limited. I agree that a special option like |url-access=regional or |url-access=GDPR-blocked (or something along that line) might be useful. --Matthiaspaul (talk) 23:09, 23 December 2019 (UTC)[reply]
Those are policy blocks. They come and go with arbitrary decree, and are relative to viewer location. What is blocked for one reader is not blocked for another. What is blocked today is unblocked tomorrow. There is no way Wikipedia can maintain that information. BTW these probably should not be set to |url-access=limited which concerns limited for all readers (if we follow the given examples). Wikipedia is not designed to deal with policy blocks, such as Turkey and China. The permutations are endless and constantly changing. -- GreenC 02:19, 24 December 2019 (UTC)[reply]
Not a soft 404. Page still exists at the original location, still contains some of the boilerplate content including correct page title, radio button selections for selecting specific years, and so on. A soft 404 is not that, but typically a server trapping a page, that like you said, no longer exists, and putting up substitute material, such as, "Hmm... that page seems to be missing. Try our site map.." or some such. This is nothing like that. This is the original page, in its proper place, with some of the proper material, but with the guts of the content hollowed out or missing. This doesn't affect the utility or benefit of Trappist's suggestion pro or con; but I don't agree that calling ita dead url is correct, as "dead url" has a specific meaning. This url is still owned by the domain owner, the url is not a soft 404, and the url still presents some data, but not the crucial data required for verifiability. That simply isn't a dead url. In my view, this is closer to an online news article that used to verify an assertion a month ago, but has since been significantly updated, and no longer does, with no archive of the earlier one available. Mathglot (talk) 08:18, 29 December 2019 (UTC)[reply]

date range in cite-web

is it proper to put a range of dates in {{Cite web}} to show that a website has been online for a certain period of time, or is it best to just use a specific date? —Soap— 15:11, 19 December 2019 (UTC)[reply]

Without a specific example, hard to say, but in general, if the page has a specific date (an updated on ... date for example) then use that date; else, don't date and use |access-date= to indicate when you read that page and confirmed that it supported the en.wiki article the uses the citation.
—Trappist the monk (talk) 15:18, 19 December 2019 (UTC)[reply]
Okay thanks for the prompt reply. The specific example I'm thinking of is Taxapad, though there could be many more. Somehow a few days ago I stumbled upon this site, and saw in the header a researcher named Dicky Sick Ki Yu (1997-2015). Yes, the name caught my eye, but so did the date range next to the name. I believed that Mr Yu had been a very bright young man who'd unfortunately passed away at the age of 17 or 18, and that the Bug Guide site was paying their respects. But then I looked him up on the wider Internet and found many references to Taxapad on Wikipedia, which was apparently a site run by Mr Yu. Our references list him with the date range (1997-2012). Realizing that it was implausible for a 14 year old to have done all this research, and presumably much of it when he was even younger than that, I figured that the date range must mean something else. So I looked it up and it seems that we are listing the lifespan of the website, not the researcher. That all makes perfect sense to me now. I'm just worried it might confuse other people, especially for sites that have been online for an even longer period of time.
So my question is, should we change all of the Taxapad references to just say 2012? And then apply the same practice to any other instances of {{cite-web}} that have a date range? I dont know of any, but I suspect there are probably more examples on Wikipedia somewhere. —Soap— 16:20, 19 December 2019 (UTC)[reply]
It is the purpose of citations at en.wiki to identify and help readers locate the source material that supports text in en.wiki articles. Listing the copyright dates of a relatively short-lived website is not of much use. For Taxapad, I think that |date= can be safely deleted because a date range does not identify a particular point in time when information on that website supported an en.wiki article's text. The handful of Taxapad citations that I looked at do not have |access-date= so we don't really know if the archived snapshot supports en.wiki article text. |date=1997-2015 does not help to pin that down.
—Trappist the monk (talk) 17:11, 19 December 2019 (UTC)[reply]
Okay, thank you very much. If our search function is accurate, there are nearly 4000 mentions of Taxapad on Wikipedia, and at least a healthy portion of them have the (1997-2012) text in the date field. So, I cannot do this myself, ... at most I could nibble a bit and get it down to 3800 or so. I will try to see if it can be automated through AWB or some other tool. I suspect, though, it may be low priority because the text as it stands now is not actually wrong. In either case, thank you for your helpful answer. —Soap— 01:14, 20 December 2019 (UTC)[reply]
If that date range 1997-2015 is really defining the time this site was online, and if it would be important to indicate the first time the information was available there, a combination of|date=2015 and |orig-year=1997 could be used to indicate this. However, the problem is that it may be difficult now (in 2019) to determine if some specific supporting statement was already online in 1997 (or in some other year before 2015) already under the given link, unless you can find this in archived snapshots. --Matthiaspaul (talk) 06:45, 20 December 2019 (UTC)[reply]

Cite journal disallows pages and page params together

I recently added a citation which I wanted to include both a page range, because it's a journal article, and a page, to point to a particular portion of the article, but it has a CS1 error. (diff) Maybe this should be allowed for cite journal? Cheers, Mvolz (talk) 10:59, 23 December 2019 (UTC)[reply]

You can use template {{Rp}} to indicate the particular page.   Jts1882 | talk  11:12, 23 December 2019 (UTC)[reply]
The in-source location for {{cite journal}} is usually an article, and such locations should be indicated with a page range (an older, much rarer practice cited the first page only). Since articles were historically short, this was deemed acceptable. Adding a second-level location probably overcomplicates things. I would add a shortened reference ({{sfn}}) with its own location to the specific page. Or, a note outside the full reference. 100.33.37.109 (talk) 14:50, 23 December 2019 (UTC)[reply]
Or something like |pages=98–109 [101]. Headbomb {t · c · p · b} 17:49, 23 December 2019 (UTC)[reply]
I like this notation. I've also seen |pages=98–109 (101). Not being aware that pages accepts free-flow input, personally I have used |pages=98–109, 101 hoping that readers would "get it" that there must be something important with page 101, and editors would not remove it as redundant. However, for consistency it would be better to have a well-defined and documented way to handle cases like this (with or without extra parameter). --Matthiaspaul (talk) 22:35, 23 December 2019 (UTC)[reply]

ampersands and Vancouver-style name lists

Vancouver style does not support the use of an ampersand between the last two author names in a name list so I have tweaked the module to ignore |last-author-amp= when used with |vauthors=:

Cite journal comparison
Wikitext {{cite journal|journal=Journal|last-author-amp=yes|title=Title|vauthors=Red R, Brown B, Green G}}
Live Red R, Brown B, Green G. "Title". Journal. {{cite journal}}: Unknown parameter |last-author-amp= ignored (|name-list-style= suggested) (help)
Sandbox Red R, Brown B, Green G. "Title". Journal. {{cite journal}}: Unknown parameter |last-author-amp= ignored (|name-list-style= suggested) (help)

—Trappist the monk (talk) 16:25, 23 December 2019 (UTC)[reply]

Small bug with Cite web and Visual editor

When using the Cite function to add a URL in the VisualEditor, the |subscription= parameter is still available even though it has been deprecated. - Samuel Wiki (talk) 16:05, 26 December 2019 (UTC)[reply]

Deprecated does not mean unsupported; |subscription= and |registration= are still valid supported parameters. Likely these two parameters will become unsupported at the next module-suite update.
—Trappist the monk (talk) 16:11, 26 December 2019 (UTC)[reply]
I figured out it was coming from TemplateData and set the parameters to deprecated status. - Samuel Wiki (talk) 16:44, 26 December 2019 (UTC)[reply]
There is a problem with the edit that you made. {{cite web}} does not support |chapter= or |cite entry= so template data should not recommend replacement of |subscription= and |registration= with |chapter-url-access= and |entry-url-access=. You might want to fix that.
—Trappist the monk (talk) 16:52, 26 December 2019 (UTC)[reply]
Fixed. - Samuel Wiki (talk) 17:25, 26 December 2019 (UTC)[reply]

When is url-status=unfit to be used?

I do not understand when url-status should be set to unfit. What is this setting for? The documentation doesn't seem to say what cases it is supposed to be used in. Thanks! DemonDays64 (talk) 00:46, 28 December 2019 (UTC)[reply]

Achieving clarity on that question has eluded us. See Help talk:Citation Style 1 § spam black list and archive urls (currently at the top of this page so likely soon to be archived). There is some history there.
—Trappist the monk (talk) 01:07, 28 December 2019 (UTC)[reply]

The classic use case is when a domain has expired and hijacked by spammers, malware or porn sites. We don't want those links displayed. They are no longer "fit" for Wikipedia. -- GreenC 01:56, 28 December 2019 (UTC)[reply]

  • I would think that ought to be url-status-=usurped A distinction without much difference in effect. And there is the related use case: The site is still valid, and is not porn or anything, but the content at the specified url has been changed so that it no longer supports the statement it is being cited for. This could use url-access=unfit, in that it is no longer fit for Wikipedia's purposes. Personally, I would like to see support for url-access=changed (or perhaps "altered") for this specific use case, but I can't say that doing so is vital. DES (talk)DESiegel Contribs 19:25, 30 December 2019 (UTC)[reply]

template-doc-demo should be a bad parameter in the mainspace

I was about to recommend the use of |template-doc-demo= for another user but it turns out that I had a faulty assumption in mind: It currently disables error categorization in the mainspace. I do not believe that is the intent of the parameter and do believe that placement in the mainspace should cause the parameter to be disabled (or emit its own error message). --Izno (talk) 23:08, 28 December 2019 (UTC)[reply]

At the moment, it appears that it is used in one place in article space (Paleocene, in case the search link no longer works) because that article contains a valid DOI ending in a period (full stop), which the module currently flags as an error. If we are to flag this usage somehow, I recommend a CS1 maintenance category for uses of |template-doc-demo= in article space, for situations like this where the module has not yet been updated and a red error message should not be displayed. – Jonesey95 (talk) 01:20, 29 December 2019 (UTC)[reply]
Such cases should probably use a wikitext comment to explain why the parameter throws an error (for the time being). I would certainly prefer an error; we have too many hidden maintenance messages as is. Maintenance messages should be reserved for when a page should be checked-in-on rather than obviously fixed (as with our ISBN-ignored category). --Izno (talk) 02:25, 29 December 2019 (UTC)[reply]
If the functionality of |template-doc-demo= is do as its name indicates, then it certainly should not be used in article-space. If its aliases |no-cat=, |nocat=, |no-tracking=, and |notracking= are indicators then perhaps it could be used in article-space. The parameter's documentation is not a stellar example of clarity or, more importantly, accuracy:
template-doc-demo: The archive parameters will be error-checked to ensure that all the required parameters are included, or else {{citation error}} is invoked. With errors, main, help and template pages are placed into one of the subcategories of Category:Articles with incorrect citation syntax. Set |template-doc-demo=true to disable categorization; mainly used for documentation where the error is demonstrated. Alias: no-cat.
cs1|2 does not invoke {{citation error}} nor does it use Category:Articles with incorrect citation syntax (it once did via {{citation/core}}). The first two sentences of the |template-doc-demo= documentation should go away.
The point about the 'unique' doi with required terminal punctuation seems to me to be a different sort of thing. That is a case where we want to suppress the error message and the category. For other parameters we have provided the doubled parentheses markup to tell cs1|2 that it is to accept this value as written. At some point, perhaps we will come to the decision that any parameter value that can cause cs1|2 to emit an error message should allow the accept-this-value-as-written markup. Then, |template-doc-demo= and aliases will be disabled in article-space and |ignore-isbn-error= goes away.
—Trappist the monk (talk) 14:45, 29 December 2019 (UTC)[reply]

DOI prefix errors

A quarry query reveals a few things. Namely

  • Citations with DOI prefixes that have 10.#, where # is not 4 or 5 digits should be reported as errors.
  • Citations with DOI prefixes that range from 10.0001 to 10.0999 should be reported as errors.
  • Citations with DOI prefixes that range from 10.00001 to 10.09999 should be reported as errors.
  • Citations with DOI prefixes that are over 10.40000 should be reported as errors.

Headbomb {t · c · p · b} 18:03, 29 December 2019 (UTC)[reply]

This is about the registrant code portion of a doi. If I understand §2.2.2 DOI prefix, nothing constrains the composition of doi prefix registrant codes. Have doi.org published someplace, anyplace, a list of valid registrant codes?
—Trappist the monk (talk) 18:43, 29 December 2019 (UTC);;[reply]
Technically, nothing restraints that. In practice, those have never been assigned. Theses checks should also be implemented in {{doi}}, with a error 'invalid registrant' or shove em in the existing categories of invalid dois. And DOI.org have never published a list of registrant, sadly. I've been in contact with them about it, and they leave that to DOI assigning agencies like CrossRef and Datacite. Headbomb {t · c · p · b} 20:37, 29 December 2019 (UTC)[reply]
~/Identifiers/sandbox tweaked. All of these emit the doi error message except the first four:
—Trappist the monk (talk) 16:55, 30 December 2019 (UTC)[reply]
Highest legit registrant I was able to find was 10.36931 [1]. I don't know how high they go, but none have crossed 10.40000 yet. Headbomb {t · c · p · b} 17:00, 30 December 2019 (UTC)[reply]
"Test to see that we haven't impacted something on the other side of the slash". Journal. doi:10.3109/15563650.2010.492350. --Izno (talk) 17:58, 30 December 2019 (UTC)[reply]
@Trappist the monk: seems I've overlooked a special case: {{doi}} is a legit DOI apparently. So 3 digits after 10. in the doi prefix structure 10.d.d, but not in 10.d. Headbomb {t · c · p · b} 14:17, 11 January 2020 (UTC)[reply]
Yeah, I saw that:
{{cite book |last=Metzinger |first=Thomas |year=2013 |title=Spirituality and Intellectual Honesty: An Essay |publisher=Self-Published |isbn=978-3-00-041539-5 |doi=10.978.300/0415395}}
Metzinger, Thomas (2013). Spirituality and Intellectual Honesty: An Essay. Self-Published. doi:10.978.300/0415395. ISBN 978-3-00-041539-5.
I'm not clear about what you mean by 10.d.d, but not in 10.d is each d three digits so, as regex, 10\.\d\d\d\.\d\d\d, but not in 10\.\d\d\d?
—Trappist the monk (talk) 14:23, 11 January 2020 (UTC)[reply]
@Headbomb: Because of this pending update, if you can clarify the question above before I make the update, any necessary fixes can be applied at the same time.
—Trappist the monk (talk) 17:27, 13 January 2020 (UTC)[reply]
I just mean that dois should start with 10.#/... or 10.#/... with the restrictions that # is 4 or 5 digits, ranging from 1000 to 40000. And if you have a 10.#.#/... then it seems those restrictions don't apply, or that 978 is a special case. Headbomb {t · c · p · b} 17:37, 13 January 2020 (UTC)[reply]

Module:Citation/CS1/Identifiers function doi() updated.

—Trappist the monk (talk) 14:33, 18 January 2020 (UTC)[reply]

deprecated parameters

I have removed support for the last few remaining deprecated parameters: |ASIN-TLD=, |class= (still supported by {{cite arxiv}}), |registration=, and |subscription=.

—Trappist the monk (talk) 18:41, 30 December 2019 (UTC)[reply]

Request for new url-access value(s)

I encounter a number of cited sources, particularly in medical refs cited via PMID, but in various other contexts as well, where a part of the source is made free for anyone to see (often a abstract for scholarly papers, or the first 2-3 paragraphs for a newspaper), but the full text is behind a paywall. Sometiems the visible part is all that is needed to support whatever content it is cited for, sometimes the paywalled part is needed. In any case it seems to me that we need a new value supported for |url-access=. "subscription" is not right, because a significant part of the source is visible without a subscription. Would url-access=partial work? Do we want to try to have different values depending on whether the part of the source being used is hidden or not? DES (talk)DESiegel Contribs 19:35, 30 December 2019 (UTC)[reply]

|url-access=limited works here IMO. --Izno (talk) 21:25, 30 December 2019 (UTC)[reply]
Nothing is needed, since a PMID url will be redundant to the identifiers and should be removed. If the source is paywalled behind a url that isn't redundant to identifiers, then |url-access=subscription is the one. It doesn't matter than an excerpt is freely available, what matters is the full source. Headbomb {t · c · p · b} 22:41, 30 December 2019 (UTC)[reply]
I must disagree. If the abstract or a relevant except is publicly visible, that may well be enough to verify the statement nin nthe article, and if it is, a reader who might otherwise have noticed the subscription needed icon and ignored the cite could usefully verify. This is true whatever url is being used, if it is paywalled but with a significant excerpt public, in my view. thr value limited is batter than nothing, but a more specific value would be a good idea, I think. DES (talk)DESiegel Contribs 01:09, 2 January 2020 (UTC)[reply]
Agreed with the use of |url-access=limited when an excerpt/abstract is available. "Limited" includes "partial" (among other cases), and is good enough. Proliferation of parameter options to cover every single case (or class of cases) that appears should imo be avoided. 72.43.99.138 (talk) 16:04, 2 January 2020 (UTC)[reply]
Limited is not ok. If you need to point out that you're citing the abstract specifically, then have |at=Abstract, or "See abstract in {{cite xxx}}". Abstracts are always free, so there's no need to point out that the abstract is free while the rest of the article isn't. Headbomb {t · c · p · b} 17:30, 2 January 2020 (UTC)[reply]
Yes, abstracts are free. And it seems they can be mostly found at the article url, although abstracts are similar to reliable annotations, and not technically a part of the article. So we can have a situation with two access variables "at this url there is 1. free access to a source abstract 2. paywalled access to the source" or with one "at this url there is limited access to the source". The second option is not perfect. But it is simple, and it does the job, since it covers the particular case. And if the abstract fully supports the wikitext, then access to proof is free, and no signaling is required. As a reader verifying the wikitext, I would have no need to venture into the article further. 24.105.132.254 (talk) 21:45, 2 January 2020 (UTC)[reply]
Abstracts are "official" summaries, at least in the context we are discussing presently, I think. What you are referring to would be an extract, or non-extant part. I still think that "limited" is a correct url option for it. 72.43.99.138 (talk) 15:07, 3 January 2020 (UTC)[reply]
It is not. |xxx-access= is to describe what restrictions on accessing the full source. For instance, a source that requires free registration to read is limited access. Or a source that you can read 10 times before having to pay for is limited access. A free blurb is irrelevant to this. All blurbs are free. Headbomb {t · c · p · b} 15:35, 3 January 2020 (UTC)[reply]
A site that has a requirement for free registration should use url-access=registration, this is the specific use case for that value. X articles or X articles per month is definitely "limited", that is the suggested use case for that value, but perhaps not the only use case. DES (talk)DESiegel Contribs 16:08, 3 January 2020 (UTC)[reply]
Right, same icon though. Headbomb {t · c · p · b} 17:30, 3 January 2020 (UTC)[reply]

Update to the live CS1 module weekend of 11–12 January 2020

I propose to update the cs1|2 module suite on the weekend of 11–12 January 2020.

Module:Citation/CS1

  • fix archive static text case; discussion
  • removed support for |dead-url= and |deadurl=;
  • add support for |script-map=; discussion
  • i18n support for limited parameter values; discussion
    • examples in the discussion are now broken because non-English keywords have been removed from the sandbox pending this update
    • discussion on my talk page now archived
  • support categorization when |language=<local language>; discussion
  • tweak to support IETF lang codes related to harmonization with Module:Lang; discussion
  • fix |script-title= error report bug when used in {{cite encyclopedia}}; discussion
  • support three-char codes for |script-param=; discussion
  • add prop cat to evaluate 2-location-param use in article space; discussion
  • no ampersands in vanc-style namelists; discussion
  • removed support for |ASIN-TLD=, |class=, |registration=, |subscription=; discussion

Module:Citation/CS1/Configuration

  • change deprecated errors back to visible for next release; discussion
  • fix archive static text case
  • remove laysummary, dead-url per previous deprecation
  • add support for |script-map=;
  • i18n support for limited parameter values;
  • support categorization when |language=<local language>;
  • tweak to support IETF lang codes related to harmonization with Module:Lang;
  • add script-lang code: bo, ota, dz;
  • add prop cat to evaluate 2-location-param use in article space;
  • update pmid url; see Help_talk:Citation_Style_1#PMID:_updated_PubMed_website,_URL_scheme
  • removed support for |ASIN-TLD=, |class=, |registration=, |subscription=;

Module:Citation/CS1/Whitelist

  • remove laysummary, dead-url per previous deprecation
  • add support for |script-map=;
  • removed support for |ASIN-TLD=, |class=, |registration=, |subscription=;

Module:Citation/CS1/Date validation

  • i18n fix for |year= with non-Latin script; discussion

Module:Citation/CS1/Identifiers

  • i18n support for limited parameter values;
  • use this_wiki_code from ~/Configuration;
  • emit isbn error when 9790...; discussion
  • enhance doi registrant code validation; discussion

Module:Citation/CS1/Utilities

  • fixed improper removal of pipe character | from plain text title; discussion

—Trappist the monk (talk) 15:40, 4 January 2020 (UTC)[reply]

Don't see anything controversial here. Just want to comment on
add prop cat to evaluate 2-location-param use in article space; discussion
It seems to me there is some consensus into making all location parameters aliases of [publisher] |location=. 108.182.15.109 (talk) 16:34, 4 January 2020 (UTC)[reply]
By my reading, there was a consensus to implement a tracking category so that we could see whether making the location parameters aliases of one another was feasible. That tracking category will be populated after the update. – Jonesey95 (talk) 17:04, 4 January 2020 (UTC)[reply]

Cite arxiv displaying "ignored" parameters

There is something weird in the current {{cite arxiv}} code that is causing the following to display an "ignored" error... while also displaying the parameter which is supposedly ignored (I noticed on my random trawl through the archives). See here where |publisher=Publisher is displayed, as is |accessdate=:

Cite arXiv comparison
Wikitext {{cite arXiv|accessdate=3 March 2014|arxiv=0711.2260|class=quant-ph|date=2002|first=Elio|journal=Proceedings Fundamental problems of Sciences, 271-304, S. Petersburg 2002|last=Conte|pages=271-304|publisher=Publisher|title=A Quantum Like Interpretation and Solution of Einstein, Podolsky, and Rosen Paradox in Quantum Mechanics|url=https://arxiv.org/abs/0711.2260v1}}
Live Conte, Elio (2002). "A Quantum Like Interpretation and Solution of Einstein, Podolsky, and Rosen Paradox in Quantum Mechanics". pp. 271–304. arXiv:0711.2260 [quant-ph]. {{cite arXiv}}: Unknown parameter |accessdate= ignored (help); Unknown parameter |journal= ignored (help); Unknown parameter |publisher= ignored (help)
Sandbox Conte, Elio (2002). "A Quantum Like Interpretation and Solution of Einstein, Podolsky, and Rosen Paradox in Quantum Mechanics". pp. 271–304. arXiv:0711.2260 [quant-ph]. {{cite arXiv}}: Unknown parameter |accessdate= ignored (help); Unknown parameter |journal= ignored (help); Unknown parameter |publisher= ignored (help)

--Izno (talk) 03:24, 8 January 2020 (UTC)[reply]

That is how it is supposed to be. What you are really citing here is a journal, so use {{cite journal}}; {{cite arxiv}} is a pre-print citation template that supports only those parameters that are relevant to a pre-print. {{cite biorxiv}}, {{cite citeseerx}}, and {{cite ssrn}} are similar.
—Trappist the monk (talk) 03:51, 8 January 2020 (UTC)[reply]
I think Izno is pointing out that the error message says that two parameters are being ignored, but the parameter values are being displayed. I don't think both things can be true at the same time (although perhaps I haven't achieved a sufficient level of enlightenment). – Jonesey95 (talk) 05:03, 8 January 2020 (UTC)[reply]
You are the truly enlightened for understanding my bug report. ;) --Izno (talk) 06:36, 8 January 2020 (UTC)[reply]
No one has ever claimed that I am a member of the enlightened clan ... I have been rightly accused of leaping to incorrect conclusions because I failed to completely read the whole damn message before replying. Yep, I'm old enough to know better ...
The pre-print templates are rendered using the same code as is used for the periodical templates. Most of the parameters allowed in periodical templates are unset because they aren't listed in the limited-parameter lists used by the pre-print templates. |access-date= and |publisher= are valid for use in periodical templates but not valid for use in the pre-print templates. But, |access-date= and |publisher= escaped that 'unsetting' because they matched the patterns we have in Module:Citation/CS1/Suggestions. The code for that emitted the error messages but left the parameters intact so they were rendered by the periodical rendering code in the citation along with the error message.
—Trappist the monk (talk) 13:17, 8 January 2020 (UTC)[reply]
Publisher should also be ignored. Headbomb {t · c · p · b} 16:28, 8 January 2020 (UTC)[reply]
In the sandbox it is, isn't it? Are you seeing something that I'm missing?
—Trappist the monk (talk) 16:32, 8 January 2020 (UTC)[reply]
It looks to me like this bug has been fixed in the sandbox. Now I might be the blind one; was it fixed before or after this conversation was started? – Jonesey95 (talk) 01:39, 9 January 2020 (UTC)[reply]
After, at just about 12:54 UTC today. --Izno (talk) 02:39, 9 January 2020 (UTC)[reply]

Hi, I encountered a small glitch using {{cite web}}{{cite book}}:

Using one of the |author-link= etc. parameters, the link will be automatically suppressed when the citation is used on the page linked to by |author-link=. This is convenient when copying citations between articles, and also helps maintenance when articles get renamed.

I thought the same feature would be available for |title-link=, but it isn't. If this is used on the target page, the link isn't suppressed and consequently is shown in boldface, which looks odd. I think we should add the same auto-suppression to |title-link= as well.

There is a related feature which would be neat to have: If one of the |*-link= parameters points to a redirect rather than an article, it should be followed and the link should be suppressed if the template happens to be invoked from the redirect's target page as well. This would not only help keeping the link suppression feature work when renaming pages, but also would allow to deliberately go through redirects in order to reduce future maintenance.

It would be great if this could be fixed and implemented. --Matthiaspaul (talk) 01:40, 10 January 2020 (UTC)[reply]

Umm, {{cite web}} doesn't support|title-link=:
{{cite web |title=Example |url=//example.com |title-link=Example |website=Example}}
"Example". Example. {{cite web}}: URL–wikilink conflict (help)
Still, for templates that do support |title-link= and do not also have a conflicting |url=, we should probably mute the self-link. I'll attend to that after the pending update.
I do not think that we will follow redirects. To do that, it is necessary to fetch information about the target page from the database; that is an expensive operation when the target page is not the current page.
—Trappist the monk (talk) 12:23, 10 January 2020 (UTC)[reply]
That's right, I encountered this using {{cite book}} rather than {{cite web}}. Thanks for correcting me.
I think this "self-link muting feature" should be a general property of all |*-link= parameters everywhere. It seems to work for the family of |author*=, |editor*=, |translator*= and |contributor*= parameters (but I haven't tried all variants), that's why I thought it would be something generic already, but apparently it is not. Are there other parameters for which a |*-link= parameter exists?
Yeah, I was afraid following redirects could be expensive, but still it would be convenient... Assuming it would not actually harm on most pages with only a few references on them, perhaps there could be something like a counter, resolving redirects up to 100 times (or whatever is considered expensive at a time given) per page invocation and then ignoring them - after all it would be just a display convenience feature, not core functionality on which users of the templates should be able to rely on. So it would work on most pages, but still with a guaranteed upper limit for stability. Just some food for thought...
Thanks anyway...
--Matthiaspaul (talk) 21:10, 10 January 2020 (UTC)[reply]
The link parameters are the name-list parameters: |author-link=, |contributor-link=, |editor-link=, |interviewer-link=, |subject-link=, and |translator-link=; and two 'title' parameters: |episode-link= and |series-link= which are aliases of the last parameter |title-link=. The name-list parameters already mute self-links and the title parameters will in a future update.
MediaWiki already resolves redirects, it does it all the time, I'm content to let it continue to do that without adding to the complexity of cs1|2.
—Trappist the monk (talk) 23:11, 10 January 2020 (UTC)[reply]
Sounds very good to me, thanks.
Would it make sense to add this to |work= and aliases as well?
--Matthiaspaul (talk) 00:12, 11 January 2020 (UTC)[reply]
I just saw that there was a related discussion at Module talk:Citation/CS1/Feature_requests#Check for wikilink to current page (although I would not have consider this to belong into CSS). --Matthiaspaul (talk) 21:25, 10 January 2020 (UTC)[reply]
When any of the name-list parameters link to the current page, Module:Citation/CS1 simply does not create a link to the current page in that template's rendering. The solution did not involve css. At the time, a css solution would have required a change to Wikipedia-wide css; with the advent of WP:TemplateStyles that requirement is, I think, lifted. Does that mean that we should apply a css solution instead of the don't-link-to-current-page solution? Don't know.
—Trappist the monk (talk) 23:11, 10 January 2020 (UTC)[reply]
I am with you here. I consider this to be functionality that should be part of the template rather than display cosmetics only, therefore I would have put it into the templates' code as well rather than trying to address it with CSS.
--Matthiaspaul (talk) 00:12, 11 January 2020 (UTC)[reply]

Problem with "." separator in front of work or series info in conjunction with titles ending on "?" or "!"

Using {{cite web}}, if the |title= ends on "?" or "!" and either |work= or |series= is used and the separator is set to the default ".", the rendered output looks odd as the "?" or "!" is immediately followed by a ".". This does not happen when the |title= ends on "." because a trailing "." is automatically removed. Since the "?" or "!" cannot reasonably be removed from a title, the "." preceding either |work= or |series= should be suppressed instead. --Matthiaspaul (talk) 02:48, 10 January 2020 (UTC)[reply]

Examples:
Cite web comparison
Wikitext {{cite web|title=Title?|url=http://www.example.com|work=Website}}
Live "Title?". Website.
Sandbox "Title?". Website.
Cite web comparison
Wikitext {{cite web|title=Title.|url=http://www.example.com|work=Website}}
Live "Title". Website.
Sandbox "Title". Website.
Suggestions? – Jonesey95 (talk) 03:31, 10 January 2020 (UTC)[reply]
This is on the feature request list; see Module talk:Citation/CS1/Feature requests § Separator suppression.
—Trappist the monk (talk) 12:32, 10 January 2020 (UTC)[reply]

Problem with journals, magazines (and books) using all three parameters: volume, issue and number

As discussed before there are journals, magazines (and even books) which define values for |volume=, |issue= and |number= - for example Dr. Dobbs Journal, Minolta-Spiegel etc.

Right now, the usage of the |issue= and |number= parameters is mutually exclusive and will create an error message. Putting the |number= value into another parameter like |id= is an unsatisfactory solution given that we already have a suitably named parameter for this. Also, this makes the number look out of place in the output.

I understand that issuing an error message is a safety measure so that people don't accidently add one of the two parameters overlooking the other, but I wonder if this is really a frequent problem.

If not, I suggest to simply allow either or both of these parameters to be used at the same time. If both are used, |issue= should be displayed following |volume=, followed by the |number= as follows:

<volume> (<issue>) #<number>

or

Vol. <volume> no. <issue> #<number>

If only one of the parameters is given, the display should be as follows (for journals):

<volume> (<issue>)
<volume> (<number>)

or (for magazines):

Vol. <volume> no. <issue>
Vol. <volume> no. <number>

If, however, the error condition is a frequent problem that needs to be catched by default, I suggest to add at least some means to override this error message, like putting the |number= value in (()) in order to let the template accept it.

Assuming that there is only one "issue number" placeholder to be filled in metadata I'm open in regard to what value(s) should be passed on if both are given: It would be possible to only pass on |issue= or to concat both parameters into one string like "<issue> #<number>" before passing it on. It would also be possible to make this selectable on (()) being used on either or both of |issue= and |number=.

--Matthiaspaul (talk) 03:22, 10 January 2020 (UTC)[reply]

Personally, I'd prefer |num-issue=yes and |issue-num=yes to set the order and declare that both are actually relevant. See also this. Headbomb {t · c · p · b} 05:16, 10 January 2020 (UTC)[reply]
I'm open for suggestions. Whatever helps to finally get the underlying problem addressed and resolved.
BTW, I just found an older discussion Help talk:Citation Style 1/Archive 29#Cite journal causes error for journals with given issue and number numbers.
Beyond the original proposal, if we have both, |issue= and |number= values, perhaps the template output should be given some more thought to remain as close to established rules for formatting as possible:
To me (and in the case of "Dr. Dobbs Journal" and "Minolta-Spiegel"), issue is the value considered relative to volume, and number is an absolute number, but for "Aeroplane Monthly" (in the other thread) the meaning appears to be swapped: Vol. 44, No 12, Issue no 524.
Conceptually, both values are numeric to me, but if not, I would consider |number= to contain a number, but perhaps prefixed like "number 524". This could also apply to |issue=, like in "issue 4", but it could also contain a text-only value like "summer issue", "special issue" etc.
Therefore, as a refinement to the above proposal, the above suggested output rendering
<volume> (<issue>) #<number>
or
Vol. <volume> no. <issue> #<number>
appears reasonable only if both values are all-numeric.
Given the interchangeability of the two parameters, in this all-numeric case, the one with the smaller number should be considered to be relative to the volume, that is, it should be listed first. Otherwise the values are swapped so that the larger value is always the one listed last (and with the # mark), as follows:
<volume> (<number>) #<issue>
or
Vol. <volume> no. <number> #<issue>
If only one of the parameters carries a non-numeric value, and further assuming that the generic template rendering "V (X)" or "Vol. V no. X" should remain unchanged, the numeric value should be the one immediately following the volume (for backward compatibility). Example (with volume containing 5, one of the other parameter contains "6", the other "summer"):
5 (6) summer
or
Vol. 5 no. 6 (summer)
An example assuming one parameter would contain "6", the other "summer issue":
5 (6) summer issue
or
Vol. 5 no. 6 (summer issue)
Yet another example assuming one parameter would contain "6", the other "number 524":
5 (6) number 524
or
Vol. 5 no. 6 (number 524)
If both parameters carry non-numerical values, the order should again be "issue followed by number" (to preserve the nominal default order as with both values being all-numeric):
<volume> (<issue>) <number>
or
Vol. <volume> no. <issue> (<number>)
Since non-numerical values cannot (easily) be evaluated and compared, there is no swapping. It is up for the user (and documentation) to assign suitable text values to these parameters for this rendering. The only visual difference compared to the all-numerical case would be that in the non-numerical case, the # is missing in front of the number.
Well, perhaps if we would drop the proposed # from the second value in the all-numerical case as well, the output would look exactly the same for all cases. This would be more consistent and easier for documentation. Still, whatever the values put into these parameters, the output would be reasonable formatted in a way that the values can be distinguished from another.
--Matthiaspaul (talk) 22:59, 10 January 2020 (UTC)[reply]

Undesired silent suppression of some parameters by cite book and cite web templates

The {{cite book}} and {{cite web}} templates silently ignore the |issue= and |number= parameters, if they are specified. Additionally, {{cite web}} ignores the |volume= parameter. There might be more such cases, but these are the ones I run into quite frequently in articles.

In general, I don't think it is a good idea to suppress information provided. The contributing editor probably had a reason to add this information in the first place. Also, as has been discussed earlier, there are books which have volume, issue and number values assigned to them, hence this info should be displayed.

I don't know if {{cite journal}}, {{cite magazine}} etc. silently suppress some other parameters as well, but if not, {{cite book}} and {{cite web}} should display some message suggesting to switch to {{cite journal}} or {{cite magazine}} if unsupported parameters are used. (Not sure, if this should be an error message, a maintenance message or a message only displayed in edit mode.)

Additionally, these citations should be put into some maintenance category so that they can be reviewed and reworked to use more suitable templates.

--Matthiaspaul (talk) 04:58, 10 January 2020 (UTC)[reply]

Is there something in the documentation for {{cite web}} that makes you think |issue= and |number= are supported parameters? All I see is {cite news} accepts |issue= and |volume= parameters while {cite web} does not. Template documentation is supposed to list all supported parameters, and editors should not expect that other parameters will work.
The {{cite book}} documentation appears to be incorrect, in that it lists |issue= as a supported parameter. I will fix it. If this discussion results in that parameter gaining support, my edits can be reverted. – Jonesey95 (talk) 15:28, 10 January 2020 (UTC)[reply]
Yeah, documentation is not always correct, complete, or up to date. But even if it would, an editor's capabilities to keep memorized all the available and ever changing parameters (and their dependencies) for each of the many cite variants are limited.
The templates do not "passively" ignore these parameters (completely unknown parameters like typos throw an error message), but silently "suppress" them, still knowing that they are used in other cite template variants.
IIRC at some point in the past, before all the diversification started and these error checks were introduced to the citation framework, either {{cite web}} or {{cite book}} still supported these parameters, but anyway, cleaning up citations I sometimes run into these parameters (and I am "guilty" myself as well having added missing issue number information to journal citations, not realizing that {{cite web}} was used by prior editors instead of {{cite journal}}).
With all these new dependencies now throwing error messages, perhaps some users are just switching the cite templates until they get rid of the error messages (for example with a missing |journal= in {{cite journal}}, a user might be tempted to switch to {{cite web}}), not realizing that some of the other parameters will be ignored then. This is easy to miss, in particular if editing "foreign" citations.
My point is, all combinations, which exist in the real world, should be supported, and all other combinations should at least give some form of hint (if not throw an error) so that someone knowledgeable can look at the citation and change it to a better variant (instead of just ignoring the information or even removing it because it does not fit into someone's personal concept).
--Matthiaspaul (talk) 23:46, 10 January 2020 (UTC)[reply]

Cite web discussion over at MoS:Film

Seems a {{Cite web}} discussion has creeped its way to Wikipedia talk:Manual of Style/Film#We should not be italicizing RT, MC and BOM. Interested parties are welcomed. --Gonnym (talk) 09:40, 10 January 2020 (UTC)[reply]

|year= fails with non-Latin script

Cite book comparison
Wikitext {{cite book|first=سيد يوسف|last=شاه|location=لاھور|pages=١٦٠-١٦١|publisher=محمدی پریس|title=حالات مشوانی|year=١٩٣٠}}
Live شاه, سيد يوسف (١٩٣٠). حالات مشوانی. لاھور: محمدی پریس. pp. ١٦٠-١٦١. {{cite book}}: Check date values in: |year= (help)
Sandbox شاه, سيد يوسف (١٩٣٠). حالات مشوانی. لاھور: محمدی پریس. pp. ١٦٠-١٦١. {{cite book}}: Check date values in: |year= (help)

~/Date validation recognizes the Arabic digits as digit characters, but Lua's tonumber() function only works with Latin characters. Fixed in the sandbox. Because this is a lua script error, I will likely update ~/Date validation within the next week.

—Trappist the monk (talk) 17:24, 13 January 2020 (UTC)[reply]

Module:Citation/CS1/Date validation updated.

—Trappist the monk (talk) 14:35, 18 January 2020 (UTC)[reply]

Some SSRN documents now require payment

The parameter ssrn= automatically displays the green free access lock, which is almost always a good thing (apparently this feature was added in 2016 - see SSRN free access lock in this talk page's archives). I discovered today that SSRN hosts a few papers that require payment, such as an NBER Working Paper I cited today (that's a wikilink to the footnote). ¶ Therefore, it seems we will (eventually) need a method to indicate that an SSRN paper is not free. (I tried ssrn-access=subscription but that parameter doesn't exist.) I don't see this as a top priority—I simply wanted to bring it to the attention of folks who know how address little problems like this one. My solution today was to just leave out the SSRN link as interested readers will find it on the NBER page for the paper anyway. Thanks! - Mark ¶ P.S. My apologies if this is old news. I did search the archives but didn't find anything.   - Mark D Worthen PsyD (talk) (I'm a man—traditional male pronouns are fine.) 04:47, 15 January 2020 (UTC)[reply]

This is surprising, SSRN has committed to remain a free open access repository since being acquired by Elsevier. I'll be writing them to see what's what. Headbomb {t · c · p · b} 17:05, 15 January 2020 (UTC)[reply]
The free access is provided for Elsevier rather than for any users. See "License to Elevier" at https://www.ssrn.com/index.cfm/en/terms-of-use/ . Elsevier charge fees because "we believe that offering the broadest array of content provides the most value to our users". See "10. What is the charge for using the SSRN eLibrary?" at https://www.ssrn.com/index.cfm/en/ssrn-faq/#elec_lib_charge . Thincat (talk) 08:38, 16 January 2020 (UTC)[reply]

How to indicate that a web page has had its content replaced

A web page's content is replaced monthly; if I cite a specific version, from a previous month, complete with an archive URL, what value should I use for |url-status? It's not "dead", nor is it "usurped", but neither does it display the cited content. Do we need a new value, say, "replaced"? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:09, 15 January 2020 (UTC)[reply]

Ah, this discussion again...
See Help talk:Citation Style 1 § spam black list and archive urls and preceding discussions linked from there. Apparently we don't know the answer to this question, or if we do, this editor is not clever enough to decode the answer from the discussions.
—Trappist the monk (talk) 16:13, 15 January 2020 (UTC)[reply]
If this is a FAQ, perhaps you could dial down the sarcasm, and instead add it as such in the template's documentation, which I had the courtesy to check before asking here? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:28, 15 January 2020 (UTC)[reply]
I don't really see how this case differs from citing the front page of any major news organization (for whatever reason) as the content is still provided at the archive URL (if you really want to make a point of when it was relevant, add an accessdate). |url-status=live IMO. --Izno (talk) 16:17, 15 January 2020 (UTC)[reply]
It probably isn't; but then I'm more likely to cite - and to teach others to cite - a specific news page. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:28, 15 January 2020 (UTC)[reply]
Per your OP, you want to cite a previous, archived version. If the archive is by the same publisher, you add the original url and the archive url, plus the indication that the original is no longer live. Including the access dates. If the archive is by a different publisher, you are no longer citing the original source. You are citing an archive. If it is online, use {{cite web}}. If not online, use {{citation}}. 71.247.146.98 (talk) 02:47, 16 January 2020 (UTC)[reply]
"you are no longer citing the original source" Not so; I can cite a version I saw before it was changed; and perhaps one that I have in a local copy. I might also be fixing up links from citations made when the version cited was live. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:20, 16 January 2020 (UTC)[reply]
Versions you saw in the past and versions you have in local copy are unreliable sources. The only way to "fix" citations that used to be live-linked is to link to a reliable archive. The other option is to remove the link altogether, which means, if the citation depended on online verification, it is no longer valid. 108.182.15.109 (talk) 14:42, 16 January 2020 (UTC)[reply]

This passage in the documentation

RE: "(in particular, do not leave "work" empty with "publisher" non-empty in order to avoid rendering a website's name in italics; a website is a publication and thus its name should be rendered in italics – e.g., as CNN in the example above)."

In the recent RfC and related discussions, there was no consensus that "website=" or "work=" be mandatory and required in all cases. The close certainly did not state that. Yet this passage suggests that one or other of those fields is mandatory. I think we need to establish this before having a passage that suggests they are required. The MOS, at Wikipedia:Citing sources, states directly that flexibility is required for common-sense exceptions, since there is no one-size-fits-all solution.--Tenebrae (talk) 18:42, 15 January 2020 (UTC)[reply]

The documentation is clearly wrong here, even if that CNN example will often be right. Headbomb {t · c · p · b} 19:08, 15 January 2020 (UTC)[reply]
No. Every citation must cite a source, which is what "work" represents. The work in this case happens to be a website. It has to be there. This is policy, has nothing to do with the RFC. If the module does not throw an error when work (or its aliases) are missing then something is wrong with the code. 71.247.146.98 (talk) 03:07, 16 January 2020 (UTC)[reply]
Wrong. Having something like
is pointless. Ie |work=CNN.com if what you are citing was created for CCN.com as a website (i.e. this is the work being cited)
if you are citing information that happens to be broadcast on TV, and merely hosted on CNN.com, then CNN (the TV network) is the publisher, not the work.
or, if you feel like digging some more, you can optionally find which program the broadcast was part of, in this case Anderson Cooper 360°. That is the |work=.
Headbomb {t · c · p · b} 03:23, 16 January 2020 (UTC)[reply]
It is not wrong at all. Your examples use the wrong template. This should be {{cite news}} or {{cite episode}} or {{cite serial}} or {{cite av media}}. In these templates, the work should also be emphasized. What you may exclude is the publisher, not the source (the work), though the publisher could be pertinent. Works may be published by CNN subsidiaries or divisions. 108.182.15.109 (talk) 15:03, 16 January 2020 (UTC)[reply]
Plenty of things are not part of larger works. Headbomb {t · c · p · b} 15:13, 16 January 2020 (UTC)[reply]

I don't mean to reopen the RfC debate or any other. I'm simply talking about the language in the documentation page. Simply put, I think the passage says something that isn't true — because "website=" is not required. Should what appears to be an untrue passage stay or go? --Tenebrae (talk) 00:40, 17 January 2020 (UTC)[reply]

Personally I don't care if "website" or any other alias of "work" is used. But a work has to be cited. The idea that a reader will look for the source by searching for any other parameter (publisher or anything else) is novel to me. It is also grossly inefficient, imo. 108.182.15.109 (talk) 02:06, 17 January 2020 (UTC)[reply]
"A work has to be cited". It doesn't. Many things aren't even part of larger works, e.g.
Beaudoin, N.; Landry, G.; Sandapen, R. (2013). "Generalized isospin, generalized mass groups, and generalized Gell-Mann–Okubo formalism". arXiv:1309.0517.
Headbomb {t · c · p · b} 02:28, 17 January 2020 (UTC)[reply]
This example is a bad one. First, it is based on a specialized derivative of {{cite journal}} that is of little interest to the average Wikipedia editor (per the relative number of transclusions), let alone the average reader (I imagine). As a single-source template that is mostly computer-generated, it actually obscures the work (the website arxiv.org). That is because it is targeted to specialists who would know the details. But the average reader does not. The template is badly formatted and presented considering it is part of a general-purpose encyclopedia. If the module was correctly coded, explicit absence of the work (arxiv.org) would have been flagged. Because that is where readers would go to search for, and verify the wikitext, if the specific title-link was bad, or if the in-source location (the titled paper) was not specified for whatever reason. 24.105.132.254 (talk) 16:10, 19 January 2020 (UTC)[reply]

Documentation for interviewer= updated

After a discussion at WP:VPT, I have updated the documentation for |interviewer= based on the documentation for the |author= parameters. You can see the updates at {{cite interview}}. Error corrections are welcome. – Jonesey95 (talk) 22:21, 15 January 2020 (UTC)[reply]

Access date with signs

Maybe it would be helpful to have |accessdate= (or something similar to that parameter) work with {{cite sign}}, as signs are frequently removed, vandalised or become unreadable after exposure to the elements. This is just a suggestion; I could see it not being helpful due to how rarely signs are "archived" compared to web pages. Glades12 (talk) 18:22, 16 January 2020 (UTC)[reply]

I am afraid this is not doable. There is no way I can see to apply neutrality to such access, it is non-fungible and unprovable. 24.105.132.254 (talk) 19:22, 16 January 2020 (UTC)[reply]
Can you explain further? Can't it just be the same as with URLs, where the date is the last one at which someone went to the sign, read it and could confirm that it still verifies the information before the citation? Glades12 (talk) 19:50, 16 January 2020 (UTC)[reply]
I would think it self-evident... this is stated without attempting to be sarcastic or ironic. But what you are proposing is I think unverifiable. 108.182.15.109 (talk) 02:01, 17 January 2020 (UTC)[reply]
Access date with web pages is (if someone updates it, as they are supposed to) unverifiable too, yet we still have that. You seem to have a double standard here. Glades12 (talk) 06:45, 17 January 2020 (UTC)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Help_talk:Citation_Style_1&oldid=936551262"