Page MenuHomePhabricator

do not follow sitelink redirects when redirect badge is used
Open, HighPublic

Description

Problem:
We want to allow sitelinks to redirects but only under certain conditions. In detail this means:

  • The default behavior always tries to normalize sitelinks (following redirects) and thus these sitelinks are rejected in cases where the target of the redirect is already a sitelink
  • A sitelink to a redirected pages can be added to an Item if and only if a redirect badge (sitelink to redirect (Q70893996), intentional sitelink to redirect (Q70894304)) is added in the same edit
  • Adding a redirect badge to an existing redirect sitelink is possible
  • Removing a redirect badge from a sitelink that points to a redirected page is disallowed

Context:

  • In T235420 we added badges to indicate sitelinks to redirects but they can't be used because the edits related to them can not be made (as redirects are followed and sitelink conflict occur)
  • https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Wikibase/+/602422 contains some work in this direction but is probably not the right approach, (per Adam's comment at T235420#6791998) Adam notes: "Looking at the patch lots of the code will end up being reused, but it will need the addition of some checks etc to optionally pass MediaWikiPageNameNormalizer::NOFOLLOW_REDIRECT into the service etc."

BDD
GIVEN an Item
AND a page on the client that is a redirect
AND the redirect target is already used in another Item
WHEN adding the page as a sitelink to the Item
AND not adding a redirect badge in the same edit
THEN the edit is rejected

GIVEN an Item
AND a page on the client that is a redirect
WHEN adding the page as a sitelink to the Item
AND adding a redirect badge in the same edit
THEN the sitelink and associated badge are stored

GIVEN an Item
AND a page on the client that is a redirect
WHEN adding a redirect badge to the sitelink
THEN the badge is stored with the sitelink

GIVEN an Item
AND a page on the client that is a redirect
AND the redirect target also has a sitelink in another Wikidata Item
WHEN trying to remove the redirect badge from the sitelink
THEN the edit is rejected

Acceptance criteria:

  • Default behavior remains unchanged - no need to change any error messages or similar
  • Sitelinks to redirect pages are accepted if and only if there is a redirect badge attached to them

Notes:
Patches from previous tickets are https://gerrit.wikimedia.org/r/c/mediawiki/core/+/602412 and https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Wikibase/+/602422
Which includes code for turning on / off specific parts of title / sitelink normalization.

Event Timeline

I assume removing the badge from a sitelink should be disallowed if the target page is (currently) a redirect?

I assume removing the badge from a sitelink should be disallowed if the target page is (currently) a redirect?

Sure.

<s>Some further thoughts:

Instead of 2 independent badges giving 4 possible values, create just 1 with 2 mutually exclusive values:

  • deliberate link to redirect
  • dubious link to redirect (should be strongly deprecated if supported at all)

Ideally, changing

  • an ordinary page to a redirect (I consider ca 99% of such edits as vandalism ...)
  • a redirect to an ordinary page
  • page redirect to section redirect
  • section redirect to page redirect

should adjust the badges at wikidata (in the same way as moves and deletes are handled).

Further, there could be an additional independent badge about page redirect vs section redirect.

Deliberate links from wikidata to redirects should probably be allowed ONLY if the redirect CANNOT BE FOLLOWED, ie an attempt to follow it gives the infamous "already taken" error.</s>

See wikidata: https://www.wikidata.org/wiki/Wikidata:Project_chat#BUG:_%22intentional_sitelink_to_redirect%22_does_not_work

See below for better idea.

I assume removing the badge from a sitelink should be disallowed if the target page is (currently) a redirect?

😬 good catch. Will add to the description.

Re not removing a badge : note that it may be important for a user or bot to be able to change a badge, in particular from 'sitelink to redirect' (Q70893996) to 'intentional sitelink to redirect' (Q70894304), if the user determines that the redirect is valuable.

I'm not sure I'd lose too much sleep about users potentially removing badges, given that most redirects are currently unbadged, and quite possibly sitelinks to new redirects created by merges on wikipedias may not be badged until a bot finds them.

I think we should tag the local pages with a specific magic word like __VALIDREDIRECT__.

@Bugreporter : On many wikipedias the template "wikidata redirect' is available : https://www.wikidata.org/wiki/Q16956589

My original idea (before the badge exists) is if user added a sitelink to a redirect page tagged with a magic word, Wikibase software will no longer follow the redirect (see https://www.wikidata.org/wiki/Wikidata:Requests_for_comment/Allow_the_creation_of_links_to_redirects_in_Wikidata#Support #49). Introduce a badge may be helpful, but it may be a problem if a redirect is turned to an article or vice versa.

Support. Discard the badges and use __VALIDREDIRECT__ instead. Let wikidata autodetect "redirect to page" vs "redirect to section" and display appropriate icon, and autodetect __VALIDREDIRECT__ too with a tri-state verdict "intentional redirect" vs "dubious redirect" (redirect but magic word missing) vs "misuse of VALIDREDIRECT" (target is an empty page, or a redirect, or a page (not section) not linked to wikidata). I do not see the point with "Q16956589" either. Make it as simple as possible. The originally intended solution with 2 independent badges allows for a large number of dubious states.

Automatically adding badges based on a magicwork on the client is quite a different can of worms. It would involve considerably more work than I can justify here to get it to the state where it does what people expect incl. querying for sitelinks with those badges. Given that we've been trying to find a solution for this for years and people are rightfully complaining that this hasn't been solved in a long time I think we need to go ahead as laid out in the task description. It is not the perfect solution but one we can make happen now.

Addshore renamed this task from allow sitelinks to redirects if redirect badge is used to do not follow sitelink redirects when redirect badge is used.Apr 14 2021, 10:44 AM
Addshore updated the task description. (Show Details)

Looked at in story time, @Lydia_Pintscher and @Ladsgroup agreed to meditate on this a little more and bring it again in the future.

Amir and I discussed this again today. The suggested way forward is:

  • add a configuration for the redirect badges
  • introduce a sitelink page name normalizer that takes the config
  • use that service is setsitelink APIs
  • that service sets followredirects or not depending on the badges sent to the service
  • setsitelink API and co send badges provided in the edit request to this service

@Addshore Does ^ sound good to you?

I see that the badges have been created but my attempt to add the badge to a sitelink to a redirect was rejected. What is the status of this task?

Change 602412 had a related patch set uploaded (by Ladsgroup; author: Ladsgroup):

[mediawiki/core@master] Make following redirects in MediaWikiPageNameNormalizer optional

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

Change 602412 merged by jenkins-bot:

[mediawiki/core@master] Make following redirects in MediaWikiPageNameNormalizer optional

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

An update on this important and long-standing issue would be much appreciated.

Yes, people use https://www.wikidata.org/wiki/Wikidata:Sitelinks_to_redirects#Workaround as it is suggested in guideline, but why it takes so long to implement the real fix? You can check how many redirect badge were already used, even though now man can not directly attach badge on redirect, man have to use workaround.

Semantically, whether a redirect is suitable for an item is a property of the redirect, not the item, so a magic word would be the more proper solution.

I still think that a magic word is the preferable approach, irrespective of progress with the temporary fix with many badges. Discard the badges and use VALIDREDIRECT instead. Let wikidata autodetect "redirect to page" vs "redirect to section" and display appropriate icon, and autodetect VALIDREDIRECT too with a tri-state verdict "intentional redirect" vs "dubious redirect" (redirect but magic word missing) vs "misuse of VALIDREDIRECT" (target is an empty page, or a redirect, or a page (not section) not linked to wikidata). I do not see the point with "Q16956589" either. Make it as simple as possible. The originally intended solution with 2 independent badges allows for a large number of dubious states.

@Addshore Adam and Lydia, what is the status of this issue?

Please quit ping-spamming.

We are simply asking for an update from the WMF on a longstanding issue that the community has frequently asked to be fixed. If someone would take the time to explain why this has stalled then the pings would not be needed.

I'v added another note for this ticket for my next chat with @Lydia_Pintscher