Jump to content

Wikipedia:Village pump (proposals)/Archive 212

Add links
From Wikipedia, the free encyclopedia
Village pump (proposals) archive  

This page contains discussions that have been archived from Village pump (proposals). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.

< Older discussions · Archives: A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z, AA, AB, AC, AD, AE, AF, AG, AH, AI, AJ, AK, AL, AM, AN, AO, AP, AQ, AR · 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213

Wikipedia Sandbox

Not sure what happened here Wikipedia:Sandbox? May have been a talk about redoing layout adding tabs? Would have brought this up on its talk but iit is also a sandbox (where to talk about sandbox?).

To thw point..... Not only does it look very bad, but its an accessibility nightmare.

Wikipedia Talk page Template Draft User User talk page Module My Test Wikipedia

Tabs look horrible...2 tabs are using the strike parameter for those using the strike out usernames gadget...word "sandbox" is reapted over and over making tabs huge for no reason.

Main problem is the accessibility of the sandbox message that is a wall of text that is not clear as to what to click.start. Tabs cause whole page to have vertical scroll bar for some. Why so many sandboxes and some with odd space in naming i.e Wikipedia talk Sandbox? Why link Module:Sandbox that is template editor level protected? Looks messy and a bit overwhelming for new editors Moxy🍁 06:00, 12 April 2024 (UTC)

The tabs were added in this edit to Template:Sandbox header by Awesome Aasim. – Joe (talk) 06:41, 12 April 2024 (UTC)
I guess that is what WP:BRD is for.
I self reverted for now and we can discuss which tabs, if at all, are worth keeping. The perspective for a new user is that there should be a way to jump between the different sandboxes. If you want the tabs to read something else, well... {{sandbox heading/Tabs}}. Awesome Aasim 06:48, 12 April 2024 (UTC)
2 tabs are using the strike parameter for those using the strike out usernames gadget probably because User:Sandbox and User_talk:Sandbox are both user pages of a blocked demonstration account. It shouldn't be like that; maybe it should only be struck out, etc. in contributions and history pages and not on content pages. Hmm.... Awesome Aasim 06:53, 12 April 2024 (UTC)
Tangentially related, but I've made a request at Template talk:Page tabs#Tab background color to change the default tab colors so it meets the MOS:CONTRAST accessibility guidelines. hinnk (talk) 13:57, 16 April 2024 (UTC)

Template substitution counter

There is currently no way to track template substitutions without adding code to templates that adds tracking marks to the template's output, and some bot watching for these marks. Aside from all that overhead, these marks may make use of this mechanism impossible in some cases.

Tracking substitutions should be a comparatively simple modification to MediaWiki. When a template gets substitued, just increment the appropriate per-template counter, which could be accessed through a magic word. If you want to get fancy, you can add a list of the substitutions performed for this edit to its page history entry.

Having such a counter would be useful when a template is up for discussion, and to help gage when protection is appropriate. So, why not make a feature request? Paradoctor (talk) 03:02, 6 April 2024 (UTC)

Support - I can see the use of this when templates are rarely transcluded, but nearly always used by substitution. Cocobb8 (💬 talk • ✏️ contribs) 13:29, 6 April 2024 (UTC)
What would happen when a template is substituted in one edit, and that edit is subsequently reverted? --Redrose64 🌹 (talk) 13:37, 6 April 2024 (UTC)
Why should that be an issue? Paradoctor (talk) 13:41, 6 April 2024 (UTC)
Presumably nothing, if the intent is to understand how often a template is substituted (and thus how "important" a template is, and thus whether it should be protected/watched). That the resulting text was subsequently reverted doesn't change that the substitution happened.
It seems like a slightly useful feature to me.
The only thing I would question is whether we have any evidence of an actual problem that needs solving. I suspect most of the commonly substituted templates are well known, like {{afd}}, and are already recognised as high risk. Barnards.tar.gz (talk) 12:42, 8 April 2024 (UTC)
We have evidence that we don't know. That is the point here. Paradoctor (talk) 14:54, 8 April 2024 (UTC)
What I mean is that if the important templates were being vandalised, we would probably have noticed that. Barnards.tar.gz (talk) 18:56, 8 April 2024 (UTC)
Why make editors do guesswork when a machine will do the same far more accurately, for free? Paradoctor (talk) 02:55, 9 April 2024 (UTC)
I get it, that’s why I said it was slightly useful. It would be a good feature. Just a low priority one unless there’s a material problem that it would fix. Barnards.tar.gz (talk) 07:40, 9 April 2024 (UTC)
Why not using "What links here"? CactiStaccingCrane (talk) 12:19, 8 April 2024 (UTC)
I think what is being said here is that when the template is substituted, it isn't being linked or contacted in any way (because its content is being posted). Lee Vilenski (talk • contribs) 12:31, 8 April 2024 (UTC)
  • @Paradoctor: This isn't something that we would be implementing directly here on the English Wikipedia. It would require extending the database to maintain a new page value (or more likely a new linked table) - keeping in mind almost any page can be "transcluded". So if you want every parser call to {{subst:X}} to increment a counter referenced to page X, you will indeed need to open a feature request upstream for that. Feel free to do so, there are lots of ideas opened that way. — xaosflux Talk 14:39, 9 April 2024 (UTC)
    why not make a feature request?[1] Sometimes I wonder why I bother to say anything at all. Paradoctor (talk) 15:56, 9 April 2024 (UTC)
    And? You are asking for reasons why you shouldn't go make a feature request? We didn't come up with any, so go right ahead. While this page's guidelines do ask for Software changes which have consensus should be filed at Phabricator. to be discussed here, what I called out is that this type of software change isn't the type that will require community consensus. It would have no impact on readers, and no direct impact on editors. — xaosflux Talk 23:53, 9 April 2024 (UTC)
    What's the mechanism by which page saves get run through edit filters? Presumably there is something being carried out there which is capable of evaluating whether a thing's been done or not -- I don't know, maybe it's impossible to detect if template text is being expanded or not, but it seems kind of simple to me. At the very least it shoudl be possible to detect if {{subst: is being added, right? jp×g🗯️ 18:40, 11 April 2024 (UTC)
  • Well, no bigbrain comments on how this fits into the mw db schema or anything, but one issue with this does jump out to me, which is that this seems like it would fail to reflect if the template were removed later. Like, if there is some template that's getting substed 80 times a day in 2024, then we decide it's inefficient and stop using it completely in 2025, wouldn't a {{TOTALSUBSTCOUNT}} in 2026 be kind of misleading? jp×g🗯️ 18:40, 11 April 2024 (UTC)
    You just gave me an idea. Let me get back to you tomorrow. Paradoctor (talk) 19:46, 11 April 2024 (UTC)
  • Is this something we really need to track? Personally, I hate our over-reliance on templates, and would be happy to deprecate all of them. Blueboar (talk) 18:54, 11 April 2024 (UTC)
    You mean, no templates at all? 🤯 Paradoctor (talk) 19:47, 11 April 2024 (UTC)

Tagging blocked socks

I have recently noticed that @Liz has reverted my edits on blocked sockpuppet User:JayCubby for adding the {{Sockmaster}} tag on the userpage. The template page itself states that it is reserved for administrator and checkusers only, however I believe that it should be open to use for everyone in good faith who attempt to save others' time by putting this template on a blocked sock's user page to help improve the encyclopedia. I propose that the rules on that template be changed to accomodate this requirement. 2003 LN6 15:53, 18 April 2024 (UTC)

Also pinging @Primefac as original blocker. 2003 LN6 15:57, 18 April 2024 (UTC)
How exactly do you mean, "help improve the encyclopedia"? -- zzuuzz (talk) 16:35, 18 April 2024 (UTC)
@Zzuuzz:It would save time for editors wanting to know exactly why the user was blocked and when. This way, they would not need to go into their contribs and find out themselves. 2003 LN6 18:55, 18 April 2024 (UTC)
So why propose this for just sock blocks if the intention is to save time on finding why a user was blocked? Not that I want it called out on the user page for everybody, but I'm just saying, why stop there if that's the goal? Hey man im josh (talk) 21:33, 18 April 2024 (UTC)
There's probably an appropriate amount of information on the talk page for that purpose. The global lock reasons also raise significant questions. These tags can sometimes be useful to help locate the correct SPI/LTA page for finding, reporting and actioning repeat customers where it's not entirely obvious (carefully balanced with WP:DENY), but for someone who just made a mistake it's overkill with little utility. Not only might it oversimplify a complex situation, it may even overcomplicate a simple situation. Whatever the case, I don't really see how the tags would really help with anything here. -- zzuuzz (talk) 23:29, 18 April 2024 (UTC)
Template documentation isn't policy and while non-admins/non-clerks are informally discouraged from tagging socks, in practice most will look the other way if the tagging is reasonable. But there are various situations where we will choose not to tag in the interests of WP:DENY, discretion, or not oversimplifying a complex situation. I would not have tagged this account and I would suggest you find a more interesting thing to do on Wikipedia than applying tags to user pages. Spicy (talk) 16:54, 18 April 2024 (UTC)
(edit conflict) Agreed; there are more productive things for editors to do than go around tagging blocked users' pages. Primefac (talk) 16:58, 18 April 2024 (UTC)
@Spicy: Thank you for your explanation. Why would it be discouraged from tagging this user particularly? You have explained that it is generally fine if the tagging is reasonable and I believe that my use of the tag was reasonable. 2003 LN6 18:54, 18 April 2024 (UTC)
Making a fuss about blocked users is not helpful. People who deal with socks are quite capable of tagging where they believe there is a benefit. There might be many reasons a particular page is not tagged and discussing details is a waste of time and the opposite of WP:DENY. One example of why a sock might not be tagged is that we just want them to find another hobby and avoid righting-great-wrongs at Wikipedia. Johnuniq (talk) 23:30, 18 April 2024 (UTC)
  • Non-admin tagging of socks presents a few problems. 1: It doesn't improve the experience for the reader in any way whatsoever, so there is no pressing need for a tag to be applied immediately, if at all. 2: Mistakes are often made, which raises WP:CIVILity issues, and causes drama that admin often have to deal with. 3:Admins are accountable to the community, non-admin/IPs are not, so the labeling of someone as a chronic policy violator should be limited to admin only, the majority of the time. There are several reasons why admin choose to NOT tag some socks, including WP:DENY, which can be based on non-public information that non-admins don't have access to. Dennis Brown - 2¢ 23:49, 18 April 2024 (UTC)
  • @2003 LN6: I'd just like to point out, since maybe you missed it, that you tagging accounts as socks (in this case before they were even blocked) had already caused confusion for the administrator who blocked them in this ANI thread(it caused one of the socks to not be blocked): Wikipedia:Administrators'_noticeboard/IncidentArchive1153#Sockpuppet?
    The admin, @Drmies, had also asked you to leave the tagging of socks to admins or SPI clerks, as well: Special:Diff/1218557430. – 143.208.238.41 (talk) 06:11, 19 April 2024 (UTC)

Thank you for all of your comments. I appreciate the feedback and will conform to these guidelines in the future. 2003 LN6 19:06, 19 April 2024 (UTC)

RfC: Converting all current and future community discretionary sanctions to (community designated) contentious topics procedure

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.
There is a consensus that there should be clarity and consistency regarding general sanctions language, including by using the language of "contentious topics" (CTOP) rather than "discretionary sanctions" (DS).[a] However, as most keep !votes focused on clarity of terminology rather than procedure, no consensus developed to adopt either the particular procedural proposals of this RfC or Barkeep's counter-proposal. Further discussion (and likely a follow-on RfC) is needed to determine: (1) what boilerplate text to adopt for general use in community CTOPs; (2) the proper forum for imposing or modifying community CTOP restrictions; (3) the proper forum for enforcement of community CTOP restrictions; and (4) how to handle potential deviations of community from ArbCom CTOPs. voorts (talk/contributions) 02:13, 20 April 2024 (UTC)

Notes

  1. ^ This arguably eliminates the need for the broader language of "general sanctions", which encompasses CTOP and DS, since everything will just be CTOPs.


Should all community discretionary sanctions (DS) be updated to use the new contentious topics procedure? Awesome Aasim Refreshed 01:18, 8 March 2024 (UTC) 05:55, 7 February 2024 (UTC)

Background

In late 2022/early 2023, the discretionary sanctions procedure was overhauled by ArbCom and converted to "contentious topics". With now two different processes for two different kinds of sanctions there is now a lot of fragmentation and inconsistency in how contentious topics should be handled, with even conflicting wording. The main goal of this RfC is to unify the procedure used for all areas where general sanctions are in effect with the one designated by ArbCom, going forward.

As proposed at this time, there will be the some similarities and differences between community and arbitration contentious topics, including:

  • The imposition of the standard set of restrictions by consensus of administrators in a community designated topic would be at WP:ANI rather than WP:AE.
  • Reconsideration of contentious topic restrictions would be done at WP:AN instead of at WP:AE or WP:ARCA.
  • Awareness of a community contentious topic would include but not be limited to being mentioned in the discussion closing summary regarding that contentious topic, which is the closest there is to a "final decision".

And of course, ArbCom would be able to convert community contentious topics to those designated by the committee, after which all the ArbCom venues would have to be used from that point forward, though existing restrictions would remain appealable to WP:AN until renewed at ArbCom.

Survey (community contentious topics)

  • Support as proposer. It needs to be clear, especially for new editors, what contentious topics are and what the expectations are for editing topics designated as contentious by either ArbCom or the community. A unified procedure will ensure consistency rather than fragmentation and will make editing the list of contentious topics and their restrictions much easier. (I did do a little bit of work in the Module:Sanctions/sandbox adding in support for ArbCom contentious topics, as it would make it so much easier to use the related sanction templates. I also did work in user space to help envision what a unified contentious topics page might look like.) Awesome Aasim 05:55, 7 February 2024 (UTC)
  • Strong Oppose The current iteration of WP:CTOP is far too tied in to the Arbitration Committee. The available sanctions and procedures are under the jurisdiction of WP:AC/PR can be modified by the Committee by motion at any time, which in this scenario would be binding on decisions made by the community without community consensus. Additionally, many of the General Sanctions areas have a set of restrictions that either exceed what CTOP would allow, or have a more limited subset of them. The community currently has the flexibility to customize sanctions based on the needs of the individual topic area (similar to how Arbcom can impose their own restrictions either alone or on top of the CTOP designation), rather than relying on a "one size fits all" solution. Regarding the possibility of Arbcom choosing to convert community-based CTOP to Arbitration Enforcement, the Committee already has the power to supercede and convert General Sanctions. They've done so before, in cases including WP:ARBCC and WP:ARBTPM. This proposal as written would reduce the community's autonomy and flexibility for the sake of consistency, and I don't see that as a net positive.
    I would, however, support the community adopting a "standard/default" DS language that could be used when customization isn't needed, and reviewing all the existing GS areas to see if they should be abolished or modernized. Updating our own process, templates, info pages etc to completely separate from the Arbcom version would also accomplish this proposal's goal of reducing confusion and would be better than the current system of sometimes linking to CTOP, sometimes linking DS which redirects to CTOP (when they really mean the older version of DS), sometimes a completely different thing with no consistency. Template:Gs/alert is one example of this, where it links to WP:CTOP even when the actual restrictions are unrelated to that designation. Revamping our own procedures would be a better way to reduce fragmentation and confusion than glomming onto what Arbcom chooses to do. The WordsmithTalk to me 18:32, 7 February 2024 (UTC)
    I am not exactly seeing how this is a dealbreaker. The CT procedure applies only to designated contentious topics; community consensus or arbitration remedies can always add additional sanctions regardless of WP:CTOP like in WP:ARBPIA. Awesome Aasim 22:13, 7 February 2024 (UTC)
  • Support The phrase "discretionary sanctions" is not clear and so the phrase "contentious topics" was introduced as an improvement. We should have clear and consistent language for contentious matters so that discussions and actions are comprehensible. Andrew🐉(talk) 08:57, 10 February 2024 (UTC)
  • Support. The "sanctions regimes" are too complex as it is, and we need to use consistent terminology to reduce that complexity when possible.  — SMcCandlish ☏ ¢ 😼  13:03, 21 February 2024 (UTC)
  • Support. The contentious topics procedure incorporates all of the improvements from the 2021-22 review of the discretionary sanctions procedure. Compared to the discretionary sanctions procedure, the contentious topics procedure is much easier to understand and follow. For example, many editors currently need to be reminded of topic areas under community sanctions every 12 months to be eligible for certain remedies, which led to complaints in the 2021-22 review. Switching from discretionary sanctions to contentious topics would eliminate this requirement: "Editors no longer need to be alerted every 12 months, as they are presumed to remain aware after their first alert." — Newslinger talk 04:45, 9 March 2024 (UTC)
  • Support making the rules clear and consistent to all users. A big part of the problems I've had with DS is that I couldn't tell what was expected of me. No comment on whether this new way of doing things is better or worse than the old one, but it sounds like this isn't that conversation. I 100% support clear and proactive explanations of what Wikipedia does and does not want from its editors. Darkfrog24 (talk) 16:10, 9 March 2024 (UTC)
  • Support making the rules clear and consistent for all editors. Let'srun (talk) 19:33, 10 March 2024 (UTC)
  • Support standardization — as is, the current discrepancy is an unintended relic, not a feature. Community-imposed vs Arbcom-imposed sanctions is a clerical, technical distinction, and I cannot think of any good reason not to streamline the two into the same concept, for the sake of simplicity and understanding. ~Swarm~ {sting} 02:39, 12 March 2024 (UTC)
  • Support Contentious topics is confusing enough by itself. Two similar but not identical rules is too much. I support any efforts to standardize our sanction systems. Galobtter (talk) 02:53, 12 March 2024 (UTC)
  • Support in the abstract – it might require some case-by-casing, but I think in general, having one set of rules for everyone is much cleaner and easier to understand for those trying to follow the road. theleekycauldron (talk • she/her) 00:00, 17 March 2024 (UTC)
  • Oppose (despite abstract support) as ANI has generally been the wrong forum for General Sanctions work. In my mind it should be a pump or AN and ANI should be out of the whole system. I also think it's a missed opportunity to not allow community GS to be heard at AE. There is already the community option for AN but this proposal would have created the option of using AE which is the forum many think about anyway. Outside of these details I'm supportive of the effort (given the fact that amongthe few who have expressed an opinion there seems to be overall support). Barkeep49 (talk) 14:55, 21 March 2024 (UTC)
    Would you support having community contentious topics use the ArbCom noticeboards instead? Awesome Aasim 17:35, 29 March 2024 (UTC)
    That seems like it would be confusing using Arbitration Enforcement, since some sanctions would be relevant to Arbcom and some wouldn't. There's a workable idea in here somewhere, and I think unifying all the sanctions noticeboards into one venue is it. There used to be Wikipedia:Community sanction noticeboard where appeals were heard, before it was retired in 2007 and merged into AN. Having something like a Wikipedia:Sanctions noticeboard that merges General Sanctions enforcement/appeal, requests for new General Sanctions areas that are now at the Village Pump, Arbitration Enforcement/CTOP, and topic ban enforcement into one unified board. The structure of requests there should probably mirror the current AE pretty closely, since that format seems to work better than the free-for-all unstructured discussion at other boards. The WordsmithTalk to me 18:28, 29 March 2024 (UTC)
    If I recall correctly ArbCom has authorized the use of AE for community general sanctions using DS/CT. Is that still the case or was I wrong the whole time? But that is what I refer to "using ArbCom noticeboards". Awesome Aasim 05:08, 30 March 2024 (UTC)
    When the shift was made to Contentious Topics, the option was made explicitly for the community to use AE if it wished. Barkeep49 (talk) 22:45, 16 April 2024 (UTC)
    My problem with relying on AE for them is that decisions there are ultimately made only by administrators and rely heavily on ArbCom decisions in turn. ArbCom is the last stop for things that the community has failed to handle, and administrators are the second-to-last stop; but for thing like DS/CTOP designations, which can have a sweeping practical impact on editing across a large section of the wiki, the initial decision-making ought to be made by the community as a whole. --Aquillion (talk) 17:45, 17 April 2024 (UTC)
  • Oppose Ivan (talk) 20:58, 21 March 2024 (UTC)
  • Support - I don't have anything to add beyond what Galobtter said - perfectly expressed. —Ganesha811 (talk) 01:18, 22 March 2024 (UTC)
  • Oppose as written but open to most of the content of the proposal, per Barkeep49. signed, Rosguill talk 17:49, 29 March 2024 (UTC)
  • Oppose for the exact reasons given by Rosguill. Dennis Brown - 2¢ 23:50, 29 March 2024 (UTC)
  • Oppose Wikipedia:Community discretionary sanctions isn't even active, so why would it be merged? — xaosflux Talk 17:30, 1 April 2024 (UTC)
    The proposal is for community-authorized discretionary sanctions to be modified to follow the contentious topics procedure. isaacl (talk) 17:39, 1 April 2024 (UTC)
    Thanks, so just a really misleading title. Reaffirm oppose though, we should not abandon a community process further in to arbcom. — xaosflux Talk 17:46, 1 April 2024 (UTC)
    My apologies for being overly concise in my previous comment: the proposal isn't to abandon community-authorized discretionary sanctions, but to align its procedures with the contentious topics procedures. It would remain under community control, with the changes to procedure that were introduced as part of contentious topics (such as a standard set of restrictions, sanctions no longer being limited to a year, only one template-based notification required for the first notification about contentious topics). isaacl (talk) 17:57, 1 April 2024 (UTC)
    This is still a very confusing proposal, as it is not very clear about what exactly it wants changed. For example, I can't see why something that has nothing to do with arbcom remedies would need to be recorded at Wikipedia:Arbitration enforcement log (per the WP:CTOP requirements that this proposal appears to to merge in). — xaosflux Talk 10:31, 2 April 2024 (UTC)
    Further development of the details do still need to be worked out. Community-authorized discretionary sanctions was defined by pointing to the arbitration committee discretionary sanction pages and saying, like that, but with a few differences. When those pages were renamed, that left a hole. In my view, ideally the community would define its preferred base procedure, and then the arbitration committee could point to it and say like that, but with a few differences. Those differences could include locations of logs and appeals (this proposal does explicitly specify a different location for appeals). I appreciate the viewpoint of those who would prefer to have a separation based on the group responsible for the designation of a contentious topic. But maybe that purpose can be served another way, such as a lookup table with appropriate links to the specifics for each variant. From the perspective of users encountering the concept of discretionary sanctions/contentious topics for the first time, I feel it's confusing to be using both the older version and the newer version of the process simultaneously. isaacl (talk) 15:39, 2 April 2024 (UTC)
    Which is why I'm leaning that this is a bad proposal. It should have been work-shopped more first. Make X like Y, but not really like Y is messy. — xaosflux Talk 14:09, 3 April 2024 (UTC)
  • Support it will be easier to understand the community-imposed restrictions and could allow the same templates to be used to make the process more unified. Dreamy Jazz talk to me | my contributions 18:03, 1 April 2024 (UTC)
  • Conditional support "Discretionary Sanctions" needs to be deprecated – the phrase is archaic, bureaucratic, and meaningless. However, the noticeboard should not be ANI (per Barkeep), since that place is a mess, whereas sanctions enforcement should be more clear-cut than the usual ANI fare. Toadspike (talk) 09:48, 3 April 2024 (UTC)
  • Support unifying community discretionary sanctions under the contentious topics procedure as it promises to significantly simplify Wikipedia's administrative framework, especially for new users. Adopting one coherent, streamlined process will mitigate the confusion and frustration associated with understanding the diverse existing sanctions systems. FailedMusician (talk) 21:48, 12 April 2024 (UTC)
  • Support as a starting point, although there are a lot of details to hash out and we should probably approach a community CTOP policy page bit-by-bit rather than trying to create it in one go via an RFC. (I am not sure ANI is the best place for this for reasons I'll get to in a moment, it's just better than what we have.) It's important that there be a way to create or modify CTOPs that the entire community can weigh in on and form consensus around; they can drastically affect editing in an entire swath of the wiki. ArbCom's remit is only to resolve problems that the community has failed to solve, and neither they nor administrators are supposed to be creating or modifying policy by fiat, so given how widespread and central CTOPs have become, it makes no sense for the only way to modify CTOPs to be decision-making processes that go only through administrators or arbcom. In fact I would go a step further (though I think doing this cleanly would require cooperation with ArbCom and agreement on their end to modify existing CTOPs in this regard) and say that a clear, unambiguous community consensus on a particular CTOP ought to be able to move it from ArbCom to community control, since it is an indication that the community can now handle it. CTOPs have grown drastically from their initial origins and affect enough of the wiki (in a way that effectively amounts to an intricate set of policies affecting much of our editing) that it no longer makes sense to leave ArbCom as the final decision-maker regarding them, at least in situations where the community can reach clear and unambiguous agreements. I do agree with some comments above that a noticeboard rather than AN / ANI would be a better place to do things related to CTOPs, though - the whole issue is that CTOPs have grown to the point where they are effectively policy, which means that outside of emergencies or situations where the community has failed to handle one, the first line of control over them should be with the community as a whole, not with administrators or ArbCom. --Aquillion (talk) 17:45, 17 April 2024 (UTC)

Discussion (community contentious topics)

Cooperation of ArbCom

I wonder if adding in stuff to the WP:CTOP page and similar would require the petition and referendum process. If so, then I guess the merging of templates would have to hold off until a former petition and request for amendment actually passes. It is possible ArbCom will green light the merge if this RfC passes, but I do not know. Awesome Aasim 05:55, 7 February 2024 (UTC)

I feel the community should work with the arbitration committee to assume responsibility for the contentious topic process, with a pointer to an arbitration-committee specific page where it can customize the process as it feels necessary. This would bring the process under community control, while still allowing the arbitration committee to adapt it to its needs. (There is no change to arbitration policy and so no need to amend it.) isaacl (talk) 19:07, 7 February 2024 (UTC)
Wouldn't that just be the status quo (or perhaps the old GS/DS) status quo? I think Arbcom is more agile than the community in drafting this kimd language given that passing a motion is easier than an RfC and motions can be adjusted mid vote which is nearly impossible to do with an RfC. Truthfully I think the right place to start is with the standardized language for community GS and perhaps to be more intentional about whether it wants its restrictions to be eligible to be heard at AE, though as The Wordsmith points out there are really good reasons for the community to decide not to do that. Barkeep49 (talk) 04:30, 9 February 2024 (UTC)
The process for authorizing discretionary sanctions was documented by the committee, and then later the community started authorizing discretionary sanctions, with its process pointing to the Arbitration Committee pages and saying, "like that". This resulted in the community's process being coupled to decisions made by the arbitration committee. I'm suggesting the reverse: have the community assume responsibility for the contentious topics process, and then the arbitration committee can point to it and say, "like that, but with our specific customizations". I agree the community can decide on its own on what contentious topic process it wants to create. I think it would be good, though, to check with the committee that it is amenable to adopting the community process as a base, and layering any desired differences on top. isaacl (talk) 04:52, 9 February 2024 (UTC)
That also sounds like a good idea: community authorizes the remedies that are appropriate, ArbCom implements them. If ArbCom were to deviate then they would just need to ask the community whether it is an appropriate deviation or not. Awesome Aasim 17:28, 9 February 2024 (UTC)
The committee doesn't have to be constrained by the community as it is already authorized through the arbitration policy to enact remedies of its devising for matters within its scope. It would be simpler for editors to understand, though, if the arbitration committee version of the process was just a set of differences upon a common process. Differences could include things like additional administrator actions that could be performed, or a specific venue for appeals. isaacl (talk) 18:03, 9 February 2024 (UTC)
I think you know what I mean :)
WP:ARBECR is already used a lot by both the community and by ArbCom, like in WP:RUSUKR and WP:CT/A-I. What I am saying is if ArbCom feels that a specific sanction that there has never been any precedent for is necessary, they should propose it to the community, where there then can be consensus on the exact wording. Placement, enforcement, and appeals are all going to differ though depending on whether the restriction is placed by the community or ArbCom. Awesome Aasim 18:43, 9 February 2024 (UTC)
The community can provide feedback on proposed decisions. I disagree that the committee needs to obtain community consensus on new types of remedies. The arbitration committee is empowered to impose a restriction that community consensus has been unable to reach through prior dispute resolution. If you are referring specifically to the standard set of restrictions that can be imposed for designated contentious topics, I still disagree that community consensus should be mandatory. Typically the committee will provide an opportunity for feedback and the last review of discretionary sanctions illustrates that it strives to lighten the load of enforcing administrators. isaacl (talk) 19:17, 9 February 2024 (UTC)
Regarding the extended-confirmed restriction, it was initially devised by the committee on its own. After taking some time to evaluate its effectiveness, the community chose to adopt it as an available restriction. isaacl (talk) 19:25, 9 February 2024 (UTC)
I agree with isaacl that ARBPOL and CONEXEMPT explicitly mean that the committee does not have to, with-in its scope, get community consensus.
However, ECR is a example of why I think the committee is better placed at the moment to be a leader when it comes to contentious topics. The committee having to deal with the absolute hardest conflicts means there is going to be more of an incentive to try something new and ~15 people are going to have an easier time getting to yes than what is required to get community consensus for that newness. It's also revealing to me that ArbCom gets more requests for us to assume community imposed sanctions (examples: COVID, Horn of Africa as two that the committee did assume and Russia-Ukraine War as one that committee has twice been asked to assume and haven't). I would really love it if the community could, as it does in so many other ways, demonstrate broader capabilities when it comes to general sanctions than it has in the past. And to that end getting consensus for some standard wording would be a great place to start. Barkeep49 (talk) 19:48, 9 February 2024 (UTC)
I agree that the arbitration committee is better positioned to try new approaches (consensus doesn't scale up well, so getting consensus amongst 15 people is definitely easier). In a similar vein as you expressed, I feel it would be ideal for the community to agree on a base contentious topics process, which the committee could extend in new ways that the community could later choose to incorporate back into the base process. isaacl (talk) 19:57, 9 February 2024 (UTC)
  • I mentioned this in a big reply below already, but I feel one possible solution to this is to allow the community to take control of ArbCom community sanctions once they're stable (through a clear consensus of editors somewhere), transferring them to community CTOPs. This allows ArbCom to act swiftly and impose CTOPs in situations where the community would inevitably be slow-to-act, and simplifies community decision making because they can just take solutions ArbCom has created and tweak them slightly if necessary; but it avoids the situation we have now where ArbCom functionally takes control of moderation over entire topic areas indefinitely, which IMHO is something we want to avoid. --Aquillion (talk) 18:05, 17 April 2024 (UTC)
  • I do agree that it's worth considering ways to transfer more control over the CTOP process to the community; it affects so much of the wiki now, and is so forceful, that it has effectively turned into policy-by-fiat, which ArbCom wasn't supposed to do. But I'm not sure its feasible to simply transfer the entire thing to the community at once. What I would suggest (and suggested above) is the following. First, create a community CTOP page that is totally separate from ArbCom's (aside from maybe mentioning it for historical reasons), and encourage ArbCom to use that as the basis for its CTOPs, in the same way most of the other things ArbCom does relies on community-created policy. Second, establish that a clear and unambiguous consensus among a sizable number of uninvolved editors can transfer an ArbCom CTOP to community control and place it under the community CTOP rules. (This would probably require that ArbCom agree to modify existing CTOPs to add a line about how the community can take control of it in that manner.) The principle here is that ArbCom is only supposed to be handling things that the community can't; declaring that governance of an entire topic area is a problem that the community has failed to handle, indefinitely, seems like it's too much - it's a lot bigger than ArbCom handling just one person's ban! But it is true that sometimes things break down and require ArbCom intervention on a large scale or we wouldn't have CTOPs in the first place. Creating an "escape hatch" for once things settle down that allows things to transfer back to community control would leave ArbCom with the tools it needs for emergency situations that the community has failed to handle, while allowing for a way to smoothly return to community control once ArbCom's solutions have settled things and a consensus has built around that (avoiding the situation we have now where entire topic areas are under ArbCom control indefinitely.) --Aquillion (talk) 17:57, 17 April 2024 (UTC)
    That seems to match my suggestion: make the process a community-defined one, and work with the arbitration committee to define its process as an add-on to the community-defined process. Transferring all of the arbitration committee-designated contentious topics at once to community-designated ones isn't being proposed, and I agree it wouldn't be a desirable approach. isaacl (talk) 18:05, 17 April 2024 (UTC)
    (edit conflict) @Aquillion: Regarding transferring things from ArbCom control to community control. There defacto already is a procedure for this - a request for amendment to the relevant case/motion that authorised the CTOP designation. The request would need to unambiguously state that the intent was to transfer all or part of the topic from ArbCom control to community control to avoid it being confused for a request to remove the designation entirely but other than that wouldn't need to be anything special, although if I were an arbitrator reviewing such a request I'd want to see three things:
    1. Community consensus that such a transfer was desirable
    2. Community consensus that the community does feel able to handle enforcement of it (and no evidence that it can't)
    3. Evidence that CTOP is still required (because it it isn't then it would be preferable to just remove the designation)
    Yes, this does mean that it would be ArbCom giving control to the community rather than the community taking control from ArbCom, but we elect arbitrators to listen to the community desires and not act unreasonably in matters like this. I also see it as a protection against a vocal minority that doesn't have the consensus it claims to. Thryduulf (talk) 18:16, 17 April 2024 (UTC)

In WP:DS2022, one of the changes made was to allow the community to make use of AE. I think we should do so. HouseBlaster (talk · he/him) 03:42, 9 February 2024 (UTC)

I definitely think we should split contentious topics from WP:AELOG. A separate contentious topics log would make restrictions much easier to follow - and, if the restriction is rescinded or converted from community to ArbCom or the other way around - it can be logged as well. Awesome Aasim 21:21, 10 February 2024 (UTC)

Request revision to initial question

The statement all community general sanctions (DS) in the initial question is misleading. "General sanctions" is not synonymous with community authorization for discretionary sanctions. I think the intent should be clarified that the proposal only affects discretionary sanctions authorized by the community, and not all general sanctions. isaacl (talk) 19:03, 7 February 2024 (UTC)

Isaacl Done. Awesome Aasim 20:07, 7 February 2024 (UTC)

Tag Refreshed

I refreshed the RfC tag because there is not enough input to gauge consensus. Could this be because this is uncontroversial or what? Awesome Aasim 19:58, 8 March 2024 (UTC)

Could well be :) Selfstudier (talk) 10:27, 9 March 2024 (UTC)
I think it's because many editors simply don't know what's going on. I didn't know this discussion was taking place. I'm still not sure what the change in policy is, only that, if it has been changed, the system should be clear about it. Are we dissolving Discretionary Sanctions? Is AE not going to be a thing any more? Is it merging with ANI? Darkfrog24 (talk) 22:37, 17 March 2024 (UTC)
@Darkfrog24 The question is really just about making community sanctions use the new contentious topics procedure. Awesome Aasim 23:45, 17 March 2024 (UTC)
Okay. What is the new CT procedure? Do you know how it's different? I just read through one of the links that Newslinger provided above, and I'm having trouble picking out differences. Darkfrog24 (talk) 00:35, 18 March 2024 (UTC)
For full details, see Wikipedia:Contentious topics. It's basically a renamed version of discretionary sanctions, with changes made based on community feedback received during the 2021–22 review of discretionary sanctions. Some highlights: there is a standard set of restrictions that a single administrator can impose on their own discretion. Restrictions outside of these can be imposed by a consensus discussion at the arbitration enforcement noticeboard. Sanctions are no longer limited to one year, but after a year, sanctions that were imposed by a single adminstrator no longer have to be discussed at the arbitration enforcement noticeboard to be modified. Users no longer have to be made aware of each specific topic area. They only have to be notified once using a specific template about the contentious topic system. Striking out inaccurate description. isaacl (talk) 01:56, 18 March 2024 (UTC)
Users no longer have to be made aware of each specific topic area. They only have to be notified once using a specific template about the contentious topic system. That would contradict the CTOP regime. Even among the Arbcom sanctions, editors still have to be notified about topic areas individually. The WordsmithTalk to me 19:54, 18 March 2024 (UTC)
My apologies; I misspoke. A specific template only has to be used for the first notification about the contentious topic system in general. Subsequently, any form of notification can be used to inform a given user about specific contentious topics. Previously, a specific template had to be used for each affected topic area. isaacl (talk) 21:22, 18 March 2024 (UTC)
Again, not all community sanctions, but community-authorized discretionary sanctions. isaacl (talk) 01:36, 18 March 2024 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Follow Up Discussion

Firstly, does anyone want to help update all the community "discretionary sanctions" to community "contentious topics" in the relevant terminology? And secondly, what parts of the CT procedure should the community adopt and which ones should the community not? I think community should adopt a contentious topics policy (and the existing WP:CT could be moved to Wikipedia:Arbitration Committee/Contentious topics). It should detail all of the restrictions that may be issued under a CT designation, and when nonstandard restrictions may be used, etc.

I think it would be a good idea to merge Template:Gs/alert with Template:Ct/alert/first (as well as similar GS templates with CT templates) and to have one module for handling both community and arbitration contentious topics. Awesome Aasim 00:45, 21 April 2024 (UTC)

Should list articles have images

Right now some list articles have images while others have had them removed.

I brought this up at User talk:Jimbo Wales § Do you believe lists of aircraft, tanks, and ships should have pictures? and Jimbo Wales suggested reopening the discussion, so I did so at Wikipedia talk:WikiProject Aircraft § Images on list of aircraft, etc.. But someone said I should've done it here instead for more people to notice. Can people go join the discussion there, or should we just copy over what was said there over here? Dream Focus 03:06, 25 April 2024 (UTC)

Lists can have free images to show what each item on the list looks like, but they cannot have non-free images since rarely the use of non-free images in lists meets all NFC criterion. A header/infobox image may be reasonable in such lists, but definitely not a per-item list. Masem (t) 03:09, 25 April 2024 (UTC)
Some lists do have an image for every entry, e.g. List of London Underground stations. Thryduulf (talk) 08:36, 25 April 2024 (UTC)
Key is, those are all free, and there's no NFC issue to worry about. — Masem (t) 12:30, 25 April 2024 (UTC)
There is a binary assumption here between every item in the list having an image and the List as a whole having no images. There are options in between as well as those two, and a blanket guideline for all lists to pick one of these options seems too broad. CMD (talk) 03:48, 25 April 2024 (UTC)
Each list is different.
Which is best suited to a particular list can only be decided in the context of each individual list. Considerations include how long the list is, how much information is provided about each list entry, what free images are available, how large the image need to be to be recognisable, whether images add additional information or context, etc. Thryduulf (talk) 08:36, 25 April 2024 (UTC)
Non-free images can be used where our fair use criteria apply. Paradoctor (talk) 09:06, 25 April 2024 (UTC)
But simply to have an illustration on a list is not a valid reason, per WP:NFLISTS — Masem (t) 12:31, 25 April 2024 (UTC)
The biggest problem with having hundreds of images in an article, is that the browser will request ALL of these images from the server within a short timeframe. As this can overload the servers, especially if some of the thumbnails still need to be generated, some of those images might fail. It also tends to overload the memory of mobile phones, as it needs to load all this stuff into the memory and graphics buffers and mobile phones are limited. So as with so many issues. These are not binary, but SOME constraint is always warranted and where to put that is an editorial decision. But anything that assumes all or nothing is broken by (non)design. —TheDJ (talk • contribs) 09:41, 25 April 2024 (UTC)
Again, the length of the list matters here - illustrating every item in a list of 10 items is different to illustrating every item in a list of 1000 items. Thryduulf (talk) 10:02, 25 April 2024 (UTC)
I believe one of the disputed articles here is List of active United States military aircraft, so at some level the question is "Should this list have 150+ images?" WhatamIdoing (talk) 07:47, 26 April 2024 (UTC)
List_of_Ancient_Greek_temples#List and other list of buildings always have a picture of the building.
What about vehicles though? List of sport utility vehicles and many other civilian vehicles have images of the items on their lists. But list of military vehicles do not, because of a discussion back in 2015 where four people voted to eliminate them, without most people noticing the discussion. They went through and erased them. I believe the list of military aircraft for example, looked better before [2] with images showing the aircraft listed. We need a set policy in place so we don't have small numbers of people deciding things without most realizing what's going on, or arguing over every single article.
Since all of you chose to discuss this here, instead of the other place I linked to, just pointing out what I said there. If people have slow bandwidth they can easily set their browsers to not automatically load images. Any website that has images they want to see, they click the icon at the top of their browser to then load them up. No reason to remove all images simply because some have slow internet. Dream Focus 09:56, 25 April 2024 (UTC)
"they can easily set their browsers to not automatically load images" - only if they belong to the minute fraction of our readership who knows this, and how to do it. Other than loading issues, I see no reason why lists should not have images. The large category of Category:Lists of works of art are rather pointless without them. Johnbod (talk) 10:02, 25 April 2024 (UTC)
If the list item is a blue link then available image(s) of it are only one click away (and in a larger format). Related problems in aviation articles are the addition of large galleries (not advised by WP:GALLERY) and shoehorning multiple images in to articles with little text, add over length infoboxes (museums have a photo/logo and a map) and we have acres of white space above the navboxes. Nimbus (Cumulus nimbus floats by) 10:29, 25 April 2024 (UTC)
(edit conflict) If you believe that a page looked better with images, restore them. The discussion you refer to cannot stop you. I hate to break it to you, but (WP:CREEPily) bringing in a guideline to regulate this extremely situational topic would be the definition of "small numbers of people deciding things without most realizing what's going on". ~~ AirshipJungleman29 (talk) 10:30, 25 April 2024 (UTC)
Then there would be a pointless edit war. At Wikipedia:Articles for deletion/List of Polish military aircraft an editor stated:
we have a consensus to not put aircraft image into the inventory table, and intentionally ignoring the consensus may be considered as disruptive editing.
So I'm hoping far more people participate in this, and we can come to a standard agreement, and either add it to a guideline somewhere, or if nothing more, link to this discussion for the new consensus. Dream Focus 11:11, 25 April 2024 (UTC)
I have no idea what consensus would be applicable, other than "it depends". It's entirely situational whether images should be in any article. Lee Vilenski (talk • contribs) 11:17, 25 April 2024 (UTC)
I agree that this is too situational for universal guidance. If a prior consensus has determined that a specific list should/should not have images, and you disagree with that determination… remember that “consensus can change”. Go to the article talk page and discuss. Blueboar (talk) 12:27, 25 April 2024 (UTC)
No, it would lead to a discussion, if anyone cares enough to revert you. WikiProject consensuses from nine years ago with five people participating were not binding then, and are still not now. ~~ AirshipJungleman29 (talk) 12:36, 25 April 2024 (UTC)
What an utterly pointless discussion. Given that neither a policy stating that 'no list article shall have images' nor one stating that 'all list articles must have images' would stand the slightest chance of ever gaining acceptance, the 'it depends' status quo is the only possible outcome here. AndyTheGrump (talk) 13:11, 25 April 2024 (UTC)
Totally agree! Just depends on the subject really. There is no need for a overall concensus for all Wikipedia lists. Local concensus can be easily agree on the lists talk page. Davidstewartharvey (talk) 13:54, 26 April 2024 (UTC)
Yes, very much horses for courses. Images tend to swell out each item, making it difficult to see much of a long comparative list at any one moment; fifty very similar thumbnails differing only in fine detail are no compensation. Many aircraft lists are of this type. On the other hand, visual features are often important identifiers, as with the List of X-planes. — Cheers, Steelpillow (Talk) 17:29, 25 April 2024 (UTC)
If the number of available sample images is much less than the number of subject items, in each case it might be suitable to provide a hyperlink to a Commons image (or category). One example is List of surviving Douglas A-26 Invaders. PeterWD (talk) 18:43, 25 April 2024 (UTC)
  • IMO, Dream Focus exaggerated the initial problem, which was the decision not to include images into aircraft inventory table in articles dedicated to specific air forces or in lists of aircraft belonging to those air forces. However, he expanded the discussion into "Should list articles have images", which is a broader questions. Regarding this broader question, my stance aligns with Lee Vilenski, AndyTheGrump, Andrew, and Steelpillow suggesting it depends on the context. Additionally, Thryduulf has provided excellent examples for each context. Referring back to the initial problem, I believe the decision to not include images into aircraft inventory table aligns with the 5th context outlined by Thryduulf, which states that Sometimes it's best to illustrate a selection of entries throughout the list. Current articles on air forces or lists of aircraft belonging to those air forces do include a selection of images of aircraft, typically positioned beside the inventory table. Ckfasdf (talk) 06:24, 26 April 2024 (UTC)
  • Sometimes yes, sometimes no. There is no one image rule you can apply to list articles because list articles aren't all the same. Dennis Brown - 2¢ 07:59, 26 April 2024 (UTC)
    Then its all up to whoever is around at the time to notice and argue about it. Some will go around and erase it unless a set rule is established preventing it. I really wish this conversation was being had all in one place. Wikipedia_talk:WikiProject_Aircraft#Images_on_list_of_aircraft,_etc. shows clearly that some believe in removing all such images, because some of them have slow internet speed and because those using cell phones to access Wikipedia have trouble loading them. They can easily look through the settings of their browsers and set them to not load up images, or use a search engine to find out how. I am curious what sort of articles the cell phone users are accessing. I assume those just looking up a recent news story or celebrity gossip, or information they need at the moment for whatever they are doing. Is there a way to see how many people viewing an article are using a cell phone instead of something else? Dream Focus 11:53, 26 April 2024 (UTC)
We are not going to establish a 'set rule'. It simply isn't possible. There are just far too many factors to consider. And yes, this sometimes means that Wikipedia erases things. Like absolutely any other serious media project, anywhere. This is what is known as editorial judgement. Some of us clearly have it, and understand its purpose, even if you don't... AndyTheGrump (talk) 12:07, 26 April 2024 (UTC)
FWIW… I edit about 50/50 between computer and phone.
As for people removing images, that is allowed. Good Faith Editing involves both adding and removing stuff (that is why we are called “editors” and not “authors”.) There can be valid reasons to do either. If someone else (you) objects, take it to the talk page and discuss. Reach a new consensus and work from there. Blueboar (talk) 12:11, 26 April 2024 (UTC)
  • If the image fits the list then fine. Images work well and have since lists were a twinkle in the eyes of Wales/Sanger. Many visual art lists are specifically about the images. This is another example of a theory I've bounced around that Wikipedians, when given limited number of things left to do as the years go by and being accustomed to doing many edits a day/week, will turn to deleting normal components of existing pages. Please be aware of this tendency and take it into account, thanks. Randy Kryn (talk) 14:09, 26 April 2024 (UTC)
Yes of course, and videos, too. They won't slow down or crash mobile phones either, that's outdated info. At worst the images might take a bit to load, which is no reason not to have images at all. Levivich (talk) 14:18, 26 April 2024 (UTC)
This is simply not true. it is very easy to memory overload a low end phone, especially if it's a couple of years old. This is mostly due to layout calculations on very long pages. It also adds additional load serverside, which is not insignificant. There is a reason why anything 'list' that the server generates uses a pager (next page/previous page) and is limited to 50 by default and 500 max. If people throw hundreds of images on a page, it has impact. Can it handle it ? yes, sometimes, sometimes not. Where is the edge ? Somewhere on a curve and the curve ends with a cliff. the exact shape is influenced by hundreds of variables (which is why you can't define a hard limit). —TheDJ (talk • contribs) 17:13, 26 April 2024 (UTC)
You can't define a hard limit, but there are best practices. For anyone reading this who isn't familiar, what we're talking about is called "page weight," which is the total size, in kilobytes (KB) or megabytes (MB) (1 MB = about 1,000 KB), of a web page and all the other stuff that has to be loaded, including images. If the page weight is too big, it'll slow down the browser/device loading it. Of course, desktops can handle larger page weights than mobile devices.
The average page weight for a mobile device nowadays is over 2 MB according to, e.g., [3] and [4]. Now look at Special:Permalink/671675813, an old version of a list that has a lot of images on it -- 170 different images in total. The page weight of that page is 953 KB, a little less than 1 MB according to [5] (you can check any webpage's page weight using tools like the one at https://tools.pingdom.com). So that page has 170 images and it's less than half the average page weight of a mobile page today. (The last time the average mobile page weight was 1 MB was like 2016. So this list page with tons of images would have been a less-than-average-sized page in 2016; it's half the average today.)
And that makes sense because thumbnails are really small. Even though that page has 170 images, it's a total size of 844 KB for all images -- that's an average of about 5 KB per thumbnail image (and yes, almost all of the 1 MB page weight is the images). So with an average mobile page weight of 2 MB, and thumbnails of an average of 5 KB, we can have 400 thumbnails before we hit the average.
So I doubt that there are any significant number of devices in use today that can't handle, like, 50% or 40% of the current average mobile page weight. Even devices from 2016 would be able to handle 1 MB page weight. And adding thumbnails to lists -- at an average of 5 KB each -- is not going to impair the performance of the vast majority of mobile devices, unless the list gets to be over 400 images long. And that tells me why the server max is 500 images, makes sense.
And all that is assuming the mobile browser loads all those images at once, which I don't think it does because of lazy loading, which, according to our article on it, has been the default in browsers since 2020 (and the MediaWiki Lazyload extension is older than that).
DJ, what do I have wrong here? What kind of a mobile device still in use today would have trouble loading a web page that is less than 1 MB? Levivich (talk) 18:26, 26 April 2024 (UTC)

Replace disabled Graphs with other templates that work

So, the Graph extension is not going to be working again for a very long time. Graph was disabled 1 year ago, and they are re building it from the ground up, just starting to gather the people necessary for the project, which the update says will start in July. In my opinion, we need a solution until then. 18,236 pages have disabled graphs, including some very heavy traffic articles. Here is a list with more than 100k total views on my user page. (Here is the full list generated dynamically, but takes a long time and eats a lot of RAM). These include very heavy traffic and important articles such as Facebook, Murder trial of O. J. Simpson, and World War II. All of these articles you could argue are currently incomplete because there is information that is there but can't be displayed to the user.

There are alternative templates that work currently, such as Template:Bar chart,Template:Bar box, Template:Vertical bar chart, Template:Pie chart, Template:Piechart, and various others. There are some that I can't see a currently working template for, such as line, area and map. I don't know much about creating templates, but I think it'd be technically possible to create those. If a map chart template wouldn't be possible or easy, you could also have a bot or human take the map charts, recreate it offline, upload it to Commons, then place the image in the article.

You could put the bar charts and pie charts in the working templates via a bot (the chart wouldn't look exactly the same, but at least the data would be visible). Maybe the bot could be a pending changes bot to make sure it actually displays correctly and accurately. Especially pie charts, as its literally just a circle divided in parts with different colours. For the high traffic or important articles, if you can't replace them via a different template (map charts), you could recreate them manually as an SVG. MarkiPoli (talk) 06:38, 21 April 2024 (UTC)

This means pages like Transportation safety in the United States and road traffic safety is a pain to read because it mostly relies on using its own graphs and not some images. I think pages that mostly rely on the now disabled graphs should have priority because otherwise, it is useless. While far from the most popular, it is still a problemJuniperChill (talk) 10:43, 21 April 2024 (UTC)
Wow, those articles are striking examples... 38 and 16 disabled graphs respectively. As you say, at that point the article becomes borderline useless. It would probably take too long to do manually without a bot though. MarkiPoli (talk) 11:03, 21 April 2024 (UTC)
For articles like this, the problem is that those sections just need to be rewritten. That's not an encyclopedic overview of the topic, it's just a statistics dump. Thebiguglyalien (talk) 17:05, 29 April 2024 (UTC)
Using static images would be an unfortunate backwards step: a big advantage of Module:Graph was that we could including a machine-readable version of the underlying data on Commons, greatly increasing its transparency, usefulness, and ease of editing. But since the WMF have really screwed this one up, we might not have a choice. – Joe (talk) 11:12, 21 April 2024 (UTC)
Existing templates should be used and new templates should be made where possible, and only as a last resort would we use static SVGs. As for machine-readability, I'm not sure exactly how that works, maybe others have more insight MarkiPoli (talk) 11:32, 21 April 2024 (UTC)
This is more idea lab fodder than a proposal, but a sufficiently clever bot might convert data into SVG, checking where repeated work may be necessary because the data has changed more recently than the SVG. Certes (talk) 16:10, 21 April 2024 (UTC)

Suicide hotlines

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.

For the proposal see User:TheSpacebook/lifeline

Firstly, is this the correct place to put this? Also, I can’t find this proposal on Perennial proposals. I have concerns about the Suicide methods article. I believe it to be a clear violation of WP:NOTHOWTO. Failing that, the article is just a WP:BADIDEA. The consensus is currently for the page to stay, so for now, possibly the suicide crisis line for the reader could be displayed at the top of the page subtly embedded into the article.

But for now, I’ve spun this up in 15 minutes and sourced the numbers from List of suicide crisis lines. This might have to be expanded, as some lines have opening and closing times, so it can be expanded to display just the emergency telephone number when the number is closed. It relies on one thing though, IP address lookup service ‘ipapi’. There are probably better in-house Wikipedia databases that can do this, for better reliability. But essentially it curls the IP address and returns the ISO 3166-1 alpha-2.

The script is ultra-simplistic as I don't know what the specific technicalities of Wikipedia are, so it's a basic HTML script. If a more advanced tool would be better, point me towards the Wikipedia dev docs for the technical specifications. Also, I can build other tools for Wikipedia by piggybacking off the pre-existing ones.

I imagine that some people who have attempted suicide will probably have the Suicide methods article in their internet history. It should work with HTML, so the quickest solution is to insert the script only on the Suicide methods page. Sort of like an WP:IAR. It will also need to be styled so it looks better on the page.

All the phone numbers should be checked for accuracy, but the raw basic script for HTML can be found here: User:TheSpacebook/Suicide crisis line script. And the full HTML page, if it needs testing, can be found here: User:TheSpacebook/Suicide crisis line script HTML page. Just copy and paste it into a text editor, save it with the extension ".html", and then open it in a web browser. EDIT: I’ve reworked my proposal to be more subtle, it can be found here User:TheSpacebook/lifeline. TheSpacebook (talk) 23:15, 17 April 2024 (UTC)

Technical issues aside, this feels a lot like WP:RIGHTGREATWRONGS to me. * Pppery * it has begun... 23:29, 17 April 2024 (UTC)
For background, see Wikipedia:Village pump (proposals)/Archive 161 § Proposal to add suicidal disclaimer at Suicide and Wikipedia:Village pump (proposals)/Archive 192 § Suicides. isaacl (talk) 23:46, 17 April 2024 (UTC)
Thank you for supplying me with those. However, my proposal is completely different. I’m not arguing for the article to be censored, nor the article to have a disclaimer (or "trigger warning"). I’m proposing that the relevant suicide crisis line to be in the article. This already happens on a different article, Suicide prevention, but it only displays the USA number. Possibly another example of the Western, specifically American, WP:BIAS on Wikipedia? Plus, the numbers already exist on List of suicide crisis lines, I think it would be a good idea to put the specific phone number in the appropriate place. TheSpacebook (talk) 00:45, 18 April 2024 (UTC)
Both discussion threads discussed putting a link to a hotline in articles, targeted to the reader's geographical area. isaacl (talk) 01:57, 18 April 2024 (UTC)
Both of those discussions began to get sidetracked to disclaimers or censorship, and were concluded based on those two. I hope this discussion focuses only on the suicide crisis number. Also the Suicide prevention article has a number, and I said in my other comment how this could be American WP:BIAS on Wikipedia. Something like that, but it changes for the country makes reasonable sense to me. TheSpacebook (talk) 10:51, 18 April 2024 (UTC)
The point of providing background is so the relevant discussion points can be reviewed and taken into consideration, to facilitate moving forward from the previous discussions. Both discussions cover relevant issues. isaacl (talk) 16:17, 18 April 2024 (UTC)
Both of them are arguing for WP:DISCLAIMERS. I have since modified my proposal, to make it clear that I’m not proposing a disclaimer. The text already reads that to prevent suicide they should call a crisis number, so it seems more precise to have the exact number. TheSpacebook (talk) 16:29, 18 April 2024 (UTC)
For instance, the second discussion has a post from a WMF staff member on the database it maintains, and how it would be willing to provide support for any community initiative. I feel this is useful background for your proposal. isaacl (talk) 16:37, 18 April 2024 (UTC)
Thank you again for sending me that, it was an interesting discussion. But it sways into WP:DISCLAIMERS which is not what I’m proposing. The script I made is a basic example, as I don’t have access to any of the backend Wikipedia/WMF tools. Linking it to a backend database that WMF maintains would be better. If the number changes, it only needs to be edited once to reflect immediately. TheSpacebook (talk) 17:03, 18 April 2024 (UTC)
Using an external service is a huge "no" from a privacy perspective. If we were to do this, we'd take up the WMF's offer to to it in-house from Wikipedia:Village pump (proposals)/Archive 192#Suicides. But what has changed since that discussion didn't result in acceptance? Anomie⚔ 01:19, 18 April 2024 (UTC)
All the script needs run is the ISO 2-letter country code. This can easily be supplied in-house at Wikipedia/WMF. I just used an external to show a working example of the script, as I don’t have access to any of the Wikipedia backend tools that can be used instead. In my initial post, I said there are probably better in-house Wikipedia databases that can do this. I’m not suggesting an external service is actually used. TheSpacebook (talk) 01:26, 18 April 2024 (UTC)
The user's assumed country is available using Geo.country in javascript. the wub "?!" 08:55, 18 April 2024 (UTC)
Perfect. What format does that return? Would it be Geo.country_code, as the 2 letter ISO country code, or something else? Now I can take away the fetch part:
const response = await
fetch('ipapi.co/country_code');
const country = await response.text();
and have then replace this part:
const country = await fetchCountry();
with the following:
const country = Geo.country
Anyone is welcome to make amendments to User:TheSpacebook/Suicide crisis line script to make it better. Still need to check the format it returns the country in, however. Is that still not an external package/library? If not, the script now fully works in-house with Wikipedia/WMF, using no external services. TheSpacebook (talk) 11:01, 18 April 2024 (UTC)
I realise that this proposal is slightly different, but the comments that I made at Wikipedia:Village pump (proposals)/Archive 161 § Proposal to add suicidal disclaimer at Suicide and Wikipedia:Village pump (proposals)/Archive 192 § Suicides still stand. Phil Bridger (talk) 11:30, 18 April 2024 (UTC)
I quite plainly believe it is not within Wikipedia's mandate to have this sort of thing on an article. Buddy Gripple (talk) 12:48, 18 April 2024 (UTC)
Suicide prevention already does this, but it only displays the USA/Canada number, which I believe shows Western WP:BIAS. So I could maybe amend my proposal to have that page display the relevant suicide crisis number. TheSpacebook (talk) 13:01, 18 April 2024 (UTC)
No, you should rescind the proposal entirely. This is not something we should be doing AT ALL. Any current examples of such need to be removed. --User:Khajidha (talk) (contributions) 13:08, 18 April 2024 (UTC)
Also, you are wrong about the suicide prevention only showing the US/Canada number. The numbers for the Samaritans (UK) and the Netherlands's crisis line (113) are also present in the images. These images (and the one for the US/Canada number) are present as examples of prevention campaigns, not directory listings. There is, however, an imbalance in that article between US material and other countries. --User:Khajidha (talk) (contributions) 13:22, 18 April 2024 (UTC)
Are you referring to these images in the article? I hardly think they count as anything for this discussion, but the Dutch number is in the caption. Also, is List of suicide crisis lines not a directory listing? But I’m glad we agree that there is an imbalance. Perhaps to redress this, the relevant line is displayed, and not the USA/Canada one for everyone. I don’t see the relevance for it to be on the article for non-USA/Canada readers.
TheSpacebook (talk) 13:28, 18 April 2024 (UTC)
Yes, those images. They show prevention methods in use, just as the image at the top of the article shows a poster used in the US. This is not displaying the US/Canadian line for everyone. Yes, the list of suicide crisis lines is a directory. I also think it should be deleted. --User:Khajidha (talk) (contributions) 14:25, 18 April 2024 (UTC)
I’m confused by This is not displaying the US/Canadian line for everyone, it literally is displaying the number for everyone, no? If List of suicide crisis lines was put up for AfD (which I’d oppose for it even being considered to be deleted), my theory is that it would be 'keeped', as per WP:IAR or some similar exceptional policy. TheSpacebook (talk) 14:29, 18 April 2024 (UTC)
As I said before, this image is present as an example of a prevention campaign not as a "here is the number to call" listing. It's a subtle distinction and I have no objection to removing that image. --User:Khajidha (talk) (contributions) 14:59, 18 April 2024 (UTC)
Can I just clarify, I’m not proposing a banner to be placed on the page, I’m proposing something more subtle. For example, the third paragraph in Suicide methods could easily be reworded to include the script which displays the number, without looking so blatant: (emphasis added) Some suicides may be preventable by removing the means. Making common suicide methods less accessible leads to an overall reduction in the number of suicides. Some method-specific ways to do this include restricting access to pesticides, firearms, and known-used drugs. Other important measures… and calling a crisis hotline. TheSpacebook (talk) 14:23, 18 April 2024 (UTC)
It's not obvious to me that such a banner wouldn't have some unintended consequences. I know search engines and newspaper articles about suicide use them, but all kinds of stuff gets done for herd reasons. How do we know that a big obvious warning box would not itself prompt someone to move from a state of passive information consumption to a state of actively contemplating a personal action? The prompt could trigger the thought that "Someone thinks I might actually do it", which is one hop from "I might actually do it". Barnards.tar.gz (talk) 14:36, 18 April 2024 (UTC)
I’m not proposing a banner. Just something more subtle. A banner would open a Pandora’s box and snowball into other content warnings, erring too close to WP:CENSORED. TheSpacebook (talk) 14:41, 18 April 2024 (UTC)
  • So at the very least, this seems to require running a default gadget to change the content of an article in a manner that would be hard to editorially control. That doesn't seem like a good use of technical resources to me, without even getting in to the problems related to invalidating caches or editor issues of having this be interface-admin protection content. — xaosflux Talk 17:42, 18 April 2024 (UTC)
    Noted. The aim of this is to subtly include the text in the article. But, I’ll add a 'default text' parameter to display if there isn’t a number available, that can be unique to each use of the script. TheSpacebook (talk) 17:47, 18 April 2024 (UTC)
    I hadn't thought through the techical aspects of this before. The proposal seems to be to present different content to different people. As far as I am aware that is something we stopped doing, for very good reason, about fifteen years ago when we gave up turning linked dates around. Do we really propose to start doing that again? Phil Bridger (talk) 20:01, 18 April 2024 (UTC)
    I’ve completely reworked my proposal, it's vastly different from displaying dates and content warning disclaimers. It can be found at User:TheSpacebook/lifeline. I can’t find anything the exact same as what I’m proposing. Whilst they use geolocation, all previous suggestions seem to be some sort of banner/warning. TheSpacebook (talk) 20:06, 18 April 2024 (UTC)
    But you seem to be suggesting displaying different content to different people based on their location. Phil Bridger (talk) 20:27, 18 April 2024 (UTC)
    Correct. But there isn’t a specific rule against doing it for this tool/template as per WP:5P5. TheSpacebook (talk) 20:42, 18 April 2024 (UTC)
    There isn't a specific rule against me sticking my left index finger in my ear and singing "The Star-Spangled Banner" while drinking a glass of champagne, but that doesn't make it a good idea. Phil Bridger (talk) 20:58, 18 April 2024 (UTC)
    If in the UK, s/Star-Spangled Banner/God Save the King/ [1]
    1. except in Wales or Scotland, or for those in Northern Ireland from one community. And republicans, anarchists, and those who switch Javascript off. Those using TOR, VPN, or who have activated add blockers.     Sirfurboy🏄 (talk) 06:59, 19 April 2024 (UTC)
It would simply be far better than a script as to have one page, likely in WP space for the purpose, to give the read a list of numbers to contact if they feel suicidal and need help. Not dynamic , but absolutely clear what number they should use by country list. A separate mainspace page that identifies these numbers is also fine, but there's likely a different format and purpose there, to inform, not to urge getting assistance.
Whether to include it on topics that directly deal with suicide, that's a separate issue. I think our disclaimers warn about medical advice and this would seem to fall within it. — Masem (t) 12:17, 19 April 2024 (UTC)
Previous discussions have come out against this type of proposal, because it would be almost impossible to maintain an accurate and up to date list of phone numbers for every country, or to identify with 100% accuracy where the reader was located. This is an idea that is well meaning but is unlikely to work well in real life situations.--♦IanMacM♦ (talk to me) 15:02, 19 April 2024 (UTC)
I understand all the concerns. Just thought I’d offer up a solution which met in the middle when this issue is raised, and be subtle to avoid a disclaimer. WMF said that they already maintain this database in the previous discussion and have more advanced tools to geolocate users: https://en.m.wikipedia.org/wiki/Wikipedia:Village_pump_(proposals)/Archive_192#Suicides. My proposal is in good faith, the subtle template seems like something WMF could do a lot better with their advanced tools etc. TheSpacebook (talk) 16:51, 19 April 2024 (UTC)
@Masem there is meta:Mental health resources, curated by WMF. — xaosflux Talk 15:48, 21 April 2024 (UTC)
  • Support-ish but for different reasons: I am pretty sure the suicide prevention hotlines are promoted for legal reasons on various news sources, and not just because they want to. No one wants to be found legally liable for harboring content which promotes or shows instructions on how to do this. This seems like a good application of WP:IAR to WP:NDIA. We are not here to WP:RIGHTGREATWRONGS but we also need to seriously consider the social impact of having such content on Wikipedia. We can prevent auto redirection from search or clicking and direct users to here: m:Mental health resources. Would like to hear input from WMF on this. Awesome Aasim 17:05, 20 April 2024 (UTC)
  • Yes, but I support hatnotes that professionals with suicide-prevention training agree will do no harm. I oppose such notes by well intentioned editors without such trainig or experience. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 15:29, 22 April 2024 (UTC)
    Well, yes. Promoting such crisis lines may prevent a suicide, or may push the reader into it, as Elli says below. I don't think anyone has presented evidence either way. As I said in one of the other discussions about this, human psychology often moves in mysterious ways. Then there is the libertarian argument (to which I do not subscribe, but many on Wikipedia seem to) that we shouldn't do anything that interferes with personal choice anyway. Phil Bridger (talk) 19:35, 29 April 2024 (UTC)
  • Oppose we already have a hatnote on the article to Suicide prevention, which is more than we'd do in any other similar situation. Anyone who wants access to a suicide hotline will be readily able to access one already; there is no need to push this in front of people so hard and I doubt it would have any benefit (indeed, I think it might actually push people away from those resources). Not even focusing on the implementation difficulties. Elli (talk | contribs) 19:06, 29 April 2024 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Create an alias for the Template namespace

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.
--Task created Cocobb8 (💬 talk • ✏️ contribs) 20:22, 29 April 2024 (UTC)


I am proposing that tp: be added as an alias to the Template: namespace per this discussion.

Note: Though previous aliases were already listed on perennial proposals, it proposed t:, which would have conflicted with some article titles, or be confused with the Talk: namespace. Tp:, on the other hand, wouldn't, and would make it way quicker to look up a template in the search bar.


Edit (during rfc): tp: was not fully supported due to it being confused with "Talk Page", however other options were proposed, like hard coding {{ being replaced by Template: in the search bar, or other aliases like tmp:. Cocobb8 (💬 talk • ✏️ contribs) 15:19, 16 March 2024 (UTC)

  • Oppose "Template" is not a long word, and nobody abbreviates it as "tp" these days. This seems pointless. * Pppery * it has begun... 15:27, 16 March 2024 (UTC)
    I just thought it'd make it consistent with wp: for Wikipedia:, which is 10 characters, while Template: is 9 characters. Cocobb8 (💬 talk • ✏️ contribs) 15:29, 16 March 2024 (UTC)
    Nobody abbreviates it as "tp" these days. Even if that is true it is not a reason for us not to do so. Wikipedia is big enough to be making fashions rather than following them. Phil Bridger (talk) 21:16, 16 March 2024 (UTC)
    Well said. — Frostly (talk) 06:28, 5 April 2024 (UTC)
  • Support I'd find it useful. It's less effort to type "tp:infobox person" in the search box than "template:infobox person" (which is how I usually navigate to wp: and template: pages). Schazjmd (talk) 15:52, 16 March 2024 (UTC)
  • Support per Schazjmd. 🌺 Cremastra (talk) 15:57, 16 March 2024 (UTC)
  • Support I'd absolutely love this. I've often wondered if there was some technical problem that was preventing us doing this. Usedtobecool ☎️ 16:00, 16 March 2024 (UTC)
  • Support: Pretty nice QOL change. Per Schazjmd. ARandomName123 (talk)Ping me! 16:35, 16 March 2024 (UTC)
  • I don't think it's a good idea to create an alias (and implicitly creating more English Wikipedia jargon) just to improve the search function. We should instead improve the search capability directly. isaacl (talk) 17:41, 16 March 2024 (UTC)
    Yeah, but you don't want a casual reader to be confused as to why they ended up on a template page Cocobb8 (💬 talk • ✏️ contribs) 17:42, 16 March 2024 (UTC)
    It would be a lot easier for the casual user to stumble upon a namespace alias, which could happen anywhere they enter an URL that might trigger a browser to launch, than for them to deliberately select the search box and type there. Furthermore, if this isn't intended to be used by a broad audience, then a more targeted solution would be better. Users wanting this functionality can make use of the script to which you were pointed in the previous thread, or they can configure their OS to provide an appropriate macro expansion to shorten the number of keystrokes they use. isaacl (talk) 18:08, 16 March 2024 (UTC)
    For reference, the script seems to be User:Ahecht/Scripts/TemplateSearch. jlwoodwa (talk) 04:53, 18 March 2024 (UTC)
  • "tp" seems very easily misconstrued as "Talk Page" at a glance. CMD (talk) 18:12, 16 March 2024 (UTC)
    Good point. Sdkb talk 18:22, 16 March 2024 (UTC)
  • Support I've been wanting this. It really is irksome to type out "Template:" I since learned today there are scripts, and of course {{tld}} for talk pages, but it would be much cleaner and simpler to have a standard abbrev. and this is technically easy to implement. TP: or T: it doesn't matter they both are fine. I prefer T: -- GreenC 18:56, 16 March 2024 (UTC)
  • Comment: Unless I'm missing something, the TP: prefix was proposed in 2015, in a discussion which was closed as no consensus - Wikipedia:Village pump (proposals)/Archive 127#Prefix suggestion: TP: for Template:. All the best. ‍—‍a smart kitten[meow] 19:00, 16 March 2024 (UTC)
  • Oppose For the reasons in WP:PEREN#Create shortcut namespace aliases for various namespaces. In particular, the Template namespace is generally not linked often enough that saving the typing of 6 characters is likely to be at all worthwhile and there's nothing available to use for the corresponding talk pages. Anomie⚔ 20:00, 16 March 2024 (UTC)
  • The template for linking a template is called {{tl}}. Shouldn't we have some consistency between this and the short-cut? Or is "tl" already used? Phil Bridger (talk) 21:16, 16 March 2024 (UTC)
    @Phil Bridger tl is ISO639 for tagalog. — xaosflux Talk 22:20, 16 March 2024 (UTC)
    {{tl}} is short for {{template link}}, so the el doesn't have anything to do with templates qua templates. jlwoodwa (talk) 04:31, 18 March 2024 (UTC)
  • Support – While there are helpful template shortcuts, like {{t}} and its siblings, that can be used in discussions, and a script that can be used in the on-wiki searchbox to convert {{ to Template:, a namespace shortcut (tp:) would help in edit summaries and customised browser search boxes. -- Michael Bednarek (talk) 23:55, 16 March 2024 (UTC)
  • Oppose Adding layers of obfuscation is not helpful. If I want to refer to {{convert}}, writing Template:Convert is easy and helpful to someone reading my comment. Writing Tp:Convert is unnecessary jargon that saves under a second of typing at the cost of head-scratching for readers. tp would be "talk page" for many. Johnuniq (talk) 01:00, 17 March 2024 (UTC)
  • Oppose As someone who has next to no involvement with template editing, I immediately think of 'talk page' when I see 'tp'. It would confuse many people who edit outside of the technical areas of Wikipedia. (Summoned by bot) JML1148 (talk | contribs) 06:57, 17 March 2024 (UTC)
  • Rename the template mainspace from "Template:" to "Plantilla:" and use "Pl:" as a shortcut CactiStaccingCrane (talk) 18:02, 18 March 2024 (UTC)
    That would be quite a big change, but I'm not against it lol Cocobb8 (💬 talk • ✏️ contribs) 19:50, 18 March 2024 (UTC)
    But this is in español ROTFL -- ZandDev 13:45, 20 March 2024 (UTC)
    Yeah there's no way we'll get consensus on that one Cocobb8 (💬 talk • ✏️ contribs) 13:46, 20 March 2024 (UTC)
    Yea, no. Also even on eswiki that uses that namespace name this couldn't happen as Pl is ISO639 for Polish. — xaosflux Talk 09:40, 21 March 2024 (UTC)
  • Soft Oppose I'd support hard-coding {{→Template: into the search box's autocomplete natively rather than using my script as a hack, but I agree that the widespread use of links like TP:Example are an unnecessary layer of obfuscation/jargon. With the WP prefix, at least the shortcut links are mostly self explanatory, but it wouldn't be obvious to a newcomer what, for example, tp:birds is, or why it's not an article. --Ahecht (TALK
    PAGE    ) 18:17, 18 March 2024 (UTC)
    @Ahecht Yes, hard-coding that directly could be a great alternative. I just think that we need to find a solution for this, and maybe tp: wasn't the best as others have pointed out. I'll continue gathering some ideas and then conduct a sub-RfC to see what option would be best, as long as the consensus doesn't seem to be oppose. Cocobb8 (💬 talk • ✏️ contribs) 19:52, 18 March 2024 (UTC)
  • neutral i could go either way. I like the hard coding option of having 'template' be dropdown option in the menu. Slacker13 (talk) 01:29, 20 March 2024 (UTC)
  • Support – I don't think that adding the t: will add an another level of obfuscation. The current method of making interwiki link is already obscure and complicated, specially for newbies, instead a simple alias to the template namespace will be easy and handy in researches. -- ZandDev 13:57, 20 March 2024 (UTC)
    Note that I suggested tp: though, not t: as it was rejected previously: does that work for you? Cocobb8 (💬 talk • ✏️ contribs) 13:58, 20 March 2024 (UTC)
    @Cocobb8: I'm in favor to the proposal of create an alias for the template namespace, but I believe that I, when I would see one of these link, would not associate tp: directly with templates, but with talk pages. -- ZandDev 16:04, 26 March 2024 (UTC)
  • Oppose I do work with templates but I feel that this is not an intuitive shortcut and could easily be confused with "talk page". (t · c) buidhe 04:57, 21 March 2024 (UTC)
  • Support , I had typed TP: prefix in the past thinking that I would get the template page without success. This would be useful in different scenarios (just like the WP: prefix). And its use is optional, so if someone doesn't like it, they can go with the full Template: as ever. Alexcalamaro (talk) 05:32, 21 March 2024 (UTC)
  • Oppose. Unnecessary, and just as with T=Talk, TP=Talk Page. wjematherplease leave a message... 08:01, 21 March 2024 (UTC)
  • Neutral Agree with the principle, would prefer access to a shortened version; but also agree that the proposal is too close to talk page. Regards, --Goldsztajn (talk) 22:08, 21 March 2024 (UTC)
  • I think supporting {{ in the search bar would be sufficient to support the use case of issue. But beside that, I agree with oppose comments above. Izno (talk) 02:48, 22 March 2024 (UTC)
  • Oppose per above. Not intuitive and I'm not convinced this solves a genuine problem -Fastily 21:26, 24 March 2024 (UTC)
  • Strong support because I have typed "Twmplate" in the search bar too many goddamn times. Mach61 21:03, 26 March 2024 (UTC)
  • Support: I have to do everything on mobile, and am looking up templates all the time. This would make that a significantly less laborious and typo-prone experience. But I'd be happy with some other 2- or 3-letter shortcut if TP: is a problem. No more than 3 letters, though. Also I keep typing TP:, TMP: or TPL: without thinking, expecting them to work. But I only want it for search purposes. I'd be opposed to its use as jargon for referring to templates. — Preceding unsigned comment added by Musiconeologist (talk • contribs) 01:34, 28 March 2024 (UTC)
    To help you out immediately, you can use the text expansion feature or apps on your phone to expand an abbreviated string to a longer one. isaacl (talk) 01:43, 28 March 2024 (UTC)
    Well yes, this is rather basic and I've already got a vast number of shortcuts set up. The one I'd naturally use for templates translates tem into {{|}}. There are two points, though: (i) it's counterintuitive and annoying that the whole word is needed, in contrast to wp: etc.; and (ii) beyond three characters, it stops really being a shortcut because it's only a bit shorter. Part of the annoyance is in having to remember that there isn't a 2-letter prefix to use. Musiconeologist (talk) 00:43, 10 April 2024 (UTC)
  • Alias {{ (if technically possible): no ambiguity and concise. Typing {{Rfc should take you to Template:Rfc and so should {{Rfc}}. I'm neutral on aliasing TP as the ambiguity may be balanced out by utility. I like T better despite previous community rejection. — Bilorv (talk) 22:37, 29 March 2024 (UTC)
    It is technically possible for {{ to be implemented, and there already is code for it if you want to try it out. Cocobb8 (💬 talk • ✏️ contribs) 22:41, 29 March 2024 (UTC)
  • Support any shortcut except just T. Aaron Liu (talk) 02:00, 30 March 2024 (UTC)
  • Support saves me a few characters/seconds when accessing templates through the search bar, might even make up for the seconds wasted to write this comment. Tl, tmp or tpl works for me if people object to tp. Draken Bowser (talk) 21:24, 3 April 2024 (UTC)
  • Support, this is an excellent idea. I type "Template:" in the search box a lot and it seems many other users do as well, so it makes sense to add a prefix. Preferably it wouldn't be "TP" if a good amount of people have issues with that; I don't care about what ends up being chosen as it remains relatively short (2 or 3 letters). ― novov (t c) 02:59, 6 April 2024 (UTC)
  • Support. Aliasing {{ is less preferable to me because a shortcut would also allow shortening template links in edit summaries, where {{tl}} is unavailable. The particular shortcut used doesn't matter to me, just that I won't have to type "Template:" every time. Nickps (talk) 12:46, 8 April 2024 (UTC)
    Think about the possibility of [[{{example}}]] Aaron Liu (talk) 15:11, 8 April 2024 (UTC)
    No. Why should we introduce a way to link to pages that only works in edit summaries and nowhere else? (Note that using it elsewhere will transclude example instead.) TMP:example on the other hand, will work in Search, in talk pages and in edit summaries and the fact that it's a unified syntax makes it easier for non power users to learn. I'm not opposed to introducing {{ for Search (alongside a regular shortcut) as long as we take measures to make sure that people don't end up on the wrong page. That is, if e.g. {{foo}} exists we should add a {{technical reasons}} hatnote to Template:foo/doc. Nickps (talk) 16:21, 8 April 2024 (UTC)
    @Nickps It's already impossible to start a title with a bracket, see [6] Mach61 12:25, 9 April 2024 (UTC)
    I'm aware. That doesn't mean there aren't topics whose WP:COMMONNAMEs start with {{. Nickps (talk) 12:57, 9 April 2024 (UTC)
  • Support. I've been at this for ten years and still hate calling up a template doc because it requires so damn much typing. The more typing, the more opportunity for typos that have to be corrected (and I'm good at typos). No objection to something other than TP, such as TM, although no doubt someone would say that could be confused with something else. The longer it gets (e.g. TMP), the less benefit. Something like this doesn't need to be descriptive, just easy to remember. ―Mandruss ☎ 05:02, 9 April 2024 (UTC)
    Doc pages don't require much more typing - and if four characters is too many, there is always the "view" link top right of the green doc box that is displayed on the main template page. --Redrose64 🌹 (talk) 13:18, 9 April 2024 (UTC)
    I'm talking about calling up template doc when I don't have a link to click, such as {{infobox person}} (I'm looking to read the doc, not edit it, so the transclusion on the "main template page" is all I need). So I'm typing into the search box, and typing nine characters before I even get to the template name. I would dislike three characters (tm:) one-third (3⁄9) as much. My question is: Why NOT do this? Where's the significant downside? ―Mandruss ☎ 19:27, 9 April 2024 (UTC)
    I think Redrose thought that you meant actually manually going to the /doc subpage. Aaron Liu (talk) 20:23, 9 April 2024 (UTC)
    Yeah, I know. Hence my attempt at clarification. ―Mandruss ☎ 20:31, 9 April 2024 (UTC)
    @Mandruss: I highly recommend User:Ahecht/Scripts/TemplateSearch. jlwoodwa (talk) 04:05, 10 April 2024 (UTC)
    Thanks. I prefer solutions that benefit everybody, not just those who are aware of a script and choose to use it. I'm not here just for myself. ―Mandruss ☎ 04:08, 10 April 2024 (UTC)
  • Support. Don't get why this hasn't been done already. We have wp: because typing "wikipedia:consensus" is tedious. And I can't spell template—I misspell it tempalte all the time—so an alias would be very nice. Anything four characters or shorter would be fine by me; I especially like the {{ idea. And to those who think that creating an alias will cause confusion—really? Is wp:sectionlink any more confusing than tm:sectionlink or something similar? You'll be lost for all of two seconds, if that. Cessaune [talk] 03:44, 11 April 2024 (UTC)
    omg I thought I had something really wrong with my fingers for always spelling tempalte Aaron Liu (talk) 11:35, 11 April 2024 (UTC)

Template namespace alias: Second survey

It seems to me we might have wide enough support for this to pass as a general concept. But I think a closer would be unable to decide on the specific alias to use, so we'd be looking at another RfC to decide that (ugh). Therefore a separate survey is in order. Eliminating tp:, I see at least tentative support for t:, tl:, tm:, tmp:, and tpl: (am I missing any?). I don't think this needs ranked voting—the specific choice isn't that critical—so it would be great if editors could just specify their one favorite. ―Mandruss ☎ 22:31, 9 April 2024 (UTC) Redacted 05:55, 14 April 2024 (UTC)

This section is not for opposition to the general concept; see my reply to Anomie's Oppose, below. ―Mandruss ☎ 00:53, 10 April 2024 (UTC)

Off-topic about namespace aliases for other things. ―Mandruss ☎ 05:13, 11 April 2024 (UTC)
  • I noticed that all here said that 'tp' seems to refer to 'talk page', so why not use it for talk pages? You're proposing a tp: alias for talk:? Aren't you a bit off topic? Besides, it would save only two characters, not 5–7: a truly negligible improvement. Besides, there are at least two kinds of talk pages, article and user. That's if you exclude other talk spaces, such as this one. If any additional aliases might make sense, they would be atp: for talk: and utp: for user talk:—the words "talk page" can be ambiguous in some contexts, so I try to use those acronyms wherever such ambiguity might exist. Apologies for extending the off-topic; sometimes I can't help myself! ―Mandruss ☎ 05:06, 11 April 2024 (UTC)
I agree with you, it isn't worth it to add tp: as an alias to talk:, the latter being already pretty short. However, for whatever ends up being chosen for template:, might it work to add an extra t in that alias for the template talk: namespace? Say, if tm: is the one chose, then tmt: could alias template talk:. Also, a shorter alias for user talk: would be ut:. Cocobb8 (💬 talk • ✏️ contribs) 12:54, 11 April 2024 (UTC)
Note "tmt" is the ISO 639 code for Tasmate. Anomie⚔ 13:14, 11 April 2024 (UTC)
  • Comment: people realize that t: is the existing psudeo-namespace for templates, as seen at T:CN and T:DYK? That doesn't mean you HAVE to support it, but it makes the arguments that it would be "confusing" stange, as it is already in use. Mach61 12:48, 11 April 2024 (UTC)
    There's also T:MP, and there's no evidence that people not already in the know aren't confused by those. Plus it could turn out to be more confusing once people can use it for every template rather than only the handful of pseudo-namespace redirects that have been allowed. Anomie⚔ 13:14, 11 April 2024 (UTC)
  • Comment. Let me see if I understand this. If the colon were removed from the title at TM:103 Hustlerz Ambition (a vanishingly insignificant cost to the project, although some Jeezy fans would disagree), that would create a redirect with the colon that wouldn't work because of a tm: namespace alias? Then we should consider manually changing all existing links to that article (104 entries in that list, although I don't know how many would have to change) and deleting the unusable redirect. Then all we'd have to worry about is the possibility that some obscure Tamboori Wikipedia (e.g.), Tamboori being spoken by 112 people on a remote island in the South Pacific, will be created in the future and somebody at en-wiki will want to link to it. ―Mandruss ☎ 14:23, 11 April 2024 (UTC)
    @Mandruss actually, we could just create a template page and redirect that (see Help:A Day in the Life for an analogous case). The issue is when there is already an existing template with the same name as a mainspace page after the prefix. Mach61 14:27, 11 April 2024 (UTC)
    Hmmm. Well there's something to be said for knowing I don't understand something, since I'll talk less. I don't know how much of an obstacle we're talking about. I do believe that we should be prepared to make some sacrifice to make this work. ―Mandruss ☎ 14:45, 11 April 2024 (UTC)
    Yeah, it's super easy to create an alias template, provided that the alias doesn't conflict with article titles/redirects already. Which is the main issue. Cessaune [talk] 15:55, 11 April 2024 (UTC)
    Also, it seems that Jeezy is a thoughtful Wikipedian, as he chose an appropriate spelling for his 2019 album title : TM104: The Legend of the Snowman, just to avoid conflict :-) Alexcalamaro (talk) 07:44, 20 April 2024 (UTC)
  • Tm or Tl Both are close to the colon-key, which is always practical. Draken Bowser (talk) 15:51, 11 April 2024 (UTC)
    @Draken Bowser: tl is off the table, hence the strikethrough in the intro to this section. See previous discussion in this section. ―Mandruss ☎ 16:14, 11 April 2024 (UTC)
  • After further consideration, I would probably go for t: or tmp:/tpl:. Any collision with article space can be solved by redirects, similar to Portal:No Escape, given the number of offenders is relatively small. TM: is a non-starter in my opinion since many keyboards auto-correct it to a U+2122 ™ TRADE MARK SIGN, and the point of a shortcut is to avoid difficulty. ― novov (t c) 02:33, 12 April 2024 (UTC)
    Very valid point. However, I've not seen that happen inside search boxes or on Wikipedia as far as I can remember, which are basically the only scenarios in which anyone would be typing template: anyway. Cessaune [talk] 04:15, 12 April 2024 (UTC)
    Unfortunately it does happen for me; afaik it's a default text replacement on macOS. I'd disable it, but I find the ability legitimately useful in other circumstances. ― novov (t c) 07:58, 12 April 2024 (UTC)
  • First choice Tm, second choice T: — PerfectSoundWhatever (t; c) 03:11, 13 April 2024 (UTC)

Browser config

I do not know about the rest, but on chrome, using the search engine shortcut feature worked perfectly.

  1. Go to chrome://settings/searchEngines
  2. Click "Add" that's next to "Site search"
  3. Fill out: Name = [Anything], Shortcut = [I picked "tt"] , URL with %s in place of query = https://en.wikipedia.org/wiki/Template:%s

That's it. After that, just type out your shortcut, followed by title, separated by a space/tab, on the address bar and hit enter. Everyone can pick whatever shortcut they like, for all namespaces and even page prefixes of their choice. You can add one for https://en.wikipedia.org/wiki/Wikipedia:Requests_for_adminship/%s to go to RFAs by just typing out usernames, for example. Best, Usedtobecool ☎️ 05:47, 9 April 2024 (UTC)

That's good for an alternative in the meantime! But tp: would make it easier regardless of the platform people use to contribute. Cocobb8 (💬 talk • ✏️ contribs) 11:20, 9 April 2024 (UTC)
You can also use User:Ahecht/Scripts/TemplateSearch to automatically replace TP: and {{ in the Wikipedia search box with Template:. --Ahecht (TALK
PAGE) 16:31, 11 April 2024 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Allow all autoconfirmed users to move pages without leaving a redirect

REJECTED
There clearly is not broad support for this proposal. Just Step Sideways from this world ..... today 19:48, 29 April 2024 (UTC)

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.

While redirects from page moves are commonly kept, there are reasons why they should not be kept as seen at WP:PMRC. For example, moving an article to draft space or to reverse page moves vandalism. This is common even for those without special tools (such as page mover or admin). This is so that normal users do not have to tag the page to request deletion and saves times for the admins (and users with the page mover tool) to do the work. Obviously this will not be an option for unregistered or new users, or for pages that are already move protected. The 'leave a redirect' button (or something along those lines) will be on by default and users who need to remove the redirect will have to manually press a button to turn it off. JuniperChill (talk) 14:28, 20 April 2024 (UTC)

  • Opposed: Being granted pagemover isn't that big a deal, but it does require you to demonstrate that you understand the relevant policies, and a quick look at WP:PERM/PM shows me that most requests are denied. Granting this to all autoconfirmed users with no human review would be unadvisable. RoySmith (talk) 14:57, 20 April 2024 (UTC)
    Per the change in focus, I'm opposed even to making this automatic for all extended confirmed users. If you really need the ability, just apply at WP:PERM/PM when you get the required experience. RoySmith (talk) 19:05, 20 April 2024 (UTC)
  • Oppose, I wouldn't feel comfortable with trusting all autoconfirmed users to move a page without leaving a redirect. At the very most, I would slightly support having it for all extended confirmed users (but not autoconfirmed). Cocobb8 (💬 talk • ✏️ contribs) 15:11, 20 April 2024 (UTC)
  • Strong Oppose autoconfirmed is trivial, and vandalism of "disappearing" articles (by moving them to say another namespace) can be annoying to fix, can result in patrolling get skipped, and is certainly disruptive to readers. — xaosflux Talk 15:49, 20 April 2024 (UTC)
  • Oppose for autoconfirmed, support for extended confirmed. A person who games extended confirmed to make vandalistic moves will quickly find that their extended confirmed permission is gone. Awesome Aasim 16:48, 20 April 2024 (UTC)
  • Oppose even for extended confirmed - we already have rampant violations of the WP:PMRC criteria by page movers, and don't need to make it worse. * Pppery * it has begun... 16:49, 20 April 2024 (UTC)
  • Own comment, I want to change this to all extended confirmed users, but does the discussion above need to be closed and I have to make a separate one below? It will be the same text I said earlier, but with small changes so that it is now all EC users. JuniperChill (talk) 17:14, 20 April 2024 (UTC)
    I don't think that we are so bureaucratic as to require you to start a new discussion, but I guess that if any of the editors who has already commented objects you should. Phil Bridger (talk) 18:19, 20 April 2024 (UTC)
    Yeah I can leave this discussion to be (leave it as it is) because some others have suggested supporting it for EC users instead. JuniperChill (talk) 18:36, 20 April 2024 (UTC)
  • Oppose even for extended confirmed. It's not difficult for anyone that needs and can be trusted with this right to apply for it. If they don't need it then it's just hat collecting. Phil Bridger (talk) 18:23, 20 April 2024 (UTC)
  • Oppose even for extended confirmed, per Pppery, Phil Bridger and Xaosflux. Most moves should leave a redirect but many people (even some admins) don't understand this, the pagemover right is a necessary (but not sufficient) check to ensure that the relevant policies and guidelines have been read and understood. Thryduulf (talk) 08:19, 21 April 2024 (UTC)
  • Oppose even for extended confirmed. It shouldn't be a thing for anyone but trusted users - all it will lead to is disruption. LilianaUwU (talk / contributions) 05:20, 26 April 2024 (UTC)
Weak support for extended confirmed users. As these users are more experienced, aware of the policies and guidelines, I believe that little or no disruption would occur if they could move pages without making redirects, to move pages using the Round-robin method. As we currently have less than 1300 page movers, this would make certain processes (such as moving an accepted draft to mainspace, or reverting page-move vandalism) less bureaucratic and more automatic. I also admit that I never understood why we have a user with the right only to move pages, used by only 1400 editors of which the majority are administrators.InTheAstronomy32 (talk) 17:49, 29 April 2024 (UTC)
Anyone who is autoconfirmed can move pages. The pagemover right lets you delete the redirect that is left behind. Phil Bridger (talk) 19:42, 29 April 2024 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Post closure comment - Looks like I should have said ECP users, but it looks like the proposal will still not survive regardless. I counted 0/10 support for AC users and 3 for EC users (excluding the proposer). I made this proposal because of the amount of times its useful to not leave a redirect, as stated above but other than that, keep it. Maybe at least from main to draftspace, redirects would be deleted regardless. I didn't think that by this way, non admins could effectively delete the page when it was actually moved elsewhere

(not sure if this is the right place to put post closure comments as it is just below the discussion, just no more support/oppose votes) JuniperChill (talk) 23:18, 29 April 2024 (UTC)

Split proposal at Wikipedia talk:Missing Wikipedians

There is a split proposal at Wikipedia talk:Missing Wikipedians § Split proposal that may be of interest to editors. All the best, ‍—‍a smart kitten[meow] 11:49, 3 May 2024 (UTC)

Another job aid proposal, this time with AI

Moved to WP:VPI § Another job aid proposal, this time with AI

— Preceding unsigned comment added by Joe Roe (talk • contribs) 07:32, 10 May 2024 (UTC)

 You are invited to join the discussion at Wikipedia talk:Growth Team features § Should English Wikipedia enable the Suggested Links newcomer task?. Sdkb talk 21:13, 16 May 2024 (UTC)

Category:Mythological cycle

[[Category:Mythological cycle]] is written with the lowercase "cycle" even though the main article of the category is capitalized as Mythological Cycle. Should the title of the category be capitalized like [[Category:Cycle of the Kings]], [[Category:Fenian Cycle]], and [[Category:Ulster Cycle]]? YukaSylvie (talk) 01:12, 26 May 2024 (UTC)

@YukaSylvie That looks like an uncontroversial pagemove to me. Cocobb8 (💬 talk • ✏️ contribs) 13:48, 26 May 2024 (UTC)
@YukaSylvie and Cocobb8: It could go through Wikipedia:Categories for discussion/Speedy. Graham87 (talk) 12:41, 27 May 2024 (UTC)
I've submitted it there. Graham87 (talk) 12:55, 27 May 2024 (UTC)

Article name change - nuances in a bilingual context

Hello, I am not entirely sure if this belongs here, but I wanted to ask if I could change the title of the article 'CD Atlético Baleares' to 'CE Atlètic Balears'. This football (soccer) club is from Mallorca, Spain, where both Spanish (dominant language) and Catalan (original language) are spoken. I want to change the club name in the article from Spanish to Catalan because the majority of supporters uses the Catalan name and all bibliography about the club and its history always uses the Catalan name as well. On the other hand, the club's official name is only in Spanish. Still, I consider the Catalan name more appropriate and representative. Does anyone know what the policy on these topics is? Thanks in advance! Liamb723 (talk) 14:58, 31 May 2024 (UTC)

The relevant policy is WP:TITLE, which instructs us to choose titles based on what is most recognizable to English-speaking audiences, which in practice means following English-language RS's conventions. signed, Rosguill talk 19:54, 31 May 2024 (UTC)

Political userboxes (especially PIA)

The recent pages Wikipedia:Miscellany for deletion/User:AtikaAtikawa/Userboxes/Anti-israeli apartheid and Wikipedia:Miscellany for deletion/User:AtikaAtikawa/Userboxes/Antizionist have involved contentious discussion, where commenters have suggested deleting other PIA-related userboxes. Political userboxes in contentious areas, especially ones involving war and violence, have strong potential to antagonize other users and threaten Wikipedia's values of civility, collaboration and discussion. This may outweigh the value of users' political self-expression as Wikipedia is not a forum. In the case of PIA, userboxes open an avenue for unproductive controversy that does not improve PIA articles by users who are blocked from editing them by ECR. Do you believe that such controversial userboxes are a problem? If so, would you consider broader policy restrictions on userboxes that make politically controversial statements about PIA? Air on White (talk) 00:47, 27 May 2024 (UTC)

I think they may still have to be argued on a case by case basis. One problem may be that some box is "anti" or against something, rather than for something else. eg instead of anti-zionist, they could have said, the user wants only Arabs in Israel. Instead of Anti-israeli apartheid it could have said the user wants one joint Israeli-Palestinian state, and then been acceptable. So MFD probably has to consider the name and the content of each box. Graeme Bartlett (talk) 01:06, 27 May 2024 (UTC) edited Air on White (talk) 03:27, 27 May 2024 (UTC)
I agree that case-by-case evaluation makes sense, but I don't think that only positive statements will help. Remember the scandal about the editor who made a positive statement that he "respected" Hitler? Or the drama over the positive statement that the editor believed marriage should involve one man and one woman? "I positively affirm that I believe it would be best if your whole nation ceased existing" is not the kind of statement that builds up the community. It is the kind of statement that makes individuals feel excluded and rejected.
On the other hand, there are some statements that might be acceptable. The community would probably not object to more generic statements like "I'm anti-genocide" or "I support peace in the Middle East". WhatamIdoing (talk) 03:16, 27 May 2024 (UTC)
This has been discussed ad nauseam, and I'll say what I've been saying: using userspace to make politically charged statements violates WP:SOAPBOX, WP:NOTBLOG, and WP:UPNOT, and it calls into question whether an editor is capable of complying with WP:NPOV. Thebiguglyalien (talk) 01:59, 27 May 2024 (UTC)
Well the bias would be recorded on the userpage, and is disclosed, so NPOV has something to check. Undisclosed POV pushing could be worse. Graeme Bartlett (talk) 03:01, 27 May 2024 (UTC)
I agree that it gives us information about how biased an editor might be, but I still think it would hurt the community overall. We have to be able to work together. Sometimes that means not posting messages that you wish people would die, or that countries would fail. WhatamIdoing (talk) 03:18, 27 May 2024 (UTC)
(edit conflict)Agree with Graeme in that respect, there may be reasons to avoid userboxes taking clear positions on X and Y, but a userbox is, at most, a symptom of NPOV issues. CMD (talk) 03:19, 27 May 2024 (UTC)
My view, having spent years watching the ARBPIA topic area, is that this is easily resolved by not caring about PIA-related userboxes people put on their user page that no one needs to look at or spend any time thinking about (unless and until an editor does something ANI/AE-report worthy in terms of content editing or their interactions with other editors).
  • It could be argued that to care about them and draw attention to them can itself be 'unproductive and may antagonize other users and threaten Wikipedia's values of civility, collaboration and discussion' via something resembling the Streisand effect.
  • Or they can be viewed as a signal in all the noise, a useful public declaration of an editor's biases that may influence their editing.
  • If someone is deeply offended by an Israel flag on my page, or something about how great the IDF are, or my agreement with human rights organizations' assessments of Israel or Palestine, and such-like, I wonder why they are editing in the ARBPIA topic area. I wonder if they have read Wikipedia:Arbitration/Index/Palestine-Israel_articles#Editors_counselled and should do something else for a while.
  • The PIA topic area is blessed with a diverse set of editors/drive-by visitors ranging from infuriatingly dumb piece of shit fire-starter motherfuckers to very experienced and knowledgeable editors who (want/try to) focus on content. Those experienced editors all have biases that influence their content edits and talk page comments in various ways that can and do 'antagonize other users and threaten Wikipedia's values of civility, collaboration and discussion' on an almost daily basis. It's okay, the PIA topic area is not that brittle.
  • For interest (or not), many years ago I added some photos from an Israeli human rights organization to the top of my talk page, arranged in the form of a comic strip. It is deliberately ambiguous. I was interested in whether anyone would interpret them as 'politically charged statements that violate WP:SOAPBOX', because to do so they would have to use inference to decide whether they represented support or opposition to the removal of Palestinians from land in the West Bank by the IDF. No one has ever commented on them. No one cares, and for me, this is how it should be in ARBPIA.
Having opinions about how to socially engineer/nudge the ARBPIA topic area seems to be quite popular, but they are rarely evidence-based, and no one really understands the complicated dynamics and can predict the impact of rule changes and the ways they are interpreted/enforced on content and behavior. As I have said elsewhere, it's probably better to focus on enforcing the existing simple rules that cover PIA. Sean.hoyland (talk) 05:23, 27 May 2024 (UTC)
None of these boxes belong here at all. Including such things in a user box comes across as more "official" or site supported than the user just writing their views in their own words. While this site isn't a blog, having a user simply state their own biases so that others can tell that they are (or are not) someone you want to associate with is preferable to them slapping these things on their page giving the impression that Wikipedia endorses their position. Short version, we should do away with all user boxes.--User:Khajidha (talk) (contributions) 13:05, 28 May 2024 (UTC)
Deja vue. User:Donald Albury/The Great Userbox Wars Donald Albury 13:56, 28 May 2024 (UTC)
I've long thought that Userboxes expressing opinions on social/political issues should all go. I wish we had done it after the Pedophilia userbox wheel war of 2006 or any of the other userbox-related cases, but instead we just carved out very narrow exceptions. They're a pointless waste of far too much time, and don't really have a use in an online encyclopedia. I'd support any proposal that limits userboxes to those related to Wikipedia in some way. The WordsmithTalk to me 22:57, 29 May 2024 (UTC)
To clarify my position, I'd oppose a proposal to kill PIA-related userboxen. That just kicks the can down the road until the next big ethnic, religious, social or political conflict just like killing the pedophilia, anti-SSM, Hezbollah or pro-Russian userboxen did. The piecemeal approach isn't working, it just wastes more time with each flare-up and it does nothing to improve the encyclopedia. I'd support a proposal to remove all of them at once. The WordsmithTalk to me 18:13, 31 May 2024 (UTC)
I'd also support something like this. I'll note the Hezbollah one as particularly telling because it never got fully resolved. It was clear that some of the editors kept the same userbox endorsing Hezbollah's militant activity and reworded it in the hopes of creating plausible deniability. I tried to point this out last year, they shouted AGF, and nothing was done about it. None of this should matter because it's detrimental to the encyclopedia with minimal benefit—in my mind that should be the start and end of the discussion. Thebiguglyalien (talk) 20:24, 31 May 2024 (UTC)
I really don't like edgy politics shit in userboxes -- I consider it stupid and in poor taste regardless of whether I agree with it -- but I don't really know how we can put a stop to it without some kind of extremely broad dragnet apparatus that sweeps up all kinds of normal stuff. jp×g🗯️ 04:05, 30 May 2024 (UTC)
In the real world, it has proven futile to use the law to ban expressions of dumb, distasteful opinions. It remains legal to say all kinds of obnoxious, provocative trash, and to print it on bumper stickers and T-shirts. Since it’s a big waste of time to try to legislate boundaries on this stuff, we generally deal with it through the use of quiet disdain. That is, rolling our eyes and shaking our heads, but ultimately moving swiftly on. Barnards.tar.gz (talk) 19:48, 31 May 2024 (UTC)
That's for governments, where these opinions directly affect how the government operates and there are real world implications that make restrictions on this conduct undesirable. Our situation is more analogous to a workspace, where making people feel unwelcome by bringing up controversial topics is absolutely something that's penalized. Thebiguglyalien (talk) 20:27, 31 May 2024 (UTC)
I'm sorry but I'm shocked that is discussion is categorized as "political" and that these userboxes are even debatable. Both userboxes mentioned support and advocate for violence against Israeli and Jewish people. What next? "Greater Germany" and "Heim ins Reich" userboxes? Gonnym (talk) 06:35, 30 May 2024 (UTC)
Hitler was a politician, and the Nazis were a political party, so yes, that would straightforwardly be a political issue -- political issues tend to be fairly serious and important, and millions of people die over them all the time. jp×g🗯️ 06:54, 30 May 2024 (UTC)
"Both userboxes mentioned support and advocate for violence against Israeli and Jewish people." No they don't, neither one does any of that. Levivich (talk) 10:35, 30 May 2024 (UTC)
War and struggle over which people govern a piece of land is, by definition, an issue of geopolitics. That's political, and there's really no denying that. The WordsmithTalk to me 20:22, 30 May 2024 (UTC)
i don't generally comment here, but i saw it on the dashboard and thought i'd give my brief two cents. i have a single PIA-related userbox on my userpage, which says that apartheid is wrong, and another which advocates for an end to capitalism (nested among about 30 other userboxes unrelated to politics), so of course i'll be a little more generous to political userboxen than some above this comment. in my opinion, political (or otherwise controversial) userboxen are case-by-case. i find gratuitously or emphatically political userboxen usually kind of gauche, and highly provocative userboxen like the first one mentioned to be generally a bad idea, to say the least. however, i believe that self-expression on wikipedia userpages is a good thing to preserve, and i would probably oppose any kind of change to the P&Gs we currently have on this issue. we shouldn't, as some seem to say, expect that editors themselves must be neutral - No One Is Neutral, nor capable of being truly neutral. edits must be what's considered regarding NPOV. the matter here is one of disruption - i don't edit at all in the PIA area, so my userbox really has no indication on my views about the topics that i do edit about, some of which are contentious. for example, i edit articles related to the Caucasus region - if i had a "Georgia for Georgians" userbox with Abkhazia & South Ossetia erased from a map of Georgia, i couldn't blame anyone for assuming i was NOTHERE or a POV-pusher regarding Georgian topics. therefore, i keep my views on the various conflicts in the Caucasus private, as i want my editing in that area to be as explicitly NPOV and inscrutable as possible. i suggest a similarly nuanced approach for others working in contentious areas.
tl;dr - it's really all about context and disruptive potential in the areas an editor works in, rather than a hard-and-fast line. MfDs for particularly offensive or provocative userboxen are perfectly effective here. ... sawyer * he/they * talk 06:49, 31 May 2024 (UTC)
quick addendum: sean.hoyland i think says it best, regarding PIA specifically.
(edit: also, i'm unsubscribing from notifications for this and don't plan on replying or reading this thread further) ... sawyer * he/they * talk 06:58, 31 May 2024 (UTC)

Setting focus to the search box by default

I would guess that most of the time one opens Wikipedia it's to search for something.

It would be so very much easier if, when the page is opened and after a search, focus could be set to the search box, and any content there be selected.

Please. AlStonyBridger (talk) 21:06, 1 June 2024 (UTC)

See the FAQ on WP:VPT. In short, WP will not be setting focus on the search box. DalsoLoonaOT12 (talk) 21:58, 1 June 2024 (UTC)
Text:

No, we will not use JavaScript to set focus on the search box.

This would interfere with usability, accessibility, keyboard navigation and standard forms. See task 3864. There is an accesskey property on it (default to accesskey="f" in English). Logged-in users can enable the "Focus the cursor in the search bar on loading the Main Page" gadget in their preferences.

DalsoLoonaOT12 (talk) 22:01, 1 June 2024 (UTC)

Random Article Feature Could Use Some More Work

I have come to observe that the random article function on wikipedia doesn't make use of the logged history of one's past searches e.g. A person who maybe predominantly searches and edits sports articles, biographies, scientific or whatsoever type of article, the random article that might be brought up could be something of a far different angle, e.g. medievial hisory, gothic architecture or even ancient people/languages. So I want to request if there could be a change to this, because sometimes I may want to edit an article, preferably stubs, on a topic that I'm interested in by using the random article feature and it brings out something else! So, I believe there could be a few needed adjustments here so that random articles will get the interest of the editor/reader by following the past pattern of the user's search history, and making the work done faster and more enjoyable. elias_fdafs (talk) 00:41, 3 June 2024 (UTC)

If it draws from a selection of articles based on what topics a given editor isn't contributing to, then it isn't very random, is it? Also, I'd have concerns about the feature automatically tracking and analyzing my contributions. Cremastra (talk) 00:54, 3 June 2024 (UTC)
Try Special:RandomInCategory instead. Folly Mox (talk) 01:07, 3 June 2024 (UTC)
And if that's more technical or specific than what you're looking for, you could try enabling the Newcomer Homepage (if you haven't already) select all tasks from the Suggested Edits pane, then choose a topic or topics you're interested in working on. Folly Mox (talk) 01:13, 3 June 2024 (UTC)
The problem with Special:RandomInCategory is that it doesn't know how to drill down through high-level cats. To use the examples here, Category:Sports, Category:People, and Category:Science are all useless for a RandomInCategory search. I tried a few experiments using Google's site: qualifier, i.e. site:en.wikipedia.org science. The results weren't terrible, but not as good as I would have hoped. RoySmith (talk) 15:15, 3 June 2024 (UTC)
You can try combining sort=random with articletopic: (like this) or with deepcat:, but deepcat: will fail for such large container categories as listed just above (it even fails against Category:Gothic architecture) due to the number of subcategories. Folly Mox (talk) 11:38, 5 June 2024 (UTC)
Some of the WikiProject categories might actually be more suitable for the OP's task than the content categories. (The discussion shows that this is one of the disadvantages of the "tree" model for categories as opposed to the "tag" model). —Kusma (talk) 11:51, 5 June 2024 (UTC)

Non-free license template for thumbnails of online videos

Should an image copyright template be made for copyrighted online video thumbnails, presumably derived from those for non-free title cards and for non-free video screenshots. It would ideally be titled Template:Non-free video thumbnail. JohnCWiesenthal (talk) 03:48, 11 June 2024 (UTC)

Create a Wikipedia for Arbëresh language

Hi dear Wikipedians!

I am from Albania and I have a request. Can you consider to create a Wikipedia for Arbëresh language, an Indo-European language which belongs to the Albanian language family and is spoken in Italy, but this language is different from Albanian and isn't mutually intelligible with Standard Albanian. That's why I am requesting to someone who can contribute and make available a Wikipedia in Arbëresh language, in order to keep this language alive and for Arbëresh speakers, which are different from Albanian speakers, to have their own Wikipedia and to create and also edit articles on their own Wiki. Thanks SanoIsufi (talk) 10:13, 13 June 2024 (UTC)

I think you need to post at Meta and show how it is more useful than Gothic. Best of luck! ——Serial Number 54129 10:17, 13 June 2024 (UTC)
Just by the way that’s not a fair comparison. Gothic is extinct and not even fully attested due to a tiny corpus, but people in villages somewhere actually speak Arbëresh. But yes, Meta is the correct place. RadioactiveBoulevardier (talk) 16:37, 20 June 2024 (UTC)
This is not something that editors on the English Wikipedia can help with. Requests for new languages need to be made on meta, specifically at m:Requests for new languages. However, before making a new request it is important that you first read the m:Language proposal policy and follow the instructions at m:Language committee/Handbook (requesters). Thryduulf (talk) 10:20, 13 June 2024 (UTC)
One important step in getting the Wikipedia approved is starting it in the incubator. The ISO code here is aae. Animal lover |666| 00:29, 16 June 2024 (UTC)

Mention drafts after redirects

I propose showing a notice similar to {{Draft at}} to visitors who are being redirected from an article that has a draft, as such: "(Redirected from X; there is a draft at Y)" This proposal was previously added as an idea here, where another editor commented it could technically work and would be useful to have. --Talky Muser (talk) 05:43, 22 June 2024 (UTC)

Interesting idea! I'd definitely support having this be an optional option for experienced editors, who might have an interest in improving the draft. I'm a little more wary of showing it to readers, given that they may not understand what draftspace means and how article there may be unvetted. (If we design a notice to appear on all draftspace pages, that could alleviate that issue.) Cheers, Sdkb talk 14:54, 22 June 2024 (UTC)
{{R with possibilities}} already does this when viewing the redirect - automatically if the draft's at the same title, or with the (undocumented) draft parameter if not. It shouldn't be shown on the redirected-to article, for all the same reasons that articles shouldn't link to draftspace. —Cryptic 20:23, 24 June 2024 (UTC)
I'd agree with Cryptic that this shouldn't appear on the article the reader is pointed to, as drafts are not checked for their content like articles are, and things that would never be kept in the reader-facing mainspace are tolerated in drafts. However, I would definitely support this being an option for experienced editors that can be enabled in user preferences (here, the criterion for "experienced editor" only being "knowing that Special:Preferences exists"). Chaotic Enby (talk · contribs) 02:40, 27 June 2024 (UTC)

Add nowrap for para

Wrong venue. Copied from the edit request at Template talk:Para#Add nowrap for para, which was rejected as "consensus required". April 2023 attempt to seek said consensus received no response. That system leaves a lot to be desired.

I used {{para}} and got a line break after the pipe character. This looked ridiculous and makes little sense. I assume other line breaks would be possible, such as after a hyphen in the parameter name. Adding {{nowrap}} or equivalent would make far more sense than requiring editors to code, e.g., {{nowrap|{{para|archive-url}}}}. While Note 2 below the table at "General-purpose formatting" speaks of nowrap options, I'm at a loss to see how they help my situation. In any event, I don't see how automatic, unconditional nowrap for all uses of {{para}} could be the slightest bit controversial. At the very least, an option could be added to suppress the default of nowrap for cases where horizontal space is limited, such as in tables.

See also Template talk:Para#no line-breaks in output, where a request for this was ignored (or never seen) 13 months ago. As to If the proposed edit might be controversial, discuss it on the protected page's talk page before using this template., well, we've seen how effective that was. ―Mandruss ☎ 21:53, 5 May 2024 (UTC)

It's unfortunate that the edit request was declined, when this seems like a fairly straightforward improvement and there seems to be a silent consensus to implement. I will plan to implement unless there are objections (courtesy pinging @Redrose64 as edit request responder). (Yes, coming here for this is a little POINTy, but the frustration at the edit request is understandable, and in any case let's not get bogged down by process concerns. Next time, though, I'd suggest replying to or talk page messaging the edit request responder.) Sdkb talk 22:05, 5 May 2024 (UTC)
Thanks. I did reply to Rose, with a ping, a mere four minutes after her rejection. When she hadn't replied after another 25 minutes, I surmised that she wasn't going to. Mea culpa: If I had checked her contribs, I would've seen that she hadn't made an edit after the rejection, so it's likely she left the site during those four minutes. Now self-flagellating for one hour. In any case, Rose doesn't change her mind much in my experience; she's that good.
I fail to see any POINTiness here; I'm just playing the cards I was dealt. ―Mandruss ☎ 22:22, 5 May 2024 (UTC)
I'm generally against adding nowrap, and would rather see it's use curtailed. It's causes endless formatting issues for those not using desktop screens, where the auto-formatter would do a better job. Nor do I see how not having 'para' wrap is an improvement, wrapping won't lead to any misunderstanding and may not even be wrapped on different screen aspects. -- LCU ActivelyDisinterested «@» °∆t° 01:46, 6 May 2024 (UTC)
From a usability standpoint, |archive-url= should all be on one line, not wrapped, because "archive-url" is a single concept (the parameter name) and should not be split in any way, despite the hyphen. I do not find broader ideological opposition to nowrap persuasive if it is applied reflexively to this circumstance without considering the particular situation here. I would find examples of instances in which parameters should be wrapped much more persuasive. Sdkb talk 02:36, 6 May 2024 (UTC)
It would be helpful to hear from TheDJ, who appears to have disabled nowrapping after it had been in place for about 11 years. – Jonesey95 (talk) 04:04, 6 May 2024 (UTC)
Yes. Applying nowrap to anything longer than a word is really bad practice and causes many issues for mobile, and situations where width is restricted. if you are going to apply it, apply it just to to the param= part, not to values (which can be giant urls) and definitely not to the entire line. A lot has changed in 11 years. —TheDJ (talk • contribs) 06:30, 6 May 2024 (UTC)
One of the problems here is that people give examples of common usages of this template. The problem is that those are NOT the only usages of the template. Even the doc page of the template itself has examples of pretty long values that basically form an entire sentence. Making an entire line not wrap is bad. Htm has to be flexible for many situations and if you set a very strict css option on a very generic template block that has very differing uses, you will run into problems like this. Solutions are to make the css more targeted (which in this case means being more strict about what the parameters can be, instead of just wrapping the template around a block of arbitrary text) or applying the css more targeted. |archive-url= for instance is ok.it just requires more thought by those writing the uses. —TheDJ (talk • contribs) 06:57, 6 May 2024 (UTC)
Applying it only to the param= part sounds reasonable. Sdkb talk 14:14, 6 May 2024 (UTC)
I'd be happy with that, provided it included the pipe character (that was the case that brought me here). ―Mandruss ☎ 16:29, 6 May 2024 (UTC)
@TheDJ: Looks like a limited-participation agreement, but I don't see any edit activity to the template. And this is due to fall off the page in three days. At the least, this comment will keep it for another nine. ―Mandruss ☎ 20:01, 12 May 2024 (UTC)
Keep for another nine days. ―Mandruss ☎ 20:48, 21 May 2024 (UTC)
Surely |quote=Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum. should be wrapped, although "|quote=" should not be. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 09:59, 28 May 2024 (UTC)
  • Support nowrapping the parameter-name, per Sdkb. The left side of param=value is a specific string of characters, not ordinary text, so it's best that it stays unified so it can be recognized or discussed correctly. DMacks (talk) 20:54, 21 May 2024 (UTC)
  • Support binding the leading pipe with the first alphanumeric string of the first argument passed to the template. I don't much care if |chapter-url-access= wraps on a hyphen, and certainly the "value" passed to the template should be able to wrap (think |title=Dictionary of Law, Containing Definitions of Terms and Phrases of American and English Jurisprudence, Ancient and Modern: Including the Principal Terms of International, Constitutional and Commercial Law; with a Collection of Legal Maxims and Numerous Select Titles from the Civil Law and Other Foreign Systems 1891), but it's disorienting to receive as output |
    date=. Folly Mox (talk) 12:11, 31 May 2024 (UTC)
    Redrose64 (as original declining admin), I count here five editors including myself supporting adding {{nowrap}} to the "parameter name" ($1) of {{para}}, with one editor neither supporting nor opposing that specific implementation, and all of us expect possibly the OP opposing nowrapping all arguments to {{para}}. Is that sufficient consensus for change? Folly Mox (talk) 12:29, 6 June 2024 (UTC) updated 13:39, 6 June 2024 (UTC) per below
    OP (me) supports nowrapping the whole parameter name, including the pipe character, no matter how long the parameter name is. For longer parameter names at the ends of lines, we can waste a little space without costing me any sleep. OP does not support nowrapping the parameter value, if any. ―Mandruss ☎ 12:39, 6 June 2024 (UTC)
  • Support binding |1= from the leading pipe through the trailing equal. However, I oppose nowrap for |2=. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 13:16, 6 June 2024 (UTC)

Keep for another nine days. ―Mandruss ☎ 12:11, 15 June 2024 (UTC)

Keep for another nine days. ―Mandruss ☎ 18:40, 26 June 2024 (UTC)

I think consensus has been generated here, although of course I'm involved. Maybe it would make more sense to rerequest the edit at Template talk:Para with a link to this thread, rather than continuing to bump the thread every week and a half to prevent archiving. Folly Mox (talk) 11:31, 27 June 2024 (UTC)
NOTBURO. I think the appropriate party(s) is/are aware of this thread. ―Mandruss ☎ 14:09, 27 June 2024 (UTC)
That doesn't mean that they're watching this thread. WhatamIdoing (talk) 22:58, 27 June 2024 (UTC)

Mechanism for requesting a neutral facillitator for RfCs

A mechanism where editors sign up to do this role and get selected/pinged randomly by a bot to make an RfC where the involved editors feel they wouldn't be able to be neutral or facilitate discussion and target common ground. The botched RfC I've done at Talk:United States is what propels me to ask for this, I'm too passionate about it and can't find neutrality/respectful constructive discussion. I'm sure this issue is commonplace and I think this would be a good solution, similar to 3O. Alexanderkowal (talk) 11:59, 16 June 2024 (UTC)

It's certainly true that there are a lot of RfCs that waste a lot of time or affect results with the way they're initially presented, so there could be something here. We could create a 3O for RfC development, but I'm not sure how often it would be used and I'm not sure how many people there are who loves developing RfCs on topics they have no interest in and would actually be good at doing so. At the end of the day, I think what could be accomplished through such a process could probably get just as much pre-RfC buy-in from just using the talk page to workshop it first. Then if people object to your framing, well they shouldn't helped you to write it. — Rhododendrites talk \\ 13:21, 16 June 2024 (UTC)
yeah that might be a better idea, start a topic about workshopping the rfc. If people agree, that might make a good section at WP:RfC Alexanderkowal (talk) 14:59, 16 June 2024 (UTC)
A proper RFCbefore, equivalent to workshopping, usually leads to a decent RFC, or it should. Selfstudier (talk) 15:16, 16 June 2024 (UTC)
I just think the role @BilledMammal is currently doing at Talk:Kerma kingdom#Requested move 9 June 2024 is so important and necessary for rfcs Alexanderkowal (talk) 20:57, 16 June 2024 (UTC)
@Alexanderkowal Intermittently I have been trying to play a role of discussion facilitator for an example at Talk:Jinn. IMO Probably three type of experienced users can play such role WP:3O volunteers, WP:DRN moderators and substantial experience in RfC closing. Bookku (talk) 07:28, 21 June 2024 (UTC)
Specially new users are interested in starting RfC and they do not know ins and out, facilitators can be good help. Bookku (talk) 07:31, 21 June 2024 (UTC)
That’s great, I suppose WP:DRN does this role well. Maybe at WP:RFC have a sentence saying “If there is minimal collaboration and you feel you can’t be neutral when designing the RfC, go to WP:DRN” Alexanderkowal (talk) 09:23, 21 June 2024 (UTC)
I would support that,
  • presently #Responding to an RfC says "..If you feel an RfC is improperly worded, ask the originator to improve the wording, or add an alternative unbiased statement immediately below the RfC question (after the {{rfc}} tag). You can also ask for help or a second opinion at Wikipedia talk:Requests for comment. ..".
  • Presently #Responding to an RfC largely goes unnoticed. Bookku (talk) 09:35, 21 June 2024 (UTC)
Yeah I think it’d reduce the chance of malformed RfCs and address wasting editors time Alexanderkowal (talk) 09:42, 21 June 2024 (UTC)
In this latest example one new user went on to begin RfC on their own with personalized complaint. As a discussion facilitator I added a neutrally worded question. Discussion facilitators can have a role. Bookku (talk) 08:42, 21 June 2024 (UTC)
I have seen Robert McClenon play this role at WP:DRN a few times. When filing a DRN case, you fill in a field asking "How do you think we can help resolve the dispute?". It would be reasonable to say "I would like the dispute participants and the moderator to work together to craft a brief, neutral statement and start an RfC." Firefangledfeathers (talk / contribs) 12:19, 21 June 2024 (UTC)
What would happen if the other involved editors say this would be a waste of time, meaning the rfc is unlikely to be made neutral? Alexanderkowal (talk) 12:23, 21 June 2024 (UTC)
I am ready to perform this role again when requested. If the other editors do not want to participate, then I will consider whether I can write a neutral RFC based on working with one participant. It takes a minimum of one involved editor and a facilitator. Mediation requires that the principal involved editors be willing to work with the mediator, but facilitation can be done by the facilitator and one involved editor. It is true that one disruptive editor can gum up the process, but one disruptive editor can gum up many processes, and that is what topic-bans are for. It is also true that one really disruptive editor can ignore a topic-ban and break things, but, unfortunately, that is what indefinite blocks are for. Robert McClenon (talk) 13:12, 21 June 2024 (UTC)
yeah I'd be happy to help out at WP:DRN once I'm more familiar with policy and done the training, it sounds like a good role Alexanderkowal (talk) 13:18, 21 June 2024 (UTC)
Wikipedia:Requests for comment#Creating an RfC says:
If you need help writing an RFC question, whether it's because you feel you won't write it neutrally or for any other reason, just ask for help at WT:RFC. We're mostly even nice folks over there, and between us, we have many decades of experience with the RFC process. WhatamIdoing (talk) 23:01, 27 June 2024 (UTC)

Animations

Animations are very useful, but also distracting. As a matter of policy, the animations on Wikipedia pages should be set up so the reader can choose whether and when to run them. Running them automatically when the page is opened is not necessary or recommended, but if it is done, then there should be a simple way to stop (and restart) them. CCDobson (talk) 15:23, 29 June 2024 (UTC)

Tracked in Phabricator
Task T85838
@CCDobson, the problem isn't policy; most of us want that. The problem is technological. Doing this, and making it work for all the relevant file types in all the web browsers, is apparently complicated. I've linked one of the technical tasks on the side here, if you want to read a bit more about the considerations. WhatamIdoing (talk) 05:04, 30 June 2024 (UTC)

User-info box

Proposal: Move the "user-info box" up.

The "user-info box" is currently found at the bottom of the user contributions page. See image under 22.

Depending on individual settings it's rather cumbersome to navigate to. I have to scroll past 1000 edits to access it. I suggest it's moved up, perhaps between the search box and the edits. Hypnôs (talk) 20:57, 30 June 2024 (UTC)

Standardise use of Lexical sets for describing English dialect phonology

In many of the articles linked to by Regional accents of English (separate note that many should be in Category:Dialects of English but are not), there are descriptions of each dialect's phonology. However, instead of using an extended version of Wells' Lexical sets, many articles refer to the broad transcription of rhotic RP English, according to Wikipedia:Manual of Style/Pronunciation. Thus Southern American English#Modern phonology has a table where the first column reads 'English diaphoneme, /æ/, /ɑː/, /ɒ/, /ɔː/' instead of 'Lexical Set, TRAP/BATH, PALM, LOT, CLOTH/THOUGHT' (or something similar) and Indian English#Vowels contains 'Diphthong /eɪ/ is pronounced as [e]' instead of 'FACE is pronounced as [e]'. Examples of articles using Lexical sets correctly are Scottish English#Phonology and American English#Phonology (for tables and not, respectively).

The bottom line is that the whole points of Lexical sets is that we don't need to talk about dialects in terms of a 'standard' pronunciation, and we can easily refer to groups of nouns and see how they interact (it clearly makes no sense to talk about a /ɒ/-/ɒ/ split rather than a LOT-CLOTH split). Therefore it is ridiculous to keep using broad transcription when Wells' system exists and is widely used already. Citation unneeded (talk) 17:22, 6 July 2024 (UTC)

Wikipedia:Edit filter manager has an RfC

Wikipedia:Edit filter manager has an RfC for possible consensus. A discussion is taking place. If you would like to participate in the discussion, you are invited to add your comments on the discussion page. Thank you. EggRoll97 (talk) 19:03, 6 July 2024 (UTC)

Proposed split of one of our largest lists

The List of common misconceptions contains more than 23,000 words and nearly 900 inline citations. We are already using workarounds to avoid some hard technical limits affecting reference display, and there are limits to what else can be done, especially if more citations are added. Please see Talk:List of common misconceptions#Split proposal, where we are talking about splitting it into two, three, or four separate lists, or alternatively discouraging the use of more than one or two sources per entry. Opinions and other ideas would be welcome. WhatamIdoing (talk) 16:46, 8 July 2024 (UTC)

Don't see what that has to do with the pump, there is a discussion on the talk page and editors there can sort it out.Selfstudier (talk) 17:18, 8 July 2024 (UTC)

City Vector Maps in SVG format

I invite the community to consider the following question: Do articles about cities need vector maps of cities in SVG format - editable, with a full CC-0 license, for free use in any media, publications, presentations, projects, etc.

Let me explain. I have been designing vector maps for many years. Now I have the opportunity to provide a large number of my city maps in SVG format.

I am sure that a map of streets and roads of a city is the main and most necessary content in Wiki articles about cities. In most cases - in articles about cities - there are no such maps. I tried to publish some of my maps in Wiki articles.

And I was extremely surprised that my maps were immediately removed. Reasons for deletion - some users did not like my nickname, some - my user page (and what is written there) - they considered it advertising, some - generally claim that city maps in articles about cities are not needed at all (most users) - and I’m sure that all these claims are unfounded and constitute a form of vandalism. Discuss. and all the arguments of the parties can be read HERE: https://en.wikipedia.org/wiki/User_talk:Vectormapper#Maps_and_promotion

LIST OF THE FREE CITY MAPS in SVG EDITABLE CC-0

[[7]] [[8]] [[9]] [[10]] [[11]] [[12]] [[13]] [[14]] [[15]] [[16]] [[17]] [[18]] [[19]] [[20]] [[21]] [[22]] [[23]] [[24]] [[25]] [[26]] [[27]] [[28]] [[29]] [[30]] [[31]] [[32]] [[33]] [[34]] [[35]] [[36]] [[37]] [[38]] [[39]] [[40]] [[41]] [[42]] [[43]] [[44]] [[45]] [[46]] [[47]] [[48]] [[49]] [[50]] [[51]] [[52]] [[53]] [[54]] [[55]] [[56]] [[57]] [[58]] [[59]] [[60]] [[61]] [[62]] [[63]] [[64]] [[65]] [[66]] [[67]] [[68]] [[69]] [[70]] [[71]] [[72]] [[73]] [[74]] [[75]] [[76]] [[77]] [[78]] [[79]] [[80]] [[81]] [[82]] [[83]] [[84]] [[85]] [[86]] [[87]] [[88]] [[89]] [[90]] [[91]] [[92]] [[93]] [[94]] [[95]] [[96]] [[97]] [[98]] [[99]] [[100]] [[101]] [[102]] [[103]] [[104]] [[105]] [[106]] [[107]] [[108]] [[109]] [[110]] [[111]] [[112]] [[113]] [[114]] [[115]] [[116]] [[117]] [[118]] [[119]] [[120]] [[121]] [[122]] [[123]] [[124]] [[125]] [[126]] [[127]] [[128]] [[129]] [[130]] [[131]] [[132]] [[133]] [[134]] [[135]] [[136]] [[137]] [[138]] [[139]] [[140]] [[141]] [[142]] [[143]] [[144]] [[145]] [[146]] [[147]] [[148]] [[149]] [[150]] [[151]] [[152]] [[153]] [[154]] [[155]] [[156]] [[157]] [[158]] [[159]] [[160]] [[161]] [[162]] [[163]] [[164]] [[165]] [[166]] [[167]] [[168]] Vectormapper (talk) 01:07, 27 June 2024 (UTC)

Where was the data for these maps obtained? AndyTheGrump (talk) 02:15, 27 June 2024 (UTC)
My family has been involved in cartography since the 17th century. I have a huge archive of geodata. Personally, I have been designing maps for over 25 years. Much was drawn from satellite images. Vectormapper (talk) 02:43, 27 June 2024 (UTC)
This a fantastic body of work but I think unfortunately they are of limited use on Wikipedia, now that we have the Kartographer extension. – Joe (talk) 07:55, 27 June 2024 (UTC)
I know about this application - Kartographer. It is suitable for creating previews, but not suitable for creating maps in vector formats suitable for use in media. And of course, maps created in the Cartographer project cannot be edited in a regular graphical environment. That is, you can look at them, but actually cannot use them. Vectormapper (talk) 16:50, 27 June 2024 (UTC)
People come to Wikipedia to look at things. Wikimedia Commons is for those who edit. Many cities have so-called gallery pages there (like c:New York City), I think that's the best place to put your vector maps for people (professionals like you, I'm afraid) to reuse them. Ponor (talk) 03:11, 28 June 2024 (UTC)
And on the page you indicated (gallery c:New York City ) there is also no good map of New York City.
Compare what is there now and what I offer. FREE and unlimited use.
https://commons.wikimedia.org/wiki/File:New_York_City_Greater_NY_US_street_map.svg Vectormapper (talk) 03:26, 28 June 2024 (UTC)
That's why I said someone (YOU!) should add them there. I'd also suggest using the c:Template:Map on Commons, with coordinates added, like I did for the NYC map. That's needed for our {{Location map}} templates (examples: Category:New York (state) location map modules). Ponor (talk) 14:18, 28 June 2024 (UTC)
Well, I hope that my city maps will be used by others in the community - which I see already happening. And I'm very happy about it. Vectormapper (talk) 18:12, 28 June 2024 (UTC)
I'm not seeing why we should make an exception to either our image use policy (due to the in-image credits) or username policy (due to yours matching the website promoted in them). —Cryptic 08:27, 27 June 2024 (UTC)
Don't you find it strange that a username CANNOT DISPLAY HIS PROFESSION? For example, a COOK, or a MECHANIC, or an ENGINEER, OR a MUSICIAN? This is not a policy, this is a contrived restriction. And this is obviously wrong. If, for example, a COOK edits a page with methods for preparing jerboa meat in his own tears, then it would probably be correct if the user name is still a COOK, and not “CRUEL_TORMORER OF_JERBOAS” Vectormapper (talk) 16:54, 27 June 2024 (UTC)
You're very much allowed to have your profession in your username. You're not allowed to have a username be only the name of a company/organization/etc, or a position in a company/organization/etc, that would imply possible shared use and/or doesn't identify you as being a single person. "Cook" is extremely generic, but wouldn't really imply shared use as it doesn't make sense for an account to be shared between all cooks, but "Trade Union of the Cooks of Example-land" would imply potential shared use. Chaotic Enby (talk · contribs) 17:45, 27 June 2024 (UTC)
My company is registered in the USA, and the name is SOLICITY NAV LLC - there is not the slightest coincidence with the name of the company. Vectormapper (talk) 18:02, 27 June 2024 (UTC)
I admire your work, @Vectormapper, but at 300px these maps are just abstract paintings in yellow and green. I'd have them printed on A0, but zooming-in to see the labels and streets (and anything) is too painful on Wikipedia. Kartographer is much better suited for that. Ponor (talk) 11:59, 27 June 2024 (UTC)
Are you joking? These are vector files and can be scaled to any size. 300 pixels is a tiny preview. You can't see anything in this preview. Vectormapper (talk) 16:45, 27 June 2024 (UTC)
So they're good for printing, but not for online viewing. Labels (and streets, buildings...) are of a decent size only when the map is rendered at thousands of pixels, and to get there you need to click on your map (served as a ~300px bitmap in Wikipedia articles), click again, click again and click again, only so you'd get the pristine svg in the browser. And then moving around the map is a pain, at least for the users spoiled by non-static Google or OpenStreet maps. Ponor (talk) 03:03, 28 June 2024 (UTC)
Google maps and Open Street maps are good for viewing online, and are completely unacceptable if you need to edit the map, use it in media and presentations, and, of course, for printing at any scale. And it is no coincidence that Wiki articles use SVG files for many images - (schemes, district maps, state and district maps, as well as emblems, flags and coats of arms) - their authors thought that someone would use these images in their projects . And this is absolutely correct. Vectormapper (talk) 03:52, 28 June 2024 (UTC)
Not sure about that. I make them so they would look better at the scales used in Wikipedia articles, which is anywhere from 220px to 300px. What we see in articles is always a scaled-down bitmap version of an svg, never the svg itself. Readers will never get 20–40+ MB maps on their devices, even if WMF decides to switch to native SVG support. (after some manipulation, your NYC map just crashed my laptop browser!) Ponor (talk) 14:10, 28 June 2024 (UTC)
Well, first of all, there is a large amount of software for viewing and editing SVG files. In the maps of streets and roads I published, the amount of data is reduced as much as possible for large cities. But New York City is a big city. Nothing can be done about this. Vectormapper (talk) 18:10, 28 June 2024 (UTC)
@Vectormapper, may I suggest that you spend a while lurking at voy:en:Wikivoyage:Travellers' pub? The travel guide usually wants some SVG maps. WhatamIdoing (talk) 23:06, 27 June 2024 (UTC)
Thanks))) I do it))) Vectormapper (talk) 23:47, 27 June 2024 (UTC)
These are impressive maps, I suspect use on article will depend on individual discussion. One note is that given these are so specifically detailed, they should probably have a date (title or description) to note when their underlying data was obtained. Best, CMD (talk) 03:30, 28 June 2024 (UTC)
This is a valuable point. But in general, the date of creation of the map is on the file description page. In any case, they are all spring 2024. Vectormapper (talk) 03:44, 28 June 2024 (UTC)
Checking my city, I see the map is at least a year out of date. So some data used to construct it was old. So I suppose we need newer versions over time. But I think the idea is good. Graeme Bartlett (talk) 10:37, 30 June 2024 (UTC)
Just indicate the city you need. I will try to update the city map as quickly as possible. Vectormapper (talk) 18:06, 30 June 2024 (UTC)
https://commons.wikimedia.org/wiki/File:Charlottesville_Virginia_US_street_map.svg Vectormapper (talk) 21:34, 28 June 2024 (UTC)
Saint Petersburg, Russia street map https://commons.wikimedia.org/wiki/File:Saint_Petersburg_Russia_street_map.svg Vectormapper (talk) 05:31, 3 July 2024 (UTC)

This week's article for improvement

The new, sixth section of the main page. There will be no editing protections on the article, or at least a very low level of protection. It will be modelled closely after Today's featured article in terms of format. I believe it will bring the following benefits:

1) Create an opportunity for more inexperienced editors to participate in the project by bringing forth a visibly imperfect article, possibly recruiting future long-term editors

2) Emphasize the participatory nature of Wikipedia

3) Improve the actual article being showcased

I would appreciate any thoughts. We could have a trial run before we implement it permanently. Bremps... 00:29, 3 July 2024 (UTC)

That would be an interesting idea! I've heard this proposal before, but I don't really remember how it went or why it wasn't implemented. It could also be a good way to work on systemic bias in Wikipedia. Of course, there are a lot of open questions, like how the article will be selected. Maybe voting between High-importance and Top-importance articles on various WikiProjects that are lacking in quality? Chaotic Enby (talk · contribs) 00:46, 3 July 2024 (UTC)
IIRC people usually object on the basis that the main page should feature our best content rather than content we know needs improving, and possibly some skepticism that positive contributions will be able to be made in the face of vandalism. Anomie⚔ 01:06, 3 July 2024 (UTC)
And also that it doesn't work: Wikipedia talk:Articles for improvement/Archive 5#Failure * Pppery * it has begun... 01:37, 3 July 2024 (UTC)
I like to think we're wiser than 11 years ago. Wikipedia was younger and less mature then. Bremps... 02:13, 3 July 2024 (UTC)
On the contrary, the rough consensus in that discussion appears to be that the TAFI trial did show promising results but that there were problems with the format, specifically that too many articles were presented each week. – Joe (talk) 04:39, 3 July 2024 (UTC)
Voting would be a good proposal. Or it could work like OTD, where people first-come first-serve fill in upcoming slots. Bremps... 02:19, 3 July 2024 (UTC)
First-come-first-serve would fill in extremely quickly, much more than OTD (as any article could be added any day, and people would be quite interested in having others improve their articles). And it would make self-promoting on the Main Page incredibly easy, while not necessarily guaranteeing that the articles being shown are necessarily a priority for improvement. Chaotic Enby (talk · contribs) 02:21, 3 July 2024 (UTC)
Voting it is! Bremps... 02:50, 3 July 2024 (UTC)
I suggest having a discussion at Wikipedia talk:Articles for improvement regarding restoring its section on the main page, and to understand how the project has filled its queue since it was last on the main page. isaacl (talk) 16:29, 5 July 2024 (UTC)
Most people on the Main Page have 0 edits, meaning they don't know how to edit. Wikipedia is reader-focused and we don't really need to be encouraging readers to convert to editors on the Main Page imo. The community portal is a better place to start. — PerfectSoundWhatever (t; c) 01:55, 3 July 2024 (UTC)
Honestly, readers will rarely stumble upon the community portal, let alone decide that this confusing-looking page is what will turn them into editors. If we want to make Wikipedia accessible as the encyclopedia that anyone can edit, it is only natural to encourage editing directly from the Main Page. Chaotic Enby (talk · contribs) 02:25, 3 July 2024 (UTC)
That's true. About the portal, I moreso meant beginner editors who want to learn more. I mean it is the first link on the main page under the "Other areas of Wikipedia". We also have the sidebar links "learn to edit" and "help". In my opinion, the "edit" buttons on every single article are sufficient to recruit readers. — PerfectSoundWhatever (t; c) 02:36, 3 July 2024 (UTC)
The focus on new editor recruitment is why it was deemed a failure the first time. If we are going to try again (and I think we should) the focus should purely be on article improvement. Taking a poor article and making it better. Blueboar (talk) 23:44, 6 July 2024 (UTC)
There are plenty of other reasons why a person could be capable of editing and yet not do so, I think. jp×g🗯️ 02:20, 9 July 2024 (UTC)
Is there an edit page option for an article for final approval prior to finalizing an edit week ,days, window of approval from editors ?The Summum Bonum (talk) 14:53, 10 July 2024 (UTC)

Discussion at WT:CSD § F8 and keep local

 You are invited to join the discussion at WT:CSD § F8 and keep local.-- Marchjuly (talk) 03:03, 12 July 2024 (UTC)

Two or more contributer/editorial authority procedure confirmation required prior to deletion or removal of an article/talk. A single contributor may add with references and citations but would require more than one to delete or remove.

To whom it may concern, It is sad to say that some individual contributer are trigger happy of their power/privileges on denying new edits on article/talk without checking the facts on the edit. I'm promposing that one contributer can add but cannot delete or remove voices on Talk. Denying/deletions of article/talk or removal of an article / talk should be verified by at least one or more contributer process. This would limit the frustration, time and effort of anyone who worked hard on the research and simply be denied due to bias on the original authors article/talk or for unknown reason without explaining and confirming that the references or citations are indeed known relative fact from all know legal form or law on publishing such phrase, statements and or quotes. I'm proposing also that the privilege/power of denying an edit on article/talk should only be possible with a two contributer or more editorial editor processe confirming false statement or factual unless a publication is false or link to an article was null ie. References/Citations without ISBN or Link page etc. can be edited by adding only to an article/talk that it is null but can not be deleted unless confirmed by more than one contributer/editorial authority procedure, Respectfully (The Summum Bonum (talk) 00:24, 10 July 2024 (UTC)

Is there a specific talk page item that you are unhappy about? In general, WP:TPO already prevents users from summarily deleting others' talk page comments. There are of course limited exceptions, but I'm not quite sure that we're solving a problem here that our policies and guidelines don't already address. — Red-tailed hawk (nest) 00:59, 10 July 2024 (UTC)
I’m humbled on your replies and truly appreciate your response, I don’t believe in lynching and my intentions are not to point on some instances but merely proposing a more standard approach to promote a more trusted way of decorum among contributors, vandalism ie.. anonymous users included notifying that decision was not bias and was not decided by a” single person alone” but a professional group of individuals. Thank you everyone (The Summum Bonum (talk) 12:15, 10 July 2024 (UTC)
my endless campaign to get people to start linking WP:SUPERHAT etc etc jp×g🗯️ 03:04, 12 July 2024 (UTC)
Well I think you should give examples of where you think it is wrong. I remove talk page entries where they are duplicates, vandalism, attacks, spam, created by spambots, or trolling, or perhaps created by banned editors' socks. If not in scope for the talk page, eg forum-like posts, I may respond instead of delete to see if there will be an improvement suggested. Graeme Bartlett (talk) 01:00, 10 July 2024 (UTC)
If I had to guess from this user's 16 prior edits, they had a talk page edit reverted as promotional, and are unhappy about it. The mainspace concerns seem to similarly stem from an inappropriately created draft that duplicates an existing article getting rejected. I don't think a proposal for a new policy is the correct solution for this editor's problems. ⇒SWATJester Shoot Blues, Tell VileRat! 01:46, 10 July 2024 (UTC)
Like what I was saying it was on the Talk an additional information I was mentioning and I was reminded not to attach the link of a site considered as promotional and I replied professionally and yes I admitted my mistakes I’m am not perfect The Summum Bonum (talk) 12:27, 10 July 2024 (UTC)
Thank you for your opinion/citations and giving us an example why I’m proposing this additional policy. It I believe in facts not wrong not correct, technical issues are itself a different proposal and new users should be guided and supported to experience more with more welcoming organizations rather than being judge by a newbie mistake a sponsorship would highly recommend rather than looking down on me. Again Thank you on your morally motivating remarks on my new proposal and hopefully a great experience as a contributor to this organization(The Summum Bonum (talk) 13:01, 10 July 2024 (UTC)
l The Summum Bonum (talk) 13:01, 10 July 2024 (UTC)
Thank you so much I m not in a position to say it was wrong or it was right, simple adding “ See also “ at someone else articles or additional citations or maybe a sentence or pronouncing words in specific languages are also important part of an information to a topic or articles. And the assurance that a or the deletion was made by not a single person but by a team truly (The Summum Bonum (talk) 12:22, 10 July 2024 (UTC)
If a contributor adds something to an article, and another contributor removes it, the onus is on the one wanting the change (ie, the one adding the material) to get consensus. From there on, it can be discussed on the talk page (see WP:BRD). Reasons for objecting to an edit aren't limited to it being factually incorrect, and can also include WP:DUE, WP:NPOV or simply being unencyclopedic. If we remove people's ability to revert other edits, it will heavily skew the balance in favor of inclusionism, and leave unwanted material in the article even if there isn't a consensus for it.
Regarding talk pages, it is already strongly discouraged, and considered inappropriate, to remove or edit someone else's comments without their permission, even when they are factually incorrect or unsourced. WP:TPO provides an overview of what is allowed, which mostly consists of unobjectionable cleanup and/or reverting vandalism. Waiting for several people to agree to this wouldn't necessarily be more helpful as the existing guidelines are already things no reasonable person would disagree with, and would only slow down things like reverting vandalism. Chaotic Enby (talk · contribs) 01:57, 10 July 2024 (UTC)
User talk:Swatjester example of lack of decorum his opinion is a prime evidence his statements are based from 16 actions of my failure to get it right doesn’t mean my intention was vandalism or improper it was more on the technical issues rather that producing the facts of the article (The Summum Bonum (talk) 12:34, 10 July 2024 (UTC) p.s. users page reliability
I'm sorry, what? My analysis of your *very short* editing history is not an example of "lack of decorum", and I made no statements about your intentions. I'll thank you to remember to assume good faith, engage civilly with others that are criticizing your proposals, and to stop casting aspersions at those who don't agree with you. You're really not helping your case here. ⇒SWATJester Shoot Blues, Tell VileRat! 04:58, 12 July 2024 (UTC)
Like I said my intentions was not to edit the article but to request to add an information on the article excuses my newb ability to edit that I personally apologized you showed us my faults and some contributers/editor personally send me information how to fix it and showed my mistakes. Critique on my proposal is a Positive Feedback meaning it make sense. It may take a little longer to verify some facts but at least we got right and team work verification is a positive outcome reducing bias opinions of some contents openings discussion on the topic due to the fact that what you know on a topic other informations are also available that everyone should know. I’m not even aware of someone disagreeing with me I saw your comment as lack of explanation to why disagree with the proposal by simply because an editor made a mistake or the contributor mistakes or failure to properly format an edit or article are are automatically disregarded not qualified to edit or doesn’t have the voice to submit a legitimate proposal. My example was my User page reliability. Example you worked hard on article then some user without any information regarding who he is or he is expert on something decided to delete his work just because the user was offended. Again my proposal is to eliminate those power of just because someone’s opinion but to verify the facts by a team not buy a single person alone; Thank you again on your feedback on this proposal The Summum Bonum (talk) 16:37, 12 July 2024 (UTC)
My proposal was based on my experience of accountability and I truly appreciate your response, I have experienced the meaning of “slow is fast, fast is slow” in Naval Terminology it simply means doing the right way properly the first time and verifications of multiple times is the key to a successful sailing. Thank you(The Summum Bonum (talk) 12:46, 10 July 2024 (UTC)
I did not mean to imply that your edits were vandalism. However, if you wish to discuss whether your previous edits were appropriate, here is not the place for it, and I'm afraid that ship has already sailed. Chaotic Enby (talk · contribs) 13:06, 10 July 2024 (UTC)
This proposal should should also include reverts of what is considered Vandalism with specific reference from the rules stating reason for reverts with a statement not by just inserting the 1000 words of the rule itself. Not all easy way is the right way. The Summum Bonum (talk) 13:24, 10 July 2024 (UTC)
Is it permitted to adjust the indentation level on a different editor's comments? -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 13:16, 10 July 2024 (UTC)
From what indentation type to another type.? I suggest requesting your voice or intention out on talk of the article for a voting in respect to the original author. Confirmed by a contributor plus you equals a team. And would be a yes. The Summum Bonum (talk) 13:32, 10 July 2024 (UTC)
Adding or removing ":"s in column 1 to indent comment one tab to the right of the text the comment is responding to, or adding a {{od}} in front of a comment. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 13:53, 10 July 2024 (UTC)
A programmers edit should be included on my proposal so your question regarding what you do and what you cannot visually to an article applies to visual editing ie…spelling spacing heading etc…but doesn't apply to this topic , but a policy to limit any including source editors for a secondary confirmation of removal or deletion of an article/talk intentions, a programmer who edits through source not through visual Is a matter of option of what the article visual or proper grammar/spellings fonts etc… should be considered a topic on itself on talk prior to confirmation of changes/edit with more than one contributor including the editor. You can add/ change alone but 2 contributors to delete/ remove an article/talk. A repeat offender of vandalism is punishable under the rules. Hopefully it clears your dilemma and I quote “wrong questions equals wrong answer.” Don’t expect someone’s answer to your question to be the same as your answers, and there is no “stupid” question. My flowchart maybe different from your flowchart but our output should be the same and we both agree that your flowchart was more efficient. From” {}” to indent to : or indent (). a.b. C. [] ? CMOS,APA, AP types made by the original authors should be respected. A matter of taste?
The Summum Bonum (talk) 14:43, 10 July 2024 (UTC)

Remove a word from a article

I understand that Indian courts have no jurisdiction over Wikipedia content, I would like to highlight that Wikipedia, as a global platform, has a responsibility to ensure that its content adheres to ethical standards and respects the laws and sensitivities of different cultures and nations. Article 17 of the Constitution of India explicitly abolishes the practice of 'untouchability' and criminalizes any enforcement of disabilities arising out of it. The use of the term 'untouchable' is deeply offensive and historically rooted in discrimination and oppression. I respectfully request that Wikipedia review below article content to ensure that it does not perpetuate discriminatory language. Instead of using the term 'untouchable', more appropriate and respectful terminology should be employed to discuss this aspect of India's history and social structure.

https://en.wikipedia.org/wiki/Pasi_(caste) 2405:201:300B:390E:E42A:45AE:34CC:F448 (talk) 19:44, 7 July 2024 (UTC)

Oppose As long as reliable sources use the term, so do we. A law doesn't blink a term out of existence. And Wikipedia is not censored. As long as an offensive term is being used an encyclopedic manner, there's no issue. If someone called another editor an "untouchable," they'd rightly be blocked very quickly, but this is a completely different things. CoffeeCrumbs (talk) 00:16, 8 July 2024 (UTC)
What, we can't explain it or put it further down than the first sentence of the lead? jp×g🗯️ 02:22, 9 July 2024 (UTC)
It's a gross word for a gross practice (IMO), but it's so ingrained in sources of topics related to castes that I don't think that improves matters. CoffeeCrumbs (talk) 01:11, 11 July 2024 (UTC)
The term (untouchable) truly exists it is a discriminating term and a factual statement, but we should truly recognize its meaning and existence. This establishment is not to promote hate or violence and discrimination to anyone but to freely share knowledge and information without bias and fear we hope you understand this organizations ethos/ethicsThe Summum Bonum (talk) 13:13, 10 July 2024 (UTC)
Wrong forum. Dronebogus (talk) 12:27, 13 July 2024 (UTC)

Request

Hi Wikipedia users and admins!

I am a new user on Wikipedia. I have made more than 10 edits and I need to edit some pages that are semi-protected or first level protection and also create some new pages on Wikipedia, without having to create them as a draft first. Please can you unlock the feature of semi-protected pages or first level protection pages on my account and also make possible for me to create some pages directly, without having to create them as a draft first.

Thanks AdamSala1991 (talk) 08:04, 18 July 2024 (UTC)

@AdamSala1991: You just have to wait one more day and your account will be autoconfirmed, then you can do all of those things. – Joe (talk) 11:39, 18 July 2024 (UTC)
Watchlisted. ——Serial Number 54129 13:17, 18 July 2024 (UTC)

Discussion at Wikipedia:Village pump (WMF) § Unnecessary line on fundraiser banner

 You are invited to join the discussion at Wikipedia:Village pump (WMF) § Unnecessary line on fundraiser banner. It is about a controversial line in current fundraiser (putting invitation here as it is kind of a proposal to remove it). –ExclusiveEditor Notify Me! 14:56, 11 July 2024 (UTC)

A profound emotion of acceptance It’s privilege to be invited on this matter but my familiarity with the topic is pretty much kindergarten level, but I would try my best if I can to be of service for the cause of of this organization spreading facts and knowledge of false/correct informations and understanding of both information’s existence. Thank you for the inviteThe Summum Bonum (talk) 12:22, 12 July 2024 (UTC)
Are you using an LLM to generate your answers, or are you writing in a language other than English and using a translator program? Donald Albury 17:44, 12 July 2024 (UTC)
Doesn't look like an LLM. They are either translating, or are a new user trying to be very well language(d), reminding me of myself when I was new. ExclusiveEditor Notify Me! 13:45, 13 July 2024 (UTC)
I tried removing unnecessary lines on my comment then learned that it is considered an act of destroying the context of a non private conversation, within minutes I changed it. I would have just said a simple "thank you for the invitation but Im not qualified on the topic I was invited to."(The Summum Bonum (talk) 13:25, 18 July 2024 (UTC)
productive criticism? or Assuming Im not human?am I invited or nil?The Summum Bonum (talk) 12:19, 18 July 2024 (UTC)
Is my name Intimidating? that your curiously asking me if I'm using an LLM. "I find your lack of faith disturbing"- Darth Vader. lol. now I sound more like an A.I.. The Summum Bonum (talk) 12:28, 18 July 2024 (UTC)
@The Summum Bonum: Its not about your name but the way you wrote your reply in a stretchy fashionable and to be honest, in an unusual way made it feel like written by an LLM, especially because this descriptions also match others comments which were confirmed to be written by LLM. However I think it is clear now, that is really written by you, a human! ExclusiveEditor Notify Me! 13:29, 21 July 2024 (UTC)

Allow everyone to move pages in draftspace

I'm proposing that moving a page that's in draftspace to a target also in draftspace be an action that doesn't require being autoconfirmed. This is so if a draft is created in the wrong place by an IP, they can fix it themselves without going to RM, which they probably don't know exists. An example where this would have been useful is Moshe Mizrahi (basketball) which, according to its history, was created at Draft:Moshe Mizrahi ( basketball), moved to mainspace by an AfC reviewer at Moshe Mizrahi ( basketball) and only then moved to the correct title. This left behind a useless mainspace redirect that I had to RfD. If the IP could have moved the draft to the correct title, there is a good change they would have done so and the useless mainspace redirect would not have been created in the first place. Nickps (talk) 14:46, 18 July 2024 (UTC)

AfC reviewers should and usually do correct the titles of drafts when they move them to mainspace. If and until that happens, what they're called in draftspace doesn't really matter. – Joe (talk) 15:37, 18 July 2024 (UTC)
In theory, I agree that allowing anybody to move a draft to a different draft title would be fine. The problem is that (as far as I know), the MediaWiki permissions system isn't flexible enough to allow non-autoconfirmed moves only in specific namespaces, and the effort required to add that capability wouldn't be justified by the benefit. RoySmith (talk) 15:50, 18 July 2024 (UTC)
Well, similarly to how editors don't have to worry about performance, editors shouldn't worry about how easy or difficult something is to implement either. I'll take it to Phabricator and let the devs worry about it. What we need to figure out is just whether there is any reason not to do it. Nickps (talk) 16:46, 18 July 2024 (UTC)
Please post the phab number here when you get one. RoySmith (talk) 16:47, 18 July 2024 (UTC)
Wait, before I do, are you sure that's right? We can limit who moves a page like we do with Files and Categories. Is there a reason we can't go the other way around with drafts and lift a restriction? Nickps (talk) 16:55, 18 July 2024 (UTC)
For now I just asked VPT to come here. Nickps (talk) 17:00, 18 July 2024 (UTC)
My understanding is that moving a page requires the "move" user permission. The Files and Categories namespaces are special-cased by the movefile and move-categorypages permissions, but I don't believe there is any general-case ability to apply the move permission to arbitrary namespaces. RoySmith (talk) 17:12, 18 July 2024 (UTC)
This seems like a solution in search of a problem. A non-autoconfirmed editor who notices that a page is misnamed and successfully moves it will be a rare creature indeed. Meanwhile, any regular editor can move a draft page to the correct name in Draft space, and AFC editors should be checking the name. It's right there in step 1 of accepting an AFC: "Select an appropriate name". – Jonesey95 (talk) 19:13, 18 July 2024 (UTC)
You are mostly correct. However, a) AfC reviewers don't always do that as my example demonstrates and b) even if we ignore that, I believe that we should be providing as much freedom to users as possible. Locking actions behind user rights should be done only when necessary, not merely because it's convenient. Restricting moves in mainspace makes sense because move vandalism is disruptive. In draftspace that is way less of a problem and if necessary, move semi-protection exists. Nickps (talk) 19:35, 18 July 2024 (UTC)
To be fair, your example is eight years old, was corrected in less than four hours, and the AfC reviewer that accepted it has been banned for years. Do you have any idea how frequent this problem is? I take your point that technical implementation isn't our job, but some sort of cost–benefit analysis still wouldn't go amiss, and I'm sure the devs will ask for one anyway. – Joe (talk) 21:38, 18 July 2024 (UTC)
I'm not sure how I could gather frequency data for this situation but, here's a recent example of a non-autoconfirmed (at the time) editor asking to move a draft to a new title in WP:RM/TR. So it's not like the feature would go unused. Nickps (talk) 01:24, 19 July 2024 (UTC)
Also, going back to the original RfD that inspired this, we find Draft:Marabella North Secondary School ( Marabella Senior Comprehensive), Draft:Philip Dukes ( Viola Soloist) and Draft:Argo ( Sword Art Online ) which were all moved to mainspace to the uncorrected names. That last one might have been a cut and paste since the move log is empty but Argo ( Sword Art Online ) was created all the same. Nickps (talk) 01:51, 19 July 2024 (UTC)
Draft authors usually want to move to mainspace, not another draft name. Giving them a move link and move form which doesn't work for mainspace may confuse and annoy them more than help them. PrimeHunter (talk) 15:31, 19 July 2024 (UTC)
That's one way of looking at it. But, on the other hand, that move form would be the perfect place to put instructions for how to move to mainspace since people would look there. Something like: "This form can be used to change the name of the draft. Only autoconfirmed users can move drafts to the main namespace. If that is what you want to do, see WP:Articles for creation". Nickps (talk) 19:25, 19 July 2024 (UTC)
@RoySmith phab:T370471 has now been opened. Nickps (talk) 19:30, 18 July 2024 (UTC)
I would worry about draft hijacking. BD2412 T 02:18, 19 July 2024 (UTC)
All I hear is "Encourage move vandals to focus on the Draft: space", and I don't think I like what I hear. WhatamIdoing (talk) 05:27, 20 July 2024 (UTC)
This seems less like a solution in search of a problem than a problem in search of a problem. Non-autoconfirmed editors don't need the ability to move pages, and the most common use case (moving their user sandbox to Draft:Title) wouldn't even be covered, since it would cross namespaces. On the other hand, this would open up a broad attack surface for very little benefit. Folly Mox (talk) 09:38, 21 July 2024 (UTC)
I see some comments saying that this will increase vandalism in draftspace but very little evidence to support this view. In my opinion, until someone provides such evidence, restrcting IPs' ability to move in draftspace goes against WP:SOP#2 as it fails to meet the standard of strict scrutiny. Nickps (talk) 12:06, 21 July 2024 (UTC)
WP:SOP#2 doesn't have anything to do with this proposal. Not giving IP addresses/un-confirmed editors the ability to move pages is a technical anti-spam/anti-vandal measure, since moves are demonstrably much harder to undo than plain edits. Sohom (talk) 19:57, 21 July 2024 (UTC)
Such a measure makes sense on mainspace sure, but not on draftspace which is not as popular of a target for vandals and where the damage isn't as front facing. SOP#2 has everything to do with it since it's an arbitrary restriction that targets new/unregistered users. Nickps (talk) 20:06, 21 July 2024 (UTC)
How would you revert a vandal who went on a vandalism spree and moved a few thousand drafts to Draft:<insert_random_expeletive_here> ? (Short answer, you couldn't, you would need to get hold of a page-mover (or if the vandal is more sophisticated, a admin) to undo the damage). Sohom (talk) 20:13, 21 July 2024 (UTC)
The thing you're describing isn't even possible. Moving a page to overwrite a page that already exists is not allowed (except WP:MOR but that is irrelevant). Can you provide an example of my proposal being harmful that can actually happen? Nickps (talk) 21:46, 21 July 2024 (UTC)
They don't have to all be the same random_expletive. (I am somewhat dismayed to discover that Willy on Wheels is a bluelink.) —Cryptic 21:59, 21 July 2024 (UTC)
Ok, in that case I'll just revert the moves like normal. Due to WP:MOR that should be easy. No need for a page mover. Nickps (talk) 23:27, 21 July 2024 (UTC)
Nickps, thank you for volunteering to clean up all the complicated chained page move vandalism your proposal would open the door to, but kindly read the room. Folly Mox (talk) 11:07, 22 July 2024 (UTC)
When I think the room is wrong, I'm going to say so, thank you very much. Also, I'm not just saying it, my actions support it as well. Nickps (talk) 11:12, 22 July 2024 (UTC)
And just to be clear, yes, I'm saying that I'm going to be watching Recent Changes if we do this. Nickps (talk) 11:27, 22 July 2024 (UTC)
I'll try to spell it out a bit more, it takes the vandal exactly one more edit to each page for it be effectively irreversible without admin/page-mover help. Also, I assume you will not be reading RecentChanges, all the time 24 * 7 * 365 hours.
Your previous actions proves the opposite, that we already have to deal with a fair bit of page move vandalism, and we don't want to enable features that opens us up to more of the same kind of vandalism. Sohom (talk) 12:12, 22 July 2024 (UTC)
Again, no one has shown that this draftspace move vandalism will actually happen let alone that our processes will be overwhelmed by it. Up until that is shown, I can only consider such statements fear mongering. But, as I'm willing to compromise, I suggest we at least do a trial of this and see whether I'm right and constructive moves are the rule or you're right and move vandalism overwhelms our processes.
I have to also point out that we do have the tools to deal with move vandalism. Semi-move protection is already a thing and page movers/admins can revert more advanced vandalism. If you're worried about me pushing work to other people, rest assured that if the kind of vandalism you describe actually happens, I'll go directly to WP:PERM/PM. Nickps (talk) 12:24, 22 July 2024 (UTC)

The Khmer Wikipedia appears with the letters in Bold

Hi Wikipedia editors and admins!

I am a new user in Khmer Wikipedia and I have a concern. I have seen that this Wiki appears with its writing system in Bold (dark letters), which previously didn't appeared. This is seen on the language list where the Khmer language appears, when viewing articles on the Khmer Wikipedia and on the search results on Khmer Wikipedia. Can you fix the issue and make the Khmer Wikipedia to appear in normal letters, in all its forms (where the Khmer language appears, when viewing articles on the Khmer Wikipedia and on the search results on Khmer Wikipedia), like the other Wikipedia editions are?

Thanks Cheni001 (talk) 13:57, 18 July 2024 (UTC)

The editors here at the English Wikipedia cannot do anything regarding issues on any other wikis, you will need to ask for help on that Wiki (I don't speak or read Khmer so I can't advise what the best location is, but based on Google Translate km:ជំនួយ:មាតិកា is probably a good place to start looking). However, my guess is that it might be a font issue, you should be able to check that by looking at the entry for Khmer at Help:Multilingual support (Indic). If that is the issue some of the other information on that page may resolve your issue. Thryduulf (talk) 14:11, 18 July 2024 (UTC)
@Cheni001, what kind of phone are you using?
@SGrabarczuk (WMF), is there any chance that the Web team changed any fonts? WhatamIdoing (talk) 05:24, 20 July 2024 (UTC)
Thanks @WhatamIdoing for pinging me! We haven't changed any fonts recently. I will ask the teammates if they know what this may be about, though. SGrabarczuk (WMF) (talk) 20:29, 22 July 2024 (UTC)

Adding a slight speed bump to slow down revert wars.

There's a editor's notice right now on a really contentious page: "You must follow the bold-revert-discuss cycle if your change is reverted." My reaction was, "Good idea. Reverting a revert never seems to end well. Maybe that rule should apply to all pages."

Yes, I know, that's not going to happen. But we can nudge people in that direction. How about a feature detects this and makes the user confirm that's what they want to. "We see you want to revert a revert. This is often viewed with antagonism. Please consider using the BOLD, revert, discuss cycle instead."

And if the user still wants to revert, they can, but at least we've slowed down the madness a tad. Isaac Rabinovitch (talk) 15:34, 23 July 2024 (UTC)

There is an opt-in script (preference?) (although I can't remember where to find it) that asks you for confirmation before actioning a rollback. The intent of this is to avoid accidental rollbacks, IIRC there was a discussion that rejected making it opt-out because it hinders vandal fighting and similar activities, although this was quite a long time ago and consensus may have changed with the rise of tools like huggle, etc Thryduulf (talk) 15:48, 23 July 2024 (UTC)
That is legitimately a good idea in my opinion, although it should be noted that WP:BRD is only an essay and technically optional. Wikipedia:Edit warring, which is policy, could be a better basis for a reminder if a revert-of-revert is detected, and I don't object to the text itself mentioning BRD if it is clear that it's optional (but encouraged).
The functionality itself might need some MediaWiki software tweaking to be implemented, but I'm not a specialist. Chaotic Enby (talk · contribs) 15:51, 23 July 2024 (UTC)
It is difficult to slow down revert wars without slowing down vandal fighting. —Kusma (talk) 16:38, 23 July 2024 (UTC)
You must follow the bold-revert-discuss cycle if your change is reverted. Is that a thing? Or it's just an ordinary editor writing that? Selfstudier (talk) 16:52, 23 July 2024 (UTC)
Awilley added this to Template:American politics AE a few years ago. I assume this was related to his Enforced BRD idea. I don't think it makes sense to tell editors that they must follow an optional process, but WP:EPTALK (which is mandatory for all editors) is less well-known, and perhaps they couldn't get consensus for imposing WP:1RR. WhatamIdoing (talk) 17:00, 23 July 2024 (UTC)
Bit like WP:CRP. Selfstudier (talk) 17:06, 23 July 2024 (UTC)
I'm concerned about how this would impact anti-vandalism, especially when you can't seem to get ahold of an admin to block or protect. It won't matter to a vandal if it takes an extra click and five or ten seconds to re-deface a page; it will matter if takes longer to revert them. Slowing down fights over content disputes is all well and good, but not when the WP:WRONGVERSION is one full of profanity. —Cryptic 17:49, 23 July 2024 (UTC)
Although I am an admin, I do not particularly focus on antivandalism, and in my experience, before I turned on requiring a confirmation prompt for a rollback, I was accidentally rolling back edits far more often than I used rollback for vandalism. In fact, when I do have to revert a lot of edits I still prefer to verify that each edit is indeed vandalism. I think that the 'requiring an affirmative prompt before rollback' setting should be optout rather than optin. Donald Albury 18:08, 23 July 2024 (UTC)
This is a potential application of edit check that is being explored, I believe. Sdkb talk 04:08, 24 July 2024 (UTC)
This seems like a good idea, and I'm not concerned about its impact on anti-vandalism. It isn't the end of the world if vandalism is reverted a few seconds later; and it will help cut down on accidental or over-zealous reverts. Cremastra (talk) 00:20, 25 July 2024 (UTC)
What does vandalism have to do with this idea? I'm not talking about making it harder to revert other people's edits. I'm talking about making it harder to do a double revert. Isaac Rabinovitch (talk) 11:32, 25 July 2024 (UTC)
1. Vandal replaces the lead image of a highly-viewed but not-currently-protected article with a freshly-uploaded dickpic at some time after most US admins have gone to bed and before most European admins have woken up. 2. Cluebot immediately reverts. 3. Appalled bystander immediately tags the image on Commons for speedy deletion and asks for the vandal to be blocked at WP:AIV. 4. Vandal makes the same edit, which is a revert of Cluebot; it's slow because of the new revert-of-a-revert feature, but he doesn't mind. 5. Entire group of appalled bystanders try to revert the vandal; it's slow because because of the new revert-of-a-revert feature, and Cluebot doesn't intervene because it doesn't re-revert the same page. 6. Entire group expands their futile pleading for help to WP:RFPP and WP:ANI. 7-20ish: repeat steps 4 and 5 and occasionally 6 until an admin intervenes.
The problem here is that it's making step 5 slower, no matter how large the entire group of appalled bystanders is or how quickly they react. —Cryptic 14:12, 25 July 2024 (UTC)
How often have you seen this happen? Vs how often have you seen revert wars? Isaac Rabinovitch (talk) 14:19, 25 July 2024 (UTC)
This exact scenario? Never, because we don't have this exploitable misfeature you're proposing that makes reverting vandalism arbitrarily slower. Non-exactly-repeated vandalism that persists for dozens of reverts before an admin puts a stop to it? All the time. Try searching the ANI archives for, say, AIV backlogged. —Cryptic 14:33, 25 July 2024 (UTC)
@Cryptic I'm a bit confused, because I don't see a proposal to implement a cooldown timer. Steps 5 and 6 would be "5. Entire group of appalled bystanders try to revert the vandal, get a message asking them to confirm, and hit 'OK'. 6. Entire group moves on with their lives." --Ahecht (TALK
PAGE) 15:32, 25 July 2024 (UTC)
This can't be done in a client-side javascript "Are you sure?" popup like the existing, optional ones for rollback links. There needs to be a roundtrip to the server to find that the attempted edit is a revert, and that at least one of the edits it's reverting was itself a revert, and then kick it back to the user. Besides, the last sentence of the proposal - but at least we've slowed down the madness a tad - makes the goal explicit; if it's not appreciably slowing down a vandalism rerevert, it's not accomplishing its stated purpose anyway. —Cryptic 15:41, 25 July 2024 (UTC)

Although I agree with the spirit behind the idea, I can't help but think that the existing policies rules and guides are sufficient. If an editor is intent on BRRD, for example, there is not much to be done about it except to take it up in talk, if an editor were continuously making use of BRRD to try and force through their view, then that's a behavioral problem and should be dealt with as such. One could ask an admin to impose WP:CRP if the issues were causing disruption. And so on.Selfstudier (talk) 16:12, 25 July 2024 (UTC)

Legalize "subsection" parameter of template "imdb title"

There are 20 thousands of pages which refer to a movie's IMDB title page subsection. They can't use Template:IMDb title because the template doesn't document how to link to a subsection.

Even current template allows doing that via undocumented trick (although that produces a warning) - just add /section to the movie id. Example: test at IMDb.

So I propose - either document this trick and make it official, or add another parameter to the template. fuxx (talk) 18:52, 20 July 2024 (UTC)

{{IMDb title}} is meant for an external links section, not a reference. There is rarely reason to link a subsection there. IMDb is a deprecated source for references: WP:IMDb. PrimeHunter (talk) 00:22, 21 July 2024 (UTC)
What PrimeHunter said. The template clearly states it's usage is for the EL section and it as they've pointed out, IMDb is not a RS to usage as a reference. Either find a RS to source the content, added a {{Citation needed}} tag, or remove the content. Gonnym (talk) 08:08, 29 July 2024 (UTC)

I see the new Dark Mode but can we also get a 3rd "Dim Mode"?

Pretty self explanatory, but for folks like me who find that Dark Mode is too dark to be readable on most apps, Twitter got it right with a 3rd option of "Dim Mode" which is not as dark as their "Lights Out" Mode, the equivalent to Dark Mode everywhere else.

Wikipedia is the website that I do the most reading on, it would be awesome if you implement options for folks with various visual impairments.

Hopefully you guys can consider! 2603:900A:1106:2DB9:1C37:85E1:CE71:D2BB (talk) 21:28, 28 July 2024 (UTC)

Pinging SGrabarczuk (WMF). WhatamIdoing (talk) 16:36, 29 July 2024 (UTC)

Marking Wikipedia:Pokémon test as Historical

I believe that Wikipedia:Pokémon test would be better marked as a historical page. It is not really about an editor's viewpoint, but about a former argument used in Articles for Deletion that lead to a mass deletion of Pokémon related articles. The article is still used in AFDs, but only when referencing this time period. (Oinkers42) (talk) 21:39, 29 July 2024 (UTC)

Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)/Archive_212&oldid=1242991576"