Wed, Feb 17
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.
Dec 22 2020
Sep 11 2020
Jul 31 2020
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.
Jul 18 2020
Jul 16 2020
@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.
Jul 11 2020
Jun 22 2020
Jun 21 2020
Jun 19 2020
Jun 14 2020
These features need a consensus to be deployed. Local discussion is now ongoing.
Jun 8 2020
Jun 5 2020
May 15 2020
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.
May 14 2020
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.
May 9 2020
May 6 2020
May 1 2020
Apr 5 2020
I'm pretty sure your guess is right.
Mar 18 2020
It keeps getting worse and worse. I remember that purging used to work, but not anymore.
Feb 4 2020
Jan 31 2020
The problem has been noticed on itwiki as well. Pre-wrap seems good to me.
Oct 30 2019
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.
Oct 25 2019
Isn't just $currentBlock->setBlocker( $performer ); missing in SpecialBlock.php?
Sep 30 2019
Sep 20 2019
Aug 9 2019
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.
Jul 24 2019
I believe the issue is solved. It hasn't happened to me in quite a while.
May 23 2019
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.
Apr 29 2019
Still experiencing this annoying bug on it.wiki, although not as frequently as before.
Mar 5 2019
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.
Feb 27 2019
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.
Feb 2 2019
Feel free to lower priority, but probably we are losing a large amount of contributions from mobile users due to this bug.
Jan 22 2019
Jan 11 2019
Between yesterday and today, it happened to me twice on it.wiki, and both times I avoided the error as Amorymeltzer described.
Aug 21 2018
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.
Aug 20 2018
Jul 24 2018
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...
Jul 6 2018
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.