I'll book a deployment window in the morning so I don't get confused over DST/UTC.

Creating patchset..

In T248734#6007640, @HastaLaVi2 wrote:

@RhinosF1, yes. Everything should be the same. They will be used exactly in the same patterns on Turkish Wiktionary as well. Thanks!

See https://gerrit.wikimedia.org/r/plugins/gitiles/operations/mediawiki-config/+/master/wmf-config/InitialiseSettings.php#10620 for enwikt setup and https://gerrit.wikimedia.org/r/plugins/gitiles/operations/mediawiki-config/+/master/wmf-config/InitialiseSettings.php#10843 for trwikt

Hey, I’ll look at this tonight.

In T248554#6005237, @Petrb wrote:

ha, seems this was forgotten during migration to new server

Hey, Thanks for creating this!

We found a bug in our code and fixed this.

In T248487#5999038, @CyberTroopers wrote:

One of admin had adviced me that 10 voters might not guaranteed this task. I think it is much better if I continue the consensus process again. And once we have done, to whom should I contact? ;)

In T248487#5999014, @CyberTroopers wrote:

Thank you for your attention about this. Regarding these condition:

1. The wiki is prepared to handle drafts in a timely manner

:What kind of draft did you actually say? I hope you can precise it.

Draft articles from IPs that would go through a AFC-like process

2. The wiki has a well developed and editing and administrative community

:I would say most of editing in Malay Wikipedia is very active. As what is shown the activity today based on this statistic, https://ms.wikiscan.org/date/20200325/stats we have a total of 331 user who edits in Malay wikipedia including sysops.

3. The wiki should have ‘unusually broad’ consensus for the change.

: We have set up the consensus for >5 months and iclude announcement at the notice site. We also did announcement to reach up all users in Malay Wikipedia. As you can see, we have majority vote to remove this right. It's just forbid ip user from creating articles not from editing. So, wikipedia is still free knowledge for everyone. It's one of ways to control the quality of Wikipedia contents as well. I hope system adminstartor can consider this task. Thank you!

We would expect high turnout at these votes. 10 people isn’t that high.

Updated per someone who can read the actual doscussion

We also count 9 support, 1 oppose so we need a bit more of a consensus.

Blocking on SRE, per https://meta.miraheze.org/wiki/Special:GlobalRenameRequest

In T41510#5997433, @JarrahTree wrote:

Large watchlist - I have been unable to edit in any way - have tried many times and ways
[XnsCjwpAIHwAA8yh7zsAAAAP] 2020-03-25 07:05:47: Fatal exception of type "WMFTimeoutException"
a simple courtesy of indicating that if watchlists go over a certain size that they are not possible to manage, it would really be very helpful..

In T222533#5860651, @Jdforrester-WMF wrote:

If this is just an interface text change, it's presumably not blocked by the feature work on T223315 and can be uncoupled?

Yes?

@Johan: Tagged for User-notice. This isn’t due to go in soon but there’s no objection to announcing it’s happening and then when it’s done.

In T248411#5996254, @Jidanni wrote:

Upon first arrival at e.g., Special:ManageWiki/settings... but that is Miraheze specific... but they say it is a MediaWiki bug. So I don't know what to say.

Please expand on the bug description so developers don’t have to go following links to work out what’s wrong

In T248311#5994592, @Amire80 wrote:

Thank you! :) ☮️ ❤️

Is an issue with my preferences. Works, Deployed!

Debugging a weird issue with it not working for me logged in, will close later

Will resolve when deployed.

In T248311#5994501, @Zoranzoki21 wrote:

Patch merged! Closing task as resolved.

In T72#5994229, @Mhurd wrote:

I set the url wrong when testing the bot - apologies.

Scheduled for SWAT Deployment: swat-2020-03-24-eu @ 11:00 UTC Tue, Mar 24

Should be able to do this tonight. Spoke with James to go through all the steps.

Prep work all done in https://github.com/Pix1234/ZppixBot-Source/pull/128

I'm now creating a branch with all the changes on. This should not be merged until upstream merge their prep.

In T248112#5984980, @Ammarpad wrote:

In T248112#5984971, @RhinosF1 wrote:

In T248112#5984969, @Ammarpad wrote:

This does not belong to core. I have added comment on Gerrit. Probably the wiki where you saw this is misconfigured

I’ve seen it used on wikis and definitely not a misconfiguration.

Yes, the wikis are misusing $wgRestrictionTypes by adding protect and getting insane recursive loop of protect a protect action against a protect right in page protection.

insane recursive loop?

In T248112#5984969, @Ammarpad wrote:

This does not belong to core. I have added comment on Gerrit. Probably the wiki where you saw this is misconfigured

I’ve seen it used on wikis and definitely not a misconfiguration.

In T248112#5984959, @DannyS712 wrote:

In T248112#5984958, @RhinosF1 wrote:

In T248112#5984957, @Reedy wrote:

It is in core, yes
I have to wonder what other "actions" that might be useable/listed?

Delete & protect are the non defaults

"It is possible to add additional actions which can't be restricted by default" - whatever adds these should define the messages. Enwiki adds a custom user group extendedconfirmed, but the messages for it aren't in core, because the messages are only needed as a result of extending the functionality. Unless core is going to officially support protecting against protection or deletion, it shouldn't define the messages

In T248112#5984957, @Reedy wrote:

It is in core, yes
I have to wonder what other "actions" that might be useable/listed?

In T248112#5984952, @DannyS712 wrote:

In T248112#5984736, @RhinosF1 wrote:

In T248112#5984716, @Ammarpad wrote:

Where is the message being used?

I spotted it on PageInformation on a wiki that use protection restriction levels. Likely a few more places though.

Whatever extension allows this should define the messages, not core

The option is part of the core config ‘$wgRestrictionTypes’ rather than an extension afaik.

In T248112#5984939, @Reedy wrote:

Ok, so I see the problem. It's not a default one in MW core - https://github.com/wikimedia/mediawiki/blob/7a4df9b/includes/DefaultSettings.php#L5314-L5321

Correct, it’s not default.

/**
 * Set of available actions that can be restricted via action=protect
 * You probably shouldn't change this.
 * Translated through restriction-* messages.
 * Title::getRestrictionTypes() will remove restrictions that are not
 * applicable to a specific title (create and upload)
 */
$wgRestrictionTypes = [ 'create', 'edit', 'move', 'upload' ];

So this isn't actually a core but, unless $wgRestrictionTypes should have protect by default? Protecting a page to limit protecting.. seems very meta and recursive
It's also not listed in the grep friendly comment https://github.com/wikimedia/mediawiki/blob/4147bd8/includes/specials/SpecialProtectedpages.php#L145

		// First pass to load the log names
		foreach ( Title::getFilteredRestrictionTypes( true ) as $type ) {
			// Messages: restriction-edit, restriction-move, restriction-create, restriction-upload
			$text = $this->msg( "restriction-$type" )->text();
			$m[$text] = $type;
		}

Is there an actual use case, or is this just someone adding it erroneously to whichever wiki (config) you were looking at?

The use case is people who have people other than admins allowed to protect things and and want to restrict which groups can protect a page.

In T248112#5984916, @Reedy wrote:

It might be useful to backport to 1.31 and 1.33 too, depending on when it was starting to be used

Sounds good to me, didn’t check when it started being used. Just 1.34+ as that’s where I spotted the bug.

In T248112#5984716, @Ammarpad wrote:

Where is the message being used?

Replaced with https://tools.wmflabs.org/phpcs/missing

Use phab.wmflabs.org for testing.

In T247714#5970842, @Reedy wrote:

Where is "Add links"?

In T247706#5970722, @Reedy wrote:

In T247706#5970717, @RhinosF1 wrote:

I can’t find the task but I think the twice weekly cron has stopped working.

They should be running fine, as per T243599, fixed since https://phabricator.wikimedia.org/rOPUP1606b13af84e237f2aeb68e86dc46998d6f9dd62 in early March

My bad! Must have missed that.

The following data is cached, and was last updated 15:55, 13 March 2020.

This is pretty recent. Is there any reason we can't just wait for the next run of the relevant cron job?

I can’t find the task but I think the twice weekly cron has stopped working.

https://groups.google.com/a/wikimedia.org/forum/m/#!topic/sitereq-l/deL2yHN7sCs is the sitereq-l discussion.