Purge a page, open the visual editor and you'll see that it is now impossible to edit any red link. This task should be of high priority.

Looks like an easy fix? I think we just need to add the ordinal indicator to this regex so that it matches 1º and we're good to go. @TheDJ @matmarex can either of you take a quick look at this please?

Tool migrated

The tools I checked are "itwiki" and "omegabot". As for the issue, basically this is no longer working.

@Ladsgroup is a member of the community already. He even works closely with users from all projects, including enwiki checkusers. I can't find where he said that someone's ideas are "bogus", but I can clearly see the personal attacks directed at him and I agree with Martin that it's time to stop. This task is closed.

I've updated the lastmodifiedat message but I can't quite remember how I came up with that solution. Weirdly enough it does work though.

I handled the tasks in Python, hopefully everything works fine.

In T235589#7647440, @AlexisJazz wrote:

Are you saying it's impossible for "Pubblica esito" (or any other API call that does anything to the page) to run before the move? Did you just edit the page and initiate the move after the edit really really quickly?

In T235589#7644807, @AlexisJazz wrote:

Got a diff, or diff for a similar action with that gadget? I suspect the gadget edits the page and immediately after tries to move it.

Not sure about the usecase, but either submit should be equivalent to edit or it should load gadgets on action=submit only. Right now it's just being ignored unless edit is specified too.

I can't either. Guess somehow this is resolved.

As anonymus said, word-wrap is not supported by Chrome. The correct property would be word-break. Specifically, it looks like Chrome needs word-break: break-word.

I was about to report the same issue. The automatic edit conflict resolution is quite annoying indeed. This needs to be worked on.

I suggest this code:

Still not working since Tech news sections are now marked by the new static name "tech-newsletter-content". It would be great if it was the same as before, e.g. "technews-2021-W12".

Module:Graph has been updated on it.wiki, we should be fine now.

Section tags allow selective transclusion of text. For instance, enwiki community portal automatically transcludes the latest Tech News from https://en.wikipedia.org/wiki/Wikipedia:Tech_news.

Sorry, I don't know if it's relevant to this task but last Tech News were delivered without section tags. Was it just an oversight or is it one of the things left to do?

Can no longer prefill the mwProtect-reason input field. Prefilling the mwProtect-edit-expires input field populates both the fields with the same value instead.

A Venetian sysop explained me the reason here when they asked me to open this task. Basically, Venetian users believe English is easier to understand for those who live in Brazil and speak Venetian. The most active Venetian project affected by these changes is by far vec.wiki where the community comes together. I don't think we need anything else. If this is a mistake, they can still decide to revert it.

@MarcoAurelio yes, it is. I'm not sure about the redundancy though. I took MessagesIt.php as an example. By the way, thanks for the help.

These features need a consensus to be deployed. Local discussion is now ongoing.

I know that page, but this isn't a new feature request since, as has already been pointed out, that namespace doesn't work otherwise. Anyway, it doesn't matter now. Obviously, community consensus is unanimous.

I agree with Ruthven, a community discussion wasn't required here. This namespace is the equivalent to "Page" (104) on enwikisource or "Pagina" (108) on itwikisource. Subpages are enabled by default on those extra namespace IDs. It's not clear to me why the ID on napwikisource was set to 250. Maybe it'd be better to change it instead. But in any case, please don't forget to enable subpages in the associated talk namespace (251) as well.

I'm pretty sure your guess is right.

It keeps getting worse and worse. I remember that purging used to work, but not anymore.

The problem has been noticed on itwiki as well. Pre-wrap seems good to me.

Actually, the viewport goes always up to the top, then it is set back to where it was before the opening of MediaViewer. FireFox 70 still works like that just fine on MediaWiki 1.31 so it doesn't really seem a browser issue. Also, possibly it is useful to mention that on the current MediaWiki release both Firefox and Chrome return to the previous page when closing MediaViewer in fullscreen mode.

Isn't just $currentBlock->setBlocker( $performer ); missing in SpecialBlock.php?

Add it.wiki to the list. Probably, it's best to revert the last edits until you figure out a solution for what you're attempting to accomplish.

I believe the issue is solved. It hasn't happened to me in quite a while.

That's not good. For some reason now only the last visited page gets marked as read, then it gets back in bold as soon as I visit another one.

Still experiencing this annoying bug on it.wiki, although not as frequently as before.

Same issue I've reported in T217203#4988080. It seems this is happening from time to time. Some requests are processed slower than before, whereas some other are stuck at the beginning for a while. I've also noticed that the issue is not related to single requests at a time. For example, I could see up to 7 renames getting stuck until they all started together.

Please, notice that this rename (Rauman Kaupunginteatteri → Petteri Kangas) took about 20 minutes to complete. Even though it was approved at 12:52, every local account was still in queue according to rename progress special page. The rename actually started at around 13:05 when only fi.wiki was marked as done, and the process slowly ended in the next few minutes.

Feel free to lower priority, but probably we are losing a large amount of contributions from mobile users due to this bug.

Between yesterday and today, it happened to me twice on it.wiki, and both times I avoided the error as Amorymeltzer described.

Alright, so I guess it would be more appropriate to open a new task and request such a feature at a sysop level. Maybe @Tgr is interested since he already mentioned this in T24251#4021789.

Views are still dropping slowly but steadily. I believe generating a sitemap for the mobile site is worth a shot. Also, if a solution is not to be found, WMF should reconsider whether to keep encouraging such methods of protest or not. I fear they may become a double-edged sword, the effects of which could be tragic.

In T202331#4516717, @Framawiki wrote:

I see legal implications here - hideuser right allow to remove a username from a history page, thus remove author credit that is required by Wikipedia license.
Also, if I understand correctly your request, sysops will not be able to view action log that requires abusefilter-hidden-log right, only stewards will be able to do this. And they probably will not monitor abuses, that not the purpose of this group.

For the record, IP and registered users are still reporting this issue from mobile. I don't know how many links are involved, but the landing page is getting about 200.000 views per day...

Nevertheless, we cannot depend on third parties to take such important decisions as when to start and end a blackout. It is crucial for us to listen to many opinions as possible in order to proceed even at the very last time. Obviously, over the past few days that could not have been possible if we had to open a task and coordinate with someone else. It is fine to add restrictions, but communities must have the certainty to be able to act freely. Once the extension will be ready, before it gets installed we can open a discussion on it.wiki to decide whether to give the right to sysops or to a new, more trusted group.