Wikipedia:Village pump (idea lab)

 Policy Technical Proposals Idea lab WMF Miscellaneous 
The idea lab section of the village pump is a place where new ideas or suggestions on general Wikipedia issues can be incubated, for later submission for consensus discussion at Village pump (proposals). Try to be creative and positive when commenting on ideas.
Before creating a new section, please note:

Before commenting, note:

  • This page is not for consensus polling. Stalwart "Oppose" and "Support" comments generally have no place here. Instead, discuss ideas and suggest variations on them.
  • Wondering whether someone already had this idea? Search the archives below, and look through Wikipedia:Perennial proposals.

Discussions are automatically archived after remaining inactive for two weeks.

« Archives, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37

Indicator in watchlist of number of consecutive edits by same editorEdit

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 blocksEdit

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)
  • We (checkusers) have been asking the WMF for this for years. We've gotten things nobody asked for like the visual editor and IP masking instead. Especially with Chrome about to start masking and obfuscating useragents anyway, I wouldn't count on this ever happening. Ivanvector's squirrel (trees/nuts) 15:46, 13 September 2021 (UTC)
    This story just won't die. Maybe it just seems too plausible to not be fiction? But the fact is that creating a visual editor has been requested by volunteers since at least 2004. There were multiple discussions at the English Wikipedia, such as at Wikipedia:Village pump (miscellaneous)/Archive G#Wiki as an HTML editor and Wikipedia:Village pump (technical)/Archive M#Edit in place. Prioritizing its creation was a major outcome of the very first strategy: project. Ivan, I suppose that you don't remember the original strategy discussions, since they were already underway when you registered your main account in 2009, but editors here actually did ask for a visual editor, and whoever told you otherwise was mistaken.
    (Fun fact: The first known request to be able to disable any visual editor that might be created was posted here at the English Wikipedia about three years before the first line of code was ever written.) Whatamidoing (WMF) (talk) 19:33, 13 September 2021 (UTC)
    I am happy to know that I am mistaken, and the office does actually listen to user requests. So, Whatamidoing (WMF), when can we expect useragent-specific blocks to be implemented? Ivanvector's squirrel (trees/nuts) 14:42, 14 September 2021 (UTC)
    If VisualEditor is our timing model, then I'd have to predict a delay of about eight years between the first request and the project being ready for alpha testing. :-p
    @RoySmith, do you know if there's a task in phab: about this idea? Whatamidoing (WMF) (talk) 16:13, 14 September 2021 (UTC)
    I did not open one. I did a little phab searching right now and didn't find any, but my phab searching skills are rudimentary at best. -- RoySmith (talk) 16:50, 14 September 2021 (UTC)
    RoySmith, I filed one, and linked it here. Whatamidoing (WMF) (talk) 19:11, 15 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 readEdit

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 think that's a "problem solved", then. BD2412 T 20:34, 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)
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)

Real-time reporting of election resultsEdit

  • 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)
  • 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)

Undo Editor updateEdit

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)

replacement for Interlanguage link templateEdit

This is a proposal to deprecate {{interlanguage link}} and define a new type of disambiguation/redirect page that includes one or more links to the appropriate page on one or more other wikis.

The primary issue that I raise with the existing solution is that multiple articles may have links for the same article which exists on other wikis but not on enwiki. Whenever there is any change to the set of wikis that should be linked to (perhaps the article has become available in another language, or perhaps an English-language version has become available), then all the pages referencing that article need to be modified ... we even have a bot which automatically replaces the {{Ill}} with a direct link when an English-language version becomes available.

The proposed solution is a form of disambiguation or "manual redirect" page that has whatever name that would presumably be used on enwiki. The pre-existing discussion is at Template talk:Interlanguage link § Proposed alternative to Template:Ill. Fabrickator (talk) 18:47, 19 September 2021 (UTC)

Note that this can be used in a citation, a meaningful advantage over {{Ill}}. Fabrickator (talk) 19:13, 19 September 2021 (UTC)
I think you misunderstand how {{ill}} works when that red-linked article gets created here – no manual change is required, the red link will turn blue and interlanguage links should appear in the left side bar. A bot may come along and remove the template. As for citations: several components of a citation can already be linked via {{ill}}. Author links are of course possible in free-text citations, and can be hacked into citation templates as well. -- Michael Bednarek (talk) 02:49, 20 September 2021 (UTC)
Sorry, I "mis-spoke" about how the template handles the case when an enwiki version of the page becomes available.... as that's the single situation which is handled okay, more or less. Every other case is handled poorly, in that it's necessary to edit each page which references the affected article when there's any other change to availability of inter-language versions of the article. Fabrickator (talk) 06:44, 20 September 2021 (UTC)
I would be happy to see the templates and their redlinks being replaced with links to articles that provide at least a basic stub level of content, and with sufficient referencing to show the subject is notable. However, this proposal would see approximately 110,000 redlinks being replaced with links of a different color, and the creation of many new pages to which these recolored links would go. They would be each contain a list of external links to other wikis, but be lacking the level of content or citations required in standard articles. The idea that redlinks are ugly as they are highly visible and a clear indication of something being wrong (i.e. missing content) is not a major concern to me compared to the actual lack of content, something which I feel the proposal does not fix, but attempts to mask by using placeholder pages. There are numerous issues with the usage of this template, from inconsistency in the naming of the redlink to the order, number and selection of language links used with it. It may be possible to make adjustments to the template or create tools that can help to sort some of this, however, these issues are mainly the result of editing rather than the template itself. Changes to the documentation could help inform editors of some potential issues and how to avoid or work around them. EdwardUK (talk) 04:53, 20 September 2021 (UTC)
EdwardUK wrote:

I would be happy to see the templates and their redlinks being replaced with links to articles that provide at least a basic stub level of content, and with sufficient referencing to show the subject is notable

It seems like you are trying to apply some sort of technical rule that would have the effect of complicating or otherwise deterring the implementation of a presumably useful feature. I'm a little perplexed at this approach, given what seems to be a general consensus that these interwiki redlinks are expected to encourage the creation of new articles. Anyway, notability applies to articles, and I think we can distnguish between a redirect page and an article. Fabrickator (talk) 09:45, 20 September 2021 (UTC)
The technical rule is simply meeting the standard expectations of any standard article without which the article is liable to be deleted or draftified. Here it seems the intention is to circumvent these requirements by classing these as a different type of main space page for topics where there is another language version and I would be very surprised if these pages were not challenged either as a concept or on an individual level. I would expect the issue of notability to apply on the basis that wikipedia is not an indiscriminate collection of information, so inclusion here should not be based solely on the content existing on other wikis.
I understand these pages could be seen as starting points which could be expanded into full articles, but it is not clear at what point they would make the transition and the standard rules would apply. This would be a particular problem where content creeps in and it goes from "this article is not available" to "there is no article about topic X…" followed by a brief description for the benefit of the disambiguation and then to further details being added. With the redlinks there is a clear dividing line over there being an article or not, the proposed pages would make this line unclear. EdwardUK (talk) 16:40, 20 September 2021 (UTC)
I am not sure what the source is of your contention that these redirect pages could be expanded into full articles, but of course there's nothing preventing existing disambiguation pages from being expanded in this manner, and there are certainly some cases where a disambiguation page actually describes a term when there is no appropriate article to link to. Just take a look at the red herring disambiguation page. Fabrickator (talk) 18:43, 20 September 2021 (UTC)

Why do we customize appearance of stub tags by topic?Edit

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)

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

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)