In T415237#11621530, @Bugreporter wrote:

See also: T39992#424332 - one of points to emphasis is if someone use etherpad to distribute illegal (e.g. child porn) content, we have no meaningful way to prevent so (no meaningful way to find either pad by content or recently changed pad, no meaningful way to block a user, and takedown needs sysadmin action and is thus not scalable for large scale abuse).

So, at least we should have change to another similar system or stop using this service at all.

In T415237#11613170, @Pppery wrote:

There are a bunch of pages using templates that dynamically generate etherpad URLs, which I still need to process.

Here are some various features this system would have that Structured Discussions does not:

Currently not, but could have.

In T415237#11607285, @jeremyb wrote:

idk how much of the problem is old stuff no longer needed vs. spam but if it would help oauth authenticating against a wiki shouldn't be too hard to do and I can work on that. (I figure authenticate for writes. reads can be anon.)

The integration with MediaWiki, like oauth or extension, could give chance do be able to do other operations to maintain Etherpad. Most important may be the button to export pad to MediaWiki, even with some history attributions.

Please send me copy of this database on drive to my home address.

This is generated in JS. Message used is Thanks-confirmation2. It is not parsed as wikitext. Should?

Patchset 3 test: https://10372bad21.catalyst.wmcloud.org/wiki/Special:PersonalDashboard

So, it would not break tools.

New changes also breaks. Like no IP Reveal buttons.

This should apply to all of these popups.

Regarding Tech News, I prefer to say it allows high traffic on other wikis than the local bot. The current phrase about not adding permissions is confusing about effects, even it is not about MediaWiki permissions.

In T409027#11585704, @Samwilson wrote:

"View watchlist" suggests I would see items on my watchlist. This is what is done on Edit Watchlist.

Maybe. But when people talk about opening their wachlist they mean Special:Watchlist, i.e. the "watchlist" is technically the list of watched pages, but people more commonly use the term to mean the list of recent changes to pages on their list of watched pages.

What label would you suggest instead?

Note other configurations and extensions. Test AbuseFilter reactions too.

TitleBlacklist checks account creations rather than edits (in the latter case, a temporary account has already been made for the user).

Creations of Named Accounts. We need this performer to create log. AbuseFilter uses this approach.

This is because temporary accounts do not have a username displayed

But we should display them on all skins, with the notice about what it is, like in vector-2022.

Now I know this happens when CodeMirror is enabled.

"View watchlist" suggests I would see items on my watchlist. This is what is done on Edit Watchlist.

What with unlabeled pages? Choosing all and excluding them is good idea or there should be easier option?

No API endpoints need be changed for this work (we think).

API "edit" has "watchlist" and "watchlistexpiry". Why not this? :)

There is no decision to stop using and undeploy.

Some use cases?
Maybe separate installation on Translatewiki would be better?

As a CampaignEvents Developer I want a list of these links to know if they are appropriately linked.

Find for addHelpLink.

At time of creation of this task there was no user-help page. Theres is now, we can link it.

Yes, it is MediaWiki:Allevents-helppage
Good idea.

Yes, random translated/translatable pages are OK. Tested on mediawikiwiki and testwiki.

In T415725#11563488, @brennen wrote:

I've seen it claimed that ?action=purge for a given page fixes the error, but @Lucas_Werkmeister_WMDE says not always, so maybe people are seeing a coincidence with something dropping out of cache?

Also

TypeError: MediaWiki\Extension\Translate\MessageGroupConfiguration\HookDefinedMessageGroupFactory::appendAutoloader(): Argument #1 ($additions) must be of type array, null given, called in /srv/mediawiki/php-1.46.0-wmf.13/extensions/Translate/src/MessageGroupConfiguration/HookDefinedMessageGroupFactory.php on line 60

Difference between user_type should be explained.

So, it is now not intended to be a shourcut? What with translations? See /qqq to check whether to update.

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

Can't reproduce as of today.

In T241691#5769742, @DannyS712 wrote:

The $oldContent created when getting content for revid -1 is:

PageContent::getContentForRevId

if ( $revId !== -1 ) {
	[...]
}
return $this->getContentHandler()->makeEmptyContent();

And that empty content's level is then checked for changes.

https://gitlab.wikimedia.org/toolforge-repos/yearinreview/-/commit/bcc494360fa9f61eafb5956ed70aab511a3558ab

@marrivs Do you still plan to work on it?

https://gitlab.wikimedia.org/toolforge-repos/yearinreview/-/blob/main/src/utils/backend_helper.js#L239
change to

Only solution is to change hook mailPasswordInternal to set additional property to new/reset action.

The auto-reveal may exhaust it, and if auto-reveal will have less limits, it may encourage to use it instead of manual check when needed so it will result in more IP displays.

In T412644#11463769, @Lorlam wrote:

Shall I report a new bug report to describe this ?

In T220764#6806614, @Daimona wrote:

The main problem with this addition is that these variables would be very large if the diff is also large, and the details view might be filled up.

This can be used, but not is not in core: https://meta.wikimedia.org/wiki/User:Msz2001/AbuseFilter_analyzer

This can be modified to do this: https://meta.wikimedia.org/wiki/User:Msz2001/AbuseFilter_analyzer

The problem was known here: https://commons.wikimedia.org/wiki/Commons:Village_pump/Archive/2013/12#c-McZusatz-2013-12-18T20:24:00.000Z-December_5_image_loss?

Can be "filter groups" used for this?

The use case of this change is also poorly documented.

Thanks for reporting!
And these words inside included messages are also depended on both the number and presence of word "last".

Because Catalyst does not update Patchdemo's tables.

So, the reason is not providing (or bad) context to Parser. Does Xml::buildForm support it?

Can't reproduce Badtitle in editing filter or on saving page edit when filter triggered on test wiki.
It seems you want to produce links to Wikipédia:Filtro_de_edições/NUMBER_OF_FILTER. Currently it would create link to Wikipédia:Filtro_de_edições/PAGE_WHERE_TRIGGERED if on editing some page and Wikipédia:Filtro_de_edições/MEDIAWIKI_MESSAGE on preview available on editing filter, but it is not intended format I guess (also not Wikipédia:Filtro_de_edições/Especial:Filtro de abusos/200).

All gadgets not loaded on editing, even if not affecting editor but enabled in preferences. Module registry is OK. Also not working on other sister projects.

In T406724#11264528, @Tgr wrote:

Is there a chance of a user preference row containing something unrecoverable (a secret key or such)? Should we maybe send emails to users who will be affected?

From gadgets?

Thanks, fixed.

Resulted in pt wikinews main page error.

FlaggedRevs styles not loading.

In T397103#10928139, @HCoplin-WMF wrote:

@Wargo -- do you have any additional information about the types or frequency of notifications that you're seeing repeat?

Mention. But only for 5 (for me) constant pages (edits); older actions do not trigger them. Every hour or null edit.

Yes

includes/MediaWikiEventIngress/PageEventIngress.php if ( $editResult == null ) {
I guess this can be left if there are situations when editResult object is not given, but the null edit itself needs to be [also] checked as previous: $editResult->isNullEdit().