Misplaced Pages

Revision as of 10:25, 15 September 2021

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

• WP:VPI
• WP:VPIL

• Discussions of technical issues belong at Village pump (technical).
• Discussions of policy belong at Village pump (policy).
• If you're ready to make a concrete proposal and determine whether it has consensus, go to the Village pump (proposals). Proposals worked out here can be brought there.

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 Misplaced Pages:Perennial proposals.

Discussions are automatically archived after remaining inactive for two weeks.

Village pumps

policy

tech

proposals

idea lab

WMF

misc

• Refining the administrator elections process
• Blocks for promotional activity outside of mainspace
• Voluntary RfAs after resignation
• Proposed rewrite of WP:BITE
• LLM/chatbot comments in discussions

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

Bold idea: the Generic Queue Toolkit

Misplaced Pages 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 Misplaced Pages: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 Misplaced Pages 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)

• We do have many many queues, for example: CAT:CSD, WP:AIV, User:AnomieBOT/EDITREQTable - but will they really benefit from all requiring the same formatting - I don't think so. Maybe some of these could get some help - but I don't really think forcing everything in to some JSON form is the best answer. — xaosflux 23:13, 31 August 2021 (UTC)

Indicator in watchlist of number of consecutive edits by same editor

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)

Create template/link for things that have Wikidata items, but not articles

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 Misplaced Pages 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, Misplaced Pages 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)

• To my knowledge, this can currently be done in at least two ways using existing templates: {{Interlanguage link}} and {{Wikidata entity link}}. Using your example album, the first results in Changer : Dear Eris , the second in Changer : Dear Eris (Q108291790). --Animalparty! (talk) 01:10, 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)

• Furthermore, Wikidata must not be linked to in the body of an article per Misplaced Pages talk:Manual of Style/Archive 204#New RFC on linking to Wikidata * Pppery * _{it has begun...}

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)

Browser-specific range blocks

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 Misplaced Pages 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 (/_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 Misplaced Pages, such as at Misplaced Pages:Village pump (miscellaneous)/Archive G#Wiki as an HTML editor and Misplaced Pages: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 Misplaced Pages 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 (/_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)

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)

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

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

Ability to mark notifications from other wikis as read

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 Misplaced Pages 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 Misplaced Pages (or whatever Misplaced Pages they mainly use) just like notifications from the Wiki they are currently on. Blaze The Wolf | Proud Furry and Misplaced Pages 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 Misplaced Pages Editor (talk) (Stupidity by me) 18:54, 8 September 2021 (UTC)

• I'm aware of that, but I did it anyway, per WP:IAR. BD2412 T 19:29, 8 September 2021 (UTC)

  Fair enough. Blaze The Wolf | Proud Furry and Misplaced Pages Editor (talk) (Stupidity by me) 19:10, 9 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)

Real-time reporting of election results

• Should live election results be reported on Misplaced Pages 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   10:25, 15 September 2021 (UTC)

• Misplaced Pages village pump
• Misplaced Pages proposals