Wikipedia:Village pump (proposals)

"WP:PROPOSE" redirects here. For propose for deletion page, see Wikipedia:Proposed deletion and Wikipedia:Deletion requests.

 Policy Technical Proposals Idea lab WMF Miscellaneous 

• Table of contents
• First discussion
• End of page
• New post

The proposals section of the village pump is used to offer specific changes for discussion. Before submitting:

• Check to see whether your proposal is already described at Perennial proposals. You may also wish to search the FAQ.
• This page is for concrete, actionable proposals. Consider developing earlier-stage proposals at Village pump (idea lab).
• Proposed policy changes belong at Village pump (policy).
• Proposed speedy deletion criteria belong at Wikipedia talk:Criteria for speedy deletion.
• Proposed WikiProjects or task forces may be submitted at Wikipedia:WikiProject Council/Proposals.
• Proposed new wikis belong at meta:Proposals for new projects.
• Proposed new articles belong at Wikipedia:Requested articles.
• Discussions or proposals which warrant the attention or involvement of the Wikimedia Foundation belong at Wikipedia:Village pump (WMF).
• Software changes which have consensus should be filed at Phabricator.

Discussions are automatically archived after remaining inactive for nine days.

« Archives, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212

rfc: shall we update cs1/2?

Yes or No. Shall the Citation Style 1 / Citation Style 2 (cs1/2) Lua module suite be updated to reflect the changes that have accumulated in the module-suite's sandboxen?

This is an all or nothing rfc. In the event of a draw, cs1/2 shall be updated. §list of prospective changes gives brief descriptions of the individual changes and links to related discussions.

—Trappist the monk (talk) 23:11, 28 November 2021 (UTC)

list of prospective changes to the cs1/2 module suite

The last update to the cs1|2 module suite was 2021-04-10 except where otherwise noted. This section lists the changes made to the cs1|2 module suite sandboxen since that update.

list of prospective changes

changes in Module:Citation/CS1/sandbox detect generic author, editor, etc names; discussion emit error when |first= is wikilinked; discussion add Category:CS1 tracked parameter: $1 properties tracking category; discussion revise how date month-name auto-translation is enabled; discussion and discussion add support to allow editors to see citations that emit properties cats; discussion |url-status= without |archive-url= maint cat: Category:CS1 maint: url-status; discussion more consistent support of |type= with {{cite speech}}; discussion check all but url-holding and insource-locator parameters for inappropriate urls; discussion recognize stand-alone |script-chapter= in {{cite encyclopedia}}; discussion fix flaw in ref-duplicates-default detection; discussion added error summary preview; discussion reworked error messaging; discussion fix |archive-url= preview url; discussion tweaked IETF-like language handling; discussion changed formatting of volume and issue for non-journals; discussion moved hyphen_to_dash() to ~/Utilities; discussion detect leading '=' as extraneous punctuation; discussion changes in Module:Citation/CS1/Configuration/sandbox detect generic author, editor, etc names add Category:CS1 tracked parameter: $1 properties tracking category 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: Category:CS1 maint: url-status add support for |ssrn-access=; discussion add ab to script_lang_codes{}; more consistent support of |type= with {{cite speech}} check all but url-holding and insource-locator parameters for inappropriate urls add yue to script_lang_codes{}; added bogus name "Verfasser" to the list; discussion add keyword "deviated" to |url-status=; discussion added preview error summary added 'Login • Instagram' to generic titles; removed crh, nrg-gg, and nrf-je from language override added comma between volume and number; discussion added Mr. Privacy Statement, Ms. Cookie Policy and Dr. Submitted Content to list of bogus names; discussion revise kerning; discussion i18n |script-<param>= error message supplements; discussion added 'Usurped title' to generic titles; discussion added add bogus names: 'author', 'collaborator', 'contributor', 'editor', 'interviewer', 'translator'; discussion changes in Module:Citation/CS1/Whitelist/sandbox (last update 2021-05-25) removed deprecated parameter |transcripturl= deprecated |lay-date=, |lay-format=, |lay-source=, |lay-url=; discussion changes in Module:Citation/CS1/Date validation/sandbox extend allowed dates in |pmc-embargo-date= validation to two years; discussion revise month-name validation; add support to allow editors to see citations that emit properties cats; changes in Module:Citation/CS1/Identifiers/sandbox add support for |ssrn-access=; reworked error messaging; fix false positive doi error detection; discussion strip accept-this-as-written markup from all identifiers for metadata; discussion changes in Module:Citation/CS1/Utilities/sandbox (last update 2021-01-09) add support to allow editors to see citations that emit properties cats; reworked error messaging; added hyphen_to_dash() moved from main module; changes in Module:Citation/CS1/COinS/sandbox strip accept-this-as-written markup from |title=; changes in Module:Citation/CS1/sandbox/styles.css (last update 2021-01-09) Removed reliance on .error; Removed extra kerning classes; Removed unused cs1-subscription/registration styles; Moved .citation styles from MediaWiki:Common.css; Removed <code> selector;

—Trappist the monk (talk) 23:11, 28 November 2021 (UTC) 23:25, 3 December 2021 (UTC) (update link) 17:42, 23 December 2021 (UTC) (update links)

survey (update cs1/2?)

• Update see longer rationale in the discussion section. * Pppery * _{it has begun...} 23:31, 28 November 2021 (UTC)
• Strong oppose. There are far too many changes here for a single, all-or-nothing question, so I must oppose. Come back with a series of proposals that treat the community like adults and I will support the ones that will improve the encyclopaedia. Thryduulf (talk) 00:42, 29 November 2021 (UTC)

  Is there a specific change that Thryduulf objects to? If so, on what grounds is that objection based? – Jonesey95 (talk) 17:10, 29 November 2021 (UTC)

  I object to the concept of this RFC being all or nothing so that controversial changes such as removal of support for parameters that there was no community consensus to deprecate let alone remove are being pushed through with proper review because it would hold up needed uncontroversial changes. That's WP:GAMING the system. Thryduulf (talk) 19:50, 29 November 2021 (UTC)

• Not a valid RfC as per Thryduulf and Sdkb. Nikkimaria (talk) 00:57, 29 November 2021 (UTC)
  • Re Headbomb's comment below: to be clear, there is at least one change in this set known to be contentious, so a procedural closure of this RfC should not be taken as a green light to roll out everything. Nikkimaria (talk) 01:01, 29 November 2021 (UTC)
    • Assuming you are referring to add Category:CS1 tracked parameter: $1 properties tracking category; discussion, it doesn't actually add any categories, merely currently non-functional code to add categories. * Pppery * _{it has begun...} 01:19, 29 November 2021 (UTC)

      The removal of support for the unhyphenated parameters is also contentious, given that the premise of the discussion that (is claimed to) be the basis of consensus for the changes explicitly ruled that out (according to my memory of the major RFC anyway). Thryduulf (talk) 01:24, 29 November 2021 (UTC)

      The RFC was about a different set of parameters. See my explanation and link below. – Jonesey95 (talk) 17:12, 29 November 2021 (UTC)

      The RFC established that the basis on which both sets parameters were deprecated did not have community consensus, or even a local consensus given that the course of action undertaken was explicitly ruled out as something that would happen. Wikilawyering about exactly what was covered by the RFC is also not a good look. Thryduulf (talk) 13:43, 30 November 2021 (UTC)

• Support. This is a normal code update that has typically happened every few months. It contains bug fixes, minor enhancements, and small refinements. A larger number of minor changes than usual have accumulated because a small band of editors objected to the last regular update, and the volunteers who maintain the modules understandably decided to take a break from that drama for a while. Normally, notice of these updates would take place at Help talk:Citation Style 1 (418 page watchers, 125 recent visitors), where updates to these modules have been discussed for roughly a decade. Since there was drama last time, the updates are being vetted at this more-heavily-watched page (3,503 watchers / 554 recent). – Jonesey95 (talk) 02:24, 29 November 2021 (UTC)
• Support—we're overdue for the quarterly update. These updates dump millions of articles into the job queue for processing, so the changes are bundled and applied at once. Imzadi 1979 → 15:24, 29 November 2021 (UTC)
• Oppose removal of formerly valid parameter names, breaks old revisions for no good reason, was opposed at previous RfCs. Would probably support the rest, but in something as unwiki as an all-or-nothing RfC (Wikipedia usually operates by consensus), this is my only option. —Kusma (talk) 20:14, 29 November 2021 (UTC)

  As noted by Jonesey95 in the discussion section below, the parameters mentioned have already been deprecated back in February. This change should not be confused or conflated with the objected-to deprecation of |accessdate=, which is still in wide use. MichaelMaggs (talk) 08:51, 30 November 2021 (UTC)

  But that's not what Kusma (correctly) opposes for: the "deprecation" of parameters we used to allow is one thing, the "removal of support" from the code though means that all older versions of articles which did use these parameters will now give errors instead of just having a working (though no longer wanted) parameter. For parameters which were never widely in use, this may be acceptable; for parameters which where more widely used, this is problematic. Where the cutoff for "widely" should be placed is another kettle of fish of course. But that these parameters have been deprecated in February doesn't mean that one should support a change which now no longers supports them at all. Fram (talk) 09:15, 30 November 2021 (UTC)

• Support all of these changes, including those identified as potentially contentious by Pppery below. I would also prefer a return to the previous approach of more frequent updates for minor changes, with RFCs reserved for changes that are likely to prove controversial, but am content for the editors that maintain the CS{1,2} templates to decide how they bring changes to the community to review. Wham2001 (talk) 08:01, 30 November 2021 (UTC)
• Support, and agree with Wham2001's comments. MichaelMaggs (talk) 08:39, 30 November 2021 (UTC)
• Oppose. "It's an all or nothing" and you sneak in opposed changes which you happen to support? No thanks, if that's what you try then just abandon your maintenance of this please. I love the division created by a support vote between "a small band of editors" vs. "the volunteers who maintain the modules", a nice indication of a warped view of priorities there. Fram (talk) 08:42, 30 November 2021 (UTC)

  Fram's last sentence is important. Those who maintain these modules are doing a service to editors who add citations to articles not the other way around and this needs to be remembered. If the people who use the templates say something is bad, disruptive or unwanted then it should not happen and/or be reversed without question. The encyclopaedia does not exist for the convenience of coders. Thryduulf (talk) 10:51, 30 November 2021 (UTC)

  Those who maintain these modules are volunteers, not WMF employees, and they perform a complicated and very valuable service for the content creators. We are immensely grateful for the work they do. We appreciate and understand that a package of changes have been tested together and cannot easily be unbundled. Hawkeye7 (discuss) 03:52, 1 December 2021 (UTC)

  No, you've been mislead to believe that. It would in fact be technically trivial to perform the rest of the update without changing the list of supported parameters. I'm becoming more and more inclined to oppose this RfC with every passing comment. * Pppery * _{it has begun...} 03:54, 1 December 2021 (UTC)

  Those who maintain these modules are volunteers, not WMF employees yes, so?. they perform a complicated and very valuable service for the content creators. which is why they need to respect the community's wishes. Thryduulf (talk) 12:18, 1 December 2021 (UTC)

• Support all changes per Pppery and Jonesey95 comments below. As an additional comment to this procedure, the module maintainers do a very complicated and ungrateful service and I find it pretty absurd that module updates now require RfCs and even more absurd are some of the opposers are on the grounds that there are too many changes (and I'm not one of the maintainers). --Gonnym (talk) 11:01, 30 November 2021 (UTC)

  The issue is not that there are too many changes. The issue is that there are too many changes that we are being asked to approve as a single unit, and that unit includes changes that should not be made as well as changes that should. The module maintainers are giving the appearance that they care more about the module than they do about the reason the module exists: to support those writing an encyclopaedia. The only correct way to proceed in a situation like this is to swallow some pride and agree to separate the controversial and uncontroversial changes so that the former do not hold up the latter. The controversial changes than then be discussed on their merits and the consensus of the community listened to, whatever that consensus is, rather than attempting to bypass it. Thryduulf (talk) 13:40, 30 November 2021 (UTC)

• Support, although I don't really like the format of this RfC (particularly, the "all or nothing" framing and "In the event of a draw, cs1/2 shall be updated"). I don't think that the RfC should be closed as flawed, but it should be evaluated based on consensus for each of the proposed changes rather than "all or nothing", and no consensus should lead to retaining the status quo. Tol (talk | contribs) @ 21:57, 30 November 2021 (UTC)
• Support been waiting for some of these for quite a while. Hawkeye7 (discuss) 22:30, 30 November 2021 (UTC)
• Oppose this RfC as stated but support unbundling the set and implementing the many non-controversial changes but not the controversial ones aka "common sense". Levivich 05:18, 1 December 2021 (UTC)
• Oppose I've come to realize what this RfC really is, an attempt towill do: falsely establish consensus for controversial changes by making them a rider to clearly-supported changes when they failed on their own merits. That sometimes works for legislation, but it should not work on Wikipedia. * Pppery * _{it has begun...} 22:36, 1 December 2021 (UTC)

  Really? Really? Do you really think that were I trying to falsely establish consensus for controversial changes by somehow hiding them amongst a large number of other changes, I would have written this with its rather obvious markup which pretty much guarantees that anyone who merely scans the list could not fail to see it:

  • remove support for previously deprecated parameters |booktitle=, |chapterurl=, |episodelink=, |mailinglist=, |mapurl=, |nopp=, |publicationdate=, |publicationplace=, |serieslink=, |transcripturl=

  You have accused me, and probably, by extension, the other maintainers of the cs1|2 module suite of malfeasance, of dishonesty, of lying. Produce the evidence or withdraw your accusations.

  —Trappist the monk (talk) 23:50, 1 December 2021 (UTC)

  Premises:

  If this RfC passes (which might happen), then support for unhyphenated parameters will be removed.

  If there had been a RfC solely on the question of whether support for unhyphenated parameters should be removed, that RfC would likely have failed for the same reason Option C passed at the previous RfC

  Conclusion:

  This RfC passing will result in a false consensus in favor of removing support for unhyphenated parameters, as a result of it being stuck in as a rider to a broadly-supported set of changes. It was incorrect to phrase it as an accusation of malicious intent, and I've reworded the above comment slightly, but that doesn't change the underlying situation.

  * Pppery * _{it has begun...} 00:11, 2 December 2021 (UTC)

• No (equating to "oppose") as clearly mandated in the RfC's instructions, and almost entirely because of the RfC's instructions. Apparently, this RfC has to lean hard over to the "oppose" side, lest there be "no consensus", leading to to the same results as "Yes" ("support"). Then we can discuss the specific issues in an actual, properly formed RfC. — JohnFromPinckney (talk / edits) 20:36, 4 December 2021 (UTC)
• Oppose Insufficient detail. The use of German rather than English ("sandboxen") is erroneous here. Andrew🐉(talk) 13:05, 9 December 2021 (UTC)

  I am astonished, truly, I am. Usually the complaint is 'too technical' or 'too much detail'. Discussions about all of the proposed changes are linked in the collapsed box at § list of prospective changes to the cs1/2 module suite. Except for the most minor of changes, all changes to cs1|2 are always discussed so whatever detail you are seeking is likely in the related linked discussion. My word choice is not the subject of this rfc so a comment about that is erroneous here. (I'm not old enough to remember Middle English: boxen in everyday usage, but I am old enough to have used VAXen so it is not uncommon for me to also substitute boxen in its more modern sense anywhere that boxes might occur. I am not the only editor at en.wiki to do this)

  —Trappist the monk (talk) 14:43, 9 December 2021 (UTC)

  @Trappist the monk: See http://catb.org/~esr/jargon/html/overgeneralization.html for the general rule and http://catb.org/~esr/jargon/html/B/boxen.html for the specific word. WhatamIdoing (talk) 01:08, 14 December 2021 (UTC)

• Support. I support all changes. Most are minor and have strong consensus. The on that seems most controcersial is deprecation of certain unhyphenated parameters. Per the statistics bewlw, this will affect less than 1% of all pages using CS1/2, is easily fixed by bots, and a display will be displayed only when viewing old revisions. Not breaking old revisions has never been considered a strong argument at TfD and for the purposes of updating the module the reasons are the same. We don't hold supported templates hostage to faithful transclusions in old revisions. – Finnusertop (talk ⋅ contribs) 15:50, 14 December 2021 (UTC)
• Support. I see no problems with the changes. It is correct that removing parameters will mess up with page history but we have made many other actions that does that. We can't keep a fully working page history forever. I think it is a good idea to keep old parameters for some time but I see no reason why we need to keep them forever. --MGA73 (talk) 23:22, 27 December 2021 (UTC)

discussion (update cs1/2?)

• The only things here that seem plausibly controversial are:
  • add Category:CS1 tracked parameter: $1 properties tracking category; discussion (My observation: this doesn't actually add any new tracking categories, but merely adds code to populate such tracking categories if they are later needed)
  • added error summary preview; discussion
  • remove support for previously deprecated parameters |booktitle=, |chapterurl=, |episodelink=, |mailinglist=, |mapurl=, |nopp=, |publicationdate=, |publicationplace=, |serieslink=, |transcripturl=.
  . Overall, I question whether it's appropriate to remove (or to have deprecated in the first place) unhyphenated parameter aliases given the result of Wikipedia:Village pump (proposals)#RFC: Citation Style 1 parameter naming convention. Despite Trappist the monk's framing of the issue as all-or-nothing, the rest of the update is not in some way dependent on those changes, and it is anyway not sufficient to convince me not to support this update. * Pppery * _{it has begun...} 23:31, 28 November 2021 (UTC)

  FWIW, the deprecation of the above parameters happened in February 2021, more than nine months ago, all of the parameters were updated shortly thereafter, and any stray instances of those parameters have been generating error messages (and have been quickly fixed) since April 2021. This update would change the error message from "deprecated" to "unsupported" in the very rare instance that someone used one of these long-gone parameters. This change should not be confused or conflated with the objected-to deprecation of |accessdate=, which is still in wide use. – Jonesey95 (talk) 17:08, 29 November 2021 (UTC)

  How long have they been used and how many old revisions will be broken by removal of these parameters? And what is gained by removing them? —Kusma (talk) 09:38, 30 November 2021 (UTC)

  These parameter aliases were not commonly used. Hyphenated versions of them have been the standard since 2014. Dozens of unhyphenated multi-word parameters have been deprecated and removed from the CS1 citation templates over the past seven years with a minimum of drama (until the final six were proposed for deprecation back in April 2020, which is not something that is happening in this RFC). – Jonesey95 (talk) 14:19, 30 November 2021 (UTC)

  That does not answer any of Kusma's questions. Thryduulf (talk) 17:54, 30 November 2021 (UTC)

  I'll make an attempt to answer some of Kusma's questions. Per User:Monkbot/task 18: cosmetic cs1 template cleanup#hyphenate cs1|2 parameter names, before Monkbot 18 ran:

  1. |booktitle= was used 3,345 times
  2. |chapterurl= was used 17,289 times
  3. |episodelink= was used 2,539 times
  4. |mailinglist= was used 379 times
  5. |mapurl= was used 81 times
  6. |nopp= was used 2,902 times
  7. |publicationdate= was used 542 times
  8. |serieslink= was used 5,042 times
  9. |transcripturl= was used 910 times

  That totals 33,029 pages (which is an overestimate, as some pages likely used more than one such parameter). * Pppery * _{it has begun...} 22:36, 1 December 2021 (UTC)

  For a sense of scale, Module:Citation/CS1 is used in just over 5,000,000 pages. 33,000 pages was a little less than 0.7% of the total page usage. That is why it was so straightforward and easy to deprecate and update the above parameters, as opposed to the six remaining unhyphenated parameters, which are more widely used. – Jonesey95 (talk) 23:00, 3 December 2021 (UTC)

  OK, so the damage is middle sized (17000 broken chapterurls will create some annoyance). But removing these aliases still doesn't have any obvious advantages over not removing them. —Kusma (talk) 16:40, 7 December 2021 (UTC)

• In the event of a draw, cs1|2 shall be updated. This isn't normally something an editor opening an RfC can unilaterally declare, nor is an RfC's all-or-nothing status. Per WP:Consensus, if there's no consensus, we generally retain the status quo. {{u|Sdkb}} ^talk 23:33, 28 November 2021 (UTC)

  It is totally inappropriate, and whoever closes this should ignore this made-up rule that has no policy-based support whatsoever. In the event of "no consensus overall", the changes that are supported by consensus should be applied and the changes not supported by consensus not applied. —Kusma (talk) 09:36, 30 November 2021 (UTC)

• Waste of time RFC it's utter nonsense that we have to wait for months for CS1|2 updates to be rolled out, it's even more utter nonsense that we need RFCs to roll them out. If they're ready and have consensus, roll them out as soon as they've been tested in the sandbox and confirmed as working as intended. Don't delay, and don't plague us with pointless RFCs. If a particular issue is contentious, have an RFC on that issue, don't hold the rest of the updates hostage. Headbomb {t · c · p · b} 00:45, 29 November 2021 (UTC)
• I don't like the format of this RfC. It would be better done by a different method:
  1. Propose these changes and see if anyone opposes one or more of them.
     • Unopposed (uncontroversial) changes can be immediately implemented or held until after the second part.
     • Opposed (controversial) changes would need consensus in part 2.
     • Obviously uncontroversial changes don't need to be included.
  2. Open a multi-section RfC with a section on each controversial change, and let each section gain consensus individually.
  3. Implement changes that were either uncontroversial in part 1 or gained consensus in part 2.
  I don't think that the RfC should be closed as flawed, but it should be evaluated based on consensus for each of the proposed changes rather than "all or nothing", and no consensus should lead to retaining the status quo. Tol (talk | contribs) @ 21:57, 30 November 2021 (UTC)
• Why is this an all or nothing? Why will it pass in the case of a tie? Dege31 (talk) 18:24, 3 December 2021 (UTC)

  The cynical view is because that's the only way the proposer(s) do not wish to test the consensus of the changes individually, possibly because some of the desired changes may not pass. You are not the first to ask the question, but none of the responses have provided a plausible alternative view, although malicious intent has been denied. Thryduulf (talk) 21:31, 3 December 2021 (UTC)

  Changes to cs1|2 are not made secretly behind a veil; all editors are welcome, encouraged, to participate in the discussions about cs1|2 at Help talk:Citation Style 1. There is no need to re-discuss that which has already been discussed (see the discussion links in the collapsed box at § list of prospective changes to the cs1/2 module suite). Except for the most minor of changes, all changes to cs1|2 are always discussed, mostly at Help talk:Citation Style 1 and sometimes, at other locations (Help talk:CS1 errors and Template talk:Citation are common alternate-discussion locations).

  In my experience – yours may be different – inconclusive RFCs result in the question: 'now what?' To avoid the 'now what?' question, I defined an action to be taken in the event that the community's opinion is not definitive. So now you know. The answer to the 'now what?' question for this RFC is: update.

  —Trappist the monk (talk) 23:25, 3 December 2021 (UTC)

  There is no need to re-discuss that which has already been discussed (see the discussion links... But not all of those discussions reached a consensus in favour of the proposed changes. That suggests that either they do need to be re-discussed, or they should be removed from the proposal. Nikkimaria (talk) 00:03, 4 December 2021 (UTC)

  @Trappist the monk: inconclusive RFCs result in the question: 'now what?' This could not have been an inconclusive RfC - either there is consensus for the changes or there is no consensus for the changes. In the first case the changes are implemented, in the second case they aren't. If the changes did not get consensus there is nothing stopping anyone who understands why they failed to get consensus addressing the reasons and asking the community about the revised proposal. Everywhere else on Wikipedia changes for which there is no consensus do not get implemented, and there is no reason for this to be any different. Thryduulf (talk) 11:32, 4 December 2021 (UTC)

  The question asked by this RFC is simple: Yes or No, shall we update? If the community's answer as determined by the closer is predominantly Yes then we update; if the community's answer as determined by the closer is predominantly No, then we do not update. If the community's answer as determined by the closer is inconclusive then we update and avoid the 'what now?' question. Because it is stated in the question, all respondents to this RFC know what to expect in the event of a tie.

  —Trappist the monk (talk) 13:34, 4 December 2021 (UTC)

  Lol ttm like that would ever fly. The initiator of this RFC knows what to expect if updates are pushed without consensus. Levivich 14:06, 4 December 2021 (UTC)

  If the answer as determined by the closer is "inconclusive" then anywhere else on Wikipedia the status quo would apply, which in this case would mean "we do not update". You have not explained why this RfC should be different to everywhere else. Thryduulf (talk) 18:06, 4 December 2021 (UTC)

• How much of a maintenance burden would it be to keep the deprecated parameters around? I sometimes worry that while the desire to keep old revisions working is reasonable, keeping the old parameters around might create extra work when updating/maintaining/adding new functionality to CS1/2 templates and we might be neglecting this extra work. Jo-Jo Eumerus (talk) 10:42, 4 December 2021 (UTC)

  In the last RFC, which found "There is a rough consensus that non-hyphenated parameters should not be deprecated in citation templates" (emphasis in original) the maintenance burden was brought up multiple times, but nowhere in the discussion could I find anywhere that detailed exactly what that burden is or why it is so significant that it was more important than the various benefits of keeping them around (not breaking old revisions, editor familiarity, ease of use, etc). Certainly none of the arguments about maintenance burden convinced people in opposition to deprecation to change their minds. Thryduulf (talk) 11:43, 4 December 2021 (UTC)

• Some think it's okay to remove old parameters and some think we should keep them to preserve page history. Personally I do not think it is possible or needed to make sure that a page history will work forever. But I agree that it would be good to preserve page history for some time. So perhaps as a compromise there could be some time limit so parameters used on less than 1k pages could be removed faster than pages used on 1M+ pages? --MGA73 (talk) 23:33, 27 December 2021 (UTC)

Don’t annoy the 2% who give

I’m one of the above. I’ve just been berated multiple times in the last 5 minutes. A gentle nudge is sufficient. You have the technology to distinguish me from the 98%. Do that. — Preceding unsigned comment added by 216.106.102.52 (talk) 01:12, 12 December 2021 (UTC)

The Wikipedia community has no control over the fundraising banners, they are run by the Wikimedia Foundation (WMF). You can raise concerns at Wikipedia:Village pump (WMF) or meta:Talk:Fundraising. --Ahecht (TALK
PAGE) 16:17, 12 December 2021 (UTC)

Regarding the general principle of providing customized experiences for readers who are not logged in, there is a significant number of people who dislike being tracked in this manner. In theory it could be used solely to disable fundraising banners, but I suspect the resistance to IP tracking will continue to be a barrier for acceptance. isaacl (talk) 16:35, 12 December 2021 (UTC)

I agree that tracking IPs and donations would be a bad idea, but couldn't we use a browser cookie to track dismissals like we do for watchlists notices? Imagine how pissed off someone needs to be in order to track down the village pump and post this; I think it might be worth figuring out a way to make the banners slightly less annoying for readers. — Wug·a·po·des​ 00:42, 24 December 2021 (UTC)

The underlying technology is basically the same: using data in a cookie to correlate your past behaviour with your current action. In theory, maybe people could be convinced that this is only being used to disable fundraising banners. In practice, I'm dubious. isaacl (talk) 21:59, 29 December 2021 (UTC)

We already do that right ? At least that is how it used to work for years (can't check, I'm not in the geozone, but if someone else can, plz do check). I think Ppl are just complaining more this year because of increased privacy guards in various browsers blocking the cookies. I suspect. Or they just can't find how to dismiss, because the UX of the banners is so F'ed up? —TheDJ (talk • contribs) 13:59, 3 January 2022 (UTC)

Adding onto the above, if you don't already know, one easy way to disable the banners is to just create an account and log in, since they're not shown to logged in users. Cheers, {{u|Sdkb}} ^talk 21:07, 13 December 2021 (UTC)

Well, my understanding is that some fundraising banners are still displayed to logged-in users—to disable them for good, there is a preference in Special:Preferences#mw-prefsection-centralnotice-banners. See also Wikipedia:Suppress display of the fundraising banner. Mz7 (talk) 00:00, 14 December 2021 (UTC)

• We have a template for this.

Welcome and thank you for your question about donations! To hide the fundraising banners, you can create an account and uncheck Preferences → Banners → Fundraising. The Wikimedia Foundation does not track the identity of IP addresses, so it doesn't know your age, income level or whether you donated in the past.
None of the Wikipedia volunteer editors here who add and improve content in articles receive any financial benefit. We all simply contribute our time because we care about building a great encyclopedia for you and innumerable others around the world to use.
If you cannot afford it, no one wants you to donate. Wikipedia is not at risk of shutting down, and the Wikimedia Foundation, which hosts the Wikipedia platform and is asking for these donations, is richer than ever.
We are led to believe that users who allow cookies are less likely to see these banners on repeat visits (further information is available here), and you are welcome to communicate directly with the donor-relations team by emailing donate@wikimedia.org. Thank you! Beeblebrox (talk) 22:39, 29 December 2021 (UTC)

Relevant wikitext: {{subst:WikiDonation}}. Certes (talk) 22:47, 29 December 2021 (UTC)

Changing the PROD process

I noticed a couple of problems with the PROD process in its current form. As useful as PRODs are (from experience), I identified a couple of issues with the way PROD is done.

1. There is no way to identify whether removal of a tag is an objection to the proposed deletion. Sometimes with PRODs I see a contributor make a bold edit and remove the PROD tag. It could be because of edit conflicts or it could be because the removal was by mistake.
2. There is no way to see the reason an editor objects to a deletion. Sure some editors use the edit summary to discuss objections to proposed deletion.

I think the following should change:

1. An objection to PROD should be clear. Some new creators may inadvertently remove the PROD tag without giving a reason for why they are removing it.
2. An objection to PROD should turn the PROD into an XfD. This kind of happens but not always.
3. Maybe the PROD templates are unnecessary. We could completely remove those templates and replace PROD with "listing at XfD, waiting for seven days to see if there are any objections to deletion to allow for debate, and then determining consensus". Aka merge PROD with the XfD process.

What do you think? Aasim (talk) 19:00, 29 December 2021 (UTC)

• I'm not sure what changes you're proposing, but the ones I think you're proposing are ones I do not like. The editor who makes a PROD nomination is responsible for watching if there are objections, and nominating an AFD if they are not convinced by the objections. This works and there is no need to complicate it further. If you're suggesting completely removing the PROD process, you will need a clearer proposal. User:力 (powera, π, ν) 19:10, 29 December 2021 (UTC)
• I think that WP:PROD is one of our processes that works very well. It leads to a lot of crap being deleted, but ensures that there is a discussion if there is any doubt about whether it is uncontroversial. I would urge the original poster to show evidence that the suggested changes would be improvements. Phil Bridger (talk) 19:42, 29 December 2021 (UTC)
• An objection to PROD should turn the PROD into an XfD That should not happen. If I remove a PROD because I don't think that the deletion is uncontroversial, I am very likely not going to be able to provide a good rationale at AfD, other than what was provided in the PROD, which I disagree with. For example, If I de-PROD Jean Emile Oosterlynck, which has been nominated as "No evidence of notability found" but I happen to know that this is the same person as Jean Oosterlynck, who has an entry in Benezit, then I don't want to AfD that article. Vexations (talk) 21:21, 29 December 2021 (UTC)
  • Conversely, sometimes the de-PROD-er makes a solid argument and/or adds a number of sources, which will convince the PROD-er not to go to AfD. In other words, there's sometimes a good reason why an objection to a PROD does not result in an AfD nomination. JBchrch talk 21:33, 29 December 2021 (UTC)
• I object to these changes because I feel they increase the administrative burden of the PROD process, and I do not see what benefit that is supposed to bring. Also I think the new labor proposed would fall to the person objecting to PROD, when instead I feel that the most labor and responsibility should fall to the person nominating the article for PROD. I support changes which assist anyone in transitioning a PROD to an AfD, but I like PROD for what it is now and AfD for the different thing that it is now. I do not wish to make PROD more like AfD. I do agree with the nominator that I wish we more often had easily accessible records of why users post PRODs or remove them, and I support changes which increase users giving this information, but I do not want users to feel additional pressure to use the process. Blue Rasberry (talk) 21:28, 29 December 2021 (UTC)
• For the newer editors here, we don't want to make the learning curve to operate here even more difficult. Also we don't need to increase the overhead work. SO I am not supporting the suggested proposals. One possible idea if a prod is removed without an edit summary is to put up a special pop up saying that the editor remove a proposed deletion template, and asking them why they did that, with a box for a better edit summary. (maybe edit filters can do this). Graeme Bartlett (talk) 21:45, 29 December 2021 (UTC)

  I'm going to use an extreme example just to demonstrate the point. Let's say Donald Trump gets PRODed; he is obviously notable via multiple criteria, including WP:NPOL and WP:GNG among others. It would thus be rightfully contested. Why would we thus waste everyone's time by sending it to AfD? Merging PROD with AfD is fundamentally flawed, will be extremely difficult to implement, and will just increase administrators' workload. And in response to you 1st proposed changed for rationale, while we all wish all dePRODers use the edit summary, there is no functional way of enforcing this function. C'est la vie. Curbon7 (talk) 21:56, 29 December 2021 (UTC)

• This proposal seems born out of a misunderstanding of what PROD is for. It is for uncontroversial deletions. It is deliberately designed to be easy to object to. If the PROD is removed, the burden is on the PROD proposer to decide whether to proceed to AFD. Merging the two processes is therefore a terrible idea. Beeblebrox (talk) 22:43, 29 December 2021 (UTC)

  Good to see some feedback. I also see it as a way for uncontroversial deletions, but one of the problems I have seen with PROD is that I cannot identify whether a removal of a PROD template is an objection or the result of something else like an edit conflict or vandalism or what. Policy does not make this clear.

  As for point #2 which I made earlier, I am also starting to see why it may be kind of a bad idea, but at the same time, the point of AfD is to discuss whether an article should be deleted or not, which is of course the reasonable next step after a proposed deletion.

  And for adding something to the abuse filter, that is actually not a terrible idea. Although I am not sure if the filter will pop up in an edit conflict. That prob fixes point #1.

  It is possible I posted in the wrong subforum, in which case someone is free to move it to idea lab or policy. Aasim (talk) 05:34, 30 December 2021 (UTC)

  Even after your clarifications I'm strongly opposed. If the PROD template is removed and it isn't absolutely clear that the removal was vandalism then you must assume that the removal was an objection. A reason for objecting to a PROD is not required, nor should it be required. If you still think that the article should be deleted then you are the one who is responsible for listing it at AfD, it is not reasonable to require this of someone who does not think that article should be deleted. Thryduulf (talk) 12:48, 30 December 2021 (UTC)

  The policy on removal of the tag is crystal-clear. It says, "If an editor's intent is unclear, an objection should be assumed." This is simply a procedure for deleting articles that everyone accepts should be deleted without a full discussion, an application of WP:BRD to deletion. If anyone objects then discuss, just as for any other change. Phil Bridger (talk) 19:46, 30 December 2021 (UTC) P.S. And please don't start a discussion somewhere else if you don't like the outcome of this one. Here is fine, and forum shopping is frowned upon. — Preceding unsigned comment added by Phil Bridger (talk • contribs) 19:52, December 30, 2021 (UTC)

  Agreed. These are simply not viable proposals. A PROD is supposed to be a low overhead deletion process for uncontroversial deletions. Curbon7's "Donald Trump" example is a perfect counterexample to explain some of the inherent issues with the proposals. We should not be creating a backdoor method for users to effortlessly nominate things for XFD. Vandals would just love that. Meters (talk) 20:07, 30 December 2021 (UTC)

  Agree with this. Gråbergs Gråa Sång (talk) 19:47, 1 January 2022 (UTC)

Portal links on the Main Page: follow-up

A few weeks ago, a discussion about portal links on the Main Page was closed as "no consensus", with suggestions for a way forward. A closure review at AN was archived yesterday. As I will not be shepherding this discussion further, I invite any interested editor(s) to pick up where I left off. This is not a protest against the closure, but simply a decision to focus on other things for the time being. JBchrch talk 11:15, 2 January 2022 (UTC)

Changing yearnumbering on Wikipedia

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Sitting on the edge of a policyproposal I do think it belongs here though.

Wikipedia is said to be an unbiased, non-reliant and objective source of information. Yet it follows the remnant of 'our' (I'm European) religious and colonial past by presenting the years as BCE/BC and CE/AD. Wikipedia should be an inclusive platform, for all human knowledge, without a bias towards Christianity and its systems introduced often by means of oppression. Only about a third of all humans consider themselves Christian according to the wikipedia page on World Religion. More than half the population in my home country (The Netherlands) consider themselves as non-religious according to official CBS statistics in 2020. With the start of the new year 12022 HE I wanna start the discussion of introducing the Holocene calendar on wikipedia worldwide, as default yearnumbering system with the local dominant system only presented in between brackets if dates are named in an article. Let Wikipedia be a forerunner in the introduction of an inclusive calendar reform. What are your thoughts on this? Grifo (talk) 13:29, 3 January 2022 (UTC)

Wikipedia follows the sources, it doesn't lead them. Convince most of the English-speaking world to start using a new Common Era and Wikipedia will follow. As it is, why should we use the "Holocene calendar" (which itself seems to be off by ~300 years) rather than declaring the current year as −72 BP? And why not rename the months to not be mostly named after old Roman gods and numbers that are off by two? Anomie⚔ 13:51, 3 January 2022 (UTC)

Can you define 'the sources' please? I thought Wikipedia was about following reliable, unbiased sources. Not some 6th century monk (Dionysius) who erroneously placed the birth of his religious frontfigure randomly along a timeline, which was applied as yearnumbering system ever since due to the makeup of contemporary society.

I'm ok with the BP calendar, but the HE is more practical. The years the Holocene calendar might be off compared to the assumed real onset of the Holocene is a minor issue. We will never know the exact year the Holocene started, nor will there ever be an historical neolithic event dated so precisely that the HE calendar needs a reform to allow that event to be fixed inside the calendar.

The 'standardized' Roman/Germanic name of months and days doesn't render the same effect of applying value to certain historic events likr yearnumbering does (i.e. before time began or after a certain local and subjective event took place: after time began), implying less importance to the events prior to year 1. With either the BP or the HE calendar, such exclusive subjectiveness of implied value of events is removed and is instead replaced by an objective marker having the same value for all citizens of the world as the event (Holocene/Nuclear Era) was omnipresent. Grifo (talk) 15:42, 3 January 2022 (UTC)

It seems there are several incorrect assumptions above. To see what Wikipedia actually is fundamentally, start with Wikipedia:General disclaimer. Then proceed to something like WP:NOT which, even though not as embedded as the first, is also pretty basic. And so on. What "Wikipedia should be" is an opinion, which anyone may embellish with moralizing of one sort or another without in any way affecting its factual validity. Other than that, I've no idea if what you suggest is technically actionable. 65.88.88.201 (talk) 16:01, 3 January 2022 (UTC)

This isn't about when Jesus was born, or even whether he existed. (There's at least as much doubt that the changes marking the Holocene epoch occurred in precisely 10,000 BCE.) The important thing is the WP:COMMONNAME of the current year, and most English speakers seem to call it 2022. Any campaign to change that should not start at Wikipedia. Certes (talk) 17:24, 3 January 2022 (UTC)

• Grifo As noted, you are going to need to launch a worldwide campaign to persuade governments and people to adopt your preferred calendar, before Wikipedia can do so. 331dot (talk) 16:05, 3 January 2022 (UTC)
• I have many articles about archaeological sites and cultures on my watchlist, many of which use BCE/CE. I see far more users who are not familiar with our guidelines trying to convert BCE/CE to BC/AD, than the other way round (and I don't recall anyone trying to convert the era designation to HE or BP). Even if there were a consensus to ignore the sources (overturning some core Wikipedia policies), I doubt there would be any consensus to use anything other than BC/AD as the default era designation. - Donald Albury 17:35, 3 January 2022 (UTC)
• Civil calendar states that most civilizations use the CE/BCE system with the Gregorian calendar - so even outside of what the sources may document dates in, it is the reference frame that English literate readers of our encyclopedia would expect when reading articles. — xaosflux ^Talk 18:34, 3 January 2022 (UTC)
• More than half the population in my home country (The Netherlands) consider themselves as non-religious... but what calendar do they actually use? The Gregorian calendar. The vast majority of countries use the Gregorian calendar for at least some purposes and the few countries which don't will nevertheless be familiar with it. This is particularly true for English speakers, which are the target audience of the English Wikipedia. Switching to an alternative such as the Holocene calendar would just confuse people who aren't familiar with that calendar. Wikipedia generally follows the rest of the world (or at least English speakers) in matters like this, you should try convincing others first. Hut 8.5 12:59, 4 January 2022 (UTC)

But how to convince others when something grassroots like Wikipedia follows the dictate of past colonial society which implemented the Gregorian Calendar worldwide, disregarding any cultural heritage of oppressed peoples? Where to start when even Wikipedia does not follow its own standards? Wikipedia is based on reliable sources. The Monk I mentioned is not a reliable source at all, yet Wikipedia follows his yearnumberingsystem everywhere. I am NOT opposing the Gregorian Calendar though, I'm opposing the starting point of it. The starting points of the Holocene Calendar or the Carbon Dating Calendar (BP) are much better, much more inclusive, much more reliable, much less subjective to pre-Christian times and have a worldwide recognisable starting point. Something an encyclopedia should prefer, despite the inconveniance this might result in to alter all dates.Grifo (talk) 16:33, 4 January 2022 (UTC)

Apart from all other arguments against this given above; you are aware that the Holocene calendar is "directly" based on the same BC/AD calendar, but simply moves it back exactly 10,000 years? If you want to get rid of the influence of Christianity or the calculations of a monk, then using the Holocene calendar is not the solution at all. Fram (talk) 16:42, 4 January 2022 (UTC)

perhaps Stardate.... — xaosflux ^Talk 16:55, 4 January 2022 (UTC)

Because it would confuse the hell out of just about everybody. Everybody knows that it this year is 2022, and would think that 12024 HE is a typo. And just think for a moment about having to change almost every citation. Vexations (talk) 16:57, 4 January 2022 (UTC)

• Let me ask a related question: "Isn't writing this in English a vestige of European colonialism?" The only reason a lot of people in the world speak English today is because a few hundred years ago, the English built boats and sailed to other continents where they conquered the native populations. The Spanish, French, Portuguese, Dutch, etc did a lot of that too. The only reason I speak English is because my great-grandparents left their homes and came to the United States, where they learned English (but didn't convert to Christianity). Isn't continuing to use those languages to write encyclopedias just following the remnants of our colonial past? Well, yeah, but as noted above, wikipedia's job is to collect and document information, not to be a leader for sweeping social change. We use CE dates not because we think they're best, but because that's what most of our sources use, and what our readers are used to. Looking at the home pages of the zh, hi, ar, and he wikis, I see they all use CE dates. Surely if CE dates are good enough for those wikis, it's good enough for enwiki. -- RoySmith (talk) 17:25, 4 January 2022 (UTC)
• Not going to happen, nor should it. Time to stop wasting time discussing it. Johnbod (talk) 17:57, 4 January 2022 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

New edit tags, for sockpuppets and other blocked users

Background: I recently opened a series of SPI investigations on some sockpuppets. As I look through their contributions, I realised that those were all created for the sole purpose of disruptive editing. A number of their edits are not reverted, and in a few cases happen to be the latest revision of a certain article. Now this certainly isn't an issue unique to my case, there would be lots of such issues lying around elsewhere within Wikipedia. How can we help editors working on specific projects/articles point out potential problematic edits?

Proposal: Should we establish new tags (list) that automatically appears on edits made by revealed sockpuppets? And another tag for edits made by users who are currently blocked for reasons like vandalism, disruptive editing, multiple test editing, etc. This would help editors skimming through edit history of a page identify potential problematic edits made by users who are blocked for violating WP rules. ---CX Zoom(^he/_him) (^{let's talk}|_contribs) 22:32, 4 January 2022 (UTC)

It's not a bad idea. There are user scripts that automatically flag blocked accounts a number of ways with colors or strikethroughs. These should be standard IMO. -- GreenC 22:38, 4 January 2022 (UTC)

Special:Preferences#mw-prefsection-gadgets has "Strike out usernames that have been blocked". Is that what you mean? Vexations (talk) 23:11, 4 January 2022 (UTC)

markblocked, which you can enable in preferences, accomplishes roughly the same thing (you can hover over the blocked editor's username to see the block reason). Using tags to do this doesn't seem like a good idea. AFAIK this would require an admin (or adminbot) to add the tags whenever someone gets blocked, and remove them if they successfully appeal; the script, on the other hand, requires no additional maintenance work. The whole business of blocked users, sockpuppetry, etc. is also largely irrelevant to the average user, who only comes here to fix a typo once in a while. I think it's best to leave it as an optional gadget for those interested. Spicy (talk) 23:28, 4 January 2022 (UTC)

It doesn't require an adminbot. The bot usergroup has the changetags userright, so any bot account can do this. ProcrastinatingReader (talk) 02:13, 5 January 2022 (UTC)

markblocked or similar sounds like a better idea, as it will update automatically whenever the [ir]responsible editor is blocked and unblocked. Tags are for properties of an edit, whereas this proposal is about the properties of a user. Good users occasionally make bad edits, and vice versa. Certes (talk) 02:18, 5 January 2022 (UTC)

Fstops in gadget page

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

About Preference, Gadgets: four codes are listed and described in the Gadget legend: (D), (E), (S), (U). The descriptions appear in the list as {{abbr}} like ^(D), OK. Now, between the four the period (full stop) is alternating missing/present in the abbr tooltip text. Maybe could be smoothed?

(I personally do not think for this issueette the Project should be restarted from 20 year ago, but I do like to take my examples from high end quality webpages ;-) ). -DePiep (talk) 06:58, 7 January 2022 (UTC)

@DePiep: I'm closing this section as this is a very minor tweak that shouldn't require a community proposal. See MediaWiki_talk:Gadgets-prefstext#Tool_tips and feel free to just open an edit request there for any sorts of minor updates you would like made on the labels. — xaosflux ^Talk 11:28, 7 January 2022 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Categorize Set index articles as disambiguation pages

• Wikipedia:Set index articles
• Template:Disambiguation
• [[Category:All disambiguation pages]]
• add {{Disambiguation}} to any Set index article.

.... 0mtwb9gd5wx (talk) 07:44, 9 January 2022 (UTC)