Yes, I think you're right. Well spotted. I think we can close this. Thanks for your time.

Oh I see. It's because the panel floats. One workaround until I figure out how to fix this is to zoom out your browser.

I'm unable to reproduce. But I see what you mean. The fix is probably to increase

I 100% agree that some kind of shorter syntax for <syntaxhighlight> is needed.

Because of this ...

I'll hold the patch for another two weeks. Setting my calendar reminder for August 25.

I'll have to thoroughly read this ticket, but my idea is...

This could be done by using the edit page hook to detect if an article in mainspace is getting flipped from a redirect to an article, and then adding some kind of metadata to the SQL table pagetriage_page_tags with the redirect flipper's username.

In T238848#8098924, @Novem_Linguae wrote:

Patching T204465 should fix this too. That patch would make a blank text box = no notification.

I don't think that radio button is hurting anything. May not be worth the effort and additional complexity of hiding it.

This patch/ticket might be obsolete. I can't find #t-curationtoolbar in the rendered HTML at all, and I don't see an "Open Page Curation" link in my toolbox using Vector 2010 skin. Finding this is necessary to even test the submitted patch above.

For local imports, call importScript(). This is not, and never was, deprecated. For cross-wiki and other less trivial use cases, call mw.loader.load().

Support. I have a template used on talk pages that has a date in it (~~~~~) and it is receiving a [ reply ] button. Having some way to suppress this would be useful. Even if it is as simple as adding a class somewhere.

In T311324#8129496, @Tgr wrote:

Please file a separate bug if something is causing duplicate notifications, we are generally trying to avoid those.

Hmm, not sure. The left click behavior keeps the changes, but my use case above was to view the "original" wikicode (discarding the changes).

Notes in case I work on this later

@ComplexRational reports this bug is still present even after my patch. Maybe it's a race condition. I'll release an additional patch shortly.

I think I misunderstood this one. What is actually being requested is T313651. Closing for now.

I agree with the code reviewer that the algorithm in the existing patch is unusual. I might write a new patch that simply swaps the HTML <options> in modules/ext.pageTriage.views.toolbar/mark.underscore

Possible duplicate of T303117. PageTriage doesn't appear to work at all on the Minerva (mobile) skin. Quick testing in Google Chrome 103 for Android + Desktop mode + Vector seemed to work.

Doesn't appear to work at all in the Minerva (mobile) skin. Neither Special:NewPagesFeed nor the Page Curation toolbar.

I agree that this would not be simple to implement. Would have to do an API query on every hover, or store this info in the pagetriage_page_tags table and prebuild the popups. The latter is how we do it for reviewed articles. The code is in modules/ext.pageTriage.util/models/ext.pageTriage.article.js -> formatMetadata()

I'm leaning no on this one. As of July 2022, thanks to Danny's bot and the efforts of Rosguill and other redirect patrollers, the redirect queue is at 1 month and the article queue is at 5 months. Strategically it seems better to prioritize and highlight the article queue.

Appears to have been fixed in 2018 in this patch: https://github.com/wikimedia/mediawiki-extensions-PageTriage/commit/dc9d204cd2df68367dbc61b5ac3e2a203bc8f6e4

Additional bug on the same form: It will forget your custom wiki name. It always resets back to "MyWiki".

Unable to reproduce.

Sounds like the two proposed new metadata tags are "Previous AFD" and "Previous Draft"