In T415237#11612397, @Marostegui wrote:

In T415237#11611326, @Tkarcher wrote:

All pads will be permanently deleted after 30 April, 2026.

I still think this is the worst of all possible options: If there's really no way around a complete purge, you should at least move todays pads to etherpad-legacy.wikimedia.org asap and start a new instance on etherpad.wikimedia.org where people can create new pads not affected from this purge: There're a lot of events already planned for end of April / begin of May with pads being created and communicated in advance, which would all be gone instantly with no chance to back them up in time.

The point of this task and discussion is that maintaining a 233GB single-table database is an operational burden. Spinning up a read-only legacy instance doesn't reduce that burden it just moves it somewhere else. We'd still need a database server hosting that 233GB table, most likely the same and we'd now also need to maintain a separate etherpad application instance serving it. That's more infrastructure to maintain, not less, for a service we're already struggling to maintain.

In T394732#11610757, @Arendpieter wrote:

Has this resolved the issue? Is the script now working correctly? Could one of the CheckUsers or stewards please check it?

Something like T391543: Abusefilter: Request confirmation for making a filter public might already be an improvement

In T92795#11591421, @Bugreporter2 wrote:

How exactly does one "create ContentHandler delivery lists?" - can this be added to the task description? It's very vague.

Using Special:CreateMassMessageList – but mass message senders without admin permissions cannot use that page.

In T388718#11589592, @MGChecker wrote:

It seems the documentation aspect of this task has been thoroughly forgotten. I came across this accidentally, after being annoyed for a while by my impression that there is no such indication. That even in languages like German this message is not translated yet supports my impression it is basically unknown. If I see it correctly, T415153 is a duplicate of this task.

Stewards didn’t get GTAIV because it’s redundant to our steward permissions. But it turned out most of us still got the permissions once our local groups changed in a wiki where we hold CU/OS permissions (even when the group change was unrelated to CU/OS like in the example above) or when temporarily granting CU/OS permissions to ourselves to perform actions on a wiki without local CU/OS.
As of today there are just four stewards left without GTAIV https://meta.wikimedia.org/wiki/Special:GlobalUsers?username=&group=steward&limit=100

In T416080#11583286, @Mvolz wrote:

In T416080#11571730, @Johannnes89 wrote:

This doesn't seem to be limited to Safari or mobile browsers. Steps to replicate the issue (even in desktop browsers):

• Open any (enwiki) article in VisualEditor and use Citoid to automatically create a reference from any URL (e.g. https://www.bbc.com/sport/football/articles/cj6w3wr9x2lo)
• Observe that the wikitext output doesn't respect the parameter order (and the space between different parameters) defined in TemplateData of en:Template:Cite web

<ref>{{Cite web|title=Rafaela Pimenta talks transfer system, gender inequality and more|url=https://www.bbc.com/sport/football/articles/cj6w3wr9x2lo|website=BBC Sport|date=2026-02-01|access-date=2026-02-01|language=en-GB|first=Simon|last=Stone}}</ref>

• Switch to 2017 Wikitext editor and use Citoid to create the same citation
• Observe that the wikitext output matches the format defined in TemplateData

<ref>{{Cite web |last=Stone |first=Simon |date=2026-02-01 |title=Rafaela Pimenta talks transfer system, gender inequality and more |url=https://www.bbc.com/sport/football/articles/cj6w3wr9x2lo |access-date=2026-02-01 |website=BBC Sport |language=en-GB}}</ref>

Can you tell me which desktop browser you're using and ideally the version?

I've tried both Chrome and Firefox and I'm unable to replicate this using the 2010 editor.

In T397224#11576807, @matmarex wrote:

In T397224#11376026, @Johannnes89 wrote:

Another weird case: https://en.wikibooks.org/w/index.php?title=Special:Log&logid=5292619 caused https://en.wikibooks.org/wiki/Special:Log/gblrights even though the relevant local group (CU) wasn't even changed – and local admins shouldn't be able to do anything that affects global groups: All local/global group changes (CU/OS/GS) which trigger granting/removing GTAIV can only be done by stewards.

I suppose this is because the new global group was not initially populated with the users belonging to relevant local groups, so the change took effect the next time the local group membership was changed in any way?

seems like the issue occurs more often recently
https://de.wikipedia.org/wiki/Wikipedia:Technik/Werkstatt#Mouseover_Wikilink_Ferrari_P4/5_→_komische_Seitenvorschau_von_Actinium

Thanks! I just tested accessing Turnilo, everything works as expected :)

This doesn't seem to be limited to Safari or mobile browsers. Steps to replicate the issue (even in desktop browsers):

• Open any (enwiki) article in VisualEditor and use Citoid to automatically create a reference from any URL (e.g. https://www.bbc.com/sport/football/articles/cj6w3wr9x2lo)
• Observe that the wikitext output doesn't respect the parameter order (and the space between different parameters) defined in TemplateData of en:Template:Cite web

T413366: Content translation copied ref displayed as "undefined" is probably a duplicate?

That's intentional, there's even a warning: "On the English Wikipedia this tool is limited to extended confirmed editors, and the machine translation component is disabled for all users (see WP:CXT)."

The same issue also affects messages aimed at Temporary accounts, e.g. MediaWiki:Temp-user-banner-tooltip-description-learn-more or MediaWiki:Postedit-temp-created (@Niharika @Madalina fyi). Temporary accounts will always end up on the English version of mw:Special:MyLanguage/Help:Temporary accounts unless wikis create local versions of these messages (which is what I did following a complaint on dewiki) – but local overrides increase the risk of missing potential updates to the original messages.

This came up in multiple community discussions and should have higher priority in my opinion. Special:Statistics should at least indicate that it now includes logged out editors as well (which greatly inflates the numbers, especially when users delete their cookies...). Ideally TA should be excluded, just like IPs used to be.

• Wikipedia:Village pump (technical)#Statistics error?
• Wikipedia:Village pump (WMF)/Archive 13#Active users jump
• Wikipedia:Village pump (miscellaneous)/Archive 85#Weird increase in active users?

Due to my mistake https://gerrit.wikimedia.org/r/c/operations/puppet/+/1229200 refers to johannnes89 (there's no account with that name) instead of j89, that needs to be changed.

I'm very sorry I simply submitted the wrong username. Can't remember why but apparently I chose j89 years ago: https://ldap.toolforge.org/user/j89

@Eskivor did assigning ref groups in VisualEditor ever work in articles using {{Références|groupe=note}} instead of <references group="note" />? I don't think the behaviour is unexpected given how much VisualEditor struggles with templates – e.g. T350064: References defined in templates disappear or render differently in Edit mode compared to Read mode? Any way this is unrelated to Reference Previews.

Duplicate of T235346: Edits which has been reverted and revision deleted over 40 hours ago were visible on page previews?

https://de.wikipedia.org/wiki/Wikipedia:Fragen_zur_Wikipedia#Donald_Sutherland sounds like the same issue

Thanks for working on this task! I'm not yet part of the NDA group (https://ldap.toolforge.org/group/nda) as requested which is why I cannot access Turnilo so far.

In T290324#11539679, @MGChecker wrote:

Who is able to see the information that a certain filter is suppressed? I would suspect abusefilter-view to suffice, but maybe it is regulated differently?

In T414952#11535053, @Umherirrender wrote:

Why should this prevented? What is the idea behind it?

MediaWiki can handle the situation without 2FA enabled. For example the user account get new rights that require 2FA, the account can still edit, but not use the extra rights. So in general it is possible to hold rights that are not usable ("Disabled group").

When 2FA is compromised or lost it must be possible to disable or remove that 2FA from the account. Asking for removal of user rights may take to long.
There is no need to block the removal of the last 2FA, maybe add an extra warning that the user group get disabled or is no longer usable.

The general idea is to prevent users from only turning on 2FA when they want to use their interface admin permissions (or other rights which require 2FA). If 2FA "enforcement" just means disabling rights as long as 2FA is deactivated, malicious users could compromise a privileged account and then set up 2FA themselves...

In T414990#11534922, @Pppery wrote:

The fundamental principle of a wiki is that every change that can be done can also be undone. I don't see sufficient cause to break that principle here.

The proposal is identical to protected variables which also don't allow unprotecting the filter. But I'm open to alternative proposals on how to make sure not to accidentally leak PII in abuse logs...

In T414952#11534765, @mszwarc wrote:

In T414952#11534370, @Johannnes89 wrote:

I'm all in favour of those restrictions, but how should a user a user proceed if they need to temporarily disable 2FA before setting it up on a new devise?

Given that now it is possible to set up many 2FA methods, the proposed way to go is to first set up 2FA on the new device and then remove the old one, so that for the whole time the user has at least one 2FA method.

I'm not sure that's feasible in all situations, but I suppose a user could just ask for temporary removal of their permissions if a scenario occurs where they need to temporarily deactivate 2FA.

I'm all in favour of those restrictions, but how should a user a user proceed if they need to temporarily disable 2FA before setting it up on a new devise?

I believe the issue occurs when translating an article which uses {{reflist}} (or a local equivalent) instead of <references /> – presumably because ContentTranslate can't properly detect the references. I couldn't reproduce the bug in articles without such a template.

I can reproduce the issue:

• Open Special:ContentTranslation and start translating the enwiki article "2026 United States elections" to Slovenian https://sl.wikipedia.org/wiki/Special:ContentTranslation?from=en&to=sl&page=2026+United+States+elections
• Translate the first section including a reference using the default machine translation feature

• Notice that the reference gets correctly translated:

• Now translate a section with another reference and make sure the original reference is different from the first one:

• Notice how the footnote number has changed in the translation to [1] (instead of [2]) and the footnote shows exactly the same content as the first reference (which is now [undefined] instead of [1] but still shows the same content)

Indeed, "no results" would be wrong, there are results, but not everyone can see them.

In T414789#11530547, @KFrancis wrote:

Hi @Johannnes89 To process your volunteer NDA, I'll need your home mailing address and your personal email address. Please send that information to kfrancis@wikimedia.org. Thanks!

Seems like a Regression – the same issue occurred a couple of months ago T407549: [Regression] Temp accounts banner overlay blocks content on mobile and was fixed per QA in T407549#11287143 / F66758361

In T220769#11520617, @Arendpieter wrote:

In T220769#11519478, @Johannnes89 wrote:

Doesn't seem to be related to SUL3

I assumed that because T368230 was related to SUL3—after T363695 disabled CentralLogin on loginwiki—this would be as well.

Doesn't seem to be related to SUL3

In T241440#11515300, @JJMC89 wrote:

"there's no true global abusefilter that applies to all wikis". Is that still true?

yes

InitialiseSettings.php

'wmgUseGlobalAbuseFilters' => [
	// Enabled on all public sites, see T341159.
	'default' => false,
	'sul' => true,

	// Individual wiki overrides
	'enwiki' => false, // T341159
	'jawiki' => false, // T341159
],

In T290324#11514874, @Wargo wrote:

Note the Unsuppress will unhide all the logs. Should be warning somewhere or the logs until unflag should stay hidden?

The same issue exists with public vs. private filters (and local vs. global ones). Hypothetically speaking you could set up a filter to log every edit… I don’t think it’s a huge issue if abuse filters with a lower protection level catch the same edit because their log entries won’t indicate that there’s sensitive content.

In T414011#11501812, @MolecularPilot wrote:

Therefore, the only way that I can see to fix this without the need for a database schema change is to do the same as protected filters and make it impossible to undo the setting of a filter as suppressed. @MolecularPilot, what do you think about this idea?

That could work. Another idea I had is there's already a flag to manually suppress an individual log entry I believe, so we can set this flag on any log entry generated while a filter is suppressed, meaning if the filter is unsuppressed the logs remain suppressed and need manual unsuppression if desired for any reason. Though it might be tricky to backdate this to any logs created between now (when the feature is live) and whenever this patch lands, so I'm leaning towards thinking it's best to make it impossible to unsuppress. I can write a patch for that if we think that's the best way forward and you'd like.

Just to make sure this doesn't get overlooked – it's not just about fixing who can edit the filter:

Removing the suppressed checkbox (no matter if oversighters do this intentionally or if it happens via this bug) should never automatically unsuppress previously suppressed abuse logs – they might still contain PII

that's also useful on talk pages which now display the show IP button next to TA signatures – there's quite a lot of additional text if the revealed IP is an IPv6...

That's not specific to the android app, the citations in https://cdo.wikipedia.org/wiki/Dá̤_(nguòng-só) didn't appear in desktop and mobile browsers as well.

In T377771#11492206, @Tamzin wrote:

The way TAs are implemented already means that someone can't appeal a block through normal channels if they haven't already created a TA on that client pre-block, which artificially decreases the base rate of appeals

Not sure if that's different on non-Wikimedia wikis but Special:ListUsers doesn't show any global groups on WMF wikis, no matter if the assigned global group is permanent or temporary? That's why Special:GlobalUsers exists.

In T413216#11491225, @Tchanders wrote:

Thanks @STran

In T413216#11480994, @STran wrote:

Without doing additional prep work:

• Talk pages will always be blue, as there won't be an external check to see if the talk page exists
• Contribs won't support redContribsWhenNoEdits (UserRights sets this to false so it's no difference in this use case

I think this is fine - seems better to have a wrongly-coloured link than no link.

Agree.

Block and Send Email do checks on the local wiki which I would prefer not to check on the external wiki as this adds an API call. If this is the case, then should these links always be shown? Or never shown?

We could remove these, perhaps. @Johannnes89 Do you find these links particularly useful when editing the groups of a user at an external wiki?

I've never used block and email links via Special:UserRights. meta:Special:UserRights already doesn't show those links, instead there are talk, contribs, membership in global groups – different to en:Special:UserRights and other wikis (talk, contribs, block, send email).

Probably just random search results from https://search.crossref.org/search/works? (see e.g. T382446: Return >1 results from search in citoid service in the absence of a url, doi, isbn or pmcid/pmid / T413679: Revise Citoid “Automatic” tab UX to clarify text input performs a search, not a definitive lookup)

Glad you were able to fix it :)

Everything works as intended if you use https://atj.wikipedia.org/wiki/Otitikowin?safemode=1 which makes me believe that https://atj.wikipedia.org/wiki/MediaWiki:Common.css is responsible for the issue.

I don't see the issue MediaWiki is transparent by design – https://meta.wikimedia.org/wiki/Special:UserRights works just like https://meta.wikimedia.org/wiki/Special:CentralAuth or https://meta.wikimedia.org/wiki/Special:ListUsers

Is the default mentioned at https://www.mediawiki.org/wiki/Manual:$wgTempAccountCreationThrottle still correct or should the documentation page be updated with the newly introduced limits?

https://de.wikipedia.org/wiki/Spezial:Beiträge/~2025-42582-52 might be related – IP is unavailable for the second revision (and therefore no IP info as well)

The specific issue reported in this ticket appears to be fixed, ULS works in VisualEditor and Wikitext 2017 editor. It doesn't work when using the regular wikitext editor (T391512) and when switching from regular wikitext editor to VisualEditor (because the page is not reloaded and the buttons already disappeared -> T413536)

That's only true for Wiktionary and Wikisource per https://en.wikipedia.org/wiki/MOS:INTERWIKI – and other projects are even more restrictive and prohibit any interwiki links in the article body (except for sections like "external links"), e.g. https://de.wikipedia.org/wiki/Wikipedia:Verlinken#ANR or https://pt.wikipedia.org/wiki/WP:NOIW. And if projects allow interwiki links in certain circumstances, they should be formatted like that instead of using the external link format.

We shouldn't allow newcomer users to insert content while already indicating that they don't have a source for it. In that case they shouldn't add new content (unless it's common knowledge, but in that case {{citation needed}} would be wrong as well).

In T410164#11459368, @PBradley-WMF wrote:

Re. 2. (@SToyofuku-WMF @Etonkovidova): correct, the specification doc was just noting that a sidebar Contacts link was an existing feature on those wikis, but we are not affecting those with this project. The local community is free to keep a link like that (or even better, they could update the community page it points to, so that it mentions our new link).

I was unaware of T389939: Wikimedia footer links that use Special:MyLanguage should also use `?uselang=` - let's hope that gets resolved, since indeed, it's not great UX, especially for the various legal links in the footer (terms of use, privacy policy, etc)

Does this happen with any page (no matter the page size)? Did you check if you're using a script / gadget or a browser extension which might cause the issue? -> https://www.mediawiki.org/wiki/Help:Locating_broken_scripts

sounds similar to T330602: Special:CreateLocalAccount should comply with user's block-bypass permissions which got resolved by fixing T189362: ipblock-exempt does not allow account creation when blocked – seems like IPBE gets ignored again

Another report: https://www.mediawiki.org/wiki/Talk:Product_Safety_and_Integrity/Anti-abuse_signals/hCaptcha#hCaptcha_does_not_show

I don't think this is worth a Tech News entry. Others might disagree (perhaps @doctaxon who added the user-notice tag?) but I would still consider this a "limited-scale incident" -> https://meta.wikimedia.org/wiki/Tech/News/For_contributors#What_is_typically_not_included

https://www.mediawiki.org/wiki/Trust_and_Safety_Product/Temporary_Accounts/Repository lists several user scripts which might help distinguishing different TA.