Would we want to scope this to only show on desktop? Commons has some historical issues with cross-wiki uploads, particularly from mobile devices.

I think we might have a ticket somewhere (but cannot find it) about making it so that the check icon in the mobile gutter is kept on-screen. That would address this issue, in a non-paste-specific way.

This specifically means the read-mode popup, not the context item inside VE, right?

I could see it having many suggestions

Technically, and I know this is a weird edge case, you could have a replyable comment on a page you're not allowed to edit. Because replies work across transclusions, you could have a read-only page that does {{Wikipedia:ProjectFrontPage/Comments}}, and so long as Wikipedia:ProjectFrontPage/Comments is editable it'd pass the replies through.

One approach would be to use the likely outcome of T422431, which intends to add the ability to scope a check to only apply within a given node type. In this case it'd be fairly easy to make a textmatch check that checks for \.$ only within mwCaption nodes.

MOS:GEO is an example of something where we should almost-certainly include a link. You'll be able to write wikitext in the descriptions and have it work, though it's admittedly incredibly enwiki-specific as a result.

Context: this is the same toast that's triggered by clicking the timestamp, so this was a long-ago behavioral decision. It could be revisited if we want.

It's init-related, so getting a third person to take a look makes sense.

We might need to consider a tiered set of actions -- top-level being the current "here is a description of what the model thinks is wrong", and then becoming more specific like "take action X", then "take action Y automatically". So we'd always be able to offer something, and wouldn't have it be potentially-weird if the model-generated text was suggestion you take an action we don't offer on that wiki.

Looks pretty good now. We've had literally no budget consumed in the last 7 days on the dashboard.

Testing note: https://en.wikipedia.org/w/index.php?search=hasrecommendation%3Alink&title=Special%3ASearch&profile=advanced&fulltext=1&ns0=1 will show you pages with link suggestion data available. That's pre-filtering by the threshold though, so they won't all actually show a suggestion if you edit them.

The Tooltip could be shown on hover or focus on the Button on desktop, while being shown by long pressing on touchable screens.

I doubt anyone is going to think to try that, so I'm skeptical that it's worth the implementation-effort of a whole new interaction that we don't currently support. (Plus, it'd be overriding an actual expected system-level browser interaction that people might expect -- it's how you trigger the context menu.)

You can also look directly on translatewiki -- go to https://translatewiki.net/wiki/Special:Translate?group=ext-mobilefrontend&language=ru&filter=&action=translate and enter "abandon-survey" in the search box at the top of the list.

@Wellverywell you can see all the strings in the green lines in this file in the patch: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/MobileFrontend/+/1291108/3/i18n/en.json

Bear in mind that the ⓘ approach wouldn't be particularly viable on mobile, where this button also appears.

Thus far translatewiki has localized it into: az, de, fi, gl, ia, ko, lb, ms, so.

Depends a little on which wiki you edit on. It'll be on the deployment train, so at latest you should see the fix on Thursday.

I think this has helped. Following those patches going out on the train (finished on the 21st) we haven't yet seen any spikes like there were before.

Oh wait, that was the same patch appearing twice as "uploaded" for some reason, not getting merged. So, ignore that "despite the patch" comment.

Definitely still happening despite the above patch, e.g. https://integration.wikimedia.org/ci/job/quibble-with-gated-extensions-selenium-php83/36425/console this morning.

In T407664#11970555, @Wellverywell wrote:

Also, seems like e.g. regexp \. matches the result of <code>.html</code> even if ignoreQuotedContent is set to true.

I'm fairly sure we used to wait to clear out the highlights until the processing phase was completed, so this is likely to be a regression from some of our recent refactors.

@bmartinezcalvo How do you think this button should adjust to being multi-line? (I can see at least two ways it could scale, depending on whether the sides remain semi-circles or not...)

Here's an example of a template that adds a hidden category:

<link rel="mw:PageProp/Category" href="./Category:All_articles_with_unsourced_statements" about="#mwt5" typeof="mw:Transclusion" data-mw='{"parts":[{"template":{"target":{"wt":"Citation needed","href":"./Template:Citation_needed"},"params":{"date":{"wt":"January 2026"},"reason":{"wt":"There is conflicting information about when this album was released, as sources such as Amazon list the release date as 2001 instead of 2000. If one has a reliable source per WP:RSPS that says 2000, please cite it."}},"i":0}}]}' id="mwDQ"/><link rel="mw:PageProp/Category" href="./Category:Articles_with_unsourced_statements_from_January_2026" about="#mwt5"/><sup class="noprint Inline-Template Template-Fact" style="white-space:nowrap;" about="#mwt5" id="mwDg"><span typeof="mw:Entity">[</span><i><a rel="mw:WikiLink" href="./Wikipedia:Citation_needed" title="Wikipedia:Citation needed"><span title="There is conflicting information about when this album was released, as sources such as Amazon list the release date as 2001 instead of 2000. If one has a reliable source per WP:RSPS that says 2000, please cite it. (January 2026)">citation needed</span></a></i><span typeof="mw:Entity">]</span></sup>

One thing we could do is improve the documentation for this. I'm fairly sure this isn't highlighted anywhere as something a community might want to do.

I cannot reproduce this on a mac (where it's option-shift-space):

One more reproduction note: I cannot reproduce this when I have JS disabled.

Might be worth leaving the MinervaNeue tag on, just because it's significantly easier to trigger there, so there may be some relation.

@gh87 https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(WMF)?useformat=desktop&useparsoid=1&useskin=vector2022#Survey should get you that. It could be somewhat device-dependent, since the apparent error is RAM-exhaustion -- I'm testing it on an iPhone 17 pro, meaning there's 12GB of RAM.

• Has bug: https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(WMF)?useformat=desktop&useparsoid=1&useskin=minerva#Survey
• Does not have bug: https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(WMF)

Note that this does expose something currently sort-of private, which is exactly what content was thanked. The user was told this when the notification of the thanks arrived, but if they cleared that notification then it was no longer available to them.

Follow-up: I have done some DiscussionTools performance work on the above-mentioned ticket.

^ those patches take a local clone I made of the currently very-busy Village_Pump_(WMF), and reduce the time-cost of these areas of DiscussionTools during the initial page load from 176ms to 25ms. (On my high-spec macbook, so we can expect that to be more significant for many users.)

Did you try useformat=mobile&useskin=monobook ? That would help eliminate whether Minerva has anything to do with this.

As a variant of 1/2, we could make the existing showAsCheck and showAsSuggestion keys accept a config-object as well as just a boolean. We've already got precedent of doing nested config checks via textmatch rules, so a similar system could be used here. Check the top-level config, and then check whichever of the sub-configs are provided.

Connecting a cable didn't help as much as I had hoped. The main thing learned was that this isn't the page actually being stuck in a reload loop via navigation, but rather the rendering is crashing and restarting. I was also able to place breakpoints in Toggler.js which weren't reached (or at least, the process crashed regardless and things moved on -- hard to tell the difference).

I tested this on iOS.

Some debugging:

I'd have to assume it's something about the highlighting / auto-expansion code that's clashing, presumably in ways that're more noticeable on larger (and thus slower-to-load) pages.

Is this causing enough of a problem that we should backport the API fix on monday?

First, @matmarex is completely right. DiscussionTools should preserve all the subscriptions when you move signed comments between pages, so long as you avoid altering signature timestamps. If you then transclude the discussion onto the original page, DiscussionTools should also be able to automatically reply on the correct page for people viewing the main village_pump page. (There are ways it can get confused with more complicated arrangements, but an entire thread being transcluded should Just Work.)

Theoretically, DiscussionTools is supposed to not be activating when the ConvenientDiscussions gadget is enabled, which we'd hope would stop this. (See: DiscussionTools HookUtils.php featureConflictsWithGadget.)

^ that fixes the imageSizes access, which was definitely wrong, and will stop these errors from occurring. Should probably also work out what's going on with thumblimits though.

I could absolutely patch the widget, but I'm not sure whether or not "siteinfo returned an object for this value" should be considered the new ongoing behavior or just a bug.

In a similar vein, this seems to have caused T427066 because the way this value now gets serialized into the siteinfo API has changed (it was formerly an array, and is now an object).

On quick examination, it's not anything inside the VisualEditor extension, this is a request made by mw.widgets.MediaSearchWidget in core. When the VE media dialog opens, it makes one of those search widgets and requests that it fetch the user-upload queue (via this.search.queryMediaQueue()), and that results in this request with malformed parameters.

With that patch:

Issue appears to be that this is what setContents does:

In this context, the font-size on that element is set to use @font-size-small, which correctly evaluates to 0.875rem (per codex), which in this document becomes 14px. I cannot say exactly why that isn't the 12px you specify, but that isn't the token-meaning so it does make sense.

Ah, the joys of the token life. Fixing this one might involve either ignoring the token or doing a bunch of digging into the CSS stack.

Icon spacing issue was that icon-size-small reacts to the vector appearance menu's content-size setting, and the rest of this widget does not. Spacing was fine when that was set to small (which is where I leave it locally), but at standard/large it looked off. I changed the token used to get an equivalent size across all settings.

Footer text size should be font-size-small (12px on Vector22, 14px on Minerva)

ve.init.mw.DesktopArticleTarget.prototype.afterActivate focuses the surface once it's done loading. On a page without editnotices, we could pretty easily check whether document.activeElement exists and is the sort of thing that can contain typing-focus, and not focus the surface if that's the case.

Verified on beta @ https://en.wikipedia.beta.wmcloud.org/wiki/Cats?veaction=edit&ecenable=suggestions,experimental

In general, we'd really prefer that {{reflist}}-style templates not be used, because they make it extremely difficult for us to ever support list-defined references. See the venerable T52896, and more recently the bug that meant T356471 had to get reverted.

Checked on https://en.wikipedia.beta.wmcloud.org/wiki/Cats?veaction=edit&ecenable=suggestions,experimental where there's a tone issue that thus had a footer:

At this point, we need to get this initial refinement released.

To be fair on the robot one, the "head only" approach is what was picked for almost-all takes on the robot emoji (🤖). Granted, there's more detail available to them rather than just an outline.

I noticed these search icons...

Sorry, forgot to close this because of the hackathon.

@bmartinezcalvo if there's a ticket for more general design adjustments to the widget (for the footer and the suggestion-feedback icon), I could retag those patches against it.

That patch adjusts the footer display:

For the suggestion feedback ... menu, that patch does this:

To align with the Revise Tone one, the footer should include the cdxIconRobot in icon-size-small

With those patches, we're now to this state:

@medelius did some earlier looking into this because CommunityConfiguration requires a schema. The schemas it required weren't permissive enough to make that system usable for us at the time, but there might be some reusable fragments from when that was done?

I can't reproduce this one.

Those patches all came from me investigating uncaught JS errors related to editcheck for this task, though not all of them could actually interfere with the SLO.

On iOS: the context doesn't appear, but the keyboard does get dismissed. A second tap on the link open the context.