Thanks Tim and Lucas. This is working as intended if the page accesses data from Wikidata like in this case.

Perfect! \o/ Thank you.

This seems to have solved it in my testing on beta \o/
Just one small issue: by default it seems to start with a collapsed termbox. I think if nothing has been set we should have it be uncollapsed like before.

In T245643#9537162, @Sarai-WMDE wrote:

4. For now, the decision has been to wait and track whether servers' performance is impacted by these upcoming changes to the QS UI, and add design mitigations in case overloads are detected (e.g. increase waiting times, add a Cancel confirmation dialog). Nevertheless, the WDQT team would like to know if there's anything that we can do from our side to prevent making this new Cancel functionality unavailable for bots: is this a strategy that sounds necessary to the Search Platform / Query Service Team? What can our team do to support that? Maybe @Lydia_Pintscher can help us validate/ clarify this? 🙏🏻

In T344984#9537517, @Michael wrote:

That is a valid point. I do not have enough insight to guess which editing patterns tend to trigger check-user requests, given that they might be different from your random vandalism. Not sure if there is already research on that, but I'm adding Wikidata data quality and trust as this relates to fighting (somewhat more) sophisticated abuse. Also, to me this now enters Product territory, and so @Lydia_Pintscher might have thoughts on the next steps.

Gotcha! Thanks.
Ok right now Special:Merge does the redirect edits and then shows you the following:

It looks like it to me.

Do I understand the options correctly?

Screenshot:

Ah doh! Ok that I can reproduce. Thanks!

I just checked and this is what I get on English Wikipedia:

I agree that we should have this.
In the meantime there is a script by @Nikki that you can add to your commons.js with this line:

importScript("User:Nikki/AnchorLinks.js")

\o/
Thank you. This is good enough for us.

In T329631#9505298, @noarave wrote:

• if the mismatch already exists in the DB in its exact form, for this uploader, it is ignored during upload
• the existing mismatch gets tagged as "reviewed" in the "review_status" column of the csv summary of the upload

In T245643#9495822, @Sarai-WMDE wrote:

2. Potential risks, concerns and improvements they would suggest in order to adjust the feature to their needs: When it comes to their concerns, there were some clear patterns. The most frequently mentioned issue was the risk of overloading the WQS server, due to the facilitation of running multiple heavy queries in parallel, accidental double clicks, and active vandalism (DDoS attacks). As potential solutions, users brought up strategies like avoiding making the "Stop query" functionality available for bots, or actually stopping the query on the server side (which I'm aware is not feasible). They also mentioned some redesign suggestions that we're integrating in the next iteration (whenever suitable), and made very interesting comments regarding the lack of visibility of the server's status (users don't get an estimation of the query execution time, nor know when it's struggling – I believe there's a very interesting improvement opportunity here).

In T356119#9496535, @Harej wrote:

@Lydia_Pintscher Are there better alternatives at this point?

Additional context: Relatively small number of people means right now no-one as the Bridge is effectively disabled anywhere but test systems until the new team gets going with it.

Thanks nikki! I was slightly confused what exactly we are talking about. And I now assume we are talking about the short messages that describe the text like "Wikidata User Interface" vs "Wikidata user interface". If that is correct that makes sense from my side.
@Manuel Any issue from your side?

From my side this is good.
@Mohammed_Sadat_WMDE What do you say?

I don't think we can invest the time right now to do the test dumps, so let's deploy it even if it can't be tested on Test Wikidata unfortunately.

Yeah I'd say this is an oversight and they should be considered stable.

In T354730#9449572, @ArthurTaylor wrote:

NewProperty fails with a clear permission error because the action is not enabled for anonymous users on beta. But that may not be the case for all installations - trying the same on a local development wiki creates the stack trace again.

We should also check if the same is the case for creating new Properties and Lexemes. I assume yes.

Can we clarify what is still missing? Is it only the creation of Lexemes? The dev team had asked for that to be held off a bit initially to take things a bit slowly when Lexemes were introduced. I think by now this is no longer an issue and shouldn't block anything.

Since the edit is made on Wikidata, that is what should be taken into account for deciding if IPs are going to be leaked.

Thank you :)

This is unfortunately not ok from Wikidata PM side. It was a mistake to do it this way on enwp and I really do not want this to spread further.

From the Wikidata PM side this unfortunately is still not ok to do.

In T243138#9415152, @Bean49 wrote:

Could someone with expertise state that understands the problem and indicate which workaround is less worse?

1. make 1800 API requests instead of 4
2. use a very low percentage (1-15%) of downloaded data, increasing network traffic with no use

We could easily resolve this with a new filter parameter.

Let's do it.

We currently don't have it high on our list unfortunately but we'd be happy to review patches if someone wants to submit one.

Info: We have T155109 for adding tag parameters to remaining api modules.

I have not seen anyone complain about this so far so the easiest thing for now is probably to adjust the documentation and be done with it until it becomes a thing.

This has actually been bugging me as well...
We need UX input on how to best go about this.

Thank you everyone! The gadget has been rendered inoperable on-wiki so I'm considering this done as well.
If anyone has an idea why this happened now I'd love to hear it. AFAIK the gadget hadn't been touched in ages so I'm wondering if something else changed that we should worry more about. But maybe not...

Slides for @Epidosis's talk during the Data Modelling Days: https://commons.wikimedia.org/wiki/File:DMD2023_-_A_better_way_to_enforce_a_data_model._Suggestions_to_improve_Autofix.pdf

I can confirm the issue in my work account but not in my personal account.

Thanks for narrowing it down, @PKM!

I tried this and I can't reproduce it. Can you please try if this happens for you in safemode as well? Just add the following to the Item URL: ?safemode=1

Anything major I forgot based on the investigation?

@Arian_Bozorg Can you help flesh this out please? Thanks!