Could this possibly turn out to be a solution for the issue described at T119366?

Ok, more on this from trwiki. The right move works for Autoconfirmed, but movestable doesn't, even though the User Group Rights special page lists this right as a part of the Autoconfirmed bundle. The fact that the group Patroller can move the stable pages even though the only extra right they have is movefile leads me to think that movestable and movefile now behave as a bundle for some reason. This is merely a speculation of course. Looking forward to the input of the devs.

I'm going to go ahead and raise the priority to High, because restriction of the right to move articles to a select few -- in our case, only those who seem to have the movefile right -- at a project (or projects) this size is not a minor issue.

Same problem at trwiki. Autoconfirmed users should be able to move pages, but currently members of the Autoconfirmed or Autoreview groups cannot move pages, unless the page is in the User namespace. We merged the Editor user group with the Patroller group, so right now only the members of the Patroller group -- or admins -- can move pages, even though the only relevant right patrollers hold is movefile. The UserGroupRights special page does not indicate any changes to the rights these groups contain, so I am guessing this is a bug of some sort.

Similar sentiments expressed here.

Do we have an ETA on this?

Thanks, Aaron. Congrats on the baby btw!

In T154116#6602331, @Elitre wrote:

According to Runa, "It seems like a momentary problem with parsoid. We will keep watch for any repeats. Usually, in such scenarios, people can try again and publish soon after."

The issue has been reported again for a translation of the enwiki article on Ruslan Abışov into Turkish.

Thank you @matmarex , this makes sense.

Hi, I don't know if it is relevant, but the tool has just wrapped a comment that I was responding to inside the <nowiki> tag. Here is the diff. Obviously I did not have direct editing access to the said comment while I was typing my reply.

Apparently this issue has not been fully resolved, as a fellow trwiki user has informed me that he encountered the issue while trying to translate the enwiki article on Makhmud Esambayev and the said error was displayed when he tried to publish the translation.

No, it hasn't been resolved. It has only shifted to the right. See the following image:

In T265402#6548933, @Gomdoli4696 wrote:

https://tr.m.wikipedia.org/w/index.php?title=%C3%96zel:MobileDiff/23782154

This is works normally.

@Uncitoyen has reported that it also happens at trwiki. The diff button on Special:RecentChanges provides an URL in the following form:

@Halfak , have you been able to get to this one?

Thanks Martin.

We currently use many shortcuts based on these aliases, and they have been kept on the main namespace until now. Since it is not possible to access a page like WP:XX at enwiki without being redirected to Wikipedia:XX, I am wondering if these shortcuts need to moved to their respective namespaces (i.e.: VP:XX -> Vikipedi:XX) before the implementation. Please let me know if this is the case.

Let me elaborate on the steps to reproduce the problem.

I can still reproduce the problem at frwiki (and all the other ones).

Ok, here is something that might be helpful. When I "select all" at enwiki in New Vector, I see the following:

Hi @Aklapper , yes, I was referring to the line wrap, but since you mention it yourself, I guess that is intended. Let me have another go with the actual problem that I was trying to point to in the second part of my post:

Thank you @Urbanecm . I was able to confirm that only two pages from last month appear on Google and both had the localized behavior switch in question. I have now created https://tr.wikipedia.org/wiki/%C3%96zel:%C4%B0stismarS%C3%BCzgeci/89, so hopefully it will not happen again.

It seems to be working only partially. It has been brought to my attention that many sandbox pages are being indexed by Google, raising concerns of self-promotion by the community. This even includes a page that was created today, which has now been deleted (google: Kullanıcı:Muhammetemreaydinofficial/deneme tahtası). Try googling the words "kullanıcı deneme tahtası vikipedi" without the quotation markers and you will get many hits for sandbox pages in the user namespace. Some main user pages would also be in there. They all have the meta tag that @Urbanecm refers to above, so I don't know what's causing this.

Indeed. The Patroller user group at trwiki is a combination of 1) the original Patroller user group (introduced by Extension:Patroller), 2) the Editor user group (introduced by Extension:FlaggedRevs), and 3) the rollback right. So, they are certainly trustworthy.

Following extensive tests conducted with @Evrifaessa we've come to realize that the problem is due to the global version of the MoreMenu script. I will be contacting @MusikAnimal on-wiki about this.

Second alternative: Try an article with pending changes from https://tr.wikipedia.org/wiki/%C3%96zel:BekleyenDe%C4%9Fi%C5%9Fiklikler.

If you can't replicate the issue, please de-activate the Legacy Vector view and try again.

We are actively trying to develop a counter-vandalism bot at the moment, so it would be of tremendous help to us if this task could be given some precedence / priority in the backlog.

Will create a new ticket for the faulty autopromotion issue.

Also apparent in trwiki and enwikibooks.

Thank you, @RobH. I have just the one that I use across-the-board. Please see https://lists.wikimedia.org/mailman/listinfo/wikimedia-tr for both of our addresses, listed as admin accounts of the respective mailing list.

Here is a more concrete example. Please see https://tr.wikipedia.org/w/index.php?title=%C3%96zel%3AT%C3%BCm%C4%B0letiler&prefix=group-autoreviewer-member+&filter=modified&lang=tr&limit=50.

Would it be too much trouble to fix this somehow or should I just let it go?

@Deskana: The MediaWiki page I mentioned above is still under the name of https://tr.wikipedia.org/wiki/MediaWiki:%C4%B0pboptions. Is this something we should be concerned about?

Oh right, sorry. Which action did trigger the account creation then?

I'm delighted to report that the patch has fixed the problem. I've successfully managed to have the account block me while not logged-in. Thank you, @Legoktm.

It happened when we enabled block for a vandalism filter, and @Mavrikant triggered it (while logged-out) with a test edit. If you need us to reproduce it for testing purposes, just say the word.

The blocking feature of AbuseFilter does not work due to this problem, and we're under constant attack from our notorious vandal. I'd appreciate it if this could be treated a high-priority task.

It works: https://tr.wikiquote.org/wiki/%C3%96zel:Katk%C4%B1lar/New_user_message I will bug the active sysop for the in-wiki configuration.

I'm on it. Thank you, Dereckson.

Thank you for your understanding.

Ok, Sébastien. Please provide assurances that you will be able to handle this if we have a new discussion and re-establish consensus, and I shall oblige. But if this will only re-initiate the "figuring out" phase and you will need a third consensus by the time the phase in question is done, I think it would be a massive waste of time on our end. Wouldn't you agree?

No, that's your opinion. There is community consensus (a strong one at that) for this, but somehow noone has been able to implement this. We have been talking about this for years and wondering why it has not been implemented yet. Please respect the community's decision and implement this, or let someone else do it instead of brushing us off. I am perfectly aware of what the community wants, and I shouldn't be flogging a dead horse just because noone has been able to do this yet.

Is this being currently worked on? If not, can we revive this? We'd be delighted if this could be handled some time soon. No autopromotions have been observed since 2013.

Let me report something that I think may be related. I recently realized that we have both of the following pages at trwiki:

You can go ahead and do this, since it does not change anything locally. The majority of our technicians are on breaks anyway. HakanIST and I would take care of the interface messages within minutes.