Misplaced Pages

Revision as of 04:19, 9 February 2021

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

• WP:VPR
• WP:VP/PR
• WP:VPPRO
• WP:PROPS

New proposals are discussed here. 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 WikiProjects or task forces may be submitted at Misplaced Pages:WikiProject Council/Proposals.
• Proposed new wikis belong at meta:Proposals for new projects.
• Proposed new articles belong at Misplaced Pages:Requested articles.
• Discussions or proposals which warrant the attention or involvement of the Wikimedia Foundation belong at Misplaced Pages:Village pump (WMF).
• Software changes which have consensus should be filed at Phabricator.

Discussions are automatically archived after remaining inactive for nine days.

Village pumps

policy

tech

proposals

idea lab

WMF

misc

• Refining the administrator elections process
• Blocks for promotional activity outside of mainspace

• view
• edit
• history
• watch
• archive
• talk
• purge

RfC: What to do with category links to Commons?

What should we do with the links to Commons in categories? Mike Peel (talk) 09:23, 12 December 2020 (UTC)

Hi all. We currently link from categories here to Wikimedia Commons categories using {{Commons category}}. Over the last few years, we have been working on synchronizing the links to Commons categories between enwp and Wikidata, and for the Category namespace these are now fully synchronized. These links use sitelinks on Wikidata, which are robust against vandalism (a Commons category has to exist to sitelink to it), and these also match the sidebar link to Commons. They are also used to display links back to enwp from the Commons categories (both in the sidebar and the infoboxes there).

In 2018 I posted an RfC to switch to using Wikidata for interwiki links to Wikimedia Commons, which led to conditional approval to implement the changes here, and the creation of a new set of tracking categories at Category:Commons category Wikidata tracking categories. A subsequent RfC in 2019 on removing locally-defined links to Commons categories if they match the Wikidata sitelinks resulted in no consensus to remove locally defined links to Commons.

I would like to revisit this as it applies to categories only (i.e., this proposal does not apply to articles). At some future point this may also be applied to articles, but for those we need to fix the issue that causes Commons sitelinks to not appear in the sidebar (on the Community Wishlist Survey 2021), and there are ~15k articles that aren't synchronised to Wikidata yet (cases with e.g., multiple, mismatched, or misplaced links) out of 560k articles. These are not issues for links in the Category namespace, which are now fully synchronized with Wikidata.

Changes to current links

I suggest the following options for the use of {{Commons category}}, which would only apply in the Category namespace:

A1. Remove {{Commons category}} and just have the sidebar link. This is the easiest option to maintain here as MediaWiki will automatically display it where available. This would affect around 310k categories (the tracking categories listed in A2 and A3). An example of how the Commons link would look like after this change is Category:1817 in Vermont.

A2. Remove the locally defined links from categories, i.e., {{Commons category|Example}} -> {{Commons category}}. This is the second easiest to maintain, as e.g., renames of categories will be automatically updated. Manually defined links would only be removed where they match the Commons sitelink on Wikidata, so this would also allow local overrides. This would affect around 290k categories at Category:Commons category link is on Wikidata. An example of how the Commons link would look like after this change is Category:Data modeling.

A3. Always locally define the link, i.e., {{Commons category}} -> {{Commons category|Example}}. This is the most difficult to maintain, as it requires bot or manual edits when the link changes. This would affect around 20k categories at Category:Commons category link from Wikidata. An example of how the Commons link would look like after this change is Category:Bodies of water of Lebanon.

Adding new links

I also propose:

B. Bot-adding {{Commons category}} where a Commons category sitelink is available on Wikidata

Many links have been added between Wikidata and Commons over the last few years (now totaling over 3 million links). If we go for (A2) or (A3) above, then bot-adding them would significantly increase the number of links to Commons. These links are already available in the sidebar, so if we go for (A1) above then this isn't needed. Mike Peel (talk) 19:52, 11 December 2020 (UTC)

Discussion (Commons category links)

I suggest !voting for A1, A2 or A3 and saying yes/no to B. If we reach consensus for any of these options, I will code a bot to implement it and propose it at Misplaced Pages:Bot requests for final discussion before implementation. Thanks. Mike Peel (talk) 19:52, 11 December 2020 (UTC)

It's not clear from the RFC as written which options would still allow us to customise the displayed text and whether we could link to multiple categories, both of which are something that arises fairly often (Commons has a slight tendency to split categories so we want to provide links to more than one, and has a very strong tendency to give categories really peculiar names which don't tally with the English common name). I'd be strongly inclined to reject any option that wouldn't allow us at minimum to add explanatory text to the link (e.g. for an biography of an architect, have one link for portraits of the subject and one link for images of their buildings, clearly labelled which is which). ‑ Iridescent 20:15, 11 December 2020 (UTC)

@Iridescent: Those are rare occurrences in categories (but somewhat more common in articles, which is out of scope for this RfC). I can implement something for A2 that will continue to allow customised display text if really necessary, but that can easily be used to mislead the reader. Linking to multiple categories never makes sense anyway, since you can either link directly to the appropriate category from "Category:Buildings by X", or just link to 'Category:X" for the architect, and readers can then look at the subcategories on Commons for the rest - or you can improve the categories in Commons. Thanks. Mike Peel (talk) 21:02, 11 December 2020 (UTC)

P.S., are those intentionally missing links noted/explained somewhere, please? If not, perhaps they could be noted somehow? Thanks. Mike Peel (talk) 21:34, 11 December 2020 (UTC)

@Mike Peel: what is your brief and neutral statement? At over 4,500 bytes, the statement above (from the {{rfc}} tag to the next timestamp) is far too long for Legobot (talk · contribs) to handle, and so it is not being shown correctly at Misplaced Pages:Requests for comment/Wikipedia technical issues and templates. --Redrose64 🌹 (talk) 23:37, 11 December 2020 (UTC)

@Redrose64: The title was kinda the summary, I've paraphrased it just below the RfC tag for the bot. Thanks. Mike Peel (talk) 09:23, 12 December 2020 (UTC)

Just to note, I've posted a neutral note about this RfC at commons:Commons:Village_pump#Commons_links_from_enwp_categories (diff), since this directly relates to Commons. Thanks. Mike Peel (talk) 20:11, 12 December 2020 (UTC)

• I'm not sure why this was bot-archived while still running, I've manually unarchived it. Thanks. Mike Peel (talk) 13:04, 31 December 2020 (UTC)

  belated @Mike Peel: It was archived at 02:40, 30 December 2020 (UTC) because there had been no posts since 18:17, 20 December 2020 (UTC), and the archiving settings (that's the {{User:MiszaBot/config}} at the top of this page) include the parameter |algo=old(9d), which means that any thread which has had no new posts for at least nine days is eligible for archiving. Archiving bots cannot tell if a discussion is running or not - they simply look at the most recent timestamp. --Redrose64 🌹 (talk) 20:11, 17 January 2021 (UTC)

• Just to note that I've requested a closure for this at Misplaced Pages:Administrators' noticeboard/Requests for closure. Thanks. Mike Peel (talk) 12:59, 22 January 2021 (UTC)
  • Still pending someone to close this... Thanks. Mike Peel (talk) 11:34, 2 February 2021 (UTC)
    • Ditto. Mike Peel (talk) 21:12, 8 February 2021 (UTC)

Survey (Commons category links)

• Oppose A1 without even blinking. I'm certain 99.9% of readers aren't aware the sidebar is even there, and on a topic with a lot of interlanguage links readers are never going to see it. Weakly oppose A2 as I can't see any particular advantage to removing the ability to override the displayed label. If these are the only three alternatives then support A3, although I could accept A2 provided there were a means to override or disable it in circumstances where what's on Wikidata isn't considered appropriate. Definitely oppose B, as there are occasions when we intentionally don't link to Commons for a given subject. ‑ Iridescent 20:18, 11 December 2020 (UTC)

  @Iridescent: As stated in the A2 description, "this would also allow local overrides". Thanks. Mike Peel (talk) 09:17, 12 December 2020 (UTC)

• Oppose A1 and Support A3 To always have local control over the destination of the link, makes it easier for users. Keith D (talk) 20:30, 11 December 2020 (UTC)

  @Keith D: Can you elaborate on how that 'makes it easier for users' please? Thanks. Mike Peel (talk) 21:03, 11 December 2020 (UTC)

• Concern (not opposition)... We here at WP.en have become very leery of linking to Wikidata (in any form). There are times when the two projects just don’t seem to speak the same language, and that has caused headaches for both projects. I have no idea if this is an exception or not... but please go with caution. Blueboar (talk) 01:28, 12 December 2020 (UTC)
• Support A1 is the easiest to maintain with the tools at our disposal and with common sense protections against vandalism. A1 is a question of getting used to it and knowing where to look. The template can have a deprecation period where it says "See sidebar left for link to Commons" to help educate during the transition period. Failing A1, would also support A2 w/ Bot add (sigh.. see how much better A1 is?). Oppose A3. -- GreenC 02:38, 12 December 2020 (UTC)

  Genuine question and not being snotty, but how do you think "getting used to it" would work? In the skin in which more than 50% of readers see Misplaced Pages, A1 wouldn't just change the location of the link but would remove it altogether; from the perspective of readers this wouldn't be a matter of looking somewhere else to navigate to Commons, but of Commons suddenly apparently ceasing to exist. (Existing readers would probably know to ask where it had gone, but new readers would have no reason to suspect the links ever existed.) Plus, Misplaced Pages doesn't just have a single cohort of readers; new people discover us all the time. Most people viewing a category have either got there via a search or via the links on a Misplaced Pages article and aren't insiders who understand the quirks of MediaWiki, and "the links from Misplaced Pages pages to related content appear on that page" is a very well-established convention reinforced by 20 years of categories and navbox templates. A typical reader couldn't possibly be expected to know that if they're looking for the media associated with a category, they need to switch to desktop view if they're not already there, and then once there click a cryptic "In other projects: Wikimedia Commons" link hidden in the sidebar. ‑ Iridescent 06:40, 12 December 2020 (UTC)

  Ouch, that's a pretty major bug. I hadn't noticed that since I never use the mobile interface. I had a look on Phabricator to see if there was an existing bug report, but I couldn't find one, so I've started phab:T269992. Thanks. Mike Peel (talk) 09:17, 12 December 2020 (UTC)

  Repeating my plug for the gadget discussed here which adds a one-click button to preview how pages will look to readers (who mostly use the mobile view) rather than editors (who rarely if ever do). You'll be astonished how many things you take for granted are either missing completely or behave completely differently (see what a mess User:Mike Peel looks in mobile view, for an obvious example). If I had my way we'd deprecate mobile view and start again from scratch—I think the current skin is irredeemably bad both for readers and for editors—but I can't imagine the WMF ever admitting that a pet project they've spent a decade promoting is a complete lemon. ‑ Iridescent 13:22, 12 December 2020 (UTC)

• Support A1. The Commons link is just one example of the "other projects" links, and displaying them automatically as part of the user interface makes more sense than adding one or more templates to every category. If the mobile interface isn't displaying these links, then it should be fixed. Perhaps removal of the existing templates should be delayed until it's fixed. ghouston (talk) 02:18, 13 December 2020 (UTC)
• Oppose A1, Oppose A2, Support A3 To always have local control over the destination of the link, makes it easier for users. As Keith_D put it. Or, as I put it during the last RFC: Oppose. Kerry put it well. I have long been troubled by persistent efforts for systematic bulk deletion of content from Misplaced Pages, in favor of obscure remote-ownership of everything by the bot-farm known as Wikidata. One of these days we need to reach a community consensus on the practice in general. Either we should transfer everything possible over to Wikidata and accept that that Wikidata is going to manage everything from now on, or we need to roll back Wikidata to tracking-categories and rare purposes of specific value. This endless struggle to roll Wikidata forwards (or backwards) one inch at a time is wasteful at best and disruptive at worst. Alsee (talk) 16:26, 8 May 2019 (UTC) A tiny number of Wikidata enthusiasts have been persistently trying to bulk-delete content screwing over other editors in a holy crusade to make Wikidata lord&ruler of all they survey. Among other problems, the typical editor is going hit CTRL-F trying to find the content they want to change, and it wouldn't be there. They maybe eventually find the would-be-completely-useless template in the wikitext, but there would be no value there. The editor is left stranded with an impossible edit, absolutely no indication anywhere WTF is going on, and no path forward. Alsee (talk) 16:31, 13 December 2020 (UTC)
• Support A2 and B. The typical editor does not need to edit technical interproject links. Ruslik_Zero 20:38, 13 December 2020 (UTC)
• Oppose A1, Oppose A2, Support A3 noting that we would need to explicitly discourage well-meaning editors removing labels "because it's on Wikidata", as has already happened with the A3 example. Sometimes the difference between the Commons category name and the local name is going to be jarring, all the more so if this is used as a precedent for changing how Commons category links are presented in articles: Commons has a more worldwide focus on titling categories than any individual Misplaced Pages has on titling pages, and has evolved different conventions as a result, and although this doesn't arise much on categories ("in" vs. "of" Lebanon in the A3 example is barely noticeable), it will be jarring in the cases where it does matter. I've frequently created categories on Commons with different names from the Misplaced Pages articles, for example using a disambiguator instead of "The". On the broad issue, concur with Alsee; having what the reader sees on a page determined at Wikidata rather than on the individual project is unacceptably risky with regards to vandalism or simple error (I corrected a Wikidata description in Dutch the other day that assigned something to the wrong US state) and makes editing unacceptably difficult; "anyone can edit" is one of our foundational principles, we want readers to be drawn to correct or update something and have the satisfaction of seeing their change live, and we want those who add or expand something to fix things linked to it (WP:SOFIXIT). Wikidata is intentionally behind a steep accessibility wall because it's a thing for information professionals and because errors there potentially affect all the projects. So I must oppose A2 and especially A1 (Iridescent's point being also hugely important regarding A1, and I am astonished the WMF was unaware of it). That said, I can see no harm in the bot run so long as we retain the ability to pipe the links when our category moves to a new title and no longer matches that at Wikidata: support B providing A3 is implemented. Yngvadottir (talk) 21:01, 13 December 2020 (UTC)
• Oppose A1, Oppose A2, Support A3 Local control provides needed flexibility. Another aspect is language - my impression Commons tends yo make more use of local language names where as enWikipedia often uses names translated into English - more likely to cause category names to need local control. Changes other than A3 assume a 1-to-1 correspondence between Misplaced Pages articles and Commons Categories; there have been Misplaced Pages changed where I've wanted to add more than one Commons Category link. PsamatheM (talk) 23:21, 13 December 2020 (UTC)
• As nominator, in case it wasn't obvious, my long term preference is A1 (but that bug with the mobile site needs to be fixed first), right now I would prefer A2 since it minimises data duplication - which is the fundamental problem here. If you have multiple copies of the same data, then you have to fix each of them separately. By storing that link on Wikidata, in the same way as we store interwikis there, is the simplest option: it is then the same dataset here, on Wikidata, and on Commons (where that link is used to display the multilingual infobox). Then there are more eyes on the links, and more chance that someone will spot bad links and fix them. I'm saying this as someone that has gone through and corrected thousands of incorrect commons links from enwp over the last year.

I could live with A3 if needed, but it means continuing to bot/manually sync changes between Commons/Wikidata/here, which is just duplicate effort. Vandalism-wise, using the sitelinks/interwiki links is the safest way, since the category has to exist to be linked to (you can't change it to any random bit of text). There are currently no categories that link to multiple Commons categories, and there should rarely be a need to do that - but A2 would still let that be possible if needed. Similar with local text if really needed (but Commons category names are English by default). A tiny number of Wikidata-haters tend to trot out the same rhetoric whenever Wikidata is mentioned, which isn't really helpful (it's like arguing that all websites should go back to static rendering rather than using databases: it doesn't scale). With B, I'm happy either way - if we don't do that, I don't have to code up the bot, but we also don't get a lot more links to Commons (and bear in mind these have historically been bot-added to categories anyway). Thanks. Mike Peel (talk) 18:05, 14 December 2020 (UTC)

• Support A2. This is the best of both worlds option. It eliminates a need to maintain two different systems to link a WP category to its equivalent Commons category, but also allows flexibility and control in handling special cases. – Finnusertop (talk ⋅ contribs) 16:42, 15 December 2020 (UTC)
• Oppose A1 unless and until the mobile view is fixed (as per the nominator). Support A2 provided it isn't seen as a step to not allowing local over-riding, which will remain necessary for all the reasons others have explained above. Peter coxhead (talk) 17:50, 15 December 2020 (UTC)
• Oppose A1, week oppose on A2 and support A3 for the reasons outlined by Iridescent. -- Euryalus (talk) 23:12, 15 December 2020 (UTC)
• Oppose A1, A2, B, - Support A3 for reasons above already given. Only in death does duty end (talk) 15:36, 16 December 2020 (UTC)
• Oppose A1 and A2 (very strongly), B, - Support A3 per Iri & others above. The problem with A2 is that (as I understand it) the current category links will all be removed, and the "local overides" would have to manually re-added. "Matching Wikidata" is a totally untrustworthy test. This would be a nightmare. Johnbod (talk) 15:44, 16 December 2020 (UTC)

  @Johnbod: The check is that the links between enwp + Wikidata + Commons are all in sync, not just 'matching Wikidata'. If you disagree with the link, then in A2 you would have to fix the link (e.g., by adding the local override, which we'd then check and correct on Wikidata/Commons - or better by fixing it on Wikidata so it's then fixed everywhere), or in A3 then you would have to fix the link (e.g., by changing the local override, which we'd then check and correct on Wikidata/Commons). Either way, the work you would have to do is very similar, it's hardly a nightmare. Reminder that enwp/wikidata is currently 100% synced for the categories we're talking about. Thanks. Mike Peel (talk) 20:44, 16 December 2020 (UTC)

• Weekly Oppose A1, Strongly support A2 and Strongly Oppose A3 as explained hereafter
  • Weekly Oppose A1 indeed the links to the other wikimedia projects are from my point of view not visible enough for wikipedia readers in order to lead them to click on this link in the side menu.Robby (talk) 21:50, 19 December 2020 (UTC)
  • Strongly support A2 from my point of view this is at this moment the best solution. Robby (talk) 21:53, 19 December 2020 (UTC)
  • Strongly Oppose A3 indeed this will result in an endless workk by both bots and manual che3ck for categories deleted respectively moved on Commons.Robby (talk) 22:33, 19 December 2020 (UTC)
• I generally support A1, but I think that's a question better left for a more general RFC on the boxes we put at the ends of articles. I also support A2 as a minimum result since it removes duplication of what is just another interwiki link at the end of the day, which we already accepted managing interwiki links at Wikidata. Hard oppose A3. I also oppose B as I do not want to see a continuing spread of these boxes; secondarily, enforcing the inclusion by bot of these seems to override the apparent editors' will in editing particular pages. --Izno (talk) 18:17, 20 December 2020 (UTC)
• Support A2 for better visibility of the connection, but A1 is okay for me too. We should leverage Wikidata as much as possible in uncontroversial scenarios like this one. --MarioGom (talk) 14:16, 4 January 2021 (UTC)
• Oppose A1, Support A2, Neutral A3, Support B. This gives the best combination of visibility and avoiding unnecessary duplication of effort. Thryduulf (talk) 16:05, 9 January 2021 (UTC)
• I don't care too much about A1-A3 (though I think that local definition is better, goals of en.wikipedia and wikidata do not always align and definitions are sometimes different). I however strongly oppose any automated or blind additions of the 'commons category' (and I guess that is then also an agreement with selective A1). There are many cases where commons category has nothing that is adding to our articles (all images are already used, and, albeit in rare cases, commons has less than what en.wikipedia has), and sending people off to commons to find less (or the same) than what is here is silly and just clogging our articles (especially when you get the whole series of sisterlinks). Note that commons sometimes has different croppings of 1 image, so even if the number of images on commons is higher, it still does not add. --Dirk Beetstra 14:11, 10 January 2021 (UTC)
• A3 (and A2 when the names are the same). Commons categories too often do not have names that match ours.  — SMcCandlish ☏ ¢ 😼  08:33, 15 January 2021 (UTC)
• Oppose A1 and A2. And support A3. And support B but only if it says "Bot-added link". And Mike Peel, please stop removing commons category links that don't exactly match up with the English article name or English article categories. See this diff. You don't have that authority as far as I know. It is an example of why a bot shouldn't be removing commons categories. Humans like you shouldn't be doing it either. I noticed from your contributions that you are on a bot-like spree in doing so. Just because you are an admin doesn't mean you have the right to do so. Show me the guideline. I have tens of thousands of edits on both the commons and Misplaced Pages. I know many of these attempts at synchronization will not work due to the many idiosyncrasies of Commons work and Misplaced Pages work. I prefer an additive approach. Let the bot add commons links, but not let a bot remove commons links. --Timeshifter (talk) 04:18, 9 February 2021 (UTC)

RfC: Should we have Support/Oppose/etc. survey convenience templates?

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.

Should we have survey convenience templates? Mike Peel (talk) 22:07, 1 January 2021 (UTC)

While WP:NOTVOTE is really important, we have a lot of discussions/debates (like this one) that people Support/Oppose and comment on. A lot of the Wikimedia projects use templates like {{Support}}, {{Oppose}} etc. to help with this, often also including a symbol. These templates were deleted here back in 2005, mostly because people objected to the inclusion of the symbol.

In this RfC I propose restoring these templates but without the symbol. This would mean that editors could use {{Support}} rather than '''Support''', but it would look the same. It would not be compulsory to use one or the other, and of course the !vote should be accompanied by a rationale regardless. The templates would simply be a convenience for editors that are used to using the other syntax, and would avoid a lot of follow-up edits to fix formatting after trying to use the templates instead of the bold formatting (which I at least frequently do, either after saving or in preview!). Their use would have negligible impact on server load (another concern from 2005), but could easily be bot-substituted (by batches every day/week/month) if that really is still a concern.

(These templates have been frequently recreated since their deletion, to the extent that it is a perennial request (the difference with this !vote is that it's to meet cross-wiki expectations, and I'm not proposing to use icons). I originally took this to WP:DRV last month as per the latest deletion/protection edit summaries, but an RfC was recommended instead.)

Thanks. Mike Peel (talk) 22:07, 1 January 2021 (UTC)

Survey (survey convenience templates)

• {{Support}} as proposer. Thanks. Mike Peel (talk) 22:07, 1 January 2021 (UTC)
• Oppose As I would typically say in TfD, insufficient complexity of markup to warrant a template. I completely fail to see the point of creating a template whose content is its name with three apostrophes prepended and appended, when that is only two characters longer than typing the wikitext out in the first place. * Pppery * _{it has begun...} 22:27, 1 January 2021 (UTC)

• @Pppery: It's not about the number of characters, it's about the time it takes to remember the syntax, and that the syntax shouldn't depend on which Wikimedia project you are using. The human cost is much more than the syntax cost. It's the same as {{tq}} vs. this alternative way of writing it. Thanks. Mike Peel (talk) 22:38, 1 January 2021 (UTC)

• I would prefer to type “ {{Support}}” rather than “'''Support'''” because the “'” character is not on the iPad keyboard. {{Support}} could be made to auto-subst. Oppose cut or gaudy pictures. —SmokeyJoe (talk) 23:05, 1 January 2021 (UTC)
  • my iPad allows me to type a '. Switch the keyboard to punctuation, then press and hold the ‘ key. The pop up menu offers you 4 differs types of quote symbol — GhostInTheMachine 23:36, 1 January 2021 (UTC)
    • That was a nice trick to learn! Thank you. Unfortunately, it is very tedious to do the six times. --SmokeyJoe (talk) 04:34, 2 January 2021 (UTC)
  • or just type Oppose, select the word and click the B on the editing toolbar — GhostInTheMachine 23:48, 1 January 2021 (UTC)
    • Yeah that works. Unfortunately, the toolbar is above the fold. I wish it could be moved to below the editing window. --SmokeyJoe (talk) 04:34, 2 January 2021 (UTC)
      • Or you could just try convincing people using words instead of syntax. —Cryptic 06:39, 2 January 2021 (UTC)
        • I like the simple bold of the lede word of the !vote. Do you dislike that low level of syntax? This !vote bolding culture underlies the working of https://afdstats.toolforge.org/, which is sometimes a nice tool. --SmokeyJoe (talk) 07:00, 2 January 2021 (UTC)
  • One possible work around is to use iOS's text replacement feature (Settings -> General -> Keyboard -> Text replacement). You can choose any sequence of characters to be replaced by another. For example, you could choose bqq to turn into ''' (three single quotes.) isaacl (talk) 20:23, 9 January 2021 (UTC)
• Oppose Sorry but no. I understand that moving between projects is a mental pain (I struggle with the equivalent of {{tl|xxx}} at Commons) but hiding simple syntax does not help the project. Some projects appear more focused on a vote count, and that idea should not be encouraged here. Johnuniq (talk) 23:08, 1 January 2021 (UTC)
• Oppose per Johnuniq's comments, especially about hiding syntax. We should not be encouraging anything that gives the impression that votes are more important than the rationale accompanying them. Thryduulf (talk) 23:14, 1 January 2021 (UTC)

  @Thryduulf: How exactly does the existance of a convenience template give that impression, please? Thanks. Mike Peel (talk) 21:07, 3 January 2021 (UTC)

  @Mike Peel: the existence of a template, regardless of the formatting it outputs, elevates the importance of that output - if it wasn't important then why would anybody make a template for it? Why would any template be kept if it wasn't adding something of value? Experienced editors will unlikely gain this impression, but that is not necessarily true of those who are new to Misplaced Pages or who have a limited understanding of how XfD discussions work (if there wasn't an impression they are votes then we wouldn't need boilerplates like {{not a vote}}). Thryduulf (talk) 23:57, 3 January 2021 (UTC)

  I disagree with that thinking, I don't think having the template would give any more weight to a new user's thinking that they can !vote than seeing a list of bold-formatted support/oppose votes that they could copy/paste would. Thanks. Mike Peel (talk) 09:30, 4 January 2021 (UTC)

• Oppose what would the Support template expand to, other than Support in bold? — GhostInTheMachine 23:45, 1 January 2021 (UTC)
  • I would have the string {{Support}} auto-change and substitute to '''Support'''. I would find it useful, for the same end result. --SmokeyJoe (talk) 04:34, 2 January 2021 (UTC)
• weak support I don't think it unreasonable request--no reason to make anyone's editing harder and it sounds like there are a few people it would help. That said, the help is minor and the worries about a slippery slope to voting aren't utterly trivial. So a small thing that helps people now vs. a very unlikely thing (but not impossible) that might hurt the culture down the road? I'm gently leaning toward the short-term gains being worth the improbable long-term risk. Hobit (talk) 04:32, 2 January 2021 (UTC)
• Oppose per Johnuniq ~ HAL333 04:45, 2 January 2021 (UTC)
• weak Support If we can have {{Agree}} and {{Disagree}} why not Support or Oppose? RudolfRed (talk) 05:03, 2 January 2021 (UTC)
  • Like this: {{agree|1=Support}} → Support. Now, how to lose the gaudy green tick? --SmokeyJoe (talk) 06:55, 2 January 2021 (UTC)
  • {{strong}}? {{strong|Support}} → Support. --SmokeyJoe (talk) 07:06, 2 January 2021 (UTC)
    • Does it substitute? {{subst:strong|Support}} → Support. --SmokeyJoe (talk) 07:46, 2 January 2021 (UTC)
      • <strong {{#if:|role="{{{role}}}"}} {{#if:|class="{{{class}}}"}} {{#if:|id="{{{id}}}"}} {{#if:|style="{{{style}}}"}} {{#if:|title="{{{title}}}"}}>Support</strong>. Oh dear, that's a mess of wikimarkup, isn't it. --SmokeyJoe (talk) 07:48, 2 January 2021 (UTC)
• Usually I eschew starting my comment with a bolded word, precisely to place emphasis on discussion over voting. Assuming the community is truly dedicated to making decisions through discussion, I do not favour having templates that give more prominence to votes. isaacl (talk) 07:18, 2 January 2021 (UTC)

  @Isaacl: the opposite is that there are so many words in a section that prefacing the section with a bold helps you know what to expect, especially in confusingly worded arguments you know better what they're trying to get at. eg when closing RfCs I don't necessarily close based on vote, but knowing a binary yes/no before a comment helps follow the comment and get a general feel of where the discussion lies. ProcrastinatingReader (talk) 19:20, 2 January 2021 (UTC)

  I wrote something similar once about how knowing where an argument is heading can help provide context and thus improve understanding. Nonetheless, it can be done with a thesis sentence, rather than a single bolded word. I appreciate many people like starting with a single bolded word. I believe, though, that it puts more emphasis on voting and tabulation of votes versus discussion. isaacl (talk) 19:28, 2 January 2021 (UTC)

  User:Isaacl, you are assuming that others find it as easy to read or write a thesis sentence as you do. E.g. people with dyslexia, ESL, inexperience with writing topic sentences) I personally struggle to summarise positions into a sentence for many reasons. It was also helpful to me as a new editor that there's a format which people are generally using to help me feel able to engage with discussions. --Xurizuri (talk) 11:33, 12 January 2021 (UTC)

  If someone can't, that's OK. Starting with "I support the proposal," is fine. If we're trying to encourage discussion amongst those who have opted to contribute to a writing project, though, I think it's reasonable to aspire for participants to craft a concise explanation of their viewpoint. Though it'll likely remain an ideal, it's a good target to aim for. isaacl (talk) 17:00, 12 January 2021 (UTC)

  The practice became widespread because editors felt it worked best. It has persisted because editors continue to feel it works best (for the most part, although many surely do it because they see others doing it). To my mind, there is no higher principle than that, and there is something to be said for consistency in formatting (some handle the variation better than others, and I'm in the latter group). But whether to use a bolded first word and whether to create templates for it are separate and independent questions. ―Mandruss ☎ 18:42, 12 January 2021 (UTC)

  Yes, as I said, I appreciate many people like to start their response with a bolded word. isaacl (talk) 01:01, 13 January 2021 (UTC)

• I'll support such templates, not because I'd use them myself, but I see no justification for preventing other people from using them. When instructions are given for how to participate in XFD discussions, a summary word in bold is suggested. On the rare occasions when I take part in such discussions on other wikis I have to go round searching other people's comments for the appropriate syntax so I can sympathise with the difficulties of occasional !voters here. Thincat (talk) 09:48, 2 January 2021 (UTC)
• Oppose. This is a good example of the failure to understand the cost of complexity in terms of barrier to entry. Multiple ways to accomplish the same thing is unnecessary complexity, unjustified by the perceived need to let every editor "have it their way" (apparently because they are unpaid). Anyway, the template syntax is no less prone to typing error than the markup. In the worst case the editor can omit the bolding and it may be fixed by another editor per TPO. To the extent that is not done, a few very rare cases of unbolded !votes are not a significant problem. ―Mandruss ☎ 11:29, 2 January 2021 (UTC)
• OPPOSE - The goal is simply to highlight what your opinion is. There are lots of ways to do this. As demonstrated here, ALL-CAPS works too. Blueboar (talk) 14:16, 2 January 2021 (UTC)
• To disincentivise plain voting, we could adopt these templates, but ensure they only output an empty string :) – Uanfala (talk) 16:56, 2 January 2021 (UTC)
• Oppose This is NOT a problem. No SOLUTION is necessary. GenQuest 22:02, 2 January 2021 (UTC)
• Oppose - per User:GenQuest and User:Mandruss (and probably a few others that I agree with for other points). Or, if you wish for greater detail, why would we decrease inconsistency between multiple projects by increasing inconsistency in one project? Having the same method for producing bold "oppose" and "support" as is used for making other things bold throughout Misplaced Pages is beneficial to the general run of users on Misplaced Pages.--Khajidha (talk) 00:33, 3 January 2021 (UTC)
• Support. Minimal implementation cost, minimal burden on other users, and well-defined use case. Thincat put it well. I understand the instinctual "no voting templates!" response, but there's no icon and no emphasis on the opinion. It would be a good idea to brainstorm ways to enforce current community norms around !voting if these templates are created, though. Enterprisey (talk!) 00:52, 3 January 2021 (UTC)
• Sure. If there are no icons, {{Support}} and {{Oppose}} become shortcuts for wiki markup. As with SmokeyJoe I use an iPad to edit Misplaced Pages, and typing {{Support}} would be slightly better for me than '''Support'''. I also agree on what Thincat and Enterprisey said. GMX (on the go) 16:00, 3 January 2021 (UTC)
• {{Support}} The cognitive dissonance of people typing '''Oppose''' in this discussion is remarkable. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:19, 3 January 2021 (UTC)
  • As one of the several people who have explained why a template producing the same output as '''Oppose''' is not desirable I find this ad hominem to be in rather bad taste. Thryduulf (talk) 20:40, 3 January 2021 (UTC)
    • @Thryduulf: Andy has a point here about how people comment regardless of the existence of the template, it's not an ad hominem. Thanks. Mike Peel (talk) 21:07, 3 January 2021 (UTC)
      • Effectively calling everyone idiots, without explaining why they're being called idiots, sort of looks like an ad hominem, doesn't it? – Uanfala (talk) 21:45, 3 January 2021 (UTC)
      • @Mike Peel: if Andy has a point other than insulting the intelligence of people with a different opinion on these templates to him then I am at a loss as to what it is. I can't prove it, obviously, but the impression I get is that he has read only the bolded words (which would be rather ironic for this discussion). Thryduulf (talk) 23:57, 3 January 2021 (UTC)
      • Competent editors can see that Andy's comment was 100% insult and 0% argument, and therefore a "not-not-vote" of no consequence. A competent closer, if there is a closer, would simply discard it. ―Mandruss ☎ 16:10, 4 January 2021 (UTC)
• weak support I would not use it, but why not have such a template if it makes it easier for some? Graeme Bartlett (talk) 02:52, 4 January 2021 (UTC)
• Oppose. Tends to encourage voting rather than discussion aimed at generating a consensus. Solution looking for a problem. Stifle (talk) 09:56, 4 January 2021 (UTC)
• OPPOSE per Thryduulf, isaacl and Stifle. Those who can't write bold should use the workarounds mentioned above, address their shortcomings (which would help in a far wider range of applicability) or simply write all caps, as Blueboar suggested. ◅ Sebastian 11:17, 4 January 2021 (UTC)
• Oppose per Johnuniq, Mandruss and GenQuest - This really is a solution looking for a problem. I appreciate Commons etc use {{Support}} however we're not Commons, Every project has their own way of doings things and "'''Support'''" is our way of doing things. Personally I use "'''Support'''" on all projects as it's what I'm used too (unless it looks out of place which I then change it after (ie with RFAs etc)). –Davey2010 11:30, 4 January 2021 (UTC)
• Support: trivial implementation, no disruption of previous practices, no migration cost, aligns well with other Wikimedia projects, probably slightly less chance of unbalanced markers (e.g. 2x2 vs 3x3). --MarioGom (talk) 14:06, 4 January 2021 (UTC)
• As much as I myself mostly start comments with a bold oppose text, I don't think this a template necessary. Firstly, per there being a wide range of commonly used !vote strings and having a template for each is a massive overkill. Will we be needing {{Option|2}} for Option 2 or something? This proposal fails to list (even as example) the actual templates, there are surely more than the two mentioned. And having only a few of these will just create extra differences in markup. I would want to see some statistics of the commonly bolded terms in discussion first. Furthermore, the non-existent complexity of the output does not warrant a template, it is unnecessarily convoluting what is a simple text message, nor is having (even more) templates in text helpful when it's literally default bold syntax. Then there's grammar -- what if I want it lowercase or add other words that need bolding? These just feel like ballot checkboxes rather than a summary of the opinion to follow. Finally, pretty sure this will just make using visual editor way more complicated needing to insert a template when one could have clicked/tapped bold like is standard in every other text editor. —  HELLKNOWZ   ▎TALK 14:39, 4 January 2021 (UTC)

  This is a good point - the common recommendations at current discussions are: "allow recreation", "containerize"/"containerise", "convert to an article"/"write an article", "delete", "disambiguate", "draftify", "dual merge", "endorse", "keep", "listfy", "merge", "move", "oppose", "overturn", "purge", "redirect", "refine", "relist", "rename", "rename", "restore", "retarget", "reverse merge", "revert", "setindexify", "soft redirect", "split", "subst", "support", "upmerge", "userfy", "wrap"/"wrapperify" and "wrong venue". Then you have modifiers like "all", "don't", "for now", "in principle", "leaning", "speedy", "strong", "weak" and "without prejudice" and non-recommendation bolds like "comment", "note", "question" and "update". Covering all these would need between 40 and 50 templates. Thryduulf (talk) 13:09, 5 January 2021 (UTC)

  @Thryduulf: We're only talking about the most common uses of such templates, which are also used on other wikis, like those mentioned in the proposal. There's a latin phrase you could use to explain your comment if you want, though. Thanks. Mike Peel (talk) 22:04, 5 January 2021 (UTC)

  These are the the recommendations used multiple times in a current discussion and/or in multiple current discussions on en.wp (AfD, RfD, CfD, TfD, MfD, DRV, MRV and RM; although there were none exclusive to MfD). To be useful to editors at en.wp they will need to cover the !votes they will commonly make otherwise they will frequently have to use the standard ''' markup which negates the whole point of having templates in the first place. What other wikis do is not relevant to discussions on the English Misplaced Pages. Thryduulf (talk) 00:43, 6 January 2021 (UTC)

• Why not I would never use them, but that doesn't mean that others wouldn't find them useful. Most of the oppose votes are people who have no personal use for them. Why is this even a vote? The OP could have saved themselves some trouble by just creating them. I am struggling to figure out why we needed to even have this discussion/vote. --Jayron32 15:43, 4 January 2021 (UTC)

  No trouble would have been saved by doing that, because (a) the templates are salted and (b) I would have tagged than as {{db-g4}} if I had noticed them being recreated. We would have ended up here anyway after a few more rounds of bureaucracy. * Pppery * _{it has begun...} 15:47, 4 January 2021 (UTC)

  It's quite apparent that this is controversial. Sure, people often slip in new templates that would be controversial if discussed beforehand, but I don't consider that good faith practice. Editors are less likely to challenge by WP:TFD because it's such a hassle (and, for some, because they aren't aware of TfD or don't have the time to learn how to use it correctly). If the creation of a template were as easily challenged as an ordinary edit, standard BRD process would work fine, but that is unfortunately not the case. I commend the proposer for "discussing first" in this case, despite the fact that it likely would have been easier to get forgiveness than permission. ―Mandruss ☎ 16:38, 4 January 2021 (UTC)

My primary concern is that templates (in general) too often shift from being “optional” to being “preferred” ... and then to “expected” and finally to essentially “mandatory”. I know this is not the intent here, but I have seen this shift occur too many times with other templates to be comfortable with it now. Blueboar (talk) 17:03, 4 January 2021 (UTC)

@Blueboar: Definitely not the intent here. I can't say that this won't happen, but if it does, then presumably it would be accompanied by discussions that you and others (including myself) could object to. Thanks. Mike Peel (talk) 21:58, 5 January 2021 (UTC)

My experience with “template creep” is that there often isn’t any discussion in which to state an objection. So I am objecting NOW, while I have a chance to do so. Blueboar (talk) 22:25, 5 January 2021 (UTC)

• Orz... can we have "Strong Meh" as well? But really we already have Template:Done/See_also and we also don't have a problem with people actually typing "Support" so I really don't care if a template does it as well, however I don't want to see a proliferation of media like File:Symbol confirmed.svg on every discussion, less concerned if it is stylized text (even check marks that are not image files). — xaosflux 17:22, 4 January 2021 (UTC)
  • Sadly {{meh}} already exists as . We would probably want {{weak meh}} as well — GhostInTheMachine 10:17, 6 January 2021 (UTC)
• Even without images, we can still run into problems with a page's transclusion limit which could end up breaking the village pumps or ANI where there are lots of proposals with lots of bolded !votes. Not worth the trouble just to save two keystrokes. I'm also worried about what Blueboar points out with templates going from "optional"->"preferred"->"required" over time. In this case, it would threaten to undermine the already weak "discussion-not-vote" consensus process which worries me per WP:NOTAVOTE and meatball:VotingIsEvil. — Wug·a·po·des​ 22:20, 4 January 2021 (UTC)

  We could always have a bot auto-subst them (although it would clutter the page history). Enterprisey (talk!) 08:54, 5 January 2021 (UTC)

  @Enterprisey: I suggested that in the proposal. I could code up a bot to do so if needed. Thanks. Mike Peel (talk) 21:58, 5 January 2021 (UTC)

  I left it vague, but to be clear, I think that's a worse idea for precisely the reason Enterprisey hints at. The last thing I want is a WP:COSMETICBOT roaming around making non-visible changes to markup and cluttering discussion diffs just to help powerusers save 2 keystrokes. It would probably also make people think they themselves ought to be substituting it which actually costs them 4 keystrokes compared to just using bare markup. — Wug·a·po·des​ 02:23, 6 January 2021 (UTC)

• Support without the icon and with substitution to avoid transclusion limit. As other projects have implemented it, I have found myself trying the template before realize that here doesn't work. Alexcalamaro (talk) 23:59, 4 January 2021 (UTC)
• O - or a bold S is simple enough or better yet, separate the sections like we do at RfA. Atsme 💬 📧 15:30, 5 January 2021 (UTC)
  • @Atsme: Great, let's support more options for commenting, like this proposed template? Thanks. Mike Peel (talk) 21:58, 5 January 2021 (UTC)
• Oppose: or alternatively doing it properly, Hell no. I despise bolded words as a substitute to discussion and the lack of nuance of just going support or oppose is not to be encouraged. Spartaz 19:58, 5 January 2021 (UTC)
  • @Spartaz: But you just used bold words in your comment? This proposal is for a convenience template to make it easier for other editors to comment, not a substitute. Thanks. Mike Peel (talk) 21:58, 5 January 2021 (UTC)
• Oppose. The convenience factor does not outweigh the barrier to newcomer participation created by use of excessive templates in simple discussions. --SmokeyJoe (talk) 00:19, 7 January 2021 (UTC)
• Support I support anyone making and using almost any template, and the creation of templates rarely requires a vote or discussion. I must be misunderstanding something here. As noted above, we already have {{agree}} and {{meh}} which are similar templates that people can use or ignore. Why the opposition? No one is proposing to force or require the use of this template, so most people would either not know it exists or not care. Other Wikimedia projects like Commons use these templates, so it is understandable to me that if some people want to use it, then they might look for it across projects. In 2005 the template was deleted for use of images, but no one is proposing that right now. To a typical reader they would not know a template is being used at all.

I think the point of this discussion is that this template has been deleted ~10 times since 2005 because of prior use of images, but I see no harm or cost in having the template available for those who want to use it now. Blue Rasberry (talk) 16:25, 7 January 2021 (UTC)

• {{weak strongest possible oppose}} Majavah (talk!) 18:51, 7 January 2021 (UTC)
• Oppose: (1) It's not that hard to type the non-templated equivalent (2) It encourages !voting without !vote rationale, (3) It only increases the number of templates transcluded on discussion pages. Thanks! Plastikspork _―Œ 20:03, 7 January 2021 (UTC)

  @Plastikspork, you don't ever edit from a smartphone, right? We have editors above who say that it actually is "that hard" for them to type straight apostrophes ('). I think we can trust them that they struggle with this. WhatamIdoing (talk) 23:21, 8 January 2021 (UTC)

  Then type in all caps (as suggested above), which is even easier than finding the {} symbols. Thanks! Plastikspork _―Œ 23:30, 8 January 2021 (UTC)

  That's a good point. On my bog-standard Android keyboard ' is on the first page of symbols, { and } are on the second page. Additionally, when editing using the Misplaced Pages Android app there is a single button that automatically inserts the markup for bold text, there is no equivalent for templates. Unless iOS works very differently (I own no Apple products so can't check) then it seems very likely that templates being easier to insert than bold markup for smartphone users looks fallacious. Thryduulf (talk) 14:01, 9 January 2021 (UTC)

  @Thryduulf: Checking on an iphone (in a text application not in a Misplaced Pages app), ' is on the first page and { is on the second, but if I enter ' then the characters go back to the alphabet, while if I enter { then it stays on the second page, so it's easier to add a second {. Does android behave the same? Thanks. Mike Peel (talk) 17:31, 9 January 2021 (UTC)

  I just tried editing in the Misplaced Pages app on iPhone, and I see the same keyboard behavior there. Thanks. Mike Peel (talk) 17:33, 9 January 2021 (UTC)

  If there is a consensus to try to make it easier to enter bold or italic text without using a straight single quote, then I'd prefer it be done in a generic way for all text, not just specific words. Let's extend wikitext markup in some way, for example. Maybe something like @‘’’, @’’’, and other combinations of typographical quotes can be supported. isaacl (talk) 17:01, 9 January 2021 (UTC)

• This is a textbook example of a solution looking for a problem. – Teratix ₵ 14:23, 10 January 2021 (UTC)

  Agreed. It's quite sad to see the amount of attention this is getting, while much more significant issues get crickets. {{u|Sdkb}}  15:21, 10 January 2021 (UTC)

  It's a simple solution to a problem I and others encounter regularly. I know others don't have this problem, but I am surprised at how many have gone out of their way to oppose this. Thanks. Mike Peel (talk) 16:06, 10 January 2021 (UTC)

  Mike Peel, perhaps we are not simply going out of our way, but instead many more people than expected felt strongly about this. (Similarly, User:Sdkb perhaps what you feel is significant is not the same as for others.) That does however not mean that its not a real problem, but perhaps instead that this is not the best solution. Personally, I wish I could have a panel of formatting/template shortcuts that I could customise to address a related problem I have with often forgetting specific template names (even if I use them regularly). --Xurizuri (talk) 11:33, 12 January 2021 (UTC)

  Xurizuri, significance is not some wishy-washy subjective value. Yes, assessments differ, but there are objectively things that have a big impact on readers and things that don't. The size of this discussion is perfectly indicative of our worst navel-gazey tendencies. {{u|Sdkb}}  12:37, 12 January 2021 (UTC)

• Oppose per above. Likely to encourage voting behavior which would not harmonize well with enwp's consensus-based culture. -FASTILY 01:04, 12 January 2021 (UTC)
• Oppose because this method of bolding is very simple. As someone that recently began editing, the vast numbers of templates have frankly been barriers to me engaging with some parts of WP thus far, particularly when there's no immediately obvious consistency in when people use one method or the other. And trying to remember all the templates and their parameters, and type them out correctly, is one of the biggest barriers from editing resulting from my ADHD that I've had. I would greatly prefer to not have more of either of those issues. The bolding and italicising are, to me, the simplest/easiest type of formatting we've got and making that more confusing is frankly not worth it. --Xurizuri (talk) 11:33, 12 January 2021 (UTC)
• If the arguments about how very difficult it is to type straight apostrophes with a smartphone were being made in good faith, this would be a discussion about undeleting Template:Bold. —Cryptic 15:54, 12 January 2021 (UTC)
• (Restored from archive as the RfC is still active. Thanks. Mike Peel (talk) 12:57, 22 January 2021 (UTC))
• Oppose as a solution in search of a problem, and seconding Cryptic on the matter of bolding templates. Vaticidalprophet (talk) 04:59, 23 January 2021 (UTC)
• Support per SmokeyJoe's comments. On Apple mobile devices such as iPhones or iPads, it defaults to ‘, and a good half-second press is needed for ', which is very tedious and seemingly time consuming, much more than typing {{}}. This would solve all the mistakes when mobile editors try to bold text. Using <b></b> isn't any better, as you would need to switch from the default keyboard to the symbols keyboard for the "<", then go back to the default for "b", then go back for ">", then back to default for text, then rinse and repeat with an additional "/". D🐶ggy54321 04:25, 1 February 2021 (UTC)

Convert all English variant notices to editnotices

This proposal arises from an ongoing discussion at the idea lab about how to reduce the clutter of excessive talk page banners, a phenomenon that leads to banner blindness, overwhelming and confusing new editors and reducing the visibility of the more important notices.

One idea I put out that seems to have gotten particular traction is that there is no need to have English variant notices (e.g. {{British English}}) appear on the talk page, rather than just as an editnotice that appears in the edit window while one is editing the article. The primary rationale is that no one is policing the English variety used on talk pages, so the only place this is needed is the editnotice. I'm therefore proposing here that we convert all existing English variant notices on talk pages to editnotices on the corresponding page. This would be done via a bot task, and once completed Module:English variant notice would be configured so that it produces an error notice if placed on an article talk page. {{u|Sdkb}}  14:34, 10 January 2021 (UTC)

Survey (English varieties)

• Support as nominator. To address two potential concerns: (1) In the rare instance that there's a talk page discussion about changing the variant, it's easy for the proposer to provide the context. I can't think of any other situation in which people on the talk page need to pay attention to the variant. (2) Modifying editnotices currently requires advanced permissions; my understanding is that this is for technical reasons rather than because of any editorial consensus. This is an issue that ought to be addressed on its own at some point, but I don't think it's an insurmountable impediment here, as most pages developed enough to be tagged with a variant notice are monitored by editors able to modify it, and if not, they will be prompted to create an edit request, which is quite straightforward. {{u|Sdkb}}  14:34, 10 January 2021 (UTC)
• Support This is a good idea and should be implemented, provided any technical issues are addressed eventually (new permission?). GenQuest 15:34, 10 January 2021 (UTC)
• Support there's a dual benefit as it simultaneously improves both the talk page (by reducing clutter) and the edit screen (by displaying relevant info), a win-win. --Paul ❬talk❭ 16:55, 10 January 2021 (UTC)
• Oppose The proposal seems half-baked because it doesn't address the use of templates like {{Use British English}} which are what I see most often. For talk pages, we could use something like an infobox which would contain key pieces of information about the article such as its size and quality rating. The dialect would fit best in such a summary of the article's properties. Andrew🐉(talk) 17:26, 10 January 2021 (UTC)

  Regarding the "use" templates, this wouldn't affect them one way or another; they'll continue being available for when it's desirable to designate a variant but there's not enough erroneous editing for there to be a need for a notice. We could discuss down the line how often to have something visible vs. invisible, but for now I think getting all the visible notices into editnotice format is the best first step.

  Regarding your idea for a hypothetical talk page infobox, I'd suggest proposing that at the broader idea lab discussion. I could support it if it's implemented well, but it's beyond the scope of the more narrow change I'm trying to achieve here. {{u|Sdkb}}  19:12, 10 January 2021 (UTC)

• Excellent idea. I suspect if editnotices had existed when these templates started this problem would not have arisen. ϢereSpielChequers 18:50, 10 January 2021 (UTC)
• Strong support if implemented, this would be huge for reducing talk page clutter, and actually making the english variety notices effective. As I said at the idea lab, the people who are disregarding or ignoring an established English variety aren't going to be on the talk page and see it there. As such, I'm convinced that the current position on the talk page is basically worthless. Aza24 (talk) 21:03, 10 January 2021 (UTC)
• Support this seems like a way to make the information more effective and reduce talk-page clutter at the same time. Thryduulf (talk) 22:06, 10 January 2021 (UTC)
• Support we do this for a few Canadian articles already...like Template:Editnotices/Page/Canada....still not seen in mobile view :-( --Moxy 🍁 01:06, 11 January 2021 (UTC)
• Support great idea. One added benefit is that it reduces ownership of articles by preventing new users from posting useless engvar tags. Since only admins, template editors, and page movers can add these if we make them edit notices, it also gives template editors and page movers something to do. — Wug·a·po·des​ 02:54, 11 January 2021 (UTC)
  • I also like the idea of removing them altogether. — Wug·a·po·des​ 21:45, 13 January 2021 (UTC)
  • Template editors and page movers may not want something else to do. It seems simple enough to write a bot with the necessary permissions to do this. ChromaNebula (talk) 23:20, 26 January 2021 (UTC)
• Support for all of this genre of notices (engvar, date formats etc.), but -- perhaps heretically -- I would support all top-of-the-page cleanup notices going into editnotices as well, so people who just want to consult an article for information aren't bothered with them. Beyond My Ken (talk) 03:17, 11 January 2021 (UTC)

  Beyond My Ken, by top-of-the-page cleanup notices are you referring to things like {{NPOV}} or {{Original research}}? I think those notices are pretty necessary from a reader perspective, since readers deserve to know when an article has significant problems so that they can read it with due caution and skepticism (yes, people should always be doing that, but they trust us enough they de facto often don't). That's more true for some notices than others, though; I could see a case for many of the yellow style ones like {{Cleanup bare URLs}} to be converted to be shown to editors only. The question at that point becomes whether we're wasting an opportunity to convert readers to editors by offering them an easy task. All this is tangential to the current discussion, so maybe take it elsewhere if you want to develop it further, but I hope my comment is food for thought. {{u|Sdkb}}  11:05, 11 January 2021 (UTC)

  No, you are correct, I was referring to the "yellow style" ones which primarily concern editors only. Beyond My Ken (talk) 21:26, 11 January 2021 (UTC)

  I would argue that a fair number of the yellow banners are useful to readers (eg Template:Overcoloured letting colourblind users know that they may not interpret something on the page correctly, or Template:Essay-like). Further, as I've been editing even the ones which non-editor readers may not find useful now inform how I read. For example, seeing Template:Debate wouldn't have changed how I read something in the past, but now it suggests to me that people may have POV forked, there may not be great usage of reviews/meta-analyses (in the case of scientific articles), or its editing may have been a series of unconnected additions. They're also useful for the purpose of editing - I will detour from doing other tasks to correct an article if I notice some kinds of banners, including when I wasn't intending to edit it. --Xurizuri (talk) 10:55, 12 January 2021 (UTC)

• Support Great idea, this banner contributes to creep and I hope that this reduces needless conflict, as many well intentioned edits from new and IP editors are related to ENGVAR. --Tom (LT) (talk) 03:20, 11 January 2021 (UTC)
• Support not useful on talk pages, useful when editing which shows on editnotice. No need for new permission, nor should editing editnotices be available to all, PMR & TPE can do this. If the TPER queue becomes too long, we can get a bot with TPE to carry over additions from the talk page into the editnotice. ProcrastinatingReader (talk) 09:21, 11 January 2021 (UTC)

  Striking in favour of using hidden templates such as {{Use British English}} on the article prose, as said by Whatamidoing, and removing all the editnotices and talk page banners and converting them into hidden templates such as {{Use British English}}. Alternatively, a {{article standards}} template, as described in the thread by Levivich. Arguments by Levivich & L235 are compelling imo. ProcrastinatingReader (talk) 15:15, 5 February 2021 (UTC)

• Support per proposal ~ ToBeFree (talk) 11:09, 11 January 2021 (UTC)
• Support – reducing talk page template bloat and helping new editors understand Engvar at the same time sounds like a clear win-win to me. AngryHarpy‍ 12:47, 11 January 2021 (UTC)
• I think I oppose for sympathetic reasons. 2 reasons: 1) I do not think this is technically feasible. It asks to make an edit notice for essentially 6 million pages. That's an awful lot of infrastructure. (Someone tell me I'm wrong.) 2) I do think the correct remedy is removing these in their entirety from talk pages. We do not need them present in both their canonical place as article tags as well as talk pages. (Replace as needed on the article proper.) --Izno (talk) 14:41, 11 January 2021 (UTC)
  • @Izno: I think it would be at most creating 41,000 edit notices with current use of the eng var module. --Paul ❬talk❭ 18:36, 11 January 2021 (UTC)
    • Just a casual 41k. Eyeroll. --Izno (talk) 18:44, 11 January 2021 (UTC)
      • Trivial for a bot. Thryduulf (talk) 19:57, 11 January 2021 (UTC)
      • Trivial or not, a very different figure to 6 mil. --Paul ❬talk❭ 21:14, 11 January 2021 (UTC)
        • Creation is "trivial for a bot". Maintenance and filtering through the noise in the template namespace looking for anything but edit notices? Yeah, not so much. --Izno (talk) 01:39, 12 January 2021 (UTC)
• Support This seems like a good idea worth pursuing. --Jayron32 18:16, 11 January 2021 (UTC)
• Support Reducing talk page clutter is a good idea. Remagoxer (talk) 20:51, 11 January 2021 (UTC)
• Support. It'd be more useful as an edit notice - I know I never check first, and it's a pain to have to open the talk page in a new tab (especially as I have ADHD and sometimes forget the variant as soon as I close said tab). Ideally, similar notices about the style of writing in a given article would also be great to have as edit notices. However, a concern would be that by reducing talk page clutter, we need to not just relocate the clutter (sweeping it under the carpet, so to speak). --Xurizuri (talk) 10:55, 12 January 2021 (UTC)
• Support, but what about protected pages? There might be an increase of (incorrect) ENVAR edit request, I guess you would also add a en-varent message on the talk page too? (please ping) DarthFlappy 18:53, 12 January 2021 (UTC)

  @DarthFlappy: I would expect that the vast majority of edit requests come from people trying to edit a protected page (that they don't meet the requirements of), clicking the button to request an edit and filling in the form. You might have noticed many are blank—this is because people don't read what's on their screen and just click the big blue "Submit" (maybe thinking that they're requesting permission for them to be given edit access). But anyway, I wouldn't think the talk page banner would really make a difference on edit request content. — Bilorv (talk) 23:49, 14 January 2021 (UTC)

• Oppose Will only worsen banner blindness. CaptainEek ⚓ 20:41, 12 January 2021 (UTC)
• Support but not at scale, and only as a pilot. As I understand this could affect millions of articles, so please try it first as a pilot for 100s of articles. Big changes like this are best done with test cases, time passing, multiple requests for comment, and documentation. This already has my general support and also I anticipate supporting again in the future, but the proposal as it is has no limits. The scale and pace of the changes matters to me. I am only expecting volunteer-level documentation and not the best and most complete, and I encourage the pilot. I recognize the existence of the problem and feel that it will only grow. There are various possible solutions, and perhaps we have to use several solutions at once to address this issue. Please develop this one solution first. Blue Rasberry (talk) 20:51, 12 January 2021 (UTC)
• Oppose editnotice banners are far more annoying than talk page notices. They slow down editing. Graeme Bartlett (talk) 22:18, 12 January 2021 (UTC)
• Oppose — Enwiki has got to be the only publication in the world that writes a single work using multiple varieties of English. Engvar isn't important enough to have talk page banners for, I agree, but the solution is to remove them altogether. Moving them to the edit notice will create edit notice blindness instead of talk page banner blindness, and that's even worse, because in theory, edit notices have the really important stuff, even moreso than talk page headers. Creating thousands or millions of edit notices is a huge overhead and maintenance increase. Edit notices are annoying and largely ignored anyway. They don't show at all for mobile users. In all, I think this moves the problem to a worse place rather than alleviating it. Levivich /_hound 04:53, 13 January 2021 (UTC)

  This is a fair point. I was thinking the notice should be trimmed down, literally into a bullet point like: “* This article uses British English.”. Alternatively, we can have a single “Article conventions” talk page template which is highly trimmed down and signifies standards like the variety of English used — this assumes that there are other types of standards other than English and date variety that could possibly apply. A bit like {{article standards|lang=British|dates=dmy}}. ProcrastinatingReader (talk) 09:16, 13 January 2021 (UTC)

  An article conventions template sounds like a very good idea. There are probably others besides engvar and usedmy, but those two are good examples. I would find iconography to be the most efficient way of communicating these sorts of things, but I'm not sure if everyone would be on board for that. So like a little British flag somewhere if it was use BrEng, a US flag for AmEng, something like that. Levivich /_hound 17:27, 13 January 2021 (UTC)

  I agree that the notices should be kept unobtrusive and concise. Regarding the "just remove them entirely" point, we already have the e.g. {{Use British English}} family of templates, which set the standard without displaying anything, just as you describe. I'm undecided about whether/when we should use that compared to {{British English}}, but I think that, in circumstances where it is important enough to warrant a banner, that banner should be proximate to the place it actually applies, which means putting it in the edit notice next to the article rather than the talk banners next to the talk. {{u|Sdkb}}  00:06, 14 January 2021 (UTC)

• Oppose We should save banners for the truly important stuff like BLP, rather than spelling. (t · c) buidhe 18:35, 13 January 2021 (UTC)
• Oppose per Graeme Bartlett and CaptainEek. ~ HAL333 22:19, 13 January 2021 (UTC)
• Support: seems like a no-brainer. Banner blindness on a talk page is already a massive issue, and ENGVAR isn't relevant to reading the talk page, it's relevant to editing the page, so it should be where it's relevant. Sceptre (talk) 23:33, 14 January 2021 (UTC)
• Oppose: it's absolutely a reasonable proposal, but I'd prefer removal of these banners from the talk page instead. I just don't buy that language variant is important enough to warrant this kind of attention, and instead it will just cause reader blindness wherever it appears. I understand that it's very frustrating to be reverting the same good-faith spelling changes over and over again (I've lost count of the number of times I've had to revert "installment" back to "instalment" on the BritEng Black Mirror series of articles), but I've found that most unregistered editors will not see an editnotice, a wikicode template or a hidden comment in the middle of a word that keeps being changed (I don't know why the last doesn't work, but it doesn't), or possibly just willfully ignore them all. So I believe that this proposal, though it seems like the common sense logical position to move the template to, would just create blindness and have little-to-no effect on averting editing redundancies. — Bilorv (talk) 23:40, 14 January 2021 (UTC)

  @Bilorv: Your point about having to correct the same word over and over gives me a thought: what if we had an edit filter so that e.g. anyone trying to introduce "installment" to an article tagged with British English would get a big caution notice when they try to publish? {{u|Sdkb}}  01:58, 15 January 2021 (UTC)

  I think it is unreasonable for new/IP users to have no way of knowing this info before editing. Yes, they most likely won't read the notice, but "there's a notice that you ignored" is much better than "there's a policy hidden in our arcane (to new users) WP namespace that you don't even know about". And given that the varieties of English are largely identical, it's sometimes difficult to tell what variant the article is in; the notice is a nice reminder. - Novov T C 07:57, 15 January 2021 (UTC)

  To Sdkb, that's possibly something I could support, but I really don't like edit filters targeted at newbies because it's one more barrier to entry. If there was a way to say "literally the only changes in this edit are a bad spelling changes" then that would be ideal. I know that's asking a lot. To Mir Novov, many good faith edits I see by new/IP users that I have to revert are something I couldn't reasonably expect them to understand. There's been a discussion on the talk page? The lead doesn't mention this because of due weight? This source is unreliable even though it's a newspaper one million people read per day? It's wrong to call a section "Controversy" even though you've seen 1000 other articles with that bad heading? If anything it seems to me that "this article uses Australian English because it's about an Australian show" is so much easier to explain than most common mistakes made. — Bilorv (talk) 09:37, 15 January 2021 (UTC)

  Bilorv, in my idealized 2030 version of Misplaced Pages, the way that filter would work is that someone would go in and try to make a bad switch to another variant within an otherwise fine edit, and when they click publish, a notice would pop up saying "Hey, you switched 'instalment' to 'installment', which appears to go against the British English used for this article. Would you like to (a) publish, but keep British English? , or (b) publish anyways?"

  Even with that, though, I agree with Novov that, for pages where switches are common (which is the group we're discussing here), it's better not to make someone do all the work before giving them the alert. And it's not just newcomers—I didn't know that "installment" was one of the words that differed until you mentioned it above, so I could easily see myself making that error. Whereas if there's an editnotice that (again, thinking futuristically) automatically detects that "instalment" is used a lot on that page and therefore includes it in the examples, that'll let me know not to touch anything. {{u|Sdkb}}  13:05, 15 January 2021 (UTC)

• Support - This information is most useful for actually editing pages, not discussions. Logically, it should belong there, and such a relocation would be useful to the IP editors that have "corrected" spelling . Yes, some other info is on the talk page that should be read, but a lot of people don't read that, and wishful thinking won't make that fact go away. - Novov T C 07:57, 15 January 2021 (UTC)
• Oppose. Instruction creep, overly intrusive and will just lead to more edit notice blindness. Neutrality 19:43, 15 January 2021 (UTC)
• Oppose per Neutrality. Personally, I dislike edit notices and more edit notices that would intrude on the editing interface is something that I would not want. Perhaps something similar to the Template:Use mdy dates template would be better. A whole host of edit notices on the national varities of English (sometimes where editnotices are already in place) would be worse than talk page banner blindness for content creators hoow would have to scroll past the edit notice every time they edit. Plus, the national varities of English really isn't that important and as such, this is why we should keep them on talk pages. P,TO 19104 (talk) (contribs) 23:08, 15 January 2021 (UTC)
• Oppose per Graeme Bartlett and CaptainEek. Cavalryman (talk) 03:14, 16 January 2021 (UTC).
• Oppose. Varieties of English are not important enough to warrant placement as an editnotice. Just try and notice what variety the article is using and emulate that; if you get it wrong, someone will help you fix it. In my view, the talk page banner exists only to attempt to avert edit wars over this stuff, with one side being able to point to the banner. The rest of the time it's not useful, whether on the talk page or as an editnotice. KevinL (aka L235 · t · c) 20:07, 18 January 2021 (UTC)
  • Further to this, there are some truly important editnotices (e.g. DS notices that create blockable offenses), and the more editnotices we add the more banner blindness we get. Talk page notices are already ignored; let's not consign editnotices to the same fate. KevinL (aka L235 · t · c) 20:09, 18 January 2021 (UTC)

  Whilst I see your argument, to be fair, the editnotice format already exists right now and is placed arbitrarily; admins/TE/PMRs will place it themselves or on request for other editors, also in line with the current documentation for these templates. The pages that only have a talk notice are usually arbitrary. ProcrastinatingReader (talk) 20:12, 18 January 2021 (UTC)

  • There's an editnotice already? That's awful. Let's delete it. KevinL (aka L235 · t · c) 20:22, 18 January 2021 (UTC)
    • Yeah, see doc of {{British English}}. It’s done using a parameter, but the idea is (I think) to use both. To clarify, my point isn’t that we should enshrine a pattern that may not make sense, but if we don’t want language editnotices we should remove them entirely rather than the arbitrary system currently.Personally I think either trim it down to literally a bullet point not a hefty notice, or create a {{article standards}} for talk pages. Each option has a different purposes of course: the former is intended to alert editors writing to tailor their language, the latter to help copyeditors ‘fix’ errors. Personally, I don’t know other varieties of English so I make my ‘errors’ and let someone else copyedit their fixes if they care, so possibly the latter is smarter. ProcrastinatingReader (talk) 20:26, 18 January 2021 (UTC)
      • The current editnotice should be terminated with prejudice. KevinL (aka L235 · t · c) 20:52, 18 January 2021 (UTC)
        • I think I have used that edit notice. But the idea is to only insert the notice if it really needs to be noticed, ie there is a chronic problem with numerous edits on the page. So in general it should not be added in my opinion. Graeme Bartlett (talk) 23:59, 18 January 2021 (UTC)

• Oppose - editnotices should be reserved for important article- and page-specific instructions, and should be used as minimally as we can manage. Opening editnotices to general advisories about article styles will lead to clutter and significantly diminish the usefulness of editnotices for those article- and page-specific notices. See also this discussion from a couple years back about this exact thing which led to consensus that style notices shouldn't be used this way without evidence of disruption. In the same discussion, several users smarter than me also suggested that doing this would pollute the database with a few hundred thousand new pages and increase the loading time of articles, for no particularly important reason. Ivanvector's squirrel (/_nuts) 01:04, 20 January 2021 (UTC)

  Furthermore, we still haven't solved the issue that editnotices aren't visible to mobile editors, so they're not well suited to editorial advisories anyway. Ivanvector's squirrel (/_nuts) 01:06, 20 January 2021 (UTC)

• Oppose as this proposal appears to ignore the fact that editnotices don’t show on mobile. SK2242 (talk) 06:41, 20 January 2021 (UTC)

  Neither do talk notices. Or, well, they're well hidden. ProcrastinatingReader (talk) 23:00, 21 January 2021 (UTC)

• Weak oppose; how many times have you read on AN or ANI a reminder along the lines of, "Dear OP, did you miss the violently orange notice when you posted here?" If they miss that, do we really think that an editnotice will prevent page watchers from having to revert to the correct EngVar? Personally, i think that editnotices should be kept for the very most important things ~ things that if you cross or miss might end up with your privileges restricted. happy days, Lindsay 14:10, 22 January 2021 (UTC)
• Support but only if there's an option for logged-in editors to turn off the notifications. Lugnuts 17:23, 22 January 2021 (UTC)
• Oppose having more edit notices. In the visual editor and the 2017 wikitext editor, you have to click to get past the edit notices every single time you open that page to edit. Also, just as Ivanvector's squirrel says, you stop reading them when they're common. WT:MED has an edit notice that I've clicked past most days for the last several years, and I no longer know what it says. When we need to have notes about the language variant to use, please make them all "invisible" templates that carry the necessary information in the title, such as {{Use British English}}. WhatamIdoing (talk) 19:58, 22 January 2021 (UTC)
• Support. As many others have said, very few editors will actually notice talk page banners, especially IPs and newbies. And failure to heed ENGVAR instructions has often led to disruptive, pointless edit wars. Of course, we need to be mindful of not accumulating so many edit notices that people will stop paying attention, but that's a separate discussion of how to condense the edit notices. ChromaNebula (talk) 23:20, 26 January 2021 (UTC)
• Support: Even if people ignore the notice, it won't be worse than it is now. This is a great way to stop people from changing between English varieties unnecessarily. And, also, since more people are seeing the fact that "you can tag articles for types of English?", there'll be more people tagging, which, in turn, leads to more standardisation and organization. Opal|zukor 22:10, 29 January 2021 (UTC)
• Support, ideally with the notice stripped down to its bare essentials. Perhaps just This article is written in American English, and this should not be changed without consensus. Learn more. I see using editnotices as an improvement in multiple ways. Talk pages become less cluttered. Newbies who don't know about our approach to English varieties are more likely to learn about it and avoid making unwanted changes. And more experienced users editing articles without strong national ties can quickly see how they should write without having to either check the talk page or scan the article for clues as to the preferred variety. the wub "?!" 23:35, 30 January 2021 (UTC)
• Support - this seems like a good idea. Rollo August (talk) 17:32, 3 February 2021 (UTC)
• Oppose per Levivich and L235. AVSmalnad77 04:04, 5 February 2021 (UTC)

Discussion

• If this is adopted, how would it be implemented relative to existing editnotices that already incorporate English variety? That is, see Misplaced Pages:Featured articles/Editnotice templates for a list of all medical featured article editnotices, that already include English variety, incorporating a custom list of words from the article. (Not a techie, please spell this out in Dummy 101 detail.) SandyGeorgia (Talk) 16:46, 10 January 2021 (UTC)
  • In the cases where it's already in the edit notice, I think we'd just leave it there and only remove it from the talk page. --Paul ❬talk❭ 17:07, 10 January 2021 (UTC)

    Yeah, for pages like Template:Editnotices/Page/Rotavirus, it already includes {{British English|form=editnotice}}, so the bot would just remove the talk page notice and not add a duplicate. For the rare page that has a custom language editnotice, like Template:Editnotices/Page/COVID-19 pandemic, that'd be a little trickier, but still doable; the bot could just skipping adding anything for editnotices that link to a page in Category:English dialects. {{u|Sdkb}}  19:55, 10 January 2021 (UTC)

• Shifting banners from talk to the edit notice helps talk but makes it even more unlikely that people will read the edit notice. I would want to see a draft of exactly how this proposal would be implemented (create a million new edit notices? create one central edit notice with magic code to show the language variety?), and exactly how it would appear. Try editing Donald Trump to see what an edit notice can look like. Johnuniq (talk) 22:59, 10 January 2021 (UTC)
  • You're emphasis of how big of a change this will be is certainly valid, though I don't know if I agree that moving to an edit notice makes it even more unlikely that people will read the edit notice – even just the flag of the UK or US in the edit notice would do more than right now. The only alternative I can see to the current situation or the proposed solution above is to completely remove the english variety, which is a more or less impossible scenario. Aza24 (talk) 00:10, 11 January 2021 (UTC)
  • We make the editnotice form smaller? ProcrastinatingReader (talk) 09:25, 11 January 2021 (UTC)
    • I'm not sure how feasible this is in a technical sense, but if an editnotice template is about the formatting (eg date order), language variant, etc, then could those be smaller and all placed together right above the editor? It'd make it less obtrusive, while still being easy to locate all the relevant little pieces of information re writing conventions. Those could alternatively be in an expandable bar, like some of the category lists at the end of articles are. --Xurizuri (talk) 10:22, 12 January 2021 (UTC)

  @Johnuniq, I believe that this will involve creating tens of thousands of edit notices. WhatamIdoing (talk) 20:01, 22 January 2021 (UTC)

• Many old time editors, most newer editors, and virtually all IPs never make it a habit to look at the talk page before editing an article page. English version notices on the talk page are worthless. GenQuest 23:30, 10 January 2021 (UTC)
  • Completely agreed, and this proposal should address that appropriately I believe. The current placement of English variety templates are virtually invisible to the intended audience. Aza24 (talk) 00:10, 11 January 2021 (UTC)
    • As a newer editor, I have never intentionally checked before editing so that's at least some anecdotal evidence for your point. However, I'm not sure if this is a function of the notice on the talk page, but on the visual editor on some articles there's a little prompt right under the title (eg Education in Australia). I'm a big fan of those little prompts. --Xurizuri (talk) 10:22, 12 January 2021 (UTC)
• The need for an administrator to intervene will force an non-administrator-editor who notices a a change to the English variety is clearly warranted to spend two edit sessions on the page. The first session would be to place a protected edit request. The second would be to actually change the variety. Jc3s5h (talk) 01:02, 11 January 2021 (UTC)
  • Given how infrequently a page's variety of English should be changed this sounds like a benefit to this proposal - ensuring that it only happens when there is a good reason to do so. Thryduulf (talk) 11:12, 11 January 2021 (UTC)
    • I would agree with this. Requiring two edits isn't unreasonable for something that defines how the entire article is written. --Xurizuri (talk) 10:22, 12 January 2021 (UTC)

• I expect that the opposers on the basis of "we shouldn't have them in the first place" will actually do something about that and propose that we remove them all together (were this proposal not to pass) . Otherwise, you're wasting everyone's time. Aza24 (talk) 06:08, 13 January 2021 (UTC)

  Opposing a change from the second-best solution (talk page banners) to the third-best solution (edit notices) is not a waste of time, even if one doesn't propose the best solution (no banners). Making a proposal that doesn't have a reasonable chance of success is a waste of time. Oftentimes, "second-best" is status quo because it's the compromise. Levivich /_hound 06:16, 13 January 2021 (UTC)

  You are mistaken if you believe this discussion cannot generate the consensus to remove these from talk pages without replacement. RFCs are not votes.

  Secondly, we are not wasting time regardless. We should prefer the best solution, however we get to it. It is a logical fallacy to argue that we also must do things consistent with our position, especially as this is a volunteer mission. (I have no problem being called a hypocrite if you like. :)

  Thirdly, this is maybe the least concerning thing on the wiki today. We don't need the polarism on your part. --Izno (talk) 22:09, 13 January 2021 (UTC)

  Izno, literally no where did I say anything like this discussion cannot generate the consensus to remove these from talk pages without replacement, and I certainly wasn't intentionally trying to generate "polarism"; the misrepresentations are not appreciated. I think I was pretty clear about what would be "wasting time" – a situation where people who oppose on the basis of "we shouldn't have them in the first place", the proposal fails, yet these opposers don't start some proposal to remove English variety banners. Because in a situation where a problem is brought up, consequently unresolved by the introduction of a bigger problem and neither end up being addressed is a waste of time. Aza24 (talk) 22:39, 13 January 2021 (UTC)

• Obviously, the best solution would be a bot that automatically (and quietly) corrected spelling and usage to whatever variant was designated (assuming that a variant has been designated)... with an edit summary explaining what was done and why. Then editors could simply write, and not worry about whether they were writing in the designated variant. Blueboar (talk) 14:00, 15 January 2021 (UTC)

  @Blueboar: editors that are writing any new content shouldn't be overly concerned with this already - it is really about avoiding refactoring the existing text over and over again. — xaosflux 11:45, 16 January 2021 (UTC)

• At the very least, the banners should be reduced and have the flags or other images removed. English varieties don't always neatly follow political boundaries, and at any rate we have WP:FLAGCRUFT for such situations in articles and yet flags are spammed across talk pages. Removing them also helps reduce space and prominence for a template that is probably mostly seen when explicitly being looked for. CMD (talk) 16:47, 17 January 2021 (UTC)

Delete Gadget and Gadget Definition namespaces

Please consider joining the feedback request service. An editor has requested comments from other editors for this discussion. This page has been added to the following lists: Misplaced Pages proposals Misplaced Pages technical issues and templates When discussion has ended, remove this tag and it will be removed from the lists. If this page is on additional lists, they will be noted below.

The Gadget and Gadget Definition namespaces are unused, have never been used, and have confusing documentation at Misplaced Pages:Gadget due to having never been used. Apparently, all relevant gadgets are in MediaWiki-space (for example, MediaWiki:Gadget-Twinkle.js). Considering this, there is no reason to keep the namespaces around.

Somewhat relevant:

• Phab tasks for Gadgets-2.0, which would supposedly use this namespace
• Previous post at the technical village pump about Gadgetspace

If after five years nothing has happened, I doubt anything will happen with the namespace in the future. Elliot321 (talk | contribs) 20:25, 15 January 2021 (UTC)

• Support unless there is a realistic plan to use them within a year. They take up space and confuse in many namespace selections like Special:Search, Special:WhatLinksHere, Special:PrefixIndex, Special:AllPages, Special:RecentChanges, Special:Watchlist, Special:MovePage and so on. The main reader facing is probably Special:Search. We could remove them there right away with the below in MediaWiki:Common.css. PrimeHunter (talk) 20:56, 15 January 2021 (UTC)

.mw-advancedSearch-namespace-2300, .mw-advancedSearch-namespace-2301,
.mw-advancedSearch-namespace-2302, .mw-advancedSearch-namespace-2303 {display:none !important;}

• Strong support, especially gadget definition, which is literally comprised in a single page: MediaWiki:Gadgets-definition. JJP...MASTER! _{JJP... master?} 21:12, 15 January 2021 (UTC)

  I'm not sure what you mean by this. That page is where the current gadgets are defined, so would be unaffected by this change. What would be removed are the namespaces above, which are currently entirely unused, but in theory would be by the future gadget reorganization. ~ Amory (u • t • c) 22:44, 17 January 2021 (UTC)

  Amorymeltzer, what I mean is that the gadget definition namespace is entirely useless, because what it would be supposed to contain is in that single page. JJP...MASTER! _{JJP... master?} 18:19, 18 January 2021 (UTC)

• Please note that I requested gadgets improvements, including parts of Gadgets 2.0, in the most recent community wishlist, see m:Community Wishlist Survey 2021/Bots and gadgets/Gadgets improvements. This may be addressed by the community tech team in the coming year. --DannyS712 (talk) 05:22, 16 January 2021 (UTC)

  I'll withdraw this proposal if there's actual work on gadgets. I don't have a gripe with the namespace, I just didn't get the impression it was ever going to be used at this point. Elliot321 (talk | contribs) 07:56, 16 January 2021 (UTC)

• I’m still yet to see many valid usages of this namespace as an article title, other than one popular redirect example, possibly two. ProcrastinatingReader (talk) 08:15, 16 January 2021 (UTC)

  I see it has been added to the RfC list. Can someone clarify if it within the domain of community consensus to even remove the namespace / gadget, and if so is it even a good idea if that Wishlist proposal will happen? If no to either, then RfC is likely a waste of time. ProcrastinatingReader (talk) 18:41, 16 January 2021 (UTC)

  I think it falls under WP:CONEXCEPT. --Izno (talk) 19:32, 16 January 2021 (UTC)

  @ProcrastinatingReader: As I understand it, adding or removing a namespace is something that only developers can implement, and they will (again AIUI) only do so in two circumstances (1) where it is (no longer) required for a new (or removed) software feature, or (2) clear community consensus. Regarding the Wishlist proposal, it is almost impossible to predict which of the proposals will be actually be worked on beyond investigating in more detail what that work would entail and what resource is required. If there is no clear indication on Phabricator after about 3 months then I'd say to ask for an update, but before that point it's unlikely to be worthwhile even asking. Thryduulf (talk) 03:45, 17 January 2021 (UTC)

• Support* *unless there's work on the namespace, as DannyS712 indicted might be coming. ~Gwennie🐈｟💬 📋｠ 22:00, 16 January 2021 (UTC)
  • Notified: Template:Centralized discussion. –MJL ‐Talk‐ 17:29, 17 January 2021 (UTC)
• I'm not clear on what the point of this RfC is. There's only one page in any of these namespaces (i.e. Gadget:Invention, Travel, & Adventure), and AFAIK, it cannot be modified or deleted by anyone on enwiki without at least steward--if not sysadmin--intervention (which itself is why it exists, as a one-off hack). Is the intent to establish a consensus first, and then open a phab ticket or something to ask for the removal of the namespace by developers, using this RfC as evidence of consensus? I think that would be a platform-wide change, wouldn't it? If so, wouldn't we need more than just enwiki to agree with that before the devs would even begin to listen? I ask because we've been here before, last year, and nothing came of it, and I'm not sure what this RfC would change about that. Writ Keeper ⚇♔ 17:42, 19 January 2021 (UTC)

  Writ Keeper, if that's the case then should this be a Meta RfC? JJP...MASTER! _{JJP... master?} 23:06, 19 January 2021 (UTC)

  @Writ Keeper and JJPMaster: I don't think that removing these namespaces would be a platform-wide change given that different wikis can have different namespaces, although it's possible it might be. If it is possible, the developers will not remove the namespace here without evidence of consensus to do so. If it isn't consensus to remove it only on en.wp would be evidence of a good reason to start a discussion on meta. Thryduulf (talk) 12:05, 21 January 2021 (UTC)

  @Thryduulf: Generally speaking, yes different wikis can have different namespaces. But my understanding--which is limited for sure--is that these aren't just extra namespaces the way Draft is. The Gadget: and Gadget definition: namespaces are reserved by the Gadgets 2.0 extension, so I think removing the namespaces would require a code change for that extension, which would impact all wikis.

  My point isn't ultimately about whether this should be here or on Meta, although that is a pending question. My point is that--again, based on my limited knowledge and unlike a normal modification of namespaces--this is a non-trivial code change that will impact all wikis, not just enwiki, and it's one that the devs have already repeatedly refused to do. (Why we even have a half-finished extension on a production site is another question entirely, but...) I don't think this RfC is formulated in a way that people know what they're asking for, and as such, I don't think it'll go anywhere, even if we get a consensus. Writ Keeper ⚇♔ 14:41, 21 January 2021 (UTC)

• Support Never used, only use I have seen is Gadget:Invention, Travel, & Adventure, which is only in that namespace because of the format of the subject title. SemiHypercube 13:44, 20 January 2021 (UTC)
• Support. Having this sort of thing around contributes to complexity and confusion and, as mentioned, this namespace is only used once. I have always wondered what the point of this namespace was / is and can see now others are in the same boat. With respect to our jurisprudence I think it's perfectly fine to indicate that locally on EN WP we don't see this namespace being useful, and further discussion can happen at a larger venue. Many such technical changes have arisen from discussions locally that indicate the feeling of editors, even if there may need to be other discussions elsewhere. --Tom (LT) (talk) 07:03, 21 January 2021 (UTC)
• Strong Support, not a single page in those namespaces other than Gadget:Invention, Travel, & Adventure and the talk page, which isn't even a real gadget. All gadgets, as far as I know, are, in fact, in the MediaWiki namespace. 54nd60x (talk) 07:55, 26 January 2021 (UTC)
  • Additional comment: Unlike the Education Program namespace, which had talk pages (why it was installed back in 2018,) there are no real gadget (definition) talk pages on this wiki, which is another reason why I think it should be deleted. 54nd60x (talk) 09:21, 26 January 2021 (UTC)
    • See User:54nd60x/common.css, add that to your common.css if you want to hide the gadget/gadget definition namespaces. 54nd60x (talk) 09:21, 26 January 2021 (UTC)
      • The current version only hides it at Special:Search. This hides it in some other places but not all, and maybe not in all browsers:

        option, option,
        option, option {display: none !important;}
        

        PrimeHunter (talk) 14:11, 26 January 2021 (UTC)
• Support. It has been several years, and there do not seem to be any concrete plans to do the work which would use this namespace. If there are plans, I'm happy to keep it, but otherwise there's no sense in the extra complexity and confusion it causes by having it appear in every namespace selector. the wub "?!" 18:15, 30 January 2021 (UTC)
• Question — How much is the namespace costing us? — GhostInTheMachine 22:10, 30 January 2021 (UTC)
  • Nothing. Writ Keeper ⚇♔ 22:26, 30 January 2021 (UTC)
    • Not true. This namespace has caused a lot of drama over the years, mainly due to conflicts involving the name of the visual novel Gadget Invention, Travel, & Adventure. Some examples are Misplaced Pages:Village pump (technical)/Archive 139#Gadget:Invention, Travel, & Adventure, User talk:MaxSem/Archives/August 2015#Gadget redirects, Talk:Gadget Invention, Travel, & Adventure#Edit request, Gadget talk:Invention, Travel, & Adventure#Edit request, m:Steward requests/Miscellaneous/2019-04#Edits to gadget namespace, and Misplaced Pages:Administrators' noticeboard/Archive311#Add maintenance template, Misplaced Pages:Administrators' noticeboard/Archive326#Creation of the page Gadget:Past as Future. * Pppery * _{it has begun...} 23:14, 30 January 2021 (UTC)
      • I was assuming that the question was about the monetary cost of hosting the Gadgets namespace, which is $0. Writ Keeper ⚇♔ 17:32, 31 January 2021 (UTC)
• Support As I wrote in the last of the above list of links, the movement to use the gadget namespace has been stalled with no sign of progress for over 4 years, so there's no reason to expect it to happen in the near future. This namespace's existence is causing periodic problems, for no apparent benefit. * Pppery * _{it has begun...} 23:14, 30 January 2021 (UTC)

  How often do we need to create articles whose names begin with the seven characters "Gadget:"? There's one documented instance, mentioned above. So, that one aside, which other potential articles is this causing problems for? --Redrose64 🌹 (talk) 08:46, 31 January 2021 (UTC)

• Okay, here's my hat: oppose. This namespace is not harming anything, the periodic discussions notwithstanding. The discussions themselves take more time than the actual namespace takes from anyone else. A single page hanging out in the wrong place also isn't breaking the wiki. That we're having this conversation when this is basically a WP:CONEXCEPT question is asinine. Go home, live with it, wait until the namespace is actually used. It's not hard to ignore it, people. Put something on WP:Namespace if it isn't there. --Izno (talk) 07:25, 31 January 2021 (UTC)
• It's unclear to me whether this is proposal to temporarily remove these namespaces until Gadgets 2.0 is ready or a request to permanently remove them. If it's the latter, that's a non-starter, if it's the former then I'd ask exactly what the issue is in having them around, albeit unused, given that they will be used...eventually. For context, I was one of the most recent people (like 4-5 years ago) working on Gadgets 2.0 whenever we could find time (usually once a year at the Wikimania hackathon). I do believe that every editor actually wants Gadgets 2.0 to happen, though most won't care and won't notice. Gadgets will be slightly faster and gadget authors will get access to more features. So...if the problem is that these namespaces are sitting unused, I think the best solution/use of time is to find some more technically minded folks who would be interested in contributing to the Gadgets extension and work towards getting 2.0 ready for users, so we can populate those namespaces. Legoktm (talk) 08:00, 31 January 2021 (UTC)
  • I think moving away from Gerrit will be a boon for code contributions. Moving the code into GitHub would’ve probably helped too, though I guess that’s a non-starter. But there’s still the issue of getting code reviews. ProcrastinatingReader (talk) 10:46, 31 January 2021 (UTC)

    If code review is what's stopping people or getting set up with Gerrit I'm always happy to help with that. Legoktm (talk) 00:02, 2 February 2021 (UTC)

  When I originally opened this, I was unaware that there was still work being done on Gadgets 2.0. I'm obviously not opposed to that - I was under the impression that these namespaces were long-abandoned. Elliot321 (talk | contribs) 17:26, 31 January 2021 (UTC)

  To be clear, no one is currently working on Gadgets 2.0 as far as I know. But eventually, I hope. (I won't make any promises or even suggestions because I already told people we'd have Gadgets 2.0 by 2017 and well, here we are.) Legoktm (talk) 00:02, 2 February 2021 (UTC)

  Strong support: Have never been used, unlikely to be used in the future. If there’s no benefit of this namespace and it’s causing problems for any page, I think the namespaces should very well be deleted. 54nd60x (talk) 01:35, 1 February 2021 (UTC)

• Oppose any en-wiki specific development hacks to remove namespaces 2300-2303. That would just result in some barely/un-supported technical debt that will likely break down in the future. Strong Oppose any display hacks to try to "hide" this locally, that will certainly break down and be inconsistent across platforms/browsers/etc. Neutral on if the results of this are just to petition the devs to globally remove these namespaces from all/all-wmf projects. — xaosflux 13:58, 2 February 2021 (UTC)

@Xaosflux: What do you mean by "some barely/un-supported technical debt that will likely break down in the future?" These namespaces have never been used on this wiki, aren't likely to be used in the future, and cause too many problems for the page Gadget:Invention, Travel, & Adventure. There are no archives to keep - unlike the Education Program namespace. I don't see any benefit in keeping these namespaces as they are currently unused and have never been used, and cause so many problems for every edit request to Gadget:Invention, Travel, & Adventure. I know that one page hanging out in the wrong place may not be that big of deal, but that's not the only problem readers face. There are problems in Special:Search as well. 54nd60x (talk) 14:29, 3 February 2021 (UTC)

@54nd60x: these namespaces are deployed to the 700+ WMF integrated projects, so making some special one-off configuration that is only for the English Misplaced Pages would mean an exception that has to be cared for indefinitely by the developers. — xaosflux 15:08, 3 February 2021 (UTC)

• Oppose, if it wasn't clear. The request is a non-starter; it's something we as a community can't do, and the people who can won't. Given that there is a sum total of one page across the entire enwiki that's affected by it (a redirect that does not require ongoing editing or maintenance), I don't see the benefit in a massive effort to change their minds. This is by far too much effort for not enough payoff for the wiki; I'd almost call it a solution in search of a problem. Writ Keeper ⚇♔ 14:50, 3 February 2021 (UTC)
• Amusing how all this discussion and still the only repeated example above is one article, this gadget movie, not a particularly popular article by any metric either, nor do I think any readers care. I’m getting the feel that people just have an axe to grind with WMF/dev actions, tbh. There are far bigger problems, community caused, that nobody seems to care about doing anything about. ProcrastinatingReader (talk) 15:56, 3 February 2021 (UTC)

If my opinion wasn't clear enough, the reason I want to delete these namespaces isn't because of that one article, but because they have never been used and won't likely to be used in the future. So there's no use in keeping these namespaces if they are not used and won't be used. But @Xaosflux: was right, that the gadget and gadget definition namespaces are used on just about every wiki, so uninstalling those namespaces on enwiki would mean that an exception would have to be cared for indefinitely by the developers. Only Wikimedia Vote Wiki and Wikimedia Login Wiki I know of don't have these namespaces. 54nd60x (talk) 01:15, 4 February 2021 (UTC)

Should Cewbot remove interlanguage link templates once local articles exist?

This task (]) destroys the information about which other wikis have relevant articles about the subject. For instance, if the article is created, and then one week later is deleted again, the {{ill}} link is gone and the work of the editor who originally placed it there is lost.

The reason for this odd behavior has been that the bot is computationally intensive. Now, the bot was recently given the ability to bypass this load. The idea is that an editor adds |display=force to the {{Interlanguage link}} when the English article exists. The template will then render as a regular blue link but retain the information about other wikis, so if that article is deleted, an editor can simply turn off the |display= parameter again. Of course, the bot itself should be this editor.

Another reason brought up is that {{ill}} create clutter in the editing window, but I see nothing worse than when you have a load of references interspersed in running text.

One argument is also that Cewbot waits one week before removing the {{ill}} links. But articles quite often take more than one week to go through PROD or AfD.

So should Cewbot remove interlanguage link templates once local articles exist?

I say there's gotta be a better solution that doesn't destroy the work of editors. CapnZapp (talk) 10:47, 22 January 2021 (UTC)

I should add that I brought this up at the bot's talk page but was shut down twice and told the Bot Noticeboard was a more appropriate place to have this discussion. Then that discussion was shut down and I was told to go to the Village Pump. So far I've complied, but this is the end of the line.

User talk:Kanashimi/Archive 1#Task 1 Convert interlanguage link templates with local article to wikilinks

Misplaced Pages:Bots/Noticeboard#Should_Cewbot_remove_interlanguage_link_templates_once_local_articles_exist?

CapnZapp (talk) 10:51, 22 January 2021 (UTC)

• To answer the question in the headline, absolutely. --Izno (talk) 19:25, 22 January 2021 (UTC)
• I wonder whether the conversion could be logged somewhere. Maybe a note on the edited article's talk page ("I changed {{il|French}} to Local" – please revert if Local gets deleted)? Maybe a note on the possibly-to-be-deleted article's talk page ("If you delete this, please go revert this edit by the bot")? Maybe a central log, which any interested editors could scan it for red links later? WhatamIdoing (talk) 20:38, 22 January 2021 (UTC)
• Forum shopping is not OK. That said, perhaps the bot could run this task every month rather than every week to reduce the chances of article creations being subsequently deleted. Or better, the deleting admins could restore the interlanguage links while they are deleting the article. In general, it's better to link to a local language article where it exists, though. Thanks. Mike Peel (talk) 21:13, 22 January 2021 (UTC)
  • @Mike Peel:, CapnZapp was directed here by the BAG. No one at WP:BOTN supported stopping Cewbot, because no one saw any consensus to stop it. This RFC is a legitimate attempt as checking if C has C'd. There's also the possibility that while Cewbot still has a general consensus to do its task, the community finds its preferable to tweak certain behaviour. Headbomb {t · c · p · b} 05:18, 23 January 2021 (UTC)
    • Thanks for the background, I've struck that part of my comment. It still sounds like waiting a bit longer, or perhaps checking for deletion tags in the article to be linked to, would be an improvement. Thanks. Mike Peel (talk) 18:54, 23 January 2021 (UTC)
• Yes it should. I also don't see any reason to change its one week delay, especially if it removal of {{ill}} is halted during an ongoing AFD/PROD discussion. Having logs could be a good idea though. Headbomb {t · c · p · b} 05:18, 23 January 2021 (UTC)

What does especially if it removal of {{ill}} is halted mean, Headbomb? It can very easily be more than just a week before an article even starts the PROD or AfD process, so arguing the bot respects that process (if indeed that is the case?) seems insufficient... CapnZapp (talk) 11:01, 25 January 2021 (UTC)

Articles may be deleted at any point, from seconds, to days, to weeks, to years after their creation. That something might potentially be deleted is not a valid argument against suspending basic maintenance tasks. Headbomb {t · c · p · b} 16:17, 25 January 2021 (UTC)

• Yes Pointless wikitext makes editing the article more difficult. Having {{ill}} in some articles but plain wikilinks in others invites hapless gnomes to go round "fixing" one or the other. I don't think logs are warranted: just another unloved maintenance page to be ignored. All that is needed is an edit summary spelling out what was done (not each link) so it could be found in article history or the bot's contributions. Perhaps the bot could wait longer than a week from page creation. Johnuniq (talk) 06:06, 23 January 2021 (UTC)

  I'm arguing the wikitext isn't pointless. It was useful info added before the local article was created and this usefulness is exactly the same after it gets deleted. Having {{ill}} in some articles but plain wikilinks in others is just a hypothetical I'm having trouble taking in good faith. What has your conspiracies against "wiki gnomes" to do with my question and my arguments, Johnuniq? What do you mean by "plain wikilinks" in this context (I haven't mentioned any)? All that is needed is an edit summary spelling out what was done (not each link) so it could be found in article history or the bot's contributions. You appear to miss one step of reasoning - why would anyone think to check the edit summaries when the bot leaves no trace of anything to find - unless there's say, an editor comment of some kind: "here was once useful interlanguage links, check the page history for details"? I will note I haven't asked for any logs, so we're in agreement there. As of yet I haven't seen a single editor arguing why the bot should wait such a desperately short time, so, yes, waiting more than a week seems like one easy step to take, whatever else we agree on. CapnZapp (talk) 11:09, 25 January 2021 (UTC)

  One article might have a plain link such as ] while another has {{ill|Example|de}}. Johnuniq (talk) 00:27, 26 January 2021 (UTC)

• Yes As per the comment above, pointless wikitext should be removed. Editing is difficult enough already for new editors. What would be the point of a log? How would it advance the project? Peter coxhead (talk) 07:33, 23 January 2021 (UTC)

No, that comment doesn't explain or justify why the wikitext is "pointless". (I invite you to be the first to actually start the argument, Peter coxhead) Personally, I don't find {{ill}} templates more difficult than a jumble of references/citations where it can be quite tricky to find the actual article text among the sea of reference parameters, and you don't see any bots obsessively messing around with them... I am not asking for a log, I am asking for a discussion wherein we don't just take cewbot for granted, but arrive at alternatives that don't erase information volunteered by editors. Cheers CapnZapp (talk) 11:13, 25 January 2021 (UTC)

@CapnZapp: if there's no article here, then {{ill}} is of some value. Once there is an article here, it isn't. The links to other language wikis are then provided via Wikidata. Yes, full references in text are also confusing, especially to new editors, which is why I always prefer the list-defined approach with the minimum reference in the text. But the argument that X is confusing so it doesn't matter if Y is as well isn't, in my view, convincing. We should remove as much complexity as possible. Peter coxhead (talk) 11:30, 25 January 2021 (UTC)

• Yes. I struggle to think of a situation in which we'd need to retain an ill when a local article exists. If the article in the other language is better, just tag the English page with {{Expand language}}, which is plenty enough of a signal to readers that they might want to just use Google Translate. And if the article in English is created and then deleted as not notable, then it shouldn't have an ill as an ill is just a type of redlink and non-notable pages shouldn't be redlinked. {{u|Sdkb}}  16:40, 23 January 2021 (UTC)

To ease your struggle, I started the very first talk section with If an article is created, but later deleted (perhaps a person article that's deemed not notable enough), the ill link is lost and we have a red link instead. saying the bot actually destroys input added by editors (the existence of the foreign-language wiki article). Regards, CapnZapp (talk) 11:21, 25 January 2021 (UTC)

Let me respond to Mike Peel in a more prominent place since this is important. It has been very hard indeed to actually get a discussion started where people look at the bot's job critically and were we discuss alternatives that still accomplish what the bot set out to do but in a way that does not actively destroy the work of editors. I have mainly had to battle editors who focus solely not just on shunting the discussion elsewhere like a hot potato but actively shutting it down before arguments were even considered. Here seems to be the only place where there's nowhere else to point, so I look forward to an open-minded discussion which does not avoid the greater issue. With that in mind, thank you for striking that part of your comment, and thanks to Headbomb for highlighting the struggle to even start the discussion. CapnZapp (talk) 11:27, 25 January 2021 (UTC)

• Yes The question contains an unstated supposition that "the work of editors" is somehow sacrosanct and "destroying" it is axiomatically a "bad thing". I don't believe this idea has any merit at all. In any case an "ill" link is intended to only be a temporary "patch" to cover a supposed hole in the 'pedia. Roger (Dodger67) (talk) 17:10, 25 January 2021 (UTC)
• Yes. Removing an obsolete {{ILL}}, is helpful, and deletion of the article is not the expected/common path. The week delay should cover almost all speedy deletes, and that delay could be increased if we want to catch a higher number of AFD/PRODs. However we should not halt this useful work and obviously not permanently retain ILLs, just because an article might eventually be deleted. Alsee (talk) 02:20, 26 January 2021 (UTC)
• Yes – good idea and would certainly be an example of a bot doing helpful "edits that would be extremely tedious to do manually". Can see no reason why we'd want the ill links to stick around. Aza24 (talk) 07:18, 26 January 2021 (UTC)

Two takeaways: 1. If the bot updates wikidata thereby retaining the information otherwise lost, that'd be sufficient. 2. Several posters have qualified their response by saying a longer waiting time could be useful. What would then be a more reasonable length of time for the bot to wait? Three months? More? Less? CapnZapp (talk) 09:22, 1 February 2021 (UTC)

• Question. If {{ill|Example|simple}} and ] both result in Example/Example.. then isn't this a cosmetic bot task? –MJL ‐Talk‐ 03:57, 5 February 2021 (UTC)

  With the parameters in your example, {{ill|Example|simple}} incurs the cost of one "expensive parser function" since it checks for the existence of the Example page on the English Misplaced Pages. davidwr/(talk)/(contribs) 04:05, 5 February 2021 (UTC)

  A cosmetic bot task is one that makes a change which has no effect on reader-facing aspects of the encyclopaedia. So, yes, this is cosmetic. Thryduulf (talk) 11:15, 5 February 2021 (UTC)

  Ah, but it does have an effect on reader-facing aspects of Misplaced Pages if removing an expensive parser function call will cause the formerly-501st expensive parser function call on that page to succeed instead of "failing because it was the 501st" and produce different output to the user. Therefore, it is not necessarily a cosmetic bot when used on pages that are already over the limit. davidwr/(talk)/(contribs) 19:54, 5 February 2021 (UTC)

  Also, it is effectively not a cosmetic change if it removes Template:Interlanguage link then the en-wiki page is deleted or changed into a redirect. Had the bot NOT run, the interlanguage link template would've shown a link to the other-language page as soon as the en-wiki target was deleted or changed into a redirect. So, I guess technically it's a cosmetic change at the time the bot is run, but it is effectively a non-cosmetic change in that if the bot runs AFTER the en-wiki link is deleted or changed into a redirect, the bot will skip it and the end result will be different for the reader. davidwr/(talk)/(contribs) 19:58, 5 February 2021 (UTC)

Proposal: Adding more links in the sidebar in mobile view

I think that the mobile view should have more links directing users to appropriate places. I think one link that should be added is a help link and tutorial. I will create specific sections to try to propose and hopefully get community support for the idea. I am now editing in mobile view more than desktop view now and hopefully these changes will help Misplaced Pages become a more user-friendly site in the future. Interstellarity (talk) 16:57, 24 January 2021 (UTC)

Add a help link in the sidebar linking to Help:Contents

1. Support as proposer. Interstellarity (talk) 16:57, 24 January 2021 (UTC)

Add a tutorial link linking to Help:Introduction

1. Support as proposer. Interstellarity (talk) 16:57, 24 January 2021 (UTC)

Question....I don't see any sidebar in mobile view..do you mean the top banner? Also is the tutorial accessible to you in mobile view? --Moxy 🍁 17:09, 24 January 2021 (UTC)

I’m talking the hamburger menu in mobile view to clarify. Interstellarity (talk) 17:24, 24 January 2021 (UTC)

Oh and I forgot to answer your second question. I had no problems with viewing tutorial on my mobile device. Interstellarity (talk) 18:44, 24 January 2021 (UTC)

General discussion

I find mobile extremely complex, since there's not just one mobile version—there's the mobile web browser, the mobile web browser in advanced mode, the Android app, the iPhone app, and possibly others I'm forgetting. I agree that it'd be good to have some discussion about which links from the desktop left sidebar to include on the mobile version, but without knowing exactly what's currently there for the different mobile versions or what the space/design considerations are, it's hard to make judgements about specific changes. {{u|Sdkb}}  03:08, 26 January 2021 (UTC)

mergers @ AfD (yes, again)

Yes, I know it's a perennial proposal, and yes I've read over quite a few discussions in the past and yes I do feel times are different now. Mergers often stay open exorbitantly long times . This is not practical, and the system of proposed mergers is clearly struggling with low participation and interest (not to suggest that other areas aren't). It is more effective and efficient to nominate an article for deletion if you want it to be merged. Like it or not, that would seem to be a fact at this point based on my highly unscientific day-to-day life. See, for instance, 1 and 2, where unanimous consensuses were reached in a week-- this would usually take months to a year or more if you followed the 'correct' way of proposing a merge. Currently, some users will !vote "keep: a merger should be discussed elsewhere" and I'd argue that more often than not no discussion happens elsewhere.

I'm not suggesting completely folding PROPMERGE into AfD and I'm not suggesting necessarily renaming AfD to articles for discussion, I just think it past time that we seriously consider making 'merge' a valid option to start an AfD for. Is AfD exactly booming with participants? no, but I'd argue it's higher visibility than proposing a merger, the format works just as well better, and I highly doubt the number of new merges would overwhelm the system. We could always do a trial for X months and reassess... Cheers, Eddie891 _Work 23:22, 25 January 2021 (UTC)

• To clarify I'm suggesting that we make merge an acceptable proposal to suggest when opening an AfD, but leave Proposed mergers as a functional place where people can still file proposals if they either feel that system would work better (perhaps for a sufficiently high traffic article) or if the AfD is closed as no consensus (but, of course, not 'keep' or 'delete). This would allow most merger suggestions to get more discussion (because of higher visibility) and closed faster (time limit of AfD) and may also have the benefit of more controversial Proposed mergers getting more attention because there are more manageable amounts. Eddie891 _Work 23:38, 25 January 2021 (UTC)

  Eddie891, I agree (as I hope everyone does) that the merge proposal system is clearly broken and needs some sort of reform. I'll leave it to others more familiar to decide whether folding it into AfD is the best approach, but I'm down to try something, and worst case scenario it fails and we return to the status quo.

  Since this is a developed, actionable proposal, you might want to move it to WP:VPR, as the idea lab isn't a place for !voting. {{u|Sdkb}}  03:18, 26 January 2021 (UTC)

• I think we should redirect RMergers to AFD and be done with it. (Regardless of that opinion, we should also make it doubly clear somewhere on WP:Deletion policy and/or WP:ATA and/or WP:AFD/AI that not-votes like "AFD is not for merging" get kicked to the curb.) --Izno (talk) 03:58, 26 January 2021 (UTC)
• Unless someone provides a good reason for the bureaucracy that is having completely separate and non-overlapping (by policy, if not practice) procedures for merging versus deletion versus draftication versus etc of articles, I agree completely that AfD should serve as a central point of discussion for any article that people feel should not be an article - be that "it should be a redirect" or "it should be merged" or "it's too soon so draftify". -bɜ:ʳkənhɪmez (User/say hi!) 04:09, 26 January 2021 (UTC)
• I have concerns about the actual execution as well as diluting AfD participation with large numbers of merge articles. While the discussion and closing don't take too long, merging requires a lot of execution effort. I don't do AfDs that have a merge close likely result since I don't want to merge them, and without someone agreeing to do it (say, the nom), it risks the close of discussions without actual merging being carried out on a reasonable timescale. Nosebagbear (talk) 10:15, 27 January 2021 (UTC)

  Even in that scenario though, you still get a decision and anyone can act without sitting in ambiguity. And that decision is timely, and it's visible on the article that the article is long in the tooth. RFM is like AFC except it can be years rather than months before you know. --Izno (talk) 18:28, 27 January 2021 (UTC)

  What plays the biggest role in diluting AFD is when users go on large nominating sprees of 20+ articles in a single day. So far in january there have been 200 proposed mergers, or about seven a day. I don't see adding those to the 100+ AFDs regularly nominated each day as holding the potential for overwhelming that process. Eddie891 _Work 18:35, 27 January 2021 (UTC)

  @Eddie891: I wouldn't say that reasoning is entirely cast-iron. You'd like this change because it would make it easier to get merges to happen, presumably encouraging more. That would logically bump up the figures far more than the 7/day (which would be notable, but certainly tolerable). If it didn't bump it up, then the change would probably not be worth making. Nosebagbear (talk) 10:35, 29 January 2021 (UTC)

• I have been editing WP since 2006... and I didn’t know a separate Merger process even existed! It certainly was not advertised widely (When was it created?) I have no problem dealing with contentious merger proposals through AFD. Why do we need two separate bureaucracies? Blueboar (talk) 13:19, 27 January 2021 (UTC)

  Probably because it's listed somewhere in PEREN. :^) --Izno (talk) 18:28, 27 January 2021 (UTC)

• It seems unlikely that any experienced editor has not seen and attended a merge discussion such as this or that. I am reminded of M. Jourdain who is surprised to learn that he has been speaking prose all his life, without knowing it! Andrew🐉(talk) 09:37, 30 January 2021 (UTC)

• Comment: The general Articles to be Merged backlog is now below 12 months (this used to be 2.5+ years), and the AfD resulting in Decision to Merge backlog is again below 90 days and rapidly being reduced. Just so you know. Anyone who wishes to help out, you now have the links to do so. Regards, GenQuest 18:50, 27 January 2021 (UTC)
• Comment, I have similar concerns to Nosebagbear but I see merit in the idea that likely contested nominations could be nominated at AfD with the nominator proposing a merger. I would however oppose anything that would prevent editors from conducting bold mergers/redirects (obviously bold deletion is unavailable to most of us, for good reason), if contested they could then be formally nominated (as is currently the case). Cavalryman (talk) 11:50, 29 January 2021 (UTC).
• I've never really understood why they're separate. If anyone wishes to only watch for deletion discussions or only watch for merger proposals, that can be handled via one of the several ways we already organize AfDs. AfDs don't get lost in talk page archives, are more centralized, and have a structure that can already result in merger. I say take this opportunity to reduce our number of complicated processes. Or perhaps try it out for a while? — Rhododendrites \\ 02:42, 30 January 2021 (UTC)
• Oppose Let us count the ways:

1. Mergers are inherently unproductive because they just move content from one page to another with low value-added
2. Mergers can mostly be done by anyone using ordinary editing tools, just as anyone can add, remove or move a section in an article
3. Deletion however is a specially restricted function because it makes the content inaccessible and is not easy to revert
4. AfD exists primarily for deletion, providing the clear consensus required for admins to use this specially restricted function
5. AfD is moribund too because it's no fun looking at junk
6. The longer the AfD list, the less likely that people will look through it and so participation will decline further
7. Already we see lots of AfD discussions being relisted again and again for lack of participation
8. AfD tends to attract zealots who tend to vote delete as a knee-jerk reflex, without regard to the merits of the topic and its potential
9. The proposal therefore risks turning mergers into deletions and content will be lost
10. There are technical limits on the size of the daily AfD logs due to their heavy use of templates
11. The AfD process doesn't scale - neither technically nor in its human factors
12. The proper place to get attention for mergers would be projects staffed by subject-matter experts
13. But projects are dying too
14. The main reason that everything is dying is excessive assholery, battleground behaviour, busywork and conflict
15. We need to focus on fostering collaboration, cooperation and content creation rather than finding new and better ways to annoy each other

Andrew🐉(talk) 08:21, 30 January 2021 (UTC)

• I agree with merging merges into AFD. One place to discuss what happens to a stand alone page (delete, draftify, merge, etc) seems to make the most sense and will avoid the duplication of effort and dilution of attention that happens now with multiple processes. Levivich /_hound 15:15, 4 February 2021 (UTC)
• Support folding it into AfD Didn't even know WP:PROPMERGE existed (note, most merge discussions I've closed on WP:ANRFC didn't use such a process either but were just regular talk page discussions). Looks like a useless process to me. Personally I'd have taken "blank-and-redirect" type merges into AfD anyway. It's a centralised venue which achieves conclusive outcomes, whereas many talk page discussions take far more weeks and still end up with minimal participation. I dislike that some admins refuse to acknowledge merge consensus imo, with the rationale that AfD isn't for merges, even if the AfD reached a consensus for merge. That part seems to be dependent on the closing admin (some allow it, others don't and say "can be discussed elsewhere", from what I've seen). ProcrastinatingReader (talk) 16:06, 4 February 2021 (UTC)
• Support The only place where such a discussion will get any attention at all is AfD--though participation is lower than it should be, it's still the best-attended of such processes. Since merge has in the past been used as a surreptitious method of deletion by calling it a merge, but not actually merging anything substantial, it makes sense. We should probably specify that the action in such discussions if there is no participation is not the soft delete we use for articles, but merge, as undisputed. Both are easily reversible if challenged. As Levivich says, the virtue of AfD is that if disputed, it comes to a conclusion. Yes, AfD tends to attract people who try to find reasons to vote delete, but it also attracts those who seek every possibility for keep. Those in each party have always been sure they were a struggling minority. I'm not sure how that would translate into merges--each side sometimes suggests it to find a compromise solution. Merges are not unconstructive--they move the information, but they remove the often extensive duplication and all the overhead associated with being a separate article.~~

Warn new editors before putting in a date-of-birth less than 18 years ago

Lately I've found and reported more than a handful of minors posting their own year-of-birth or that of a family member, or people creating drafts about non-notable teenagers complete with real name and date-of-birth.

I propose an edit filter for non-(auto)confirmed editors that that would throw up a warning recommending that the editor read Misplaced Pages:On privacy, confidentiality and discretion, Misplaced Pages:Guidance for younger editors, and WP:AUTOBIOGRAPHY before publishing anything that looked like a date of birth 5-17 years ago. This wouldn't prevent publication, but it would at least put some "friction" in the process giving the editor a chance to think about it. For obvious reasons, the filter should be set to "private" and edits that are saved anyway should be flagged for review by someone with visibility to that edit filter, as a fair number of them would likely need to be immediately WP:REVDELed away and referred to WP:OVERSIGHT.

I wanted to get feedback on the idea here before making a more formal proposal on Misplaced Pages:Village pump (technical) or Misplaced Pages:Edit_filter/Requested in case there's some good reason NOT to proceed.

It's not part of this proposal (first things first) but a similar proposal to flag new editors putting up email addresses or social-media links on user- and draft- pages and new-ish pages in other namespaces would also help cut down on naive users posting things that have to be cleaned up later. davidwr/(talk)/(contribs) 03:06, 27 January 2021 (UTC)

... in what context? Edit filters are not magical. --Izno (talk) 04:41, 27 January 2021 (UTC)

Moreover, this seems better for WP:VPI since you don't know what you want exactly. --Izno (talk) 04:43, 27 January 2021 (UTC)

I suppose we could flag new articles with Category:2004 births or later, but I doubt that editors unsophisticated enough to attempt to make articles on themselves or their family members of that age are adding birth categories. BD2412 T 06:20, 27 January 2021 (UTC)

It's impossible to make an edit filter totally private. The username and page title will always be visible. Are you sure you want to make a handy list of minor editors? Suffusion of Yellow (talk) 06:25, 27 January 2021 (UTC)

I'm sure I do NOT want such a list, at least not one that is visible to the public or unprivileged editors. I had forgotten about the limitations of the privacy features of the edit filter log. From re-reading the edit filter documentation, it looks like this is not currently possible in en-wiki. That said, in principle it looks like the edit filter extension could be "cloned" so there could be two independent groups of edit filters, one that is very locked-down to the point that its logs were invisible to most editors. That said, it's not the simple undertaking I envisioned, which makes my suggestion impractical at least in the short term. davidwr/(talk)/(contribs) 19:15, 27 January 2021 (UTC)

Yes, please move this to VPI. {{u|Sdkb}}  14:53, 30 January 2021 (UTC)

Many non-notable people (most of them young) have created articles about themselves or non-notable people whom they personally know. Even more have added their births to year and day articles. I can't work out a way to prevent this while not preventing articles & additions being made which are useful & justified. Jim Michael (talk) 15:40, 28 January 2021 (UTC)

The birthdatescammers!

Proof https://i.pinimg.com/originals/87/86/66/878666a2074787830017c0981de58e10.jpg --2A01:C23:7033:1D00:115B:35E7:3490:2E47 (talk) 13:02, 7 February 2021 (UTC)

New template (a new way) to track how many times an article is listed at Portal:Current events

So Misplaced Pages has a template that is able to track daily page views and that template can be placed on any article when it is relevant or wanted by the community. I am proposing to create a template that can track the number of times and/or the dates when an article is listed on the Portal:Current events.

This would allow people to know when an article was relevant in the international/national news and this would also allow for people to know when an article most likely had a major update of content.

For example, Biden–Ukraine conspiracy theory was created during the first set of allegations. The article saw a massive spike in the number of views and number of edits. The number of edits/vandalism was so big that active arbitration remedies were placed on the article. After about a week, the articles edits died to almost none and a 23 day long request for a copy-edit took place. During those 23 days, only 4 edits were made to the article. About two weeks later, the article was back in the US national news, so the article had tons of new content being added.

Another example is the Sandy Hook Elementary School shooting happened in 2012. Of course it was a major thing in the international news, so it saw major content for the week or two that it was in the news. The article was slowly updated, but on December 12, 2019, the article was in the news against due to a trial. The article had 8 edits during that week alone, when it was getting maybe 4 edits a month.

Some articles never see the Portal:Current events, and some may only see it once. For example, 2019 Bagram Airfield attack only saw the portal 1 time and that was on the day of the attack.

If this is added, people could fairly easily find the dates when the article had new content added. It would also allow people to know how many times (or how many days in a row) the article was of importance in the world (or national importance).

Elijahandskip (talk) 15:11, 28 January 2021 (UTC)

That'd be good, providing it's easy to use & clear to understand.

Some major events which should be on CE never are, although I don't know how to solve that problem. Jim Michael (talk) 15:37, 28 January 2021 (UTC)

My mind is thinking of a copy/paste type template with some fill in spots that the editor adds, so it would be easy to use. Elijahandskip (talk) 17:37, 28 January 2021 (UTC)

I think this is a great idea.~~ 🌀𝕾𝖚𝖕𝖊𝖗 𝕮𝖞𝖈𝖑𝖔𝖓𝖎𝖈 𝕾𝖙𝖔𝖗𝖒 𝕮𝖔𝖗𝖔𝖓𝖆🌀 17:58, 28 January 2021 (UTC)

This is just more talk page cruft. When there are multiple discussions elsewhere about reducing how much Stuff is at the top of talk pages, this is not a socially-feasible proposal. Certainly not as its own template. Going beyond that, I doubt Portal:Current events drives much if any traffic at all. --Izno (talk) 20:41, 28 January 2021 (UTC)

@Izno: according to that daily page views, it gets about 60,000 views daily.Elijahandskip (talk) 21:03, 28 January 2021 (UTC)

"Drives" is a key word in context. --Izno (talk) 21:12, 28 January 2021 (UTC)

Why wouldn't it drive traffic? Many people read what's happened recently & click on the links to find out more. Jim Michael (talk) 22:48, 28 January 2021 (UTC)

But compared to the number of people coming in via Google, social media etc. it's likely insignificant. We need fewer templates cluttering up talk pages, not more. If for some reason you want to check when something was on the portal, it's easy to do via Special:WhatLinksHere/Biden–Ukraine_conspiracy_theory and filter to the Portal namespace. the wub "?!" 23:07, 28 January 2021 (UTC)

Being very honest, I am a 2 year Misplaced Pages editor and I have never seen that before. Highly unlikely 99% of that 60,000 even know what that is. But I would guess maybe 75% of them would click on the articles and maybe 30% of them would click the talk page of that article. That is at least a few thousand up to 10k. Elijahandskip (talk) 23:30, 28 January 2021 (UTC)

Besides 75% click-through from the portal being very unlikely, you're significantly overestimating readers' interest in talk pages as well. The number of views of the talk page is about 2% that of the article . the wub "?!" 00:59, 29 January 2021 (UTC)

The featured article two days ago, The Holocaust in Slovakia, had a gracious 60k views. That's 1 in 100 clickthroughs from the main page, which gets 6-7 million (which is fairly high for recent TFAs). Let's assume that a secondary portal, though linked prominently with its own 60k pageviews, has a similar clickthrough. That's 600 pageviews a day from the one page.

No thank you to a new template. --Izno (talk) 06:40, 29 January 2021 (UTC)

A stronger argument is not that it drives traffic, but correlates with it—as in the examples given by the OP. It could still be useful for someone trying to work out what made the pageviews/edits spike. But I think this would be better as a tool of some kind than a talk page banner (even one minimized by default). "Track when page X was linked on page Y" would work for this use case (Y = Portal:Current events) and might plausibly be useful in other situations too. — Bilorv (talk) 20:55, 4 February 2021 (UTC)

An idea is to make it similar to how the ITN recognition that is placed on talk pages. Elijahandskip (talk) 22:21, 28 January 2021 (UTC)

Pending-changes protection of Today's featured article

The idea of automatically applying WP:Semiprotection to WP:Today's featured article (TFA) has been thrashed to death; see WP:PERENNIAL#Protecting Today's Featured Article on the Main Page. I think the most recent discussion was in July 2020, at WT:Today's featured article/Archive 14#Question about protection. The key argument (for me at any rate) is that the last thing we want to do is discourage new editors.

Nevertheless, any time an article with a hint of controversy is TFA, it turns up at WP:ANI. For some recent examples, see Misplaced Pages:Administrators' noticeboard/IncidentArchive1057#The Holocaust in Slovakia—TFA subject to ongoing vandalism (27 January 2021), Misplaced Pages:Administrators' noticeboard/IncidentArchive1057#Guadeloupe amazon—Today's TFA subject to ongoing vandalism (28 January 2021), Misplaced Pages:Administrators' noticeboard/IncidentArchive1057#Pyramid of Nyuserre —Today's TFA subject to persistent vandalism (30 January 2021) and WP:ANI#Hitler's prophecy—TFA undergoing ongoing vandalism (30 January 2021). They may also get posted at WP:AIV, which is less easy to search. I haven't seen reports of problems with WP:DYK articles.

During that last discussion, I suggested that TFA might be WP:Pending changes-protected for only so long as it is on the Main Page; and this idea seems to be new. IPs and unconfirmed editors would be able to post, even if their contributions didn't display immediately; and vandalism could be speedily dispatched where it belongs. A TFA's godaprents could be encouraged to help the regular pending changes patrollers. It would also solve the problem of working out when the vandalism occurred and who did it (a perennial problem with the small amount of vandalism I deal with - mostly involving links to DAB pages - which can be buried behind several recent good edits and require copy&paste from the last good version). It shouldn't be technically difficult to implement; it could be part of the script which adds articles to and removes them from the Main Page. Some other editors seem to like the idea, and it was suggested that I open a discussion here. (For the record - I'm in favour.) Narky Blert (talk) 10:36, 2 February 2021 (UTC)

I'll note that one of the primary reasons for rejections of auto semi on TFA in the past is giving the impression that Misplaced Pages isn't so free to edit by having our most visible page be uneditable to the majority of the audience of TFA. Pending changes protection avoids this by still allowing users to make the edit, even if there is a slight delay in publishing it live, so it would be a decent compromise between unfettered access and maximum accessibility for our most visible page, and avoiding wasting of the community's time and potential risk of bad content being put up for all to see. Regards, User:TheDragonFire300. (Contact me | Contributions). 11:01, 2 February 2021 (UTC)

As a further thought - the protection template text should be tailormade for TFA, and welcoming. Narky Blert (talk) 13:35, 2 February 2021 (UTC)

And another - WP:ANI#Pacific swift - Today's TFA receive high level of IP Vandalism (4 February 2021). Narky Blert (talk) 08:59, 5 February 2021 (UTC)

Another one, for which protection was declined - WP:ANI#Cheadle Hulme - Today's TFA receive high level of IP Vandalism (5 February 2021). Narky Blert (talk) 11:42, 7 February 2021 (UTC)

This is every edit made to Cheadle Hulme during its day at TFA. I see a grand total of two IP vandals, one of whom made two edits and one of whom made one, while every other IP edit is constructive. If any admin had protected it under those circumstances, then unless there's something I've missed they'd have been instantly hauled off to Arbcom for admin abuse. ‑ Iridescent 12:37, 7 February 2021 (UTC)

PC is widely agreed not to work/be practical on highly edited pages. That's why no one suggests it, probably. --Izno (talk) 15:44, 2 February 2021 (UTC)

This is something that was proven during the PC backdoor attempt, by the Barack Obama and George W. Bush articles. The volume of edits was so high that the queue on those articles were perennially backlogged, and so it was and still is agreed that PC is not suitable for pages that would see high volumes of edits, something which would happen with TFA as a matter of course. —A little blue Bori v^_^v 16:43, 2 February 2021 (UTC)

At least the TFAs as considered in this discussion. I have seen some fairly quiet TFAs of late. --Izno (talk) 17:17, 2 February 2021 (UTC)

Unfortunately I suspect the set of TFAs that would be suitably quiet for PC to work is almost identical to the set of TFAs where PC is not needed. Thryduulf (talk) 01:30, 3 February 2021 (UTC)

As a supporter of the proposal, and an active PCR, I don't think this would be insurmountable for most TFAs. I note that the two given examples are highly political topics, one of whom was at the time President of the United States and the other of whom had been less than a full term ago. Vaticidalprophet (talk) 06:04, 3 February 2021 (UTC)

I'm against preemptive protection of any kind, especially pending changes which makes more work for volunteers and is rarely useful. — Wug·a·po·des​ 01:53, 3 February 2021 (UTC)

• Support some sort of protection it's unacceptable to have editors (very predictably!) vandalizing articles like The Holocaust in Slovakia while they're on the main page. This diminishes our reputation much more than any protection would do. (t · c) buidhe 04:16, 3 February 2021 (UTC)
• I should note that "highly active" is a fairly low boundary - PCR starts having real issues well before, say, editors would be frequently edit-conflicting. I'm also not sure how accurate a prediction of a TFA's likely edit rate we can do. Obviously we can predict the "very active" and "not likely to be edited much" buckets, but there'd be a large middle category that is tough to order. As such, I continue to believe PCR remains distinctly problematic for any TFA use that would actually warrant PCR. Nosebagbear (talk) 07:35, 3 February 2021 (UTC)
• To be honest, I'm not totally against this. The utility of pending changes is different from semi-protection: the goal is not to reduce the workload for administrators and recent change patrollers (as others have correctly pointed out above, pending changes effectively does the opposite), but rather, to prevent the vandalism from being seen by readers and thus possibly bringing the project into disrepute. As a matter of fact, if my memory serves me right, for a brief period a few years ago, we actually did start preemptively putting PC protection on the TFA after an WP:AN discussion because of a particularly nasty LTA that would replace images on TFAs with extremely shocking ones. The traditional problems with PC on highly edited pages don't seem to be a big concern here because the protection would only last for one day, and most TFAs don't seem to be edited so frequently that large backlogs might become a problem. At the very least, I would probably support a trial period for this idea. Mz7 (talk) 07:53, 3 February 2021 (UTC)

  Thinking about this a little further, I think the relevant question would be how frequently vandalism remains undetected for longer than, say, a minute while on the TFA. Pending changes works best on articles where vandalism has a hard time getting reverted quickly, and now that I think about it, because the TFA already has a lot of eyes on it in general, it may be the case that most vandalism is already reverted within seconds, rendering the need for pending changes moot. Mz7 (talk) 08:02, 3 February 2021 (UTC)

So far as I can tell, TFA vandalism is rarely if ever reverted within seconds. I've heard averages around 10-15 minutes, which is enough to be problematic for those articles, especially with heavy or grotesque vandalism. Vaticidalprophet (talk) 11:39, 3 February 2021 (UTC)

Looking at the edit histories of the articles I mentioned in the opening paragraph (a very small statistical sample): if ClueBot spots it, within seconds; if a human, 1-40 minutes (median 8). Narky Blert (talk) 14:24, 3 February 2021 (UTC)

I think the relevant question would be how frequently vandalism remains undetected for longer than, say, a minute while on the TFA This is the crucial question for me. If our goal is to prevent disruption to the reader, we need to know how much vandalism is currently disrupting readers. I don't think a trial would change our ability to look at that, we just need someone to crunch the numbers from the page history. It could also be crossed with the day's page hits to estimate the number of readers who actually saw the vandalism, e.g., this vandalism was up for 5 minutes, so with a total of 60 thousand page views that day---5 thousand people probably saw this instead of the article. In my experience it's as you describe with the added eyes bringing faster reversions, but knowing the average and other statistics would be useful and quite possibly change my mind. If PC protection really is a substantial benefit, I'd be willing to support its use on TFA. It at least allows users without accounts to edit, and if we craft a nice message as Narky suggests, it could minimize the potential newbie biting. So my main concern in this case is usefulness because I've rarely seen PC solve more problems than it caused. — Wug·a·po·des​ 20:13, 3 February 2021 (UTC)

(I guess the maths in your example isn't meant to be taken literally but 5 mins of 60,000 pageviews is about 209 views—5000 would be 60,000 per hour. A limitation of this approach is that vandalism lasts longer the less-viewed the page is, and the pageviews vary based on time zones in areas where most of our readers are from. But I think some API somewhere can give you hourly pageviews.) — Bilorv (talk) 20:43, 4 February 2021 (UTC)

• Support pending changes protection as a trial: TFA is different from other highly-viewed pages in that there is very likely a highly active editor who is passionate about the article (the one who just promoted it to FA), and activity is limited to 24 hours (maybe the next few days as well, while it's still linked on the main page). I can't really speak for all such editors (I've only been that person once) but perhaps some would be able to look through all the changes at the very least after the dust has settled, and collect any of the changes which are productive. A counterargument is that TFAs are, well, featured articles, and so much less likely to have issues that new and unregistered users will be able to solve. But there are likely still small prose improvements that one might expect to be made in the TFA period. An alternative is maybe pre-emptively semi-protecting only some TFAs based on topic. — Bilorv (talk) 20:43, 4 February 2021 (UTC)
• Support Few useful changes are made, vandalism is a serious problem not for the number of vandals but for the black eye we get for allowing it on the front page. Volume of changes we are talking about is not great. So this is an excellent use of PC. Hawkeye7 (discuss) 04:33, 5 February 2021 (UTC)
• Support, in my view, this is the ideal balance between preserving both the integrity of our "anyone can edit" mantra, and quality of our featured articles. I tend to agree with Hawkeye that "few useful changes are made"—to the point where the amount of vandalism or unhelpful edits vastly outnumbers the occasional random spelling fix (and any major edits/errors would better be discussed on the talk page anyways). But either way, this protection could address both the vandalism and occasionally helpful edits. Aza24 (talk) 09:07, 5 February 2021 (UTC)
• (nom) I agree that any change should be on a trial basis.

My idea for the template text is along the lines of: "Welcome to Today's featured article. It is an unfortunate fact that these articles attract vandals. Therefore, changes by new editors are reviewed by experienced editors before they show up for everyone to see. This usually takes only a few minutes. If you are here to be part of the community whose goal is to improve Misplaced Pages - Thank you, and happy editing! You might find Help:Editing a useful beginners' guide. If you are here only to disrupt - Be off with you!" Narky Blert (talk) 18:04, 5 February 2021 (UTC)

• Support Would prevent instant publication of toxic or copyrighted material on such highly visited articles. ~ HAL333 02:58, 6 February 2021 (UTC)
• Upon notice I haven't explicitly said it here yet, support as one of the parties in the original conversation. Vaticidalprophet (talk) 13:53, 6 February 2021 (UTC)
• Oppose. PC protection generates significant amount of work for minimal benefit, and doesn't work on pages with a high volume of editing; those pages which attract enough vandalism to make protection worthwhile, are also going to be those pages on which PC won't work. PC also comes with significant additional drawbacks in addition to the maintenance backlog it generates; there's no way to add a summary when rejecting an edit, so when disapproving a good-faith but inappropriate edit one can't explain why in the edit summary; for BLP issues PC has little impact since it doesn't affect what Google scrapes (they pick up the most recent revision even if it's been unapproved); to approve/disapprove changes to an article at FA level often requires specialist knowledge of the topic, which the handful of people who work the Special:PendingChanges queue are unlikely to have; the whole proposal appears to be predicated on the idea that every, or at least most, FAs are going to be on peoples' watchlists, which just isn't the case. ‑ Iridescent 08:00, 7 February 2021 (UTC)

(Interesting to see you here -- I was literally just wondering what you would think of the proposition.) For what it's worth, "there's no way to add a summary when rejecting an edit, so when disapproving a good-faith but inappropriate edit one can't explain why in the edit summary" is incorrect -- the edit summary box is...huh, PC queue is empty as we speak, so my plan to take a screenshot for "right here" will have to wait, but it's prominently placed complete with giant "ADD AN EDIT SUMMARY IF WHAT YOU'RE REVERTING ISN'T BLATANT VANDALISM" bold text. Vaticidalprophet (talk) 06:37, 8 February 2021 (UTC)

In lieu of screenshotting the edit summary box itself, here's a screenshot from my recent PCR contributions showing them. Vaticidalprophet (talk) 06:42, 8 February 2021 (UTC)

Misplaced Pages as fact-checker

Hey, my name is Joey.

I think Misplaced Pages is great and would like to try to contribute to its success in the future.

Misplaced Pages is full of facts, making it a great place for research. It is also highly monitored, making it trustworthy. I think Misplaced Pages could fill another, in my opinion much needed, position in our modern society. Nowadays people have the option to post whatever they please on social media. I feel like a fact-checker, like the one Twitter recently implemented, is highly needed. I think Misplaced Pages could fill that role. The digital engineers behind the site could develop a system that would be able to check videos, text and images for how factually true it is. Then Misplaced Pages could strive to have a fact-check button implemented on every social media platform.

I think this is something that is indefinitely going to happen in the future and I think that Misplaced Pages would be the perfect organization to make it happen.

Thanks for listening to my idea. Greetings, Joey — Preceding unsigned comment added by 2001:1c04:3f14:6d00:5091:fa99:3bbc:f338 (talk • contribs) 13:09, 4 February 2021 (UTC)

Joey, please read about how Misplaced Pages is not a reliable source, or in other words, not trustworthy. We don't deal in truth, but in what can be verified. 331dot (talk) 08:03, 7 February 2021 (UTC)

• The problem is that a fact checking system like twitter’s would likely violate our WP:No original research policy.

All we can do is ensure that our information is accurate, based on what reliable sources tell us. And sometimes, the reliable sources disagree. When this happens, our WP:Neutral point of view policy says we can not choose between them, but must present what the various reliable sources say (even if we, as individuals, think one side of the disagreement may be wrong). Blueboar (talk) 14:31, 7 February 2021 (UTC)

Bot to remove year of birth/death categories when the claim is removed from the article body

This proposal is related to an open bot approval request (BattyBot 53). AWB, as part of its current genfixes, will add birth/death categories (like Category:1980 births) to biographies that contain a birth/death statement in the article body (either the lead sentence or the infobox, I think). However, it seems no process exists to remove the categories if the corresponding statement is later removed from the article. An example of this problem is at Advaitha (actress): adds an uncited date of birth, (automated) adds the corresponding category, and removes the date of birth as unsourced, but misses the category and it is left unsupported by the article, until manually removed by me much later.

I'm wondering if there is support for a bot to automatically remove these categories in this type of situation. Some additional thoughts, open questions, and potential objections:

• The bot should only remove the category if a birth/death claim formerly existed in the article and was removed, not if the category was added without a corresponding claim ever being present. (This would lead to the bot directly reverting a manual edit, which is not my intention.)
• To prevent edit warring, the bot should not remove a category from the same article multiple times, and could wait for some grace period (a day? a week?) before removing in case the removal of the claim itself was mistaken/vandalism.
• Should the bot replace the category with Category:Year of birth missing or a related category, or just remove it?
• "This would just result in multiple bot edits when there could be none. My watchlist and I hate bots with a passion." Yes, fair. The current situation, though, appears to be that these categories get added and are not always maintained. It is also possible that the category was originally added by a human, so this is not always a case of "bots reverting bots", but a bot cleaning up something a human missed.
• "Not a good bot task, too situational." Perhaps. The bot could log these issues and not directly action them. Would anyone bother to check the log? Part of the justification for this proposal is to avoid unsourced BLP information, on which I believe we should err on the side of removal.
• "The category should be automatically handled by the infobox/Wikidata, so there aren't multiple places to maintain this information." Maybe? This is a very different proposal. Not every article has an infobox, and not every {{Infobox person}} is in the lead section of a biography. There is frequent opposition to using Wikidata for this due to lack of review/quality sourcing.
• "The category system is terrible." Yes, but this is a non sequitur. The category system exists and we must maintain it, particularly for BLPs.

Thanks. — The Earwig ⟨talk⟩ 16:29, 4 February 2021 (UTC)

• My first thought is that this is a good idea, but as you say it needs workshopping a bit before implementation. For example, how will it cope if a duplicate year of birth/death statement is added and then removed, or the statement is changed without being removed (e.g. Born 1986 changed to Born 1987)? If it adds any categories it should be ones that are flagged as needing human review (perhaps "year of birth possibly missing" or something) - especially for deaths (we don't want living people in year of death missing cats). The bot will need to cope with people changing e.g. "born 1930" to "1930–2021" in a variety of formats. How will it cope with the year of birth/death being removed from the prose or infobox but not both? Maybe an edit filer for year of birth/death removed would be a good first and/or additional step? Thryduulf (talk) 02:30, 5 February 2021 (UTC)
  • Thanks Thryduulf, this is helpful. My original idea was to simply check whether the claimed year of birth/death is present in the page text or infobox at all, except for the category itself. It would be prone to false negatives, but seemed like a safe starting point for detecting situations where the category is completely unsupported. Of course, you are right to bring up the case where the year changes; I would be less comfortable about a bot doing something in that situation, but removing the category wouldn't be strictly improper? (I don't think I'd want the bot to change the category to the new birth year without human review.) Your comment on adding categories makes me think that it would be best to not add any due to uncertainty—a "year of birth possibly missing" category does not seem especially useful. I know there has been some prior discussion about the (lack of) utility of these. An edit filter is a good suggestion, but it might be difficult to build a useful one. I will think more about this. — The Earwig ⟨talk⟩ 08:44, 7 February 2021 (UTC)

logo

Recently the logo was temporarily changed to.....see image at right. In this case I'm proposing adding back 'The 💕' however with '20 Years over one Billion edits' the idea is that it is a milestone and hence would give even more credibility to the movement as its indicating how many years its been helping readers, and how many edits have been done--Ozzie10aaaa (talk) 19:15, 4 February 2021 (UTC)

@Coffeeandcrumbs, Valereee, and Armadillopteryx: who have very recent feedback on this on Talk:Main Page that I'm going to point to here. — xaosflux 19:45, 4 February 2021 (UTC)

thank you(it could be 'more than')--Ozzie10aaaa (talk) 19:49, 4 February 2021 (UTC)

• Support as proposer--Ozzie10aaaa (talk) 16:47, 5 February 2021 (UTC)
• Oppose. Pretty much every reader knows that Misplaced Pages is a very popular and well-established website, so we don't need to use up the most valuable space in our layout (since people begin reading at upper left) to remind them of that fact. I'd rather we keep using the official tagline ("the 💕"), which at least says something about our editorial philosophy. {{u|Sdkb}}  05:10, 5 February 2021 (UTC)

what I propose is this same logo with "The 💕" as usual on it--Ozzie10aaaa (talk) 15:51, 5 February 2021 (UTC)

Ozzie10aaaa, if you're proposing a logo change at VPR, it's preferable to have an actual logo file in hand, so that this sort of confusion doesn't happen. You could request that at the WP:Graphics lab if you don't know how to make it yourself. Without knowing where exactly you'd want to place each piece of text, I have to continue to oppose, although if you came back with a file and it looks better than I expect it to, there's a slight chance I'd change my mind. {{u|Sdkb}}  07:28, 7 February 2021 (UTC)

ok its here (Im not very good at images but you get the general idea)--Ozzie10aaaa (talk) 13:26, 7 February 2021 (UTC)

• Support Until February 15th and then bring back the normal logo in march unless the WMF opposes this idea and wants us to keep using the normal logo before the 15th 🌸 1.Ayana 🌸 (talk) 11:27, 5 February 2021 (UTC)
• Oppose We should stick with this one for a while more. Pretty notable milestone. Someone should really ping all of the editors who contributed to the previous discussion on this. ~ HAL333 02:54, 6 February 2021 (UTC)

HAL333 did you vote 'oppose' if your saying We should stick with this one for a while more. Pretty notable milestone....--Ozzie10aaaa (talk) 20:28, 8 February 2021 (UTC)

• The back and forth logo changes are probably confusing to the average reader who notices. Though, I guess that is quite representative of Misplaced Pages’s consensus building process, so perhaps a good thing to showcase. ProcrastinatingReader (talk) 08:59, 7 February 2021 (UTC)

RFC: Should certain succession box content, be deleted

Please consider joining the feedback request service. An editor has requested comments from other editors for this discussion. This page has been added to the following lists: Politics, government, and law History and geography When discussion has ended, remove this tag and it will be removed from the lists. If this page is on additional lists, they will be noted below.

Should we delete succession box content such as the following? Examples: "Oldest-living British prime minister". What say all of you? GoodDay (talk) 21:57, 4 February 2021 (UTC)

Survey (succession boxes)

• Yes. We ought not to have any of that trivia in succession boxes. There are often many boxes, dozens even, and additional clutter is unhelpful. One would be very hard-pressed to find reliable sources discussing how James Callaghan "succeeded" Alex Douglas-Home as the oldest British prime minister, and I dare say that no biography of either of them mentions it. Surtsicna (talk) 22:15, 4 February 2021 (UTC)
• Yes. Only posts with transitions (or successions) would need succession boxes. -- Kautilya3 (talk) 22:56, 4 February 2021 (UTC)
• Not here. Trivia should be deleted, non-trivia should not be. Whether any specific succession is or is not trivia needs discussing individually at an appropriate forum - that forum is very much not here. Thryduulf (talk) 02:21, 5 February 2021 (UTC)
• No As Thryduulf says trivial ones should be, non-trivial ones should not be. That needs to be done on a case by case basis. -DJSasso (talk) 18:03, 5 February 2021 (UTC)
• Yes I find succession boxes unnecessary in general since they usually duplicate the infobox, a navbox, and/or the text. When it's not duplicative like this example, it's often trivial that doesn't need a box to itself. Reywas92 19:36, 5 February 2021 (UTC)
  • You dislike them, whereas I find the clear, consistent presentation extremely useful. Succession boxes, infoboxes, navboxes and prose all serve different functions and so the same link appearing in more than one place is a Good Thing. Some succession boxes should be removed, but most should not be. Which is the case for any given succession box can only be determined by a consensus discussion about the succession box in question. Thryduulf (talk) 01:04, 6 February 2021 (UTC)
• Yes and would support getting rid of them all. Redundant and pointless clutter. Why not have separate boxes for marriages, spouses, and works dispersed througout the article while we're at it? ~ HAL333 02:50, 6 February 2021 (UTC)
  • What are they redundant to? Links in prose and links in succession boxes have different purposes so they are not redundant to each other. Boxes (for anything) scattered throughout the prose would be completely disruptive to the prose, which is why succession boxes are not placed in the middle of the prose? Thryduulf (talk) 11:58, 6 February 2021 (UTC)
• Yes - Not sure we even need them for positions, but definitely not for superlatives. Levivich /_hound 17:22, 6 February 2021 (UTC)
  • All superlatives? What about tallest buildings and longest bridges? Those seem extremely useful succession boxes to me. Thryduulf (talk) 18:24, 6 February 2021 (UTC)
• Comment: I feel the validity or triviality of succession boxes should be discussed on a case by case basis on their respective talk page. Not sure what a global decision one way or another on "trivial" succession boxes could achieve, when it does nothing to establish what is trivial and what is not. PraiseVivec (talk) 14:01, 7 February 2021 (UTC)

Discussion (succession boxes)

• Why? Ivanvector's squirrel (/_nuts) 22:17, 4 February 2021 (UTC)

  Because, those are not political or party offices. They're merely trivial. GoodDay (talk) 22:19, 4 February 2021 (UTC)

  Why do we need a global policy or guideline or anything about this? If you think a given succession box is trivia, discuss that specific succession box somewhere (talk page, WikiProject, TfD, there are plenty of venues). I genuinely don't understand what you are trying to achieve here - there is no chance that there will be a consensus that we should have succession boxes for everything (10th place qualifier in a British Touring Car Championship race as an unquestionable example), but with the wording of the discussion you cannot get consensus (for or against) regarding any individual example. Thryduulf (talk) 02:18, 5 February 2021 (UTC)

  You expect there to be a separate discussion on each individual bio article? Anyways, I don't exactly know what you're posting about. GoodDay (talk) 17:29, 5 February 2021 (UTC)

  I expect you to get consensus for each individual succession. That could be on an article talk page or a centralised discussion. e.g. if you want to get rid of oldest living British Prime Minister, you need to have a discussion specifically about removing the "oldest living British Prime Minister" succession box from every article it appears on, with notifications to (at least) the talk page of all the affected articles. In other words you need to do exactly the same as you would for any other bulk change. Thryduulf (talk) 22:26, 5 February 2021 (UTC)

  That's too time consuming. There's too many 'useless' topics in these succession boxes, to go through one-by-one. GoodDay (talk) 22:30, 5 February 2021 (UTC)

  A centralised discussion about the succ boxes for oldest living British Prime Minister could be held at Misplaced Pages talk:WikiProject Politics of the United Kingdom. --Redrose64 🌹 (talk) 23:40, 5 February 2021 (UTC)

  But the British prime ministers example, is just one example of these trivial topics in suc-boxes. GoodDay (talk) 23:41, 5 February 2021 (UTC)

  The issue is that we have no idea what other succession boxes you regard as trivial so we (and most importantly editors of the articles they appear on) have no way of knowing whether we agree or disagree. While oldest living British Prime Minister doesn't seem very useful, others such as Prime Minister of the United Kingdom is very much not trivial, where to draw the line between them needs to be determined by consensus. Thryduulf (talk) 00:59, 6 February 2021 (UTC)

  Subjects like "Tallest President of country", "Fattest Prime Minister of country", "Oldest Stock Car racer", "Youngest 100 meter dasher", would be trivial topics for suc-boxes. GoodDay (talk) 02:18, 6 February 2021 (UTC)

  The first two undoubtedly would be trivial, the latter two maybe - it would depend if there was any significance given to this in reliable sources. However a short list of topics (which a cursory search suggests are not in use) that you consider trivial do not go any way towards addressing the issue in my comment. Thryduulf (talk) 18:20, 6 February 2021 (UTC)

  I don't know what your complaint is. Perhaps if you would put down examples of suc-box topics that you believe should & shouldn't be deleted, would help. GoodDay (talk) 18:26, 6 February 2021 (UTC)

  My point is that they need to be discussed individually or in small, closely related groups (e.g. perhaps succession boxes related to British Prime Ministers). No matter how many examples are listed here you cannot get consensus for anything not listed here, and the more examples you list here the greater the liklihood of a trainwreck. Thryduulf (talk) 00:10, 7 February 2021 (UTC)

  RFC is already in full swing. We'll see how it ends up. GoodDay (talk) 00:47, 7 February 2021 (UTC)

  Consensus that some but not all succession boxes should be removed, but no consensus for the removal of any one in particular - that will need further discussion. It's pretty much the only way it can end. Thryduulf (talk) 02:20, 7 February 2021 (UTC)

  Besides, I find Wiki-Projects tend to garner less attention. Was considering moving another RFC to Village Pump, for the same reason. GoodDay (talk) 23:55, 5 February 2021 (UTC)

  Your subjective opinion that something is "Too time consuming" does not grant you the right to ignore WP:CONSENSUS. If you propose a course of action on a WikiProject and advertise the discussion to the relevant talk pages but nobody opines after a reasonable time (~week) then you can go ahead and remove the succession boxes listed in the discussion. Thryduulf (talk) 00:59, 6 February 2021 (UTC)

  If you want to advertise this RFC on the related WikiProjects? then by all means, do so. GoodDay (talk) 02:18, 6 February 2021 (UTC)

  If this discussion was actually about specific succession boxes that would be appropriate, but as the discussion is actually a vaugie and unfocused attempt to get rid of an unspecified list of succession boxes you (or presumably any other editor) personally dislikes then it is impossible to know which projects and articles are relevant. On the other hand, if you did deign to list those boxes you deem trivia, then it would I suspect rapidly become a trainwreck due to the large number of disparate boxes editors will have different opinions about. Thryduulf (talk) 11:55, 6 February 2021 (UTC)

  Since my concerns grew out of the discussion at James Callaghan, one would link to Political WikiProjects. GoodDay (talk) 18:41, 6 February 2021 (UTC)

All should be delete as links spam due to duplication of links and undue because of overwhelming size. Never understood why we have giant boxes with very few links in them overwhelming the sections. It's definitely a point of contention for content editor that these undue boxes are spamed automatically without consideration of over linking or unwarranted linking.--Moxy 🍁 00:04, 6 February 2021 (UTC)

Very simply because many (not all) of the succession boxes are very useful for readers. Thryduulf (talk) 00:59, 6 February 2021 (UTC)

Not sure how duplication of lnks and overwhelm sections is good for readers. We have protocols for these 2 points....just ignored by template spammers.— Preceding unsigned comment added by Moxy (talk • contribs) 01:19, 6 February 2021 (UTC)

See my reply in the section above for why duplication is not a problem, and I disagree that the presentation is overwhelming. That some succession boxes are trivia does not mean every succession box is spam. Thryduulf (talk) 01:41, 6 February 2021 (UTC)

We will simply have to disagree. By placement practice alone indicates there very low value to the community. See also links dumped at the bottom of articles because they duplicate existing links and the format is not responsible anywhere else in the articles. It's horrible that these boxes are more prominent than the actual topic-specific navigation boxes. Odd they were not omitted from mobile view as load junk.--Moxy 🍁 02:01, 6 February 2021 (UTC)

How does placement indicate they are low value? Of course the format is not appropriate anywhere else in the article - see also links and links in succession boxes have a completely different purpose to links in the prose. You need to explain why the duplication is problematic. Thryduulf (talk) 11:55, 6 February 2021 (UTC)

It's why we have a guideline on this..... distracts readers from the links that are actually important Misplaced Pages:Overlink crisis. They are so overwhelming that editors hide them in collapsible templates Abraham Lincoln#External links. In many other cases the amount of them is simply overwhelming...mass link spam John A. Macdonald#External links.--Moxy 🍁 17:59, 6 February 2021 (UTC)

Some countries aren't even protected!

While I was searching about Burma, I then went to Israel. It was "Extended-Confirmed". Then I went to the Malta page and it didn't have any protection! There should be a policy that all countries MUST have at least some protection on their articles.

Avishai11 (talk) 23:59, 4 February 2021 (UTC)

Avishai11, articles are protected only when it's truly necessary. You can learn more at WP:PP. Schazjmd (talk) 00:04, 5 February 2021 (UTC)

(edit conflict) @Avishai11: We do not pre-emptively protect pages; we apply protection when it is necessary to do so - persistent vandalism, for example. What kind of edits are you thinking of that protection would have prevented? --Redrose64 🌹 (talk) 00:08, 5 February 2021 (UTC)

Avishai11, like most Israel-Palestine related articles, the Israel article has Extended confirmed protection because of ArbCom enforcement. You can read about that here - WP:A/I/PIA. As for other country articles, they can be protected individually if they have persistent disruption. Otherwise it is not necessary. AVSmalnad77 05:35, 5 February 2021 (UTC)

Topic blocks to complement topic bans

Now that we have the capability of blocking editors from editing specific articles, is there a way that we can bundle together all articles within a specific topic area (e.g. post-1992 American politics, COVID-19, Beyoncé) so that an editor who has been topic-banned from editing in those areas could in fact be blocked from editing pages deemed to fall within those areas? BD2412 T 21:19, 8 February 2021 (UTC)

Thought about this before, and imo it seems to be technically infeasible. There's no special way to determine whether an article is really within the AP2 editing area. There are talk page DS notices ({{Ds/talk notice}}), but anyone can place that so relying on it would be problematic (eg I'd be able to place that notice on a random article to block people from editing it. highly likely to be abused). Of course, this assumes that the page blocking functionality could work with categories or templates, which it can't. ProcrastinatingReader (talk) 21:26, 8 February 2021 (UTC)

Another problem is articles that include both content under the ban and content not under the ban. For example, the article for any year since 1992 is going to include both AP2 and non-AP2 content. _signed, Rosguill 21:30, 8 February 2021 (UTC)

I had two thoughts for specific approaches. One would be by the category tree where the Tban is specific to something like a country or a musical artist. The other would be to manually construct a list on a protected page in project space and reference it. An actual block on editing would likely only apply to pages squarely within the Tban. BD2412 T 22:18, 8 February 2021 (UTC)

• I believe there was an RFc before pblocks were implemented discussing this and "category" style pblocks being too easy to game...CUPIDICAE💕 22:31, 8 February 2021 (UTC)

• Misplaced Pages village pump
• Misplaced Pages proposals
• Misplaced Pages requests for comment