Help talk:Citation Style 1/Archive 60

There's been a couple of times lately, I've been pondering how to handle the increasingly different headlines between print and Internet versions of articles. While the articles appear to be identical (occasionally with an extra paragraph or two on the Internet version - perhaps trimmed for length), the headlines can differ massively. Today's example is on page A9 of the September 1 Toronto Star called The road with NO GREED LIMIT. The internet version though is a much more politically inflammatory Birth of a fiasco: How the Ontario Tories completely botched the sale of Highway 407. So which one should be cited? My preference would be to cite both - but I don't see an appropriate field. Any thoughts? Nfitz (talk) 16:04, 1 September 2019 (UTC)

Cite the one you read. If you read both, cite both separately. You might consider leaving a hidden note that titles differ. --Izno (talk) 16:52, 1 September 2019 (UTC)

Invariably when this comes up (or at least when I notice), it's because I've started from the print, or microfilmed subscription copy, and then used that to to discover the article is available online, with a (very) different headline, while looking for a URL. Probably best include the URL ... But if I use the URL, I know that sooner or later, someone will "fix" the reference. Yeah, hidden text might be the solution - something like this? Nfitz (talk) 21:44, 1 September 2019 (UTC)

That's what I should have suggested originally, yes. :) --Izno (talk) 22:05, 1 September 2019 (UTC)

Why not title=foo [print] bar [Internet] All the best: Rich Farmbrough, 12:03, 28 September 2019 (UTC).

plz add it ·Carn !? 09:21, 3 September 2019 (UTC)

Please provide an example where this parameter would be useful. Per

WP:SAYWHEREYOUREADIT

, editors should be citing the single source that they are using to back up any claim, and a single source has only one ISBN (the 10-digit and 13-digit ISBNs are equivalent for a given book, so there is no need for both).

If a second source with a different ISBN is useful for some reason, use a second citation template to cite the second source, or place the additional ISBN outside of the citation template. – Jonesey95 (talk) 16:39, 3 September 2019 (UTC)

Some books have more than one ISBN. All the best: Rich Farmbrough, 12:03, 28 September 2019 (UTC).

Citation needed. – Jonesey95 (talk) 13:50, 28 September 2019 (UTC)

Assuming they’re not just talking about ISBN-13 vs ISBN-10, some books’ edition notices might have multiple ISBNs displayed, but it will be because they list, say, the ebook and hardback ISBNs, or have different ISBNs for a boxed set and an individual volume. None of these warrant multiple inclusions in a works cited, in my view. Umimmak (talk) 14:00, 28 September 2019 (UTC)

This very long WP:AN discussion has just concluded, and requires changes to the modules, some of which have been made already:

1. Stop categorizing "missing periodical" errors
2. Stop displaying "missing periodical" error messages (already changed to "hidden" using CSS; change to eliminate messages entirely)

The following change has also been made since the updates listed above, but it was not mandated by the discussion closure:

1. Stop displaying "deprecated parameter" errors for |dead-url= / |deadurl= (already changed to "hidden" using CSS)

We (Trappist, unless someone else has the programming skills) should probably make the remaining change as soon as possible. We could optionally start displaying the deprecated parameter messages, but I think that would just make people angry. I would prefer to see that happen after 99% or more of the |dead-url= / |deadurl= have been converted to the new |url-status= parameter. – Jonesey95 (talk) 21:00, 6 September 2019 (UTC)

I have asked for a bit of clarification with regard to the missing periodical errors reporting.

—Trappist the monk (talk) 21:54, 6 September 2019 (UTC)

Sounds good. While waiting, I have edited above to clarify that I believe the close means that even the hidden "missing periodical" error messages should be eliminated in the modules. – Jonesey95 (talk) 22:02, 6 September 2019 (UTC)

Trappist says everything required by the close is completed. The closing message also said "The other updates shall stand", so I think we should also monitor the progress plan for finalizing this change.

• Monkbot task 16 - to finish replacing |dead-url=
• Confirm that documentation is up to date to the current implementation
• Tools are updated to conform to new documentation
• Task-force to deal with any other problems/error categories that came out of this

The following were in scope for this change, but are now to be treated as discussions before further updates.

• Re-instate error message for |dead-url= - is that needed and welcome?
• What is the intended use of |website=, can documentation be updated and agreed upon?
• How important was the italics RfC and what options are there now to reach that goal?
• Anything else that was "reverted" and should be rescheduled for inclusion or discussion?

-- JAGulin (talk) 14:21, 8 September 2019 (UTC)

Unhide missing periodical error messages? – Levivich 14:33, 8 September 2019 (UTC)

Bumping this discussion, hopefully, since I feel the time has come. Category:CS1 errors: deprecated parameters is currently down to 48,060 pages as of typing, which is a bit over 0.8% of all Wikipedia articles (including disambiguation pages). (Live values can be found here: 3/6,814,415 = 4.0E-5%.) Therefore, I request that the deadurl/dead-url errors become fully visible again. I find it useful for clean-up purposes. -BRAINULATOR9 (TALK) 14:37, 28 September 2019 (UTC)

We have to wait for Monkbot to finish going through the deprecated parameters category, after which further manual intervention will be necessary to clean up instances that the bot was unable to handle, along with instances in Category:CS1 errors: invalid parameter value. In the meantime, instructions for displaying the error messages for yourself, when you are logged in, are available at Category:CS1 errors: deprecated parameters. – Jonesey95 (talk) 16:57, 28 September 2019 (UTC)

If you would like to display them yourself, you will actually need to do something not presently documented at the category page in your CSS:

.mw-parser-output span.cs1-hidden-error {display: inline;} /* display Citation Style 1 hidden errors */

That's because the template which tells people how to configure their CSS does not include how to configure hidden errors, which were not expected to be used again (and so I had removed when we went to TemplateStyles).... --Izno (talk) 17:12, 28 September 2019 (UTC)

That aside, I've now made the change in the module sandbox, so the next release should make them visible again. --Izno (talk) 17:16, 28 September 2019 (UTC)

OK, thank you all! -BRAINULATOR9 (TALK) 19:47, 28 September 2019 (UTC)

When url-status=dead, it correctly produces:

... Cambridge University Press, pp. 34–42, archived from the original (PDF) on 2009-09-06

When url-status=unfit, it incorrectly produces:

... Cambridge University Press, pp. 34–42, Archived from the original on 2009-09-06

The case is not agreeing with the comma before it. The second one should change to ", a", to match the first (unless there is a reason for it to be capitalized, in which case it should change to ". A"). (I'm not expert in citing, here or elsewhere.) - A876 (talk) 04:31, 29 September 2019 (UTC)

I've tweaked the sandbox:

—Trappist the monk (talk) 08:43, 29 September 2019 (UTC)

Now that the blocking rfc has been closed, I propose to update the live cs1|2 module suite after 2 September 2019. Changes are:

Module:Citation/CS1:

• better |xxx-url-access= error reporting; discussion
• remove apostrophe markup from periodical and publisher params; discussion
• periodical templates missing periodical parameter error messaging; discussion
• add script parameter error detection & messaging; discussion
• add |script-periodical= and |trans-periodical= parameter support; discussion
• deprecate and replace |dead-url= and |deadurl=; discussion
• add |map-url-access=; discussion
• require |title= for {{cite encyclopedia}}; discussion
• |issue= & |volume= in {{citation}} same as cs1 templates; {{citation|website=...}} error message when |url= missing or empty; discussion
• access icon parameter-value bug fixed; discussion
• add support for {{
  cite ssrn}}; discussion
• support single letter 2nd level domain for .company tld; discussion
• |doi-broken= requires |doi= error messaging; discussion
• add maint cat when various parameter values have trailing punctuation (comma, colon, or semicolon); discussion

Module:Citation/CS1/Configuration:

• update bibcode url; discussion
• update two error category names and many maint category names to make capitalization consistent; discussion
  • Category:CS1 maint: Archived copy as title → Category:CS1 maint: archived copy as title
  • Category:CS1 maint: Uses authors parameter → Category:CS1 maint: uses authors parameter
  • Category:CS1 maint: Date format → Category:CS1 maint: date format
  • Category:CS1 maint: Date and year → Category:CS1 maint: date and year
  • Category:CS1 maint: Uses editors parameter → Category:CS1 maint: uses editors parameter
  • Category:CS1 maint: Extra text → Category:CS1 maint: extra text
  • Category:CS1 maint: Extra text: authors list‎ → Category:CS1 maint: extra text: authors list‎
  • Category:CS1 maint: Extra text: editors list → Category:CS1 maint: extra text: editors list
  • Category:CS1 maint: Extra text: interviewers list‎ → Category:CS1 maint: extra text: interviewers list‎
  • Category:CS1 maint: Extra text: translators list‎ → Category:CS1 maint: extra text: translators list‎
  • Category:CS1 maint: Ignored ISBN errors → Category:CS1 maint: ignored ISBN errors
  • Category:CS1 maint: Multiple names: authors list‎ → Category:CS1 maint: multiple names: authors list‎
  • Category:CS1 maint: Multiple names: editors list‎ → Category:CS1 maint: multiple names: editors list‎
  • Category:CS1 maint: Multiple names: interviewers list‎ → Category:CS1 maint: multiple names: interviewers list‎
  • Category:CS1 maint: Multiple names: translators list‎ → Category:CS1 maint: multiple names: translators list‎
  • Category:CS1 maint: Unfit url → Category:CS1 maint: unfit url
  • Category:CS1 maint: Unrecognized language → Category:CS1 maint: unrecognized language
  • Category:CS1 maint: Untitled periodical → Category:CS1 maint: untitled periodical
  • Category:CS1 errors: Explicit use of et al. → Category:CS1 errors: explicit use of et al.
  • Category:CS1 errors: Missing pipe → Category:CS1 errors: missing pipe
• remove unsupported |distributor=; discussion
• periodical templates missing periodical parameter error messaging;
• add script parameter error detection & messaging;
• add |script-periodical and |trans-periodical parameter support;
• deprecate and replace |dead-url= and |deadurl=;
• add |map-url-access=;
• add long-missing zbl maint cat; discussion
• |doi-broken= requires |doi= error messaging;

Module:Citation/CS1/Whitelist:

• added missing |contribution-url-access=; discussion
• add script parameters for all |chapter= aliases; discussion
• add |script-periodical and |trans-periodical parameter support;
• deprecate |lay-summary= and |laysummary=; discussion
• deprecate |dead-url= and |deadurl=;
• add |map-url-access=;
• add support for {{cite ssrn}};

Module:Citation/CS1/Date validation:

• fix date format bug; discussion

Module:Citation/CS1/Identifiers:

• zbl temporary-id support; discussion
• access icon parameter-value bug fixed;
• |doi=10.5555... error detection; discussion
• tweak bibcode validation; discussion
• refine |doi-inactive= categorization; discussion

Module:Citation/CS1/Utilities:

• strip apostrophe markup() from ~/COinS; discussion
• tweak strip apostrophe markup() to return text and a flag;

Module:Citation/CS1/COinS:

• move strip apostrophe markup() to ~/Utilities;
• add support for cite ssrn;

—Trappist the monk (talk) 14:11, 27 August 2019 (UTC)

Also Inactive DOIs are now sorted into months of the year categories. --Izno (talk) 14:23, 27 August 2019 (UTC)

No support for

b

} 14:28, 27 August 2019 (UTC)

Yes, both of these too. Added to the list.

—Trappist the monk (talk) 17:03, 27 August 2019 (UTC)

@

b

} 07:22, 28 August 2019 (UTC)

I'm confused. |agency= isn't used in the templates at the link you provided.

—Trappist the monk (talk) 10:05, 28 August 2019 (UTC)

@

b

} 15:30, 28 August 2019 (UTC)

I guess I'm still confused. This:

{{cite book/new |title=Title |agency=Agency,}} → Title. {{cite book}}: Unknown parameter |agency= ignored (help)CS1 maint: extra punctuation (link)

does not emit a red error message but does emit the green maint cat extra punctuation message. That was all that it was intended to do,

—Trappist the monk (talk) 15:39, 28 August 2019 (UTC)

My bad, I read things too fast and had a brain fart, I thought the URL error message was the trailing garbage error message and that threw me off.

b

} 15:58, 28 August 2019 (UTC)

@Trappist the monk: Even with the heads up, this change caused some problems. Please assist in the questions below. JAGulin (talk) 13:53, 3 September 2019 (UTC)

The changes as a whole right now are being discussed at ANI, I would also address the comments there Monk. - Knowledgekid87 (talk) 14:10, 3 September 2019 (UTC)

Cite web error

@Trappist the monk: When using cite web a large number of red errors are sprinkled through the references saying "Cite web requires |website=". It is quite clear that cite web does not actually require the website parameter from the documentation, so whatever code is generating this error should be reverted or cut. This error is in CSS class "cs1-visible-error error citation-comment" Graeme Bartlett (talk) 11:54, 3 September 2019 (UTC)

(edit conflict) Came here to say the same thing as I noticed a large number of new errors of this type in references I wrote a while ago. Requiring |website= is dramatically unexpected behaviour and different to how I've been using the template for over 5 years. I often use publisher instead, but even if both are omitted, it should not be an error as the reference is still sufficient without either parameter as long as it includes a URL, a title and enough extra information to specify the reference if the URL breaks (e.g. author). This error type should be removed quite urgently due to the number of articles it affects. — Bilorv (talk) 12:11, 3 September 2019 (UTC)

(edit conflict) I've just noticed this error message "Cite web requires |website=" and again as Rfassbind says the citation in question has a |publisher= parameter in it. It seems a bit superfluous to me for the citation to have to read {{cite web |url=http://foo.com/the_greatest_thing_ever_told |title=Whatever |website=foo.com |publisher=The Foo Corporation}} producing
"Whatever". foo.com. The Foo Corporation. to stop the error message appearing when the publisher parameter is supplying the identification about the sources of the information. Can |publisher= be added as an acceptable alternative to the periodical parameters already listed? Nthep (talk) 13:20, 3 September 2019 (UTC)

WTF did {{Cite web}} without |website= starting spitting ugly red error messages everywhere? Especially when there's already a perfectly appropriate |publisher= in there. Andy Dingley (talk) 11:10, 3 September 2019 (UTC)

Also the documentation for {{Cite web}} doesn't mention that this param is now mandatory, and that same documentation is itself littered with these inlined red error messages. Andy Dingley (talk) 11:15, 3 September 2019 (UTC)

This is new functionality as of the update listed above about which these new sections were started. The documentation, I assume, will be updated shortly. Help:CS1 errors I know has already been updated. We knew it would affect many articles which have had more-or-less incomplete citations. Please review the documentation pointed to in the above change notes. --Izno (talk) 12:22, 3 September 2019 (UTC)

It's not an incomplete citation, Publisher is often the more fitting parameter, and in many cases neither Website nor Publisher are needed. VisualEditor's automatic citation tool uses Cite Web by default, I don't expect people to know how to open syntax mode and change Cite Web to Cite News. This requirement is not needed and it's very confusing, could you consider turning this error message off? – Thjarkur (talk) 12:43, 3 September 2019 (UTC)

Requiring website= is crazy, as the web site can be determined by the URL in most cases. Just leave it as optional. I will say this is a bungled change without care for the consequences. Graeme Bartlett (talk) 12:54, 3 September 2019 (UTC)

I agree, why was changing "url=" to "website=" a good idea again? Millions of pages are now disrupted for this minor crazy change. - Knowledgekid87 (talk) 13:02, 3 September 2019 (UTC)

Also agree, this is an incredibly poor thought-out change. GiantSnowman 13:09, 3 September 2019 (UTC)

Note that website is not a replacement for url, it's an additional parameter. I agree that it should not be mandatory, or at least it should accept |publisher= as well as the other options. JAGulin (talk) 13:53, 3 September 2019 (UTC)

I agree that {{

b

} 14:35, 3 September 2019 (UTC)

Is there a way to make "website=" and "newspaper=" non mandatory? - Knowledgekid87 (talk) 14:43, 3 September 2019 (UTC)

I am sure there is, the question is whether it should be. I think there is a case for having a "medium" and a "publisher" parameter as sometimes they are not the same thing, instead of having a "website" parameter that commingles two not-always-identical things. Jo-Jo Eumerus (talk, contributions) 15:02, 3 September 2019 (UTC)

Well I want to point out that news doesn't only come from a "newspaper" anymore. - Knowledgekid87 (talk) 15:06, 3 September 2019 (UTC)

From this comment, it appears that Trappist sees this change as part of the advertised change periodical templates missing periodical parameter error messaging. However, the linked discussion shows {{cite journal}}, {{cite news}} and {{cite magazine}}. I seems that adding this error message to {{cite web}} has not been discussed, and in view of the apparent lack of consensus, should be reverted. Kanguole 16:16, 3 September 2019 (UTC)

Yes, that is what I think. That I omitted {{cite web}} from the discussion was merely an oversight on my part. The code that emits the missing periodical error message is the same for all of the periodical templates / parameters.

—Trappist the monk (talk) 16:31, 3 September 2019 (UTC)

It seems that few share your view that web sites should be treated like periodicals. Kanguole 16:51, 3 September 2019 (UTC)

"Works", in citation-speak, are the cited sources. They are abstractions (of the underlying material). For purposes of citing, the underlying material, be it a website, book, periodical, map, encyclopedia, etc. is not relevant. It follows they are treated the same in a consistent, well-defined citation platform. We don't care what the source is, as long as it can be identified and found in the most efficient manner. Traditionally, this meant that citations were designed around the way sources were classified and indexed. First, by name/author/date, then by classification/marketing number, more recently by digital indexing. Such classification was always based on complete units (works), as they would be expected to be searched for by the person looking for them (citations of fragments being a special case). In the world wide web, the "unit" of search, or work, is a so-called "site". The smallest web item, say a few characters text, cannot exist without a hosting site. Any citation that does not include this simple fact, which happens to be the pathway to verification, cannot really be a citation. It is something else. 69.193.220.107 (talk) 20:24, 6 September 2019 (UTC)

69.193.220.107, I grant your understanding of citations generally, especially wrt to physical media, but it's very unclear from what you've written whether you understand the difference between a

domain, and a URI, and which one corresponds to "work" and how well digital media correspond generally when considering document retrieval. The fact that you say "In the world wide web, the 'unit' of search, or work, is a so-called 'site' ", makes me think you don't understand it well, or maybe you made a slip of the tongue. Your lead-off claim about "website, book, periodical," being analogous based on that faulty understanding is therefore mistaken. Mathglot (talk

) 20:47, 6 September 2019 (UTC)

Actually there are many different technical terms for periodical. As many, or more, as there are for website. And that is not the point. The point is, citations are there solely for verification. Which means, they must accommodate solely the verifier. In a non-expert citation system like Wikipedia's, which if I am not mistaken is the first large-scale such system of its kind anytime anywhere, special considerations have to be applied. Including, paring down technicalities as much as it is possible without compromising validity. In writing a citation, I cannot assume that the reader would know the nuances or even the main building blocks of a network directory system or its underlying software infrastructure. If popular libraries were organized under such a view, nobody would be able to use them unless they knew the intricacies of the Dewey Decimal. We have to stick with what is the common, popularly known laymen's terms. Which doesn't mean that they will be incorrect. In broad terms, and as far as the experience of the vast majority of users is concerned, it is safe to assume that the meaning of "site" is unambiguous: it is where one goes to find stuff on the web. And that is it. Walk backwards from that, from where a user starts. You might arrive to the conclusion that not for any reason can the website name be left out of a citation. 98.0.246.242 (talk) 23:32, 6 September 2019 (UTC)

You might arrive at a different conclusion, after watching ten different users place five different things in the website param for the same source. Noting that url is unique and unambiguous and rarely misused, and "website" is none of the above, might lead you to the conclusion that making "url" required for a web page, and "website" merely informative and optional, was another way to go. Mathglot (talk) 00:09, 7 September 2019 (UTC)

But this is more because of the confusing documentation. The reason for many of these updates is because of the misuse of the parameters. This misuse is to an extent the result of below-par documentation. It is the responsibility of those who produce these changes to document them properly. I agree that citation writers have every right to expect clear-cut and plain documentation of everything the system does. However this is separate from the design rationale. 98.0.246.242 (talk) 01:27, 7 September 2019 (UTC)

Everyone complains about the documentation yet, when asked to help improve it, those same editors seem to always find something else to do ... I have admitted for years that I suck at documentation because my writing style is too technical, too strange, too wordy, too something, to make user documentation that I have written accessible to the general editing population. If you can see how our documentation can be made better, please help us fix it.

—Trappist the monk (talk) 03:02, 7 September 2019 (UTC)

"watching ten different users place five different things in the website param" - This issue was addressed in the citation tool, at my suggestion, by changing the label from "website" to "website name". Maybe the same fix could be applied to the parameter itself? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:02, 15 September 2019 (UTC)

'This has gone far enough. It's not a documentation issue but an issue of overreaching micromanagement by the maintainers of the citation template group who have an incorrect understanding of policy. I feel that the changes (to flag "incorrectly populated" parameters) have been put through unilaterally without due concensus are detrimental to the project. As highlighted already by fellow editors, the numerous red cs1-errors tags that have been appearing since the change do not always correctly identify parameters that are problematic. Please note that few WP articles about websites have

Same for 'dead-url' paramter... I see this is listed now as deprecated and replaced with url-status, but couldn't there be a bot or something to fix them first? Broken citations everywhere are not a good look I'd think... --IamNotU (talk) 12:10, 3 September 2019 (UTC)

What are the available options? Getting errors and not sure how to format properly. There should be a mechanism to automatically rename parameter labels of citations in production when such labels change. As a utility module perhaps. 108.182.15.109 (talk) 12:15, 3 September 2019 (UTC)

|dead-url= was deprecated in favor of |url-status=, which accepts 'dead', 'live', 'unfit', 'usurped', and 'bot: unknown' (without quotation marks of course), so the only parameters which will have changed are the first two. As for renaming, there is a bot task approved for that work to start now. --Izno (talk) 12:18, 3 September 2019 (UTC)

Wouldn't it have been better if the bot was left to run for a few weeks before this mandatory change was sprung on us without warning. Now we have surprised editors, surprised readers, links to unhelpful error messages with no useful clue how to fix it and even the template documentation has not been updated yet. A complete mess on practically every WP article that could have been easily avoided.  Stepho  talk  12:28, 3 September 2019 (UTC)

In the current template documentation, "url-status=live" is mentioned as the default value. This is not currently the case. The current default is "url-status=dead". 108.182.15.109 (talk) 12:31, 3 September 2019 (UTC)

Can confirm. Leaving it empty causes the citation to act as if the url is dead. PanagiotisZois (talk) 12:47, 3 September 2019 (UTC)

Yes please turn off these warnings until the bot has updated the parameters. – Thjarkur (talk) 12:36, 3 September 2019 (UTC)

I think it would make sense to keep the warnings, but only in preview while both parameters are supported. That would help prevent new |dead-url= tags from being added while minimizing the confusion of editors. --AntiCompositeNumber (talk) 12:49, 3 September 2019 (UTC)

I'm not sure it can be visible only in preview, is that the difference of a "warning" and an "error"? They should make sure to bot quickly and reduce this to a warning. JAGulin (talk) 13:54, 3 September 2019 (UTC)

Wikipedia:Bots/Requests for approval/Monkbot 16 —Trappist the monk (talk) 13:21, 3 September 2019 (UTC)

@Trappist the monk:Perhaps it might be a good idea to have the citation templates throw a special error message akin to "Parameter is being replaced, please change to Foo as appropriate" until the bot pass is done then switch back to the normal red error? Jo-Jo Eumerus (talk, contributions) 13:55, 3 September 2019 (UTC)

That's what the help link is for with a deprecated parameter. (An unknown parameter is a different message.) --Izno (talk) 14:08, 3 September 2019 (UTC)

The normal deprecated parameter text does not make it clear enough that there is a mass replacement effort underway and is probably too visible for this specific situation. Jo-Jo Eumerus (talk, contributions) 14:27, 3 September 2019 (UTC)

The changes in the module are proper. It is their implementation that is lacking. As it was suggested at ANI, there should have been a parallel implementation of aliases, with sufficient warnings about the impending changes. 108.182.15.109 (talk) 14:03, 3 September 2019 (UTC)

They both work at present. Here: "Title". Website. {{cite web}}: Check |archiveurl= value (help); Unknown parameter |deadurl= ignored (|url-status= suggested) (help). --Izno (talk) 14:06, 3 September 2019 (UTC)

In general, deprecated parameters should not emit red error messages. They should populate maintenance categories until they are brought down to reasonable levels, and then support removed. Then they can emit errors.

b

} 14:38, 3 September 2019 (UTC)

Echoing some of the other comments here regarding the rollout of this change, as well as the change itself. Why was it necessary to deprecate deadurl for this new param? And why was such a major change made, apparently, almost unilaterally? It seems to offer no obvious benefits over deadurl, and the rollout has caused an incredible amount of chaos across the project. JimmyBlackwing (talk) 21:03, 3 September 2019 (UTC)

Why has "deadurl=yes" been changed to "url-status=dead"? The latter is harder to remember, needs a hyphen, and there are more letters to type. What is the point of the change? SarahSV ^(talk) 00:03, 5 September 2019 (UTC)

cs1|2 has a bunch of parameters intended to hold urls. These all end in -url:

|archive-url=, |article-url=, |chapter-url=, |conference-url=, |contribution-url=, |entry-url=, |event-url=, |lay-url=, |map-url=, |section-url=, |transcript-url=

|dead-url= does not hold a url but, because it looks like it should, editors do use it to hold the dead url. |url-status= was the best name we could come up with that didn't end in -url and still conveyed the meaning that we were looking for.

—Trappist the monk (talk) 00:30, 5 September 2019 (UTC)

SV, I fully agree with this change. The new one is easier to read and its meaning is clearer. Any change that makes the cite templates easier to use and understand (as this one does) has my full support. The hyphen is an advantage (good for clarity), not a drawback. (OTOH, I disagree strongly with some of the other changes, but that's a matter for discussion elsewhere.) --NSH001 (talk) 00:48, 5 September 2019 (UTC)

Okay, that makes sense. Trappist and NSH001, thanks for explaining. Just one other question. Would it not be easier to remember "urldead?=yes/no". I was thinking the same recently about "etal?=yes/no", rather than "display-authors=etal". There is so much to remember with these templates, and a lot of it isn't in the toolbar. An extra few characters may not seem worthy of complaint, but when you spend a lot of time adding these templates, you long for simplicity, things that are easy to remember, and as few characters as possible to type. SarahSV ^(talk) 01:13, 5 September 2019 (UTC)

I suspect that we considered |url-dead= and rejected it because it is awkward in an English-grammar-sort-of-way. |etal= doesn't work because, besides authors, there are also contributors, editors, interviewers, and translators.

—Trappist the monk (talk) 01:26, 5 September 2019 (UTC)

The other valid values for |url-status= are "unfit" and "usurped", which would not make sense syntactically with a parameter name that included the word "dead", including the old |dead-url= parameter. As for the hyphen, CS1 was standardized long ago on hyphenated parameters when the parameter name contains more than one word. – Jonesey95 (talk) 02:42, 5 September 2019 (UTC)

Please change website equals back to url

This new change is crazy, disruptive, and does not appear to have consensus here. "URL" is much easier to remember, quicker to type in, and its something editors are used to doing. - Knowledgekid87 (talk) 13:05, 3 September 2019 (UTC)

@Knowledgekid87: You are mistaken. |url= remains entirely undeprecated. --Izno (talk) 13:20, 3 September 2019 (UTC)

Why the error message then saying "website=" is needed when a url is already provided for cite web? - Knowledgekid87 (talk) 13:21, 3 September 2019 (UTC)

|website= is a periodical parameter much like |journal= is a periodical parameter. It names the website because the website name is hidden in |url=.

—Trappist the monk (talk) 13:24, 3 September 2019 (UTC)

@Knowledgekid87: See this example for what |website= actually does: {{cite web|url=https://www.example.com/|website=ExampleWebsite |title=Webpage}} produces "Webpage". ExampleWebsite. --Izno (talk) 13:25, 3 September 2019 (UTC)

@Izno: I fixed your example to stop further misunderstanding. Another example: "Webpage". ExampleWebsite. PublisherName. -- JAGulin (talk) 14:13, 3 September 2019 (UTC)

"Website=" should not be mandatory then. - Knowledgekid87 (talk) 14:32, 3 September 2019 (UTC)

New error messages as of 2 September 2019

{{cite web}} displays new CS1 Error messages:

• Cite uses deprecated parameter |dead-url= (help)
• Cite web requires |website= (help) [a"publisher" parameter already exists]

The changes were probably added today and affect numerous citations (millions?). Are these permanent changes? And if so, where are they documented? Rfassbind – talk 12:30, 3 September 2019 (UTC)

Rfassbind, see #update to the cs1|2 module suite after 2 September 2019 above. The changes were made first, documentation is in the process of being updated, and bots are being written and modified to support the changes. As someone who previously didn't watch this page, they did catch me by surprise (but I guess that's what the big red warnings are for). --AntiCompositeNumber (talk) 12:44, 3 September 2019 (UTC)

Also affects {{cite news}} - error message is "Lua error in Module:Citation/CS1 at line 802: Argument map not defined for this variable." This is an incredibly poor implementation, given literally thousands of articles will be affected. If a bot is going to 'fix' them then when and how? I don't want my watchlist clogged up with 5,000 bot changes... GiantSnowman 13:08, 3 September 2019 (UTC)

It appears that this whole mess was made without first thinking of the effects done. - Knowledgekid87 (talk) 13:10, 3 September 2019 (UTC)

Can someone restore the old version until problems are resolved? Dentren | ^Talk 13:13, 3 September 2019 (UTC)

@Trappist the monk: Please revert your change until consensus can be established and/or there is a fix to this mess. - Knowledgekid87 (talk) 13:18, 3 September 2019 (UTC)

@GiantSnowman: That particular error is likely because of Ivanvector's revert on only one of the 7 module pages, which Ttm has now undone. --Izno (talk) 13:22, 3 September 2019 (UTC)

It's at ANI, and the original lack of discussion is paramount. ——SerialNumber54129 13:23, 3 September 2019 (UTC)

Discussion to undo all of the changes

Discussion: Wikipedia:Administrators' noticeboard#Proposal to overturn the mass change made to Module:Citation/CS1 - Knowledgekid87 (talk) 13:41, 3 September 2019 (UTC)

"mode = CS1" raises warning

@Trappist the monk: Sorry to ping you, but I know you're the expert even if I may be wrong about this. Was mode parameter check among the changes in this batch? Is it too complicated or undesirable to make value lowercase before use? Also, the Category:CS1_errors:_invalid_parameter_value seems to keeps track of each article, but not the offending Template itself. When I fixed OED 200 errors were solved in one go. If the template/doc pages were listed in a sub-category it would make it easier to fix those first. -- JAGulin (talk) 11:28, 4 September 2019 (UTC)

In cs1|2 all parameter names and all special keyword values are supposed to be lowercase. The change that enforced lowercase happened because a non-lowercase keyword caused Lua script errors (this discussion though the script error no longer shows.

Yeah, subcats might be nice but they are most times not required yet must still be maintained if they exist. It is possible to detect namespace so for pages in the Template: namespace it might be possible to add a sortkey to the category link so templates would be grouped together. I think that I remember reading that there is a standard Greek-letter sortkey specifically chosen for templates; don't remember where I read that.

—Trappist the monk (talk) 11:51, 4 September 2019 (UTC)

Usually you go with a lowercase Greek letter. β → Book:, τ → Template:, ω → Wikipedia:, etc...

b

} 00:33, 5 September 2019 (UTC)

@

WP:CAT#T. I've suggested to reinstate it. @Trappist the monk: As long as the category is consistent, you can choose any way to sort. *τ {{PAGENAME}} may be the sortorder I suggest for templates, in cases like this when I want to gather them in the beginning of the list. All of this is in vain if no templates show up in the category, but I would think that at least the doc page should be listed. JAGulin (talk

) 16:28, 5 September 2019 (UTC)

There's no real standardized thing, but you can check

b

} 18:54, 5 September 2019 (UTC)

@Headbomb:, @Jagulin:, @Trappist the monk:: {{Namespace Greek}}. All the best: Rich Farmbrough, 11:58, 28 September 2019 (UTC).

Here is a petscan query that lists all templates in CS1 error categories. It should be perused with the following caveats: (1) there are strong objections to the "missing periodical" errors that are currently being tracked, so it may be unwise to "fix" those errors before there is further discussion; and (2) some template pages, such as Template:Cite Memoria Chilena, should not be "fixed" just because the template page itself has errors. There have been about 40 or 50 semi-permanent residents on that page for a few years. – Jonesey95 (talk) 14:12, 4 September 2019 (UTC)

@Jonesey95: Great, your query is a good way to filter. I was able to modify it to the category I wanted, but as I expected it found no templates.

@Trappist the monk: Thanks for confirming that this was an intentional change. Specifically the Limited petscan also confirms that there are no Templates in "CS1 errors: invalid parameter value". It specifically mentions filtering some namespace out, but Template is not listed among them. Could you check for it?

If it doesn't interfere with anything else, it's fine to put the templates in the same category. May I suggest using greek tau to get the templates gathered on top? If there's a better choice, you can change later.

I think that the Template:GRIN should show up, but if not, the Template:GRIN/doc#Samples also should. --JAGulin (talk) 17:45, 4 September 2019 (UTC)

Changes to templates and modules can take days, sometimes months, to affect Category membership of pages that transclude those templates, so you may have to resort to an "insource" search of pages to find what you are looking for. This search currently yields 30 pages for me, for example, but I'm going to tidy them up anon. – Jonesey95 (talk) 17:56, 4 September 2019 (UTC)

Again you show that the simple tricks are also the most effective. Thanks for cleaning those up, it effectively reduced the warnings in "my category". That said, I think it would be useful to have the templates in the "CS1 errors: invalid parameter value" category, so if it wasn't due to lag it should be fixed. Over and out, JAGulin (talk) 19:59, 4 September 2019 (UTC)

Any Template-space pages that I did not catch and fix today will eventually appear in the category if the Template page itself contains an error. Sometimes, templates cause errors only when they are used; those instances will need to be caught by examining pages in the error category.

As of this time stamp, there are 338 pages in Category:CS1 errors: invalid parameter value. Most of them are due to |deadurl=No/Yes (change to |url-status=live/dead, respectively) and to |nopp=Y (change "Y" to "y"). – Jonesey95 (talk) 21:04, 4 September 2019 (UTC)

Cite ssrn, where it is?

The change log says 'add support for {{

cite ssrn/new

}}.

—Trappist the monk (talk) 14:35, 6 September 2019 (UTC)

@

b

} 14:43, 6 September 2019 (UTC)

Did you look? There is no Lua code in that template sandbox: There is an {{invoke:}} (not Lua code), {{documentation}} (not Lua code), and <includeonly>...</includeonly> & <noinclude>...</noinclude> tags (not Lua code). The invoke should not point to the module sandbox.

Template needs documentation.

—Trappist the monk (talk) 15:19, 6 September 2019 (UTC)

I have created the template and a draft documentation page (copied from cite web docs). The documentation needs examples, and probably adjusting of the transcluded contents, provided by someone who knows what the new template is for and how it is used. I think there are a couple of other pages that try to list all of the CS1 templates; those need to have the new template added to their tables/lists, with appropriate descriptions. – Jonesey95 (talk) 17:32, 6 September 2019 (UTC)

Category redirection over deletion

Since there are many pages and edit summaries that link to the old (and recently mostly deleted categories), wouldn't it be better to {{

I don't know how many edit summaries link to the various renamed categories. Most links to the old-named categories are residue from the change to the new name in non-article namespaces. This because any page that isn't an article won't be refreshed with the frequency that article-namespace pages are refreshed.

Take for example Category:CS1 maint: Multiple names: authors list. As I write this, there are 5k+ pages linking to that category Of those pages, there are three in article namespace:

Manchester City F.C. supporters (ve edit)

Sarracenia × swaniana (from ro:Sarracenia swaniana via Content translation)

Albert Schweitzer High School (Erlangen) (from de:Albert-Schweitzer-Gymnasium (Erlangen) via Content translation)

All three of these have raw (not created by the current versions of a cs1|2 template) old category link because of that abomination that is ve (copying named references from one page to another) or because the article was created by the auto-translation process (whatever that is) from another language Wikipedia.

If we redirect all of these old-named categories, it is (I think) harder to find these buggered up articles because they don't get listed in the old-name category but, instead, get lumped in with all of the articles in the new-named category.

—Trappist the monk (talk) 17:15, 29 September 2019 (UTC)

Category:CS1: long volume value should probably display a cs1-maint (the green type) message, right? Currently it has no visual output. – Finnusertop (talk ⋅ contribs) 16:29, 29 September 2019 (UTC)

See this discussion.

—Trappist the monk (talk) 16:37, 29 September 2019 (UTC)

Without having read the initial discussion, my first thought is that "long volume value" is not an inherent problem, although many of these cases may justify the addition of a |volume-subtitle= parameter or something to that effect. -BRAINULATOR9 (TALK) 01:02, 30 September 2019 (UTC)

What is the correct resolution for invisible character errors in citations with titles using zero-width joiners between emoji, as in the citation on 2019 in American television? —Ost (talk) 20:47, 30 September 2019 (UTC)

You could leave it out; the rendering of the emoji on my win10 machine at en.wiki is different from the rendering of the emoji at twitter. If you must keep the emoji, replace the unicode zwj with its html equivalent:

{{cite tweet|number=1155848220775452673|user=TeenNick|author=TeenNick|title=An all new season of #HunterStreet is coming to TeenNick TONIGHT at 7:30/6:30p 🕵️‍♀️ |date=July 29, 2019|accessdate=September 26, 2019}}

TeenNick [@TeenNick] (July 29, 2019). "An all new season of #HunterStreet is coming to TeenNick TONIGHT at 7:30/6:30p 🕵️‍♀️" (Tweet). Retrieved September 26, 2019 – via Twitter.

—Trappist the monk (talk) 21:50, 30 September 2019 (UTC)

Self-explanatory.

I suspect that this is because {{cite compare}} no longer obeys |old=no; any value causes the transclusion of {{cite xxx/old}}. In this case, {{cite arXiv/old}} unconditionally adds Category:Articles with missing Cite arXiv inputs regardless of the namespace. The fix for this is at {{cite compare}} to make it obey |old=no. Pinging Editor Izno?

—Trappist the monk (talk) 10:35, 3 October 2019 (UTC)

Yes, I flipped the intent of |old= and made it so that any value caused the old template to display. The correct fix is to remove |old=no in this case. --Izno (talk) 13:17, 3 October 2019 (UTC)

Having |old=no behave the same as |old=yes is counter-intuitive. I suggest fixing that, or at least cleaning up all former uses that depended on the previous behavior. – Jonesey95 (talk) 14:28, 3 October 2019 (UTC)

I will not be doing the latter as I saw it as zero-value-add to do so. I think you should instead change your understanding of the parameter as to the former per my earlier comment, but I won't revert someone who really feels that's the Way It Should Be (that only |old=yes should trigger display of the old template). --Izno (talk) 14:58, 3 October 2019 (UTC)

These two identically formatted citations, as found in Abelian group:

• {{cite book |last=Fuchs |first=László |date=1970 |title=Infinite Abelian Groups |series=Pure and Applied Mathematics |volume=36-I |publisher=[[Academic Press]] |mr=0255673 }}
• {{cite book |last=Fuchs |first=László |date=1973 |title=Infinite Abelian Groups |series=Pure and Applied Mathematics |volume=36-II |publisher=[[Academic Press]] |mr=0349869 }}

produce inconsistent formatting: the first book's volume number is bolded and the second is not.

• Fuchs, László (1970). Infinite Abelian Groups. Pure and Applied Mathematics. Vol. 36-I.
  MR 0255673
  .
• Fuchs, László (1973). Infinite Abelian Groups. Pure and Applied Mathematics. Vol. 36-II.
  MR 0349869
  .

Maybe we should fix this? —David Eppstein (talk) 06:06, 5 October 2019 (UTC)

This is the 4-character-limit issue:

|volume=36-I → 4 characters

|volume=36-II → 5 characters

—Trappist the monk (talk) 11:41, 5 October 2019 (UTC)

Really books should display this as "Vol. 36-I", rather than "36-I".

b

} 13:50, 5 October 2019 (UTC)

I agree. Bolding should be reserved for the situations where we use the journal-style formatting of page numbers. Kanguole 16:29, 5 October 2019 (UTC)

It should also group volume with pages, rather than separate them with the publisher.

b

} 17:31, 5 October 2019 (UTC)

Unlike magazines, I disagree. The volume of a book is more a function of its title. Imzadi 1979 → 21:21, 5 October 2019 (UTC)

Not so for series of books, which is when |volume= should be used.

b

} 21:26, 5 October 2019 (UTC)

Yes, in this case the volumes should definitely be immediately after the series, not the title. The next most tight grouping would be that the series+volume should be adjacent to the publisher. It would be wrong to move the volume past the publisher and away from the series to put it closer to the page numbers. —David Eppstein (talk) 21:32, 5 October 2019 (UTC)

I'm thinking something like

• Fuchs, László (1973). Infinite Abelian Groups. Pure and Applied Mathematics. Vol. 36-I. pp. 1–10. Academic Press.
  MR0349869
  .

Out of curiosity, what is the urgency? This has been discussed since the change to conditional bolding was being considered, some years back. Why does this keep popping up? Either leave as is and provide a better explanation for the apparent inconsistency, or apply uniform font weight. It is a bit tiresome to keep revisiting the same issues. 72.43.99.138 (talk) 15:14, 6 October 2019 (UTC)

Why does this keep popping up? Because it's an unresolved problem? — UnladenSwallow (talk) 19:39, 6 October 2019 (UTC)

Yes, we know. The question is, why is it still unresolved after it has been brought up multiple times? As was suggested, either change the bolding, or explain it better so it isn't brought up so often. 98.0.246.242 (talk) 01:37, 7 October 2019 (UTC)

Here is some things to cleanup, most related to citations. I think the related bug in VE has been fixed. --Izno (talk) 18:03, 8 October 2019 (UTC)

I am skeptical of any claimed fixes to ve. Are you referring to this one: phab:T209493?

—Trappist the monk (talk) 18:08, 8 October 2019 (UTC)

Here's an edit adding templatestyles nonsense on 4 October 2019. It doesn't look like this bug is fixed. – Jonesey95 (talk) 18:41, 8 October 2019 (UTC)

In

• Abazov, V.M.; et al. (
  PMID 17501561
  .

That is normal. The module interprets the resulting pipe as an end-of-field character. You could try <nowiki>. 98.0.145.210 (talk) 12:45, 13 October 2019 (UTC)

Another option would be using U+200D ZERO WIDTH JOINER (&zwj;) after the pipe template magic word. In the original citation, the module sees two pipes in succession, therefore it ignores the additional. 72.43.99.138 (talk) 14:06, 13 October 2019 (UTC)

That is not normal {{!}} is specifically designed to render, not be treated as yet another | delimited. See e.g. {{xt|{{!}}V<sub>tb</sub>{{!}}}} which renders exactly as intended, e.g. |V_tb|. — Preceding unsigned comment added by Headbomb (talk • contribs) 18:33, 13 October 2019 (UTC)

I agree. Using the standard workaround for vertical bars in templates should work. It is a bug that it does not. I note, however, that even without that issue the title is not quite formatted correctly. If you look at the original source, ${\displaystyle |V_{tb}|}$ is a mathematics formula in which the letters are all italicized. So it would be rendered better as

• {{cite journal |last=Abazov |first=V.M. |collaboration=[[DØ Collaboration]] |display-authors=etal |year=2007 |title=Evidence for production of single top quarks and first direct measurement of <math>|V_{tb}|</math> |journal=[[Physical Review Letters]] |volume=98 |issue=18 |pages=181802 |doi=10.1103/PhysRevLett.98.181802 |arxiv=hep-ex/0612052 |bibcode=2007PhRvL..98r1802A |pmid=17501561 |hdl=10211.3/194387}}
• Abazov, V.M.; et al. (
  DØ Collaboration
  ) (2007). "Evidence for production of single top quarks and first direct measurement of ${\displaystyle |V_{tb}|}$".
  PMID 17501561
  .

—David Eppstein (talk) 18:44, 13 October 2019 (UTC)

The italics thing is besides the point. |V_tb| would equally fail to render correctly.

b

} 02:50, 14 October 2019 (UTC)

And it would not render with the proper serif font for math variables, again. In mathematical formulas, the correct font matters. Using a different font can often mean that you are referring to a completely different variable, or something undefined. If you don't want to use <math>, the other alternative for getting something close to acceptable mathematical formula rendering is the {{

PMID 17501561. — Preceding unsigned comment added by David Eppstein (talk • contribs

) 03:31, 14 October 2019 (UTC)

Again, that's besides the point. And variables certainly don't have to be rendered in serif fonts.

b

} 05:06, 14 October 2019 (UTC)

If you want to preserve the meaning in a mathematical text where the author is using the default serif italic for one meaning and \mathsf (LaTeX-style sans-serif) for a different meaning (and maybe bold upright and outlined upright for other meanings), then yes, they do. If you're writing something where you're choosing your own variable names, then you're free to make them sans, but they still need to stay consistently formatted rather than inheriting formatting from the surrounding text. —David Eppstein (talk) 05:36, 14 October 2019 (UTC)

Use of <math>...</math> is problematic because MediaWiki took away our ability to see the underlying content of the tag. The content of <math>...</math> is rendered visually as an image; logged in editors can select one of three styles according to a setting in their Special:Preferences. When MediaWiki took away our ability to see the image's underlying makeup, we lost the ability to render any sort of meaningful metadata. All that Module:Citation/CS1 sees is a math stripmarker that looks something like this: ?'"`UNIQ--math-0000001C-QINU`"'? (the '?' characters represent the delete character). Because we can no longer see what that stripmarker represents, all title metadata for titles with <math>...</math> in them get an error message (MATH RENDER ERROR) in place of the <math>...</math> content. So, for the example template, cs1 produces this article title metadata:

&rft.atitle=Evidence+for+production+of+single+top+quarks+and+first+direct+measurement+of+MATH+RENDER+ERROR

Cannot do anything about that until Lua is allowed access to the content of <math>...</math> tags. See the phabricator ticket.

—Trappist the monk (talk) 13:34, 14 October 2019 (UTC)

Doesn't seem like this ticket will be resolved any time soon. 72.43.99.138 (talk) 14:21, 14 October 2019 (UTC)

Interesting. Using {{pipe}} instead works as it should, so this has something to do with template expansion vs magic word rendering. It seems that the magic word is processed after the field has been formatted (with quote marks). If that is the case, instead of the module rendering |"{delimiter} it renders "{delimiter}{delimiter}. 98.0.246.242 (talk) 01:44, 14 October 2019 (UTC)

EDIT: or maybe not. Since the magic word works properly when followed by a zero width joiner, my idea that it is processed after the quote mark formatting is a dud. Something else is the culprit. 98.0.246.242 (talk) 01:48, 14 October 2019 (UTC)

Use of {{pipe}} is discouraged because it produces improper metadata.

—Trappist the monk (talk) 13:34, 14 October 2019 (UTC)

Metadata is irrelevant. I was only using {{pipe}} to illustrate that the template expands properly inside the |title= field, unlike the magic word/variable, which apparently trips when display format is applied on the parameter. 72.43.99.138 (talk) 14:08, 14 October 2019 (UTC)

Metadata is relevant to those who consume these citations via the metadata.

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

There may be some sort of interaction between the magic word/variable {{!}} and the script_concatenate function in Module:Citation/CS1 (lines 572-580). The {{!}} variable works as it should when inserted in other fields, but not for |title= (and its various aliases). The function that formats |title= (format_chapter_title) uses the function script_concatenate. See line 714, and the code comment: -- <bdi> tags, lang atribute, categorization, etc; must be done after title is wrapped. This also appears in section "format main title" starting in line 3110 (the pertinent statements are in lines 3126-3140). So |title= formatting may have something to do with the disappearing variable after all? 72.43.99.138 (talk) 13:24, 14 October 2019 (UTC)

Fixed in the sandbox: