In T328764#8688456, @Lucas_Werkmeister_WMDE wrote:

Should the current user interface language be part of the shareable link or not?

Relevant PRs:
Add language selector Icon to Wikit; https://github.com/wmde/wikit/pull/678

To make the LanguageSelector visible temporarily for development, the changes of this file can be re-added: https://gerrit.wikimedia.org/r/c/wikidata/query-builder/+/892394/3/src/components/QueryBuilder.vue

@Arian_Bozorg you can do the UX review here: https://892394--clicky-sparqly.netlify.app/

Has been solved as part of T329487 here: https://gerrit.wikimedia.org/r/c/wikidata/query-builder/+/889547/20/src/components/LanguageSelector.vue#50

@Arian_Borzog @karapayneWMDE Please check the visual implementation of the base elements of the component LanguageSelector. The component has been added to the screen for now just so you can review it, but it will be not be merged into the code. The component will be added with the button and correct position in another task: T328148 . Please note that this version doesn't include the mobile version, keyboard navigation or RTL behaviour, those features will be added in subsequent tasks.
https://889547--clicky-sparqly.netlify.app/

In T328141#8578615, @Michael wrote:

Looks mostly good to me, though I would probably have phrased the comment in the info section differently. I'll move it to Tech Verification nonetheless, mainly for @karapayneWMDE to verify (including the info copy) and close if deemed acceptable.

Relevant PR: https://github.com/wmde/wikidata-mismatch-finder/pull/533

In T328141#8578305, @karapayneWMDE wrote:

I generally don't like to change two things at once while experimenting, but looking at the last 6 months we've not gone above 350ms so reducing down to 500ms makes sense.

wbeditentity 50 - 500ms

wbgetentities 5-30ms

The Entity Schema is now on the Daily Dashboards Column. @Lydia_Pintscher @Lucas_Werkmeister_WMDE

In T325743#8564098, @Lucas_Werkmeister_WMDE wrote:

One unintended consequence of this change is that the focus outline of links is now gone in Firefox, where it was previously nice and visible. (However, in Chromium, links already didn’t have a focus outline and that doesn’t change.) Is this okay to deploy, or should we find a fix for the focus outline first?

In T324680#8561517, @Lucas_Werkmeister_WMDE wrote:

Looks good to me, though I’d suggest adding a signature in the note on #64.

In T325372#8561136, @Lucas_Werkmeister_WMDE wrote:

Looks good to me as far as the task description goes, but doesn’t it actually belong in the “Daily Dashboards” section? The data looks pretty daily to me at least.

@Michael and @Lucas_Werkmeister_WMDE
I don't see an option to delete the Abuse Filter, it's either not possible or not possible with my permissions. #66 has been disabled and #64 has been update and a note added. Please let me know if we can consider it as done or if you think there are other considerations to be taken.

Maybe @Lucas_Werkmeister_WMDE has something to add about the global flag (?)

EntitySchemas has been added to the Live Dashboards section of the main Wikidata grafana board

Thanks for your review @Michael, it seems like the Global flag makes this filter affect all the wikis, so disabling it will make the filter work only in beta-wikidata. The global flag was on on the original filter and I assume this is the original desired behavior that's why I left it. I don't know about Link spamming in other betas but there were quite a few daily hits for beta-wikidata. I also think it's a good idea to delete nr 66, I wanted to get approval from a reviewer before. So we keep 66 with unset global flag? Or only keep an updated 64. To me is the same. And indeed the bug here is specifically for beta-wikidata. :)

AbuseFilter 64 has been deactivated and it's no longer blocking testing with filter 66. In case AbuseFilter 66 gets approved we still need to change the Block time from 2 hours to indefinite to match what the previous filter was doing. Also i don't know if we might want to update the name of the new filter or leave the current one "Refactored Link spamming" to diferentiate it from the previous filter.

In T324680#8528582, @Lucas_Werkmeister_WMDE wrote:

I looked at the AbuseFilter code a bit, and while filters are cached pretty aggressively (one week), it looks like the cache is supposed to be purged when a filter is edited… I don’t know why that doesn’t seem to be working.

But it should still be possible to test the new filter, right? Even if an edit gets blocked by #64, we can check in the abuse filter log whether it triggered #64 and #66 or #64 only (Beta Wikidata abuse filter log for global filters #64 and #66).

Created AbuseFilter 66 which is a modification of AbuseFilter 64 and disabled nr. 64. Testing is a bit tricky since trying to add a statement with a link is caught by the new Filter (66) but creating a global coordinate still triggers nr. 64 which is theory is deactivated. Will move to Peer Review. Is this maybe a bug when deactivating the filters?