fbpx
Wikipedia

Help talk:Citation Style 1/Archive 77

August 25, 2023

url-status usurped

Latest comment: 2 years ago8 comments5 people in discussion

At Clanwilliam (County Limerick) I set several {{Cite web}} as url-status=usurped however the original links seem to be remaining in place, which is not what the documentation implies. I would not expect this, but admit I may have made a spelling mistake or something. In this case it is not too serious, in other cases it could be an inappropriate website. Thankyou. Djm-leighpark (talk) 21:04, 15 May 2021 (UTC)

The documentation is here. It says, in part:
When the original URL has been usurped for the purposes of spam, advertising, or is otherwise unsuitable, setting |url-status=unfit or |url-status=usurped suppresses display of the original URL (but |url= and |archive-url= are still required).
|url-status= is meaningless without |archive-url=. Where you set |url-status=usurped, those templates do not have |archive-url= so nothing happens.
—Trappist the monk (talk) 21:34, 15 May 2021 (UTC)

I have tweaked the Module:Citation/CS1/sandbox so that it adds a maintenance category when |url-status= is set but |archive-url= is not set. There were many upon many |url-status=<something> without |archive-url= that Monkbot task 18 cleaned up. That bot task is now suspended so we must seek another way of cleaning up this sort of problem.

{{cite book/new |title=Title |url-status=live}} → Title.{{cite book}}: CS1 maint: url-status (link)

Further, we might enhance this a bit so that |url-status=dead when |archive-url= has a value is also included in the maint cat; this is analogous to Category:CS1 maint: ref duplicates default.

Once the maintenance cat has been cleared, we should convert it to a normal error because, to be meaningful, |url-status= requires |archive-url=.

—Trappist the monk (talk) 22:05, 15 May 2021 (UTC)

Maybe the documentation could better clarify that a usurped url invalidates the link (if there is no legitimate archive link). In such cases the link should be removed. If the citation depends on the link for verification (likely where {{cite web}} is concerned), the citation itself is no longer valid and should be removed. 98.0.246.242 (talk) 22:29, 15 May 2021 (UTC)
I disagree that the citation is invalid and should be removed. It is the link that has become invalid, the citation itself was (likely) in good faith but verificability was lost. Citation removal can be tricky as it can sometimes(but not always) be recovered. As it is we leave it mostly in the hands of the bot(s) to hope successful archives are created, and they dont mark if this has not happened. And in the end manual dead/usurped link recovery can sometimes be more successful than the tool. I'm not actually sure what IAbot would make of the example given here. Djm-leighpark (talk) 01:00, 16 May 2021 (UTC)
Citations must verify the wikitext in real time, not sometime in the past or future. If they don't, they should be removed. It is worse to include a misleading (because unverifiable) citation, than having no citation at all, as it gives unverified claims the appearance of truthfulness. This is not something to leave to any bot. You, as editor, must support what you edit. This is policy, and non-negotiable. At the very least, mark the citation as needing work, and quickly (meaning in hours, not days) either correct it or remove it. 68.173.79.202 (talk) 13:06, 16 May 2021 (UTC)
Replaced, maybe, not necessarily removed. Please read WP:DEADREF. Known usurped/dead linked sources should, as you say, be marked or upgraded. I disagree with your strict statement that the citation itself is no longer valid and should be removed. — JohnFromPinckney (talk) 16:42, 16 May 2021 (UTC)
The last point at WP:DEADREF refers to removal when verification depends on the link only, without an archived version or other sourse. This was the rationale for the earlier comments above. Although the guideline on this point includes the following incomprehensible statement: if there is no archived version of the web page (be sure to wait ~24 months). No idea what this means in normal English. 98.0.246.242 (talk) 18:10, 16 May 2021 (UTC)

ssrn

Latest comment: 2 years ago6 comments4 people in discussion

Editor Nemo bis made this edit which is more or less pointless because identifier access is by default paywalled unless explicitly set to free. The Editor did add a comment in the code: 'often free to read, but rate limited and may require subscription'. I do not know how true that statement is so invite Editor Nemo bis to discuss that change here.

—Trappist the monk (talk) 14:24, 9 May 2021 (UTC)

I've removed the default option, since it access varies. SSRN started hosting pay-to-read articles, despite it being clearly against their stated mission. Headbomb {t · c · p · b} 16:09, 9 May 2021 (UTC)
But in addition to that, you need to login in order to be able to actually be able to download the supposedly open things. If you're logged out, you're subject to restrictions à la metered paywall, where the second PDF you download in a day will require you to login or things like that.
Changing the default access level is not "pointless". It's useful for people to be able to navigate the identifiers and links we provide in citations, which is the entire point of having them in the first place. Having the grey icon next to one identifier and the green icon next to another makes it easier to reach the full text without having to open a dozen tabs for each citations and without having to study the purpose and access model of each target website.
Nemo 17:18, 9 May 2021 (UTC)
"You need to login in order to be able to actually be able to download the supposedly open things", again, not for most papers. Most papers are free, and don't require login. Some might require registration. Others might require you to pay. Headbomb {t · c · p · b} 18:04, 9 May 2021 (UTC)
Support for |ssrn-access=free added:
Cite ssrn comparison
Wikitext {{cite ssrn|ssrn-access=free|ssrn=12345|title=Title}}
Live "Title". SSRN 12345.
Sandbox "Title". SSRN 12345.
It would be nice to track |ssrn= because each use of that parameter should be reviewed and |ssrn-access=free added where appropriate. But, recent XfDs prevent that without we first RfC for permission.
—Trappist the monk (talk) 12:04, 21 May 2021 (UTC)
? Is there an XfD with such implications? I thought the recent CfD (which is peripherally still under discussion) concerned different, specific parameters? 24.103.251.114 (talk) — Preceding undated comment added 12:47, 21 May 2021 (UTC)

Protected edit request on 16 April 2021

Latest comment: 2 years ago27 comments12 people in discussion

Please revert this edit, since it was based on the incorrect and now overturned closure of this RfC. The new close finds that "non-hyphenated parameters should not be deprecated in citation templates"; therefore the edit as it stands is in clear violation of this consensus. RandomCanadian (talk / contribs) 13:36, 16 April 2021 (UTC)

Accessdates and the like were not deprecated in that edit, so this edit request is based on a flawed premise. Headbomb {t · c · p · b} 13:47, 16 April 2021 (UTC)
Except it still marks these parameters as "discouraged", which is not what the close of the RfC says, does it? "This means that existing hyphenated (e.g. access-date) and non-hyphenated (e.g. accessdate) parameters should both continue to be supported by the templates." - if I can read the template correctly, that should mean they should be set to "true", not "pre-deprecation purgatory" (since there is explicitly no consensus to deprecated the parameters, now or at some future point). RandomCanadian (talk / contribs) 14:03, 16 April 2021 (UTC)
That edit has already been reversed in the module sandboxes, and the category description has been changed to explain that it is only a tracking category. Conversations continue above about how best to track the remaining unhyphenated parameters. – Jonesey95 (talk) 14:38, 16 April 2021 (UTC)
Oppose. Discouraged ≠ deprecated, and discouragement need not lead to deprecation. The RFC outcome (Option C) doesn't restrict "developer discouragement", so there is no need to reverse the edit. The module will continue to support both parameters. The module comment, re: "pre-deprecation purgatory", may be too aggressively suggesting deprecation, and can be changed or removed.   ~ Tom.Reding (talk ⋅dgaf)  16:27, 17 April 2021 (UTC)
The finding that these parameters are in any way "discouraged" was reversed, and the associated changes made should thus also be reversed. Nikkimaria (talk) 18:15, 17 April 2021 (UTC)
The concept of "discouragement" wasn't 'reversed' in close#2; it wasn't even mentioned. As such, the RFC has no bearing on whether or not to track these parameters in any way.   ~ Tom.Reding (talk ⋅dgaf)  21:36, 17 April 2021 (UTC)
Close#1 invented the concept of "discouraged", and was reversed, meaning that the concept no longer has any basis. The other changes associated with the reversed closure should similarly be reversed. Nikkimaria (talk) 21:50, 17 April 2021 (UTC)
Close#1 invented the concept of "discouraged" Not true. The first close invented the term developer discouraged. Elsewhere on this page, I wrote that developer discouraged is a new term to me. On my talk page, the closer confirmed the term is a made-up term created for the purpose of the close. The notion of discouraged cs1|2 parameters has been around for quite a while. Before it was deprecated and finally removed, use of |editors= was discouraged and at one time had its own tracking category Category:CS1 maint: uses editors parameter (July 2016 – August 2020). |authors= is discouraged; see, for example, the documentation at {{cite book}} and Category:CS1 maint: uses authors parameter (since July 2016).
—Trappist the monk (talk) 23:02, 17 April 2021 (UTC)
the closer confirmed the term is a made-up term created for the purpose of the close - ie. the close invented the concept as used in the context under discussion - the changes resulting from that close. The current close does not support the notion that these parameters are discouraged as you define it, nor that they require a maintenance category. Nikkimaria (talk) 23:17, 17 April 2021 (UTC)
You wrote: Close#1 invented the concept of "discouraged". That is a false statement because, as I explained, cs1|2 has had the concept of "discouraged" parameters since 2016. The closer's term, developer discouraged, as noted on my talk page where the closer wrote: No, I literally just made it up, was made up for the purposes of that close. Close #2 is mute with regard to categories; is mute with regard to the term discouraged; is mute with regard to the term developer.
—Trappist the monk (talk) 15:22, 18 April 2021 (UTC)
We should probably delete the main page and many other things, while we're at it, since the close made no mention of it.   ~ Tom.Reding (talk ⋅dgaf)  16:16, 18 April 2021 (UTC)
If you want to delete the main page, or make parameters discouraged, feel free to start a new RfC. In the meantime though, since the initial close was undone, the associated changes should also be undone. Nikkimaria (talk) 00:53, 19 April 2021 (UTC)

The request was for the module to be reversed; while it is nice that this has been done in the sandbox already, it doesn't answer the original request. If sandbox changes get automatically transported to the main module, then please tell us when. If not, then please inform us when this change will be reverted. Fram (talk) 17:22, 16 April 2021 (UTC)

Looking at Module:Citation/CS1, updates only happen every few months, and the most recent update was just a few days ago. It will probably be a while, given the need to avoid re-rendering millions of pages too frequently. Vahurzpu (talk) 02:51, 17 April 2021 (UTC)
Seeing as the initial RfC result was implemented within a week, it seems reasonable that the new result would also be implemented promptly, rather than waiting a few months. Nikkimaria (talk) 14:48, 17 April 2021 (UTC)
Indeed, I think that would be reasonable. I just don't think that we know what the exact next step is, especially with an unnecessary CFD started by thread OP. --Izno (talk) 14:54, 17 April 2021 (UTC)
RandomCanadian (the OP) didn't start the CfD. Fram (talk) 08:21, 19 April 2021 (UTC)
@RandomCanadian: Can this be closed? It's being discussed elsewhere (here and here). It's been more than ten days already while this edit request has been pending.. –MJL ‐Talk‐☖ 03:05, 28 April 2021 (UTC)
Note that Wikipedia:Categories for discussion/Log/2021 April 16#Category:CS1 maint: discouraged parameter has now been closed as delete. * Pppery * it has begun... 18:10, 9 May 2021 (UTC)

Now that the CfD has closed as "delete", can this edit request please be executed, and can the necesarry changes be made to depopulate the category? Fram (talk) 07:06, 10 May 2021 (UTC)

It would probably be better to wait for Wikipedia:Deletion review/Log/2021 May 10#Category:CS1 maint: discouraged parameter to close before taking any action. 13:23, 10 May 2021 (UTC) — Preceding unsigned comment added by Pppery (talk • contribs)
That DRV has now been closed without consensus to overturn the original CfD. Can someone please do this now? * Pppery * it has begun... 13:14, 18 May 2021 (UTC)
I wouldn't rush... The DRV reviewer's opinion has holes that have to be attended to. 64.18.9.210 (talk) 15:31, 18 May 2021 (UTC)
Please drop the stick. * Pppery * it has begun... 16:40, 18 May 2021 (UTC)

Now that the RfC close review, the CfD, the DRV, and the DRVRV are all closed, can we perhaps finally do this? Fram (talk) 14:21, 21 May 2021 (UTC)

  Done by Amakuru (this exact edit wasn't implemented, but code to depopulate the discouraged parameter was, which is what is fundamentally being asked for) * Pppery * it has begun... 15:14, 25 May 2021 (UTC)
Thank you. Fram (talk) 08:34, 26 May 2021 (UTC)

CS1 module suite update (date TBD) April 2021

Latest comment: 2 years ago41 comments12 people in discussion

I suggest that we do an out-of-cycle update to the cs1|2 module suite on a date TBD sometime between now and the end of April 2021, primarily in order to implement the reclosure of the unhyphenated parameter RFC. Here are the changes to date since the last major update on 10 April:

Module:Citation/CS1

  • detect generic author, editor, etc names; discussion
  • Remove code to detect, categorize, and display hidden maintenance message for "discouraged" parameters, per RFC reclosure.
  • add "CS1 uses parameter: $1" properties tracking categories; discussion
  • emit error when |first= is wikilinked; discussion
  • revise how date month-name auto-translation is enabled; discussion
  • add support to allow editors to see citations that emit properties cats; discussion
  • |url-status= without |archive-url= maint cat; discussion

Module:Citation/CS1/Configuration

  • detect generic author, editor, etc names
  • Remove code to detect, categorize, and display hidden maintenance message for "discouraged" parameters, per RFC reclosure.
  • add "CS1 uses parameter: $1" properties tracking categories
  • remove support for unused |isbn13= and |ISBN13=; discussion
  • remove support for previously deprecated parameters |booktitle=, |chapterurl=, |episodelink=, |mailinglist=, |mapurl=, |nopp=, |publicationdate=, |publicationplace=, |serieslink=, |transcripturl=
  • add support for nrf-gg, nrf-je language codes; discussion
  • revise how date month-name auto-translation is enabled
  • add support to allow editors to see citations that emit properties cats
  • Removed reliance on .error; discussion
  • |url-status= without |archive-url= maint cat
  • add support for |ssrn-access=; discussion

Module:Citation/CS1/Whitelist (updated 25 May 2021)

  • Remove support for previously deprecated parameters |booktitle=, |chapterurl=, |episodelink=, |mailinglist=, |mapurl=, |nopp=, |publicationdate=, |publicationplace=, |serieslink=, |transcripturl=
  • Remove code to detect, categorize, and display hidden maintenance message for "discouraged" parameters, per RFC reclosure.
  • add "CS1 uses parameter: $1" properties tracking categories
  • remove support for unused |isbn13= and |ISBN13=
  • add support for |ssrn-access=
  • remove support for url and URL from {{cite arxiv}}, {{cite biorxiv}}, {{cite citeseerx}}, and {{cite ssrn}}; discussion
  • Support for some template-specific parameters limited to those templates; discussion

Module:Citation/CS1/Date validation

  • extend allowed dates in |pmc-embargo-date= validation to two years; discussion
  • revise month-name validation; discussion
  • add support to allow editors to see citations that emit properties cats

Module:Citation/CS1/Identifiers

  • add support for |ssrn-access=

Module:Citation/CS1/Utilities

  • add support to allow editors to see citations that emit properties cats

Module:Citation/CS1/COinS

  • No changes

Module:Citation/CS1/styles.css

  • Removed reliance on .error

Module:Citation/CS1/Suggestions

  • Uncomment suggestions for parameters moving from deprecated to unsupported

Links to relevant discussions, along with implementation date suggestions, are welcome in the above list; they should all still be on this page. I will come back and add the discussion links if I have time later. – Jonesey95 (talk) 21:39, 19 April 2021 (UTC)

arxiv-class

Really don't see the point of having |arxiv-class=, class doesn't cover anything else, and is only supported by {{cite arxiv}}. There's no confusion possible, and I object its creation. Headbomb {t · c · p · b} 23:32, 19 April 2021 (UTC)
Yes, you know all this only if you follow this page. There's a chance that the module may be targeted to a wider audience. On that outside chance, the module should present editors a consistent approach, and its documentation should expand on consistency as one of the design principles applied. Additionally, the documentation could include info about the particular template, such as the one you referred to above. Again on the outside chance that editors may not encounter Arxiv or arxiv citations on a daily basis. I know, it's a drag. But you are not the one doing it, it is somebody else's burden. 173.52.226.51 (talk) 00:39, 20 April 2021 (UTC)
Actually, I'm the one doing most arxiv-related cleanup. Again, there is no confusion with anything, class doesn't pertain to anything but cite arxiv because class is only used with cite arxiv. If you don't use cite arxiv, you will not see class anywhere. |arxiv-class= is busy work that serves no purpose but to cause confusion by renaming a uniformly-used parameter into a mismash of new and old for no reason. Headbomb {t · c · p · b} 00:50, 20 April 2021 (UTC)
What was meant as "burden" was the updating/maintenance of the module. Otherwise, and sincerely, I believe that any work you do to clean up this area is commendable. 98.0.246.242 (talk) 03:28, 20 April 2021 (UTC)
"class" is a pretty vague parameter. I'm not personally sold on moving deck chairs around though so... Izno (talk) 01:15, 20 April 2021 (UTC)
These discussions about parameter labels are very refreshing. Questions spring to mind: how is an editor to know that only {{cite arxiv}} uses a "class" parameter? Secondly, is there an implicit assumption that there will forever be only one "class"-labeled parameter in all of CS1/2? I understand that people with intimate knowledge of Arxiv will find the new term unnecessary and convoluted. I am not in favor of aliases, but I would recommend |arxiv-class= as an alias of |class= for this template. CS1/2 covers a diverse field of cited sources. It is not unusual to find in any article a number of different CS1/2 citation templates. At some point, it may be easier for the average editor to have to deal with a single standardized nomenclature (the one native to CS1/2) rather than wade through unfamiliar "industry" practice. Assuming that such nomenclature is simply and concisely explained. 98.0.246.242 (talk) 03:19, 20 April 2021 (UTC)
How is an editor to know that only {{cite arxiv}} uses a "class" |class= only appears in {{cite arxiv}} documentation, and is undermentioned anywhere else. Headbomb {t · c · p · b} 12:03, 20 April 2021 (UTC)
I have my doubts that even seasoned template editors would know this. It may require an extraordinary level of attention to the particulars of template/parameter documentation. 98.0.246.242 (talk) 23:57, 21 April 2021 (UTC)
CS1/CS2 parameters should follow a consistent naming scheme within the CS1/CS2 universe so that they are easy to memorize (and ideally can be constructed from memorizing the scheme without having to remember a particular parameter specifically or to look up it up the documentation). They should also be self-explanatory so that if a user runs into a parameter s/he can guess the meaning without having to look up the documentation. While there are still areas for improvement, I think we have improved quite a bit regarding this in recent years.
|class= by itself is quite meaningless and ambiguous. There are other possible "classes" that are used in conjunction with references. We don't currently use them but we might have other |...-class= parameters in the future, so I think it is time to prepare for this. We don't need to hurry, |class= can stay for the while being, but the |arxiv-class= parameter should exist as well for a smooth transition.
Parameters and attributes named "class" are also used for other purposes (for example in HTML), making it difficult to reliably search for the CS1 parameter |class=. Searching for |arxiv-class=, however, would not give false positives.
As the |arxiv= parameter is supported by other CS1 templates than {{cite arxiv}} as well, is there a specific reason why we do not support the |class= parameter in other templates as well?
--Matthiaspaul (talk) 19:48, 22 April 2021 (UTC)
Simply put, no. This is citations, not CSS. We do not need to preemptively disambiguate something that doesn't need disambiguation. As for not supporting it in other citations, it's because it's not relevant to other citations. This is something that's only relevant to {{cite arxiv}}. There is zero point in forking the parameter and breaking tools for, we have consistant usage, let's keep it that way. Headbomb {t · c · p · b} 19:52, 22 April 2021 (UTC)

Reverted the arxiv-class thing in the sandbox. This does not have consensus. Headbomb {t · c · p · b} 05:01, 28 April 2021 (UTC)

Headbomb, I think your removal was incomplete. The sandbox renders with red Lua errors. Scroll up and down this page to see them. – Jonesey95 (talk) 05:10, 28 April 2021 (UTC)
He removed the whole line and probably should not have since that is not undoing what the original edit did. ;) Fixed. Izno (talk) 05:19, 28 April 2021 (UTC)
Yes, thanks for fixing. LUA is awful. Headbomb {t · c · p · b} 05:55, 28 April 2021 (UTC)
I don't find your arguments that we shouldn't have |arxiv-class= very convincing.
{{cite arxiv}} is a CS1/CS2 citation template and within that family of citation templates all parameters should follow the same naming scheme in order to make it easier for editors to remember or even derive parameter names and their relations. This holds true also for parameters which are for some reason private to a specific template only, because otherwise we could have a |class= parameter in another template with a completely different meaning. |class= being a modifier for one of the identifiers (|arxiv=) its name should be |arxiv-class= following the example of all other such parameters we have (|doi=/|doi-broken-date=, |pmc=/|pmc-embargo-date=, |asin=/|asin-tld=) and a whole bunch of |bibcode-access=, |doi-access=, |hdl-access=, |jstor-access=, |ol-access=, |osti-access=, |s2cid-access=. They all start with the identifier name they belong to and end on the argument type to be entered (a date, a top-level-domain, an access state), so following this scheme a class type belonging to |arxiv= should be specified in a parameter named |arxiv-class=. This would be consistent. |class= by itself is not following this scheme and therefore is inconsistently named. It is also a meaningless parameter name by itself, so people running into it cannot derive its purpose from its name, and for people who are potentially using it, it is more difficult to remember because it is an exception to the mind model of how other parameter names were chosen.
Unfortunately, you didn't answer my question why we don't support the parameter in all CS1/CS2 parameter supporting |arxiv=. You just stated it would not be relevant in other templates, but did not answer why. In the original thread you even asked for |class= to become kind-of a mandantory parameter for {{cite arxiv}}; from this I derive that it is important to you. So, why is it important in {{cite arxiv}} and not in, say, {{cite book}} which supports |arxiv= as well? I'm asking because right now it is handled as an exception, and it would simplify the code if we won't have to treat it like an exception.
Regarding HTML/CSS, the existence of the "style" attribute was brought forward against naming a parameter |style=, which is (one reason for) why we settled on |name-list-style= eventually. Similar situation for "class".
Regarding scripts, adding a parameter is not breaking anything. And it would be trivial to change the scripts to support both parameters |arxiv-class= and |class=, anyway (if we don't fade out |class= at a later stage). If, as you stated, you are mostly alone working in this area, updating the scripts should be even easier. Of course, in an ideal world a good parameter name would have been chosen right from the start, so that there would be no desire to change it, but if we want to reach the goal of having a logical and consistent interface for all CS1/CS2 templates eventually, we shouldn't wait harmonizing parameter names until we actually run into a name conflict, because the longer we wait the more we will have to clean up afterwards. Therefore, even if we do not disable support for |class= soon (in order to keep backward compatibility until everyone has switched), we should start to educate people to use |arxiv-class= instead as soon as possible.
--Matthiaspaul (talk) 07:18, 28 April 2021 (UTC)
Except that class doesn't modify in anyway arxiv. What you'll find in {{cite arxiv}} is most typically {{cite arxiv|...|eprint=1234.54321|class=hep-ex}}. Headbomb {t · c · p · b} 09:27, 28 April 2021 (UTC)
I'm inclined to agree with Editor Matthiaspaul because I too don't find Editor Headbomb's reason persuasive. Editor Headbomb appears to be the only editor who is opposed; Editor Izno appears to be indifferent; IP editor (98.0.246.242, 173.52.226.51) appears to support; Editor Matthiaspaul supports; and I support because I am persuaded by the argument that parameter names should be correctly descriptive (we should think about |ref= – in another discussion). So, I think that Editor Headbomb's edit should be reverted.
—Trappist the monk (talk) 13:10, 28 April 2021 (UTC)
The argument for renaming the parameter arxiv-class in cite arxiv is as nonsensical as renaming isbn to book-isbn in cite book. It's a parameter unique to cite arxiv, there is no need for disambiguation, especially at the expense of creating unnecessary complexity that will cause maintenance headache and tool breakage. Headbomb {t · c · p · b} 15:49, 28 April 2021 (UTC)
I think right now I lean toward "let's not move the deck chairs around with only 3 in support and 1 opposed" at this time. Adding a parameter later is easy; removing one later is not. Generally I'd be appreciative for opinions from editors who aren't you four. I see persuasive arguments for changing the name but not sufficiently persuasive if all it is doing is moving deck chairs (or with the stated purpose of moving deck chairs).
That all said, I continue to prefer to wait until the CFD for the category responsible for this update be settled first, so perhaps others may comment and settle the matter. Izno (talk) 14:21, 28 April 2021 (UTC)
I would say that any discussion in these parts involving 4 editors is packed to the rafters... 98.0.246.242 (talk) 01:12, 4 May 2021 (UTC)
As much as it pains me to say it, Izno was right to say that we should wait for the CFD closure. Blargh. – Jonesey95 (talk) 18:20, 9 May 2021 (UTC)
What is the use of |class= even in {{Cite arXiv}}? This is not physical library where we need to first take the stairs to astro-ph. Is is because some areas have low standards or because it helps identify areas like a journal title would or is it another reason? AManWithNoPlan (talk) 01:52, 21 May 2021 (UTC)
It's the topical classification of the arxiv, which corresponds to moderation sections (i.e. standards). hep-ph is in the High Energy Physics - Phenomenology section, hep-ex is the High Energy Physics - Experimental section. gen-ph is general physics [which is where a lot of woo nonsense get classified into], and so on. A while back, this was part of the identifier (physics/0123467), but the identifier changed to YYMM.####, with the classification listed separately in square brackets. Headbomb {t · c · p · b} 03:23, 21 May 2021 (UTC)
See also User_talk:Headbomb/unreliable#gen-ph. Headbomb {t · c · p · b} 03:27, 21 May 2021 (UTC)
Years ago it was explained to me that a national physics conferences have an anything goes crack-pot section in which basically all talks were accepted, but were limited to 5 minutes including the changing speaker time. We chemists generally have a poster section like that. AManWithNoPlan (talk) 14:27, 21 May 2021 (UTC)

Anyone want to update the list and support this update?

A number of changes have been made to the sandboxes since I posted the above list. Is there support for this out-of-cycle update? If so, please speak up here, and someone needs to update the above list of changes. – Jonesey95 (talk) 05:10, 28 April 2021 (UTC)

So long as arxiv-class is kept out, what's in there shouldn't be controversial / reflects RFCs. Headbomb {t · c · p · b} 09:25, 28 April 2021 (UTC)
I've made an attempt at updating the list of changes from the comments section of each sandbox, although there appear to be some edits to Module:Citation/CS1/Identifiers/sandbox and Module:Citation/CS1/Configuration/sandbox that don't have any entry in the changes list. (And I support this update happening, in order to finally implement the result of the discouraged parameters CfD) * Pppery * it has begun... 00:47, 21 May 2021 (UTC)
... does something else need to be done before this update happens? * Pppery * it has begun... 00:02, 22 May 2021 (UTC)
I believe it should be good to go from what's in the Sandbox. @Trappist the monk: is there anything holding this up? I would sync from the sandbox myself, but it looks like nobody except Trappist has edited Module:Citation/CS1/Whitelist in the past eight years, so I don't want to tread on any toes! We do need to get the latest updates in though, because currently certain parameters are still being tracked as "discouraged". Cheers  — Amakuru (talk) 21:02, 23 May 2021 (UTC)
More silence ... @Amakuru: The CS1 module suite is not WP:OWNed by Trappist the monk, and this would not be the first time an external admin edited it. The only reason Module:Citation/CS1/Whitelist hasn't been edited by anyone else in years is that its contents have never been controversial before, whereas various other CS1 modules have been controversial and were edited by others at various times. You should just do it, and either copy from Module:Citation/CS1/Whitelist/sandbox to Module:Citation/CS1/Whitelist, or just implement #Protected edit request on 16 April 2021 above and revert the last two edits to Module:Citation/CS1/Whitelist(going back to Special:PermaLink/999303024). It's more important that things get done than vague worries about things like tread[ing] on [...] toes at this point (now more than 2 weeks after the CfD was closed, and one week after the DRV was closed) * Pppery * it has begun... 14:03, 25 May 2021 (UTC)
@Pppery:   Done. As you say, there has been enough time for this to be enacted, and nobody has even replied to the above comments. So I have gone ahead and pushed the sandbox changes from Module:Citation/CS1/Whitelist/sandbox live into Module:Citation/CS1/Whitelist. If anything else needs doing, or this leads to any errors then please let me know.  — Amakuru (talk) 15:13, 25 May 2021 (UTC)
Thanks. I don't think anything else needs doing, although it will likely take several weeks for the Job queue to remove all 1,000,000+ pages from the category. * Pppery * it has begun... 15:22, 25 May 2021 (UTC)

Tracked parameter code (partially?) removed

The "discouraged parameter category" this CFD has been closed, and Pppery set the hyphenated parameters back to "true" in Whitelist/sandbox (no judgment on this action, just stating facts to keep the timeline straight). I don't think that change to just one of the modules will completely undo the parameter tracking system that we have set up. It is unclear to me whether the sandboxes are in a deployable state as of this time stamp. – Jonesey95 (talk) 18:20, 9 May 2021 (UTC)

I believe it's deployable in the sense that nothing would break were they to be deployed, but there's some now-dead code in the Configuration and main modules that someone could clean up if they felt inclined to. * Pppery * it has begun... 00:45, 10 May 2021 (UTC)
I would recommend waiting. I have commented at the closer's talk page (well one of them) and at CfD regarding the closure, which imo is ripe for review. So let's see where this will go, if anywhere. Relax and enjoy! 98.0.246.242 (talk) 01:44, 10 May 2021 (UTC)
Note that this IP has now taken the CfD to deletion review at Wikipedia:Deletion review/Log/2021 May 10#Category:CS1 maint: discouraged parameter. * Pppery * it has begun... 13:23, 10 May 2021 (UTC)
... and the DRV has now been closed without consensus to overturn the CfD closure. Can this please go ahead now? * Pppery * it has begun... 13:14, 18 May 2021 (UTC)
Maybe, maybe not. I have asked for certain clarifications from the DRV reviewer. Depending on whether the answers are forthcoming and make sense, this will then proceed accordingly. 67.254.224.137 (talk) 19:53, 18 May 2021 (UTC)

I am having a nice discussion with the DRV reviewer about this. But I don't want to be seen as holding up anything that happens here. I have a feeling that the issue of the biased CfD nomination may have to be escalated to a wider forum more appropriate to reviewing administrator decisions. So please proceed, I have no objections, as the final resolution of this may take a while. And of course anything can be reversed :-) 64.18.9.192 (talk) 12:10, 19 May 2021 (UTC)

Preprint template TemplateData showing multiple "not valid parameter" errors

Latest comment: 2 years ago1 comment1 person in discussion

{{cite arxiv}}, {{cite biorxiv}}, and {{cite ssrn}} are all showing at least one "not valid parameter" error message at the top of their TemplateData sections. Some of the messages conflict with existing template documentation. I don't mess with TemplateData, but if anyone wants to sort this out, that would be helpful. If actual documentation changes are needed, I'm happy to help with those. – Jonesey95 (talk) 16:36, 25 May 2021 (UTC)

New "unsupported parameter" errors after Whitelist update

Latest comment: 2 years ago5 comments3 people in discussion

A note to those who watch the "unsupported parameter" error category: the Whitelist portion of the module was updated today, and it has resulted in a flow of new pages into Category:CS1 errors: unsupported parameter. I believe that I have compiled a comprehensive list of the relevant changes below:

The documentation for the relevant CS1 templates does not entirely match these changes yet, and in some cases, the Whitelist, instead of the documentation, may need to be modified. The documentation for {{cite serial}}, for example, currently shows |season= as valid, but it generates an error. Post any questions here. – Jonesey95 (talk) 17:02, 25 May 2021 (UTC)

@Jonesey95: thanks for compiling this list. If there are any Whitelist changes that need to be effected, and Trappist isn't around, then I'll be happy to help out. Cheers  — Amakuru (talk) 17:07, 25 May 2021 (UTC)
@Amakuru: I guess this was done to finally implement the RfC consensus (seeing as the hyphenated parameters are no longer classified as "discouraged")? @Jonesey95 why is the second "cite episode" unlinked when the other repeated template names are linked -BRAINULATOR9 (TALK) 17:28, 25 May 2021 (UTC)
@Brainulator9: yes, that's correct. See the section above, at Help talk:Citation Style 1#Anyone want to update the list and support this update? I implemented all the changes that were waiting in the sandbox, which I assume is the usual procedure. Presumably it's those changes that have led to the now-deprecated parameters mentioned above. Cheers  — Amakuru (talk) 17:39, 25 May 2021 (UTC)
Yes, the change to the Whitelist has resulted in a new batch of citations being detected as using unsupported (not deprecated; there is a meaningful difference when it comes to this module at least) parameters. – Jonesey95 (talk) 18:30, 25 May 2021 (UTC)

Identifying paper with cite conference

Latest comment: 2 years ago2 comments2 people in discussion

The documentation at template:cite conference for {{cite conference}} is incomplete, e.g., it mentions |book-title= but does not describe its use nor its relation to |conference= and |title=. As a concrete example, if I want to cite the paper The interface message processor for the ARPA computer network, which was presented at the 1970 Spring Joint Computer Conference and printed in AFIPS Conference Proceedings Volume 36 1970 Spring Joint Computer Conference, do I mark it up as 

{{cite conference | title = The interface message processor for the ARPA computer network | pages = 551-567 | conference = 1970 Spring Joint Computer Conference | book-title = AFIPS Conference Proceedings Volume 36 1970 Spring Joint Computer Conference | year = 1970 | publisher = AFIPS Press }}

which will render as

"The interface message processor for the ARPA computer network". AFIPS Conference Proceedings Volume 36 1970 Spring Joint Computer Conference. 1970 Spring Joint Computer Conference. AFIPS Press. 1970. pp. 551–567.

or do I abbreviate SJCC, remove some of the redundant text or wikilink, e.g., AFIPS, in the parameters? Shmuel (Seymour J.) Metz Username:Chatul (talk) 17:51, 25 May 2021 (UTC)

You figured it out. I have updated the documentation to explain how to use |book-title=. I don't know when that explanation went missing, if it was ever there. – Jonesey95 (talk) 18:43, 25 May 2021 (UTC)

Template:Cite sign

Latest comment: 2 years ago5 comments3 people in discussion

What parameters are supported by Template:Cite sign, and where is the blank version we are told to copy? DuncanHill (talk) 22:45, 24 May 2021 (UTC)

I'm also having this issue. The template needs more descriptors specific to signs, too. Tyrone Madera (talk) 19:21, 25 May 2021 (UTC)
@Tyrone Madera: As there appears to be nobody here either willing or able to help I shall ask at WP:VPT instead. DuncanHill (talk) 15:20, 30 May 2021 (UTC)
I've made a start on a blank version. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:28, 30 May 2021 (UTC)
@Pigsonthewing: thank you, and is there anything in this which you might find helpful? DuncanHill (talk) 16:18, 30 May 2021 (UTC)

edtf date formats as cs1|2 date parameter values (-2)

Latest comment: 2 years ago7 comments4 people in discussion

MediaWiki giveth; MediaWiki taketh away. Changes made because of phab:T132308 are to be rolled back so I have removed support for the EDTF (YYYY-MM-XX) date format from the sandboxen.

—Trappist the monk (talk) 22:15, 11 May 2021 (UTC)

We might need a bot run to fix the 600+ articles in which this format currently appears. – Jonesey95 (talk) 22:43, 11 May 2021 (UTC)
I don't think so. In bureaucratic terms, a WP:BRFA is far too costly. I've begun picking away at the 600 with awb as the mood takes me; I'll be done soon enough, after all, there is no hurry.
—Trappist the monk (talk) 23:00, 11 May 2021 (UTC)
"In bureaucratic terms, a WP:BRFA is far too costly." This is the sort of thing that could be approved in a day after a short trial. Headbomb {t · c · p · b} 23:17, 11 May 2021 (UTC)
Could be AWBd in 2 hours instead... Izno (talk) 23:57, 11 May 2021 (UTC)
That has never been my experience. And besides, in the current toxic atmosphere 'Monkbot task anything' is likely to incite drama. No thanks.
Current batch of YYYY-MM-XX dates converted. There are likely to be more between now and when the rolled-back version of citoid goes live.
—Trappist the monk (talk) 13:12, 12 May 2021 (UTC)
I've been wondering if we shouldn't just make a |machine-date= for machine filling. (I briefly considered |iso-date= but that doesn't indicate to users that they shouldn't use that.) Use it as the backup date if someone should add |date=. Izno (talk) 03:44, 31 May 2021 (UTC)

Cite serial

Latest comment: 2 years ago4 comments4 people in discussion

Is there any reason that {{Cite serial}} (274 transclusions) cannot be merged into {{Cite episode}} (over 15K transclusions)? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:29, 30 May 2021 (UTC)

I think it should be redirected after ensuring that nothing will break. I've never fully understood the difference between them. In practice, {{cite serial}} appears to be used quite a bit for individual episodes instead of something that is part of "a collection of episodes" that is not a season (UK "series"). The edit summary for its creation says Creating "Cite serial" - it's a copy of "Cite episode" except it italicizes a serial title, rather than putting it in quotes. For use of tv shows which use both serial titles and episode titles. In practice, I don't think it's used for that in most cases. Perhaps we should just go through the citations one by one and convert the ones that cite a single episode (without a serial title) to {{cite episode}}, and then see what is left. – Jonesey95 (talk) 17:41, 30 May 2021 (UTC)
Agreed. I tried to conceive a valid reason for one to cite an entire season/series rather than the particular episode(s), and it escapes me. The closest I could come to a rationale would be an article citing multiple episodes of the same series, where the editor might prefer a compound reference with the series as the main citation and the individual episodes in sublist. A bit involved. 161.221.13.10 (talk) 20:30, 30 May 2021 (UTC)
Surprisingly no previous TFD on the point that shows up in WLH. I vaguely recall this being somewhat contentious, but maybe that's some weird memory to do with Dr. Who fans (you know how they get).
The migration to CS1 discussion may be illuminating as to actual purpose and why they weren't merged way back when. Izno (talk) 20:42, 1 June 2021 (UTC)

How to markup reports done under contract to government agencies?

Latest comment: 2 years ago8 comments4 people in discussion

I want to create a citation for https://apps.dtic.mil/dtic/tr/fulltext/u2/a206308.pdf in Timeline of operating systems#1980s, and am having trouble locating the correct template and parameters. The markup 

{{cite report | title = Quarterly Status Report - Report #1 | id = AD-A206 308 | date = 15 March 1989 | url = https://apps.dtic.mil/dtic/tr/fulltext/u2/a206308.pdf | publisher = TRW - Federal Systems Group - Systems Division }}

produces "Quarterly Status Report - Report #1 (PDF) (Report). TRW - Federal Systems Group - Systems Division. 1989-03-15. AD-A206 308." and seems like a reasonable start, but it is missing, e.g., the contract number, the order code, the program code, the program name, the sponsoring agency. I intend to use |work= for the program name as a stopgap, but that doesn't seem right. What is the proper markup? 15:58, 31 May 2021 (UTC)Shmuel (Seymour J.) Metz Username:Chatul (talk)

Chatul Is all of that detail really neccessary to uniquely identify the document? Roger (Dodger67) (talk) 16:31, 31 May 2021 (UTC)
Agreed, that detail is not generally necessary. You might consider |via= for DTIC and |work= for Advanced Computing Systems: An Advanced Reasoning-Based Development Paradigm for Ada Trusted Systems and Its Application to MACH. That would be the sufficient details to find a copy. (Also |archive-url= and -date, of course.) --Izno (talk) 16:58, 31 May 2021 (UTC)
You can also put any text that you want to append after the cite template itself, and inside the ref tags: Quarterly Status Report - Report #1 (PDF) (Report). TRW - Federal Systems Group - Systems Division. 1989-03-15. AD-A206 308. Contract number ABCD123. Sponsored by DARPA. etc. – Jonesey95 (talk) 21:48, 31 May 2021 (UTC)
Are you proposing
{{cite report | title = Quarterly Status Report - Report #1 | id = AD-A206 308 | date = 15 March 1989 | url = https://apps.dtic.mil/dtic/tr/fulltext/u2/a206308.pdf | work = Advance Computing Systems: An Advanced Reasoning-Based Paradigm for Ada Trusted Systems and its Application to MACH | via = https://apps.dtic.mil/dtic/tr | publisher = TRW - Federal Systems Group - Systems Division }} Contract number MDA 972-89-C0029. Sponsored by [[DARPA|ARPA]], order No. 6414, Program Code No. 9T10.
BTW, the actual title included the date. Was it proper to redact it since I had a |date=, or should I have left it in? Shmuel (Seymour J.) Metz Username:Chatul (talk) 14:36, 1 June 2021 (UTC)
Via is not for URLs; use DTIC in context. Yes, that is what Jonesey is proposing. Izno (talk) 14:51, 1 June 2021 (UTC)
Yes, 'suppressing' the date is fine and/or idiomatic when it appears in the title (probable exception: you have nothing else to put in the title). Izno (talk) 14:55, 1 June 2021 (UTC)
I'm not aware of any guidance in WP:MOS on what level of detail to provide in citations; such guidance, and links to it from template documentation, would be helpful. Shmuel (Seymour J.) Metz Username:Chatul (talk) 14:36, 1 June 2021 (UTC)
Sufficient information to identify where the information being cited originates such that another sufficiently motivated person can verify the content being cited themselves (c.f. WP:Citing sources). For web sources, this is fundamentally the URL and perhaps the archive URL. Anything else is largely a bonus. The parameters this template supports are almost always sufficient to identify a source. Certainly, contract number, sponsoring agency, order number, and program code are superfluous given the other information in the cite report you have filled in response to Jonesey's comment. Izno (talk) 14:54, 1 June 2021 (UTC)

|lay-url and |laysummary

Latest comment: 2 years ago4 comments4 people in discussion

WP:MEDPOP suggests using {{{laysummary}}}. However, when I put that into the template, apparently, because somebody decided somewhere that unhyphenated parameters are not OK, I get this error message... So the solution is either A) to add the suggested alternative as an alias (as consistent with making templates easier to use for everyone) or B) to update MEDPOP to enforce whatever you folks over here have decided on doing. Cheers, RandomCanadian (talk / contribs) 19:25, 1 June 2021 (UTC)

Updated medpop.
The 'lay source' parameters that are supported are a topic of discussion for the chopping block in a few recent instances on this talk page, because if the lay source really is valuable as a source, it should get its own template, not be hacked badly into the journal article's template. Current use of lay-url is only 2300 pages. Izno (talk) 20:24, 1 June 2021 (UTC)
|lay-date=, |lay-format=, |lay-source=, and |lay-url= should go away because cs1|2 templates are intended to cite a single source. These parameters make it sort-of-possible to cite two independent sources using a single cs1|2 template but, the citation of the second source is flawed because these four parameters cannot be used to create a complete second citation and there is no support in the citation's metadata for the second source. If the lay source is truly important to an article (WP:MEDPOP seems to suggest that most lay sources are not), then {{cite magazine}}, {{cite news}}, {{cite web}}, etc are better choices for citing the lay source.
—Trappist the monk (talk) 23:09, 1 June 2021 (UTC)
the lay source is often the orginal source too because of template misuse. AManWithNoPlan (talk) 23:16, 1 June 2021 (UTC)

cite newspaper

Latest comment: 2 years ago15 comments11 people in discussion

Given that pages using {{cite news}} outnumbers {{cite newspaper}} by over a factor of 100, and newspaper is just a redirect. Is there any reason to not have the Citation Bot covert newspaper to news when it finds them? AManWithNoPlan (talk) 01:14, 27 May 2021 (UTC)

If that were the only change Citation Bot made to a page, it would be a cosmetic edit, and six editors would show up with pitchforks and torches and block the bot. Other than that, I don't see a problem with it, and the guideline at WP:BRINT vaguely supports replacing template redirects with their targets, as long as there is some other substantive change being made to the page at the same time. – Jonesey95 (talk) 15:12, 27 May 2021 (UTC)
No pitchforks from my side, but I think that {{cite newspaper}} is actually the more appropriate name for the template. {{cite news}} has the advantage that it is shorter. What gives? Keep them as was decided upon by the editor who added them. ;-) --Matthiaspaul (talk) 16:57, 29 May 2021 (UTC)
The ratio of pages with news to newspaper is about 200 to 1. I highly doubt almost anyone is make a decided choice - some editors carefully choose between issue and number in cite journal, so never say never. I find that many applications of newspaper are to online newspapers and many applications of news are to paper copies. The existence of two templates only can confuse editors and in no way helps users. AManWithNoPlan (talk) 17:05, 29 May 2021 (UTC)
In fact, I'm one of those who tries to carefully distinguish between journals and magazines, numbers and issues, written-at and publication places, etc., always trying to use what is used in the actual source, if that can be determined, and use the most specific parameter or template name for it. While some of this gets displayed the same way at present, this may not always remain so in the future. For example, if we switch the display of journals to use abbreviations instead of the symbolic notation we use now, we will ideally have to distinguish in the display of "No." and "Iss.". This will also have to happen when we finally add support for periodicals which indicate both, a number and an issue, as we long planned to do. Similar, if I cite from what can be clearly identified as a newspaper, either because it advertises itself as such, or if I cite from something for which a paper issue exists, I use {{cite newspaper}}. If I cannot determine this, I typically use {{cite news}} if it is a news outlet and {{cite web}}, if it is some other type of web page. While {{cite newspaper}} and {{cite news}} do the same at present, at some point in the future, they may deviate in different directions supporting different parameters or requiring a different rendering (like {{cite journal}} and {{cite magazine}}) or different meta-data creation. So, it makes sense to give the editor, who is actually citing the source, the chance to document what it actually is - it will be much more difficult for other editors and at a later point in time - and next to impossible for a bot. Occasionally, someone might have used {{cite journal}} for a magazine, {{cite magazine}} for a journal, etc. and it is perfectly fine for another editor to improve that, but unless a bot is utilizing a curated datebase indicating if some outlet is a journal or a magazine, this is not something a bot should try to do. Same for {{cite newspaper}} and {{cite news}}.
Another reason why I generally tend to prefer {{cite newspaper}} over {{cite news}} is that the latter is somewhat ambiguous a name as we also have {{cite newsgroup}} - sometimes, when I haven't used the template for some while, I wonder if {{cite news}} is the same as {{cite newsgroup}} or {{cite newspaper}}, so it is safer to use the longer, more specific names.
--Matthiaspaul (talk) 08:44, 30 May 2021 (UTC)
Do the existing templates support the distinctions that you wish to preserve? Does the documentation describe all of the relevant parameters? I know that for, e.g. {{cite book}}, it is not possible to preserve the hierarhical relation among part, chapter and section, since all of the types of locations are synonymous or undefined, and only one location and its URL is allowed. You can't maintain fidelity without enhancing the existing templates. Try, e.g.,

{{cite book | title = Text with nested divisions | part = foo | chapter = bar | section = baz }}

and you get

"bar". Text with nested divisions. {{cite book}}: More than one of |section= and |chapter= specified (help); Unknown parameter |part= ignored (help)

Would what you want to do with {{cite newspaper}} have similar issues? Shmuel (Seymour J.) Metz Username:Chatul (talk) 15:15, 30 May 2021 (UTC)
I would not consider fidelity a requirement. Citations are pointers to sources. As long as the source can be easily located with a minimum of information, citations do not need to be exact representations of the source's structure. The additional info may give a better picture of the source to the reader or it may make it easier to locate. This has to be measured against clutter and complexity. Also, templates are just that. They are formatted applications of the most generic cases, of common denominators and regular trade practice. Covering more specialized cases is not really the main objective, and imo is not worth the programming effort. Especially so when programming is subject to irrational whims and the technicalities surrounding such work have to be submitted for review. 23.246.115.158 (talk) 13:05, 31 May 2021 (UTC)
The final sentence above was not referring to editor Chatul. 64.18.9.192 (talk) 13:52, 31 May 2021 (UTC)
Is {{cite newspaper}} still appropriate when the news isn't available on paper but only as web page text, audio or video? Certes (talk) 17:12, 29 May 2021 (UTC)
Is "page" appropriate in the present medium? Can we please step away a bit from micromanaging everything. Sheesh! 98.0.246.242 (talk) 17:19, 29 May 2021 (UTC)
FCOL, {{cite newspaper}} is and always was a redirect. When did WP:NOTBROKEN become obsolete (or should I say, deprecated). Sheesh indeed. -- Michael Bednarek (talk) 17:29, 29 May 2021 (UTC)
https://en.wikipedia.org/wiki/Wikipedia:Templates_for_deletion/Log/2007_October_13#Template%3ACite_newspaper {{cite newspaper}} was voted to be deleted, and the redirect was put in place to hold us over until all the usages were removed. AManWithNoPlan (talk) 14:13, 2 June 2021 (UTC)
Not quite. The template was indeed deleted in October 2007 and then recreated as a redirect in February 2008. Redirects to templates are a dime a dozen, and sometimes more used than their canonical names. There's nothing wrong with that and there's no need to do anything about it. -- Michael Bednarek (talk) 14:54, 2 June 2021 (UTC)
It is not obsolete, but as a cosmetic change with other non-cosmetic changes template redirects are quite often converted to their canonical name to simplify the root wikitext. As Jonesey above points out this is routine and implemented in other (semi)automated systems.
CitationBot converting to the canonical form in this case seems quite reasonable. Izno (talk) 15:51, 2 June 2021 (UTC)
Redirects may be free, but free can mean many things, in computing. I've spent a lot of my "free" time discovering and programming around them (or missing and causing errors), that would have been better used elsewhere. That doesn't mean eliminate all aliases, they can be useful, but when they are small in number let's convert to canonical. If they fail to reappear (no one is using them) then delete. -- GreenC 19:37, 2 June 2021 (UTC)

Suffixes?

Latest comment: 2 years ago5 comments4 people in discussion

Just curious, in the Cite xxx templates, what about suffixes like Jr., Sr., III, etc.? They are part of the "first" parameter, right? Thanks! — XComhghall (talk) 10:43, 2 June 2021 (UTC)

Correct. I would separate with comma to disambiguate compound first names or middle anything. 24.103.251.114 (talk) 11:20, 2 June 2021 (UTC)
Clarify:
{{cite book|first=FirstA FirstB, Sr|last=Last|title=Title}}
Last, FirstA FirstB, Sr. Title.{{cite book}}: CS1 maint: multiple names: authors list (link)
This is not a guideline, just a personal pref. 24.103.251.114 (talk) 11:31, 2 June 2021 (UTC)
I generally do not place the comma per MOS preference for no-comma, but yes, placing it in |first= is correct. I also do not add a comma for some future where we can detect commas in our name parameters for maintenance. Izno (talk) 15:56, 2 June 2021 (UTC)
There is a guideline for this. See MOS:JR, which says When the surname is shown first, the suffix follows the given name, as Kennedy, John F. Jr. Also, in an accompanying note, we find: Do not append "Jr." and the like to the surname (Kennedy Jr., John F.) especially in citations, as this pollutes the surname metadata with extraneous information and will also alter the sorting order, to after all simple "Kennedy" entries. So |first=John F. Jr. would be correct per MOS in a cite template. – Jonesey95 (talk) 16:07, 2 June 2021 (UTC)

Having a special value for url-status when a page is geo-restricted?

Latest comment: 2 years ago8 comments5 people in discussion

This came to my mind when I was considering citing a page from a video streaming website. It had a TV show description I needed but rendered a "content isn't available in your country" template page until I used some VPN magic. Still it is crawlable by Internet Archive (with desired content shown in place), so despite the fact that citing a source like this should be avoided if possible, I can imagine having a thing like "url-status=georestricted" that could be used alongside with "archive-url". Kadilov (talk) 12:10, 2 June 2021 (UTC)

Georestrictions may have legal ramifications that should not be gamed by archive links. I suggest offering the source in a different, legitimate form. 50.74.165.202 (talk) 13:27, 2 June 2021 (UTC)
I agree after giving some more thought to this. As I see it now, an archiving service may be the first actor who violates something in this chain, though it does not relieve others from responsibility. Kadilov (talk) 11:55, 3 June 2021 (UTC)
This is a regular request. Please review the archives for why it has not been implemented. Izno (talk) 15:38, 2 June 2021 (UTC)
Thanks. Now found this discussion. Kadilov (talk) 11:55, 3 June 2021 (UTC)
Policy blocks are fluid and contingent. For example, China blocks Germany over a dispute. Readers from China want URLs hosted in Germany to be archived to avoid the block. Later, China lifts the block and the status changes again, but only for Chinese readers. There is no way to say "url-status=georestricted" but only if you are located in China, and only for the duration of the block. This is a straightforward example, they get more complicated. Recommend a browser plugin that auto redirects to the Wayback version when there is a 404 (or similar). Avail at bottom of the page WP:LINKROT. -- GreenC 19:25, 2 June 2021 (UTC)
I don't see these examples as applying to enwiki. I perhaps wrongly, interpreted the OP as applying to georestrictions on enwiki users. I would make sure that bypassing such restrictions through the use of an archive is not a copyvio or other legal misstep before inserting an archive-url. 24.103.101.218 (talk) 22:51, 2 June 2021 (UTC)
I think we should not use correlations between language and a country of residence here. As for laws, I am not a lawyer but now I think of my proposal as something that arguably encourages breaking typical Terms of Service (provided by a website). Kadilov (talk) 11:55, 3 June 2021 (UTC)

Cite lecture?

Latest comment: 2 years ago6 comments3 people in discussion

Currently, {{cite speech}} includes the parenthetical "(Speech)" after the title of a speech. Is there a way to change this—in particular, to make it render as "(Lecture)"? --Usernameunique (talk) 13:51, 2 June 2021 (UTC)

No... actually. For some reason unknown. And it's using the TitleNote meta-parameter, instead of the one that might make sense which is |type= (which is how cite interview and I think cite report do it). Bizarre. Izno (talk) 15:49, 2 June 2021 (UTC)
Because {{cite speech}} uses |event= which renders to the left of |type=:
{{cite speech |title=Title |event=Event |type=Type}}
Title (Type). Event.
The event is not a speech.
At the time that {{cite speech}} migrated to Module:Citation/CS1 the mechanism that I adopted was a convenient solution (and there had been no call to override the default annotation). |type= (if present) should override the default annotation text (which is a candidate for i18n) in {{cite speech}} so I'll work on those things.
—Trappist the monk (talk) 16:48, 2 June 2021 (UTC)
But ... There are these and this one so while what I have hacked in the module works:
{{cite speech/new |title=Title |type=Lecture |event=Event}}
Title (Lecture). Event.
it doesn't work when |type= is being used to indicate the type or medium of the cited source.
—Trappist the monk (talk) 17:35, 2 June 2021 (UTC)
Thanks, Trappist the monk. Should I use {{cite speech/new}}, or are you still tinkering with it and {{cite speech}}? --Usernameunique (talk) 03:52, 4 June 2021 (UTC)
{{cite speech/new}} is a sandbox so should never be used in article space. As I noted above, there is the issue of |type=Video etc that still requires resolution. It may be that the very few {{cite speech}} templates that use |type= or |medium= are better served by {{cite AV media}}. For template-to-template consistency, it may be that {{cite speech}} should be like all other cs1|2 templates that have default annotation values so that |type=Lecture or |type=Video simply overrides the default annotation. These things have not been decided.
—Trappist the monk (talk) 13:17, 4 June 2021 (UTC)

Script-series

Latest comment: 2 years ago1 comment1 person in discussion

Requesting for script-series (and trans-series) parameter the way we have script-title and script-chapter in Template:Cite book. It is only logical since if a foreign book is a part of foreign series and has its title written in script-title, it has its own script-series parameter as well. Lulusword (talk) 07:08, 5 June 2021 (UTC)

Whitelist/Blacklist

Latest comment: 2 years ago8 comments5 people in discussion

Many organizations are moving away from usage of these terms. Google and Microsoft have had guidelines against it for over a decade, though not requirements. There are many alternatives, sometimes they can be even more clear. It doesn't mean our particular usage is racist, it almost never is, but it is systemic and potentially inflammatory. Some articles about it:

  • [1], "my colleague went on to impress upon me the discomfort he felt everyday living in a world where black was equated with bad [disallowed] and white with good [allowed]."
  • [2]

These terms are a reminder that culture considers white good/allowed and black bad/disallowed. As a large and globally inclusive organization we can do better with an easy change in wording. -- GreenC 19:57, 2 June 2021 (UTC)

Until whitelist and blacklist stop being the mainstream default terms for these things, we shouldn't do linguistic gymnastics to avoid them. No different than white hat and black hat hackers, or the myriad of other things. White and Black (the colors) being good/bad is enshrined in culture (or alternatively Dark/Light). You have to do a huge non-sequitur leap to go from villainous colour/light schemes meaning good/bad to mean that skin color is good/bad. Headbomb {t · c · p · b} 21:08, 2 June 2021 (UTC)
Because the rest of the core software is changing its terms as is a large set of other software? It's not exactly mental gymnastics to change "Whitelist" to "Validargs" or similar, which coincidentally describes the purpose of the module. Izno (talk) 21:57, 2 June 2021 (UTC)
I've got no objection to renaming the module/function name to ValidArgs/InvalidArgs or similar, if that's all that's proposed. Headbomb {t · c · p · b} 22:05, 2 June 2021 (UTC)
I'm pretty sure that's the only use of the terms in this module set. I'm sure someone could control F find more... Izno (talk) 22:21, 2 June 2021 (UTC)
We recently declined a similar re-naming at Wikipedia talk:Spam blacklist#Requested move 10 February 2021. – Finnusertop (talk ⋅ contribs) 22:24, 2 June 2021 (UTC)
Not only is this topic a can of worms, but it's part of a bigger can of worms. Should our sensitity to left handed people cause us to refrain from using such words as gauche and sinister? Should such issues be discussed in isolation, or should there be a broader discussion of terms that might be construed as pejorative towards one group or another?
With regards to the specific issue of blacklist versus blocklist, the anti-spam community debated it for decades and never came to a consensus; both terms are still in use. RFC 5782 uses both terms. Personally I favor blocklist, but if a DNSBL or organization has the other in its name, then changing it here would be WP:OR at best. Shmuel (Seymour J.) Metz Username:Chatul (talk) 02:47, 6 June 2021 (UTC)
The term Dark Ages has been disputed, and continues to be, for 100s of years. Historians say don't use it, but then continue to use it (occasionally - less so than before). More in popular culture than professionally. That is probably what blacklist/whitelist will be, a sort of indication of amateur or retrograde. We can't get rid of it socially (systemic), but it can be disputed by those who have examined the issue. It's a question of where you want your app or organization to be. Some of course will embrace it to be edgy or counter, but that has its own problems. The easiest solution IMO is just don't use it, avoid the issue, if you can. The neutral term is Early Middle Ages. -- GreenC 03:24, 6 June 2021 (UTC)

Examples for Template:Cite report

Latest comment: 2 years ago3 comments2 people in discussion

Hi! I've stumbled into Template:Cite report and I would find it really helpful if someone could give examples of how to use the template in the template description. I feel like I could use an example of a report being cited using the template, and some other users might also benefit as well. Best, Tyrone Madera (talk) 16:17, 5 June 2021 (UTC)

There is an example of such just above. Izno (talk) 17:46, 5 June 2021 (UTC)
Izno, Awesome. Should it be put in the template as an example? Tyrone Madera (talk) 17:55, 5 June 2021 (UTC)

Issue/number being ignored?

Latest comment: 2 years ago2 comments2 people in discussion

I have just updated some citation in the article Jerusalem District, and it looks like the issue / number fields are being ignored. This happens with both cite report and cite web. Am I using the citation wrong / is this a known issue, or does the template need to be fixed? Thanks. —Ynhockey (Talk) 10:21, 6 June 2021 (UTC)

|issue= and |number= are periodical parameters. {{cite web}} and {{cite report}} are not periodical templates. When I look at the two sources that use |number= at Jerusalem District, I don't see any indication of an issue or number 71.
See the table that shows which templates support |issue=.
—Trappist the monk (talk) 12:02, 6 June 2021 (UTC)

url in name parameters

Latest comment: 2 years ago13 comments8 people in discussion

We don't allow wikilink markup or urls in |<name>-linkn= parameters. We do allow wikilink markup in the name's |lastn= parameter but not in the name's |firstn= parameter. I just stumbled upon this {{cite web}} template that has a url in |author=. So I added a test to Module:Citation/CS1/sandbox to catch names that have urls:

Cite web comparison
Wikitext {{cite web|access-date=2014-03-01|author=Dr. [http://science.jpl.nasa.gov/people/Benner/ Lance A. M. Benner]|date=2013-11-18|publisher=NASA/JPL Asteroid Radar Research|title=Binary and Ternary near-Earth Asteroids detected by radar|url=http://echo.jpl.nasa.gov/~lance/binary.neas.html}}
Live Dr. Lance A. M. Benner (2013-11-18). "Binary and Ternary near-Earth Asteroids detected by radar". NASA/JPL Asteroid Radar Research. Retrieved 2014-03-01. {{cite web}}: External link in |author= (help)
Sandbox Dr. Lance A. M. Benner (2013-11-18). "Binary and Ternary near-Earth Asteroids detected by radar". NASA/JPL Asteroid Radar Research. Retrieved 2014-03-01. {{cite web}}: External link in |author= (help)

—Trappist the monk (talk) 15:58, 5 June 2021 (UTC)

Should probably do this with most of our parameters for anything that evaluates to having a full URL, that isn't meant for a URL parameter, TBH. Izno (talk) 17:45, 5 June 2021 (UTC)
Agreed, but shouldn't wikilinks be similarly rationalized. There are specific wikilink parameters in place and bifurcating the issue by allowing wikilinks in |last= for example, allows waste and confusion. Seem to remember prior discussion about this. 2603:7000:3842:C100:D26:7E6:7C2F:18B6 (talk) 22:47, 5 June 2021 (UTC)
Wikilinks are allowed in |lastn= because those parameters are aliases of |authorn=.
—Trappist the monk (talk) 23:22, 5 June 2021 (UTC)
Going in circles is great, but this wasn't the question. To rephrase: why are wikilinks allowed in parameter sets that have a corresponding |parameter-link= option? I mean, apart from general inertia. 64.18.9.198 (talk) 00:42, 6 June 2021 (UTC)
Inertia certainly, but why should we prohibit wikilink markup in |authorn=?
—Trappist the monk (talk) 11:48, 6 June 2021 (UTC)
I don't know, perhaps for the same reason as this section's heading? 50.75.222.254 (talk) 14:11, 6 June 2021 (UTC)
I see no reason to limit links whatsoever. Moreover, though you clearly don't mean to suggest the argument for it, we should remove X-link where X is not an authorship parameter. The module handles stripping of brackets today and wikitext links are more wikitext and tool-friendly. That would appear to be title-link, episode-link, and series-link. Izno (talk) 18:48, 6 June 2021 (UTC)
Ok. The sandbox now checks every parameter that isn't a url-holding parameter. url-holding parameters are the parameters associated with these url-holding metaparameters: ArchiveURL, ChapterURL, ConferenceURL, LayURL, MapURL, TranscriptURL, URL and these non-url-holding metaparameters that are allowed to hold urls: Page, Pages, At, QuotePage, QuotePages. Are there any others that should be included in these lists?
—Trappist the monk (talk) 16:28, 6 June 2021 (UTC)

Love the convoluted logic which is eventually applied as unnecessarily complicated code and inscrutable documentation. There are 3 simple, workable options:

  • All parameters allow links away from the citation
  • No parameter allows links away from the citation
  • Designated, function-indicative parameters (such as |something-link|url=) that are link-specific allow links away from the citation

Anything else requires explanation. But, go ahead, do your thing. 24.103.101.218 (talk) 00:20, 7 June 2021 (UTC)

Yes, anything else does require explanation.
We have a good reason to accept links in |last= and analogous authorship parameters: duplicating the text of one parameter into another parameter simply to add a link is simply asinine, which is what we would need to do to accept links for organizations. We also have a good reason to accept |author-link=: we want to provide links for parameters that have been split into |first= and |last=, as we would like to see for all authorship related parameters.
Those design considerations do not extend to any of our other parameters.
The reason linking is (or perhaps, should be) allowed for internal links is that we prefer users to link to internal links if they are going to link to anything. We explicitly want to avoid the actual spam (and/or sea of blue effects) associated with external links in the other parameters (or confusion by users, which is already warned about as "URL in website", regarding the use of |website=).
There is not, and never has been, a requirement for all parameters to do all things, or one thing only, or have any consistency at all. You have pointed out an inconsistency, that's great, but whether we take that to extend to all parameters or to limit it to no parameters is a choice we get to make between those options as well as any others we deign to consider. That is actual design. Presenting false trichotomies does not actually help your case in this regard.
For a particular prior case, we have previously had the explicit discussion to limit |volume= and |issue= to some templates. Not all templates have access to those parameters. I do not see how that was ever the wrong choice, for the templates that do not have access to one or the other of those parameters do not fundamentally need them. Just because we do not treat these templates consistently does that mean we got the choice wrong.
Thank you for indeed helping to identify 3 parameters that do not need a link parameter any more. :^) Izno (talk) 01:11, 7 June 2021 (UTC)
One thing that I have seen is that many editors use {{cite web}} when a different template is appropriate. Are there any cases where an editor actually needs an unsupported parameter for {{cite web}} as opposed to being able to use a more appropriate template? I would rather have other templates enhanced than have enhancements to {{cite web}} that are done solely to support inappropriate use. Shmuel (Seymour J.) Metz Username:Chatul (talk) 11:05, 7 June 2021 (UTC)
Well I know why the module is becoming more inefficient with every update, no need to lay it out.
It is not just the inconsistency of "something-link" being asinine while "something-url" isn't. It is not just the fact that the wikilink may have different format or text than the name(s) inserted in the author parameters which would necessitate further editing of the author fields by the user. Neither is the fact that good software design does not allow the same parameter to be populated with different data types ("text" or "link"). Or the fact that parameters that are classified by data type are more understandable and better utilized by editors. Also it is not because the so-called "internal" links are technically any different (they are all URLs parsable by mediawiki) or conceptually different (they can also be spam, irrelevant, or unverified nonsense just like external links).
Nah... the reason imo for the module's increasing inefficiency is that these things have to be explained. Continuously :-) 68.173.79.202 (talk) 13:23, 7 June 2021 (UTC)

extra text that is not detected in |page(s)=

Latest comment: 2 years ago1 comment1 person in discussion

The template {{p.}} and it's redirect {{pp.}} when used in |page(s)= create extra text conditions that are not detected by the module. I have added pattern to Module:Citation/CS1/Configuration that fixes that:

Title. p. p. 123. {{cite book}}: |page= has extra text (help) ← {{cite book |title=Title |page={{p.|123}}}}
Title. p. p. 123. {{cite book}}: |page= has extra text (help) ← {{cite book/new |title=Title |page={{p.|123}}}}

—Trappist the monk (talk) 13:55, 10 June 2021 (UTC)

Walls-of-text when editing

Latest comment: 2 years ago16 comments8 people in discussion

Quite recently I've started seeing lots of citations with all the spaces around the pipes removed, for example: {{cite web|author=Center for Whale Research|date=June 17, 2018|title=Southern Resident Orca Community Demographics, Composition of Pods, Births and Deaths since 1998|url=https://www.orcanetwork.org/Main/index.php?categories_file=Births%20and%20Deaths|publisher=Orca Network|accessdate=July 31, 2018}} ... This makes it hard to read (and edit) as a wall of text and also causes text wrapping problems. I haven't seen any change promulgated in the guidelines that says to remove the spaces. Could it be a bot doing it? In any case, could we re-emphasize the standard of a space before each pipe and figure out what's driving this change? Abductive (reasoning) 20:46, 9 June 2021 (UTC)

There are scripts that convert to {{A|B=C}}, scripts that convert to {{ A | B = C }}, and everything in between (I have a personal preferred style, but that's not this discussion), and no-one's been willing to have a discussion about standardizing on the point (at least for citations). So I'm not really surprised if you're noticing a trend, but I doubt the trend is anything more than confirmation bias on the point. Izno (talk) 20:50, 9 June 2021 (UTC)
The examples on the Help page that this is the talk page of all show a consistent bias towards a space before each pipe. Could the guilty parties just come clean? Abductive (reasoning) 20:54, 9 June 2021 (UTC)
I think the best way is to have a space before each pipe, no-spaces makes it harder to read, while spaces both before and after pipes and before and after equal (=) signs seems excessive and unnecessary. However, I don't know if this is worth having a potentially massive RfC where it's likely consensus won't be reached. Many will probably also cite WP:CREEP against the very idea of setting a standard. —El Millo (talk) 21:15, 9 June 2021 (UTC)
It doesn't seem like there is a cadre of entrenched users ignoring the longstanding consensus and demanding the wall of text, I think it is a bot or bots doing it. Abductive (reasoning) 21:25, 9 June 2021 (UTC)
(ec) I've found that a space around pipes and after = makes it easier to edit, because then I can double-click the text to change it; without a space, the double-click selects the pipe or = as well. But I don't edit articles just to do that (and sometimes I forget to do it in my own edits). Just pointing out that the space can be useful. Schazjmd (talk) 21:26, 9 June 2021 (UTC)
Are you sure, Schazjmd? Whenever I double-click text next to an equal sign, it only selects the text. —El Millo (talk) 21:34, 9 June 2021 (UTC)
Oh, it's just my setup? I figured it worked that way for everyone. (Now I have to try to figure out what I might have done on my computer to make it behave that way...) Thanks, Facu-el Millo! Schazjmd (talk) 21:38, 9 June 2021 (UTC)
Different browsers on different operating systems differ in how they deal with double click. It also matters whether the text area is plain old HTML or if it is spiced up with Javascript (and the latter can cause variance itself). There may be nothing you can do about it beside try a different browser than your normal one. Izno (talk) 21:43, 9 June 2021 (UTC)
When I'm typing citations by hand, I tend to omit the spaces because that's less typing. When I'm converting from one-parameter-per-line to all-on-one style citations, if I space the pipes and equal signs, the regular expression substitutions I use for this tend to also mess up long parameterized urls (like the ones for Google Books) so the unspaced style is safer. Anyway, for avoiding wall-of-text issues, my feeling is that moving the references to the end of the article by giving them names and using the |refs= parameter of {{reflist}} is much more effective than any variation in how you space the parameters of the reference. —David Eppstein (talk) 21:42, 9 June 2021 (UTC)
Agreed, WP:LDR or WP:SFN does more to deal with walls of citations. Izno (talk) 21:45, 9 June 2021 (UTC)
IMHO, bots that make mass changes to style, absent a strong consensus, are disruptive. This is especially true when somebody takes the time to make his markup easy to edit and a script wipes out his work. I could make a case for automatic prettyprinting, but even that is laden with pitfalls. --Shmuel (Seymour J.) Metz Username:Chatul (talk) 21:49, 9 June 2021 (UTC)
Abductive and others, if you think a bot is applying this style, find an article with citations like this, and go back through its history to find when and how the citation was inserted. Histories are (almost all) publicly visible; there is no reason to speculate. If you find that a bot or script is changing the citation style, address that CITEVAR issue with the bot or script operator. – Jonesey95 (talk) 23:29, 9 June 2021 (UTC)
I will fully admit: I prefer things unspaced because in many cases, it creates smaller wikitext that can fit on one line. Whether I convert anything depends on what the article is already using (I try to keep styles consistent if possible). Sometimes, though, it is a hassle. Long lists of author names split into first and last names can be really awkward, as can particularly long URLs. The worst instance is probably |archive-url=, which at least 90%, I feel, of the time contains the same value as |url= but with stuff added to the beginning. Shortened footnotes and list-defined references are definitely better for cleaning up clutter than spacing things out. (Full disclosure: I use the 2017 wikitext editor on desktop computers, which allows line breaks on hyphens, spaces, and question marks, and probably some other characters. The mobile version, however, seems line break with pipes, too, last I checked. Could implementing this on desktops solve our problems?) -BRAINULATOR9 (TALK) 13:30, 10 June 2021 (UTC)
Perhaps I'm misunderstanding what you're saying, but it doesn't seem like you understand the purpose of |archive-url=. The parameter is used to contain an archived version of the link, so that the content is still accessible if the link is ever broken or the info is ever removed. Wayback Machine, the most commonly used archive, just makes the links so that they contain the full url of the page being archived (https://web.archive.org/web/[archive number]/[original's url]). It's not like it's useless repeated info, and it's not like there's anything we can do about it. —El Millo (talk) 17:30, 10 June 2021 (UTC)
I understand what |archive-url= does and that it's not restricted to the Wayback Machine. I'm just saying it's the most prevalent instance of unfixable line break mishaps. -BRAINULATOR9 (TALK) 19:04, 10 June 2021 (UTC)

Chapter woes

Latest comment: 2 years ago4 comments4 people in discussion

What am I doing wrong here? I thought as long as work was omitted the chapter should work correctly.

Markup Renders as 
{{Cite web |chapter-url=http://www.airvectors.net/avf4u_1.html#m3 |chapter=Corsair in the Pacific War |url=http://www.airvectors.net/avf4u.html |title=Vought F4U Corsair |last=Gobel |first=Greg |date=1 May 2015 |publisher=AirVectors}}

Gobel, Greg (2015-05-01). "Vought F4U Corsair". AirVectors. {{cite web}}: |chapter= ignored (help)

Also when I change chapter to at it tells me chapter-url is ignored, which is not explicitly covered in the error guide. Ibadibam (talk) 16:30, 10 June 2021 (UTC)

Webpages do not have chapters. Use cite book. AManWithNoPlan (talk) 16:48, 10 June 2021 (UTC)
Or, use title= and url= for the individual piece you are citing and work= for the larger collection of web pages it comes from. —David Eppstein (talk) 17:09, 10 June 2021 (UTC)

I think I would much prefer this, as I do not really see this as a book citation (for which 'chapter' might apply); I believe this is also what David is suggesting:

Markup Renders as 
{{Cite web |last=Gobel |first=Greg |date=1 May 2015 |url=http://www.airvectors.net/avf4u_1.html#m3 |title=Corsair In World War II |website=AirVectors |at=Corsair in the Pacific War}}

Gobel, Greg (2015-05-01). "Corsair In World War II". AirVectors. Corsair in the Pacific War.

I have added the specific section callout. This seems like a sufficient citation to me. You do not need to identify all layers between the specific web page and any higher level works. --Izno (talk) 18:49, 10 June 2021 (UTC)

Bad value in website= field

Latest comment: 2 years ago7 comments4 people in discussion

I've noticed a value entered to some cite web uses "TREKNEWS.NET | Your daily dose of Star Trek news and opinion" in an example like: {{Cite web|last=Staff|first=TrekNews net|date=2017-02-10|title=[REVIEW] Deep Space Nine Complete Series DVD Box Set|url=https://treknews.net/2017/02/10/review-star-trek-ds9-complete-series-dvd-box-set/|access-date=2021-02-19|website=TREKNEWS.NET {{!}} Your daily dose of Star Trek news and opinion|language=en-US}}. Should this be flagging any tracking category perhaps? Gonnym (talk) 11:36, 11 June 2021 (UTC)

Which flag that would be? The website field is badly formatted, the only thing there should be www.treknews.net. There could be some error checking to catch extraneous characters before the prefix and after the suffix I suppose. Tracking category submissions must go through an RfC process now as I understand it. 24.103.251.114 (talk) 12:20, 11 June 2021 (UTC)
Websites may be in either their "URL" form (as in 24's comment) or a caps URL form ("TrekNews.net") or their word form ("Trek News"), so looking for spaces would not help. The latter half of the title is a bit spammy but is a valid part of the name, and isn't obviously unuseful in the sense that "Bloomberg, are you a robot" is. This case seems fine. I do recommend doing an insource search and removing the offending half of the name. Izno (talk) 12:26, 11 June 2021 (UTC)
The guidance (and code) may need to be finetuned. In good practice, websites are directory entries distinguishable by the prefix "www". Good practice not being universal practice. Although there is nothing wrong with subtitles (even when these are in effect, marketing messages), the template does not have to accept them. If it makes the code tighter and more efficient, in the sense of allowing for expanded error checking, why not? Subtitles would only be pertinent if index pages needed disambiguation, and that is not a case. 24.103.251.114 (talk) 13:05, 11 June 2021 (UTC)
How do you distinguish a 'subtitle' for a website? Izno (talk) 13:49, 11 June 2021 (UTC)
Anything after the suffix? That is why it was suggested that the work be expected in DNS format exclusively. A conditional formatting parameter could switch the display to hide the DNS artifacts per editor preference. I understand that this involves a lot of work for a module that is constantly scrutinized by snowflakes, so these suggestions are very tentative. 65.88.88.69 (talk) 14:56, 11 June 2021 (UTC)
Right, but 'DNS' format is not required and I do not think it should be required for the field. Izno (talk) 15:35, 11 June 2021 (UTC)

Protected edit request on 11 June 2021

Latest comment: 2 years ago2 comments2 people in discussion

An acknowledgement and inclusion of the TemplateData newly created for Cite Map in its documentation in the same style as Cite Book BMACS1002 (talk) 23:57, 11 June 2021 (UTC)

Template:Cite map/doc is not protected. There is nothing preventing you from adding TemplateData.
—Trappist the monk (talk) 00:21, 12 June 2021 (UTC)

cite document

Latest comment: 2 years ago2 comments2 people in discussion

There is a template {{cite document}} which seems to have always redirected to {{cite journal}}. It's got 7968 transclusion and most of these are coming up with red cs1 errors as the required parameter |journal= makes little sense for documents.

For the page I saw this on A30 road the references ref to off line sources held by the UK national archive, and one user has commented on Template talk:Cite document that it's used for a commencement speech. While changing thee links to {{cite web}} would cure the cs1 warning, this does not seem to be semantically correct, but there no obvious candidate in the cite family. --Salix alba (talk): 03:02, 12 June 2021 (UTC)

There have been previous inquiries and discussions about this. The main issue here is the fact that few documents are published as stand-alone items, and only published sources can be cited. Long documents may be published as reports; there are a couple of templates available. Other published documents may use {{cite book}}, or {{cite web}}. In the particular case, the document can be sourced as a location in an online publication (the website for the UK National Archives). Use {{cite web}}. If a hard copy of the pertinent Archives volume was consulted use {{cite book}}. 64.18.9.201 (talk) 13:11, 12 June 2021 (UTC)

Autolinking

Latest comment: 2 years ago10 comments7 people in discussion

Please autolink the title when |hdl= and |hdl-access= are provided similar to how it works with a supplied |doi=. Please add hdl as an option for |title-link= with |hdl= for cite journal. It would be useful if the combination of |hdl=, |hdl-access=, and |title-link= worked for cite report, techreport, or web too. Thank you. --Whywhenwhohow (talk) 04:30, 8 March 2021 (UTC)

The PMC content is sometimes stale when compared with the journal article and should not be the default when a free doi or free hdl is present. The existence of the paramaters |doi-free= or |hdl-free= should cause the doi or hdl to have priority and be used instead of the pmc for the title link. --Whywhenwhohow (talk) 23:59, 8 March 2021 (UTC)
What is the process to implement these recommendations? --Whywhenwhohow (talk) 05:27, 26 March 2021 (UTC)
For the articles you edit? Add the url you want to link as the |url= parameter. That way the logic for which thing somehow overrides which other thing can be as convoluted as you like and the rest of us don't have to try to understand or remember it. —David Eppstein (talk) 06:14, 26 March 2021 (UTC)
Yes, this would be appropriate. Institutional repositories hosted by academic institutions are by far the most stable and reliable link targets we have in our citations.
On the other hand it's not appropriate to give priority to the DOI over the PMC ID, because PubMed Central is more likely to present relevant updates, such as retraction notices of medical articles, which often go missing on the publishers' websites. Legacy publishers generally lag several years behind PubMed, see for instance Elsevier. Nemo 18:38, 25 April 2021 (UTC)
Dearchived due to ongoing discussion. Nemo 18:54, 27 May 2021 (UTC)
"Ongoing discussion" meaning the topic wasn't edited for a month? That's a curious definition. Izno (talk) 19:20, 27 May 2021 (UTC)
The topic was mentioned here, though I was unaware of this discussion at the time. Certes (talk) 16:51, 28 May 2021 (UTC)
Right now |pmc= overrides |doi-access= free link. Has any thought been put into this order? AManWithNoPlan (talk) 22:13, 24 June 2021 (UTC)
{{cite journal |title=Title |journal=Journal |pmc=12345 |doi=10.1415/sommat |doi-access=free |title-link=doi}}
"Title". Journal. doi:10.1415/sommat. PMC 12345.
—Trappist the monk (talk) 22:33, 24 June 2021 (UTC)

Thesis in italics

Latest comment: 2 years ago8 comments6 people in discussion

The guideline MOS:MINORWORKS recommends quotation marks, not italics, for titles of theses. This contrasts with the behaviour of {{Cite thesis}} wher |title= is italicised. Which is correct?

As for the merits of the distinction major/minor works in this regard: Most PhD dissertations are quite substantial, and often they are later published as books, so italics makes sense. My impression of masters theses is that they are more like extended essays, so it's not clear to me whether they are minor or major. Anyway, there's a conflict between the MOS and the tamplate's behaviour.

I raised the same question at Wikipedia talk:Manual of Style/Titles#Thesis in italics. -- Michael Bednarek (talk) 01:44, 18 June 2021 (UTC)

Generally, works published as stand-alone items are in italics, and items that are parts of published works are quoted. Since the CS1 citation templates are named per (stand-alone) source, this template would only be suitable for theses published as stand-alone items. I would imagine this to be a fairly small number? 74.64.150.19 (talk) 11:56, 18 June 2021 (UTC)
History: From its creation in 2009 until this edit in 2011, |title= rendered upright without quotation marks. After that edit, |title= renders in italic.
—Trappist the monk (talk) 12:45, 18 June 2021 (UTC)
I don't understand 74.64.150.19's response. Every thesis is a stand-alone work, isn't it? // Regarding history: maybe User:Headbomb can provide guidance whether the advice in MOS:MINORWORKS should be removed. -- Michael Bednarek (talk) 13:05, 18 June 2021 (UTC)
I'm not sure why I'm pinged here, or what the question is, but thesis are major works, and their titles should be italicized. I believe this is the current behaviour of the templates. Headbomb {t · c · p · b} 13:31, 18 June 2021 (UTC)
Michael Bednarek, thanks for posting this. I have responded over at the MOS page with some detective work. In short, I believe that the guidance was added to the "minor works" list in error and without discussion in 2019, and that it contradicts both our long-standing practice and some style guides. MOS should be modified, not {{cite thesis}}. – Jonesey95 (talk) 16:04, 18 June 2021 (UTC)
@Michael Bednarek: for the purposes of citations, "stand-alone" would mean works published as themselves, and not as part of a larger work, or of a collection. An article/essay published as a pamphlet is a stand-alone work, indexed as such, and found as a discrete item. Its title should be italicised. The same piece published in a magazine or journal is a location in a stand-alone work, and its title should be in quotation marks, as it is in fact text quoted from the source. 65.88.88.69 (talk) 19:42, 18 June 2021 (UTC)
I've now adjusted MOS:TITLE. -- Michael Bednarek (talk) 01:29, 19 June 2021 (UTC)

Journal volume in Bold

Latest comment: 2 years ago10 comments6 people in discussion

The volume parameter is showing up in bold in the journal citation. It is quite jarring as it stands out among all the other parameters, and I thought it's a bug. The documentation said it can be in bold, but did not say why the bold is required. On going through the archives I found similar concerns (1, 2, 3), and on how to workaround the bold, and requests and proposals to handle or eliminate the bold completely. I accordingly modified Iridium Communications so the bold is avoided.

In Template:Citation Style documentation/volume I added a mention of why the bold is done, from one of the conversations. From the proposals in /Archive 62#Bolding of the volume number, I vote for: 

Proposal 2 vol. 3, pp. 12–56.

so the reader understands what the 3 stands for, plus it is not in bold. - Jay (Talk) 13:40, 20 June 2021 (UTC)

I'm inclined to revert your change to Iridium Communications because that change causes Module:Citation/CS1 to emit a |volume= has extra text error message (which see). I am also inclined to revert your changes to Template:Citation Style documentation/volume unless you can name the international standard that lays out the expected styling for journals. What is the name of this international standard?
—Trappist the monk (talk) 14:02, 20 June 2021 (UTC)
Citation bot already reverted my workaround, and I can take that up at the bot's page. On the international standard, I got that from /Archive 4#Bold/non-bold volume parameter doc issue, or bug, where user Gadget850 said: "Volume values that are wholly digits, wholly uppercase Roman numerals, or less than five characters will appear in bold, as per the international standard that lays out the expected styling for journals. Any non-numeric value of five or more characters will be presumed to follow some other convention and will not appear in bold." - Jay (Talk) 06:35, 21 June 2021 (UTC)
An editor saying something in a general comment on a talk page doesn't necessarily make it true. This obviously isn't article space so not quite WP:V level, but I would agree with Trappist that we shouldn't call something an "international standard" in the documentation unless we can justify that with some reliable source saying so.
On the original question, I've grown quite used to the bold volume numbers, I don't find them particularly jarring, but I do think it's important to justify why we're doing it that way, and to be confident that readers will be able to interpret that layout without hitting the edit button and looking at the template parameters.  — Amakuru (talk) 07:16, 21 June 2021 (UTC)
I'm used to the bold volume numbers as that is common in the scientific literature (e.g. Nature and Science both use bold volume numbers). But while I'd expect the bolding for scientific journals, I find the bolding jarring with books, where I'd expect "Volume 2" rather than "2" for books. I think it would be better if {{cite journal}} and {{cite book}} handled volumes differently. There is the option of using |Volume=((Volume 2)) to suppress the hidden error message but this seems an unnecessary extra step. —  Jts1882 | talk  08:31, 21 June 2021 (UTC)
For Nature and Science that use bold volumes, "there are also plenty that don't any more / never have (e.g. BMJ, Cell, PLOS, BMC)." (by User:Evolution and evolvability). What looks normal on printed pages, may not look so on web pages. Especially on a wikipedia page where nothing but the first mention of the subject is allowed to be in bold. - Jay (Talk) 15:07, 21 June 2021 (UTC)
I just said I was used to seeing the bolding in the scientific literature. I gave Nature and Science as examples as they are well-known and more geared to a general audience. My unscientific survey of journals I read and publish in suggests a majority use bold (e.g. PNAS, J. Physiol, J. Biol. Chem). Cell and Neuron (Cell Press) don't use bold but use italics to provide emphasis to the journal number. The BMC journals were on my bold list, but it looks like they now don't bold the number now, which may or may not be an indication of the modern trend. For journals that show issue numbers in parenthesis, none that I looked at used bold, although Cell Press used them in normal text following an italicised journal number. I don't feel too strongly about bolding the journal number, as many journals don't, but find the emphasis useful. What I don't think is correct is the bolding of book volume numbers or flagging the text "volume" as an error (which result in people deleting volume titles and just leaving the number). In my brief survey, the journals that bold the journal number don't bold the book volume number and use Volume 2 or Vol. 1, although finding examples for this is difficult. —  Jts1882 | talk  16:15, 21 June 2021 (UTC)
I agree it doesn't make it true. I cited the user and his quote to provide context, the best I could get, because in the discussions I'm seeing in the archives, the typical explanation for something being a particular way is "because this was discussed and agreed by the editors on Wikipedia years ago", with no other context. What I gave is a lead, so someone who was part of the discussions can pitch in with the unnamed standard, since the quoted user is now inactive.
A quote from another archive /Archive_8#Add a 'volume-b=' parameter that skips the four-chr test for bolding?, where user J. Johnson (another inactive user) says: "Volume numbers, which are especially significant for serials and journals, are often overlooked on account of being so short, wherefore they are commonly bolded so they are more readily seen in long citations." Now this is a usability explanation that can be given in the doc, and this would suffice for the time-being. It answers the question, why are volumes bolded, but not, Is it the right thing to do? - Jay (Talk) 14:31, 21 June 2021 (UTC)
It is not a good idea to make assumptions based on what one is used to, or by looking at other citation systems. This is a general-purpose encyclopedia geared towards non-experts. There are no prior examples of citation systems addressing such an audience. All existing citation systems are geared to experts, sometimes in very narrow fields. Very rough guidelines is the most such systems can provide. The present citation system must be more than anything, simple, understandable, and consistent. And also coherent, given the expected level of reader expertise (zero). The volume parameter is one of the places where the system fails, but not for the reasoning you outlined, imo. It is inconsistently presented (sometimes bold, sometimes not) and arbitrarily so (why bold if less than X rather than Y characters?)
It would make sense to emphasize the parameter by using bold weight: in cases of multi-part sources the parameter is instrumental in locating the verifying info, and its presentation should attract the reader's attention. But this may be secondary to consistency. Whatever is decided should apply uniformly, wherever this parameter is used in-system. This is easier for both non-expert readers and non-expert editors. Certainly easier than following arcane trade practices per citation template or following whatever foreign citation system suits one's particular preferences.
If memory serves, I believe I first made a similar comment in some Wikipedia page almost 20 years ago :-) Likely I will be repeating this 20 years from now, if I'm still around. Something to do, I guess. 66.65.114.61 (talk) 14:37, 21 June 2021 (UTC)
The most recent discussion on this topic is at Help_talk:Citation_Style_1/Archive_75#Obtuse_template_style; you'll see I started a draft RFC and posted for some feedback there which I took somewhat, but no-one followed up after my last comment there. Happy to hear more, just not sure I'll take more... :^)
As for comments above about standard/not standard, the couple of ISO standards out there seem to favor the written out "vol." without bolding, but I could swear that I had seen at least one ISO citation with bolding/parens along the lines of the couple major journals already mentioned. Izno (talk) 20:26, 22 June 2021 (UTC)

|script-chapter= (and aliases) without |chapter= (or aliases) not recognized in cite encyclopedia

Latest comment: 2 years ago1 comment1 person in discussion
Cite encyclopedia comparison
Wikitext {{cite encyclopedia|encyclopedia=Encyclopedia|script-entry=zh:Entry}}
Live Entry. Encyclopedia.
Sandbox Entry. Encyclopedia.

fixed.

—Trappist the monk (talk) 11:39, 26 June 2021 (UTC)

Old parameter coauthors

Latest comment: 2 years ago2 comments2 people in discussion

The citation templates supported the coauthors parameter before lua modules were introduced. Does anybody here remember how the references with that parameter were treated when en.wiki switched to lua modules? Were they removed from template calls in the articles? (there are very few remaining, see insource:/coauthors=/). I need this for another wiki. Many thanks! Ponor (talk) 01:14, 30 June 2021 (UTC)

They were supported by the Lua modules for a while, and then we deprecated |coauthors= and converted them all to |author1= etc. or |last=/|first= pairs. – Jonesey95 (talk) 03:04, 30 June 2021 (UTC)

DOI and/or URL for cite SSRN to support PlumX/Altmetric?

Latest comment: 2 years ago3 comments3 people in discussion

Anyone here familiar with PlumX/Altmetric and how they pull data from Wikipedia references? Should we add the ability to specify a DOI and/or a URL for {{cite ssrn}}? Wikiscienceguru wrote on my talk page about a change they made using {{cite journal}} with a DOI and a URL instead of using {{cite ssrn}} for a paper from SSRN:

So the important change I made is to include the DOI. If this is not done, metrics tools like PlumX and Altmetric do not find the reference in Wikipedia which prevents people from finding wikipedia articles that reference a given article. While SSRN is technically not a journal, it does have what it calls "eJournals" which include content based on editorial staff selection criteria. The referenced article is in an eJournal. But again, most importantly, the DOI must appear in the reference (not as a link) to be captured by PlumX and Altmetric. References by PlumX and Altmetric steer traffic to wikipedia via those references. SSRN functions as a Journal so perhaps it's best to use that citation style. Somehow, the DOI must appear in the reference as directly visible text, not hidden within a link.

--Whywhenwhohow (talk) 03:46, 7 July 2021 (UTC)

That's nice, but that has 0 bearing on how we make citations. Wikiscienceguru, those platforms should fix their software. We should not use a specific template to make them happy. Izno (talk) 04:12, 7 July 2021 (UTC)
{{cite ssrn}} is kind of a special purpose template. If the issue is that it does not support |doi=, you could use e.g. {{cite web}}, which does support |doi= and |ssrn=. However, according to [3] at least Altmetric also retrieves SSRNs from citations, so adding DOIs should not be necessary in the first place. In general, if their harvesters don't recognize some identifiers in the visible text of a citation, they should be improved to also read the invisible COinS metadata as it is provided by all CS1/CS2 citation templates in Wikipedia (and various other places). Thereby they could reliably retrieve SSRNs, DOIs and many other identifiers via the rft_id key (see also: Module_talk:Citation/CS1/COinS).
--Matthiaspaul (talk) 14:34, 7 July 2021 (UTC)

access-date query

Latest comment: 2 years ago19 comments10 people in discussion

Hi all

If I have a citation with a dead URL, for which an archived version has been added, e.g. through an archive.org link, should the access-date parameter represent the date on which the actual original URL was last verified to be online and accurate, or should it be the date on which the archived version was last retrieved? Cheers  — Amakuru (talk) 08:44, 5 July 2021 (UTC)

In this case I would not use the |access-date= parameter at all, but if you prefer it should be set to the date the archived snapshot was created. --Matthiaspaul (talk) 10:40, 5 July 2021 (UTC)
Well, we already have |archive-date= to cover that, so I'm not sure it would be particularly helpful to use that date. I guess the question is whether the archiving site will ever go down or somehow change the way the source looks... If not, then as you say perhaps omitting it altogether similar to a GBooks link would be best. Personally I've always just used the date I looked at the archive site myself, but I just wondered this mornign if that was really correct.  — Amakuru (talk) 10:45, 5 July 2021 (UTC)
Just for clarification: My above comment addresses the scenario of adding |access-date= at a time when the original site is already dead, and where an |access-date= newer than the |archive-date= implies that the archived contents was still live at that date - something that does not necessarily hold true and that, except for in very rare cases, cannot be determined retroactively any more.
Like Trappist below I do not suggest to remove an already existing |access-date= parameter, because when that parameter was applied at a time when the original site was still alive the date provides valuable information for verification purposes and to possibly find the most suitable replacement link.
--Matthiaspaul (talk) 15:54, 5 July 2021 (UTC)
|access-date= applies to |url=. When |url= has died, do not delete or modify |access-date= unless you replace |url= with a url that links to the same source (because that source revised how they structure their online presence). We hope that the date in |access-date= reflects the date that a human editor confirmed that the source addressed by |url= supported our article (alas, there are tools out there that automatically add today's date to |access-date= when they cleanup bare url references today). We need to know the correct |access-date= so that when |url= goes 404, we can find an archived snapshot from on or near that date.
—Trappist the monk (talk) 11:09, 5 July 2021 (UTC)
First, if I may suggest, don't think as an editor, and think as the consumer (the reader). What serves the reader is a live url and an indication of the date that url was accessed. When a previously live link has died for whatever reason, and there is an archive, the live url that verifies the source is the archived one. If you can access that, you should say it, with the date you did so. The |url-status= will auto-format the current live link, but the editor must update the parameter |access-date= by hand. The parameter that indicates the snapshot date is a different parameter |archive-date= and has a different purpose. 64.18.9.201 (talk) 12:17, 5 July 2021 (UTC)
Yes, I think this matches what I would expect as a reader too. Note the way such a citation renders:
  • "Wikipedia, the free encyclopedia". Wikimedia Foundation, Inc. Archived from the original on 2021-02-06. Retrieved 2021-07-05.
As a reader, I would expect that "Retrieved 5 July 2021" to refer to the actual link of the source as I'm verifying it, which in this case is the archived copy. Saying the "access-date" refers to the "url" may make sense from the point of view of this template, but IMHO what's important is the rendered text and what it implies. Cheers  — Amakuru (talk) 12:37, 5 July 2021 (UTC)
Hm, I don't think it is a good idea to retroactively add an |access-date= to specify the date an archived snapshot was accessed once the actual |url= has died. The |archive-date= already implies that the original site was accessed (by the archiver) on that date. At most, |access-date= could be set to the same date as |archive-date=.
An |access-date= newer than an |archive-date= implies that the actual site was still alive at the given moment in time and its contents still supported the statement. Except for in very rare cases, we do not know if this holds true or not, therefore we should not make such statements. It would be possible that the contents of the site changed in unsuitable ways no longer supporting the statement prior to going dead. If, in this case, |access-date= would be given as the date when the (older) archive was accessed, it would lead to the assumption that the original site supported the statement up until it died and not only up until the archived snapshot was taken. To distinguish between these cases we would need to known when a site went dead and see if the |access-date= is older or newer than this date, but we do not normally have this information. --Matthiaspaul (talk) 15:54, 5 July 2021 (UTC)
No. Nobody is adding an access date retroactively. The opposite is happening: the date the source is accessed is added concurrently. It does not matter at all to the reader if that source was an original or an archive, although it is good practice to indicate so, as is currently happening. It is wrong to leave a stale date as access date. It is a false statement because the pertinent new live link is not accessed on that date. The archive date is indicating the snapshot, and is important when the original changes, since it is part of a revision history. By definition, the snapshot used verifies the wikitext exactly like the contemporary original. So if the archive is going to be used instead, the date it is accessed should be indicated. 68.173.76.118 (talk) 20:15, 5 July 2021 (UTC)
My preference is to remove the access-date when I discover a url to be dead and replace it with an archived url, because the version of the source at the old access-date is no longer verifiable and we need to go by the archived version instead. There is no point in also adding an access-date because archived versions do not change, so the date that I found it in the archive is not useful information to readers. Adding an archive to a still-live url is not something I usually do, but if you are doing that, then the access-date can remain as a record of when the content at the live url was verified. —David Eppstein (talk) 20:34, 5 July 2021 (UTC)
Not all archives are stable. Services such as WebCite may remove archived material especially if there are multiple archives of the same source. I have experience of Wayback Machine archive URLs that have changed, affecting the entire snapshot chain. I agree that known stable/well-managed archives that become the live URL would not need an access date, and therefore the parameter could be removed in such cases. In the other cases, the live URL (whether original or archive) should have a corresponding contemporaneous access-date. 68.173.76.118 (talk) 21:15, 5 July 2021 (UTC)
The point is that if you link to a version with an archive-date, the date of that version will never change. It is stable in the sense of being a fixed snapshot, regardless of whether it might someday become a deadlink. So having an access-date to tell you which version of a changing web page was used is pointless for an archived page. —David Eppstein (talk) 21:35, 5 July 2021 (UTC)
There's a misunderstanding, I believe. The archive-date identifies the snapshot, as you state. The access-date identifies the date that snapshot was accessed as the then-live URL. In the case of non-stable archives, I think that link info is as pertinent as any other link info. Some time ago I inserted a citation whose source (the live URL) was a newspaper archive, curated by the newspaper itself. So this is an authoritative archive. Recently, following a change in publishers, the entire archive was repositioned as a subdomain of the publisher's subscription services. I became aware of the change months later, and edited the citation. I believe that in the meantime the info regarding the link's known accessible date added value for readers wishing to find the source. It could be a starting point to discover where the source went. With rapid developments in the publishing industry, this may not be an unusual incident. 74.85.112.198 (talk) 23:47, 5 July 2021 (UTC)
I do not see the relevance of telling readers "the date that snapshot was accessed", as you put it. It provides no useful information to readers. —David Eppstein (talk) 01:10, 6 July 2021 (UTC)
|access-date= is for |url=, not for |archive-url=. Period. Izno (talk) 01:27, 6 July 2021 (UTC)
You are only partially correct. The access date refers to the live URL, neither the "original" nor the "archived" one. Any URL may need an access date if there is a good possibility it will not be stable, regardless of provenance. If the documentation says otherwise, it should be fixed to line up with common sense, so that editors don't come here with such questions (not the editor's fault). And verifying readers won't have to be entangled with yet another wrong/false date statement. 65.88.88.200 (talk) 20:31, 7 July 2021 (UTC)
No, it is specifically for |url=. Your opinion is simply wrong. Izno (talk) 00:55, 8 July 2021 (UTC)
"Simply wrong" according to whom? These templates exist first and foremost to make it easy for editors to produce reader-friendly citations in a standard format. And as such, as I said above, the crucial point is that what the |access-date= parameter produces is a snippet of text saying "Retrieved 8 July 2021". The question we need to ask ourselves is therefore not "does that date refer to the URL parameter", but rather "what will the reader interpret that date to mean"? In that regard I think the IP is right, the reader will logically assume that it refers to the primary URL associated with the citation, which in the Case of a dead-link is the archived version. If I'm wrong about that interpretation then say, but please don't argue it on the basis of what the parameter was "intended to mean", because that is (a) not what matters to our readers, and (b) not documented in any case so still subject to opinions. It may or may not be best to remove the date altogether at the time of switching to an archived version, but I don't think we should pretend it still refers to when the original URL was accessed.  — Amakuru (talk) 14:00, 8 July 2021 (UTC)

As stated, Izno is partially correct, in a very narrow technical sense regarding module argument dependencies. That is not relevant to editors or readers. I suspect what they want to see is rational real-world equivalents without the low-level mumbo-jumbo.

Technical-mumbo-jumbo example 1 (|url-status=live)
{{cite web|title=Title|website=Website|url=http://original_url.com|archive-url=http://archive_url.com|archive-date=2020-01-11|access-date=2021-01-11|url-status=live}}
renders
"Title". Website. Archived from the original on 2020-01-11. Retrieved 2021-01-11.
with html exposed
'"`UNIQ--templatestyles-00000054-QINU`"'<cite class="citation web cs1">[http://original_url.com "Title"]. ''Website''. [http://archive_url.com Archived] from the original on 2020-01-11<span class="reference-accessdate">. Retrieved <span class="nowrap">2021-01-11</span></span>.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=unknown&rft.jtitle=Website&rft.atitle=Title&rft_id=http%3A%2F%2Foriginal_url.com&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+77" class="Z3988"></span>
Notice that the "live" title URL in rendered html is the original URL
Technical-mumbo-jumbo example 2 (|url-status=dead - default)
{{cite web|title=Title|website=Website|url=http://original_url.com|archive-url=http://archive_url.com|archive-date=2020-01-11|access-date=2021-01-11}}
renders
"Title". Website. Archived from the original on 2020-01-11. Retrieved 2021-01-11.
with html exposed
'"`UNIQ--templatestyles-00000058-QINU`"'<cite class="citation web cs1">[http://archive_url.com "Title"]. ''Website''. Archived from [http://original_url.com the original] on 2020-01-11<span class="reference-accessdate">. Retrieved <span class="nowrap">2021-01-11</span></span>.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=unknown&rft.jtitle=Website&rft.atitle=Title&rft_id=http%3A%2F%2Foriginal_url.com&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+77" class="Z3988"></span>
Notice that the "live" title URL in rendered html is the archived URL. The access date of the live link is either superfluous (if a stable archive) or wrong (it refers to obsolete access of now-dead link). The documentation compounds the error. The low-level coding produces it, by generically tying |access-date= to |url= without any contingencies.

65.88.88.76 (talk) 19:01, 8 July 2021 (UTC)

Bogus names

Latest comment: 2 years ago4 comments3 people in discussion

Following up on Help_talk:Citation_Style_1/Archive_76#junk_author_names where we added a facility to detect bogus names in citations, I saw that Trappist fixed the bogus name "Verfasser" in some 30 citations recently. Even though "Verfasser" is a German word (meaning author/editor) I consider the number high enough to no longer see this as an unsystematic error requiring manual detection and fixing. I have therefore added "Verfasser" to the list of names the template checks for so that it cannot be added to citations any more without generating an error:

Verfasser, Troumbis, Andreas Y. Declining Google Trends of public interest in biodiversity: semantics, statistics or traceability of changing priorities?. OCLC 1188566404. {{cite book}}: |last= has generic name (help)CS1 maint: multiple names: authors list (link)
Troumbis, Andreas Y. Declining Google Trends of public interest in biodiversity: semantics, statistics or traceability of changing priorities?. OCLC 1188566404.

--Matthiaspaul (talk) 11:54, 11 July 2021 (UTC)

@Matthiaspaul: I have a bot task for this - see BattyBot's contributions with an edit summary of "Removed/fixed incorrect author parameter(s)". I have more patterns to share if you're interested. Is there a maintenance category associated with this error? GoingBatty (talk) 18:09, 11 July 2021 (UTC)
Articles with names that satisfy the generic-name test (name_is_generic()) will be categorized in Category:CS1 errors: generic name. There are four sort-of-related maintenance categories: Category:CS1 maint: numeric names: authors list, Category:CS1 maint: numeric names: editors list, Category:CS1 maint: extra text: authors list, and Category:CS1 maint: extra text: editors list.
—Trappist the monk (talk) 18:53, 11 July 2021 (UTC)
Sure, if you know more such patterns, they can be considered for inclusion as well. --Matthiaspaul (talk) 20:48, 14 July 2021 (UTC)

The parent page

Latest comment: 2 years ago1 comment1 person in discussion

1. The volume parameter is not correctly explained. The text should be amended to account for the current schizophrenic presentation.

2. In External links/Online sources it is stated that reviews of the work should not be linked. ???? Practically any art/literature related article is suspect if that is the case?

3. The parameter subject is not explained/described anywhere.

66.108.237.246 (talk) 13:48, 14 July 2021 (UTC)

Proposal: default to display-authors=6

Latest comment: 2 years ago7 comments5 people in discussion

Edits that add references with long lists of authors are quite common, leading to references with very long lists of author names. For journals and books, it seems to be common practice to limit this list to 6, 4, or 3 authors. Likewise, display-editors=3 is quite common. So instead of always having to do this kind of maintenance manually every time, I'd like to propose that the citation templates default to display-authors=6 and maybe display-editors=3, then Wikipedians only have to set these parameters when necessary. --Fernando Trebien (talk) 17:11, 19 June 2021 (UTC)

I believe that this limit was in place for a long time, at first for technical reasons IIRC, but consensus here was that the artificial limit should be removed and left up to editors. If you dig a bit through this page's archives, you can probably find relevant discussions. (Edited to add: here is a discussion from 2014 talking about the old functionality.) – Jonesey95 (talk) 17:20, 19 June 2021 (UTC)
Yes, as Jonesey notes, the count that you find regarding 6 particularly was first a requirement of the templates before Lua, which could not process many more authors than that. This requirement made its way into the tools of the time that were used (e.g. Refill and others).
9 is the other number you will see.
I am not a fan of adding a limit here. Individual page authors can sort out how many authors they want. Izno (talk) 17:44, 19 June 2021 (UTC)
@Jonesey95: @Izno: Just for clarity, I'm not proposing a hard limit, just a default value. What happens is that many authors are careless about conciseness in citations. So an attentive author could still override the proposed default by setting display-authors=0 or any other value they see fit. I also believe that many experienced authors would find these defaults good enough in most cases, so they wouldn't feel they have to set them differently, which saves work. --Fernando Trebien (talk) 18:40, 19 June 2021 (UTC)
If you set a limit, then in practice it will become a hard limit in most cases. If you think that the number needs limiting in some particular article, then why not set it in that particular article, rather than pushing your preference to all articles where the editors have not already expressed a preference, and forcing all editors of articles with many-author references to come to consensus on how many is appropriate for that article? It's perhaps worth mentioning in relation to this that lately within academia I've seen a push for avoiding "et al" abbreviation of authors, especially in fields where authors are traditionally alphabetical (see for example the STOC 2021 call for papers), as it can be unfair to alphabetically-disadvantaged researchers to never have their names mentioned. —David Eppstein (talk) 18:57, 19 June 2021 (UTC)
Makes sense. There should be an easier way to handle this, perhaps adding a parameter like alpha=y to indicate that the citation system is alphabetic, which would set display-authors=0 by default. So, of course, we would need a crawler to look for citations of articles from specific journals that adopt this practice to add alpha=y to them. In any case, I've seen citations containing more than 50 authors, it seems problematic to simply allow them to be so extensive from the start. --Fernando Trebien (talk) 14:00, 20 June 2021 (UTC)
I consider this to be searching for a solution to a problem that does not exist. The majority of sources do not include many contributors, and in the few cases where dozens or even hundreds of authors could actually become problematic (per WP:NOTPAPER I don't think it does unless there would be many such references on a single page) the number of authors to be displayed can be controlled by the |display-authors= parameter. The simple solution you are looking for is to not implement any limit and choose a suitable |display-authors= limit (only) where it is actually necessary.
Any static default hardcoded into the template would be arbitrary and may give unfair advantage to some contributors (which we, as an encyclopedia, should all treat the same) or even violate our policy on neutrality (WP:NPOV). Different publishing houses have different strategies to list authors; some do not sort them at all, some sort them by relevance to the work, by their amount of contribution, by chronology of their contributions, by alphabet, by affiliation, by their reputation, by their function, by their age or by other criteria, and within each group, the entries might be listed in ascending or decreasing order - only the contributors and the publisher know. Any static default limit would be off in most of the cases, therefore we should not even try and introduce any such technically unnecessary limits to citation templates.
--Matthiaspaul (talk) 11:30, 11 July 2021 (UTC)

edited and translated

Latest comment: 2 years ago13 comments5 people in discussion

There are fields for editor and for translator, but these are often the same person and it looks awkward showing them in two different fields. Is there a way of showing " Smith, Joe, ed. and trans."? Dudley Miles (talk) 18:24, 26 June 2021 (UTC)

I suspect that there is little need to duplicate a name in the case that you have mentioned. Remember, the purpose of a citation is to help readers locate the source that you consulted when writing the en.wiki article. In cs1|2 templates, you can probably just write |editor-last=Smith |editor-first=Joe and that will be sufficient. There are cases, I just did one, where an author is also an editor so for that I wrote:
{{cite book |first=Kevin J. |last=Cathcart |chapter=The Curses in Old Aramaic Inscriptions |title=Targumic and Cognate Studies: Essays in Honour of Martin McNamara |editor=Cathcart |editor2=Michael Maher |year=1996}}
Cathcart, Kevin J. (1996). "The Curses in Old Aramaic Inscriptions". In Cathcart; Michael Maher (eds.). Targumic and Cognate Studies: Essays in Honour of Martin McNamara.
In this case it is important to state the chapter author and to name the editors of the edited collection. If you believe that it is important to separately name the translator then |translator=Smith should suffice (assuming that there is only one 'Smith' in the citation).
—Trappist the monk (talk) 18:56, 26 June 2021 (UTC)
I am thinking of a different case, an edition of a medieval work in Latin. Some editions are just the work in Latin, others also have a translation, and it would be very helpful for readers to know whether the edition includes a translation. I have cited *Greenaway, Diana, ed. (1996). Henry, Archdeacon of Huntingdon, Historia Anglorum The History of the English People. Oxford, UK: Clarendon Press. ISBN 978-0-19-822224-8.
I did not add the trans field as I thought it would look odd, but I think a field for 'ed and trans' would give the reader very useful additional information. Dudley Miles (talk) 20:23, 26 June 2021 (UTC)
I would use the language parameter, inserting both languages either by code or literal. And I would also use the translator parameter per Trappist. The parameter you suggest is probably too specialized to be considered.
{{cite book|title=Title|trans-title=Translated title|editor=Editor|translator=Editor|language=latin, en}}
renders
Editor (ed.). Title [Translated title] (in Latin and English). Translated by Editor. {{cite book}}: |editor= has generic name (help)
98.0.246.242 (talk) 20:38, 26 June 2021 (UTC)
Thanks for your help. I have added "language=latin, en". It looks a bit odd to me but at least it conveys the information. I still think the standard method used in academic citation of showing "ed. and trans." is better. It is very common, not specialized. Dudley Miles (talk) 20:58, 26 June 2021 (UTC)
Common, but complicates the citation module somewhat painfully, especially if there are multiple editors/translators who are not both of the two. Izno (talk) 21:10, 26 June 2021 (UTC)
There is no simple solution with multiple editors/translators, but the addition of fields editortrans-first and editortrans-last would cover most eventualities without causing complications. Dudley Miles (talk) 21:26, 26 June 2021 (UTC)
And still adds complexity, contrary to your suggestion. The simple solution as suggested above works today at some cost of repetition. I would not support a change here. Izno (talk) 21:58, 26 June 2021 (UTC)
So are you proposing *Greenaway, Diana, ed. (1996). Henry, Archdeacon of Huntingdon, Historia Anglorum The History of the English People. Translated by Greenaway, Diana. Oxford, UK: Clarendon Press. ISBN 978-0-19-822224-8.? This seems absurdly clumsy compared with a simple trans and ed field. Dudley Miles (talk) 22:34, 26 June 2021 (UTC)
/shrug. Circles at that point. Izno (talk) 22:54, 26 June 2021 (UTC)
I too think dedicated parameters for editors who are also translators would be overkill and open a can of worms: What about contributors who are authors and translators rather than editors and translators? What about those who are authors and editors? Or authors, editors and translators combined? Not to mention that there are more roles than authors, editors and translators alone. We obviously can't have dedicated parameters for all these combinations. This would complicate the user-interface too much. If anything, this would have to be something that the template would have to figure out by itself based on the usage of the existing parameters.
What I can envision for somewhen in the distant future is added support for some symbolic arguments which would allow someone to refer to another already given name in order to not have to repeat that name again (in order to reduce the risk for typos and also to define relations). At a yet later stage the template could then internally group the roles for display purposes. This could look like
|editor-first1=First1 |editor-last1=Last1 |editor-first2=First2 |editor-last2=Last2 |translator1=editor1
But in the current implementation this would add significant overhead, and there are more important things to be added first. Therefore, I would suggest to just add the names according to their roles using the existing parameters regardless of the mild clumsiness and repetition it causes.
--Matthiaspaul (talk) 16:56, 4 July 2021 (UTC)
Isn't Henry of Huntingdon the author so shouldn't the citation read:
{{cite book |author=Henry of Huntingdon |editor-first=Diana |editor-last=Greenaway |translator=Greenaway |title=Historia Anglorum: The History of the English People |publisher=Clarendon Press |location=Oxford, UK |year=1996 |isbn=978-0-19-822224-8}}
Henry of Huntingdon (1996). Greenaway, Diana (ed.). Historia Anglorum: The History of the English People. Translated by Greenaway. Oxford, UK: Clarendon Press. ISBN 978-0-19-822224-8.
Probably should have |orig-date=...
—Trappist the monk (talk) 22:51, 26 June 2021 (UTC)
Regarding commonality, I doubt that the combination editor/translator is a good example. Out of the entire universe of published works, relatively few list an editor. Fewer may list both an editor and a translator. I believe a substantially smaller subset of the last category would have the same person as editor and translator. That I think applies also in the much smaller universe of academic works. There is also the issue of utility. What is the marginal advantage that extra parameters add in order to find the cited source? If a work has an editor, it is likely that it has been classified (in main index or subindex) by editor, or also by editor. I can see how adding the additional info (+editor) can speed up discovery. If the work has been edited by different editors in different editions, then editor is necessary. I don't see equal utility by adding a translator, because usually bibliographic/reference databases rarely provide translator index results, even for translated works (unless perhaps one digs deep into the reference record). The marginal advantage the translator parameter adds in finding the source is more apparent when a certain work has different translators in different editions with the same editor. If a different edition has different editor (or editor/translator) see the comments on editors in this post. In any case, I always provide the translator, in the outside case there exist editions with different translators. 98.0.246.242 (talk) 00:32, 27 June 2021 (UTC)

Auto-generated URL question

Latest comment: 2 years ago6 comments4 people in discussion

{{cite journal}} will auto-generate a URL in the |url= field under some conditions eg. when |doi-access=free and |url= is otherwise empty. My question is, do other templates auto-generate |url=? The conditions are not important, only knowledge of which templates are capable of auto-generating URLs in the |url= field (for whatever reason). Is it possible {{cite magazine}} can auto-generate a URL? Or any of the other CS1|2 templates?-- GreenC 16:01, 15 July 2021 (UTC)

No. Only {{cite journal}} supports this because the identifiers that are the source for the url (currently |pmc= and |doi=) typically apply to journal articles. It has been suggested that |doi= with |doi-access=free might be applied to chapters of books or entries in encyclopedia. So far as I know, there has been no effort undertaken to accomplish this or to even determine if we should support |chapter= / |entry= autolinking from |doi=. I think that there has also been a suggestion to autolink |title= in {{cite book}} from |hdl= but again, just the suggestion.
—Trappist the monk (talk) 16:12, 15 July 2021 (UTC)
Ok, thanks. -- GreenC 16:26, 15 July 2021 (UTC)
There have been multiple requests to extend support for auto-linking beyond |pmc= and |doi= - I remember specific requests for |hdl=, |jstor=, |pmid= and |s2cid= as well as requests to support auto-linking for all identifiers. In addition to this, there have been requests to allow auto-linking in all CS1/CS2 templates instead of in {{cite journal}} only.
While I was not a fan of auto-linking in general, I can accept it for as long as there is a way to override or disable the automatic selection (as is meanwhile implemented through |title-link=none/pmc/doi/link). I would also support adding this feature to all citation templates and to extend support to all identifiers under one restriction:
For new identifiers, we should not support automatic selection because it would be impossible to come up with a reasonable list of priorities for automatic selection when more than a few identifiers are involved. However, if the feature requires manual selection via |title-link=identifier it cannot cause harm. Eliminating exceptions and being able to use more generic table-driven code rather than hardcoded special cases will help to simplify the code and documentation, and therefore will make the templates easier to use and maintain.
Regarding autolinking support for chapters, this was requested several times as well. In fact, I even started implementing it in the sandbox in 2020 by adding |chapter-doi= and |title-doi= parameters as more specific aliases to |doi=, but this was removed again. --Matthiaspaul (talk) 20:54, 15 July 2021 (UTC)
All free versions of record identifiers, not all identifiers. PMID, for instance, will never link to a version of record. arxiv is likewise, not a version of record (although it could certainly autolink in {{cite arxiv}}). Headbomb {t · c · p · b} 21:17, 15 July 2021 (UTC)
Regarding free, this should probably use the same mechanism as with |doi= and |doi-access=free (see Help:Citation_Style_1#Access_indicator_for_named_identifiers).
Regarding version of record vs. arxiv, this could be controlled by a flag in the identifier table, but supporting an identifier in specific templates only could complicate things again rather than simplify them. For as long as only manually selected auto-linking would be implemented for the other identifiers (as suggested by me above), the auto-linking would always be the result of an editor's conscious decision, so perhaps the extra complexity to prevent certain combinations would not be needed (those, which do not make much sense would probably not be selected in the first place, and if so occasionally, they can be easily corrected).
--Matthiaspaul (talk) 10:45, 16 July 2021 (UTC)

Publisher of a website

Latest comment: 2 years ago7 comments6 people in discussion

Cite web says "The publisher is the company, organization or other legal entity that publishes the work being cited"

When a page is cited from the MTV website, sometimes I see |publisher=MTV. Viacom or |work=MTV|publisher=Viacom

Are either/both of these variations acceptable or is there a more preferred way to cite this? Kaltenmeyer (talk) 22:32, 15 July 2021 (UTC)

|title= is the name of the page or article that you are citing; |work=MTV or |website=MTV is the name of the enclosing work (the website, or for a journal article |journal= or for a newspaper article |newspaper= – they are essentiall synonymous); |publisher=<publisher's name> is the name of the business entity that published the work and so the article. In general, |publisher= isn't needed in {{cite web}} for the same reason that |publisher= isn't usually needed for {{cite journal}} and {{cite news}} – the business entities behind the journal / newspaper / website are bought and sold so the publisher information doesn't really help the reader locate a copy of the source. Of course there are those who disagree with me ... some of them vehemently ...
—Trappist the monk (talk) 23:03, 15 July 2021 (UTC)
Unless there's something surprising or special about the publisher, I usually leave it out of {{cite web}} citations. That Viacom owns MTV is, IMO, widely known and not surprising. If the site has some more arcane or technical name, like Our Friend the Butterfly, and the publisher is the International Union for Promoting Fluttering Insects, I would include both, as it might be relevant to weighing the ref's worth. I believe I have also done |website=National Weather Service |publisher=National Oceanic and Atmospheric Administration as well. — JohnFromPinckney (talk / edits) 23:05, 15 July 2021 (UTC)
There are 2 reasons, somewhat esoteric, I would include the publisher: if there are works with the same name but with different publishers; and as a location of last resort. If the source cannot be found anywhere, it is possible that the publisher, or the then-publisher may be able to provide a copy. 64.18.9.208 (talk) 11:30, 16 July 2021 (UTC)
If anything, what gets to me is that CS1 italicizes website names regardless of whether or not it's appropriate. This means I end up seeing things like MTV or CNN in citations when I have never seen MTV or CNN italicized in general. Whether to mention that MTV is owned by Viacom (or I guess ViacomCBS now)... I don't know. MTV's been with Viacom for over 35 years – not only the majority of its total lifespan but also its entire Internet lifespan – so ownership is stable, and I guess clearing things up for those who don't know might be desirable (WP:DOCITEBLUE, WP:POPE, comic on today's lucky 10,000), but most websites need little more than a URL to help you find it, technically speaking. -BRAINULATOR9 (TALK) 18:00, 16 July 2021 (UTC)
See MOS:ITALICWEBCITE, more specifically the footnote. —El Millo (talk) 18:04, 16 July 2021 (UTC)
Thanks for that; it helps to know that this was settled in an RfC. -BRAINULATOR9 (TALK) 19:31, 16 July 2021 (UTC)

Invalid Cite web aliases in TemplateData

Latest comment: 2 years ago6 comments3 people in discussion
For a list of depreciated Cite web parameters, see Cite web § Deprecated.

I have attempted to edit the TemplateData shown for the {{Cite web}}. In the previous iteration, depreciated aliases for the various editorn-link parameters were listed. These invalid aliases were: editornlink and editorlinkn. I am trying to remove the nonexistent aliases from the TemplateData, but Wikipedia won't let me save my changes, citing JSON errors. — CJDOS, Sheridan, OR (talk) 19:05, 20 July 2021 (UTC) (edited 19:11, 20 July 2021 (UTC))

I have attempted to resolve the JSON syntax errors per mediawikiwiki:Help:TemplateData#Syntax error in JSON / Bad JSON format, believing that I had orphaned commas in my edit (which was true), but it still won't let me save changes due to other unidentified JSON syntax error present. — CJDOS, Sheridan, OR (talk) 19:30, 20 July 2021 (UTC)

JSON is fragile and the error reporting is laughable so it is probably best to use Manage TemplateData button at the top of the page when viewed using the wikitext editor using the section [edit] link (the button is directly under the main page header).
—Trappist the monk (talk) 19:40, 20 July 2021 (UTC)
Thank you. I will try that later, but I'm taking a break for now. If I'm not mistaken, I believe true is supposed to be encased in quotation marks, but that hasn't cleared the JSON syntax error messages. — CJDOS, Sheridan, OR (talk) 19:58, 20 July 2021 (UTC)
The Boolean constants true and false should not be quoted - if they are, they get casted to string type and may not test correctly. --Redrose64 🌹 (talk) 20:07, 20 July 2021 (UTC)
  Done: I have performed the editorn-link edit in the manner suggested. Thank you. — CJDOS, Sheridan, OR (talk) 20:14, 20 July 2021 (UTC)
August 25, 2023
help, talk, citation, style, archive, this, archive, past, discussions, edit, contents, this, page, wish, start, discussion, revive, please, current, talk, page, archive, archive, archive, archive, archive, archive, archive, 80contents, status, usurped, ssrn, . This is an archive of past discussions Do not edit the contents of this page If you wish to start a new discussion or revive an old one please do so on the current talk page Archive 70 Archive 75 Archive 76 Archive 77 Archive 78 Archive 79 Archive 80Contents 1 url status usurped 2 ssrn 3 Protected edit request on 16 April 2021 4 CS1 module suite update date TBD April 2021 4 1 arxiv class 4 2 Anyone want to update the list and support this update 4 3 Tracked parameter code partially removed 5 Preprint template TemplateData showing multiple not valid parameter errors 6 New unsupported parameter errors after Whitelist update 7 Identifying paper with cite conference 8 Template Cite sign 9 edtf date formats as cs1 2 date parameter values 2 10 Cite serial 11 How to markup reports done under contract to government agencies 12 lay url and laysummary 13 cite newspaper 14 Suffixes 15 Having a special value for url status when a page is geo restricted 16 Cite lecture 17 Script series 18 Whitelist Blacklist 19 Examples for Template Cite report 20 Issue number being ignored 21 url in name parameters 22 extra text that is not detected in page s 23 Walls of text when editing 24 Chapter woes 25 Bad value in website field 26 Protected edit request on 11 June 2021 27 cite document 28 Autolinking 29 Thesis in italics 30 Journal volume in Bold 31 script chapter and aliases without chapter or aliases not recognized in cite encyclopedia 32 Old parameter coauthors 33 DOI and or URL for cite SSRN to support PlumX Altmetric 34 access date query 35 Bogus names 36 The parent page 37 Proposal default to display authors 6 38 edited and translated 39 Auto generated URL question 40 Publisher of a website 41 Invalid Cite web aliases in TemplateData 42 doi 10 119 1 foobar should throw an error 43 Date validation error 44 ref duplicates default detector flaw 45 Visual Editor claims that usurped is not expected in the url status field 46 Identifier specific template EBSCOhost 47 summary messaging in the preview warning headerurl status usurped Latest comment 2 years ago 8 comments 5 people in discussionAt Clanwilliam County Limerick I set several Cite web as url status usurped however the original links seem to be remaining in place which is not what the documentation implies I would not expect this but admit I may have made a spelling mistake or something In this case it is not too serious in other cases it could be an inappropriate website Thankyou Djm leighpark talk 21 04 15 May 2021 UTC The documentation is here It says in part When the original URL has been usurped for the purposes of spam advertising or is otherwise unsuitable setting url status unfit or url status usurped suppresses display of the original URL but url and archive url are still required dd url status is meaningless without archive url Where you set url status usurped those templates do not have archive url so nothing happens Trappist the monk talk 21 34 15 May 2021 UTC I have tweaked the Module Citation CS1 sandbox so that it adds a maintenance category when url status is set but archive url is not set There were many upon many url status lt var style padding right 1px something var gt without archive url that Monkbot task 18 cleaned up That bot task is now suspended so we must seek another way of cleaning up this sort of problem cite book new title Title url status live Title a href Template Cite book html title Template Cite book cite book a CS1 maint url status link Further we might enhance this a bit so that url status dead when archive url has a value is also included in the maint cat this is analogous to Category CS1 maint ref duplicates default Once the maintenance cat has been cleared we should convert it to a normal error because to be meaningful url status requires archive url Trappist the monk talk 22 05 15 May 2021 UTC Maybe the documentation could better clarify that a usurped url invalidates the link if there is no legitimate archive link In such cases the link should be removed If the citation depends on the link for verification likely where cite web is concerned the citation itself is no longer valid and should be removed 98 0 246 242 talk 22 29 15 May 2021 UTC I disagree that the citation is invalid and should be removed It is the link that has become invalid the citation itself was likely in good faith but verificability was lost Citation removal can be tricky as it can sometimes but not always be recovered As it is we leave it mostly in the hands of the bot s to hope successful archives are created and they dont mark if this has not happened And in the end manual dead usurped link recovery can sometimes be more successful than the tool I m not actually sure what IAbot would make of the example given here Djm leighpark talk 01 00 16 May 2021 UTC Citations must verify the wikitext in real time not sometime in the past or future If they don t they should be removed It is worse to include a misleading because unverifiable citation than having no citation at all as it gives unverified claims the appearance of truthfulness This is not something to leave to any bot You as editor must support what you edit This is policy and non negotiable At the very least mark the citation as needing work and quickly meaning in hours not days either correct it or remove it 68 173 79 202 talk 13 06 16 May 2021 UTC Replaced maybe not necessarily removed Please read WP DEADREF Known usurped dead linked sources should as you say be marked or upgraded I disagree with your strict statement that the citation itself is no longer valid and should be removed JohnFromPinckney talk 16 42 16 May 2021 UTC The last point at WP DEADREF refers to removal when verification depends on the link only without an archived version or other sourse This was the rationale for the earlier comments above Although the guideline on this point includes the following incomprehensible statement if there is no archived version of the web page be sure to wait 24 months No idea what this means in normal English 98 0 246 242 talk 18 10 16 May 2021 UTC dd dd dd dd ssrn Latest comment 2 years ago 6 comments 4 people in discussionEditor Nemo bis made this edit which is more or less pointless because identifier access is by default paywalled unless explicitly set to free The Editor did add a comment in the code often free to read but rate limited and may require subscription I do not know how true that statement is so invite Editor Nemo bis to discuss that change here Trappist the monk talk 14 24 9 May 2021 UTC I ve removed the default option since it access varies SSRN started hosting pay to read articles despite it being clearly against their stated mission Headbomb t c p b 16 09 9 May 2021 UTC But in addition to that you need to login in order to be able to actually be able to download the supposedly open things If you re logged out you re subject to restrictions a la metered paywall where the second PDF you download in a day will require you to login or things like that Changing the default access level is not pointless It s useful for people to be able to navigate the identifiers and links we provide in citations which is the entire point of having them in the first place Having the grey icon next to one identifier and the green icon next to another makes it easier to reach the full text without having to open a dozen tabs for each citations and without having to study the purpose and access model of each target website Nemo 17 18 9 May 2021 UTC You need to login in order to be able to actually be able to download the supposedly open things again not for most papers Most papers are free and don t require login Some might require registration Others might require you to pay Headbomb t c p b 18 04 9 May 2021 UTC dd dd Support for ssrn access free added Cite ssrn comparison Wikitext cite ssrn wbr wbr ssrn access free wbr wbr ssrn 12345 wbr wbr title Title Live Title SSRN 12345 Sandbox Title SSRN 12345 It would be nice to track ssrn because each use of that parameter should be reviewed and ssrn access free added where appropriate But recent XfDs prevent that without we first RfC for permission Trappist the monk talk 12 04 21 May 2021 UTC Is there an XfD with such implications I thought the recent CfD which is peripherally still under discussion concerned different specific parameters 24 103 251 114 talk Preceding undated comment added 12 47 21 May 2021 UTC dd Protected edit request on 16 April 2021 Latest comment 2 years ago 27 comments 12 people in discussion This edit request to Module Citation CS1 Whitelist has been answered Set the answered or ans parameter to no to reactivate your request Please revert this edit since it was based on the incorrect and now overturned closure of this RfC The new close finds that non hyphenated parameters should not be deprecated in citation templates therefore the edit as it stands is in clear violation of this consensus RandomCanadian talk contribs 13 36 16 April 2021 UTC Accessdates and the like were not deprecated in that edit so this edit request is based on a flawed premise Headbomb t c p b 13 47 16 April 2021 UTC Except it still marks these parameters as discouraged which is not what the close of the RfC says does it This means that existing hyphenated e g access date and non hyphenated e g accessdate parameters should both continue to be supported by the templates if I can read the template correctly that should mean they should be set to true not pre deprecation purgatory since there is explicitly no consensus to deprecated the parameters now or at some future point RandomCanadian talk contribs 14 03 16 April 2021 UTC That edit has already been reversed in the module sandboxes and the category description has been changed to explain that it is only a tracking category Conversations continue above about how best to track the remaining unhyphenated parameters Jonesey95 talk 14 38 16 April 2021 UTC dd dd Oppose Discouraged deprecated and discouragement need not lead to deprecation The RFC outcome Option C doesn t restrict developer discouragement so there is no need to reverse the edit The module will continue to support both parameters The module comment re pre deprecation purgatory may be too aggressively suggesting deprecation and can be changed or removed Tom Reding talk dgaf 16 27 17 April 2021 UTC The finding that these parameters are in any way discouraged was reversed and the associated changes made should thus also be reversed Nikkimaria talk 18 15 17 April 2021 UTC The concept of discouragement wasn t reversed in close 2 it wasn t even mentioned As such the RFC has no bearing on whether or not to track these parameters in any way Tom Reding talk dgaf 21 36 17 April 2021 UTC Close 1 invented the concept of discouraged and was reversed meaning that the concept no longer has any basis The other changes associated with the reversed closure should similarly be reversed Nikkimaria talk 21 50 17 April 2021 UTC Close 1 invented the concept of discouraged Not true The first close invented the term developer discouraged Elsewhere on this page I wrote that developer discouraged is a new term to me On my talk page the closer confirmed the term is a made up term created for the purpose of the close The notion of discouraged cs1 2 parameters has been around for quite a while Before it was deprecated and finally removed use of editors was discouraged and at one time had its own tracking category Category CS1 maint uses editors parameter July 2016 August 2020 authors is discouraged see for example the documentation at cite book and Category CS1 maint uses authors parameter since July 2016 Trappist the monk talk 23 02 17 April 2021 UTC the closer confirmed the term is a made up term created for the purpose of the close ie the close invented the concept as used in the context under discussion the changes resulting from that close The current close does not support the notion that these parameters are discouraged as you define it nor that they require a maintenance category Nikkimaria talk 23 17 17 April 2021 UTC You wrote Close 1 invented the concept of discouraged That is a false statement because as I explained cs1 2 has had the concept of discouraged parameters since 2016 The closer s term developer discouraged as noted on my talk page where the closer wrote No I literally just made it up was made up for the purposes of that close Close 2 is mute with regard to categories is mute with regard to the term discouraged is mute with regard to the term developer Trappist the monk talk 15 22 18 April 2021 UTC We should probably delete the main page and many other things while we re at it since the close made no mention of it Tom Reding talk dgaf 16 16 18 April 2021 UTC If you want to delete the main page or make parameters discouraged feel free to start a new RfC In the meantime though since the initial close was undone the associated changes should also be undone Nikkimaria talk 00 53 19 April 2021 UTC dd dd dd dd dd dd dd dd The request was for the module to be reversed while it is nice that this has been done in the sandbox already it doesn t answer the original request If sandbox changes get automatically transported to the main module then please tell us when If not then please inform us when this change will be reverted Fram talk 17 22 16 April 2021 UTC Looking at Module Citation CS1 updates only happen every few months and the most recent update was just a few days ago It will probably be a while given the need to avoid re rendering millions of pages too frequently Vahurzpu talk 02 51 17 April 2021 UTC Seeing as the initial RfC result was implemented within a week it seems reasonable that the new result would also be implemented promptly rather than waiting a few months Nikkimaria talk 14 48 17 April 2021 UTC Indeed I think that would be reasonable I just don t think that we know what the exact next step is especially with an unnecessary CFD started by thread OP Izno talk 14 54 17 April 2021 UTC RandomCanadian the OP didn t start the CfD Fram talk 08 21 19 April 2021 UTC dd dd dd RandomCanadian Can this be closed It s being discussed elsewhere here and here It s been more than ten days already while this edit request has been pending MJL Talk 03 05 28 April 2021 UTC Note that Wikipedia Categories for discussion Log 2021 April 16 Category CS1 maint discouraged parameter has now been closed as delete Pppery it has begun 18 10 9 May 2021 UTC Now that the CfD has closed as delete can this edit request please be executed and can the necesarry changes be made to depopulate the category Fram talk 07 06 10 May 2021 UTC It would probably be better to wait for Wikipedia Deletion review Log 2021 May 10 Category CS1 maint discouraged parameter to close before taking any action 13 23 10 May 2021 UTC Preceding unsigned comment added by Pppery talk contribs That DRV has now been closed without consensus to overturn the original CfD Can someone please do this now Pppery it has begun 13 14 18 May 2021 UTC I wouldn t rush The DRV reviewer s opinion has holes that have to be attended to 64 18 9 210 talk 15 31 18 May 2021 UTC Please drop the stick Pppery it has begun 16 40 18 May 2021 UTC dd dd dd Now that the RfC close review the CfD the DRV and the DRVRV are all closed can we perhaps finally do this Fram talk 14 21 21 May 2021 UTC Done by Amakuru this exact edit wasn t implemented but code to depopulate the discouraged parameter was which is what is fundamentally being asked for Pppery it has begun 15 14 25 May 2021 UTC Thank you Fram talk 08 34 26 May 2021 UTC dd CS1 module suite update date TBD April 2021 Latest comment 2 years ago 41 comments 12 people in discussionI suggest that we do an out of cycle update to the cs1 2 module suite on a date TBD sometime between now and the end of April 2021 primarily in order to implement the reclosure of the unhyphenated parameter RFC Here are the changes to date since the last major update on 10 April Module Citation CS1 detect generic author editor etc names discussion Remove code to detect categorize and display hidden maintenance message for discouraged parameters per RFC reclosure add CS1 uses parameter 1 properties tracking categories discussion emit error when first is wikilinked discussion revise how date month name auto translation is enabled discussion add support to allow editors to see citations that emit properties cats discussion url status without archive url maint cat discussionModule Citation CS1 Configuration detect generic author editor etc names Remove code to detect categorize and display hidden maintenance message for discouraged parameters per RFC reclosure add CS1 uses parameter 1 properties tracking categories remove support for unused isbn13 and ISBN13 discussion remove support for previously deprecated parameters booktitle chapterurl episodelink mailinglist mapurl nopp publicationdate publicationplace serieslink transcripturl add support for nrf gg nrf je language codes discussion revise how date month name auto translation is enabled add support to allow editors to see citations that emit properties cats Removed reliance on error discussion url status without archive url maint cat add support for ssrn access discussionModule Citation CS1 Whitelist updated 25 May 2021 Remove support for previously deprecated parameters booktitle chapterurl episodelink mailinglist mapurl nopp publicationdate publicationplace serieslink transcripturl Remove code to detect categorize and display hidden maintenance message for discouraged parameters per RFC reclosure add CS1 uses parameter 1 properties tracking categories remove support for unused isbn13 and ISBN13 add support for ssrn access remove support for url and URL from a href Template Cite arxiv html class mw redirect title Template Cite arxiv cite arxiv a a href Template Cite biorxiv html class mw redirect title Template Cite biorxiv cite biorxiv a a href Template Cite citeseerx html class mw redirect title Template Cite citeseerx cite citeseerx a and a href Template Cite ssrn html class mw redirect title Template Cite ssrn cite ssrn a discussion Support for some template specific parameters limited to those templates discussion season series no and series number limited to use by a href Template Cite episode html title Template Cite episode cite episode a series link limited to use by cite episode and a href Template Cite serial html title Template Cite serial cite serial a cartography limited to use by a href Template Cite map html title Template Cite map cite map a book title limited to use by a href Template Cite conference html title Template Cite conference cite conference a conference conference format conference url event limited to use by a href Template Cite conference html title Template Cite conference cite conference a and a href Template Cite speech html title Template Cite speech cite speech a degree limited to use by a href Template Cite thesis html title Template Cite thesis cite thesis a docket limited to use by a href Template Cite report html title Template Cite report cite report a and a href Template Cite thesis html title Template Cite thesis cite thesis a Module Citation CS1 Date validation extend allowed dates in pmc embargo date validation to two years discussion revise month name validation discussion add support to allow editors to see citations that emit properties catsModule Citation CS1 Identifiers add support for ssrn access Module Citation CS1 Utilities add support to allow editors to see citations that emit properties catsModule Citation CS1 COinS No changesModule Citation CS1 styles css Removed reliance on errorModule Citation CS1 Suggestions Uncomment suggestions for parameters moving from deprecated to unsupportedLinks to relevant discussions along with implementation date suggestions are welcome in the above list they should all still be on this page I will come back and add the discussion links if I have time later Jonesey95 talk 21 39 19 April 2021 UTC arxiv class Really don t see the point of having arxiv class class doesn t cover anything else and is only supported by cite arxiv There s no confusion possible and I object its creation Headbomb t c p b 23 32 19 April 2021 UTC Yes you know all this only if you follow this page There s a chance that the module may be targeted to a wider audience On that outside chance the module should present editors a consistent approach and its documentation should expand on consistency as one of the design principles applied Additionally the documentation could include info about the particular template such as the one you referred to above Again on the outside chance that editors may not encounter Arxiv or arxiv citations on a daily basis I know it s a drag But you are not the one doing it it is somebody else s burden 173 52 226 51 talk 00 39 20 April 2021 UTC Actually I m the one doing most arxiv related cleanup Again there is no confusion with anything class doesn t pertain to anything but cite arxiv because class is only used with cite arxiv If you don t use cite arxiv you will not see class anywhere arxiv class is busy work that serves no purpose but to cause confusion by renaming a uniformly used parameter into a mismash of new and old for no reason Headbomb t c p b 00 50 20 April 2021 UTC What was meant as burden was the updating maintenance of the module Otherwise and sincerely I believe that any work you do to clean up this area is commendable 98 0 246 242 talk 03 28 20 April 2021 UTC dd dd class is a pretty vague parameter I m not personally sold on moving deck chairs around though so Izno talk 01 15 20 April 2021 UTC These discussions about parameter labels are very refreshing Questions spring to mind how is an editor to know that only cite arxiv uses a class parameter Secondly is there an implicit assumption that there will forever be only one class labeled parameter in all of CS1 2 I understand that people with intimate knowledge of Arxiv will find the new term unnecessary and convoluted I am not in favor of aliases but I would recommend arxiv class as an alias of class for this template CS1 2 covers a diverse field of cited sources It is not unusual to find in any article a number of different CS1 2 citation templates At some point it may be easier for the average editor to have to deal with a single standardized nomenclature the one native to CS1 2 rather than wade through unfamiliar industry practice Assuming that such nomenclature is simply and concisely explained 98 0 246 242 talk 03 19 20 April 2021 UTC How is an editor to know that only cite arxiv uses a class class only appears in cite arxiv documentation and is undermentioned anywhere else Headbomb t c p b 12 03 20 April 2021 UTC I have my doubts that even seasoned template editors would know this It may require an extraordinary level of attention to the particulars of template parameter documentation 98 0 246 242 talk 23 57 21 April 2021 UTC CS1 CS2 parameters should follow a consistent naming scheme within the CS1 CS2 universe so that they are easy to memorize and ideally can be constructed from memorizing the scheme without having to remember a particular parameter specifically or to look up it up the documentation They should also be self explanatory so that if a user runs into a parameter s he can guess the meaning without having to look up the documentation While there are still areas for improvement I think we have improved quite a bit regarding this in recent years class by itself is quite meaningless and ambiguous There are other possible classes that are used in conjunction with references We don t currently use them but we might have other class parameters in the future so I think it is time to prepare for this We don t need to hurry class can stay for the while being but the arxiv class parameter should exist as well for a smooth transition Parameters and attributes named class are also used for other purposes for example in HTML making it difficult to reliably search for the CS1 parameter class Searching for arxiv class however would not give false positives As the arxiv parameter is supported by other CS1 templates than cite arxiv as well is there a specific reason why we do not support the class parameter in other templates as well Matthiaspaul talk 19 48 22 April 2021 UTC Simply put no This is citations not CSS We do not need to preemptively disambiguate something that doesn t need disambiguation As for not supporting it in other citations it s because it s not relevant to other citations This is something that s only relevant to cite arxiv There is zero point in forking the parameter and breaking tools for we have consistant usage let s keep it that way Headbomb t c p b 19 52 22 April 2021 UTC dd dd dd dd dd dd dd Reverted the arxiv class thing in the sandbox This does not have consensus Headbomb t c p b 05 01 28 April 2021 UTC Headbomb I think your removal was incomplete The sandbox renders with red Lua errors Scroll up and down this page to see them Jonesey95 talk 05 10 28 April 2021 UTC He removed the whole line and probably should not have since that is not undoing what the original edit did Fixed Izno talk 05 19 28 April 2021 UTC Yes thanks for fixing LUA is awful Headbomb t c p b 05 55 28 April 2021 UTC dd dd I don t find your arguments that we shouldn t have arxiv class very convincing cite arxiv is a CS1 CS2 citation template and within that family of citation templates all parameters should follow the same naming scheme in order to make it easier for editors to remember or even derive parameter names and their relations This holds true also for parameters which are for some reason private to a specific template only because otherwise we could have a class parameter in another template with a completely different meaning class being a modifier for one of the identifiers arxiv its name should be arxiv class following the example of all other such parameters we have doi doi broken date pmc pmc embargo date asin asin tld and a whole bunch of bibcode access doi access hdl access jstor access ol access osti access s2cid access They all start with the identifier name they belong to and end on the argument type to be entered a date a top level domain an access state so following this scheme a class type belonging to arxiv should be specified in a parameter named arxiv class This would be consistent class by itself is not following this scheme and therefore is inconsistently named It is also a meaningless parameter name by itself so people running into it cannot derive its purpose from its name and for people who are potentially using it it is more difficult to remember because it is an exception to the mind model of how other parameter names were chosen Unfortunately you didn t answer my question why we don t support the parameter in all CS1 CS2 parameter supporting arxiv You just stated it would not be relevant in other templates but did not answer why In the original thread you even asked for class to become kind of a mandantory parameter for cite arxiv from this I derive that it is important to you So why is it important in cite arxiv and not in say cite book which supports arxiv as well I m asking because right now it is handled as an exception and it would simplify the code if we won t have to treat it like an exception Regarding HTML CSS the existence of the style attribute was brought forward against naming a parameter style which is one reason for why we settled on name list style eventually Similar situation for class Regarding scripts adding a parameter is not breaking anything And it would be trivial to change the scripts to support both parameters arxiv class and class anyway if we don t fade out class at a later stage If as you stated you are mostly alone working in this area updating the scripts should be even easier Of course in an ideal world a good parameter name would have been chosen right from the start so that there would be no desire to change it but if we want to reach the goal of having a logical and consistent interface for all CS1 CS2 templates eventually we shouldn t wait harmonizing parameter names until we actually run into a name conflict because the longer we wait the more we will have to clean up afterwards Therefore even if we do not disable support for class soon in order to keep backward compatibility until everyone has switched we should start to educate people to use arxiv class instead as soon as possible Matthiaspaul talk 07 18 28 April 2021 UTC Except that class doesn t modify in anyway arxiv What you ll find in cite arxiv is most typically a href Template Cite arxiv html class mw redirect title Template Cite arxiv cite arxiv a eprint 1234 54321 class hep ex Headbomb t c p b 09 27 28 April 2021 UTC dd I m inclined to agree with Editor Matthiaspaul because I too don t find Editor Headbomb s reason persuasive Editor Headbomb appears to be the only editor who is opposed Editor Izno appears to be indifferent IP editor 98 0 246 242 173 52 226 51 appears to support Editor Matthiaspaul supports and I support because I am persuaded by the argument that parameter names should be correctly descriptive we should think about ref in another discussion So I think that Editor Headbomb s edit should be reverted Trappist the monk talk 13 10 28 April 2021 UTC The argument for renaming the parameter arxiv class in cite arxiv is as nonsensical as renaming isbn to book isbn in cite book It s a parameter unique to cite arxiv there is no need for disambiguation especially at the expense of creating unnecessary complexity that will cause maintenance headache and tool breakage Headbomb t c p b 15 49 28 April 2021 UTC dd dd I think right now I lean toward let s not move the deck chairs around with only 3 in support and 1 opposed at this time Adding a parameter later is easy removing one later is not Generally I d be appreciative for opinions from editors who aren t you four I see persuasive arguments for changing the name but not sufficiently persuasive if all it is doing is moving deck chairs or with the stated purpose of moving deck chairs That all said I continue to prefer to wait until the CFD for the category responsible for this update be settled first so perhaps others may comment and settle the matter Izno talk 14 21 28 April 2021 UTC I would say that any discussion in these parts involving 4 editors is packed to the rafters 98 0 246 242 talk 01 12 4 May 2021 UTC As much as it pains me to say it Izno was right to say that we should wait for the CFD closure Blargh Jonesey95 talk 18 20 9 May 2021 UTC What is the use of class even in Cite arXiv This is not physical library where we need to first take the stairs to astro ph Is is because some areas have low standards or because it helps identify areas like a journal title would or is it another reason AManWithNoPlan talk 01 52 21 May 2021 UTC It s the topical classification of the arxiv which corresponds to moderation sections i e standards hep ph is in the High Energy Physics Phenomenology section hep ex is the High Energy Physics Experimental section gen ph is general physics which is where a lot of woo nonsense get classified into and so on A while back this was part of the identifier physics 0123467 but the identifier changed to YYMM with the classification listed separately in square brackets Headbomb t c p b 03 23 21 May 2021 UTC See also User talk Headbomb unreliable gen ph Headbomb t c p b 03 27 21 May 2021 UTC Years ago it was explained to me that a national physics conferences have an anything goes crack pot section in which basically all talks were accepted but were limited to 5 minutes including the changing speaker time We chemists generally have a poster section like that AManWithNoPlan talk 14 27 21 May 2021 UTC dd dd dd dd dd dd dd Anyone want to update the list and support this update A number of changes have been made to the sandboxes since I posted the above list Is there support for this out of cycle update If so please speak up here and someone needs to update the above list of changes Jonesey95 talk 05 10 28 April 2021 UTC So long as arxiv class is kept out what s in there shouldn t be controversial reflects RFCs Headbomb t c p b 09 25 28 April 2021 UTC I ve made an attempt at updating the list of changes from the comments section of each sandbox although there appear to be some edits to Module Citation CS1 Identifiers sandbox and Module Citation CS1 Configuration sandbox that don t have any entry in the changes list And I support this update happening in order to finally implement the result of the discouraged parameters CfD Pppery it has begun 00 47 21 May 2021 UTC does something else need to be done before this update happens Pppery it has begun 00 02 22 May 2021 UTC I believe it should be good to go from what s in the Sandbox Trappist the monk is there anything holding this up I would sync from the sandbox myself but it looks like nobody except Trappist has edited Module Citation CS1 Whitelist in the past eight years so I don t want to tread on any toes We do need to get the latest updates in though because currently certain parameters are still being tracked as discouraged Cheers Amakuru talk 21 02 23 May 2021 UTC More silence Amakuru The CS1 module suite is not WP OWNed by Trappist the monk and this would not be the first time an external admin edited it The only reason Module Citation CS1 Whitelist hasn t been edited by anyone else in years is that its contents have never been controversial before whereas various other CS1 modules have been controversial and were edited by others at various times You should just do it and either copy from Module Citation CS1 Whitelist sandbox to Module Citation CS1 Whitelist or just implement Protected edit request on 16 April 2021 above and revert the last two edits to Module Citation CS1 Whitelist going back to Special PermaLink 999303024 It s more important that things get done than vague worries about things like tread ing on toes at this point now more than 2 weeks after the CfD was closed and one week after the DRV was closed Pppery it has begun 14 03 25 May 2021 UTC Pppery Done As you say there has been enough time for this to be enacted and nobody has even replied to the above comments So I have gone ahead and pushed the sandbox changes from Module Citation CS1 Whitelist sandbox live into Module Citation CS1 Whitelist If anything else needs doing or this leads to any errors then please let me know Amakuru talk 15 13 25 May 2021 UTC Thanks I don t think anything else needs doing although it will likely take several weeks for the Job queue to remove all 1 000 000 pages from the category Pppery it has begun 15 22 25 May 2021 UTC dd dd dd dd dd Tracked parameter code partially removed The discouraged parameter category this CFD has been closed and Pppery set the hyphenated parameters back to true in Whitelist sandbox no judgment on this action just stating facts to keep the timeline straight I don t think that change to just one of the modules will completely undo the parameter tracking system that we have set up It is unclear to me whether the sandboxes are in a deployable state as of this time stamp Jonesey95 talk 18 20 9 May 2021 UTC I believe it s deployable in the sense that nothing would break were they to be deployed but there s some now dead code in the Configuration and main modules that someone could clean up if they felt inclined to Pppery it has begun 00 45 10 May 2021 UTC I would recommend waiting I have commented at the closer s talk page well one of them and at CfD regarding the closure which imo is ripe for review So let s see where this will go if anywhere Relax and enjoy 98 0 246 242 talk 01 44 10 May 2021 UTC Note that this IP has now taken the CfD to deletion review at Wikipedia Deletion review Log 2021 May 10 Category CS1 maint discouraged parameter Pppery it has begun 13 23 10 May 2021 UTC and the DRV has now been closed without consensus to overturn the CfD closure Can this please go ahead now Pppery it has begun 13 14 18 May 2021 UTC Maybe maybe not I have asked for certain clarifications from the DRV reviewer Depending on whether the answers are forthcoming and make sense this will then proceed accordingly 67 254 224 137 talk 19 53 18 May 2021 UTC dd dd dd dd I am having a nice discussion with the DRV reviewer about this But I don t want to be seen as holding up anything that happens here I have a feeling that the issue of the biased CfD nomination may have to be escalated to a wider forum more appropriate to reviewing administrator decisions So please proceed I have no objections as the final resolution of this may take a while And of course anything can be reversed 64 18 9 192 talk 12 10 19 May 2021 UTC Preprint template TemplateData showing multiple not valid parameter errors Latest comment 2 years ago 1 comment 1 person in discussion span data mw comment start id c Jonesey95 2021 05 25T16 36 00 000Z Preprint template TemplateData showing multiple not valid parameter errors span a href Template Cite arxiv html class mw redirect title Template Cite arxiv cite arxiv a a href Template Cite biorxiv html class mw redirect title Template Cite biorxiv cite biorxiv a and a href Template Cite ssrn html class mw redirect title Template Cite ssrn cite ssrn a are all showing at least one not valid parameter error message at the top of their TemplateData sections Some of the messages conflict with existing template documentation I don t mess with TemplateData but if anyone wants to sort this out that would be helpful If actual documentation changes are needed I m happy to help with those Jonesey95 talk 16 36 25 May 2021 UTC New unsupported parameter errors after Whitelist update Latest comment 2 years ago 5 comments 3 people in discussionA note to those who watch the unsupported parameter error category the Whitelist portion of the module was updated today and it has resulted in a flow of new pages into Category CS1 errors unsupported parameter I believe that I have compiled a comprehensive list of the relevant changes below remove support for url and URL from a href Template Cite arxiv html class mw redirect title Template Cite arxiv cite arxiv a a href Template Cite biorxiv html class mw redirect title Template Cite biorxiv cite biorxiv a a href Template Cite citeseerx html class mw redirect title Template Cite citeseerx cite citeseerx a and a href Template Cite ssrn html class mw redirect title Template Cite ssrn cite ssrn a discussion Support for some template specific parameters limited to those templates discussion season series no and series number limited to use by a href Template Cite episode html title Template Cite episode cite episode a series link limited to use by a href Template Cite episode html title Template Cite episode cite episode a and a href Template Cite serial html title Template Cite serial cite serial a cartography limited to use by a href Template Cite map html title Template Cite map cite map a book title limited to use by a href Template Cite conference html title Template Cite conference cite conference a conference conference format conference url event limited to use by a href Template Cite conference html title Template Cite conference cite conference a and a href Template Cite speech html title Template Cite speech cite speech a degree limited to use by a href Template Cite thesis html title Template Cite thesis cite thesis a docket limited to use by a href Template Cite report html title Template Cite report cite report a and a href Template Cite thesis html title Template Cite thesis cite thesis a The documentation for the relevant CS1 templates does not entirely match these changes yet and in some cases the Whitelist instead of the documentation may need to be modified The documentation for a href Template Cite serial html title Template Cite serial cite serial a for example currently shows season as valid but it generates an error Post any questions here Jonesey95 talk 17 02 25 May 2021 UTC Jonesey95 thanks for compiling this list If there are any Whitelist changes that need to be effected and Trappist isn t around then I ll be happy to help out Cheers Amakuru talk 17 07 25 May 2021 UTC Amakuru I guess this was done to finally implement the RfC consensus seeing as the hyphenated parameters are no longer classified as discouraged Jonesey95 why is the second cite episode unlinked when the other repeated template names are linked BRAINULATOR9 TALK 17 28 25 May 2021 UTC Brainulator9 yes that s correct See the section above at Help talk Citation Style 1 Anyone want to update the list and support this update I implemented all the changes that were waiting in the sandbox which I assume is the usual procedure Presumably it s those changes that have led to the now deprecated parameters mentioned above Cheers Amakuru talk 17 39 25 May 2021 UTC Yes the change to the Whitelist has resulted in a new batch of citations being detected as using unsupported not deprecated there is a meaningful difference when it comes to this module at least parameters Jonesey95 talk 18 30 25 May 2021 UTC dd dd dd Identifying paper with cite conference Latest comment 2 years ago 2 comments 2 people in discussionThe documentation at template cite conference for cite conference is incomplete e g it mentions book title but does not describe its use nor its relation to conference and title As a concrete example if I want to cite the paper The interface message processor for the ARPA computer network which was presented at the 1970 Spring Joint Computer Conference and printed in AFIPS Conference Proceedings Volume 36 1970 Spring Joint Computer Conference do I mark it up as cite conference title The interface message processor for the ARPA computer network pages 551 567 conference 1970 Spring Joint Computer Conference book title AFIPS Conference Proceedings Volume 36 1970 Spring Joint Computer Conference year 1970 publisher AFIPS Press which will render as The interface message processor for the ARPA computer network AFIPS Conference Proceedings Volume 36 1970 Spring Joint Computer Conference 1970 Spring Joint Computer Conference AFIPS Press 1970 pp 551 567 or do I abbreviate SJCC remove some of the redundant text or wikilink e g AFIPS in the parameters Shmuel Seymour J Metz Username Chatul talk 17 51 25 May 2021 UTC You figured it out I have updated the documentation to explain how to use book title I don t know when that explanation went missing if it was ever there Jonesey95 talk 18 43 25 May 2021 UTC Template Cite sign Latest comment 2 years ago 5 comments 3 people in discussionWhat parameters are supported by Template Cite sign and where is the blank version we are told to copy DuncanHill talk 22 45 24 May 2021 UTC I m also having this issue The template needs more descriptors specific to signs too Tyrone Madera talk 19 21 25 May 2021 UTC Tyrone Madera As there appears to be nobody here either willing or able to help I shall ask at WP VPT instead DuncanHill talk 15 20 30 May 2021 UTC I ve made a start on a blank version Andy Mabbett Pigsonthewing Talk to Andy Andy s edits 15 28 30 May 2021 UTC Pigsonthewing thank you and is there anything in this which you might find helpful DuncanHill talk 16 18 30 May 2021 UTC dd dd dd edtf date formats as cs1 2 date parameter values 2 Latest comment 2 years ago 7 comments 4 people in discussionMediaWiki giveth MediaWiki taketh away Changes made because of phab T132308 are to be rolled back so I have removed support for the EDTF YYYY MM XX date format from the sandboxen Trappist the monk talk 22 15 11 May 2021 UTC We might need a bot run to fix the 600 articles in which this format currently appears Jonesey95 talk 22 43 11 May 2021 UTC I don t think so In bureaucratic terms a WP BRFA is far too costly I ve begun picking away at the 600 with awb as the mood takes me I ll be done soon enough after all there is no hurry Trappist the monk talk 23 00 11 May 2021 UTC In bureaucratic terms a WP BRFA is far too costly This is the sort of thing that could be approved in a day after a short trial Headbomb t c p b 23 17 11 May 2021 UTC Could be AWBd in 2 hours instead Izno talk 23 57 11 May 2021 UTC That has never been my experience And besides in the current toxic atmosphere Monkbot task anything is likely to incite drama No thanks Current batch of YYYY MM XX dates converted There are likely to be more between now and when the rolled back version of citoid goes live Trappist the monk talk 13 12 12 May 2021 UTC dd dd dd I ve been wondering if we shouldn t just make a machine date for machine filling I briefly considered iso date but that doesn t indicate to users that they shouldn t use that Use it as the backup date if someone should add date Izno talk 03 44 31 May 2021 UTC Cite serial Latest comment 2 years ago 4 comments 4 people in discussionIs there any reason that Cite serial 274 transclusions cannot be merged into Cite episode over 15K transclusions Andy Mabbett Pigsonthewing Talk to Andy Andy s edits 17 29 30 May 2021 UTC I think it should be redirected after ensuring that nothing will break I ve never fully understood the difference between them In practice cite serial appears to be used quite a bit for individual episodes instead of something that is part of a collection of episodes that is not a season UK series The edit summary for its creation says Creating Cite serial it s a copy of Cite episode except it italicizes a serial title rather than putting it in quotes For use of tv shows which use both serial titles and episode titles In practice I don t think it s used for that in most cases Perhaps we should just go through the citations one by one and convert the ones that cite a single episode without a serial title to cite episode and then see what is left Jonesey95 talk 17 41 30 May 2021 UTC Agreed I tried to conceive a valid reason for one to cite an entire season series rather than the particular episode s and it escapes me The closest I could come to a rationale would be an article citing multiple episodes of the same series where the editor might prefer a compound reference with the series as the main citation and the individual episodes in sublist A bit involved 161 221 13 10 talk 20 30 30 May 2021 UTC Surprisingly no previous TFD on the point that shows up in WLH I vaguely recall this being somewhat contentious but maybe that s some weird memory to do with Dr Who fans you know how they get The migration to CS1 discussion may be illuminating as to actual purpose and why they weren t merged way back when Izno talk 20 42 1 June 2021 UTC How to markup reports done under contract to government agencies Latest comment 2 years ago 8 comments 4 people in discussionI want to create a citation for https apps dtic mil dtic tr fulltext u2 a206308 pdf in Timeline of operating systems 1980s and am having trouble locating the correct template and parameters The markup cite report title Quarterly Status Report Report 1 id AD A206 308 date 15 March 1989 url https apps dtic mil dtic tr fulltext u2 a206308 pdf publisher TRW Federal Systems Group Systems Division produces Quarterly Status Report Report 1 PDF Report TRW Federal Systems Group Systems Division 1989 03 15 AD A206 308 and seems like a reasonable start but it is missing e g the contract number the order code the program code the program name the sponsoring agency I intend to use work for the program name as a stopgap but that doesn t seem right What is the proper markup 15 58 31 May 2021 UTC Shmuel Seymour J Metz Username Chatul talk Chatul Is all of that detail really neccessary to uniquely identify the document Roger Dodger67 talk 16 31 31 May 2021 UTC Agreed that detail is not generally necessary You might consider via for DTIC and work for Advanced Computing Systems An Advanced Reasoning Based Development Paradigm for Ada Trusted Systems and Its Application to MACH That would be the sufficient details to find a copy Also archive url and date of course Izno talk 16 58 31 May 2021 UTC You can also put any text that you want to append after the cite template itself and inside the ref tags Quarterly Status Report Report 1 PDF Report TRW Federal Systems Group Systems Division 1989 03 15 AD A206 308 Contract number ABCD123 Sponsored by DARPA etc Jonesey95 talk 21 48 31 May 2021 UTC Are you proposing dd dd cite report title Quarterly Status Report Report 1 id AD A206 308 date 15 March 1989 url https apps dtic mil dtic tr fulltext u2 a206308 pdf work Advance Computing Systems An Advanced Reasoning Based Paradigm for Ada Trusted Systems and its Application to MACH via https apps dtic mil dtic tr publisher TRW Federal Systems Group Systems Division Contract number MDA 972 89 C0029 Sponsored by DARPA ARPA order No 6414 Program Code No 9T10 BTW the actual title included the date Was it proper to redact it since I had a date or should I have left it in Shmuel Seymour J Metz Username Chatul talk 14 36 1 June 2021 UTC Via is not for URLs use DTIC in context Yes that is what Jonesey is proposing Izno talk 14 51 1 June 2021 UTC Yes suppressing the date is fine and or idiomatic when it appears in the title probable exception you have nothing else to put in the title Izno talk 14 55 1 June 2021 UTC dd dd I m not aware of any guidance in WP MOS on what level of detail to provide in citations such guidance and links to it from template documentation would be helpful Shmuel Seymour J Metz Username Chatul talk 14 36 1 June 2021 UTC Sufficient information to identify where the information being cited originates such that another sufficiently motivated person can verify the content being cited themselves c f WP Citing sources For web sources this is fundamentally the URL and perhaps the archive URL Anything else is largely a bonus The parameters this template supports are almost always sufficient to identify a source Certainly contract number sponsoring agency order number and program code are superfluous given the other information in the cite report you have filled in response to Jonesey s comment Izno talk 14 54 1 June 2021 UTC dd dd lay url and laysummary Latest comment 2 years ago 4 comments 4 people in discussionWP MEDPOP suggests using laysummary However when I put that into the template apparently because somebody decided somewhere that unhyphenated parameters are not OK I get this error message So the solution is either A to add the suggested alternative as an alias as consistent with making templates easier to use for everyone or B to update MEDPOP to enforce whatever you folks over here have decided on doing Cheers RandomCanadian talk contribs 19 25 1 June 2021 UTC Updated medpop The lay source parameters that are supported are a topic of discussion for the chopping block in a few recent instances on this talk page because if the lay source really is valuable as a source it should get its own template not be hacked badly into the journal article s template Current use of lay url is only 2300 pages Izno talk 20 24 1 June 2021 UTC span data mw comment start id c Trappist the monk 2021 06 01T23 09 00 000Z RandomCanadian 2021 06 01T19 25 00 000Z span lay date lay format lay source and lay url should go away because cs1 2 templates are intended to cite a single source These parameters make it sort of possible to cite two independent sources using a single cs1 2 template but the citation of the second source is flawed because these four parameters cannot be used to create a complete second citation and there is no support in the citation s metadata for the second source If the lay source is truly important to an article WP MEDPOP seems to suggest that most lay sources are not then a href Template Cite magazine html title Template Cite magazine cite magazine a a href Template Cite news html title Template Cite news cite news a a href Template Cite web html title Template Cite web cite web a etc are better choices for citing the lay source Trappist the monk talk 23 09 1 June 2021 UTC the lay source is often the orginal source too because of template misuse AManWithNoPlan talk 23 16 1 June 2021 UTC dd cite newspaper Latest comment 2 years ago 15 comments 11 people in discussionGiven that pages using cite news outnumbers cite newspaper by over a factor of 100 and newspaper is just a redirect Is there any reason to not have the Citation Bot covert newspaper to news when it finds them AManWithNoPlan talk 01 14 27 May 2021 UTC If that were the only change Citation Bot made to a page it would be a cosmetic edit and six editors would show up with pitchforks and torches and block the bot Other than that I don t see a problem with it and the guideline at WP BRINT vaguely supports replacing template redirects with their targets as long as there is some other substantive change being made to the page at the same time Jonesey95 talk 15 12 27 May 2021 UTC No pitchforks from my side but I think that cite newspaper is actually the more appropriate name for the template cite news has the advantage that it is shorter What gives Keep them as was decided upon by the editor who added them Matthiaspaul talk 16 57 29 May 2021 UTC The ratio of pages with news to newspaper is about 200 to 1 I highly doubt almost anyone is make a decided choice some editors carefully choose between issue and number in cite journal so never say never I find that many applications of newspaper are to online newspapers and many applications of news are to paper copies The existence of two templates only can confuse editors and in no way helps users AManWithNoPlan talk 17 05 29 May 2021 UTC In fact I m one of those who tries to carefully distinguish between journals and magazines numbers and issues written at and publication places etc always trying to use what is used in the actual source if that can be determined and use the most specific parameter or template name for it While some of this gets displayed the same way at present this may not always remain so in the future For example if we switch the display of journals to use abbreviations instead of the symbolic notation we use now we will ideally have to distinguish in the display of No and Iss This will also have to happen when we finally add support for periodicals which indicate both a number and an issue as we long planned to do Similar if I cite from what can be clearly identified as a newspaper either because it advertises itself as such or if I cite from something for which a paper issue exists I use cite newspaper If I cannot determine this I typically use cite news if it is a news outlet and cite web if it is some other type of web page While cite newspaper and cite news do the same at present at some point in the future they may deviate in different directions supporting different parameters or requiring a different rendering like cite journal and cite magazine or different meta data creation So it makes sense to give the editor who is actually citing the source the chance to document what it actually is it will be much more difficult for other editors and at a later point in time and next to impossible for a bot Occasionally someone might have used cite journal for a magazine cite magazine for a journal etc and it is perfectly fine for another editor to improve that but unless a bot is utilizing a curated datebase indicating if some outlet is a journal or a magazine this is not something a bot should try to do Same for cite newspaper and cite news Another reason why I generally tend to prefer cite newspaper over cite news is that the latter is somewhat ambiguous a name as we also have cite newsgroup sometimes when I haven t used the template for some while I wonder if cite news is the same as cite newsgroup or cite newspaper so it is safer to use the longer more specific names Matthiaspaul talk 08 44 30 May 2021 UTC Do the existing templates support the distinctions that you wish to preserve Does the documentation describe all of the relevant parameters I know that for e g cite book it is not possible to preserve the hierarhical relation among part chapter and section since all of the types of locations are synonymous or undefined and only one location and its URL is allowed You can t maintain fidelity without enhancing the existing templates Try e g cite book title Text with nested divisions part foo chapter bar section baz and you get bar Text with nested divisions a href Template Cite book html title Template Cite book cite book a More than one of section and chapter specified help Unknown parameter part ignored help Would what you want to do with cite newspaper have similar issues Shmuel Seymour J Metz Username Chatul talk 15 15 30 May 2021 UTC I would not consider fidelity a requirement Citations are pointers to sources As long as the source can be easily located with a minimum of information citations do not need to be exact representations of the source s structure The additional info may give a better picture of the source to the reader or it may make it easier to locate This has to be measured against clutter and complexity Also templates are just that They are formatted applications of the most generic cases of common denominators and regular trade practice Covering more specialized cases is not really the main objective and imo is not worth the programming effort Especially so when programming is subject to irrational whims and the technicalities surrounding such work have to be submitted for review 23 246 115 158 talk 13 05 31 May 2021 UTC The final sentence above was not referring to editor Chatul 64 18 9 192 talk 13 52 31 May 2021 UTC dd dd dd Is cite newspaper still appropriate when the news isn t available on paper but only as web page text audio or video Certes talk 17 12 29 May 2021 UTC Is page appropriate in the present medium Can we please step away a bit from micromanaging everything Sheesh 98 0 246 242 talk 17 19 29 May 2021 UTC dd dd FCOL cite newspaper is and always was a redirect When did WP NOTBROKEN become obsolete or should I say deprecated Sheesh indeed Michael Bednarek talk 17 29 29 May 2021 UTC https en wikipedia org wiki Wikipedia Templates for deletion Log 2007 October 13 Template 3ACite newspaper cite newspaper was voted to be deleted and the redirect was put in place to hold us over until all the usages were removed AManWithNoPlan talk 14 13 2 June 2021 UTC Not quite The template was indeed deleted in October 2007 and then recreated as a redirect in February 2008 Redirects to templates are a dime a dozen and sometimes more used than their canonical names There s nothing wrong with that and there s no need to do anything about it Michael Bednarek talk 14 54 2 June 2021 UTC dd It is not obsolete but as a cosmetic change with other non cosmetic changes template redirects are quite often converted to their canonical name to simplify the root wikitext As Jonesey above points out this is routine and implemented in other semi automated systems CitationBot converting to the canonical form in this case seems quite reasonable Izno talk 15 51 2 June 2021 UTC dd Redirects may be free but free can mean many things in computing I ve spent a lot of my free time discovering and programming around them or missing and causing errors that would have been better used elsewhere That doesn t mean eliminate all aliases they can be useful but when they are small in number let s convert to canonical If they fail to reappear no one is using them then delete GreenC 19 37 2 June 2021 UTC Suffixes Latest comment 2 years ago 5 comments 4 people in discussionJust curious in the Cite xxx templates what about suffixes like Jr Sr III etc They are part of the first parameter right Thanks XComhghall talk 10 43 2 June 2021 UTC Correct I would separate with comma to disambiguate compound first names or middle anything 24 103 251 114 talk 11 20 2 June 2021 UTC Clarify cite book first FirstA FirstB Sr last Last title Title cite id CITEREFLast class citation book cs1 Last FirstA FirstB Sr i Title i cite span title ctx ver Z39 88 2004 amp rft val fmt info 3Aofi 2Ffmt 3Akev 3Amtx 3Abook amp rft genre book amp rft btitle Title amp rft aulast Last amp rft aufirst FirstA FirstB 2C Sr amp rfr id info 3Asid 2Fen wikipedia org 3AHelp talk 3ACitation Style 1 2FArchive 77 class Z3988 span span class cs1 maint citation comment code class cs1 code a href Template Cite book html title Template Cite book cite book a CS1 maint multiple names authors list link span code dd This is not a guideline just a personal pref 24 103 251 114 talk 11 31 2 June 2021 UTC I generally do not place the comma per MOS preference for no comma but yes placing it in first is correct I also do not add a comma for some future where we can detect commas in our name parameters for maintenance Izno talk 15 56 2 June 2021 UTC There is a guideline for this See MOS JR which says When the surname is shown first the suffix follows the given name as Kennedy John F Jr Also in an accompanying note we find Do not append Jr and the like to the surname Kennedy Jr John F especially in citations as this pollutes the surname metadata with extraneous information and will also alter the sorting order to after all simple Kennedy entries So first John F Jr would be correct per MOS in a cite template Jonesey95 talk 16 07 2 June 2021 UTC dd dd Having a special value for url status when a page is geo restricted Latest comment 2 years ago 8 comments 5 people in discussionThis came to my mind when I was considering citing a page from a video streaming website It had a TV show description I needed but rendered a content isn t available in your country template page until I used some VPN magic Still it is crawlable by Internet Archive with desired content shown in place so despite the fact that citing a source like this should be avoided if possible I can imagine having a thing like url status georestricted that could be used alongside with archive url Kadilov talk 12 10 2 June 2021 UTC Georestrictions may have legal ramifications that should not be gamed by archive links I suggest offering the source in a different legitimate form 50 74 165 202 talk 13 27 2 June 2021 UTC I agree after giving some more thought to this As I see it now an archiving service may be the first actor who violates something in this chain though it does not relieve others from responsibility Kadilov talk 11 55 3 June 2021 UTC dd This is a regular request Please review the archives for why it has not been implemented Izno talk 15 38 2 June 2021 UTC Thanks Now found this discussion Kadilov talk 11 55 3 June 2021 UTC dd Policy blocks are fluid and contingent For example China blocks Germany over a dispute Readers from China want URLs hosted in Germany to be archived to avoid the block Later China lifts the block and the status changes again but only for Chinese readers There is no way to say url status georestricted but only if you are located in China and only for the duration of the block This is a straightforward example they get more complicated Recommend a browser plugin that auto redirects to the Wayback version when there is a 404 or similar Avail at bottom of the page WP LINKROT GreenC 19 25 2 June 2021 UTC I don t see these examples as applying to enwiki I perhaps wrongly interpreted the OP as applying to georestrictions on enwiki users I would make sure that bypassing such restrictions through the use of an archive is not a copyvio or other legal misstep before inserting an archive url 24 103 101 218 talk 22 51 2 June 2021 UTC I think we should not use correlations between language and a country of residence here As for laws I am not a lawyer but now I think of my proposal as something that arguably encourages breaking typical Terms of Service provided by a website Kadilov talk 11 55 3 June 2021 UTC dd dd Cite lecture Latest comment 2 years ago 6 comments 3 people in discussionCurrently cite speech includes the parenthetical Speech after the title of a speech Is there a way to change this in particular to make it render as Lecture Usernameunique talk 13 51 2 June 2021 UTC No actually For some reason unknown And it s using the TitleNote meta parameter instead of the one that might make sense which is type which is how cite interview and I think cite report do it Bizarre Izno talk 15 49 2 June 2021 UTC Because a href Template Cite speech html title Template Cite speech cite speech a uses event which renders to the left of type cite speech title Title event Event type Type Title Type Event dd dd The event is not a speech At the time that cite speech migrated to Module Citation CS1 the mechanism that I adopted was a convenient solution and there had been no call to override the default annotation type if present should override the default annotation text which is a candidate for i18n in cite speech so I ll work on those things Trappist the monk talk 16 48 2 June 2021 UTC But There are these and this one so while what I have hacked in the module works cite speech new title Title type Lecture event Event Title Lecture Event dd dd it doesn t work when type is being used to indicate the type or medium of the cited source Trappist the monk talk 17 35 2 June 2021 UTC Thanks Trappist the monk Should I use cite speech new or are you still tinkering with it and cite speech Usernameunique talk 03 52 4 June 2021 UTC span data mw comment start id c Trappist the monk 2021 06 04T13 17 00 000Z Usernameunique 2021 06 04T03 52 00 000Z span a href Template Cite speech new html title Template Cite speech new cite speech new a is a sandbox so should never be used in article space As I noted above there is the issue of type Video etc that still requires resolution It may be that the very few cite speech templates that use type or medium are better served by a href Template Cite AV media html title Template Cite AV media cite AV media a For template to template consistency it may be that cite speech should be like all other cs1 2 templates that have default annotation values so that type Lecture or type Video simply overrides the default annotation These things have not been decided Trappist the monk talk 13 17 4 June 2021 UTC dd dd dd dd Script series Latest comment 2 years ago 1 comment 1 person in discussionRequesting for script series and trans series parameter the way we have script title and script chapter in Template Cite book It is only logical since if a foreign book is a part of foreign series and has its title written in script title it has its own script series parameter as well Lulusword talk 07 08 5 June 2021 UTC Whitelist Blacklist Latest comment 2 years ago 8 comments 5 people in discussionMany organizations are moving away from usage of these terms Google and Microsoft have had guidelines against it for over a decade though not requirements There are many alternatives sometimes they can be even more clear It doesn t mean our particular usage is racist it almost never is but it is systemic and potentially inflammatory Some articles about it 1 my colleague went on to impress upon me the discomfort he felt everyday living in a world where black was equated with bad disallowed and white with good allowed 2 These terms are a reminder that culture considers white good allowed and black bad disallowed As a large and globally inclusive organization we can do better with an easy change in wording GreenC 19 57 2 June 2021 UTC Until whitelist and blacklist stop being the mainstream default terms for these things we shouldn t do linguistic gymnastics to avoid them No different than white hat and black hat hackers or the myriad of other things White and Black the colors being good bad is enshrined in culture or alternatively Dark Light You have to do a huge non sequitur leap to go from villainous colour light schemes meaning good bad to mean that skin color is good bad Headbomb t c p b 21 08 2 June 2021 UTC Because the rest of the core software is changing its terms as is a large set of other software It s not exactly mental gymnastics to change Whitelist to Validargs or similar which coincidentally describes the purpose of the module Izno talk 21 57 2 June 2021 UTC I ve got no objection to renaming the module function name to ValidArgs InvalidArgs or similar if that s all that s proposed Headbomb t c p b 22 05 2 June 2021 UTC I m pretty sure that s the only use of the terms in this module set I m sure someone could control F find more Izno talk 22 21 2 June 2021 UTC dd dd dd We recently declined a similar re naming at Wikipedia talk Spam blacklist Requested move 10 February 2021 Finnusertop talk contribs 22 24 2 June 2021 UTC Not only is this topic a can of worms but it s part of a bigger can of worms Should our sensitity to left handed people cause us to refrain from using such words as gauche and sinister Should such issues be discussed in isolation or should there be a broader discussion of terms that might be construed as pejorative towards one group or another With regards to the specific issue of blacklist versus blocklist the anti spam community debated it for decades and never came to a consensus both terms are still in use RFC 5782 uses both terms Personally I favor blocklist but if a DNSBL or organization has the other in its name then changing it here would be WP OR at best Shmuel Seymour J Metz Username Chatul talk 02 47 6 June 2021 UTC The term Dark Ages has been disputed and continues to be for 100s of years Historians say don t use it but then continue to use it occasionally less so than before More in popular culture than professionally That is probably what blacklist whitelist will be a sort of indication of amateur or retrograde We can t get rid of it socially systemic but it can be disputed by those who have examined the issue It s a question of where you want your app or organization to be Some of course will embrace it to be edgy or counter but that has its own problems The easiest solution IMO is just don t use it avoid the issue if you can The neutral term is Early Middle Ages GreenC 03 24 6 June 2021 UTC dd Examples for Template Cite report Latest comment 2 years ago 3 comments 2 people in discussionHi I ve stumbled into Template Cite report and I would find it really helpful if someone could give examples of how to use the template in the template description I feel like I could use an example of a report being cited using the template and some other users might also benefit as well Best Tyrone Madera talk 16 17 5 June 2021 UTC There is an example of such just above Izno talk 17 46 5 June 2021 UTC Izno Awesome Should it be put in the template as an example Tyrone Madera talk 17 55 5 June 2021 UTC dd Issue number being ignored Latest comment 2 years ago 2 comments 2 people in discussionI have just updated some citation in the article Jerusalem District and it looks like the issue number fields are being ignored This happens with both cite report and cite web Am I using the citation wrong is this a known issue or does the template need to be fixed Thanks Ynhockey Talk 10 21 6 June 2021 UTC span data mw comment start id c Trappist the monk 2021 06 06T12 02 00 000Z Ynhockey 2021 06 06T10 21 00 000Z span issue and number are periodical parameters a href Template Cite web html title Template Cite web cite web a and a href Template Cite report html title Template Cite report cite report a are not periodical templates When I look at the two sources that use number at Jerusalem District I don t see any indication of an issue or number 71 See the table that shows which templates support issue Trappist the monk talk 12 02 6 June 2021 UTC url in name parameters Latest comment 2 years ago 13 comments 8 people in discussionWe don t allow wikilink markup or urls in lt var style padding right 1px name var gt link var style padding right 1px n var parameters We do allow wikilink markup in the name s last var style padding right 1px n var parameter but not in the name s first var style padding right 1px n var parameter I just stumbled upon this a href Template Cite web html title Template Cite web cite web a template that has a url in author So I added a test to Module Citation CS1 sandbox to catch names that have urls Cite web comparison Wikitext cite web wbr wbr access date 2014 03 01 wbr wbr author Dr http science jpl nasa gov people Benner Lance A M Benner wbr wbr date 2013 11 18 wbr wbr publisher NASA JPL Asteroid Radar Research wbr wbr title Binary and Ternary near Earth Asteroids detected by radar wbr wbr url http echo jpl nasa gov lance binary neas html Live Dr Lance A M Benner 2013 11 18 Binary and Ternary near Earth Asteroids detected by radar NASA JPL Asteroid Radar Research Retrieved 2014 03 01 a href Template Cite web html title Template Cite web cite web a External link in code class cs1 code author code help Sandbox Dr Lance A M Benner 2013 11 18 Binary and Ternary near Earth Asteroids detected by radar NASA JPL Asteroid Radar Research Retrieved 2014 03 01 a href Template Cite web html title Template Cite web cite web a External link in code class cs1 code author code help Trappist the monk talk 15 58 5 June 2021 UTC Should probably do this with most of our parameters for anything that evaluates to having a full URL that isn t meant for a URL parameter TBH Izno talk 17 45 5 June 2021 UTC Agreed but shouldn t wikilinks be similarly rationalized There are specific wikilink parameters in place and bifurcating the issue by allowing wikilinks in last for example allows waste and confusion Seem to remember prior discussion about this 2603 7000 3842 C100 D26 7E6 7C2F 18B6 talk 22 47 5 June 2021 UTC Wikilinks are allowed in last var style padding right 1px n var because those parameters are aliases of author var style padding right 1px n var Trappist the monk talk 23 22 5 June 2021 UTC Going in circles is great but this wasn t the question To rephrase why are wikilinks allowed in parameter sets that have a corresponding var style padding right 1px parameter var link option I mean apart from general inertia 64 18 9 198 talk 00 42 6 June 2021 UTC Inertia certainly but why should we prohibit wikilink markup in author var style padding right 1px n var Trappist the monk talk 11 48 6 June 2021 UTC I don t know perhaps for the same reason as this section s heading 50 75 222 254 talk 14 11 6 June 2021 UTC I see no reason to limit links whatsoever Moreover though you clearly don t mean to suggest the argument for it we should remove X link where X is not an authorship parameter The module handles stripping of brackets today and wikitext links are more wikitext and tool friendly That would appear to be title link episode link and series link Izno talk 18 48 6 June 2021 UTC dd dd dd dd dd Ok The sandbox now checks every parameter that isn t a url holding parameter url holding parameters are the parameters associated with these url holding metaparameters ArchiveURL ChapterURL ConferenceURL LayURL MapURL TranscriptURL URL and these non url holding metaparameters that are allowed to hold urls Page Pages At QuotePage QuotePages Are there any others that should be included in these lists Trappist the monk talk 16 28 6 June 2021 UTC dd Love the convoluted logic which is eventually applied as unnecessarily complicated code and inscrutable documentation There are 3 simple workable options All parameters allow links away from the citation No parameter allows links away from the citation Designated function indicative parameters such as var style padding right 1px something var link url that are link specific allow links away from the citationAnything else requires explanation But go ahead do your thing 24 103 101 218 talk 00 20 7 June 2021 UTC Yes anything else does require explanation We have a good reason to accept links in last and analogous authorship parameters duplicating the text of one parameter into another parameter simply to add a link is simply asinine which is what we would need to do to accept links for organizations We also have a good reason to accept author link we want to provide links for parameters that have been split into first and last as we would like to see for all authorship related parameters Those design considerations do not extend to any of our other parameters The reason linking is or perhaps should be allowed for internal links is that we prefer users to link to internal links if they are going to link to anything We explicitly want to avoid the actual spam and or sea of blue effects associated with external links in the other parameters or confusion by users which is already warned about as URL in website regarding the use of website There is not and never has been a requirement for all parameters to do all things or one thing only or have any consistency at all You have pointed out an inconsistency that s great but whether we take that to extend to all parameters or to limit it to no parameters is a choice we get to make between those options as well as any others we deign to consider That is actual design Presenting false trichotomies does not actually help your case in this regard For a particular prior case we have previously had the explicit discussion to limit volume and issue to some templates Not all templates have access to those parameters I do not see how that was ever the wrong choice for the templates that do not have access to one or the other of those parameters do not fundamentally need them Just because we do not treat these templates consistently does that mean we got the choice wrong Thank you for indeed helping to identify 3 parameters that do not need a link parameter any more Izno talk 01 11 7 June 2021 UTC One thing that I have seen is that many editors use cite web when a different template is appropriate Are there any cases where an editor actually needs an unsupported parameter for cite web as opposed to being able to use a more appropriate template I would rather have other templates enhanced than have enhancements to cite web that are done solely to support inappropriate use Shmuel Seymour J Metz Username Chatul talk 11 05 7 June 2021 UTC Well I know why the module is becoming more inefficient with every update no need to lay it out It is not just the inconsistency of something link being asinine while something url isn t It is not just the fact that the wikilink may have different format or text than the name s inserted in the author parameters which would necessitate further editing of the author fields by the user Neither is the fact that good software design does not allow the same parameter to be populated with different data types text or link Or the fact that parameters that are classified by data type are more understandable and better utilized by editors Also it is not because the so called internal links are technically any different they are all URLs parsable by mediawiki or conceptually different they can also be spam irrelevant or unverified nonsense just like external links Nah the reason imo for the module s increasing inefficiency is that these things have to be explained Continuously 68 173 79 202 talk 13 23 7 June 2021 UTC dd extra text that is not detected in page s Latest comment 2 years ago 1 comment 1 person in discussionThe template a href Template P html title Template P p a and it s redirect a href Template Pp html class mw redirect title Template Pp pp a when used in page s create extra text conditions that are not detected by the module I have added pattern to Module Citation CS1 Configuration that fixes that Title p p 123 a href Template Cite book html title Template Cite book cite book a page has extra text help cite book title Title page p 123 Title p p 123 a href Template Cite book html title Template Cite book cite book a page has extra text help cite book new title Title page p 123 Trappist the monk talk 13 55 10 June 2021 UTC Walls of text when editing Latest comment 2 years ago 16 comments 8 people in discussionQuite recently I ve started seeing lots of citations with all the spaces around the pipes removed for example cite web author Center for Whale Research date June 17 2018 title Southern Resident Orca Community Demographics Composition of Pods Births and Deaths since 1998 url https www orcanetwork org Main index php categories file Births 20and 20Deaths publisher Orca Network accessdate July 31 2018 This makes it hard to read and edit as a wall of text and also causes text wrapping problems I haven t seen any change promulgated in the guidelines that says to remove the spaces Could it be a bot doing it In any case could we re emphasize the standard of a space before each pipe and figure out what s driving this change Abductive reasoning 20 46 9 June 2021 UTC There are scripts that convert to A B C scripts that convert to A B C and everything in between I have a personal preferred style but that s not this discussion and no one s been willing to have a discussion about standardizing on the point at least for citations So I m not really surprised if you re noticing a trend but I doubt the trend is anything more than confirmation bias on the point Izno talk 20 50 9 June 2021 UTC The examples on the Help page that this is the talk page of all show a consistent bias towards a space before each pipe Could the guilty parties just come clean Abductive reasoning 20 54 9 June 2021 UTC I think the best way is to have a space before each pipe no spaces makes it harder to read while spaces both before and after pipes and before and after equal signs seems excessive and unnecessary However I don t know if this is worth having a potentially massive RfC where it s likely consensus won t be reached Many will probably also cite WP CREEP against the very idea of setting a standard El Millo talk 21 15 9 June 2021 UTC It doesn t seem like there is a cadre of entrenched users ignoring the longstanding consensus and demanding the wall of text I think it is a bot or bots doing it Abductive reasoning 21 25 9 June 2021 UTC ec I ve found that a space around pipes and after makes it easier to edit because then I can double click the text to change it without a space the double click selects the pipe or as well But I don t edit articles just to do that and sometimes I forget to do it in my own edits Just pointing out that the space can be useful Schazjmd talk 21 26 9 June 2021 UTC Are you sure Schazjmd Whenever I double click text next to an equal sign it only selects the text El Millo talk 21 34 9 June 2021 UTC Oh it s just my setup I figured it worked that way for everyone Now I have to try to figure out what I might have done on my computer to make it behave that way Thanks Facu el Millo Schazjmd talk 21 38 9 June 2021 UTC Different browsers on different operating systems differ in how they deal with double click It also matters whether the text area is plain old HTML or if it is spiced up with Javascript and the latter can cause variance itself There may be nothing you can do about it beside try a different browser than your normal one Izno talk 21 43 9 June 2021 UTC dd dd dd dd dd dd When I m typing citations by hand I tend to omit the spaces because that s less typing When I m converting from one parameter per line to all on one style citations if I space the pipes and equal signs the regular expression substitutions I use for this tend to also mess up long parameterized urls like the ones for Google Books so the unspaced style is safer Anyway for avoiding wall of text issues my feeling is that moving the references to the end of the article by giving them names and using the refs parameter of reflist is much more effective than any variation in how you space the parameters of the reference David Eppstein talk 21 42 9 June 2021 UTC Agreed WP LDR or WP SFN does more to deal with walls of citations Izno talk 21 45 9 June 2021 UTC dd IMHO bots that make mass changes to style absent a strong consensus are disruptive This is especially true when somebody takes the time to make his markup easy to edit and a script wipes out his work I could make a case for automatic prettyprinting but even that is laden with pitfalls Shmuel Seymour J Metz Username Chatul talk 21 49 9 June 2021 UTC Abductive and others if you think a bot is applying this style find an article with citations like this and go back through its history to find when and how the citation was inserted Histories are almost all publicly visible there is no reason to speculate If you find that a bot or script is changing the citation style address that CITEVAR issue with the bot or script operator Jonesey95 talk 23 29 9 June 2021 UTC dd I will fully admit I prefer things unspaced because in many cases it creates smaller wikitext that can fit on one line Whether I convert anything depends on what the article is already using I try to keep styles consistent if possible Sometimes though it is a hassle Long lists of author names split into first and last names can be really awkward as can particularly long URLs The worst instance is probably archive url which at least 90 I feel of the time contains the same value as url but with stuff added to the beginning Shortened footnotes and list defined references are definitely better for cleaning up clutter than spacing things out Full disclosure I use the 2017 wikitext editor on desktop computers which allows line breaks on hyphens spaces and question marks and probably some other characters The mobile version however seems line break with pipes too last I checked Could implementing this on desktops solve our problems BRAINULATOR9 TALK 13 30 10 June 2021 UTC Perhaps I m misunderstanding what you re saying but it doesn t seem like you understand the purpose of archive url The parameter is used to contain an archived version of the link so that the content is still accessible if the link is ever broken or the info is ever removed Wayback Machine the most commonly used archive just makes the links so that they contain the full url of the page being archived https web archive org web archive number original s url It s not like it s useless repeated info and it s not like there s anything we can do about it El Millo talk 17 30 10 June 2021 UTC I understand what archive url does and that it s not restricted to the Wayback Machine I m just saying it s the most prevalent instance of unfixable line break mishaps BRAINULATOR9 TALK 19 04 10 June 2021 UTC dd dd Chapter woes Latest comment 2 years ago 4 comments 4 people in discussionWhat am I doing wrong here I thought as long as work was omitted the chapter should work correctly Markup Renders as Cite web chapter url http www airvectors net avf4u 1 html m3 chapter Corsair in the Pacific War url http www airvectors net avf4u html title Vought F4U Corsair last Gobel first Greg date 1 May 2015 publisher AirVectors Gobel Greg 2015 05 01 Vought F4U Corsair AirVectors a href Template Cite web html title Template Cite web cite web a chapter ignored help Also when I change chapter to at it tells me chapter url is ignored which is not explicitly covered in the error guide Ibadibam talk 16 30 10 June 2021 UTC Webpages do not have chapters Use cite book AManWithNoPlan talk 16 48 10 June 2021 UTC Or use title and url for the individual piece you are citing and work for the larger collection of web pages it comes from David Eppstein talk 17 09 10 June 2021 UTC dd I think I would much prefer this as I do not really see this as a book citation for which chapter might apply I believe this is also what David is suggesting Markup Renders as Cite web last Gobel first Greg date 1 May 2015 url http www airvectors net avf4u 1 html m3 title Corsair In World War II website AirVectors at Corsair in the Pacific War Gobel Greg 2015 05 01 Corsair In World War II AirVectors Corsair in the Pacific War I have added the specific section callout This seems like a sufficient citation to me You do not need to identify all layers between the specific web page and any higher level works Izno talk 18 49 10 June 2021 UTC Bad value in website field Latest comment 2 years ago 7 comments 4 people in discussionI ve noticed a value entered to some cite web uses TREKNEWS NET Your daily dose of Star Trek news and opinion in an example like Cite web last Staff first TrekNews net date 2017 02 10 title REVIEW Deep Space Nine Complete Series DVD Box Set url https treknews net 2017 02 10 review star trek ds9 complete series dvd box set access date 2021 02 19 website TREKNEWS NET Your daily dose of Star Trek news and opinion language en US Should this be flagging any tracking category perhaps Gonnym talk 11 36 11 June 2021 UTC Which flag that would be The website field is badly formatted the only thing there should be www treknews net There could be some error checking to catch extraneous characters before the prefix and after the suffix I suppose Tracking category submissions must go through an RfC process now as I understand it 24 103 251 114 talk 12 20 11 June 2021 UTC Websites may be in either their URL form as in 24 s comment or a caps URL form TrekNews net or their word form Trek News so looking for spaces would not help The latter half of the title is a bit spammy but is a valid part of the name and isn t obviously unuseful in the sense that Bloomberg are you a robot is This case seems fine I do recommend doing an insource search and removing the offending half of the name Izno talk 12 26 11 June 2021 UTC The guidance and code may need to be finetuned In good practice websites are directory entries distinguishable by the prefix www Good practice not being universal practice Although there is nothing wrong with subtitles even when these are in effect marketing messages the template does not have to accept them If it makes the code tighter and more efficient in the sense of allowing for expanded error checking why not Subtitles would only be pertinent if index pages needed disambiguation and that is not a case 24 103 251 114 talk 13 05 11 June 2021 UTC How do you distinguish a subtitle for a website Izno talk 13 49 11 June 2021 UTC Anything after the suffix That is why it was suggested that the work be expected in DNS format exclusively A conditional formatting parameter could switch the display to hide the DNS artifacts per editor preference I understand that this involves a lot of work for a module that is constantly scrutinized by snowflakes so these suggestions are very tentative 65 88 88 69 talk 14 56 11 June 2021 UTC Right but DNS format is not required and I do not think it should be required for the field Izno talk 15 35 11 June 2021 UTC dd dd dd dd Protected edit request on 11 June 2021 Latest comment 2 years ago 2 comments 2 people in discussion This edit request to Template Cite map has been answered Set the answered or ans parameter to no to reactivate your request An acknowledgement and inclusion of the TemplateData newly created for Cite Map in its documentation in the same style as Cite Book BMACS1002 talk 23 57 11 June 2021 UTC Template Cite map doc is not protected There is nothing preventing you from adding TemplateData Trappist the monk talk 00 21 12 June 2021 UTC cite document Latest comment 2 years ago 2 comments 2 people in discussionThere is a template cite document which seems to have always redirected to cite journal It s got 7968 transclusion and most of these are coming up with red cs1 errors as the required parameter journal makes little sense for documents For the page I saw this on A30 road the references ref to off line sources held by the UK national archive and one user has commented on Template talk Cite document that it s used for a commencement speech While changing thee links to cite web would cure the cs1 warning this does not seem to be semantically correct but there no obvious candidate in the cite family Salix alba talk 03 02 12 June 2021 UTC There have been previous inquiries and discussions about this The main issue here is the fact that few documents are published as stand alone items and only published sources can be cited Long documents may be published as reports there are a couple of templates available Other published documents may use cite book or cite web In the particular case the document can be sourced as a location in an online publication the website for the UK National Archives Use cite web If a hard copy of the pertinent Archives volume was consulted use cite book 64 18 9 201 talk 13 11 12 June 2021 UTC Autolinking Latest comment 2 years ago 10 comments 7 people in discussionPlease autolink the title when hdl and hdl access are provided similar to how it works with a supplied doi Please add hdl as an option for title link with hdl for cite journal It would be useful if the combination of hdl hdl access and title link worked for cite report techreport or web too Thank you Whywhenwhohow talk 04 30 8 March 2021 UTC The PMC content is sometimes stale when compared with the journal article and should not be the default when a free doi or free hdl is present The existence of the paramaters doi free or hdl free should cause the doi or hdl to have priority and be used instead of the pmc for the title link Whywhenwhohow talk 23 59 8 March 2021 UTC What is the process to implement these recommendations Whywhenwhohow talk 05 27 26 March 2021 UTC For the articles you edit Add the url you want to link as the url parameter That way the logic for which thing somehow overrides which other thing can be as convoluted as you like and the rest of us don t have to try to understand or remember it David Eppstein talk 06 14 26 March 2021 UTC dd dd Yes this would be appropriate Institutional repositories hosted by academic institutions are by far the most stable and reliable link targets we have in our citations On the other hand it s not appropriate to give priority to the DOI over the PMC ID because PubMed Central is more likely to present relevant updates such as retraction notices of medical articles which often go missing on the publishers websites Legacy publishers generally lag several years behind PubMed see for instance Elsevier Nemo 18 38 25 April 2021 UTC Dearchived due to ongoing discussion Nemo 18 54 27 May 2021 UTC Ongoing discussion meaning the topic wasn t edited for a month That s a curious definition Izno talk 19 20 27 May 2021 UTC The topic was mentioned here though I was unaware of this discussion at the time Certes talk 16 51 28 May 2021 UTC Right now pmc overrides doi access free link Has any thought been put into this order AManWithNoPlan talk 22 13 24 June 2021 UTC span data mw comment start id c Trappist the monk 2021 06 24T22 33 00 000Z AManWithNoPlan 2021 06 24T22 13 00 000Z span cite journal title Title journal Journal pmc 12345 doi 10 1415 sommat doi access free title link doi Title Journal doi 10 1415 sommat PMC 12345 dd Trappist the monk talk 22 33 24 June 2021 UTC dd dd dd dd dd Thesis in italics Latest comment 2 years ago 8 comments 6 people in discussionThe guideline MOS MINORWORKS recommends quotation marks not italics for titles of theses This contrasts with the behaviour of Cite thesis wher title is italicised Which is correct As for the merits of the distinction major minor works in this regard Most PhD dissertations are quite substantial and often they are later published as books so italics makes sense My impression of masters theses is that they are more like extended essays so it s not clear to me whether they are minor or major Anyway there s a conflict between the MOS and the tamplate s behaviour I raised the same question at Wikipedia talk Manual of Style Titles Thesis in italics Michael Bednarek talk 01 44 18 June 2021 UTC Generally works published as stand alone items are in italics and items that are parts of published works are quoted Since the CS1 citation templates are named per stand alone source this template would only be suitable for theses published as stand alone items I would imagine this to be a fairly small number 74 64 150 19 talk 11 56 18 June 2021 UTC History From its creation in 2009 until this edit in 2011 title rendered upright without quotation marks After that edit title renders in italic Trappist the monk talk 12 45 18 June 2021 UTC I don t understand 74 64 150 19 s response Every thesis is a stand alone work isn t it Regarding history maybe User Headbomb can provide guidance whether the advice in MOS MINORWORKS should be removed Michael Bednarek talk 13 05 18 June 2021 UTC I m not sure why I m pinged here or what the question is but thesis are major works and their titles should be italicized I believe this is the current behaviour of the templates Headbomb t c p b 13 31 18 June 2021 UTC Michael Bednarek thanks for posting this I have responded over at the MOS page with some detective work In short I believe that the guidance was added to the minor works list in error and without discussion in 2019 and that it contradicts both our long standing practice and some style guides MOS should be modified not cite thesis Jonesey95 talk 16 04 18 June 2021 UTC dd Michael Bednarek for the purposes of citations stand alone would mean works published as themselves and not as part of a larger work or of a collection An article essay published as a pamphlet is a stand alone work indexed as such and found as a discrete item Its title should be italicised The same piece published in a magazine or journal is a location in a stand alone work and its title should be in quotation marks as it is in fact text quoted from the source 65 88 88 69 talk 19 42 18 June 2021 UTC I ve now adjusted MOS TITLE Michael Bednarek talk 01 29 19 June 2021 UTC dd dd dd Journal volume in Bold Latest comment 2 years ago 10 comments 6 people in discussionThe volume parameter is showing up in bold in the journal citation It is quite jarring as it stands out among all the other parameters and I thought it s a bug The documentation said it can be in bold but did not say why the bold is required On going through the archives I found similar concerns 1 2 3 and on how to workaround the bold and requests and proposals to handle or eliminate the bold completely I accordingly modified Iridium Communications so the bold is avoided In Template Citation Style documentation volume I added a mention of why the bold is done from one of the conversations From the proposals in Archive 62 Bolding of the volume number I vote for Proposal 2 vol 3 pp 12 56 so the reader understands what the 3 stands for plus it is not in bold Jay Talk 13 40 20 June 2021 UTC I m inclined to revert your change to Iridium Communications because that change causes Module Citation CS1 to emit a volume has extra text error message which see I am also inclined to revert your changes to Template Citation Style documentation volume unless you can name the international standard that lays out the expected styling for journals What is the name of this international standard Trappist the monk talk 14 02 20 June 2021 UTC Citation bot already reverted my workaround and I can take that up at the bot s page On the international standard I got that from Archive 4 Bold non bold volume parameter doc issue or bug where user Gadget850 said Volume values that are wholly digits wholly uppercase Roman numerals or less than five characters will appear in bold as per the international standard that lays out the expected styling for journals Any non numeric value of five or more characters will be presumed to follow some other convention and will not appear in bold Jay Talk 06 35 21 June 2021 UTC An editor saying something in a general comment on a talk page doesn t necessarily make it true This obviously isn t article space so not quite WP V level but I would agree with Trappist that we shouldn t call something an international standard in the documentation unless we can justify that with some reliable source saying so On the original question I ve grown quite used to the bold volume numbers I don t find them particularly jarring but I do think it s important to justify why we re doing it that way and to be confident that readers will be able to interpret that layout without hitting the edit button and looking at the template parameters Amakuru talk 07 16 21 June 2021 UTC I m used to the bold volume numbers as that is common in the scientific literature e g Nature and Science both use bold volume numbers But while I d expect the bolding for scientific journals I find the bolding jarring with books where I d expect Volume 2 rather than 2 for books I think it would be better if cite journal and cite book handled volumes differently There is the option of using Volume Volume 2 to suppress the hidden error message but this seems an unnecessary extra step Jts1882 talk 08 31 21 June 2021 UTC For Nature and Science that use bold volumes there are also plenty that don t any more never have e g BMJ Cell PLOS BMC by User Evolution and evolvability What looks normal on printed pages may not look so on web pages Especially on a wikipedia page where nothing but the first mention of the subject is allowed to be in bold Jay Talk 15 07 21 June 2021 UTC I just said I was used to seeing the bolding in the scientific literature I gave Nature and Science as examples as they are well known and more geared to a general audience My unscientific survey of journals I read and publish in suggests a majority use bold e g PNAS J Physiol J Biol Chem Cell and Neuron Cell Press don t use bold but use italics to provide emphasis to the journal number The BMC journals were on my bold list but it looks like they now don t bold the number now which may or may not be an indication of the modern trend For journals that show issue numbers in parenthesis none that I looked at used bold although Cell Press used them in normal text following an italicised journal number I don t feel too strongly about bolding the journal number as many journals don t but find the emphasis useful What I don t think is correct is the bolding of book volume numbers or flagging the text volume as an error which result in people deleting volume titles and just leaving the number In my brief survey the journals that bold the journal number don t bold the book volume number and use Volume 2 or Vol 1 although finding examples for this is difficult Jts1882 talk 16 15 21 June 2021 UTC dd dd I agree it doesn t make it true I cited the user and his quote to provide context the best I could get because in the discussions I m seeing in the archives the typical explanation for something being a particular way is because this was discussed and agreed by the editors on Wikipedia years ago with no other context What I gave is a lead so someone who was part of the discussions can pitch in with the unnamed standard since the quoted user is now inactive A quote from another archive Archive 8 Add a volume b parameter that skips the four chr test for bolding where user J Johnson another inactive user says Volume numbers which are especially significant for serials and journals are often overlooked on account of being so short wherefore they are commonly bolded so they are more readily seen in long citations Now this is a usability explanation that can be given in the doc and this would suffice for the time being It answers the question why are volumes bolded but not Is it the right thing to do Jay Talk 14 31 21 June 2021 UTC It is not a good idea to make assumptions based on what one is used to or by looking at other citation systems This is a general purpose encyclopedia geared towards non experts There are no prior examples of citation systems addressing such an audience All existing citation systems are geared to experts sometimes in very narrow fields Very rough guidelines is the most such systems can provide The present citation system must be more than anything simple understandable and consistent And also coherent given the expected level of reader expertise zero The volume parameter is one of the places where the system fails but not for the reasoning you outlined imo It is inconsistently presented sometimes bold sometimes not and arbitrarily so why bold if less than X rather than Y characters It would make sense to emphasize the parameter by using bold weight in cases of multi part sources the parameter is instrumental in locating the verifying info and its presentation should attract the reader s attention But this may be secondary to consistency Whatever is decided should apply uniformly wherever this parameter is used in system This is easier for both non expert readers and non expert editors Certainly easier than following arcane trade practices per citation template or following whatever foreign citation system suits one s particular preferences If memory serves I believe I first made a similar comment in some Wikipedia page almost 20 years ago Likely I will be repeating this 20 years from now if I m still around Something to do I guess 66 65 114 61 talk 14 37 21 June 2021 UTC dd dd dd dd The most recent discussion on this topic is at Help talk Citation Style 1 Archive 75 Obtuse template style you ll see I started a draft RFC and posted for some feedback there which I took somewhat but no one followed up after my last comment there Happy to hear more just not sure I ll take more As for comments above about standard not standard the couple of ISO standards out there seem to favor the written out vol without bolding but I could swear that I had seen at least one ISO citation with bolding parens along the lines of the couple major journals already mentioned Izno talk 20 26 22 June 2021 UTC script chapter and aliases without chapter or aliases not recognized in cite encyclopedia Latest comment 2 years ago 1 comment 1 person in discussionCite encyclopedia comparison Wikitext cite encyclopedia wbr wbr encyclopedia Encyclopedia wbr wbr script entry zh Entry Live Entry Encyclopedia Sandbox Entry Encyclopedia fixed Trappist the monk talk 11 39 26 June 2021 UTC Old parameter coauthors Latest comment 2 years ago 2 comments 2 people in discussionThe citation templates supported the coauthors parameter before lua modules were introduced Does anybody here remember how the references with that parameter were treated when en wiki switched to lua modules Were they removed from template calls in the articles there are very few remaining see insource coauthors I need this for another wiki Many thanks Ponor talk 01 14 30 June 2021 UTC They were supported by the Lua modules for a while and then we deprecated coauthors and converted them all to author1 etc or last first pairs Jonesey95 talk 03 04 30 June 2021 UTC DOI and or URL for cite SSRN to support PlumX Altmetric Latest comment 2 years ago 3 comments 3 people in discussionAnyone here familiar with PlumX Altmetric and how they pull data from Wikipedia references Should we add the ability to specify a DOI and or a URL for cite ssrn Wikiscienceguru wrote on my talk page about a change they made using cite journal with a DOI and a URL instead of using cite ssrn for a paper from SSRN So the important change I made is to include the DOI If this is not done metrics tools like PlumX and Altmetric do not find the reference in Wikipedia which prevents people from finding wikipedia articles that reference a given article While SSRN is technically not a journal it does have what it calls eJournals which include content based on editorial staff selection criteria The referenced article is in an eJournal But again most importantly the DOI must appear in the reference not as a link to be captured by PlumX and Altmetric References by PlumX and Altmetric steer traffic to wikipedia via those references SSRN functions as a Journal so perhaps it s best to use that citation style Somehow the DOI must appear in the reference as directly visible text not hidden within a link Whywhenwhohow talk 03 46 7 July 2021 UTC That s nice but that has 0 bearing on how we make citations Wikiscienceguru those platforms should fix their software We should not use a specific template to make them happy Izno talk 04 12 7 July 2021 UTC cite ssrn is kind of a special purpose template If the issue is that it does not support doi you could use e g cite web which does support doi and ssrn However according to 3 at least Altmetric also retrieves SSRNs from citations so adding DOIs should not be necessary in the first place In general if their harvesters don t recognize some identifiers in the visible text of a citation they should be improved to also read the invisible COinS metadata as it is provided by all CS1 CS2 citation templates in Wikipedia and various other places Thereby they could reliably retrieve SSRNs DOIs and many other identifiers via the rft id key see also Module talk Citation CS1 COinS Matthiaspaul talk 14 34 7 July 2021 UTC access date query Latest comment 2 years ago 19 comments 10 people in discussionHi allIf I have a citation with a dead URL for which an archived version has been added e g through an archive org link should the access date parameter represent the date on which the actual original URL was last verified to be online and accurate or should it be the date on which the archived version was last retrieved Cheers Amakuru talk 08 44 5 July 2021 UTC In this case I would not use the access date parameter at all but if you prefer it should be set to the date the archived snapshot was created Matthiaspaul talk 10 40 5 July 2021 UTC Well we already have archive date to cover that so I m not sure it would be particularly helpful to use that date I guess the question is whether the archiving site will ever go down or somehow change the way the source looks If not then as you say perhaps omitting it altogether similar to a GBooks link would be best Personally I ve always just used the date I looked at the archive site myself but I just wondered this mornign if that was really correct Amakuru talk 10 45 5 July 2021 UTC Just for clarification My above comment addresses the scenario of adding access date at a time when the original site is already dead and where an access date newer than the archive date implies that the archived contents was still live at that date something that does not necessarily hold true and that except for in very rare cases cannot be determined retroactively any more Like Trappist below I do not suggest to remove an already existing access date parameter because when that parameter was applied at a time when the original site was still alive the date provides valuable information for verification purposes and to possibly find the most suitable replacement link Matthiaspaul talk 15 54 5 July 2021 UTC dd span data mw comment start id c Trappist the monk 2021 07 05T11 09 00 000Z Amakuru 2021 07 05T08 44 00 000Z span access date applies to url When url has died do not delete or modify access date unless you replace url with a url that links to the same source because that source revised how they structure their online presence We hope that the date in access date reflects the date that a human editor confirmed that the source addressed by url supported our article alas there are tools out there that automatically add today s date to access date when they cleanup bare url references today We need to know the correct access date so that when url goes 404 we can find an archived snapshot from on or near that date Trappist the monk talk 11 09 5 July 2021 UTC First if I may suggest don t think as an editor and think as the consumer the reader What serves the reader is a live url and an indication of the date that url was accessed When a previously live link has died for whatever reason and there is an archive the live url that verifies the source is the archived one If you can access that you should say it with the date you did so The url status will auto format the current live link but the editor must update the parameter access date by hand The parameter that indicates the snapshot date is a different parameter archive date and has a different purpose 64 18 9 201 talk 12 17 5 July 2021 UTC Yes I think this matches what I would expect as a reader too Note the way such a citation renders Wikipedia the free encyclopedia Wikimedia Foundation Inc Archived from the original on 2021 02 06 Retrieved 2021 07 05 As a reader I would expect that Retrieved 5 July 2021 to refer to the actual link of the source as I m verifying it which in this case is the archived copy Saying the access date refers to the url may make sense from the point of view of this template but IMHO what s important is the rendered text and what it implies Cheers Amakuru talk 12 37 5 July 2021 UTC Hm I don t think it is a good idea to retroactively add an access date to specify the date an archived snapshot was accessed once the actual url has died The archive date already implies that the original site was accessed by the archiver on that date At most access date could be set to the same date as archive date An access date newer than an archive date implies that the actual site was still alive at the given moment in time and its contents still supported the statement Except for in very rare cases we do not know if this holds true or not therefore we should not make such statements It would be possible that the contents of the site changed in unsuitable ways no longer supporting the statement prior to going dead If in this case access date would be given as the date when the older archive was accessed it would lead to the assumption that the original site supported the statement up until it died and not only up until the archived snapshot was taken To distinguish between these cases we would need to known when a site went dead and see if the access date is older or newer than this date but we do not normally have this information Matthiaspaul talk 15 54 5 July 2021 UTC No Nobody is adding an access date retroactively The opposite is happening the date the source is accessed is added concurrently It does not matter at all to the reader if that source was an original or an archive although it is good practice to indicate so as is currently happening It is wrong to leave a stale date as access date It is a false statement because the pertinent new live link is not accessed on that date The archive date is indicating the snapshot and is important when the original changes since it is part of a revision history By definition the snapshot used verifies the wikitext exactly like the contemporary original So if the archive is going to be used instead the date it is accessed should be indicated 68 173 76 118 talk 20 15 5 July 2021 UTC dd dd dd My preference is to remove the access date when I discover a url to be dead and replace it with an archived url because the version of the source at the old access date is no longer verifiable and we need to go by the archived version instead There is no point in also adding an access date because archived versions do not change so the date that I found it in the archive is not useful information to readers Adding an archive to a still live url is not something I usually do but if you are doing that then the access date can remain as a record of when the content at the live url was verified David Eppstein talk 20 34 5 July 2021 UTC Not all archives are stable Services such as WebCite may remove archived material especially if there are multiple archives of the same source I have experience of Wayback Machine archive URLs that have changed affecting the entire snapshot chain I agree that known stable well managed archives that become the live URL would not need an access date and therefore the parameter could be removed in such cases In the other cases the live URL whether original or archive should have a corresponding contemporaneous access date 68 173 76 118 talk 21 15 5 July 2021 UTC The point is that if you link to a version with an archive date the date of that version will never change It is stable in the sense of being a fixed snapshot regardless of whether it might someday become a deadlink So having an access date to tell you which version of a changing web page was used is pointless for an archived page David Eppstein talk 21 35 5 July 2021 UTC There s a misunderstanding I believe The archive date identifies the snapshot as you state The access date identifies the date that snapshot was accessed as the then live URL In the case of non stable archives I think that link info is as pertinent as any other link info Some time ago I inserted a citation whose source the live URL was a newspaper archive curated by the newspaper itself So this is an authoritative archive Recently following a change in publishers the entire archive was repositioned as a subdomain of the publisher s subscription services I became aware of the change months later and edited the citation I believe that in the meantime the info regarding the link s known accessible date added value for readers wishing to find the source It could be a starting point to discover where the source went With rapid developments in the publishing industry this may not be an unusual incident 74 85 112 198 talk 23 47 5 July 2021 UTC I do not see the relevance of telling readers the date that snapshot was accessed as you put it It provides no useful information to readers David Eppstein talk 01 10 6 July 2021 UTC span data mw comment start id c Izno 2021 07 06T01 27 00 000Z 74 85 112 198 2021 07 05T23 47 00 000Z span access date is for url not for archive url Period Izno talk 01 27 6 July 2021 UTC You are only partially correct The access date refers to the live URL neither the original nor the archived one Any URL may need an access date if there is a good possibility it will not be stable regardless of provenance If the documentation says otherwise it should be fixed to line up with common sense so that editors don t come here with such questions not the editor s fault And verifying readers won t have to be entangled with yet another wrong false date statement 65 88 88 200 talk 20 31 7 July 2021 UTC No it is specifically for url Your opinion is simply wrong Izno talk 00 55 8 July 2021 UTC Simply wrong according to whom These templates exist first and foremost to make it easy for editors to produce reader friendly citations in a standard format And as such as I said above the crucial point is that what the access date parameter produces is a snippet of text saying Retrieved 8 July 2021 The question we need to ask ourselves is therefore not does that date refer to the URL parameter but rather what will the reader interpret that date to mean In that regard I think the IP is right the reader will logically assume that it refers to the primary URL associated with the citation which in the Case of a dead link is the archived version If I m wrong about that interpretation then say but please don t argue it on the basis of what the parameter was intended to mean because that is a not what matters to our readers and b not documented in any case so still subject to opinions It may or may not be best to remove the date altogether at the time of switching to an archived version but I don t think we should pretend it still refers to when the original URL was accessed Amakuru talk 14 00 8 July 2021 UTC dd dd dd dd dd dd dd As stated Izno is partially correct in a very narrow technical sense regarding module argument dependencies That is not relevant to editors or readers I suspect what they want to see is rational real world equivalents without the low level mumbo jumbo Technical mumbo jumbo example 1 url status var style padding right 1px live var cite web title Title website Website url http original url com archive url http archive url com archive date 2020 01 11 access date 2021 01 11 url status live renders cite class citation web cs1 Title i Website i Archived from the original on 2020 01 11 span class reference accessdate Retrieved span class nowrap 2021 01 11 span span cite span title ctx ver Z39 88 2004 amp rft val fmt info 3Aofi 2Ffmt 3Akev 3Amtx 3Ajournal amp rft genre unknown amp rft jtitle Website amp rft atitle Title amp rft id http 3A 2F 2Foriginal url com amp rfr id info 3Asid 2Fen wikipedia org 3AHelp talk 3ACitation Style 1 2FArchive 77 class Z3988 span with html exposed UNIQ templatestyles 00000054 QINU span class p lt span span class nt cite span span class na class span span class o span span class s citation web cs1 span span class p gt span http original url com Title Website http archive url com Archived from the original on 2020 01 11 span class p lt span span class nt span span span class na class span span class o span span class s reference accessdate span span class p gt span Retrieved span class p lt span span class nt span span span class na class span span class o span span class s nowrap span span class p gt span 2021 01 11 span class p lt span span class nt span span span class p gt lt span span class nt span span span class p gt span span class p lt span span class nt cite span span class p gt lt span span class nt span span span class na title span span class o span span class s ctx ver Z39 88 2004 amp rft val fmt info 3Aofi 2Ffmt 3Akev 3Amtx 3Ajournal amp rft genre unknown amp rft jtitle Website amp rft atitle Title amp rft id http 3A 2F 2Foriginal url com amp rfr id info 3Asid 2Fen wikipedia org 3AHelp talk 3ACitation Style 1 2FArchive 77 span span class na class span span class o span span class s Z3988 span span class p gt lt span span class nt span span span class p gt span Notice that the live title URL in rendered html is the original URL dd Technical mumbo jumbo example 2 url status var style padding right 1px dead var default cite web title Title website Website url http original url com archive url http archive url com archive date 2020 01 11 access date 2021 01 11 renders cite class citation web cs1 Title i Website i Archived from the original on 2020 01 11 span class reference accessdate Retrieved span class nowrap 2021 01 11 span span cite span title ctx ver Z39 88 2004 amp rft val fmt info 3Aofi 2Ffmt 3Akev 3Amtx 3Ajournal amp rft genre unknown amp rft jtitle Website amp rft atitle Title amp rft id http 3A 2F 2Foriginal url com amp rfr id info 3Asid 2Fen wikipedia org 3AHelp talk 3ACitation Style 1 2FArchive 77 class Z3988 span with html exposed UNIQ templatestyles 00000058 QINU span class p lt span span class nt cite span span class na class span span class o span span class s citation web cs1 span span class p gt span http archive url com Title Website Archived from http original url com the original on 2020 01 11 span class p lt span span class nt span span span class na class span span class o span span class s reference accessdate span span class p gt span Retrieved span class p lt span span class nt span span span class na class span span class o span span class s nowrap span span class p gt span 2021 01 11 span class p lt span span class nt span span span class p gt lt span span class nt span span span class p gt span span class p lt span span class nt cite span span class p gt lt span span class nt span span span class na title span span class o span span class s ctx ver Z39 88 2004 amp rft val fmt info 3Aofi 2Ffmt 3Akev 3Amtx 3Ajournal amp rft genre unknown amp rft jtitle Website amp rft atitle Title amp rft id http 3A 2F 2Foriginal url com amp rfr id info 3Asid 2Fen wikipedia org 3AHelp talk 3ACitation Style 1 2FArchive 77 span span class na class span span class o span span class s Z3988 span span class p gt lt span span class nt span span span class p gt span Notice that the live title URL in rendered html is the archived URL The access date of the live link is either superfluous if a stable archive or wrong it refers to obsolete access of now dead link The documentation compounds the error The low level coding produces it by generically tying access date to url without any contingencies dd 65 88 88 76 talk 19 01 8 July 2021 UTC Bogus names Latest comment 2 years ago 4 comments 3 people in discussionFollowing up on Help talk Citation Style 1 Archive 76 junk author names where we added a facility to detect bogus names in citations I saw that Trappist fixed the bogus name Verfasser in some 30 citations recently Even though Verfasser is a German word meaning author editor I consider the number high enough to no longer see this as an unsystematic error requiring manual detection and fixing I have therefore added Verfasser to the list of names the template checks for so that it cannot be added to citations any more without generating an error Verfasser Troumbis Andreas Y Declining Google Trends of public interest in biodiversity semantics statistics or traceability of changing priorities OCLC 1188566404 a href Template Cite book html title Template Cite book cite book a last has generic name help CS1 maint multiple names authors list link Troumbis Andreas Y Declining Google Trends of public interest in biodiversity semantics statistics or traceability of changing priorities OCLC 1188566404 Matthiaspaul talk 11 54 11 July 2021 UTC Matthiaspaul I have a bot task for this see BattyBot s contributions with an edit summary of Removed fixed incorrect author parameter s I have more patterns to share if you re interested Is there a maintenance category associated with this error GoingBatty talk 18 09 11 July 2021 UTC Articles with names that satisfy the generic name test name is generic will be categorized in Category CS1 errors generic name There are four sort of related maintenance categories Category CS1 maint numeric names authors list Category CS1 maint numeric names editors list Category CS1 maint extra text authors list and Category CS1 maint extra text editors list Trappist the monk talk 18 53 11 July 2021 UTC Sure if you know more such patterns they can be considered for inclusion as well Matthiaspaul talk 20 48 14 July 2021 UTC dd The parent page Latest comment 2 years ago 1 comment 1 person in discussion1 The volume parameter is not correctly explained The text should be amended to account for the current schizophrenic presentation 2 In External links Online sources it is stated that reviews of the work should not be linked Practically any art literature related article is suspect if that is the case 3 The parameter subject is not explained described anywhere 66 108 237 246 talk 13 48 14 July 2021 UTC Proposal default to display authors 6 Latest comment 2 years ago 7 comments 5 people in discussionEdits that add references with long lists of authors are quite common leading to references with very long lists of author names For journals and books it seems to be common practice to limit this list to 6 4 or 3 authors Likewise display editors 3 is quite common So instead of always having to do this kind of maintenance manually every time I d like to propose that the citation templates default to display authors 6 and maybe display editors 3 then Wikipedians only have to set these parameters when necessary Fernando Trebien talk 17 11 19 June 2021 UTC I believe that this limit was in place for a long time at first for technical reasons IIRC but consensus here was that the artificial limit should be removed and left up to editors If you dig a bit through this page s archives you can probably find relevant discussions Edited to add here is a discussion from 2014 talking about the old functionality Jonesey95 talk 17 20 19 June 2021 UTC Yes as Jonesey notes the count that you find regarding 6 particularly was first a requirement of the templates before Lua which could not process many more authors than that This requirement made its way into the tools of the time that were used e g Refill and others 9 is the other number you will see I am not a fan of adding a limit here Individual page authors can sort out how many authors they want Izno talk 17 44 19 June 2021 UTC Jonesey95 Izno Just for clarity I m not proposing a hard limit just a default value What happens is that many authors are careless about conciseness in citations So an attentive author could still override the proposed default by setting display authors 0 or any other value they see fit I also believe that many experienced authors would find these defaults good enough in most cases so they wouldn t feel they have to set them differently which saves work Fernando Trebien talk 18 40 19 June 2021 UTC If you set a limit then in practice it will become a hard limit in most cases If you think that the number needs limiting in some particular article then why not set it in that particular article rather than pushing your preference to all articles where the editors have not already expressed a preference and forcing all editors of articles with many author references to come to consensus on how many is appropriate for that article It s perhaps worth mentioning in relation to this that lately within academia I ve seen a push for avoiding et al abbreviation of authors especially in fields where authors are traditionally alphabetical see for example the STOC 2021 call for papers as it can be unfair to alphabetically disadvantaged researchers to never have their names mentioned David Eppstein talk 18 57 19 June 2021 UTC Makes sense There should be an easier way to handle this perhaps adding a parameter like alpha y to indicate that the citation system is alphabetic which would set display authors 0 by default So of course we would need a crawler to look for citations of articles from specific journals that adopt this practice to add alpha y to them In any case I ve seen citations containing more than 50 authors it seems problematic to simply allow them to be so extensive from the start Fernando Trebien talk 14 00 20 June 2021 UTC I consider this to be searching for a solution to a problem that does not exist The majority of sources do not include many contributors and in the few cases where dozens or even hundreds of authors could actually become problematic per WP NOTPAPER I don t think it does unless there would be many such references on a single page the number of authors to be displayed can be controlled by the display authors parameter The simple solution you are looking for is to not implement any limit and choose a suitable display authors limit only where it is actually necessary Any static default hardcoded into the template would be arbitrary and may give unfair advantage to some contributors which we as an encyclopedia should all treat the same or even violate our policy on neutrality WP NPOV Different publishing houses have different strategies to list authors some do not sort them at all some sort them by relevance to the work by their amount of contribution by chronology of their contributions by alphabet by affiliation by their reputation by their function by their age or by other criteria and within each group the entries might be listed in ascending or decreasing order only the contributors and the publisher know Any static default limit would be off in most of the cases therefore we should not even try and introduce any such technically unnecessary limits to citation templates Matthiaspaul talk 11 30 11 July 2021 UTC dd dd dd edited and translated Latest comment 2 years ago 13 comments 5 people in discussionThere are fields for editor and for translator but these are often the same person and it looks awkward showing them in two different fields Is there a way of showing Smith Joe ed and trans Dudley Miles talk 18 24 26 June 2021 UTC I suspect that there is little need to duplicate a name in the case that you have mentioned Remember the purpose of a citation is to help readers locate the source that you consulted when writing the en wiki article In cs1 2 templates you can probably just write editor last Smith editor first Joe and that will be sufficient There are cases I just did one where an author is also an editor so for that I wrote cite book first Kevin J last Cathcart chapter The Curses in Old Aramaic Inscriptions title Targumic and Cognate Studies Essays in Honour of Martin McNamara editor Cathcart editor2 Michael Maher year 1996 Cathcart Kevin J 1996 The Curses in Old Aramaic Inscriptions In Cathcart Michael Maher eds Targumic and Cognate Studies Essays in Honour of Martin McNamara dd dd In this case it is important to state the chapter author and to name the editors of the edited collection If you believe that it is important to separately name the translator then translator Smith should suffice assuming that there is only one Smith in the citation Trappist the monk talk 18 56 26 June 2021 UTC I am thinking of a different case an edition of a medieval work in Latin Some editions are just the work in Latin others also have a translation and it would be very helpful for readers to know whether the edition includes a translation I have cited Greenaway Diana ed 1996 Henry Archdeacon of Huntingdon Historia AnglorumThe History of the English People Oxford UK Clarendon Press ISBN 978 0 19 822224 8 I did not add the trans field as I thought it would look odd but I think a field for ed and trans would give the reader very useful additional information Dudley Miles talk 20 23 26 June 2021 UTC I would use the language parameter inserting both languages either by code or literal And I would also use the translator parameter per Trappist The parameter you suggest is probably too specialized to be considered cite book title Title trans title Translated title editor Editor translator Editor language latin en renders cite id CITEREFEditor class citation book cs1 cs1 prop foreign lang source Editor ed i Title i i Translated title i in Latin and English Translated by Editor cite span title ctx ver Z39 88 2004 amp rft val fmt info 3Aofi 2Ffmt 3Akev 3Amtx 3Abook amp rft genre book amp rft btitle Title amp rfr id info 3Asid 2Fen wikipedia org 3AHelp talk 3ACitation Style 1 2FArchive 77 class Z3988 span span class cs1 visible error citation comment code class cs1 code a href Template Cite book html title Template Cite book cite book a span editor has generic name help code dd dd 98 0 246 242 talk 20 38 26 June 2021 UTC Thanks for your help I have added language latin en It looks a bit odd to me but at least it conveys the information I still think the standard method used in academic citation of showing ed and trans is better It is very common not specialized Dudley Miles talk 20 58 26 June 2021 UTC Common but complicates the citation module somewhat painfully especially if there are multiple editors translators who are not both of the two Izno talk 21 10 26 June 2021 UTC There is no simple solution with multiple editors translators but the addition of fields editortrans first and editortrans last would cover most eventualities without causing complications Dudley Miles talk 21 26 26 June 2021 UTC And still adds complexity contrary to your suggestion The simple solution as suggested above works today at some cost of repetition I would not support a change here Izno talk 21 58 26 June 2021 UTC So are you proposing Greenaway Diana ed 1996 Henry Archdeacon of Huntingdon Historia AnglorumThe History of the English People Translated by Greenaway Diana Oxford UK Clarendon Press ISBN 978 0 19 822224 8 This seems absurdly clumsy compared with a simple trans and ed field Dudley Miles talk 22 34 26 June 2021 UTC shrug Circles at that point Izno talk 22 54 26 June 2021 UTC dd dd I too think dedicated parameters for editors who are also translators would be overkill and open a can of worms What about contributors who are authors and translators rather than editors and translators What about those who are authors and editors Or authors editors and translators combined Not to mention that there are more roles than authors editors and translators alone We obviously can t have dedicated parameters for all these combinations This would complicate the user interface too much If anything this would have to be something that the template would have to figure out by itself based on the usage of the existing parameters What I can envision for somewhen in the distant future is added support for some symbolic arguments which would allow someone to refer to another already given name in order to not have to repeat that name again in order to reduce the risk for typos and also to define relations At a yet later stage the template could then internally group the roles for display purposes This could look like editor first1 i First1 i editor last1 i Last1 i editor first2 i First2 i editor last2 i Last2 i translator1 editor1 But in the current implementation this would add significant overhead and there are more important things to be added first Therefore I would suggest to just add the names according to their roles using the existing parameters regardless of the mild clumsiness and repetition it causes Matthiaspaul talk 16 56 4 July 2021 UTC dd dd dd dd dd Isn t Henry of Huntingdon the author so shouldn t the citation read cite book author Henry of Huntingdon editor first Diana editor last Greenaway translator Greenaway title Historia Anglorum The History of the English People publisher Clarendon Press location Oxford UK year 1996 isbn 978 0 19 822224 8 Henry of Huntingdon 1996 Greenaway Diana ed Historia Anglorum The History of the English People Translated by Greenaway Oxford UK Clarendon Press ISBN 978 0 19 822224 8 dd dd Probably should have orig date Trappist the monk talk 22 51 26 June 2021 UTC dd dd Regarding commonality I doubt that the combination editor translator is a good example Out of the entire universe of published works relatively few list an editor Fewer may list both an editor and a translator I believe a substantially smaller subset of the last category would have the same person as editor and translator That I think applies also in the much smaller universe of academic works There is also the issue of utility What is the marginal advantage that extra parameters add in order to find the cited source If a work has an editor it is likely that it has been classified in main index or subindex by editor or also by editor I can see how adding the additional info editor can speed up discovery If the work has been edited by different editors in different editions then editor is necessary I don t see equal utility by adding a translator because usually bibliographic reference databases rarely provide translator index results even for translated works unless perhaps one digs deep into the reference record The marginal advantage the translator parameter adds in finding the source is more apparent when a certain work has different translators in different editions with the same editor If a different edition has different editor or editor translator see the comments on editors in this post In any case I always provide the translator in the outside case there exist editions with different translators 98 0 246 242 talk 00 32 27 June 2021 UTC dd dd Auto generated URL question Latest comment 2 years ago 6 comments 4 people in discussion span data mw comment start id c GreenC 2021 07 15T16 01 00 000Z Auto generated URL question span a href Template Cite journal html title Template Cite journal cite journal a will auto generate a URL in the url field under some conditions eg when doi access free and url is otherwise empty My question is do other templates auto generate url The conditions are not important only knowledge of which templates are capable of auto generating URLs in the url field for whatever reason Is it possible a href Template Cite magazine html title Template Cite magazine cite magazine a can auto generate a URL Or any of the other CS1 2 templates GreenC 16 01 15 July 2021 UTC No Only a href Template Cite journal html title Template Cite journal cite journal a supports this because the identifiers that are the source for the url currently pmc and doi typically apply to journal articles It has been suggested that doi with doi access free might be applied to chapters of books or entries in encyclopedia So far as I know there has been no effort undertaken to accomplish this or to even determine if we should support chapter entry autolinking from doi I think that there has also been a suggestion to autolink title in a href Template Cite book html title Template Cite book cite book a from hdl but again just the suggestion Trappist the monk talk 16 12 15 July 2021 UTC Ok thanks GreenC 16 26 15 July 2021 UTC There have been multiple requests to extend support for auto linking beyond pmc and doi I remember specific requests for hdl jstor pmid and s2cid as well as requests to support auto linking for all identifiers In addition to this there have been requests to allow auto linking in all CS1 CS2 templates instead of in cite journal only While I was not a fan of auto linking in general I can accept it for as long as there is a way to override or disable the automatic selection as is meanwhile implemented through title link none pmc doi i link i I would also support adding this feature to all citation templates and to extend support to all identifiers under one restriction For new identifiers we should not support automatic selection because it would be impossible to come up with a reasonable list of priorities for automatic selection when more than a few identifiers are involved However if the feature requires manual selection via title link i identifier i it cannot cause harm Eliminating exceptions and being able to use more generic table driven code rather than hardcoded special cases will help to simplify the code and documentation and therefore will make the templates easier to use and maintain Regarding autolinking support for chapters this was requested several times as well In fact I even started implementing it in the sandbox in 2020 by adding chapter doi and title doi parameters as more specific aliases to doi but this was removed again Matthiaspaul talk 20 54 15 July 2021 UTC All free versions of record identifiers not all identifiers PMID for instance will never link to a version of record arxiv is likewise not a version of record although it could certainly autolink in cite arxiv Headbomb t c p b 21 17 15 July 2021 UTC Regarding free this should probably use the same mechanism as with doi and doi access free see Help Citation Style 1 Access indicator for named identifiers Regarding version of record vs arxiv this could be controlled by a flag in the identifier table but supporting an identifier in specific templates only could complicate things again rather than simplify them For as long as only manually selected auto linking would be implemented for the other identifiers as suggested by me above the auto linking would always be the result of an editor s conscious decision so perhaps the extra complexity to prevent certain combinations would not be needed those which do not make much sense would probably not be selected in the first place and if so occasionally they can be easily corrected Matthiaspaul talk 10 45 16 July 2021 UTC dd dd dd Publisher of a website Latest comment 2 years ago 7 comments 6 people in discussionCite web says The publisher is the company organization or other legal entity that publishes the work being cited When a page is cited from the MTV website sometimes I see publisher MTV Viacom or work MTV publisher ViacomAre either both of these variations acceptable or is there a more preferred way to cite this Kaltenmeyer talk 22 32 15 July 2021 UTC span data mw comment start id c Trappist the monk 2021 07 15T23 03 00 000Z Kaltenmeyer 2021 07 15T22 32 00 000Z span title is the name of the page or article that you are citing work MTV or website MTV is the name of the enclosing work the website or for a journal article journal or for a newspaper article newspaper they are essentiall synonymous publisher lt var style padding right 1px publisher s name var gt is the name of the business entity that published the work and so the article In general publisher isn t needed in a href Template Cite web html title Template Cite web cite web a for the same reason that publisher isn t usually needed for a href Template Cite journal html title Template Cite journal cite journal a and a href Template Cite news html title Template Cite news cite news a the business entities behind the journal newspaper website are bought and sold so the publisher information doesn t really help the reader locate a copy of the source Of course there are those who disagree with me some of them vehemently Trappist the monk talk 23 03 15 July 2021 UTC Unless there s something surprising or special about the publisher I usually leave it out of cite web citations That Viacom owns MTV is IMO widely known and not surprising If the site has some more arcane or technical name like Our Friend the Butterfly and the publisher is the International Union for Promoting Fluttering Insects I would include both as it might be relevant to weighing the ref s worth I believe I have also done website National Weather Service publisher a href National Oceanic and Atmospheric Administration html title National Oceanic and Atmospheric Administration National Oceanic and Atmospheric Administration a as well JohnFromPinckney talk edits 23 05 15 July 2021 UTC There are 2 reasons somewhat esoteric I would include the publisher if there are works with the same name but with different publishers and as a location of last resort If the source cannot be found anywhere it is possible that the publisher or the then publisher may be able to provide a copy 64 18 9 208 talk 11 30 16 July 2021 UTC If anything what gets to me is that CS1 italicizes website names regardless of whether or not it s appropriate This means I end up seeing things like MTV or CNN in citations when I have never seen MTV or CNN italicized in general Whether to mention that MTV is owned by Viacom or I guess ViacomCBS now I don t know MTV s been with Viacom for over 35 years not only the majority of its total lifespan but also its entire Internet lifespan so ownership is stable and I guess clearing things up for those who don t know might be desirable WP DOCITEBLUE WP POPE comic on today s lucky 10 000 but most websites need little more than a URL to help you find it technically speaking BRAINULATOR9 TALK 18 00 16 July 2021 UTC See MOS ITALICWEBCITE more specifically the footnote El Millo talk 18 04 16 July 2021 UTC Thanks for that it helps to know that this was settled in an RfC BRAINULATOR9 TALK 19 31 16 July 2021 UTC dd dd Invalid Cite web aliases in TemplateData Latest comment 2 years ago 6 comments 3 people in discussion This help request has been answered If you need more help you can ask another question on your talk page contact the responding user s directly on their user talk page or consider visiting the Teahouse For a list of depreciated Cite web parameters see Cite web Deprecated I have attempted to edit the TemplateData shown for the Cite web In the previous iteration depreciated aliases for the various editorn link parameters were listed These invalid aliases were editor small i n i small link and editorlink small i n i small I am trying to remove the nonexistent aliases from the TemplateData but Wikipedia won t let me save my changes citing JSON errors CJDOS Sheridan OR talk 19 05 20 July 2021 UTC edited 19 11 20 July 2021 UTC I have attempted to resolve the JSON syntax errors per mediawikiwiki Help TemplateData Syntax error in JSON Bad JSON format believing that I had orphaned commas in my edit which was true but it still won t let me save changes due to other unidentified JSON syntax error present CJDOS Sheridan OR talk 19 30 20 July 2021 UTC JSON is fragile and the error reporting is laughable so it is probably best to use Manage TemplateData button at the top of the page when viewed using the wikitext editor using the section edit link the button is directly under the main page header Trappist the monk talk 19 40 20 July 2021 UTC Thank you I will try that later but I m taking a break for now If I m not mistaken I believe true is supposed to be encased in quotation marks but that hasn t cleared the JSON syntax error messages CJDOS Sheridan OR talk 19 58 20 July 2021 UTC The Boolean constants true and false should not be quoted if they are they get casted to string type and may not test correctly Red rose64 talk 20 07 20 July 2021 UTC dd dd Done I have performed the editorn link edit in the manner suggested Thank you CJDOS Sheridan OR talk 20 14 20 July 2021 UTC button, wikipedia, wiki, book, books, library,

article

, read, download, free, free download, mp3, video, mp4, 3gp, jpg, jpeg, gif, png, picture, music, song, movie, book, game, games.