Out of interest, should/would WikimediaCustomizations be added to {H425} as a result of this? (If not, should MediaWiki-Platform-Team be added manually to any future tasks that concern the extension as a framework/that might benefit from code steward input?)

(swapping tags, IIUC this tag might be more fitting here as there might be work needed on the translatewiki side of things)

In T408110#11440842, @Novem_Linguae wrote:

Your patch added a FlaggedRevs namespace. Yet you say some things were removed. I must be missing something. Feel free to elaborate.

This should now be done (thx @Ladsgroup for the code-review!). Apologies for the delays :)
A couple of things to bear in mind:

• As I discovered earlier in this task, FlaggedRevs can be...somewhat unpredictable. So, if anyone notices anything that doesn't seem right on enwikibooks now that this has been deployed, please feel free to leave a comment here. Worst case scenario, if things have gone wrong, we can always revert the config-change and see if there's another way to get this done!
• Speaking of FlaggedRevs being unpredictable: while the deploy was in progress, I discovered that the counter of pending-changes at Special:PendingChanges hasn't updated following the removal of these namespaces (and so is now slightly higher than it should be). I didn't revert the patch as it seems like a relatively minor issue; but if the community thinks it's worth e.g. reverting these changes due to this issue, please feel free to leave a comment and we can get that done :)
  • (@Ladsgroup are you aware of an easy fix/a maintenance script for this? it seems to read fp_pending_since from flaggedpages, which I'm guessing the config change won't have updated. no worries if not but I thought I'd ask :))

This should now be done :) Apologies for the delays. Please feel free to leave a comment and/or reopen the task in case of any issues.

^ deployed :]

I'll remove this as a subtask of T166622: Allow all users on all wikis to use OATHAuth, as it didn't block that from happening. (FWIW @Mstyles, If it's been decided that this e.g. isn't going to happen/shouldn't happen, it can be reclosed, just as 'declined' rather than 'resolved'.)

Boldly closing, assuming that the above information has resolved this. Please comment/reopen if this is incorrect!

See also T410106: Log thank buttons are an unfit style for their location

(Resolving per the above merge & deploy)

In T409568#11355956, @Huji wrote:

@Chuiimuii_ofc I cannot understand where this is enabled for enwiki. The config file doesn't show it being enabled for Category namespace (14) for enwiki.

I just discovered this bug myself while figuring out how the English Wikipedia has subpages enabled in its Category: namespace (T409568#11355956).

(Since leaving my previous comment, I've found that this is already tracked upstream @ https://we.phorge.it/T15160. So I'm gonna boldly reopen this task to track that upstream one.)

FWIW I have also found this behaviour confusing. If someone asked me about this, at first glance, I would probably also consider it a bug that the feed item for a given comment doesn't update when that comment itself is edited.

Hi @Varnent! Just looking through the Wikimedia-Site-requests backlog & I just want to check if this is something that's still wanted, given it's been a bit of time. If so, I assume that this is something that'd need to be lead by the WMF/WMF staff (rather than volunteers), given (for one reason) that volunteers presumably wouldn't be able to access officewiki to test out any patches/check that things are working okay.

AFAIK, a task is supposed to be created automatically as well

In T406023#11417321, @TheDJ wrote:

Can a site requester take care of this one ? https://gerrit.wikimedia.org/r/1192528
I don't have the time to schedule config changes and be present during weekdays.

Out of interest, do you know if admins on Wikipesija.org were able to add/remove confirmed? If so, I guess this could also be viewed as a continuation of something that sysops were able to do on the wiki's previous site; and therefore, potentially not as big of a deal to make the change without waiting for the discussion to be open for longer. (disclaimer: i'm not a sysadmin :))

In T410572#11429882, @Dzahn wrote:

I would say this is so against what a reasonable user can expect that I would consider it a bug.

@valerio.bozzolan Admittedly I'm out of my depth here, but I'm not sure if async Herald rules would necessarily have to be limited to non-content-affecting actions? I included this in the upstream task I filed:

In T408110#11398732, @codenamenoreste wrote:

I have a question: is there a way for FlaggedRevs to exclude some certain pages? Three specific pages would be the Main Page, Cookbook:Table of Contents, and Wikijunior.

I'm not personally aware of one, apologies (but I'm not overly familiar with FlaggedRevs myself). The closest thing that comes to my mind right now is the ability to use FlaggedRevs as a 'page protection' option (like the English Wikipedia does), but to me that sounds like the inverse of what you're describing. Maybe someone else might know.

In T410018#11374839, @dancy wrote:

Does anyone know where https://noc.wikimedia.org sources its data?

Closed as a duplicate as (to me) it seems like the same as T395168, but feel free to reopen if it's different :)

(noting that tokwiki has now been created)

In T411119#11411847, @Tamzin wrote:

@A_smart_kitten, I self-reverted after remembering T404507#11181616

Ah, ty for the pointer :) I have no objection if someone wants to revert me; but in this case specifically, IMO the wiki having the correct logo is probably closer to being necessary for the wiki to 'function properly'. (& also it turns out that setting up the wiki's logo & wordmarks is a checkbox in T404567: Post-creation work for tokwiki)

(oops, didn't see the prior addition/removal before adding it as a parent task myself. if there's a reason for it not to be a subtask then please revert me by all means :))

In T411078#11409427, @Jdrewniak wrote:

hi @A_smart_kitten Ideally both, but I think any end-user reported bugs can be primarily filed with MediaWiki-extensions-WP25EasterEggs .

@Jdrewniak To confirm -- in case of (e.g.) any end-user-reported bugs with the new extension, will the MediaWiki-extensions-WP25EasterEggs tag on its own be monitored? Or e.g. should tasks filed in that project also be tagged with PES1.3.3 WP25 Easter Eggs? /genq

In T411015#11406501, @Reedy wrote:

It's not seemingly really documented anywhere where tasks relating to any of these should go, https://www.mediawiki.org/wiki/CLDRPluralRuleParser doesn't really mention anything etc either.

FWIW, that page currently links to MediaWiki-Internationalization as the issue tracker. (Not that this would necessarily block the creation of a specific Phab project, just noting it for the record :))

Going by the author listed at https://packagist.org/packages/wikimedia/gpglib, maybe @Tgr might know?

@jsn.sherman that seems similar to T370943: On diff pages, the logo overlaps the diff summary in dark mode

(tagging based on the function calls that I can see in the Codesearch result - the 'other' extension is ext:SemanticWebBrowser, so subscribing @Denny fyi as one of its listed authors)

(rm'ing MediaWiki-Special-pages tag, as its description indicates that tasks re. Special:Upload are generally tracked in MediaWiki-Uploading)

I'm not certain but it feels like the main issue reported in this task may have been (indirectly) fixed by @matmarex's patch here (written for T371756), now that - following that patch - the JS event listener in question appears to no longer match tags <h1> to <h6> without the .mw-heading class (and so, IIUC, shouldn't now match the element containing a page's title).

[...] it seems like the auto-generated section links for these types of headings used to also include the comment markup itself (e.g. <!--T:2-->). My guess would be that this was probably fixed by T173711: HTML tags are incorrectly included in edit summaries when editing sections in 2017 editor / https://gerrit.wikimedia.org/r/374573.

(The upstream task is closed as resolved, and the (main) patch linked to it was deployed downstream in T409947: Merge and deploy upstream master from Phorge as of 2025-11-12. To confirm, is there anything left to do here? xref. the comments in T409640: "@" suggestions should come from participants user list first)

FYI T410845: Userrights special pages layout requires excessive scrolling

(tagging MediaWiki-General as this is a request to extend this feature beyond just temporary accounts)