Documenting my query about regex flavors: Editors using AWB are used to the .NET flavor and those using Cirrus search are used to a MediaWiki-flavored version. Hopefully we can avoid introducing a third flavor that could cause confusion.

The tendencies of the Add-a-Link model to suggest overlinks and to suggest linking over partial terms have been points of community concern, and this could scale if deployed in Suggestion Mode. T415623 and T405185 respectively could help address these issues.

@Aklapper, is there a tag on Phabricator I should be using for licensing issues (which the legal folks might want to know about)?

@Femkemilene and @Johannnes89, I believe work on this is continuing at T420258.

@AAlhazwani-WMF, for "Username must represent you as an individual, not an organization." would it be more grammatical to start the sentence with "Your username must..."?

Documenting the risk case I shared offline. Consider two publications of equal overall reliability, the Political Post and Mushroom Metrics Monthly. The Political Post regularly covers hot-button topics, and is often cited on political articles, where edits tend to be reverted frequently. Mushroom Metrics Monthly, on the other hand, tends to cover a more mundane topic with fewer reverts. Because of this, the Political Post might accrue a much higher revert risk score, misleading editors (and going against the consensus at the reliable sources noticeboard) that it is just as reliable a source. More broadly, this phenomenon could disadvantage sources that tend to engage with controversial topics.

I like that screenshare! There seem to be various other technical restrictions on usernames listed at this page. If we have the capacity, it might be nice to handle some of the other ones in a similarly elegant way.

This link appears more than once in this section. Help readers navigate the article more easily by removing repeated links.

If I'm not too late on this, it's occurring to me that we might want to remove "the article" here. Removing duplicate links is mainly about helping readers navigate between articles rather than navigate within the article they are reading. So taking this out would both be more accurate and more concise.

@AAlhazwani-WMF, I'm curious, what was the thinking behind changing (recommended) to (optional) for the email address? It's easier to communicate with users who provide their email address (since someone who doesn't notice the alert notification for a warning on their talk page might still notice the email that I think (?) is also sent by default), so I'd think it's something we'd want to encourage.

@ppelberg, is this referring to potentially surfacing suggestions in the source editor, or to readers, or both?

@Samwilson, sure, see here for the version that appears on desktop, leading to Help:Contents on en-wiki:

That setting is enabled on my volunteer account (left). On my staff account (right), it oddly appears to not exist:

@GMikesell-WMF, it looks like the task you merged in is slightly different than this one. That task refers to the general editing help page in the main menu (accessible from any page), whereas this task is about the specific help for watchlists (accessible from the watchlist page). Would it make sense to undo the merge?

Hmm, that partially explains what I observed (in the "other information" section), but not the discrepancy between my accounts. And overall it doesn't seem optimal to have one design in some places but another in other places.

I was thinking of commenting on those icons myself. To me they indicate "this is an external link," not "this will open in a new tab".

Published on-wiki.

Could we do a data query to figure out how much this reduction of scope would reduce the number of instances in which this check is activated?

Following up on the challenge point, do we have enough scale with the task that it'd be likely we might detect a difference in revert rates if we ran an A/B test? Are there particular obstacles that would make it difficult to run an A/B test? (This applies to T415623 as well.)

Noting here that it might be helpful to check in with folks more familiar with linking on non-English wikis to determine whether the linking practices described in this ticket apply there as well or not.

I like those updates, @bmartinezcalvo! We should probably ensure that editors are automatically subscribed to the section that they create on the talk page, since otherwise they might miss follow-ups or be unable to get back to the report they made (since there's nothing in their browser history, and not all newer editors know how to use their contribution history to navigate).

@Clovermoss, just wanted to check, is this an issue you're still experiencing, or has it since been resolved?

For future consideration, Wikidata has lexemes (e.g. color/colour) that note varieties of English. It might be possible (but perhaps difficult) to generate a list of conversions based on those.

Ah, my bad, I missed those requirements! That basically captures it; the only remaining element would be the implementation of how those pieces of data are actually displayed on the talk page where reports go.

Yay! Looking at the patchdemo, a few observations:

One aspect that I'm not sure we've covered yet is how we're going to capture the information about which phrase on which article triggered the suggestion. That's info that I presume we want, as it could help us with any investigation we make. Ideally the feedback form will generate it and attach it automatically to the post. A lighter-weight approach would be to just ask in the instructions that editors include it when making a report.

Thanks for the follow-ups! When I shared my initial impressions above, I moreso had in mind newcomers. Realizing that this is intended at the moment (and maybe permanently?) for experienced editors changes my perspective. I wonder whether we're over-engineering. Experienced editors are very used to being sent to talk pages to report issues, so perhaps all we need to add is just a button that goes to a talk page that has an intro paragraph at the top explaining what we're looking for in feedback. But if we've already done the work to make a feedback form, I think it may work just as well.

Thanks for sketching this out, Barbara! A few initial thoughts:

• I don't think it'd be clear to me out of context that "Suggest changes" refers to suggesting changes to the feature itself, as opposed to the article. I might assume that it's to the article, i.e. something that posts a message to the article talk page.
• Learning how Talk pages work is an important skill we want to be teaching newcomers, and I'd like to think that, with the improvements we've made in recent years through DiscussionTools, it's no longer insurmountably difficult. Are the benefits of using a feedback form worth passing up that learning opportunity? And could it cause other issues like making it harder for editors to understand where their report is going/see other reports/go back for follow-up?
• Related to the above, I worry that "Your comment helps improve suggestions on Wikipedia. It will be reviewed by people and won't affect this edit automatically." is not going to be enough information to teach newcomers how to offer useful feedback. We've seen with Mentorship that making it very easy to post a message results in a lot of gibberish-type messages from users asking for e.g. help with their homework. And making a good Suggested Edits bug report is fairly complicated, since it involves understanding both how the suggestion is supposed to work and some way in which that's going awry, and then articulating it. I guess we could just wait to see what sort of messages we get, but I fear that, without additional explanation (and perhaps even with it) we may get so much spam that we end up ignoring the feedback page (or restricting feedback to more experienced editors). One way to make things more structured might be to split the "Message" field into several questions guiding users through the steps of a good bug report. While not as lightweight as the current design, fewer low-effort reports could be desirable if it clears out some of the spam.

@zoe, if the above list of redirects is hard-coded, does that mean that, if future redirects are created to the British English template, articles tagged with those redirects would not cause the suggestion to activate? That's not optimal, but if it's what we want for the MVP we should probably add a note to the template documentation that, if new redirects are created, they should also do something to ensure this stays in sync.

Following up from my previous comment, I have created T414898 for that issue as it relates to Suggestion Mode.

One thought: When I come across an external link in the body of an article, sometimes it's being used as a kind of reference, i.e. it goes to an external source that verifies the information being provided nearby. In these cases, I tend to convert it into a citation rather than just directly removing it. It'd be helpful if this check (and the related suggestion; not sure where that is on Phabricator) could prompt editors to consider that option as one possible way to resolve the issue.

Two related points to consider:

The exceptions listed in MOS:ENGVAR include quotations, titles of works, and proper names. For quotations, we probably want to apply the same logic to skip them as we're doing for Tone Check. For titles of works, maybe skip anything in italics. And for proper names, maybe skip anything capitalized.

Oh, and one other nuance: When a link goes to a section of an article (or comes from a redirect that might be a subtopic), those should probably be treated as a separate links. So e.g. There are many types of Wikipedia editors, including [[List of Wikipedia editor types#Wikignomes|Wikignomes]] and [[List of Wikipedia editor types#Wikifairies|Wikifairies]] should not trigger the suggestion.

Looking at MOS:DUPLINK, there are various exceptions that it'd be good to build into the tool. If these rules are different in other languages, it might be good to ensure that Community Configuration can handle them. Specifically:

I think editors would probably be open to that solution, so long as it didn't affect the appearance of the boxes. Given that a manual option for suppression is still needed for the other use cases, though, it would require (a small bit of?) additional development work to implement.

As of 2025, the lack of this feature is one of the most common reasons I end up needing to disable DiscussionTools while editing. (Various talk page templates, such as new year's greetings, don't play nicely with it, not just welcome templates.)

Definitely makes sense to have a universal default, although it does seem like MOS/Accessibility is translated into more languages than MediaWiki's Documentation/Style_guide. Hopefully it'll be possible for each wiki to create a localized destination for the link?

@ppelberg and @Iflorez, when the final report is available, can you share a link so that I can draft an update for sharing on en-WP and update the Asana task?

For reference, copying an offline comment I made about the possibility of the feature helping users who come across improperly formatted quotes to correct them:

Along with location, date of creation is one of the other fairly important pieces of metadata that isn't currently being displayed for the example file. Is that part of the same issue?

Thanks for that clarification, @OKarakaya-WMF! The partial name link issue (which the Agricultural Bank of France edit is an example of) is really the main capitalization issue we've been encountering — it's also what happened in the examples I cited above reported by Rich Farmbrough and Kerry Raymond.

At en-WP, I'd suggest placing notices of the discussion at Wikipedia:Village pump (WMF), Wikipedia talk:Editnotice, Wikipedia talk:Help Project, Wikipedia talk:User scripts, and the #general and #english-wikipedia Discord channels. For people who patrol edits, Wikipedia talk:Recent changes patrol might help, and people who patrol articles can be found at Wikipedia talk:WikiProject Articles for creation and Wikipedia talk:New pages patrol/Reviewers (for all of those, and explanation along with the invite of why we're particularly valuing their perspective might be helpful).

^ Spam, @Aklapper

English Wikipedia has 40,000 articles tagged as needing an update.

If I'm understanding it correctly, this task seems ripe for Wikidata integration of some sort.

On English Wikipedia, which articles should have an infobox is a surprisingly contentious question, with some editors very much opposed to having them everywhere.

@Chipmunkdavis has pointed to an additional instance of a partial name link in this edit.

Thanks, @C.Suthorn! This is a little beyond my depth technically. But if there are pieces of metadata that aren't being shown for webp files that ought to be, to match the behavior of image file types, then it'd be helpful for someone to file a ticket for that.

This is interesting, @MNeisler! People being more likely to complete an edit when the check is shown feels unexpected, since normally throwing warning notices at people causes some portion to give up and abandon the task. I'm curious, do we have any hypotheses that might explain this?

To read the metadata, I was just looking at the metadata section of the file page. Is there a reason that the coordinates (which per above do seem to be part of the file's metadata) — and every other piece of metadata apart from "software used" — might not show up there in the same way they do for photos? If so, perhaps the issue is with how we display metadata for video files rather than something Video2Commons is doing.

@Jdlrobson could you share more about why this was deemed not a priority?

@Amdrel , if you'd like another example of a V2C video, here's one (or take your pick from the category).