Wikipedia

Wikipedia:Village pump (idea lab)/Archive 37

< Wikipedia:Village pump (idea lab)
Latest comment: 3 years ago by Mz7 in topic Default Protection of Closed RFAs
Village pump (idea lab) archive  

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

< Older discussions · Archives: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61

Footnote markers should not be copied when copying from an article

Latest comment: 3 years ago10 comments7 people in discussion

When you paste text into messaging apps and some word processors, the footnote markers stop being superscripts and show up with a normal baseline, which "makes the[1] text somewhat[2] illegible[3]".

It's good for pasted passages to refer to their sources, but more often than not, the medium that the Wikipedia passage is being pasted to omits the link (e.g. text messages where hyperlinks become normal text, or printed paper where hyperlinks are useless).

Footnote markers being copied is more often a nuisance than a useful thing, so I propose that they not be copiable under regular circumstances (maybe a keyboard shortcut or a toggle could make them copiable). — Preceding unsigned comment added by 207.172.131.14 (talk) 03:05, 2 July 2021 (UTC)

I highly doubt that's possible. Graham87 08:09, 2 July 2021 (UTC)
Graham87 is right. There's no way to do this. 🐔 Chicdat  Bawk to me! 10:31, 2 July 2021 (UTC)
Coincidentally, it's helpful for identifying particularly lazy plagiarists. Nosebagbear (talk) 12:34, 2 July 2021 (UTC)
It is possible, by applying the CSS sup.reference { user-select: none; }. However I doubt it's actually desirable: as Nosebagbear says we don't want to make it too easy for plagiarists. the wub "?!" 14:16, 2 July 2021 (UTC)
Why do we care whether people plagiarize from Wikipedia?207.172.131.14 (talk) 16:53, 3 July 2021 (UTC)
Uh... let's see, because it's AGAINST THE LAW?! 🐔 Chicdat  Bawk to me! 10:14, 4 July 2021 (UTC)
? in general, "plagiarism" isn't against the law, though copyright violations may be. — xaosflux Talk 10:56, 6 July 2021 (UTC)
Oh. Maybe I was confusing the two. They are similar. 🐔 Chicdat  Bawk to me! 12:48, 6 July 2021 (UTC)
Nosebagbear, Good point. S Philbrick(Talk) 16:10, 3 July 2021 (UTC)

WP:LIBRARY, Research Sources, and Fundraising

Latest comment: 3 years ago5 comments4 people in discussion

The Wikipedia Library has a horrendous backlog of suggested sources. So I'm curious about the idea of fundraising (via some external platform) so the wiki/editors can purchase institutional-type access to various scientific journals and databases for the Library. Access to academic publications and resources is absolutely critical to developed well-sourced content in a significant amount of subject matter that isn't covered in the news media but is covered in those publications. Additionally certain high-quality news cites are also now under paywall and if the funds can be raised, the Library could also potentially offer access to these very important sources.

I'm curious about implementing this in a couple ways:

  • Centralized crowdfunding for specific source databases
  • Independent donations by editors/organizations which are then used to acquire access to those source databases
  • Possible request by the community to WMF to allocate funds for specific source databases

If anyone has input on this, please do. ~Gwennie🐈｟💬 📋｠ 23:46, 4 July 2021 (UTC)

  • A good first step would be to get some costings for institutional access for, say, the 10 most wanted ones that we don't have. I'm sure someone who is adept at putting together WMF grant applications can be found who knows how to thread the needle - the use-case is obvious, but we'd want to be clear that we're going to need the money every year. It would be a shame to need to split off our own fundraising for this, so it's good to at least try out the central funding route, but if it doesn't work, a worked out scheme for "crowdfunding will be used to get x number of spaces access to the following y projects, working in order". Perhaps do an initial fundraising, lasting for, say, a month, then 10 months later, do it again (then every 11/12 months from that point)? Nosebagbear (talk) 00:38, 5 July 2021 (UTC)
    I think this is more likely to succeed if we go through existing channels than if we try to establish something new. I agree that the backlog of suggested sources is a major issue. The WMF has a lot of financial/staff resources at their disposal, and I think it would be a good use of them to negotiate access to more sources or pay for them if the sources are unwilling to donate. {{u|Sdkb}} talk 02:48, 7 July 2021 (UTC)
    Sdkb, Nosebagbear I'm beginning to catalog all sources currently on the backlog (minus duplicates) and categorize them, send out emails to the source contacts, and attach information and pricing to what I can find. Anyone is free to contribute to the list at User:Gwennie-nyan/WikiLibrary Access Costs. ~Gwennie🐈｟💬 📋｠ 04:16, 7 July 2021 (UTC)
  • Wow, this has been a wild day reading though the Idea Lab. I’ve got an idea that might supplement whatever action resulting in this discussion. As I mentioned to the folks over at WP:Discord, in the future, I am planning to propose a sort of “paywalled resource exchange”, probably which will be across all WMF projects, that would supplement REX by having a “last-resort” place where editors, after asking for help at appropriate venues (e.g. REX), have their resources paid for (hopefully through a WMF grant). 🐶 EpicPupper (he/him | talk, FAQ, contribs | please use {{ping}} on reply) 18:28, 7 July 2021 (UTC)

Relatives from wikidata

Latest comment: 3 years ago4 comments4 people in discussion

i noticed wikidata has property for relationships, is it better to show them in a nav bar template like baike https://baike.baidu.com/item/%E5%94%90%E7%BA%B3%E5%BE%B7%C2%B7%E7%89%B9%E6%9C%97%E6%99%AE?fromtitle=Donald+Trump&fromid=7895491 bi (talk) 05:49, 30 June 2021 (UTC)

Oppose We are not Baidu Baike. --🏳️‍🌈 Chicdat  Bawk to me! 10:42, 30 June 2021 (UTC)
Chicdat, the idea lab is not the place for polling. 15 (talk) 15:22, 4 July 2021 (UTC)
This is not an appropriate venue for the English Wikipedia idea lab. Instead, try a centralized discussion venue for Wikidata. 🐶 EpicPupper (he/him | talk, FAQ, contribs | please use {{ping}} on reply) 18:30, 7 July 2021 (UTC)

Put banners on pages signifying momentous view counts?

Latest comment: 3 years ago14 comments9 people in discussion
  Moved from WP:VPR § Put banners on pages signifying momentous view counts?
 – {{u|Sdkb}} talk 03:04, 30 June 2021 (UTC)

Page hits some number of hundreds of thousands of views, or hits 1 million views, add a banner for the day that "This page has hit 1 million views"? And similar increments, 2 million, 5 million, 10, 20, 50, and so on. Is that something we'd do, or could do? Hyperbolick (talk) 09:02, 29 June 2021 (UTC)

  • There's no reason it wouldn't be possible from a technical standpoint, but I just don't see what the purpose of it would be. We already have the WP:Top 25 Report for weekly pageviews, and the WP:Top 50 Report for yearly page views. I don't think that "This article has received X page views" is useful information for readers, it seems more like social media or self-congratulatory celebration than useful encyclopaedic information. Also the current page view tool only has data going back to 2015, the previous one only went back to 2011 and the original implementation completely broke when the site started using multiple servers so we have no idea how many views a lot of these pages actually have. 192.76.8.91 (talk) 14:04, 29 June 2021 (UTC)
Hyperbolick,
This is good example of a suggestion that would be better started in the idea lab which was specifically designed to bat around and debate alternatives before settling on a specific proposal which should be largely voted up or down. I think there is some merit in the concept but would love to see it brainstormed before settling on a specific proposal. S Philbrick(Talk) 18:13, 29 June 2021 (UTC)
@Hyperbolick, do you think this would interest readers or editors? WhatamIdoing (talk) 20:33, 29 June 2021 (UTC)
Would think readers would find it cool. Actually, maybe both. Do editors usually have any idea when pages they’ve made or worked on hit milestones? Hyperbolick (talk) 01:52, 30 June 2021 (UTC)
I just don't see the use of this. @Hyperbolick: What problem does this solve? Anyway, if you'd like to see a page's pageviews, all you have to do is go to XTools Pageview Statistics. To see the views of this page, for instance, it's right here. 🏳️‍🌈 Chicdat  Bawk to me! 10:00, 30 June 2021 (UTC)
It would solve much the same problem as taking a break to watch the sunset solves, or pausing along a jog to smell a rosebush. Hyperbolick (talk) 08:32, 2 July 2021 (UTC)
I don't see any similarity. 🐔 Chicdat  Bawk to me! 10:33, 2 July 2021 (UTC)
baike has this, shows views ,talk page count, https://baike.baidu.com/item/%E9%BB%84%E5%AE%B6%E9%A9%B9/77734
top counter shows number of "flowers sent" to the article similar Basic Attention Token automatic contribute bi (talk) 05:26, 30 June 2021 (UTC)
Wouldn't be difficult to do so here, would it? Hyperbolick (talk) 08:25, 30 June 2021 (UTC)
We are not Baidu Baike. 🏳️‍🌈 Chicdat  Bawk to me! 11:14, 30 June 2021 (UTC)

The future of pending changes

Latest comment: 3 years ago29 comments14 people in discussion

Pending changes has been discussed recently in this RfC and this RfC. Specifically, there are a few issues I think may be worth discussion:

  1. Should pending changes continue to be used on the English Wikipedia in its current form?
    • The extension has no maintainer; it is ancient and technically complex. There are few people still around that are familiar with the codebase, and most devs don't want to touch it. T233561, T234743 and T256296 are still open, and various random bugs keep cropping up[1][2][3][4][5][6][7]. The fix for one bug frequently causes another inexplicable bug. Presumably due to its instability, the WMF has maintained a policy of not permitting its deployment on new wikis. T185664 (since 2018) discusses the long-term future of the extension but the code stewardship review is stalled since no WMF team wishes to take responsibility for the extension. When I spoke to some devs about it last year, they said they lost faith in the code stewardship review process, and guessed that the eventuality for the extension would be undeployment. As of a few months ago, a volunteer is trying to axe code and functionality from it to make it more maintainable, however there still does not seem to be WMF interest to maintain it. Sometimes upstream fixes for regressions do not happen or take a while; recently the bot stopped autoreviewing revisions and we had to create and approve an enwiki bot to work around the bug locally.
    • Even if it did work properly, the extension arguably does not provide a great UI and is potentially redundant to edit requests. The PC interface needs improvement, but (going back to bullet one) it is barely maintained for bug fixes never mind new functionality. Some of the issues can be mitigated by not using it on high-volume articles, but even on many of those pages arguably the time spent reverting can be a waste of time.T277883
    • Given the above issues, I'm wondering if an RfC should be held to discuss the future of pending changes. If action is necessary some valid options could be: deprecating its usage only for future protections (leaving existing ones in place), or moving all pending changes over to semi-protection and then removing the extension.
  2. Even if the extension is kept, the pending changes user right doesn't make sense to me. PC is supposedly considered a 'less restrictive alternative' to semi-protection (really the only difference is semi-protection requires you to make a request on talk; PC lets you use the editing interface and submit the request that way). But any autoconfirmed editor (10 edits, 4 days registered) can implement a semi-protected edit request. Given this, it doesn't make sense to have a special user-right that users have to apply for to be able to accept pending changes. Should the PC user-right be removed and its permission bundled into either autoconfirmed or extendedconfirmed?

Thoughts appreciated to refine the above ideas and decide whether there is a problem here, before taking it to RfC. ProcrastinatingReader (talk) 19:46, 3 July 2021 (UTC)

Specifically regarding the difference between making an edit request and editing an article directly, it's a significant streamlining of the collaboration work flow to be able to edit an article directly, picking up all pending changes in the process. This of course relies on most pending changes being productive ones. isaacl (talk) 20:12, 3 July 2021 (UTC)
ProcrastinatingReader, from a technical perspective I do not thing we should be running code on enwiki that doesn’t have a maintainer/doesn’t get expeditious bug fixes and so would support removing it entirely as the end goal. I realise that may be controversial but I don’t really see many other options if a code steward for the extension isn’t found. firefly ( t · c ) 06:27, 4 July 2021 (UTC)
I admit that I might be a little biased because I myself a pending changes reviewer, as well as a regular at VPI, but Should the PC user-right be removed and its permission bundled into either autoconfirmed or extendedconfirmed? makes me confused. Some vandals and many disruptive editors make it to autoconfirmed before being blocked. This would make many hours of discussion at ANI; threads with titles like "User accepting vandalism in pending changes protected articles. I would support the bar being a little higher, like 365/5000 rather than 30/500 or 4/10, though. Most purposely disruptive editors don't make it that far. 🐔 Chicdat  Bawk to me! 10:30, 4 July 2021 (UTC)
There's no good reason to restrict approving pending changes to a higher level than accepting semi-protected edit requests. If vandalism were a concern then the bar should be raised for semiprotection too. Vandalism on semi-protected articles is far more infrequent from my experience managing edit filters (autoconfirmed prevents most), and it's consistent with our other practices. The general principle is to make editing as open as possible without overloading our volunteer capacity. Frankly, the biggest limitation on our volunteer capacity with PC is requiring approval at WP:PERM. ProcrastinatingReader (talk) 12:14, 4 July 2021 (UTC)
  • Can anyone supply figures on how often pending changes protection is used, and any examples where any other form of protection would not have been as good? I very rarely come across articles with PC protection, but would prefer solid statistics to my gut feeling. If this is really needed (something of which I remain to be convinced) then we should certainly increase our efforts to ensure that the code is maintained. Phil Bridger (talk) 13:14, 4 July 2021 (UTC)
    @Phil Bridger: Anecdotally I agree, I infrequently see PC pages compared to semi (I'd guesstimate 1 in 25 or less). The data suggests we have about 4,000, in comparison to 50,000 semi-protections. ProcrastinatingReader (talk) 13:14, 11 July 2021 (UTC)
  • @ProcrastinatingReader: you say that you're not sure about why it could be used, as any AC editor could handle a SP edit request, as opposed to the smaller group who can handle pending. Accept for the fact that a quick look at the sheer length of the edit request list shows that isn't happening. Whereas the pending queue is vastly shorter - its use case is "any article that would be semiprotected but has a low enough rate of edits for PCR to not get clogged by stacked edits". It's significantly less work to review a single pending edit than evaluate and then actually add-in a single edit request. So there are negatives to removing it. Nosebagbear (talk) 16:05, 4 July 2021 (UTC)
    Well, there are ~13x more semiprotected pages than PC-protected pages. There are currently 2 requests in the PC queue, which AFAIK is atypical and the small sample makes for poor comparison. But at that number * 13, there are indeed less PC requests than semi. If there were 4 requests in the queue, which there probably will be in a few hours, there would be more requests when compared against the semi queue. A small difference in the number of requests made a big difference in this comparison. You can't do a meaningful comparison without knowing the average number of semi requests and PC requests. And this is without considering whether semiprotected articles tend to have more complex edit requests, on average, than PC-eligible articles. I like the concept of being able to edit in the editor, but its implementation in the form of FlaggedRevs is shoddy, and the extension is totally unmaintained. I'd prefer to see the WMF work on something better. ProcrastinatingReader (talk) 16:29, 4 July 2021 (UTC)
    @ProcrastinatingReader: the number of edits in the queues aren't how it should really be compared. "Average time of a request in the queue" should be the comparing point. And you note that any AC user can process SP-requests, and there's definitely more than 13x as many users with AC than PCR on top of that. Nosebagbear (talk) 17:28, 4 July 2021 (UTC)
  • I don't have much experience with Pending Changes, but I do want to respond to the statement that The extension has no maintainer; it is ancient and technically complex. There are few people still around that are familiar with the codebase, and most devs don't want to touch it. As a software engineer, that's a big red flag. You really don't want a system as big and widely used as wikipedia to depend on something like that. The scary scenario is not that it stops working and nobody can figure out how to fix it. The scary scenario is that it breaks in some way that impacts the running of the site (perhaps a security exposure) and nobody can figure out how to disable it cleanly because there's some dependency that nobody knew existed. You really want to discover things like that during a planned phase-out, not when you're putting out a fire.
As an admin, I don't see that PC provides significant value. I can't speak for all admins, but I personally never consider using it; I find that semi-protection and ECP provide a sufficiently rich tool set that the additional option of PC isn't needed. I'm not saying it's worthless (Nosebagbear, for example, describes a valid use case above), just that the risk/reward doesn't seem worth it to me. -- RoySmith (talk) 17:18, 4 July 2021 (UTC)
+1 on both counts. signed, Rosguill talk 22:49, 8 July 2021 (UTC)
  • I'd like to put in my two cents in this, as recently, I've had an idea relating to pending changes which I think could be of note here. How about we merge PC with the other types of protection (fullprot, templateprot, semiprot, etc) with a new extension? I've noticed that various others including ProcrastinatingReader have commented on various small tidbits of my ideas here, so they might seem a bit duplicated, sorry. Here are my thoughts, repeated into levels of difficulty to reach consensus/build:

Level 1

  • Bundle the PCR user right into autoconfirmed

Level 2

  • Drop the current PC system as it is and protect all currently PC-protected pages with semiprotection

Level 3

  • Have community members/WMF write a new extension for Pending Changes, and overhaul the system. I think that a Pending Changes system where the currently existing levels of protection (semi protection, full protection, etc) could be converted into a type of Pending Changes, where users who do not meet the required permissions to edit certain pages (say, an extended confirmed editor trying to edit a template-protected page) would get direct access to the editing UI, and their changes would have to be approved by a person with the relevant permissions (template editor). My proposal intends to be extremely similar to the current system. Nosebagbear says its use case is "any article that would be semiprotected but has a low enough rate of edits for PCR to not get clogged by stacked edits". It's significantly less work to review a single pending edit than evaluate and then actually add-in a single edit request. Reading through that sentence above, it seemed like a no-brainer to me to merge the two protection levels and make semi-protected pages have easier review tools for edit requests (through an UI instead of a template). I imagine that if there were to be a new system for PC that essentially merges PC and semiprot, the visibility (do unregistered editors see pending changes?) mechanics would be the same as "regular" PC, which is the system currently. As for how something like this could be written, and by who, I'm not entirely sure. If a community member wants to ask for a WMF grant in exchange for building a new extension, that could work. This could be brought up at the next Community Wishlist Survey, or the m:WMDE Technical Wishes. I'm not sure if this is appropriate for a Phab task, but if all other methods are exhausted, a Phabricator feature request task could be filed as a last resort. I refer to this as a last resort, as in my experience Phab is rather slow for feature requests, especially fairly large ones (which is completely fair).

Sorry, I just realised that this is a gigantic jumble of words. I'll try to clean it up later, but I'm publishing this now to save it. 🐶 EpicPupper (he/him | talk, FAQ, contribs | please use {{ping}} on reply) 04:40, 7 July 2021 (UTC)

I like your level 3 idea. It would be especially good if changes can be 'merged' without holding up the rest of the article, a bit like git branches. However, I'm not sure how likely it is we're able to request a brand new extension. It would probably be substantially easier to build than FlaggedRevs, which has a lot more purpose than just the 'pending changes' we use it for. But I don't know of anyone who would want to seek a grant to build it, and asking the WMF seems to be a hit-or-miss. Perhaps the comments of some technical users (@Legoktm, DannyS712, and MusikAnimal) would help. ProcrastinatingReader (talk) 10:28, 7 July 2021 (UTC)
It sounds like a big project. Before any formal work could be done, you'd need to show widespread support for the idea. The Wishlist Survey is a good place for that. As for the idea, I disagree that a UI for edit requests is sufficient. Pending changes allows users to edit the article directly, just as they would any other article (using VisualEditor for instance). As a good-faith new user, ideally I shouldn't have to learn about edit requests or any internal processes in order to contribute. I should just be bold and edit, inline with the spirit of the wiki. — MusikAnimal talk 17:49, 7 July 2021 (UTC)
I disagree with the statement that pending changes allows people to edit articles directly. The whole point of editing articles directly is that changes are visible to other readers, which doesn't happen with pending changes. Phil Bridger (talk) 18:04, 7 July 2021 (UTC)
@MusikAnimal, @Phil Bridger, apologies, seems like I stumbled a bit on wording there. MusikAnimal, I fully agree that As a good-faith new user, ideally I shouldn't have to learn about edit requests or any internal processes in order to contribute. I should just be bold and edit. That’s exactly what I meant, Pending Changes is much less of a barrier for new users to go through (just click edit) than edit requests, and if semi prot is replaced by PC, PC would be the replacement of our current edit requests system. Phil Bridger, I meant “editing articles directly” as in having an easier UI for new editors to edit exactly what is inside the article instead of having to fiddle around with using a template, going to the talk page, describing the changes, etc, with edit requests. 🐶 EpicPupper (he/him | talk, FAQ, contribs | please use {{ping}} on reply) 18:21, 7 July 2021 (UTC)
The pending changes capability decouples the article version seen by non-logged in viewers from the current article being edited. Edits are still made to the latest consolidated version. isaacl (talk) 14:45, 8 July 2021 (UTC)
Proper forking support (T113004: Make it easy to fork, branch, and merge pages (or more)) as well as suggesting edits ala Google Docs (can't find the phab task, I'm sure something exists) is definitely something that MediaWiki needs and would make editing Wikipedia a nicer experience.
Technically pending changes is effectively a second version of the page that conditionally should be shown to users, which means it needs to fragment and duplicate a lot code to achieve that goal since MediaWiki doesn't expect that! Avoiding that in any solution would make it a lot simpler.
While I'm on the soapbox, I'd like to point out that pending changes is anti-wiki, in that it it's no longer instantaneous for your edit to show up. I think that contributes to the reluctance of developers, myself included, to work on it (and then throw in all the technical debt and complexity...). If it were trivial to branch a wiki page and suggest an edit with good UX, would admins be more aggressive in semi protecting pages knowing that it isn't (theoretically) locking out edits? It could easily become more anti-wiki, imposing a pre-review process.
I believe the BLP problem is real and needs some technical help, but not really sure where to go. I do worry that sometimes we're trapped in the XY problem in that the only two solutions we know are page protection and pending changes and so all proposals are based off those two models. Legoktm (talk) 08:09, 8 July 2021 (UTC)
Legoktm, it's interesting that you say pending changes is "anti-wiki", and yet MusikAnimal says above that PC is a more wiki-like alternative to semiprotection and edit requests. Either way, shouldn't MW developers broadly be implementing features that there is a widespread desire for among MW/WMF communities, rather than holding back from such implementations on the basis of - for want of a better phrase - "wiki ideology"?
However, on a purely technical level I entirely agree that the flaggedrevs extension is an unholy mess that is technically incongruous with how MediaWiki otherwise works. Forking like Git or suggested edits/'track changes' as in MS Word would be a massive improvement, and yet also a massive task to implement as you say. In the interim I stand by my comments above that the extension should be phased out of use here on enwiki. firefly ( t · c ) 08:44, 8 July 2021 (UTC)
@Firefly, I could see why people consider PC to be less anti-wiki than semi-protection, but I don't see that much of a distinction, both effectively require pre-approval of edits. Personally as an admin, I prefer semi-protection over PC because it's much more obvious that the wiki process is being halted and should be in place for as minimal a time as possible. As for what to implement...I don't really see why MediaWiki developers would implement features that go against "wiki ideology" just because Wikipedia users asked them to. Developers aren't necessarily the best gatekeepers, but in absence of a different group of people, that's kind of where the buck has fallen. I do not think WMF management has done a good job in prioritizing features that editors need, but that's a different conversation (I also don't really work on MediaWiki stuff directly that much anymore).
I think implementing forking/suggested edits could be done with an 75% solution using a gadget and maybe a Toolforge tool. ("Don't let perfect be the enemy of good") Maybe someone needs to try to prove the concept is viable, as seems to have worked with talk page improvements/DiscussionTools with reply-link and ConvenientDiscussions. Legoktm (talk) 00:51, 11 July 2021 (UTC)
Yes, my comment was in comparing semi-protection and PC. With semi, you have to request others make edits for you. It's cumbersome, more prone to edit conflicts (i.e. someone else changed the content since you requested your changes), and you lose attribution of who actually authored the content. With PC, you can make real-time changes to the article just as you would as if it were unprotected. For all intents and purposes, it is identical to normal editing in that a revision is in fact saved, visible to the author, with attribution intact. Technical complexities aside, I believe a world without PC and only normal page protection is far, far more anti-wiki. I think it's well understood that PC is a technical mess, but it's the best tool we have for low-edit rate pages subject to persistent vandalism. So long as it's working well enough, it should be kept. — MusikAnimal talk 22:21, 11 July 2021 (UTC)
@Legoktm: Is "Technically pending changes is effectively a second version of the page" true? If I recall correctly, it doesn't make any independent version of the page. It just displays an older "known good" revision of the page to certain editors, rather than the current revision. All the "reviewing" is about looking at the difference between the last known-good revision and the current revision to make any needed edits and then flag a new known-good revision. But it does reinvent a ton of code to do that, probably far more than it would really need to. I'd say that complexity is what discourages developers rather than a philosophical opinion that others may not even share. Anomie⚔ 11:55, 8 July 2021 (UTC)
Right, in my head the "known good" revision is a second version that is in parser cache and varnish/HTML cache and all the special handling that goes along with that. And fair, it's possible I was projecting on the philosophical front. Legoktm (talk) 01:03, 11 July 2021 (UTC)
Branching is an immensely powerful feature of source control versioning systems—and also one that can be confusing even to experienced users. To simplify working with them, it's helpful to have regular integration points to one branch and rebase points out to the working branches. Otherwise, integrating working branches becomes laborious. Even then, it's difficult to manage when multiple people are working on the same passage of text, and when co-ordination is possible, it saves a lot of time to divvy up work between editors to minimize overlap.
Pending changes doesn't introducing branching: it decouples the "release to non-logged in viewers" process from the edit submission process. Edit requests are akin to someone creating a working branch/diff and putting the onus on someone to rebase and merge the change. Pending changes puts the onus on someone else to remove a change if it is undesirable, which is the same as regular edits.
Given the difficulties of trying to co-ordinate edits between Wikipedia editors of differing levels of experience in general, who could show up at any time and drop in an edit anywhere, I am wary of making a multi-branching model the standard mode of operation. Having an additional tool or tools to help power editors revamp articles on the side could be helpful, such as a tool to aid with merging in changes from a given point in the article's history. I'm unclear, though, as to how much priority this should be given versus other improvements that can be made. isaacl (talk) 15:12, 8 July 2021 (UTC)
  • I doubt it would improve the project to remove Pending Changes today, but the entire system needs to be re-designed from the ground up. I'm not sure there's any path to a Git-like revision history on a per-page level, but that would be the ideal system. If PCR is to be bundled, I would suggest bundling it with Extended-Confirmed, simply to help with the learning curve. User:力 (power~enwiki, π, ν) 21:24, 8 July 2021 (UTC)
    @力: I think git-like revision history would be terribly confusing for most people. Merge conflict resolution is complicated. It's really something to be avoided if at all possible. -- RoySmith (talk) 22:41, 11 July 2021 (UTC)
  • Get rid of it. As I recall, it managed to get in even though the community didn't want it. The listing of options above without a "simply get rid of it" choice is the type of thing that can make that happen. Far too complicated. What it does is done better by human and bot vandal patrol and partial protection. North8000 (talk) 01:03, 11 July 2021 (UTC)
  • Note that I've modified my opening comment slightly, specifically to add links and references to technical issues. Diff. ProcrastinatingReader (talk) 12:43, 11 July 2021 (UTC)

More consistency in redirecting/disambiguating terms that have a grammaticalized meaning in English?

Latest comment: 3 years ago1 comment1 person in discussion

Relevant guideline (I think): Wikipedia:Disambiguation § Dictionary definitions: A short description of the common general meaning of a word can be appropriate for helping the reader determine context.

My impression is that this is generally sufficient guidance when it comes to content words, and ditto when it comes to the minority of function words that have their own articles - i, we, you, he, she, it, they, for example. With the predictable exception of single-letter "I", each of these leads either to the article about the pronoun, or to a disambiguation page, either directly or via a redirect. And if a disambiguation page, the pronoun is either treated as the primary topic and placed above the "may also refer to" introduction, or else the very first entry below it. Additionally, of course, there's always a link to the corresponding wiktionary entry via the interwiki template. So, clearly no consistency issues here.

It's quite different for the majority of function words that don't have separate articles, though - am, are, is, for example. In each case, the path relevant to the function-word usage ultimtely leads to the same place, Copula (linguistics) § English, which is good, but which is also where the consistency ends. "Am" and "are" redirect to disambiguation pages. The former puts it at the bottom of § Other uses, making it, by accident or design, the very last regular disambiguation entry on the page. The latter puts it at the very top of the page, just as in the case of the pronouns. And "is" redirects straight to the target section, which has the requisite "For other uses" hatnote link to the disambiguation page... which in turn includes a link to the target section mid-page, under § Language. Doesn't get much more inconsistent than that, does it.

My guess is that this comes about because both of these factors - not lexical, not "worthy" of an article - make it more likely that people will have widely differing ideas as to whether and how such a usage is "appropriate for helping the reader determine context", in the words of the guideline. So maybe this constitutes a special case, and should be treated as such.

On the other hand, maybe this is a non-issue - "foolish consistency [being] the hobgoblin of little minds", and all that.  ··  2A02:talk  ··  13:56, 17 July 2021 (UTC)

Extent of coverage of a reference should be marked

Latest comment: 3 years ago7 comments5 people in discussion

Many times when I have doubts about info in an article and there is a citation nearby, I ponder if the reference covers the part of the info I have doubts about. When the ref is easily searchable online, I can verify, which takes time, some times a little sometimes more. And when the ref is a book that is not searchable online, then the doubt persists and I wonder, what info covers the reference? Is it just one word? Is it a phrase, is it a sentence? A paragraph? For example, in the article Jacobo Árbenz, you can find the following: "On one of his visits to Mexico, Árbenz contracted a serious illness, and by the end of 1970 he was very ill. He died soon after. Historians disagree as to the manner of his death: Roberto Garcia Ferreira stated that he died of a heart attack while taking a bath,[140]". What info does the citation 140 covers? That he died of a heart attack while taking a bath? Or does it include the disagreement claim? Or does it include that he died soon after? You may think it is evident that it just covers the heart attack or not, but this is just to illustrate my point.

I think in order to save time for editors and to have more certainty about the info in a page, there should be a system to mark the extent of the coverage of any given specific reference. There could be a tab next to the "view history" tab, where one could see the page with the text of the info within in different colors, marking the extent of the coverage of each reference. The info that is not backed by any reference would just remain without color. Thinker78 (talk) 18:06, 13 July 2021 (UTC)

BTW, for example of something related that is already implemented, see Template:Citation needed span. --A D Monroe III(talk) 19:02, 13 July 2021 (UTC)
Thinker78, I know this issue came up a few years ago, although I don't have any idea how to track down that discussion. My vague recollection is that someone proposed something very similar to what you suggest – a way to highlight the word, phrase, sentence or paragraph that is supported by the reference, probably in a way that's not immediately visible to the reader but would show up in edit mode. The challenge, if I recall correctly, is that this might work reasonably well when the text and supporting reference are first added, but what happens if subsequent editors decide to reword the text. The example I'll give is not ideal but I'll try to lean on your example. What if the reference supported the term heart attack, and some well-meaning editor decides to modify the term replace it with myocardial infarction? It's very possible that the replacement would undo the highlighting. If another editor decided that term was appropriate and changed it back to heart attack, will that restore the linkage or not? Just a simple example but one can imagine situations where over the years, it becomes harder and harder to tell what exactly is supported by the source. This doesn't mean it's not worth considering but it does mean it's a little bit more complicated than suggested.
What I try to do isn't as good as what you suggest but it's much easier to implement. I try to take advantage of the fact that the citation templates can have a field for "quote" which can be used to include the relevant statement from the source supporting the claim. Having said that, I just realized I added a few refs in the last week or so and did not use it, so I went back and included the quotes. One challenge with this method is that the default fields when one creates a reference do not automatically include quote, you have to manually add it. I think I attempted to change that so that the quote field would be one of the default fields but to be honest I didn't push all that hard and it doesn't seem to have happened.
All I'm suggesting is probably fairly obvious but this diff is a specific example. S Philbrick(Talk) 19:33, 13 July 2021 (UTC)
I also have rather vague recollections of something similar existing many (at least in Wikipedia terms) years ago, but being abandoned for the reasons stated by User:Sphilbrick. It is one of those things that would be great if everyone followed it, but it only takes a few people not to follow it for it to become pretty useless. Phil Bridger (talk) 19:57, 13 July 2021 (UTC)
As an example implementation, we could create a new {{Citation span}} template, similar to the {{Citation needed span}} template, where the text supported by the cite is included within the template. (Unlike the citation needed span template, the cited text shouldn't be highlighted in any way in normal view mode.) Thus later editors could see where text outside the template doesn't use this cite, or where modifying the cited text may need rechecking against the cite, rather than having to make assumptions.
Of course, using the cite span template would be optional. New edits could use it or not as the editor sees fit, and later editors could enjoy the benefits or not. --A D Monroe III(talk) 18:21, 14 July 2021 (UTC)
In the abstract I like the thinking of the original question/idea posed here. It is indeed an imperfection of the system that sometimes you can't know for sure how much an in-line citation covers. I am unsure there is an easy/practical solution to that, but if someone comes up with something I'd be positively predisposed to it.Al83tito (talk) 03:54, 24 July 2021 (UTC)
One partial solution is this: use the quote function of the ref template. In some of my contributions I included some short quote within the citation (and even more so when the original reference is no in English-- and I include a translation of the quote) so that I make it as transparent as possible what text from the source informs the contribution to the wiki article.Al83tito (talk) 03:54, 24 July 2021 (UTC)

Illustrations on Wikipedia

Latest comment: 3 years ago19 comments14 people in discussion

One thing that Wikipedia falls short of on commercial encyclopedias such as Encyclopædia Britannica are its illustrations. Almost everyone can write an article, use citations and understand sources, but often illustrations, especially in more niche and complex topic areas require skill to create. Let's look at Encyclopædia Britannica's map of London's West End; vs the only map we have. The dedicated forum for requesting maps is really a hit and miss, a lot of requests go unanswered. It's not just maps, especially in topics such as geography and the sciences, we get poor illustrations. Our diagram for the water cycle (which wasn't even made by a Wikimedian), and Britannica's. Especially at smaller scales the former diagram is too detailed, and contains too much text to read.

Another problem is consistency. On Wikipedia, maps are relatively standardised (by no means 100%) but there are basically no guidelines on other illustrations. No guidelines on the fonts that should be used, the colours, the keys, meaning almost every illustration on Wikipedia shares no conventions, meaning a reader has to repeatedly adapt from style to style.

I don't really know a solid solution to this, I think probably the best would be for WMF to hire professional illustrators, meaning illustrations could be requested, similar to the Art Team on WikiHow. However, whether this is financially viable I do not know. I think a good starting step however would be to set out conventions on Illustrations, and the general style they should follow (even then this doesn't guarantee people will actually follow these guidelines). Standardising fonts, colours, and levels of detail would certainly benefit the project as a whole.

I might be speaking rubbish, or maybe there isn't a problem at all. I just thought it would be useful to get other's opinions on this matter. — Berrely • Talk∕Contribs 14:40, 17 July 2021 (UTC)

If you are going to standardise, then internationalise, too. Build a mechanism so that an illustration has a separate, translatable list of captions (linked to positions on the illustration), so it can be easily reused on different language Wikipedias. That would also share the cost of creation across every Wikipedia, and give the smaller ones access to a fantastic resource. It could also allow for local or individual tweaking of text sizes and fonts.--Verbarson (talk) 19:51, 17 July 2021 (UTC)
@Berrely: I certainly would not want the WMF creating images - that's content work, to, and not one lacking in controversy either. I'm not sure how viable it would be to try and bring standardisation on such a broad scale. Perhaps picking an area or two - such as fonts and keys, and see if you can get a standard guideline. Like citations, it would need to start with all remaining permissable, but the fact that there was one recommended route means new entrants into the field would become more heavily that way, and over time it would become more standard. Nosebagbear (talk) 13:55, 19 July 2021 (UTC)
@Verbarson, it's already possible to translate text in SVG files. See c:Commons:Translation possible/Learn more. Whatamidoing (WMF) (talk) 20:08, 19 July 2021 (UTC)
Yes, illustrations could certainly be improved, but I don't think that involving the WMF in a content issue is the way to do it. And nor do I think that introducing stricter standards will lead to more illustrations being created by volunteers. Somebody (maybe you?) simply needs to persuade editors to create them where they are needed. I must add that maps can be highly controversial. As one example among many, what country would you put Crimea in? Lots of countries even have laws saying what can be shown in maps, including at least one of the claimants to Crimea, and I just found out the other day that one of the sillier laws brought in by the current Polish government forbids anyone from claiming that the border between Poland and Germany was not legally settled till after the fall of communism. Illustrations are not as innocuous as they may seem. Phil Bridger (talk) 15:48, 19 July 2021 (UTC)
At least for maps, we have <mapframe>, which gives interactive maps that are not terrible overall. See {{OSM Location map}}. For other diagrams, it is super difficult to get the size and level of detail right for all resolutions and screen sizes, especially if you want to use the same image on desktop and mobile. Generally, if you want to try to standardise the font and colour conventions for diagrams, your best shot is to lead by example and create (with a dedicated Wikiproject) a few thousand diagrams using these conventions that are clearly superior to what is currently used, and then people will want to use these and might follow your conventions. Or they might not, if these conventions are at odds with subject-specific ones. —Kusma (talk) 20:43, 19 July 2021 (UTC)
Maybe it would help if we had a page for "illustrations requested" in the same way as we do for translations, articles, etc.; then any budding illustrator could try their hand. Of course it might just turn into a list of stuff requested 10 years ago that never gets done, but one can only hope. Elemimele (talk) 21:17, 19 July 2021 (UTC)
We have lots of venues, see Template:Image requested/doc - and feel free to expand as useful. — xaosflux Talk 21:49, 19 July 2021 (UTC)
Elemimele, A better resource is Wikipedia:Graphics Lab, which has a specific section for illustrations. I've had very good luck with some requests, although my very anecdotal feedback is that very targeted requests (change blue to green on this map) are much more likely to be fulfilled than something more general ( can you illustrate the feedback cycle) and I have serious doubts that the volunteers could ramp up to the volume desired. However, it might be worth identifying a few of the volunteers who help out and get some thoughts. S Philbrick(Talk) 20:18, 21 July 2021 (UTC)
Sphilbrick, thanks for that, I had a look, it's a really useful-looking place. Elemimele (talk) 11:52, 22 July 2021 (UTC)
Berrely, First, I want to applaud you for posting this in idea lab rather than in proposals. You've identified a problem but not quite sure what the right solution is. The idea lab is the right place to bat around ideas, and maybe it can be turned into a formal proposal.
I concur with the problem assessment — the observation that volunteer editors are doing a better job of writing grows than creating illustrations. (I would also include high-quality photos, or lack of, as a related shortcoming.) I also agree with your assessment of the reasons for the shortcomings — virtually everyone can write prose, but the creation of good illustrations and maps is the skill set that's much harder to come by.
I also agree with Verbarson's desire for a set of captions in various languages. The good news is that captions can be created by people without mapping or illustration skill sets, the bad news is that translation is an activity is one that's in short supply than we need. I've suggested in the past that I could support WMF funding for translation services. That's less likely to run into the interesting problem pointed out by North8000. S Philbrick(Talk) 20:14, 21 July 2021 (UTC)
Thanks Sphilbrick and everyone else for replying, apologies this slipped my mind :). On SVGs, we are actually able to translate text by way of the <switch> element. We even have a dedicated tool made by Community Tech, SVG Translate. It's actually rather good, and much better than manually editing code with a text editor. Sadly, as you noted, even if we have the tools to translate illustrations, it doesn't mean all illustrations are translated, and we have a lot of illustrations that are either only in English, yet used for other projects, or only in another language, and no one has the time to translate them. Not to mention that if a diagram is in a bitmap format such as PNG or JPEG translating it also requires image manipulation knowledge, which many don't have. — Berrely • Talk∕Contribs 08:49, 22 July 2021 (UTC)

I hesitate ti say this for fear of being guilty of unleashing a monster when this interacts with other poorly written policies, but illustrations often contain information and statements. In essence creating unsourced OR. North8000 (talk) 23:32, 19 July 2021 (UTC)

Yup. And not just WP:OR, but WP:OR that is darned difficult for anyone but the technically accomplished to correct when it is clearly wrong. For a classic case in point, relating to a highly-controversial topic, note that Commons still hosts a world map illustration purportedly showing the 'Legality of zoophilia by country or territory'. [8] As was firmly established before the article in the English-language Wikipedia which used it was deleted (see Wikipedia:Articles for deletion/Legality of bestiality by country or territory), the content is essentially fiction - to describe it as WP:OR would be giving it more credibility than it deserved, since the 'research' involved consisted of partisan guesswork driven by an obvious agenda. This thoroughly-misleading object is still in use by several Wikipedia projects in other languages. [9][10][11][12][13] AndyTheGrump (talk) 23:54, 19 July 2021 (UTC)
One possible solution: Require references on the diagram's page, and change the WP:IMAGEPOL to require a link to the file page of diagrams. Sungodtemple (talk) 20:05, 21 July 2021 (UTC)
We do have a source parameter, but it's not often used sadly. As noted it's often hard to correct it when it's wrong. I think it would be beneficial to try and enforce sources, but I doubt it could be massively enforced, especially since a lot of the illustrations we use are relatively old, or have creators who are no longer active. Another problem is that often illustrations have many data sources, and creators don't find it worthwhile to add all of them. — Berrely • Talk∕Contribs 08:49, 22 July 2021 (UTC)
An illustration having 'many data sources' is frequently a good indicator that WP:OR is involved. Sometimes (as with the example I've already provided) with the express intent of pushing some sort of agenda. AndyTheGrump (talk) 12:36, 23 July 2021 (UTC)
Not necessarily. For example, one may have a historical data trend set, mapping some value by year, but the last publication of the complete set was in 2015 (hypothetically) as to demonstrate that the time-trend of this data was considered important by that source (or more); if one has the ability to get that value from an equivalent source for each year after through the present, then this would not fail OR/CALC to continue extending the data until some other source provides the more complete, to-date package. But there are also cases where the graphic can be pulling one piece of data from each source listed, and no sign that the complete data set compiled is of importance to RSes, which would beg if that's OR. Either way, we can certainly add references within the File: page, outside of any template or the like. --Masem (t) 18:18, 23 July 2021 (UTC)

I personally have accepted it as a characteristic of Wikipedia, that because it is free and the contributions are free, and that we can't use copyrighted works (except sometimes with Fair Use), we often don't have the beautiful illustrations that paid/professional media has (we do have one partial work-around, though: Template:External media). On the other hand I am still amazed at the many times we do have good illustrations. I praise your desire to do better and think of ways.

I see only two options: we either go through another phase of expansion (I wish!) in the number of wikipedians (and a small subset of them coming with graphic skills), or we accept the fact that to get good graphic design you have to pay for it at times. A system could be set up where editors propose and upvote on the graphics that need creation, and then the WMF offers some modest funding for someone to create them (either in-house, or gig-economy style). It may not be the most "pure" way of expanding wikipedia, but it may be the more pragmatic one. Just a thought. Al83tito (talk) 04:24, 24 July 2021 (UTC)

Many editors not using edit summaries- proposed fix

Latest comment: 3 years ago10 comments9 people in discussion

I've noticed a lot of editors forget to use edit summaries. Perhaps we should require edit summaries for edits to the mainspace? --Firestar464 (talk) 11:35, 21 July 2021 (UTC)

And how do you propose to ensure that such edit summaries actually contain anything meaningful? AndyTheGrump (talk) 12:11, 21 July 2021 (UTC)
Or truthful.--Khajidha (talk) 20:15, 24 July 2021 (UTC)
I don't think this will work. It will put yet another barrier to editing; on top of policies and guidelines, help with wikitext/visual, and protection, now we have required edit summaries. There is an example of this being hurtful: With canned edit summaries newcomers may think that a summary is required, leading to misleading edit summaries. Wikipedia:Canned edit summaries says: While [canned edit summaries] [are] a convenient feature for users, some may click or tap the buttons simply because the buttons are there, or perhaps they think they have to select one (i.e. they believe the edit will not be saved unless they enter a summary, which is not true). Consequently, one may see a substantial edit with the summary "Fixed typo" or other misleading summary. Patrollers should be careful not to assume the edit summary was intentionally misleading or that the edit was made in bad faith. This will also hurt vandal-fighters by making it easier for vandals to blend in, as mentioned in the quote. Sungodtemple (talk) 20:00, 21 July 2021 (UTC)
Firestar464, Andy is right. Any enforcement mechanism can be easily gamed. I installed the script that reminds me if I accidentally try to save without having an edit summary which is helpful. I think the best option is to politely point out to an editor not using edit summaries that useful edit summaries can be very, very helpful, and hope that the polite encouragement will achieve a goal that an automated rule will not achieve. S Philbrick(Talk) 20:04, 21 July 2021 (UTC)
@Firestar464: This is a variation of a perennial proposal: Wikipedia:Perennial_proposals#Automatically_prompt_for_missing_edit_summary RudolfRed (talk) 01:40, 22 July 2021 (UTC)
Since I know I can be careless, I have set the option that reminds me (by failing to save first time and putting a prompt up) to fill in the edit summary. However, I find it rather annoying to be so prompted when editing talk pages, help pages, this page etc.
Please can we have a option (or default) to prompt only on mainspace edits? --Verbarson (talk) 18:59, 22 July 2021 (UTC)
Verbarson, try User:Alexis Jazz/warn-edit-summary. — Alexis Jazz (talk or ping me) 00:52, 23 July 2021 (UTC)
or User:GhostInTheMachine/NoEditSummary — GhostInTheMachine talk to me 21:00, 23 July 2021 (UTC)
Noted. Thanks.--Verbarson (talk) 11:51, 24 July 2021 (UTC)

Avoid pixel size forcing in multiple image templates

Latest comment: 3 years ago6 comments3 people in discussion

Not sure where else to post this, but at a recent FAC[14] it was brought up that multiple image templates, which I've used a lot recently, should be avoided because they require that you force a certain pixel size, which is problematic. Is it technically possible to add something like the "upright" parameter that are already used on single images, which scales images relative to particular screens instead? Otherwise it will be hard to use the multiple image templates for articles meant for promotion. FunkMonk (talk) 11:22, 10 July 2021 (UTC)

FunkMonk, This is an interesting point worth exploring. I've used galleries and multiple image templates on occasion. Obviously, those templates were designed long before smart phone usage became ubiquitous, and it made a lot of sense to spread images horizontally across what one expected to be a fairly wide page. Given the usage of mobile, we ought to investigate whether those templates should be deprecated or rewritten. S Philbrick(Talk) 13:20, 10 July 2021 (UTC)
Generally, a gallery or cluster of images should not be added so long as there is space for images to be effectively presented adjacent to text see WP:GALLERY — GhostInTheMachine talk to me 19:02, 10 July 2021 (UTC)
I don't think that applies to the multiple image template, which can be used to group multiple related images in a way that they only take the space of a single image. See for example in Podokesaurus. FunkMonk (talk) 23:46, 10 July 2021 (UTC)
In any case, regular galleries are used in some recent FAs, such as Gothic boxwood miniature, so it doesn't really matter that they are generally meant to be avoided, when there are cases where they are fully accepted. There is no reason why we shouldn't adapt their use to newer standards, instead of pretending they don't exist. If they were completely discouraged, their templates would have been phased out long ago, but that's not the case. FunkMonk (talk) 00:33, 15 July 2021 (UTC)
  • Any idea how this can be taken further? Surely it's an issue that needs some kind of resolution, the galleries and multiple image templates aren't going away any time soon. FunkMonk (talk) 21:06, 27 July 2021 (UTC)

A better alternative to template:convert

Latest comment: 3 years ago7 comments5 people in discussion

We encourage people to use {{convert}} so readers can see numerical values in terms that are familiar to them. A laudable goal, but IMHO, poorly implemented. For example, in Mercury-Redstone 3, we've got "His spacecraft reached an altitude of 101.2 nautical miles (116.5 statute miles, 187.5 km) and traveled a downrange distance of 263.1 nautical miles (302.8 statute miles, 487.3 km)" That's not very reader-friendly. It seems to me a better way to do this would be to have a preference people could set "I want metric units" or "I want that bat shit crazy stuff they use in the US". Then, somebody could see "His spacecraft reached an altitude of 187.5 km and traveled a downrange distance of 487.3 km". Or, "His spacecraft reached an altitude of 116.5 miles and traveled a downrange distance of 302.8 miles" for those of use who grew up in an awkward backwater corner of the universe. -- RoySmith (talk) 00:39, 27 July 2021 (UTC)

I can see some advantages of that, but one advantage of the current system is that it exposes readers to alternative units, making them realise that not everyone uses the same units as them. The example given is pretty bad, because it gives the figure in more than two different units. Phil Bridger (talk) 08:14, 27 July 2021 (UTC)
To help with readability, the alternate units could be in a footnote instead of in parentheses. Of course, the {{convert}} template wouldn't be used in this instance, at least not in its conventional way. —El Millo (talk) 08:20, 27 July 2021 (UTC)
An tooltip popup would avoid having to jump-scroll all around just to see a single number in a different format, but apparently that is not accessible and/or breaks on mobile browsers and/or gives generally malformed/semantically-incorrect HTML. "His spacecraft reached an altitude of 101.2 nautical miles and traveled a downrange distance of 263.1 nautical miles." DMacks (talk) 08:50, 27 July 2021 (UTC)
For those of us in some regions who study certain topics, different topics have different most-comfortable units. For example, US scientists would reasonably expect US geography and transportation articles would probably talk about miles between cities and degrees Fahrenheit for weather but [prefix]meters and degrees Celsius for chemistry and physics properties. And sometimes Kelvin for other chemistry/physics properties. The "main" unit to display is probably in the realm of MOS for certain article-topics and ENGVAR. Basically it's two-dimensional batshit-crazy (topical x locale). DMacks (talk) 08:42, 27 July 2021 (UTC)
And the units can differ even in closely related topics. For example here in the UK fuel for vehicles has been sold in litres for several decades now, but its consumption is nearly always measured in miles per gallon (which, as well being in imperial units rather than metric, is also inversely proportional to the litres per 100 kilometers used in much of Europe) (and I just had another afterthought - the gallons used here are a different size from those used in the US). The "main" unit to display is in most cases determined by the source. Phil Bridger (talk) 16:39, 27 July 2021 (UTC)
Wouldn't the preference only be available to logged in readers? The example is not reader friendly because convert isn't used in that. {{Convert|263.1|nmi|lk=in}} gives 263.1 nautical miles (487.3 km; 302.8 mi) which is much better. There are articles that should have different measurements. Most but not all airports, see the box at Heathrow Airport, measure their elevation in feet but runways in metres. While I'm happy mainly to use metric and know that 5 cm is 2 in without the use of convert I wouldn't know how long 6.3 cm is. So 6.3 cm (2.5 in) (convenient guess). CambridgeBayWeather, Uqaqtuq (talk), Huliva 01:07, 29 July 2021 (UTC)

Looking for Category:Linux distributions organization ideas

Latest comment: 3 years ago9 comments3 people in discussion

We have received complaints from readers that Category:Linux distributions is an non-navigable mess and I agree, it is. It has obviously grown up "organically", with people adding random cats over time without rhyme or reason, making it almost impossible penetrate it and actually find comprehensible lists of Linux distros.

There have been several attempts fix this, including:

So, as mentioned, at User:Huggums537's suggestion I am bringing this here for ideas, thoughts and suggestions as to what to do about the remaining sub-categories in this category. Should they be retained, changed, or just left alone?

I duplicate here the category tree that I also posted in the CfD discussion, which diagrams the situation under discussion:

category tree

- Ahunt (talk) 00:34, 28 July 2021 (UTC)

Ahunt, would you mind pinging into the discussion and telling us who the user is who created Category:All Linux Distributions so we could get their input as well? Thanks. Huggums537 (talk) 00:44, 28 July 2021 (UTC)
I actually would have if I knew who they were, but since the category they created was deleted, the record is now gone (unless an admin can still see it). They did not participate in the deletion discussion, either. - Ahunt (talk) 00:51, 28 July 2021 (UTC)
Ok, perhaps Guy Macon can divulge who they are and ping them to the discussion since he said he was aware of who the person was and that he was aware that both deleted cats were created at the same time by this same person. Huggums537 (talk) 01:13, 28 July 2021 (UTC)
That could be helpful! - Ahunt (talk) 02:10, 28 July 2021 (UTC)
Using Special:WhatLinksHere for the deleted cats, non-admins can find that it's probably User:Crazybpjumper who created them. DMacks (talk) 02:22, 28 July 2021 (UTC)
Thanks. Doesn't seem likely they will contribute since they appear to have only been a single purpose account... Huggums537 (talk) 05:30, 28 July 2021 (UTC)
Ahunt, if we don't attract any attention for this topic here, then I suppose another option would be an RfC to get some community input. Huggums537 (talk) 05:53, 29 July 2021 (UTC)
I think that if no one has any ideas here either, I will just drop this issue altogether. I have recently once again gone through the whole category tree in detail and can't see anything that can be done to fix it. By the total lack of input, it looks like no one else can, either. I think by turning it into a non-diffusing category and listing all the actual distributions in it, that has solved half the problem. The other half, the sub-category tree mess, seems to be basically unsolvable, it is just something Wikipedia will have to live with (plus I am sure more will be added over time, too) so personally I am not prepared to waste any more time on it. I'll just get back to writing new articles instead, but if you want to take it further, then please do. - Ahunt (talk) 12:48, 29 July 2021 (UTC)

Should slave ownership be mentioned in the first sentence of articles about slave owners?

Latest comment: 3 years ago18 comments14 people in discussion

Wikipedia:Manual_of_Style/Biography#Opening_paragraph says the first sentence should include "Context (location, nationality, etc.) for the activities that made the person notable." If the subject was a slave owner should this context be included in the first sentence?♥ L'Origine du monde ♥ ♥ Talk ♥ 02:07, 13 July 2021 (UTC)

It depends, are they most notable for being a slave holder? Then maybe. Otherwise it is likely not appropriate for the first sentence. PackMecEng (talk) 02:09, 13 July 2021 (UTC)
I'd loosen PackMecEng's thought as "are they most notable...". There could easily be major notability for something they did historically significant ("notability is not transient" and all that), but also major interest later specifically in their slave-ownership (weight of recent refs). Not for us as editors to decide which orthogonal types of notability is "most". But this aspect definitely would need to be demonstrated to be highly significant by article content that has secondary refs (WP:LEDE standard). DMacks (talk) 02:45, 13 July 2021 (UTC)
If they were the president of the United States then the answer is obviously no. The presidents did not derive their notability from slave ownership. This was explained to you repeatedly in the unanimous RfC on Washington started by you.You were reverted every time you tried to insert "slave owner" into the first sentence of every presidential bio: [15], [16], [17], etc. Please drop the stick Dr. Swag Lord (talk) 02:57, 13 July 2021 (UTC)
I assume Dr. Swag Lord's "you" refers to L'Origine du monde (not me, as the indentation-flow suggests)? I have not been involved in the RfC or this aspect of presidents' articles in general. But looking at these details (now that I know about them, not just an out-of-the-blue VPIL brainstorm), WPIL is not the place for this. Yhe MOS talkpage would be a reasonable venue, but given the SNOW at the RfC, I agree with the STICK advice. DMacks (talk) 03:00, 13 July 2021 (UTC)
DMacks, Yes, my apologies. I was referring to the OP. Dr. Swag Lord (talk) 03:08, 13 July 2021 (UTC)
No worries. DMacks (talk) 03:29, 13 July 2021 (UTC)
That (require this mention in the first sentence) seems like way too strict of a style rule to try to enforce across any biography. If it is significantly notable it should already qualify, but for example I don't really see why forcing that in to the first sentence for Sneferu would be necessary. — xaosflux Talk 14:15, 19 July 2021 (UTC)
I spot-checked the first 10 entries in List of American federal politicians convicted of crimes. Only two of them (John H. Mitchell and Albert B. Fall) mention their criminal activities in the first sentence. And of course, without implying that it was ever OK, if slave ownership was not illegal at the time, then it wasn't a crime. Apparently several of our past presidents were Opium addicts [18], an activity which our society now considers illegal. Should we update the first sentence of Thomas Jefferson to include this fact? -- RoySmith (talk) 14:58, 19 July 2021 (UTC)
Yes, plus this is not the place to raise the issue - there appears to be some WP:FORUMSHOPPING going on. Johnbod (talk) 14:54, 19 July 2021 (UTC)
A lot of men in the past didn't respect women, or pooh-poohed their talents and ideas. For sure let's mention that in the first sentence too. The first sentence also needs to say if they gave their kids a belt once in a while, or were not nice to animals, or conquered other peoples and exploited them, or had ideas which today would be called antidemocratic.
Just kidding -- see WP:PRESENTISM. EEng 03:28, 20 July 2021 (UTC)
Only if the article subject is very notable for being a slave owner. 🐔 Chicdat  Bawk to me! 10:46, 20 July 2021 (UTC)

Slave ownership is often mentioned in the lead sentence. See e.g. John Taylor (Baptist preacher) and Robert Ward Johnson. However, the mention is usually "was a planter....". "Planter" strikes me as a euphemism and I think most people won't know what it means. On the other hand, is suppose there is a difference between somebody whose income/livelihood was largely derived from slave labor (a "planter"), and somebody who owned a small number of slaves but earned most of their money through other ventures. Plantdrew (talk) 19:19, 20 July 2021 (UTC)

No. We should place it only if the subject's main notability is his slave ownership. Kings from ancient kingdoms ranging from Egypt to Babylonians to Romans to China have slaves. Generals from those periods also have slaves, as defeated enemies will be sold as slaves. I am sure Julius Caesar is a slave owner, should we place "slave owner" on the first sentence instead of his military achievements? Should we include "slave owner" on every Ottoman sultans and Roman senators? It shouldn't be. SunDawntalk 04:52, 23 July 2021 (UTC)
It's interesting to think that an unintended consequence of what the OP apparently wants could be to normalize slavery in the reader's mind. EEng 06:05, 23 July 2021 (UTC)
I suspect that this proposal was meant to apply only to articles about people in the land of the free and the home of the brave.
Some estimates indicate that this would affect about one in every 10 or 15 families in places where slavery was legal, but as owning slaves was correlated with wealth, and as wealth is correlated with notability, it would probably be a rather larger percentage of notable people.
I'm not sure that it would "normalize slavery" so much as help readers understand just how pervasive it was. WhatamIdoing (talk) 18:10, 23 July 2021 (UTC)
Wikipedia is a neutral source of information. If a notable historical figure was an owner of enslaved people, it is a relevant piece of information that ought to be part of the biographical article. Further, if as a consequence of mores changing the person is seen in a different light by subsequent generations of historians, then the article can and should reflect how that historical person has been viewed differently in different periods. However, whether it is written in the lead section, should be determined by whether that person is notable as an owner of enslaved people, or for some other non-related reason. The lead section, and especially the top paragraph, ought to provide insights into why that person is of encyclopedic interest; there are some people who are historically relevant because they were traders of enslaved people, for example, while others are relevant for being political leaders who would not have been notable on the fact alone of being owners of enslaved people. Al83tito (talk) 03:40, 24 July 2021 (UTC)
  • The relevant policy is WP:DUE. To echo some above, if sources considered it one of the most important things about them or that it contributed to their notability, then by all means include it in the lede. But this will usually not be the case, since owning slaves was for most of history a relatively common and mundane thing (if you had the money). As for the point about planter, I would argue that that's different as "planter" refers to an occupation and high social station (particularly in 1700s/1800s United States). "Slave owner" is as much an occupation as "car owner" and a "slave owner" could be of modest means and only own one slave, whereas a planter (if they were the slave-owning type) would probably have at least a couple dozen slaves and a fair amount of land. -Indy beetle (talk) 23:31, 30 July 2021 (UTC)

Countering bias

Latest comment: 3 years ago7 comments6 people in discussion

https://www.realclearpolitics.com/video/2021/07/22/wikipedia_co-founder_on_bias_website_has_completely_abandoned_neutral_point_of_view_sullied_reputations.html

Above and other reports from Wikipedia Co founder raise questions over article bias, foreign government fake news etc. How can that be countered?

Is possible to have a pro and con page tab per subject?

With links to each disputed 'fact' so that both the pro and con view can be read by reader?

How can Wikipedia measure or show the validity or support for each point of view?

Can links to alternate points of view be included in a semi permanent way? So that biased editors are forced to acknowledge alternative narratives?

At least it might at least show on Wikipedia that entry views are 1) indispute Or 2) minority views — Preceding unsigned comment added by Ro mona lisa (talk • contribs) 14:55, 1 August 2021 (UTC)

See Larry_Sanger#Relationship_with_Wikipedia. - Ahunt (talk) 15:04, 1 August 2021 (UTC)
See Conservapedia. This proposal relies on the ignorant assumption that there are only two views to every historical event/political issue, and of course we know that those views are only the American political left view and the American political right view (because Sanger and the alt-right media can't conceive of anything else in this planet of 190 some countries). Where academic consensus is lacking on an issue and there a prominent debates, those are supposed to be covered appropriately. We don't always do our best to represent this, but the policies that direct us to do so are already in place. Fundamentally changing the nature of the encyclopedia to include "different views" because a group of people are upset that facts contradict their worldview would be a useless exercise. -Indy beetle (talk) 03:47, 2 August 2021 (UTC)
Indy beetle, I think it's a little harsh to categorize a binary option as "ignorant", but I will agree that treating all issues as only having two points of view is not a good limitation. The proposal I made at Jimbo Wales talk page allows for multiple views. As an additional benefit, it allows the presentation of abuse that might not be backed up by the reliable sources required by Wikipedia. S Philbrick(Talk) 19:10, 2 August 2021 (UTC)
Alternative theories that have reliable sources are usually included on the article. For instance, look at Malaysia Airlines Flight 370 disappearance theories or Pearl Harbor advance-knowledge conspiracy theory or Moon landing conspiracy theories. The point of Wikipedia is verifiability, not a popular contest on which theory is more well known and which one is less known. All facts in Wikipedia can be disputed, all entries can be challenged, but your "challenge" must also be reliable and verifiable.SunDawntalk 14:10, 2 August 2021 (UTC)
Ro mona lisa, I proposed something here User_talk:Jimbo_Wales#Aggrepedia Which I hoped would generate some discussion, but this is the right place for such a discussion so I hope someone will comment. I see it as a way for Wikipedia to help deal with the bias issue. S Philbrick(Talk) 19:07, 2 August 2021 (UTC)
Wikipedia has bias for sure. But it's not the sort of exaggerated nonsense these clickbait articles report based on nothing but someone's personal view. WP:V exists. WP:NPOV exists. WP:OR exists. Until these articles at least acknowledge the core principles of Wikipedia, we can safely ignore them as the sensationalist churnalism that they are from these supposed "reporters" that haven't bothered to do the slightest bit of research on how article with multiple viewpoints are actually collaboratively written. You know, actual journalism. —  HELLKNOWZ   ▎TALK 19:32, 2 August 2021 (UTC)

A-Class articles

Latest comment: 3 years ago3 comments2 people in discussion

I really don't understand the A-Class article ranking. I can't remember the last time I came across one. Does it even really serve a purpose? ~ HAL333 20:41, 3 August 2021 (UTC)

The A-Class criteria is more like a parallel ranking system. Since we have good articles and featured articles, the issue of even having an A-Class has been raised several times (see for example Wikipedia:Village pump (policy)/Archive 121#A-Class article assessment, Wikipedia:Miscellany for deletion/Wikipedia:WikiProject assessment/A-Class criteria, and several of the discussions on Wikipedia talk:Content assessment/A-Class criteria). Several Wikiprojects like having the A-class, because they can assess and promote FA-like articles on their own without actually having to open it up to the wider FA community process. Wikipedia:WikiProject Military history/Assessment/A-Class review always seems to be cited by supporters as the best formal example. On the other hand, a large percentage of Wikiprojects do not use the A-Class (which is most likely why you have rarely seen one), and instead prefer to immediately aim for the FA. Zzyzx11 (talk) 22:10, 3 August 2021 (UTC)
Ah, ok. Thanks for pointing me towards those discussions. ~ HAL333 03:49, 4 August 2021 (UTC)

Changing to flat icons

Latest comment: 3 years ago34 comments12 people in discussion

I feel like this is something uncontentious as flat icons are being used all across the modern web. But still I want to build this proposal so that it is something that can reasonably be implemented.

I built a list at User:Awesome Aasim/Flat design idea - Wikipedia and @Arsonxists continued expanding that list at User:Arsonxists/Flat Icons - Wikipedia. I feel like it would be a waste of time to get community input on something uncontentious, but I still want to figure out if there is a way that we can transition to flat icons and if there is someone willing to implement this idea. Aasim (talk) 21:45, 3 August 2021 (UTC)

Don't assume that changing icons that have massive usages will be uncontentious. — xaosflux Talk 21:53, 3 August 2021 (UTC)
+1, also the GA icons proposal that was widely opposed. This would need an RfC I think. ProcrastinatingReader (talk) 11:48, 4 August 2021 (UTC)
Perhaps you've forgotten the reaction the last time you proposed this? You can also search the archives for the many icon proposals, and see for yourself how many people weigh in with different views. isaacl (talk) 00:09, 4 August 2021 (UTC)
Yes the feedback I got was "this proposal is not ready and prime yet". That is why the rfc tag was removed and that is why I withdrew. This discussion is about building a proposal for changing icons at a large scale. Aasim (talk) 02:46, 4 August 2021 (UTC)
The feedback should not have given you the impression that a change in icons is uncontentious and doesn't require community input. (What would you propose in lieu of community input?) isaacl (talk) 04:50, 4 August 2021 (UTC)
In fact, to quote Izno: I do not think this question is ripe for an RFC. I see no recent discussion and I certainly see no major significant dispute needing resolution. I see a lot of "we should do this" but not a lot of "here's my solution". This is the drawing board, this is the place to figure out how the proposal should be done before it is proposed again via RFC. Aasim (talk) 09:00, 4 August 2021 (UTC)
That's a separate issue from the point I raised. (Please rest assured I read your posts and the previous discussion; there's no need to repeat yourself.) isaacl (talk) 19:40, 4 August 2021 (UTC)
Nowhere in Wikipedia guidelines or policies does it say that things should be done because they are modern or trendy, or for some reason have to be changed even though Wikipedia has only been in existence for just over 20 years. This can only be considered if you tell us some genuine benefits that changing icons brings rather than such fripperies. And claiming, after your previous such proposals, that such a change would be uncontentious is simply mind-boggling. I'm afraid it loses you any credibility that you might have had. Phil Bridger (talk) 05:28, 4 August 2021 (UTC)
I think this is more about graphic design; these templates are visible to readers of any page all over Wikipedia. While most readers could care less about these templates, they probably could care more about how a page looks if they were to say, screenshot it or print it out. The last thing we want is that in a decade or so, Wikipedia looks like a site from thirty years ago in 2030. Having non-flat icons like File:Information icon4.svg could possibly degrade from that look. I know WMF is working on a new and improved vector skin with features like responsive design so that Wikipedia can look as modern as it can possibly be. Changing the icons to flat icons would help with this move, especially because almost every modern website from wikiHow to FANDOM to Google and Facebook uses flat design, and websites that do not use flat design look very old and archaic. Aasim (talk) 08:57, 4 August 2021 (UTC)
I, for one, am perfectly happy with a web site that looks 20 or 30 years old, which, by the way, isn't anywhere near archaic. We're an encyclopedia, not some super-duper fun app for right-on teenagers, so that is the type of look we should be going for. Phil Bridger (talk) 09:05, 4 August 2021 (UTC)
That is not to say that others may or may not find it engaging. What kind of boggles my brain is that MediaWiki wiki was able to switch over the icons with no problem, but here we have this kind of debate over if or whether these icons should be switched.
The web is also moving on; you no longer see as many websites that have "mobile versions" of websites under an "m" domain and you see more websites that just adapt to all screen sizes. This idea has nothing to do with responsifying Wikipedia's skin. That is already being done by WMF. It is just about the icons in Template:Mbox.
Another thing to consider is load times. Take for example, File:OOjs UI icon information-progressive.svg ( ) and its non-flat counterpart File:Information_icon4.svg ( ). From my understanding, all the rendering happens on Wikipedia's servers then sent to the browser. The file size of the non-flat icon at 40px is three times bigger than the OOjs-UI flat icon. Not sure if it is a significant impact compared to the size of some of our pages being 150KB, but when loading something on your mobile phone or on a poor Internet connection, every single byte matters.
And yes, we are an encyclopedia. I am not doubting that. This is just an idea in the works. If proposed correctly, it is possible for some to say "you know what, yeah, this is a good idea." or for people to be indifferent to the change, rather than people complaining that "the newer modern interfaces are harder to use" as TransporterMan put it. This is not about the UI for Wikipedia. Just the icons. Should have made that clear.
I'll probably work on finding suitable flat alternatives to each of the icons that could be changed that are easy to understand to build this idea, but I do not think there will be a set timeline. My understanding of flat design is that it is supposed to feel less clunky and cluttered and easier to understand compared to skeuomorphic design. Maybe it is just personal preference that I prefer the flat version of icons. I don't know. (On a side note: We already redid our protection icons to something flat mainly because the non-flat padlocks were difficult to understand for someone with color blindness.) Aasim (talk) 10:46, 4 August 2021 (UTC)
Now you are starting to give valid reasons for changing the icons, such being less clunky and offering better accessibility. Being more "modern" or following the herd to look more like Google and Facebook are not valid reasons. The first is neutral and I would say that the second is negative. We should be distinguishing ourselves, not looking like other sites, and setting the trends, not following them. Phil Bridger (talk) 10:55, 4 August 2021 (UTC)
Agreed. I think the real reason for making a switch to an icon is to make us Wikipedia look professional. That is also why we have rules as to what is allowed on user and talk pages and what is not.
From an accessibility standpoint, some design decisions made by flat web designers actually impeded usability, for example by removing cues that a link is clickable. Fortunately, Wikipedia has not done that. I think there are probably good reasons that Microsoft, Google, Apple, then Facebook moved towards a more flat interface that goes beyond looks and trends. That is what I haven't figured out yet lol. Aasim (talk) 11:14, 4 August 2021 (UTC)
@Awesome Aasim: the community on "MediaWiki wiki" is very very small, and is primarily comprised of technical-minded editors, and their readers are primarily there looking for documentation. It is certainly not representative of the community or readership of large content projects such as the English Wikipedia. — xaosflux Talk 13:21, 4 August 2021 (UTC)
Leaving aside the problems that others have already pointed out, I also note that most of those icons are under the Expat license. That license includes a clause that "The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software", which means we need to maintain the link to the file description page to satisfy that requirement. It would be better if you'd select icons that are public domain or CC0 as people tend to like to suppress the link. Anomie⚔ 11:13, 4 August 2021 (UTC)
Even more interesting... although I think that may apply if we were to use all the icons or if we were to duplicate and modify the software that generates and uses these icons [19]. The majority of the icons would be too simple to be copyrightable anyway, given that they are below the United States threshold of originality, so I would not see how omitting a link would be a problem. The main reason for using the OOjs icons in particular (which is separate from using flat icons) would be that this is what MediaWiki software uses, and people like the right mix of novelty and familiarity. They have probably seen these icons on MediaWiki or when they were looking for some button on mobile or when they were using the VisualEditor. Aasim (talk) 11:26, 4 August 2021 (UTC)
That's a lot of assumptions. The licenses on the individual images don't depend on using "all" of them or on whether we're modifying software. If they're too simple to copyright, then they should be labeled as public domain rather than Expat (but not all of them are too simple). How many people actually use mediawiki.org, or pay attention to icons in mobile, or VE? Anomie⚔ 11:40, 4 August 2021 (UTC)
  • I took a look at the suggested flat icons. To my eye, they look cartoony and amateurish - not professional at all. So… while this is not a “never” !vote, I have to say “no”. Blueboar (talk) 12:02, 4 August 2021 (UTC)
    Cartoony? I don't think so at all. A simplified icon doesn't look "cartoony".
    The main problem is that most Wikipedia editors brand themselves as knowing what's "best for the readers". I've always wanted to change the FA icon to File:Symbol star gold.svg, but I'm sure that'd be met with huge criticism where "the current FA icon is iconic to readers" or "what's the problem with the current icons?". By the time Wikipedia actually changes it's icon style to something consistent and usable there'll be some new style that makes this look outdated. — Berrely • Talk∕Contribs 13:27, 4 August 2021 (UTC)
    You have explained there quite accurately why Wikipedia should not attempt to follow trends. Only people who are interested in such shallowness worry about things like looking "outdated". And I can't for the life of me imagine how avoiding such ignomony benefits readers. I wish people would get into their heads that most people couldn't give a fig about the latest fashions in graphic design. Phil Bridger (talk) 14:17, 4 August 2021 (UTC)
    It's not about whether "it's the latest trend", Wikipedia will always be outdated and there's no changing that :). However there many advantages to using simplified icons. Especially at smaller scales the details of these icons, such as drop shadows and gradients, disapperar completely and often make it harder to understand what the image is. Consistency is also important. Wikipedia amboxes, messages and other notices all use a wild array of barely consistent icons (we do seem to use the Tango set most commonly). These icons are already being used in parts of Mediawiki, such as the mobile site and the newcomer's homepage. It's much easier to quickly understand an icon when you have seen an icon similar to it before. — Berrely • Talk∕Contribs 16:20, 4 August 2021 (UTC)
  • Agree that those proposed icons looks very cartoonish. Not at all what an encyclopedia should look like. --Khajidha (talk) 18:31, 4 August 2021 (UTC)
  • I'm not opposed to updating or replacing some of the icons in principle (I do really like the idea of swapping FA's to that star icon Berreley mentioned, it fits much better with the good article icon), but I'm not sure that these are really the set to replace them. They don't really seem to work as a set to me. Some specific feedback:
    • With the minimalist sans-serif font it's difficult to tell the difference between "shape with an i indicating information" and "shape with an ! showing a warning".
    • Why do the normal deletion and speedy deletion message boxes now have different icons? They both warn of impending deletion.
    • with the original clean-up templates the different icons made it clear what issue each issue addressed - brush for tidying, blue i for information, orange ! for issues. With the new icons this information has been reduced entirely to colour, and I don't think it would be obvious to readers that a yellow dot means "minor clean-up" or an orange dot means "content issues".
    • Why does the level 3 user warning template use a completely different design, colour scheme and font compared to all the other icons?
    • Why is the "on hold" icon a yellow information sign? Wouldn't a clock make more sense for waiting?
    • Why has the stop question mark changed shape? I thought the whole point of that icon was that it looked like a stop sign.
Regardless of my thoughts on this set of icons any change is not going to be a "minor" alteration, and will certianly require a rfc advertised on cent. If I were to be proposing it I would do it one set of icons at a time, I think you would have a better chance of ending up with some kind of consensus rather than a trainwreck. 192.76.8.91 (talk) 21:03, 4 August 2021 (UTC)
Take a look at the colored clock icons that exist for the {{unblock}} template:
  •  
    Unreviewed
  •  
    On hold
  •  
    Declined
  •  
    Accepted
Per MOS:ACCESSIBILITY and web accessibility guidelines, we should never exclusively use color to communicate information, as people who are color blind cannot distinguish at first glance what these icons mean, especially for those with red-green and blue-yellow color blindness at best and full color blindness at worst. That is why the padlock icons were changed to begin with to include more visual information. The three icons that I am suggesting replace this as I build my proposal are easy to understand at first glance as to what they mean, if someone scrolls past and just sees "unblock" at the top of the page:
  •  
    Unreviewed
  •  
    On hold
  •  
    Declined
  •  
    Accepted
These icons will fit the unblock template fine, although someone could possibly modify File:OOjs UI icon pause.svg so that it is available in yellow.
And about the icons looking too cartoonish: I disagree. These icons are flat, like what flat design is. An example of a cartoonish icon would be this. Aasim (talk) 23:40, 4 August 2021 (UTC)
@Awesome Aasim: So firstly, just to pile on the above, this is absolutely controversial and given your involvement in previous efforts it's beyond me how you could think it didn't need community consideration. Beyond that, while your example of cartoonish is definitely that, it also is an example of picking something that's an ultra-example of such so as to be able to state that examples less far along the spectrum don't belong in the same bucket. I also feel that your examples do look cartoonish, and would want to see better examples before supporting them. I do generally support efforts to include non-colour information in - and in that specific sense, ones in a similar vein to your examples could be a good shift if, and only if, you can resolve the other issues. Nosebagbear (talk) 23:58, 4 August 2021 (UTC)
I don't know why I thought this would be uncontentious either 🤷‍♀️
About the cartoonish icons, maybe it would be better to visualize what some of the templates would look like with these icons, and we could go from there. If I can find a better set of icons, that would be excellent. I'll take that into consideration. This is the idea lab, after all :) Aasim (talk) 00:02, 5 August 2021 (UTC)
And to counter the argument that the icons are too cartoon-y: These icons have already been in use on mboxes on mobile: An American in Paris - Wikipedia. Since they already have widespread use on the mobile site, why not expand it to desktop? Aasim (talk) 00:47, 5 August 2021 (UTC)
So, you are saying that because someone else did something stupid, we should too?--Khajidha (talk) 00:55, 5 August 2021 (UTC)
Stupid or not stupid is subjective. I think consistency is also important; our current icons are mostly inconsistent with mobile and the rest of the MediaWiki interface.
And remember that this is the idea lab: it is the place to work on proposals before sending it off to community consensus. And how can we comment on a specific icon when we cannot visualize its potential use? Unlike the Padlock RFC, which was easy to visualize since the icons can clearly be seen in the corner of every page, most of these icons that I am proposing to be changed are used in message boxes, interface messages, and the like.
One important thing is form follows function, something that the unblock request clocks in my above example does not follow. For someone who is fully color-blind, it will look like something is pending, rather than declined or accepted. Hell, even I would see something like this as pending if I were a new editor and did not understand what the colors for the block clocks meant. A check mark reads as "done", an ex mark reads as "not done", a clock reads as "pending", and that OOUI pause symbol reads as "on hold".
I think one thing to aim for is consistency across the board: I maybe propose a few different icon sets (some which are PD instead of CC or MIT) that we could use on Wikipedia, and whichever icon set is more popular we just fork and modify for use on Wikipedia's messages. We also want to make sure that the messages communicated by the icons are the messages we intend to communicate. Aasim (talk) 01:35, 5 August 2021 (UTC)
I don't think you'll get very far with an argument that we should be consistent with the weird hacks that they've done in the mobile site, given all the other hugely bad ideas they've implemented in the past (often in the name of "design") like hiding the existence of talk pages from mobile editors. Anomie⚔ 12:41, 5 August 2021 (UTC)
I think we should start by examining the question of whether we even should use these icons. --Khajidha (talk) 19:14, 5 August 2021 (UTC)

Really, what do we know?

Maybe we should take a different approach. What happened to readers' input? After all, readers are the ones who are using Wikipedia, we are modifying it: WP:CREEP strikes again. User:Berrely made a good point: We don't know much about our readers. Maybe our readers are Gen Z teenagers. Maybe our readers are scientists who understand jargon. What do we know?

Is there some way we can poll our readers to see what they want? If this has been tried before, don't heckle me, come up with a better solution. Sungodtemple (talk) 14:30, 5 August 2021 (UTC)

I'm sure somewhere in one of the hundreds of research papers about Wikipedia that are released every year, there's something like this. A poll or survey could be interesting, but I'm sure if something like that were to go through it would require coordination with WMF on how to do it, as well as people generally wanting to use it again. It's no simple feat.
I just know that most people I know prefer icons that are clean and consistent. I do agree some of these icons are oversimplified or inappropriate, why is speedy a different icon? Why is the unblock on hold icon not a clock? However, I disagree that some icons are too hard to understand, e.g. this is much better than this at a low resolution.
The real answer is that we don't know what most readers want. Me asking a few people certainly doesn't represent everyone's view. However I definitely do know the simplicity and consistency are very important, especially when it comes to icon design. — Berrely • Talk∕Contribs 15:04, 5 August 2021 (UTC)

Political positions bloat in articles of politicians

Latest comment: 3 years ago1 comment1 person in discussion

If you use Wikipedia to stay informed about current politics and elections, you will be used to articles of politicians being filled with sections about their political positions. Such sections are often divided into sub-sections about specific issues and may become very long. It seems that editors will indiscriminately add a politician's statement about their political position as long as there is RS (usually news) to substantiate it. I have noticed this problem in the English-speaking countries of the US, the UK, Canada, and Australia, and it may extend to virtually every democratic country. It also extends beyond government officials, elected or unelected, to political commentators and others who are involved in politics.

Political positions bloat is unencyclopedic, excessive detail, recentism, and cruft. Remember that Wikipedia articles are summaries of their topics, not treatises, not essays, not voter guides. While politicians generate a lot of media coverage (which would be considered routine coverage in the terms of our notability guides), we do not consider every detail mention-worthy, unless it happens to be a political position. Why would we include a low-profile comment someone says about, say, marijuana, but not if they own a dog? Both will not be remembered in the long term.

The salience of political issues constantly changes, and politicians will become known for a few accomplishments or ideological opinions. Lists of political positions will not pass the 10-year test, but summaries and generalizations will. We should not include such lists for pre-21st century politicians because we are aware of what they are notable for and what is a side detail. Indeed, we find sections discussing the political positions of dead politicians, though they are not bloated with details of minor political issues. In reality, that is because the Internet and the existence of Wikipedia have enabled the expansion of lists in gradual steps. One may object that we do not know which political positions are relevant. But even without the certainty of scholarship, we should recognize what is noteworthy based on how much attention some position has garnered in RS, just as we recognize which details of personal life are notable and which are not. It is especially useful when a source explicitly states that someone is known for something.

I propose a link-able essay written on this issue (Wikipedia:Political positions, WP:POLPOS as a link?) and hope that we can soon cut down on political views sections. WIKINIGHTS talk 13:19, 9 August 2021 (UTC)

Hide offensive images and allow users to show them if they want to see them

Latest comment: 3 years ago13 comments13 people in discussion
 
Note:Image depicts an undressed, female, spider

There are people who find certain images on Wikipedia offensive or disturbing. It should be possible for those viewers to access the text of an article without being forced to view the images. There is community consensus that offensive or disturbing images shouldn't be censored. At the same time one fundamental goal of Wikipedia is to make information accessible for everyone. If the graphic nature of certain (e.g. medical) images shocks some users, the information on that page is in effect no accessible to those persons. In those cases, those images work against one of the fundamental goals of Wikipedia. I therefore propose that sensitive images are hidden by default, and can be displayed with a single click. If no consensus can be reached which images should be considered offensive or disturbing, I propose that all images are hidden – and not loaded – be default. This will have the additional effect of making both mobile browsing for users and hosting of Wikipedia cheaper.— Preceding unsigned comment added by 2003:df:972b:fc52:bc41:2309:e4d1:9069 (talk • contribs) 07:40, 3 August 2021 (UTC)

There are many browser extensions you could use to not load images if you really don't want them to load; not displaying every image by default for every reader would be a big disservice. See Help:Options to hide an image for many options available. — xaosflux Talk 10:42, 3 August 2021 (UTC)
I agree with Xaosflux. A reader who is offended by images on Wikipedia will also be offended by many images elsewhere on the Internet, so it is better to use such a general solution rather than a Wikipedia-specific one. This will also have a bigger effect on the cost of mobile browsing (if a reader is paying by the amount of data downloaded), and neither will have any appreciable effect on the cost of hosting. Phil Bridger (talk) 10:56, 3 August 2021 (UTC)
This is not a new discussion for us. Different people have different concepts as to what is sensitive. Defining one or more criteria for offensive imagery is not a realistic task for a global community. If we hid or removed everything that anyone was offended by we would offend a bunch of people who aren't offended by human shins or female faces. So it is better that we make Wikipedia freely available to everyone, and those who don't want to see certain things can write and install their own filters, and make their own version of Wikipedia. Wikipedia is openly licensed under terms that allow for such reuse. ϢereSpielChequers 11:09, 3 August 2021 (UTC)
If we hid everything that offended people, then people would be offended. 🐔 Chicdat  Bawk to me! 11:11, 3 August 2021 (UTC)
See the policy WP:NOTCENSORED. - Ahunt (talk) 13:07, 3 August 2021 (UTC)
Hiding all images is a good start, but to absolutely avoid offending readers, we may need to go a step further. Wikipedia is full of textual descriptions of all kinds of offensive things, such as Adolf Hitler, the Rwandan genocide, and Hawaiian pizza. These articles (even without images) could cause the reader to visualize offensive mental images. To show you just how bad this problem is, consider that our article on the human penis contains about 8500 words. If a picture is worth a thousand words, then the text on its own is equivalent to eight or nine potentially offensive images of a penis! In order to protect readers from offense, I propose that we hide all article text by default, and allow the user to click to un-hide it, paragraph by paragraph, to ensure they are definitely not offended. RoxySaunders (talk · contribs) 05:10, 4 August 2021 (UTC)
I think a few years ago there was a large initiative to solicit the community's opinion on this matter. It was remarkably even advertised in banners on the top of pages, if I recall correctly. It was a big deal. I wish I could provide a link to that but I don't recall where to go find it. So this is indeed a very relevant issue, that was addressed in breadth and depth some time ago. Generally I think the result was to keep leaning against censorship, or even optional hiding/displaying features. Al83tito (talk) 03:34, 6 August 2021 (UTC)
Probably one of the main discussions on this matter. See Wikipedia:Perennial proposals#Censor offensive images. The specific event you're talking about Al83tito is the m:Image filter referendum from August 2010. — Berrely • Talk∕Contribs 07:16, 6 August 2021 (UTC)
Technically we could tag files. A simple good-bad tagging is unlikely to be sufficient. We could borrow the MPA film ratings or tag based on content like being nausea-inducing, NSFW, nudity, violence and religiously offensive. We could add a class to images (e.g. [[File:Example.jpg|thumb|caption here|class=rated_g]] though this would require changes to various infobox templates which likely can't pass classes for images. Nannyware and/or a gadget could use these classes to hide undesired image classes or only display those that are rated G/unoffensive. This would very much be opt-in as the classes wouldn't do anything by themselves. I wouldn't oppose this, but it may still prove an uphill battle to get the community to embrace this. If anyone wants to try I might be able to assist but this is isn't something I'd take on myself. — Alexis Jazz (talk or ping me) 12:47, 6 August 2021 (UTC)
Your idea has already been proposed in the past, and evaluated as unworkable. The US-based movie rating system, for example, can be seen in other cultures as allowing ridiculous amounts of violence while being very prudish with respect to nudity. Category-based tagging might work slightly better, but keep in mind you'd need a lot of categories. "Image contains spiders", for example, to avoid offending arachnophobes. "Image contains visible women" to not offend people from some cultures (but that tagging might offend people in other cultures). And so on. Anomie⚔ 03:36, 7 August 2021 (UTC)
The 2010 report found four general categories covered most situations for most cultures:
  • extreme violence (e.g., photo of a wrestler gouging out another wrestler's eye)
  • sexuality (e.g., photos of sex acts)
  • religious sensibilities (e.g., Depictions of Muhammad)
  • disgusting images (mostly medical conditions; e.g., the lead image at Smallpox draws regular complaints)
With the growth of structured data about Commons images, it may someday be possible to run a script that would suppress most images of spiders (or your least-favorite politician, or whatever you felt like), but there have never been serious proposals to suppress narrow categories (e.g., only images of spiders).
Among the objections to this that I've always found unconvincing: Vandals will add politicians to the "disgusting" list/category, it will be impossible to get consensus about whether some borderline images belong in these groups, and that unsubstantiated rumor Anomie alludes to, about someone who is allegedly very offended by photos of fully clothed women, but who still uses the internet/reads Wikipedia articles regularly. However, even if everyone was enthusiastic about it, doing it effectively would still require manually reviewing and tagging millions of images, so this would require years of work to set up plus maintenance forever. There is no quick or easy fix here. Whatamidoing (WMF) (talk) 18:38, 9 August 2021 (UTC)
I see a script possible based on individual user input, where one user who sees an image under certain criteria will flag it, and then it will be blocked if a user opts into the filter. The list of filtered files will be hosted on an autoconfirmed-protected page, and no categories will actually be added to the images. Over time, the filter list will become very accurate. Of course, this relies on user participation and lack of conflict over the list. It may also require web hosting to confirm if a file is on the list so that users do not have to download very long lists of files. WIKINIGHTS talk 20:47, 9 August 2021 (UTC)
Latest comment: 3 years ago6 comments4 people in discussion

Idle thought: {{uw-van1}} etc really ought to link to a specific diff when they can. Enterprisey (talk!) 07:46, 10 August 2021 (UTC)

It makes it easier for others to see what the warning is about. And may make it easier to find inappropriate warnings. However it is too much trouble for warners to do, and it is extremely likely that the recipients know what the warning is about. So Enterprisey, I suggest that you go through all the warnings on users' talk pages and find the diff that led to it. I guess you will find it to be a waste of time. Graeme Bartlett (talk) 12:02, 10 August 2021 (UTC)
We would need to change the automated tools that place these warnings; asking patrollers to find specific revids would certainly be a waste of time. Enterprisey (talk!) 21:40, 10 August 2021 (UTC)
There's already an article parameter for the template, but not a diff template. I agree it'd be nice if we could get some of the warning tools to add one automatically. A wrinkle is that sometimes the warning will be for multiple edits on a page. {{u|Sdkb}} talk 22:17, 10 August 2021 (UTC)
Yeah, needless to say in that case we'd just go with the current behavior. But I'm pretty sure we could get a decent user experience improvement out of this nevertheless. Enterprisey (talk!) 06:56, 11 August 2021 (UTC)
Ikr. So much of this website seems to run on... manual paperwork, for things that could easily be automated with structured data. Intralexical (talk) 15:40, 11 August 2021 (UTC)

Deleted section aggregator?

Latest comment: 3 years ago3 comments2 people in discussion

Are there any tools that can automatically find and display sections that used to be in an article but have since been deleted?

I think this might unfortunately be the most insidious form of vandalism. Disinformation isn't terribly hard to spot, verify, and remove, but sourced material that has been removed can't be seen again unless you go digging through the page's history for some reason. Intralexical (talk) 15:42, 11 August 2021 (UTC)

@Intralexical: Edit filter 172 automatically tags all edits that remove a section as "section blanking". You can have a look through the filter log or you can sort recent changes to show only tagged edits, see here. 192.76.8.91 (talk) 18:02, 11 August 2021 (UTC)
@192.76.8.91:. Hm. Cool. Clunky, though. I guess it could be useful as an scraping/API endpoint for generating a more robust display. Intralexical (talk) 21:03, 11 August 2021 (UTC)

Possible redesign of Template:AFD help

Latest comment: 3 years ago41 comments10 people in discussion

Hello,

I have been spending some time in the sandbox of Template:AFD help, trying to fix some problems I perceive with it:

  1. Because it's positioned below the "previous AfDs" box, they're designed to appear as the same size. This causes a lot of whitespace, sometimes with both templates.
  2. The "Hide this box" link is surrounded by square brackets. One person on the talk page for the template felt that this suggested it should be a button that actually hides the box; compare with Template:Hidden and Template:Collapse which have action links in square brackets.

Below are some possible redesigns, transcluded from Template:AFD help/testcases:

Possible redesigns of Template:AFD help
Comparisons

Current live code

[Hide this box] New to Articles for deletion (AfD)? Read these primers!

Sandbox code

[Hide this box] New to Articles for Deletion (AfD)? Read these primers!

Any feedback is appreciated. Also, please feel free to suggest other possible designs. Regards, DesertPipeline (talk) 05:38, 15 August 2021 (UTC)

Comments (Possible redesign of Template:AFD help)

Comments by Headbomb (Possible redesign of Template:AFD help)

This idea/proposal is fundamentally flawed and is based on several misconceptions.

  1. Firstly, the template doesn't cause "a lot of whitespace". {{AFD help}} is designed match the width of the box containing previous AFD discussions. It doesn't cause AFD links to 'have a lot of whitespace', that's caused by the AFDs link box itself, being of width 33%.
  2. Secondly, the proposal entirely ignores that {{AFD help}} comes after the previous AFDs link box, not before. More specifically, that means that all the mockups should look like the two examples below, not the way DesertPipeline imagines them to look like. This would be applied retroactively to tens of thousands of AFDs (65815 as of writing), borking them up, causing misalignment and a jarring clash in presentation.
  3. Thirdly, and perhaps more importantly, there is no actual problem with the current template. It is perfectly functional, and DesertPipeline's problems with it simply amounts to WP:IDONTLIKEIT. There's half a dozen proposed redesigns, all incoherent, changing the colour of the box for no reason, to the alignment of the box for no reason, to width for no good reason, explicitly cause a mismatch between the two boxes.
Example 1 (Live sandbox, since it changes all the time); Original Wikipedia:Articles for deletion/Daniel Carver (3rd nomination)

The following discussion is an archived debate of the proposed deletion of the article below. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the article's talk page or in a deletion review). No further edits should be made to this page.

The result was no consensus. Sandstein 06:33, 1 July 2018 (UTC)

Daniel Carver

[Hide this box] New to Articles for Deletion (AfD)? Read these primers!

AfDs for this article:

Daniel Carver (edit | talk | history | protect | delete | links | watch | logs | views) – (View log · Stats) (Find sources: Google (books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL) Doesn't seem to satisfy WP:GNG. Ambrosiaster (talk) 17:56, 1 June 2018 (UTC)

Note: This discussion has been included in the list of People-related deletion discussions. MT TrainTalk 07:58, 2 June 2018 (UTC)

Relisted to generate a more thorough discussion and clearer consensus.
Please add new comments below this notice. Thanks, North America1000 07:13, 9 June 2018 (UTC)
  • Keep The sourcing in the article seems weak and I do not believe it is enough to justify an article in itself. This [20] indicates there was a Nightline interview with him so NEXIST comes into play. If he were simply some Howard Stern Show interviewee I would not think there is enough out there on which to base an article but there is nearly always something reported in RS before Nightline becomes interested. Jbh Talk 14:16, 9 June 2018 (UTC)
  • Keep I also think the 3 different, reliable sources are enough to keep this article. While it is a stub it's cited, and neutral. SEMMENDINGER (talk) 23:25, 9 June 2018 (UTC)
  • Delete local area coverage does not show notability. This really fails any reasonable reading of our fringe coverage guidelines. A few local interests stories in newspapers do not overcome the inherent problems of this article.John Pack Lambert (talk) 19:17, 13 June 2018 (UTC)
Relisted to generate a more thorough discussion and clearer consensus.
Please add new comments below this notice. Thanks, Sandstein 18:28, 16 June 2018 (UTC)
Relisted to generate a more thorough discussion and clearer consensus.
Please add new comments below this notice. Thanks, Enigmamsg 05:09, 24 June 2018 (UTC)
The above discussion is preserved as an archive of the debate. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the article's talk page or in a deletion review). No further edits should be made to this page.

The following discussion is an archived debate of the proposed deletion of the article below. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the article's talk page or in a deletion review). No further edits should be made to this page.

The result was no consensus. Sandstein 06:33, 1 July 2018 (UTC)

Daniel Carver
AfDs for this article:

Daniel Carver (edit | talk | history | protect | delete | links | watch | logs | views) – (View log · Stats) (Find sources: Google (books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL) Doesn't seem to satisfy WP:GNG. Ambrosiaster (talk) 17:56, 1 June 2018 (UTC)

Note: This discussion has been included in the list of People-related deletion discussions. MT TrainTalk 07:58, 2 June 2018 (UTC)

Relisted to generate a more thorough discussion and clearer consensus.
Please add new comments below this notice. Thanks, North America1000 07:13, 9 June 2018 (UTC)
  • Keep The sourcing in the article seems weak and I do not believe it is enough to justify an article in itself. This [21] indicates there was a Nightline interview with him so NEXIST comes into play. If he were simply some Howard Stern Show interviewee I would not think there is enough out there on which to base an article but there is nearly always something reported in RS before Nightline becomes interested. Jbh Talk 14:16, 9 June 2018 (UTC)
  • Keep I also think the 3 different, reliable sources are enough to keep this article. While it is a stub it's cited, and neutral. SEMMENDINGER (talk) 23:25, 9 June 2018 (UTC)
  • Delete local area coverage does not show notability. This really fails any reasonable reading of our fringe coverage guidelines. A few local interests stories in newspapers do not overcome the inherent problems of this article.John Pack Lambert (talk) 19:17, 13 June 2018 (UTC)
Relisted to generate a more thorough discussion and clearer consensus.
Please add new comments below this notice. Thanks, Sandstein 18:28, 16 June 2018 (UTC)
Relisted to generate a more thorough discussion and clearer consensus.
Please add new comments below this notice. Thanks, Enigmamsg 05:09, 24 June 2018 (UTC)
The above discussion is preserved as an archive of the debate. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the article's talk page or in a deletion review). No further edits should be made to this page.

This is bike-shedding at its finest. Headbomb {t · c · p · b} 06:42, 15 August 2021 (UTC)

User:Headbomb: I'm confused. Previously, you stated that there was no relation between the previous AfDs box and the help box – that was why you said you didn't think the version with the help box inside the previous AfDs box works. I agree with you. But now you're saying that the changes explicitly cause a mismatch between the two boxes. That is the intent; they aren't related boxes. Putting the help links elsewhere allows us to make the previous AfDs box a dynamic size, avoiding a load of whitespace which would occur if the links inside that box aren't as long as the box itself. DesertPipeline (talk) 07:04, 15 August 2021 (UTC)
I said there were no hierarchical link between the AFD help box and the previous AFD discussion link box, because you wanted to put the AFD help box inside the previous AFD discussions link box, making it appear as a sub-level of the previous AFD discussions link box. AFD helps is not a sub-level of previous AFD discussions, conceptually or practically, which means it is inappropriate to present as such and is bad design. Changing the width of one box without changing the width of the other box will cause a mismatch in width between the boxes, and that's also bad design. Headbomb {t · c · p · b} 07:07, 15 August 2021 (UTC)
User:Headbomb: And, likewise, they are unrelated in every other sense. There's no rule saying that the help links have to go after the previous AfDs box. They're two different sets of information for different purposes: One for helping people new to AfD, and one for linking to previous discussions on the article in question.
Changing the width of one box without changing the width of the other box will cause a mismatch in width between the box, and that's also bad design.
Currently, both boxes have to be the same size to not look strange. That's also bad design. The help box will never have enough text to fit all of that area; the previous AfDs box might. That's why I believe that the best solution is to move the help box elsewhere. Do you have any other suggestions? DesertPipeline (talk) 07:14, 15 August 2021 (UTC)
"There's no rule saying that the help links have to go after the previous AfDs box." There is. Namely, the ~65815 previous AFDs, as of writing, where {{AFD help}} is after the previous AFD discussions box. These won't magically change positions if the template is editted. Headbomb {t · c · p · b} 07:17, 15 August 2021 (UTC)
User:Headbomb: On Wikipedia, we are familiar with retaining things for historical reference. But that doesn't mean we can't change what we're doing; this is an argument of "We've always done it this way; therefore, it should stay this way". It's perfectly fine to leave existing AfDs with the current layout. Only new AfDs would use the new one. Is that an issue in your opinion? DesertPipeline (talk) 07:19, 15 August 2021 (UTC)
And, like I said to you before You could in theory design something that's used on a go forward basis, but you'd need to redesign the AFD link box, the AFD help box, both should line up and be of equal width, then redesign the AFD workflows to make use of them. And then you'd need an RFC to roll out the changes. You cannot do so simply by editing {{AFD help}}, you need new templates entirely, and then redesign AFD around those new templates. Headbomb {t · c · p · b} 07:21, 15 August 2021 (UTC)
User:Headbomb: Why do you consider it a requirement for the previous AfDs box and help box to line up? I don't believe there's any way to do that which will fix the whitespace problem. However, if you have any suggestions, please state them. DesertPipeline (talk) 07:23, 15 August 2021 (UTC)
There is no 'whitespace problem'. This is what things look like now (or at a different zoom level). If it's not an issue for the previous AFD discussion links, it's not an issue for the AFD help box either. Headbomb {t · c · p · b} 07:24, 15 August 2021 (UTC)
User:Headbomb: It isn't helpful or effective to deny the existence of a clearly-existing problem. At 33% width, the AfD help box has a lot of whitespace on the right. Do you not see this on your monitor? If so, just because it isn't like that for you, it doesn't mean it isn't like that for others. Also, I can't view your image links. If you upload them to Wikipedia, I'll be able to. DesertPipeline (talk) 07:30, 15 August 2021 (UTC)
No more or less than the previous AFD discussions link box does. It's exactly the same width. And try the links again, they should work now. Headbomb {t · c · p · b} 07:32, 15 August 2021 (UTC)
 
User:Headbomb: See the screenshot on the right. Also, when I say "I can't view the images", I mean I can't view the website. Please upload them to Wikipedia so I can view them. DesertPipeline (talk) 07:36, 15 August 2021 (UTC)
The exact same thing will happen if you go to an AFD discussion with previous AFDs discussion links with the same zoom level. So again, why is this a problem with the AFD help box, but not the previous AFDs discussion links box? Headbomb {t · c · p · b} 07:38, 15 August 2021 (UTC)
User:Headbomb: It is a problem with the previous AfDs box. Putting the help links somewhere else will allow us to make the previous AfDs box scale to fit the text inside it without having two boxes of different sizes, as it would be with the current help box. DesertPipeline (talk) 07:40, 15 August 2021 (UTC)

Here are the same screenshots:

  •  
    Zoom level 1
  •  
    Zoom level 2

Headbomb {t · c · p · b} 07:42, 15 August 2021 (UTC)

User:Headbomb: Your first screenshot demonstrates that the problem exists. We should try to make it look good on all (or most) displays. DesertPipeline (talk) 07:45, 15 August 2021 (UTC)
Which, for the at least third time now, you cannot do in a vacuum.

You could in theory design something that's used on a go forward basis, but you'd need to redesign the AFD link box, the AFD help box, both should line up and be of equal width, then redesign the AFD workflows to make use of them. And then you'd need an RFC to roll out the changes. You cannot do so simply by editing {{AFD help}}, you need new templates entirely, and then redesign AFD around those new templates.

Headbomb {t · c · p · b} 07:46, 15 August 2021 (UTC)
User:Headbomb: We can start from what we have right now; if it requires that a new template be made, then that's fine. Currently it's in the testing stage, and there's no reason to make a new template until we know what we're going to do. Right now I want to see if anyone has other suggestions. Are you saying, though, that the layout I suggest with a messagebox at the top is a bad design? If so, why? DesertPipeline (talk) 07:51, 15 August 2021 (UTC)
You've got seven million designs going on. Messages boxes are overkill for what is effectively "BTW" side information and it makes no sense to put previous AFD discussion links in a message box, and it will break old pages/require a massive effort to rollout (depending on the specifics). Leave the bike shed alone. Headbomb {t · c · p · b} 07:55, 15 August 2021 (UTC)
User:Headbomb: So if you think the messagebox design isn't a good choice, please suggest an alternative. Otherwise, I'm not really sure how it helps to just keep talking about bike sheds over and over. I recognise you don't want anything to be changed. Please stop telling me over and over. I'm not going to stop talking about it until a conclusion has been reached (either a change which takes into account all requirements is suggested or I have been convinced that it actually doesn't need changing). The "bike shed" thing isn't convincing me that it doesn't need changing. DesertPipeline (talk) 08:02, 15 August 2021 (UTC)
The current design is working just fine, and saves everyone considerable headaches. The alternative to your proposals is the status quo. Your eyes won't start bleeding because there's more whitespace than you'd like in some situations (i.e. big zoom out levels). Leave the bike shed alone. Headbomb {t · c · p · b} 08:16, 15 August 2021 (UTC)
User:Headbomb: My zoom level is 100% and my monitor is 1920x1080. It's displaying like this on a standard setup. DesertPipeline (talk) 08:26, 15 August 2021 (UTC)

Is any bot allowed to create Wikipedia articles unassisted?

Latest comment: 3 years ago10 comments6 people in discussion

Apologies if this is the wrong place, willing to move this question if this is the case. Is there any bot currently on the English Wikipedia which creates articles unassisted? And would such a bot be allowed in the future if this isn't the case? By articles I don't mean redirects, or disambiguations. Note that this is not me making a bot request but instead just asking out of curiosity. Cheers, Rubbish computer Ping me or leave a message on my talk page 18:21, 16 August 2021 (UTC)

See WP:MASSCREATION; bots can only create articles with pre-approval. ProcrastinatingReader (talk) 18:28, 16 August 2021 (UTC)
I'm not aware of any currently approved article-creation bots, and any request that went to WP:BRFA would require a strong consensus for the task - with the amount of support, advertisement, and participation proportional to the size of the task. Getting a task to do something like "Create 200 articles on this specific bacteria family based on this well regarded public-domain source" are much more likely to be approved then for example doing what ruwikinews is doing with mass-mirroring external sources in to their project. — xaosflux Talk 18:32, 16 August 2021 (UTC)
I believe User:Qbugbot is the most recent instance of a bot approved to create articles; see Wikipedia:Bots/Requests for approval/Qbugbot 2/ Plantdrew (talk) 19:07, 17 August 2021 (UTC)

Thank you both, will read more about it at the links provided. Rubbish computer Ping me or leave a message on my talk page 18:34, 16 August 2021 (UTC)

Xaosflux I didn't realise ruwikinews did that, sounds like a mess. Rubbish computer Ping me or leave a message on my talk page 18:36, 16 August 2021 (UTC)

They are copying verbatim professionally written news articles that were placed into Creative Commons after the Putin regime forced the closure of this newspaper as it was critical of the regime. This might have unintended results since anyone including pro-Putin elements can now edit those articles requiring constant vigilance to monitor millions of articles. A read-only archive might have been better. -- GreenC 19:35, 16 August 2021 (UTC)

@GreenC: sounds like something more aligned with the Internet Archive capabilities. — xaosflux Talk 17:55, 17 August 2021 (UTC)

CU policy exception for handling OS requests

Latest comment: 3 years ago8 comments5 people in discussion

Background

Earlier today I stumbled upon a help request from a user asking for suppression of the IP associated with an edit they made while accidentally logged out. The request didn't include a diff of the problematic edit (duh), but since such requests are routinely granted, I thought someone at #revdel would be able to CU the user and find the edit in question. To my surprise, this couldn't be done because our current CU policy precludes such checks.

Idea

I believe that adding an exception to our CU policy that would allow Oversighters who are also CUs to use the CU tool to expedite the handling of incomplete suppression requests would be an improvement on the current situation in which the requester is needlessly required to supply the missing information before their request can be actioned.

Global CU policy compliance

The global CU policy allows individual wikis a degree of latitude in handling self-requested checks; I believe that filing an OS request (regardless of its form) such that it requires user IP information to handle can be regarded as such a request and so the exception would be in keeping with the global policy. An argument could be made that such a check might reveal more than the user wanted us to know but this is always the case with self-requested checks and doesn't clash with the long-standing practice of allowing such, globally speaking (enwiki currently disallows self-requested IP checks wholesale).

Is this really necessary though?

I'd imagine that the typical profile of a person that inadvertently reveals their IP while logged out is that of a careless new editor. Such are notorious for being difficult to reach when a follow-up is needed which means their perfectly valid OS requests may end up rejected, or significantly delayed, due to purely bureaucratic hurdles. That sounds to me like a situation that could and should be improved upon regardless of how often this actually happens.

Mock-up phrasing

My proposed policy amendment would roughly look something like this:

As oversight requests are often time-sensitive, oversighters who are also checkusers are permitted to perform CU checks to expedite the processing of incomplete suppression requests. Information obtained through such checks may be used only for that specific purpose, and must not be shared; it also must not be retained, or even accessed, by the oversighter any longer than absolutely necessary for the handling of the request.

Is this something worth proposing at VPP? I'd appreciate some feedback. 78.28.44.31 (talk) 05:57, 26 July 2021 (UTC)

Thing is, considering the avg response time of oversight, I don't know whether having to follow up once with the diff of the edit is a big slowdown. The delay here was because the user apparently didn't know oversight could be used for this, but usually editors would, and so they would email into the queue or email an OSer directly, presumably with the diff of the logged out edit. So I suspect this particular case is very uncommon and not worth amending the CU policy over. I'm surprised CU can't be used to actually verify the OS request though, but I suppose in most circumstances it's probably obvious from the context. ProcrastinatingReader (talk) 09:33, 26 July 2021 (UTC)
It's not the response time of Oversight that's the problem here though, is it? It's the fact there's a needless roadblock in the policy that occasionally stops them from doing their job. Thanks for pointing out request verification as a potential consideration; I haven't even thought of it! If I take my idea to VPP, it'll need a complete rewrite to accommodate that concern, that's for sure. 78.28.44.31 (talk) 00:05, 17 August 2021 (UTC)
I can't find a circumstance where material cannot be suppressed because policy somehow gets in the way. The cases such as the one mentioned above are just people not knowing or realising how to request suppression (OS requests should always be private and made with the relevant info such as an IP in this instance), and we shouldn't charge the CU policy to accommodate them. Giraffer (not) 19:28, 7 August 2021 (UTC)
Quite obviously, any material that oversighters aren't able to locate cannot be suppressed. This occasionally includes material that needs to be suppressed and could be suppressed if its location were known. Here's a real world analogy. You dial 911. You scream "fire." You run out of the building, leaving the phone behind. Should the emergency services have the ability to track your phone call to find out what your address is or not? Sure, in a perfect world, you would've provided it yourself but we don't live in a perfect world, do we? Your house is on fire so clearly we don't. 78.28.44.31 (talk) 00:05, 17 August 2021 (UTC)
  • This whole thing looks to me very much like a solution without a problem. The purpose of suppressing IP addresses for editors who have edited logged out is to prevent the connection of the IP address to the account from being publicly visible. If an administrator or oversighter can't see that information without CheckUser then it isn't publicly visible. End of story. JBW (talk) 09:15, 17 August 2021 (UTC)
  • Users have individual styles and quirks in editing. It is often possible to guess the identity of a logged-out user, especially if the logged-out edit is on a page where the user has also edited while logged in, or if the logged-out user refers to previous edits made while logged in. Users inadvertently editing while logged out has been called the "poor man's checkuser." - Donald Albury 17:03, 17 August 2021 (UTC)
@Donald Albury: I've never before come across the expression "poor man's checkuser" used in that sense. The expression was, however, once in fairly common use to refer to the fact that if an account became blocked from editing, on the contributions page of any IP address that consequently became autoblocked, the administrator link "block" changed to "change block", so that any administrator who had reasons to believe that the account and IP address were linked could see confirmation of the fact. However, the software was changed many years ago to prevent that from happening. JBW (talk) 21:08, 17 August 2021 (UTC)

Distinguish between block-type with preference gadget

Latest comment: 3 years ago6 comments4 people in discussion

I use a gadget in my preferences that shows blocked users with a strike through their username on talk pages and page histories. However, anything from a decade ago, for example, has quite a lot of strikethroughs. Some of the users are LTAs, trolls, and whatnot, but a lot are either deceased or retired or just abandoned. I was wondering if there could be some kind of difference in a perma-ban block & a deceased block, etc. Also, at ANI a 24-hr block appears the same as an indef. Maybe a perma-ban could have double strike throughs, a deceased block could be a different color, etc. Thoughts? Rgrds. --Bison X (talk) 15:55, 15 August 2021 (UTC)

How would the script determine any of these things? Headbomb {t · c · p · b} 19:41, 15 August 2021 (UTC)
The gadget already does distinguish temporary and indefinite blocks. The latter appear paler and are italicized. The gadget even provides a way to specify custom styles in your common.js. Also, the age of the block is available in the tooltip. Nardog (talk) 17:13, 17 August 2021 (UTC)
Yes, but that's because length of block is something that's easy for a script to determine. How would a script know the reason for the block? Headbomb {t · c · p · b} 03:45, 18 August 2021 (UTC)
I don't know if scripts can read the block log, but could it search for phrases "retired" or "deceased" versus "ArbCom" or "community"? If not, then, and I have no idea how possible this is, can a choice be added to the block button that allows for an "honorable" or "dishonorable" block? Rgrds. --Bison X (talk) 12:54, 18 August 2021 (UTC)
It wouldn't be difficult to write a user script that checks the user's talk page for {{retired}}, {{deceased}}, and other templates that imply things about the block. Users with those two templates aren't usually blocked, though, which is another issue. Enterprisey (talk!) 08:25, 20 August 2021 (UTC)

Add redirects to Commons talk pages for all images

Latest comment: 3 years ago1 comment1 person in discussion

Sometimes when an image becomes the subject of discussion, discussion takes place both on en-Wikipedia and on Commons. However, most images are hosted on Commons, you can't directly edit or replace the image on en-Wikipedia etc. so image talk page on en-Wikipedia probably shouldn't be used unless any discussion relates only and specifically to en-Wikipedia.

I propose that soft redirects to Commons talk pages on all pictures be added automatically.

An alternative is to add tags like Discussed on sister project or talk at enwp to en-Wikipedia file discussion pages, like is used here: https://commons.wikimedia.org/wiki/File_talk:RGB_3bits_palette_sample_image.png but I think that tag is specific to Commons.

(Why am I proposing this? I recently updated in the seating diagram of the US Senate, and found it cumbersome getting consensus both at Talk:United States Senate and c:File Talk:117th United States Senate.svg. I ended up adding a soft redirect at File Talk:117th United States Senate.svg lest discussion began in a 3rd location.)

update: please discuss at MediaWiki talk:Newarticletext instead!

Egroeg5 (talk) 02:50, 22 August 2021 (UTC)

Transcluding categories from templates

Latest comment: 3 years ago6 comments3 people in discussion

Was there a previous discussion on whether categories should or should not be transcluded from templates? For example, {{Kerala State Award for Best Actress}} could potentially transclude Category:Kerala State Film Award winners onto the articles. That would make categorization of the articles a little easy, by removing the manual need of adding cats to articles. Surely, it would also put the Kerala State Film Award for Best Actress article into the category. To counter these unwanted, a |cat=no parameter could be introduced to templates to not allow not transcluding the cats. I updated {{NSE}} and {{BSE}} to include the respective cats, and wondering if I acted too quickly. Thoughts around these? -- DaxServer (talk) 13:00, 22 August 2021 (UTC)

I had the idea from {{Infobox film}} -- DaxServer (talk) 13:09, 22 August 2021 (UTC)
@DaxServer: Wikipedia:Categorization#Categorization using templates says: "it is recommended that articles not be placed in ordinary content categories using templates in this way". PrimeHunter (talk) 13:10, 22 August 2021 (UTC)
@PrimeHunter: Should I rollback the BSE and NSE edits and add the cats back to the articles? -- DaxServer (talk) 13:36, 22 August 2021 (UTC)

Sub-categorizing non-free posters

Latest comment: 3 years ago1 comment1 person in discussion

There are about ~88,000 files under the Category:Non-free posters which will benefit from moving to sub-categories. Depending upon the article where the file is used, it could be moved. This way the huge cat could be diffused. The category can be set in the {{Non-free poster}} as the first unnamed parameter. This ideally could be done by a bot.

One straight forward action is for movie posters which are used only once on the respective movie articles. The {{Infobox film}} transcludes appropriate language category from Category:Films by language. There are not that many sub-categories by language in the Non-free posters category. My proposal is to create those categories under Category:Fair use images of film posters (under appropriate country), and assign the posters based on the Infobox transcluded category intersecting Category:Films by country on the article. In case of multi-lingual films, [I'm not sure if it transcludes all categories for multi-lingual films], the first category that one encounters would be put in the {{Non-free poster}} template and the second category would be added as a normal category.

Categories other than films could also be handled accordingly, or be left out for a follow-up work. Surely, a con that I see is the mis-categorization of the main article, (either due to unchecked vandalism, or some other reason,) resulting in the mis-categorization of the poster. The bot could also regularly check and re-categorize, or post a message for a manual check. Opinions and thoughts around this? -- DaxServer (talk) 12:09, 23 August 2021 (UTC)

What is the Best AI model for Content Moderation on Wikipedia?

Latest comment: 3 years ago6 comments5 people in discussion

Imagine you’ve just spent 27 minutes working on what you earnestly thought would be a helpful edit to your favorite article. You click that bright blue “Publish changes” button for the very first time, and you see your edit go live! Weeee! But 52 seconds later, you refresh the page and discover that your edit has been reverted and wiped off the planet.

An AI system - called ORES - has been contributing to this rapid judgement of hundreds of thousands of editors’ work on Wikipedia. ORES is a Machine Learning (ML) system that automatically predicts edit and article quality to support content moderation and vandalism fighting on Wikipedia. For example, when you go to RecentChanges, you can see whether an edit is flagged as damaging and should be reviewed. This is based on the ORES predictions. RecentChanges even allows you to change the sensitivity of the algorithm to "Very Likely Have Problems (flags fewer edits)" or "May Have Problems (flags more edits)”.

In this discussion post, we want to invite you to discuss the following *THREE potential ORES models* -- Among those three models, which one do you think presents the best outcomes and would recommend for the English Wikipedia community to use? Why?

ABOUT US: We are a group of Human–computer interaction researchers at Carnegie Mellon University and we are inviting editors to discuss the trade-offs in AI-supported content moderation systems like ORES; your input here has the potential to enhance the transparency and community agency of the design and deployment of AI-based systems on Wikipedia. We will share the results of the discussion with the ML platform team which is responsible for maintaining the ORES infrastructure. However, the decisions of the discussion are not promised to be implemented. More details are available at our research meta-pages: Facilitating Public Deliberation of Algorithmic Decisions and Applying Value-Sensitive Algorithm Design to ORES.

Model Card One: High Accuracy

  • Performance table
Group / Metrics Accuracy
Percentage of edits that are correctly predicted
 Damaging Rate
Percentage of edits that are identified as damaging
 False Positive Rate
Percentage of good edits that are falsely
identified as damaging
 False Negative Rate
Percentage of damaging edits that are
falsely identified as good
Overall 98.5% 3.4% 0.5% 26.3%
Experienced 99.7% 0.2% 0.0% 61.2%
Newcomer 95.7% 10.7% 1.8% 23.0%
Anonymous 94.8% 12.7% 2.4% 22.8%
  • Explanation: this model has the highest overall accuracy.

Model Card Two: Fair Treatment

  • Performance table
Group / Metrics Accuracy
Percentage of edits that are correctly predicted
 Damaging Rate
Percentage of edits that are identified as damaging
 False Positive Rate
Percentage of good edits that are falsely
identified as damaging
 False Negative Rate
Percentage of damaging edits that are
falsely identified as good
Overall 97.2% 1.2% 0.1% 69.9%
Experienced 99.6% 0.0% 0.0% 94.0%
Newcomer 91.2% 4.4% 0.8% 68.5%
Anonymous 90.7% 4.5% 0.0% 67.2%
  • Explanation: Compared to Model One, this model treats experienced editors, newcomers, and anonymous editors more similarly, but it has lower overall accuracy.

Model Card Three: Balanced

  • Performance table
Group / Metrics Accuracy
Percentage of edits that are correctly predicted
 Damaging Rate
Percentage of edits that are identified as damaging
 False Positive Rate
Percentage of good edits that are falsely
identified as damaging
 False Negative Rate
Percentage of damaging edits that are
falsely identified as good
Overall 96.1% 7.6% 4.0% 2.4%
Experienced 99.9% 0.4% 0.0% 17.9%
Newcomer 91.8% 19.8% 9.1% 1.0%
Anonymous 82.7% 30.8% 19.9% 0.8%
  • Explanation: Compared to Model One and Two, Model Three attempts to achieve a better balance between false positive rate and false negative rate. The false negative rate is the best among the three models. But this model has lower accuracy and higher damaging rate.

If you are not satisfied with any of the models described above, you can try out this interface, pick a model on your own, and share your chosen model card in the discussion by copying and pasting the wikitext offered in the interface.

Bobo.03 (talk) 15:32, 20 August 2021 (UTC)

Honestly, after looking at them and comparing them, in my opinion I think Option 2 would be a better option. While it has a nice high false negative rate of 69.9% overall, looking at the individual percentages show that it's mostly experienced users that would have their edits identified as false negatives. However I think that percentages don't always show the full picture. Instead I think it would be better for it to be shown as like 1 in every thousand edits is identified as a false negative, that way we can actually see what scale we're looking at. However, I think a combination of models 2 and 3 would be best as Option 2 has a low False Positive rate but a high False Negative rate and Option 3 has a high(ish) false positive rate and a low false negative rate. Blaze The Wolf | Proud Furry and Wikipedia Editor (talk) 16:32, 23 August 2021 (UTC)

Discussion Break

Hi @Bobo.03: I'm sure this has come along since my very early engagement with it. I know you are well-aware of CluebotNG, but I'd like to draw a highlight that although it once accepted a false positive rate of 0.25%, it has been changed to use 0.1% as its threshold. That hit 55% and 40% of vandalism (thus 45% and 60% false negative). That, I think, gives a pretty clear marker that Wikipedians are way more willing to accept it missing something than an unwarranted hit. Unwarranted hits kill off new users, and irk experienced users, while many issues missed can be caught by alternate means. I tried to have a fiddle with the interface but couldn't figure out how to make it apply different tolerable false positive rates to different groups. Nosebagbear (talk) 20:43, 20 August 2021 (UTC)

I would add my opinion that the false positive rates reported for option 3 are way too high for me, and I suspect for most other editors. Phil Bridger (talk) 23:08, 20 August 2021 (UTC)
I'd like to add that IMO, whatever happens to 'Experienced' editors is pretty irrelevant to me, so that leaves newcomers and anonymous edits. False positives rates above 1% are unacceptable from the outset IMO. So the 'fair treatment' table approach is the most viable one, IMO. Since this only flags, but doesn't revert, I'm OK with a higher false positive rate than ClueBot NG, but it should be sub 1% on any given categories, and lower would be even better. Headbomb {t · c · p · b} 02:24, 22 August 2021 (UTC)
Hi @Nosebagbear: Thanks for your questions! The interface, based on ORES, indeed does not allow users to apply different FPR tolerance level to different groups! Would you mind to share that in your opinion, which level of FPR is tolerable for different groups? The information would be extremely useful to improve the interface and the ORES model itself. Thank you! — Preceding unsigned comment added by Bobo.03 (talk • contribs) 18:20, 22 August 2021 (UTC)

Ability to add pages to watchlist by entering page name

Latest comment: 3 years ago6 comments3 people in discussion

Hello! So I have an idea of being able to add pages to your watchlist by simply putting the name of the article/page into a text box and it will add that article/page into your watchlist instead of having to go to individual pages and clicking on the star to add it on to the watch list. Not sure if this is already something that's been mentioned or if it's even possible because I don't know how to write code that makes Wikipedia work. Blaze The Wolf | Proud Furry and Wikipedia Editor (talk) 13:53, 20 August 2021 (UTC)

You can sort of do this at Special:EditWatchlist/raw. CMD (talk) 13:56, 20 August 2021 (UTC)
It appears to be broken for me or it just doesn't work all that well. Blaze The Wolf | Proud Furry and Wikipedia Editor (talk) 14:53, 20 August 2021 (UTC)
@Blaze The Wolf, would you please click on https://en.wikipedia.org/wiki/Special:EditWatchlist/raw?safemode=1 and let me know if it looks different from what you see at Special:EditWatchlist/raw? Whatamidoing (WMF) (talk) 16:30, 20 August 2021 (UTC)
It does. It would be what displayed on Special:EditWatchlist/raw for a brief second before showing a blank page. Blaze The Wolf | Proud Furry and Wikipedia Editor (talk) 16:32, 20 August 2021 (UTC)
@Blaze The Wolf, that means that one of your scripts is causing the problem. Check Special:MyPage/common.js or m:Special:MyPage/global.js – that's where most user scripts are stored for most editors. Feel free to compare against mine, if you want, because I have the same problem. Directions are in the mw:safemode page. Whatamidoing (WMF) (talk) 00:46, 24 August 2021 (UTC)

New Idea (Access user preferences via mobile)

Latest comment: 3 years ago4 comments2 people in discussion
Tracked in Phabricator
Task T229818

Hi guys! Please consider my Idea. The mobile view doesn't have easy access to the preferences, so I was just thinking if there was a way to change that? Twilight Sparkle 222 (talk) 22:12, 16 August 2021 (UTC)

@Twilight Sparkle 222: this requires an upstream software change, you can follow and comment on the outstanding request for this feature here: phab:T229818. — xaosflux Talk 18:01, 17 August 2021 (UTC)

Adding messages to thanks

Latest comment: 3 years ago8 comments6 people in discussion

Hello! I have a feeling I already proposed this idea but i can't remember. Anyways, my idea is the ability to add a short message to your thanks. Yes WikiLove exists, however if someone does something small and you'd like to show your appreciation, I'd find that WikiLove would be a bit overkill. For example, on my talk page, ferret fixed a WikiLove another editor gave me as when I replied to the WikiLove, it was part of the WikiLove and I attempted to fix it myself but couldn't and ferret fixed it for me. I thanked them and would've liked to leave a short little message saying something like, "Thanks for fixing the WikiLove" however I don't necessarily think something like that would be fit for a WikiLove message. Blaze The Wolf | Proud Furry and Wikipedia Editor (talk) 16:23, 23 August 2021 (UTC)

I proposed this a while back at Wikipedia:Village_pump_(idea_lab)/Archive_35#Thank_summary. The arguments are generally that the thanks is great enough that a message must be added, why not just use WikiLove? 🐔 Chicdat  Bawk to me! 10:13, 24 August 2021 (UTC)
As I mentioned in that conversation (thanks for posting the link), personalized talk page messages are always appreciated and I feel sufficient to cover this case. On a minor note, no one mentioned WikiLove in that discussion. isaacl (talk) 14:45, 24 August 2021 (UTC)
So there are all sorts of problems with this: Where would this message be stored? Would it be public or private? What do we do if someone were to use this to send inappropriate messages? — xaosflux Talk 15:33, 24 August 2021 (UTC)
I think of the current thanking system as a low-overhead way to express gratitude. If I want to add a personal message, I can always leave it on their talk page. -- RoySmith (talk) 16:02, 24 August 2021 (UTC)
RoySmith, I support that. I use thanks on a regular basis and occasionally feel the need to provide more than one word, and maybe feel that it's not quite necessary to do a wiki love message and in those cases and a drop of quick note on the talk page. Given the reasonable concerns expressed by xaosflux, that approach works for me, and I be disinclined to support the bureaucracy of an alternative system. S Philbrick(Talk) 19:05, 24 August 2021 (UTC)
Alright, so maybe instead we should propose minor wikilove? It's bigger than a thanks but smaller than a normal wikilove. Or maybe the "minor barnstar" could be used to fulfill this purpose, it would just have to have it's description changed to basically be like, "this is no longer just for thanking those who make countless minor edits" Blaze The Wolf | Proud Furry and Wikipedia Editor (talk) 17:39, 25 August 2021 (UTC)
In my opinion, I feel you can just write a message on the user's talk page, without necessarily including any barnstar template, expressing your gratitude. People really like being thanked with a personal message. isaacl (talk) 19:51, 25 August 2021 (UTC)

Election discussion space

Latest comment: 3 years ago1 comment1 person in discussion

I propose making a space for editors to openly discuss and recommend candidates in Wikimedia elections. Wikimedia is the parent organization of Wikipedia and as such takes important decisions that affect Wikipedia, therefore it is my belief that it is important for editors to discuss Wikimedia elections, candidates, make recommendations of candidates to vote for and have a space in Wikipedia for such discussions, without running afoul of rules like WP:CANVASS. Thinker78 (talk) 01:03, 26 August 2021 (UTC)

Feature Proposal: Contextual Citations

Latest comment: 3 years ago11 comments7 people in discussion

I'm interested in getting feedback for a feature I've been working on as a hobby. I have working code but it is alpha-quality.

The Problem:

Many people do not trust quotations in the media because they are suspicious that the quote may be taken out of context or fabricated.

Solution:

I've been developing an open-source app that: 

 * given a quotation which is attributed with a URL, 
 * looks up the quote context using a Python Webservice and saves the contextual data to a JSON file
 * displays the context to the reader using javascript to render contextual popups or expanding blockquotes

Proposal:

 * I propose that Wikipedia explore "upgrading" those quotations that are attributed to a web source to CiteIt-style contextual citations.
 
Screenshot: Contextual Popup used in Sample Ruth Bader Ginsburg Wikipedia article

Benefits:

The Benefit of using Contextual Citations is that readers: 

 * learn more about the context of quotes
 * gain trust in the integrity of the citation and verify that a quote wasn't fabricated or cherry-picked.

Implementation:

You can view a video and demo on my project website: 

 * View Demo

More Information:

I've outlined some of the steps to implementing this on my Wikipedia User page: 

 * https://meta.wikimedia.org/wiki/User:Timlangeman/sandbox

Open Source License:

 * All code is published on GitHub and licensed under the open-source MIT License

P.S. I'm new to the Wikipedia culture, so feel free to point out the correct Wikipedia way.

Timlangeman (talk) 03:05, 24 July 2021 (UTC)

Hi Timlangeman, thank you for your neat idea and having the tech chops to develop the code! From seeing how it works in the demonstration video, I can see this implemented in one of two ways: just as you show it, by making the quote itself clickable to bring up the contextual pop-up box, or, have this feature imbedded in the corresponding in-line citation. The question is: would this feature be used so often by readers to be it worth to make the main text clickable? Or should we minimize the "noise" in the text by having this feature a bit more discretely included within the reference? Food for thought. Thanks! Al83tito (talk) 05:35, 24 July 2021 (UTC)

Feedback Ideas: Contextual Citation UI

Hi Al83tito, I'm open to UI suggestions and I'd be happy for others to experiment with UI ideas too.

As far as the amount of link "noise", this can be handled in different ways:

  1. style the link in a visible way
  2. style the link in an unobtrusive way, but still visible on hover
  3. remove the link and move quote inspection functionality into an icon or the footnote

Sample Articles

I don't know if you saw the 8 sample articles that I mocked up? 

 * 8 Sample Wikipedia Articles

These should provide good samples for programmers and designers to experiment with.

Alternate UI Designs: Programmers Download Sample Articles

I packaged these files up into a Git repository for anyone that has UI skills and wants to experiment with different UI options. 

 * https://github.com/CiteIt/wikipedia-samples

Feedback

If you don't have programming skills, I can create mockups based on your suggestions.

Timlangeman (talk) 14:48, 24 July 2021 (UTC)

@Timlangeman, you might be interested in mw:New Developers. Whatamidoing (WMF) (talk:Whatamidoing (WMF)|talk) 20:30, 26 July 2021 (UTC)
@Whatamidoing, Thanks for that suggestion. It looks like the python Wikibot may be helpful :-). Timlangeman (talk)

I like the general idea. I do have one issue however... Wikipedia generally doesn't have many direction citations. This is because of the copyright nature of Wikipedia and because it is a tertiary source. We intentionally 'transform' and 'rewrite' points from 1st and 2ndary sources most of the time and then use references. I see that as a bit of a problem for the success of this particular tool. Do you have thoughts on that ? —TheDJ (talk • contribs) 09:05, 3 August 2021 (UTC)

This is a copyright nightmare. Even the image used to demonstrate this ([22]) is probably not acceptable, as it has a way too long quote of copyrighted text. We instruct editors to make their quotes as short as possible (if the text is copyrighted, and if they can't avoid using quotes altogether): to then add a tool that shows much longer quotes simply contradicts this. For public domain sources, fine, but for copyrighted texts, I don't think this will be acceptable. Fram (talk) 09:24, 3 August 2021 (UTC)

@talk:Fram, I'm fine with changing the length of the context so long as it is long enough to get a proper sense of the meaning. The question I have is whether it is possible to automate the process of setting the context length? I did a little bit of research into copyright law and it seems like the law is fairly subjective or at least not something that a computer can easily calculate. I don't know any copyright lawyers. Does Wikipedia have access to any copyright lawyers? I've drafted an email to Lila Baily, who is the in-house lawyer for the Internet Archive. I'm interested in hearing ideas on whether a fixed or computable length is feasible or whether each quote has to be handled on a case-by-case basis. Timlangeman (talk) 10:42, 15 August 2021 (UTC)

American Copyright: Fair Use

@Fram and @TheDJ, I did a little bit more research and consulted with @LWyatt, who has a Master's degree in Intellectual Property law.

Fram is correct that copyright can be a nightmare in many countries.

I asked LWyatt why the Internet Archive is able to publish complete archived documents. He said that this is due to the US's fair use laws. LWyatt said that just as fair use laws in the US allow the Internet Archive to host archives of complete documents, fair use would allow the US Wikipedia to publish CiteIt's contextual snippets, but only for the US version hosted in the US.

This means that to start with at least, CiteIt's Contextual Citations would have to be restricted to the US English site.

Do people have additional feedback on other isssues, such as the user interface or the general idea? Timlangeman (talk) 13:31, 27 August 2021 (UTC)

Citation Deep Linking with Google Text Fragments

If copyright issues are a barrier to contextual citations, I'm wondering what people think about using Google Text Fragments in linking to citations to help the reader more easily inspect the context of the quote. I've written up a summary aggregating some information about them: 

 * Using Google Text Fragments to Link to Specific Text

I know that there are issues with browser support and privacy. At this point, I'm mainly trying to seek what people think about them in principle. Timlangeman (talk) 21:47, 5 August 2021 (UTC)

@Mike Peel and Andy Mabbett have a talk scheduled for this weekend at Wikimania:2021:Submissions/Automatically maintained citations with Wikidata and Cite Q. They've spent a lot of time thinking about questions related to verifiability. @LWyatt (WMF), don't you have a talk about WikiCite coming up, too? Whatamidoing (WMF) (talk) 18:09, 9 August 2021 (UTC)
Yep User:Whatamidoing (WMF) - we've got a session on Sunday. LWyatt (WMF) (talk) 14:40, 10 August 2021 (UTC)

Requesting inputs

Latest comment: 3 years ago1 comment1 person in discussion

Greetings

Requesting (brainstorming) inputs regarding Manual of Style proposal @ Chronological listing of coastal townships

Thanks and warm regards

Bookku, 'Encyclopedias = expanding information & knowledge' (talk) 06:38, 29 August 2021 (UTC)

refs and notes for transclusion

Latest comment: 3 years ago3 comments2 people in discussion

There is a longstanding problem with transcluded refs and notes -- their name and group parameters sometimes collide with names/groups in the transcluding article or names/groups from other transclusions. I've made suggestions about this elsewhere in the past (some good and some hare-brained), but none of those have gone anywhere. Another approach occurred to me this morning. I'm wondering whether en editor-discoverable short unique article identifier (effectively an article-ID) which remains stable through article renamings/page-moves. If there is such a thing, or if it is easily implementable within WP,, that identifier could be incorporated by editorial convention into the name and group parameters of refs and notes subject to transclusion. This was prompted by what appears to be an instance of this problem which I fixed with a workaround in this edit. Wtmitchell (talk) (earlier Boracay Bill) 12:35, 29 August 2021 (UTC)

There is a page_id for each page in the Wikipedia database that holds the pages with a magic word to get it. See mw:Manual:page table#page_id for information. StarryGrandma (talk) 15:50, 29 August 2021 (UTC)
Thanks. I'll try to think of a way to put that to use which might be palatable to editors. Wtmitchell (talk) (earlier Boracay Bill) 18:59, 29 August 2021 (UTC)

Create Wikidata items for Files on Wikipedias

Latest comment: 3 years ago5 comments4 people in discussion

There are 2 problems that creating Wikidata items for Files on Wikipedias could solve:

  • The same/similar media on different Wikipedias and possibly Commons (if intentionally duplicated) could be linked just as articles currently are
  • These items could be used to describe Wikidata items, just as image (P18) or video (P10) does, without directly using them (which would avoid a copyright violation with non-free content).

Example of benefits:

Music release covers are copyrighted images and therefore can only be uploaded to Wikipedias. Giving them Wikidata items could allow them to be linked to other Wikipedias that have them and be used in statements on their corresponding release items.

To implement this, all we would need to do is:

  • Add a "Wikidata item"/"Create Wikidata item" sidebar link to every File
  • Initiate an effort to create items for Files and link their counterparts on other Wikis
  • Allow image (P18), video (P10), etc. to support Commons media and items as datatype values. Or, create new properties.

Wikidata already supports Files as sitelinks, so no new development is needed to implement this (unless allowing 2 datatypes for a property might be an issue).

Thoughts? Lectrician1 (talk) 22:57, 28 August 2021 (UTC)

See m:NonFreeWiki.--GZWDer (talk) 01:57, 29 August 2021 (UTC)

Feature Proposal: Citation broken warnings

Latest comment: 3 years ago6 comments3 people in discussion
Problem:

In scientific works quotations are used to directly quote another piece of literature; a source citation is usually provided directly after the quote. On Wikipedia, citations are required, but I find that text taken from a source can be broken through editing quite easily. For example, if someone provides "including the sum of all virtual worlds, augmented reality, and the Internet" and a source, someone can just delete "augmented reality", leaving a perhaps incorrect statement "including the sum of all virtual worlds and the Internet".

Suggestion

I understand that Wikipedia does not want lots of quoted pieces of text. I would like to suggest a markup tag that provides similar functionality internally, but with no visible changes on the rendered page. If I'm not mistaken the <ref/> tag is always used without text, except the citation e.g., <ref>{{citation}}</ref>.

Instead of providing something like:

including the sum of all virtual worlds, augmented reality, and the Internet<ref name="citation-name">{{citation}}</ref>

I would suggest:

<ref name="citation-name">including the sum of all virtual worlds, augmented reality, and the Internet{{citation}}</ref>

or a new nested tag:

<ref name="citation-name"><syntaxhighlight lang="">including the sum of all virtual worlds, augmented reality, and the Internet</syntaxhighlight>{{citation}}</ref>
Benefit:

To the person editing it immediately provides a visual cue of which text comes from a particular reference. On the "Related changes" and history page a visible symbol could warn when an edit happens within a quote of text without the source being updated or when a quote is deleted entirely. Editors can then know when the source needs to be checked to verify the edit was correct.--K.Nevelsteen (talk) 07:14, 27 August 2021 (UTC)

You can already use <blockquote> tag or {{blockquote}} template. Ruslik_Zero 13:49, 27 August 2021 (UTC)
you have misunderstood. I'm not talking about formatting. I'm talking about preserving the quality of text.--K.Nevelsteen (talk) 17:51, 27 August 2021 (UTC)
We call this problem "Text–source integrity".
K.Nevelsteen, have you seen Template:Ref supports2? It seems to do something similar to what you're talking about. WhatamIdoing (talk) 20:07, 27 August 2021 (UTC)
That's close. It does mean a potential editor is not visually warned to breaking text, since the text separate from the citation. Editors have to manually make comparisons to see if the text matches the citation. It makes it impossible to build in a visual warning symbol on the Related changes pages, which would help others notice changes to citations. --K.Nevelsteen (talk) 04:05, 29 August 2021 (UTC)
I am not sure how using the <blockquote> tag is different from what you are proposing? You can place the citation inside it just after the text. Ruslik_Zero 20:48, 30 August 2021 (UTC)
Latest comment: 3 years ago14 comments7 people in discussion

Inspiration:

I commonly create music release items on Wikidata for artists who may not be popular enough to have an article for every release or song they release. These releases are mentioned on their artist or discography pages, however they have no link to the Wikidata item that exists for release.

This clearly has some disadvantages:

  • If an article is created for a release with a Wikidata item in the future, editors may create a new item for the article without knowing one has already been created.
  • No link exists between the term on the article and the item. Editors could usefully cite the information and references on the item to add to the article, or vice-versa.

Proposal:

Create a template called "Existing Wikidata link" that displays an orange (or another color) link to the Wikidata item of a term for logged-in users (editors). No link displays for non-logged-in users and the text looks normal. This functions similarly to how the Wikidata edit button on templates that support Wikidata shows up only for editors.

This link will be used exactly as blue links currently are. The first mention of a relevant term on an article deserves a link.

Example:

A.C.E (South_Korean_band)#2021–present: New_agency, Siren: Dawn and Changer: Dear Eris mentions the album "Changer : Dear Eris". This release does not have an article, so it is not linked.

I created an item for this release: Changer : Dear Eris (Q108291790)

I replace the text on the article with: {{Existing Wikidata link|Q108291790}}

The text then turns orange and becomes a link to the item.

The text for the link can be automatically drawn from the label of the item or be specified as the second argument for the template.

Going further:

A link could be created for every repeated thing mentioned on a Wikipedia article.

This clearly would make source-editing articles a nightmare, however it could serve an important purpose.

Wikidata is a subset of the Semantic Web movement. One of the goals of the semantic web is to link all things on all webpages. By linking everything on an article, Wikipedia could help this movement and provide computer-interpretable contextualization for all content on all Wikpedia articles.

I'm mentioning this because it's something to think about.

When the Visual Editor eventually becomes usable for all editing actions, specific links could be implemented for all things mentioned in an article. The source text could become a convoluted system of links for all things mentioned, but not disrupt the editing of the user utilizing the Visual Editor which would provide a usable user interface to work with the links.

Additionally, AI in the future could assist in the linking of text in articles.

Feedback:

Let me know what you think of both the main proposal (which is intended to be implemented) and the future-thinking ideas of linking everything (which is not intended to be implemented at the moment). Lectrician1 (talk) 00:47, 29 August 2021 (UTC)

@Animalparty Uhhh so should one just use {{Interlanguage link}}? Is a new template not needed? Lectrician1 (talk) 02:14, 29 August 2021 (UTC)
As Pppery reminds us, it has been agreed, for what I consider to be excellent reasons, that there should not be links to Wikidata in the body of an article, so Lectrician1's proposal and Animalparty's solution are non-starters. Peter coxhead (talk) 16:50, 29 August 2021 (UTC)
@Peter coxhead @Pppery So you think that people wouldn't support the links, even if they were only visible to editors as Wikidata already is in infoboxes?
That entire RFC is a mess. Maybe people will have changed opinions after 3 years and a new RFC could be started? Lectrician1 (talk) 18:45, 29 August 2021 (UTC)
Is there any reason to think consensus has changed? * Pppery * it has begun... 19:38, 29 August 2021 (UTC)
Fairly sure it hasn’t. Blueboar (talk) 21:05, 29 August 2021 (UTC)
The underlying reasons for rejecting Wikidata links in article text haven't changed, so I would also expect that the consensus (such as it is) would be the same in a new RfC. Peter coxhead (talk) 07:00, 30 August 2021 (UTC)
+1 on that RfC without clear conclusions. Bouzinac (talk) 05:06, 30 August 2021 (UTC)
Exactly. The RFC was did not have clear conclusions and no one ever proposed anything like I'm proposing. I think my proposal is very reasonable. The text remains unlinked for most users of Wiki: non-editors. Lectrician1 (talk) 12:00, 30 August 2021 (UTC)
It did have a clear conclusion, and you're just edit warring against consensus at 1971–74 French nuclear tests because you don't like it. The claim that it does not is wishful thinking * Pppery * it has begun... 13:51, 30 August 2021 (UTC)
How on earth is "Wikidata should not be linked to within the body of the article except in the manner of hidden comment(s) as to mentioning the Q-number." not a clear conclusion? 192.76.8.74 (talk) 17:19, 30 August 2021 (UTC)
  • I don't see why this needs a template or link - HTML comments would work fine for informing editors that a wikidata item exists for something. 192.76.8.74 (talk) 17:19, 30 August 2021 (UTC)
    Users wouldn't see that the link exists without clicking edit. It also grants users the greater visibility of the existence of the item and allows them to "explore" and possibly add info to the item. Lectrician1 (talk) 16:26, 1 September 2021 (UTC)

Bold idea: the Generic Queue Toolkit

Latest comment: 3 years ago9 comments8 people in discussion

Wikipedia has a lot of queues. Two disparate examples: WP:AFC/R and WP:PERM. What if we made them all use the same technology? I have a vision. If you write a JSON page that has the following information:

  • Questions to ask requesters, and request instructions (like the "Before applying for approval" section at Wikipedia:Bots/Requests for approval/Instructions for bot operators)
  • Templates to add to the request (like the toolbox available at PERM)
  • Possible outcomes (templates the responders could use, like those listed at {{BAG Tools}})
  • Whether each request gets a new section, or a new subpage (OK, this one's a bit ambitious - let's only support the "new section" workflow for the first version)

You should get:

  • A nice form requesters can fill out (like the WP:DRN form - click "Request dispute resolution" for an example)
  • A page where new requests go (of course)
  • A nice user script to respond to requests (could look like the WP:AFC/R script, or any number of the other request-response scripts we have)
  • Nice archives

Problems this solves:

  • Not having to maintain a new "form script", "response script", and archival process for each darned queue. (This is really big. Most people don't notice this. Being the maintainer for one of these, I really notice it)
  • We can improve the user experience for every queue simultaneously
  • Users don't have to fill out a wikitext form, one of the more user-hostile things we still have
  • Responders don't have to respond by clicking "Edit section" over and over and over

Queues this could apply to, off the top of my head: DRN, BRFA, PERM, AFC/R (probably more)
Anyway, if anyone wants to help out, let me know here. This might be a bit of a heavy lift, but I'm sure it's worth it, and I know a thing or two about graceful and peaceful transitions of Wikipedia processes to newer technology. Enterprisey (talk!) 07:10, 11 August 2021 (UTC)

@Enterprisey: I could probably help you with this. TheTVExpert (talk) 21:04, 11 August 2021 (UTC)
@Enterprisey: Relevant: mw:Workflow. (The WMF intended to tackle this, once upon a time.) --Yair rand (talk) 05:30, 24 August 2021 (UTC)
@Enterprisey: I'd like to help if you do this. Tol (talk | contribs) @ 19:10, 31 August 2021 (UTC)
Yes, please. There's tons of these things. AfD, DYK, SPI, RFPP, DRV, just to name a few. User-hostile, indeed. -- RoySmith (talk) 19:20, 31 August 2021 (UTC)

Enterprisey, part of User:Alexis Jazz/LuckyRename is more or less a library. (getToken() gets an edit token, getArticletext('Main Page') gets raw page text, that sort of thing) Editing ( doAPICall() ) isn't a proper separate function atm, though I plan to change that. Not sure you could use any of it in its current state, but I hope creating a user script can eventually be made as simple as, say: 

userscriptID = 'myVoteScript';
$( '.mw-content-text' ).append('<div id="userscriptID"></div>');	// would attach to the bottom of the page
addvote = function(yourvote) {
	pagename=mw.config.get('wgPageName');
	voted = editpage(pagename, yourvote, 'append');
	if ( voted.edit.result == 'Success' ) {
		$( userscriptID ).append('<br \>You voted!');
		location.reload() }
	else { $( userscriptID ).append('<br \>Squirrels intercepted your vote. Whatcha gonna do?') }
}
$( userscriptID ).append('Vote something?<br \>');
addButton(userscriptID, 'supportButton', 'Yay support!');
addButton(userscriptID, 'opposeButton', 'Boo! Boo!');
buttons.supportButton.on( 'click', function() { addvote('* \'\'\'Support\'\'\' ~~~~') });
buttons.opposeButton.on( 'click', function() { addvote('* \'\'\'NO NEVER\'\'\' ~~~~') });

But this is largely a rough idea at this point. Not sure it'll even help here, but perhaps it could attract more coders if creating a user script was simpler.   Edit: Now that I think about it, this is simplifying on a lower level. The gadget you envision could partially be made using something like this, but wouldn't have to be. Your idea is pretty clever. Shouldn't even be that hard to create. (though the 80/20 rule applies, 80% can be written in 20% of the time) — Alexis Jazz (talk or ping me) 22:36, 31 August 2021 (UTC)

It's customary for every script/gadget writer to write a few functions that look generic and think they've developed a "library" that others too can use. In practice, it isn't as straightforward. – SD0001 (talk) 08:53, 3 September 2021 (UTC)
SD0001, so why isn't there a library? (as far as I'm aware) — Alexis Jazz (talk or ping me) 13:16, 3 September 2021 (UTC)

How long are we going to have to live with the new authority control?

Latest comment: 3 years ago2 comments2 people in discussion

A VPR discussion closed about three months ago eeked out a consensus to experiment with a new look for Template:Authority control, but it wasn't super clear even at the time what exactly the community wanted that look to be. The new design has resulted in effectively the authority control turning from a one-line bar into a navbox, which is a major expansion, and the general sense I have is that this isn't what the community signed up for. How long do we have to live with this version of authority control before it's either improved to something tolerable or rolled back? I'd encourage a little bit of discussion here, but if improvements are not forthcoming, I'd like to soon see a more formal referendum at VPR that'll carry the possibility of action. {{u|Sdkb}} talk 00:19, 4 September 2021 (UTC)

Well, there were like three VPR discussions IIRC, all reaffirming pretty much the same consensus. The thing should be removed from most articles, but it used to be more obnoxious and now it's less obnoxious (it might be more bulky, but at least it's collapsed now). I think its current state is pretty much what the community signed up for, although I'd say we should still be going one step further and removing it from all articles that aren't BLPs as per the ANI. ProcrastinatingReader (talk) 00:51, 4 September 2021 (UTC)

Indicator in watchlist of number of consecutive edits by same editor

Latest comment: 3 years ago4 comments4 people in discussion

I have come across a situation when I am checking edits in my watchlist. I for example see the last minor edit of someone and then I don't bother and keep going through the list. But behind that edit in the article's history may be a number of consecutive edits that I would like to take a look, but I didn't because I thought it was a single minor edit the editor made. As a solution, an idea is to add the number of consecutive edits next to the number indicating the size of the edit in bytes. I think this would help editors be more engaged in their patrolling by not missing consecutive edits that may be of interest to them, which oftentimes are overlooked because in the watchlist one assumes there was only one little edit made. It would also help save time by giving the editor some info that currently is obtained by clicking on the page history to see namely the number of consecutive edits by an editor. Thinker78 (talk) 00:08, 22 August 2021 (UTC)

Thinker78, I was intrigued by this idea, the concern that it would be a bit of work to implement for relatively little benefit. I'm going to throw out two options chance that they would achieve almost all of the benefits with the possibility the they might be easier to implement.
Option 1: the most recent edit is shown, and if it is part of a sequence of edits by the same editor, it will be marked as minor only if all of those edits are marked as minor
Option 2: the most recent edit is shown and if it is part of a sequence of edits by the same editor it will not be marked as minor.
I slightly prefer option 2, because I think it's easier to implement. The only downside is that it will occasionally identify and edit as non-minor when it is a sequence of two or more minor edits in the truly are minor, but if someone makes several minor edits in a row on an article on watching I might want to see what going on S Philbrick(Talk) 19:11, 24 August 2021 (UTC)
Special:RecentChanges already shows things like (3 changes | history). No doubt the WMF code for watchlists is incredibly convoluted and any change will be a pain, but the proof of concept is there. This would make no difference to me personally, but I see the use case for others (I aim to review every edit that pops up in my watchlist, and try to keep my watchlist as small as possible for that reason). — Bilorv (talk) 21:49, 28 August 2021 (UTC)
@Thinker78, Sphilbrick, and Bilorv: It does show multiple edits collapsed together, Bilorv, but those are just edits to the same article on the same day, collapsed after the data is date-sorted and grouped by page — so, they're rows that would be right next to each other anyway, and therefore it's trivial to collapse them. To do what's being proposed here, though, requires looking beyond the chronological, page-grouped dataset that's used to generate Special:Watchlist (since runs of consecutive edits will very often cross day boundaries), so that could prove quite prohibitively expensive indeed. Every type of filtering or querying currently implemented at Special:Watchlist requires nothing outside the default time-sorted edit history data.
Because this would be so expensive to generate on the fly, I'd suggest approaching it by getting the necessary information incorporated into the individual edit records at the time of their creation. When an individual edit is made to an individual article, it's trivial at that point to determine if that edit is the first, second, fifth, or seventeenth consecutive edit from that user. So it would make sense, if that information is useful, to add a tag to that effect — the same way edits are tagged as being source-edited, or done using the Visual Editor, or performed by a bot, or involving section blanking, or removing references, or any of the other... holy s---, HUNDRED-plus (I hadn't looked at the list in a while!) tag dimensions that can be used to filter the watchlist view.
If edits are tagged as being part of a series, that information _alone_ is enough to implement the second proposal from Sphilbrick. Simply suppress the minor edit tag if the "previous consecutive edits" tag is set.
Implementing the first proposal might still be tricky. I'm not sure how realistic it would be to tag each edit with the number of previous consecutive edits from the same user. If that is a possibility, it would help a lot because the processing code would know exactly how far back to go, to retrieve the full set of consecutive edits by that editor on that page, which it could then analyze however's necessary.
Even if the boundaries of the edit series are fully known, when it's not already part of the existing watchlist dataset it's an open question whether it would be feasible to pull it in while generating the watchlist data. Still, it is an interesting idea. -- FeRDNYC (talk) 21:44, 5 September 2021 (UTC)
When an individual edit is made to an individual article, it's trivial at that point to determine if that edit is the first, second, fifth, or seventeenth consecutive edit from that user. Actually, that's an assumption on my part. It's certainly much more likely to be doable in the context of performing the edit, than trying to assemble the info after-the-fact during watchlist processing, but even at edit time it would still require examining the nearby edit history for the article. But without knowing far more about the inner workings of the system, the only statements I can make about its difficulty are ignorant ones. That being said, tags already exist for things like "Non-autoconfirmed user rapidly reverting edits" and "repeated addition of external links by non-autoconfirmed user", and that fact alone tells me that taking surrounding context into account when tagging edits is far from impossible. -- 21:56, 5 September 2021 (UTC)

Browser-specific range blocks

Latest comment: 3 years ago24 comments9 people in discussion
Tracked in Phabricator
Task T291122

We've got IP range blocks, but when the ranges get wide, the collateral cost becomes prohibitive. So, how about browser-specific range blocks? You could block a wide (/18 or more) range, and specify that it only applies to a specific client string. I could see two ways to implement this. One for use by CUs, where you explicitly specify the client string (or perhaps, a pattern). The other would be a "block by example" version that any non-CU admin could use by supplying a specific edit and it would block whatever client was used to perform that edit without revealing the actual client to the blocking admin.

I'm working on a WP:Sockpuppet investigations/Rgalo10 where we'd need to block three different /18s to be effective. That's unlikely to happen, but blocking those 3x/18 in combination with a client string would be much more attractive.

Yeah, I know, people upgrade their browser. People switch browsers. People use browser-obscuring proxies. It's not perfect, but it would still be a good tool. -- RoySmith (talk) 22:13, 2 September 2021 (UTC)

People use browser-obscuring proxies. Well, you don't even need a proxy. You just need to modify the user-agent header, which is trivial. ProcrastinatingReader (talk) 22:16, 2 September 2021 (UTC)
Well, sure. I accept that there are ways to defeat this (and the professional socks at the big PR firms will certainly know how), but it will still be a powerful tool against your run-of-the mill vandals, foamers, and other low-budget LTAs who soak up so much admin time. -- RoySmith (talk) 22:31, 2 September 2021 (UTC)
RoySmith, are you saying I should apply for a job at a big PR firm as a professional sock? Two clicks seems little to boast about in a job interview, but I won't complain. Imma print some business cards! — Alexis Jazz (talk or ping me) 23:01, 2 September 2021 (UTC)
If the sock fits, wear it? -- RoySmith (talk) 23:51, 2 September 2021 (UTC)
RoySmith, I'm just saying: changing your IP is harder than changing your user-agent. And it's hard to say what collateral damage might happen when the bar for range blocks is lowered by this. If you want to target idiot vandals, I'd lean towards something that gives vandals a cookie that prevents them from editing or tags all their edits. Just as easily evaded if you know what you're doing but less risk of collateral damage. Another advantage of that would be that enwiki (or any other project) could probably implement it on their own, without support from MediaWiki developers or the WMF. — Alexis Jazz (talk or ping me) 08:50, 3 September 2021 (UTC)
Hmm, if I want to change my IP, I could switch to a different wifi network. If I were willing to attempt editing on a phone, I could have four different IP addresses just by walking down the street, without any active effort on my part. I hear that power cycling the hardware will also do that, at least for most people's home internet connections.
I don't know how to switch my user agent offhand. Presumably I'd have to spend a couple of minutes looking that up first. It might be just as easy, but I don't think it could be significantly easier than picking the neighbor's wifi network out of the menu. Whatamidoing (WMF) (talk) 17:17, 3 September 2021 (UTC)
Whatamidoing (WMF), it depends. In my neighborhood all wireless networks require a password. (mostly preconfigured ISP-issued routers) Whether power cycling results in a new IP depends on the provider. I don't know the basis for your claim that most home internet connections would be like that like that, I simply don't know what's more common. To change the user agent you install an obviously named extension from your browser extension.. store? And then it's two clicks. So using it for blocks would really only be effective if the vandal can't figure out what a user agent is. Though even in that case, they'll have a second user agent on their phone, a third on their backup phone, a fourth on their tablet, a fifth on their game console and if they realize that all they need to change is the browser, multiply all by two or three. — Alexis Jazz (talk or ping me) 01:38, 4 September 2021 (UTC)
It's clearly not an effective tool against a determined and highly intelligent attacker, but it could work against some kids. The issue I see is more with how much non-checkusers would know about these blocks, and how we would support innocent people caught in such a block. —Kusma (talk) 08:49, 4 September 2021 (UTC)
Kusma, indeed, having anything classified is to be avoided for blocks whenever possible. The kids this would work against I suspect you couldl mostly catch with a cookie as well. — Alexis Jazz (talk or ping me) 09:45, 4 September 2021 (UTC)
Alexis, I live in a place where you know your neighbors (and their kids, their pets, their out-of-town visitors, their cars, and more). It might be different in an urban environment, or if you live so far away that your neighbors' wifi doesn't reach your house. I could switch to at least two other networks right now; other people couldn't. Whatamidoing (WMF) (talk) 04:44, 7 September 2021 (UTC)
However the number of wifi networks you can reach in one place is generally limited due to physical constraints. You can change your user agent effectively in unlimited ways, after a one-time cost of learning how to do it. (With Chrome/Edge/Safari you can do it using the developer tools that come with the browser, and with Firefox you can set a configuration value, though installing a plugin makes it much simpler.) isaacl (talk) 20:23, 14 September 2021 (UTC)
@NKohli (WMF) might be interested in this idea. Whatamidoing (WMF) (talk) 17:09, 3 September 2021 (UTC)
I like the idea, however what I'm seeing is the ability to block editors who use a certain browser from editing which is not a good idea considering just how many people use Google Chrome as the browser they use for editing. Blaze The Wolf | Proud Furry and Wikipedia Editor (talk) (Stupidity by me) 15:09, 13 September 2021 (UTC)
Anyone who knows what they are doing can evade this. Google Chrome allows users to change their user agent in the developer tools. I don't remember exactly how, but I remember that it allows a very expansive range of browsers and operating systems. There are browser extensions for Chromium-based and Firefox browsers that allow someone with zero technical knowledge to do this. wikinights talk 21:40, 14 September 2021 (UTC)
Yes, it can be evaded by changing your user agent, just like people can create sock accounts and people can switch IP addresses. Switching your user agent takes more than "zero technical knowledge". You have to know that user agent strings even exist, and how to go into developer tools or install an extension (or a few other ways). Will it stop determined and educated vandals? No, of course not. It's not perfect, but it's another tool to use in the losing battle against vandals, spammers, and other miscreants. -- RoySmith (talk) 19:32, 15 September 2021 (UTC)
Understood. This feature could be very useful for blocking LTAs who hop wi-fi networks. Remember that the user agent string reports the browser version and operating system. The other would be a "block by example" version that any non-CU admin could use by supplying a specific edit and it would block whatever client was used to perform that edit without revealing the actual client to the blocking admin. I oppose this feature. As noted before, blocking user agents is prone to blocking a large number of users. When the blocking admin has no idea what they are blocking in the first place, they may block something very common (latest public release of Google Chrome on Windows 10). "Google Chrome" is not specific enough. "Firefox on MacOS on this specific version" is better. We need CheckUsers with the private data to work out the subtleties.
How could we phrase our message in a way that doesn't strongly imply we use the user agent? Your device and location are similar to those used by someone who has been blocked for abuse on the following IP range: ###... .? wikinights talk 22:54, 15 September 2021 (UTC)
When the blocking admin has no idea what they are blocking in the first place, they may block something very common this happens now on almost every user block. If the "Autoblock any IP addresses used" option is selected (which it is by default), you block IP addresses without even knowing what they are. -- RoySmith (talk) 23:03, 15 September 2021 (UTC)

Ability to mark notifications from other wikis as read

Latest comment: 3 years ago16 comments8 people in discussion

Hello! So I'm not sure if this is at all possible but when I go to another Wiki I haven't been on before, I always get a notification when I come back to English Wikipedia saying I have notifications from other wikis, while being forced to go to that wiki (or at least click on the notification which takes me to the other Wiki) in order to mark the notification as read. I propose that we give users the ability to mark notifications from other Wikis as read from English Wikipedia (or whatever Wikipedia they mainly use) just like notifications from the Wiki they are currently on. Blaze The Wolf | Proud Furry and Wikipedia Editor (talk) (Stupidity by me) 20:15, 7 September 2021 (UTC)

  • Support, it is so annoying when that happens. Sometimes I get notices from Wikis I have never edited because a change I made like a file rename in Commons was ported there. BD2412 T 20:28, 7 September 2021 (UTC)
It took me awhile to figure out, but there is a way to mark notifications from other wikis as read without going there. In the notification dropdown, there's a blue dot to the right of the notification. Click it to clear it and that will do it. Schazjmd (talk) 20:29, 7 September 2021 (UTC)
I kinda wish it were a bit more obvious than that. Also @BD2412: you're not supposed to vote here. This is just for formulating ideas before you vote on them. Blaze The Wolf | Proud Furry and Wikipedia Editor (talk) (Stupidity by me) 18:54, 8 September 2021 (UTC)
You can also do this at Special:Notifications, which is easily reached by choosing "All notifications" at the bottom of the dropdown menu. Whatamidoing (WMF) (talk) 16:35, 9 September 2021 (UTC)
I mean, that's functionally as awkward as having to go to that project to resolve it, but I was not aware of that blue dot method noted above, so will try that out next time. And I've just tested with 10 editors, and only a few knew about that working. Nosebagbear (talk) 15:41, 11 September 2021 (UTC)
Can confirm blue dot method works (though it looks like it wipes the notification rather than marking it was read) Nosebagbear (talk) 21:40, 13 September 2021 (UTC)
Hitting the blue dot does not wipe the notification on my Chromebook using MonoBook. - Donald Albury 23:00, 13 September 2021 (UTC)
Clicking the blue dot moves the notification between "Read" and "Unread". If you have a lot of notifications (I have 62 waiting for me this morning), then that will move it out of the visible list. Whatamidoing (WMF) (talk) 16:15, 14 September 2021 (UTC)
It removes the notification only while you are browsing a wiki other than the one where it originated. If you go to the originating wiki, you will see the notification of interest. IznoPublic (talk) 16:19, 22 September 2021 (UTC)
I'd like the ability to figure out what other wiki a notification is from when I am on my phone. In the responsive monobook skin, crosswiki notifications show the red/blue numbers, but the actual text notifications are hidden, and there is no obvious way to find out they even exist. I've previously used
.mw-echo-ui-notificationsInboxWidget-sidebar {display:block;}
in my monobook.css to turn the wiki selector on, but that messes up the formatting. Currently I'm just hoping I don't get crosswiki pings while on my phone. Any ideas? @Whatamidoing (WMF)? —Kusma (talk) 20:10, 14 September 2021 (UTC)
@Kusma, my advice is that you post that question at Wikipedia:Village pump (technical). Whatamidoing (WMF) (talk) 18:46, 15 September 2021 (UTC)
Been there, done that: Wikipedia:Village_pump_(technical)/Archive_190#Crosswiki_notifications_and_the_responsive_monobook_skin. —Kusma (talk) 21:23, 15 September 2021 (UTC)

Why do we customize appearance of stub tags by topic?

Latest comment: 3 years ago22 comments12 people in discussion

I was recently questioning the utility for readers of having stubs display their category. For instance, at Lukas Lämmel (to choose the first Special:Random hit), why does it help readers to say This biographical article related to association football in Germany, about a midfielder born in the 1990s, is a stub. rather than just the standard This article is a stub.? Lämmel's page already establishes the basic information about him, so it doesn't help to repeat it at the bottom. It'd be better to be concise (or, if we're allowing ourselves some wordiness, to use it to provide better instruction on how to de-stubify an article). The icon is purely decorative. For editors, the stub category (Category:German football midfielder, 1990s birth stubs) already appears in the visible category list, and most stub sorting happens via sorters clearing out the maintenance category rather than stumbling on an unsorted stub anyways.

Given all this, I'm inclined to suggest (in a more formal proposal in a highly visible setting) that we stop using custom displays for stub tags and have them all adopt the standard {{Stub}} appearance. To be clear, I'm not considering proposing that we stop using sorted stub tags, which would be very different. Are there considerations I should have in mind for making such a proposal?

Note: I'm posting here rather than WT:WikiProject Stub sorting since I'm interested in feeling out what the likely response will be among a broad group of editors, not stub specialists. I'm putting an invite there, though, as I do want to hear from those more heavily involved with stubs. I'd appreciate if those coming here from that invite could note so in their comments. {{u|Sdkb}} talk 00:16, 21 September 2021 (UTC)

I don't claim to understand all of this metadata stuff that gets incorporated into WP, but it seems to me that having these somewhat vague characteristics be called out in a specific place (i.e. at the bottom of the page) serves multiple purposes:
1. This is content that should be populated at the initiation of the article.
2. This should avoid random editing later on..
3. It saves us from having to dig this out from the article as it develops over time.
Maybe I'm missing something, but it seems like this may be quite useful. Fabrickator (talk) 07:13, 21 September 2021 (UTC)
The text "related to association football in Germany, about a midfielder born in the 1990s," explains how the article gets into Category:German football midfielder, 1990s birth stubs. The rest of the text is boilerplate, it is generated by {{asbox}}. --Redrose64 🌹 (talk) 08:59, 21 September 2021 (UTC)
I have never been convinced by the theoretical basis for stub sorting, but I am happy it exists in practice. Let's talk about the history here: stub tags and stub sorting are old and predate both talk page assessment tags and the category namespace's transformation from a chaotic mess of tags into something resembling a system. Stub tags were always centrally controlled and provided a parallel and working system both for basic assessment and for categorisation. Sometimes this results in oddly fine categories like the one you mention above, a bit different from those used a long time ago on Ambrosius Stub, the best stub we've ever had. While we might not strictly still need this (if we assume that talk page assessments work perfectly, which isn't true either), it isn't terrible to have a redundant system in place. However, the really good thing about stub sorting in my view is not that it is all that useful by itself, but that most stub sorters perform a lot of cleanup tagging, page triage and categorisation while stub sorting. I'd be sad to lose that.
As for having different stub tags display differently: I kind of agree that it is more important that the article is a stub and that it should be expanded than what type of stub it is. For better visuals, all stubs should have a "stub" icon, not a distracting German football for the football related ones. (Similarly, Portals should use a "Portal" icon, not a decorative picture related to the portal topic). —Kusma (talk) 09:21, 21 September 2021 (UTC)
@Kusma: Thanks for that history! The broader thought about stub sorting being redundant to talk page banners and categorization did occur to me. It's hard to know whether getting rid of it would push stub sorters to add talk page banners instead or just make them give up. That would be an even huger change than what I'm considering here, though, and Wikipedians aren't exactly known for embracing bold changes to the way we operate, so I doubt it would pass. {{u|Sdkb}} talk 13:14, 21 September 2021 (UTC)
I like the idea, although Redrose does make a good point so maybe instead it could include what the subject is related to as part of the stub template since some stubs are literally 1 sentence, not really establishing what they are known for. ― Blaze The WolfTalkBlaze Wolf#0001 15:07, 21 September 2021 (UTC)
I'm sure that somewhere there's an article that has a stub template that includes information that the article itself does not, but my sense is that it's very rare. If an article is so bad it doesn't establish the basic thing it's about, that's a problem beyond anything a stub tag can fix. {{u|Sdkb}} talk 15:16, 21 September 2021 (UTC)
Stub sorting and WikiProject banners serve separate purposes and are not interchangeable. Stub sorting is an article categorization task. The meaning is "This is a short article about Subject _____." WikiProject banners are associating the article with a semi-formal group of editors. It happens that most (but not all!) WikiProjects care about articles mostly (but not entirely!) within a given subject area, but others don't follow subject areas at all, and many articles are interesting to a wide variety of WikiProjects. Talk:Leonardo da Vinci includes 17 WikiProjects. WhatamIdoing (talk) 16:40, 21 September 2021 (UTC)
They're definitely not interchangeable, but if I were constructing Wikipedia's systems from scratch, I would make one system for categorizing things, not multiple partially redundant ones (categories, talk page banners, structured data at Wikidata, stub tags, even lists and navboxes). Anyways, this is all a tangent; if editors want to consider changing stub categorization more fundamentally, we should open a separate thread for that. {{u|Sdkb}} talk 17:22, 21 September 2021 (UTC)
If I were constructing Wikipedia's systems from scratch, I wouldn't put metadata in a free-form text file. WhatamIdoing (talk) 02:14, 22 September 2021 (UTC)
The images attached to stub templates draw attention to the stub tag; I hope that doing so might suggest an editor/reader edit the article, and images are more compelling than text. Also, I'm not fussy about what the text of the stub tag says, as long as it deposits the article in an appropriate stub category, for the use of editors who browse the categories rather than noticing the individual tag. (Also also, WhatamIdoing's point is spot on and not germane to this discussion, though I understand why folks think "Stub-Class article" and "stub" are related.) Her Pegship (?) 16:50, 21 September 2021 (UTC)
  • One reason for thematic stub tags is that a stub article, by its nature, is incomplete and so lacks information. The thematic stub tags therefore help both readers and editors understand the topic and take it forward. The graphical icon is also useful in drawing the reader's attention and encouraging them to develop the article. They are also reasonably attractive and inoffensive. They thus compare very favourably with the obnoxious banner tags at the head of articles which are far more unpleasant and unhelpful. It is those which should be done away with. Andrew🐉(talk) 18:48, 21 September 2021 (UTC)
    Per my reply to Blaze the Wolf, I don't think stub tags actually tend to bolster understanding of a topic in the vast majority of cases. But even for the cases where we do, a stub tag isn't where we want to be doing it for a multitude of reasons: it doesn't fit with their essential message (designating an article as a stub), they're at the bottom of a page (whereas we want essential info at the top), and they're going to be removed once the article is improved. {{u|Sdkb}} talk 19:00, 21 September 2021 (UTC)
    they're going to be removed once the article is improved - that's kinda the point, we want people to expand the article and when they do so, that will justify the removal of the stub tag. --Redrose64 🌹 (talk) 23:40, 21 September 2021 (UTC)
I'm sure this sounds/is stupid, but I find that the stub tag categorization line encourages improvement of the article because, by indicating in the voice of the tag itself that the tag knows what the article is about, it makes it feel like someone has thought about how this article fits into the broader encyclopedia. If I read "This food-related article is a stub" I feel that Wikipedia's coverage of food in general is lacking because of this article's stubbiness, not just that this particular niche article is too short. This increases the urgency in a way that I find maybe helpful or at least charming. CapitalSasha ~ talk 19:40, 21 September 2021 (UTC)
I agree that the icons should be removed. They serve at best a decorative purpose. Some people here are arguing they should be kept because they "draw attention to the stub tag", but I think this is precisely the reason they should be removed. If drawing the reader's attention away from the content of the article and toward the invitation to improve it is a valid goal, then why not make them flashing animated gifs to achieve that goal even more effectively? Colin M (talk) 23:46, 21 September 2021 (UTC)
As the stub tag and its image are located at the bottom of the page, I don't see the (very small) icons as drawing attention away from the article itself; they're discreet enough to catch the eye but not so intrusive as to demand the reader's attention. In a related aspect of the appearance of tags, if the icon is a problem I would at least propose that a generic stub icon such as   be applied to all stub tags (though it would be too bad to waste the effort we've put into creating appropriate icons!). Her Pegship (?) 00:09, 22 September 2021 (UTC)
I have a pretty significant case of Banner blindness where stub tags (and much of the English Wikipedia's other infrastructure) is concerned. Could any of the editors here comment on whether they personally have expanded an article because the image in the stub tag caught their attention? WhatamIdoing (talk) 02:18, 22 September 2021 (UTC)
I chronically forget to remove the stub tags AFTER I'm done improving the articles. It's a curse. I've probably annoyed other editors over it. I've never paid it much mind otherwise, as a reader or editor. Estheim (talk) 06:37, 23 September 2021 (UTC)
I doubt that anyone is annoyed by that. They're probably just grateful that you expanded the article. WhatamIdoing (talk) 18:27, 23 September 2021 (UTC)
Lol, hope so! Trying to psychoanalyze how I feel about decorated vs non-decorated tags, the ones that are decorated make me think the article is a part of a highly active and enthusiastic Wikiproject. Like, I wouldn't be surprised if Hurricanes and Military articles had more decorative stub tags, but it can create that impression even if the actual Project is actually moribund. This is speaking as an editor, not as a reader. Estheim (talk) 19:45, 23 September 2021 (UTC)
@WhatamIdoing: I think the Wikiproject assessment is more likely to lead to improvements. At least in the Wikiprojects to which I belong, the tables of importance by quality are used to try to ensure that if possible Top or High importance articles aren't stubs. I can't recall having responded to a stub template or the categories created by stub templates. Peter coxhead (talk) 08:02, 23 September 2021 (UTC)

What to do about infoboxes for soundtracks in film articles?

Latest comment: 3 years ago2 comments2 people in discussion

Wikipedia:WikiProject Albums/Backlog elimination drive: Album covers is an effort to reduce the Category:Album infoboxes lacking a cover backlog, which has approximately 24,000 entries. Over at WikiProject Film, editors are discussing how there are many film articles with infoboxes for soundtracks lacking cover art. The lack of images in these infoboxes is a major source of the backlog, but we're not sure how this can be resolved. Sometimes, soundtracks have unique covers, other times they are similar to film posters (fair use images).

If you have ideas, please contribute to the discussion at WikiProject Film. And, of course, editors are invited to join the campaign to reduce the missing album covers backlog. Thanks and happy editing! ---Another Believer (Talk) 16:00, 23 September 2021 (UTC)

My only solution to this would be to add a cover (if available).--Filmomusico (talk) 20:15, 23 September 2021 (UTC)

Undo Editor update

Latest comment: 3 years ago8 comments4 people in discussion

So whenever I undo an edit and add something to the edit I undid, I'm forced to use what I'm going to call the undo editor. It appears to be a version of the source editor, however I find it a bit hard to use, mainly when adding a reference or adding more than a few things, as there are some tools in the top bar of the source editor that I like to use when normally using the source editor that either appear to be missing from the undo editor or aren't as good in the undo editor. For example, on the page for Sonic Colors, I undid an edit and added a reference in that same edit, however the ref tool in the undo editor simply just adds <ref> </ref> instead of adding {{Citeweb}} as well as ref tags. So I have to publish the editor and remove the reference and then click the reference tool in the top toolbar of the source editor which allows me to simply put in the link of the reference and it will add the correct information (Such as the Citeweb template and ref tags) for me. I propose that we update the undo editor to be on par with the current source editor (maybe something similar to the reply tool that's being added). Blaze The Wolf | Proud Furry | Discord: Blaze Wolf#0001 (talk) 14:49, 16 September 2021 (UTC)

  Works for me @Blaze The Wolf: are you using mobile or the visual editor? Can you tell which editor you are using from this list: mw:Editor? When I'm on the undo screen, I get the same tools as if I'm in the normal source editor. Is perhaps your citation tool bar just collapsed? — xaosflux Talk 13:07, 17 September 2021 (UTC)
@Xaosflux: It appears it's because I"m using WikiEd which I didn't realize did that until just now. ― Blaze The WolfTalkBlaze Wolf#0001 13:14, 17 September 2021 (UTC)
@Blaze The Wolf: thanks for the update, for bug reports on that personal user script, please follow up at: User_talk:Cacycle/wikEd. — xaosflux Talk 13:21, 17 September 2021 (UTC)
@Xaosflux: Nah I don't really think it's a bug. It's just a bit to complex for me to understand. ― Blaze The WolfTalkBlaze Wolf#0001 13:23, 17 September 2021 (UTC)
mw:Editor has screenshots of all the editing environments I'm aware of. The "Undo" button always uses your default editor, which is always an old wikitext editor (either 2010 or 2003 versions). Whatamidoing (WMF) (talk) 19:17, 17 September 2021 (UTC)
@Whatamidoing (WMF): Why using an old version? Isn't there a new one? The updates should come out every week, if I am not mistaken.--MollyPollyRolly (talk) 02:59, 23 September 2021 (UTC)
If you haven't change your prefs, then you are the 2010 wikitext editor. It is rarely updated, because there usually isn't any need to change it. The date is the year that it was widely released. Whatamidoing (WMF) (talk) 16:46, 24 September 2021 (UTC)

Real-time reporting of election results

Latest comment: 3 years ago12 comments12 people in discussion
  • Should live election results be reported on Wikipedia articles?

Live election results may contradict one another. The references to support the results soon become unverifiable because updated results erase any prior results. There is no protocol for determining which how often the live results should be updated, or if the reference needs to be static (like a webpage archived with the Wayback Machine).

See 2020 United States presidential election on November 5, 2020, for example. The references for the election results are live election results from ABC News and The New York Times, whose previous versions have been lost.

I have no objections to declaring winners based on election calls of reputable media organizations, or the reporting of final but unofficial results provided that our sources concur. wikinights talk 20:07, 14 September 2021 (UTC)

  • Yes, as long as it's made clear what the sources are and what the reporting figure is (e.g. as used in this infobox). This is pretty standard practice and is usually done quite reasonably. Number 57 20:17, 14 September 2021 (UTC)
  • This is the idea lab, so what is your idea for dealing with this problem? Yes, on election nights in Western Anglophone countries we get a lot of such edits, but they seem to be fixed quickly enough for nobody who realises that this is an encyclopedia, not a breaking news service, to be inconvenienced. Phil Bridger (talk) 20:32, 14 September 2021 (UTC)
  • Experience says it's basically impossible to stop people from adding such information in near real time. I don't think any "protocol" or special rules are likely to work. What would you do if people update "too quickly"? Fortunately counts usually finish at some point, and then we can use the final results and find stable references for those. Hyperlink references on old revisions are very often broken. That's just a fact of life. As long as current versions are working, I'm not bothered. —Kusma (talk) 21:11, 14 September 2021 (UTC)
  • On election day & for a month after ward, an article should be semi-protected, due to oncoming mostly well-meaning but scarcely informed editing. GoodDay (talk) 23:50, 14 September 2021 (UTC)
  • We basically already report election results in near-real-time. Overly excited editors tend to forget to add/update the refs, but that's why we have {{Current election}} enabled on election pages. I would be in favor of discouraging such reporting altogether (in the spirit of WP:RSBREAKING) but that's probably something that won't happen anytime soon. Dr. Swag Lord (talk) 06:56, 15 September 2021 (UTC)
  • Yes. 🐔 Chicdat  Bawk to me! 10:25, 15 September 2021 (UTC)
  • This is an encyclopedia, not a breaking news service. No. SQLQuery Me! 10:55, 15 September 2021 (UTC)
    • We update the stats for the players, are we not? Those are live. Elections should be treated the same. My only worry is that it might generate edit warring like crazy.--MollyPollyRolly (talk) 03:02, 23 September 2021 (UTC)
      • @MollyPollyRolly: "We" don't. A certain cadre of editors do — to the overall encyclopedia's detriment, IMHO. Enough of their frequent-flyer articles have ended up under Pending Changes protection that I'd love to ban the lot of them. WP:NOTSTATSBOOK anyway, but not one of their stats edits ever includes a single citation. How is any of that even supposed to be reviewed? (It doesn't help that the side-by-side diff view removes enough context that edits to table content are rendered near-indecipherable most of the time, and the visual diff more likely than not craps out because of the article length / coding complexity.) Thank you for the opportunity to rant about one of my pet peeves! 😁 -- FeRDNYC (talk) 15:55, 27 September 2021 (UTC)
  • I see no issue with the status quo I see with most ongoing elections. Broad stroke reporting (number of seats, which may be subject to change but will largely remain static) should be added, but not full reports such as developing vote totals. JackWilfred (talk) 13:02, 15 September 2021 (UTC)
  • This came up at WT:CANADA just a few days ago, Mathew5000 observed that while editors had rushed to update preliminary results in the template series for the 2015 and 2019 Canadian federal elections, the vast majority of those templates were never subsequently updated with official results nor verified, and have been hosting incorrect data for several years now. Wikipedia shouldn't do anything in real time, but if we're not going to actively prevent this behaviour then we need a concerted effort to go around and clean it up once official results are available. Some editors have also suggested adding a disclaimer to results templates indicating that results are preliminary, and maybe that banner could populate a maintenance category? Category:2021 Canadian federal election results by riding with unofficial results, as a subcat of Category:2021 Canadian federal election results by riding? That would be a big help. Ivanvector's squirrel (trees/nuts) 15:54, 15 September 2021 (UTC)

Using TV/radio call letters/signs instead of station branding for News articles citations (US and Canada)

Latest comment: 3 years ago12 comments6 people in discussion

I am aware that any station in the US and Canada would use a generic brand of a newscast with the name of the network and it can happen to most stations. Others use different names. Here's an example of what I mean:

  • If you refer to ABC 7 (Or in other cases, ABC 7 [Eyewitness/Action] News) for source, it's either KGO-TV, KABC-TV, WLS-TV, WABC-TV, or any other TV station that is in that channel affiliated to the network.
  • If you refer to Fox 5 (or Fox 5 News) for a source of the article, you refer to KTTV, WTTG, WNYW, or other stations with the name Fox [Channel number] News.

Replacing the station's name for their newscasts and using just the station's call letters (for an example: ABC 7 in New York as WABC-TV]]) is in my view the best solution so it can not only become clarified, but it makes it easier for people to know which station it is directly coming from. I must mention, this should apply to local newscasts in the US and Canada. I really feel that its much better this way so people don't have to figure out which station this source it goes to and eases up the need to search which source it is coming from. 20chances (talk) 00:33, 21 September 2021 (UTC)

Why does it matter which station it's coming from, if they're all showing the same newscast? WhatamIdoing (talk) 16:42, 21 September 2021 (UTC)
The proposal is for local newscasts, which rarely get picked up by the national networks. - Donald Albury 18:14, 21 September 2021 (UTC)
Are the USA and Canada the only ones where two different stations far enough to each have the same place in the over the air spectrum that would be designated the same way? Could this also apply to the different broadcasters that are part of ABC (Australia)?Naraht (talk) 18:45, 21 September 2021 (UTC)
All TV stations in the US and Canada broadcast regionally. However, they're affiliated to the network that they broadcast. For an example. WABC-TV only broadcasts in the NYC Area and airs ABC Programming. CBLT-DT in Toronto only airs in the Greater Toronto Area, and is part of the CBC Network. Australia has regional stations just like in the U.S. but it is different. 20chances (talk) 23:47, 21 September 2021 (UTC)
We normally refer to works by their titles, in this case that is part of the title of the source - the government license number could be useful, but in general is less informative. — xaosflux Talk 18:59, 21 September 2021 (UTC)
I will agree that using the station call letters (Like using KABC-TV (which uses abc7.com) for the use of any articles for its newscasts if using the article from the station.) My problem is that not mentioning the call letters and just using the name of the website from the station (ex: abc7.com for KABC-TV) or using ABC 10 to refer to a station in Sacramento or San Diego in California or other similar ones can not only be vague, but also confusing if not directed to the right source. 20chances (talk) 23:47, 21 September 2021 (UTC)
You certainly can do both. Here is an example citation:
{{Cite episode
|series=NBC 6 South Florida News at 12pm
|author=NBC 6 South Florida
|network=NBC
|station=WTVJ
|minutes=14|quote=This experiment concludes that water is wet
|date=2021-09-22}}
Which produces:NBC 6 South Florida (2021-09-22). NBC 6 South Florida News at 12pm. 14 minutes in. NBC. WTVJ. This experiment concludes that water is wet{{cite episode}}: CS1 maint: numeric names: authors list (link)
— xaosflux Talk 13:53, 23 September 2021 (UTC)
My only if is what if there's a link to that segment that is posted online? 20chances (talk) 16:54, 23 September 2021 (UTC)
@20chances: we have lots of citation templates, that one is in Template:cite episode. — xaosflux Talk 16:57, 23 September 2021 (UTC)
@Xaosflux:I agree on the use of citations, but the problem is that some stations don't mention where the article and/or the news segment is uploaded. Sometimes, many articles do link a segment from a newscast (some don't mention the times on which it was actually aired) 20chances (talk) 01:39, 24 September 2021 (UTC)
@20chances: If you're citing a web upload of a video, probably best to use {{Cite web}} even if the video was aired on TV at some point. If you're looking to add a link to an existing {{Cite episode}} citation, it does accept the standard |url= parameter, though interestingly that parameter is documented as (emphasis mine) URL of an online location where the text of the publication can be found. (But then there's also a separate |transcript-url=, which makes me think |url= doesn't have to link exclusively to text.) -- FeRDNYC (talk) 18:00, 29 September 2021 (UTC)
{{Re|FeRDNYC]] Right. The only problem is that people will use the name of the website instead of the station's call letters as the source for the website parameter like the examples I mentioned above. So instead of using the URL abc7ny.com for the website parameter for the ABC station in New York, since there's 2 TV Stations on channel 7 that are affiliated to the ABC Network, it would be WABC-TV instead. Hopefully I'm trying to get it right.

Mnemonic for evaulating potential vandalism

Latest comment: 3 years ago6 comments4 people in discussion

Last night, I thought of a mnemonic for evaluating potential vandalism, and I wrote it on a user subpage (User:Plutonical/MOUSE). I'm posting it here to see what you guys think.

M - Maliciousness – Is the edit seemingly malicious?

O – Overtness – Is the edit openly and blatantly disruptive?

U – User – Does the responsible user have a history of vandalizing Wikipedia?

S – Source – Is the edit based on a reliable source?

E – Experience – Is the responsible user new?

Is this in line with current wikipedia policies in your opinion? Plutonical (talk) 12:08, 30 September 2021 (UTC)

This is a good idea for a mnemonic, but there is a change that I think can improve it. The experience of the user does not greatly influence if the user is prone to vandalising, for example: A user that has been on Wikipedia for 3 months can still vandalise, regardless of the time she/he has been on the site. Perhaps change the E to something more constitutional? I don't know, but I think this can be a potential improvement, regardless it is a good, nice, and rememberable mnemonic that can be extremely useful. --Pink Saffron (talk) 14:33, 1 October 2021 (UTC)
Point E being true does not mean the edit is more likely to be vandalism. It's meant to help check if it's a new user who really doesn't know much about the site and is using an article as a sandbox or damaging them accidentally. That way we avoid biting as per Wikipedia:DONTBITE Plutonical (talk) 14:26, 2 October 2021 (UTC)
  • Points 3 and 5 seems slightly redundant to me, they both seem to be variants on "does the user have any productive contributions". It's also not the case that a user with experience is immune from vandalising, there's been quite a few cases of experienced editors making sock puppets to vandalise. I also think the "source" point misses the mark - if a user adding sourced content then it's probably more a case of WP:NOCLUE than vandalism - they're probably trying to improve the encyclopaedia, they just don't know the details of WP:RS. It wouldn't be obvious to a lot of newcomers that the daily mail of facebook are not suitable for adding content to articles for example, that doesn't make their edits vandalism. 192.76.8.74 (talk) 05:50, 2 October 2021 (UTC)
point 5 (E) is there to check if the user might be using random articles as a sandbox or damaging them for other reasons.. It's a measure against putting harsh punishments on newcomers. Plutonical (talk) 14:24, 2 October 2021 (UTC)
Really not sure you need an acronym to evaluate anything. 99%+ of vandalism is obvious to everyone, with the other 1% obvious to everyone who's familiar with the subject. Headbomb {t · c · p · b} 13:31, 2 October 2021 (UTC)

Notified of Manual Reverts

Latest comment: 3 years ago15 comments7 people in discussion

Hello! So I discovered that you get a notification when someone reverts your edit in any way BESIDES a manual revert which I find rather interesting. So I propose that people are also notified when their edit is reverted manually. ― Blaze The WolfTalkBlaze Wolf#0001 19:41, 22 September 2021 (UTC)

Just add the page to your watch list… then you can track all edits not just reverts. Blueboar (talk) 19:50, 22 September 2021 (UTC)
Won't this just create talkpage bombardment?--MollyPollyRolly (talk) 22:05, 22 September 2021 (UTC)
@MollyPollyRolly: The notifications never go to your talkpage though. ― Blaze The WolfTalkBlaze Wolf#0001 22:21, 22 September 2021 (UTC)
@Blaze The Wolf: Where does it go then? I thought that notifications are linked to talkpages, like we see with ClueBot.--MollyPollyRolly (talk) 01:20, 23 September 2021 (UTC)
@MollyPollyRolly: ClueBot uses warnings which go to talk pages. Notifications go to the bell icon. ― Blaze The WolfTalkBlaze Wolf#0001 01:21, 23 September 2021 (UTC)
@Blaze The Wolf: Still, even it does go to a bell icon, it will still be a bombardment of some kind. For example, a new editor edits an article which you revert by using manual revert. First, majority of new editors don't even pay attention to what is on top. Second, if the editor edits multiple articles at the same time, it might be considered as notification spamming.--MollyPollyRolly (talk) 02:31, 23 September 2021 (UTC)
@MollyPollyRolly: That is true. And the reason ClueBot's warnings go to the bell icon is because you are automatically notified about things on your talk page. ― Blaze The WolfTalkBlaze Wolf#0001 12:16, 23 September 2021 (UTC)
They still require attention. I think it's a bad idea. Doug Weller talk 15:42, 23 September 2021 (UTC)
@Doug Weller: The idea itself is not bad, the outcome of it might spill a disaster to an already fragile project. :(--MollyPollyRolly (talk) 20:12, 23 September 2021 (UTC)
Ya, I realized that if someone makes an edit that is a manual revert of an older edit, if you got notified about manual reverts then it could spam multiple people's notifs. ― Blaze The WolfTalkBlaze Wolf#6545 16:41, 24 September 2021 (UTC)
If memory serves, brand-new accounts aren't notified about being reverted. Whatamidoing (WMF) (talk) 16:59, 24 September 2021 (UTC)
That seems rather interesting. It can technically do both harm and good, depending on what the person behind the account is wanting to do. ― Blaze The WolfTalkBlaze Wolf#6545 18:32, 24 September 2021 (UTC)

@Blaze The Wolf: I suspect the thinking there is that new users being reverted would be helped more by a talk page message (even if it comes in the form of a warning) giving some guidance about why they were reverted, vs. just a notification with no explanation behind it. And we are all encouraged to template the n00bs when we revert them, so they know what they did wrong.

Regarding the idea in general, I feel like it would have to be opt-in, if it were implemented. But would that be an all-or-nothing, sitewide opt-in, so you get notified every time there's a revert of some edit you made months and months ago and have already forgotten about? Or would it be on a per-page basis, in which case... yeah that really just sounds like the watchlist, huh? -- FeRDNYC (talk) 16:06, 27 September 2021 (UTC)

@Blaze The Wolf: The removal of request templates after fulfilling the request (like a file move or non-free reduce) is also a manual revert. Archiving of discussions can also result in manual reverts. — Alexis Jazz (talk or ping me) 21:12, 3 October 2021 (UTC)

Default Protection of Closed RFAs

Latest comment: 3 years ago6 comments4 people in discussion

I was thinking and wondering, given how some RFAs experience vandalism, and it's very unlikely they'll be edited after closure, why RFAs aren't automatically fully protected by the closer as a standard practice? Could this be a viable practice? Would it make sense? ~Gwennie🐈｟💬 📋｠ 21:09, 3 October 2021 (UTC)

Full protection is a bit much as that would impede template maintenance, fixing lint errors and other such legitimate edits. But extended-confirmed protection would probably be a good idea. – SD0001 (talk) 08:50, 4 October 2021 (UTC)
Could you show me some statistics on how much of a problem this is first? — xaosflux Talk 10:27, 4 October 2021 (UTC)
I wish I could come up with some, however that feels like OR. ;) (How would I gather the requisite data?) ~Gwennie🐈｟💬 📋｠ 01:06, 5 October 2021 (UTC)
@Gwennie-nyan: in general, we only protect things when necessary to prevent disruption to the project. Over time we have had to extend certain preemptive protections (such as to templates that are widely used) because as a class they have been disruptively edited previously. We generally don't see a lot of disruption at closed discussions such as RfA (or the immensely larger number of AFD pages) - so to consider preemptive protection on them we should have a showing of a pattern of disruption first. I agree it seems reasonable that those pages don't have a need to be edited - and from a "content" perspective - they shouldn't be. From a technical perspective, sometimes they need to be - and currently can be by anyone doing such technical updates. — xaosflux Talk 01:16, 5 October 2021 (UTC)
My impression is that this issue isn't serious enough to warrant preemptive protection. If a particular RfA page is being persistently targeted for vandalism or harassment, then we could protect them individually, but we shouldn't protect all RfA pages preemptively, especially if, as SD0001 mentions, there are legitimate reasons for editing them after closure. See also WP:PREEMPTIVE. Mz7 (talk) 06:18, 5 October 2021 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(idea_lab)/Archive_37&oldid=1114549891"