Help talk:Citation Style 1

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

Published online parameter?

Increasingly journal articles are published online many months before they are published in the print version of the journal, which is often the following year. As a result many articles have references added with {{cite journal}} using |date= for the date of online publication. For example, this article was published online in October 2017 and appeared in print in 2018. The print edition gives published online as part of the citation. Using the year to state the actual date issue 1 of volume 12 was published ignore the date of original publication, while leaving date leaves a mismatch with the journal citation. A |published-online= would allow all the information to be provided. An alternative is to use |orig-year=published online 10 October 2017 but I'm not sure this is an appropriate use of this parameter.   Jts1882 | talk  14:39, 16 March 2019 (UTC)

|orig-year= is meant to be used for this sort of thing, if the difference in time is meaningful. The parameter is free-form, allowing for such clarification. I would highly recommend restraining yourself to just one date in the general case if there is no difference between the online and paper publications. --Izno (talk) 16:22, 16 March 2019 (UTC)

References

Really, we should have |orig-date= Headbomb {t · c · p · b} 23:38, 20 March 2019 (UTC)

Yes, this would be a welcome addition. I too proposed an |orig-date= parameter several times already. Whenever I have to use |orig-year= to specify a date rather than only a year I feel as if I have to abuse a parameter to make the template do what it should do.

--Matthiaspaul (talk) 19:32, 25 March 2019 (UTC)

I saw this same matter come up a few months ago in (as I recall) Nature.^* Part of the reason for having both dates (online and print) is that prior to the print publication an article might be referred to by its online date. (And I have an instance of this, an article that was published online in 2018, but has not yet appeared in print. So if I cite it now: do I need to change the date when it comes out in print?) At any rate, it looks like some of the journals are starting to consider the problem, and I think we should monitor that.

As to using "orig-date/year": the print date has always been (and still is) considered the date-of-record, and calling the "pre-print" date "original" tends to confuse matters. I am thinking we should have a "online-date" parameter, which can be treated like orig-date, and indeed, could be a synonym [see below]. The point of having a different name is to avoid using (or telling people to use) "orig-date" for a date that is generally considered not original. ♦ J. Johnson (JJ) (talk) 20:37, 25 March 2019 (UTC)

^* Keller and Prusiner, "Cite the online date of publication", Nature, 28 June 2018, p.519. ♦ J. Johnson (JJ) (talk)

Were we to proceed with this, it seems to me that a date-holding parameter for the online publication date must be a real date-holding parameter subject to all of the constraints of other date-holding parameters; not free-form so not an alias of |orig-year=. Can we presume that a journal article published online is the same as the printed article-of-record? If online is subject to change (like preprints in the arXiv suppository) then WP:SAYWHEREYOUGOTIT applies so we should treat such citations in the same manner as our other preprint templates. What to do with the online date when |date= has a value – is there any need to render both simultaneously? Special annotation for this online date to identify it as an online rather than article-of-record date? Applies only to {{cite journal}} or {{citation}} when |journal= is set? No doubt there is other minutia to worry about.

—Trappist the monk (talk) 11:37, 26 March 2019 (UTC)

I can't speak for Jts and I am not against the introduction of a specific |online-date= parameter with full range checking, but I only asked for |orig-date= as a simple alias for |orig-year=, just so that people can finally use a sensibly named parameter when they specify a date rather than only a year. I really can't see a problem with this.

The |orig-year= parameter is used for many purposes beyond just online magazines, as would be a |orig-date= parameter. One of them is in conjunction with a prior publication in limited circulation or even restriced access form such as inside of organizations such as companies, governments, or the military, when the same publication will become accessible to the general public (typically much) later on - in this case, an internal publication in print may even preceed a later online publication. The parameter is also used in conjunction with reproductions/reprints of historic sources. I have also seen it applied to indicate the original publication date of the first edition of a work, when later editions where only slightly modified, or to indicate a filing date or the last edit date of sources, if it differs from a publication date. So, if that includes more than a simple year, putting this under |online-date= would be just as wrong as under |orig-year=. That's why I think |orig-date= (as a free-flow parameter) would be more flexible. --Matthiaspaul (talk) 17:08, 28 March 2019 (UTC)

I am going to strike my suggestion that 'online-date' could a synonym of 'orig-year'. Regardless of whether 'orig-year' was "meant to be used for this sort of thing" (as Izno says) or not, I now think that (at least for journals) that is not appropriate: the on-line version and print version should (at least initially) be identical, and therefore equally "original". (After publication the on-line version may be revised to correct any errors, which would involve a revision date, but the original publication date remains unchanged.)

So I think 'orig-year/date' isn't really applicable to journals. In that sense having 'orig-date', likely as a synonym (both being free-form?), seems good. But that is a different discussion than this one.

Re an on-line publication date: I think it should be a "real date". After checking it could be handled like orig-year: shown in square brackets. We should show both dates, because other sources might refer to it by the initial on-line publication date. (I had a case like that once: a source referred to "Smith 2000", which I simply could not find. Turned out that the print publication was like "Smith 2002".) I don't know that the 'online-date' needs to be labeled as such. (Do we label 'orig-year'?) If the print publication date is not yet known then the brackets show that the date provided is preliminary. As to post-publication on-line dates: of course. Revisions are sometimes made, and the on-line date can indicate that, but the date-of-record remains the same.

But none of this applies to a pre-print server. An item there might turn out to be identical with the "published" item, but that's not guaranteed. If such a source is used it should be identified as "draft" or "pre-press", or some such.

Matthiaspaul raises the matter of re-publication. There is a fine question here of just what constitutes "publication". Ordinarily this is when something first becomes available "publicly", and not to subsequent reprinting or copying, even copying on-line. (E.g.: copying an article to ResearchGate.net is not considered publication.) But note that non-public documents, secret memos, etc., are usually dated by when they were created or issued. To cite a memo from General Smith that was secret until published in The Pentagon Papers, a typical citation would be "Smith, 1966, In: The Pentagon Papers, 1972 ...". But these considerations could go well beyond the present topic. ♦ J. Johnson (JJ) (talk) 20:27, 29 March 2019 (UTC)

Are we going anywhere with this? The matter of on-line publication dating seems to be a developing issue which we might want to stay ahead of. ♦ J. Johnson (JJ) (talk) 21:08, 16 April 2019 (UTC)

Contextual indication of source reliability

Wikipedia:Reliable sources/Perennial sources and WP:SOURCEWATCH have some high-quality info and it's a shame to relegate it to pages deep within Wikipedia. I think of all the readers who could benefit when unwittingly clicking through to a "Forbes" article that is actually written by a Forbes contributor. What if we provided some visual indication or explanatory tooltip for specific sources so that readers can better prepare themselves to critically assess the citation's contents? At the very least, we could provide better context for how readers should approach the source's reliability (and why). And has there been prior discussion about such a CS1 feature before? czar 00:30, 1 April 2019 (UTC)

(off-topic but still relevant) @Trappist the monk Ack! I was quite shocked to see my name in a reversion saying "Do not delete others' text" etc. Then doubly shocked to check contribs and see that apparently I did delete it. I can only conclude/assume this was a butt-deletion by a cellphone in my pocket. The post above is extremely bland and non-controversial, and I have exactly zero problems with User:Czar. So please accept my apologies for the misdeeds of my posterior. ♦ Lingzhi2 (talk) 01:39, 1 April 2019 (UTC)

Yeah those are some neat resources. I'm afraid if we give them too much prominence editors will begin to treat them as immutable rules like a board game and Wikipedia would begin to be deleted by well-meaning but zealous editors who are "cleaning up". Maybe an optional plugin or something for those doing verification work to colorize sources? Remember the quality of sourcing varies from topic to topic - sourcing quality for an off-beat Internet meme is different from that for George Washington. Everything is contextual. -- GreenC 16:19, 1 April 2019 (UTC)

I don't think we need to do anything here at the CS1 level as far as warning readers is concerned. If you need to warn readers, or want them make up their mind about a source, either use a link |journal=Journal of Cosmology, or clarify things in prose "In an article published in the fringe-science Journal of Cosmology... ".

However, it will likely be useful for WP:SOURCEWATCH to have a sort of verification parameter akin to {{cite journal ... |sourcewatch=appropriate}} for something cited per WP:ABOUTSELF (or similar) or {{cite journal ... |sourcewatch=!hijacked}} to indicate that this is the legit, not the hijacked journal. This would turn the SourceWatch into a proper worklist by letting us filter out non-problematic citations to Forbes (or other questionable/problematic sources). However, this needs a bit more stewing in my mind before anything should be implemented here. Headbomb {t · c · p · b} 16:30, 1 April 2019 (UTC)

@Headbomb, but readers do not know the standing of a source, especially when used within an article with no additional context, as if often the case. Wikipedia encourages basic information literacy in providing verifiable sources to check claims, but we assume that readers know to vet the source for trustworthiness. In my experience, readers trust that the source is reliable for the claim in the first place, when it could be, e.g., an interview/primary source. We're in a unique position to be able to offer contextual information about a source's use and reliability within the citation itself, or at least to develop the paradigm of visually indicating a source's trust status, even if only for the major cases with deliberate community-wide consensus. czar 13:25, 20 April 2019 (UTC)

That's what Wikilinks are for. We don't need to either clutter prose or referencing with POV/Weasily stuff like In the very reliable, but not perfect, Nature, authors said that ... but in the probably reliable Journal of Potato Research and Potato Farming researcher said that..., which is supported by claims published in the prestigious Science and also the averagely prestigious Journal of Farming.

The default is a reliable source. Readers shouldn't have to look up wether something is reliable or not because we're supposed to write things based on reliable sources. If it's not, remove the source and put a {{cn}}. Headbomb {t · c · p · b} 15:43, 20 April 2019 (UTC)

My focus was on the citation template (CS1), not in sentence-level prose context. The untrained reader does not know how to discern the difference between a self-published source, a fishy source, and a reputable source, and we have the tools/position to assist. My intent is less about requiring us to intervene with {{cn}} and more about giving context about how to use the best available source. (not watching, please {{ping}}) czar 23:36, 28 April 2019 (UTC)

Capitalisation of subtitle with sentence case

I can't find anything definitive on whether to capitalise the first letter of a subtitle after a colon in a book title using sentence case. A subtitle can seem a continuation or separate from the title. A bibliography example that I did 1962 Tour de France#Bibliography. BaldBoris 14:35, 10 April 2019 (UTC)

@Trappist the monk: It may seem silly, but I'd really appreciate some feedback on this if you get it. BaldBoris 00:18, 27 April 2019 (UTC)

I did not reply to this post because I don't really have an opinion. If you have a particular case, maybe I will have an opinion about that. What does the original source do? Follow the source's example?

—Trappist the monk (talk) 00:58, 27 April 2019 (UTC)

For as long as the capitalization is consistent in the source, try to reproduce the same capitalization as in the original source. If the capitalization of the source differs between the cover and the front matter, I would suggest to use that found in the front matter. This also applies to usage of "-", ":" or "," to separate subtitles. --Matthiaspaul (talk) 18:28, 30 April 2019 (UTC)

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

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

to Module:Citation/CS1:

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

to Module:Citation/CS1/Configuration:

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

to Module:Citation/CS1/Whitelist:

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

to Module:Citation/CS1/Date validation:

• support auto-date-formatting

to Module:Citation/CS1/Identifiers:

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

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

Required auto date formatting interface protected edit request made.

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

Subscription

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Parameter: |subscription

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

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

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

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

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

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

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

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

Broken citation module

Tracked in Phabricator
Task T221625

Screenshot of the error

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

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

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

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

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

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

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

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

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

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

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

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

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

Answered at phabricator.

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

Deprecated subscription=

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Self transclusion

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

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

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

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

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

The documentation for the getContent() title object says:

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

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

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

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

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

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

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

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

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

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

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

Template-protected edit request on 17 April 2019

There's a typo at the page Template:Cite AV media. In the TemplateData table, in the row for "In-source location", there's a "source" that is misspelled as "soruce". Thank you. Shuipzv3 (talk) 11:57, 17 April 2019 (UTC)

 Done - Actually the typo was on the subpage Template:Cite AV media/doc, which isn't protected. -- John of Reading (talk) 12:14, 17 April 2019 (UTC)

Languages that do not use a Latin-based alphabet

For those citations which languages that don't use a Latin-based alphabet, is the romanized transliteration required for the title? —Wei4Green | 唯绿远大 (talk) 14:48, 22 April 2019 (UTC)

It is useful to have the original non-Latin title in |script-title=, the romanization in |title= and a translation in |trans-title=. Kanguole 15:00, 22 April 2019 (UTC)

So it would look like this?

Chinese president Xi Jinping and Premier Li Keqiang expressed their condolences to Sri Lanka leaders on 22 April 2019 after the bombings.

—Wei4Green | 唯绿远大 (talk) 15:12, 22 April 2019 (UTC)

References

As you can see from your above, yep, that's how it looks. Is there something wrong with that rendering or are you simply using this page as a sandbox?

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

I was wondering if it looks good like that with every citation needed to be romanized. Look at Beijing Daxing International Airport#References, would it look readable with all of the Chinese article titles transliterated? —Wei4Green | 唯绿远大 (talk) 15:36, 22 April 2019 (UTC)

Deciding whether or not it looks good like that ... is a subjective, personal opinion, is it not? Were it me, because I cannot read either the original or the transliteration (I am not alone in that disability), neither really help me to decide if I believe that the source is interesting enough to pursue. So, for me and for other readers like me, English-language sources are best. English-language sources not being available, then the original source title in either |script-title= or |title= is a must. There is no requirement for both but if both are provided, then readers should be able to locate the source by either original title or by the transliterated title. If the transliteration is your own and not provided by the source as an 'official' transliteration, then it is little use to readers, right? For example, if I paste this:

"Xí Jìnpíng jiù Sīlǐlánkǎ fāshēng xìliè bàozhà shìjiàn xiàng Sīlǐlánkǎ zǒngtǒng zhì wèiwèn diàn, Lǐ Kèqiáng xiàng Sīlǐlánkǎ zǒnglǐ zhì wèiwèn diàn" [search results]

into google search, it returns one link, our 2019 Sri Lanka Easter bombings article. Pasting the original title into google search finds about 7k hits; none of which I can read ... but still better, I suppose, than a circular link back to our article.

—Trappist the monk (talk) 16:03, 22 April 2019 (UTC)

Auto-date-format: {{use dmy dates}}

Please, either: change the script parameter to |cs1-style= or change the template documentation to |cs1-dates=. 65.88.88.91 (talk) 19:53, 23 April 2019 (UTC)

[edit] I suppose you could also alias the script parameter. 65.88.88.91 (talk) 19:56, 23 April 2019 (UTC)

done

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

Vcite templates

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Lua makes migration hard

Tracked in Phabricator
Task T191737

Perhaps this has been said before, but the incorporation of Lua code into this template makes it rather hard to migrate Wikipedia articles to other wikis because the standard MediaWiki release does not include Lua. -- Communpedia Tribal (talk) 15:04, 28 April 2019 (UTC)

You could make that complaint about any number of en.wiki templates, not just the cs1|2 templates. I know that Scribunto and Lua are available so it would seem that it is just a matter of the other wikis's sysops installing it (and also installing / updating whatever system support Scribunto requires). If you think that Scributo and Lua should be in the MediaWiki standard release, then you should probably raise that issue with MediaWiki because we can do nothing to help you with that here.

—Trappist the monk (talk) 15:35, 28 April 2019 (UTC)

... and that issue has already been raised on Phabricator. * Pppery * _{has returned} 15:36, 28 April 2019 (UTC)

Yes, the same has been said about the automated taxobox system, but the advantages of Lua for complex coding far, far outweigh any issues over migration, and I agree that the answer is to make Lua into a MediaWiki standard. Peter coxhead (talk) 16:03, 28 April 2019 (UTC)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

updated in the sandbox:

Cite journal comparison

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

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

Response from ADS staff

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

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

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

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

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

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

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

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

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

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

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

Thank you for doing that.

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

Perennial italics debate is recycling again

FYI

 – Pointer to relevant discussion elsewhere.

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

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

Needs to support "no title"

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

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

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

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

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

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

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

Here is what I meant to have there:

--------

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

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

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

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

There has been previous discussion that did not go anywhere.

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

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

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

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

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

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

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

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

Fixed {{para}} templates in your post.

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

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

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

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

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

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

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

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

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

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

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

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

Possible exception to para others maintenance message

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

Cite AV media notes comparison

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

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

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

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

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

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

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

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

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

Old Blind Dogs

Close to the bone

I might write something like:

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

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

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

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

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

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

Error and maintenance category names updated in sandbox for capitalization consistency

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

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

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

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

Website field

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

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

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

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

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

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

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

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

|website= ~120k articles (timed out)

|work= ~128k articles (timed out)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

"Panthera leo atrox". Paleobiology Database. Retrieved 11 March 2012.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

The n.d. keyword for undated sources

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

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

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

Protected edit request on 5 May 2019

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

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

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

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

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

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

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

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

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

Cite book comparison

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

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

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

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

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

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

This citation is from Climate sensitivity:

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

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

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

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

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

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

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

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

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

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

So, this template from Babaria:

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

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

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

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

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

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

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

@Sitush: Hmm. Does this help:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Categorization of registration/subscription

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

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

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

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

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

better |xxx-url-access= error reporting

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

Cite book comparison

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

and aliasing still works:

Cite book comparison

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

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

Examples of how to use the templates

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

We don't "need" (and shouldn't have) a way to cite works without italicizing them. When any website is cited as a work, it is cited as a published work (by definition), not as a shop or server or corporate entity or whatever else the same name might refer to outside of a citation-to-published-work context, where it gets italicized. If someone wants to change MOS:TITLES to have an "except when the source is electronic" exception, go propose one at WT:MOSTITLES (I predict a WP:SNOW close against the idea; it's not like we haven't been over this before).  — SMcCandlish ☏ ¢ 😼  22:03, 6 May 2019 (UTC)

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

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

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

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

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

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

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

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

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

GreenC, since you referenced these "sources" below:

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

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

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

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

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

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

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

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

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

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

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

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

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

Yep, you did. Thanks.

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

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

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

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

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

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

(edit conflict)Now we are going in circles.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Attempt to conclude

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

Thoughts:

• Based on MOS:ITALICTITLE, in regular text websites should be italicized when they are "online magazines, newspapers, and news sites with original content".
• At MOS:ITALICWEBCITE, it says: "When any website is cited as a source, it is necessarily being treated as a publication, and in that context takes italics. Our citation templates do this automatically; do not abuse unrelated citation parameters, such as |publisher=, to evade italicization of online work titles in source citations."
• What about the idea that CNN, CBS, etc. are news websites and organizations. It could be that we would italicize them in the context of being a website (a work produced by the publisher of the same name), but not as a company, network, etc.
• Does it matter if the reference is created by one of the cite templates or is just wiki text?
• Would this apply to websites in External links sections?

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

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

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

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

Potential RfC

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

To talk about the wisdom of an RfC, please comment below. Thank you. SchreiberBike | ⌨  05:01, 15 May 2019 (UTC)

removing apostrophe markup in periodical and publisher parameters

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

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

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

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

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

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

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

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

Before I made this change, I had not looked at how pervasiveness of these practices. Simple insource searches timeout:

publisher ~34k results

website ~2.6k

newspaper ~3k

journal ~1.2k

work ~8.3k (did not timeout)

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

—Trappist the monk (talk) 12:46, 7 May 2019 (UTC)

The use of italic markup in these parameters is pervasive. I suggest at least a maintenance category, though I'd be happy to have an error as well. --Izno (talk) 13:14, 7 May 2019 (UTC)

Can the error be restricted to new instances? If the error appears when someone is editing a section already using such a reference it will be confusing.   Jts1882 | talk  13:45, 7 May 2019 (UTC)

No. Templates don't work that way; the error is an error whether it is old or it is new. I would hope, yeah, I know, a forlorn hope, that when editors do see preexisting errors in a section that they are working on, they will take a few seconds and fix them.

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

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

Cite journal comparison

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

Original url commented out so as not to cause horizontal scrolling

Another, from Insulin:

Cite journal comparison

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

The sandbox version italicizes the Chinese journal title, which is undesirable, and I don't know of a way to prevent it. Maybe I am failing to read the documentation well enough. [A note on sample sizes: I found three such examples in the first page of 20 search results.] – Jonesey95 (talk) 17:24, 7 May 2019 (UTC)

Yeah, problematic. I suppose that the preferred answer is for editors to use English when available; see the English-language version of your first example which has a 'how to cite this article' blurb at the bottom. I know, doesn't fix the problem. Which means ...

|script-<periodical>= and |trans-<periodical>=? It may be that that these are the only way to have our cake, consume it, and retain our sylph-like forms.

—Trappist the monk (talk) 18:17, 7 May 2019 (UTC)

That's the solution I was thinking of as well, but I wanted to give the example some space to breathe before jumping to a proposed answer. (mmm, cake!) – Jonesey95 (talk) 18:37, 7 May 2019 (UTC)

People are doing this in many cases because CS1|2 is not properly able to render output correctly so they are working around it. For example every style guideline on planet Earth says never capitalize CNN in citations. But that is exactly what CS1|2 does when placed in the |work= field. So people are trying to work around CS1|2's behavior. I would suggest determine what the problems are, why people are doing this, and fix that. For example not every value in |work= should be italicized. Until then covering over the symptoms is stop gap. -- GreenC 19:20, 7 May 2019 (UTC)

So much hyperbole. cs1|2 is a general purpose tool that does a fair job of correctly rendering most of what editors want to cite. It will never be perfect for all citations all of the time.

I wonder if this change, supported by |script-<periodical>= for non-Latin languages might prompt a definitive decision with regard to what should and what should not be italicized in citations, which, as you will recall from WP:CITESTYLE, are allowed to have their own style. cs1|2, like it or not, intended or not, is and has its own style, part of which is to italicize the value assigned to the periodical parameters. This has been true since very early in their development:

cite web 7 December 2004

cite journal 4 February 2005

citation 15 November 2005

cite news 8 March 2006 (this one also italicized |publisher=)

It occurs to me that much of what editors are squabbling about in the other conversation is three-letter acronyms: CNN, PBS, BBC, NPR. All uppercase letters. That can be detected and extended to station call letters: WGBH-TV. So, there is a possible automatic 'fix' (if a fix is required) that is simple to implement if it comes to that.

—Trappist the monk (talk) 22:52, 7 May 2019 (UTC)

There's also Rotten Tomatoes, Metacritic, and Box Office Mojo. Personally, I'm OK with italics. —BarrelProof (talk) 23:31, 7 May 2019 (UTC)

The lack of flexibility in italicizing the work value is the source of disputes like above, and also why the problem this thread is trying to resolve exists (in many cases). Checking for all-caps is one solution but imperfect there can be others as noted by BarrelProof. Three other solutions off-hand: turn off italics like |workitalics=no; a properties flag like |work=WGBH-TV $i; or an optional work argument such as |iwork=WGBH-TV. All of these are clumsy I admit but the first step is consider ideas. With |work=WGBH-TV $i this mechanism could be applied to any argument optionally modifying default italics $i, bold $b, underline $u, etc.. as users wish. The last word would rarely begin with a '$' so it would be a safe metacharacter. -- GreenC 01:03, 8 May 2019 (UTC)

Further ideas, similar to '$i' use a template called {{csc|itoff}} where "csc" means "CS1|2 control", "itoff" means "italics off". The template does nothing but acts as a flag that CS1|2 detects and acts on eg. |work=WGBH-TV {{csc|itoff}}. This has the advantage of staying within the existing template system so the "$i" method doesn't inject garbage data into existing bots and tools that don't expect meta-characters of that form. -- GreenC 01:13, 8 May 2019 (UTC)

Yeah, those are possibilities. cs1|2 does have some parameters that support the use-this-parameter-value-as-written ((...)) markup (|issue=, |pages=, |title=, |vauthors=, |veditors=). Perhaps that should be applied to the periodical parameters so:

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

would render as: CNN

Without that markup, apostrophe markup would be removed so:

|website=''[[CNN]]''

would render as: CNN

—Trappist the monk (talk) 11:40, 8 May 2019 (UTC) 13:25, 8 May 2019 (UTC) 15:09, 8 May 2019 (UTC)

Oh that solution is fine. In fact rather than converting all cases of |website=''[[CNN]]'' to |website=[[CNN]], convert to |website=((''[[CNN]]'')) under the assumption this is what the editor originally intended anyway. For CNN we can't automatically determine if they meant to link to a website (italics) or a TV channel (non-italic). I can work on a document somewhere about when to use this method and why, for the periodical parameter, and link to it in the main docs. Further debates about it can take place there and CS1|2 is off the hook since it will be flexible to support italics or not. -- GreenC 17:09, 8 May 2019 (UTC)

I don't think that the module should attempt to guess editors' intent with respect to this rather heated debate. The module and the templates should simply do as we tell them to do. We have told the module from its inception (and the templates from their early days) that periodical parameter values shall be italicized and that should not change.

Long ago, I wondered in these talk pages if the module should require the periodical templates to have a periodical parameter. At the time I was thinking about {{cite journal}} but this could/should apply to all periodical templates. Recalling this lead me to have a re-look at the COinS metadata support at Module talk:Citation/CS1/COinS. You will see from that table (at rft.pub) that |publisher= is only supported for book objects. This means that the metadata for all of those periodical templates that use |publisher= to avoid italics are missing that important piece of information. We cannot prevent the use of |publisher= in periodical templates (there was an RFC) but we can, and I think should, emit an error message when a periodical template does not have some form of periodical parameter.

While I was thinking about this, I looked at the parameters that are aliases of |publisher=. These are:

|distributor= – listed in Module:Citation/CS1/Configuration but not in Module:Citation/CS1/Whitelist; don't know what it was (if it was) used for; I propose to delete it

|institution= – shown in examples at {{cite techreport}} but not otherwise documented

|newsgroup= – for {{cite newsgroup}}

If we continue with the process we will:

1. ignore italic wiki markup in the |<periodical>= parameters and |publisher=; the module shall emit an appropriate error message when it does this
2. add support for use-this-parameter-value-as-written ((...)) markup in |<periodical>= parameters (|publisher= is never italicized)
3. add support for |script-<periodical>= and |trans-<periodical>=
4. add error message for periodical templates without periodical parameter (and attendant category and help text)
5. remove |distributor=

—Trappist the monk (talk) 12:56, 9 May 2019 (UTC)

Regarding #2 above, I still have not seen any examples where it is valid for |<periodical>= values to ever *not* have italics. I could be misunderstanding this (and I agree this isn't something that needs to be demonstrated to my satisfaction, I'm just one voice on this), but if we allow ((...)) markup there we should also have valid example(s) of when to use it – especially with regard to anything that has |url= populated. Otherwise we are just kicking the can down the road and potentially causing the churning that Mandruss is correctly worried about above.

One possible compromise (that may be non-trivial to implement, in which case please just ignore this suggestion) would be to disallow the ((...)) exception in |<periodical>= anytime |url= has a value. - Paul^T+/_C 17:35, 9 May 2019 (UTC)

My primary interest in this is to make sure that the metadata are not corrupted and are present when they should be. So if it takes use-this-parameter-value-as-written ((...)) to get editors to use the |<periodical>= parameters instead of |publisher= because they want, for whatever reason, to have the periodical name in upright font, then at least the name gets into the metadata as it should do.

Why is the presence or absence of |url= important or distinguishing? |url= is required for {{cite web}} so you must be talking about the periodical parameters in {{cite journal}}, {{cite news}}, {{cite magazine}}.

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

The presence or absence of |url= is important because it forces the distinction of being a published work and therefore italicized as a result of the current guidelines. Per SMcCandlish above: When any website is cited as a work, it is cited as a published work (by definition), not as a shop or server or corporate entity or whatever else the same name might refer to outside of a citation-to-published-work context, where it gets italicized.

Here is a quote of the relevant guideline from MOS:ITALICTITLE:

When any website is cited as a source, it is necessarily being treated as a publication, and in that context takes italics. Our citation templates do this automatically; do not abuse unrelated citation parameters, such as |publisher=, to evade italicization of online work titles in source citations. - Paul^T+/_C 18:32, 9 May 2019 (UTC)

Whether a URL is present or not probably has nothing to do with any of this. The ITALICTITLE footnote quoted above doesn't imply otherwise. If you're citing an online source, it should have a URL so people can find it. It doesn't make it less or more of a published work. The fact that it can be cited at WP is what makes it a published work, since we do not cite anything other than published works (even our very limited citations of primary sources like one of Trump's tweets is citing it as a very short work that has been published). It's not the URL parameter that makes something a published work, it's the citation to it at all as a source. Simple proof: Many e-books have identical pagination to hardcopy versions (being either scans of the latter, or PDF/Kindle/whatever exports of the same desktop publishing files use to generate the latter). Per WP:SAYWHEREYOUGOTIT, if you are reading the hardcopy, your citation needs no URL, while if you're reading a Web-provided PDF version at the author's website, it does need one to indicate you are reading that electronically-distributed version even if the rest of the parameters are the same. If you are reading an Amazon-exclusive e-book version via its app for that stuff, then your cite should use some other method of indicating this (e.g. a specific ASIN in the |id= parameter or whatever). They are not italicized differently, and none of the three versions is less or more of a published work.  — SMcCandlish ☏ ¢ 😼  01:07, 10 May 2019 (UTC)

By that logic, the ((...)) markup should never be used (or work) in |<periodical>=. I'm on board with that and have been arguing that point at length. However, allowing the ((...)) markup in |<periodical>= is being pitched as a compromise so as to make sure that the metadata are not corrupted and are present when they should be in cases where the editor want[s], for whatever reason, to have the periodical name in upright font. My point is, if we are going to allow for that compromise, it should never work when a URL is present. - Paul^T+/_C 01:33, 10 May 2019 (UTC)

I too have thought that there is no real need for the ((...)) markup if community resolution of the publisher/work/upright/italic squabbles determines that the values assigned to |<periodical>= shall be rendered in italic font. Anticipating that such a resolution will occur before the next module update seems a forlorn hope. I do know that without that community resolution, the Upright Periodical-name Brigade will show up with their torches and their pitchforks and inflict drama on us. I'd rather avoid that so the ((...)) markup, along with the other items in the TODO list make for correct metadata whilst the argument is settled.

If you have made a case for specific restrictions involving citations that have |url= set, I don't understand your point. Can you explain why it is that |url= is so important to you?

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

If that is how you feel, perhaps we should "do the right thing" (not allow ((...)) in |<periodical>= ever) and force the debate?

To directly answer your question... the point is to better comply with MOS:ITALICTITLE, which specifically mentions websites in the passage I quoted above. If there is a |url=, then there is a link to a website and the |<periodical>= should be italicized as explicitly stated by the guideline. (That passage in the guideline probably deserves its own shortcut - perhaps MOS:ITALICCITEWORK/MOS:CITEWORK, MOS:ITALICWORKCITE/MOS:WORKCITE, MOS:ITALICWORKREF/MOS:WORKREF, or simply MOS:ITALICWORK/MOS:ITALICCITE?I created MOS:ITALICWEBCITE.) This, in combination with error messages in #1 and #4 above, will suppress the use of |publisher= simply to avoid italics in cases where there is no |url=. In cases where there is a |url=, I think the rationale at MOS:ITALICTITLE is clear enough to at least focus any debate there instead of here if there is drama from the Upright Periodical-name Brigade. The guideline is very explicit: any website. Why make it easier to flout it?

Furthermore, I still have not seen any example where it is correct to remove italics in |<periodical>= and if we allow ((...)) markup there we should also have valid example(s) of when to use it.

But, again, I understand that adding this bit of logic between |url= and ((...)) markup in |<periodical>= may be non-trivial, and if it will significantly add to the complexity of the change then please ignore my suggestion. (And perhaps consider the first sentence in this reply instead?) - Paul^T+/_C 13:53, 10 May 2019 (UTC)

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

Notes

1. ignore wiki markup

ignore italic wiki markup in the |<periodical>= parameters and |publisher=; the module shall emit an appropriate error message when it does this

Cite book comparison

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

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

Cite news comparison

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

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

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

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

2. support for use-this-parameter-value-as-written

add support for use-this-parameter-value-as-written ((...)) markup in |<periodical>= parameters (|publisher= is never italicized)

Cite book comparison

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

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

Cite news comparison

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

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

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

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

Title. ((Publisher)).

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

I suspect that this should be announced somehow. How?

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

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

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

I came across an instance where something like "|pages=1,234–6,789" was input into a cite template and it rendered unexpectedly -> "pp. 1, 234–6, 789" as if there were 3 separate page ranges: "1", "234 to 236", and "789". This is contrary to the expected "pp. 1,234–6,789". Now, the mistake here (and fix) should be obvious - remove the comma, but there is nothing in the documentation to indicate that this would be a problem. Is this worth mentioning in the HELP:CS1#Pages section or is it too obscure? The specific example I saw was in an academic journal that apparently is often over 1000 pages. - Paul^T+/_C 02:55, 8 May 2019 (UTC)

Some journals start with a page 1 for the first page of the January issue and continue the numbering consecutively until the end of the year. In such a case, page numbers above 1,000 are common. The issue of the journal I happen to have at my fingertips starts on page 915, and that's for the April issue. Extrapolating to December, it'll end up with around 3,000 pages for the year (and I know of others that are much longer). My suggestion is different – just don't automatically insert spaces after commas. MOS:NUMRANGE does not discourage commas in numerical range expressions and MOS:DIGITS suggests to use them, and they seem likely to be used relatively often anyway. —BarrelProof (talk) 03:07, 8 May 2019 (UTC)

That makes way more sense. Thanks for the clarification on why the page numbers are so high! - Paul^T+/_C 15:54, 8 May 2019 (UTC)

Cite journal comparison

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

Illustration of the problem is above. – Jonesey95 (talk) 04:40, 8 May 2019 (UTC)

It is the responsibility of the module suite to render properly formatted citations as best it can given the broad variety of stuff it gets as parameter values. Editors will leave out spaces, will use hyphen instead of endash (and the other way round), will use semicolons, will leave out punctuation, will duplicate punctuation, .... |pages= lists are supposed to be an endash-separated page range, a comma-separated list of individual pages, or a comma-separated list of individual pages and endash-separated page ranges. It isn't really possible to for the module to know if |pages=1,234–6,789 refers to a (completely unhelpful-to-readers) 5,555-page range or three individual elements: page, small page-range, page. |pages= does support the use-this-parameter-value-as-written ((...)) markup so:

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

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

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

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

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

without the ((...)) markup

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

"Title". Journal of Page Numbering: 1, 234–1, 256. – second element is rendered as an endash-separated page range

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

to a (completely unhelpful-to-readers) 5,555-page range 1(,)000% correct - I was giving an example of the phenomenon, not directly quoting what I saw. the use-this-parameter-value-as-written ((...)) markup this is an obscure, but useful feature. I will use it to correct the incorrectly rendered references that prompted my comment.

It may make sense to explicitly outline this "limitation"/"feature" at HELP:CS1#Pages. Is ((...)) mentioned/documented anywhere at HELP:CS1 or elsewhere? - Paul^T+/_C 12:02, 8 May 2019 (UTC)

Also note, this feature doesn't seem to work with the |page= parameter. - Paul^T+/_C 12:35, 8 May 2019 (UTC)

((...)) is mentioned in the documentation for |vauthors= and |veditors=, for which it was originally developed; |title= got it as a result of this discussion; |pages= and |issue= got it as a result of this discussion.

Yet another claim that something-doesn't-work-but-I-can't-be-bothered-to-provide-an-example. Do you know how frustrating that is? Why do you and other editors do that?

I don't think that I have said here that this feature applies to |page= though I did imply that ((...)) markup applied to |page= in another conversation – I'll fix that. Module:Citation/CS1 treats the content of |page= as a single value. Single values do not need to be massaged to get spacing right, do not need to have hyphens converted to endashes, etc. cs1|2 does not automatically change p. to pp. though it will render digit-only |pages= value as p. <digit(s)>.

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

Please accept my apology. I didn't mean it to come across as a complaint, it was simply unexpected and I figured I should note it here. Here is the example:

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

I changed it to:

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

The ((...)) notation is not required for |page=, but it was confusing that the two parameters didn't work similarly in this instance. - Paul^T+/_C 14:24, 8 May 2019 (UTC)

Do you know of any reason why |page= should support ((...)) markup?

The drawback to this 'solution', there always is something ..., is that when you tell the module to use-this-parameter-value-as-written, it does. For example your Babcock et al. (1992) citation uses a hyphen instead of an endash which would be the correct form and which the module would have supplied.

—Trappist the monk (talk) 15:07, 8 May 2019 (UTC)

The double-paren markup could be useful with the page parameter if the document has page numbers of the form chapter-page, such as "10-5". Maybe there is a different trick that permits that; I can't keep track of all the tricks in Wikipedia markup to prevent overly-helpful software from "correcting" correctly written character strings. Jc3s5h (talk) 15:18, 8 May 2019 (UTC)

Already doesn't do anything with that sort of page number:

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

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

so ((...)) markup not needed for this example.

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

This just illustrates that when you take it upon yourself to correct any parameter, or family of parameters, for editor errors, you impose on all editors the burden of predicting whether their unusual but correct parameter value will be mangled or not. Jc3s5h (talk) 15:26, 8 May 2019 (UTC)

Thanks Ttm! Fixed. I have no specific example as to why ((...)) is necessary other than it could be confusing when compared to other references using |pages=. I was merely reporting my surprise (well, really ignorance). - Paul^T+/_C 15:51, 8 May 2019 (UTC)

May I ask, is the thousands separator necessary? Just add the page number(s) without any type of separator (I believe the math term is radix). 65.88.88.91 (talk) 18:58, 8 May 2019 (UTC)

WP:MOS requires a comma. --Izno (talk) 19:26, 8 May 2019 (UTC)

Yes, or a variety of space types, which seems to be the new trending norm in digit-grouping. My point was that this is a relatively minor issue, where neither the readability nor the integrity of the citation is affected by omitting the separator. There are other cases where MOS exceptions are made for CS1-specific formatting. I would think this would be non-controversial. 65.88.88.91 (talk) 19:34, 8 May 2019 (UTC)

The "obscure but useful feature" should be added to the documentation for this parameter, and all should then be well.  — SMcCandlish ☏ ¢ 😼  03:09, 10 May 2019 (UTC)

Citing norms and standards

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

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

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

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

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

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

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

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

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

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

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

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

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

This example is provided:

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

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

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

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

Julian Gregorian uncertainty

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

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

FYI:

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

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

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

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

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

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

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

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

Author mask

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

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

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

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

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

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

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

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

Missing pipe?

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

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

Cite web comparison

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

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

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

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

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

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

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

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

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

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

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

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

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

Cite book comparison

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

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

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

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

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

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

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

Hyphenation in page/pages

Compare |page=1-10

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

with |pages=1-10

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

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

No.

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

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

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

But consider this citation:

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

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

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

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

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

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

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

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

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

The same in search form for easy use with e.g. AWB. (I've been getting results out of the et al category before they actually appear on the category page using incategory: searches.) --Izno (talk) 15:21, 14 May 2019 (UTC)