Change #1009601 had a related patch set uploaded (by DLynch; author: DLynch):

[mediawiki/extensions/VisualEditor@master] Use reliability API to detect blocked external links

https://gerrit.wikimedia.org/r/1009601

Test wiki created on Patch demo by PPelberg (WMF) using patch(es) linked to this task:
https://patchdemo.wmflabs.org/wikis/19835917a4/w

In T366751#9865717, @PatchDemoBot wrote:

Test wiki created on Patch demo by PPelberg (WMF) using patch(es) linked to this task:
https://patchdemo.wmflabs.org/wikis/19835917a4/w

@DLynch great spot. Two questions:

1. To confirm, "...the external link annotation inspector..." refers to the External site tab in the Add a link dialog shown here?

2. Assuming "1)" is accurate, what URL might we be able to enter to see experience what 1009601 implements?

@ppelberg re: 1, yes, the "external site" tab is what I'm talking about. Specifically, it'll appear where that "enter a full URL" error is.

Re: 2, there's no specific sites configured on the blocklist on a patchdemo, but anything on the global blocklist that's autofetched by Extension:SpamBlacklist would work. E.g. https://an.to/

It'll wind up looking like this:

(The patch is being very permissive -- it's not actually stopping you from continuing to add the link, though carrying on and then trying to publish should block you in the end when it runs into the normal antispam checks.)

In T366751#9865816, @DLynch wrote:

@ppelberg re: 1, yes, the "external site" tab is what I'm talking about. Specifically, it'll appear where that "enter a full URL" error is.

Understood, ok.

Re: 2, there's no specific sites configured on the blocklist on a patchdemo, but anything on the global blocklist that's autofetched by Extension:SpamBlacklist would work. E.g. https://an.to/

It'll wind up looking like this:

Mmm, got it. Thank you, David.

(The patch is being very permissive -- it's not actually stopping you from continuing to add the link, though carrying on and then trying to publish should block you in the end when it runs into the normal antispam checks.)

Understood. Can you share a bit more about why you're proposing an experience that, as I think you put well, is quite permissive? Asked another way: what – if anything – do you think we ought to consider before mirroring the experience we implemented in T352134?

...I ask the above wondering about the value of the current permissive approach seeing as how the error message and interface seem to be saying two contradictory things:

1. The error message, to me, is saying: "You can't do this."
2. The Interface (read: Done) is saying, "Here is how you can do this."

I was mostly thinking of avoiding unintended consequences if it turned out there was some case where we were blocking something in the dialog that wouldn’t really be blocked by the existing pre-save checks. That said, I don’t actually know of such a case, so I might well be being overly cautious. I’m not wedded to the current behavior, so I’d be entirely happy to change it to a full block of choosing “done” (or, I guess, in the other direction changing it to display as a warning ⚠️ rather than an error 🛑).

Patch has been updated: it'll disable the done button after checking whether the URL is blocked.

In T366751#9868871, @DLynch wrote:

Looking good; can we please revise the error/feedback message to read the following? Assuming "yes" this looks good to me. cc @nayoub

"Wikipedians" is going to look pretty weird on non-wikipedias. Even on our projects, someone on e.g. wikivoyage isn't a "wikipedian" -- and this is going to run on non-WMF third party wikis as well... fandom, etc.

Also, we can't necessarily say that people consider it spam in the generic message, since we don't know why a specific domain was blocked -- the global blocklist has a bunch of categories. A lot of them are spam, for sure, but I'd bet that the most common thing people are going to hit this warning with is pasting a URL-shortener link in that they've copied from somewhere else semi-accidentally, and that's blocked more because it's misleading than because we think it's spam per-se.

(e.g. It's less of an issue now, since Musk did his Musk-y thing to it, but copying links from twitter used to get you a t.co link that's a shortener, and that's on the global blocklist... and also the sort of place that people will grab links from that they want to place into talk pages.)

Mmm, great spots, @DLynch. I hadn't considered the nuance of this message appearing across Wikimedia and third-party projects.

With the above in mind, can we say the following?

“This project” is also a bit of a WMF-specific terminology — a random fandom wiki wouldn’t call itself a project, I think? Would “this wiki” or “this site” work for you?

In T366751#9869609, @DLynch wrote:

“This project” is also a bit of a WMF-specific terminology — a random fandom wiki wouldn’t call itself a project, I think? Would “this wiki” or “this site” work for you?

Fair. Can we do…?

“Please try another link. People at this wiki decided to block links to the domain you entered.”

It's worth noting that "links to the domain you entered" isn't quite right, because the blocks can be much more specific than that. E.g. blocks on specific pages of sites aren't uncommon -- particular youtube videos, google books pages, etc. It's why I went with "site" originally.

Our normal sequence in error messages is problem -> suggestion, so it'd be more consistent if we reversed that.

Suggestion: People at this wiki decided to block links to this site. Please try another link.

Or maybe "page", because "site" might still be read as the entire domain. 🤔

In T366751#9869727, @DLynch wrote:

It's worth noting that "links to the domain you entered" isn't quite right, because the blocks can be much more specific than that. E.g. blocks on specific pages of sites aren't uncommon -- particular youtube videos, google books pages, etc. It's why I went with "site" originally.

Mmm, got it. Thank you for explaining. Makes sense to me.

Our normal sequence in error messages is problem -> suggestion, so it'd be more consistent if we reversed that.

Fine with me.

Suggestion: People at this wiki decided to block links to this site. Please try another link.

This looks great. I've updated the task description to include this.

Ed raises in the patch comments that we might want to say "users" rather than "people". We're fairly inconsistent about that across messages, admittedly. "Administrators" might be most accurate.

Change #1009601 merged by jenkins-bot:

[mediawiki/extensions/VisualEditor@master] Use reliability API to detect blocked external links

https://gerrit.wikimedia.org/r/1009601

First draft of language for Tech/News below.

Please let me know what edits you think this could benefit from! cc @Quiddity

Beginning Thursday (13 June), people who attempt to add an external link in the visual editor will receive immediate feedback when they attempt to link to a domain a project has decided to block. Please see [[phab:T366751|T366751]] and [[mw:Edit_check#11_June_2024|mw:Edit check]] for more details.

I checked this against the Global list: meta:Spam_blacklist, and seeing the new feedback being displayed inside the external link annotation inspector.