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, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214

Spoken narrations of the blurbs at Today's featured article (TFA)

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.

After 22 days, I think it's time to close this one. First, I want to say a big thank you to everyone who participated—I learned a lot about accessibility and formatting throughout the process and particularly by reading all of your comments. I think it's fair to say that the general consensus was the proposal's clunkiness and bureaucracy outweighed possible accessibility upsides, given the prevalence and improvement of screen reader technology. Accessibility, to all who might not consider reading the best form of digesting information (including, but also supersedind, blind people), is a super important topic for the encyclopedia to address and I can't wait to see where we go to address it. Here's to the sparks of new ideas and to the saucer that cools the coffee—Cheers, everyone! theleekycauldron (talk • contribs) (they/she?) 06:56, 8 December 2021 (UTC)

---

Should the Today's featured article section of the Main Page allow for spoken recordings of its blurbs? theleekycauldron (talk • contribs) (they/them) 06:53, 15 November 2021 (UTC)

Executive summary by proposer

Problem: The Main Page of English Wikipedia is regularly seen by 5.5 million people, of whom a significant number are visually impaired. While WikiProject Spoken Wikipedia exists to narrate existing articles, and has narrated hundreds of Featured Articles, users are currently not allowed to add recordings to sections of the Main Page. This lack of audio narration poses a barrier to not just the visually impaired who wish to view the works we want to spotlight, but also those with reading or learning disabilities, those too young to read large chunks of text comfortably and seamlessly, and those who simply are more predisposed to retain information auditorily rather than textually. Not every section of the Main Page is easily narrated—Did you know, On this day, and In the news, for example, are too unpredictable to have immutable recordings attached to them. Today's featured article (TFA), however, consists of a single thousand-character blurb generally updated only once a day, ideal for a spoken recording.

Proposal: In every nomination template for TFA, there should be an optional "narration" parameter that allows the nominator, or any other interested editor, to add a spoken recording of the blurb that is to appear on the Main Page. A sample narration on a past iteration of the Main Page can be found here to roughly illustrate how this may look and feel, although this will be changed as more experienced template editors than myself fiddle with the idea. No nomination will be required to contain a narration, but any recording that is attached to the nomination must be reviewed by an admin according to the guidelines laid out by WikiProject Spoken Wikipedia for technical quality, clarity, and accuracy before the recording can accompany the nomination to the Main Page. This proposal has the potential to help thousands in accessing the articles that Wikipedia is most proud of. Thanks for your time, and I hope I can count on your support! theleekycauldron (talk • contribs) (they/them) 06:54, 15 November 2021 (UTC)

Discussion (TFA blurbs)

• I'm interested to hear from editors familiar with visual impairment whether spoken versions of articles actually help aid accessibility. I have a sense that text-to-speech software has improved dramatically in the past decade or so, which has limited the usefulness of spoken versions. If there's not a major advantage of having human narration, the costs in effort, inconsistency, and difficulty in updating may be reasons to reject this. {{u|Sdkb}} ^talk 09:13, 15 November 2021 (UTC)

  This isn't totally my field, but WikiProject Spoken Wikipedia's landing page offers a few reasons as to why a spoken recording might be better than text-to-speech. theleekycauldron (talk • contribs) (they/them) 09:28, 15 November 2021 (UTC)

  I've responded below. Graham87 10:12, 15 November 2021 (UTC)

  I'm not persuaded that there is a pressing need, particularly given the advances in text-to-speech technology since WikiProject Spoken Wikipedia launched. {{u|Sdkb}} ^talk 02:13, 16 November 2021 (UTC)

• In-principle, this is a very nice and innovative idea, which is definitely useful for visually impaired—in my opinion, a human narration is better than an automated one. But presently, the biggest issue I see with this is its inconsistency. "No nomination will be required to contain a narration ..." may not be a good idea, especially for the main page. To me, it will look odd if we have narrated version attached with the blurb for three days, but not for the fourth. Article featuring at TFA are scheduled well in advance. As of today (November 15), we have articles scheduled for all the dates till December 31! I was wondering if we can have a group of interested editors volunteering to create recordings in advance as to avoid this inconsistency. Thoughts? – Kavyansh.Singh (talk) 09:32, 15 November 2021 (UTC)
• As a blind user, I wouldn't benefit from this at all personallly, but I'm one of the most un-audio-oriented blind people I know of. I don't know any other blind people this would benefit; people who are proficient at using screen readers tend to prefer using them, but not all blind people are (especially those who have recently lost their sight). As noted in the executive summary and at the idea lab discussion (which I noticed but chose to lurk in), this might also benefit people with other disabilities. Since the TFA blurbs are relatively short and the spoken version isn't a *requirement*, I'm basically meh on the whole idea. Also, many people who visit Wikipedia's Main Page don't read much or any of it and just use it as a search bar; we don't have exact figures but I highly doubt that 5.5 million people a day actually engage with the "Today's featured article" section, for example. Graham87 10:12, 15 November 2021 (UTC)

  Roughly 40,000 click through to the TFA on any given day, so I'd hazard that around 100,000 or more at least read the blurb. theleekycauldron (talk • contribs) (they/them) 10:24, 15 November 2021 (UTC)

• I think it's worth a try, it does require both volunteers willing to record narrations and those to quality check the recordings - so being optional is necessary as either of those could fail to emerge. A probably-more-than-bikeshedding part to consider from VPI is how much screen real estate to allocate for this control. It could be anything from a small icon (topicon sized), a line of text, the full player control - or something else. — xaosflux ^Talk 11:00, 15 November 2021 (UTC)
• I reiterate what I've stated elsewhere, in that this is a forward-thinking idea. Just consider all you access on the internet that comes with sound, some helpful and some not. But Wikipedia has no sound on its main page, possibly the first Wikipedia page that opens up for much of the global readership. In addition to the sight-impaired benefit, even if it's just a little two-sentence oral blurb, it enhances the reader experience. On a global media outlet where nothing is censored, there's an aspect to consider about whether or not we want it on every TFA. That could be decided on a one-on-one basis as the TFA process puts together it's individual blurbs. But I certainly believe it's a worthy feature we should enable. — Maile (talk) 11:31, 15 November 2021 (UTC)
• I think this is a great idea. It calls attention to WikiProject Spoken Wikipedia with a minimum of effort: recording one blurb doesn't take long at all, and they can be prepared weeks in advance, so I don't think we need to worry about gaps. I'd also like to hear more about whether readers with visual impairments find these useful, but that shouldn't be the only consideration either. Lots of people just prefer listening or watching to reading and Wikipedia's overwhelmingly text-based front page is really starting to show its age in comparison to other websites. – Joe (talk) 12:18, 15 November 2021 (UTC)
• There are some practical difficulties. We are scheduled until December 31, but that is because I scheduled December a bit early this month (I schedule the third month in each quarter) and often it's not until the 20th or so that the coordinator whose month it is competes work. "Nominations" (at TFA/R) account for perhaps five or six of the blurbs in a month, many of the remainder won't have prepared blurbs yet. Once a blurb is posted (whether by a coordinator or by one of the principal editors of the article), that is not a final version as there are several users who often go through some days in advance and offer suggestions or edit it directly. And, quite often, WP:ERRORS weighs in on the day or on the day before, and we wind up changing the blurb. Since the spoken word version needs to be finalized some time in advance of main page day to allow for review, one can expect variances between it and the written blurb.--Wehwalt (talk) 13:35, 15 November 2021 (UTC)

  If there's a substantial difference, or an error of fact, the recording can be pulled (or even remade); but I think it's okay if there are more unimportant variances between the two. The recording still supplies the necessary information to the relevant people. I do agree that it's hard to make recordings so far in advance.theleekycauldron (talk • contribs) (they/them) 19:22, 15 November 2021 (UTC)

  I wouldn't want to see variances, even minor ones. The main page is supposed to have the most refined content, and having a different blurb and spoken version is something that could cause mild confusion for readers or arguments among editors (over whether or not a variation is minor). {{u|Sdkb}} ^talk 02:11, 16 November 2021 (UTC)

• Oppose. Moving to a !vote since the discussion above has failed to articulate compelling reasons (accessibility-related or otherwise) that we would want to do this. The "meh, it doesn't seem useful but wouldn't do any harm either" position is tempting, but I can't buy that either. As we've been experiencing (sometimes painfully) with the book and portal namespaces over the past few years, even when editing/engaging in an area is optional, there are costs to having it around in maintenance, diverted attention, clutter, etc. Fundamentally, this is not worth it. {{u|Sdkb}} ^talk 02:21, 16 November 2021 (UTC)

  I don't think one can compare this to books or portals. Both of these need active maintenance, while the contents of this proposal seemingly do not. Dege31 (talk) 16:32, 16 November 2021 (UTC)

• Lean oppose. This seems like busywork that we don't even know if there are people who'd volunteer for it. I think the option to add audio to the blurb is ok, but only if it's a cut from the existing spoken article, assuming the content matches. Otherwise, it's more work for very little gain. Dege31 (talk) 16:40, 16 November 2021 (UTC)

@User:Dege31Speculation. I believe there's only one way to find out, and that's to give it a try for a week or so, and then have people weigh in on the tangible results.Gallomimia (talk) 17:38, 28 November 2021 (UTC)

• Oppose. Project Spoken Wikipedia, while done out of good faith, was largely a misguided way to direct volunteer time, and doing the same for blurbs would have the same problems. Most blind people who wish to listen to an article would actually rather hear the up-to-date version spoken by a controllable machine reader which can go at the desired pace, accent, and so on of the listener, not a snapshot made three years ago by an unknown speaker. I suppose the risk of "vandalism" would be less for the front page version, but this seems like misspent effort - very, very, very few people would be interested in this, yet it wouldn't really achieve much for accessibility. And unlike article recordings, these front page blurbs would be used one day and then never again. SnowFire (talk) 19:23, 18 November 2021 (UTC)
  • Agree with SnowFire. ProcrastinatingReader (talk) 02:58, 21 November 2021 (UTC)
• I don't see why this is better than using a screen reader. User:力 (powera, π, ν) 01:38, 21 November 2021 (UTC)
• Oppose—a screen reader would be preferable as SnowFire explains. Imzadi 1979 → 03:10, 21 November 2021 (UTC)
• Oppose: I am not too familiar with this area and it seemed like a grand idea --- until --- issues were brought to light that derailed it. Unless there was some compelling solution to issues mentioned by Wehwalt then I can see some corrections not being updated in the audio resulting in "variances" as mentioned by Sdkb. I would imagine an editor making last-minute changes could (a stretch) simply remove the audio but consistency and convenience would seem to mandate it should be there all the time or not at all. -- Otr500 (talk) 03:31, 22 November 2021 (UTC)
• Support (with caveats) - Wikipedia is one of the least accessible websites there is, making it more accessible is always a good thing. When I visit other websites, and they have a "Listen to this article" option, I always always use it rather than my screen reader. For me, a human voice is preferable over a machine translation. But, here's my caveat, if it's not going to be consistent on a day to day basis, what's the point? Readers shouldn't land on the main page one day, and see this new feature and think, oh wow, look at Wikipedia stepping up their game, and then come back the next day and not find it, thinking, I knew it was too good to be true. Be consistent or don't do it at all. This is good advice for the whole project, audio articles help retain readers. Isaidnoway (talk) 13:57, 26 November 2021 (UTC)
• Support - Volunteer I put forward that none of us will really know whether it is a great idea or a terrible idea until we get a few blurbs read aloud and hear them, gauge how much work is involved, and compare this to the benefits reaped. I thus volunteer to do several blurbs, as I have found this work very beneficial to myself personally. If it's no better than a screen reader, we can discontinue.Gallomimia (talk) 17:35, 28 November 2021 (UTC)
• Oppose based on considered feedback of several above. First, if Graham87 doesn't see it as helpful, that is huge in my estimation. Second, the concerns raised by Wehwalt are very real and serious ... the blurb is changing even as it is on the mainpage, so this could be a very difficult wrinkle, and the TFA/mainpage/FA editors don't need another wrinkle to deal with on mainpage day. And I agree that doing all of this for a one-day event is misspent effort. Third, I agree that Spoken Wikipedia is well intended but quite misguided; I note how often even Featured articles have links to dated spoken versions on the article page. In the medical realm, this is really troubling, when we are linking to outdated info. So, I'm not really inclined to do something to advertise a project that isn't working as well as hoped. I could be persuaded otherwise if I thought this move would really benefit the visually impaired, but with Graham87 not on board, that pushes me definitively to oppose. SandyGeorgia (Talk) 17:47, 28 November 2021 (UTC)
• Oppose. Better to rely on text-to-speech tech, in which big corporations are investing millions of dollars. Adds a lot of complexity to the TFA process which, while I'm not personally familiar with it, I don't think is a walk in the park. Also sharing Sdkb about diverting editors' attention away from more central missions of the project. JBchrch talk 22:23, 3 December 2021 (UTC)
• Oppose as someone who makes Spokens. I would prefer only a few select ones that can be updated as time goes on for each user, of a high quality. Each blurb would most likely be rapidly made and quickly be outdated. I think Spoken Wikipedia may not serve an accessbility purpose anymore, as Graham has pointed out, but as just another format to absorb Wikipedia. If they are not of the quality and close to the date of the article it corresponds to, it really isn't useful to any listeners. And as a small tangent; SandyGeorgia, a lot of why the articles are old and outdated is that the project was dormant for a long time. I hope to get around to them at some point, but it is a serious problem. If they are that outdated, feel free to remove them I guess. Sennecaster (Chat) 19:19, 6 December 2021 (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.

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)

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)

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)

They are asking money for policy writing!

Sorry if it is not right place for this kind of post. This is not related to enwiki but i thought i should share. While browsing on meta, this rapid grant proposal caught my attention. They are asking money for policy writing on their wiki! It suppose to be created by community discussions and consensus by volunteers and not as paid job. If wmf fund this proposal, i guess, wmf should start paying all wiki (including enwiki) editors for on-wiki works like policy making you guys do here. --আফতাবুজ্জামান (talk) 15:12, 7 December 2021 (UTC)

It’s just a “proposal” (ie someone’s suggestion). It is unlikely to be approved or implemented. Blueboar (talk) 15:17, 7 December 2021 (UTC)

Pinging @SGill (WMF) Whatamidoing (WMF) (talk) 19:13, 7 December 2021 (UTC)

Hello everyone, I am advising on this project in my volunteer capacity. My username has been changed to my volunteer account on the proposal itself.Also, this project is not about writing the policy by one person but rather helping coordinate with the community and experts to co-create various policies. Workshops with other community members to educate them about the policies and organizing further events is a major component of this project. Satdeep Gill (talk • contribs 10:50, 14 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)

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)

Cosmic Dawn and Reionization two items or one only

Good morning,
I a not a scientific but it is possible to have two articles. Cosmic Dawn matches several and many more results in Google in English. The french translation of Cosmic Dawn i.e Aube Cosmique matches more and more results. I will reading you. Thank's and best regards, Mike Coppolano (talk) 14:41, 12 December 2021 (UTC)

As that seems to be a question of content, the place to talk about this Talk:Reionization. This page is about suggestions for larger changes. I suspect I am not the only one here who would have absolutely no idea about the appropriateness of splitting that article. — JohnFromPinckney (talk / edits) 19:26, 12 December 2021 (UTC)

Thanks ! Have a good day, Mike Coppolano (talk) 05:04, 21 December 2021 (UTC)

Cite Web & WP:RS

When using the Cite template forms, especially in the article text editor, submitting the URL should not only return title, author, but also a red, green, yellow, or blue, indicating its reliablity status, if known. .... 0mtwb9gd5wx (talk) 05:42, 13 December 2021 (UTC)

• This probably should go in VPI for further fleshing out, as it doesn't propose a methodology, or how to handle cases where a source has heavily mixed reliability statuses, but would be an interesting add-on. Nosebagbear (talk) 09:15, 13 December 2021 (UTC)
• You might be interested in the CiteUnseen user script. – Joe (talk) 10:27, 13 December 2021 (UTC)
• Or WP:UPSD if you're interesting in finding out about bad sources. Highlighting "good" sources in green is problematic, because no source is always reliable for all information. Headbomb {t · c · p · b} 00:40, 14 December 2021 (UTC)

  No source is always reliable, and no source is always unreliable, because reliability always depends on the relationship between the source and the material you're supporting. There are sources that have a very high (or low) probability of being reliable for typical statements that editors might use them for, but even the most unlikely sources – self-published, non-expert, non-independent, and primary – can be reliable for certain statements. See just about everything using Template:Cite tweet or Template:Cite instagram for proof. WhatamIdoing (talk) 01:39, 14 December 2021 (UTC)

  In addition, even the sources that are blacklisted are sometimes (albeit rarely) appropriate to use, for example in an WP:ABOUTSELF manner, and while you could hazard a guess that if the name of the source matches the name of the article that it's being used in that manner this isn't always the case, nor is that the only place ABOUTSELF may be used. Thryduulf (talk) 03:07, 14 December 2021 (UTC)

This is a very interesting idea, which is essentially asking for WP:RefToolbar to have some some (un)reliable source detection. The good part is that RefToolbar is a community-maintained gadget and so it can be implemented without any changes in mediawiki software (which are well known to take a lot of time to be implemented and approved). Any colour indicators would only indicate likely reliability or unreliability, so I don't see exceptions and edge cases as being problematic. – SD0001 (talk) 06:53, 14 December 2021 (UTC)

There is no source that is a priori reliable. There are sources with a history of prior reliability. This is entirely irrelevant when it comes to supporting a new wikitext claim. The fact that certain sources have been historically reliable in no way elevates reliability of a new, particular claim backed by the same source. Reliability trends do not predict the reliability of individual new claims any more than they predict the next outcome of a coin toss. And every citation must be reliable in its context. The aggregate or average or trend being "generally reliable" just won't cut it. Every wikitext claim must be reliably proven. A "reliability list" or "reliability algorithm" or "reliability bot" will not do. This is too important to be relegated. If you want to help the project, you, personally, have to do the work. There is an exception: when the exact same claim has been made in the past, and has been unambiguously proven correct using the exact same source. For that case only, the particular source is currently (per the available information) considered reliable. Until perhaps contrary information emerges. 74.64.150.19 (talk) 12:59, 14 December 2021 (UTC)

I think the OP has only suggested colour indicators to highlight general reliability status of the source. No one has suggested blocking inclusion of such sources by the software or bot. – SD0001 (talk) 14:20, 14 December 2021 (UTC)

There can be no such thing. As noted above, the reliability of the source is relative to the context of the citation and the corresponding claims made in wikitext. This is not a one-to-many relationship. Apart from the exception, also noted above, of a repeated claim supported by the same citation. 65.88.88.47 (talk) 15:21, 14 December 2021 (UTC)

Even if we all agree that the tool will "only indicate likely reliability or unreliability", it will be enforced by POV pushers and others as an absolute thing. Headbomb has spent put a lot of effort into the UPSD script, several of us have helped to make the documentation as clear as we can, and he still has to tell far too many experienced to stop blindly rejecting everything that the script highlights in its "50–50 chance" category. WhatamIdoing (talk) 21:54, 14 December 2021 (UTC)

Agreed. But I would tweak the terminology. There are sources proven reliable after the fact and sources likely unreliable before, with varying degree of unreliability. For any given citation, only unreliable sources have degrees or likelihoods. And for any given citation, reliable sources are just that. They are no more or less likely to be what they are. 71.105.141.131 (talk) 02:30, 15 December 2021 (UTC)

This basically isn't true. RSP says that the Associated Press is generally reliable, right? But if you cite any newspaper article from that highly reputable, officially-generally-reliable news source to support a sentence like "25% of cigarette smokers get lung cancer", then you'll be reverted because news media are not reliable sources for biomedical information. You can't say whether a source is reliable until you know what the Wikipedia content is. WhatamIdoing (talk) 19:04, 17 December 2021 (UTC)

The phrase "generally reliable" does not help one bit in elevating any citation. It means nothing, because the citation in question may not fall under such a "general" case, and there is no proper criteria to measure what constitutes "general" reliability. Past performance in no way guarantees the specific reliability of the next citation, unless one is gullible. You just have to work at it carefully, each time. Take a sentence like "25% of cigarette smokers get lung cancer" in wikitext. First, if it depends on a news source, it should be made clear. Say it is published in a general-interest high-circulation newspaper like the New York Times. Is this part of an opinion piece, an analysis, or is it straight reporting? Different types of news stories may employ different sources. A straight report may be based on an interview with a known, published expert in the field. A news analysis may be sourced from an official medical report. This is easy. You can easily ascertain whether the New York Times is reliable in this case, all you have to do is look at the primary source (assuming it is publicly accessible). You can do that in a million articles and prove the NYT reliable, and still, the next analysis/report may get the numbers or the quotes or the context wrong. If you state in wikitext "according to a New York Times analysis/report based on official medical records/interview with this expert etc. etc." this is a conditional statement, not a positive one. You give the wiki reader the option to accept it as relevant or accurate or neither, but it may be important in showing how general mass media may present the subject. Such a citation can be produced (and verified) easily. The gist of it is, "generally reliable" is a meaningless statement. Unlike say, "generally unreliable", which is a good starting point. 65.88.88.93 (talk) 20:25, 17 December 2021 (UTC)

In addition to WAID's points, we have sources listed at WP:RSP whose reliability varies by context, e.g. Fox News should only be used "with caution" for politics and science where it is regarded as a biased source, it is regarded as generally reliable for other news topics, and its talk shows "should not be used for statements of fact but can sometimes be used for attributed opinions." I don't know how any automated tool could correctly label a citation to FoxNews. The RSP entry for China Daily is going to be even trickier for a bot to parse let alone implement. Thryduulf (talk) 16:06, 21 December 2021 (UTC)

WP:RSPSS is worthless as a reliability predictor. It is a list based on historical data that assigns reliability based on past experience but also other considerations that are largely opaque to the reader. Its existence may induce confirmation bias in cases where editors 1. rely on it instead of doing proper context-based research of the source for a specific citation or 2. rely on it to engage in improper presentation. Any news organization that covers politics may have a declared or implied bias when it comes to such coverage. Mass commercial media such as CNN or Fox News cater to specific population segments representing opposing political opinions. This built-in bias is enough to make both likely unreliable in this area. This reliability-diminishing bias has to be made clear in wikitext describing political coverage: "according to liberal-leaning CNN/conservative-leaning Fox ..." etc. That is not to say that non-commercial political news sources are a priori reliable or unbiased. On the contrary. 65.88.88.47 (talk) 16:32, 21 December 2021 (UTC)

it will be enforced by POV pushers and others as an absolute thing That's a problem with the POV pushers. Every kind of technology can be abused. It's like saying we should not use the internet because hackers will then find ways to attack us. – SD0001 (talk) 17:53, 15 December 2021 (UTC)

It's also like saying that before we create and deploy a tool that we already know has a high potential for abuse, we should figure out whether it's going to cause more problems than it's worth. WhatamIdoing (talk) 18:59, 17 December 2021 (UTC)

The rationale regarding the tool's creation is wrong, not its usage. Proof of reliability is not conducive to automation. The proposal seems to treat sources as static items with uniform fixed qualities. This approach is already suspect, as one inviting confirmation bias. 65.88.88.93 (talk) 20:37, 17 December 2021 (UTC)

Automatically convert $ values for inflation.

https://en.wikipedia.org/wiki/Maximum_Overdrive for example should read $9 million (1986) => $22 million (2021)

What price index should be used for the conversion? 65.88.88.76 (talk) 19:14, 14 December 2021 (UTC)

The {{inflation}} template can be used for this. clpo13_(talk) 19:20, 14 December 2021 (UTC)