Page MenuHomePhabricator

Automatically tag edits that make a redirect, or convert a redirected page to a normal page, or move a page across namespaces, etc.
Closed, ResolvedPublic

Description

When one creates a redirect without filling an edit summary, MediaWiki automatically uses an edit summary to identify that the edit created a redirect. That's very useful. But the autosummary doesn't work if the user fills the edit summary. It also doesn't work when the user edits a redirected page to make it a normal page, by removing the #REDIRECT syntax.

Redirections are very special edits that would be good to have them tagged for review on recent changes and watchlists.

With AbuseFilter one could write some tricky filters to tag those edits, but that's far from ideal.

My proposal is to have at least 2 new tags:

  • One to tag when a redirect is created
  • One when a redirect is removed (not by page deletion, but by removing the #REDIRECT)

It would be nice to also have a tag for when a redirect target is changed (pointing the redirect to another article) and also when a redirect is edited without changing the redirect (like for example adding a category, a comment, or simply content that won't be viewed anyway).

A slight limitation of tags (as I understand) is that they won't display the redirect target as the autosummary does, but that's not important, I think. The autosummary would do the job when present.

Related Objects

StatusSubtypeAssignedTask
ResolvedCenarium
ResolvedLadsgroup
ResolvedLadsgroup
ResolvedLadsgroup
ResolvedLadsgroup
OpenNone
ResolvedLadsgroup
ResolvedPRODUCTION ERRORLadsgroup
ResolvedMarostegui
ResolvedBstorm
ResolvedLadsgroup
ResolvedLadsgroup
ResolvedLadsgroup
ResolvedLadsgroup
ResolvedMarostegui
ResolvedMarostegui
ResolvedTrizek-WMF
ResolvedLadsgroup
ResolvedLadsgroup
ResolvedLadsgroup
ResolvedLadsgroup
ResolvedLadsgroup
ResolvedLadsgroup
ResolvedLadsgroup
ResolvedLadsgroup
ResolvedMarostegui
ResolvedLadsgroup

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
daniel subscribed.

Assigning to RFC queue, since I think the ArchCom should have a look at this.

@Cenarium do you think this should be an RFC? See https://www.mediawiki.org/wiki/Requests_for_comment/Process for the process. If not, feel free to remove the @MediaWiki-RfCs tag.

GWicke moved this task from Old to Under discussion on the TechCom-RFC board.

@daniel I haven't implemented any of the controversial aspects.

The first one being the ability to activate / deactivate these tags directly from Special:Tags, which would require a database change. So we don't need a RFC on this at the moment, but we might revisit this issue if it turns out after implementation that there are requests from the wiki communities for such a feature.

The second one is how to handle these tags for display in a drop down menu. I've given up the controversial idea of having a localizable tag name, instead having a separate message for it which can also be used to prevent the tag from appearing in the drop down menu. I haven't had feedback yet on this proposed solution so I can't say if a RFC might be needed, but I don't see which alternatives we have.

Do we have statistics on how many (non-Wikimedia) wikis consider cross-namespace redirects to be a problem?

Do we have statistics on how many (non-Wikimedia) wikis consider cross-namespace redirects to be a problem?

I don't think so.

Should we deactivate the feature by default in mediawiki core ?
(And enable it on WMF wikis.)

Should we deactivate the feature by default in mediawiki core ?

Yes.

(And enable it on WMF wikis.)

That requires a separate discussion IMHO.

@Cenarium, @Ciencia_Al_Poder: We (the ArchCom) thinks it may be nice to discuss this RFC at the hackathon in Lyon. Will you be attending?

@Cenarium, @Ciencia_Al_Poder: We (the ArchCom) thinks it may be nice to discuss this RFC at the hackathon in Lyon. Will you be attending?

No I won't be attending. What is it in particular that you want to discuss ?

@Cenarium, @Ciencia_Al_Poder: We (the ArchCom) thinks it may be nice to discuss this RFC at the hackathon in Lyon. Will you be attending?

Me neither

@daniel
I dunno what you intend to discuss, but FYI the patch set in https://gerrit.wikimedia.org/r/194458 when combined with https://gerrit.wikimedia.org/r/#/c/190656/ allows to resolve T92621, and when also combined with https://gerrit.wikimedia.org/r/#/c/211656/, allows to resolve T14363 as well (from recent changes, not from new pages where performance issues make this impossible IMO).

Did anyone work on this task at Wikimedia-Hackathon-2015? If do, please share an update. If not, remove the label.

@Cenarium, @Ciencia_Al_Poder: do you think it would be useful to have a discussion on IRC about this soon? Or would you say the patch sets you mentioned would be sufficient to close this? Is there anything more to discuss?

Change 194458 pretty well does what's requested on this bug, so I'd say it could be closed once it's merged

ArchCom approves: this seems pretty uncontroversial. We have added some reviewers to the patch. If the review doesn't go forward, let us know.

@daniel, if you have time, Cenarium and I would really appreciate a second opinion on some of these patches, particularly 201905. Anomie is too busy, and I personally have some doubts about ChangeTagsContext and would like someone's else's point of view.

what's the status of this? Can we get the patches merged?
Hm, seems to be a long chain...

Lots of dependencies indeed...
For automated tags, we need a user-friendly drop down menu instead of an input box (since internal tag names are in english and obtuse, e.g. core-move-crossnamespace). It's 211497.
For the dropdown menu, we need to overhaul the caching so that a list of tags can be efficiently fetched. It's 218265.
Before overhauling the caching, we need to make several related performance improvements. It's 201905.
218777 is not essential to this (I might put it in another branch).

In T73236#1641141, @TTO wrote:

@daniel, if you have time, Cenarium and I would really appreciate a second opinion on some of these patches, particularly 201905. Anomie is too busy, and I personally have some doubts about ChangeTagsContext and would like someone's else's point of view.

Yes, I would appreciate reviews.
I've created ChangeTagsContext so that the ChangeTag class can't be provided with arbitrary hitcounts or tag definitions, in a way that doesn't require unnecessary duplications when multiple ChangeTag instances are involved.

Change 311683 had a related patch set uploaded (by Cenarium):
Implement redirect-related and other tags in mediawiki core

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

Nemo_bis renamed this task from Automatically tag edits that make a redirect, that converts a redirected page to a normal page, moves across namespaces and others to Automatically tag edits that make a redirect, or convert a redirected page to a normal page, or move a page across namespaces, etc..Sep 22 2016, 5:53 PM

Change 211497 had a related patch set uploaded (by Cenarium):
Implement redirect-related and other tags in mediawiki core

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

Change 311683 abandoned by Cenarium:
Implement redirect-related and other tags in mediawiki core

Reason:
I ended up removing the dependencies directly in I2e48bd458fc8d7c289f04dc276f9287516e0b987 so I have only one commit to maintain.

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

Change 390224 had a related patch set uploaded (by Catrope; owner: Petar.petkovic):
[mediawiki/core@master] Add new core tags

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

Change 390224 merged by jenkins-bot:
[mediawiki/core@master] Add new core tags

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

Change 194458 abandoned by Krinkle:
Implement redirect-related and other tags in mediawiki core

Reason:
Closing for now due to inactivity and to clear review dashboards. The associated ticket appears to have been resolved without this commit.

Feel free to re-open at any time.

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