Help talk:Citation Style 1/Archive 74

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

Archive 70

←

Archive 72

→

Invalid DOI

In

Buckley, Walter; Schwandt, David; Goldstein, Jeffrey A. (2008). "An introduction to "Society as a complex adaptive system"". E:CO Emergence: Complexity & Organization. 10 (3): 86–112. doi:10.emerg/10.17357.06e9a4b2212fd8b56de2bd2009e3a348. Retrieved 2020-11-02. {{cite journal}}: Check |doi= value (help)

The DOI is clearly invalid. The format is 10.####/ or 10.#####/ and nothing else. Headbomb {t · c · p · b} 05:18, 4 January 2021 (UTC)

already fixed.

—Trappist the monk (talk) 12:45, 4 January 2021 (UTC)

Why no archive-chapterurl?

If a book is available online, we enter |url=, and if this URL is dead we can enter |archive-url=. But there is no such equivalent for chapter-specific links, i.e. |chapterurl=. Is there is specific reason for that? (for a specific example, I could've just used such an option here.) --bender235 (talk) 17:25, 2 January 2021 (UTC)

That would be this template?

{{cite book |first=Michael P. |last=Barnett |authorlink=Michael P. Barnett |chapter=Symbolic calculation in the life sciences: trends and prospects |title=Algebraic Biology 2005 |series=Computer Algebra in Biology |editor-first=H. |editor-last=Anai |editor2-first=K. |editor2-last=Horimoto |publisher=Universal Academy Press |location=Tokyo |year=2006 |chapterurl=https://web.archive.org/web/20060616135155/http://www.princeton.edu/~allengrp/ms/annobib/mb.pdf }}

That can be written as:

{{cite book |first=Michael P. |last=Barnett |author-link=Michael P. Barnett |chapter=Symbolic calculation in the life sciences: trends and prospects |title=Algebraic Biology 2005 |series=Computer Algebra in Biology |editor-first=H. |editor-last=Anai |editor2-first=K. |editor2-last=Horimoto |publisher=Universal Academy Press |location=Tokyo |year=2006 |chapter-url=http://www.princeton.edu/~allengrp/ms/annobib/mb.pdf |archive-url=https://web.archive.org/web/20060616135155/http://www.princeton.edu/~allengrp/ms/annobib/mb.pdf |archive-date=2006-06-16}}

Barnett, Michael P. (2006). "Symbolic calculation in the life sciences: trends and prospects" (PDF). In Anai, H.; Horimoto, K. (eds.). Algebraic Biology 2005. Computer Algebra in Biology. Tokyo: Universal Academy Press. Archived from the original (PDF) on 2006-06-16.

—Trappist the monk (talk) 17:58, 2 January 2021 (UTC)

However, since there can be both, |chapter= and |title= as well as |chapter-url= and |url=, this model could be extended so that if an |archive-chapter-url= parameter would be given, it would be taken as archive link for |chapter-url= instead of |archive-url= (and |archive-url= for |url=). I have run into citations where it would have been desirable to specify independent archive links for chapters and work titles.

--Matthiaspaul (talk) 15:57, 3 January 2021 (UTC)

There are quite a few URL-related arguments and IMO having separately named archive-url/archive-date/url-status for each is a lot of complication. There is {{webarchive}} for those archive URLs that don't fit the current model. -- GreenC 16:14, 3 January 2021 (UTC)

Of course, there is a limit of what we can link to, but I find {{webarchive}} too verbose to use - readers typically care about the fact that they can access an archived link, but don't care about the name of the archiving service.

Also, at least in the case of linking chapters, our citation templates already support most of it, and an archive link for chapters could probably be integrated into the displayed output in less obtrusive ways than the longer explanations that would probably be necessary to establish the connection to chapters when the link would be provided by a separate template. Also, maintenance would be easier.

--Matthiaspaul (talk) 15:30, 7 January 2021 (UTC)

Range of hyphenated page numbers?

What is the correct markup for a range of hyphenated page numbers? Is |pages=4-5{{snd}} 4-7 (4-5 – 4-7) correct or should it be |pages=4{{hyphen}}5{{snd}}4{{hyphen}}7 (4-5 – 4-7)? Shmuel (Seymour J.) Metz Username:Chatul (talk) 15:17, 3 January 2021 (UTC)

Use commas between hyphenated ranges. Do not use {{snd}}. It doesn't play nice with the metadata. 64.61.73.84 (talk) 15:44, 3 January 2021 (UTC)

(64.61.73.84)'s answer does not give the correct meaning. The meaning of Shmuel (Seymour J.) Metz Username:Chatul's post is that the information in the Wikipedia is supported by information on pages 4-5, 4-6, and 4-7. You could use a spaced n-dash, like this: |pages=4-5 – 4-7. Or you could write |pages=4-5 to 4-7. Jc3s5h (talk) 16:12, 3 January 2021 (UTC)

Or you can write |pages=4-5-4-7 (all simple keyboard hyphens) and let cs1|2 figure out the rendering:

{{cite book |title=Title |pages=4-5-4-7}}

Title. pp. 4-5–4-7.

—Trappist the monk (talk) 16:58, 3 January 2021 (UTC)

Another option is to put the value in |at=, anticipating that well-meaning editors will come along and mangle the carefully constructed page range. |at=pp. 4-5–4-7 should work. – Jonesey95 (talk) 18:51, 3 January 2021 (UTC)

I should have RTFM. The documented way to handle this is |pages=((4{{hyphen}}5–4{{hyphen}}7)), where the thing in the middle is an n-dash. Jc3s5h (talk) 18:55, 3 January 2021 (UTC)

Actually, TFM spells out what to do for |page=hyphenated-number and for |pages=simple-range, but does not spell it out for a range of hyphenated numbers. Thanks. Shmuel (Seymour J.) Metz Username:Chatul (talk) 19:48, 3 January 2021 (UTC)

I think, it covers this case quite good already (without avoiding the redundancy that would be necessary to add to spell it out in even more explicit terms). But feel free to further improve on it.

--Matthiaspaul (talk) 15:34, 7 January 2021 (UTC)

Documentation bloat

I am concerned that the documentation for these templates, both Help:Citation Style 1 and Template:Citation Style documentation, is becoming bloated with redundant prescriptive injunctions, which degrade its value as documentation. In this case, the admitted purpose is to further a position in a dispute on this talk page, but the problem is broader, and has been going on for some time.

Bloated documentation wastes users' time, and makes it harder for them to find the information about the templates that they seek. The documentation should define the meaning of each parameter concisely, and not expand with polemics on what they should not be used for, especially when this is already a logical consequence of the definition. Kanguole 22:26, 4 January 2021 (UTC)

Only seeing this now... I would normally agree, but if the existing documentation (per the very existence of the discussion at Help_talk:Citation_Style_1#Italics_2) does not prevent editors from abusing parameters for stylistic reasons, the documentation apparently is not clear enough for some...

(The purpose of my edit was to improve that situation/documentation by stating what should be obvious, but apparently is not, not to further any position in a dispute.)

--Matthiaspaul (talk) 23:25, 4 January 2021 (UTC)

I tend to agree with the points Matthiaspaul is making. But the OP makes a point worth examining, especially regarding sections like "What's new", "Deprecated parameters", "Recently added parameters" etc. that have been ripe for forking since forever. Perhaps the OP can provide other examples of, in his opinion, existing bloat. Here's the thing: a correct baseline imo for a project like Wikipedia is to assume that people who don't know how to write citations are providing them for people who don't know how to read them. Disregard the quantum-magnitude infinitesimal number of people involved in these discussions (compared to the universe of daily unique visitors). If this is the encyclopedia than (almost) anyone can edit, it follows that this is the encyclopedia in which anyone (everyone) can (should) provide reliable citations. To the satisfaction (verification ease & ability) of anybody (everybody) else.

That is not to say that the documentation doesn't have problems. There are many, and not all of them are the result of "bloat". 98.0.246.242 (talk) 00:46, 5 January 2021 (UTC)

Italics 2

I know that sources like PBS, NPR, CNN, ABC, NBC, BBC, etc. should not be italicized. We save that for newspapers and magazines. Where is the MoS guideline for when NOT to italicize those listed news sources? An editor seems to think it makes no difference, and they are changing the citations all over the place so that those agencies are italicized. When I'm in doubt, I just look at the article for the source and see how it's done there, because I know that other editors have followed the MoS. -- Valjean (talk) 01:20, 25 November 2020 (UTC)

Can you provide specific examples. 98.0.246.242 (talk) 02:28, 25 November 2020 (UTC)

This is just one example which changes the correct format to italicized format. That editor does this a lot. I have tried to discuss this with them to no avail, hence my need for better information. Where is the MOS guideline for this? -- Valjean (talk) 02:36, 25 November 2020 (UTC)

It seems that the italics appear as a result of swapping |publisher= for |work=. The "work" is what is generally considered as the source, and this (unlike "publisher") is emphasized, in most cases with italic type. I would recommend a compromise: use the website (e.g. www.npr.org) as the "work", and NPR as the "publisher" of such work. And let the software format them accordingly. 69.94.58.75 (talk) 12:30, 25 November 2020 (UTC)

This is related to: User talk:Citation bot § Unhelpful changes? You did not like the answers that you got there so are asking elsewhere? Your posting here seems to be the same, more-or-less, as this: Wikipedia talk:Manual of Style § Italics...help. I'm pretty sure that you should not ask the same question in multiple venues because doing that is considered to be disruptive.

How do you know that sources like PBS, NPR, CNN, ABC, NBC, BBC, etc. should not be italicized? In cs1|2, the name of the source (the publisher's work) is italicized. If the source is a website, the name of the website is italicized; if the source is a magazine, journal, newspaper, or other periodical, the name of the magazine, journal, newspaper, or other periodical, is italicized; if the source is a book, the name of the book is italicized; if the source is a corporate entity initialism or broadcaster call-sign, the initialism or call-sign is italicized. This applies to both physical an online sources. It does not matter if the initialism of a cited source is the same as the initialism of the business that produced it.

I disagree to some extent with what the IP editor wrote. At Help:Citation Style 1 § Work and publisher is this:

Do not append ".com" or the like if the site's actual title does not include it ... and omit "www."

and this:

The "publisher" parameter should not be included for widely-known mainstream news sources, for major academic journals, or where it would be the same or mostly the same as the work.

—Trappist the monk (talk) 14:54, 25 November 2020 (UTC)

Yes this is a pretty confusing guidance (re: website name). It should be made clear that what is expected is the dba (doing business as) name, not the website title (the index or main page html title tag) or the domain/subdomain FQDN. However I don't know if dbas are indexed. Page titles and domains do, and therefore should be easier/faster to find. 50.75.204.50 (talk) 19:48, 25 November 2020 (UTC)

Hmmmm.... So why not go to these articles (PBS, NPR, CNN, ABC, NBC, BBC) and try to italicize them? See what happens. Then take the resulting edit wars to ArbCom or some appropriate drama board. I'd like to see a final decision, because I keep getting conflicting answers. I'd really like to know, but I'm not sure where is the best place to ask. Some places don't answer. -- Valjean (talk) 16:45, 25 November 2020 (UTC)

So why not go to these articles (PBS, NPR, CNN, ABC, NBC, BBC) and try to italicize them? Why would I want to do that? The articles are about those entities as businesses; we do not cite the business, we cite the business' work (its programming, its articles, etc), and the work, in cs1|2, is italicized.

—Trappist the monk (talk) 16:58, 25 November 2020 (UTC)

What's cs1|2? -- Valjean (talk) 17:19, 25 November 2020 (UTC)

Shorthand for "Citation Style 1 and 2". This help page is about them ie. the suite of templates such as cite web, cite news, etc..-- GreenC 17:23, 25 November 2020 (UTC)

Now I feel dumb. I have never used this page before. Thanks. -- Valjean (talk) 18:18, 25 November 2020 (UTC)

This has come up before – because the template only "allows" us to set websites in italics, and/or how every publishing organisation has been redefined, by cite template editors and partly through creepage at the MOS, as a "work". Plenty of examples were mentioned here in past discussion(s). The one that comes to mind is the music database AllMusic: as a result of the title being rendered italic in citations, some editors then italicise AllMusic in prose "for consistency". Which is ridiculous; and italicised BBC, NPR, PBS, etc, could well result from that also. It's not as if readers are left confused and dizzy by a roman (so-called) "work" in a citation, but that sort of rationale has been put forward here as a reason that each and every website must be italicised. Seems to me it's more a case of obsessiveness by editors who just think of cite templates in isolation (similar problem, eg, when editors focus solely on infoboxes from article to article, and not on how the infobox works with the article in question).

There was some discussion elsewhere, from memory, about coming up with a sort of "cite organisation" which would allow for non-italicised web sources. I think that would be a great idea. Until then, you default to writing out the relevant citations manually, avoiding the templates altogether. JG66 (talk) 17:32, 25 November 2020 (UTC)

JG66, this is an area where I confess to ignorance. I have been editing here since 2003, but have never gotten this fully explained. I don't fully understand the parameters in templates, but I know that ~~publisher= and website= produce italics, and work= does not,~~ website= and work= produce italics, and publisher= does not, so I use the one which will produce the "right" result, but that may not be the right approach.

I have gotten my cues (for how I should italicize in references) by looking at our articles. If the article uses italics, I use them in references and text, and if not, I don't. That's why I don't italicize sources like these (PBS, NPR, CNN, ABC, NBC, BBC), and do italicize The New York Times, The Guardian, etc. Am I wrong and/or totally naive? Is it really more complicated than that? I really appreciate the help, advice, and AGF. -- Valjean (talk) 18:30, 25 November 2020 (UTC)

—Trappist the monk (talk) 18:36, 25 November 2020 (UTC)

Oops! I remembered wrong. That should be "website= and work= produce italics, and publisher= does not." Fixed above. Here are some examples:

website= Mayer, Jane (November 25, 2019). "The Inside Story of Christopher Steele's Trump Dossier". The New Yorker. Retrieved November 27, 2019.
website= Borger, Julian (October 7, 2017). "The Trump–Russia dossier: why its findings grow more significant by the day". The Guardian. Retrieved December 28, 2017.
work= Elfrink, Tim; Flynn, Meagan (February 27, 2019). "Michael Cohen to testify that Trump knew of WikiLeaks plot". The Washington Post. Retrieved February 27, 2019.
publisher= (plus manual italicizing for Fresh Air) Gross, Terry; Simpson, Glenn; Fritsch, Peter (November 26, 2019). "Fusion GPS Founders On Russian Efforts To Sow Discord: 'They Have Succeeded'". NPR. Fresh Air

So what's the best way to do this? -- Valjean (talk) 18:54, 25 November 2020 (UTC)

The New Yorker is a magazine so {{cite magazine}} and |magazine=. Both The Guardian and The Washington Post are newspapers so {{cite news}} and |newspaper=. Fresh Air isn't a news program nor is it a journal or a magazine or a newspaper, so {{cite web}} (because you included a url) or because it's aired periodically (daily where I live) you might use {{cite periodical}} (a redirect to {{cite magazine}}) and |work=[[Fresh Air]]. You can include or omit |publisher=[[NPR]] as you choose. Hanging the program name after the cs1|2 template as you did means that the name is not included in the citation's metadata (for those who consume our citations using various machine tools).

—Trappist the monk (talk) 19:14, 25 November 2020 (UTC)

Valjean, that is the situation as I see it also – "If the article uses italics, I use them in references and text ..." It's logical (unless one's a template obsessive, it seems) and, as I've said, it ensures editors don't go and work the other way by deciding to italicise AllMusic, NPR, etc, because the word's italicised in references.

There was a discussion here early in the year which might be relevant: Help talk:Citation Style 1/Archive 63#This passage in the documentation. I believe it was Tenebrae (there or elsewhere) who outlined the "cite organisation" option, and laid out other reasons why italicising each and every website was either wrong or potentially confusing. JG66 (talk) 13:29, 28 November 2020 (UTC)

Yes, in spite of all the well-meaning advice above, I'm still confused. It can't be right that all sources in references should be italicized, but that's what some editors are doing. We need clearer guidelines, with very specific, site by site, instructions, a literal list, just like we have a specific list at WP:RS/P. There shouldn't be any rubbery wiggle room in those instructions.

Either The New York Times is always italicized or it's never italicized. What is it?

The list should also specify the ideal template to use. -- Valjean (talk) 16:30, 28 November 2020 (UTC)

The list should also specify the ideal template to use – my answer would be always use {{Citation}} for all citations. If you like full stops/periods all over the place, then add |mode=cs1. I'm sure that many editors would strongly disagree, which is why the list should not specify the ideal template to use. Peter coxhead (talk) 17:15, 28 November 2020 (UTC)

Sources in citations are not italicized, they are emphasized using italics. This is a not simply a typographical convention, it has semantic meaning, so a reader can immediately recognize what source it is they should be looking for. Formatted citations are terse, utilitarian statements employing a certain quasi-shorthand. Their style follows their syntax conventions. In that syntax, the source or work is paramount. But anyone is free to use a different citation format, or none (freehand). The objective is to give the reader a quick & easy way to verify what is claimed in text. The best-looking and best-articulated article means nothing if it cannot be verified. This does not require templates, formatted citations, or specific styles. As for the narrow case of template selection, I think one can only make recommendations. Different templates have slightly different format/syntax options or output, and there is a continuing effort to match them to the relevant sources. 98.0.246.242 (talk) 17:44, 28 November 2020 (UTC)

That's completely incorrect. They're italicized because because they're titles of major works. When we cite them as sources, we are by definition citing them as works, not as companies or as anything else – Wikipedia has a formal policy that we only cite published works. It has nothing at all to do with emphasis. If the convention in English had evolved differently, e.g. to put titles of minor works (chapters in a book, articles in a journal, etc.) in double quotes, as we do, and put titles of major works in single quotes, instead of italics, then this is exactly what our citations and the templates that construct them would also do, despite the smaller single quotes being less visually emphasizing than the larger double quotes. — SMcCandlish ☏ ¢ 😼 19:38, 4 December 2020 (UTC)

We've been over this so many times. The title of the work is mandatory. The publisher name is optional, when it is redundant with the title. There is no way around this, no gaming plan to employ. Most of the "confusion" about this is patently manufactured by people trying to impose a different style on electronic sources. We just recently had an RfC clearly rejecting that idea. So, it's time to stop. If you need to cite something from news.bbc.com, for example, it is |title=Title of Article Here|work=[[BBC News]], and do not include |publisher=[[BBC]] which would be redundant and would treat our readers like they have severe brain damage. If you're citing a news source that has no clear title beyond its domain name, then do |work=Whatever.com. If you're citing a work that has the exact same name as the publisher (aside maybe from an appended "Inc." or "Ltd" in the latter case), put the name in |work=, even if the wikilink in it (if any) goes to a company article (the publication is a subtopic thereof), and omit |publisher=. E.g., the title of npr.org really is NPR, which is also the common name of the organization (in longer form National Public Radio), ergo: |work=[[NPR]]. If this just makes your head asplode, no one is likely to care if you do |work=[[NPR|NPR.org]] to distinguish a bit between company and output. But someone is apt to remove the .org later, because it is not actually a part of the title of the work. You cannot omit the work title and just use the publisher in an attempt to avoid italics because you have some weird notion in your head that online sources shouldn't receive the same style as dead trees ones. If you do that, you are writing broken citations and someone will correct them. If you revert-war against these corrections you are being disruptive and need to give up your lost cause. [PS: I'm using a generic "you" in this; it's not directed at a specific party in this thread, but at a diffuse cloud of editors who keep trying to abuse template parameters to de-italicize things and to pretend that we're citing a corporation rather than a published work produced by a corporation.] — SMcCandlish ☏ ¢ 😼 19:54, 4 December 2020 (UTC)

Titles are italicized. But ABC News is not a title (publisher=ABC News). Sometimes it's entirely appropriate to use publisher=, not website= or work=. SarahSV ^(talk) 23:18, 6 December 2020 (UTC)
This is just rehash of WP:CITALICSRFC. It's not an either/or, "use the one I like better" matter. The |work= is always required (|website= and |newspaper=, etc., are aliases of it); Wikipedia only cites published works (see WP:V and WP:CITE); it does not cite companies, persons, or other entities, only works by them. The |publisher= should be added, as additional source-identification information, only if significantly different from the title of the work (do |work=The New York Times not |work=The New York Times|publisher=The New York Times Company). If the name of the website is ABC News then that is in fact the title of the work, despite that also being part of the name of publisher. (It's also harmless to do |work=ABCNews.Go.com, though that's a bit sloppy.) The actual publisher is ABC News Internet Ventures, a division of ABC News Network, a division of American Broadcasting Company, a division of Walt Disney Television, a division of the Walt Disney Company (most or all of which also have corporate postfixes like "Inc." in their full names). None of these names need appear in a citation, because they are either redundant with the |work= at the lower levels, or too lost in financial-holdings arrangements, at the upper levels, to be meaningful to the reader in relation to a citation. (In most contexts, anyway. In a WP article about Disney or one of its other properties, it might in fact be pertinent to indicate that Disney is the ultimate publisher, either with that parameter or with a free-form note, so the reader has a clear indication of the source's lack of complete independence from the subject.) — SMcCandlish ☏ ¢ 😼 22:52, 31 December 2020 (UTC)
PS, an aside to address of a bit of WP:WIKILAWYERING that was attempted at one of the redundant concurrent threads: When the |work= parameter (or one of it aliases) does not apply (e.g., the cited material is stand-alone and not part of a broader publication), then |title= is the work being cited. So, yes, the work is always required, just not necessarily in the form of the parameter by that name. Another side point that's been covered before: When any website is cited by WP, 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, even if it would not be italicized in running text as a service or company or whatever. — SMcCandlish ☏ ¢ 😼 19:41, 1 January 2021 (UTC)

I think We have partially the issue of reality vs ideal in some ways. Assume the ideal is both |work= and |publisher= in many cases (when they are not basically the same): {{Citation|Title=He Smart|work=The Evening News with Walter Kronkite|publisher=Fox Sports}}, that raises the question of which is better when someone skips the work and goes straight to the publisher, which of these is better : {{Citation|Title=He Smart|work=Fox Sports}} or {{Citation|Title=He Smart|publisher=Fox Sports}} AManWithNoPlan (talk) 15:23, 2 January 2021 (UTC).

If anyone is claiming that the |work= or an alias thereof is always required, I call bullshit. Nonprofit organizations and for-profit corporations publish stuff all the time and what matters is the organization or corporation. When Amnesty International publishes something, it is |publisher=Amnesty International. When Human Rights Watch publishes something, it is |publisher=Human Rights Watch. When The Heritage Foundation publishes something, it is |publisher=The Heritage Foundation. When United Airlines publishes something, it is |publisher=United Airlines. When Nestlé publishes something, it is |publisher=Nestlé. Bonafide news organizations are the same. When NPR does a news story, it is |publisher=NPR. If the story is part of All Things Considered, publisher is an optional addition to |work=All Things Considered. When BBC News does a news story, it is |publisher=BBC News. These organizations existed long before the World Wide Web, and the existence of npr.org does not turn NPR into a "work".

How do we know BBC News is not a work? Just as Chevrolet is part of General Motors, BBC News and BBC Sport are part of BBC. Just as Chevrolet is not a "work" of General Motors, BBC News is not a "work" of BBC. Similarly, Fox News and Fox Sports are divisions, not works, of Fox Corporation. —Anomalocaris (talk) 06:23, 3 January 2021 (UTC)

This is a discussion on citing material. Citations have several distinct requirements that have nothing to do with how things are represented elsewhere. First, you have to cite something - a source, a discrete item that can be found and accessed. In citations, "source" and "work" are one and the same. Publishers and organizations of any kind are not sources as far as citations are concerned. They make sources available. And sources can be anything from a sprawling news organization like BBC News or something as small as a postage stamp. In works (sources) such as Wikipedia, which is inherently unreliable and geared to nonexperts, further drilling down into citation sources to provide in-source locations is generally considered helpful: examples are the title of a specific broadcast or article, or the first-day-of-issue, or the page numbers of a book, or a combination of such. But citing anything without a work, is claiming "this publisher or org put this out, go find where and when". Don't do that. Show me exactly the item that justifies whatever you write in wikitext. You, who claims in an article that this or that is true, have to do the work, not the reader. 64.61.73.84 (talk) 15:40, 3 January 2021 (UTC)

And we've already been over this above (and in many previous discussions on many pages). It is not possible for a parameter which cannot apply in a particular citation to be required in it, so this "I call bullshit" stuff is in fact the bullshit. Last I looked, none of us had severe brain damage, so none of us are going to buy the hand-waving idea that it's okay to abuse the |publisher= parameter for the value that belongs in |work= just because some citations don't have a |work= value to put anywhere (those that do not will have their sole work title in |title=, which is still a work). So, let's not be silly. What this is about is the difference between a publication (a work), and a publisher (a business, nonprofit, or governmental entity). As shown above, trying to claim that CBS News is not the work (when the actual title of that work is provably CBS News) but is instead the publisher (when the actual publisher is provably CBS Interactive) is fact-falsification twice over. That some editors are so obsessed with the strange notion that online sources are magically exempt from the italics style applied to all publications regardless of medium, that they'll engage in falsification to trick the templates into giving them their way, is a strong indication that some topic bans from changing these parameter values around in citations is probably in order, to prevent further damage to citation integrity and factuality. — SMcCandlish ☏ ¢ 😼 20:20, 3 January 2021 (UTC)

Comments—I think this discussion is improperly conflating a "work" and a "source", and unlike the IP above me, I do no say that they are one and the same. If I'm citing an article in a newspaper for a piece of information, the article is my source, and the newspaper is the encompassing work that contains it. If I'm citing a chapter in an anthology, the chapter is my source, and the book anthology is the work that contains it. In those cases, my citation will have something rendered in italics as a work: the newspaper title, the anthology book title. If I'm citing a press release though, the press release is my source, and there may not be an encompassing work that contains it. Of course, my source might be a work; if I'm citing a book that isn't an anthology, the source is the book, which is a work.
I agree with SlimVirgin and Anomalocaris above. Not all websites have been named, or it may be redundant with the name of a corporation. In that case, list the publisher alone and move along. Imzadi 1979 → 20:39, 3 January 2021 (UTC)

IP user 64.61.73.84 and my distinguished colleague SMcCandlish: Let's consider this citation:

{{cite news |title=Newly released docs show world's reaction to Nixon's resignation |date=August 24, 2016 |publisher=CBS News |url=https://www.cbsnews.com/news/richard-nixon-resignation-newly-released-docs-show-worlds-reaction/}}

: "Newly released docs show world's reaction to Nixon's resignation". CBS News. August 24, 2016.

CBS News, a division of CBS, published this story. Sometimes CBS News publishes stories as part of one of its programs (works), such as CBS Evening News or CBS This Morning. This story is not part of any CBS News program, it's just CBS News. This is not "abuse" of the publisher. There is no "work". The "work" is not in the title. The actual title is provably "Newly released docs show world's reaction to Nixon's resignation". The reader will see that CBS News published the story, and if the reader has any further concerns about it, the reader will click the link and see that this is exactly right: CBS News did publish the story. The fact that CBS News is part of something that is part of something is irrelevant, as is the fact that in the fine print, we see that the copyright is held by CBS Interactive Inc. That's equivalent to the fact that if someone is injured by a defective Chevrolet, they might sue General Motors, but the car is still a Chevrolet. CBS Interactive holding the copyright doesn't change the fact that CBS News published this story. News stories that appear on media websites may be the same as news read aloud by named or anonymous journalists on unnamed radio broadcasts one or more times. This is an additional reason that there is no "work", just a publisher. —Anomalocaris (talk) 22:18, 3 January 2021 (UTC)

If you still cannot (or will to continue to pretend you cannot – I don't read minds) understand that the title, both visible and coded, of the website at https://ABCNews.Go.com is in fact ABC News, I don't know what to tell you. If you still refuse to see that the brand name "CBS News" can refer to that work and some other works, yet can also refer to the name of the ABC's news division, and that this division may produce other works with different titles such as CBN This Morning, in various other media, and that exactly how to use the string "ABC News", if it appears at all, in particular citations to various of these works is going to differ on a case-by-case basis, then we can't help you. I'm just going to mention WP:SATISFY and WP:CAPITULATE and move on. — SMcCandlish ☏ ¢ 😼 22:30, 3 January 2021 (UTC)

Looks to me like CBS News (the business entity) obtained a story ("Newly released docs show world's reaction to Nixon's resignation") from Associated Press (who holds the copyright – says so right at the bottom) and published it as a story in their (CBS News') eponymously named website (the publication or work) so the correct form for this citation is:

{{cite news |title=Newly released docs show world's reaction to Nixon's resignation |date=August 24, 2016 |work=CBS News |url=https://www.cbsnews.com/news/richard-nixon-resignation-newly-released-docs-show-worlds-reaction/ |agency=Associated Press}}

"Newly released docs show world's reaction to Nixon's resignation". CBS News. Associated Press. August 24, 2016.

—Trappist the monk (talk) 22:44, 3 January 2021 (UTC)

  SMcCandlish: We do not cite the title of websites, we cite the title of articles. Before the Internet, companies and organizations published press releases. If you go to an archive somewhere and find an original press release from Polaroid, Polariod is the publisher. It doesn't have a work. The existence of the Internet doesn't change this, and magically turn Polaroid into a work.

Trappist the monk: You are correct, I overlooked that the CBS News story should have had |agency=Associated Press. But that doesn't turn the business entity CBS News into a work. It's just a division of a larger corporation. —Anomalocaris (talk) 23:35, 3 January 2021 (UTC)

The story is published in the CBS News division's eponymously-named publication, CBS News so of course, in cs1|2, that publication-name goes in |work= (or an appropriate alias). This is no different from that same story from AP were it published in a newspaper.

—Trappist the monk (talk) 23:59, 3 January 2021 (UTC)

(edit conflict) Anomalocaris, I have no idea why you keep engaging in these strange false dichotomy fallacies, but this is another one. We cite the titles of articles, and of chapters, and of books, and of songs, and of albums, and of episodes, and of series, and of websites, and of papers, and of .... I think you are confusing the |title= parameter name with what a title is (see MOS:TITLES). That which goes in |work= is also a title. So is what goes in |series=; they are simply titles of different things. And |title= isn't even the same parameter in different templates. In {{cite book}} it is the title of the entire work (the "article" equivalent in that template is |chapter=). That is, in {{cite web}} and the periodical citation templates, |title= takes the place of |chapter= in the book template, and |work= or one of its many aliases takes the place of |title= in the book template. Honestly, at this point your unfamiliarity with the templates, their parameters, and even the basic terminology of source citation makes me wonder why you are in this discussion. PS: Even if you were correct that "[CBS News is] just a division of a larger corporation", that still would not make it the |publisher=; the larger corporation or other entity would be (in this case it is CBS Interactive, which is too similar to the work title to bother including). But it's a false statement to begin with, as has already been explained to you (please see WP:IDHT); "CBS News" is both the name of that division and the title of several works by that division and subsidiaries thereof, including the CBS News website. — SMcCandlish ☏ ¢ 😼 00:10, 4 January 2021 (UTC)

The RFC cited does not support the claims put forward in this edit. The RfC's conclusion was solely that websites should be italicized, which is accomplished by the use of |website=. It did not comment on when |website= vs |publisher= should be used - ie whether a particular entity is best described as a work or a publisher. Nikkimaria (talk) 03:04, 4 January 2021 (UTC)
- I strongly disagree. That WP:CITALICSRFC had extensive discussion and it should not be necessary to rehash it all again and act all confused about it. It shouldn't matter whether the website I am referencing is the CBS News website or The New York Times website or the CNN website or the BBC website or the PBS website – the name of the website should be rendered in the same way (with italics). And we should definitely not be using the publisher parameter and omitting the website/work name as a way of avoiding the italics. The concept here is not really so complicated. — BarrelProof (talk) 05:55, 4 January 2021 (UTC)
  - You and SMcCandlish are both repeating loudly and at great length the part we are all completely clear about (names of websites or more generally of collections of works should be italicized, names of organizations that publish websites should not) and by doing so, you are obfuscating the real question: how do we come to agreement on whether a name like "BBC News" refers to the organization that publishes collections like "BBC Newsroom Live", or whether it refers to a collection of pages or programs that is published by a larger umbrella organization, BBC? —David Eppstein (talk) 07:41, 4 January 2021 (UTC)
    - Roughly speaking, BBC or BBC News is both the name of a website and the name of the organization that publishes it. When the name of a work/website and the name of its publisher are the same or very similar (e.g., The New York Times and The New York Times Company), we omit the redundant publisher name in citations. We also ordinarily omit publisher names for well-known publications (e.g., Newsweek, published by IBT Media). None of that is a new concept. — BarrelProof (talk) 19:10, 4 January 2021 (UTC)

I wonder if the confusion arises from the fact that the publisher and the publisher's property have similar names. BBC publishes BBC News which has a department/regular feature called BBC Newsroom Live that may sometimes produce named reports. So the title here would be the title of the named report, absent that the publication/broadcast/upload date would in effect double as the title, since that is the way news programs are classified. Or is it that the medium (online) makes people think that different rules apply? All this is somewhat academic. What matters in citations is how do you find it, or rather how do you find it in the easiest way possible? Online searches may often obfuscate the provider. The actual source may be hidden in the URL syntax, and what appears to have come from one place, may have actually come from a different discrete location. 4.35.85.227 (talk) 13:12, 4 January 2021 (UTC)

What I take from this discussion is that some editors need to be reminded to properly distinguish between the |work= and |publisher= parameters and to not abuse them for stylistic reasons. I tried to improve the documentation by stating this explicitly and adding a crosslink but was reverted by Kanguole ([1]) for this would be bloating the documentation. In fact it does and I would prefer we would not need it, but looking at the discussion above apparently we do. My time is limited and I do not care enough about this triviality to further engage into this discussion, therefore I leave it to others to restore the sentence and link - or not - as they see fit.

--Matthiaspaul (talk) 23:05, 4 January 2021 (UTC) (updated 03:47, 5 January 2021 (UTC))

deprecation and removal of nonhyphenated multiword parameter names

User:Monkbot/task 18 is a cosmetic bot task. Among the various things that it does is replace nonhyphenated parameter names with their canonical hyphenated names. One of those replacements is |accessdate= to |access-date=.

I have started this discussion because an editor at my talk page has objected to the bot's replacement of |accessdate=: accessdate is not currently deprecated, there is currently no discussion about deprecating it, and your only basis for replacing it by bot is the concern that were we to get consensus to deprecate it at some unknown future point, error messages would annoy people? For the time being, I have disabled the |accessdate= to |access-date= replacement.

I believe that it is our intent to deprecate and remove all of the all-run-together multiword parameter names in favor of their hyphenated forms. Am I wrong? At the bottom of the §Deprecated section of every cs1|2 template (except Template:Cite citeseerx/doc) is this:

In addition to the above list(s) of deprecated and removed parameters, all non-hyphenated aliases of parameters with hyphens are discouraged to be used in citation templates and are kept only for legacy support. They are subject to becoming deprecated and unsupported in the future as well. To streamline the appearance and improve consistency across the project, these variants should no longer be used when adding parameters to citation templates. Instead, select the hyphenated parameter variants and also consider switching other non-hyphenated parameters, which may be present in a citation already, to their hyphenated equivalents at the same time. – emphasis in original

A variant of that text is present at Help:CS1 errors#Cite uses deprecated parameter |<param>=:

Plan for the future: All non-hyphenated, multiword parameter names are aliases of hyphenated multiword parameter names. The non-hyphenated aliases exist only for legacy support. Editors should expect that support for non-hyphenated parameter names will be withdrawn. Choose the hyphenated form when adding parameters to a citation template. Consider replacing non-hyphenated parameters with the hyphenated equivalents at the same time.

Do those declarations accurately reflect our intent with regard to nonhyphenated parameter names? I believe that the answer is yes because:

we have arranged the cs1|2 documentation to list hyphenated multiword forms first; these are the canonical forms
we have arranged the aliases{} table in Module:Citation/CS1/Configuration so that the hyphenated multiword forms are listed first
cs1|2 parameters need only one name except where semantics dictate a need for alternate parameter names (|chapter=, |contribution=, |entry=, |article=, |section=); nonhyphenated variants of a hyphenated parameter name do not meet this criterium
there is no need to retain relics from the mergers of the various independent cs1 templates
we have created new multiword parameters without simultaneously creating new nonhyphenated aliases (|chapter-url-access=, |name-list-style=, |script-title=, |url-status=, etc)
at the 2020-10-10 Module:Citation/CS1-suite update, we deprecated several nonhyphenated parameter names and removed support for quite a few others; see the lists at Cite uses deprecated parameter |<param>=
at the next module-suite update, we will be deprecating these: |conferenceurl=, |contributionurl=, |laydate=, |laysource=, |layurl=, |sectionurl=, |seriesno=, |timecaption=, and |titlelink=; discussion

It is probably true that we have never actually declared an intent to deprecate and remove, but reading between the lines of our past and current actions, it seems highly likely to me that our intent is to deprecate and remove these parameter names.

Is it?

—Trappist the monk (talk) 12:41, 30 November 2020 (UTC)

There is a very significant difference between saying hyphenated is preferred and saying non-hyphenated cannot be used. Given the scale of the change proposed, this requires strong consensus, including from those who are not regulars here. Nikkimaria (talk) 12:46, 30 November 2020 (UTC)
- Pinging some other editors who have raised objections at your talk page: ɱ, Jason Quinn, oknazevad. Nikkimaria (talk) 12:49, 30 November 2020 (UTC)
Agree to deprecate and remove. For the sake of clarity, made-up compound terms should be separated. Even more so where specialist language may be employed.
I also agree that this should have consensus but I don't see the scale of change as an important factor. We are talking about a formatting change that is transparent, with zero effect on semantics, in a very specialized area of Wikipedia. Imo, the change makes semantic meaning more obvious, a good thing. 68.173.79.202 (talk) 13:42, 30 November 2020 (UTC)

We are talking about a formatting change that impacts a very widely used parameter in a very widely used set of templates. Whether you think the change is positive or not, it can be anticipated to have a impact on a large number of editors. As such, it would be appropriate to solicit input from a wider range of contributors than just those who happen to frequent this page. Nikkimaria (talk) 22:39, 30 November 2020 (UTC)
Well, we are in almost complete agreement. Almost, because if someone is going to throw a fit over the appearance of perfectly harmless punctuation, and solely in the edit window, then we may be getting into the realm of therapy. Not that this is uncommon in Wikipedia. Among certain groups of editors, it is often prevalent behavior. In any case, that is why the presumed gravity of this change was questioned - everything else you state is agreed. As for the server load, well, not our concern really. And I assume that this would happen at the next module-group update anyway? Perhaps the commit might add a few more tics on the server clocks. I think Wikipedia will survive it. 98.0.246.242 (talk) 01:53, 1 December 2020 (UTC)
Support deprecation & preemptive and/or prescriptive updating of all relevant non-hyphenated parameters. ~ Tom.Reding (talk ⋅dgaf) 14:48, 30 November 2020 (UTC)
If there isn't consensus already, I say we should deprecate the remaining unhyphenated parameter aliases. One of the objections raised was that the hyphens create line breaks. Funnily enough, that's exactly why I prefer the hyphenated forms; in addition to being more canonical in general, the line breaks mean that the lines will have more consistent lengths. This is perhaps the most useful in connection to |archiveurl=, which often has a very long link without any breaks. Using |archive-url= helps alleviate this. It also helps to distinguish "Archived from the original on..." as plain text, |archivedate=, and |archive-date= in plain-text searches. -BRAINULATOR9 (TALK) 15:07, 30 November 2020 (UTC)
The system evolved over time and occasionally needs a refactor to keep it from spiraling into an unmanageable beast. "Caution: work in progress". Given the scale getting it done as quickly as possible is best, otherwise it will be irritating watchlists for 6 months ( at 10 edits/minute). AWB is not the right tool. The fastest way is via parallel processes on Toolforge (up to 15 slots though more slots might be requested). Toolforge is in the same data center so LAN speed. It should be possible to get it done in a few weeks with forward warning to temporarily enable "Hide: [ ]Bots" for anyone concerned about watchlist overload. -- `GreenC 15:09, 30 November 2020 (UTC)
I believe all the regression testcases (Template:Cite book/testcases/regression tests) use authorlink and accessdate. Should deprecate mean changing those to author-link, or should legacy support mean duplicating them all? Or are these regression tests really not useful? David Brooks (talk) 18:20, 30 November 2020 (UTC) ETA: also true of Template:Cite book/testcases, I realize. David Brooks (talk) 18:22, 30 November 2020 (UTC)
Those are updated when necessary. (Their utility is also somewhat suspect as they aren't exactly systematic.) --Izno (talk) 19:45, 30 November 2020 (UTC)
I prefer non-hyphenated authorlink and accessdate because it is easier to type. I don't see why it should be deprecated. —David Eppstein (talk) 19:21, 30 November 2020 (UTC)
By one character? Seriously? :-) They're harder to read; our entire template system has for years been moving away from mashedtogetherwordmess in template parameters and names, as it has been a major part of the daunting WP learning curve for new editors. There's no reason to disable them, but we should stop "advertising" those variants, and should ask citation tool makers to switch to the more sensible versions. Similarly, {{cn}} still redirects to {{citation needed}}, but we even have bots and AWB/JWB scripts that canonicalize such shortcuts to the real, non-jibberish templates names, and various tools use the real names of the templates in the first place now. Also, various cite template parameters (mostly newer ones) with hyphens don't even have non-hyphenated aliases, and the sky did not fall; there is no editorial outcry about it, so obviously there's not a real editorial demand for them theruntogetherversions as necessary or desirable. — SMcCandlish ☏ ¢ 😼 21:23, 30 November 2020 (UTC)
It's not just that it's one character; it's one character for which I have to move my whole hand away from the letter keys. It's significantly slower for me than just another letter. —David Eppstein (talk) 18:19, 1 December 2020 (UTC)
Well, then don't use the hyphen version. Some bot or AWB script can deal with it later. I don't see anyone arguing for disabling the hyphen-free versions. They don't don't need to be advocated in the documentation since their use makes human parsing of the wikicode more difficult. — SMcCandlish ☏ ¢ 😼 20:58, 4 December 2020 (UTC)
SMcCandlish, deprecating the hyphen-free version is in fact exactly what this discussion is advocating. Nikkimaria (talk) 21:47, 4 December 2020 (UTC)
"Deprecation" need not equate to disabling the functionality of. @Trappist the monk:, can we get some clarity on the intent here? I don't think it's a good idea to totally nuke the ability of old and heavily used parameter aliases to even work at all, versus just no longer "advertising" the old versions in the documentation (and having a bot replace them as part of routine cleanup). This is one of those WP:NOT#BUREACRACY things. The templates and their code exist to serve us, not the other way around. — SMcCandlish ☏ ¢ 😼 21:59, 4 December 2020 (UTC)
"Deprecation", by the definition used in the context of CS1/CS2, means that if the parameter is used, a red maintenance message will be shown and it will appear in a tracking category. It is a phase before removal of support for a parameter (in which case only an "unsupported parameter" message and optionally a hint on the new parameter will be shown). It is possible to stay in this state for extended periods of time, but the idea is that eventually the functionality will go (at least under this particular parameter name). While some of the non-hyphenated parameters are already deprecated, parameters like |accessdate= or |authorlink= are still too frequently used in mainspace to deprecate them now, they are only "discouraged". Being "discouraged" means that the functionality is still supported and no error message shown, but that preparations are in the works to deprecate the parameter at some later point in time, so it is wise to reduce the parameter's use whereever possible so that less work needs to be done when it gets deprecated eventually. --Matthiaspaul (talk) 23:16, 4 December 2020 (UTC)

The first word in the this discussion's heading is 'deprecation'. Deprecation will not disable the functionality of |accessdate=. The functionality of any deprecated parameter is retained through the deprecation period. At the end of the deprecation period, support for the parameter name will be withdrawn and the parameter name will no longer work. For |accessdate=, an extended deprecation period may be desirable.

—Trappist the monk (talk) 12:32, 5 December 2020 (UTC)
So what you're saying is that yes, this discussion will lead to the disabling of the functionality of |accessdate=. Nikkimaria (talk) 13:12, 5 December 2020 (UTC)

Are you not reading what I have previously written in this discussion? Earlier I wrote: The purpose of this discussion is to determine if we, the maintainers of the cs1|2 templates, intended to deprecate and remove all nonhyphenated parameters, and if we do, to declare that intent. In that sentence, all nonhyphenated parameters includes |accessdate= because that parameter name is a concatenation of two words and is not hyphenated.

—Trappist the monk (talk) 15:43, 5 December 2020 (UTC)
Well, for my part then, I don't think this should be deprecated in this particular way. Long-used parameter aliases should still remain functional, even if we do not mention them any longer in the documentation. — SMcCandlish ☏ ¢ 😼 17:55, 6 December 2020 (UTC)

At least in the common two-hand keyboard layouts for touch-typing (including US and UK QWERTY layouts), there is no need to move the whole hand away from the letter keys to reach the hyphen. All it requires is a slight move of the right hand's little finger. --Matthiaspaul (talk) 23:16, 4 December 2020 (UTC)
For |accessdate= on a qwerty keyboard, the introductory pipe is both hands, 'accessdate' left hand only, and the assignement operator is right hand and the key is directly adjacent to the hyphen character.

—Trappist the monk (talk) 12:32, 5 December 2020 (UTC)
Support of the deprecation of all non-hyphenated multiword parameter names to achieve consistency across the project, improve readability in general and help users to memorize multiword parameter names. The fact that long parameter names wrap around also helps to keep citations readable even in narrow edit windows. In the long run, deprecation will help to simplify the citation template source code somewhat, giving us more room for more useful enhancements than just supporting syntactical equivalent parameter variants. I think, there has been a trend towards this for several years.
While I think we should be careful not to actually remove support for frequently used parameter variants until all uses in mainspace (and possibly also in other spaces) and all tools have been updated to use hyphenated parameter variants, I think, we should not skip a chance to transform citations automatically in order to make the transition as smooth as possible for everyone.
--Matthiaspaul (talk) 22:34, 30 November 2020 (UTC)

Just one observation about the automation proposal. There are hundreds (literally) of templates that wrap {{cite book}}, and many more that wrap {{cite encyclopedia}}, etc. Some of these templates recognize and pass through |authorlink= etc. That raises two concerns - identify all those leaf templates that recognize these parameters and pass them on, and make sure they also recognize the hyphenated version before touching their customer articles. (There are other templates that transclude {{cite book}} and can be fixed painlessly). Second, somewhat orthogonally, in order to make the change thoroughly it should be necessary to list all templates that through a call chain end up in cs1|2, and fix the articles that use them. None of this is urgent as long as the smashedtogether variants are supported, of course. David Brooks (talk) 04:19, 1 December 2020 (UTC)
Reconsideration overnight: First, I used the term transclude too loosely above. I meant templates that are simply shorthand for a specific book and have a hardwired |authorlink=, as opposed to those that call {{cite book}} with parameters passed through. More significantly, I guess {{cite book}} was not a great example, because it is not likely that users will override the specific author. More likely cases: templates that wrap {{cite encyclopedia}} or {{cite journal}}. An example of the former is {{New Cambridge History of Islam}}, which needs to recognize |author-link= before fixing its callers. I only did a shallow dive to show this pattern is non-zero. David Brooks (talk) 14:38, 1 December 2020 (UTC)
Yes, both are good points but are already on the radar, I think, although perhaps more in a manner of an ad-hoc approach rather than systematically planned. As far as I have seen it, what we have done in the past is mostly to fix up the call down to CS1/CS2 (thereby ensuring that the templates continue to work after a switch) and leave it to the maintainers of these non-CS1/CS2-wrappers to adjust the article-facing side of parameters as they see fit. To achieve maximum consistency across the project it probably makes sense to help them by running bots tasks to fix up their parameter uses as well, but we have plenty of time for that.

--Matthiaspaul (talk) 15:38, 1 December 2020 (UTC)

I did some experimentation yesterday with a variant of Monkbot task 18 (namespace restriction limit lifted and the empty positional parameters subtask disabled). The experiments that I did yesterday suggest that task 18 in its limited form can successfully edit many of these kinds of templates. This search finds about 3300 templates that use {{cite book}}. Similar numbers for {{cite news}}, {{cite journal}}, and {{citation}} but not for {{cite encyclopedia}} (142).

—Trappist the monk (talk) 15:37, 2 December 2020 (UTC)
Thanks for the suggested search terms. Using that as a basis, I found that {{Cite encyclopedia}} has just 6 customers with {{{authorlink but no mention of author-link. So the potential fixups are getting more tractable. David Brooks (talk) 16:28, 2 December 2020 (UTC)
There appear to be about 13,000 templates that contain "accessdate=", typically in a CS1 template inside the template. At some point in this long process, preferably before we start categorizing pages with unhyphenated parameters, Monkbot or someone else with an approved BRFA will probably need to run through those templates. – Jonesey95 (talk) 15:58, 3 December 2020 (UTC)
I didn't look at accessdate, but it's the case that authorlink is often hard-coded in a template's code to refer to a particular book, rather than being passed down to CS1. For example, that's true of the first one that came up in that search, {{Taxonomy/Lepidoptera}}. No reason not to fix them, but as they aren't visible to regular editors they may be less urgent - if they could be distinguished easily. David Brooks (talk) 16:43, 3 December 2020 (UTC)
|authorlink=? Did you mean |accessdate=? It is those kinds of cs1|2 templates-within-templates that task 18 can fix. It will not be able to fix cases where the wrapper template accepts/requires |accessdate= as an input:
|accessdate={{{accessdate|}}}

might be able to fix the lvalue and maybe, with some tweaking (don't hold your breath) might fix simple rvalues like my example.

—Trappist the monk (talk) 17:16, 3 December 2020 (UTC)
Yes, I meant |authorlink=, which I had looked at in a little detail, and just inferred that |accessdate= could have similar characteristics. Thanks for the clarification. David Brooks (talk) 17:44, 3 December 2020 (UTC)
Something I thought about: when the time comes (say, the next update), should we create a category like Category:CS1 maint: uses non-hyphenated parameter names to track remaining uses of the parameters in question, regardless of whether they are currently deprecated? Since it's a maintenance category, this would only be visible to users who have opted in to seeing these messages anyway. -BRAINULATOR9 (TALK) 02:49, 2 December 2020 (UTC)
Were we to do that today, we would create an enormous category of some 2.7 million articles. This search finds that many for |accessdate=. I'm not at all sure how useful that will be.

—Trappist the monk (talk) 15:37, 2 December 2020 (UTC)

I think that the sense of the above discussion is that we are going to deprecate all nonhyphenated parameter names. As of the time I write this, Monkbot task 18 has made more than 125,000 edits. About half of those edits included the |accessdate= → |access-date= fix. Those 125k edits were made to a broad variety of articles so likely are included on thousands of watchlists. There have been 22 reverts (0.0176%). Given all of this, I intend to restore the |accessdate= → |access-date= fix to minimize the number of articles that Monkbot must revisit.

—Trappist the monk (talk) 14:53, 3 December 2020 (UTC)

Is it possible that this bot activity changed the parameter name in "old" templates that don't recognize access-date? David Brooks (talk) 16:43, 3 December 2020 (UTC)

I don't know what you mean by "old" templates. The task's activities are constrained to edits inside the canonical 27 cs1|2 templates and some of their most commonly used redirects. All of the canonical cs1|2 templates invoke Module:Citation/CS1 so all of them accept both |accessdate= and |access-date=. Redirects, being redirects, simply take the round-about way to get to Module:Citation/CS1. Did I answer the question?

—Trappist the monk (talk) 17:08, 3 December 2020 (UTC)

Yes, you did, thanks. "old" meant those written in innocence of the newer hyphen-preference. David Brooks (talk) 17:44, 3 December 2020 (UTC)

And here's a fun one. {{Schaff-Herzog}} (hundreds of uses, but I didn't check how many specify access date or author link) recognizes only |accessdate= but presents it as access-date when calling {{Schaff-Herzog cite}}. That redirects to {{Cite Schaff-Herzog}}, which (stop me if you've heard this before) recognizes only |accessdate= but presents it as access-date before passing to {{Cite encyclopedia}}, which invokes CS1. So there's no way of successfully representing the parameter, and the same blocked path attends |authorlink=. Sorry, just pointing out that while the 27 canonical templates are well-behaved, the rest of the ecosystem is a mess; there's no simple global fix. But I think everyone knew that. David Brooks (talk) 22:39, 3 December 2020 (UTC)

I have fixed a lot of those kinds template pairs. It is a good use of Module:Template wrapper so I'll fix those templates.

—Trappist the monk (talk) 23:19, 3 December 2020 (UTC)

And fixed, I think,

—Trappist the monk (talk) 00:44, 4 December 2020 (UTC)

@Trappist the monk: The above discussion is definitely not a strong enough consensus to deprecate such a widely-used parameter; it's only been four days and participation is quite low. Suggest making this an RfC with appropriate publicity. Nikkimaria (talk) 02:52, 4 December 2020 (UTC)

The purpose of this discussion is to determine if we, the maintainers of the cs1|2 templates, intended to deprecate and remove all nonhyphenated parameters, and if we do, to declare that intnet. We seem to have made the determination that yes, we intend to deprecate nonhyphenated parameters. But, I will wait a few more days until this discussion has been open a week to see if there is a change in our opinion.

—Trappist the monk (talk) 12:50, 4 December 2020 (UTC)

And I'm saying that, given the scale of this change, it shouldn't be left up to the small number of regulars on this page but should receive input from the wider community. What is your objection to that? Nikkimaria (talk) 13:47, 4 December 2020 (UTC)

Monkbot task 18 is closing in on 150,000 page edits. Each page that is edited is a poll of the editors who watch that page and so a poll of the wider community. Sure, it's likely that a portion of those pages are not being watched. The remainder are being watched. Every watcher in the wider community has the opportunity to revert the bot's edits. A very few (15 at the time I write this) have chosen to revert. The wider community's silence speaks quite loudly.

—Trappist the monk (talk) 15:05, 4 December 2020 (UTC)

See WP:FAIT. Let's have a properly advertised and well attended discussion to establish real consensus for what you're proposing, rather than having your bot make this change without an established consensus and then pointing to revert-count as a substitute. Nikkimaria (talk) 21:47, 4 December 2020 (UTC)

Not WP:FAIT but, as alluded to in the last sentence of my previous post, WP:SILENT.

—Trappist the monk (talk) 12:32, 5 December 2020 (UTC)

Making a mass edit without prior established consensus and then pointing to its persistence as evidence of consensus? Textbook FAIT. Have an actual RfC to get consensus for your proposed change, or don't make your proposed change at all. Nikkimaria (talk) 13:12, 5 December 2020 (UTC)

An edit is made, it is neither reverted nor changed. Text book WP:SILENT. So you then say something about WP:FAIT. Which prompts me to ... ad nauseum. Sigh.

—Trappist the monk (talk) 15:43, 5 December 2020 (UTC)

Not "an" edit. By your own count, 150,000 edits made without consensus. With objections from multiple editors. Nikkimaria (talk) 15:59, 5 December 2020 (UTC)

Trappist the monk, again: please start a well-advertised properly-run RfC. Editors have raised objections here and at your talk page, and even those supporting preferring hyphenated parameters have expressed concerns about aggressive bot-runs and removing functionality. A change impacting over a third of the articles on the site should have a stronger consensus behind it than what is seen here. Nikkimaria (talk) 22:06, 8 December 2020 (UTC)

Support most bot-assisted "aggressive" deprecation, but anything >25,000 uses (e.g. |accessdate= should be kept supported. When they fall <25,000 through "passive" conversations (e.g. AWB genfixes), then we can have bots aggressively convert them. Headbomb {t · c · p · b} 17:28, 3 December 2020 (UTC)

That's an idea, though for |access-date= the scale is millions of articles, it could take years - even bot speed could take months. Years might not be a problem through patience and dogged determination, but in the mean time users are still adding new templates (est 5-10 thousand a week) creating churn - users adding, bots removing, spinning wheels. So the idea if I understand is to deprecate with a red warning message, but that can't be rightly done until most of the existing stock is removed since in the past when millions of red warning messages suddenly appear the community revolts and demands the problem be fixed before red errors flood articles. -- GreenC 18:12, 3 December 2020 (UTC)

I tried the "passive" [conversions] route by including |accessdate= → |access-date= in AWB genfixes but there was pushback; understandable because there are so many instances of |accessdate= that the genfix obfuscates the fixes that awb operators intend. I have since suspended that genfix.

—Trappist the monk (talk) 18:51, 3 December 2020 (UTC)

I support deprecation of unhyphenated multi-word parameters. I do not think we should show red error messages or put pages in any sort of tracking category until Monkbot has processed 95% or more of the estimated 2.7 million articles with such parameters. – Jonesey95 (talk) 18:30, 3 December 2020 (UTC)

Comment ~~and neutral~~. I wonder why bot task 18 was approved in the first place. Consider task 18's function #5: hyphenates cs1|2 parameters when they are written using the to-be-deprecated all-run-together form. It is admitted above that "we have never actually declared an intent to deprecate and remove" those parameters so this description could be considered misleading. Second, "to-be-deprecated" means they are still valid so the choice of wording here is suspiciously imprecise for a multi-million article bot and was a hint that many this hasn't been scrutinized enough. I also question the wisdom of not recognizing that the widespread use of |authorlink= and |accessate= makes global changes to them important enough to warrant special treatment. I think sometimes it makes sense to unbundle big very specific changes from less specific umbrella tasks that have mostly a bunch of rare and non-controversial changes. I'd like to see the bots approval group lean towards more specific, smaller tasks in the future as the discussion above shows how valuable focused discussion just on just |accessdate= is. That said, I recognize the power of WP:BE BOLD and don't want to discount the efforts of those who have the know-how and put in the work to keep Wikipedia evolving. For reasons related to both typing and reading source code, I have a preference for |accessdate= over |access-date= but since those editors actually working in this area are clearly against the un-hyphenated ones, I am fine with being neutral in regards to their deprecation or this bot making these changes. Jason Quinn (talk) 06:09, 4 December 2020 (UTC) (EDIT: Now oppose instead of neutral. Jason Quinn (talk) 02:08, 6 January 2021 (UTC))

You should not be surprised that we have never actually declared an intent to deprecate and remove. We know our intent from the actions that we take, the code and the documentation that we write, etc. This discussion is about declaring our intent.

Yes, "to-be-deprecated" means they are still valid. These parameters are valid now and will be valid during the deprecation period until support for them is withdrawn. Given that support will be withdrawn, it is necessary to convert those nonhyphenated names to their hyphenated equivalents before deprecation so that we minimize the quantity of Cite uses deprecated parameter |accessdate= and similar error messages. Too many of those cause torches and pitchforks uprisings. It is precisely the recognition of the widespread use of some of these parameters that makes Monkbot task 18 important because when it comes time to deprecate these parameters, there will be far fewer error messages to distress editors.

If you have issues with WP:BAG and the WP:BRFA processes then you should take them up in the appropriate venues. This venue is not for those topics.

—Trappist the monk (talk) 12:50, 4 December 2020 (UTC)

Is it clear that parameters are not removed/deprecated? What is changing are parameter ~~labels (names)~~ aliases, marginally. All the software routines and module functions will be the same, and will result in exactly the same intended result. For prospective template editors, this is purely a minor nomenclature change to conform with the rest of the system, and one which I believe enhances clarity. It seems that most objections to this are along the lines of "we've always done it this way". 98.0.246.242 (talk) 00:01, 5 December 2020 (UTC)

@Trappist the monk: task18's revert rate (as of a week ago) of 0.0176% is very, and indeed WP:SILENTly, low. Would you be able to determine a previous large task's revert rate, as another point for reference? ~ Tom.Reding (talk ⋅dgaf) 15:44, 9 December 2020 (UTC)
Alas, no. Because task 18 is a cosmetic task and because there was concern at the WP:BRFA that the community might rise against it, from the start I have been keeping track of the number of edits and logging each revert so that I could get a sense of what the community thinks. I have never felt the need to keep such statistics in the past. I have a sense that task 14 incurred more enmity than task 18 and involved 'only' 50k–75k' articles.

Ah! this just in: For task 14 I kept a filter file that I could use to make awb remove articles from the lists that it created from cirrus searches. That list has 55 article titles. If, to be ultra conservative, we assume that task 14 operated on 100k articles, that gives a revert rate of 0.055% – 'hostile' reverts only, I did not keep track of reverts where the bot had edited vandalized articles or the I-don't-know-what-this-is-so-I'll-revert kinds of reverts or the inevitable drive-by reverts.

As of this writing the revert rate for task 18 is 0.0145% (35 reverts in 241k edits). That includes all reverts, including those where the bot edited a vandalized page, etc.

—Trappist the monk (talk) 17:06, 9 December 2020 (UTC)

Where are we on this? Everyone seems to have moved on and I'm not clear that all the outstanding questions are resolved.

The only RFC I'm aware of is the June 2014 resolution that only "All parameter names in Citation Style 1 templates" should accept hyphenated parameters; in addition, I think there is a consensus that documentation—narrative, examples, and TemplateData—should privilege the hyphenated versions. I believe both have been accomplished for the 26 or 23 (depending which list you consult, and I may have the wrong formal terms) canonical or "General use CS1 templates", but question 1: Is it still valid to use the nonhyphen versions in an example, if there are any such?

Remaining are the hundreds that wrap one of those templates, in particular those that recognize the parameters and pass them on (there are others that simply use a CS1 template internally to identify a single specific source). Are they included in the phrase "Citation Style 1 templates" in the RFC? If so, question 3: should there be a formal effort to identify those that don't recognize hyphens, and fix them? Some have been fixed recently but I think only because they were found using an incomplete search. Independently, question 4: should we make an effort to fix all the documentation, or will "fix them when you see them and have time" be OK for now, given that there is no agreement to formally deprecate the nonhyphen parameters? David Brooks (talk) 16:50, 14 December 2020 (UTC)

As I said above, there are many thousands of templates that contain |accessdate=. Not all of them are CS1 wrapper templates. It will probably be easiest to deal with them as follows: (1) Let Monkbot complete its run through affected articles, (2) put unhyphenated parameters in a maintenance category, which will allow us to catch templates, pages in other namespaces, and edge cases that the bot was unable to process, (3) process the pages in the maintenance category using a combination of bots and manual gnome work, (4) formally deprecate unhyphenated parameters in the module code, using the deprecated parameter category, and finally (5) remove support for the deprecated parameters. This process will probably take a year or more. – Jonesey95 (talk) 17:36, 14 December 2020 (UTC)

Sure, except (1) needs care, because there is no guarantee that every template, whether or not they end up in CS1, that accepts |accessdate= (etc) recognizes |access-date=. I guess the hunt through those that use CS1 could be automated pretty easily. David Brooks (talk) 22:40, 14 December 2020 (UTC)

I oppose User:Monkbot/task 18 at least temporarily until it's been discussed - this seems to be a large-impact task that didn't get much attention when it was approved, and is now causing consternation...

I thought AWB wasn't supposed to be used for purely cosmetic edits? Isn't DavidBrooks right that if it is done it should be with Toolforge instead of spamming everyone over millions of articles?
I don't see a need to get rid of especially |accessdate= which is so commonly used. A lot of editors prefer it, perhaps even most? What was the ratio of with and without the hyphen before Monkbot started "fixing" it?

··gracefool 💬 09:38, 15 December 2020 (UTC)

I don't think I mentioned Toolforge, not that it matters. My preference is only that we should first complete the work implied by the RFC, now well over 6 years old: permit hyphenated parameters and establish them as "normal" in documentation. Admittedly the RFC wasn't clear in its scope (26 canonical template or all their transitive callers?). David Brooks (talk) 23:57, 15 December 2020 (UTC)

Comment. There should be no circumstance in which |accessdate= without the hyphen is ever deprecated. It should remain a valid alias. Plenty of users still create articles with citations that use the unhyphenated form, and if the goal is to inflict big ugly red error messages or just not display the date at all upon use of the unhyphenated form, I can't see how that's going to go down well or how it's even an appropriate remedy. There are claims this is for clarity, but who has ever said they were confused about what the unhyphenated form of |accessdate= means? Cosmetic, spam-like bot edits is all this is currently amounting to. I don't see the point of these edits. There will never be complete conformity on any issue like this on Wikipedia, and we should stop trying to force people to adapt when the old form has endured for years without any hassle. Ss112 13:42, 15 December 2020 (UTC)
Comment. Per Ss112, and out of incredulity at the leeway cite template editors appear to be afforded, this ongoing wave of so-called cosmetic edits is spam-like; totally disruptive. I try to keep my watch list to a minimum, but even then, they're well-visited articles, and the mass (bot) activity can mask a whole range of unwelcome IP edits. What I can't figure out is why accessdate=, archiveurl=, p= (etc), was ever permitted if it's now deemed a major problem across the whole encyclopedia. Or the other way 'round: why it's suddenly a problem, after someone wayback-when allowed the unhyphenated/abbreviated forms, and editors acted accordingly and continue to do so. It's constantly upside down with this CS1/2 bollocks: it should be the cite templates serving article content, but it ends up that editors have to come here and ask a precious few what they're doing. Ask their permission, even. Which would be WP:OWN in every other circumstance. JG66 (talk) 14:51, 15 December 2020 (UTC)
Response. This is the page where the templated application of cs1/cs2, one of the non-compulsory citation formats (styles) is discussed. That is why people have to come here, if they want to join the discussion. And like any other restricted property in Wikipedia, suggestions must be submitted and edit requests must be made to those who are currently administering the particular areas. This is the norm; given the complexity of the cs1cs2 project, a necessity.

In Wikipedia, citations in general do not serve articles. They explicitly serve the Wikipedia verification policy, which may apply to individual articles, but impacts Wikipedia's standing in toto. Wikipedia, after all, is a project where pseudonymous persons? bots? pieces of scrapcode? calling themselves "JG66" or some easily faked machine network address, can find a platform for elaborate discussions on non-issues such as the temporary appearance of an error message regarding the rendering of an important, but non-vital parameter in an application of style that is a matter of choice.

Without easily verifiable citations (in any style) anything in main space is garbage, worthy of any inane handle it is edited under. To repeat: citations do not serve articles. They are not around to make your article look good, or complete. They are there to take your work out of the trash pile, and establish it as fact. Otherwise, there are many platforms one can publish fiction at.

In any case, I believe that good arguments have been made for this particular change, including the argument that separating madeup compound terms enhances clarity and it is not simply cosmetic. 66.65.114.61 (talk) 20:10, 15 December 2020 (UTC)

I don't think it's clear at all that adding hyphens enhances clarity. It seems to me that the argument that it decreases the readability of templates is equally strong. ··gracefool 💬 21:42, 15 December 2020 (UTC)

At first glance, imo "access-date" is more readable and clear than "accessdate". I believe this to be so for any such compound term, but more so for the ones that have uncommon usage. 107.14.54.1 (talk) 22:33, 15 December 2020 (UTC)

Comment Wikipedia is becoming ever more complex. Simply reduce complexity where possible: standardize, remove duplication. Humans vs. entropy. -- GreenC 04:18, 16 December 2020 (UTC)
Comments (1) Alternatives (aliases) in templates don't inherently increase complexity for editors using the template. New editors can be steered to one form; old editors can continue to use the form they would normally. They do increase complexity for template maintainers – and I speak from experience because currently I do most of the maintenance of the automated taxoboxes. (2) What's readable depends on what you are used to. As a programmer, "accessdate" looks right to me as a parameter name, "access-date" looks wrong, as it wouldn't be allowed as a variable name in any of the computer languages I use. I have no objection to "accessdate" being deprecated; I do object to it being treated as an error. Peter coxhead (talk) 06:54, 16 December 2020 (UTC)

Technically, we are discussing a minor element of the edit window user interface, not the way parameters are set in code. 69.94.58.75 (talk) 14:12, 16 December 2020 (UTC)

Those maintaining software are also editors and users, who go to great lengths to make things easy for non-technical users where possible even to the point of creating a system that becomes overly complex with time. This impacts everyone who parses wiki text which includes bots, templates, researchers, etc.. a large and diverse community. FWIW it's not technically a variable but a key/value pair of a data object, and it depends what the data structure is, for example an associative array can do spaces eg. citation["cite book"]["access date"] = "2020-12-16" -- GreenC 15:33, 16 December 2020 (UTC)

I oppose User:Monkbot/task 18: cosmetic cs1 template cleanup. There are several reasons:
- Per gracefool, AWB isn't meant for cosmetic edits. Seems like a less invasive approach should be used, like Toolforge (per GreenC) Or, maybe this is a secondary task -- done on articles that are being edited for other fixes, but not only for this change.
- There just isn't any real benefit; deprecating hyphenated parameter versions delivers little to no value. "Improve consistency" doesn't give any tangible improvement. Everything already works, and there's little compelling reason to change it. The change forces humans and tools to re-learn. And, for what?
- There's substantial risk. Since Monkbot doesn't test its edits to see if they introduce problems, it leaves behind duplicate citation definitions in dozens (so far, manually counted) of articles. This negative side-effect wasn't previously considered here and must be addressed.

Further, the task (which is presently running) should be paused until the community's concerns are addressed. -- Mikeblas (talk) 18:08, 24 December 2020 (UTC)

I too oppose these edits. It is a solution to a problem that does not exist. I've not seen the bot owner give a clear, conscise, non-technical succinct reason to WHY this is needed. There's just line after line of techno-guff that is TL/DR and not helpful. Lugnuts ^{Fire Walk with Me} 10:33, 30 December 2020 (UTC)
If there is something that I have written that you do not understand, why have you not asked me to clarify?

—Trappist the monk (talk) 13:35, 30 December 2020 (UTC)

I've already done so. So, without reams of text, a nice succinct answer to: what are the point of these cosmetic changes? I see little to zero value in adding a hyphen for the sake of adding a hyphen. Lugnuts ^{Fire Walk with Me} 14:32, 30 December 2020 (UTC)

@Trappist the monk: - why does the bot keep running, despite it being asked to stop? This is disruptive and WP:IDHT mentality. Please stop the bot until the issues have been addressed. Thank you. Lugnuts ^{Fire Walk with Me} 14:41, 30 December 2020 (UTC)

@Lugnuts: Trappist did answer you 5 days ago in the link you conveniently provided. Not reading it^TL/DR is no excuse for childishly spamming Monkbot to stop. It also sounds like the pot calling the kettle black/psychological projection.^WP:IDHT ~ Tom.Reding (talk ⋅dgaf) 14:59, 30 December 2020 (UTC)

Please WP:AGF, Tom. When you ask someone to stop running a bot, and take part in this discussion, you'd expect any reasonable person to do just that. Why would they ignore THREE messages? It's not just me who have raised concerns (per the above comments). Trappist gave a filibuster response and has not taken part in any further discussions. Thanks. Lugnuts ^{Fire Walk with Me} 15:03, 30 December 2020 (UTC)

No comment on the rest of this, but I think Trappist has been quite responsive here and elsewhere regarding this task, noting also that he is a volunteer like the rest of us and this is holiday season, and a lot of the concerns are repetitive. The link you sent it appears Trappist replied in length to your concern. 'Communication' doesn't mean he should badger every single comment in this section, even if not addressed for a response from him. ProcrastinatingReader (talk) 16:09, 30 December 2020 (UTC)

Lugnuts, recommend disable bot notifications even temporarily. In two weeks you created 520 articles, as you have done for years. At WP:NOA you are ranked #3 (#2 soon) most articles ever created on Wikipedia. Undoubtedly your watchlist is seriously lit up, assuming you watch all those article. Consider you are far outside the norm and take measures to deal with it. The problem is that instead of having citations in a database, where they belong, they are embedded directly in the wikitext itself. This is poor design, everyone knows it, it creates endless problems like this minor metadata change that causes endless needless human friction. But that is what we got, it evolved that way. Until something better happens we are all gonna need to work together with an architecture we got. -- GreenC 17:21, 30 December 2020 (UTC)

As others have pointed out, I did answer you at User talk:Trappist the monk § Bot consolidating access-date→accessdate with this edit. Your contributions history shows that you have been editing quite regularly between the time of your original post and today. How am I to know that you do not understand what I wrote if you don't take the trouble to respond to my writings?

Sometime, probably within the coming year, |accessdate= will be deprecated as part of our move to consolidate all multiword parameter names to the hyphenated form. When that deprecation occurs, citation templates that the the bot touched will not show error messages. But, citation templates that the bot touched and were subsequently reverted like this one from And a Little Child Shall Lead Them will show an error message:

{{cite web |url=http://www.silentera.com/PSFL/data/A/AndALittleChildShallLe1909.html |title=And a Little Child Shall Lead Them |accessdate=February 13, 2015 |work=Silent Era}}

"And a Little Child Shall Lead Them". Silent Era. Retrieved February 13, 2015. Cite uses deprecated parameter |accessdate=(help) – error message is a mockup

The bot's edits prevent the unnecessary error messages that will occur when |accessdate= is deprecated.

Because the bot's edit at And a Little Child Shall Lead Them has been reverted, I have added that article to the bot's skip-list. The bot will not visit it again.

—Trappist the monk (talk) 18:07, 30 December 2020 (UTC)

Sometime, probably within the coming year, |accessdate= will be deprecated as part of our move to consolidate all multiword parameter names to the hyphenated form. Where have you established consensus for that? It certainly hasn't been demonstrated in this thread. Nikkimaria (talk) 19:01, 30 December 2020 (UTC)

Comment this is totally a drive-by comment, but it is really annoying to have Monkbot pop-up in my watchlist a million times just to find out each time it is just adding two hyphens to a template parameter that doesn't change anything for the reader or editor. If the parameters get deprecated, then this seems like a simple task for a bit to fix to limit the dreaded error messages. But until that does get deprecated, it is a solution without a problem. This may be a good idea (on the face, it seems like it is), but that is no reason to just proceed without consensus. I doubt anyone minds Monkbot fixing these parameters when it edits an article for another reason, but just editing an article for this reason, especially when we are talking 150k+ articles requires consensus. « Gonzo fan2007 (talk) @ 21:37, 30 December 2020 (UTC)

Comment I want to second User:Gonzo_fan2007 on the annoyance of Monkbot in the watchlist just making hyphen changes. Given the concerns that have been raised, consensus should be reached before the bot continues. Sariel Xilo (talk) 18:27, 1 January 2021 (UTC)
Agreed. Clogging up everyone's watchlists with numerous changes that make literally no difference to the article is disruptive and pointless. I'm getting fed up of checking all these diffs only to discover they're just non-visible hyphen changes, for no good reason. Making parameter hyphens consistent might be appropriate as part of a more substantive edit, but on its own it's WP:ABDF. Modest Genius ^talk 11:49, 5 January 2021 (UTC)

FWIW, to both, see WP:HIDEBOTS ProcrastinatingReader (talk) 12:30, 5 January 2021 (UTC)

Oppose deprecation. It's easier to type and remember "accessdate", and no one has explained why it might cause a problem. SarahSV ^(talk) 02:38, 6 January 2021 (UTC)

Illustrator=

I saw in the archive that this has been touched on in the past. I would like to see if there is a possibility of adding |illustrator-last= and |illustrator-first= to the template cite book. An example where I see the need is for John Eyre (British artist), who illustrated classics such as Pickwick Papers, The Compleat Angler, and Rip Van Winkle. These were classics, even in his day. Putting him as |author-last2=, etc. makes it appear that he helped write the books, when his actual role was to make the stories more compelling with art. Considering all the illustrated books in the world, I think the template should inlude illustrator. Am I alone? Jacqke (talk) 14:12, 19 December 2020 (UTC)

Recommend |contributor-last=Eyre |contributor-first=John |contribution=Illustrator |contributor-link=John Eyre (British artist) -- there are many contributor roles which come to mind: illustrator, cover artist, cover designer, forward, introduction, narrator, photographer, preface, translator. If there are multiple contributors, not sure how that works of contribution and contributor-link support > one. -- GreenC 14:36, 19 December 2020 (UTC)

Actually the above does not produce expected results:

Eyre, John. "Illustrator". Pickwick Papers. By Charles Dickens.

How about this:

Charles Dickens. Pickwick Papers. Illustrated by John Eyre. Narrated by Simon Vance.

-- GreenC 14:49, 19 December 2020 (UTC)

(edit conflict)

No. Do not do that. |contribution= is an alias of |chapter= and is rendered in the citation in the same way that a chapter is rendered and is included in the citation's metadata as &rft.atitle=Illustrator. Do not corrupt the citation's metadata.

{{cite book|title=Pickwick Papers|author=Charles Dickens|contributor-last=Eyre|contributor-first=John|contribution=Illustrator|contributor-link=John Eyre (British artist)}}

'"`UNIQ--templatestyles-00000040-QINU`"'<cite id="CITEREFEyre" class="citation book cs1">[[John Eyre (British artist)|Eyre, John]]. "Illustrator". ''Pickwick Papers''. By Charles Dickens.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=bookitem&rft.atitle=Illustrator&rft.btitle=Pickwick+Papers&rft.aulast=Eyre&rft.aufirst=John&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+74" class="Z3988"></span>

|others= is where other contributors go so |others=Illustrations by [[John Eyre (British artist)|John Eyre]]

{{cite book |title=Pickwick Papers |author=Charles Dickens |others=Illustrations by [[John Eyre (British artist)|John Eyre]]}}

Charles Dickens. Pickwick Papers. Illustrations by John Eyre.

—Trappist the monk (talk) 14:58, 19 December 2020 (UTC)

Typically a citation would look like this:

Charles Dickens, John Eyre (illustrator). Pickwick Papers

But I don't see how to achieve that. -- GreenC 15:19, 19 December 2020 (UTC)

Trappist the monk, GreenC, that looks good! Thank you both. Jacqke (talk) 15:37, 19 December 2020 (UTC)

So, we are again at this discussion: "Others" further up on this page. ;-)

What can be drawn from this is that there are two general types of contributors, those who should be listed in front of the title (because they are the subject of a particular citation), and those who should be listed after the title (for completeness/relevance):

For the first type, we currently have |contribution= together with |contributor-last/first=, which works quite good for as long as only one type of contribution needs to be mentioned and it is okay to list it in front of the citation (and include them in the metadata).

For the second type, which IMO is the more common and more important one, we currently only have |others= requiring manual free-style formatting. This latter type should be expanded to allow to specify multiple names by their last and first names and their roles to let the template format the output according to our preferences. In the other thread I gave examples how to possibly combine this with the |contributor-last/first= parameters utilizing a new |contributor-role= parameter. Alternatively, |others= could be expanded to the same effect (|other-last/first= and |other-role=), but the parameter name is not particularly meaningful.

Yet another alternative would be to add parameters for the most common contribution roles. According to some style guides, illustrators come right after translators, and in front of foreword- and afterword writers. These are the most important ones, but there are yet more standard roles used in some citation style guides, and as there are too many to have parameters for all of them, a general solution seems more appropriate.

--Matthiaspaul (talk) 21:34, 20 December 2020 (UTC)

module suite update 9–10 January 2021

I propose to update cs1|2 module suite over the weekend 9–10 January 2021. Here are the changes:

Module:Citation/CS1:

support for |editors= withdrawn; discussion
support for |ignore-isbn-error=, |lastauthoramp=, |last-author-amp= withdrawn; discussion
support for |nocat= withdrawn; discussion
extra text for edition and pages test now emit two separate categories, and are promoted to errors; discussion
- also detect the British abbreviation "[Ee]dn[.]" in extra-text detection for |edition= parameter; discussion
- add "pg(s)(.)" pattern to extra text test for |page(s)=, also test |quote-page(s)=;
fix Wikisource title handling; discussion
add ((accept-this-as-it-is)) support for |quote-pages= in analogy to |pages=; discussion
- fixed local/global ((accept-this-as-it-is)) syntax in hyphen_to_dash; adjusted |volume= evaluation accordingly for all cite types;
"escape" nbsps in multiple names check; discussion
i18n; category wikilink name moved to ~/Configuration; discussion
replace double/triple-hyphen (as found in some BibTeX entries) in page ranges with en/emdash
add |quote-page(s)= to metadata if none of the other page-related parameters was used; discussion

Module:Citation/CS1/Configuration:

support for |editors= withdrawn;
support for: |authormask=, |displayauthors=, |editorlink=, |ignore-isbn-error=, |subjectlink=, |authormask#=, |author#mask=, |editorlink#=, |editor#link=, |subjectlink#=, |subject#link=, |lastauthoramp=, |last-author-amp= withdrawn; discussion
support for |seriesnumber=, |event-format=, |event-url=, and |eventurl= withdrawn; discussion
support for |nocat= withdrawn;
consistent error/maintenance category names; discussion
- proper capitalization of identifier abbreviation "Zbl" in Category:CS1 errors: Zbl and Category:CS1 maint: Zbl
correct missing SSRN from "ssrn" to same as bad SSRN which is "SSRN"
extra text for edition and pages test now emit two separate categories, and are promoted to errors;
- add 'et alii' and 'et aliae' variants to "et al." detection;
add script language codes ky, te, ti;
i18n; category wikilink name moved from Module:Citation/CS1/sandbox;
reduce PMC suffix from single space character to empty string to avoid pending space in COinS metadata
add id_limit to OCLC, OSTI and RFC for Module:cs1 documentation support; discussion and discussion
- fix broken links with spaces in label by encoding JSTOR id;
- error message support for |rfc= and |osti=;
add   to "et al", "edition", "section"', "sections" messages to avoid wrapping; discussion
add double-bracket variant to "et al." detection to avoid its only partial removal; discussion, discussion
add 'Subscribe to read' to list of generic titles; discussion
unhide unknown-empty parameter error message; discussion
- prevent error categorization of log and archive pages;

Module:Citation/CS1/Whitelist:

support for |editors= withdrawn;
support for: |authormask=, |displayauthors=, |editorlink=, |ignore-isbn-error=, |subjectlink=, |authormask#=, |author#mask=, |editorlink#=, |editor#link=, |subjectlink#=, |subject#link=, |lastauthoramp=, |last-author-amp= withdrawn;
support for |seriesnumber=, |event-format=, |event-url=, and |eventurl= withdrawn;
support for |nocat= withdrawn;
|conferenceurl=, |contributionurl=, |laydate=, |laysource=, |layurl=, |seriesno=, |sectionurl=, |timecaption=, |titlelink= deprecated; discussion

Module:Citation/CS1/Identifiers:

support for |ignore-isbn-error= withdrawn;
error detection support for |rfc= and |osti=;
- change lower OSTI limit from 1 to 1018;
add error detection (http(s):// and spaces) for |jstor=;
catch non-digit & non-dot chars in doi registrant; discussion

Module:Citation/CS1/Utilities:

simplify piped wikilinks in make_wikilink() where link and label are the same; discussion

Module:Citation/CS1/COinS:

(not currently needed but) add missing suffix catenation to identifier links; discussion
- indicate identifier name as transparent #fragment to rft_id URLs for those identifiers which have no predefined info or rft type;

Module:Citation/CS1/Suggestions:

Add hints for removed parameter |editors=;
Add hints for removed parameters |displayauthors=, |ignore-isbn-error=, |last-author-amp=, |lastauthoramp=, |authormask=, |authormask#=, |author#mask=, |editorlink=, |editorlink#=, |editor#link=, |subjectlink=, |subjectlink#=, |subject#link=;
Added hints for removed parameters |ASIN-TLD=, |registration=, |subscription=;
Added hints for removed parameter |nocat=;
Added hints for Brazilian citations; discussion
Added hints for Turkish citation templates;

—Trappist the monk (talk) 17:32, 3 January 2021 (UTC)

@Izno: In Module:Citation/CS1/Configuration/sandbox both of err_extra_text_edition and err_extra_text_pages have hidden = true. Why? Copy/pasta oversite?

—Trappist the monk (talk) 17:52, 3 January 2021 (UTC)

Yes, feel free to fix that. --Izno (talk) 20:11, 3 January 2021 (UTC)

Caught one. --Izno (talk) 06:23, 6 January 2021 (UTC)

+1 --Matthiaspaul (talk) 15:38, 7 January 2021 (UTC)

multiple editors in encyclopedia?

The citation indexing in Mortimer Taube is rather poor, which is highly ironic. I'm trying to improve this, but ran into a problem. How do I list multiple editors in an encyclopedia? editor_first1 et all does not appear to work and no alternative is listed on the template help page. Maury Markowitz (talk) 13:51, 7 January 2021 (UTC)

—Trappist the monk (talk) 14:02, 7 January 2021 (UTC)

We catch a few of these through our parameter suggestion system, but if this would be a more common mistake, we could add a dedicated error message for parameters with underscores or spaces.

--Matthiaspaul (talk) 15:09, 7 January 2021 (UTC)

Does template:cite document need changes?

I have been working on the maintenance backlog for a wikiproject and a significant number of the issues are "CS1 errors: missing periodical". In a majority of cases, the fix is obvious, e.g. use cite book instead, or add the journal name. However, a minority are coming from "cite document" which is basically as far as I can see a wrapper to cite journal. The problem with this is that it is not obvious to editors that if you use a template called "document" you need to add the journal field. Some examples of its use for generic documents can be found on the A30 road page. The talk page for this template states "This template is used when a bot needs to switch from the Citation format to the Cite xxx format, but cannot deduce whether the source is a book, newspaper or other document" but if the source is a book or a newspaper, then there won't be a journal field either, so this is a problem for that use case as well. Can anyone suggest a way forward here please?--NHSavage (talk) 09:22, 9 January 2021 (UTC)

Intent of url-access=limited

The documentation at Help:Citation Style 1, and for the individual CS1 templates, says that |url-access=limited means that, besides registering on some website, there are other constraints (such as a cap on daily views) to freely access this source, while the tooltip on the lock icon that |url-access=limited produces says Free access subject to limited trial, subscription normally required.

These descriptions of the meaning of |url-access=limited don't seem equivalent to me. For example, having a free account on Archive.org lets one "borrow" a book, but (for many books) one must wait to do so until there is a copy of the book available (not borrowed by someone else). If such a book is used as a source, I would understand this simulation of a physical library to create an other constraint besides registration to freely access this source, so, according to the documentation, |url-access=limited applies. On the other hand, the Archive.org account is not merely a free trial, and (as far as I'm aware) there is no "full subscription" one could buy to bypass the constraint, so, according to the tooltip, |url-access=limited does not apply.

Could the intent of |url-access=limited be clarified?

Thank you, —2d37 (talk) 13:53, 6 January 2021 (UTC)

The tooltip message is limited to trial and subscription only. It could be broadened. For example it could say Free access limited eg. trial, subscription, registration, or cap on views. The "eg." (or "for example") means these are not a complete set of reasons but are typical. -- GreenC 14:01, 6 January 2021 (UTC)

A viewcap limit is a limited trial, so they're already covered by the 'limited trial' part. But no objections to listing view caps separately, since that can make things clearer for some people. Headbomb {t · c · p · b} 17:24, 7 January 2021 (UTC)

I don't think a viewcap limit necessarily entails a trial, despite that it does so in what I imagine is an archetypal example of such a limit, a newspaper's website's allowing a user to read some limited number of articles per month for free and offering a paid subscription for full access. Literally, I suppose the case of books at Archive.org involves a cap on views (not limiting a user to viewing some number of articles but limiting a book to being viewed by some number of users), but there's no trial in that case; as far as I know, one can't buy unlimited access to the Archive's books. —2d37 (talk) 10:12, 8 January 2021 (UTC)

To try to see how these parameter values are used in practice for Archive.org URLs, I went through many, many WP:RANdom articles until I found four that cite books on Archive.org: in the order I found them, Hemileuca neumoegeni, Rosario Weiss Zorrilla, Service-oriented architecture, and Gerard J. Milburn. I would have gone for more, but the search was too tedious. Of these four articles, the first two use |url-access=registration, which gives the true but incomplete description "Free registration required", and the second two use |url-access=limited, despite that the tooltip produced thereby speaks inapplicably of trials and subscriptions. I realize that my sample size here is terribly small; if it's interesting, perhaps someone familiar with running bulk queries against Wikipedia could get better data. —2d37 (talk) 10:59, 8 January 2021 (UTC)

The |url-access= parameters appear to have been added to all four of those articles by InternetArchiveBot and/or GreenC bot:

registration:

limited:

Service-oriented architecture – 14 June 2020 (v2.0.1) (GreenC bot)
Gerard J. Milburn – 28 May 2020 (v2.0) (GreenC bot)

Which of the bots is actually responsible for an edit when both bots are named isn't exactly clear. Nor is the versioning clear: the older edits have numerically greater version identifiers than the newer edits. Regardless, if I understand you, your complaint suggests that the IA/GC bot pair isn't using the correct value for |url-access= but when IA bot is operating on its own, |url-access= gets the correct value. It would seem to me that you should raise this issue with the bot operators and not here.

—Trappist the monk (talk) 14:34, 8 January 2021 (UTC)

I meant no complaint in that comment. I hadn't been thinking of bots at all; in opening this thread, my intent was to request clarification of how I, as a human editor, should choose a value for |url-access=. If there were necessarily an implicit complaint in my original post, it was that the documentation for |url-access=limited seems inconsistent with the tooltip that it produces. —2d37 (talk) 09:18, 9 January 2021 (UTC)

The books marked limited have more restrictions than those marked registration. I suppose there are at least 3 levels of restriction at archive.org and 4 or 5 levels at Google Books. -- GreenC 03:24, 9 January 2021 (UTC)

Indeed, I wasn't paying enough attention and failed to heed how some books at Archive.org have more restrictions: not normally available for borrowing at all but only to patrons with print disabilities. Perhaps offtopically, I wonder whether, given that restriction, Google Books previews (where available) should be preferred for those citations' URLs. —2d37 (talk) 09:38, 9 January 2021 (UTC)

The entire book is only available to borrow for disabled patrons. But previews, like Google, are available to everyone. Google does not allow borrowing entire books for disabled or anyone unless PD of course. -- GreenC 15:52, 9 January 2021 (UTC)

At least for the three books cited at Service-oriented architecture and Gerard J. Milburn, Archive.org gives a preview of 11 'pages' (including the cover), in no case extending past the table of contents. I see now, though, that the corresponding Google Books previews, though more extensive, are not as extensive as I had thought they were, and I realize now that the choice of which to use for |url= is made less significant because of how the ISBN links to many different BookSources. —2d37 (talk) 08:06, 10 January 2021 (UTC)

ISBN line breaking redux

Undesirable line breaking within an ISBN number; look at ref. 114

This is a follow-up to Help_talk:Citation_Style_1/Archive_73#ISBN_line_breaks, which got archived before consensus became fully clear. I continue to believe that it would be beneficial to wrap ISBNs in {{nowrap}}, which would prevent line breaks like the one in the screenshot (that appears for Chrome; issue does not seem to manifest on Firefox). Because ISBNs are quite short, I do not see any significant downside; one would have to have an insanely narrow screen width to run into any issues. Can we decide if we're ready to implement? (Please note that the space between "ISBN" and the ISBN itself is already non-breaking; it is just the hyphens within the ISBN that are at issue.) {{u|Sdkb}} ^talk 14:49, 9 January 2021 (UTC)

My opposition remains the same. There was a separate request elsewhere about possibly making the IDs easier to target in CSS for personal use. You could today take care of this for yourself if you dislike it in CSS with something like .citation a[href*="BookSources"] { white-space: nowrap }. --Izno (talk) 15:42, 9 January 2021 (UTC)
Izno, your opposition, as I understand it, is that no-wrapping can sometimes lead to a worse experience on mobile, where there need to be more line breaks. I thought Matthiaspaul at the original discussion and myself above addressed that concern, though.

And I appreciate the CSS hack, but I'm seeking this for readers, not just for myself, so my interest in something that only applies to me is about 1⁄number of readers that of a global fix. {{u|Sdkb}} ^talk 14:44, 11 January 2021 (UTC)
And I am telling you that it is a personal preference not to wrap this strings, for which the appropriate remedy is personal CSS.

No, you (plural) didn't address the concern in question. "Dedicated" browsers are a fantasy in this day and age (in fact, with decreasing diversity in the browsers served; Chrome owns 70-80% of the market and hasn't stopped growing in a decade), and skins are irrelevant to the question. As for particular strings, it's a microoptimization for display that would increase the template expansion size to boot, which of course impacts our largest articles worst. --Izno (talk) 17:04, 11 January 2021 (UTC)

Ruby content

Furigana#References has a reference which contains {{ruby}}, which is an instance of Ruby character content. I can replace the template (which uses templatestyles) with the associated HTML. Is that reasonable for metadata et al? --Izno (talk) 19:33, 9 January 2021 (UTC)

cs1|2 is good for most citation needs but cannot be (will never be) <announcer voice>the-prefect-solution-for-all-of-your-citation-needs</announcer voice>. Perhaps the best solution is to hand-write those citations; their use in that article appears to be as examples of Furigana in use.

—Trappist the monk (talk) 15:27, 11 January 2021 (UTC)

I'm just gnoming away some TemplateStyles strip marker errors and that didn't have an obvious fix to me. You didn't answer the actual question. :) --Izno (talk) 16:46, 11 January 2021 (UTC)

I thought I did: Perhaps the best solution is to hand-write those citations

—Trappist the monk (talk) 16:47, 11 January 2021 (UTC)

Is that reasonable for metadata et al?, for which I would have expected "yes, go ahead and use the raw HTML and the template will be fine" or "no, seek another solution, such as removing the ruby annotation or rewrite it". You will find no answer on that specific question in your responses. :) --Izno (talk) 16:56, 11 January 2021 (UTC)

Pretty sure that Perhaps the best solution is to hand-write those citations is the answer to the specific question because implicit in hand-write is: no, seek another solution.

—Trappist the monk (talk) 19:24, 11 January 2021 (UTC)

I do not really see why you were obtuse about it. --Izno (talk) 01:30, 12 January 2021 (UTC)

Ideally, this question would be answered by people from the Far East who have every-day-experience with Furigana and Ruby characters. Our goal here is to somehow "make work" everything that is not an error and leave it to the editorial judgement of the article authors to decide if Furigana/Ruby annotation is useful in a citation or not, instead of imposing our preferences on them.

Assuming that parties consuming our citation metadata are capable of displaying/processing Far East scripts, they shouldn't have problems to cope with Furigana/Ruby stuff in principal as well (at least when provided in raw form). Its presence may also help screen readers.

If that would still cause some error message to occur, perhaps the best solution to address this at present is to add this to |title=((...)) as well - similar to what is proposed in Help_talk:Citation_Style_1#Modifier_being_recognized_as_zero_width_joiner.

--Matthiaspaul (talk) 01:24, 12 January 2021 (UTC)

Fixes needed for manual invocations of CS1 categories

These 50 pages have manual invocations of CS1 categories that need to be converted from "Category" to ":Category" inside their brackets. If anyone has a quick script that can fix them, go for it. I fixed a half-dozen of them, but it's tedious. – Jonesey95 (talk) 23:37, 9 January 2021 (UTC)

GoingBatty, could this be handled by your bot's Task 9? The cats in question are all subcategories of Category:CS1 errors. – Jonesey95 (talk) 02:24, 11 January 2021 (UTC)

@Jonesey95: Funny you should ask - I'm just restarting this task after a long time without running it.

Doing... GoingBatty (talk) 02:36, 11 January 2021 (UTC)

@Jonesey95:

Done! GoingBatty (talk) 02:48, 11 January 2021 (UTC)

JSTOR links do not work right if they have a slash

X. JSTOR 10.14321/j.ctt1pd2k5h. links to https://www.jstor.org/stable/10.14321%2Fj.ctt1pd2k5h and not https://www.jstor.org/stable/10.14321/j.ctt1pd2k5h and escaping the slash breaks the link. AManWithNoPlan (talk) 13:37, 10 January 2021 (UTC)

That happens because of this edit. @Editor Matthiaspaul: Why did you do that?

—Trappist the monk (talk) 14:43, 10 January 2021 (UTC)

Thanks for reporting this. Damn, that we didn't saw this just a little bit earlier... Per Help_talk:Citation_Style_1/Archive_73#URL_in_identifier and [2], this was a fix for an existing bug with broken links for JSTORs containing spaces spotted while adding the new plausibility tests to the JSTOR code. The temporary hotfix now is to set encoding back to false in the live code while devising a better solution for the next update. Trappist, can you do this, please? Thanks. --Matthiaspaul (talk) 15:46, 10 January 2021 (UTC)

Are there legitimate jstor identifiers that include space characters?

—Trappist the monk (talk) 15:57, 10 January 2021 (UTC)

I don't think so. --Matthiaspaul (talk) 16:22, 10 January 2021 (UTC)

Thanks for switching it back. For illustration, here are two examples of the issue for why this was changed:

{{cite book |title=Title |jstor=141 294}}

Title. JSTOR 294 141 294. {{cite book}}: Check |jstor= value (help)

{{cite book |title=Title |jstor=141dfdfdf29 4}}

Title. JSTOR 4 141dfdfdf29 4. {{cite book}}: Check |jstor= value (help)

Since the spaced value is broken anyway, this is not a serious problem, but even an invalid JSTOR should ideally be displayed (and linked to) correctly.

--Matthiaspaul (talk) 16:36, 10 January 2021 (UTC)

Straw poll: make publication-date and publication-place full synonyms...

Straw poll: make publication-date and publication-place full synonyms... to date and place/location respectively. Publication-place and location are used only some 600 times in conjunction (see Category:CS1 location test). I anticipate publication-date and date have similar numbers (the first several in this search look like they are being used as synonyms, and at least one or two misuses of publication-date). Anything so little used does not need full support in the module. --Izno (talk) 02:43, 11 January 2021 (UTC)

|publication-place= and |location=/|place= are not aliases, and shouldn't be treated as such. Publication place and written-at location are two independent properties of a source, and while it is true that they are seldomly both relevant and given at the same time (hence the low numbers), sometimes they are relevant and it would be counter-productive for readers as well as for machine-readability to not distinguish between them any more. It would weaken the quality of information in references. While the parameter name |publication-place= is perfectly descriptive already, the parameter name |location=, unfortunately, is not. Therefore, I propose a semantically more descriptive name for it like |written-at-place=, |written-place=, |writing-place=, |write-place=, |creation-place= or something else along that line following our modern naming conventions of adding more descriptive parts of parameter names on the left side of a parameter. Afterwards, the |location= parameter could either be left as it is or be faded out slowly, probably a process that would take several years to finish as each usage would have to be checked manually and the parameter replaced by either the written-at or the publication place parameter.

Regarding |publication-date= and |date=, we should analyze what other typical types of dates are referred to in various types of references and add dedicated and descriptive parameter names for them as well to improve machine-readability and allow for more meaningful and consistent output. At present, we have to put everything else into the |orig-date= parameter, which has no date format checking and cannot contribute to the metadata output. Using more descriptive parameter names would improve the situation.

--Matthiaspaul (talk) 04:26, 11 January 2021 (UTC)

|publication-place= and |location=/|place= are not aliases, and shouldn't be treated as such. You are incorrect and continue to be incorrect. They are only not aliases when they are used together, and that situation has a total of 600 uses. Total. Out of 5 million pages using this template. We do not and need not support the distinction.

Adding another alias to the pile only increases our alias count and is not worth our maintaining multiple ways to say "this is the place on the tin" (which wasn't necessary anyway internal to the citation). This suggestion is just another standard.

And no, we shouldn't invite our date parameters to the same idiocy.

Recommended use of the parameter set is and should be "publication place", with a user side fall back to another location if they do not have a publication place on hand (and they can choose to use place or location rather than publication-place, if they didn't already default to that). We have the evidence users don't need or care for the extra parameter. --Izno (talk) 13:04, 11 January 2021 (UTC)

"location", meaning the place of publication, is important for books, newspapers and magazines, though it is apparent that a lot of WP editors don't realise this, and leave it out. (In particular, the city of publication, and NOT the name of the publisher, is the standard means of disambiguating between different newspapers with the same name, e.g. there are several newspapers called The Guardian in different parts of the world.) I have only rarely come across people labouring under the misapprehension that "location" means "written-at", which is something one does not put in a newspaper citation, so I wonder if that isn't a bit of a red herring. -- Alarics (talk) 14:21, 11 January 2021 (UTC)

Publication place and written-at location are two independent properties of a source Yeah, that is true but irrelevant. Citation templates are not repositories for all possible properties of a source. For cs1|2, machine-readability is constrained to what COinS can support so a cs1|2 template with both of |location= and |publication-place= and both of |date= and |publication-date= emits metadata from |publication-place= and |date=; the other two are ignored.

—Trappist the monk (talk) 14:57, 11 January 2021 (UTC)

I would be generally supportive. I assume the value of publication-date or -place would be the winning value where |date= and/or |place= are also present. Be mindful of the fact that certain sources such as films, etc. may be classified by work date (date of production) by default, and would be much harder to find by publication date (date of ~~exhibition~~ distribution). 50.74.165.202 (talk) 14:31, 11 January 2021 (UTC)

No, true synonyms, not simply override in some situations. Those 600 pages with citations would have the "better" place/date moved/removed/replaced by hand. --Izno (talk) 15:03, 11 January 2021 (UTC)

In this discussion I wondered if we really need a 'written at' facility. I speculated then that that facility is not needed because it does not help readers locate a copy of a source. I believe that the functionality is not really useful. Similarly, I don't think that readers benefit when |date= and |publication-date= are paired.

publication-place ~8k articles
place ~30k articles (search times out)
location ~350k articles (search times out)
publication-date ~13k articles
date ~670k articles (search times out; search is cs1 and cs1-like templates only to avoid contamination from {{citation needed}} which also takes |date=)

Clearly, the overwhelming preference is for |location= and |date=. Deprecate and remove the others.

—Trappist the monk (talk) 14:57, 11 January 2021 (UTC)

"Synonym" may be the wrong term. The more common in programming abbreviation "alias" is probably better. I don't think POLA is violated by these terms. They are correct in the context of the programming construct, ie they conform to the normal usage of the terms in citations. In citations, "date" is expected to mean "publication date"; "place" is "publication place". Citations can only cite published materials and info pertinent to the publication. 50.74.165.202 (talk) 16:23, 11 January 2021 (UTC)

Indeed, alias is the probably more domain-specific term used in templates. --Izno (talk) 17:06, 11 January 2021 (UTC)

Session number and time for cite conference?

What is the proper way to mark up a {{cite conference}} to specify the dates of the conference, the location of the conference, the time of a session and the number of a session, e.g.,

Dual Address Space & Linkage-Stack Architecture
Dan Greiner 
dgreiner@us.ibm.com
z/Server Architecture
SHARE 118 in Atlanta
Session 10446, 12 March 2012, 4:30 pm

I can fudge some like this,^[1] but Atlanta would be incorrectly indexed as the publication place and it doesn't show the session time. Shmuel (Seymour J.) Metz Username:Chatul (talk) 03:33, 09 January 2021 (UTC)

For the date & place, see recent discussion in #How do you indicate both the location of a conference and the place of publication?.

Session numbers & times are not pertinent to citations, unless you specifically cite the conference program or other such promotional/informational conference materials published by the sponsor. You do need to cite the relevant paper as published in the proceedings, which should be cited as well. 50.74.165.202 (talk) 16:09, 9 January 2021 (UTC)

The published information for SHARE conferences is organized by date, time and session number. Shmuel (Seymour J.) Metz Username:Chatul (talk) 18:41, 11 January 2021 (UTC)

First, I'm surprised they're still around. :) My first computing experience was on a block terminal timesharing an S/360. We also used punch cards... but never mind, this was such a long time ago. Back to now, since the proceedings are members-only, I cannot verify the citation offhand. If there is an online record of the conference, and if it includes presentations indexed by session number, then there's nothing wrong with your example. If this kind of indexing (ie search facility) reaches a critical mass, perhaps |session= would be apt. I am not sure this is the case now. 98.0.246.242 (talk) 04:33, 12 January 2021 (UTC)

Neither https://share.confex.com/share/118/webprogram/Session10446.html nor the https://share.confex.com/share/118/webprogram/Handout/Session10446/Dual%20Address%20Space%20%26%20Linkage%20Stack.pdf link on that page is members only, nor is https://share.confex.com/share/118/webprogram/, the link for the complete SHARE 118 conference. Shmuel (Seymour J.) Metz Username:Chatul (talk) 14:21, 12 January 2021 (UTC)

References

^ Dan Greiner (12 March 2012). Dual Address Space & Linkage-Stack Architecture. SHARE 118. Atlanta. Session 10446.

I still do not see the need for a session parameter. I assume you want to cite the specific paper, not information about the session it was presented in. The first example is a sponsor/publisher abstract; the second, ancillary material (a presentation handout); the 3rd, a conference program. The first two can be part of the presentation's citations. The last cites the proceedings as a whole. In all cases, the session number(s) is not necessary. It may be helpful in locating the presentation, and this can be offered via |id=. 66.65.114.61 (talk) 19:48, 12 January 2021 (UTC)

Modifier being recognized as zero width joiner

In List of most-liked TikTok videos, ref 15 (currently) has the error zero width joiner character in |title= at position 46. The issue is with the characters 🤷‍♂️🔥 - removing the modifier character solves the error but leads to 🤷🔥 - different text. This is a very minor issue but a bit annoying. Elliot321 (talk | contribs) 07:52, 9 January 2021 (UTC)

Do we actually need to issue the error message for this particular joiner character in the first place? Is it really polluting metadata?

If we need to issue the message in general, couldn't we add a special case for the concatenated characters being emojis, or add this as a special case for |title=((...)) or |script-title=?

--Matthiaspaul (talk) 05:12, 11 January 2021 (UTC)

The emoji implementers being creative with the zwj (which is not warned for in Unicode blocks that do not need it, which is several character sets) is something we've talked about before. I might be personally agreeable for also allowing it for the blocks of interest, but I must also be skeptical that we are using any quality source that purports to be a serious work for our reference that also editorially allows any emoji in their titles.... --Izno (talk) 13:10, 11 January 2021 (UTC)

Citing section of journal article?

IBM System/360 cites a section^[1] within a journal article with this <ref>{{cite journal | author = A. Padegs | title = System/370 Extended Architecture: design considerations | journal = IBM Journal of Research & Development | volume = 27 | issue = 3 | pages = 198–205 | date = May 1983 | publisher = IBM | doi = 10.1147/rd.273.0198 }} – a subsection titled "31-bit addressing" begins on page 201.</ref> markup. The {{cite journal}} template does not support |section= or |section-url=, nor does it support nested page ranges.

What is the proper markup for doing this? Shmuel (Seymour J.) Metz Username:Chatul (talk) 13:24, 13 December 2020 (UTC)

References

^ A. Padegs (May 1983). "System/370 Extended Architecture: design considerations". IBM Journal of Research & Development. 27 (3). IBM: 198–205. doi:10.1147/rd.273.0198. – a subsection titled "31-bit addressing" begins on page 201.

Template:Cite journal § In-source locations: "page: The number of a single page in the source that supports the content" and "pages: A range of pages in the source that supports the content." Others, of course, disagree with that and are happy to squabble about it. Alternately, "at: For sources where a page number is inappropriate or insufficient." Perhaps, |at=§31-bit addressing p. 201

—Trappist the monk (talk) 14:41, 13 December 2020 (UTC)

There have been many discussions in the past how to specify both, the page range of an article as a whole and the individual page(s) supporting a statement in there. Some editors think that only one of them is necessary (sometimes depending on the type of source), but the majority seems to like the idea of being able to specify both when relevant. More recent discussions led to the proposal of dedicated page parameters like |span-page(s)= or |range-page(s)= and |cite-page(s)= to distinguish between them, and we came up with two possible notations how to display them in a citation. However, for as long as these parameters are not implemented, you could use something like |pages=198–205 [201] to manually specify a page range of 198–205 with a relevant page 201 in there.

This does not provide means to specify the title of a section or chapter, though - this is a known shortcoming of periodical citation templates. A lot of people have requested some means to specify subheaders in the past already.

Trappist's suggestion above might be a workaround, but it does not look particularly great IMO. Appending this at the end of the citation, as in your example, also appears to be undesirable.

--Matthiaspaul (talk) 15:08, 17 December 2020 (UTC)

{{{quote-page}}} strike 2: {{{no-pp}}}

Monkbot doesn't like the combination. Why, @Trappist the monk:? 98.0.246.242 (talk) 03:19, 14 January 2021 (UTC)

Bump DOI limit to 10.55000

Berube, David; Eubanks-Turner, Christina; Mosteig, Edward; Zachariah, Thomas (2018-07-01). "A Tale of Two Programs: Broadening Participation of Underrepresented Students in STEM at Loyola Marymount University". Journal of Research in STEM Education. 4 (1): 13–22. doi:10.51355/jstem.2018.32. ISSN 2149-8504.

10.51355 is a working prefix. Headbomb {t · c · p · b} 04:35, 14 January 2021 (UTC)

Cite journal comparison
Wikitext	{{cite journal\|date=2018-07-01\|doi-access=free\|doi=10.51355/jstem.2018.32\|first1=David\|first2=Christina\|first3=Edward\|first4=Thomas\|issn=2149-8504\|issue=1\|journal=Journal of Research in STEM Education\|language=en\|last1=Berube\|last2=Eubanks-Turner\|last3=Mosteig\|last4=Zachariah\|pages=13–22\|title=A Tale of Two Programs: Broadening Participation of Underrepresented Students in STEM at Loyola Marymount University\|url=https://j-stem.net/index.php/jstem/article/view/32\|volume=4}}
Live	Berube, David; Eubanks-Turner, Christina; Mosteig, Edward; Zachariah, Thomas (2018-07-01). "A Tale of Two Programs: Broadening Participation of Underrepresented Students in STEM at Loyola Marymount University". Journal of Research in STEM Education. 4 (1): 13–22. doi:10.51355/jstem.2018.32. ISSN 2149-8504.
Sandbox	Berube, David; Eubanks-Turner, Christina; Mosteig, Edward; Zachariah, Thomas (2018-07-01). "A Tale of Two Programs: Broadening Participation of Underrepresented Students in STEM at Loyola Marymount University". Journal of Research in STEM Education. 4 (1): 13–22. doi:10.51355/jstem.2018.32. ISSN 2149-8504.

Limit is 10.59999.

—Trappist the monk (talk) 13:44, 14 January 2021 (UTC)

Talk pages for new CS1 error categories

Should the new CS1 error categories (e.g. Category:CS1 errors: extra text: edition, Category:CS1 errors: extra text: pages, Category:CS1 errors: redundant parameter, Category:CS1 errors: URL) have talk pages that redirect here? Thanks! GoingBatty (talk) 05:02, 11 January 2021 (UTC)

Yes, this would be very useful, also for the older cats without talk pages as well as for existing talk pages of older cats (unless some significant discussion emerged there already - in that case, we should at least add a hatnote pointing to here).

--Matthiaspaul (talk) 05:33, 11 January 2021 (UTC)

Yes, all category talk pages for CS1 error and maintenance categories, as well as talk pages for CS1 templates and modules, should redirect to this page. – Jonesey95 (talk) 07:22, 11 January 2021 (UTC)

@Trappist the monk: Could you please weigh in as well? I see you moved page Category talk:Pages with URL errors to Category talk:CS1 errors: URL. Thanks! GoingBatty (talk) 17:53, 11 January 2021 (UTC)

Meanwhile I have added redirects to here to all previously red CS1 category talk pages. So far, I did not touch talk pages already containing some discussions.

--Matthiaspaul (talk) 05:38, 16 January 2021 (UTC)

Removal of no longer used name-list-format= in sandbox

Following up on Help_talk:Citation_Style_1/Archive_72#last-author-amp=, support for the |name-list-format= alias of the |name-list-style= parameter has now been removed in the sandbox. Use of |name-list-format= and the former |last-author-amp= parameter has been completely replaced by |name-list-style= in mainspace. --Matthiaspaul (talk) 05:34, 16 January 2021 (UTC)

empty unknown param error message

In the sandbox I have unhidden the empty unknown parameter error message. At this writing, Category:CS1 errors: empty unknown parameters has 324 entries, most of which are not in article space. I still think that there are various archives logs etc that should not be in error categories. Someone tell me again: Why it is that we don't automatically disable categorization of archives and logs for things in Wikipedia and other name spaces?

—Trappist the monk (talk) 14:11, 30 December 2020 (UTC)

A good question. I asked similar questions in our discussion Help_talk:Citation_Style_1/Archive_72#|nocat= about the |no-cat= parameter, but got no answer.

IMO, disabling categorization should be the default for uses outside mainspace (and perhaps a few other spaces, but not talk pages, archives, sandboxes, logs - TBD). If there would be some limited use for categorization on these pages, the |no-cat= parameter (renamed to something more semantically meaningful or merged into a more generic |debug= parameter) could be used to enable it, likewise to disable categorization in mainspace.

However, if we could agree to promise to the community that we won't leave problems caused by overly strict plausibility checks unaddressed for longer periods of time (like we did with some dates, the DOI check and still do with various identifier limit checks) and at least provide some parameter-specific override mechanism (e.g. via ((...))), we probably won't need a facility to disable categorization in mainspace at all any more.

--Matthiaspaul (talk) 23:57, 30 December 2020 (UTC)

I'm confused. The namespaces that cs1|2 does not categorize are listed in Module:Citation/CS1/Configuration in uncategorized_namespaces{}. You appear to be saying that we should be categorizing talk pages, archives, sandboxes, logs. I can see no justification for categorizing pages that are archives, or logs, or sandboxen (these kinds of pages are 'dead') nor can I see a reason to categorize talk pages. To get archived and logged pages out of the various error categories requires that editors visit each cs1|2 template with an error and manually add |no-tracking=yes. As new error detection is created so too, we create new 'dead' entries in the associated categories so it's back to the 'dead' pages to add yet more |no-tracking=yes. That is mind numbing drudgework but, at present, necessary to get those 'dead' pages out of the category. Why is it that you think that these 'dead' pages should be categorized? How does categorizing 'dead' pages benefit us?

—Trappist the monk (talk) 14:45, 31 December 2020 (UTC)

Matthiaspaul should probably answer, but I'd just like to jump in quickly and say I was only briefly confused. I believe, once the triple negative has been negotiated, that he thinks we should continue characterization for mainspace plus possibly a few other spaces to be identified, but those few other spaces should not include Talk etc. For me, that list would probably include File and Portal, and of course Category itself. This sounds like a topic for wider consensus. David Brooks (talk) 17:03, 31 December 2020 (UTC)

Sorry if I was unclear. Actually, I share your view that these special pages should not be categorized, at least not by default.

--Matthiaspaul (talk) 17:55, 31 December 2020 (UTC)

Ok, so why should we categorize talk pages? Long ago we decided that we would not categorize talk pages and I don't see any reason to change that decision.

I think that we should change to this which will prevent categorization of most archive and log pages:

uncategorized_subpages = {'/[Ss]andbox', '/[Tt]estcases', '/[^/]*[Ll]og', '/[Aa]rchive'}

—Trappist the monk (talk) 19:13, 31 December 2020 (UTC)

Honestly, I think we're in violent agreement. Happy New Year. David Brooks (talk) 02:11, 1 January 2021 (UTC)

Yep. Happy New Year as well. :-) --Matthiaspaul (talk) 14:11, 3 January 2021 (UTC)

suggested parameters when "access" is tried

Currently, if you do |access= CS1 templates suggest |access-date=. However, it probably should include |url-access= which (at least in my case) was what I was trying to get to. –MJL ‐Talk‐^☖ 18:20, 1 January 2021 (UTC)

.. or not because I guess there are more options than |url-access= per Help:CS1 errors#param_access_requires_param.

–MJL ‐Talk‐^☖ 18:24, 1 January 2021 (UTC)

I think this is down to the type of and way suggestions are made by the CS1/CS2 templates. Suggestion rules are typically created for

equivalent parameters in citation templates in other WP language entities to make reuse of citations easier
formerly supported parameters which might still occur on talk pages, in archives, etc. and which might occasionally be readded to mainspace when copying from such sources or when using old scripts
frequent spelling or capitalization mistakes of existing parameters
likely spelling mistakes or otherwise screwed parameters (e.g. swapped words)
free association of likely assumed parameter name

The access suggestion is issued as a by-product of a (possibly somewhat too lax) rule to catch possible misspellings of |access-date= not because someone could simply assume |access= to be the correct name of the |access-date= parameter. We could strengthen the rule to no longer trigger on variations of access without some form of date following, but given that we also have rules to catch some parameter names very similar to access as used in foreign language Wikipedias for |access-date= I don't think this would be an improvement.

The current system does not support more than one suggestion or other more sophisticated hints, a proposal for extension was recently given here:

Help_talk:Citation_Style_1/Archive_72#Hinting_on_Citation_Bot's_duplicate_parameters

--Matthiaspaul (talk) 15:11, 3 January 2021 (UTC)

Fixed display of parameter names in error message for parameters unsupported by some templates but found in the list of suggestions

Fixed two bugs in the error message display for parameters unsupported by some templates (like |publisher= with {{cite bioRxiv}}, {{cite citeseerx}} and {{cite ssrn}}) if the given parameter was in the list of parameter suggestions. The first bug caused the template to still suggest a parameter even if not supported by a particular template. The second bug caused the template to display the name of the suggested parameter rather than the given parameter.

Valid parameter |publisher= given: (supported by {{cite book}} but not by {{cite ssrn}})

Cite book comparison
Wikitext	`{{cite book\|publisher=Publisher\|title=Title}}`
Live	Title. Publisher.
Sandbox	Title. Publisher.

Cite ssrn comparison
Wikitext	`{{cite ssrn\|publisher=Publisher\|title=Title}}`
Live	"Title". `{{cite SSRN}}`: `\|ssrn=` required (help); Unknown parameter `\|publisher=` ignored (help)
Sandbox	"Title". `{{cite SSRN}}`: `\|ssrn=` required (help); Unknown parameter `\|publisher=` ignored (help)

Bogus parameter |xyz= given:

Cite book comparison
Wikitext	`{{cite book\|title=Title\|xyz=Publisher}}`
Live	Title. `{{cite book}}`: Unknown parameter `\|xyz=` ignored (help)
Sandbox	Title. `{{cite book}}`: Unknown parameter `\|xyz=` ignored (help)

Cite ssrn comparison
Wikitext	`{{cite ssrn\|title=Title\|xyz=Publisher}}`
Live	"Title". `{{cite SSRN}}`: `\|ssrn=` required (help); Unknown parameter `\|xyz=` ignored (help)
Sandbox	"Title". `{{cite SSRN}}`: `\|ssrn=` required (help); Unknown parameter `\|xyz=` ignored (help)

Misspelling |pulbisher= given instead of parameter |publisher=: (example for pattern matching rule)

Cite book comparison
Wikitext	`{{cite book\|pulbisher=Publisher\|title=Title}}`
Live	Title. `{{cite book}}`: Unknown parameter `\|pulbisher=` ignored (`\|publisher=` suggested) (help)
Sandbox	Title. `{{cite book}}`: Unknown parameter `\|pulbisher=` ignored (`\|publisher=` suggested) (help)

Cite ssrn comparison
Wikitext	`{{cite ssrn\|pulbisher=Publisher\|title=Title}}`
Live	"Title". `{{cite SSRN}}`: `\|ssrn=` required (help); Unknown parameter `\|pulbisher=` ignored (help)
Sandbox	"Title". `{{cite SSRN}}`: `\|ssrn=` required (help); Unknown parameter `\|pulbisher=` ignored (help)

Old parameter |pub= given instead of parameter |publisher=: (example for specific matching of rule)

Cite book comparison
Wikitext	`{{cite book\|pub=Publisher\|title=Title}}`
Live	Title. `{{cite book}}`: Unknown parameter `\|pub=` ignored (`\|publisher=` suggested) (help)
Sandbox	Title. `{{cite book}}`: Unknown parameter `\|pub=` ignored (`\|publisher=` suggested) (help)

Cite ssrn comparison
Wikitext	`{{cite ssrn\|pub=Publisher\|title=Title}}`
Live	"Title". `{{cite SSRN}}`: `\|ssrn=` required (help); Unknown parameter `\|pub=` ignored (help)
Sandbox	"Title". `{{cite SSRN}}`: `\|ssrn=` required (help); Unknown parameter `\|pub=` ignored (help)

--Matthiaspaul (talk) 23:45, 17 January 2021 (UTC)

url-access=free

Why is url-access=free not a permitted parameter? I'm thinking of citing something like this: Kramer, Hilton (June 26, 1977). "Black Art or Merely Social History?". The New York Times. p. D25.{{cite news}}: CS1 maint: url-status (link) Reprinted as Kramer, Hilton (June 26, 1977). "A show about black artists, not an anthology of achievements". St. Louis Post-Dispatch. p. 29. Retrieved 2021-01-19.{{cite news}}: CS1 maint: url-status (link) The review was originally published in the NYT (and a review by a NYT critic is obviously more significant than a review by a St. Louis Post-Dispatch critic) so the citation should refer to the review's original publication in the NYT. If a reader wants to verify the reference, though, it will probably be easier to visit the newspapers.com clipping of the St. Louis Post-Dispatch reprint of the review. I'd like to show the contrast between paywalled/free so readers immediately know to click on the second one. Is the idea just that not having an icon indicates it is free? I know that I could use but if I just stick it after {{cite web}} it doesn't put the icon in a parallel position. Thanks, Calliopejen1 (talk) 19:02, 19 January 2021 (UTC)

Titles in cs1|2 templates are presumed to be free-to-read unless marked otherwise (|url-access=subscription). cs1|2 does not highlight the norm. See Help:Citation Style 1 § Registration or subscription required.

Is it really a reprint? Both cites give the date as June 26, 1977. I would expect a 'reprint' to have a later date. The St. Louis Post-Dispatch article doesn't credit The New York Times so it isn't clear that Kramer is actually a writer employed by The New York Times or that the The New York Times is the source of the story. Perhaps some unnamed agency was involved in distributing the story. According to our article, Kramer was chief art cricket at The New York Times at the time, but St. Louis Post-Dispatch doesn't say that. Maybe 'also printed as' instead of 'reprinted as'.

For the St. Louis Post-Dispatch cite, consider adding |via=Newspapers.com because the source is delivered to our readers from Newspapers.com not from St. Louis Post-Dispatch. It's |page=5B, the page number actually printed on the page. For both cites, unless you are going to provide links to archives, delete |url-status=live, |archive-url=, and |archive-date=; the former has no meaning without the latter two (with values).

—Trappist the monk (talk) 20:12, 19 January 2021 (UTC)

Thanks. It's the same text so I assume it was written for the NYT and somehow distributed to the SLPD. Calliopejen1 (talk) 21:11, 19 January 2021 (UTC)

A couple of additional questions for a related citation: Ghent, Henri (October 10, 1976). "LACMA Takes a Giant Step for Black Heritage". The Los Angeles Times. pp. 1, 64-65 (Calendar section) – via Newspapers.com. Article continues here and here. ---- Is there some better way to indicate which section the article appeared in? (If they're just letters it would be something like A1, A64-A65, but Calendar-1, Calendar-64-65 or similar is pretty horrible.) Also, is there recommended way of handling this situation where there are multiple URLs for the multiple pages of the newspaper article? Thanks! Calliopejen1 (talk) 21:15, 19 January 2021 (UTC)

One way to write that citation might be:

{{cite news |last=Ghent |first=Henri |date=October 10, 1976 |title=LACMA Takes a Giant Step for Black Heritage |pages=1, [https://www.newspapers.com/clip/68027414/ 64], [https://www.newspapers.com/clip/68027363/ 65] |work=Los Angeles Times Calendar |url=https://www.newspapers.com/clip/68026751/black-american-art-crossing-the/ |via=[[Newspapers.com]]}}

Ghent, Henri (October 10, 1976). "LACMA Takes a Giant Step for Black Heritage". Los Angeles Times Calendar. pp. 1, 64, 65 – via Newspapers.com.

Another way might be:

{{cite news |last=Ghent |first=Henri |date=October 10, 1976 |title=LACMA Takes a Giant Step for Black Heritage |pages=1, [https://www.newspapers.com/clip/68027414/ 64], [https://www.newspapers.com/clip/68027363/ 65] |work=Los Angeles Times |department=Calendar |url=https://www.newspapers.com/clip/68026751/black-american-art-crossing-the/ |via=[[Newspapers.com]]}}

Ghent, Henri (October 10, 1976). "LACMA Takes a Giant Step for Black Heritage". Calendar. Los Angeles Times. pp. 1, 64, 65 – via Newspapers.com.

You know that the page 65 clipping is incomplete?

—Trappist the monk (talk) 22:45, 19 January 2021 (UTC)

Thanks for those ideas! Also fixed the clipping! Calliopejen1 (talk) 05:55, 20 January 2021 (UTC)

Title in a foreign language; text in English

Greetings, everyone. The line "language=English" does not return anything in a citation. Perhaps because it's considered the obviously default language in the Engligh Wikipedia. However, there are cases (like this one) where the source's text carries only the title in a foreign language while the text is in English. I'd suggest that this information should be allowed to appear in the citation. Whenever redundancy appears, i.e. someone puts that up for a typical English-language source, we can simply delete it. -The Gnome (talk) 11:39, 22 January 2021 (UTC)

The title of the report is understandable and searchable in English. The subtitle/title expansion is in French. I suppose a translation of that part could be provided with |trans-title=. You could also note that the body is a translation if the original was first published in French. If the report was published in both languages simultaneously there's no need to indicate a foreign language original. 65.204.10.231 (talk) 13:16, 22 January 2021 (UTC)

Since the letter is published in a mix of English and French, |language=en, fr is probably the correct form which will render as: (in English and French).

—Trappist the monk (talk) 14:06, 22 January 2021 (UTC)

Not sure if a subtitle in another language would qualify it as a mixed-language source, but I don't see any harm either way. 98.0.246.242 (talk) 00:55, 23 January 2021 (UTC)

Re Whenever redundancy appears, i.e. someone puts that [|language=] up for a typical English-language source, we can simply delete it. — I seem to recall that it's desired to have |language= given for all citations because it helps the other Wikipedias. —2d37 (talk) 01:59, 23 January 2021 (UTC)

SCITE_ extension display problem

My understanding is that the DOI parameter supports the addition of scite_ data (info from https://scite.ai/ ), but this addition is creating a display problem where "SCITE" is expanded to a huge extent, obscuring references which invoke the addin. Is this a known problem? --User:Ceyockey (talk to me) 02:12, 20 January 2021 (UTC)

Please link to a page where you are having trouble. – Jonesey95 (talk) 03:03, 20 January 2021 (UTC)

Seems to have self-corrected. The page I originally encountered was https://en.wikipedia.org/wiki/Antimicrobial_peptides, but now things are behaving properly. --User:Ceyockey (talk to me) 00:28, 24 January 2021 (UTC)

The url-status parameter of Template:Cite web

I see that in |url-status= there is a value for "unfit". I'm looking at a reference that is behind a paywall (so, useless to most), but for which there is an archive at archive.org. Should I use unfit for this purpose, or is there a better option, like creating a "paywall" value? Cyphoidbomb (talk) 00:12, 24 January 2021 (UTC)

No. Don't do that. "Unfit" is for when urls have been taken over by spammers or domain-parking ads or malware sites. It is not for marking your preference for open access. Also, you are making assumptions about what readers have access to that may not be true. My employer provides me subscription access to many paywalled academic journals and a few major newspapers, for instance, and I would prefer to be able to see the authoritative publisher link to resources to which I have access rather than some ersatz substitute which may or may not accurately represent the published version. —David Eppstein (talk) 00:17, 24 January 2021 (UTC)

Fair enough. I know that WP:ELNO doesn't want us to link to sites that require subscriptions or registration, so it seemed a reasonable question. Cyphoidbomb (talk) 01:53, 24 January 2021 (UTC)

But WP:ELNO does not apply to citations, it's for links in an "External links" section. --Matthiaspaul (talk) 18:39, 24 January 2021 (UTC)

You are looking for |url-access=. --Izno (talk) 00:58, 24 January 2021 (UTC)

Thanks. Cyphoidbomb (talk) 01:53, 24 January 2021 (UTC)

Volume 5, part 1

{{cite book |last1=Dexter |first1=Franklin Bowditch |title=Biographical sketches of the graduates of Yale College: with annals of the college history |date=1911 |publisher=Holt |location=New York |pages=41-45 |volume=5 |number=1 |url=https://archive.org/details/biographicalsket51dext |oclc=1041576339 |language=en}}

This is actually part 1 of a two-part volume. |number= does not do anything in cite book, so how would I reflect this fact? –MJL ‐Talk‐^☖ 19:37, 26 January 2021 (UTC)

{{cite book |last1=Dexter |first1=Franklin Bowditch |title=Biographical sketches of the graduates of Yale College: with annals of the college history |date=1911 |publisher=Holt |location=New York |pages=41-45 |volume=5, part 1 |number=1 |url=https://archive.org/details/biographicalsket51dext |oclc=1041576339 |language=en}}

Dexter, Franklin Bowditch (1911). Biographical sketches of the graduates of Yale College: with annals of the college history. Vol. 5, part 1. New York: Holt. pp. 41–45. OCLC 1041576339.

My advice is don't overthink it. Your job is to ensure that readers know where to find the information. – Jonesey95 (talk) 19:48, 26 January 2021 (UTC)

The book's publisher doesn't seem to have named that volume as part 1. Volume V covers the period June 1792 – September 1805. Volume VI apparently takes up where volume V left off and covers the period September 1805 – September 1815. These details suggest that there may not be any 'part 1' or 'part n'; the handwritten annotation on the title pages notwithstanding. If the publisher didn't include a part descriptor, then it would seem that you should not include such a descriptor in a citation.

—Trappist the monk (talk) 20:06, 26 January 2021 (UTC)

DOI encoding

|doi=10.1126/science. 1140516 encodes as https://doi.org/10.1126/science.+1140516 instead of as https://doi.org/10.1126/science.%201140516 Note that this DOI has a space in it! AManWithNoPlan (talk) 19:08, 27 January 2021 (UTC)

Why do they do that? Why?

We've been using the default encoding (mw.uri.encode ('10.1126/science. 1140516')) for a very long time. If we are to believe the Scribunto documentation, we can change to mw.uri.encode ('10.1126/science. 1140516', 'PATH') which differs only from the default by encoding space characters as %20 instead of +. I am not inclined to relax the 'no spaces' requirement just because this one doi uses a space character. I've tweaked Module:Citation/CS1/Identifiers/sandbox. Here, the doi works:

Cite book comparison
Wikitext	`{{cite book\|doi=10.1126/science. 1140516\|title=Title}}`
Live	Title. doi:10.1126/science. 1140516. `{{cite book}}`: Check `\|doi=` value (help)
Sandbox	Title. doi:10.1126/science. 1140516. `{{cite book}}`: Check `\|doi=` value (help)

and here, the error message is suppressed (doi still works):

Cite book comparison
Wikitext	`{{cite book\|doi=((10.1126/science. 1140516))\|title=Title}}`
Live	Title. doi:10.1126/science. 1140516.`{{cite book}}`: CS1 maint: ignored DOI errors (link)
Sandbox	Title. doi:10.1126/science. 1140516.`{{cite book}}`: CS1 maint: ignored DOI errors (link)

I do not know if this change will adversely affect other identifier links.

—Trappist the monk (talk) 19:38, 27 January 2021 (UTC)

The allowing of white space is odd, but to actually do it is bad. My brain might bleed if I try to understand. Seems like a mistake that they have to live with. I once can upon a single DOI the was in the format of 10.X/Y/10.X/Y - double paste they were now stuck with. AManWithNoPlan (talk) 02:29, 28 January 2021 (UTC)

Using ((...)) to allow spaces in DOIs as an exception looks like a good solution to me. I found a few more DOIs containing spaces, but all of them were invalid and the result of incorrect OCR or transmission errors caused by line-wrapping. --Matthiaspaul (talk) 19:19, 29 January 2021 (UTC)

PMID numbers

Hello, at the Arecibo Observatory article there's a valid PMID of 33214727 despite the red ink saying 'Check |pmid= value'. I presume that the range of valid PMID numbers needs extending- please can someone fix this? TIA, Yadsalohcin (talk) 08:20, 25 November 2020 (UTC)

Thanks for reporting. The current limit is set to 33200000 per Help talk:Citation Style 1/Archive 73#PMID limit.

I have increased it to 33500000 in the sandbox.

--Matthiaspaul (talk) 13:23, 25 November 2020 (UTC)

I'm guessing that 33500000 (>33214727!) should do it- does it propagate on automatically from the sandbox? Despite refreshing, there's still red ink at Arecibo Observatory Yadsalohcin (talk) 15:01, 25 November 2020 (UTC)

The live template gets updated from the sandbox every couple of months. The next update will probably happen in January.

As there have been quite a number of changes already, I would also support an earlier update, but it can be carried out by admins only. Also, as we are in the middle of a process to fade out many old parameter variants (not the functionality) we have to make sure that some old parameters have been updated in mainspace before we can roll out the next update.

Alternatively, we could just update the limits in the live template.

In the linked thread we are discussing possible means how to make it easier to update the limits so that keeping them tight does not cause inconvenience for editors. If you have ideas, your input is welcome there.

--Matthiaspaul (talk) 20:30, 25 November 2020 (UTC)

This is getting annoying to editors. I just saw 33273063. Please just set a {{template edit request}} for the specific template and value you want and let's get this limited problem fixed. DMacks (talk) 17:15, 6 December 2020 (UTC)

Thanks Trappist the monk for[3]. DMacks (talk) 15:55, 9 December 2020 (UTC)

It might be a good idea to figure out the growth rate of these PMID numbers. At the time or writing, the "latest literature" section on https://pubmed.ncbi.nlm.nih.gov/ gives 33338219, already 17000 more than the november 19 arecibo article. This growth rate feels ridiculous, since it would imply that PMID would've gone from 0 to 33500000 in less than 3 years. Someone got to analyze the XML dump. --Artoria 2e5 🌉 21:33, 19 December 2020 (UTC)

Citation needed; there is no such implication. The PMID database has been around for much longer than three years. 17,000 in a month does seem reasonable, though. – Jonesey95 (talk) 20:38, 20 December 2020 (UTC)

Hello, https://pubmed.ncbi.nlm.nih.gov/33511486 is over 33500000. The upper limit needs to be increased. Thanks. —Bruce1ee^talk 08:37, 30 January 2021 (UTC)

Maintenance message when ref= is the default ref

I have added a maintenance message in the sandbox when |ref= is the default CITEREF generated:

Cite book comparison
Wikitext	`{{cite book\|author=_A_\|ref=CITEREF_A_2020\|title=T\|year=2020}}`
Live	_A_ (2020). T.`{{cite book}}`: CS1 maint: ref duplicates default (link)
Sandbox	_A_ (2020). T.`{{cite book}}`: CS1 maint: ref duplicates default (link)

Cite book comparison
Wikitext	`{{cite book\|author=_A_\|ref=CITEREF_A_2020\|title=T\|year=2020}}`
Live	_A_ (2020). T.`{{cite book}}`: CS1 maint: ref duplicates default (link)
Sandbox	_A_ (2020). T.`{{cite book}}`: CS1 maint: ref duplicates default (link)
The ref parameter is actually {{sfnref}} just to prove it works. I don't really understand why author jumped to the end in the displayed wikitext.

This can be used to clean up wikitext, and I imagine when the great deletion of |ref=harv is over can be merged with that category, either as maintenance or error (basically, "stop trying so hard" :).

I have also made a dedicated Module:Citation/CS1/testcases/anchor where other tests regarding the anchor can be found and regressions indicated. I found a couple unexpected cases down the way in test_ref, indicated on the module page-proper.

(I plan to add maybe one or two more cases/assertions to ensure that display names don't impact the CITEREF generation, which I was thinking about the other day.)

I also did some code cleaning related to Ref and the CS1/2 style setting code, since by the time the style code was being reached, the module was setting |ref= to harv if it was not yet set. --Izno (talk) 07:17, 30 January 2021 (UTC)

While I have nothing against issuing this maintenance message in general, I wonder why an editor would have explicitly encoded a CITEREF-style anchor this way in the first place - I have never seen someone doing this. Thinking about possible reasons for this, an editor might have wanted to link to this CITEREF-anchor manually and found the implicit default name difficult to "guess", therefore, once found out, the editor would specify it explicitly for easier maintenance within the article. There might be several anchors with similar names, therefore easy to mix up. Perhaps also to have the pattern in the code as search target. If so, it might be counter-productive to remove the |ref= parameter as people would have to start guessing the actual anchor name again.

Therefore, for further evaluation it's certainly good to be pointed to cases where it was defined this way, but I'm not sure, if the message should be visible to all editors and if removing the parameter is always an improvement. Relying on implicit defaults is often convenient and might save a few bytes for a parameter, but spelling out things explicitly often has advantages as well (self-documenting ("someone was here, thinking about this, and this is the setting used here"), stability, if the default might change in the future). It really depends on the circumstances, that's why I, per good user-interface design rules, always propose to have dedidated keywords also for the default cases instead of only being able to specify deviations from the defaults.)

--Matthiaspaul (talk) 17:18, 30 January 2021 (UTC)

According to this simple search there are about 112 articles that use |ref=CITEREF....

—Trappist the monk (talk) 17:32, 30 January 2021 (UTC)

I have seen the hard-coded version regularly, either in non-template versions assigned an ID, or in CS1 templates on greater occasion. I assume that sometimes the former are converted to CS1/2 where (I assume) the ID is kept out of a sense of conservative change. I assume "big pages" is another use case, where someone was using CS1 templates but didn't want to pay the cost of Sfnref transclusions. All mostly irrelevant now. Either way, this also serves to catch unneeded Sfnref uses.

My assertion for your supposed "its hard to discover the default" is that users don't, and certainly shouldn't, do that any more. The ones interested in not trying to figure it out should indeed use a simple form of it, but this can be done anyway with sfnref.

We already have consensus to remove the keyword of relevance, so that dimension also falls flat with me.

It is for now a maintenance message. --Izno (talk) 18:06, 30 January 2021 (UTC)

[1] Dan Greiner (12 March 2012). Dual Address Space & Linkage-Stack Architecture. SHARE 118. Atlanta. Session 10446.

[2] A. Padegs (May 1983). "System/370 Extended Architecture: design considerations". IBM Journal of Research & Development. 27 (3). IBM: 198–205. doi:10.1147/rd.273.0198. – a subsection titled "31-bit addressing" begins on page 201.

[1]

[1]