Page MenuHomePhabricator

Avoid lost link for deleting pages which is later restored
Open, LowPublic

Description

Currently when a page is deleted on a client the sitelink is also deleted on the repo. When the page is undeleted, the link should be restored

Another way is to allow not to remove sitelinks while deleting. This way has side benefit (e.g. link will not be lost while moving an temproary page to the main one), but is not useful for normal page deletion (noboby can predict when the deletion review happens).

Event Timeline

Lydia_Pintscher assigned this task to Wikidata-bugs.
Lydia_Pintscher raised the priority of this task from to Needs Triage.
Lydia_Pintscher updated the task description. (Show Details)
Lydia_Pintscher changed Security from none to None.
Lydia_Pintscher added subscribers: Lydia_Pintscher, hoo.
hoo closed this task as Declined.Nov 25 2014, 8:02 PM

I think this is to much work, for to little benefit. What we could possible do is to delay the execution of the jobs that update the repo so that immediate restores/ recreations aren't propagated. But I'm not sure that's desired.

Bugreporter renamed this task from re-add sitelink when undeleting article to Avoid lost link for deleting pages which is later restored (e.g. history merge/spilt/cleanup).Mar 4 2015, 2:54 PM
Bugreporter reopened this task as Open.
Bugreporter triaged this task as Low priority.
Bugreporter updated the task description. (Show Details)
Bugreporter added a project: Wikidata.
Bugreporter removed a subscriber: Unknown Object (MLST).
Lydia_Pintscher removed Wikidata-bugs as the assignee of this task.Mar 4 2015, 3:03 PM
Lydia_Pintscher moved this task from incoming to hold on the Wikidata board.

Another usecase: In zhwiki all copyvio will tag as {{copyvio}} and be deleted 7 days later. They can be rewritten in a /temp page. When /temp page is moved to main article, the interwiki link is lost.

hoo added a comment.Mar 5 2015, 3:59 PM

Another usecase: In zhwiki all copyvio will tag as {{copyvio}} and be deleted 7 days later. They can be rewritten in a /temp page. When /temp page is moved to main article, the interwiki link is lost.

But those are different pages, thus it wouldn't be semantically correct to restore such a site link.

Bugreporter renamed this task from Avoid lost link for deleting pages which is later restored (e.g. history merge/spilt/cleanup) to Avoid lost link for deleting pages which is later restored.May 25 2015, 4:54 AM
Bugreporter updated the task description. (Show Details)

I think i that we need users to confirm whether the re-created page is connected to other pages via interlanguage links.

The check has to be only for re-created pages and be something like:

"This page is re-created. A deleted version of this page was connected to item Qxxxxxx in Wikidata. Do you want to attach this file with this item? Y/N"

However re-created pages aren't always with the same topic of orginal pages.

That's why suggest a warning and not an automatic action

Stryn added a subscriber: Stryn.Feb 5 2016, 9:35 PM

I think one possible way of doing this would be to store in the local wiki page metadata the associated Wikidata ID. The existence of this could be used as a trigger to display the dialog suggested by Magioladitis above.

If it has been associated with more than one data item in the past, it could list all or only the most recent.

If the Wikidata item has been linked to something else on the same wiki in the meanwhile, then I think something should be promtped at the Wikidata end (note to whoever next edits the entry? post on the item talk page? entry in a list?) for a WD contributor to review which is the better link.

Nikki added a subscriber: Nikki.Oct 28 2016, 3:00 PM

History-merging pages on enwiki is enough of a pain already (delete and restore are slow, and often time out and need to be repeated) and having to tend to Wikidata on top of that just adds to the trouble.
https://en.wikipedia.org/wiki/Wikipedia:Administrators%27_guide/Fixing_cut-and-paste_moves#Bugs_and_problems