Resolved now on extension level, should also be resolved on Wikimedia upon next message update.

In T270854#7074330, @Amire80 wrote:

Maybe: The latest {{PLURAL:$1|version of this page|version of each of these pages}} has been marked for translation. ?

In T260140#6393512, @thiemowmde wrote:

Just keep Project:Licensing as it is.

In T92795#6079008, @Xaosflux wrote:

So this is still stalled on idealistic concerns? @Vogone "I believe this restriction is harmful. It forbids users requesting a mass message delivery for their project to take advantage of this formatting option." ? My suggestion was that people that can send mass messages should be allowed to create mass message lists, and that is an improvement over the current state. How is making it incrementally better worse off then just blocking action? Additionally, any project could just add the editcontentmodel right to the 'users' group if they really wanted anyone to be able to just edit any content model. I'm even open to making a permission for Special:CreateMassMessageList, and a project could give it to mass-message-senders, or even 'users' if they really wanted to.

@Urbanecm Yes, it is. I have also quickly added dewiki and ruwiki as import sources after an administrator has shown me templates which are to be imported. Thanks for pointing out the WIP status!

The described issue still persists, even with the same example as provided in the task description.

In T92795#5352317, @DannyS712 wrote:

The gerrit patch was objected to by @Vogone, who hasn't responded yet to Xaosflux's question above

In T202625#5344657, @Legoktm wrote:

Per bawolff, this isn't really suitable for a user preference, sorry. Plus with UrlShortener, it would defeat the point of the whitelist since people could just shorten https://en.wikipedia.org/wiki/google:foo

In T92795#5245358, @DannyS712 wrote:

only users with the "editcontentmodel" right can create new mass message lists

I a

Thanks a lot for investigating the issue!

In T203335#4753662, @gerritbot wrote:

Change 474181 had a related patch set uploaded (by Greta WMDE; owner: Greta Doçi):
[mediawiki/extensions/WikibaseLexeme@master] I changed the lowercase into uppercase of Lexeme/Form/Sense/Item

https://gerrit.wikimedia.org/r/474181

Sorry, I had not seen this task, only the fact that "item" was mostly lower case and the WikibaseLexeme entity types mostly upper case. I decided to make them all lower case because that reflects natural language, and obviously a decision for upper case pseudo-proper names would get lost in translation, anyway.

In T202597#4527510, @Xaosflux wrote:

@Vogone, this could be re titled - unless you want to build a community consensus on metawiki for changing their group only - I think in the discussion so far we've identified that this is really a "global" problem that could be fixed a few ways.

In T202625#4527067, @Bawolff wrote:

Yes its anti-phising. e.g. Someone giving a link to https://en.wikipedia.org/wiki/somewhereevil:Foo making it look like a wikipedia link in an email ( https://cwe.mitre.org/data/definitions/601.html )

In T202625#4527067, @Bawolff wrote:

In T202625#4527047, @Vogone wrote:

Are you sure there is a real security concern for users who explicitly disable the splash page only for themselves? For example, normal external links don't need to a splash page either. The main reason for this being introduced seem to be "phishing" concerns which mostly affect users who are not familiar with the interwiki system, I would assume.

Yes its anti-phising. e.g. Someone giving a link to https://en.wikipedia.org/wiki/somewhereevil:Foo making it look like a wikipedia link in an email ( https://cwe.mitre.org/data/definitions/601.html )

This is not a high severity issue by any means - if it was really annoying I'd be open to having a preference (Although in principle I dislike preferences for security features. Its often users who don't think it can happen to them who are the one's who end up being tricked. I also think this is a very specialized usecase to make a preference for). Maybe we could use a user-script for this?

Are you sure there is a real security concern for users who explicitly disable the splash page only for themselves? For example, normal external links don't need to a splash page either. The main reason for this being introduced seem to be "phishing" concerns which mostly affect users who are not familiar with the interwiki system, I would assume.

In T202597#4526274, @MarcoAurelio wrote:

@Vogone If you're using the new UI (PolyGerrit) you can't edit patches. Switch to the old UI (there should be a link at the footer of the page) then go to the patch and you'll see an Edit button on the patch that'll let you edit, add, rename and remove files. Then Done editting and Publish edit (at the top} and you're all set. When you think the patch is ready for review hit Start Review so it appears on people's review dashboards. Let me know if I can help. Regards.

In T202597#4525853, @gerritbot wrote:

Change 454762 had a related patch set uploaded (by Vogone; owner: Vogone):
[operations/mediawiki-config@master] This change adds the permission 'editcontentmodel' to the 'massmessage-senders' user group on metawiki. The change will allow 'massmessage-senders' on metawiki to use Special:CreateMassMessageList.

https://gerrit.wikimedia.org/r/454762

Started community discussion at https://meta.wikimedia.org/wiki/Meta:Babel#'editcontentmodel'_permission_for_'massmessage-senders'.

In T202597#4525596, @Xaosflux wrote:

This is not an "error" it is by design. Simply being able to use the massmessage extension doesn't require changing content models.

As to why I called it a "hack": I created this redirect by importing the redirect from metawiki which is obviously a rather unusual way of creating pages in the wikidatawiki ns0.

If I remember correctly, I was asked by Lydia to delete this because the WMDE developers had some technical concerns due to ns0 being the item namespace. But since this is almost 5 years ago by now, my memory could be wrong.

Sorry, I meant <listname>-join@… as per http://www.list.org/mailman-member/node13.html.

Although the idea sounds nice I believe it would not prevent all bot-generated subscription requests since sending a <listname>-request@lists.wikimedia.org mail as well causes a subscription request.

In fact, this is exactly the "side-effect" described in LFaraone's initial commit. This means we need a solution which works for both, users with only 'deleterevision' and those with only 'deletedhistory'.

In T128914#3342706, @Legoktm wrote:

In T128914#3337294, @Vogone wrote:

This change broke the accessibility of Special:RevisionDelete to ombudsmen which causes quite some trouble. I would suggest to revert this change and look for another way to solve this bug.

I've read this discussion again, and maybe I'm missing it, but could you clarify what accessibility was broken? AIUI you have deletedhistory & deletedtext rights. What functionality do you expect to have that is currently missing?

I'm sorry if this may sound a little impolite, but is it really so hard to check Special:GlobalGroupPermissions (https://meta.wikimedia.org/wiki/Special:GlobalGroupPermissions)? FWIW, I am an ombudsman myself and should probably know which technical access I have.

In T128914#3337515, @Huji wrote:

In T128914#3337491, @Vogone wrote:

In T128914#3337478, @Huji wrote:

In T128914#3337294, @Vogone wrote:

In T128914#2091895, @gerritbot wrote:

Change 275268 had a related patch set uploaded (by LFaraone):
Allow users with deleterevision but not deletedhistory to delete revisions

https://gerrit.wikimedia.org/r/275268

This change broke the accessibility of Special:RevisionDelete to ombudsmen which causes quite some trouble. I would suggest to revert this change and look for another way to solve this bug.

Why not give the Ombudsmen the appropriate rights? Just like how they have CheckUser access. If we can trust them with having CheckUser and Oversight access on every project, we can certainly trust them to have deletedhistory and deletedtext rights or even sysop rights everywhere.

In other words, you are trying to revert something that works correctly for many, just because there is a select few for whom it does not work, when there is an easy way to fix the permissions of those few.

I think you are misunderstanding the issue. Ombudsmen do have these passive rights, we would need to add 'deleterevision' in order to "fix" it which would allow ombudsmen to actively hide revisions which is certainly not intended.

I think you are misunderstanding my point. The Ombudsmen currently have rights such as CheckUser and Oversight, using which they could "actively run checks" or "actively suppress revisions". They do not use it for those purposes though, because they know they are not supposed to.

Similarly, it is fine to give them "deleterevision" with the understanding that they are not to use it to actively delete a revision.

In T128914#3337478, @Huji wrote:

In T128914#3337294, @Vogone wrote:

In T128914#2091895, @gerritbot wrote:

Change 275268 had a related patch set uploaded (by LFaraone):
Allow users with deleterevision but not deletedhistory to delete revisions

https://gerrit.wikimedia.org/r/275268

This change broke the accessibility of Special:RevisionDelete to ombudsmen which causes quite some trouble. I would suggest to revert this change and look for another way to solve this bug.

Why not give the Ombudsmen the appropriate rights? Just like how they have CheckUser access. If we can trust them with having CheckUser and Oversight access on every project, we can certainly trust them to have deletedhistory and deletedtext rights or even sysop rights everywhere.

In other words, you are trying to revert something that works correctly for many, just because there is a select few for whom it does not work, when there is an easy way to fix the permissions of those few.

In T128914#2091895, @gerritbot wrote:

Change 275268 had a related patch set uploaded (by LFaraone):
Allow users with deleterevision but not deletedhistory to delete revisions

https://gerrit.wikimedia.org/r/275268

Steps: 1) Go to wikitext editor, 2) put --~~~~ in, 3) click preview, 4) wait a minute, 5) save the edit.
Result: Timestamp shows the time when the edit has been previewed instead of the time when the edit has been saved.

Please revert, community discussion has been closed as "no consensus" by a bureaucrat.

In T153397#2880221, @Krenair wrote:

Obviously? If I go to the simple form, type some text, then "Configure Form" and "View Form Configurations", then press the back button to return to the form, I get my text back.

Just a technical task, I suppose. But it still requires some time to complete, because there is still an issue with Wikidata as outlined in a comment above:

In T27522#2655109, @Zordsdavini wrote:

Redirect sgs → bat-smg is not needed, because bat-smg was temporary decision until we got normal ISO code

Why should we do this?

+1, 'importupload' is not a right which should be assigned automatically to any administrator, since it requires a fair amount of technical skills besides community trust. Entire page histories can be messed up (no matter if intentionally or by accident); I would strongly discourage from implementing this and would indeed suggest considering to follow the suggestion above and add transwiki import sources instead.

In T27522#2649432, @Amire80 wrote:

be-tarask was indeed moved, but it uncovered a Wikidata issue, which must be resolved before further changes: T112426.

Any progress here? It's been 6 years now and there are examples (be-x-old moved, jpwiki redirected) which show that this here is a resolvable task.

In T138919#2413993, @Glaisher wrote:

You can use https://meta.wikimedia.org/wiki/MediaWiki:Globalrenameuser-text. It is not enabled by default.

@Dereckson I suppose the Wednesday "Morning SWAT" (today 15-16 UTC) will be just fine for this, Though, this obviously requires someone to create the patch before. Are you willing to do so? I will certainly not be available anymore before that time.

I can confirm this happens on multiple pages.

Also happens on other wikis.

In T64717#2063405, @Dzahn wrote:

In T64717#2062666, @Candalua wrote:

In T64717#2062328, @Dzahn wrote:

I don't see why this is "Traffic". but it's declined anyways

Why is it declined?

See the comment above mine by Luke081515

"Declined per T124354. There is no consensus for this change yet. Please reopen the task if consensus reached."

This doesn't make any sense. Why do we need duplicate requests? And why would we want to wait until there is "no consensus"?

I have a question concerning the user preferences. If I choose to use the old wikitext editor as my personal default editor, do I need to switch from VE to WT manually and individually on every wiki and every device I use or will there be an easy way to make this decision with global effect? This is quite important to me, because as a globally active user I edit several hundred different wikis and my slow internet connection does not appreciate VisualEditor at all.

In T121168#1873247, @Hydriz wrote:

Two questions:

1. Why do you need to modify global groups? If there is a need, a task in Phabricator is preferred so discussion can take place.
2. Testing? Do you really need steward rights for doing "tests" that global sysop isn't sufficient?

Judging from your comments, I am inclined towards just allowing global sysops to modify global abusefilter rules on beta to fit your use case.

In T121168#1872602, @Luke081515 wrote:

I discovered some of the bugs by the way, so unwanted, like the both bugs concerning mediawiki currently triaged as low. For the bug triaged as high you need just the right to view, so nobody can replicate this, if he just can see my logs/actions. The bug at normal priority concerning logging is just visible for people with more rights, so you can't discover the bugs I reported, if you only see my logs, so it's not discernable in this situation. But there are other issues, I found at beta, reproducilbe for production too, and I can't find them at the future without the possibility to simulate some situations there, so in this point the consequence could be, that we have more bugs, which are unknown, because no one discovered them.

In T20954#1869876, @Luke081515 wrote:

@Cenarium: Maybe a case for SWAT? Then we would now, at which time.

Please don't, talk pages have to be editable by anyone, not just by people who are into flow.

In T96899#1230121, @Glaisher wrote:

For user rights, @* already works. It might be useful to show it even if Special:Log/rights is not specifically selected though (i.e. Special:Log (all public logs))

In T95408#1189527, @Legoktm wrote:

I suppose we need a javascript confirm button on the rename queue like Special:GlobalRenameUser has?

Anyone working on this right now? I personally miss this tool quite a lot.

I was under impression we do not change already implemented group names, even if wrongly named. enwiki has also a case where the autopatrolled group is internally called 'autoreviewer'.