Jump to content

Wikipedia talk:Wikidata/Archive 5

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 1←Archive 3Archive 4Archive 5Archive 6

Q numbers showing up in infobox

Don't know where to place this:

? --Francis Schonken (talk) 05:42, 17 June 2018 (UTC)

The problem is that the linked items for the "has part" statements on d:Q495 don't have English labels. It looks like most of them have only Italian labels. To fix it someone could add the English labels to these items. --Lydia Pintscher (WMDE) (talk) 09:48, 17 June 2018 (UTC)
@Lydia Pintscher (WMDE): there seems to be some misunderstanding about the nature of my question. I did not ask to solve this particular instance (which, BTW, was already solved satisfactorily). The nature of my question is: what can be done to prevent similar issues in the future? Throwing WHS Wikidata infoboxes out of English Wikipedia was already decided, and that solved the issue in this particular instance. I suppose there are other Wikidata infoboxes which could show this problem, so my question is: how do we prevent that from happening in these other infoboxes (as in a structural solution)? --Francis Schonken (talk) 10:19, 17 June 2018 (UTC)
@Francis Schonken: Yes, you did ask to solve that particular instance. The solution is the same as for any issue where data is incorrect: you fix the data. More generally, these kind of rare problems can be minimised by ensuring that infoboxes are designed so that they only import sourced data by default, unless we know that every page that transcludes the infobox has been checked. That is clearly only appropriate where the number of transclusions is small enough to be curated comfortably by an individual or a WikiProject. In any case, and especially for larger scale use, we ought also to insist that the editor adding an infobox to a given article should either correct any deficiency in the data or suppress the display of unwanted data in that article by using |suppressfields=includes (or whatever field should not display).
  • {{wdib |P527 |qid=Q495 |fetchwikidata=ALL |onlysourced=no}} → Crocetta Centre, , , Borgo San Donato, , , Circoscrizione 7, , Lingotto,  Edit this on Wikidata
  • {{wdib |P527 |qid=Q495 |fetchwikidata=ALL |onlysourced=yes}} →
  • {{wdib |P527 |qid=Q495 |fetchwikidata=ALL |onlysourced=no |name=includes |suppressfields=includes}} →
  • {{wdib |P527 |qid=Q495 |fetchwikidata=ALL |onlysourced=no |linked=no |lang=it}}} → 1 - Centro, Crocetta, 2 - Santa Rita, Mirafiori nord, 3 - San Paolo, Cenisia, Cit Turin, Pozzo Strada, 4 - San Donato, Parella, Campidoglio, 5 - Borgo Vittoria, Madonna di Campagna, Lanzo, Lucento, Vallette, 6 - Regio Parco, Barca, Bertolla, Barriera di Milano, Rebaudengo, Falchera, Villaretto, 7 - Aurora, Vanchiglia, Sassi, Madonna del Pilone, 8 - Borgo Po, San Salvario, Cavoretto, Lingotto, 10 - Mirafiori sud Edit this on Wikidata
The tools are all there; it just remains for you to learn how to use them. --RexxS (talk) 11:25, 17 June 2018 (UTC)
I prefer the tool that was agreed upon for the WHS infobox. Seems far less complicated. Regarding what I asked or didn't ask: I think I'm responsible for my own intentions, thus I explained what my original intention was, i.e. asking for a structural solution. --Francis Schonken (talk) 11:40, 17 June 2018 (UTC)
Also, the example in my OP also showed "Q28769238", unrelated to the items for the "has part" statements (P527). So yes, a structural solution would be welcome. --Francis Schonken (talk) 11:57, 17 June 2018 (UTC)
See MOS:LISTGAP. If you think something different is less complicated, why don't you just use it, instead of complaining here about an issue that's already been solved? Whatever your intentions, the onus is on you to express them clearly. It's no use getting irritable when you fail to do that. If your problem was with the "Location" field, rather than the far more obvious "Includes" field, why didn't you say so? The solution, of course, is to apply an English label "Province of Turin" to d:Q28769238, just as Lydia explained to you. In that particular case, the infobox could have been designed to use only the "best" value for located in the administrative territorial entity (P131), which would have avoided that problem. Something to think about for infobox designers in future. --RexxS (talk) 19:00, 17 June 2018 (UTC)

My problem is with "Q numbers showing up in infobox(es)" – do you have a structural solution for that? --Francis Schonken (talk) 19:41, 17 June 2018 (UTC)

Actually, I agree that the infobox must show the English sitelink as the first choice, the English label as a distant second choice, and probably show nothing if none is there.--Ymblanter (talk) 20:08, 17 June 2018 (UTC)
@Ymblanter: There seems a reasonable agreement that the disambiguated sitelink is probably best on enwiki when a sitelink exists. Even without a sitelink, I can still create a link if there's a redirect on en-wiki with the same title as the label. Obviously the unlinked label remains the next best choice when there is no sitelink. That leaves the unusual situation where no sitelink or label exists in English. Is it worth giving the editor a hint that a value exists but not in English at present? The other possibility might be to return nothing as you suggest, but we then lose useful data that can be provided simply by adding an English label to the Wikidata entry. As English is the fallback language for all others, it also does a favour to the other projects by ensuring that there will then be a label available for everybody. I suppose we could return just a maintenance category like "Infoboxes with data available in other languages". There's a similar discussion of an "opposite" request at c:Template talk:Wikidata Infobox #Please don't display Q-IDs to the end user! What do others think? --RexxS (talk) 23:17, 17 June 2018 (UTC)

Thanks for the link to the commons discussion. To me it is rather self-evident to not show bare Q numbers in infoboxes, if it is technically avoidable. Do we need a consensus on that first? --Francis Schonken (talk) 05:25, 18 June 2018 (UTC)

We definitely must not show Q-numbers to the readers, I do not think we need consensus on that. But we might indeed show them to some categories of users - may be as an opt-in gadget or smth like this.--Ymblanter (talk) 05:51, 18 June 2018 (UTC)
Let's then first address the issue for the general readership: adding gadgets can be an objective if and when the general issue has been sorted. --Francis Schonken (talk) 06:28, 18 June 2018 (UTC)
Regarding the suggestion to use Wikidata labels as a (first) fall-back option: disagree, because of the multiplication effect of label vandalism (see Wikipedia:Wikidata/2018 Infobox RfC#Trocolandia – several approaches to solve the issue were proposed there, none implemented afaik). --Francis Schonken (talk) 06:45, 18 June 2018 (UTC)
Example 2: the "location" parameter of the second infobox on this page seems to contain a lot of cruft, including a Q number. Is it vandalism? cluelessness? good-faith excessive detail? ...seems rather complicated to sort. In this instance, the second infobox should not repeat the location info which is already contained in the first infobox (and it was sorted by embedding the second infobox in the first) – the point being that the crufty list of ten (!) location descriptors should and could have been somewhat more contained by at least excluding second-hand descriptors such as bare Q numbers. --Francis Schonken (talk) 07:38, 18 June 2018 (UTC)
In this example, for whatever reason, the infobox reads and displays all historical locations, whereas it only must display the actual location.--Ymblanter (talk) 07:44, 18 June 2018 (UTC)
Well, in fact, even if not embedded in the first infobox, the second infobox should not have location info at all: the location info should be in the main infobox – at best, it is a redundant doubling of infobox info, or worse, as was the case here, a rather detailed, questionable & undesirable content variation. --Francis Schonken (talk) 07:59, 18 June 2018 (UTC)
I would even argue that not the whole city is the World Heritage site, but a smal collection of buildings most of which ar in the historic center, therefore there must be a separate article on the WH site (similarly to the one I created about St. Petersburg), and the infobox belongs there. However, obviously none of these issues is a Wikidata problem.--Ymblanter (talk) 08:44, 18 June 2018 (UTC)
Displaying Q numbers in infoboxes is the topic of this thread. Summing it up for the second example (Q4322516):
  • the Q number should not show up in a second infobox on a page (prior situation)
  • the Q number should not show up in an embedded infobox (current situation)
  • the Q number should not show up in a main infobox on a page dedicated to the specific WHS (possible future situation)
in sum, the Q number should never show up, not in any infobox shown to a general readership. --Francis Schonken (talk) 09:03, 18 June 2018 (UTC)
So what should show up:
  1. When there is no sitelink, but a label in English exists?
  2. When there is no sitelink or label in English?
I don't see any answers to those questions so far. --RexxS (talk) 21:49, 18 June 2018 (UTC)
@Francis Schonken: "Regarding the suggestion to use Wikidata labels as a (first) fall-back option: disagree, because of the multiplication effect of label vandalism (see Wikipedia:Wikidata/2018 Infobox RfC#Trocolandia – several approaches to solve the issue were proposed there, none implemented afaik)." This is why your complaints can't be taken seriously. First, there are not "several approaches to solve the issue ... proposed there". There are dozens of whines from you, and one, just one, indication from Was a bee about possibly using the sitelink to avoid the problem of vandalism of labels. If you claim otherwise, then tell me what the other "several approaches" are. Name them or retract your error. Secondly, on 9 June, I completed the modifications that used the sitelink where available instead of the label. That circumvents the problem in your complaint there. But I don't get "Thank you, Rexx, for addressing the problem I raised". I get "none implemented afaik". Well, you're welcome.
As for "Regarding the suggestion to use Wikidata labels as a (first) fall-back option: disagree, because of the multiplication effect of label vandalism". There's none. Nobody has brought forward a single case of where vandalism has affected the label where there is no sitelink. Why do you think it is sensible to throw out information from the infobox, to solve a problem that doesn't exist? --RexxS (talk) 22:15, 18 June 2018 (UTC)
I would say to q1 - the label must be shown, but we must make sure there is no vandalism. The items without a sitelink are more obscure typically attract less vandals, I guess we can negotiate indefinite protection of these items (only those which are used in infoboxes) on Wikidata, since they are not expected to be changed on the projects either. If the snswer to q1 is to show label, I would say the answer to q2 is show nothing and log the item; than someone can go through the logs and add an English label.--Ymblanter (talk) 07:00, 19 June 2018 (UTC)
But we probably need more test cases to understand what is going on. The one with Novgorod should not have been in the infobox anyway.--Ymblanter (talk) 07:02, 19 June 2018 (UTC)

Labels

FYI
 – Follow-up on Wikipedia:Wikidata/2018 Infobox RfC#Trocolandia

Proposed approaches:

  1. Was a bee's idea: see Template talk:Wikidata location#Label text or sitelink text
  2. MisterSynergy's idea: see phabricator ticket T196057
  3. Make labels vandal-proof at Wikidata

Afaik Wikidata labels can not carry an external reference: they are added (and can be modified) by Wikidata users and/or are imported from sources such as Wikipedia. As such they can never be considered as deriving from a reliable source, per WP:USERGENERATED, WP:CIRCULAR and/or other aspects of WP:RS/WP:V.

To answer RexxS's question ("what should show up ... When there is no sitelink, but a label in English exists?"): at least, the label should not show up in the infobox – would breach Wikipedia's core content policies if it did. For clarity: under current circumstances, i.e. the technicalities of Wikidata not (yet) having the possibility of an external reference for a label, and the English Wikipedia's core content policies, where an exception is not (yet) allowed in this case. --Francis Schonken (talk) 07:46, 19 June 2018 (UTC)

You clearly don't understand what referencing means. I might request the name of Douglas Adams' wife:
  • Jane Belson Edit this on Wikidata
In the entry for Douglas Adams, Wikidata holds the id of his wife's name ("Q14623681") and a reference url for that fact: http://www.nndb.com/people/731/000023662/ so you can use that to verify the statement. You will see that the source contains the statement "Wife: Jane Belson (m. 24-Nov-1991, until his death, one daughter)". That is what referencing the statement involves.
If Jane Belson had an article on Wikipedia, we would use the sitelink from Jane Belson (Q14623681) to display her name. She doesn't have such an article, so we use the label which does exist in English. Either way, that is nothing to do with our core content policies, which requires verification for the statement that Jane Belson was Douglas' Adams' wife (not that Jane Belson's name was "Jane Belson") - see WP:BLUESKY. If you find an entry that is not supported by the reference, then you correct it, just as everyone else does when that happens.
Of course the label "Jane Belson" should show up in the infobox: it's her name.
Now let's see your answer to the question: "what should show up ... When there is no sitelink, but a label in English exists?" I'm not interested in hearing yet again what you think shouldn't show up – we've heard that a dozen times already – I want to know what you think should show up. --RexxS (talk) 12:48, 19 June 2018 (UTC)

If the issue has already been resolved, what is the point of wasting everybody's time here by whining about a non-problem? Why should anybody be interested in your faulty hypotheses? Give some real examples, or can it. --RexxS (talk) 23:38, 19 June 2018 (UTC)

@RexxS: again, could you please stop your whining? Tx. In example 3 the human intervention to remove a redundant label could easily have been avoided (by not showing the label in the first place). So, if you won't/can't implement a structural solution to prevent that happening again in other instances, please at least stop the whining. --Francis Schonken (talk) 07:05, 20 June 2018 (UTC)
Stop whining Francis. You chose your way to resolve the problem - i.e. throw out all the work done on that infobox - the rest of us worked on how to fix the problem and did so. There are no examples left of vandalised labels showing up. As for "Třebíč castle", the text in St. Procopius Basilica in Třebíč states "The basilica is the parish church of Třebíč castle, by which it is owned.", so go fix that first, if you think it's wrong and that "Třebíč castle" should not appear in the infobox. It's obvious that when you keep resurrecting those now non-existent problems that you're just looking for something to whine about. There was no "redundant label" and there was no human intervention to remove it. It is really quite offensive to suggest I haven't been implementing structural solutions. Why not do your homework before you start making groundless personal attacks? Just examine this update and see the amount of structural improvements made over the last few months. Show me examples of where labels still cause problems or STFU. --RexxS (talk) 16:21, 20 June 2018 (UTC)
Again, please stop your whining:
  • "The basilica is the parish church of Třebíč castle, by which it is owned." → "As of 2013, the renovated Třebíč castle is a museum adjacent to the Basilica.[1][2][3]" – I don't see how one building (a castle) can "own" another (a basilica), nor what a "parish church" of a "museum" even means. The inclusion of the castle in the respective infoboxes was nonsensical. These infobox inclusions didn't pass WP:V, not even by a wide margin. It would have been wiser to prevent such infobox inclusions before they occurred.
  • The "includes" field of this infobox is my fourth example, again illustrating that it would be better to prevent such far-fetched (and difficult to check) label transclusions. No idea whether: Gamla Herrgården, Linnés bröllopsstuga, Stora Kopparberg church and Östanfors are situated in a former copper mine, and since no references (thus failing WP:V) nor even links are offered this seems difficult to check. The two linked items: Elsborg (a ship at the bottom of the Irish Sea afaics unrelated to the copper mine) and Kristine Church (of course not in the mine, but in the city after which the mine is named) don't seem to promise much. Note that my update added more material than it removed, replacing questionable unsourced material by material entirely covered by a reliable source (the UNESCO World Heritage site reference), so please stop your whining about me "throw[ing] out all the work done": I throw out material that fails WP:V, and replace & expand it with WP:V-compliant material.

References

  1. ^ About the Castle: Exhibition of Vysočina Museum Třebíč at www.zamek-trebic.cz
  2. ^ The Castle of Třebíč at www.trebiczije.cz
  3. ^ The castle: Vysočina Museum Třebíč at www.visittrebic.eu
--Francis Schonken (talk) 06:55, 21 June 2018 (UTC)
That's your biggest whine to date, Francis. Just cut it out if you can't be constructive. Just because you can't see how Třebíč Castle (the entity, not the building) can own another building doesn't mean that it can't happen. In any case, that infobox only reflected the text of an article, and your complaints about the article text belong on the talk page for the article. Get a grip. What kind of idiot thinks that there is a way of writing code that can psychically detect that the data it is working with is inaccurate. Editors can find and will correct inaccurate information, but Lua has no function that can recognise inaccuracies in the data. Nevertheless, this is no longer a problem, because we can write code that rejects unsourced information. In the latest version of the code you will find that:
That's "nothing returned" just in case you still don't get it. The value you previously saw was location (P276), of course, not "includes", so the rest of your rant about that is way off the mark.
Here's what we now get for property has part(s) (P527) in the entry for Falun Mine (Q636194)
That's "nothing returned" again, because it's not sourced. If it were sourced, then you could argue the toss about whether a World Heritage Site called "Great Copper Mountain" (which is an instance of a mining community, not a mine) can have a church or whatever within its precincts, but that's irrelevant for this discussion because it's got fuck-all to do with labels. The same would apply whether there were site-links available or no label. Are you deliberately going off-topic just to whine about the first thing that comes into your head, or do you really not understand the question "where are the current examples of labels causing problems?" --RexxS (talk) 16:44, 21 June 2018 (UTC)
In this infobox I replaced:
Fågelsjö Gammelgård
Kristofers
Pallars
(...)
by
1 Kristofers [commons], (...) • 3 Pallars [sv], (...) • 5 Bortom Åa [sv], (...)
Could {{ill}} implementations be supplied structurally instead of unlinked labels? --Francis Schonken (talk) 09:00, 21 June 2018 (UTC)
If you mean "programmatically", then the answer is "Yes, but it would take a lot of work to implement". The principal reason why nobody has put any effort into doing that sort of job so far is that there has long been vociferous opposition to programmatically making links outside of the English Wikipedia. However, I do appreciate your suggestion and I agree that the interlanguage links are an improvement. I believe it is worth spending time trying to implement. Thank you. In the meantime, replacing the value from Wikidata with a local value containing the links, as you have done, improves the article and is worthwhile. --RexxS (talk) 16:44, 21 June 2018 (UTC)
[Update:] I've been looking at this functionality. Annoyingly, the Wikidata-Lua interface doesn't yet have a function that gives us the list of sitelinks directly, so I've asked for that. I could read all of the interlanguage links by loading the entire entry from Wikidata, but that would include everything from that entry on the enwiki watchlists, which we're trying to avoid. If I can figure out a work-around, or we get an improved interface, I'll implement the interlanguage links. --RexxS (talk) 23:34, 25 June 2018 (UTC)

Q numbers in infoboxes

To answer RexxS's other question ("what should show up ... When there is no sitelink or label in English?"): at least, the bare Q number should not show up. @Ymblanter: seems we need a consensus on this after all, although for me this is completely self-evident. So, until if an when there's a proposal to have something else show up that makes sense, for me the answer is clear: in this case the infobox should show no value, meaning, as if there is no Wikidata claim for the value. --Francis Schonken (talk) 06:51, 19 June 2018 (UTC)

Yes we need consensus. Having a "Q-number" is an obvious way of inviting someone to add an English label that then benefits all of the projects. It only takes a few moments to improve the entry and then that is available for everybody thereafter. There is very little argument for excluding information that is easy to supply if somebody knows that it needs to be done.
In fact, I'll make an offer: whenever you find an example of a bare Q-number displaying on enwiki, let me know and I'll fix it for you if you can't be bothered to do so yourself. --RexxS (talk) 13:10, 19 June 2018 (UTC)
I do not think readers have a slightest idea what a Q-number is, and showing it to the general reader audience is not a good idea.--Ymblanter (talk) 13:28, 19 June 2018 (UTC)
  • My suggestion/preference instead of showing the hard QID would be "Unlabeled item" (small/italics/bold/etc. formatting optional) that is either hyperlinked to Wikidata or to have the edit pencil directly to the right of that text. "Unlabeled item" is more informative than "Q81276487365" and gives a cue to the reader, as is standard on WD IBs nowadays.   ~ Tom.Reding (talk ⋅dgaf)  14:39, 19 June 2018 (UTC)
We couldn't use small, Tom because it would make text in an infobox breach MOS:FONTSIZE. We could try italics, so I've knocked up a demo in Module:WikidataIB/sandbox. It would give results like this (taken from Turin (Q495)):
  • {{#invoke:WikidataIB/sandbox |getValue |qid=Q495 |P527 |fwd=ALL |osd=no}} → Crocetta Centre, , , Borgo San Donato, , , Circoscrizione 7, , Lingotto,  Edit this on Wikidata
Wouldn't we get the usual complaints from editors that readers will be surprised if they follow the links and find themselves on a different project? --RexxS (talk) 00:23, 20 June 2018 (UTC)
That's ok, I'm just spitballing. I see now that individual links are useful in addition to the pencil, in that they save mouse clicks and draw just a wee bit of attention. I'm assuming that, when labeled, they would be converted to plain text?
Something you might want to also do is place these pages into a hidden tracking category, that capable editors can more easily devour.   ~ Tom.Reding (talk ⋅dgaf)  00:47, 20 June 2018 (UTC)
And there will always be someone to complain. Wikidata is more or less a backbone to Wikipedia now, so not linking to it, or trying to avoid it is both difficult and counterproductive for all involved projects. I'd entertain reasonable arguments, but there are nary a one.   ~ Tom.Reding (talk ⋅dgaf)  00:56, 20 June 2018 (UTC)
Actually, common sense makes this a quite acceptable solution. "Unlabeled item" is more intuitive than "Q81276487365", it describes the link, and links to the unlabeled item, so WP:EGG does not apply. If you want to argue for "Unlabeled Wikidata item", I'm ok with that too.   ~ Tom.Reding (talk ⋅dgaf)  16:05, 20 June 2018 (UTC)
Whether you spell it unlabelled or unlabeled it remains imho counter-intuitive. Which one is most counter-intuitive is imho a moot discussion: neither should be used in Wikipedia's mainspace, imho. --Francis Schonken (talk) 09:09, 21 June 2018 (UTC)
I wish all of these were in a tracking cat so we could see the scale of the problem. I'm not familiar with the module (yet) to do it myself, though.   ~ Tom.Reding (talk ⋅dgaf)  14:04, 25 June 2018 (UTC)
Fixed, as promised. --RexxS (talk) 21:27, 25 June 2018 (UTC)
I'll try to implement Category:Articles with missing Wikidata information - one problem is that the category can only populate when a page is rendered. Let's see if it works. --RexxS (talk) 21:38, 25 June 2018 (UTC)
That seems to be working. there are about a dozen pages showing up. I've just fixed the Kedu (Q10890914) entry in Five hundred meter Aperture Spherical Telescope. --RexxS (talk) 23:47, 25 June 2018 (UTC)
Thank you RexxS. It's so much nicer/easier having everything in 1 place. Perhaps, with decent visibility and/or eager editors keeping this category small, we could even sidestep the 'what should we replace Q# with in the infobox' discussion? If it balloons out of control then some solution will definitely be desired. I've placed it in Template:Infobox/doc#Tracking categories for visibility.   ~ Tom.Reding (talk ⋅dgaf)  02:54, 26 June 2018 (UTC)

Whining

@RexxS: could you please stop your whining, and think about solutions instead? Tx. --Francis Schonken (talk) 06:51, 19 June 2018 (UTC)

I spend all my time thinking about solutions. How about you stop whining and do the same? --RexxS (talk) 12:18, 19 June 2018 (UTC)

Breaking redirects to insert into Wikidata

Please see User talk:Maqivi#April 2019 - User:Maqivi is using a weird workaround to insert Wikipedia redirects into Wikidata items. Is this really the best way to do this? --Slashme (talk) 16:19, 18 April 2019 (UTC)

Small Android app change

Hey, just as a small related update: It’ll be possible to edit Wikidata descriptions in the Wikipedia Android app. The local descriptions will always be prioritised and there will be no link to edit the English Wikidata description for articles that have local descriptions, to avoid confusion. This is related to the app editor tasks project that has previously been reported in Tech News. The new version of the app is currently scheduled to be realsed towards the end of the week.

(The app editor tasks tool has been developed for the Wikipedias in general, but then changed to respect the consensus on English Wikipedia and take the local solution into account. It only affects the Android app, not the mobile web.) /Johan (WMF) (talk) 18:34, 23 April 2019 (UTC)

This is now active. /Johan (WMF) (talk) 16:02, 29 April 2019 (UTC)

Parser function to get wikidata id from arbitrary article title

My question is whether there exists any parser-function, or module, or "magic word", or whatever (something of the form {{#invoke:Foo|Article title}}) which, given an article title, will return the wikidata "Q" number of said article if one exists. Particularly for use in a list of page titles on some project/sandbox page, not on any article page itself. I did read this section but the examples don't appear to include what I'm describing. ―cobaltcigs 16:31, 10 August 2019 (UTC)

@Cobaltcigs: What I guess you want is something that will emit "Q42" if used at Douglas Adams. This should be Module:Wikidata#Example: Linking to Wikidata item, from which we see that "{{#invoke:Wikidata|pageId}}" → "" and since it doesn't seem to be working, I'm going to call in RexxS (talk · contribs) who will know for certain. --Redrose64 🌹 (talk) 20:06, 10 August 2019 (UTC)

To be clear, I meant something totally independent of what page it's being used on (or at). Something that looks up which wikidata id, if any, corresponds to a particular page title on the local wiki. Something that would let you make a list on some totally random sandbox page and get the following result: 

*{{#SomeFunc:George Washington}}
*{{#SomeFunc:John Adams}}
*{{#SomeFunc:Thomas Jefferson}}
→
  • Q23
  • Q11806
  • Q11812

SomeFunc that you could embed in SomeTemplate to construct a clickable wikidata url. Let's say the template looks like this: 

[[{{{1}}}]] ([[Talk:{{{1}}}|talk]] · [[wikidata:{{#SomeFunc:{{{1}}}}}|wikidata]])

It could be used to output a "pretty" list like this: 

*{{SomeTemplate|George Washington}}
*{{SomeTemplate|John Adams}}
*{{SomeTemplate|Thomas Jefferson}}
→

Technically feasible, or no? ―cobaltcigs 20:49, 10 August 2019 (UTC)

The problem is that Wikidata pages (entities) are identified uniquely by an entity-id (q-number), not by a title because Wikidata is multilingual. There is no automatic association between a Wikidata entity and a Wikipedia article. That link is created by adding a sitelink on the Wikidata page that names the Wikipedia article. The result is that it's easy to read from the Wikidata page which article is associated with it for each language Wikipedia, but there's nothing exposed the other way round.
You might also consider the matching problem. Which Wikidata id should correspond with Newport, for example? Would you expect Newport (Q101254), or Newport (Q54264), or Newport (Q13409718), or Newport (Q11797275), or Newport (Q2950337), or Newport (Q985594), or Newport (Q1027134), or Newport (Q914291), or Newport (Q22072870), or even Newport (Isle of Wight) (Q7018738) (not what it looks like). There are about a dozen more, but you get the picture. --RexxS (talk) 01:18, 11 August 2019 (UTC)
I should add that if you want to create lists from given criteria, then you could write a bot that would scan though Wikidata to produce the list automatically for you. Except that Magnus Manske already did that User:ListeriaBot and the English Wikipedia community banned it from editing articles. Technically feasible, yes, but still not possible. --RexxS (talk) 01:25, 11 August 2019 (UTC)
  • Being the title of an enwiki disambig page, using {{#SomeFunc:Newport}} on enwiki should absolutely output Q224715 and none of the above numbers.
  • If we want Q7018751, we would use the enwiki title {{#SomeFunc:Newport (cigarette)}}.
  • For the title of a much newer disambig page (such as Easterly which has not been assigned a wikidata number yet) {{#SomeFunc:Easterly}} should probably output an empty string—never the ID of (literally) Tom, Dick, or Harry listed on that page.
So the guesswork concern seems misplaced. ―cobaltcigs 21:35, 11 August 2019 (UTC)
You can't possibly enumerate all the rules like "return the dab page if it exists" that will cover all of the possibilities of different meanings for any given title. Why shouldn't {{#SomeFunc:Perth}} on enwiki output Perth (Q3183), the primary topic, rather than Perth (Q192336), the dab page? The city in Australia occupies the article title Perth (average 1,787 daily pageviews), so what readers would want Perth (disambiguation) (average 11 daily pageviews)?
How would the code recognise that {{#SomeFunc:Newport (cigarette)}} is supposed to return Newport (Q7018751) when the only place where it can find that connection is on the d:Q7018751 page? if the code knows where to look, it already has the answer.
Pages on Wikipedia don't have a wikidata number assigned. They are the target of a sitelink on a Wikidata page. You only have to change that sitelink to point to a different article for that connection to change. So how would the code work out that the page is a newer dab page? How would it ascertain that the page is not the sitelink target of any Wikidata page, unless it reads all 59,000,000 pages to check?
It seems to me that guesswork is all you have to offer in trying to solve the problems I've raised. --RexxS (talk) 23:35, 11 August 2019 (UTC)
I'm really confused. I understand the user's request to be already provided in the library; that's mw.wikibase.getEntityIdForTitle( pageTitle ). In fact, that same function can also return a QID from another connected wiki given a second parameter, the globalSiteId. --Izno (talk) 23:46, 11 August 2019 (UTC)

Thank you. That seems to be exactly what I'm looking for. So I searched the module namespace for getEntityIdForTitle and found Module:ResolveEntityId, which is a bit verbose but works fairly well:

  • {{#invoke:ResolveEntityId|entityid|George Washington}} → "Q23"
  • {{#invoke:ResolveEntityId|entityid|Douglas Adams}} → "Q42"
  • {{#invoke:ResolveEntityId|entityid|Newport}} → ""
  • {{#invoke:ResolveEntityId|entityid|Newport (cigarette)}} → "Q7018751"
  • {{#invoke:ResolveEntityId|entityid|Easterly}} → ""
  • {{#invoke:ResolveEntityId|entityid|Farm to Market Road 685}} → "Q2504820"

It meets expectations in every case except for the disambiguation page Newport. That seems to be because the module code filters out otherwise valid Q numbers that are an "instance of" Wikimedia disambiguation page (Q4167410). I don't know why it's programmed to fail like that, and would rather use something that directly exposes getEntityIdForTitle without discretion. But at least it succeeds in the merge/redirect case, which is wonderful. ―cobaltcigs 12:44, 12 August 2019 (UTC)

@Cobaltcigs: Sorry I owe you an apology. @Izno: thank you - I had come across that module recently and assumed that was the behaviour of the library function without bothering to look. Hence my preoccupation with the problem of dab pages. I can see it would be trivial to modify the module code to accept a boolean parameter that disabled the test for a dab page. --RexxS (talk) 15:44, 12 August 2019 (UTC)
@Cobaltcigs and Izno: As penance, I've made a modified version of the call in Module:WikidataIB that should return all the values you wanted, with optional switches to suppress dabs if wanted, and to use articles on other wikis to find the entity-ID if needed.
  • {{#invoke:WikidataIB |getEntityFromTitle |George Washington}} → Q23
  • {{#invoke:WikidataIB |getEntityFromTitle |Douglas Adams}} → Q42
  • {{#invoke:WikidataIB |getEntityFromTitle |Newport}} → Q224715
  • {{#invoke:WikidataIB |getEntityFromTitle |Newport (cigarette)}} → Q7018751
  • {{#invoke:WikidataIB |getEntityFromTitle |Easterly}} → Q1278102
  • {{#invoke:WikidataIB |getEntityFromTitle |Farm to Market Road 685}} → Q2504820
  • {{#invoke:WikidataIB |getEntityFromTitle |Newport |showdab=no}} →
  • {{#invoke:WikidataIB |getEntityFromTitle |George Washington |showdab=no}} → Q23
  • {{#invoke:WikidataIB |getEntityFromTitle |Anna Hufnagl |site=}} →
  • {{#invoke:WikidataIB |getEntityFromTitle |Anna Hufnagl |site=dewiki}} → Q560910
I'm quite pleased because I didn't think the feature was fully implemented, so this is a real bonus. Cheers --RexxS (talk) 17:20, 12 August 2019 (UTC)

RfC:Redundant parameters in wikidata tracked templates

Myself and @Davey2010: have come to a disagreement as to whether a wikidata tracked template (such as Template:IMDB name, Template:Official website, Template:Twitter ...) should include the id and title, if these parameters are stored in wikidata. It turns out a lot of our individual edits have involved adding these when missing, or removing them when not needed(or moving them into wikidata) respectively. What's the preferred/consensus usage? #ThereCanOnlyBeOne

REWORDING using User:RexxS's wording from below.
in edits like this, I changed {{Twitter|EmAtack}} to {{Twitter}} and {{IMDb name|3038143|Emily Atack}} to {{IMDb name}} because in those templates the values will be retrieved from Wikidata and we don't need to explicitly give the parameters in that article. Whereas in edits like this, Davey2010 is restoring or adding those parameters explicitly, either because no valid reason was given for the removal, or because "Full parameters are always preferred". So we would like clarity on whether (1) it's better to keep simple facts centrally on Wikidata and retrieve them as needed; or (2) it's better to keep all information on Wikipedia where it is under our direct control.Bogger (talk) 21:19, 2 September 2019 (UTC)

(willing to have this section retitled if it seems biased. Also willing to have discussion moved to another page/changed to a dispute/vote if that seems more appropriate.) Bogger (talk) 18:09, 31 August 2019 (UTC)

First observation: over 1,000 pages have a contradiction between the en.wikipedia and wikidata versions. Bogger (talk) 18:14, 31 August 2019 (UTC)
  • This is an open topic, there isn't consensus here. My view is that it costs a lot of extra time and energy to maintain multiple systems that do the same thing, and I think that's unnecessary. My preference is to just maintain things on Wikidata, so that the information is then maintained across all of the different projects. Others disagree. Thanks. Mike Peel (talk) 18:31, 31 August 2019 (UTC)
  • I've always preferred to add the data (usernames/urls etc) to templates and the majority of articles here already have data inside them, I've often seen editors add data and I myself have added data obviously not realise it all comes from WikiData,
If there's consensus that Boggers edits should stand then I shan't edit war but my impression has been data should always be included in the templates, Thanks, –Dave | Davey2010Talk 18:42, 31 August 2019 (UTC)
Second observation: there are bots that migrate the parameters from wp to wd. Bogger (talk) 18:43, 31 August 2019 (UTC)
  • Please give an example of what you're talking about before inviting people to comment. I gather it concerns whether certain parameters should be omitted from certain templates that could use Wikidata without parameters. Why does anyone want to add a redundant parameter? Is it related to the WP:Short description scenario where redundant descriptions are being placed in articles to isolate them from hard-to-monitor changes that may occur at Wikidata? Johnuniq (talk) 10:44, 1 September 2019 (UTC)
    @Johnuniq: For some unaccountable reason, I spent the time following the links to figure out what the issue was. As I understand it, in edits like this, Bogger changes {{Twitter|EmAtack}} to {{Twitter}} and {{IMDb name|3038143|Emily Atack}} to {{IMDb name}} because in those templates the values will be retrieved from Wikidata and we don't need to explicitly give the parameters in that article. Whereas in edits like this, Davey is restoring or adding those parameters explicitly, either because no valid reason was given for the removal, or because "Full parameters are always preferred".
    This is yet another example of the two opposing points of view: (1) it's better to keep simple facts centrally on Wikidata and retrieve them as needed; or (2) it's better to keep all information on Wikipedia where it is under our direct control. I don't expect to be able to change the minds of either side, so I try to keep out of it. --RexxS (talk) 12:34, 1 September 2019 (UTC)
    Sure, I worked it out, and you worked it out, and the next person can work it out. It would be kinder if the OP spelled out the issue. Johnuniq (talk) 05:29, 2 September 2019 (UTC)
    Just to add - I've here and there seen editors add usernames etc to these templates but haven't actually seen anyone remove the data which is why I put "Full parameters are always preferred", Ofcourse I don't have any proof to say one or the other is indeed preferred I was just going by what I've seen over the last few years, Admittedly up until now I never even knew they were coming via Wikidata (I didn't know how the templates were working)- I just assumed editors forgot to fill them in and that's it,
Given descriptions were vandalised over there I'm rather iffy on transcluding other things from there but that's just me. –Dave | Davey2010Talk 19:52, 6 September 2019 (UTC)
The critical thing concerning data is not where the data are stored but how can you protect your data from vandalism. If you let the data in the wikicode of the articles, how can you monitore the change on the data you take care ? How can you monitore edits in thousands articles ? You need a bot, you have to extract the information regularly,...
In the other hand having data in WD allows you to extract the whole set of data using the query system and to do data comparison in a excel sheet if you keep a reference list on your side. Snipre (talk) 20:02, 1 September 2019 (UTC)
starting an RfC here. Bogger (talk) 13:26, 1 October 2019 (UTC)

Highest ranking

Golf Wikiproject wants to track players' highest rankings. Wikidata does not have a property for highest ranking but they have ranking (P1352). Rankings are generally associated with a particular point in time (see for example Shaun Micheel (Q1755828)). I would like to know if there is any easy way to obtain the highest ranking, in case there are multiple rankings specified. Thanks — Martin (MSGJ · talk) 12:57, 2 October 2019 (UTC)

The general workaround to get the highest is to sort the multiple values within the module, then use Module String2 split function to isolate the first or last value. I need to improve WikidataIB sorting algorithm, but I don't mind doing that if there is now a demand for it. --RexxS (talk) 11:24, 4 October 2019 (UTC)

Nomination for deletion of Template:Wikidata Infobox

Template:Wikidata Infobox has been nominated for deletion. You are invited to comment on the discussion at the template's entry on the Templates for discussion page. * Pppery * it has begun... 01:59, 12 October 2019 (UTC)

Disregard, misunderstood what this template did. * Pppery * it has begun... 03:30, 12 October 2019 (UTC)

Short description in a Wikipedia article...

Does at Wikidata entry mean a short description in a Wikipedia article is not required? Best regards DynamoDegsy (talk) 15:53, 5 March 2020 (UTC)

@DynamoDegsy: No. On the contrary, an entry on Wikidata means that a local short description is even more important. See Wikipedia talk:Short description#Often pointless descriptions and the archives of that page, there is plenty on the matter there. --Redrose64 🌹 (talk) 17:26, 5 March 2020 (UTC)
@Redrose64: Then would it be possible to add short descriptions en-masse using AutoWikiBrowser (or similar)? Best regards. DynamoDegsy (talk) 12:22, 6 March 2020 (UTC)
Several users do that, for instance Keith D (talk · contribs). There is also a tool called Shortdesc helper. BTW the best place to ask questions like this is at WT:Short description. --Redrose64 🌹 (talk) 20:53, 6 March 2020 (UTC)
I have been using the helper and importing on each page as I improve it. Folks would be appalled to see what some of the contributions from Wikidata are. SPAM, vandalism, graffiti, stuttering Wikimedia abcd, very long entries, and yes, some good ones too.
At least the short description is visible to editors here. —¿philoserf? (talk) 15:35, 18 May 2020 (UTC)

Help:Wikidata

I think a very visible link to Help:Wikidata (the newsbies namespace) would be good and not only for templates. But also for pages. There are some troubles about Wikipedia pages related to Wikidata function that are important. I can do a little try. You can improve and add more information, if you want. If more specialized template information is needed, can be created Help:From Wikidata to templates or similar. BoldLuis (talk) 13:48, 18 May 2020 (UTC)

Hope you like Help:Wikidata. I did my best. BoldLuis (talk) 19:22, 18 May 2020 (UTC)

I think it's an "easy" question, but I can't work out the "easy" answer

I'm looking at a settlement within a country. E.g. Burgas in Bulgaria and Argao in Philippines. All I want is the country calling code (P474) at the settlement level. But it only lives in the highest level, country (P17).

Obviously, it would work using Bulgaria (Q219), Philippines (Q928), for instance {{wikidata|property|Q219|P474}} = +359, {{wikidata|property|Q928|P474}} = +63

But is there a way of using the qualifier directly, without knowing what the country (and its qualifier for Bulgaria, Philippines) is? So it would work for just about every settlement (assuming each settlement has a country). The alternative would require adding P474 to every settlement - a big job.

But these days I can't read manuals like before. Sorry! Help! 31.124.11.63 (talk) 13:07, 31 May 2020 (UTC)

You want the value of a property that belongs to the value of a property. Using Module:WikidataIB for Burgas (Q6509):
  • {{#invoke:WikidataIB |getPropOfProp |fwd=ALL |osd=n |noicon=y |prop1=P17 |prop2=P474 |qid=Q6509}} → +359
For Argao (Q315703):
  • {{#invoke:WikidataIB |getPropOfProp |fwd=ALL |osd=n |noicon=y |prop1=P17 |prop2=P474 |qid=Q315703}} → +63
If you leave out |qid=, it will use the Wikidata entry connected with the calling page. Let me know if you get any problems. --RexxS (talk) 20:22, 31 May 2020 (UTC)
Thanks! Easy when you know how! 31.124.11.63 (talk) 21:47, 31 May 2020 (UTC)

One value only from multiple properties

I have been working on Infobox templates that use Wikidata extensively. A property may legitimately have multiple values: the example given in the article for is for Douglas Adams (Q42): 'playwright, screenwriter, novelist, children's writer, science fiction writer, comedian, writer, musician'.

However for an infobox you may want just one: the locator map in particular (P242): it is quite legitimate to have two maps to choose from, but in that case the infobox does not work. Is there a way in the "{ {#property:[etc] function t say "just the first one"? Hogweard (talk) 16:24, 6 June 2020 (UTC)

Module:WikidataIB was designed specifically for use in infoboxes. It has a parameter |maxvals= that will set the number of property values returned. For occupation (P106) and Douglas Adams (Q42):
To only return sourced values, set |onlysourced=yes or |osd=y or leave it out, as 'only sourced' is the default:
Setting |maxvalues=1 will limit the results to just the first:
  • {{#invoke:WikidataIB |getValue |fwd=ALL |maxvals=1 |P106 |qid=Q42}} → screenwriter Edit this on Wikidata
The documentation has a list of all of the parameters and their shortcuts. --RexxS (talk) 17:56, 6 June 2020 (UTC)
Ah. I created that module also on ang:, and it works for some values but not all. The example used above does work, and likewise if I use another writer. I then tried to get a locator map for Shetland:
  • {{#invoke:WikidataIB |getValue |fwd=ALL |maxvals=1 |P242 |qid=Q47134}}
- and it comes out blank.
I have incorporated a work-around on the template in question. I just thought I could make it neater.
Hogweard (talk) 07:59, 7 June 2020 (UTC)
@Hogweard: It came out blank because the value of locator map image (P242) in Shetland Islands (Q47134) is unsourced. Because we are not allowed to import unverified information into the English Wikipedia, the call only returns a value if it is sourced, or if you explicitly override the sourcing requirements with |onlysourced=no. I'm sorry I didn't make that clearer in my previous reply.
  • {{#invoke:WikidataIB |getValue |fwd=ALL |osd=n |maxvals=1 |P242 |qid=Q47134}} → Shetland UK relief location map.jpg Edit this on Wikidata
  • {{#invoke:WikidataIB |getValue |fwd=ALL |osd=n |maxvals=1 |noicon=true |P242 |qid=Q47134}} → Shetland UK relief location map.jpg
  • {{#invoke:WikidataIB |getValue |ps=1 |maxvals=1 |P242 |qid=Q47134}} → Shetland UK relief location map.jpg
For things like images, maps, identifiers, etc., it is legitimate to import an unsourced value because the value is its own verification. If you're using the module on other wikis that don't have requirements for WP:V, then of course you can set |osd=n more freely, or use |ps=1 which is a shortcut for 'parameterset=1' which is just a set of commonly used parameters. It's all in the documentation. Please beware that the module depends on Module:Complex date for its handing of dates, and that module has a lot of dependencies that have to be copied from Commons if you don't already have them on the other wiki. --RexxS (talk) 17:10, 7 June 2020 (UTC)
Thanks - it works. I have also checked and found (to my relief) that if the article is linked to a Wikidata entry (as they all are) then the "|qid=" value can be omitted. That will work well with an infobox template. Hogweard (talk) 21:14, 7 June 2020 (UTC)

Template:Infobox Russian inhabited locality and import of bad data

The template, which was (against my objections) converted to a wrapper, is currently importing bad data (see for example Ozyory, Moscow Oblast - it is unclear what the area data refer to, and they are cited to the Russian Wikipedia; I had similar issues with Taldom where I had to erase data from Wikidata). Would it be possible to make sure that the template only shows data which on Wikidata are sourced and not to Wikipedia (Commons is fine, I believe it also imports Commons category)? Thanks in advance.--Ymblanter (talk) 20:29, 12 June 2020 (UTC)

At present the template will automatically add data from Wikipedia for several fields whenever the respective local parameter is omitted. It is also unable to filter out unsourced data, which isn't a problem for images and identifiers, but isn't acceptable for fields that are not self evident like area (P2046). The Wikipedia:Wikidata/2018 Infobox RfC stated "there is a consensus on one point: if Wikipedia wants to use data from Wikidata, there needs to be clear assurances on the reliability of this data." Importing unsourced data from Wikidata, which has no obvious means of being verified by a source is counter-productive: it not only degrades the quality of information in Wikipedia, but it hardens the attitudes of those who wish to prohibit any use of Wikidata on Wikipedia. The infobox in question ought not to be used in mainspace until concerns about reliability have been addressed. If it's not withdrawn consentually, it should be sent to TfD for deletion. --RexxS (talk) 23:51, 12 June 2020 (UTC)
In fact, we used to have a custom infobox, which only imported reliable data. It was taken to AfD and the consensus (against my objections) was to make it a wrapper. --Ymblanter (talk) 15:50, 13 June 2020 (UTC)
And taking {{Infobox settlement}} from the main space is probably more than I can accomplish without risking my physical health.--Ymblanter (talk) 15:51, 13 June 2020 (UTC)
Okay, Ymblanter, I sympathise. I've proposed amending the wrapper template to remove any Wikidata that is not self-evident and not guaranteed to come from a reliable source at Template talk:Infobox Russian inhabited locality. --RexxS (talk) 16:34, 13 June 2020 (UTC)
Thank you, let us see what happens.--Ymblanter (talk) 16:43, 13 June 2020 (UTC)

Using nested properties in Wikipedia infoboxes

It's the wrong terminology, but I do not know what the right word is. The examples above make it look simple, but somehow the data will not come out.

I have started using data in infoboxes in ang:, which has few active editors so the Wikidata will be invaluable in keeping the data in infoboxes up to date and the boxes short. If I develop the Infobox for royalty, for example:

  • There is no problem filling in this way "image" {{#property|P18}}, or "date of birth" {{#property|P560}}
  • However I cannot work out how to do regnal dates: the data for the start of the reign of an English king is within "position held" (P39), then "Monarch of England" (Q18810062) and in that context the start time is 'P580' and end 'P582' but those are just "start time" and "end time" and can only be read in the context of the period to which they refer (say Q18810062). How do I say "{{#property|P580}} of Q18810062 in the context of P39"?

Hogweard (talk) 21:55, 5 October 2020 (UTC)

@Hogweard: You might consider using Module:WikidataIB, which was developed specifically to include information from Wikidata in infoboxes and offers a lot more flexibility and features than #property. It's a bit of a pain to import to other wikis because it uses another module to translate dates, but I can help with the task if needed. The corresponding calls are documented at Module:WikidataIB/doc, but to take some examples for Henry VIII of England (Q38370), using position held (P39):
Alternatively, there is also a specialised call that fetches the qualifier of a value that you want to match (like monarch (Q116), start time (P580) for example):
  • {{#invoke: WikidataIB |getQualifierValue |fwd=ALL |osd=n |P39 |pval=Q116 |qual=P580 |qid=Q38370}} →
  • {{#invoke: WikidataIB |getQualifierValue |fwd=ALL |osd=n |P39 |pval=Q116 |qual=P580 |qid=Q38370 |df=y}} →
There are a lot of short-cuts available for the parameter names which can help keep your infobox code more readable, such as |fwd= for |fetchwikidata=. {{wdib}} is a shortcut ("wrapper") for {{#invoke: WikidataIB | getValue}}. |df= allows you to set the date format (dmy, mdy, or just y).
The documentation has a section entitled Coding into an infobox that might be useful for examples. There are also existing infoboxes here that you could examine, such as Template:Infobox telescope and Template:Wikidata infobox. --RexxS (talk) 00:07, 6 October 2020 (UTC)
Thank you - that works! I had to copy several Modules into ang: (which I do not understand - I just blindly copied and pasted and hope they work - and now I can indeed extract the dates. Hogweard (talk) 06:19, 6 October 2020 (UTC)
@Hogweard: You're welcome. Please feel free to ping me directly if you run into any problems. --RexxS (talk) 16:57, 6 October 2020 (UTC)

Help with citations please

What's the en-wp template for generating harv-style citations from wikidata records? E.g. expanding d:Q22961841 into The Routledge Guide to Music Technology. Routledge. 2013. ISBN 978-1-135-47780-6. {{cite book}}: Invalid |ref=harv (help) Retired electrician (talk) 20:50, 3 November 2020 (UTC)

I think you are looking for {{cite Q}}. These citations are CS1 citations though (and automatically generate the magic that makes harv refs work, so |ref=harv is not necessary). --Izno (talk) 21:14, 3 November 2020 (UTC)

Generating new Wikidata entries from Wikipedia articles

I noticed that if you're logged out and try to add an interlanguage link to a Wikipedia article with no corresponding Wikidata entry, it takes you to the "create a new item" form on Wikidata with the link to the Wikipedia article already filled in. Is there a simple way to get to that page while logged in as well? I haven't been able to find one, since that workflow takes you to a popup for adding interlanguage links instead, and it seems like the easiest way to add a Wikidata entry for Wikipedia articles that only exist in English. TheCatalyst31 Reaction•Creation 19:10, 26 November 2020 (UTC)

I've never noticed that before, probably because I never edit logged out. But I wonder why it does this? — Martin (MSGJ · talk) 21:49, 26 November 2020 (UTC)
The url for the page you want is https://www.wikidata.org/w/index.php?title=Special:NewItem&site=enwiki&page=xxx where xxx is replaced with the name of the article. This can be accessed whether logged in or not. — Martin (MSGJ · talk) 21:55, 26 November 2020 (UTC)
It can, and I think I figured out a hacky way to replicate the logged-out behavior; if you open the link in a new tab instead of just clicking on it, it takes you to the new item page even if you're logged in. I'm still not sure what's behind the difference in behavior, but I figured out what I needed to at least. TheCatalyst31 Reaction•Creation 17:53, 27 November 2020 (UTC)

Template:P listed at Redirects for discussion

Is this page the main noticeboard for Wikidata on Wikipedia? Assuming it is: A discussion is taking place to address the redirect Template:P. The discussion will occur at Wikipedia:Redirects for discussion/Log/2021 January 16#Template:P until a consensus is reached, and readers of this page are welcome to contribute to the discussion. czar 04:08, 16 January 2021 (UTC)

Items generated automatically for new Wikipedia articles?

Are Wikidata items automatically generated for new Wikipedia articles or does it need to be done manually? Whatisbetter (talk) 19:15, 20 January 2021 (UTC)

It is currently a semi-manual process. But yes, mostly manual. --Izno (talk) 20:21, 20 January 2021 (UTC)
I thought usually bots do it, and pretty quickly.--Ymblanter (talk) 17:40, 21 January 2021 (UTC)
I had to manually create one for this article Hopetoun Hotel however the Wikidata link is not appearing under tools - has something gone wrong? Whatisbetter (talk) 10:01, 25 January 2021 (UTC)
I can see the Wikidata link there, to Hopetoun Hotel (Q104927996). You might need to purge your cache (add ?action=purge on the end of the URL).
Pi bot now creates new items after 14 days (and quicker than that for humans where it can't find a search match), the delay is to give time to match articles to existing items. Thanks. Mike Peel (talk) 10:09, 25 January 2021 (UTC)
So is there no more wikidata tool? I also can't find it under the tools header. Is it now done automatically? Gabymess (talk) 16:24, 6 May 2021 (UTC)Gabymess (talk)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:Wikidata/Archive_5&oldid=1050166468"