In T297513#7564580, @MisterSynergy wrote:

Not sure whether this is a good idea. Access to deleted content is restricted to admins, but a tool would make a lot of it available to everyone. Does WMF allow this?

In T333477#8751473, @JJMC89 wrote:

In T333477#8751278, @Bovlb wrote:

Just a note that this major event could have been much better publicised. I wasted a significant amount of time yesterday trying to debug my tool to find out why it wasn't working properly, before finally stumbling across this planned outage. I saw no notice on affected projects. I found nothing searching the toolforge Wiki. I saw nothing in the MOTD.

You should subscribe to the cloud-announce mailing list, where it was announced.

Just a note that this major event could have been much better publicised. I wasted a significant amount of time yesterday trying to debug my tool to find out why it wasn't working properly, before finally stumbling across this planned outage. I saw no notice on affected projects. I found nothing searching the toolforge Wiki. I saw nothing in the MOTD.

@Ammarpad Hi! I was wondering if you planned to respond to my questions.

In T328689#8583064, @Daimona wrote:

This is working as intended, normal filters won't work on Flow pages. If you need that, you have to change the group of the filter to "flow"; there's a dropdown at the top of the editing form, after the filter name.

related to T297513

I have prototyped such a tool at https://wd-deleted.toolforge.org/

At Wikidata we often encounter IP users who repeatedly make the same mistakes, ignoring reversions and talk page messages, until we are reluctantly obliged to block them for "competence is required". The fact that IP users are not notified of reversions and mobile IP users are not notified of talk page messages may be a major contributor to this problem. Are (mobile) IP users even shown block messages?

I spent a fair bit of time trying to debug why I couldn't read deletedtext on PAWS before I came across this ticket.

Just an update to say this is still an issue for Wikidata administrators. We face a deluge of semi-notable additions and many long-time repeat spammers. It would be super-helpful if admins had a way to search for similar items that have been deleted in the past.

I agree that it's a problem that bots get notifications that are never checked, but I don't think the answer is to throw them away. Bot operators ought to be reviewing their notifications. If a bot is continually reverted, the operator should know about that as a matter of urgency. Editors rely on the fact that reverting another user's change will alert them to a problem, and bots should not be an exception to this.

In T224921#5382785, @Bawolff wrote:

There was basically one production error which arguably was intentional behaviour (albeit maybe a poor design choice not to suppress it)

Another case of this bug was reported today:

In T246814#6659177, @John_Cummings wrote:

Great, is there anywhere this info could be added for others doing a similar thing to you?

It's now much better than it was, but there still seems to be a problem, possibly related to my use of the "Use a compact language list, with languages relevant to you." option. When looking at deleted versions of https://www.wikidata.org/wiki/Q101239641 just now, I saw a table of three languages, showing no labels or descriptions, and with no option to see "All entered languages". In fact, the item had both label and description in French, but there was no way I could see this.

I see edits, and I was able to highlight them in recent changes by adding the following to my Common.css:

Thanks @matej_suchanek . That's certainly helpful, and maybe we can take it the rest of the way with some CSS, but I don't see any hits on that filter yet.

I wasted more of my time today following up on a "vandal" who turned out to be doing the WikiTour.

@Ammarpad Hi! I was wondering if you intended to clarify your earlier comments. Is this a bug in the code or a deliberate deviance from document behaviour?

Just to add another perspective on this issue, I have several times come close to blocking/warning a new user for vandalism before I realized they were taking a WikiTour. Having any sort of tag on the edit would be useful.

I don't see an option to exclude by tag

To clarify, it would be really helpful to know either:

• When we plan to fix this bug; or
• If we're not fixing it (soon), what the nature of the bug is, so that we can devise workarounds.

@Mrjohncummings asked me to share this comment I posted at Wikidata:

From the discussion so far, there seem to be two proposed solutions:

1. Add an edit filter that checks the item id against a hard-coded list and adds a tag. Any admin can do this, but we would need to (remember to) update the filter whenever we create new topics.
2. Change the WikiTours interface to add a tag. This would be the more elegant solution, but would require work from a WikiTours interface developer. I don't know who that is, and I don't know how to find out.

what tag would be needed to tell recent changes to ignore it?

Hi! The spam blacklist is an important tool for Wikidata and other projects. If there's a big hole in its functionality, we'd like to know more about the bug so we can work around it.

Before the edit, the official website was "https://chaturbate.com/" which is (as I understand it) correct. I expect that the spam blacklist would NOT prevent that from being added, and this appears to be behaving as expected.
After the edit there was a second value for official website "http://chaturbateme.com/" which is not correct and which I expected to be prevented by the spam blacklist entry:

\bchaturbateme\.com\b

Are you saying that there is there some (undocumented) similarity test that allows editors add the spam site notwithstanding the spam blacklist because the hostname is similar to the correct one?

@Ammarpad: Thanks for responding. If I understand what you're saying correctly, the version preceding the edit (HTML, JSON) contains a "similar link" to the one introduced in the offending edit. Does this mean a link that also matches the same blacklist pattern? Or is there some weaker similarity test in play here? Can you pinpoint the specific link that is considered to be similar?

For information: I have now disabled this edit filter in favour of a set of softblocks on certain /16 IP ranges.

Note that we currently use vis, not visjs-network.

A workaround could be to use a template like Template:Interwiki_Extra on ENWP. For example, on Draft:Principality of Pavia, we could add the line:

{{interwiki extra|qid=Q3921984}}

Enable the visual editor and the new wikitext mode in Structured Discussions

Is there any update on this? I've been trying out structured discussions on my talk page, but this lack of preview makes it very hard to use the tool effectively.

I have tried setting these two options, but it does not seem to change the behaviour.

As I said, I was wondering if this is related to https://www.wikidata.org/wiki/User:Bovlb/common.js .
It might not be related but it's broken in the line importScript( 'MediaWiki:Gadget-statementSort.js]' ); due to the ].

Which browser do you use?

In T54564#3957162, @Izno wrote:

Thought of a technical solution, might as well throw it out there:

1. Let's say we create a new magic word, something like __WIKIDATAREDIRECT__.
2. Place the magic word on a Bonnie redirect.
3. Wikidata treats that page like it's a normal page (with all the associated constraints and behavior), with one additional constraint: A WIKIDATAREDIRECT cannot be the only link on a data item.
   1. With associated tracking and such forth and suchwith.

https://www.wikidata.org/wiki/User_talk:Bovlb

Some more things I have established:

• I can see the toolbar when I log out and access Wikidata as an IP user. This suggests that it is not a site-wide problem for all users.
• When I log in in incognito mode, no toolbar is seen. This indicates that it is not caused by any browser extensions.
• When I disable all Wikidata gadgets except Structured Discussions, I see no toolbar. This suggests that it is not caused by other gadgets.
• Global JavaScript are empty. Clearing the local JavaScript does not cause the toolbar to appear.

We the stewards are just 34 people and it's not enough people to beat big wikis like enwiki to make it through. It's basically a popularity poll and behind-the-scene works don't have that much possibility of winning it as I see.

I am also seeing missing data today, including Wikidata. For example, https://tools.wmflabs.org/guc/?user=157.246.37.191 is empty, whereas https://www.wikidata.org/wiki/Special:Contributions/157.246.37.191 has entries from over an hour ago. This discrepancy is not accounted for by the replag report.

@Yurik asked:

I would like to solicit more community feedback on how useful this would be.

Here's another one:
https://meta.wikimedia.org/wiki/Special:CentralAuth/Kamapants

https://www.wikidata.org/w/index.php?title=Q128799&diff=182532048&oldid=172424125
Here is an alias change on 21 December 2014 that exhibits the problem.