@TauluAlan if you intend to use https://www.mediawiki.org/wiki/Extension:FlaggedRevs by introducing editor / autoreviewer please note that this is not possible per https://meta.wikimedia.org/wiki/Limits_to_configuration_changes#Prohibited_changes as the extension has been unmaintained for years.

@Aklapper is it possible that the reporting account @Renascitur got disabled by accident? Regardless of the insufficient task description it looks like they're trying to report something they perceived as a bug https://en.wikipedia.org/w/index.php?title=2026_in_Kenya&diff=1379343110&oldid=1379307297

In T431194#12414255, @Andrybak wrote:

The bug is still actual. Example from URL https://en.wikipedia.org/w/index.php?hidemyself=1&hidepreviousrevisions=1&hideWikibase=1&limit=50&days=30&enhanced=1&title=Special%3AWatchlist&urlversion=2&safemode=1

I'm sure many community members would also appreciate insights from WMF Design on how to improve the community warning messages itself (I certainly would!). Most large wikis have made changes to the default block messages (custom text, design, links...) – usually only thinking about the desktop experience and with little (or no) insights into how any of these changes are actually perceived by inexperienced/new users or readers. The screenshots above show English Wikipedia's custom messages which are much better than the default version in my opinion but still pretty bad (even on desktop). Providing an updated default message (perhaps you also need to provide an easy option to define different messages for different skins/devices?) and a documentation page with best practices for all wikis that want to keep using their custom version(s) would be very helpful...

Thanks, I'm not aware of any other Phabricator task related to this feature request, could you link it for us volunteer CN admins to follow?
If there's no other task this one should stay open as long as there's no (non-JS) option to limit banners to users with a certain edit count. Closing this task without resolving it and without an alternative task hides the feature request from any non-WMF developer who might decide to contribute to the CN extension one day.
If Fr-tech isn't interested in this feature (which I can understand, it's only relevant to community banners – or WMF banners directed at the community like the wishlist example mentioned in the task description) you could just remove your Fundraising project tags and leave it in the CN backlog for someone else to discover it :)

@SBurnett-WMF is there a reason why this feature request has been declined without comment? It is still one of the most important feature requests to volunteer CentralNotice admins like me, because the JavaScript hack mentioned in the task description is bad UX. The task should stay open even if the WMF doesn't want to work on it in case some volunteer or affiliate is willing to help out some day.

In T240311#12061413, @Pppery wrote:

https://meta.wikimedia.org/wiki/Community_Wishlist/W354

Appears to be a content dispute about https://id.wikipedia.org/wiki/Halaqoh_BEM_Pesantren_se-Indonesia

Duplicate of T414786: Fix parser parity when handling unclosed ref tags or T398402: Remaining feature parity issues between the two Cite parsers?

In T66090#12320657, @HFan-WMF wrote:

@Quiddity thanks so much for cleaning up and summarizing. To better triage for my own team, a clarification question: the requested feature is that for a particular user who did not create the article originally, they can "subscribe" to an article so that any time links are added to the article (and no other types of changes, like new section added or new citations added), a notification is sent to that user?

and we'd like to have all the articles that are "watched" in this way to be on a list together, but it shouldn't be a sublist type within Watchlist?

In T426137#12317189, @Bugreporter wrote:

In T426137#12277753, @SomeRandomDeveloper wrote:

In T426137#12276917, @Novem_Linguae wrote:

@SomeRandomDeveloper. Sounds like you already signed an NDA but are not in the phabricator NDA group. Normally this group is obtained by making a phab ticket and tagging it #NDA-Access-Requests. So might want to do that.
Of course, the systemic issues you mentioned should probably also be addressed. For example, having this group get added as part of an acl*security application checklist somewhere, and making sure that corto is not setting things as access policy wmf-nda.

I guess requesting the group is the easiest solution for me. However, out of the 9 other members in acl*security_volunteer, 3 are also not in WMF-NDA, so I agree that in general, it would make sense to add users to the ACL automatically when granting security issue access.

We should also consider whether to add all stewards to WMF-NDA group. They have security task access, but never have it permanently.

+1 this LTA changes its target every couple of days, I got lots of annoying thanks from them a few days ago. I believe WikiBayer's proposal (500 edits) is too strict, but some limit (e.g. 1 thanks per hour unless you're autoconfirmed) would be helpful to slow them down / make it more annoying for them to annoy others.

In T423949#12305614, @ppelberg wrote:

With these concerns in mind, as well as the points you raised around usability and discoverability, the Editing Team prefers the following path forward: introduce a new item within DiscussionTools's existing overflow menu that, when tapped, opens a dialog containing the user information PSI specifies:

Desktop	Mobile	Reference (Report)

I like this approach, but I'm not sure about the mobile proposal. That's the menu option for an entire discussion thread – whose user info is supposed to be shown? The last user who commented? I would recommend to add the user info option only to the three dot menu next to user signatures (which is available on mobile as well).

Probably related: T334763: Language selector box getting cut off in Vector 2022

@TheDJ not sure if this is related: https://en.wikipedia.org/wiki/File:U.S._President_Joseph_R._Biden_Delivers_Remarks_on_the_Attemped_Assassination_of_Donald_J._Trump_(14_July_2024).webm doesn't show TimedText (when using Firefox, it works in Safari) while https://commons.wikimedia.org/wiki/File:U.S._President_Joseph_R._Biden_Delivers_Remarks_on_the_Attemped_Assassination_of_Donald_J._Trump_(14_July_2024).webm shows TimedText regardless of the browser.

Now I can (kind of) reproduce the bug – yesterday everything was loading correctly after removing the filter, now I'm seeing the UserInfo icon but clicking on it doesn't open the UserInfoCard.

I can't reproduce the bug.

I don't think it's meant to be substituted per https://www.mediawiki.org/wiki/Help:Extension:CheckUser#User_Info_card_in_page_content
https://zh.wikipedia.org/w/index.php?title=Template%3AUserblock&diff=94093964&oldid=94033848 appears to fix the zhwiki template?

It's still getting slightly cut off: https://meta.wikimedia.org/wiki/Main_Page?safemode=1&useskin=vector-2022

Seems like a duplicate of T431600: Parsoid read views: Citation preview broken on some pages. Quoting from that task:

In T429518#12213903, @Jdlrobson-WMF wrote:

@Johannnes89 I notice "Pending changes" is duplicated in the UI - as a tab and as an indicator in the top right. Is that standard for German Wikipedia and something we should reconsider to free up some space at lower resolutions?

I didn't test this on mobile but when I choose an option (inline wikitext / two-column wikitext / VisualDiff) and open another random article (or reload the page) I'm still getting that option (although when choosing VisualDiff I briefly see the wikitext diff before it switches automatically, I have a feeling that the VisualDiff used to show up right away).

I've tested the changes using https://de.wikipedia.beta.wmcloud.org/wiki/DC-37?vectornavigationupdate=1&uselang=de

In T434403#12205433, @DLynch wrote:

Actually, I can't reproduce anything close to that slowness locally in Chrome -- it takes about 4s to load that Mainz article. Could you check whether this still happens in safemode?

In T428103#12203789, @JJMC89 wrote:

This task does not provide any rationale/justification for forcing the use of 2FA.

I would rather stop using private wikis than flood my authenticator app with more Wikimedia entries.

Polish Wikipedia editors also reported today that VE is annoyingly slow when using Chromium-based browsers, sharing the example of
https://pl.wikipedia.org/wiki/Lista_filmów_ze_świata_Gwiezdnych_wojen?veaction=edit on their Discord server. It takes much longer to load this on Chrome compared to Firefox and Safari.

I don't think the proposed test is still useful given that FancyCaptcha has been replaced by hCaptcha on WMF wikis https://www.mediawiki.org/wiki/Product_Safety_and_Integrity/hCaptcha

In T422435#12173177, @Quiddity wrote:

An Admin/IntAdmin from Italian Wikipedia has also requested user sandbox pages (plus Draft namespace), at https://www.mediawiki.org/wiki/Talk:VisualEditor/Suggestion_Mode#namespaces_configuration
I noted there, that user sandboxes are complicated because AFAIK there isn't much consistency between wikis (or even within wikis) regarding categories/templates used to mark "article sandboxes" as distinct from "random notes page as a user-subpage" where we probably don't want to display suggestions - e.g. Only 21 wikis currently seem to have a dedicated templates for Template:Draft article (Q19723431) - but perhaps that would be sufficient as a start?
@Wellverywell is there a standard template/category used in Ruwiki for article drafts within the User: namespace?

What about users who deactivated topic subscription / reading lists in their preferences? Will they see unnecessary whitespace or get the watch star icon back?

In T420792#12161487, @Bugreporter wrote:

Note: If we choose to prevent users without 2FA from logging in, we need to make sure they can not receive email notification (both core enotif and Echo), otherwise content can be leakes via watchlist notifications (see T54453 and T199993).

(Other ways I can imagine to access private wiki's contents includes bot passwords and owner-only OAuth clients, but they are much more edge case.)

Noting that this should be requested some time in advance per https://meta.wikimedia.org/wiki/Mass_account_creation#Requesting_temporary_lift_of_IP_cap unless you can find someone who can deal with it on short notice.

Please fill out the form and re-open the task if this wasn’t a test edit.

Seems like a duplicate of T404898: IPInfo shows an incorrect number of edits on Special:IPContributions

Considering that the TA creation limit has been severely restricted in December 2025 I agree that such an abuse filter variable is no longer useful.

Fixed per backport in T432316

Fixed per backport in T432316

Looks like a duplicate of T432316: Print/export section missing in 1.47.0-wmf.11 – both "print/export" and "in other projects" are missing in Vector 2022 in group 0 and group 1 projects.

In T101841#12125680, @ssastry wrote:

So, the only thing left here is a product decision: Do we want to do this?

Turns out there's a difference if you turn off the UserInfoCard – but without it the links (talk | contribs | block) are misplaced in a different way (in all changes, not just log entries).

In T197137#12112551, @Od1n wrote:

I'd like to add a bit of perspective here as an aside.

This ticket was opened in 2018, and in practice nothing here was ever actually exploited until a single, unique 2026 incident — caused by one person who went as far as executing thousands of scripts without any verification. The scale of discussion this ticket has generated feels disproportionate to what we have seen on the ground: we're mostly debating a hypothetical, not a widespread or common attack pattern. That should tip the balance toward avoiding friction that is, ultimately, largely unnecessary.

I don't think that's correct, there have been exploits of accounts with extended permissions due to (user) JS by malicious actors in previous years. Due to some lucky coincidences those incidences were quickly contained, but we shouldn't rely on luck, requiring reauthentication certainly makes it harder for attackers to achieve their goal.

In T307488#12112206, @Mathglot wrote:

Johannnes89 wrote:

I don't think the renamed task title (and your changes to the task description) reflect what's requested by volunteers from different wikis: We want a simple way to remove an account from mentoring without assigning them to another mentor.

If that is what is requested by different wikis (links, please),

• The original task description said: "There is a way for mentees to opt-out their mentor, but there is no way for mentors to stop mentoring someone not nice. As a volunteer, I encounter this problem. What if a fellow mentor doesn't want to take my mentee away from me?"
• The link in T307488#10891047 points to a similar request on frwiki.
• The dewiki case with a juvenile mentor feeling uncomfortable due to his mentees questions was discussed in a private Discord channel (it prompted me to subscribe to this ticket in April 2024).

In T307488#12109976, @KStoller-WMF wrote:

I added some clearer acceptance criteria. Is this closer to what you were thinking?

However, I'm not sure this is a task we can work on any time soon. It seems like it could get complex and is really only helpful in a small number of edge cases.

In T431159#12105438, @Samwalton9-WMF wrote:

In T431159#12105426, @Ladsgroup wrote:

It works just fine for me o.O. It timed out before the clean up but not anymore.

Hmm. It loads in a logged-out private window but times out when I'm logged in to an account. Tested on two different accounts, and using safemode.

Seems like this specifically affects the Reference Tooltips gadget (which is enabled by default on English Wikipedia and some other wikis). There's no issue when using Reference Previews, perhaps the gadget needs an update?

Slightly off-topic, but does https://www.mediawiki.org/wiki/Readers/Reader_Growth/Image_Browsing have an effect of the image limit? (@egardner fyi).
I checked https://en.wikipedia.org/wiki/List_of_national_flags_by_design on my phone and it seems the carousel shows at least 100+ images (I stopped counting afterwards, the actual number is probably 200-300 images) which would heavily limit the number of images editors can show in the list itself if all of them are counted twice...

+1, we're currently using an AbuseFilter for that purpose on German Wikipedia -> T242541#9527407

https://simple.wikipedia.org/wiki/Special:RecentChanges?goodfaith=verylikelybad&hidebots=1&hidecategorization=1&hideWikibase=1&limit=50&days=3&damaging__maybebad_color=c3&damaging__likelybad_color=c4&damaging__verylikelybad_color=c5&urlversion=2 is timing out for me.

Probably related to recent changes in T404514: User name gets misplaced in mobile watchlist and recent changes?

Given that https://en.wikipedia.org/wiki/User:Cacycle/wikEd is no longer maintained and almost all of its features are available in the regular editor, the best solution is to just disable the gadget in https://en.wikipedia.org/wiki/Special:Preferences#mw-prefsection-gadgets

In T197137#12086638, Od1n wrote:

I just noticed that the reauth flow is no longer triggered when opening the edit page, but instead when clicking "Publish"; note that there was no indication on this ticket of this change (no reference to a Gerrit change), and it was only a comment above that tipped me off. This is a change in the right direction.

@mszwarc @HakanIST fyi could this be a regression caused by recent work on T424356: Rights log entries replicated from remote wiki have broken links / T6055: Interwiki rights logs should be duplicated at related wikis?