Template talk:Wikidata location#Label text or sitelink text
Debugging
This template is a bugger to debug, so I'm dropping here a "beautified" version of the template as it was at 14:49, 29 July 2017 UTC.
{{#if:{{{location|}}}
|
{{{location|}}}
|
{{#if:{{#invoke:WikidataIB|checkBlacklist|name=location|suppressfields={{{suppressfields|}}} }}
|
{{comma separated values
| 1 =
{{#if:{{#Property:P706|from={{{qid|}}}}}
|
{{#ifexist:{{#invoke:Wikidata|getRawValue|P706|qid={{{qid|}}}|onlysourced=no|FETCH_WIKIDATA}}, {{#invoke:Wikidata|getRawValue|P131|qid={{{qid|}}}|onlysourced=no|FETCH_WIKIDATA}}
|
|
{{#invoke:WikidataIB|getValue|P706|qid={{{qid|}}}|name=location|suppressfields={{{suppressfields|}}}|fetchwikidata={{{fetchwikidata|ALL}}}|onlysourced={{{onlysourced|no}}}|noicon=yes|{{{terrainfeature|}}} }}
}}
{{#ifeq:{{{refs|yes}}} |yes
|
{{wikidata|references|normal+|{{{qid|}}}|P706}}
}}
}}
| 2 =
{{#invoke:WikidataIB|getValue|P276|qid={{{qid|}}}|name=location|suppressfields={{{suppressfields|}}}|fetchwikidata={{{fetchwikidata|ALL}}}|onlysourced={{{onlysourced|no}}}|noicon=yes|{{{location|}}}}}
{{#ifeq:{{{refs|yes}}} | yes
|
{{wikidata|references|normal+|{{{qid|}}}|P276}}
}}
| 3 =
{{#ifexist:{{#invoke:Wikidata|getRawValue|P706|qid={{{qid|}}}|onlysourced=no|FETCH_WIKIDATA}}, {{#invoke:Wikidata|getRawValue|P131|qid={{{qid|}}}|onlysourced=no|FETCH_WIKIDATA}}
|
|
{{#ifexist:{{#invoke:Wikidata|getRawValue|P131|qid={{{qid|}}}|onlysourced=no|FETCH_WIKIDATA}}
|
|
{{#invoke:WikidataIB|getValue|P131|qid={{{qid|}}}|name=location|suppressfields={{{suppressfields|}}}|fetchwikidata={{{fetchwikidata|ALL}}}|onlysourced={{{onlysourced|no}}}|noicon=yes|{{{area|}}}}}
}}
{{#ifeq:{{{refs|yes}}} | yes
|
{{wikidata|references|normal+|{{{qid|}}}|P131}}
}}
}}
| 4 =
{{#ifeq:{{#Property:P17|from={{{qid|}}}}} | United States of America
|
{{#if:{{#Property:P706|from={{{qid|}}}}}{{#Property:P276|from={{{qid|}}}}}{{#Property:P131|from={{{qid|}}}}}
|
US
|
United States
}}
|
{{#ifeq:{{#Property:P17|from={{{qid|}}}}} | no value
|
{{#if:{{#Property:P30|from={{{qid|}}}}}
|
{{#Property:P30|from={{{qid|}}}}}
{{#ifeq:{{{refs|yes}}} | yes
|
{{wikidata|references|normal+|{{{qid|}}}|P30}}
}}
{{EditAtWikidata|pid=P17|qid={{{qid|}}} }}
}}
|
{{#if:{{#Property:P17|from={{{qid|}}}}}
|
{{#if:{{#invoke:WikidataIB|checkBlacklist|name=location|suppressfields={{{suppressfields|}}} }}
|
{{#Property:P17|from={{{qid|}}} }}
{{#ifeq:{{{refs|yes}}} | yes
|
{{wikidata|references|normal+|{{{qid|}}}|P17}}
}}
{{EditAtWikidata|pid=P17|qid={{{qid|}}} }}
}}
}}
}}
}}
}}
}}
|
}}
{{documentation}}
= Template and module =
I've also created a debugging template at Template:Wikidata location/debug that can be used to show the output of this template along with the values of the five properties that it uses, which may help when examining its behaviour. --RexxS (talk) 14:51, 29 July 2017 (UTC)
Update: {{ping|Mike Peel|Rehman}} I've now got Module:WDloc working after a fashion. It's set (for now) to display a table of all the Wikidata location values for an article, along with my best guess for what ought to be the location reported in an infobox. I can quickly disable the table display if we agree on the "best" location to be returned for any article.
In {{q|Q172822}},
{{#invoke:WDloc|location|fetchwikidata=ALL |qid=Q172822}}
Whereas
{{Wikidata location/debug |qid=Q172822}}
{{reflist-talk}}
I think the module gives a better result than {{tl|Wikidata location}} in this case. Maybe the countries/continents shouldn't be linked.
In {{q|Q3299222}}, we can see
{{#invoke:WDloc|location|fetchwikidata=ALL |qid=Q3299222}}
We really need to try out as many articles as possible when we get a chance, so that we can form an opinion on whether I've picked the best algorithm for determining what is to be displayed. --RexxS (talk) 20:59, 30 July 2017 (UTC)
: {{ping|RexxS}} Trying
: I've set up a test page at User:Mike Peel/Test locations that fetches the locations for optical and radio telescopes through the module. It mostly looks good. I've been told before that links to the countries should be avoided, though, as they're overlinking. Other then that, there's just the Antarctica bug mentioned above. Thanks. Mike Peel (talk) 21:43, 30 July 2017 (UTC)
: A few other issues: apparently it should be "US", unless there is no other location information in which case it's "United States". And for {{Q|Q18132140}} (amongst others), Geo-feature should be shown (it currently just shows the country); see {{Q|Q4938704}} for a case where geo-feature + admin unit + country is needed, and {{Q|Q787671}} where it's location + admin unit (although this is because the data isn't stored right on Wikidata). Thanks. Mike Peel (talk) 22:03, 30 July 2017 (UTC)
::
:: {{ping|Mike Peel|label=Mike}} I've updated the code to deal with "novalue" as well as "somevalue" and sorted out the US/United States requirement. As your page was too long for the parsers, I've split it into three parts:
::* User:RexxS/Test locations1
::* User:RexxS/Test locations2
::* User:RexxS/Test locations3
:: Sadly, the module doesn't seem to be any better than {{tl|Wikidata location}} and shows few differences, such as returning: "South Pole, Antarctic Treaty area" instead of "South Pole, Antarctic Treaty area, Antarctica" in South Pole Telescope (I set it not to return continent unless it was the only location as requested); and "China" instead of "People's Republic of China" (because that's the name of our article). I haven't checked them all, so there may be other differences – perhaps improvements or perhaps not.
:: On the other hand, if someone is going to use the template on objects other than telescopes, like the {{Q|Q172822}}, then we might want to avoid locations like "Colorado River[1], Arizona, Nevada, Mohave County, Clark County[1][2], US". --RexxS (talk) 18:56, 31 July 2017 (UTC)
::: Thanks, those look like improvements. Using preferred values (which is the difference for Q172822) is definitely a good step forward - although we should look through User:Mike_Peel/World_Heritage_Sites to see if there are any issues there (since there are WHS's that span multiple countries). Just to be clear on my view here: the sooner we can scrap my template and switch over to using your module here, the better. :-) Thanks. Mike Peel (talk) 02:30, 1 August 2017 (UTC)
::: {{ping|RexxS}} Circling back to this, I think it's nearly ready to replace my template/hack in regular use, I think the main thing that's outstanding is the concatenating of links. The main ones we need to check are "geofeature, adminlocation" and "adminlocation1, adminlocation2", Would it be possible to add those in such a way that doesn't cause the disambig people problems? There are other things (in particular see User_talk:Nikkimaria#Location_formatting), but perhaps that's for the next version unless they're straightforward to do. Thanks. Mike Peel (talk) 16:44, 23 September 2017 (UTC)
:::: Sorry {{u|Mike Peel|Mike}}, I'm not really sure about what you mean by concatenating of links. I'm a dinosaur of small brain and I really need concrete examples. When I looked at Nikki's page, I was immediately worried about how you think I might deal with Riverside, California. Is that the problem?
:::: Are we going to face a similar problem with locations like Southwark, London? If you want the 'London' unlinked, then the code would also unlink 'Ulaanbaatar' in Baganuur, Ulaanbaatar – is that desirable? The injunction to delink "names of major geographic features" in Wikipedia:Manual of Style/Linking is not easily amenable to coding into an algorithm, unless somebody is willing to supply an exhaustive list of the names of major geographic features. I'm rather stuck at that point. --RexxS (talk) 19:25, 23 September 2017 (UTC)
::::: {{ping|RexxS}} As far as I can tell, the aim is to have links like Riverside, California, Southwark, London, Mount Wilson, California and so on, i.e. single links rather than two separate links or one link and one plaintext. The complication being that the two halves are from separate properties on Wikidata. That's what I was using the #ifexist statements for in this template, to check for the existance of such a link and to use that if available. Can that be done in Lua? Thanks. Mike Peel (talk) 19:39, 23 September 2017 (UTC)
:::::: {{ping|Mike Peel}} Well, I just tried
:::::: How do we deal with that in a systematic way? If editors can set both {{Q|Q99}} and {{Q|49243}} as values for {{Q|P131}} in {{Q|Q1920529}} – and with undefined order – it's going to need the code to start looking for an occurrence of one value within the other and dropping any that are contained. Do I have to cater for three values? four? The programming is going to need me to find several hours of uninterrupted time to crack that one.
:::::: I have no idea yet how I can generate Southwark, London from Wikidata. Our article is called Southwark – compare that with Riverside, California. Compare the en-wp site links (interlanguage links) for {{Q|Q5273898}} with those for {{Q|Q49243}}. No consistency. Here's the result for King's Bench Prison: {{#invoke:WDloc|location|fetchwikidata=ALL|qid=Q3403975}} How am I to generate London from that? --RexxS (talk) 21:47, 23 September 2017 (UTC)
::::::: {{ping|RexxS}} Yeah, this is complicated and messy. :-( With the ordering, I've mostly been manually changing them on Wikidata, which isn't great. If there are two values, maybe try checking them both ways around, so Riverside, California returns a result, but California, Riverside doesn't. In cases where the second part isn't present, I'd say just stick with the single links (e.g., don't try to generate 'London' if it's not here). Ideally we'd have different location parameters on Wikidata for state vs. county, but I think that was discussed in the past and rejected for some reason. Thanks. Mike Peel (talk) 21:55, 23 September 2017 (UTC)
:::::::: {{ping|Mike Peel}} Yes, I realised that I'd have to check (if A is in B) and (if B is in A) with two entries. But can you see how it increases as N(N-1) if we have to cater for 3, 4, ... values? Even with three values, we have to check six possibilities: (if A is in B); (if B is in A); (if A is in C); (if C is in A); (if C is in B); (if B is in C). That's why I posed the question how many we ought to cater for. Perhaps we can run a few SPARQL queries to get an idea of the maximum number of values of each location property in the current database? --RexxS (talk) 23:15, 23 September 2017 (UTC)
::::::::: {{ping|RexxS}} True. From my experience so far, I think we're talking about low numbers (<5 or so), but I appreciate the problems that could be caused if there are more than that, and I don't know how well this scales... Thanks. Mike Peel (talk) 23:26, 23 September 2017 (UTC)
== No validation on constructed link ==
{{re|Mike Peel|RexxS}} And there is another problem with this entire concept too. I just updated the template to use Module:Wd over the unmaintained and deprecated Module:Wikidata (see 964782070). This seems to have only been used for Mike's "ifexist" Wikidata label based
:
: {{re|Uzume}} Because of the free-form nature of the way Wikidata can hold information, I don't think there's an algorithm that can accurately generate a hierarchical location for every case.
: The Module:WDloc dates back to 2017 and was only created to let us compare what location information was available on Wikidata. It was never intended to be production code.
: Looking at {{q|Q2471197}} we can examine what is returned by {{tl|wikidata location}} and what is returned by the location function in Module:WikidataIB:
:*
:*
: On Wikidata, the Hale Telescope has location properties {{q|P131}}, {{q|P706}} and {{q|P361}}. The location function prefers P131, so it skips to {{q|Q99}}. I would have thought that a telescope was actually in a smaller administrative region than that. You would improve the result by moving the telescope from California to San Diego County! Optionally, you could argue that the algorithm should prefer P361 and move to the object that it is part of.
: So, looking at {{q|Q191684}}:
:*
:*
: The Palomar Observatory is located in San Diego County (P276) and San Diego (P131), so which should we follow? The location function prefers P276. The wikidata location template incorrectly adds the city as a higher level entity than the county.
: If all that is required is a sequence of higher level entities, then I think the location function generally does a better job, but it still depends on accurate Wikidata, and I can't state that there aren't cases that will catch it out. --RexxS (talk) 17:39, 27 June 2020 (UTC)
::{{re|RexxS}} So you are suggesting {{mlx|WikidataIB|location}} over {{tlx|Wikidata location}}, an older and less flexible "solution". I am not particularly familiar with that function and will have to have a look at it but it sounds interesting and useful. You say {{mlx|WDloc|location}} was only created for debugging but isn't that what {{tlx|Wikidata location/debug}} was also created for? I was never considering/suggesting having this template be implemented specifically by Module:WDloc. Moving to a Scribunto module-based solution is probably a good idea and perhaps {{mlx|WikidataIB|location}} is the way to go. Should we consider substituting that for this template? The value of this template seems questionable. I agree there is likely no algorithm that can accurately generate correct hierarchical location data in all cases when provided with convoluted/missing/broken input data (from Wikidata or otherwise). —Uzume (talk) 18:16, 27 June 2020 (UTC)
::: {{re|Uzume}} Yes, I would use the function to implement the template, but that's not my call.
::: I do say that Module:WDloc was created to examine ways of offering what location information could be retrieved from Wikidata, as you can read above. My intention was to create code that could be re-used in other solutions, but that never took off, and the module remained pre-alpha without documentation. The Template:Wikidata location/debug was a simple attempt at debugging, but was quickly superseded.
::: The location function that I added to WikidataIB was intended for use in infoboxes, so it follows common infobox conventions like using {{q|P1813}} where available, omitting US, and not linking top-level locations or major geographic features. It also attempts to deal with the situation where an intermediate region is split between two larger regions. Check {{q|Q1704043}} for example:
:::* {{#invoke:WikidataIB |location |Q1704043 |first=y}}
::: The complication there is that {{q|Q23086}} is {{q|P131}} of both {{q|Q47983}} and {{q|Q48063}}. --RexxS (talk) 18:51, 27 June 2020 (UTC)
::::{{re|RexxS}} It appears as though most if not all uses of this template are in infoboxes so {{mlx|WikidataIB|location}} seems an appropriate substitute for this template in most such cases (but see Mike's comments below). —Uzume (talk) 23:22, 27 June 2020 (UTC)
: My current approach is to use both this template and the WikidataIB code, depending on what info is available in the Wikidata item - see the location code in {{tl|Wikidata Infobox}}. In general, the WikidataIB location parameter is the best option, but there are edge cases that it has problems handling, where falling back to this template seems to be the best solution. Hopefully in the long term, the WIkidataIB location parameter will be the best solution. Thanks. Mike Peel (talk) 19:01, 27 June 2020 (UTC)
::{{re|Mike Peel}} I assume you are referring to this wikitext blob of complexity from Template:Wikidata Infobox/core: {{ucfirst:{{#invoke:WikidataIB | getLabel | P276}}}} {{#invoke:Wikidata Infobox|ifThenShow | {{#ifeq:{{#invoke:WikidataIB | getValue | rank=best | P131 | name=adminunit | qid={{#invoke:WikidataIB |getQid |qid={{{qid|}}} }} | spf={{{spf|}}} | fwd={{{fwd|ALL}}} | osd={{{osd|no}}} | maxvals=1}}|{{#invoke:WikidataIB | getValue | rank=best | P131 | name=adminunit | qid={{#invoke:WikidataIB |getQid |qid={{{qid|}}} }} | spf={{{spf|}}} | fwd={{{fwd|ALL}}} | osd={{{osd|no}}}}}|{{#ifeq:{{#invoke:WikidataIB | getValue | rank=best | P276 | name=adminunit | qid={{#invoke:WikidataIB |getQid |qid={{{qid|}}} }} | spf={{{spf|}}} | fwd={{{fwd|ALL}}} | osd={{{osd|no}}} | maxvals=1}}|{{#invoke:WikidataIB | getValue | rank=best | P276 | name=adminunit | qid={{#invoke:WikidataIB |getQid |qid={{{qid|}}} }} | spf={{{spf|}}} | fwd={{{fwd|ALL}}} | osd={{{osd|no}}}}}|{{#invoke:Wikidata Infobox|ifThenShow|{{#invoke:WikidataIB | location | {{#invoke:WikidataIB |getQid |qid={{{qid|}}} }}}}|{{Wikidata location | qid={{#invoke:WikidataIB |getQid |qid={{{qid|}}} }} }}}} |{{Wikidata location | qid={{#invoke:WikidataIB |getQid |qid={{{qid|}}} }} }} }} | {{Wikidata location | qid={{#invoke:WikidataIB |getQid |qid={{{qid|}}} }} }} }} }}
along with this from Module:Wikidata Infobox:
function p.ifThenShow(frame)
if mw.text.trim(frame.args[1] or ) ~= then
return (frame.args[3] or ) .. (frame.args[1] or ) .. (frame.args[4] or '')
else
return (frame.args[2] or '')
end
end
If there are claims for all of {{wdp|P131}}, {{wdp|P276}} and {{wdp|P17}} then it emits a table row for location which seems to use {{mlx|WikidataIB|location}} if it returns a nonempty value and there is a single claim for both {{wdp|P131}} and {{wdp|P276}}, otherwise defaults to using {{tlx|Wikidata location}}. I hope I was able to grok that correctly. It seems like we could incorporate such logic into this template so it uses {{mlx|WikidataIB|location}} if there is a single value for P131 and P276 falling back to its current behavior otherwise. Of course I am not sure how that affects any other uses of the template. I also note that the above wikitext blob uses {{mlx|Wikidata Infobox|ifThenShow}} but never provides the third and fourth framing arguments so this could have just as easily been written with {{tlx|If empty}}. —Uzume (talk) 23:22, 27 June 2020 (UTC)
::: You could equally say that whenever {{tl|If empty}} is used with only two arguments, you could use {{tl|If then show}} instead. {{tl|If then show}} is part of a series of convenience templates (for use inside other templates) that are designed to minimise the calls to Wikidata caused by wiki-templates' inability to store a result, except through a parameter. There's some documentation at Module:WikidataIB #Helper templates. Cheers --RexxS (talk) 23:47, 27 June 2020 (UTC)
:::: "If there are claims for all of" -> "If there are claims for any of", otherwise that seems about right. It is rather complex code, sorry. Thanks. Mike Peel (talk) 08:37, 28 June 2020 (UTC)
:::::{{re|RexxS}} I was not familiar with {{tl|If then show}} but I am well aware of the limitations of wikitext templating where there are no variables except parameters. {{re|Mike Peel}} Yes, I meant "any" but I clearly did not write that. —Uzume (talk) 18:00, 28 June 2020 (UTC)
Location excluding country
Hello Mike and RexxS! Is there way to use this template to generate the location, excluding the country (i.e. all other parts)? Rehman 12:38, 30 July 2017 (UTC)
: Hi {{u|Rehman}}, not this template, but I could probably create one for you if I had an example or two of what you want. Apart from {{q|P30}} and {{q|P17}}, Wikidata has three other possible ways of expressing location:
:* {{q|P276}} – example: Library of Alexandria location = Alexandria
:* {{q|P131}} – example: Eiffel Tower located in the administrative territorial entity = 7th arrondissement of Paris
:* {{q|P706}} – example: Erta Ale located on terrain feature = Erta Ale Range
: Are those the sorts of things you wanted? --RexxS (talk) 13:21, 30 July 2017 (UTC)
::
::Hi RexxS. Thanks for the quick reply. Basically, I want to use {{tl|Wikidata location}}, but with 'country' on one parameter, and all other parts on another. I intend to use it on {{tl|Infobox power station}}. Rehman 13:25, 30 July 2017 (UTC)
::: OK, that sounds a sensible request. As an example, I looked at Hoover Dam. Wikidata holds the following information on its location: {{q|P131}} = Arizona, Nevada, Mohave County, Clark County; {{q|P706}} = Colorado River. That's quite a lot of information to jam into a single field in an infobox, so do you think that editors would be willing to go to Wikidata and mark the county values as preferred (as I've just done)? Then for the Hoover Dam, you'd only have to use something like:
:::*
::: In the infobox design, it would look like:
:::*
::: Would that work for other power stations? --RexxS (talk) 13:53, 30 July 2017 (UTC)
::::
::::Yes, that seems to be the best way forward. And then probably have a bot or query run (would you know how?) to scan articles which have such long entries (such as the old version of Hoover Dam), so that we can manually tweak the preferred entries... Thanks for your help, and detailed reply. Appreciate it :) Rehman 16:09, 30 July 2017 (UTC)
Hello RexxS! I hope you're doing well. Do you think it would be possible to implement parameters in this template, so that we could optionally disable key parts of the output? (i.e exclude only the country) I tried looking at the code, but I'm afraid it is in a whole new level of complexity for me! Rehman 04:00, 9 August 2018 (UTC)
: Hi {{u|Rehman}}! I'm well, thanks - hope you are too. I've made some changes in the sandbox to implement a {{para|displaycountry}} parameter. If you set it to "no", it should suppress the {{q|P17}} value form the template. Because it's so complex, I can't be certain it will catch all the cases you want. Would you be able to test it out where you wanted to use it and let me know if it's not doing what you expect, please?
: In {{q|Q46879}}:
:*
:*
: As soon as I'm certain it meets your needs, I can update the main template from the sandbox. Tell me if you want a different name for the parameter. Regards --RexxS (talk) 18:16, 9 August 2018 (UTC)
::
::Thank you, RexxS! I did some tests on random articles, it worked quite well, except for when districts and provinces are both stated (as in {{Q|3440914}}). Since districts are within provinces, "Kandy District" should come before "Central Province" when previewing
::: I would be wary of code implementing {{para|displaycountry|no}} via 854209968. This template already implements, {{para|terrainfeature}}, {{para|location}}, and {{para|area}} in addition to {{para|onlysourced}}, {{para|suppressfields}} and {{para|fetchwikidata}} (though I notice all the calls to {{mlx|WikidataIB|getValue}} improperly always set {{para|name|location}} regardless when fetching claims for {{wdp|P706}}, {{wdp|P276}} and {{wdp|P131}}; I might have to fix that). Would it not be better to implement a similar {{para|country}} override for {{wdp|P17}} instead of {{para|displaycountry}}? If someone wants to suppress it they could just provide an blank argument for the parameter. —Uzume (talk) 17:25, 27 June 2020 (UTC)
:::: {{re|Uzume}} The {{para|name}} parameter contains the name of the infobox field that the call is made from. That is the name an editor will specify if they want to either include the infobox field in {{para|fetchwikidata}} or exclude the field using {{para|suppressfields}}. The infobox designer will choose a sensible name that should be obvious to an editor: in this case "location" is the name an editor will use to whitelist or blacklist the field. That brings me to the issue of {{tl|wd}}, which does not implement the whitelist, blacklist, or onlysourced filtering that {{tl|wdib}} does. If you test for an non-empty value using {{tl|wd}}, you may still have an empty value returned from the {{tl|wdib}} later on because of any filtering set. --RexxS (talk) 13:41, 28 June 2020 (UTC)
::: I also notice {{para|location}} seems to be improperly implemented having two meanings: once at the top allowing one to replace everything and later for just replacing {{wdp|P276}}. The latter can never be used properly. —Uzume (talk) 17:25, 27 June 2020 (UTC)
::: {{ping|Mike Peel}} Mike, do you think there's a solution possible for the "districts are inside provinces" issue within this template without messing up too much? For comparison:
:::
::: What do you reckon? --RexxS (talk) 12:15, 10 August 2018 (UTC)
:::: {{ping|RexxS}} Definitely. I think that code can replace a good chunk of this template, although I guess we'd still need to keep it for the {{Wikidata entity link|P706}}, {{Wikidata entity link|P276}} and {{Wikidata entity link|P30}} cases, unless there's an easy way that they could also be added to the Lua code. If you get the chance before I do, perhaps test it out in the sandbox either here or on Commons? Thanks. Mike Peel (talk) 14:12, 10 August 2018 (UTC)
Label text or sitelink text
{{ping|Mike Peel}}
Hi, I'm from this discussion (Wikipedia:Wikidata/2018_Infobox_RfC#Trocolandia). At there, the situation where single label-vandal in WD affects many articles in WP is discussed. I don't know about discussions behind this template was made. So if I'm pointless, please ignore me.
Currently it seems label text is used. Label in WD would be one of the most edited field. So stability is not high. For this reason, I think sitelink can be good alternative text source. For example, {{Q|P17}} of {{Q|Q37200}} is {{Q|Q79}}. Writing down this in {{tl|wd}} notation,
{{wd|label| {{wd|property|raw|Q37200|P17}} }} {{wd|label| {{wd|property|raw|Q37200|P17}} }}(This is label text){{wd|title| {{wd|property|raw|Q37200|P17}} }} {{wd|title| {{wd|property|raw|Q37200|P17}} }}(This is sitelink text)
I think the later one would be stabler than the former one through time.
Although texts are different in above example, in most cases, both texts are the same ([https://query.wikidata.org/#%23Cats%0ASELECT%20%3FWikiData_item%20%3FWikiData_itemLabel%20%3FWikiPedia_article%0AWHERE%20%0A%7B%0A%20%20%3FWikiData_item%20wdt%3AP31%20wd%3AQ3624078.%0A%20%20OPTIONAL%20%7B%3FWikiPedia_article%20schema%3Aabout%20%3FWikiData_item%3B%20schema%3AisPartOf%20%3Chttps%3A%2F%2F%5BAUTO_LANGUAGE%5D.wikipedia.org%2F%3E%20%7D%20%23If%20collected%20item%20has%20link%20to%20WikiPedia%2C%20show%20that%0A%20%20SERVICE%20wikibase%3Alabel%20%7B%20bd%3AserviceParam%20wikibase%3Alanguage%20%22%5BAUTO_LANGUAGE%5D%2Cen%22.%20%7D%0A%7D SPARQL query]). Thoughts? --Was a bee (talk) 17:12, 2 June 2018 (UTC)
: The labels are more available than sitelinks (since many Wikidata entries don't have Wikipedia articles), which makes them preferable to use as standard. However, perhaps an option where the sitelink is shown in place of the label would help avoid these highly-visible cases of vandalism. {{Ping|RexxS}} what do you think? Thanks. Mike Peel (talk) 17:42, 2 June 2018 (UTC)
::
:: As Mike says, there are a lot of Wikidata entries that don't have a site-link to en-wiki. That includes items like {{q|Q3621491}} which are redirects. Because label is easy to edit, as you say, it is easy for an editor to add a label in their own language – and that's the whole point of them. There is also the problem of very long sitelinks in enwiki: should we really be displaying John Smith (anatomist and chemist), rather than John Smith in an infobox? Should we be degrading the functionality of infoboxes just because a vandal can edit a label? If we do, the vandal has won. --RexxS (talk) 17:57, 2 June 2018 (UTC)
:::
:::Fair points, but I wonder whether it would be possible in specific cases with broad impact, eg. country names. Nikkimaria (talk) 00:20, 3 June 2018 (UTC)
::::
::::I made test module for the idea (:Module:Sandbox/Was a bee/getLinkedName). What do you think? Personally I have started to use sitelinks for getting coherent, integrated appearance as one encyclopedia at my test module. To say, to resolve many mismatches of "WP article title" and "WD label" at where term has many synonyms and alternative names. --Was a bee (talk) 17:04, 6 June 2018 (UTC)
:::::
::::: In the cases where a sitelink exists, it is fairly easy to change the displayed text from the label into the text of the sitelink (truncating any terminating parenthetical text, as {{u|Was a bee}} demonstrates). I've made a test version in Module:WikidataIB/sandbox to see if it offers an improvement and to give an opportunity to test for errors. Comparing Module talk:WikidataIB/testing with Module talk:WikidataIB/testing, I see that it returns Versailles, Yvelines instead of Versailles, which is not so good for an infobox where space is limited. I also wonder if vandals won't simply switch their attention to sitelinks instead of labels if we make a change? --RexxS (talk) 22:22, 6 June 2018 (UTC)
::::: To solve the Versailles issue, we could use sitelink:gsub("%s%(.+%)$", ""):gsub(",.+$", "") to remove the comma-separated disambiguation as well. The extreme case would be displaying Wiegenlied, D 498 (Schubert) as Wiegenlied. Thoughts? --RexxS (talk) 22:57, 6 June 2018 (UTC)
:::::: It seems very good with new regex. That do reduce frequency of vandals which affect Wikipedia articles. Most of label vandals are, AFAIS, random vandal. Just like test-edit kind vandal, not so intentional or prepared one. I think this is because label is at the most top of the page, and free text input. Contrary to this, sitelink is at the bottom (or right-side in big screen?) and doesn't accept free text. So from statistical point of view, I can assume that that would reduce the frequency of vandalism. By the way, how can I use that functionality? I'm not familiar with Module:WikidataIB syntax. --Was a bee (talk) 04:23, 9 June 2018 (UTC)
::::::: I've amended the code in Module:WikidataIB/sandbox to remove the comma disambiguation and to strip any namespace as well (because the module is in use on Commons as well, and that often has Category: sitelinks). I keep the most updated documentation at Module:WikidataIB/sandbox1/doc, so you can see what functionality is available. There are also a number of test cases at Module talk:WikidataIB/sandbox/testing in case you prefer to examine examples. You can see some diverse examples of the module in use at Commons:Template:Wikidata Infobox, Template:Infobox telescope and Template:Infobox person/Wikidata among others. There is also a convenience wrapper template {{tl|wdib}} for the getValue function in the Module. HTH --RexxS (talk) 10:54, 9 June 2018 (UTC)
:::::::: Function getLink seems to be corresponding one. Thanks. --Was a bee (talk) 20:18, 9 June 2018 (UTC)
::::::::: I have no qualms with using a heuristic to change link labels when better labels (like Wikidata labels) are otherwise unavailable, however, we should never attempt to link to articles by constructing titles using any such heuristic. The issue is there are many things with the same or even similar names and there is no good method to validate any constructed titles. For this reason we should always use titles provided in Wikidata sitelinks as link targets so we never link to incorrect things. Humans are good at interpreting things and labels that might be similar or the same or even ones with some minor confusing tweaks can be easily overlooked. Linking to the wrong things is unacceptable. —Uzume (talk) 16:48, 27 June 2020 (UTC)
:::::::::: {{re|Uzume}} I think you've missed the point of the above discussion from two years ago. The code at Module:WikidataIB already constructs the display text for a linked item by using the sitelink and stripping disambiguators from it. That is far superior to the label field in Wikidata because sitelinks are hardened against vandalism and almost all links are constructed in that way. However, if there is no sitelink, it still checks whether a redirect exists with the same name as the label and uses that to construct a link, which is necessary for a minority of cases, for example, where an occupation like egyptologist is a redirect to the subject egyptology. That means if we didn't construct a link to the redirect, we would be unable to link to egyptologist because {{q|Q1350189}} has no enwiki sitelink. It does slip up in a vanishingly small number of cases when a label is the same name as a redirect to a dab page, but there is really no good reason to have a redirect to a dab page, and I've managed to fix the problem every time it's come to my attention. --RexxS (talk) 18:00, 27 June 2020 (UTC)
::::::::::: {{re|RexxS}} My point was just that constructed links are dangerous. Even without hardened against vandalism, sitelinks are edited and reviewed by humans so they can be corrected in ways no algorithm can contrive. —Uzume (talk) 18:21, 27 June 2020 (UTC)
:::::::::::: {{re|Uzume}} Of course, Wikidata actively prevents you from adding a sitelink unless the target exists, is not already linked, and is not a redirect. That makes it exceptionally robust. It will let the vandals add any nonsense as a label. Unfortunately I can't find a better solution than constructing from the label for items like {{q|Q1350189}}, can you? --RexxS (talk) 19:05, 27 June 2020 (UTC)
::::::::::::: {{re|RexxS}} No, but that is an excellent argument for allowing redirect titles in WD sitelinks (I understand the arguments against this but I believe the arguments for such are more compelling unfortunately this has not reached consensus so we are currently stuck without them unless you want to employ the workaround of removing the redirect, adding the sitelink and then reapplying the redirect). I suppose you could find all the corner cases you know of and convert the redirects to disambiguation pages and sitelink them as a work around (though I believe dab pages typically have a different inherent {{wdp|P31}} type). —Uzume (talk) 22:24, 27 June 2020 (UTC)
:::::::::::::: {{re|Uzume}} actually it did gain consensus, but as it's the actual software that prevents the link to a redirect, we're waiting for the devs to implement that consensus (which will never happen). I started doing the trick of having the enwiki redirect open in one tab and the wikidata item in the other, then quickly editing the redirect into a one-line stub and then adding the sitelink on Wikidata before reverting back to the original redirect on enwiki. It left the redirect as an "article" for about ten seconds, but the Wikidata-haters still complained that I was disrupting the wiki, so I gave up and created the workaround in the module code. I think gnomes on Wikidata sometimes mechanically remove the enwiki sitelink because they have read somewhere that it shouldn't link to a redirect, so the work I originally did is gradually eroding. That's okay, I guess. There are too many things to fix here without having to fight battles on Wikidata. The fundamental problem there is that almost everybody is geared to inputting data into the database and organising it in a way they think is ontologically correct, and just about nobody is thinking about how to get the data out of the database to be used productively. --RexxS (talk) 23:32, 27 June 2020 (UTC)
::::::::::::::: {{re|RexxS}} Do you have the reference where the consensus was reached? Hopefully there is a Wikimedia Phabricator ticket for this. If no one else gets there first, I might have to try my hand at making such a change. I imagine it should be trivial to remove the check for a redirect in the sitelink creation code (the hard part is finding it). I do not have a regular Mediawiki development environment setup so I am pretty slow but I have managed to get things committed to WMF Gerrit before. —Uzume (talk) 23:46, 27 June 2020 (UTC)
:::::::::::::::: {{re|Uzume}} Sure: it's at d:Wikidata:Requests for comment/Allow the creation of links to redirects in Wikidata. About as clear as it gets. You can see me arguing the case at Mike's support #9 and mine at #10. That's the sort of stuff we have always been up against. Heh, I just spotted my oppose in 'Against removing existing links': {{tq|1=A database only has value when information is retrieved from it. A "self-standing database" is the computing equivalent of a book with a spine on each edge}}. They really got me annoyed in that. Good luck if still fancy taking it on. --RexxS (talk) 01:19, 28 June 2020 (UTC)
::::::::::::::::: {{re|RexxS}} Thanks but after a brief look at the discussion methinks one would have to understand that huge set of arguments and come up with a design solution to address issues before making such changes. I notice there are already sitelink badges for "sitelink to redirect" and "intentional sitelink to redirect". I think reusing the sitelink badging system is a good direction to move towards (FYI: changes to badges are considered a sitelink changes which currently fails for redirects so to use such one needs to badge thusly before one makes turns things into redirects). Badges and things like {{Q|Q16956589}} would allow a system where one can allow but control sitelink redirects without allowing arbitrary sitelink redirects. I also notice that discussion declined to reference any WMF Phabricator task(s). —Uzume (talk) 02:26, 28 June 2020 (UTC)
County
Contrived links
Related to lots of discussion above, I am not a fan of the code which is trying to "guess" links. I had an edit that was reverted today because of this. {{Q|Q892945}} sitelinks to Booby Island (Queensland) but for some reason the template was using Booby Island, Queensland which redirected to a disambiguation page. I don't understand why the sitelink was not used in this case. — Martin (MSGJ · talk) 16:35, 23 November 2021 (UTC)