Jump to content

User:TheresNoTime/1

From Meta, a Wikimedia project coordination wiki
User:TheresNoTime/1
0 proposals, 0 contributors




Block history for individual IPs on ranges

Discussion

[edit]
  • There is a tool hosted on Toolforge called Rangeblock finder, which seems to cover what this asks for. And although it only supports enwiki, making it support other wikis should be trivial. Nardog (talk) 06:01, 6 February 2023 (UTC)
    That is a possible solution and would be considerably easier than implementing it in MediaWiki, but I've added phab:T146628 to the proposal anyway as this would add IP range support for all log types. MusikAnimal (WMF) (talk) 22:17, 6 February 2023 (UTC)
    I have bookmarked it and used it a couple of times. Daniel Case (talk) 02:47, 12 February 2023 (UTC)
  • I am ok with it if it comes with ways of not block ISPs/Severs with dynamic IPs, some users, specially outside first world countries, may get blocked from using or edit wiki because some vandal happens to have the same,ISP provider as this person, I think that should be seem firest before a such tool be made Meganinja202 (talk) 14:37, 14 February 2023 (UTC)
    This proposal is about block history for all IPs and subranges of a given range. Blocking functionality for ranges has been existing for a long time, and I don't think anybody is arguing that such blocks should be handled very carefully. ~~~~
    User:1234qwer1234qwer4 (talk)     16:47, 24 February 2023 (UTC)

Voting

[edit]

In Spam blacklist, allow sysops to enable blacklisting only on some namespaces

Discussion

[edit]
  • Improving Spam-blacklist interface would also be an opportunity to add a specific area/text box dedicated to comments (the reason why each website has been blacklisted). — Jules* talk 17:06, 29 January 2023 (UTC)
  • A very simple method to abuse this would be to create a blank page in a little-watched namespace where this link is permitted; transclude the new page in an article; after that add the link to the new blank page. If implemented, this request must have a simple method to prevent this. Animal lover 666 (talk) 21:16, 2 February 2023 (UTC)
  • I think a more interesting fix would be implementing MCR for the spam whitelist, which I filed a while ago as phab:T203157. Then however the local wiki has decided to make edit requests can do so much more locally and quickly. Izno (talk) 06:58, 13 February 2023 (UTC)

Voting

[edit]

Stop-time blocks

Discussion

[edit]

I appreciate that you're trying to come up with a solution, but I think this could be problematic. If I understood correctly, I as an admin would basically be able to "force" a user to spend an X amount of time online, on Wikipedia, clicking on links and so on, or else that person would not be able to edit again? Most of the vandals are probably less than 15 years old, and I would much rather want to tell them to go outside and/or do your homework instead of reading random pages on Wikipedia. Also, I'm pretty sure that letting admins see how much time someone spends on Wikipedia is against the privacy policy. -kyykaarme (talk) 10:00, 11 February 2023 (UTC)

You could set this up so admins wouldn't be able to see the exact time left ... perhaps just an indicator that would go from red to yellow to green as the block progressed. Daniel Case (talk) 02:44, 12 February 2023 (UTC)
  • I don't see how this is going to be implemented. First, logging "minutes spent on Wikipedia" requires some privacy issues. Secondly, the block will be unbearable and too long for all editors. Let's consider 24 hours block, a block that is given as a "first offense". A person averaged 4 minutes on every visit. Let's say people visit Wikipedia 3 times a day, which goes for 12 minutes every day. Then, for 24 hours block, it will take 120 days for the editor to be unblocked. I usually spend around 4 hours per week reading Wikipedia outside editing, which is way above the average user. It will take me 45 days for a 24-hour block to expire. If you want stricter/stronger punishment, a longer block is an easier solution. SunDawn (talk) 12:34, 11 February 2023 (UTC)
    You'd go with a shorter block than 24 hours. Maybe 10. Daniel Case (talk) 23:51, 11 February 2023 (UTC)
    Also, remember, blocks are not supposed to be punitive. We are getting to the point where in some situations (range blocks, block evasions using IPs) admins are increasingly opting for longer blocks on the first offense. This is going to hurt us with some prospective editors who may want to start an account, find that their school or whatever was blocked six months ago and will be blocked for another six months when they can't, and then just give up on ever getting involved. Daniel Case (talk) 02:44, 12 February 2023 (UTC)

Voting

[edit]
  • Support Support SHB2000 (talk | contribs) 22:24, 10 February 2023 (UTC)
  • Support Support Hanif Al Husaini (talk) 05:12, 11 February 2023 (UTC)
  • Support Support Arado Ar 196 (talk) 08:06, 11 February 2023 (UTC)
  • Oppose Oppose SunDawn (talk) 12:34, 11 February 2023 (UTC)
  • Oppose Oppose Wakelamp (talk) 13:17, 11 February 2023 (UTC)
  • Oppose Oppose No need to do that, it's hard to implement and no way it will work. Also it will cause some privacy breaches. Thingofme (talk) 13:38, 11 February 2023 (UTC)
  • Support Support Srijan Suryansh (talk) 17:23, 11 February 2023 (UTC)
  • Support Support Daniel Case (talk) 02:44, 12 February 2023 (UTC)
  • Oppose Oppose Per the privacy and implementation difficulties. Nosebagbear (talk) 17:30, 13 February 2023 (UTC)
  • Oppose Oppose Erbiton (talk) 21:06, 13 February 2023 (UTC)
  • Support Support ドラみそ (talk) 02:53, 14 February 2023 (UTC)
  • Oppose Oppose SpacedShark (talk) 05:31, 14 February 2023 (UTC)
  • Support Support cyrfaw (talk) 11:32, 15 February 2023 (UTC)
  • Oppose Oppose PRmaster1 (talk) 12:36, 15 February 2023 (UTC)
  • Oppose Oppose Phatom87 (talk) 16:10, 17 February 2023 (UTC)
  • Oppose Oppose It seems like a nice idea until you think about people spamming and/or gaming the system. Or the opposite, someone who doesn't spend much time on Wikipedia or mostly uses an IP is effectively indefinitely banned. Mitch199811 (talk) 18:18, 17 February 2023 (UTC)
  • Oppose Oppose per all the others above; there isn't a reasonable way to even define "time spent reading", much less measure it. 3mi1y (talk) 08:24, 18 February 2023 (UTC)
  • Oppose Oppose.--Vulcan❯❯❯Sphere! 12:30, 18 February 2023 (UTC)
  • Oppose Oppose --Libertyguy (talk) 21:32, 18 February 2023 (UTC)
  • Oppose Oppose Kcat37 (talk) 13:32, 21 February 2023 (UTC)
  • Oppose Oppose per Nosebagbear. ~~~~
    User:1234qwer1234qwer4 (talk)     17:15, 24 February 2023 (UTC)

Discussion

[edit]
  • If you're asking for enwiki, there's a link at the bottom of a user's contributions page – link "accounts", here en:MediaWiki:Sp-contributions-footer. If it's for some other wiki, any sysop can edit the MediaWiki message. If you still want it on the top, I'm not sure if there would be enough space for the link in that one line. But I agree, it helps to have the CentralAuth link handy. ponor (talk) 01:13, 25 January 2023 (UTC)
    I'm asking for this to be present at all the wikis, not just the biggest, and especially including the many wikis that don't have any admins who feel comfortable editing the interface. WhatamIdoing (talk) 06:28, 1 February 2023 (UTC)
  • Sure, there's also this that you can use: User:Linedwell/centralauthlink.js. Stryn (talk) 06:42, 25 January 2023 (UTC)
    Another script you can use, which I use globally, is CAWhoisProxy.js. Sdrqaz (talk) 17:29, 26 January 2023 (UTC)
    Sure, there are scripts that I already use, but this should be available to everyone, not just to the highly experienced editors who know where to ask or how to find the magical scripts. WhatamIdoing (talk) 06:29, 1 February 2023 (UTC)
  • Many projects already include this somewhere on that page, typically in the footer. Not sure the mediawiki software should be changed just for this. — xaosflux Talk 14:59, 26 January 2023 (UTC)
    This does seem like something the software can be expected to offer, and should be trivial to add. Also, on a very technical level, it's not guaranteed that Special:CentralAuth/Foo will be the same user (although the only SUL stragglers are now ancient bots and users with weird one-off migration bugs) so it's better done by the software. Tgr (talk) 02:01, 1 February 2023 (UTC)
  • They are already included at the end of the contribution page, but not all wikis show these links. Thingofme (talk) 03:11, 28 January 2023 (UTC)
  • The link at the bottom (in some wikis) is pretty inconvenient. I think CentralAuth does belong to the top links. It is probably useful to even a bigger audience than, let's say, abuse logs. MarioGom (talk) 17:38, 28 January 2023 (UTC)
  • Note that the Sp-contributions-footer links are unreliable: apart from the fact that every community has to set them up on their own, if you read English Wikipedia with a non-English interface language you probably won't see them (due to T57473). I would actually go the opposite direction and add the widely-used, well-maintained tools from the footer via the ContributionsToolLinks hook. --Tgr (talk) 05:27, 1 February 2023 (UTC)
    That sounds much more complicated, so I'd rather leave it for another time. Among the complications, I believe that Toolforge has rules against having anything in MediaWiki depend on its tools, and the non-WMF-hosted tools have privacy challenges. For example, if you click a link on the English Wikipedia to geolocate an IP address at a third-party website, you are inadvertently telling that third-party that someone at the English Wikipedia is interested in that IP. This might not be very valuable information (I hope), but it's not really living up to our ideals about privacy, either. WhatamIdoing (talk) 06:34, 1 February 2023 (UTC)
    Differentiating between what can be linked from the footer vs. what can be linked from the header just because they happen to be generated via different means doesn't seem useful to me. Tgr (talk) 07:27, 1 February 2023 (UTC)
    I've been poking at this problem for years. Main notes are in phab:T140585 and details at mw:Notes for potentially moving some mediawiki system messages into wikimediamessages (and linked subpages one and two) (and older notes in my old comment that was forked into phab:T67446). I believe the solution is to (1) research the most-used links, and their ordering, in the wikis which currently use these systems, (2) use Extension:WikimediaMessages to make a new 'default'. -- I've been blocked on 2, as it needs dev-confirmation that this is the best route forward. But I'd also welcome the CommTech team taking on the research and outreach aspects. Quiddity (talk) 20:32, 6 February 2023 (UTC)
  • This indeed should be visible on all wikis. Taylor 49 (talk) 10:14, 5 February 2023 (UTC)
  • Maybe the contribution footer with CentralAuth and editcount link should be the default on all Wikimedia wikis, no matter how big or how small. Thingofme (talk) 14:43, 6 February 2023 (UTC)
    Strongly support this. If a certain project doesn't want it or wants a different set/sequence of links at the footer, they are always free to edit the relevant MediaWiki page. —‍CX Zoom (A/अ/অ) (let's talk|contribs) 19:44, 17 February 2023 (UTC)
  • See also w:User:The Voidwalker/centralAuthLink.js. ~~~~
    User:1234qwer1234qwer4 (talk)     17:17, 24 February 2023 (UTC)
  • Question Question: I've picked this up (T331743 / patch) as a quick little task to do, and a question of user experience has been raised. So rather than us guess what y'all want, I thought it was best to just ask: when you click on this new CentralAuth link in the ContributionsToolLinks, would you want that to go to the local Special:CentralAuth (i.e., if you were on the English Wikipedia, the link would go to en:Special:CentralAuth) or always come to Special:CentralAuth here on Meta? — TheresNoTime (talk • they/them) 22:57, 10 March 2023 (UTC)
    As there's no difference in the results shown, I don't care which wiki it's displayed on. WhatamIdoing (talk) 19:22, 11 March 2023 (UTC)
    I always go to Meta, so that what is essentially the same page has only one entry in my browser history and is in the language I'm familiar with (also "Previous global account changes" only seems to appear on Meta). I get sending the user to another site could be contra expectation though (if so I'll keep on using my MoreMenu custom link). Nardog (talk) 19:46, 11 March 2023 (UTC)
    Local CA page is useless for stewards, I never use it. If it links to a local CA page at least a local CA page should include a link to CA on Meta. Stryn (talk) 07:13, 12 March 2023 (UTC)

Voting

[edit]

Layering/timing of blocks

Discussion

[edit]

We have an important update about this wish – October 17, 2023

[edit]

Hello Daniel Case, and everyone supporting this request about blocks.

We have selected this wish for fulfillment, and as usual, we have created a project page to share information about our approach and give you space to give feedback.

Please note that the project has been renamed Multiblocks.

Visit the project page to learn more about the scope of work, constraints, and the status of our technical investigation into this wish.

Please read what we have presented, and give us feedback immediately if you disagree with anything. We would also like to know if you agree with our approach.

Thank you. ––– STei (WMF) (talk) 22:25, 17 October 2023 (UTC)

We have updated the project page – November 10, 2023

[edit]

We have added more information in November 2023 about our technical investigation of the wish, and a brief glossary of terms used on the project page. Please check and give feedback on the project talkpage.

–– STei (WMF) (talk) 19:00, 10 November 2023 (UTC)

Pinging users: –– STei (WMF) (talk) 19:00, 10 November 2023 (UTC)

Voting

[edit]
  • Support Support Allowing for overlapping blocks would certainly be useful. — xaosflux Talk 18:19, 10 February 2023 (UTC)
  • Support Support I personally haven't seen a need for layered blocks (yet), but stacked blocks (as in sequentially following each other) would definitely be useful. —Mainframe98 talk 18:59, 10 February 2023 (UTC)
  • Support Support I have multiple times thought, that this would be useful. Taivo (talk) 19:52, 10 February 2023 (UTC)
  • Support Support reducing cognitive load on admins who must currently remember to check back in when a sitewide ends in order to reapply a partial block. Folly Mox (talk) 20:07, 10 February 2023 (UTC)
  • Support Support Strainu (talk) 20:11, 10 February 2023 (UTC)
  • Support Support HouseBlaster (talk) 20:24, 10 February 2023 (UTC)
  • Support Support Tol (talk | contribs) @ 20:26, 10 February 2023 (UTC)
  • Support Support Patar knightchat/contributions 20:36, 10 February 2023 (UTC)
  • Support Support Dan.- (talk) 21:37, 10 February 2023 (UTC)
  • Support Support SHB2000 (talk | contribs) 22:19, 10 February 2023 (UTC)
  • Support Support both layered protection and layered block. Jeeputer (talk) 23:05, 10 February 2023 (UTC)
  • Support Support LD (talk) 23:29, 10 February 2023 (UTC)
  • Support Support Adding on to this, I've noticed that if a user is blocked site-wide then an admin has to remember to reinstate the partial block. With layered blocks this wouldn't be an issue as they would be site-wide blocked while still having the partial block. ― Blaze WolfTalkBlaze Wolf#6545 23:37, 10 February 2023 (UTC)
    This is exactly the issue I was describing at the second bullet point. Daniel Case (talk) 02:52, 12 February 2023 (UTC)
  • Support Support --NGC 54 (talk｜contribs) 23:54, 10 February 2023 (UTC)
  • Support Support StartGrammarTime (talk) 00:39, 11 February 2023 (UTC)
  • Support Support Hehua (talk) 00:52, 11 February 2023 (UTC)
  • Support Support Mark Ironie (talk) 01:18, 11 February 2023 (UTC)
  • Support Support Dreamy Jazz talk to me | enwiki 02:41, 11 February 2023 (UTC)
  • Support Support Why we can't do this like we can overlay semi-protection over pending changes has baffled me. Katietalk 03:19, 11 February 2023 (UTC)
  • Support Support * Pppery * it has begun 03:37, 11 February 2023 (UTC)
  • Support Support Spencer (talk) 04:38, 11 February 2023 (UTC)
  • Support Support Hanif Al Husaini (talk) 05:25, 11 February 2023 (UTC)
  • Support Support Soumendrak (talk) 06:15, 11 February 2023 (UTC)
  • Support Support Martin-78 (discutailler) 07:54, 11 February 2023 (UTC)
  • Support Support --Jim Hokins (talk) 07:57, 11 February 2023 (UTC)
  • Support Support Arado Ar 196 (talk) 08:05, 11 February 2023 (UTC)
  • Support Support NguoiDungKhongDinhDanh 09:20, 11 February 2023 (UTC)
  • Support Support Golmote (talk) 12:26, 11 February 2023 (UTC)
  • Support Support Lupe (talk) 13:18, 11 February 2023 (UTC)
  • Support Support IP blocks are layered by ranges so this should be done. Also, protections as admin temporary fully protect a page while this page is getting indefinite semi/or 30/500 protection and when the full one expire they have to remember to reinstate the block again or the page getting vandalized. Thingofme (talk) 13:47, 11 February 2023 (UTC)
  • Support Support Guerillero Parlez Moi 13:51, 11 February 2023 (UTC)
  • Support Support Rots61 (talk) 15:59, 11 February 2023 (UTC)
  • Support Support Robertsky (talk) 17:29, 11 February 2023 (UTC)
  • Support Support Thomas Kinz (talk) 18:40, 11 February 2023 (UTC)
  • Support Support Novak Watchmen (talk) 18:47, 11 February 2023 (UTC)
  • Support Support Also, per Jeeputer, layered protections would also be helpful! HJ Mitchell | Penny for your thoughts? 18:55, 11 February 2023 (UTC)
  • Support Support WhatamIdoing (talk) 20:12, 11 February 2023 (UTC)
  • Support Support — Jules* talk 21:18, 11 February 2023 (UTC)
  • Support Support Hey, I proposed it. Daniel Case (talk) 23:46, 11 February 2023 (UTC)
  • Support Support Gohan 02:59, 12 February 2023 (UTC)
  • Support Support This proposal so firmly establishes the desire, need, and utility of this clearly missing technical capability that should, otherwise, be in long term use before now that I am, hereby, compelled to give my support.--John Cline (talk) 16:29, 12 February 2023 (UTC)
  • Support Support Daniuu (talk) 19:16, 12 February 2023 (UTC)
  • Support Support Izno (talk) 06:52, 13 February 2023 (UTC)
  • Support Support Tacsipacsi (talk) 08:48, 13 February 2023 (UTC)
  • Support Support Titore (talk) 14:02, 13 February 2023 (UTC)
  • Support Support - per the above Nosebagbear (talk) 17:31, 13 February 2023 (UTC)
  • Support Support · · · Peter (Southwood) (talk): 17:54, 13 February 2023 (UTC)
  • Support Support —Yahya (talk • contribs.) 21:17, 13 February 2023 (UTC)
  • Support Support Ayumu Ozaki (talk) 22:29, 13 February 2023 (UTC)
  • Support Support ドラみそ (talk) 02:50, 14 February 2023 (UTC)
  • Support Support. Greater nuance is a good thing. Sdrqaz (talk) 03:05, 14 February 2023 (UTC)
  • Support Support SpacedShark (talk) 05:20, 14 February 2023 (UTC)
  • Support Support //Lollipoplollipoplollipop::talk 13:38, 14 February 2023 (UTC)
  • Support Support Barkeep49 (talk) 16:52, 14 February 2023 (UTC)
  • Support Support Tris T7 (talk) 18:14, 14 February 2023 (UTC)
  • Support Support Antimuonium U wanna talk? 23:18, 14 February 2023 (UTC)
  • Support Support Rzuwig► 08:48, 15 February 2023 (UTC)
  • Support Support -Xayala Mammadli (talk) 10:29, 15 February 2023 (UTC)
  • Support Support cyrfaw (talk) 11:33, 15 February 2023 (UTC)
  • Support Support ~Cybularny Speak? 13:42, 15 February 2023 (UTC)
  • Support Support Ruthven (msg) 15:30, 15 February 2023 (UTC)
  • Support Support --——d—n—f (fr.-sysop) (talk) 07:56, 16 February 2023 (UTC)
  • Support Support Hey man im josh (talk) 15:05, 16 February 2023 (UTC)
  • Support Support ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 07:37, 17 February 2023 (UTC)
  • Support Support Kalesh (talk) 09:02, 17 February 2023 (UTC)
  • Support Support Geraki TL 10:46, 17 February 2023 (UTC)
  • Support Support ~ Amory (u • t • c) 16:25, 17 February 2023 (UTC)
  • Support Support —‍CX Zoom (A/अ/অ) (let's talk|contribs) 19:42, 17 February 2023 (UTC)
  • Support Support Lightoil (talk) 02:53, 18 February 2023 (UTC)
  • Support Support This is a good proposal Uncle Bash007 (talk) 04:28, 18 February 2023 (UTC)
  • Support Support --Minorax«¦talk¦» 09:02, 18 February 2023 (UTC)
  • Support Support Johannnes89 (talk) 11:45, 18 February 2023 (UTC)
  • Support Support Sakretsu (炸裂) 13:00, 18 February 2023 (UTC)
  • Support Support FoBe (talk) 14:20, 18 February 2023 (UTC)
  • Support Support —‍Mdaniels5757 (talk • contribs) 17:48, 18 February 2023 (UTC)
  • Support Support The person who loves reading (talk) 21:29, 18 February 2023 (UTC)
  • Support Support Alfa-ketosav (talk) 14:00, 19 February 2023 (UTC)
  • Support Support Zsinj (talk) 02:13, 20 February 2023 (UTC)
  • Support Support Amir (talk) 08:25, 20 February 2023 (UTC)
  • Support Support — Draceane talkcontrib. 11:03, 20 February 2023 (UTC)
  • Support Support As a former cs:wiki arbcomer I mean, this thing will be very useful. We’ve banned one user for one year to article discussion and for two years editing of article, and this block settings is now impossible--F.ponizil (talk) 14:15, 20 February 2023 (UTC)
  • Support Support --Rosičák (talk) 16:05, 20 February 2023 (UTC)
  • Support Support —מקף⁻ණ (Hyphen) 22:36, 20 February 2023 (UTC)
  • Support Support --Lamiot (talk) 11:04, 21 February 2023 (UTC)
  • Support Support Snowmanonahoe (talk) 13:26, 21 February 2023 (UTC)
  • Support Support DrowssapSMM (talk) 16:06, 21 February 2023 (UTC)
  • Support Support Some administrators often forget to set up a new protection after a higher level of protection has expired. 星海子 (talk) 16:17, 21 February 2023 (UTC)
  • Support Support. —— Eric Liu（Talk） 01:31, 23 February 2023 (UTC)
  • Support Support Sennecaster (talk) 02:12, 23 February 2023 (UTC)
  • Support Support আফতাবুজ্জামান (talk) 15:58, 24 February 2023 (UTC)
  • Support Support ~~~~
    User:1234qwer1234qwer4 (talk)     16:55, 24 February 2023 (UTC)

Discussion

[edit]
@Mannivu: Thanks for sharing this suggested improvement. Could you clarify the proposed solution? I think what you mean is that, when using Special:RelatedChanges for a category, you would like the option to also display changes from subcategories - is that right? One top-of-mind concern I'll just note on this is that MediaWiki categories can be circular and/or incredibly deep, so this might need to be limited to direct subcategories. Samwalton9 (WMF) (talk) 13:26, 30 January 2023 (UTC)
@Samwalton9 (WMF) yes, my idea is that I'd like to have an option that the user can activate in order to see the changes from subcategories of a given category. Maybe it could also let the user set a deep option (i.e. 2 for the direct subcategories and their subcategories). --Mannivu · ✉ 13:37, 30 January 2023 (UTC)
So far RelatedChanges does not even seem to support transclusions, which (unlike subcategories) is included in Special:WhatLinksHere. ~~~~
User:1234qwer1234qwer4 (talk) 16:57, 24 February 2023 (UTC)

Voting

[edit]
  • Support Support with an option to set levels deep to include Joshbaumgartner (talk) 21:45, 10 February 2023 (UTC)
  • Oppose Oppose some categories can be very deep and all of this is subjective to the wiki anyway. On some wikis, such as Wikivoyage, all categories essentially come back to 10 core categories, and this would just make things more confusing. --SHB2000 (talk | contribs) 22:23, 10 February 2023 (UTC)
    @SHB2000 I understand, and I know that there are such situations, that's why I proposed this as a toggle, so that the user can activate it, but it's not mandatory. --Mannivu · ✉ 08:43, 14 February 2023 (UTC)
  • Support Support CaféBuzz (talk) 09:52, 11 February 2023 (UTC)
  • Support Support With the depth limit being proposed. Some category "tree" may node back to itself. Thingofme (talk) 13:51, 11 February 2023 (UTC)
  • Support Support Heterotrofo (talk) 21:00, 11 February 2023 (UTC)
  • Support Support BeyPolite (talk) 12:03, 12 February 2023 (UTC)
  • Support Support 🌸 Sakura emad 💖 (talk) 15:21, 12 February 2023 (UTC)
  • Support Support ドラみそ (talk) 02:55, 14 February 2023 (UTC)
  • Support Support support cyrfaw (talk) 11:25, 15 February 2023 (UTC)
  • Support Support Sadads (talk) 01:07, 16 February 2023 (UTC)
  • Support Support —‍(ping on reply)—‍CX Zoom (A/अ/অ) (let's talk|contribs) 07:19, 18 February 2023 (UTC)
  • Support Support Wire723 (talk) 10:38, 18 February 2023 (UTC)
  • Oppose Oppose --Libertyguy (talk) 21:17, 18 February 2023 (UTC)
  • Support Support Bass-Kuroi (talk) 04:24, 19 February 2023 (UTC)
  • Support Support Carlotm (talk) 08:21, 19 February 2023 (UTC)
  • Support Support Blue Edits (talk) 10:18, 19 February 2023 (UTC)
  • Support Support DrowssapSMM (talk) 16:04, 21 February 2023 (UTC)
  • Support Support Morten Haan (talk) 18:05, 22 February 2023 (UTC)
  • Support Support. —— Eric Liu（Talk） 01:45, 23 February 2023 (UTC)

Utility to attach acccount to all wikis

Discussion

[edit]
  • To reduce certain abuse factors, may want to limit to a permission. — xaosflux Talk 17:09, 3 February 2023 (UTC)
    @Xaosflux Would fixing the user script be a solution? I wonder how many people really want this functionality and whether it really belongs as part of mw:Extension:CentralAuth. But if it's restricted to some permission, as you say, I suppose it's harmless to implement it directly in MediaWiki.
    Either way we will approve this proposal, but if most people are content with a working script, I imagine that can be done quite easily – likely within a day. MusikAnimal (WMF) (talk) 18:31, 3 February 2023 (UTC)
    @MusikAnimal (WMF) since this is really only for massive centralauth deployments (which practically is only the WMF cluster) - script based should still be fine (we could even gadgetize it here). We certainly didn't require a permission for a script - but was trying to not make it too easy for User:DisruptiveUsername to show up on hundreds of account creation logs at once. — xaosflux Talk 18:37, 3 February 2023 (UTC)
    Got it! I will accept this proposal as-is, then, but I imagine a script is what we'll actually do. This wish may or may not be granted before the survey even finishes :) MusikAnimal (WMF) (talk) 20:47, 3 February 2023 (UTC)
    Possible patch to old userscript listed at User_talk:Krinkle/Tools#running_Global_SUL.js_does_not_create_local_accounts by User:Suffusion of Yellow. — xaosflux Talk 01:56, 6 February 2023 (UTC)
    Path appears to work. — xaosflux Talk 17:43, 9 February 2023 (UTC)
    The patch has been applied to the original script which fulfills this wish before voting is even complete. --BDavis (WMF) (talk) 21:36, 10 February 2023 (UTC)
  • I don't get the point of this proposal. What would it actually improve? It would make the local account autocreation log entirely useless (granted I'm not sure how useful it is now), in exchange you'd have accounts on wikis you have never visited... what for? --Tgr (talk) 05:48, 6 February 2023 (UTC)
    @Tgr, may be helpful for local searching by others users perhaps, for receiving a message by mail or at own talk page locally. Also the user will have the ability to be notified.
    @MusikAnimal (WMF): I wonder what will be the underlying IP of accounts created. There may have privacy concerns. If the IP is owned by the account owner, they will leave too many tracks, and they will be able to be checked everywhere, which is good and bad at same time. If that’s someone else’s IP, that can be confusing. Just thought about it. —Teles «Talk ˱C L @ S˲» 16:20, 9 February 2023 (UTC)
    @Teles Today, script-wise, it is the enduser ip; the same as if they just visit a new project SUL logs them in. — xaosflux Talk 11:05, 12 February 2023 (UTC)
    @Xaosflux, got it. Tks. —Teles «Talk ˱C L @ S˲» 16:08, 13 February 2023 (UTC)
  • maybe... but why doe still have local accounts ? Maybe its time to get rid of that instead ? one step closer now that actor migration is so much further along. —TheDJ (talk • contribs) 14:13, 18 February 2023 (UTC)
    Might want to add the script as a gadget here on Meta (restricting to autopatrolled or similar would probably be sensible) but I don't think this needs a native implementation. ~~~~
    User:1234qwer1234qwer4 (talk)     17:02, 24 February 2023 (UTC)
  • @Xaosflux: I've marked this as Done by Suffusion of Yellow, given that Krinkle's user script now works — does that sound okay? — TheresNoTime (talk • they/them) 19:49, 14 March 2023 (UTC)
    I'd think so, unless someone really wants to write a path to SUL for this! — xaosflux Talk 21:14, 14 March 2023 (UTC)

Voting

[edit]

Enable removing block log entries entirely, not just redacting

Discussion

[edit]
  • @WikiFer: It is already possible to hide the block log entries, just as with any log entry or revision. If you want it hidden from other admins, too, suppression can be used. Is that not satisfactory? MusikAnimal (WMF) (talk) 02:19, 6 February 2023 (UTC)
    @MusikAnimal (WMF) Help:RevisionDelete only hides information in the text, summary of edits and account name or IP. The lockout log is not deleted if there is an administrator error in applying the lockout. WikiFer msg 04:11, 6 February 2023 (UTC)
    @WikiFer Using my sysop account, if I go to Special:Log/block, I see checkboxes next to each log entry and a "Change visibility of selected log entries" button. Is this not doing what you want? Apologies if I'm still missing something! I know RevisionDelete is a bad name, because in this case it's not actually a revision that we're deleting. MusikAnimal (WMF) (talk) 04:18, 6 February 2023 (UTC)
    @MusikAnimal (WMF) You are right. Now I realized that this option really exists. I'm sysop on ptwiki, but I've never used the possibility of hiding a blocking log. WikiFer msg 04:46, 6 February 2023 (UTC)

Comment Comment Although it is possible to hide the blocking log, the suppression policy of each local community may not allow this use to hide a blocking considered incorrect. That's why I created this proposal, so that there would be no link with the suppressors. WikiFer msg 04:56, 6 February 2023 (UTC)

@WikiFer If I'm understanding you correctly, are you proposing a mechanism by which the community could collectively remove the log entry without requiring an admin/suppressor to be the one to enact the consensus? Samwalton9 (WMF) (talk) 10:42, 6 February 2023 (UTC)
@Samwalton9 (WMF) The admin will still be responsible for clearing the lock log, but it wouldn't be considered a hide in the way suppressors use it. The consensus for applying this removal would be by consensus among local administrators. WikiFer msg 11:34, 6 February 2023 (UTC)
@WikiFer I'm not sure I understand your proposal and how it's different from what is currently possible - could you elaborate on what the difference is? Samwalton9 (WMF) (talk) 12:49, 6 February 2023 (UTC)
@Samwalton9 (WMF) See this example here, it has the block log where a user was unblocked because another administrator objected to the block. My proposal is to remove this block log of user, leaving the his account without any blocking records. If it was unlocked because the lock was incorrect, it shouldn't be part of this history. WikiFer msg 13:03, 6 February 2023 (UTC)
@WikiFer Here you can see a test I just did where I removed blocks from the logs for my test account. Are you suggesting that the software should enable you to remove those log entries entirely, rather than have "removed" text in the log? Samwalton9 (WMF) (talk) 13:35, 6 February 2023 (UTC)
@Samwalton9 (WMF) Exactly. The proposal is for the software to remove log entries of locks that the local community has deemed to be incorrect. In the example you showed, the lock configuration change is another log. The proposal is not to remove only text, but not to appear in the account history anymore. WikiFer msg 13:56, 6 February 2023 (UTC)
@Samwalton9 (WMF) Another better example was this administrative war of blocking and unblocking this account only on December 30, 2020 on Portuguese Wikipedia. My proposal is to leave this entire history blank, as if there were no blocks. WikiFer msg 14:00, 6 February 2023 (UTC)
@WikiFer Gotcha. I've updated the proposal title to clarify this. Samwalton9 (WMF) (talk) 14:50, 6 February 2023 (UTC)
@Samwalton9 (WMF) @WikiFer Note that if you use RevDel (aka redaction) on all fields, the entry is completely hidden from the log. Only users who have the ability to change the visibility of the log entry will be able to see it, and they will see it as "([field] removed)". In this case that is only admins, but you can use suppression to hide it from them, too. Are we sure that doesn't satisfy the wish?
I don't think full proper deletion from the database is something that would be considered. We could add yet another layer of visibility, as in something above suppression, but is there really any point in doing that? MusikAnimal (WMF) (talk) 16:49, 6 February 2023 (UTC)
@MusikAnimal (WMF) In this example, it would be unfair for a person to have a history of having their account blocked due to an administrative war. I think that in situations like this, deleting database locks would resolve unfairness. WikiFer msg 16:58, 6 February 2023 (UTC)
@WikiFer "Deleting" isn't really a thing. I see now above you said you wanted something that worked without the assistance of suppression, but I still have the same concerns. We need a log of everything that happens. Anything done by an admin should be auitable by another admin. If we want it hidden from admins, use suppression. In your example, if you use RevisionDelete, the log entries are only visible to 49 users (and those users will see it as "hidden" and have to click through to see what actually happened). To everyone else (non-admins), they won't see the log entries at all. If suppression is used, it brings down the visibility to just three users, who again will see them as "hidden" and have to click through if they want more information. MusikAnimal (WMF) (talk) 17:02, 6 February 2023 (UTC)
@MusikAnimal (WMF) Oh, huh. I swear I tested looking at the Samwalton9Testing block log from a non-admin account and could still see the deleted logs, but now I'm looking again I don't see them, so maybe it was an account cache issue. I agree that there's not much else to be done if that's the current behaviour. Samwalton9 (WMF) (talk) 17:29, 6 February 2023 (UTC)
I'd like to hear confirmation from @WikiFer first, but I'm thinking this proposal could be archived as there are existing solutions. I'm unclear on why we would need the ability for admins to completely hide block log entries from other admins. Those other admins will see "[field] removed", and if they use the "Change visibility" link or check the deletion log, they will see the rationale which for this use case would say something like "accidental block". That is by design. All actions in MediaWiki are intended to be audited. Imagine a rogue admin who remove visibility of the blocks they made, and also the log entries of them changing the visibility.
As I said suppression can be used to hide the entries from admins, too, but I don't see the point as admins can already confirm the blocks are invalid. MusikAnimal (WMF) (talk) 18:57, 6 February 2023 (UTC)
@MusikAnimal (WMF) As I already opened the proposal, the ideal thing is for the community to manifest itself in a vote, since the tool for hiding administrators is just another blocking log, a new administrative action that can only be used if the username is incorrect, or the edit summary violates the local hiding policy. I believe that wrongs blocks should be removed from an account's history, and admins will be able to set this by consensus on each project. WikiFer msg 19:16, 6 February 2023 (UTC)
My point is that what you're proposing is already possible. I don't think anything new needs to be engineered. But, the proposal is actually already approved, so as it stands now it's going to voting. MusikAnimal (WMF) (talk) 17:22, 7 February 2023 (UTC)

I come to this discussion from a situation where this was an issue. I opposed because I agree that, as framed, leaving it solely to administrative discretion is too open a door to abuse.

But ... certainly someone who gets mistakenly blocked for a few hours after, say, 15 years of productive, block-free editing might be entitled to ask for this sort of expungement, which could be granted through community consensus and only a limited number of users (i.e., the OS team, maybe) could actually do it.

Maybe we'll consider that proposal next year. Daniel Case (talk) 02:37, 12 February 2023 (UTC)

I am that soldier! (Hi Daniel!) Yes, I would like my 15-year clean block log record back, please! Note also the provisions of the EU's General Data Protection Regulations. Included in the seven principles of GDPR are two that are very relevant: a) the requirement for accuracy (and the consequent right to have incorrect information amended or deleted!); and b) the principle of accountability (which means that Data Controllers need to ensure that they not only comply with the principles, but also have appropriate processes and records in place to demonstrate compliance.) Other jurisdictions have similar laws in place. Now, it may well be the case that RevDel meets those criteria (as only other delegated Data Controllers can see the logs), but the proposal should not be dismmised out of hand. Bastun (talk) 11:09, 13 February 2023 (UTC)

Voting

[edit]
  • Oppose Oppose. A later unblock should be sufficient. However, there should be possible to add a tag to the block log to mark the block as "done in error". --Ciencia Al Poder (talk) 18:29, 10 February 2023 (UTC)
  • Oppose Oppose. You can look this. In my opinion unblock is enough. This "feature" would encourage administrators to hide their own mistakes, which would be not good. Everything what admin does, including mistakes, must be public as much as possible. Taivo (talk) 20:02, 10 February 2023 (UTC)
  • Oppose Oppose this creates a system open to abuse. Especially on some wikis (such as kawiki), this feature could be abused just so admins can hide the fact that they've been misusing their tools to block good-faith users for some time. --SHB2000 (talk | contribs) 22:17, 10 February 2023 (UTC)
  • Oppose Oppose this can go entirely unchecked. I have been involved in assisting administrators on the English Wikipedia with continuing to report long-term abusers. Doing this will give the long-term abusers an upper-hand. - TheLionHasSeen (talk) 22:41, 10 February 2023 (UTC)
  • Oppose Oppose suppression should be enough here. Outright removal removes accountability. Dreamy Jazz talk to me | enwiki 02:37, 11 February 2023 (UTC)
  • Oppose Oppose The stated problem is a deliberate social construct of the community, not a technical issue in need of solving. * Pppery * it has begun 03:35, 11 February 2023 (UTC)
  • Oppose Oppose Per above. Spencer (talk) 04:36, 11 February 2023 (UTC)
  • Oppose Oppose We are supposed to be held to a high standard. (That doesn't always happen). Admins even more so. You wouldn't want something covered up at work for example. So why is here any different? There needs to be accountability and transparency. What you have proposed would remove that and allow some admins to abuse it. Those that do abuse it shouldn't be an admin to be begin with. Good thing the proposer is not an admin (if they're not) because I could see them doing this. Mr. C.C.Hey yo!I didn't do it! 09:09, 11 February 2023 (UTC)
    @Fishhead2100 I'm an admin, but the proposal doesn't for me, but to users who are blocked unfairly and have their blocking record tarnished by the incompetence of wrong blocks by other administrators. WikiFer msg 14:51, 11 February 2023 (UTC)
  • Oppose Oppose This is unnecessary, the unblock log is the right place to point this out, if there has been a conflict or a debate between sysops, or mistake by the initial blocker, there is no good reason why this should not be visible in the log. CaféBuzz (talk) 09:51, 11 February 2023 (UTC)
  • Oppose Oppose SunDawn (talk) 12:37, 11 February 2023 (UTC)
  • Oppose Oppose don't hide errors, but maybe mark them Lupe (talk) 13:28, 11 February 2023 (UTC)
  • Oppose Oppose due to transparency issues. Thingofme (talk) 13:55, 11 February 2023 (UTC)
  • Oppose Oppose but only as an action an admin may take on their own. If the tool were, say, only part of the oversighter user right, and required consensus to implement, I think there would be more supports. See my comments above. Daniel Case (talk) 02:33, 12 February 2023 (UTC)
  • Support Support A clean block log is a great value for a user, and accidental or bad faith blocks may spoil it. Bináris tell me 10:46, 12 February 2023 (UTC)
  • Support Support As someone who had a 15-year clean block log tarnished due to an admin's mistake, I support this, Bastun (talk) 11:11, 13 February 2023 (UTC)
  • Oppose Oppose --cyrfaw (talk) 11:32, 15 February 2023 (UTC)
  • Support Support A clean block log is a great value for a user, and bad faith blocks spoil it. .... 0mtwb9gd5wx (talk) 04:13, 16 February 2023 (UTC)
  • Support Support Per Bináris and Bastun, I support this but it should be restricted to stewards, almost like bigdeletes. Just to be clear, I only support it if only stewards could do remove block entries, and the blocks were accidental, like https://en.wikipedia.org/w/index.php?title=Special:Log/block&page=User%3AFerien -- Ferien (talk) 20:11, 17 February 2023 (UTC)
  • Oppose Oppose per above. —‍(ping on reply)—‍CX Zoom (A/अ/অ) (let's talk|contribs) 07:33, 18 February 2023 (UTC)
  • Oppose Oppose. See voy:Wikivoyage_talk:Deny_recognition#How_far_should_hiding_go. Pashley (talk) 13:45, 18 February 2023 (UTC)
  • Oppose Oppose --Libertyguy (talk) 21:25, 18 February 2023 (UTC)
  • Oppose Oppose Carlotm (talk) 08:49, 19 February 2023 (UTC)
  • Support Support iff this is only part of oversighter rights. Else, neutral. Alfa-ketosav (talk) 14:02, 19 February 2023 (UTC)
  • Oppose Oppose hiding blocks will not fix anything ANewPreson (talk) 12:41, 21 February 2023 (UTC)
  • Oppose Oppose This is unnecessary, we can use revisiondelete instead. 星海子 (talk) 16:09, 21 February 2023 (UTC)
  • Oppose Oppose on philosophical grounds--MediaWiki loves to save literally everything, why should there be an exception to this? Snowmanonahoe (talk) 12:44, 23 February 2023 (UTC)
  • Oppose Oppose per Taivo, I don't see how [e]veryone would benefit. Accidental blocks aren't a big deal. ~~~~
    User:1234qwer1234qwer4 (talk)     17:06, 24 February 2023 (UTC)

Display a notice on newly created articles

Discussion

[edit]
  • @Owee mªthias: the only time limits about new page creation are in large values (weeks+) and have to do with indexing. I think what you are talking about is a process that people are doing on a project, and not something that will be resolved with a technology change - correct? — xaosflux Talk 01:52, 30 January 2023 (UTC)
  • There might be some possibilty to add {{in use}} or equivalent - many users don't know that this possibility exists. But this can be misused by spammers. JAn Dudík (talk) 08:01, 31 January 2023 (UTC)
    • @JAn Duík: That template is for major edits to an existing article. It's not for an article created five minutes ago. That's what sandboxes and drafts are for. One would think you would have known that. I guess not. Mr. C.C.Hey yo!I didn't do it! 09:18, 11 February 2023 (UTC)
  • @Owee mªthias: As noted by Xaosflux above - this seems to be a suggestion for a community process, rather than a technical change. Is there a specific change you would like to see to MediaWiki software to enforce this limit in some way? Samwalton9 (WMF) (talk) 11:11, 2 February 2023 (UTC)
  • I guess the way this could be helped technically would be a feature so that any new article could automatically have some "Created in the last hour" or "New article" notice that would inform readers and patrollers alike with users having to tag and de-tag. Option to set duration and configure message/format would be required. KylieTastic (talk) 11:15, 2 February 2023 (UTC)
    yes,it's more like that what i thaught Owee mªthias (talk) 12:09, 2 February 2023 (UTC)
    @Owee mªthias Could you update the wish description fields above to clarify this? It's the section that will be translated so it will be helpful to clarify there so that voters understand what they're voting on. Samwalton9 (WMF) (talk) 09:22, 3 February 2023 (UTC)
    I've updated the description per the above. Samwalton9 (WMF) (talk) 10:38, 6 February 2023 (UTC)
  • Meanwhile, the way to do it is to work on an early-stage article in your user space or in draftspace rather than create an article in mainspace. For example, your draft fr:Trash(Youtube) was moved to fr:Utilisateur:Owee mªthias/Brouillon where you have more time to work on it. Fayenatic london (talk) 14:36, 2 February 2023 (UTC)
  • Comment Comment Draft namespace is only in some wikis. Sandbox is one of solutions, but sometimes user need to work in main namespace because of wikidata connection. But this is probably not problem of newbies, their problem is not knowing about {{inuse}}. JAn Dudík (talk) 10:05, 13 February 2023 (UTC)
  • If you're talking about articles in Wikipedia, there is already a template called Under Construction that can notify any readers to not edit the page in order to avoid edit conflicts. Tutwakhamoe (talk) 20:01, 20 February 2023 (UTC)

Voting

[edit]
  • Oppose Oppose Seems to be a Wikipedia-only problem; the deletion processes of each individual wiki should be handled locally. --SHB2000 (talk | contribs) 22:19, 10 February 2023 (UTC)
  • Support Support Tgr (talk) 01:46, 11 February 2023 (UTC)
  • Oppose Oppose Templates exist for this purpose. 5225C (talk • contributions) 02:53, 11 February 2023 (UTC)
  • Oppose Oppose This is yet another proposal that is trying to solve a fundamentally social problem through technical means. That won't work. * Pppery * it has begun 03:38, 11 February 2023 (UTC)
  • Oppose Oppose the {{inuse}} template satisfies this need. Article deletion can be contested in case a genuine article is deleted by speedy deletion and/or community consensus is enough to decide the fate of the article if it reaches the AfD venue. Raydann (talk) 05:29, 11 February 2023 (UTC)
    @Raydann: That template is for major edits to an existing article. It's not for an article created five minutes ago. That's what sandboxes and drafts are for. One would think you would have known that. I guess not. Mr. C.C.Hey yo!I didn't do it! 07:35, 11 February 2023 (UTC)
    Learning from the best. Raydann (talk) 02:04, 19 February 2023 (UTC)
  • Oppose Oppose - likely unnecessary. New articles should in theory be no less unreliable than old articles. If there is a problem, or if it is still under construction, local wikis have ways to manage these. Anarchyte (talk) 06:57, 11 February 2023 (UTC)
@Anrchyte: Yeah, it's called sandboxes and drafts. Mr. C.C.Hey yo!I didn't do it! 07:37, 11 February 2023 (UTC)
  • Oppose Oppose --Jim Hokins (talk) 08:01, 11 February 2023 (UTC)
  • Oppose Oppose Using sandboxes and drafts solve this issue as they are there for the proposed solution. (Drafts will be deleted after a certain period of inactivity, so best to use your sandbox until ready). Mr. C.C.Hey yo!I didn't do it! 09:14, 11 February 2023 (UTC)
  • Oppose Oppose CaféBuzz (talk) 09:48, 11 February 2023 (UTC)
  • Oppose Oppose SunDawn (talk) 12:36, 11 February 2023 (UTC)
  • Oppose Oppose Lupe (talk) 13:32, 11 February 2023 (UTC)
  • Oppose Oppose There are resolutions to the problem like Draft namespace and user sandboxes. Thingofme (talk) 13:56, 11 February 2023 (UTC)
  • Support Support One of the best ideas. Heterotrofo (talk) 21:01, 11 February 2023 (UTC)
  • Oppose Oppose I don't think it's necessary, but if a community does decide it is this is a policy issue that can be addressed locally by creating a template that attaches to any article created by a user with >n edits. Daniel Case (talk) 02:54, 12 February 2023 (UTC)
  • Oppose Oppose verweis=User_talk:Flossenträger 06:43, 13 February 2023 (UTC) already established solutions available
  • Support Support Leo067 (talk) 08:39, 13 February 2023 (UTC)
  • Support Support I had the same problem, made my first article and Admin rushed to delete it, lost 50' of work because of "edit conflict". Also, "sandboxes" and "drafts" are the solution only if you accept to further complicate the article creation: for me it is better to have one stub more than no article at all. FranzXYZ (talk) 08:44, 13 February 2023 (UTC)
  • Oppose Oppose --cyrfaw (talk) 11:25, 15 February 2023 (UTC)
  • Support Support ~Cybularny Speak? 13:30, 15 February 2023 (UTC)
  • Oppose Oppose It would support SPAM edits in order to have the page indexed on Google and other search engines. Ruthven (msg) 15:29, 15 February 2023 (UTC)
  • Oppose Oppose No, sandboxes are enough. --——d—n—f (fr.-sysop) (talk) 08:00, 16 February 2023 (UTC)
  • Support Support A person with less notability should also get a chance to list on Wikipedia. Stardustnite (talk) 08:44, 17 February 2023 (UTC)
  • Support Support This would be a good thing. Kalesh (talk) 09:00, 17 February 2023 (UTC)
  • Oppose Oppose Bilykralik16 (talk) 01:53, 18 February 2023 (UTC)
  • Support Support I think this is a great idea. Especially for the fact that I use RTRC in viewing recent edits, I have to open a page history to verify whether it is newly created or not. I therefore support if the fact that I can see newly created articles right before I even open the page. I support this proposal Uncle Bash007 (talk) 04:16, 18 February 2023 (UTC)
    You might want to use mw:XTools/ArticleInfo.js, which shows the age and creation date of a page below its title. ~~~~
    User:1234qwer1234qwer4 (talk)     16:49, 24 February 2023 (UTC)
  • Oppose Oppose --FoBe (talk) 14:18, 18 February 2023 (UTC)
  • Support Support First time readers should no about the article if it is recently created

    Homolego (talk) 15:27, 18 February 2023 (UTC)

  • Oppose Oppose: this seems like feature creep. There are technical solutions like templates (en:Template:In use), user sandboxes, and draft namespaces. There are also policy/guideline solutions such as adding guidance to admins and patrollers about time to deletion. For example, in English Wikipedia, new page reviewers wait for some time before nominating a new article for deletion, unless it's blatant vandalism or spam. MarioGom (talk) 18:23, 18 February 2023 (UTC)
  • Support Support Libertyguy (talk) 21:27, 18 February 2023 (UTC)
  • Support Support Captain Almighty Nutz (talk) 01:57, 19 February 2023 (UTC)
  • Support Support Bass-Kuroi (talk) 04:03, 19 February 2023 (UTC)
  • Support Support Packerfan386 (talk) 09:39, 19 February 2023 (UTC)
  • Oppose Oppose This is wiki-specific, intrudes on policy rather than being a purely technical feature, and half the supports on here don't list valid reasoning (what on earth does "A person with less notability should also get a chance to list on Wikipedia." have to do with this?) Blue Edits (talk) 10:20, 19 February 2023 (UTC)
  • Support Support 我支持此提案。 --维基佛祖 (talk) 23:23, 20 February 2023 (UTC)
  • Support Support --Serieminou (talk) 22:23, 21 February 2023 (UTC)
  • Support Support -- I really think that this is a very good idea. --  Manjiro91💬 12:09, 23 February 2023 (UTC)
  • Oppose Oppose per Pppery. ~~~~
    User:1234qwer1234qwer4 (talk)     16:48, 24 February 2023 (UTC)

Allow viewing of edit filter logs for IP ranges

Discussion

[edit]

Currently, it is possible to search for ranges only on Special:Contributions. There are even more views that would benefit from such a feature: Special:Log (phab:T146628, phab:T188690), Special:DeletedContributions, Special:AbuseFilter/test (phab:T257420). Maybe a way to make it work for any similar view could also be made.
Yet, there is the ongoing IP masking initiative that will probably soon change patterns of anti-vandalism efforts regarding IP's. --Matěj Suchánek (talk) 16:44, 4 February 2023 (UTC)

Admins will, I understand, still have the ability to see IPs. And won't they be assigned unique on-wiki identifiers à la vanished users? They could still be searched that way by patrolling users? Daniel Case (talk) 03:21, 5 February 2023 (UTC)
I think they will. But I'm not sure either what queries will be possible (reformulating your second question). --Matěj Suchánek (talk) 13:54, 5 February 2023 (UTC)

Voting

[edit]

Add block option to hide or suppress username from logs

Discussion

[edit]

This is more of an "anti-harassment" item, so maybe it belongs there, but yes I'm for it all the same. Daniel Case (talk) 23:20, 29 January 2023 (UTC)

@WikiBayer: Thanks for this proposal. It might be helpful to elaborate in the "Who would benefit" section on the proposed benefits. It seems like there are potential benefits both for sysops (time savings) and for other users (not seeing bad usernames in logs). This will help other editors understand why they might want to vote for this! Samwalton9 (WMF) (talk) 13:51, 30 January 2023 (UTC)
  • To be clear, there is an option to hide usernames from logs. The linked task is about making that option available to admins (and not just oversighters). (Also, admins can already hide usernames from logs on a one-by-one basis via RevDel, but that can be quite cumbersome. Also also, the existing option is for SUL users; it might make sense to support such functionality locally, and to avoid dependency on the CentralAuth extension.) --Tgr (talk) 02:09, 1 February 2023 (UTC)
Are we talking about abusive/swearing/toxic login names? Wakelamp (talk) 13:20, 11 February 2023 (UTC)
  • Local oversighters already have a checkbox in Special:Block (added by having the hideuser right) to suppress the username from lists and logs upon blocking. Is this is to have a similar function for admins, as per the Phabricator ticket? —MarcoAurelio (talk) 10:29, 12 February 2023 (UTC)
    Yes. There should be a similar function as the one for oversighter for admins. 𝐖𝐢𝐤𝐢𝐁𝐚𝐲𝐞𝐫 👤💬 10:37, 12 February 2023 (UTC)
  • I'm not really seeing the use case for administrators to have this. Some further explanation would be helpful. Risker (talk) 03:22, 21 February 2023 (UTC)

Voting

[edit]

Allow grouping of blocks and protections

Discussion

[edit]
There's already en:User:1234qwer1234qwer4/mass-tools.js for this exact reason, but a WMF remake would be good to see as a part of vanilla WP tools.--A09 (talk) 22:21, 1 February 2023 (UTC)

Voting

[edit]

Attribution repair mechanism

Discussion

[edit]
  • For what is worth, English Wikipedia handles translation attributions with a template in the talk page: w:Template:Translated page, which can be added at any time, and usually includes links to exact revisions. MarioGom (talk) 15:44, 29 January 2023 (UTC)
    English wikipedia en:Wikipedia:Copying within Wikipedia declares that editor must provide either a list of authors or a hyperlink to the page in edit summary. Templates on the talk page add supplementary information. They don't provide legal mechanism for alternative attribution. D6194c-1cc (talk) 10:17, 30 January 2023 (UTC)
    Terms of Use in the paragraph 7b say: "Through hyperlink (where possible) or URL to the article to which you contributed (since each article has a history page that lists all authors and editors)" (m:Terms of Use/en). So our terms of use expect that information about all the authors will be available in the edit history. Talk page isn't related to the edit history nor to information about authors.
    Also paragraph 7c say: "You agree that, if you import text under a CC BY-SA license that requires attribution, you must credit the author(s) in a reasonable fashion. Where such credit is commonly given through page histories (such as Wikimedia-internal copying), it is sufficient to give attribution in the edit summary, which is recorded in the page history, when importing the text" (m:Terms of Use/en).
    So technically text copied from other page without attribution in edit summary is plagiarism (see en:Wikipedia:Plagiarism). Dummy edit helps to fix it, but they are useless in decades-long histories. D6194c-1cc (talk) 10:17, 30 January 2023 (UTC)
    Obviously it is an accepted practice that, in the absence of full attribution in edit summaries, templates in talk pages serve the same purpose. That template, indeed, contains cross-wiki links to exact revisions and history, which lists all authors and editors. Terms of use say that page histories are "commonly" used, not that they are the only way to do it. So far, I don't think there's a serious challenge to the idea that clear attribution in talk pages is crediting the authors in a reasonable fashion. If you really think that's not the case, this is probably a problem for WMF Legal team to clarify before jumping to implement any feature based on your interpretation. MarioGom (talk) 21:44, 31 January 2023 (UTC)
    In my understanding "commonly" means that attribution can be made in the face of the article as it is common with external CC BY-SA texts added to Wikipedia articles: en:Template:CCBYSASource. D6194c-1cc (talk) 14:26, 1 February 2023 (UTC)
  • Because this wish relates to legal concerns with the Wikimedia Terms of Use, I checked in with the Wikimedia Foundation Legal team to clarify whether this is a pressing concern. They said it's probably not a required change under the ToU, and the risk is pretty low and will be even lower when we move to CC 4.0 soon. @D6194c-1cc: Are there other potential benefits to making this change? If so I would recommend rewording the wish to focus around those, rather than legal concerns. Samwalton9 (WMF) (talk) 13:51, 1 February 2023 (UTC)
    Do you mean CC BY-SA 4.0 or CC 4.0 without BY-SA? Current Wikipedia authors licensed their texts under BY-SA, so its impossible to change the license of previously added content to a license without attribution. D6194c-1cc (talk) 15:37, 1 February 2023 (UTC)
    @D6194c-1cc CC BY-SA 4.0 - when I wrote CC 4.0 it was (confusing) shorthand. Samwalton9 (WMF) (talk) 16:03, 1 February 2023 (UTC)
    I have only legal concerns, so I'll leave it as is. I try to find best way to fix attribution of translations made long time ago. Currently I use something like this: ru:special:diff/128107741. D6194c-1cc (talk) 19:27, 1 February 2023 (UTC)
    @D6194c-1cc Because this change isn't required according to the WMF Legal team, I'm going to archive this wish. Thanks for making the suggestion and prompting us to look into this though! Samwalton9 (WMF) (talk) 11:08, 2 February 2023 (UTC)
    Because the wish has been updated to focus on other potential benefits I've unarchived it. Samwalton9 (WMF) (talk) 16:56, 3 February 2023 (UTC)
  • @D6194c-1cc Admin can add tags to revisions. Tags like credited later on 1st revision and credited here on crediting revision can solve this lack of order, that's compatible with license terms. On fr-wiki, we also use templates in references header to credit authors (see fr:Aide:Crédit d'auteurs => fr:Modèle:Crédit d'auteurs). Hope it helps ru-wiki. --LD (talk) 03:49, 11 February 2023 (UTC)
    @LD Thanks for the reply. But when the user contributes to the Wikipedia, he adds a piece of text so that anyone who re-uses article text under the CC BY-SA license needs to know what changes were made to every piece of text. Article's history is responsible not only for authorship, but also for information about modification of every added piece of text.
    I started using this translated template to mark articles with insufficient attribution: :en:Template:Copying within Wikipedia. This template has the same purposes as fr:Modèle:Crédit d'auteurs, but I think it's more appropriate and calls to fix attribution. D6194c-1cc (talk) 13:33, 11 February 2023 (UTC)
  • This is a tangent, but the concern I have is: Alice translates an article written by Bob at xxwiki. Carol deletes Bob's article from xxwiki. Now Alice's translation has a link to a page that no longer exists. It would be nice if Carol/xxwiki were aware that Alice had translated the article, so they could preserve the article history. WhatamIdoing (talk) 20:08, 11 February 2023 (UTC)

Voting

[edit]
  • Oppose Oppose This seems like a lot of effort spent on a relatively minor thing. If admins want to annotate the history in this way, they can just use the already-existing import feature instead. * Pppery * it has begun 03:39, 11 February 2023 (UTC)
  • Neutral Neutral This thing is useful when editing the edit summary or import feature rather than making a dummy edit, but otherwise it is not useful. Thingofme (talk) 13:50, 11 February 2023 (UTC)
  • Support Support Bluerasberry (talk) 15:03, 11 February 2023 (UTC)
  • Support Support a better way of fixing attribution problems and edit summary errors. · · · Peter (Southwood) (talk): 16:28, 13 February 2023 (UTC)
  • Support Support cyrfaw (talk) 11:27, 15 February 2023 (UTC)
  • Support Support Ppt91 (talk) 19:08, 17 February 2023 (UTC)
  • Support Support 3mi1y (talk) 08:33, 18 February 2023 (UTC)
  • Support Support Alfa-ketosav (talk) 12:40, 19 February 2023 (UTC)
  • Support Support. In addition, in my opinion it could be used for any additional need for linking between edits, not just for providing attribution. —מקף⁻ණ (Hyphen) 22:47, 20 February 2023 (UTC)

Discussion

[edit]

Having to spend a lot of time referring registered users caught in proxy blocks to IPECPROXY so they may request IPBE, I am in favor of any option that would reduce that caseload. Daniel Case (talk) 23:18, 29 January 2023 (UTC)

SHB2000: Sure. Users can clean cookies. They can change browser. They can use incognito mode. None of these solves the problem, which is that many users are encountering confusing blocks about IPs they are not currently using, and they end up at various venues for support, like VRT. MarioGom (talk) 18:29, 18 February 2023 (UTC)

Voting

[edit]

Option to filter bots from the block log

Discussion

[edit]
Question Question: @Iniquity: to be clear, you don't want to "clear" as in erase/remove these from the log - just have a way to filter them (such as you can filter bot edits on watchlists) correct? — xaosflux Talk 15:01, 26 January 2023 (UTC)
Yep, thanks, you are right! I want to filter them. Iniquity (talk) 15:05, 26 January 2023 (UTC)
I have renamed your proposal to reflect this. I hope that is OK. DWalden (WMF) (talk) 13:49, 27 January 2023 (UTC)
Thanks :) Iniquity (talk) 15:38, 27 January 2023 (UTC)
  • Bot edits should not be seen in the standard log, just like Recent changes. Thingofme (talk) 03:17, 28 January 2023 (UTC)
  • Special:Logs includes a Tag filter which can be inverted. It should be possible to tag bot log actions with an edit filter, so we could theoretically implement a version of this proposal today. -FASTILY 10:25, 28 January 2023 (UTC)
    What Fastily said. Bots making these blocks can be filtered out today if we make a tag for it and then use the existing facilities. I think that'd be a great idea to change the existing bot(s), which CommTech could assist with if necessary. Izno (talk) 06:53, 13 February 2023 (UTC)
  • Here we have 4903 QBA-bot out of 5000. At least this bot must be filtered! These 5000 entries only cover 1 hour of time.--Jaguar K (talk) 22:09, 23 February 2023 (UTC)

Voting

[edit]

Inline diffs and inline patrol

2024 update

[edit]
Inline diffs and patrol (2024)

The proposed feature now exists as a single user script that works on all wikis: m:User:Ponor/inline-diff-inline-patrol. It could use some help from WMF teams for better/easier button positioning, "group results by page" RC feature, etc. ponor (talk) 15:25, 14 June 2024 (UTC)

Discussion

[edit]
  • What if the diff is 100 lines long ? How would we handle that ? And how would this behave on mobile ? —TheDJ (talk • contribs) 19:37, 23 January 2023 (UTC)
    @TheDJ, the majority of diffs are short. I've used the two scripts to patrol thousands of edits, and had no issues with very long diffs either. It's as painful as checking the diff on a separate page: if it's too long, it's too long. The [show diff] button could ask for a second press if diffsize (example) is above some threshold. Every diff is downloaded on demand, and can be easily closed because the change entry and the corresponding [show diff] button do not shift relative to the viewport.
    No issues for me on mobile. I don't use my phone to patrol en masse, but the buttons come in handy for some users and some edits. Jdlrobson suggests using in lineinline, as opposed to side-by-side diffs on mobile (phab:T327566), that'd be cool if supported by MW API.ponor (talk) 21:09, 23 January 2023 (UTC)
    However, there are some problems resulting from the diff is too large, such as harder to load (some vandals insert a lot of content in one edit). Thingofme (talk) 01:50, 24 January 2023 (UTC)
    I use my own version of this type of script and it has built-in "jump to bottom/top" buttons ;) Nardog (talk) 19:23, 24 January 2023 (UTC)
    FWIW some Fandom wikis use QuickDiff, which arguably has slicker UI than the popular inline diff scripts on Wikipedia. Nardog (talk) 07:25, 27 January 2023 (UTC)
    See User:NguoiDungKhongDinhDanh/QuickDiff. He has deployed the tool onto Wikimedia. Thingofme (talk) 03:10, 28 January 2023 (UTC)
    I did think of using modal windows myself, and QuickDiff may indeed *look* slicker, but it introduces more complexity and actually slows down some common patroller workflows (I'm talking about 1000–2000 manually patrolled changes a month here!): 1) a user makes 10 small overlapping changes, you check their joint diff on Page history and quickly click one by one as patrolled using inline [patrol] buttons; with modal windows you'd need to open and close 10 windows; 2) when global (semi)-bots rename images, you also want to patrol quickly without checking the diffs; 3) it's sometimes convenient to see a few consecutive diffs at the same time, to check "where the user is going", and quickly patrol them; with modal windows you can view one diff at a time (...) All in all, I still prefer simple, efficient and quick over slick. The note at the bottom of NguoiDungKhongDinhDanh's page also tells you why we need some support from CommTech here: our hacks sometimes just don't play well together. ponor (talk) 09:19, 28 January 2023 (UTC)
    In Fandom, we have aggregative changes over one page by multiple users in Recent Changes, but in Wikimedia does not have this feature. Thingofme (talk) 13:57, 28 January 2023 (UTC)
    Actually, QuickDiff do allow you to navigate between consecutive diffs by using arrow keys. However, you're right: continuously opening and closing a window doesn't seem so nice. For inline patrolling, we have this Wikidata gadget which works quite well. NguoiDungKhongDinhDanh 09:15, 11 February 2023 (UTC)
    QuickDiff cannot patrol edits like this (QuickDiff was copied from Fandom script). Thingofme (talk) 13:34, 11 February 2023 (UTC)
  • Given the proposer, and supposedly other users, seem to be content with the existing tools, I feel like this should be developed bottom-up (by community), not top-down (by WMF). Not something I want to see CommTech's limited resources spent on. Nardog (talk) 19:23, 24 January 2023 (UTC)
    @Nardog, I never said I was satisfied. The scripts work (hackishly) on some wikis, for some users, on some pages, and only with some options, so the two features — [show diff] & [patrol] — definitely need some love and support from CommTech. Plus, I specifically asked this be enabled for all patrollers (and other roles I may not even know about) in a unified way, which helps with teaching, translations, debugging... I mean, you go to Revision history or User contributions and you can't even see which changes have or haven't been patrolled. Our patrollers deserve better than that! ponor (talk) 22:21, 24 January 2023 (UTC)
  • If implemented, it should have nothing to do with patrolling rights. This is useful for any advanced user, regardless of holding any advanced rights. That being said, I'm more or less satisfied with w:User:Bradv/Scripts/ExpandDiffs.js, and I think improving some of the existing scripts might be a good option. MarioGom (talk) 17:34, 28 January 2023 (UTC)
    If there's interest, all users can get [show diff] buttons inline, and patrollers/sysops/? can additionally get buttons to [patrol]. Also, if possible, non-patrollers could get [unpatrolled] 'tags" instead of the [patrol] buttons, so they could see which changes have been patrolled – why not? When thinking of user scripts, please don't think enwiki alone. I've used ExpandDiffs for my mock-ups because I like the style (of its buttons), but I'm forced to use the other script to patrol on my little wiki /has to do with how the script extracts some data from html source. ponor (talk) 23:49, 28 January 2023 (UTC)
    Sure. I think about all wikis. User scripts can also be improved for cross-wiki support. And, if required, MediaWiki can be improved to make it easier to port these scripts, if these rely on some features that are not portable. MarioGom (talk) 21:56, 29 January 2023 (UTC)
    I agree the proposal's coupling of diff and patrol is weird. I bet it would attract more support if it were about just one or the other. Nardog (talk) 14:30, 29 January 2023 (UTC)
  • Improving moderation tools by providing more context directly in the patrol interface (i.e., recent changes) is something I would much support. --Matěj Suchánek (talk) 13:55, 29 January 2023 (UTC)
  • I think that if this is done, we should make it a special 'app'. We should resist the urge to stuff ever more functionality into a few highly critical pages (that should also be mobile compatible). —TheDJ (talk • contribs) 23:36, 29 January 2023 (UTC)
    There are special apps like SWViewer that have this capability, however the request seems to be integrating it into MediaWiki and Wikimedia pages. Thingofme (talk) 15:31, 30 January 2023 (UTC)
    Arguably, we call RCh/PHist/UContrib pages highly critical *precisely because* that's from where we start patrolling. Since both actions (show diff + patrol) will happen on demand, with some quick calls to MW API, this can be coded as an "official" javascript gadget (or two), adding very little burden to those pages for patrollers/admins who leave the feature enabled and choose not to use it. Those who are patrollers but do not patrol can always disable the feature and will see nothing. ponor (talk) 16:40, 30 January 2023 (UTC)
    People usually start patrolling from there Recent Changes pages, and patrollers and rollbackers with these tools can perform their duties faster without using 3rd party apps like Huggle, SWViewer... but Twinkle and RedWarn/Ultraviolet has proven to increase the patrolling speeds. Thingofme (talk) 14:35, 31 January 2023 (UTC)
  • Somewhat overlaps with Redesign the watchlist. --Tgr (talk) 00:58, 1 February 2023 (UTC)
  • We can already view diffs in Navigation Popups; a "mark as patrolled" option could - and should - be added there. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:10, 2 February 2023 (UTC)
  • You can also use this great script that allows you to see the changes in a pop-up window: commons:User:Serhio Magpie/instantDiffs.js - mw.loader.load('https://commons.wikimedia.org/w/index.php?title=User:Serhio_Magpie/instantDiffs.js&action=raw&ctype=text/javascript'); Iniquity (talk) 19:16, 10 February 2023 (UTC)

Voting

[edit]
  • Support Support Xbypass (talk) 19:49, 10 February 2023 (UTC)
  • Support Support needs more thoughts, but I kinda like the idea MisterSynergy (talk) 20:40, 10 February 2023 (UTC)
  • Support Support Jeeputer (talk) 23:17, 10 February 2023 (UTC)
  • Support Support --NGC 54 (talk｜contribs) 00:10, 11 February 2023 (UTC)
  • Support Support Tgr (talk) 01:44, 11 February 2023 (UTC)
  • Support Support EpicPupper (talk) 05:05, 11 February 2023 (UTC)
  • Support Support Hanif Al Husaini (talk) 05:27, 11 February 2023 (UTC)
  • Support Support It would make patrolling much more efficient and quick. Raydann (talk) 05:34, 11 February 2023 (UTC)
  • Support Support Doktor Züm (talk) 05:59, 11 February 2023 (UTC)
  • Support Support Arado Ar 196 (talk) 08:03, 11 February 2023 (UTC)
  • Support Support Oltrepier (talk) 08:49, 11 February 2023 (UTC)
  • Support Support Matěj Suchánek (talk) 09:23, 11 February 2023 (UTC)
  • Support Support CaféBuzz (talk) 09:43, 11 February 2023 (UTC)
  • Support Support Waldyrious (talk) 10:48, 11 February 2023 (UTC)
  • Support Support Wikipelli (talk) 12:52, 11 February 2023 (UTC)
  • Support Support There are significant proposals to include the diffs, and to view diffs more efficiently but I think we need WMF attention to the difficulty of viewing diffs without external tools like QuickDiff, Huggle and SWViewer. Thingofme (talk) 13:31, 11 February 2023 (UTC)
  • Support Support Swagtennis (talk) 13:50, 11 February 2023 (UTC)
  • Support Support FinixFighter (talk) 15:22, 11 February 2023 (UTC)
  • Support Support Prairie Astronomer (talk) 15:33, 11 February 2023 (UTC)
  • Support Support Rots61 (talk) 15:55, 11 February 2023 (UTC)
  • Support Support Novak Watchmen (talk) 17:22, 11 February 2023 (UTC)
  • Support Support Thomas Kinz (talk) 18:45, 11 February 2023 (UTC)
  • Support Support De nue pw (talk) 22:19, 11 February 2023 (UTC)
  • Support Support MASUM THE GREAT (talk) 06:21, 12 February 2023 (UTC)
  • Support Support Mauricio V. Genta (talk) 07:45, 12 February 2023 (UTC)
  • Support Support Epifanove (talk) 11:39, 12 February 2023 (UTC)
  • Support Support BeyPolite (talk) 12:02, 12 February 2023 (UTC)
  • Support Support Tryvix t 14:00, 12 February 2023 (UTC)
  • Support Support Hári Zalán (talk) 17:36, 12 February 2023 (UTC)
  • Support Support --Minarin❄️[talk] 01:56, 13 February 2023 (UTC)
  • Support Support Izno (talk) 07:00, 13 February 2023 (UTC)
  • Support Support β16 - (talk) 09:58, 13 February 2023 (UTC)
  • Support Support Titore (talk) 14:03, 13 February 2023 (UTC)
  • Support Support Wargo (talk) 00:02, 14 February 2023 (UTC)
  • Support Support ··· 🌸 Rachmat04 · ☕ 09:49, 14 February 2023 (UTC)
  • Support Support Tris T7 (talk) 18:28, 14 February 2023 (UTC)
  • Support Support Quiddity (talk) 21:05, 14 February 2023 (UTC)
  • Support Support Rzuwig► 08:42, 15 February 2023 (UTC)
  • Support Support NPP volunteers on enwiki have been asking for improvements for a long long time. —⁠andrybak (talk) 09:49, 15 February 2023 (UTC)
  • Support Support Ani6032 (talk) 09:51, 15 February 2023 (UTC)
  • Support Support cyrfaw (talk) 11:26, 15 February 2023 (UTC)
  • Support Support ~Cybularny Speak? 13:33, 15 February 2023 (UTC)
  • Support Support Sadads (talk) 01:06, 16 February 2023 (UTC)
  • Support Support Aishik Rehman (talk) 06:42, 16 February 2023 (UTC)
  • Support Support The Yennefer (talk) 21:18, 17 February 2023 (UTC)
  • Support Support --Yining Chen (Talk) 10:05, 18 February 2023 (UTC)
  • Support Support Bilykralik16 (talk) 11:32, 18 February 2023 (UTC)
  • Support Support Vulcan❯❯❯Sphere! 12:29, 18 February 2023 (UTC)
  • Support Support The idea of making more known the topic of protection the environment (including animals) is very important. Eugene Eugene 1992 (talk) 12:58, 18 February 2023 (UTC)
  • Support Support Quangkhanhhuynh (talk) 13:04, 18 February 2023 (UTC)
  • Support Support Bass-Kuroi (talk) 04:12, 19 February 2023 (UTC)
  • Support Support Blue Edits (talk) 10:23, 19 February 2023 (UTC)
  • Support Support — Omegatron (talk) 16:24, 20 February 2023 (UTC)
  • Support Support UTF48 (talk) 22:27, 20 February 2023 (UTC)
  • Support Support Dr vulpes (talk) 06:16, 21 February 2023 (UTC)
  • Support Support Kalendar (talk) 07:18, 21 February 2023 (UTC)
  • Support Support Jaguar K (talk) 06:48, 24 February 2023 (UTC)
  • Support SupportI like the idea of all users being able to see which edits have not been patrolled or have been patrolled and by who SoupePrimordiale (talk) 07:36, 24 February 2023 (UTC)



Allow checkusers to use XFF variable in Abusefilters

Discussion

[edit]

Voting

[edit]

Notifications for user page edits

Discussion

[edit]
  • The request was successful in 2022, but it is requested again to attract attention by CommTech team. Thingofme (talk) 02:16, 29 January 2023 (UTC)
  • I think this really belongs under "notifications and watchlists". Daniel Case (talk) 23:24, 29 January 2023 (UTC)
    • It logically makes sense there too, yes, but as the use-case is primarily for anti-harassment, I think it's fine to stay here. MusikAnimal (WMF) (talk) 15:14, 30 January 2023 (UTC)
  • FWIW this was #2 by votes and #6 by the CommTech team's combined priority score in 2022. There's some in-progress work courtesy of @Legoktm:. --Tgr (talk) 01:57, 1 February 2023 (UTC)
  • WMF develeopment change alternative : What about adding a preference for a new notification option similar to "Edit to my user talk page"? Wakelamp (talk) 02:53, 7 February 2023 (UTC)
  • If WMF resources are the bottle neck, could we use a new bot job that sends a notification for edits that are not done by bots or the owner. OR What about external page watch tools? They exist on apps and desktops. Wakelamp (talk) 02:53, 7 February 2023 (UTC)
  • This would have to be optional, because I at least don't want these types of notifications. I trust that my homewiki userpage is defended by the abusefilter for the most part, and if that fails it's very likely that a RC patroller or another good faith user reverts the vandalism before I see it. I don't want to see it, and I don't even keep my userpage on my watchlist. --kyykaarme (talk) 15:38, 11 February 2023 (UTC)
  • Instead of a notification, i think than an option for an user to protect his own page from edits would be more useful. Particularly for user under big harassment, casual users who rarely edit, are on "vacation", or think than their time has finally come... etc. Miniwark (talk) 10:17, 13 February 2023 (UTC)
  • My hi: Wikipedia userpage was created by a vandal long ago. I never knew that my global userpage was being overriden by a blank white page for over 2 years. This is not desirable at all. —‍CX Zoom (A/अ/অ) (let's talk|contribs) 19:26, 17 February 2023 (UTC)
  • @MarioGom: @MusikAnimal (WMF): Wouldn't it be even better if every user is notified not just for edits to their user pages, but for any edit to any page or subpage on any wiki belonging to someone's username? Nythar (talk) 14:17, 20 February 2023 (UTC)
    I believe having notifications for subpages is subject to debate, but it could likely easily be supported if we wanted it to be. Notifications will already be cross-wiki without any additional effort because of how Echo works. MusikAnimal (WMF) (talk) 14:56, 24 February 2023 (UTC)

Voting

[edit]
  • Strong support Strong support As someone who deals with vandals (including some LTAs) frequently, this is long overdue. ◇HelenDegenerate◆ 19:44, 10 February 2023 (UTC)
  • Support Support Firestar464 (talk) 20:34, 10 February 2023 (UTC)
  • Support Support I hope this can be done easily using a similar mechanism to talk page notifications. Certes (talk) 20:56, 10 February 2023 (UTC)
  • Support Support most definitely! Joshbaumgartner (talk) 21:57, 10 February 2023 (UTC)
  • Support Support with the condition that you should be able to turn this off at any time. SHB2000 (talk | contribs) 22:27, 10 February 2023 (UTC)
  • Support Support LD (talk) 22:28, 10 February 2023 (UTC)
  • Support Support BluePenguin18 🐧 ( 💬 ) 22:54, 10 February 2023 (UTC)
  • Support Support DemonDays64 (talk) 23:45, 10 February 2023 (UTC)
  • Support Support HeyElliott (talk) 23:46, 10 February 2023 (UTC)
  • Support Support ·addshore· talk to me! 00:02, 11 February 2023 (UTC)
  • Support Support --NGC 54 (talk｜contribs) 00:30, 11 February 2023 (UTC)
  • Support Support XtexChooser (talk) 01:42, 11 February 2023 (UTC)
  • Support Support Tgr (talk) 01:48, 11 February 2023 (UTC)
  • Support Support Lalalalala7 (talk) 02:07, 11 February 2023 (UTC)
  • Support Support Svartava (talk) 02:21, 11 February 2023 (UTC)
  • Support Support ··· 🌸 Rachmat04 · ☕ 02:31, 11 February 2023 (UTC)
  • Support Support Hehua (talk) 02:43, 11 February 2023 (UTC)
  • Support Support Dreamy Jazz talk to me | enwiki 02:46, 11 February 2023 (UTC)
  • Support Support Antonio B.1234 (talk) 02:52, 11 February 2023 (UTC)
  • Oppose Oppose Is there some reason the watchlist isn't sufficient for this? * Pppery * it has begun 03:40, 11 February 2023 (UTC)
    @Pppery: For cross-wiki patrollers (or any editors who work on many wikis), it's highly unlikely that they can watchlist their user pages (if uncreated; since most wikis allow autoconfirmed users to edit other userpages) and/or keep checking them for vandalism. As stated above, [u]nlike article vandalism, user page vandalism can affect the unwitting user's standing in the community, so usually it is much more urgent to be alerted of it. Svartava (talk) 05:43, 11 February 2023 (UTC)
    @Pppery: In my case, my watchlist has hundreds of items so I rarely check it, but I swiftly address notifications.--Error (talk) 10:15, 13 February 2023 (UTC)
  • Support Support Khoshhat (talk) 04:05, 11 February 2023 (UTC)
  • Support Support Spencer (talk) 04:59, 11 February 2023 (UTC)
  • Support Support EpicPupper (talk) 05:06, 11 February 2023 (UTC)
  • Support Support Soumendrak (talk) 06:16, 11 February 2023 (UTC)
  • Support Support Doktor Züm (talk) 06:52, 11 February 2023 (UTC)
  • Support Support Transient-understanding (talk) 07:38, 11 February 2023 (UTC)
  • Support Support Arado Ar 196 (talk) 08:00, 11 February 2023 (UTC)
  • Support Support Martin-78 (discutailler) 08:00, 11 February 2023 (UTC)
  • Support Support --Jim Hokins (talk) 08:05, 11 February 2023 (UTC)
  • Support Support Oltrepier (talk) 08:54, 11 February 2023 (UTC)
  • Support Support Szymonel (talk) 09:00, 11 February 2023 (UTC)
  • Support Support —Bruce1eetalk 09:15, 11 February 2023 (UTC)
  • Support Support CaféBuzz (talk) 10:00, 11 February 2023 (UTC)
  • Support Support //Lollipoplollipoplollipop::talk 10:03, 11 February 2023 (UTC)
  • Support Support Sebleouf (talk) 10:07, 11 February 2023 (UTC)
  • Support Support Waldyrious (talk) 10:45, 11 February 2023 (UTC)
  • Support Support Mirliz (talk) 11:46, 11 February 2023 (UTC)
  • Support Support User:Djm-leighpark(a)talk 12:41, 11 February 2023 (UTC)
  • Support Support SunDawn (talk) 12:42, 11 February 2023 (UTC)
  • Support Support Golmote (talk) 12:55, 11 February 2023 (UTC)
  • Support Support Hervegirod (talk) 12:55, 11 February 2023 (UTC)
  • Support Support Wyslijp16 (talk) 13:20, 11 February 2023 (UTC)
  • Support Support Tiputini (talk) 13:32, 11 February 2023 (UTC)
  • Support Support Lupe (talk) 13:36, 11 February 2023 (UTC)
  • Support Support OwenBlacker (Talk) 14:08, 11 February 2023 (UTC)
  • Strong support Strong support I kind of assumed something like this was already in-place. Yikes. Alhadis (talk) 14:14, 11 February 2023 (UTC)
  • Support Support This is long overdue and should be notified. Thingofme (talk) 14:54, 11 February 2023 (UTC)
  • Support Support -- Spielvogel (talk) 14:56, 11 February 2023 (UTC)
  • Support Support Bluerasberry (talk) 15:01, 11 February 2023 (UTC)
  • Support Support CROIX (talk) 15:17, 11 February 2023 (UTC)
  • Support Support FinixFighter (talk) 15:27, 11 February 2023 (UTC)
  • Support Support Realmartcraft (talk) 17:03, 11 February 2023 (UTC)
  • Support Support Novak Watchmen (talk) 18:53, 11 February 2023 (UTC)
  • Support Support Vukky (talk) 18:59, 11 February 2023 (UTC)
  • Support Support Thomas Kinz (talk) 19:21, 11 February 2023 (UTC)
  • Support Support De nue pw (talk) 22:22, 11 February 2023 (UTC)
  • Support Support Gohan 03:14, 12 February 2023 (UTC)
  • Support Support Betseg (talk) 03:59, 12 February 2023 (UTC)
  • Support Support HLFan (talk) 06:57, 12 February 2023 (UTC)
  • Support Support EnIRtpf09b (talk) 07:33, 12 February 2023 (UTC).
  • Strong support Strong support i deal with vandals to the point they frequently vandalized my User Page (along with talk page) on some projects that i was unaware of until an admin protected my user page and notified me of what happened. 🌸 Sakura emad 💖 (talk) 13:35, 12 February 2023 (UTC)
  • Support Support Daniuu (talk) 19:21, 12 February 2023 (UTC)
  • Support Support Bencemac (talk) 20:14, 12 February 2023 (UTC)
  • Support Support Funcrunch (talk) 23:40, 12 February 2023 (UTC)
  • Support Support — Officine Informatiche msg 09:02, 13 February 2023 (UTC)
  • Support Support BRP ever 10:03, 13 February 2023 (UTC)
  • Strong support Strong support Error (talk) 10:15, 13 February 2023 (UTC)
  • Support Support JAn Dudík (talk) 10:28, 13 February 2023 (UTC)
  • Support Support -- EN-Jungwon 10:34, 13 February 2023 (UTC)
  • Support Support β16 - (talk) 10:36, 13 February 2023 (UTC)
  • Support Support Maybe include even subpages of the user and user talk pages? That would need a separate opt-out, though. Tacsipacsi (talk) 11:01, 13 February 2023 (UTC)
  • Support Support Syunsyunminmin 🗨️talk 13:52, 13 February 2023 (UTC)
  • Support Support Airtransat236 (talk) 16:08, 13 February 2023 (UTC)
  • Support Support —Yahya (talk • contribs.) 21:29, 13 February 2023 (UTC)
  • Support Support --Minarin[talk] 22:46, 13 February 2023 (UTC)
  • Support Support ドラみそ (talk) 02:59, 14 February 2023 (UTC)
  • Support Support To make Wikipedia universally acceptable, it should avoid all kinds of controversial topics including obscenity, blasphemy. Hossain Muhammad Ramzan (talk) 04:48, 14 February 2023 (UTC)
  • Strong support Strong support - I hope, as this proposal's technical development begins that developers will extend the scope of notification need to also include user/subpage edits/moves. It seems reasonable, to me, that T296955 could be concurrently resolved with the same technical effort needed for the sole implementation of this proposal in isolation.--John Cline (talk) 05:07, 14 February 2023 (UTC)
  • Support Support SpacedShark (talk) 05:34, 14 February 2023 (UTC)
  • Support Support Mikxth (talk) 12:13, 14 February 2023 (UTC)
  • Support Support ZandDev (talk) 12:53, 14 February 2023 (UTC)
  • Support Support Meganinja202 (talk) 14:40, 14 February 2023 (UTC)
  • Support Support Barkeep49 (talk) 16:42, 14 February 2023 (UTC)
  • Support Support Labdajiwa (talk) 00:05, 15 February 2023 (UTC)
  • Support Support Rzuwig► 09:12, 15 February 2023 (UTC)
  • Support Support cyrfaw (talk) 11:37, 15 February 2023 (UTC)
  • Support Support PRmaster1 (talk) 12:42, 15 February 2023 (UTC)
  • Support Support Mike gigs (talk) 15:26, 15 February 2023 (UTC)
  • Support Support —MdsShakil (talk) 18:12, 15 February 2023 (UTC)
  • Support Support PumpkinHusky (talk) 19:06, 15 February 2023 (UTC)
  • Support Support Aishik Rehman (talk) 06:59, 16 February 2023 (UTC)
  • Support Support ABAL1412 (talk) 14:08, 16 February 2023 (UTC)
  • Support Support Hey man im josh (talk) 15:13, 16 February 2023 (UTC)
  • Support Support JFremd (talk) 15:49, 16 February 2023 (UTC)
  • Support Support OtroQus (talk) 17:35, 16 February 2023 (UTC)
  • Support Support Kays (talk) 02:29, 17 February 2023 (UTC)
  • Support Support ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 07:35, 17 February 2023 (UTC)
  • Support Support Gubeko (talk) 10:08, 17 February 2023 (UTC)
  • Support Support ~ Amory (u • t • c) 16:32, 17 February 2023 (UTC)
  • Support Support —‍CX Zoom (A/अ/অ) (let's talk|contribs) 19:27, 17 February 2023 (UTC)
  • Support Support As long as it's like undo notifications where you can turn them off when you want, I think this is a great idea. -- Ferien (talk) 20:17, 17 February 2023 (UTC)
  • Support Support Totalstgamer (talk) 22:18, 17 February 2023 (UTC)
  • Support Support Dankowski (talk) 22:52, 17 February 2023 (UTC)
  • Support Support DoublePendulumAttractor (talk) 06:01, 18 February 2023 (UTC)
  • Support Support -- Karelj (talk) 08:43, 18 February 2023 (UTC)
  • Support Support --Yining Chen (Talk) 10:13, 18 February 2023 (UTC)
  • Support Support Fabius Lector (talk) 11:23, 18 February 2023 (UTC)
  • Support Support MarioGom (talk) 12:17, 18 February 2023 (UTC)
  • Support Support Trimton (talk) 15:15, 18 February 2023 (UTC)
  • Support Support —‍Mdaniels5757 (talk • contribs) 17:53, 18 February 2023 (UTC)
  • Support Support Teafed (talk) 20:51, 18 February 2023 (UTC)
  • Support Support Kess (talk) 05:21, 19 February 2023 (UTC)
  • Support Support Blue Edits (talk) 17:19, 19 February 2023 (UTC)
  • Support Support Ïvana (talk) 01:06, 20 February 2023 (UTC)
  • Support Support Hans5958 (talk) 02:48, 20 February 2023 (UTC)
  • Support Support I support this as vandalism of their user talk causes editors to quit, but we need a better process for watchlists due to thei increasing length, Wakelamp (talk) 10:18, 20 February 2023 (UTC)
  • Support Support Nashona (talk) 14:41, 20 February 2023 (UTC)
  • Support Support Yes, useful PamD (talk) 15:16, 20 February 2023 (UTC)
  • Support Support Krzysiek 123456789 (talk) 13:01, 21 February 2023 (UTC)
  • Support Support Kcat37 (talk) 13:41, 21 February 2023 (UTC)
  • Support Support DrowssapSMM (talk) 16:09, 21 February 2023 (UTC)
  • Support Support Rosewood (talk) 14:25, 22 February 2023 (UTC)
  • Support Support Tryvix t 14:27, 22 February 2023 (UTC)
  • Support Support XRozuRozu (talk) 17:15, 22 February 2023 (UTC)
  • Support Support. —— Eric Liu（Talk） 02:05, 23 February 2023 (UTC)
  • Support Support --Tchoř (talk) 10:11, 23 February 2023 (UTC)
  • Support Support NicoScribe (talk) 20:46, 23 February 2023 (UTC)
  • Support Support CommanderWaterford (talk) 21:52, 23 February 2023 (UTC)
  • Support Support Krokofant (talk) 09:32, 24 February 2023 (UTC)
  • Support SupportAs an opt-in in Special:Preferences, like user talk notification emails. TheDragonFire300 (talk) 13:48, 24 February 2023 (UTC)
  • Support Support as last year. ~~~~
    User:1234qwer1234qwer4 (talk)     17:23, 24 February 2023 (UTC)

Allow checkusers to use user-agent variables in Abusefilters

Discussion

[edit]
  • User-agent's design is well-known. Such "Mozilla/5.0 (Linux; Android 6.0; HTC One M9 Build/MRA58K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.98 Mobile Safari/537.3" for HTC One M9's mobile could be handled by a few variables, depends how precise we need to be : kernel from a database [equiset] and inherited from browser, browser = "Chrome 52.0.2743.98" [browser_version ?], device = "HTC One M9", system = "Android 6.0". Even if vars are regex-alike, a Toolforge tool can easily parse and convert an UA's string into regexes (mainly . into \., [0-9] into \d). LD (talk) 20:59, 2 February 2023 (UTC)
  • phab:T242825 should probably resolved first. The current status from Chrome suggests time is running out, and Firefox is in support so they will likely follow suit. I'm thinking if anything, someone should re-propose Community Wishlist Survey 2022/Anti-harassment/Deal with Google Chrome User-Agent deprecation. Would you be interested in that, Jules*? I think it's going to be worked on regardless, but the proposal will help ensure it has the urgency it needs. MusikAnimal (WMF) (talk) 02:42, 6 February 2023 (UTC)
    Maybe @LD or Hyméros could re-propose that, as they better know the subject than myself? — Jules* talk 16:53, 6 February 2023 (UTC)
    Re-proposing a known whish is irrelevant (at least not recommended). RFC1945's design, or RFC8942's design, doesn't matter much in front end. It's all about matching properties retrieved in Abuse Filter. At some point, SEC-CH-UA might be used instead of UA, but while waiting for the migration, the request seems justified to me. On top of that, SEC-CH-UA seems to not be uncompatible with the purposes of this request [1][2]. LD (talk) 17:44, 6 February 2023 (UTC)
    Well, as I said, I assume the user agent deprecation will be worked on anyway. And you're right; whether it's client hints or UAs, we can use whatever one is available and expose in CheckUser.
    We just approved Allow checkusers to use XFF variable in Abusefilters knowing it involves phab:T234155 which the more significant amount of work. So I'm going to approve this one, too. According to a blog post from Google, UAs as we know them will largely be gone in just a matter of months, and thus probably not that useful in AbuseFilter. But there other browsers than just Chrome, and automation can still supply a custom UA. So I think there's something to do here regardless of what happens.
    I'll approve this now. Thanks for participating in the survey! MusikAnimal (WMF) (talk) 21:28, 7 February 2023 (UTC)
    Hello everybody. I just want to emphasize that in the few cases where we need to track the "agents", it always involves the use of mobile phones, sometimes with the added use of WikiApp. In this case, the phone model is the final discriminant element. The ability to select or sort based on one of the agents would really save us hours. Hyméros --}-≽ ♥ Yes ? 17:47, 8 February 2023 (UTC)

Voting

[edit]

Minimize Wikimedia/Wikipedia's risk by enforcing 2FA on 'Mandatory Use User' groups

Discussion

[edit]
    • Just a demo notification. Getting the credentials for these accounts is improbable but not impossible.
      Just a demo notification. Getting the credentials for these accounts is improbable but not impossible.
    • If any ill-intention expert hacker can get access for 10 minutes in any of these accounts, just imagine how much damage could be done to Wikimedia web sister projects!
      If any ill-intention expert hacker can get access for 10 minutes in any of these accounts, just imagine how much damage could be done to Wikimedia web sister projects!
    • By not enabling 2FA (or improving security) on these accounts, we are actually challenging non-admirer hackers to use brute-force cracking or other methods.
      By not enabling 2FA (or improving security) on these accounts, we are actually challenging non-admirer hackers to use brute-force cracking or other methods.

    This was a wish on the previous 2019 wishlist survey, proposed by MASUM THE GREAT, and ranked #10.--MASUM THE GREAT (talk) 15:03, 1 February 2023 (UTC)

    • This probably should be in the Anti-harassment section, not Multimedia and Commons? And the more relevant task is T150898 I think. --Tgr (talk) 02:15, 1 February 2023 (UTC)
      Someone, please do that. Many thanks. -- MASUM THE GREAT (talk) 08:41, 1 February 2023 (UTC)
      @Tgr and Ahm masum: Moved, and the other Phabricator task added. Thanks! SWilson (WMF) (talk) 12:29, 1 February 2023 (UTC)
      Disagree that this should be in anti-harassment, unless every single security issue is also in anti-harassment. There's no harassment element in people failing to use 2FA. This is targeted at users who are already *supposed* to have 2FA in place; the overwhelming majority of them keep 2FA in place once they have it, so there's no reason that a hypothetical hacker would go after specific accounts. Risker (talk) 03:29, 21 February 2023 (UTC)
      @Risker: We've already established a conscious, which is why they're called "Mandatory Use User" groups. We don't need to make the same conscious again. So can you tell me, why just 'majority', not 'all' required account holders? Can you, or any advanced permission holder, guarantee us that the current non-enabling state is a 0% security loophole? Are these non-2FA advanced permission holders not a threat to our platform with each passing day?
      Yes. I agree. To make a long term effective mass implimentainon we need to rethink/redesigh our current 2FA mathod. We must have to make it as per industry standard, automative as much as possible. We also have to keep in mind that, as a nonprofit charitable organization, we have limited resources. We can't afford to hire too many paid support representatives. -- ~ MASUM THE GREAT (talk) 13:08, 21 February 2023 (UTC)
      Large-scale websites like this, always attract non-admirers, ill-intentioned people who want to do harm. They don't need Steward credentials. Getting access to any wiki Homepage/Database for 20 minutes through any one of the advanced account holders would be enough for them to tarnish Wikipedia/wikimedia's reputation. We've already seen how we've gotten negative news coverage for silly little mistakes or through vandals.
      Yes. We will wait for a redesigned 2FA. But in the meantime, leaving a 'security loophole' in our platform isn't a wise decision. Is it, @Risker ? -- ~ MASUM THE GREAT (talk) 13:57, 21 February 2023 (UTC)
    • This proposal should must not be implemented without quite a few improvements to the 2FA process as is, in terms of set-up, use, support, how to handle globally, amongst others. Nosebagbear (talk) 13:28, 1 February 2023 (UTC)
      The people who would be affected by this proposal are already required by Foundation policy to have 2FA enabled. This would make it a technical requirement, rather than a social one. Yes, those issues need to be addressed, but this would not make the current situation any worse. HouseBlaster (talk) 21:40, 2 February 2023 (UTC)
    • Stewards/WMF Staff could have a routine audit process on this today - would likely catch most deviations. — xaosflux Talk 15:04, 12 February 2023 (UTC)
      @Xaosflux On non-crat wikis, in theory, yes. On other wikis, we can't remove permissions, so it'd be an informative campaign. Martin Urbanec (talk) 15:38, 15 February 2023 (UTC)
    • I question the problem statement that initiates this request. Administrators and editors are not amongst those who have mandatory 2FA requirements, most of those who have that requirement were verified to have 2FA enabled at the time of their accession to the positions that have mandatory 2FA. There is a limited number of individuals involved, and it should be an easy activity to ensure that they maintain 2FA through periodic scripted verification that has nothing to do with anything else in this proposal. It should be noted that the limitations of the current 2FA software are very well known, and have been for years; it was never designed or intended for broad community use, but instead was designed for use by those who have very close contact with the few individuals who can reset 2FA if the user has a problem (i.e., highest level developers, WMF staff, stewards, and a few others with a long history within the community). If the desire is to improve usage of 2FA amongst those outside of this very limited group, then the software needs a major redesign as well as dedicated ongoing multilingual support by paid employees, not just a minor tweak. There have been extremely few account hijackings over the last 20 years, and to my knowledge they have all been related to poor password hygiene on the part of the account holder. It would be more cost-effective, and considerably less work, to require a password change as a condition of granting advanced permissions. Note that I fully support the proper redesign of 2FA, but right now the current 2FA is massively below the industry standard and I do not think we should be further promoting it until it is brought up to something at least close to industry standard. Risker (talk) 03:56, 21 February 2023 (UTC)

    Voting

    [edit]
    • Support Support Rakib (talk) 21:48, 23 February 2023 (UTC)
    • Support Support HouseBlaster (talk) 20:31, 10 February 2023 (UTC)
    • Support Support As pointed out by HouseBlaster, the user groups that will be affected by this proposal are already required to use 2FA. This is just making it a technical requirement. Firestar464 (talk) 20:31, 10 February 2023 (UTC)
    • Support Support BluePenguin18 🐧 ( 💬 ) 22:17, 10 February 2023 (UTC)
    • Oppose Oppose I don't see how this is any different from the status quo. --SHB2000 (talk | contribs) 22:26, 10 February 2023 (UTC)
    • Support Support XtexChooser (talk) 01:51, 11 February 2023 (UTC)
    • Support Support Lalalalala7 (talk) 02:09, 11 February 2023 (UTC)
    • Support Support LD (talk) 02:31, 11 February 2023 (UTC)
    • Support Support Hehua (talk) 02:45, 11 February 2023 (UTC)
    • Support Support Arado Ar 196 (talk) 07:56, 11 February 2023 (UTC)
    • Support Support Szymonel (talk) 09:00, 11 February 2023 (UTC)
    • Support Support Lemonaka (talk) 10:32, 11 February 2023 (UTC)
    • Support Support OtherPrivacyGuy (talk) 10:45, 11 February 2023 (UTC)
    • Support Support OwenBlacker (Talk) 14:07, 11 February 2023 (UTC)
    • Support Support This is extremely useful that this is enforced by technical means. Thingofme (talk) 14:46, 11 February 2023 (UTC)
    • Oppose Oppose Ain't broke. --Radio-Somewhere (talk) 16:44, 11 February 2023 (UTC)
    • Support Support Realmartcraft (talk) 17:04, 11 February 2023 (UTC)
    • Support Support Vukky (talk) 17:56, 11 February 2023 (UTC)
    • Support Support Novak Watchmen (talk) 18:53, 11 February 2023 (UTC)
    • Support Support Izno (talk) 07:05, 13 February 2023 (UTC)
    • Support Support β16 - (talk) 10:34, 13 February 2023 (UTC)
    • Support Support ドラみそ (talk) 02:58, 14 February 2023 (UTC)
    • Support Support cyrfaw (talk) 11:36, 15 February 2023 (UTC)
    • Support Support -- Riaz (talk) 17:27, 15 February 2023 (UTC)
    • Support Support ~ Amory (u • t • c) 16:27, 17 February 2023 (UTC)
    • Support Support Dankowski (talk) 22:53, 17 February 2023 (UTC)
    • Support Support Johannnes89 (talk) 11:48, 18 February 2023 (UTC)
    • Support Support Vulcan❯❯❯Sphere! 15:15, 18 February 2023 (UTC)
    • Support Support Anonimo88 (talk) 16:45, 18 February 2023 (UTC)
    • Support Support enforcing 2FA on accounts with advanced permissions is an essential security measure for any website at this scale. MarioGom (talk) 18:34, 18 February 2023 (UTC)
    • Support Support This is a security problem, and therefore not something you can say "If it ain't broke, don't fix it" to. There is no point in requiring 2FA if you don't actually require 2FA, and this is a serious issue waiting to happen. Snowmanonahoe (talk) 19:15, 18 February 2023 (UTC)
    • Support Support Niskka2 (talk) 21:56, 19 February 2023 (UTC)
    • Support Support Hans5958 (talk) 02:48, 20 February 2023 (UTC)
    • Neutral Neutral Honestly I'm not so sure about this, while I do think it's a good idea, don't get me wrong. I don't know if this is going to really change anything though, since these affected groups are expected to use 2FA anyways. Toad40 (talk) 13:07, 20 February 2023 (UTC)
    • Support Support Stronger security on these accounts would absolutely be a good thing. — The Hand That Feeds You:Bite 15:14, 20 February 2023 (UTC)
    • Support Support Imran Shorif Shuvo (talk) 23:26, 20 February 2023 (UTC)
    • Support Support Ashiqur Rahman (talk) 17:35, 20 February 2023 (UTC)
    • Support SupportMzz Tanmay (talk) 17:40, 20 February 2023 (UTC)
    • Support Support Hasnat Abdullah (talk) 17:42, 20 February 2023 (UTC)
    • Support Support Mahmud (talk) 17:56, 20 February 2023 (UTC)
    • Support Support Shahidul Hasan Roman (talk) 19:43, 20 February 2023 (UTC)
    • Support Support I support significant encouragement and providing plenty of reminders to users (I even wrote the corresponding help page in Hebrew), but still think it's worth rethinking whether an absolute requirement is worthwhile. —מקף⁻ණ (Hyphen) 23:03, 20 February 2023 (UTC)
    • Oppose Oppose this proposal as written. Would support proper redesign and re-implementation of 2FA in keeping with industry standards. Frankly, most password keepers have better 2FA than is offered on MediaWiki, and I'd rather see people be encouraged to use that instead at this time. Risker (talk) 03:58, 21 February 2023 (UTC)
    • Support Support -- BIDROHI Hello.. 11:27, 21 February 2023 (UTC)
    • Support Support Krzysiek 123456789 (talk) 13:02, 21 February 2023 (UTC)
    • Support Support DrowssapSMM (talk) 16:09, 21 February 2023 (UTC)
    • Support Support — The preceding unsigned comment was added by Mahmudul Hasan (talk) 17:23, 21 February 2023 (UTC)
    • Support Support Gustamons (talk) 17:51, 21 February 2023 (UTC)
    • Support Support — SHEIKH (Talk) 20:23, 21 February 2023 (UTC)
    • Oppose Oppose Wikipedia isn’t a nuclear power plant. --Morten Haan (talk) 18:10, 22 February 2023 (UTC)
      I would argue it is. It's one of the most visited websites on the internet. At least on enwiki, admins have the capability to do break the site in ways that take a while to fix, and this has even happened before (although due to an accident rather than a security breach). Accounts like those of stewards could run malicious code on the computers of tens of thousands if not hundreds of thousands of users across the globe, and probably worse. Snowmanonahoe (talk) 13:11, 23 February 2023 (UTC)
    • Support Support Fcastillo (talk) 22:01, 22 February 2023 (UTC)
    • Support Support Ce.Rakib.Hasan (talk) 16:47, 23 February 2023 (UTC)
    • Support Support — Masum Ibn Musa  Conversation 18:20, 23 February 2023 (UTC)
    • Support Support ~~~~
      User:1234qwer1234qwer4 (talk)       17:21, 24 February 2023 (UTC)

    Reduce Conflict - Change Revert workflow

    Discussion

    [edit]

    Voting

    [edit]
    • Oppose Oppose This is fundamentally trying to change the social structure of the community through technology. That's not how this is supposed to work. * Pppery * it has begun 03:41, 11 February 2023 (UTC)
    • Oppose Oppose I agree that this sometimes is a problem, the analysis is correct, but I do not agree with the solution. This is not just a problem with new editors, but might also involve experienced editors. This is not a technical problem, but involves attitudes of editors. --JopkeB (talk) 04:41, 11 February 2023 (UTC)
    • Support Support Libcub (talk) 05:40, 11 February 2023 (UTC)
    • Support Support Komavo (talk) 14:15, 11 February 2023 (UTC)
    • Oppose Oppose Other dispute resolution processes are welcome here. Thingofme (talk) 14:35, 11 February 2023 (UTC)
    • Support Support De nue pw (talk) 22:21, 11 February 2023 (UTC)
    • Neutral Neutral yes this sometimes is a problem, but is not a technical problem. Elilopes (talk) 19:03, 14 February 2023 (UTC)
    • Oppose Oppose Ani6032 (talk) 10:03, 15 February 2023 (UTC)
    • Oppose Oppose --cyrfaw (talk) 11:36, 15 February 2023 (UTC)
    • Support Support Paulo Rená (talk) 10:25, 17 February 2023 (UTC)
    • Support Support I believe this proposal is worth trying. In case it fails it is easy to go back to the current workflow. Elucches (talk) 21:32, 18 February 2023 (UTC)
    • Support Support Packerfan386 (talk) 09:47, 19 February 2023 (UTC)
    • Support Support This sounds like it would be a great convenience for all editors. Probably needs more discussion before implementation. I would like an option to "undo and talk" which would start a new section on the talk page with the edit summary. Perhaps clicking the edit summary on thehistory page would take you to the talk page discussion. Constant314 (talk) 18:01, 19 February 2023 (UTC)
      @Constant314 As the proposer agree that more discussion is needed but I do think the system UX and quality control post edit are the root cause of a lot of conflict. (@WhatamIdoing had doubts when I mentioned it to them in passing).

      This proposal grew out of analysis I have been doing on toxicity within Wikipedia. My opinion is that the vast majority of the community is actually very polite, but brusque/time poor/Usenet/ASD dev style /passionate hobbyist style/academic/ in its approach to argument. This might reduce the conflict a little bit.

      At first I wanted a toxicity filter on user talk for comments by new editors, but then I worked out the root cause might be reverts

      @WhatamIdoing has doubts.

      This proposal grew out of a lot of analysis I have been doing on toxicity within Wikipedia. At first I wanted a toxicity filter on user talk for comments by new editors, but then I worked out the root cause might be reverts. (The WMF mechanical turk style analysis had issues, but I think their figure that 40 %iah of toxicity is caused new and IP editors seems accurate) Wakelamp (talk) 02:03, 20 February 2023 (UTC)

    • Support Support Krokofant (talk) 09:35, 24 February 2023 (UTC)
    • Oppose Oppose Don't see a technical problem. Scripts like Twinkle allow the user to send a notification after the revert. ~~~~
      User:1234qwer1234qwer4 (talk)       17:33, 24 February 2023 (UTC)

    Add watchers variable to AbuseFilter

    Discussion

    [edit]
    • In my opinion, the variable should ideally be "Active watchers". Let's think of an article about 2012 Olympics, for example. It may have accumulated 100s of watchers in 2012, but a large number of them probably left the project by now. Once 2012 has passed, it hasn't really attracted newer watchers. So, even with a large watcher number, vandalism may pile up. But, if we consider "Active watchers", we'd have a better idea of what articles are more prone to unattended vandalism. —‍(ping on reply)—‍CX Zoom (A/अ/অ) (let's talk|contribs) 21:49, 17 February 2023 (UTC)

    Voting

    [edit]

    Allow abuse filters to be hidden to only oversighters

    Discussion

    [edit]
    • How often does this issue actually arise? I'm been an admin on en-wiki (which is the project that typically has the greatest problem with long-term stalking/doxxing) for fifteen years, and in the past have been a checkuser, oversighter, and arbitrator there, and could probably count the number of occasions I'd have found this feature useful on one hand. In most cases, administrators being able to view the edit filters is a feature, not a bug; edit filters have a bad habit of triggering false positives, and restricting the ability to view them to oversighters would on some projects mean literally only a couple of people—who likely won't be experienced with regex bug-testing—have the ability to address any bugs in the filters. Iridescent (talk) 07:16, 24 January 2023 (UTC)
      I can think of at least three times in the past 30 days this would have been useful, including one that is going to mean there will be a noticeable jump in the number of suppressions on enwiki during January. I would hope any OS who isn't comfortable with regex and abuse filter testing would seek out help - either from a fellow OS or from a steward - before attempting to use on their wiki. Best, Barkeep49 (talk) 13:25, 24 January 2023 (UTC)
      Hi. I'm the author of the phab ticket. I'm sysop, oversighter and abusefilter editor on fr-wp; we encountered several cases of doxing (with threats of violence), by a small number of LTA, but those have been very active. It required the use of abusefilter, and using real names of wikipedians in an abusefilter, even if not linked to the wikipedians usernames, is not comfortable at all. On fr-wp, 5 of the 6 OS have abusefilter rights, and I'm one of the main users of abusefilters. Having the possibility to use an OS-only abusefilter does not mean that it should be used on every wiki. Best, — Jules* talk 16:00, 29 January 2023 (UTC)
    • Just noting that as a volunteer I did a tiny bit of work on this feature, the (work-in-progress/nowhere near complete) results of which I've just committed to a branch. — TheresNoTime (talk • they/them) 20:29, 24 January 2023 (UTC)
    • I can get behind something like this, but what would the abuse filter regex look like? Would it just be a small database of previously posted addresses and the like, or would it a filter to catch the pattern of an address? TheManInTheBlackHat (talk) 18:22, 28 January 2023 (UTC)
      @TheManInTheBlackHat: on fr-wp, we have an abusefilter against doxxing, mostly against the divulgation of real names of editors. The regex goal is to catch those real names (and variations). Best, — Jules* talk 16:02, 29 January 2023 (UTC)
    • Agreed that this is a needed feature and hope that it can have enough community support to be selected as one of this year wishes. Thanks, —MarcoAurelio (talk) 10:50, 6 February 2023 (UTC)
    • I understand the motivation behind this proposal, but such a feature would seem highly problematic and ripe for abuse itself, as it amounts to the ability of a very small group of users to block arbitrary content without scrutiny even from admins. (The proposal doesn't mention any intention to technically limit this ability to actual doxing content like phone numbers or names, nor does it seem feasible to do so.) I see no reason to doubt the good intentions of the proposer and other oversighters who are advocating here for giving them this extreme power, i.e. to assume that they intend to use it for anything beyond the stated purpose. However, once such a feature is deployed, we cannot assume that in the years and decades to come, all users with that right across all wikis will consistently resist that temptation. For example, recall the Croatian Wikipedia situation where an entire Wikipedia (including ArbCom etc.) was dominated for many years by a small group of power users who imposed their nationalist viewpoint via admin tools (whose use is publicly logged). phab:T290324 would have been the perfect tool for this group (say to thwart the mention of war crime convictions in certain BLPs - one of the cases examined in the linked report -, perhaps with a pseudo-justification in the filter description referring to the "Removal of potentially libelous information" clause of the oversight policy). Access to such an oversighter feature might well have enabled this group to evade for much longer the public scrutiny that eventually brought them down. Besides, even in the current setup where oversight actions are still retroactive and to a considerable extent open to review by non-oversighters, it is not unheard of that some (a minority) of oversighters occasionally overstep their remit and apply interpretations of policy that at the very least stretch the local or global community's consensus. That's another reason to not enable oversighters to operate completely without scrutiny even by admins. Regards, HaeB (talk) 15:22, 6 February 2023 (UTC)
      @HaeB if oversighters are abusing such a filter, people can turn to the Ombuds commission and these oversighters will lose their rights much faster than the Croatian admins you mentioned.
      Not sure if you're aware of this, but like many other projects dewiki uses a filter against potential doxxing too. Regular admins (many of them did not sign the WMF non disclosure agreement) should not be able to see the content + log of this filter, which they can access right now. Johannnes89 (talk) 16:07, 6 February 2023 (UTC)
      That's entirely besides the point. "people can turn to" the ombuds commission or other channels only if they are able to notice and document such policy violations (not to speak of the policy knowledge, skill and energy that may be required for filing a successful complaint). And this proposal will drastically reduce the number of people with that ability, by removing all admins (who otherwise could - and often do, as Irisdescent said and I'm sure you are aware anyway - notice and address issues with abuse filters like their frequent false positives).
      In the hypothetical Croatian "libel" filter example above, the group of people encountering it may only consist of those unlucky editors who try to edit a particular BLP to add the war crime conviction and get their edit or even account blocked with a (to them) rather cryptic message. We know that inexperienced editors, including subject matter experts, often find it difficult enough already to understand why their contributions are rejected by a publicly logged revert or deletion, and are rarely able to mount the actions and policy arguments necessary to overcome a mistaken or abusive reaction even when it is open for public scrutiny. So I really don't know where your confidence comes from that such an abusive abuse filter (that blocks edits that are not in fact libelous/oversightable, but can only be inspected by a very small group of fellow oversighters and stewards who may not even speak the wiki's language) would lead to its author "los[ing] their rights much faster than the Croatian admins you mentioned".
    Regards, HaeB (talk) 18:29, 6 February 2023 (UTC)
    The level of abuse you are imagining is already possible with private (=admin-only) filters. If oversighters abuse the newly created filter, at least there is an official instance (Ombuds commission) to turn to, which is much easier then following RfC procedures and getting help of the global community in case of admin abuse.
    I don't see much more risk for abuse then already present with private filters – but I do see a problem with OS-filter content being visible to admins currently. Johannnes89 (talk) 19:54, 6 February 2023 (UTC)
    The level of abuse you are imagining is already possible with private (=admin-only) filters - I'm sorry, but I'm not sure you actually read my entire comment, which is not about the level of seriousness of the abuse itself but about the size of the group of people who would be able to notice and scrutinize it. (And to your earlier remark about dewiki, yes, as a longtime dewiki admin myself - and former checkuser who e.g. wrote large parts of the project's local CU policy that are still in place today - I'm aware that dewiki uses them. I imagine you are referring to de:Special:abusefilter/267 in particular, which you and others are maintaining regarding doxxing. Besides blocking the kind of information that the proposal talks about, this filter honestly also already contains some questionable entries - the title of an entire book that has been the subject of legit community discussion and is currently still listed in a mainspace article? A good illustration of how such things might veer off course.)
    Regards, HaeB (talk) 00:29, 7 February 2023 (UTC)
    OS-level abusefilters logs should be accessible like any other AF log. (But, obviously, logs entries containing private data would be suppressed, as it is already done currently.)
    @HaeB, I don't get what would be the difference with oversight tools current use: oversights could already abuse their tools to revert and suppress contents, without anyone outside OS, stewards and Ombuds commission (OC) being able to check if there is an abuse. Plus only big wikis (20) have oversighters, so only those would have OS-level abusefilters.
    However, regarding your concern (even if I don't share it), there could be on meta-wiki a list of all OS-level filters of all wikis (it is not expected to have dozens of it per wiki), so there would be a special scrutinity about it by OC.
    Best, — Jules* talk 19:54, 6 February 2023 (UTC)
    oversights could already abuse their tools to revert and suppress contents - There's a big difference between oversighting edits (and log entries) retroactively, and preventing them from being made in the first place. That's after all a main rationale for using abuse filters. OS-level abusefilters logs should be accessible like any other AF log - not according to the proposal, which asks that "Abuse filters should have an option to automatically suppress the abuse log for the filter" (without limiting the suppression to only sensitive parts of the log, say).
    Similar to Johannnes89 above, you are basically contradicting yourself here, arguing on the one hand that the proposed change would not meaningfully decrease transparency when it comes to its benefits (ability of admins to scrutinize filters and address problems with them), but is necessary to decrease transparency when it comes to its downsides (increased exposure of some sensitive information to admins). Regards, HaeB (talk) 00:29, 7 February 2023 (UTC)
    • Yes: I disagree with the proposal regarding the logs auto-suppress; I'm against it.
    • No: I do not argue that the proposed change would not decrease transparency (yes, it would for AF editors, that is the point of it), I argue that it would not be less transparent that any suppress action.
    Best, — Jules* talk 00:45, 7 February 2023 (UTC)
    • Comment Comment: Looking at the above concerns raised by HaeB, might this benefit from establishing community consensus for such a feature existing prior to any (potential) work being done on it? The alternative, should this proposal get selected for work, is the implementation of a feature which then ends up unused while discussions take place and policies get built — TheresNoTime-WMF (talk • they/them) 19:27, 6 February 2023 (UTC)
    • Comment Comment @LD: there are dozens of AF editors on several wikis (144+25 on en-wp!), and any sysop can ask to be AF editor. The whole point of OS is to keep some private datas... private, by limiting the number of people who can access it. It would have more sens to check that enough OS are AF editors, and recruiting some if needed. Best, — Jules* talk 23:04, 10 February 2023 (UTC)
      @Jules* I mean: AF config has abusefilter-hide-log (right to hide logs) which can remain a OS right, and it also has abusefilter-hidden-log (right to see hidden logs), usually given to OS. Nevertheless, wikis can't really make AF editors able to have the "abusefilter-hidden-log" right, even if it doesn't give access to suppressed logs and revisions, since there's no policy (as CU policy, OS policy, etc.) allowing AF editors to sign Access to Non-Public Personal Data Policy and Confidentiality Agreement. I'm not saying any AF editor should be able to see AF hidden logs, I'm saying any wiki should be able to make it possible if it meets its scope. LD (talk) 23:23, 10 February 2023 (UTC)
      I don't understand. Why do you want to give abusefilter-hidden-log to non-OS, as it would mean that non-OS could access suppressed contents? (If you want to say that there should be a sysop-level hiding right for logs, in addition to the ability for OS to suppress contents, I agree, but this is not the subject of this proposal.) — Jules* talk 23:34, 10 February 2023 (UTC)
      From proposal : "The existing private filter status is insufficient because it still allows administrators and other editors to view personal information which should be restricted."
      That's not true, it depends on the AF config : by setting abusefilter-log-private for OS only, then you only allow OS to see private logs, no one else. You could also set it on AF and OS only. (No point at the moment since there's no policy for AF users.) So, it depends on wiki and meta scopes.

      AF users will be in contact with private details no matter what. For instance, AF extension won't erase added IP addresses in filters after at most 90 days. LTA-based filters are used as retention in order to keep identifying a person. Even non public details can be added to filters after getting an email from a CU. That's why my thinking is linked to this proposal since policy about privacy is the main subject.

      By contrast, this not a concern for #Allow checkusers to use user-agent variables in Abusefilters & #Allow checkusers to use XFF variable in Abusefilter : dev could create an encrypting export for retrieved private data from CU extension, then you import it in a filter. But you can't encrypt unexpected private details from any wiki user. Of course suppress is needed, but there are benefits to let AF users to check why suppressed logs matched to filters at the first place.

      From proposal : "The abuse log will also contain the private information that the abuse filter is preventing from disclosure".
      I can't disagree with you : OS users keep data confidential. Why they do so? Because they sign for not disclosing.
      AF do not sign for it. We "hope" they do not. LD (talk) 00:55, 11 February 2023 (UTC)
      No, I think you don't get it @LD ;-). "The existing private filter status is insufficient because it still allows administrators and other editors to view personal information which should be restricted." does reffer to the fact that (anti-doxxing) abusefilters (not logs) containing private data are accessible by all AF editors; they should be only accessible to oversighters.
      The proposal has two parts:
      • create abusefilters only visible to OS, in order to correct the current situation described above;
      • allow an auto-suppress of logs of those newly created OS-level abusefilters (it only means allowing actions that are currently already manually done by OS to be done automatically for some filters).
      — Jules* talk 10:30, 11 February 2023 (UTC)

    Voting

    [edit]
    • Strong support Strong support for the creation of OS-level filters: private data should not be visible by all sysops/abusefilters editors. Oppose Oppose auto-suppress of logs: suppress should remain a full manual process. — Jules* talk 19:01, 10 February 2023 (UTC)
    • Neutral Neutral I support providing improved tools for OS to fight against inappropriate content in Abuse logs. However, the Abuse Filter is becoming increasingly confidential. It may be necessary to implement a new policy that allows wikis to designate abuse filter editors who can sign the Access to Non-Public Personal Data Policy and Confidentiality Agreement, so that private data remains visible to these editors. LD (talk) 22:46, 10 February 2023 (UTC)
    • Support Support WhatamIdoing (talk) 00:45, 11 February 2023 (UTC)
    • Support Support Dreamy Jazz talk to me | enwiki 02:48, 11 February 2023 (UTC)
    • Support Support * Pppery * it has begun 03:40, 11 February 2023 (UTC)
    • Support Support SCP-2000 04:20, 11 February 2023 (UTC)
    • Support Support JohnNewton8 (talk) 06:06, 11 February 2023 (UTC)
    • Support Support Arado Ar 196 (talk) 07:59, 11 February 2023 (UTC)
    • Support Support Shizhao (talk) 13:37, 11 February 2023 (UTC)
    • Support Support Guerillero Parlez Moi 13:54, 11 February 2023 (UTC)
    • Support Support To be hidden private data and information and reduce harassment. Thingofme (talk) 14:47, 11 February 2023 (UTC)
    • Support Support Novak Watchmen (talk) 17:28, 11 February 2023 (UTC)
    • Support Support Vukky (talk) 18:58, 11 February 2023 (UTC)
    • Support Support Sgd. —Hasley 19:01, 11 February 2023 (UTC)
    • Support Support This would be used rarely in comparison to most abuse filters but the effect would be to prevent the most harmful edits from being made in the first place. HJ Mitchell | Penny for your thoughts? 19:15, 11 February 2023 (UTC)
    • Support Support 🌸 Sakura emad 💖 (talk) 13:39, 12 February 2023 (UTC)
    • Support Support —MarcoAurelio (talk) 14:27, 12 February 2023 (UTC)
    • Support Support Not that this matters in anyway but this is my #1 Wishlist proposal. Barkeep49 (talk) 16:39, 14 February 2023 (UTC)
    • Neutral Neutral Ani6032 (talk) 09:59, 15 February 2023 (UTC)
    • Support Support cyrfaw (talk) 11:37, 15 February 2023 (UTC)
    • Support Support Hey man im josh (talk) 15:11, 16 February 2023 (UTC)
    • Support Support Paulo Rená (talk) 10:23, 17 February 2023 (UTC)
    • Support Support —‍(ping on reply)—‍CX Zoom (A/अ/অ) (let's talk|contribs) 21:40, 17 February 2023 (UTC)
    • Oppose Oppose: There seems no need to have such a feature. --Yining Chen (Talk) 10:12, 18 February 2023 (UTC)
    • Support Support Johannnes89 (talk) 11:47, 18 February 2023 (UTC)
    • Support Support -- Ferien (talk) 16:18, 18 February 2023 (UTC)
    • Support Support Krzysiek 123456789 (talk) 13:02, 21 February 2023 (UTC)
    • Support Support ~ Seb35 [^_^] 11:49, 22 February 2023 (UTC)
    • Support Support. —— Eric Liu（Talk） 02:10, 23 February 2023 (UTC)
    • Support Support TheDragonFire300 (talk) 13:46, 24 February 2023 (UTC)
    • Support Support and similarly with CU, see the other proposals in this section. ~~~~
      User:1234qwer1234qwer4 (talk)       17:30, 24 February 2023 (UTC)

    Make the AbuseFilter edit window resizable and larger by default

    Discussion

    [edit]
    • This is really a CSS one-liner #wpAceFilterEditor, #mw-abusefilter-notes-editor {width: 90%;} And for the height #wpAceFilterEditor {height: 40em;} It would be nice if this was set as default for all. ponor (talk) 23:09, 29 January 2023 (UTC)
    • I have uploaded a patch to make the Ace editor resizable: gerrit:888349. Od1n (talk) 02:33, 13 February 2023 (UTC)
      @Od1n: Thank you! I've merged that change and updated the results to credit you This change will likely be deployed some time soon — TheresNoTime (talk • they/them) 23:39, 10 March 2023 (UTC)

    Voting

    [edit]

    Mitigate the damage caused by proxy blocks

    Discussion

    [edit]
    • I don't want to completely dodge the "what can we do" question, so here are some ideas (although there are probably better options, and quite likely we haven't found all of them yet):
      • Improve the usability and accessibility of notifications about / explanations of proxy blocks, and make it easier for users to request exemptions. (E.g. T243863, T265812)
      • Some sort of peer-to-peer exemption systems where users "in good standing" can exempt other users from proxy blocks (related: T189362).
      • Some kind of "proof of work" system where a user can spend some time to bypass a proxy block.
      • An exemption request system that lets you tie your request to your established internet identity (e.g. social media accounts) so it is easier to identify well-meaning users.
      • Make it easier to exempt editathon participants from range blocks, e.g. via T27000.
      --Tgr (talk) 07:22, 1 February 2023 (UTC)
    • A lot more could/should be done to prevent vandalism before blocking anon users by their IP address. Most vandals are not very sophisticated, so session/cookie based blocks should work for them, if made possible. Throttle: 3 edits in 10 minutes, 10 edits in 1 hour? Obligatory captcha for IPs after 3 edits. Short automatic block for obvious vandalisms (repeated c&p, ALL CAPS, emojis). Obligatory answer to "How did you improve this article". Know your enemy, WMF! The little measures that I mentioned are (of course) all circumventable, but do lead to measurable reduction of vandalism. Too restrictive? I think it's way more restrictive to block entire networks of some big internet providers – which is what sysops and stewards are manually doing now, plus 2o ooo en wiki bot blocks per day. ponor (talk) 10:59, 1 February 2023 (UTC)
    • @Tgr: I wonder if the IP Masking project might solve some of these problems, particularly of collateral when blocking IPs. This proposal is likely to be too big for Community Tech, but is a good candidate for the larger suggestions category. Unless you want to limit the scope of this proposal to something more discrete and manageable. DWalden (WMF) (talk) 14:16, 1 February 2023 (UTC)
      @DWalden (WMF) I figured CommTech could pick themselves something that they feel is appropriately sized - I think at this point what we have for improving the proxy block situation is a bucket of independent improvements (some large, some small) rather than a single block of work, so there is a lot of wiggle room in defining the scope. Deciding what's the most useful / feasible to work on would take some amount of research itself, that's why I figured it's better not to try to specify it as part of the wish (the guide suggests that's OK). I can try to turn the wish into something more concrete if that's preferred. Tgr (talk) 20:08, 1 February 2023 (UTC)
    • On enwiki I usually just refer the many unblock requests of this sort to WP:IPECPROXY where they can request IPBE. Do other wikis have this page or its equivalent? Daniel Case (talk) 06:08, 2 February 2023 (UTC)
      They can request it but do they actually get it? AIUI the process sometimes takes weeks due to the size of the backlog, it involves you writing an email to an unknown person and having to justify yourself (which, if e.g. you are using a proxy to circumvent a Wikipedia ban in an oppressive regime, is not the most comfortable thing to do - what are you going to say? how much you can trust the random anonymous volunteers at the other end of the email address?), and I don't think it's common for other wikis to have even that much. It's better than nothing (and more clearly exposing it to users is one of the things CommTech might be able to do) but not great. Tgr (talk) 03:01, 5 February 2023 (UTC)
      Yeah, I think some users just don't want to deal with it. One flatly told me he didn't want his email address to be able to be so easily connected to his account. We need something that works better for these users. Daniel Case (talk) 03:21, 16 February 2023 (UTC)
    • I think this actually is the result of a larger and probably not easy to solve problem: MediaWiki still relying mainly on IP addresses & Co. for vandalism/abuse prevention and sockpuppet detection, so NOP became necessary. If MediaWiki could rely on something different (what: I don't know) to handle vandalism/abuse/sockpuppet detection/prevention I feel proxy blocking would perhaps no longer be needed, or not that much maybe. Apologies for any inexactitude, as I'm not really "techy". —MarcoAurelio (talk) 11:05, 6 February 2023 (UTC)
    • Maybe unrelated, but now, as default, autopatrollers or approved bot are automatically blocked, even if they are logged-in, when their origin is from an IP range block. To me, this is a bug in good faith, since there is no consensus, and there is not any strong benefit, in blocking these trusted logged-in users (and maybe other trusted roles). phabricator:T309328 --Valerio Bozzolan (talk) 20:38, 6 February 2023 (UTC)
    • See also phab:T309328. In my opinion what is better is allow IPs or ranges to be (locally or globally) "semi-blocked", which is to block with (auto)confirmed users exempted. This will be a level between soft (anon-only) and hard (all non-IPBE) block, and will be applied to most open proxies.--GZWDer (talk) 23:09, 8 February 2023 (UTC)
    • Please see also Explore evasion methods of state-level censorship across Wikimedia movement. --Diskdance (talk) 15:08, 13 February 2023 (UTC)
    • I don't know the technical details, but maybe for those who use 2FA automatically allow the use of VPNs and proxies without changing the IP blocking of these services. --Klip game (talk) 08:53, 16 February 2023 (UTC)

    Voting

    [edit]
    • Support Support XtexChooser (talk) 01:49, 11 February 2023 (UTC)
    • Support Support Some of the upcoming work around IPs is going to require updates to gadgets/scripts/tools. WhatamIdoing (talk) 01:51, 11 February 2023 (UTC)
    • Support Support Tgr (talk) 03:04, 11 February 2023 (UTC)
    • Support Support Arado Ar 196 (talk) 07:53, 11 February 2023 (UTC)
    • Support Support Oltrepier (talk) 08:53, 11 February 2023 (UTC)
    • Support Support Tiputini (talk) 13:27, 11 February 2023 (UTC)
    • Support Support Lvova (talk) 13:50, 11 February 2023 (UTC)
    • Support Support There are exhaustion of IPv4 and this has negatively affected developing countries (2^32<8 billion people). And for anonymity there are movements towards hiding IPs and proxying many people are being affected by proxy blocks. And I think this should be done to reduce the damage. Thingofme (talk) 14:34, 11 February 2023 (UTC)
    • Support Support Bluerasberry (talk) 15:00, 11 February 2023 (UTC)
    • Support Support CROIX (talk) 15:17, 11 February 2023 (UTC)
    • Support Support Novak Watchmen (talk) 18:55, 11 February 2023 (UTC)
    • Support Support 🌸 Sakura emad 💖 (talk) 13:12, 12 February 2023 (UTC)
    • Support Support So options can be identified. —MarcoAurelio (talk) 14:26, 12 February 2023 (UTC)
    • Support Support, for the reasons mentioned in the proposal, and to counter systemic bias among editors. SmallJarsWithGreenLabels (talk) 19:00, 12 February 2023 (UTC)
    • Neutral Neutral as I support the concept but the innovation of this proposal (let the ComTech team chose what is doable) is also what gives me pause since time could be spent on a solution that the enwiki community, as a target of this proposal, may not support and thus not be a good use of their time in the end after all. Barkeep49 (talk) 16:45, 14 February 2023 (UTC)
    • Support Support cyrfaw (talk) 11:37, 15 February 2023 (UTC)
    • Support Support PRmaster1 (talk) 12:43, 15 February 2023 (UTC)
    • Support Support Mike gigs (talk) 15:25, 15 February 2023 (UTC)
    • Support Support Matma Rex (talk) 21:56, 15 February 2023 (UTC)
    • Support Support Daniel Case (talk) 03:21, 16 February 2023 (UTC)
    • Support Support مهدی بهرامی مطلق (talk) 09:37, 16 February 2023 (UTC)
    • Support Support JFremd (talk) 15:48, 16 February 2023 (UTC)
    • Support Support ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 07:33, 17 February 2023 (UTC)
    • Support Support Akme (talk) 18:12, 17 February 2023 (UTC)
    • Support Support —‍(ping on reply)—‍CX Zoom (A/अ/অ) (let's talk|contribs) 21:38, 17 February 2023 (UTC)
    • Support Support given that not all users come from developed countries. Alfa-ketosav (talk) 22:20, 18 February 2023 (UTC)
    • Support Support Jotamide (talk) 15:26, 19 February 2023 (UTC)
    • Support Support Vulcan❯❯❯Sphere! 01:38, 20 February 2023 (UTC)
    • Strong support Strong support. while stewards & other respondents focused their arguments on proxy IP address, the less developed and emerging communities which are the major contributor of our projects have to rely on their mobile internet carrier that uses a shared infrastructure. This IP range block policy wasted much of the Foundation's money doing outreach activities that result to users unable to participate and shy away from joining activities because to the IP address of their ISP is blocked. --Exec8 (talk) 10:56, 20 February 2023 (UTC)
    • Support Support Mndetatsin (talk) 11:12, 20 February 2023 (UTC)
    • Support Support ceci es vital pour nos communautés Aboubacarkhoraa (talk) 12:01, 20 February 2023 (UTC)
    • Support Support The idea of peer-to-peer exemptions resonates with me as an Event Coordinator/organizer as it will make it easy to exempt participants in an outreach efficient than reaching out to Admins/Stewards which takes weeks or months to get a response. I and my team are currently implementing the RWiC Abuja program and the trainees are facing the challenges of IP blocks, which are very frustrating. Atibrarian (talk) 12:56, 20 February 2023 (UTC)
    • Support Support --Oscar_. (talk) 13:33, 20 February 2023 (UTC)
    • Support Support I support the idea, because this is really one of the major concerns that prevents some people from participating, because when they are victimized once they tend to get discouraged in continuity. One of my community participants yesterday was victimized while creating his draft even though he had already contributed to various projects in the past, but that didn't stop his IP address from being blocked. I had to meet with him to explain how to send an email to one of the administrators who can resolve this situation (hopefully someone will do it so that this person doesn't get discouraged like the others who have been victims in the past and it's hard to get them back with that motivation from the beginning causing the communication to be fragile.--Azogbonon (talk) 13:56, 20 February 2023 (UTC)
    • Support Support -- As editathon organizers for the lusophone communities, we have experienced problems with IP blocking more than once, which can be especially frustraiting during in person events Contaminadas 15:57, 20 February 2023 (UTC)
    • Support Support -- our user group has gone through several proxy blocks, having affected all of our in person major events, and affecting our autonomy while organizers Anita Braga (talk) 16:37, 20 February 2023 (UTC)
    • Strong support Strong support —Sunkanmi12✉️ 19:41, 20 February 2023 (UTC)
    • Support Support —מקף⁻ණ (Hyphen) 22:56, 20 February 2023 (UTC)
    • Support Support I support this very strongly, as someone who has issued a large number of IPBEs over the years. It is a major mental leap for a lot of people to take to go from "no open proxies" to the realization that more than a quarter of the world's population is adversely affected by these large proxy blocks (or alternately blocks to Wikimedia projects applied by various jurisdictions), but it's essential. Risker (talk) 04:06, 21 February 2023 (UTC)
    • Support Support ~ Seb35 [^_^] 08:10, 22 February 2023 (UTC)
    • Support Support Rosewood (talk) 14:33, 22 February 2023 (UTC)
    • Support Support Inbox.nidhinm (talk) 16:39, 22 February 2023 (UTC)
    • Support Support Morten Haan (talk) 18:08, 22 February 2023 (UTC)
    • Support Support. —— Eric Liu（Talk） 02:08, 23 February 2023 (UTC)
    • Support Support hgzh 07:02, 23 February 2023 (UTC)
    • Support Support This open proxy block has kept a lot of resourceful people away from editing Wikipedia, which means we are losing on the total sum of human knowledge Dnshitobu (talk) 16:41, 23 February 2023 (UTC)
    • Neutral Neutral per Barkeep49. ~~~~
      User:1234qwer1234qwer4 (talk)       17:19, 24 February 2023 (UTC)



    Edit-war-detecting bot or bots

    Discussion

    [edit]
    I wonder if that was what I was describing. Daniel Case (talk) 03:23, 16 February 2023 (UTC)
    with detection of "stop you stupid idiot" @User:Novem Linguae kindly created a dump of edit histories for a month.There are a LOT of false positives,but the abuse level was far lower than I expected (Does antivandalism remove them??? Wakelamp (talk) 10:38, 20 February 2023 (UTC)
    @Iluvatar has a Discord bot with some related functionality. ~~~~
    User:1234qwer1234qwer4 (talk)     17:34, 24 February 2023 (UTC)

    Voting

    [edit]
    • Support Support --NGC 54 (talk｜contribs) 00:31, 11 February 2023 (UTC)
    • Support Support Libcub (talk) 05:46, 11 February 2023 (UTC)
    • Support Support Doktor Züm (talk) 07:11, 11 February 2023 (UTC)
    • Support Support V0lkanic (talk) 08:46, 11 February 2023 (UTC)
    • Support Support Exilexi (talk) 09:24, 11 February 2023 (UTC)
    • Support Support Shizhao (talk) 13:39, 11 February 2023 (UTC)
    • Support Support There should be war-detecting bots to help editors dealing with edit warrers. Thingofme (talk) 15:31, 11 February 2023 (UTC)
    • Support Support Prairie Astronomer (talk) 15:31, 11 February 2023 (UTC)
    • Support Support Ivario (talk) 22:07, 11 February 2023 (UTC)
    • Support Support Daniel Case (talk) 02:57, 12 February 2023 (UTC)
    • Support Support Squidward gaming (talk) 04:41, 12 February 2023 (UTC)
    • Support Support HLFan (talk) 06:59, 12 February 2023 (UTC)
    • Support Support TExtHumer (talk) 15:27, 12 February 2023 (UTC)
    • Support Support Looking at the discussion, it seems that there are already bots for this from other wikis. It shouldn’t be much of a hassle to import them or even standardize them as a gadget. Liu1126 (talk) 07:11, 13 February 2023 (UTC)
    • Support Support ドラみそ (talk) 03:01, 14 February 2023 (UTC)
    • Support Support Rzuwig► 10:58, 15 February 2023 (UTC)
    • Support Support cyrfaw (talk) 11:39, 15 February 2023 (UTC)
    • Strong support Strong support Hári Zalán (talk) 15:56, 16 February 2023 (UTC)
    • Support Support ~ Eejit43 (talk) 18:51, 17 February 2023 (UTC)
    • Support Support Lightoil (talk) 02:57, 18 February 2023 (UTC)
    • Support Support --Yining Chen (Talk) 10:15, 18 February 2023 (UTC)
    • Support Support Same comment as that of Liu1126. Elucches (talk) 21:39, 18 February 2023 (UTC)
    • Support Support Althair (talk) 02:07, 20 February 2023 (UTC)
    • Support Support Hans5958 (talk) 02:52, 20 February 2023 (UTC)
    • Support Support Davidgblackburn (talk) 05:35, 20 February 2023 (UTC)
    • Support Support Tommy Kronkvist (talk) 09:07, 20 February 2023 (UTC)
    • Support Support Wakelamp (talk) 10:39, 20 February 2023 (UTC)
    • Support Support Qxyz123 (talk) 04:15, 21 February 2023 (UTC)
    • Support Support Krzysiek 123456789 (talk) 13:03, 21 February 2023 (UTC)
    • Support Support would be extremely helpful DrowssapSMM (talk) 16:08, 21 February 2023 (UTC)
    • Support Support. —— Eric Liu（Talk） 02:18, 23 February 2023 (UTC)
    • Support Support Krokofant (talk) 09:30, 24 February 2023 (UTC)

    Make Navigation Popups work on grandchild sub-cats from category pages

    Discussion

    [edit]

    Voting

    [edit]

    A more performant bot to replace ListeriaBot

    Discussion

    [edit]
    Tracked in Phabricator:
    Task T329380
    Also see ListeriaBot returns "Last line: ERROR: Login failed":
    M2k~dewiki (talk) 18:18, 10 February 2023 (UTC)
    • The events of the last days (the bot completely inactive since 7 February, its creator looking into the problem without any result yet) have shown that ListeriaBot has become a liability, plain and simple. Too many lists across too many Wikis depend too much on it. --Edelseider (talk) 14:15, 12 February 2023 (UTC)
      @GZWDer:@Lydia Pintscher (WMDE):@MusikAnimal (WMF): Okay, ListeriaBot is working again. Except that it is not working correctly at all. For some reason, it now deletes (for lack of a better word) the line "image", thus creating a list where the labels do not correspond to the content of the fields: see here. The stuff of nightmares, that tool is.--Edelseider (talk) 12:12, 13 February 2023 (UTC)

    I think I fixed the problem that the "bot passwords" login did not work via API on some WMF wikis (any insight into that?) by switching the login to OAuth. I also fixed the table column problem, which was caused by a Pull Request that I foolishly merged. Right now the bot is somewhat limited by the Toolforge kubernetes constraints; relaxed constraints (more RAM, more CPUs per pod) would help there. Barring serious malfunction, the bot should now update every list on every wiki once every two days. If that does not work for some tasks, TABernacle provides a possible alternative. --Magnus Manske (talk) 14:37, 13 February 2023 (UTC)

    I often get a Killed by Memory Overload message, if I dont limit the number of entries to 1000 (for example, depending on the number of columns) whith LIMIT 1000. For 1500 or 2000 entries I get a Killed by Memory Overload message. M2k~dewiki (talk) 14:40, 13 February 2023 (UTC)
    @Magnus Manske:@M2k~dewiki: Even a slight change of query (see here), and it's "killed by OS for overloading memory". It has been like this and it still is like this. --Edelseider (talk) 15:50, 13 February 2023 (UTC)
    What is concerning is the bot will load the entire item for each items involved. This is really not a good thing. GZWDer (talk) 18:27, 17 February 2023 (UTC)
    Indeed. I haven't looked into this for a while, but the problem used to be not so much about number of results, but about number of big items present in some fields, such as some geographical entities. MarioGom (talk) 12:38, 18 February 2023 (UTC)

    Voting

    [edit]
    • Support Support--Frettie (talk) 18:14, 10 February 2023 (UTC)
    • Support Support--M2k~dewiki (talk) 18:15, 10 February 2023 (UTC)
    • Support Support عُثمان (talk) 23:53, 10 February 2023 (UTC)
    • Support Support Poslovitch (talk) 00:27, 11 February 2023 (UTC)
    • Support Support --NGC 54 (talk｜contribs) 00:37, 11 February 2023 (UTC)
    • Support Support Akbarali (talk) 08:55, 11 February 2023 (UTC)
    • Support Support Matěj Suchánek (talk) 10:56, 11 February 2023 (UTC)
    • Support Support RVA2869 (talk) 13:17, 11 February 2023 (UTC)
    • Support Support RPI2026F1 (talk) 13:19, 11 February 2023 (UTC)
    • Support Support Bluerasberry (talk) 14:59, 11 February 2023 (UTC)
    • Support Support I often modify lists on Wikipedia, adding missing elements. This would be really helpful in order to have updated lists and contributores could spend more time improving records on Wikidata instead, so that all Wikipedias will benefit from that. FinixFighter (talk) 15:12, 11 February 2023 (UTC)
    • Support Support Ayack (talk) 15:12, 11 February 2023 (UTC)
    • Support Support Updating Wikipedia lists based on Wikidata information will certainly be faster. Thingofme (talk) 15:26, 11 February 2023 (UTC)
    • Support Support Thomas Kinz (talk) 19:40, 11 February 2023 (UTC)
    • Support Support--WomenArtistUpdates (talk) 17:32, 12 February 2023 (UTC)
    • Support Support Bencemac (talk) 20:24, 12 February 2023 (UTC)
    • Support Support Husky (talk) 20:55, 12 February 2023 (UTC)
    • Support Support --PaFra (talk) 22:51, 12 February 2023 (UTC)
    • Support Support Izno (talk) 07:12, 13 February 2023 (UTC)
    • Support Support β16 - (talk) 11:15, 13 February 2023 (UTC)
    • Support Support Tacsipacsi (talk) 13:38, 13 February 2023 (UTC)
    • Support Support JAn Dudík (talk) 17:00, 13 February 2023 (UTC)
    • Support Support Wikidata lists are used on a large scale for maintenance and task list generation. It is crucial to have a reliable and scalable system. Fuzheado (talk) 11:05, 14 February 2023 (UTC)
    • Support Support Quiddity (talk) 21:15, 14 February 2023 (UTC)
    • Support Support cyrfaw (talk) 11:41, 15 February 2023 (UTC)
    • Support Support Sadads (talk) 01:10, 16 February 2023 (UTC)
    • Support Support Jon Harald Søby (talk) 12:37, 16 February 2023 (UTC)
    • Support Support For core bots, revamp required every 5 years or so. Yug (talk) 10:25, 17 February 2023 (UTC)
    • Support Support —The Editor's Apprentice (talk) 02:49, 18 February 2023 (UTC)
    • Support Support Kpjas (talk) 07:34, 18 February 2023 (UTC)
    • Support Support MarioGom (talk) 12:15, 18 February 2023 (UTC)
    • Support Support Rosiestep (talk) 12:33, 18 February 2023 (UTC)
    • Support Support Ipigott (talk) 20:42, 18 February 2023 (UTC)
    • Support Support PamD (talk) 23:49, 18 February 2023 (UTC)
    • Support Support Jklamo (talk) 11:56, 19 February 2023 (UTC)
    • Support Support Tommy Kronkvist (talk) 09:09, 20 February 2023 (UTC)
    • Support Support Nashona (talk) 14:30, 20 February 2023 (UTC)
    • Support Support a necessary piece of work Watty62 (talk) 17:42, 20 February 2023 (UTC)
    • Support Support Nikki (talk) 16:16, 21 February 2023 (UTC)
    • Support Support - PKM (talk) 18:47, 21 February 2023 (UTC)
    • Support Support Althair (talk) 04:01, 23 February 2023 (UTC)
    • Support Support TMg 12:32, 23 February 2023 (UTC)
    • Support Support CmdrDan (talk) 17:25, 24 February 2023 (UTC)

    Make Navigation Popups & Page Previews work cross-wiki

    Discussion

    [edit]
    • It would be good if phab:T243820 were included, if this goes ahead. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:38, 1 February 2023 (UTC)
    • Navigation Popups is a very useful gadget for me and I use it, but its UI is ugly. The UI of Page Previews looks good, though. --NGC 54 (talk｜contribs) 00:35, 11 February 2023 (UTC)
    • This would be awesome. Even better if the previews could cover other content (from Wikimedia-hosted projects) that isn't wikitext, e.g. label and description for Wikidata items (as mentioned above) or title for Phabricator links :) --Waldyrious (talk) 11:15, 11 February 2023 (UTC)

    Voting

    [edit]

    Support ASGI on Toolforge

    Discussion

    [edit]
    • It has been two years since we requested this on Phabricator. Supporting ASGI is the key to opening up our servers to more diverse tools and capabilities. It would have a great return on investment by providing more modern frameworks for development by the community. - Fuzheado (talk) 10:47, 14 February 2023 (UTC)
    • Hi folx, just reiterating an update on Phabricator by the Wikimedia Cloud Services team — the Toolforge Build Service now offers the ability to "use modern ASGI-based frameworks like FastAPI". Please note that this service is in a "beta state, which means that it is likely to change in non-backward compatible ways and/or suffer from outages and bugs". It may be worth some interested parties trying it out and leaving them some feedback. Thanks! — TheresNoTime-WMF (talk • they/them) 11:29, 24 May 2023 (UTC)

    Voting

    [edit]

    Make Navigation Popups into an Advanced-mode of Page Previews

    Discussion

    [edit]

    Voting

    [edit]

    DabFix

    Discussion

    [edit]
    • Yes, please. BD2412 T 01:02, 2 February 2023 (UTC)
    • It's unfortunate the volunteer didn't want to host their tools on Toolforge, as if they did we could have multiple engineers maintaining it. I don't think the code, although open source, is licensed. So we will need a complete rewrite. Still seems doable by Community Tech. I'm hoping we can build something directly into mw:Extension:Disambiguator. MusikAnimal (WMF) (talk) 20:23, 2 February 2023 (UTC)
      This is pedantic, but source-available and open-source are two very different things. Software can only be considered open-source when the copyright holder grants users the rights to use, study, change, and distribute the software to anyone and for any purpose. Dispenser's source code is published publicly, but is not obviously distributed under any FOSS or proprietary license. -- BDavis (WMF) (talk) 21:21, 10 February 2023 (UTC)
      My understanding is that the reason he would not move to Toolforge is precisely because some of the code he was using was not open source. Izno (talk) 07:11, 13 February 2023 (UTC)

    Voting

    [edit]

    Discussion

    [edit]
    The source code can be found here, allow it has unclear licensing. Qwerfjkl (talk) 07:34, 5 February 2023 (UTC)
    So it's hard to use other codes in the site. Thingofme (talk) 15:25, 11 February 2023 (UTC)
    Gadget pl:MediaWiki:Gadget-disFixer.js allows to detect links to disambigs in current article and choose replacements. --Wargo (talk) 20:53, 13 February 2023 (UTC)
    As do Navigation popups and w:User:Qwertyytrewqqwerty/DisamAssist.js. ~~~~
    User:1234qwer1234qwer4 (talk)     17:39, 24 February 2023 (UTC)

    Voting

    [edit]

    Allow client-side scripts to convert dates in the format used in MediaWiki interface

    Discussion

    [edit]
    • @Nardog: To clarify, this proposal is about exposing an API function to convert date/times (such as the timestamp 1672543856, or the ISO 8601 2023-02-07T20:16:29+00:00) to "human-friendly" date/times, such as those specified in Special:Preferences? — TheresNoTime-WMF (talk • they/them) 20:19, 7 February 2023 (UTC)
      @TheresNoTime-WMF: As opposed to...? The answer is yes, of course, but I'm not sure what I'm supposed to clarify between. If it's between a synchronous function that can convert dates completely offline (once the module is downloaded) versus an asynchronous one where you have to send the dates to the server every time, the former is obviously preferable, but failing that, an option to receive dates in a specified (or user-preferred) format in conjunction with the Unix/ISO dates in the same API call (much like you receive canonical page names) would be very handy, as those would be the primary use cases (I ran into the present problem as I built CatChangesViewer and MoveHistory, where I'm begrudgingly showing dates in ISO/UTC).
      AFAICS, the pieces of information needed to show a date in the same format as the MW interface are: timezone, format, numerals, era, and calendar. And currently only numerals are fully available (via mw.language.getDigitTransformTable()). mw.user.options.get('timecorrection') gives only one value for the UTC offset so it's of little use; you have to match the location with a timezone database (which Moment provides—perhaps the data should be its own RL module). The formats (like H:i, F j, Y) are in /languages/messages/. AFAIK they aren't available through the message or languageinfo API, and it'd be swell if they were. The logic for non-Common eras and non-Gregorian calendars (in use in Iran, Thailand, Japan, etc.) appears to be in Language.php. It doesn't look too complicated to port to JS but it'd be nicer if both server and client used the same codebase.
      (The opposite direction (from a formatted date to a computer-friendly one) is harder and probably in less demand, but come to think of it, it's exactly what DiscussionTools has figured out, isn't it? It's how it tells where each comment ends and the next begins after all. Exposing that function as an asynchronous API might prove useful.)
      Now I'm realizing none of these seem like "less than a year-long project", and I'm talking myself out of the original proposal! How about changing the solution to something like:
    Proposed proposed solution

    An option in <tvar name=1>Action API</tvar> that, if the response contains any dates, appends versions of them in the language/format/timezone specified in the request (somewhat similar to the "<tvar name=2>normalized</tvar>" object in <tvar name=2>action=query</tvar>). It should accept values like "<tvar name=3>site</tvar>" (the site's default format) and "<tvar name=4>user</tvar>" (the logged-in user's preferences) in addition to specific languages/formats/timezones (like <tvar name=5>uselang</tvar>). And a separate but similar API function that receives acceptable timestamps and returns them in the language/format/timezone specified in the request.

    Nardog (talk) 00:31, 8 February 2023 (UTC)
    Thank you, was just wanting to make sure I understood the scope correctly As an aside, this would be a really useful thing to have from my own volunteer dev experience wrestling datetime formats.... — TheresNoTime-WMF (talk • they/them) 10:16, 8 February 2023 (UTC)
    Okay, then I guess the alternative above should be thought of as a starting point or an acceptable compromise. Nardog (talk) 18:36, 8 February 2023 (UTC)
    • Modern Javascript has Intl.DateTimeFormat which is very capable (arguably more capable than MediaWiki's server-side logic). Unless your goal is to very specifically match the server-side date format, or to parse human-readable date strings back into numbers, you are probably best off doing that. --Tgr (talk) 03:12, 11 February 2023 (UTC)

    Voting

    [edit]
    • Support Support Xbypass (talk) 19:51, 10 February 2023 (UTC)
    • Support Support DemonDays64 (talk) 23:46, 10 February 2023 (UTC)
    • Support Support XtexChooser (talk) 02:37, 11 February 2023 (UTC)
    • Support Support * Pppery * it has begun 03:43, 11 February 2023 (UTC)
    • Support Support Libcub (talk) 05:51, 11 February 2023 (UTC)
    • Support Support SD0001 (talk) 10:09, 11 February 2023 (UTC)
    • Support Support Golmote (talk) 13:43, 11 February 2023 (UTC)
    • Support Support Lupe (talk) 14:42, 11 February 2023 (UTC)
    • Support Support We need to parse datetime tags more easily and it can be performed in JS. Thingofme (talk) 15:29, 11 February 2023 (UTC)
    • Support Support Ahkei (talk) 01:24, 12 February 2023 (UTC)
    • Support Support HLFan (talk) 07:02, 12 February 2023 (UTC)
    • Support Support Nux (talk) 08:59, 12 February 2023 (UTC)
    • Support Support Natalius (talk) 04:44, 13 February 2023 (UTC)
    • Support Support Izno (talk) 07:15, 13 February 2023 (UTC)
    • Support Support Titore (talk) 14:11, 13 February 2023 (UTC)
    • Support Support cyrfaw (talk) 11:42, 15 February 2023 (UTC)
    • Support Support Matma Rex (talk) 21:58, 15 February 2023 (UTC)
    • Support Support --Yining Chen (Talk) 10:14, 18 February 2023 (UTC)
    • Support Support Kess (talk) 05:24, 19 February 2023 (UTC)
    • Support Support Jotamide (talk) 15:27, 19 February 2023 (UTC)
    • Support Support Althair (talk) 02:08, 20 February 2023 (UTC)
    • Support Support Hans5958 (talk) 02:53, 20 February 2023 (UTC)
    • Support Support Wakelamp (talk) 10:40, 20 February 2023 (UTC)

    Automate WikiProject weekly collaborations

    Discussion

    [edit]

    Voting

    [edit]

    Community Wishlist Survey 2023/Categories



    Allow citations to be edited in the references section with VisualEditor

    Discussion

    [edit]
    • Original German proposal:

      Problem: Es ist nicht möglich den Text von Einzelnachweisen am Ende des Artikels direkt zu ändern, stattdessen muss jeder Einzelnachweis im Text einzeln angeklickt und bearbeitet werden. Das macht die ganze Bearbeitung sehr langwierig und komplizierter als sie sein müsste.

      Lösungsvorschlag: Es sollte eine Möglichkeit geschaffen werden, dass Fußnoten direkt Bearbeitet werden könne, so wie etwa bei Microsoft Word.

      Wem würde dieser Wunsch helfen: Jedem

      Copied by MusikAnimal (WMF) (talk) 03:14, 6 February 2023 (UTC)
      An easier attempt, would be, to have a bot move all citations to reflist, leaving an anchor inline. .... 0mtwb9gd5wx (talk) 04:03, 16 February 2023 (UTC)
    • So with itemizations, you mean references or footnotes, and by editing you mean using the visual editor? --Matěj Suchánek (talk) 11:31, 29 January 2023 (UTC)
      @Matěj Suchánek: I'm pretty sure they mean references, yes. I've copied the original German proposal above. We have a German speaker on our team that I can ask to engage with this user, if need be. I know VE already lets you edit references, so I'm guessing they are using the 2010 editor. If those assumptions are true, I wonder about feasibility. MusikAnimal (WMF) (talk) 03:14, 6 February 2023 (UTC)
      The German text makes it more clear now.
      I know VE already lets you edit references – that's true, but the point is: each itemization in the text must be clicked and edited individually. So I believe this is indeed related to visual editor.
      --Matěj Suchánek (talk) 07:31, 6 February 2023 (UTC)
      @@Blidfried: Danke für dein Proposal! Wir würden gern sicher stellen, dass wir Deinen Vorschlag richtig verstanden haben. Beziehst du dich auch den Visual Editor? Füge gern noch so viele Details wie möglich hinzu um Dein Proposal aussagekräftiger zu machen. KSiebert (WMF) (talk) 13:41, 7 February 2023 (UTC)
      Ja, richtig im Visual Editor. Ich möchte gerne die Fußnoten am Ende der Seite direkt anklicken könne. Blidfried (talk) 13:43, 7 February 2023 (UTC)
      This is about the editing of reflists -- which cannot be done in Visual Editor. Thingofme (talk) 15:42, 11 February 2023 (UTC)
    • Being able to see the change to the reference in the new real time preview for 2010 WTE is something I find really great, so I can definitely see the appeal of this request. And maybe being able to do this would also unlock using list-defined references in VE. Izno (talk) 07:16, 13 February 2023 (UTC)

    Voting

    [edit]
    • Support Support It should be possible to edit all refs (also those defined in References section). MarMi wiki (talk) 19:50, 10 February 2023 (UTC)
    • Support Support Xbypass (talk) 19:52, 10 February 2023 (UTC)
    • Support Support Alexcs114 (talk) 20:57, 10 February 2023 (UTC)
    • Support Support Tom Ja (talk) 21:01, 10 February 2023 (UTC)
    • Support Support SeGiba (talk) 21:02, 10 February 2023 (UTC)
    • Support Support I routinely use list-defined references to keep citation clutter out of article bodies but the visual editor does not yet support these. Andrew D. (talk) 21:11, 10 February 2023 (UTC)
    • Support Support --Barcelona (talk) 21:22, 10 February 2023 (UTC)
    • Support Support TLSOSLT (talk) 21:22, 10 February 2023 (UTC)
    • Support Support Joalpe (talk) 21:47, 10 February 2023 (UTC)
    • Support Support TJ Ryba (talk) 22:03, 10 February 2023 (UTC)
    • Support Support Geert Van Pamel (WMBE) (talk) 22:23, 10 February 2023 (UTC)
    • Support Support SHB2000 (talk | contribs) 22:32, 10 February 2023 (UTC)
    • Support Support Magnoliasouth (talk) 22:42, 10 February 2023 (UTC)
    • Support Support Chetvorno (talk) 22:45, 10 February 2023 (UTC)
    • Support Support This change would be helpful because the citation numbering in VisualEditor is different from the normal article view as it skips some template-generated citations. However, this ability to edit such citations may make it difficult to implement directly clicking on the reference list BluePenguin18 🐧 ( 💬 ) 23:04, 10 February 2023 (UTC)
    • Support Support NMaia (talk) 23:17, 10 February 2023 (UTC)
    • Support Support All references should be able to be edited. Jj1691 (talk) 23:34, 10 February 2023 (UTC)
    • Support Support Huge support, it is very tedious to edit these citations. HeyElliott (talk) 23:48, 10 February 2023 (UTC)
    • Support Support much needed BhamBoi (talk) 00:01, 11 February 2023 (UTC)
      Actually, I forgot to add a wishlist item here before the time was up, so I'll add it in a reply to my comment here because it is tangentially related. VisualEditor interface for templates while editing in an efn or infobox, where you are stuck in source mode. Should be opt-in. But if you type {{ while editing in a template, it will pop up with the visual template search/selection screen, and then a visual parameter editing interface. BhamBoi (talk) 00:08, 11 February 2023 (UTC)
    • Support Support That would be a very welcome improvement Skimel (talk) 00:20, 11 February 2023 (UTC)
    • Support Support Salem Ander (talk) 00:23, 11 February 2023 (UTC)
    • Support Support. A very good ideea. --NGC 54 (talk｜contribs) 00:40, 11 February 2023 (UTC)
    • Support Support Klein Muçi (talk) 00:46, 11 February 2023 (UTC)
    • Support Support As long as all possible methods of citation (WP:CITEVAR) are supported, it would be a boon to editors (especially FA editors). LunafreyaLaphicet (talk) 00:48, 11 February 2023 (UTC)
    • Support Support Hyruspex (talk) 01:15, 11 February 2023 (UTC)
    • Support Support Yeeno (talk) 01:57, 11 February 2023 (UTC)
    • Support Support ワーナー成増 (talk) 02:13, 11 February 2023 (UTC)
    • Support Support XtexChooser (talk) 02:36, 11 February 2023 (UTC)
    • Support Support Hehua (talk) 02:50, 11 February 2023 (UTC)
    • Support Support VarietyEditor (talk) 03:29, 11 February 2023 (UTC)
    • Support Support * Pppery * it has begun 03:44, 11 February 2023 (UTC)
    • Support Support It is irritating for me every time to look at the references and turn on the editor - and then the references are just gone. When you want to correct references, this behavior of the editor is not nice, it does not comply with the rule wysiwyg. T. Wirbitzki (talk) 04:39, 11 February 2023 (UTC)
    • Support Support Libcub (talk) 05:57, 11 February 2023 (UTC)
    • Support Support Soumendrak (talk) 06:17, 11 February 2023 (UTC)
    • Support Support Janhrach (talk) 07:06, 11 February 2023 (UTC)
    • Support Support St. Andrews Drive (talk) 07:12, 11 February 2023 (UTC)
    • Support Support Nuretok (talk) 07:14, 11 February 2023 (UTC)
    • Support Support Doktor Züm (talk) 07:18, 11 February 2023 (UTC)
    • Support Support Jurbop (talk) 07:41, 11 February 2023 (UTC)
    • Support Support Especially for citations in bibliographies (under reflist or similar template) Femke (talk) 07:45, 11 February 2023 (UTC)
    • Support Support Afernand74 (talk) 07:58, 11 February 2023 (UTC)
    • Support Support Martin-78 (discutailler) 08:06, 11 February 2023 (UTC)
    • Support Support Kekavigi (talk) 08:18, 11 February 2023 (UTC)
    • Support Support V0lkanic (talk) 08:41, 11 February 2023 (UTC)
    • Support Support Szymonel (talk) 08:55, 11 February 2023 (UTC)
    • Support Support Jeeputer (talk) 08:59, 11 February 2023 (UTC)
    • Support Support Oltrepier (talk) 09:04, 11 February 2023 (UTC)
    • Support Support Grabado (talk) 09:05, 11 February 2023 (UTC)
    • Support Support Remy34 (talk) 09:07, 11 February 2023 (UTC)
    • Support Support Matěj Suchánek (talk) 09:23, 11 February 2023 (UTC)
    • Support Support This would be very much in line with VisualEditor's goal of handling the complexity of wikitext and allow a seamless, intuitive editing experience for users. Great idea! Waldyrious (talk) 09:50, 11 February 2023 (UTC)
    • Support Support //Lollipoplollipoplollipop::talk 10:01, 11 February 2023 (UTC)
    • Support Support SD0001 (talk) 10:03, 11 February 2023 (UTC)
    • Support Support I have a terrible experience for editing ref on English Wikipedia. We need a better tool for reference. Lemonaka (talk) 10:26, 11 February 2023 (UTC)
    • Support Support Liuxinyu970226 (talk) 11:20, 11 February 2023 (UTC)
    • Support Support Simeon (talk) 12:03, 11 February 2023 (UTC)
    • Support Support SunDawn (talk) 12:43, 11 February 2023 (UTC)
    • Support Support Lion-hearted85 (talk) 12:55, 11 February 2023 (UTC)
    • Support Support Although it is nice to know how to edit in source mode, Visual mode editing is much less confusing. This is a good proposal. Slaythe (talk) 13:28, 11 February 2023 (UTC)
    • Support Support OwenBlacker (Talk) 14:35, 11 February 2023 (UTC)
    • Support Support Lupe (talk) 14:44, 11 February 2023 (UTC)
    • Support Support Bluerasberry (talk) 14:57, 11 February 2023 (UTC)
    • Support Support Nerd271 (talk) 15:18, 11 February 2023 (UTC)
    • Support Support The reflist template should be fixed using VE. In the past we can fix it but now we can't do it anymore. Thingofme (talk) 15:38, 11 February 2023 (UTC)
    • Support Support Rots61 (talk) 16:05, 11 February 2023 (UTC)
    • Support Support Nehaoua (talk) 16:21, 11 February 2023 (UTC)
    • Support Support Skogshare (talk) 17:31, 11 February 2023 (UTC)
    • Support Support Conny (talk) 18:12, 11 February 2023 (UTC)
    • Support Support Thomas Kinz (talk) 20:04, 11 February 2023 (UTC)
    • Support Support I don't use the Visual Editor. But why not? De nue pw (talk) 22:04, 11 February 2023 (UTC)
    • Support Support daSupremo 22:55, 11 February 2023 (UTC)
    • Support Support Chlod (say hi!) 03:15, 12 February 2023 (UTC)
    • Support Support Gohan 03:24, 12 February 2023 (UTC)
    • Support Support Betseg (talk) 03:56, 12 February 2023 (UTC)
    • Support Support HLFan (talk) 07:07, 12 February 2023 (UTC)
    • Support Support Mauricio V. Genta (talk) 07:48, 12 February 2023 (UTC)
    • Support Support Ameisenigel (talk) 08:55, 12 February 2023 (UTC)
    • Support Support Making citing easier will foster editing. Schlind (talk) 11:25, 12 February 2023 (UTC)
    • Support Support Maxwxyz (talk) 12:48, 12 February 2023 (UTC)
    • Support Support That would be very useful. MichaelMaggs (talk) 19:25, 12 February 2023 (UTC)
    • Support Support Bencemac (talk) 20:13, 12 February 2023 (UTC)
    • Support Support P12062545 (talk) 21:10, 12 February 2023 (UTC)
    • Support Support Swehlam (talk) 23:18, 12 February 2023 (UTC)
    • Support Support আফতাবুজ্জামান (talk) 01:00, 13 February 2023 (UTC)
    • Support Support Rickinasia (talk) 01:41, 13 February 2023 (UTC)
    • Support Support BRP ever 10:05, 13 February 2023 (UTC)
    • Support Support Ropaga (talk) 10:44, 13 February 2023 (UTC)
    • Support Support JAn Dudík (talk) 17:02, 13 February 2023 (UTC)
    • Support Support Wargo (talk) 23:51, 13 February 2023 (UTC)
    • Support Support Rdrozd (talk) 23:52, 13 February 2023 (UTC)
    • Support Support +1 YjM (talk) 00:21, 14 February 2023 (UTC)
    • Support Support PenangLion (talk) 06:10, 14 February 2023 (UTC)
    • Support Support Ayumu Ozaki (talk) 10:46, 14 February 2023 (UTC)
    • Support Support It would be very useful, also to find directly where the reference is, given that the reference link isn't clickable in edit mode. ZandDev (talk) 13:14, 14 February 2023 (UTC)
    • Support Support -BRAINULATOR9 (TALK) 16:42, 14 February 2023 (UTC)
    • Support Support Barkeep49 (talk) 16:54, 14 February 2023 (UTC)
    • Support Support Very good idea! Wikibach (talk) 19:29, 14 February 2023 (UTC)
    • Support Support Labdajiwa (talk) 00:10, 15 February 2023 (UTC)
    • Support Support Nux (talk) 08:36, 15 February 2023 (UTC)
    • Support Support Saung Tadashi (talk) 10:39, 15 February 2023 (UTC)
    • Support Support Rzuwig► 11:01, 15 February 2023 (UTC)
    • Support Support cyrfaw (talk) 11:47, 15 February 2023 (UTC)
    • Support Support · · · Peter (Southwood) (talk): 11:57, 15 February 2023 (UTC)
    • Support Support PRmaster1 (talk) 13:17, 15 February 2023 (UTC)
    • Support Support ~Cybularny Speak? 13:50, 15 February 2023 (UTC)
    • Support Support I hate it when people use list-defined references because they can't be edited in Visual, this seems so obvious even for standard footnote references. Reywas92 (talk) 14:41, 15 February 2023 (UTC)
    • Support Support Laurent Meesseman (talk) 14:51, 15 February 2023 (UTC)
    • Support Support —MdsShakil (talk) 18:12, 15 February 2023 (UTC)
    • Support Support Wikiusuarios (talk) 19:34, 15 February 2023 (UTC)
    • Support Support --Polarlys (talk) 21:32, 15 February 2023 (UTC)
    • Support Support Matma Rex (talk) 22:03, 15 February 2023 (UTC)
    • Support Support Sadads (talk) 01:11, 16 February 2023 (UTC)
    • Support Support Jake01756 (talk) 07:23, 16 February 2023 (UTC)
    • Support Support YU1010 (talk) 11:19, 16 February 2023 (UTC)
    • Support Support Pas simple à mettre en œuvre... Mais ce serait hyper-utile. Michka B (talk) 14:53, 16 February 2023 (UTC)
    • Support Support Hey man im josh (talk) 15:33, 16 February 2023 (UTC)
    • Support Support JFremd (talk) 15:53, 16 February 2023 (UTC)
    • Support Support ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 17:52, 16 February 2023 (UTC)
    • Support Support Silva Selva (talk) 18:28, 16 February 2023 (UTC)
    • Support Support Sorely needed. DFlhb (talk) 19:22, 16 February 2023 (UTC)
    • Support Support Tbartovic (talk) 20:19, 16 February 2023 (UTC)
    • Support Support Gillum (talk) 23:17, 16 February 2023 (UTC)
    • Support Support Stardustnite (talk) 08:47, 17 February 2023 (UTC)
    • Support Support Gubeko (talk) 10:06, 17 February 2023 (UTC)
    • Support Support ~ Amory (u • t • c) 16:33, 17 February 2023 (UTC)
    • Support Support Kurmanbek 💬 16:54, 17 February 2023 (UTC)
    • Support Support Mitch199811 (talk) 18:25, 17 February 2023 (UTC)
    • Support Support Dubstar (talk) 18:32, 17 February 2023 (UTC)
    • Support Support Toughpigs (talk) 19:08, 17 February 2023 (UTC)
    • Support Support —‍CX Zoom (A/अ/অ) (let's talk|contribs) 19:16, 17 February 2023 (UTC)
    • Support Support Fuchs B (talk) 19:52, 17 February 2023 (UTC)
    • Support Support David Eppstein (talk) 21:50, 17 February 2023 (UTC)
    • Support Support Lightoil (talk) 02:59, 18 February 2023 (UTC)
    • Support Support Dmytro Tvardovskyi (talk) 03:05, 18 February 2023 (UTC)
    • Support Support Thastp (talk) 10:37, 18 February 2023 (UTC)
    • Support Support Wire723 (talk) 11:00, 18 February 2023 (UTC)
    • Support Support It would be nice to declutter the body text of the page wikicode from all the reference code text and replacing the reference text by a pointer such as <ref name="text">. This first requires to move all the references at the end of the page in the section Reference as commonly done by word processors coupled to a reference management software. This is a long awaited feature from Wikipedia and should be a high priority task. A bot is the most appropriate tool to do such a repetitive and tedious task. Shinkolobwe (talk) 12:12, 18 February 2023 (UTC)
    • Support Support Herbert Ortner (talk) 12:20, 18 February 2023 (UTC)
    • Support Support Vulcan❯❯❯Sphere! 15:21, 18 February 2023 (UTC)
    • Support Support WhinyTheYounger (talk) 20:33, 18 February 2023 (UTC)
    • Support Support Albinfo (talk) 20:57, 18 February 2023 (UTC)
    • Support Support PamD (talk) 23:52, 18 February 2023 (UTC)
    • Support Support Jj14 (talk) 11:41, 19 February 2023 (UTC)
    • Support Support Jklamo (talk) 11:58, 19 February 2023 (UTC)
    • Support Support Unexpectedlydian (talk) 14:55, 19 February 2023 (UTC)
    • Support Support schurdl (talk) 15:46, 19 February 2023 (UTC)
    • Support Support Ezlev (talk) 18:43, 19 February 2023 (UTC)
    • Support Support Zsinj (talk) 02:25, 20 February 2023 (UTC)
    • Support Support Hans5958 (talk) 02:55, 20 February 2023 (UTC)
    • Support Support Cmarsch (talk) 06:23, 20 February 2023 (UTC)
    • Support Support Supporting 17387349L8764 (talk) 08:39, 20 February 2023 (UTC)
    • Support Support Would this allow inexperienced editors just to add references on a stub? (better some citations than none) Wakelamp (talk) 10:42, 20 February 2023 (UTC)
    • Support Support Nashona (talk) 14:50, 20 February 2023 (UTC)
    • Support Support IMHO all the references should be migrated to Wikidata; on the wikis should only remain the calling of their wikidata items. There is no need to maintain references in each and every wiki on its own. --Matthiasb (talk) 14:58, 20 February 2023 (UTC)
    • Support Support Kyucasio (talk) 22:55, 20 February 2023 (UTC)
    • Support Support —מקף⁻ණ (Hyphen) 23:17, 20 February 2023 (UTC)
    • Support Support Lancine.kounfantoh.fofana (talk) 23:27, 20 February 2023 (UTC)
    • Support Support --Adam Hauner (talk) 00:25, 21 February 2023 (UTC)
    • Support Support Goldsztajn (talk) 01:36, 21 February 2023 (UTC)
    • Support Support Korhoj (talk) 02:33, 21 February 2023 (UTC)
    • Support Support Dr vulpes (talk) 06:29, 21 February 2023 (UTC)
    • Support Support Bnichols23 (talk) 17:06, 21 February 2023 (UTC)
    • Support Support Serieminou (talk) 22:31, 21 February 2023 (UTC)
    • Support Support ~ Seb35 [^_^] 11:55, 22 February 2023 (UTC)
    • Support Support Chatul (talk) 12:15, 22 February 2023 (UTC)
    • Support Support مرتضا (talk) 15:01, 22 February 2023 (UTC)
    • Support Support Fcastillo (talk) 22:03, 22 February 2023 (UTC)
    • Support Support. —— Eric Liu（Talk） 02:20, 23 February 2023 (UTC)
    • Support Support GoingBatty (talk) 03:25, 23 February 2023 (UTC)
    • Support Support Althair (talk) 04:29, 23 February 2023 (UTC)
    • Support Support Lionel Scheepmans ✉ Contact (Fr-N, En-3, Pt-3) 20:41, 23 February 2023 (UTC)
    • Support Support SoupePrimordiale (talk) 07:42, 24 February 2023 (UTC)
    • Support Support OGPawlis (talk) 10:31, 24 February 2023 (UTC)

    Linking of citing tool with Wikidata

    Discussion

    [edit]
    • This is allready possible. It have to be just enabled on certain wiki. I am just affraid it would not have the expected outcome. We were researching this last year for Czech language projects and we came to conclusion that the system is way difficult to bring good outcome. I.E. if you are generating citation using QID, Citoid in VisuaEditor use Zotero, which is using a template, but for example this template is not comaptible with templates on the projects (at least not so much compatible with Czech templates). So it brings you pretty bad outcome. That is actually surprising because both wiki and CSL template points out they respect the same ISO standard. So some parts of output could me manipulated on each wiki to have better outcome, but some cannot, as there are limitations. So in this sence I would refolmulate the wish the foundation, does not use Zoter or CSL to map from Wikdata (now its from Wikidata to CSL and from CSL to wiki templates), but directly map from Wikidata to wiki templates. --Juandev (talk) 21:23, 23 January 2023 (UTC)
      • I am no programmer, and I don't understand much of what you are saying, apart from "it's complicated". I'm a friend of the salami tactic: so a first step could be to create per button the text of the reference (<ref>{{cite book |title=bla bla |etc. }}</ref>) in Wikidata. Then the user could move it to Wikipedia per copy/paste. That shouldn't be so difficult to program [said the non programmer...] --Ecelan (talk) 22:17, 28 January 2023 (UTC)
    • I support any kind of citation database that means that primary information is entered just once and stored and that all other displayed citations are drawn for this one source. Some notion of versioning would assist, so later modifications to the primary information would not result in editor‑confirmed details being summarily overwritten. I made some notes and provided a UML diagram here to indicate some preliminary design requirements. RobbieIanMorrison (talk) 22:26, 23 January 2023 (UTC)
    • I would need to see how this related to and worked alongside the OCLC record. I would actually start with getting the Wikidata information added to the Cite template. Gusfriend (talk) 01:07, 24 January 2023 (UTC)
      • I would actually start with getting the Wikidata information added to the Cite template. That is exactly what I was proposing. You open the citing tool, chose there a title, ISBN number or Wikidata Q-Number, and everything else is filled out automatically. --Ecelan (talk) 22:17, 28 January 2023 (UTC)
    • en:Template:Cite Q addresses this problem. It is intended to be transferable and is already used in a couple of dozen other projects. There is an outstanding request for Citoid to use Cite Q (also at phab:T289287). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:45, 1 February 2023 (UTC)
      I have another realisation of Wikidata driven source template for Wikidata: :ru:Модуль:CiteGost. So Cite Q is not the only one. D6194c-1cc (talk) 17:39, 12 February 2023 (UTC)
    • Same does de:Modul:Literatur supporting a couple of templates. But how could we offer an interface in a wp editor providing a wd search functionality and a button [create new entry] opening a new wd window if a book isn't in wd yet?
    • on huwiki the w:Sablon:Cite Q is used in FOUR articles only. Doubt anyone knows about its existence or you can get people to try and use a new type of template when they are already used to the others. A solution that you can build into existing ones would be more welcome. Xia (talk) 09:30, 11 February 2023 (UTC)
      • @Xia: Cite Q can be built into existing solutions. I have noted above an outstanding request for Citoid to use Cite Q. If hu.Wikipedia is your home project, you can use it there and write about it in Hungarian (its documentation is not yet translated from English), to tell others that it is available. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:35, 13 February 2023 (UTC)
    • Enable (or allow) to use citations between languages, e.g. when translating an article, for translators. Jj14 (talk) 11:38, 19 February 2023 (UTC)

    Voting

    [edit]
    • Support Support Poslovitch (talk) 00:20, 11 February 2023 (UTC)
    • Support Support --NGC 54 (talk｜contribs) 00:43, 11 February 2023 (UTC)
    • Support Support Tgr (talk) 03:14, 11 February 2023 (UTC)
    • Oppose Oppose We already have Template:Cite Q (Q22321052). I fail to see the value of more technical effort being spent reimplementing the same thing. * Pppery * it has begun 03:44, 11 February 2023 (UTC)
    • Support Support Libcub (talk) 06:03, 11 February 2023 (UTC)
    • Support Support Schmila (talk) 08:48, 11 February 2023 (UTC)
    • Support Support Exilexi (talk) 09:24, 11 February 2023 (UTC)
    • Support Support Xia (talk) 09:30, 11 February 2023 (UTC)
    • Support Support Radlna15 (talk) 10:01, 11 February 2023 (UTC)
    • Support Support CaféBuzz (talk) 10:09, 11 February 2023 (UTC)
    • Support Support Alhadis (talk) 12:27, 11 February 2023 (UTC)
    • Support Support Lupe (talk) 14:48, 11 February 2023 (UTC)
    • Support Support Bluerasberry (talk) 14:58, 11 February 2023 (UTC)
    • Support Support This is currently possible and implementation is not difficult. Thingofme (talk) 15:45, 11 February 2023 (UTC)
    • Support Support It may be better to have a separate Wikibase instance for this - for scaling reasons - rather than using Wikidata, but I'm fully in favor of this Nicereddy (talk) 16:55, 11 February 2023 (UTC)
    • Support Support Litev (talk) 17:25, 11 February 2023 (UTC)
    • Support Support Conny (talk) 18:11, 11 February 2023 (UTC)
    • Support Support Doesn't have to be in Wikidata but it would be helpful to have a database somewhere. Several sources I've used do not have the information stored correctly (e.g. missing authors). I've gotten around it by making myself a list of citations so I don't have to fix it each time, but I doubt most people check these details. Some of these are books I've seen used on several other pages OddBiologist (talk) 21:15, 11 February 2023 (UTC)
    • Support Support daSupremo 22:57, 11 February 2023 (UTC)
    • Support Support Mauricio V. Genta (talk) 07:48, 12 February 2023 (UTC)
    • Support Support Schlind (talk) 11:26, 12 February 2023 (UTC)
    • Support Support Fvtvr3r (talk) 14:32, 12 February 2023 (UTC)
    • Support Support Rickinasia (talk) 01:42, 13 February 2023 (UTC)
    • Support Support Ropaga (talk) 10:44, 13 February 2023 (UTC)
    • Support Support Shkif (talk) 18:58, 13 February 2023 (UTC)
    • Support Support JAn Dudík (talk) 21:02, 13 February 2023 (UTC)
    • Support Support Rodolfo Hermans (talk) 09:15, 14 February 2023 (UTC)
    • Support Support Just N. (talk) 14:26, 14 February 2023 (UTC)
    • Support Support Grdhrakuta (talk) 03:01, 15 February 2023 (UTC)
    • Support Support Rzuwig► 11:01, 15 February 2023 (UTC)
    • Support Support cyrfaw (talk) 11:56, 15 February 2023 (UTC)
    • Support Support Though it would have to take into account the issues that have slowed {{Cite Q}} implementation. Daniel Case (talk) 03:27, 16 February 2023 (UTC)
    • Support Support Michka B (talk) 16:06, 16 February 2023 (UTC)
    • Support Support Gillum (talk) 23:17, 16 February 2023 (UTC)
    • Support Support Kurmanbek 💬 16:53, 17 February 2023 (UTC)
    • Support Support Fuchs B (talk) 19:54, 17 February 2023 (UTC)
    • Support Support Kpjas (talk) 07:39, 18 February 2023 (UTC)
    • Support Support Shinkolobwe (talk) 11:55, 18 February 2023 (UTC)
    • Support Support Herbert Ortner (talk) 12:19, 18 February 2023 (UTC)
    • Support Support Robby (talk) 15:05, 18 February 2023 (UTC)
    • Support Support Albinfo (talk) 20:58, 18 February 2023 (UTC)
    • Support Support Jean Brasse (talk) 04:50, 19 February 2023 (UTC)
    • Support Support Jj14 (talk) 11:38, 19 February 2023 (UTC)
    • Support Support Jklamo (talk) 11:58, 19 February 2023 (UTC)
    • Support Support Mesidast (talk) 10:08, 20 February 2023 (UTC)
    • Support Support — Draceane talkcontrib. 11:08, 20 February 2023 (UTC)
    • Support Support Nashona (talk) 14:49, 20 February 2023 (UTC)
    • Support Support I proposed this a couple of years ago in a slightly different way. Thanks for reproposing. It is nonsense that we maintain references in each wiki on its own. Besides of that citations are data sets on their own which occasionally are entered into WD. Why not make that mandatory? However it needs to be addressed, that each cited source class is using its own identifier. For example, isbn for books, issn for journals, doi for articles, urls for web pages and to implement intelligent fall backs, eg. for medium age literature. --Matthiasb (talk) 15:04, 20 February 2023 (UTC)
    • Support Support --Lamiot (talk) 11:10, 21 February 2023 (UTC)
    • Support Support Bnichols23 (talk) 17:06, 21 February 2023 (UTC)
    • Support Support Plus, I would love it if it could support for other type of publications, such as dissertations! There are already five Wikidata projects on this (Stanford U, LSE, Washington, New Zealand) and I can see many universities/libraries getting on board if they can see that their Open Access dissertations can be properly cited! Silva Selva (talk) 23:31, 21 February 2023 (UTC)
    • Support Support Chatul (talk) 12:12, 22 February 2023 (UTC)
    • Support Support Michaelboerman420 (talk) 14:32, 22 February 2023 (UTC)
    • Support Support Snowmanonahoe (talk) 14:36, 22 February 2023 (UTC)
    • Support Support Phil Buchenrauch (talk) 15:02, 22 February 2023 (UTC)
    • Support Support Takamaxa (talk) 15:05, 22 February 2023 (UTC)
    • Support Support. —— Eric Liu（Talk） 02:20, 23 February 2023 (UTC)
    • Support Support Althair (talk) 04:29, 23 February 2023 (UTC)
    • Support Support Jonathanischoice (talk) 20:28, 23 February 2023 (UTC)
    • Support Support Lionel Scheepmans ✉ Contact (Fr-N, En-3, Pt-3) 20:43, 23 February 2023 (UTC)
    • Support Support OGPawlis (talk) 10:31, 24 February 2023 (UTC)
    • Support Support CmdrDan (talk) 17:31, 24 February 2023 (UTC)

    Prompt for page number(s) for compatible cite sources (e.g. book, journal)

    Discussion

    [edit]
    • With this, make it easier to add page numbers for quotations. For instance, I might be citing a book throughout, but some sections are from a certain page or chapter. There should only be one reference, but the citations can provide the page numbers. I see too many people making individual references for each page number or leaving out page numbers altogether. Both cause problems. Significa liberdade (talk) 21:32, 10 February 2023 (UTC)
    • w:Template:Cite book/TemplateData "pages" is already marked as "suggested" instead of "optional", so the field shows up by default when citing a book. What did you guys have in mind for the technical implementation of this wish? Did you want to move "pages" up to make it more prominent, display an extra popup, etc? –Novem Linguae (talk) 04:43, 13 February 2023 (UTC)
      @Novem Linguae: good question. This is most useful for when you automatically generate a citation using ISBN numbers. I just realised that automatically generating citations for reports usually doesn't work, so maybe this wish is not as relevant for it. Possibly, it could also be triggered when you click on an already existing book or report citation without a page number. In that case, care has to be taken that the editor knows they're adding the page number for all instances of that source being used on the page (at least, before WMDE implements this wish.) Femke (talk) 17:06, 14 February 2023 (UTC)

    Voting

    [edit]
    • Support Support Tom Ja (talk) 21:03, 10 February 2023 (UTC)
    • Support Support Magnoliasouth (talk) 22:43, 10 February 2023 (UTC)
    • Support Support Chetvorno (talk) 22:45, 10 February 2023 (UTC)
    • Support Support NMaia (talk) 23:18, 10 February 2023 (UTC)
    • Support Support The Phabricator ticket mock-up would definitely encourage adding page numbers and time stamps before clicking insert. As for avoiding separate citations to different portions of the same book/video, the associated parameters should have their description text altered to outright instruct this point. For example, changing the Cite book template's "Page(s) cited" description to use a parenthetical plural for "The range(s) of pages in the source that support the content (not an indication of the number of pages in the source); displays after 'pp.'; use either page= or pages=, but not both", encouraging distinct ranges to be used in the same citation BluePenguin18 🐧 ( 💬 ) 23:22, 10 February 2023 (UTC)
    • Support Support ARandomName123 (talk) 23:57, 10 February 2023 (UTC)
    • Support Support It is time consuming to use harvsp or sfn to indicate page numbers and create one ref per page. Skimel (talk) 00:22, 11 February 2023 (UTC)
    • Support Support --NGC 54 (talk｜contribs) 00:41, 11 February 2023 (UTC)
    • Support Support Especially for articles with highly contestable sections (including one that would be targeted for fake news and other kinds of misinformation/disinformation), this quirk will remind editors of the importance to veracity. LunafreyaLaphicet (talk) 00:53, 11 February 2023 (UTC)
    • Support Support 26 Ramadan (talk) 01:45, 11 February 2023 (UTC)
    • Support Support Yeeno (talk) 01:58, 11 February 2023 (UTC)
    • Support Support Only for Template:Cite_book. Open-access journals are popular on wiki, and they frequently don't have page numbers. (They have "article numbers" instead, and you don't need to know the article number to find the article.) WhatamIdoing (talk) 01:59, 11 February 2023 (UTC)
      That would work for me. The two most important ones are the books and reports. Scientific articles are often shorter, and it can be a pain to find the pdf version (which usually exists, but always). Femke (talk) 07:43, 11 February 2023 (UTC)
    • Support Support Lalalalala7 (talk) 02:15, 11 February 2023 (UTC)
    • Support Support XtexChooser (talk) 02:36, 11 February 2023 (UTC)
    • Support Support * Pppery * it has begun 03:45, 11 February 2023 (UTC)
    • Support Support Kirche (talk) 04:40, 11 February 2023 (UTC)
    • Support Support EpicPupper (talk) 05:12, 11 February 2023 (UTC)
    • Support Support Libcub (talk) 05:59, 11 February 2023 (UTC)
    • Support Support Soumendrak (talk) 06:18, 11 February 2023 (UTC)
    • Support Support St. Andrews Drive (talk) 07:13, 11 February 2023 (UTC)
    • Support Support Doktor Züm (talk) 07:20, 11 February 2023 (UTC)
    • Support Support Jurbop (talk) 07:26, 11 February 2023 (UTC)
    • Support Support Afernand74 (talk) 07:59, 11 February 2023 (UTC)
    • Support Support Martin-78 (discutailler) 08:05, 11 February 2023 (UTC)
    • Support Support --Jim Hokins (talk) 08:10, 11 February 2023 (UTC)
    • Support Support Szymonel (talk) 08:56, 11 February 2023 (UTC)
    • Support Support Oltrepier (talk) 09:02, 11 February 2023 (UTC)
    • Support Support Remy34 (talk) 09:07, 11 February 2023 (UTC)
    • Support Support HHill (talk) 09:35, 11 February 2023 (UTC)
    • Support Support Fagairolles 34 (talk) 10:19, 11 February 2023 (UTC)
    • Support Support Timawesomeness (talk) 11:10, 11 February 2023 (UTC)
    • Support Support Lion-hearted85 (talk) 12:58, 11 February 2023 (UTC)
    • Support Support Guerillero Parlez Moi 13:58, 11 February 2023 (UTC)
    • Support Support Nerd271 (talk) 15:18, 11 February 2023 (UTC)
    • Support Support This proposal could be better for page number (sfn/harvnb) to be added to cite sources like book/journal which may be digitalized. Thingofme (talk) 15:46, 11 February 2023 (UTC)
    • Support Support Litev (talk) 17:23, 11 February 2023 (UTC)
    • Support Support Thomas Kinz (talk) 19:58, 11 February 2023 (UTC)
    • Support Support Sladdusaw (talk) 20:12, 11 February 2023 (UTC)
    • Support Support De nue pw (talk) 22:08, 11 February 2023 (UTC)
    • Support Support daSupremo 22:57, 11 February 2023 (UTC)
    • Support Support Ahkei (talk) 01:27, 12 February 2023 (UTC)
    • Support Support Gohan 03:42, 12 February 2023 (UTC)
    • Support Support Betseg (talk) 03:57, 12 February 2023 (UTC)
    • Support Support HLFan (talk) 07:09, 12 February 2023 (UTC)
    • Support Support Mauricio V. Genta (talk) 07:48, 12 February 2023 (UTC)
    • Support Support Useful and probably quite easy to implement. MichaelMaggs (talk) 19:24, 12 February 2023 (UTC)
    • Support Support P12062545 (talk) 21:10, 12 February 2023 (UTC)
    • Support Support Lalaithan (talk) 21:43, 12 February 2023 (UTC)
    • Support Support Swehlam (talk) 23:19, 12 February 2023 (UTC)
    • Support Support Natalius (talk) 04:42, 13 February 2023 (UTC)
    • Support Support Tacsipacsi (talk) 13:56, 13 February 2023 (UTC)
    • Support Support Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:28, 13 February 2023 (UTC)
    • Support Support Gillum (talk) 17:54, 13 February 2023 (UTC)
    • Support Support · · · Peter (Southwood) (talk): 18:33, 13 February 2023 (UTC)
    • Support Support Shkif (talk) 18:58, 13 February 2023 (UTC)
    • Support Support Log.base (talk) 02:24, 14 February 2023 (UTC)
    • Support Support SpacedShark (talk) 05:39, 14 February 2023 (UTC)
    • Support Support PenangLion (talk) 06:09, 14 February 2023 (UTC)
    • Support Support Barkeep49 (talk) 16:54, 14 February 2023 (UTC)
    • Support Support It's a great idea! Wikibach (talk) 19:28, 14 February 2023 (UTC)
    • Support Support Labdajiwa (talk) 00:15, 15 February 2023 (UTC)
    • Support Support cyrfaw (talk) 11:56, 15 February 2023 (UTC)
    • Support Support ~Cybularny Speak? 13:51, 15 February 2023 (UTC)
    • Support Support --Polarlys (talk) 21:33, 15 February 2023 (UTC)
    • Support Support Sadads (talk) 01:10, 16 February 2023 (UTC)
    • Support Support El monty (talk) 10:03, 16 February 2023 (UTC)
    • Support Support YU1010 (talk) 11:17, 16 February 2023 (UTC)
    • Support Support Michka B (talk) 14:54, 16 February 2023 (UTC)
    • Support Support Hey man im josh (talk) 15:30, 16 February 2023 (UTC)
    • Support Support JFremd (talk) 15:53, 16 February 2023 (UTC)
    • Support Support DFlhb (talk) 19:22, 16 February 2023 (UTC)
    • Support Support ~ Amory (u • t • c) 16:33, 17 February 2023 (UTC)
    • Support Support Dubstar (talk) 18:31, 17 February 2023 (UTC)
    • Support Support David Eppstein (talk) 21:50, 17 February 2023 (UTC)
    • Support Support Rconroy (talk) 22:28, 17 February 2023 (UTC)
    • Support Support Sturmvogel 66 (talk) 00:40, 18 February 2023 (UTC)
    • Support Support Kpjas (talk) 07:38, 18 February 2023 (UTC)
    • Support Support Thastp (talk) 10:38, 18 February 2023 (UTC)
    • Support Support Herbert Ortner (talk) 12:21, 18 February 2023 (UTC)
    • Support Support Vulcan❯❯❯Sphere! 15:21, 18 February 2023 (UTC)
    • Support Support —‍Mdaniels5757 (talk • contribs) 17:57, 18 February 2023 (UTC)
    • Support Support Jean Brasse (talk) 04:49, 19 February 2023 (UTC)
    • Support Support Jj14 (talk) 11:44, 19 February 2023 (UTC)
    • Support Support Jklamo (talk) 12:00, 19 February 2023 (UTC)
    • Support Support Unexpectedlydian (talk) 14:54, 19 February 2023 (UTC)
    • Support Support schurdl (talk) 15:43, 19 February 2023 (UTC)
    • Support Support Seems far-fetched, but we'll see... Hans5958 (talk) 02:54, 20 February 2023 (UTC)
    • Support Support — Draceane talkcontrib. 11:08, 20 February 2023 (UTC)
    • Support Support Lancine.kounfantoh.fofana (talk) 23:23, 20 February 2023 (UTC)
    • Support Support Bnichols23 (talk) 17:07, 21 February 2023 (UTC)
    • Support Support Serieminou (talk) 22:30, 21 February 2023 (UTC)
    • Support Support Also prompt for section and section-url. Chatul (talk) 12:11, 22 February 2023 (UTC)
    • Support Support Michaelboerman420 (talk) 14:33, 22 February 2023 (UTC)
    • Support Support Morten Haan (talk) 18:15, 22 February 2023 (UTC)
    • Support Support. —— Eric Liu（Talk） 02:22, 23 February 2023 (UTC)
    • Support Support Sennecaster (talk) 02:29, 23 February 2023 (UTC)
    • Support Support Althair (talk) 04:29, 23 February 2023 (UTC)
    • Support Support Lionel Scheepmans ✉ Contact (Fr-N, En-3, Pt-3) 20:43, 23 February 2023 (UTC)
    • Doubtful It is doubtful Not all books have page numbers (online editions, for example), so these automatic prompts might get very annoying. Be gentle! SoupePrimordiale (talk) 07:48, 24 February 2023 (UTC)

    Warn when adding a url reference that matches the SpamBlacklist

    Discussion

    [edit]
    • This should probably be covered by T315072. Nardog (talk) 22:26, 24 January 2023 (UTC)
      • +1, @Nardog; great spot. Also, for some additional context, the Editing Team is actively working on a new project that I think this wish could fit neatly within. We're calling it "edit check" and the idea is to create ways for experienced volunteers to create "checks" that, when triggered, would offer people (particularly newcomers) actionable feedback about Wikipedia policies while they are editing. Please ping me if this sounds interesting to you; within the next week we'll be starting conversations on-wiki about this work. Oh, and if there are particular people who you think might value from participating in this project, we'd value knowing. PPelberg (WMF) (talk) 23:01, 1 February 2023 (UTC)

    Voting

    [edit]

    Auto-merging the identical references in HTML output

    Discussion

    [edit]
    • On enwiki, this is largely carried out by editors through :en:Wikipedia:reFill or via bot :en:User:Citation bot (the relevant bot task seems disabled though). It would be great to have something similar baked in during the publishing processing. Robertsky (talk) 18:28, 10 February 2023 (UTC)
      reFill can generate lots of errors, which is why it's done manually as the output needs to be checked. ActivelyDisinterested (talk) 21:21, 11 February 2023 (UTC)
      :en:Wikipedia:reFill:
      reFill NG is broken for English! Revert to reFill. ,,,, 0mtwb9gd5wx (talk) 04:08, 16 February 2023 (UTC)
    • Would this be just for visual editor edits? That might be the best way to do it. When editing with VE, the user expects some magic to happen with references. When editing the raw wikicode, the user does not want or expect any magic to happen. They want exactly what they type to be published. –Novem Linguae (talk) 21:45, 10 February 2023 (UTC)
      @Robertsky: For only VE? No. The output is not identical to the code. Currently, here are the most violator: phabricator:T246960. Dušan Kreheľ (talk) 18:57, 11 February 2023 (UTC)
      I think you meant to ping @Novem Linguae. Robertsky (talk) 18:58, 11 February 2023 (UTC)
    • This should be resolved in the source, not in the rendered HTML. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:28, 13 February 2023 (UTC)
      Yes, this seems more appropriate for a bot to fix in source than a behind-the-scenes rendering patch. David Eppstein (talk) 21:51, 17 February 2023 (UTC)

    Voting

    [edit]

    Community Wishlist Survey 2023/Editing Community Wishlist Survey 2023/Miscellaneous Community Wishlist Survey 2023/Mobile and apps Community Wishlist Survey 2023/Multimedia and Commons Community Wishlist Survey 2023/Notifications Community Wishlist Survey 2023/Reading Community Wishlist Survey 2023/Search Community Wishlist Survey 2023/Translation Community Wishlist Survey 2023/Watchlists Community Wishlist Survey 2023/Wikidata Community Wishlist Survey 2023/Wikisource Community Wishlist Survey 2023/Wiktionary

    Retrieved from "https://meta.wikimedia.org/w/index.php?title=User:TheresNoTime/1&oldid=24523859"