Help talk:Redirects

From Wikidata
Jump to navigation Jump to search

What is the basis for the creation of this help page?

[edit]

English: I don't understand this help page. What is the basis for the creation of this help page? If I understand correctly, now we can add redirects to Latvia (Q211), for example, in geography of Lithuania (Q950091), demographics of Latvia (Q2329836), economy of Latvia (Q1902255), culture of Latvia (Q2991765), and so on. That is nonsense! --Treisijs (talk) 17:48, 10 November 2014 (UTC)[reply]

Latviešu: Es nesaprotu šīs palīdzības lapas nepieciešamību. Uz ko ir balstīta tās izveide? Ja es saprotu pareizi, tad tagad mēs varam pievienot pāradresācijas lapas uz Latvija, piemēram, rakstos par Latvijas ģeogrāfiju, Latvijas demogrāfiju, Latvijas ekonomiku, Latvijas kultūru un tā tālāk. Šis viss ir bļēnas! --Treisijs (talk) 17:48, 10 November 2014 (UTC)[reply]

@Treisijs: Indeed you do not understand. Such redirects are to redirect one item toward another that is the exact same concept. Similar to Wikipedia when en:Haïti redirects to en:Haiti, Category:1911 in Morocco (Q18511155) redirects to Category:1911 in Morocco (Q9404406) (because some time in the past, two items had been created to represent the same concept, and they were merged, leaving a redirect). -- LaddΩおめが chat ;) 02:41, 11 November 2014 (UTC)[reply]
Thanks you for explanation! --Treisijs (talk) 20:23, 13 November 2014 (UTC)[reply]

Double redirects

[edit]

It seems that double redirections can be a problem with mediawiki, as it traditionnaly do not follow multiple redirects and shows the page of the target even if it is a redirect itself.

The policy recommands not to touch redirect. If after some multiple item merge, say A, B, C

with B and C merged into BC, we get C=>BC, then BC merged into A resulting into ABC, we get

A => BC => ABC

A double redirect.

This problem does not happen if we merge B into A, then C into AB though, we get

B => ABC and C => ABC


This can't solve everycase though, as we could have two sets of merged items that happens to be duplicate, then we don't have the choice of the order.

The policy is supposed to help when we cancel merges. Is there a case when solving a double redirect makes harder to cancel a change ? I'm not sure about that.

Do we need to modify the policy or open a ticket in Phabricator to the devteam ? What do you think ? Is it a real problem ? TomT0m (talk) 13:12, 12 April 2015 (UTC)[reply]

@TomT0m: The policy says that deleting redirects should not be done. However, in case of a double redirect, the redirect which links to another redirect should be changed to link to the actual item. I will add this to the policy. This should be automatically done either by the Wikibase software or by a bot like it is done on most Wikipedias already. -- Bene* talk 16:12, 12 April 2015 (UTC)[reply]
This is the query that finds double redirects:
The following query uses these:
SELECT ?x ?target ?double WHERE {
  ?x owl:sameAs ?target .
  ?target owl:sameAs ?double .
} 
LIMIT 100

Laboramus (talk) 20:56, 8 September 2017 (UTC)[reply]

[edit]

This proposed policy says the links to redirects should stay in place. However, while making reversing redirect relatively easy, this creates a number of other challenges:

  1. Queries: most queries would not work with redirects. One can modify query to make it work, but for most users it is not obvious, and none of the standard examples do it. Queries written to account for redirects would be necessarily slower and sometimes even next to impossible to write (like path queries with redirects).
  2. Labels: redirect labels are not editable, however what is displayed is redirect label, not target label. Thus, such items would display un-editable labels (since it is impossible to edit a label on redirect from GUI) and some of them are not very good, out of date or out of sync with target item. Which leads to the fact that the user is clicking on one thing, gets another thing, and there's not even a way to fix it. E.g., cemetery (Q9641002) is redirected to cemetery (Q39614), but the label on cemetery (Q9641002) has improper capitalization (and also it doesn't display properly via Q template, as you can see), which can't be fixed. And items like Kuninkaanhauta (Q1743474) display it, despite click leading to cemetery (Q39614).
  3. Additionally, some of the labels, due to the above, can be missing, because when labels from other languages are added, they'd be added to the target and not to the source of the redirect.

Due to all this, I have the following proposal. I recognize that easiness of revert is a valid concern. However, some of the redirects are pretty old - some are from almost 2 years ago - and the chance of them being reverted are quite low - in fact, no more than the chances of any other random item being split. Thus, I would propose that the links to old redirects - with old reasonably defined, like a month, or two months, or whatever sounds reasonable - would be declared "stable" and as such all links to the redirect source would be converted to the target. Laboramus (talk) 20:53, 8 September 2017 (UTC)[reply]

@Laboramus: I think what you observe in (2) above is an artefact of some caching in the system; now (a few days later) I see only "no label" shown for Q9641002. Also, the link in Q1743474 was edited yesterday by KrBot to point to Q39614. So we already have a bot doing what I think you were suggesting above. I don't think there's a current problem with redirects of this sort, other than a slight delay of a few days before things are sorted out. ArthurPSmith (talk) 14:54, 11 September 2017 (UTC)[reply]
@ArthurPSmith: Thanks for the link to KrBot, I'll check it. However I see pretty old redirects (as I said, from 2 years ago) still not updated, so I wonder whether it's the bug in the bot, or some kind of limitation, or KrBot does not take care of everything. I'll check into that. In any case, I assume since KrBot is doing this, it is OK to do it despite what is written in this proposed policy? Laboramus (talk) 22:04, 12 September 2017 (UTC)[reply]
@Laboramus: sorry, what proposed policy are you referring to? I don't recall any policy change relating to Wikidata redirects (there is an RFC on wikidata linking to redirect pages in the wikipedias, but that's quite a different issue). ArthurPSmith (talk) 13:21, 13 September 2017 (UTC)[reply]
The one outlined in Help:Redirects - the main page for this discussion page :) Laboramus (talk) 18:36, 13 September 2017 (UTC)[reply]
Ah! I'm going to edit that to reflect what's done now... ArthurPSmith (talk) 19:40, 13 September 2017 (UTC)[reply]

Connecting a topic to a redirect-page on Wikipedia?

[edit]

I understand, that this help page is about redirects on wikidata (local links from one item to another) But what I'm looking for is a guideline on if and how to connect a page on wikidate (item) with a (remote) page on any Wikipedia that is a redirect to another page on that Wikipedia. --Manorainjan (talk) 21:02, 11 December 2017 (UTC)[reply]

You can't do that right now - other than via the workaround of making the remote page temporarily NOT a redirect. A substantial majority of active wikidata users want this - see Wikidata:Requests for comment/Allow the creation of links to redirects in Wikidata. We're waiting on some development response to either make it happen or explain why it can't be done... ArthurPSmith (talk) 21:06, 11 December 2017 (UTC)[reply]

Trouble making a redirect.

[edit]

@ArthurPSmith: I hope this is the right place. I ended up with two references for one article (or what should be one article). I decided I had to use the special page, Redirect and entity. I want to redirect from Q79310374 to Q7306827 but it is blocked with the comment: Can't created redirect on non empty entity Q79310374.

I think I have made Q79310374 empty. What have I done wrong? Mystified Eddaido (talk) 09:29, 26 October 2020 (UTC)[reply]

Thank you very much, took me a week to find the courage to do it and then it worked perfectly. Many thanks, Eddaido (talk) 09:13, 3 November 2020 (UTC)[reply]

@ArthurPSmith, Eddaido: I updated the page to make it clear that one should use the merge tools. --- Jura 09:27, 3 November 2020 (UTC)[reply]

Is this redirect permenant?

[edit]

Q124269284 to Q117840901


Is it permenant?


Or Both of them get deleted ? Ceftriaxone (talk) 03:44, 18 February 2024 (UTC)[reply]