I don't think this should happen, because it loses the connection between the check card and the text it relates to -- we won't even be indicating what we're rechecking. It will also cause a strange flicker in the case where the tone issue wasn't resolved, as the state goes from "blue borders" => "0 - 5 seconds of nothing" => "yellow highlight".

Yes. See all the discussion above about how this label isn't exactly intuitive. :D (And T401980 for updating it.)

Phase 2 is basically T387175.

Patchdemo: https://07ead78978.catalyst.wmcloud.org/wiki/New_York_City?ecenable=2#/editor/all

The stale rendering can be applied when I revise the tone without actually clicking the "Revise" button. It's not necessarily tied to the "Revise" button?

That's accurate!

The observed behavior sounds correct to me.

It's more a general issue -- WikiEditor suffers from the same thing, though admittedly you can fall back on just alt-p there if you ignore the tooltip.

I updated this patch on top of the bucketing implementation I did for T389231. I had to rewrite it to cope with how we're handling the "filtering" with the async check.

That patch, as well as setting up the tone a/b test, lets us run a/b tests of any current experimental check. Just one per wiki though.

{{DISPLAYTITLE:...}} being present in the source also isn't picked up by the advanced settings dialog.

It sort of helps, but it doesn't necessarily map closely in either direction. A single point in wikitext could essentially point to a large range in VE after template expansion, or many points in wikitext could all map to the same VE location after e.g. whitespace collapse.

("We found a tone violation in the 7th paragraph that Parsoid outputs for this page, after stripping out everything that Parsoid flagged as being template-related" is a thing VisualEditor can easily match up.)

Yes, the table experience is what switched me from "I should keep these expanded so I'm seeing the default behavior for users" right to "get these menus out of my sight". 😅

I just realized: it's not even an extensions issue, this interferes with Vector's own notifications:

I think the answer is just "it isn't in skins.minerva.icons"? That's currently:

Nothing has changed about eye in forever. In 2017 it got moved from general icons into the accessibility subset, but that was the last thing that touched it. It's actively in use in VisualEditor itself and outside it in visual diffs, and in both places it's referenced as eye.

We wound up being consistent with how this setting applies to the other source editors:

In fact, that's T401457.

@EAkinloose I think that message only appears in the non-2017 source editor's preview, so that is completely unrelated to the patch.

We've changed how the selection-state works, so this shouldn't be so much of an issue now. The QA should wind up happening against the tone ticket.

@Trizek-WMF opting out of seeing the overflow menu at all is part of the bottom checkbox there, but we don't plan to offer any way to opt out of just Thanks. (I think that "preference to control whether you even see an individual button in a menu" is a bit excessive.)

The specific patch that made the initial search router fix got merged and backported on the 4th, and the followup went out on the next train, so they were all out by the time you were trying to reproduce the issue. It's certainly plausible that those in combination affected it.

In this case, the descriptions would be applying to the period after it's the default as well.

I'm extremely confident that there's another ticket out there about adding a new type to templatedata so that parameters could be flagged as expecting wikitext, in which case we could give you a VE widget in the template editor to have access to things like the link tool. But I can't find it.

That suggestion sounds good to me.

Speaking from a purely DiscussionTools perspective, we're particularly interested in making sure that we wind up with a syntax that's "pleasant looking" to power-editors who're still responding to discussions via full-page source editing.

This might have been the point of confusion, because looking at it I can see an interpretation I didn't mean:

We just have a hook that hides it from your preferences if every single feature that's bundled into it is available on a given wiki. As soon as we put Thanks in it, it'll show back up everywhere... until the moment we enable it for everyone on that wiki.

To rephrase: the beta feature reacts to the default state of other DiscussionTools features on a wiki, but it being enabled on a wiki doesn't serve as a shield against otherwise-enabled features. We can turn features on or off for a wiki by default with no relation to whether the beta feature is enabled on that wiki.

So this means that Thanks will be enabled for all logged-in users by default on mediawiki.org next week, without them opting into it?

No, nothing will change for them. Putting Thanks into the beta feature when they don't have the beta feature at all won't do anything.

Tacsipacsi is right -- technically the DT beta is currently available on every wiki but mediawikiwiki:

I think I like the second argument to addRoute the most, so here's a patch implementing it, plus the warning on an empty route.

This is specifically switching to source editing in DiscussionTools.

(it’s not really the reply buttons that are “enhanced”, but a new button is added)

I think of it that way, because it switches the [ reply ] out for OOUI buttons instead (which is also why the overflow menu doesn't apply there)... but I acknowledge that I might be technical-knowledge-poisoned here. 😅

We could adjust it so it doesn't need to change depending on the Thanks feature, if we went with something like:

Regarding learn-more: we last did some copy updates when we refreshed the flow in T400518, at which time we hadn't specified a link, and then said we weren't going to keep fiddling with it until T400518 dealt with it.

Apart from the last two. There's no check-control-[listener] because we haven't implemented any a/b test code for this yet. There's no check-learn-more because there's not a learn more link in the check yet.

Shortly after writing that, I found: T389272

I was just helping someone who had this randomly happen to them after doing a developer setup.

You should really link to logstash in these reports.

There's presumably languages where the most-natural translation would include switching the order of the reference and the message, thus the suggestion for $1, though it doesn't really work out to do that in this situation since it's a full block-level display of it.

I took a first pass at describing this in https://www.mediawiki.org/w/index.php?diff=7817207

Oh, "types" might also want to include namespaces: T400506

You can see the issue via https://en.wikipedia.org/wiki/Talk:Floppy_disk?dtdebug=1 -- DiscussionTools is respecting the mw-notalk class that has been applied to that opening section and excluding it entirely... and then the code. that extracts othercontent for the threaditemshtml API response doesn't catch this case. This is because othercontent is intended for pages that mix discussion and non-discussion sections, and so won't trigger if there's any replies at all in a section.

Added in T399184. Seems to be a complement to the existing cite-ve-dialog-reference-editing-add-details which has a similar fragmentary pattern, and was added last year in T373876.

e.g. on https://en.m.wikipedia.beta.wmcloud.org/wiki/Talk:Main_Page?useparsoid=1 -- the FOUC is only really visible at narrow phone window sizes.

My recollection was that in particular there was debate about whether it should be implemented as new magic words, or as parser functions. @cscott may want to speak more on that.

In T219543#11080413, @matmarex wrote:

In T219543#11076852, @stjn wrote:

Though there is an unresolved problem with that where canonical English name of the special page isn’t included in the searchable terms (personally I don’t know how to fix it so I haven’t tried).

Oh, that'd be nice to have.

Quick technical speculation:

Closing this, insofar as MMV is no longer going to contribute to the issue.

I'm at a loss as to why you didn't remove the search box too. Duplicating what all browsers already provide (find in page) seems like such an uncalled-for addition to the mounting tech debt.

I tried it on everything in the main menu and it didn't work -- z, x, r. Testing it with others elsewhere now, that might have been an unlucky sampling.

@Bugreporter2 They were talking about Ed's new patch, on which @Ladsgroup left the comment "The change was designed by a designer (Derick), Please before merging the revert, go a designer to sign off on it."

Yeah, based on https://yume.wiki/Special:Version you haven't updated VisualEditor since at least October 2023. Problem will go away if you update.

That said, check whether your copy of VisualEditor is up to date, because this specific instance of the issue is already being worked around because of T317600. It checks in advance whether the pagetitle message is parseable before trying to use it.

Fundamentally the same issue as T371185. Mediawiki's client-side message functionality (mw.Message which uses mediawiki.jqueryMsg) only supports a very limited subset of wikitext. PAGENAME should actually be fine, it's the parser functions that are causing the problem here.

@Esanders That does include all the converter refactoring, which is at least a bit suspicious.

From this thread on the village pump: https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#Random_article_-_keyboard_shortcut

Totally agree it's too subtle / ambiguous as-is. Ultimately, it's because we wound up bundling a few other visual change features under the general release we did with the header changes, because those were the most drastic, and it didn't seem worth calling out that we were also changing the display of the reply buttons. It just picked up a functional effect now because the overflow menu was built on the new buttons...

When you saw this, did it appear to delete the article in the review-changes diff view before saving? Or did it only happen after the save?