Topic on User talk:Spinster

Please use "Panel painting", as this will not create false positives for disambiguation links. Cheers! ~~~~

Hi BD2412, I assume you are making this comment because of odd links in infoboxes on English Wikipedia? Let's see how we can solve this. In fact, on Wikidata, panel (Q1348059) is not a disambiguation item at all - it links to normal Wikipedia pages in Dutch, Gaelic and German and it is widely used as the (correct) generic term to describe a flat, usually wooden, painting surface. panel painting (Q55439) is a type of painting, not a material. Maybe @Mike Peel has a suggestion as builder of the enwiki infobox...?

Can the Wikidata value for the English meaning be changed, so that it does not invoke the disambiguation page when called into English Wikipedia? False positive disambiguation links from Wikidata calls are a fast-growing problem. ~~~~

Can you share an example entry/article, please?

The six pages for which I made this fix earlier today - Man in a gorget and a plumed cap (Q21406066), Young Lady Playing a Clavichord (Q23890828), Resurrection of Christ (Q677682), The Baptism of Christ (Q2632688), The Last of England (Q958245), Two Male Heads (Q1851182) - all created a false positive to the English Wikipedia disambiguation page "Panel". This is not the first time. Vladimír Morávek created a link to the disambiguation page, "Director", before I changed it. Théâtre antique d'Orange (Q958961) and Triumphal Arch of Orange (Q1777218) created links to the disambiguation page "Orange" (for which the city and France is very low on the list of meanings).

I'm having difficulties reproducing this. See https://en.wikipedia.org/wiki/Bust_of_a_Man_Wearing_a_Gorget_and_Plumed_Beret - does the dab link still appear after I've added "panel" back to the Wikidata entry? I can't spot it...

Yes, it does - https://en.wikipedia.org/w/index.php?title=Special%3AWhatLinksHere&target=Panel&namespace=0

Ah, I see it now, thanks. It seems to track back to the WikidataIB call (see https://en.wikipedia.org/wiki/User:Mike_Peel/Sandbox2 which also appears in the WhatLinksHere page), so I think this needs help from @RexxS to fix.

I can't fix it. The problem goes like this:

In the infobox for en:Bust of a Man Wearing a Gorget and Plumed Beret we fetch material used (P186) from Wikidata. that is "panel (Q1348059)" - a wikibase-entity, i.e. a potentially linkable item. So we look for the English site-label in that entry, and there isn't one. That means one of 3 things: (1) the article en:Panel doesn't exist; (2) it's a disambiguation page; or (3) it's a redirect.

Unfortunately, Wikidata doesn't allow us to use a site-label for redirects (so archaeologist (Q3621491) doesn't have a site-label to en:Archeologist, for example). So we have to test whether the page "Panel" exists on the English Wikipedia; if it does, we check if it's a redirect and link it, otherwise we don't link it. The act of checking whether "Panel" exists (or is a redirect) creates a spurious link from "Bust of a Man Wearing a Gorget and Plumed Beret" to "Panel". That is a bug that's been tracked at phab:T14019 for the last 10 years.

I think you'll find my code works exactly as intended (and as I expected, given the bug). I suggest there are two choices: either Wikidata allows site-labels to point to sensible redirects (such as to a subsection of larger article); or the devs fix the bug in T14019.

What about articles having completely different meanings on different Wikiprojects? Or having a disambiguation page on one project but no article corresponding to the meaning of the Wikidata term? Fetching material without prior human oversight seems like a recipe for disaster, even without the disambiguation issue that it is presently causing.

On Wikidata an item's property (like material used (P186)) is linked to one meaning of its value on Wikidata. Items with different meanings on different Wikiprojects have different entries on Wikidata, so no problem arises. For example, if several people were born in several different places all called "Newport", each Wikidata entry for the subject would link to only one of them - that's why we have Q-numbers as unique identifiers.

We don't link to disambiguation pages, for obvious reasons, so it doesn't matter whether the specific meaning of something like "Panel" is on the dab page; it doesn't get a link anyway. Only redirects are linked.

The prior human oversight occurs on Wikidata and calling it a "recipe for disaster" is both facile and disrespectful to the efforts of Wikidatans who are trying to curate the vast amount of data in existence here.

Fetching data from Wikidata for use in English Wikipedia isn't going to go away, so it's no use burying your head in the sand. There is no issue with disambiguation, merely an over-simplistic attitude to article redirects here, and a lack of response from devs to a problem that has been causing problems since 2007 and before. Your indignation and energies would be better spent lobbying for a fix to these structural problems, than putting the blame on editors who are fully aware of these problems and are trying their best to do something about them.

I am one of the most experienced editors on English Wikipedia, and I have found it incredibly frustrating trying to figure out what is causing false positive disambiguation reports to arise for terms like "Panel", "Orange", "Castro", and "Victoria". I can't imagine the confusion these errors cause to new editors trying to contribute to fixing them.

I'm pleased that you're one of the most experienced editors on English Wikipedia, and I'm sorry you find it frustrating trying to figure out what is causing false positive disambiguation reports to arise. But now you know. Perhaps next time you might consider asking someone who knows why they arise, rather than getting frustrated?

I can imagine the confusion new editors experience, and I assure you I've tried to see the sources of the problems fixed. Perhaps you'd like to help them as well by helping persuade Wikidata devs to enable site-linking to sensible redirects and the MediaWiki devs to fix the T14019 bug?

Maybe Wikidata:Requests for comment/Allow the creation of links to redirects in Wikidata will fix it in the end, if that goes anywhere...