Module talk:WikidataIB

Maxvals

Hi, @Mike Peel: , If the first value that apears at the Wikidata item property is not the one someone want, how should that person manage to get the desired value? I'm not sure that is a good idea add maxvals in the module, just because of that lack of criteria of which one I can get (the first one, the last one, the oldest added one, the newest added one etc...). I don't know if even it's possible implement a criteria on this matter. Regardless, if you really want to get this first value returned to use in a template, I suggest {{str sub|{{#invoke:...}}||{{#expr:{{str find|{{#invoke:...}}|, }}-1}}}}, it's a bit dirty, but it works fine. Ederporto (talk) 22:41, 29 January 2018 (UTC)

@Ederporto: Maxvals is a blunt instrument, made to avoid cases where trying to return more values will cause things to fail. E.g., if more than one image is returned, then the code to display that image can't cope with it. In general, the better approach is to use getPreferredValue and to change the ranking of the value on Wikidata, rather than relying on maxvals. But having maxvals in the module is much more efficient than using template parsers (plus, @RexxS: had already coded this up on enwp). Thanks. Mike Peel (talk) 22:48, 29 January 2018 (UTC)

English module updated

I've updated en:Module:WikidataIB to fix some errors and add a couple of features as described at en:Module talk:WikidataIB #Update to latest version. Because this module has been edited since the changes were made in the sandbox2 on 26 January 2018, I can't simply copy the updated module over. I suggest that someone might want to merge the latest enwp module into this one to gain the advantage of the error fixes at least. Cheers --RexxS (talk) 13:54, 28 February 2018 (UTC)

Major update

The module has now been synchronised with the sandbox module, which itself is synchronised to en:Module:WikidataIB/sandbox. This brings a number of efficiency gains to the code, as well as implementation of many new features. The documentation has now been updated to explain the additional calls and parameters. --RexxS (talk) 23:25, 28 May 2018 (UTC)

Function to return location chain

Following the discussion at d:Wikidata:Project chat #Info Commons draws from Wikidata, I've created a basic function "location" in Module:WikidataIB that traverses the "located in the administrative territorial entity (P131)" chain up to the top level, returning the labels on each step:

• {{#invoke:WikidataIB |location |qid=Q2935180}} → Seattle, King County, Washington, Pacific Northwest, Washington, Pacific States Region

If this algorithm is acceptable, we can refine the code to use sitelinks, and the shortest short name (P1813) where there are several in a given language (for USA there are USA, America, and United States). What do folks think? --RexxS (talk) 16:52, 19 June 2018 (UTC)

@RexxS: Looks good for a start. Probably worth asking @Nikkimaria: for comments (maybe on enwp) since they've provided detailed feedback on {{Wikidata location}} before. Thanks. Mike Peel (talk) 18:11, 19 June 2018 (UTC)

Here's fine :-)

With regards to using shortest short name, I'm anticipating that in some cases that would be ambiguous - eg. both Los Angeles and Louisiana list LA as a short name, so "LA, USA" could be understood as either to someone not looking at the back-end logic. Nikkimaria (talk) 21:59, 19 June 2018 (UTC)

Thanks, Nikkimaria. I'm only using the short name for the highest-level territory, so we get USA instead of United States of America, which I think is usual practice for infoboxes. It should be internationalised here, as well. --RexxS (talk) 22:13, 19 June 2018 (UTC)

USA isn't typically used on enwiki, but here probably not a concern. However, what happens when only a high-level territory is listed - would we end up with just "USA"? Nikkimaria (talk) 22:52, 19 June 2018 (UTC)

We would get:

• {{#invoke:WikidataIB |location |qid=Q30}} →

although I could change that behaviour to give the full label when it's the only item. We could even make a special case for USA and omit it when it's not the only item. What about "King County"? Should we omit that? Is there an algorithmic means of determining which items are worth omitting? e.g. if there are 5 items, omit the middle one (!??) --RexxS (talk) 00:50, 20 June 2018 (UTC)

Update: @Nikkimaria: In the sandbox:

• Camlin Hotel (Q2935180): {{#invoke:WikidataIB/sandbox| location |qid=Q2935180}} → Seattle, King County, Washington, Pacific Northwest, Washington, Pacific States Region
• United States of America (Q30): {{#invoke:WikidataIB/sandbox |location |qid=Q30}} →

Is that better? --RexxS (talk) 00:55, 20 June 2018 (UTC)

I'd say do "United States" when standalone, and generally speaking counties can be omitted IMO. Nikkimaria (talk) 02:18, 20 June 2018 (UTC)

@Nikkimaria: "United States" done - see above. However, all top-level territories are currently rendered by their short name where it exists (except for USA which is omitted). Special rules like the ones for USA can be expanded for other places/languages on demand.:

• Shanghai Pudong International Airport (Q36420): {{#invoke:WikidataIB/sandbox| location |qid=Q36420}} → Pudong, Shanghai, Yangtze River Delta Economic Zone, PRC
• People's Republic of China (Q148): {{#invoke:WikidataIB/sandbox |location |qid=Q148}} →
• Maxixe (Q525118): {{#invoke:WikidataIB/sandbox| location |qid=Q525118}} → Inhambane Province, Mozambique
• Mozambique (Q1029): {{#invoke:WikidataIB/sandbox |location |qid=Q1029}} →

I think we probably ought to keep the country with the exception of USA for English speakers, because we just don't know programmatically what countries are obvious. Would that be acceptable? --RexxS (talk) 17:24, 20 June 2018 (UTC)

@RexxS: Exclude counties, not countRies ;-) Agree countries should generally be included. Nikkimaria (talk) 22:36, 20 June 2018 (UTC)

@Nikkimaria: d'oh! That's my poor old eyes letting me down again. I'll have to have a think about how I can algorithmically identify a county. It looks like a can of worms, first because there are English counties (like Staffordshire) that are often necessary to disambiguate English towns, and second because King County (Q108861) is an instance of county of Washington (Q13415369). I'd need a look-up table of 50 entries (one for each state) just to identify a US county, which would be an unwelcome complication. The situation in England is actually worse. I've cleaned up the chain, but look at Codsall railway station (Q2455479):

• {{#invoke:WikidataIB/sandbox |location |qid=Q2455479}} → Codsall, South Staffordshire, Staffordshire, West Midlands, England

That will take some sorting out. --RexxS (talk) 23:04, 20 June 2018 (UTC)

@RexxS: It's probably best if it doesn't show the name at the start - in the first example, "Camlin Hotel" shouldn't show, it should start with "Seattle". Thanks. Mike Peel (talk) 20:31, 20 June 2018 (UTC)

@Mike Peel: I guess you're thinking about using this directly in an infobox, where the name of the page doesn't need to be there. Agreed. But I think there may be multiple use cases, some which may need the starting item, so this time, I've created yet another parameter |first= which is true/false (or yes/no or 1/0), and switches whether the first item is returned (true) or not (false). I've set it to 'false' by default, so it can be omitted if you don't want the first item. In Module:WikidataIB/sandbox:

Testing location

Camlin Hotel (Q2935180)	{{#invoke:WikidataIB/sandbox |location |qid=Q2935180 |first=yes}}	Camlin Hotel, Seattle, King County, Washington, Pacific Northwest, Washington, Pacific States Region
United States of America (Q30)	{{#invoke:WikidataIB/sandbox |location |qid=Q30 |first=yes}}	United States
Shanghai Pudong International Airport (Q36420)	{{#invoke:WikidataIB/sandbox |location |qid=Q36420 |first=yes}}	Shanghai Pudong International Airport, Pudong, Shanghai, Yangtze River Delta Economic Zone, PRC
People's Republic of China (Q148)	{{#invoke:WikidataIB/sandbox |location |qid=Q148 |first=yes}}	People's Republic of China
Maxixe (Q525118)	{{#invoke:WikidataIB/sandbox |location |qid=Q525118 |first=yes}}	Maxixe, Inhambane Province, Mozambique
Mozambique (Q1029)	{{#invoke:WikidataIB/sandbox |location |qid=Q1029 |first=yes}}	Mozambique
Camlin Hotel (Q2935180)	{{#invoke:WikidataIB/sandbox |location |qid=Q2935180}}	Seattle, King County, Washington, Pacific Northwest, Washington, Pacific States Region
United States of America (Q30)	{{#invoke:WikidataIB/sandbox |location |qid=Q30}}
Shanghai Pudong International Airport (Q36420)	{{#invoke:WikidataIB/sandbox |location |qid=Q36420}}	Pudong, Shanghai, Yangtze River Delta Economic Zone, PRC
People's Republic of China (Q148)	{{#invoke:WikidataIB/sandbox |location |qid=Q148}}
Maxixe (Q525118)	{{#invoke:WikidataIB/sandbox |location |qid=Q525118}}	Inhambane Province, Mozambique
Mozambique (Q1029)	{{#invoke:WikidataIB/sandbox |location |qid=Q1029}}

Is that better? --RexxS (talk) 22:07, 20 June 2018 (UTC)

@RexxS: That looks good, thanks. I'm playing around with a potential new template at User:Mike Peel/Depicts at the moment, and this fits in there nicely - see File:7m telescope, Jodrell Bank Observatory.jpg for a live example. Thanks. Mike Peel (talk) 22:43, 20 June 2018 (UTC)

@Mike Peel: That's excellent, but... if Jodrell Bank Observatory (Q1569783) is located in the administrative territorial entity (P131) of Lower Withington (Q6693911), how come Lovell Telescope (Q555130) is located in the administrative territorial entity (P131) of Cheshire East (Q1070590)? Have fun :) --RexxS (talk) 23:17, 20 June 2018 (UTC)

Date language

Can we get this date:(1 September 1945  {{#invoke:WikidataIB|getValue|P569|qid=Q57480|fwd=ALL}}) in user lang "{{int:lang}}" as Module:Wikidata date: 1 September 1945{{#invoke:Wikidata date|date|item=Q57480|property=P569}} ? --Mr. Ibrahem (talk) 14:43, 17 August 2018 (UTC)

Internationalization

For the purposes of improved internationalization support I think you might consider updating this module to use Module:Complex date for formatting BCE/Decade/Century dates and Module:Ordinal in place of makeOrdinal. —RP88 (talk) 11:20, 4 September 2018 (UTC)

List of qualifiers

I think it may be useful if we allowed a list of requested qualifiers to return. Until now, the code has accepted |qual=ALL, |qual=DATES, |qual=P1234 (a single property). I can see the potential for returning more than one qualifier, so I've created code in Module:WikidataIB/sandbox that parses a list of parameters, separated by any punctuation character, and then sequentially returns the values of the qualifiers that have each of those properties, if present.

For example at place of burial (P119) for Gunnar Sträng (Q354112):

Code	Result
{{#invoke:WikidataIB/sandbox |getValue |P119 |fwd=ALL |osd=no |qid=Q354112 |linkprefix=":" }}	Norra begravningsplatsen
{{#invoke:WikidataIB/sandbox |getValue |P119 |fwd=ALL |osd=no |qid=Q354112 |linkprefix=":" |qual=ALL}}	Norra begravningsplatsen (59°21′16.42″N 18°1′14.45″E, Gunnar Sträng 1906 1992, Kvarter 14B, gravnummer 227, 2214B 00227, 1992)
{{#invoke:WikidataIB/sandbox |getValue |P119 |fwd=ALL |osd=no |qid=Q354112 |linkprefix=":" |qual=P965}}	Norra begravningsplatsen (Kvarter 14B, gravnummer 227, 2214B 00227)
{{#invoke:WikidataIB/sandbox |getValue |P119 |fwd=ALL |osd=no |qid=Q354112 |linkprefix=":" |qual=P965, P585 |qsep=" -- "}}	Norra begravningsplatsen (Kvarter 14B, gravnummer 227 -- 2214B 00227 -- 1992)
{{#invoke:WikidataIB/sandbox |getValue |P119 |fwd=ALL |osd=no |qid=Q354112 |linkprefix=":" |qual=P965; P625 |qsep=": "}}	Norra begravningsplatsen (Kvarter 14B, gravnummer 227: 2214B 00227: 59°21′16.42″N 18°1′14.45″E)
{{#invoke:WikidataIB/sandbox |getValue |P119 |fwd=ALL |osd=no |qid=Q354112 |linkprefix=":" |qual=P965/P585/P625 |qsep="; "}}	Norra begravningsplatsen (Kvarter 14B, gravnummer 227; 2214B 00227; 1992; 59°21′16.42″N 18°1′14.45″E)
{{#invoke:WikidataIB/sandbox |getValue |P119 |fwd=ALL |osd=no |qid=Q354112 |linkprefix=":" |qual=P965. P625. P585 |qsep=" – "}}	Norra begravningsplatsen (Kvarter 14B, gravnummer 227 – 2214B 00227 – 59°21′16.42″N 18°1′14.45″E – 1992)

This will allow finer control of the order that qualifiers are returned, and obviates the potential issue of extra qualifiers being added if |qual=ALL is used. @Mike Peel: is this likely to be useful? --RexxS (talk) 22:55, 26 September 2018 (UTC)

Ability to categorise

Placing a colon before the word "Category" in a link will create the link and display it. Sometimes we wish to do that. Then we can call something like:

• {{#invoke:WikidataIB |getValue |P26 |qid=Q151973 |fwd=ALL |osd=no |maxvals=1 |linkprefix=":"}}

A simple link to an existing category will place the page in that category. Sometimes we wish to do that. Then we can call something like:

• {{#invoke:WikidataIB |getValue |P26 |qid=Q151973 |fwd=ALL |osd=no |maxvals=1 |linkprefix= }}

Now, if User:Verdy p continues to edit-war a change that they haven't thought through like this and this, which places a colon before every link, then we won't have the ability to place pages into categories even when we want to. I'm reverting once more. --RexxS (talk) 15:01, 12 October 2018 (UTC)

@Verdy p: Please do not edit war in a module used in around 2 million categories. If need be, I'll protect the page, but that makes it more difficult for RexxS to develop it. Please discuss the change here first (and use the sandbox!). Thanks. Mike Peel (talk) 15:22, 12 October 2018 (UTC)

But that template now applies categories everywhere a link to a "related" category is desired. When that infobox is used in a category notably (which is the most frequent use).

These links are displayed most often as values of a Wikidata property. This "related" linki does not mean it applies to the "nature" of the entity described in the wiki page displaying the infobox. :: In general the autocategorization of a page by jusst displaying the infobox is strongly undesired : it is just enough for the box to display the info and then use it as a "hint" to categorize the page normally and explicitly in that related category... or another subcategory on Commons that does not have a Wikidata entity for it, or not at all because that information displayed does not alter the categoization of the page itself.

You addition of this feature is also "undocumented" and creates artefacts on the Commons categorization system, it does not display the info at all in the infoboxes. verdy_p (talk) 19:15, 12 October 2018 (UTC)

@Verdy p: Please can you give an example category where this problem is occurring? It may be a bug in the configuration of {{Wikidata Infobox}}. Thanks. Mike Peel (talk) 19:59, 12 October 2018 (UTC)

@Verdy p: The template does not apply 'categories everywhere a link to a "related" category is desired'.

• {{#invoke:WikidataIB |getValue |P26 |qid=Q151973 |fwd=ALL |osd=no |maxvals=1 |linkprefix=":"}} → Elizabeth Taylor 

Where is it applying a category? It isn't. We control that by adding the colon where needed via the |linkprefix= parameter. That allows us to have a choice between displaying a link or placing the page in the category. Your change removes that choice, so I reject it. You don't get to decide what should be displayed and what should be categorised in any particular application. We leave that to the designer of the infobox, and you need to stop trying to dictate to Mike (or any other designer) how he can or can't use the tools I've been developing for them. --RexxS (talk) 21:17, 12 October 2018 (UTC)

You made the categorization implicit instead of explicit, this is what has broken the usage (notably when linkprefix now takes a default "" value instead of remaining nil. Autocategorization should never occur implicitly, as the Wikidata ontology (which is bery general and not specific to Commons) is not the same as Commons categories (there are too many exceptions). An infobox is just there to "inform" about what is in Wikidata (or elsewhere) but it does not directly drive how Commons categories are structured. It just has to display candidate links to Categories to duisplay labels. What you did was to turn functions that are intended to display labels into an unexpected categorization system: this separate use should have its own separate API, but it should not tbe the default for the infobox itself everywhere a label is displayed. verdy_p (talk) 21:37, 12 October 2018 (UTC)

Complete and utter nonsense. There is no "broken usage". If you ever wrote any Lua code, you'd know that you want strings to be empty, not nil, for ease of concatenation. The categorisation is an artefact of links on Commons and this module is internationalised for use on all Wikimedia projects. If you don't want categorisation, you simply set |linkprefix=":", just as you do when writing a link to a category on any project: [[:Category:Elizabeth Taylor]] creates a link on any project, just as it does here. Any infobox on Commons where this is used sets |linkprefix=":" anywhere it wants to display, and sets |linkprefix="" anywhere it wants to categorise. And don't tell me what the functions are intended to do; I wrote them and I know what I intended when I did so. They are intended to give an infobox designer complete control over the format of what is returned from Wikidata, and I don't intend to be dictated to by you that I have to create unnecessary restrictions on that flexibility, just to satisfy your misguided sense of what the default ought to be.

Haven't you understood yet that it is straightforward to add a colon to a linkprefix that is empty, but it is a kludge to try to remove one which has already been hard-coded by your tampering. Get it through your head that the default for the module is not the same as the default for the infobox. Why on earth am I being forced to waste my time explaining to somebody who's not capable of understanding? --RexxS (talk) 22:01, 12 October 2018 (UTC)

Your language is repeatedly unacceptable. You are just obstinating in not admiting that this deviation of labels intended to be displayed are doing incorrect things that you refuse to see. And yes I have "ever" written Lua code, you're not alone! You may make errors or bugs like anyone but obstinating in rejecting them instead of investigating is unqualifiable, just like your repeated agressive terms in this discussion.

And your justification against "nil" is simply bad: the functions in question can just consider "nil" to mean that no categoization should even occur. So I suggest now in Lua:

if lprefix=nil then lprefix=':' end"

This way the implicit default behavior will then NOT perform ANY categorization, but you'll still be able to pass |lprefix= with an emptry string for your specific undocumented goal of autocategorization, using inference from Wikidata, which you'll need to discuss and make approve on Commons (and that you never tested before applying it silently to zillions pages using the infobox: this should have been done first by some tests on more limited number of pages using your explicit parameter, and possibly with tracking for debugging, because autocategozation is a plea to work with). verdy_p (talk) 22:55, 12 October 2018 (UTC)

You are simply telling untruths now. I have a 100% track record in fixing any bugs that are reported here and at Template talk:Wikidata Infobox. Anybody can look through the archives of these pages and see for themselves. You, on the other hand, have done nothing here but mess around needlessly with code that is working as intended. You even fiddled around adding unnecessary extra code to the roundto() function so that it accepts negative numbers - but the function is never passed a negative number unless there is an error in Wikidata and I would rather see that error than hide it.

The "derivation of labels" is never "doing incorrect things" as you claim. Give me an example of where this happens.

You have little understanding of writing Lua code or you would know that you can't concatenate nil or perform string functions on it. That's why any decent Lua programmer will change variables that are holding strings from nil to empty at the earliest opportunity.

If you had any experience of implementing Lua solutions, you'd know what a really bad idea it is to try to make a distinction between nil and an empty string for parameters that are passed. You can't use an infobox that behaves differently between omitting a parameter (which passes nil) and writing |linkprefix= (which passes an empty string). Editors just won't get that a difference exists and will often write an infobox with a full list of empty parameters. With your bad idea, they would then be continually complaining when the behaviour turns out not as they expected. You always sanitise passed parameters at the first opportunity to avoid those sort of problems.

You have no standing to insult me and call my justification "bad". The functions in question simply consider an empty linkprefix to create a link, [[ linktarget | displaytext ]], just the same here as in any other project. Because simple links to the Category: namespace are interpreted as a directive to categorise, rather than display the link, we then add a colon prefix to the linktarget text. We write [[:Category:Elizabeth Taylor]] to display the link and use the empty prefix [[Category:Elizabeth Taylor]] when we want to categorise. Why should we change the behaviour of a link prefix from the convention we use when writing text? It's counter-intuitive and removes the ability for the call to create a directive to categorise.

The way the code works at present, we have the option of displaying a link (linkprefix=":"), or of categorising the page (linkprefix="" or omitted), using exactly the same conventions as when writing text. If you add if lprefix="" then lprefix=':' end" then there is no way to create the ability to categorise. Removing flexibility to fix problems that don't exist is incredibly deluded thinking.

My tone is that of complete exasperation with your continual, repeated failure to give any examples of these problems that you pretend exist. So give me an example of where these problems occur. --RexxS (talk) 10:50, 13 October 2018 (UTC)

"You have little understanding of writing Lua code". This is an unproven assertion and personal attack (of course I know that you can't concatenate a nil value to strings).

A "decent" Lua programmer (sic!) does not change **blindly** an unspecified nil value into an empty string when this causes an incorrect default (which is in fact NEVER expected when it causes unexpected behavior).

A "decent" Lua programmer (sic!) chooses a **correct** default (this is absolutely not what you have made, your assumption here was incorrect as it broke the expected usage for another experimental usage that was never tested, and in fact never used, unless you show me a valid demonstration case, that I've not found anywhere in this infobox, used systematically without this internally generated quirk parameter !). verdy_p (talk) 15:39, 13 October 2018 (UTC)

NO I have NEVER insulted you, but you have constantly agressed me (and really insulted me repeatedly) in all your messages for this topic. Saying that your assumption is "bad" is certainly not an insult like you think with your anticollaborative and "professoral" attitude, which just denies the facts and instead returns agressions I never initiated against you like you constantly did.

See Category:Reinette du Canada, you'll see that the template incorrectly categorizes in Category:Normandy for what is normally a label displayed after a approximate date as an indication of origin (in the parentheses, just before the comma and the following link to "circa"). This is a proof, absolutely not imaginary. That label should link to the category, not perform ANY categorization.

Stop your constant abusive (and nonsense) aggressions, and your obstination of saying you cannot do bugs. The bug is real ! There are countless other examples where labels linking to categories are actually categorizing incorrectly and not displaying the expected label. Saying that your code is breaking functionalities is also not an insult, it is a fact, you have to admit it, independantly of your efforts you made to implement the function (siliently without ever discussing it, documenting it, testing it really and ask for approval).

I'm not here to loose your time but your obstation is a severe loss of time for all others and your constant attitude is completely unacceptable, totally anticollaborative and fully contradicting the Commons policy.

If you refuse to admit you can do bugs, and reject your own faults to others, you have NOTHING to do in Commons. In addition you make constant false personal assertions against me without any proof (and it's easy to proove that you're unable to perform any basic search or investigation for correctly reported problems, anbd notably by changing unilaterally and secretly a function that was not designed for your goal: autocategorization by inference from Wikidata has NEVER been discussed or approved, and it has NEVER been really experimented but you have made it in a template used by millions pages where experimentation and bug tracking should have been used since the begining before applying it globally).

I proposed a simple solution (an unspecified linkprefix, i.e. nil, MUST be interpreted like if it was ":" by default to force a link, and certainly not like if it was an empty string which forces categorization instead), you refuse it abusively by constantly using war terms. Stop your personal war. verdy_p (talk) 14:01, 13 October 2018 (UTC)

Now show me any example where you need and use "linkprefix=" with an empty string to force an alternate categorization from Wikidata.

I've found no valid example anywhere in Commons, unlike the countless pages where the default mising linkprefix (nil) causes unexpected categorization instead of displaying the expected links infoboxes (this is a proof that you never experimented your change and never investigated seriously your undiscussed extension, for a usage that is in fact not expected anywhere in these infoboxes). verdy_p (talk) 14:32, 13 October 2018 (UTC)

• I've reverted the module to the 'stable' version, and I have protected it, to stop this edit warring affecting millions of pages. Please use the sandbox for future changes, and we can sync them across when agreed. Thanks. Mike Peel (talk) 14:48, 13 October 2018 (UTC)
• With Category:Reinette du Canada - there's a misconfiguration in {{Wikidata Infobox}}, the fix for which is in the sandbox at {{Wikidata Infobox/sandbox}}. I'll deploy that fixed version soon. Thanks. Mike Peel (talk) 14:52, 13 October 2018 (UTC)

Note: the fix for using a different default made the page Category:Reinette du Canada really work as expected.

Reverting this fix breaks it again. Assuming that linkprefix=nil is the same as linprefix="" is simply wrong. I gave the proof, never insulted anyone like Rexx did constantly and anticollaboratively. There are countless examples on the wiki where autocategorization issues unexpectedly (and incorrectly) just because they include this untested/undiscussed infobox "feature" applied everywhere without any testing. verdy_p (talk) 14:58, 13 October 2018 (UTC)

@Verdy p: I've updated {{Wikidata Infobox}} now, so that bug should be fixed. Let me know if you spot it anywhere else. Thanks. Mike Peel (talk) 15:01, 13 October 2018 (UTC)

Note: your "fix" in {{Wikidata Infobox/sandbox}} is just incomplete ("Wikidata Infobox/line" is used in many other places where linkprefix is not specified, and then will assume autocategorization). It's just much simpler (and safer) to fix in in "Module:WikidataIB" by jsut changing the default linkprefix=nil (unspecified) to behave like linkprefix=":" (NOT like linkprefix="") and it dramatically simplifies the use of "Wikidata Infobox/line" and "Wikidata Infobox" where this link parameter is NEVER used (I've not been able to locate any place where one really wants the undocumented/untested behavior as linkprefix="" for force categorization instead of links). We should not be required to pass "|qlinkprefix=:" everywhere in the infobox implementation. In fact, everywehere this parameter should not even be needed and passed, as a ":" value should clearly be the default interpretation of a nil value. verdy_p (talk) 15:05, 13 October 2018 (UTC)

Other examples where the incorrect assumption causes bugs in your sandbox:

work period start -->{{Wikidata Infobox/line | P2031 | {{#invoke:WikidataIB | getValue | rank=best | P2031 | name=workstart | qid={{getQID | qid={{{qid|}}}}} | spf={{{suppressfields|}}} | fwd=ALL | osd=no | noicon=yes | qual=ALL}} }}<!--

work period end -->{{Wikidata Infobox/line | P2032 | {{#invoke:WikidataIB | getValue | rank=best | P2032 | name=workend | qid={{getQID | qid={{{qid|}}}}} | spf={{{suppressfields|}}} | fwd=ALL | osd=no | noicon=yes | qual=ALL}} }}<!--

florit -->{{Wikidata Infobox/line | P1317 | {{#invoke:WikidataIB | getValue | rank=best | P1317 | name=florit | qid={{getQID | qid={{{qid|}}}}} | spf={{{suppressfields|}}} | fwd=ALL | osd=no | noicon=yes | qual=ALL}} }}<!--

...

call sign -->{{Wikidata Infobox/line | P2317 | {{#invoke:WikidataIB | getValue | rank=best | P2317 | name=callsign | list=ubl | qid={{getQID | qid={{{qid|}}}}} | spf={{{suppressfields|}}} | fwd=ALL | osd=no | noicon=yes | qual=ALL}} }}<!--

...

yard number -->{{Wikidata Infobox/line | P617 | {{#invoke:WikidataIB | getValue | rank=best | P617 | name=yard number | list=ubl | qid={{getQID | qid={{{qid|}}}}} | spf={{{suppressfields|}}} | fwd=ALL | osd=no | noicon=yes | qual=ALL}} }}<!--

...

point in time -->{{Wikidata Infobox/line | P585 | {{#invoke:WikidataIB | getValue | rank=best | P585 | name=pointintime | qid={{getQID | qid={{{qid|}}}}} | spf={{{suppressfields|}}} | fwd=ALL | osd=no | noicon=yes | qual=ALL}} }}<!--

...

IATA airport code -->{{Wikidata Infobox/line | P238 | {{#invoke:WikidataIB | getValue | rank=best | P238 | name=iata | link=no | list=ubl | qid={{getQID | qid={{{qid|}}}}} | spf={{{suppressfields|}}} | fwd=ALL | osd=no | noicon=yes | qual=ALL}} }}<!--

ICAO airport code -->{{Wikidata Infobox/line | P239 | {{#invoke:WikidataIB | getValue | rank=best | P239 | name=iata | link=no | list=ubl | qid={{getQID | qid={{{qid|}}}}} | spf={{{suppressfields|}}} | fwd=ALL | osd=no | noicon=yes | qual=ALL}} }}<!--

...

taxon vernacular name -->{{#ifeq:{{VNNoDisplay|useWikidata={{getQID | qid={{{qid|}}}}} }}|||{{Wikidata Infobox/line | Q502895 |2=<div class="mw-collapsible mw-collapsed">{{VNNoDisplay|useWikidata={{getQID | qid={{{qid|}}}}} }}</div> }} }}<!--

What a nightmare ! Everywhere you have to pass two additional parameters when the default nil should behave just like ":". I'm sure there are many other locations in this unnecessarily complex implementation. Why not my simple solution centralized in Module:Wikidata, and then removal of these unnecessary parameters in your sandbox ? As a consequence the bug will reoccur at any time when one will add new infolines in the infoboxes (notably for qualifiers). I've still not seen ANY place where one wants the other untested interpretation of nil as an empty string.

Note also that qualifiers are still displayed ambiguously (for example a start date, or end date, or just date are not distinguished visually, there's no indication of the semantic of the qualifier itself, just the indication of the value of this qualifier, this is a problem from qualifiers like "except", "end date", "applies to"...). verdy_p (talk) 15:25, 13 October 2018 (UTC)

I must add that the supposed "ability to categorize" actually does not work properly. The way it is done, it will generate a categorisation with an incorrect sort key after it (it uses the translated label, which depends on the UI language, varying between each visitor, and even this key is wrong as it is just a string representing the target category page, and not even the source page to categorize).

So that "ability to categorize" using {{#invoke:WikidataIB | getValue | ... }} is simply wrong, and the extra parameters added for that (which requires passing a link prefix set to ":" for ALL normal usage of this API, but now takes a default link prefix "" to categorize instead) are really bad (in fact not needed at all).

What I poposed was correct: using a default link prefix to behave as if it was ":" is the only working option. The option with the link prefix set to an empty string is completely wrong and pollutes/complicates all the rest, introducing bugs in various places of the infobox, which was NOT designed at all for that purpose.

If you want to support autocategorization, 'you'll need another API but not {{#invoke:WikidataIB | getValue | ... }} and you'll need to test it properly (in which you will also never need any linkPrefix set to the empty string, but in which you'll provide a way to specify a sort key to generate, or by default not generate any sort key at all, i.e.:

[[Category:{{#invoke:WikidataIB | getCategory | ... }}]], or

[[Category:{{#invoke:WikidataIB | getCategory | ... }}|{{{sortkey|}}}]]

but certinaly 'not any:

[[Category:{{#invoke:WikidataIB | getCategory | ... }}|{{#invoke:WikidataIB | getLabel | ... }}|]]

like it is now defined incorrectly.

So please remove this unnnecessary and really broken havoc from {{#invoke:WikidataIB | getValue | ... }}, and then cleanup all the unnecessary link parameters set to ":" from Template:Wikidata Infobox/line which just pollutes, complicates, and slows down everything.

There was then nothing wrong in the fast fix I provided in WikidataIB (making an unspecified link prefix, or prefix set to nil, behave exactly like if it was ":"). This is for now the only stable solution.

All the rest ("Ability to categorise" with the "getValue" function in this module) is simply incorrect, has never been tested, has never been discussed, has not been documented properly (because it actually does not work), and not been approved (the Wikidata ontology does not match exactly the Commons categories, even if Wikidata contains some properties linking topics to categories, they are still not in sync and not really checked for now: using these Wikidata properties for autocategorization on Commons will create severe havoc in Commons, by moving many files unexpectedly and randomly), and actually not used at all (there may have been some isolated test cases, but I want to know where: I asked for it, but got no reply at all, visibly such fact is voluntarily hidden by @RexxS: who knows that these isolated tests have actually failed and were removed by him, and that's why he does not give any working example here on Commons !)

If you remove this incorrect ability to categorize, then the link prefix parameter in "getValue" set to nil, or "", or just ":" will have no difference of effect, and "getValue" will only generate visible texts or visible links, but never any categorization (which has never been expected there).

So test your non-working "autocategorization" feature in a separate sandbox (where you'll define a new separate function ouside "getValue"), remove this code from "getValue" (make sure it will never generate any categorization), cleanup the unnecessary (and still not correct) code added to the infobox templates, then properly test your sandbox (whose usage can be tracked outside the zillions pages currently using the infofobox and that don't want any autocategorization).

Later you can ask the community if and how we'll manage autocategorization (I'm sure there will be plenty of exceptions to the generated categorization scheme on Commons, so you'll also need a way to disable it), and if it gets approved you'll be able to integrate this separate function in the module and in the infobox templates. verdy_p (talk) 09:52, 14 October 2018 (UTC)

Summary

Here's the summary of my position:

1. This module is in use on 59 projects. Its purpose is to provide flexible tools that infobox designers can use to place information from Wikidata into infoboxes. I have worked – and continue to work – to ensure that the tools it provides can meet any foreseen need for that purpose.
2. The module returns wikibase-items just as anyone would expect: as simple links [[ link | displayed text ]]. If the link needs to be modified by prefixing it (e.g with a namespace), then we have the parameter |linkprefix= which prefixes the link with its value. The same applies for applications that need to suffix the link (|linkpostfix=), or to prefix the displayed text (|prefix=), to suffix the displayed text (|postfix=). That is consistent between each parameter and in all projects. The infobox designer has complete control over the returned wikitext. The same applies to linked qualifiers and to string items that need to be displayed as links.
3. If the linkprefix parameter is blank or omitted, then the returned link has no link prefix. If the linkprefix parameter is set to ":", then the returned link has ":" as its link prefix. That is entirely logical and is the behaviour that infobox designers across 50+ projects would expect.
4. That behaviour works perfectly well and is perfectly stable in 2 million infoboxes here, and in innumerable other infoboxes in other projects. Any reports of bugs in either {{Wikidata Infobox}} or Module:WikidataIB are dealt with immediately, and the track record of fixes speaks for itself. There are currently zero outstanding bug reports or feature requests for the module.
5. There have been zero requests from infobox designers to change the behaviour of linkprefix.
6. Any change that hard-codes a link prefix for all links removes the ability to create simple links.
7. It is bad design for a module that receives parameters from an infobox to produce different behaviours when a parameter is omitted (nil is passed to the module) from when the parameter is empty (an empty string is passed to the module). Although infobox designers understand the difference, all editors will assume that the two cases give the same result and will freely interchange them. Therefore modules have to regularise parameters as they are passed, and it is sensible to use the empty string as the default for variables that will hold strings because all of the string functions can be applied to the variable when it is empty, while they cause an error if it is nil.

@Verdy p: You claim "There are countless examples on the wiki where autocategorization issues unexpectedly (and incorrectly) just because they include this untested/undiscussed infobox "feature" applied everywhere without any testing." That's a lie, and you need to retract it. If there are "countless examples" in infoboxes, why don't we see any complaints abut them? Why can't you point to any of these "countless examples"? Have you still not understood that there's a difference between the implementation of each infobox (which can shape the default behaviour of the calls to meet its needs) and the implementation of the module (which offers as broad a range of functionality to the infobox designer as possible)? --RexxS (talk) 16:26, 14 October 2018 (UTC)

You still forget that this extension does not work at all for categorization (it uses translated labels of the target category as if it was a label to display, but the generated syntax puts it in the sort key of that category, meaning that it will categorize all pages using that module this way (with linkprefix=empty or "") in the target category under the same non-sense sortkey.

I maintain my position! This unexpected extension of "WikidataIB/getLabel" for categorization works nowhere and creates unnecessary complication (and bugs as seen above, not all of them resolved, because it still requires complex parametrization for something that is clearly not needed at all, and not used at all as it simply does not work as you expect !). It won't work either in any other 59 wiki projects (where you want them to force everywhere the addition of linkprefix=":" for all valid cases of use of this module).

So yes create another separate API for categorization (you'll need another code to determine what you currently incorrect place in the sort key).

You don't understand that this is just an unnecessary pollution of the usage. And you've not shown any valid example where categorization with this categorization actually works as expected (I'm confident you cannot find any one, except in a few trial pages where it just caused problems and were reverted, causins severe instability in the local categorization system of each wiki where your module version was deployed). The ONLY working usage for now is with linkPrefix=":" (or linkPrefix ~ /:.*/ with a regexp to match also files/images, to render links to them as texts instead of rendering the file/image itself as an HTML object in a sized box) specified everywhere meaning that this parameter is just unnecessary as this is the only valid option).

As well my proposed change did not alter any way the possibility of creating links with labels (so your claim #6. is wrong), because this ":" is in fact now unnecessarily required for that valid usage.

My change did not make your claim #4 invalid (it only checks the usage for rendering labels with links and nothing else, and this is the only effective usage everywhere).

For your claims #3 and #7, I say what you can do: create a separate API for categorization (and test it separately) and drop the ability of categorizing with that function. In that case there's no need of the parameter at all: the parameter can be ignored, and all will behave internally as if it was ":" like now to create links (so passing "", ":", or nil will make no difference at all).

Even if you keep a linkPrefix parameter for passing an optional namespace, it must still create a link, so the only valid prefixes are those starting by ":" (including ":Image:" or ":File:", or ":Category:": these special namespaces MUST be prefixed by a ":" and the function has to check that (It is not valid to pass "Image:", "File:", "Category:" there, as this won't generate a text label but will create something else than a textual link! What is after the first "|" within the double square brackets is not a text label, and for images/files they are even parsed in a more complex way)

For your claim #6, this is false as demonstrated in the bugs found now in the overly complex infobox subtemplates (where the parameter is forgotten and must always be set now to ":" everywhere).

All what you say above only concerns the usage as textual labels (all of them requiring linkPrefix=":", otherwise it will bug), but nowhere for categorization (necessarily using linkPrefix="", or nil by default with this implementation). I really ask you to ask your code for review as it was never tested, and cannot be used, and just complicates everything else on the 59 all wikis you cite.

So here is my summary. You affirm:

• Placing a colon before the word "Category" in a link will create the link and display it. Sometimes we wish to do that. Then we can call something like:
  {{#invoke:WikidataIB |getValue |P26 |qid=Q151973 |fwd=ALL |osd=no |maxvals=1 |linkprefix=":"}}.
  This is not "Sometimes we wish to do that", but "Always we want to do that." (and this is the only case were it works: the linkPrefix=":" is now always required on zillions page of this wiki, as well as all other wikis where your extension has been deployed without any discussion and testing).
• A simple link to an existing category will place the page in that category. Sometimes we wish to do that. Then we can call something like: ...
  This does not work and has never been tested, it is actually used nowhere !
  Change "Sometimes we wish to do that" by "We never wish to do that. Then we can't call something like: ..."
  You've not demonstrated any valid use of this extension anywhere.

verdy_p (talk) 20:03, 14 October 2018 (UTC)

Replace Module:Wikidata?

In the past I tried to use original Module:Wikidata code and was never able to get it to work right, while I found the source code very hard to follow. As a result, I wrote general purpose Module:Wikidata label for fetching labels from wikidata in any language and several much more specialized modules. Usually I interact with Wikidata without additional modules. However functionality of Module:Wikidata is very important to couple modules and some templates. I worry that Module:Wikidata is no longer mantained and since it was never fully functional, we should switch templates and modules that use it to stable mantained codes, like Module:WikidataIB or in some narrow cases Module:Wikidata label or even new Lua functions from mw:Extension:Wikibase Client/Lua. RexxS, any chance you can look at some modules and templates that use it and see if they can be replaced with equivalent functions from stable modules? --Jarekt (talk) 19:35, 9 November 2018 (UTC)

Returning just a local (category-derived) label for a QID ?

I like the way the output of this module by default is in the form of links to Commons categories, using the name of the Commons category for the link label if possible (though presumably the latter is only the case in English?)

Would it be possible/useful to provide similar functionality for the QID itself, rather than the value of a specified property? This would give a result similar to {{Label}} and Module:Wikidata label, but (pinging @Jarekt: ) at the moment I think it's not possible to ask the label template to link by preference to a Commons category if available.

The application would be where one has a Q-value for a field in a file-description template (eg {{Map}}), and wants to be able to use it, with a wrapper template around it automatically 'doing the right thing'.

Of course that leaves the question, what is the right thing, how should an entry in such a template be linked? (Which is something both of you may have opinions on) Most often, at the moment, if the entries are hard-edited in, they probably are hard-linked to enwiki; perhaps in some cases with a language switch to one or two others. The template {{Label}} can be used to give a link to the wiki in user's current preferred language. But it seems to me that now we have such good and informative internationalised infoboxes, would it not be better to try to keep the reader on Commons, and therefore for preference link to the relevant Commons category (if available) ?

Interested to know what you both think. Jheald (talk) 23:40, 25 February 2019 (UTC)

{{Label}} as documented allows you to pick where you want to link to. For example {{label|Q5|link=commons}} gives "human". --Jarekt (talk) 03:11, 26 February 2019 (UTC)

@Jarekt: Thanks. But doesn't it prefer galleries over categories, when both are available? e.g. {{label|Q220|link=commons}} --> Rome. I'd prefer categories. Jheald (talk) 08:18, 26 February 2019 (UTC)

At least, I think I'd prefer categories. Where do you think links should go to from entries in file-description templates? Jheald (talk) 08:24, 26 February 2019 (UTC)

@Jheald: there are some routines in WikidataIB which return raw data that you might use to get what you want. You could look at getCommonsLink that returns, in order of preference: (1) the Commons sitelink of the Wikidata entity - (which is skipped if onlycat=true and it's not a category); (2) the Commons sitelink of the topic's main category of the Wikidata entity; (3) the Commons category of the Wikidata entity.

Optionally, you could construct a customised lookup by using followQid which uses a list of properties where the Wikidata item for the qid is examined for each property in turn, and if that property contains a value that is another Wikibase-item, that item's qid is returned, and the search terminates. So you could create a lookup that went through a number of properties to get the qid you wanted and then returned the label for that.

For Rome (Q220), category's main topic (P301), Commons category (P373), topic's main category (P910)

{{#invoke:WikidataIB |getCommonsLink |qid=Q220 |onlycat=true}} → Category:Rome

{{#invoke:WikidataIB |getLabel |Q220}} → Rome

{{#invoke:WikidataIB |followQid |qid=Q220 |props=P910, P373, P301}} → Q8682052

{{#invoke:WikidataIB |getLabel |{{#invoke:WikidataIB |followQid |qid=Q220 |props=P910, P373, P301}} }} → Category:Rome

You don't have to supply the qid if you're calling it from the connected page. Those are all raw text, but in the first or last cases, you can construct the Category link by surrounding the output by [[ ]], or by making use of {{If then show}} to catch empty values.

Qualifiers on unknown

@RexxS: @Joalpe: seems to have found a bug - {{#invoke:WikidataIB | getValue | rank=best | P571 | name=inception | linkprefix=":" | qlinkprefix=":" | qid=Q64870887| fwd=ALL | osd=no | qual=ALL}} should display the dates in the qualifiers - something like "Unknown (1800, 1850)" - but instead it just displays "Unknown". Can you have a look please? Thanks. Mike Peel (talk) 17:11, 2 July 2019 (UTC)

@RexxS and Mike Peel: Another solution is what we do here, on Wikipedia in Portuguese: [1], in which the term "Unknown" is not shown. There also appears to be a language bug: the term "Unknown" is frozen in English even for people who are using Commons in Portuguese. It should be showing "Desconhecido". I hope these comments are helpful. And again great job both of you: you rock! --Joalpe (talk) 17:49, 2 July 2019 (UTC)

@Joalpe and Mike Peel: That's a bigger issue than it seems. The easy part first: the string returned isn't frozen but is set in line 64 where i18n.Unknown is set to "Unknown". Using an internationalisation module in Module:WikidataIB/i18n will allow any language to display whatever they want for that string. Commons, of course, doesn't have that ability to internationalise via a module at the moment.

The tough part is knowing what to do with values marked as "somevalue" in Wikidata. Do we want to display anything? At present we use i18n.Unknown, but we could do away with that and use an empty string, but then we must anticipate the impact it may have elsewhere if another application is relying on an unknown value being identified.

Anyway, I've enabled returning qualifiers for unknown values in the sandbox:

{{#invoke:WikidataIB/sandbox | getValue | rank=best | P571 | name=inception | linkprefix=":" | qlinkprefix=":" | qid=Q64870887| fwd=ALL | osd=no | qual=ALL}} → unknown value (before 1850, after 1800) 

I could suppress the "Unknown" and the parentheses for just these cases; you'll have to let me know what you prefer. --RexxS (talk) 21:39, 2 July 2019 (UTC)

@RexxS and Mike Peel: Thanks for taking care of this! I think we can suppress the unknown -- as the date is actually known, just imprecisely -- and the parentheses. My sole concern is that we might be giving the impression that in the case at hand the house was built from 1800 to 1850 whereas it should be that it was built in an unknown year in the range 1800-1850. I am not sure how this can be modeled. --Joalpe (talk) 17:54, 4 July 2019 (UTC)

@Joalpe: That's a real concern for me as well. Let me think about that before we make any more amendments. What do you think, Mike? --RexxS (talk) 22:25, 4 July 2019 (UTC)

@RexxS and Joalpe: Sorry for the slow response. I like "Unknown (after 1800, before 1850)" - it communicates all of the information that has been recorded in Wikidata appropriately. "after 1800, before 1850" would also work, but then it's going to display differently from the case where there are no qualifiers, or different qualifiers. Other formats like "1800s" are modeled differently on Wikidata. It's important that this is displayed multilingually though - and perhaps unknown (Q24238356) should be used to display that so that it's using Wikidata's multilingual support rather than an i18n template? Thanks. Mike Peel (talk) 19:41, 10 July 2019 (UTC)

BTW, I've temporarily added the sandbox version to Category:Sítio da Candinha for testing. Thanks. Mike Peel (talk) 19:46, 10 July 2019 (UTC)

You're probably aware that the pattern <property> = somevalue / object named as (P1932) = <string> is quite widely used on Wikidata to record data where there is no item as yet for the value, but the source gives a string (eg a name of a person, or a publisher, or a place, etc). Since this is a particularly common pattern, it may be worth some specific consideration. Jheald (talk) 20:42, 6 July 2019 (UTC)

@Jheald: I think this is a different issue that should be in its own section. I'm not sure how important this is to implement, though, as it's either a formatting difference or a case for a separate Wikidata item in my experience. Thanks. Mike Peel (talk) 19:41, 10 July 2019 (UTC)

NL template nl:Sjabloon:Zijbalk tabel uitbraak SARS-CoV-2

Hi there,

I'm getting referred here from Meta, for my question about the sortable function in our template that is not working correctly. I'm noticing that for some reason the comma used in the number for India (among others) instead of a dot (commonly used to define thousands & millions in our language) is not recognized in our sortable table and therefore India is placed far at the bottom when using the sortable function of the column - which of course is incorrect.

Can you maybe suggest a solution for this? Help would be appreciated. Ciell (talk) 05:33, 27 April 2021 (UTC)

Incorrect categorization

The page is incorrectly categorized under Massimo Stanzione and Artemisia Gentileschi. Synthwave.94 (talk) 14:56, 6 May 2021 (UTC)

followQid - why does it return qid if no property values exist?

The followQid function is very difficult to use and mostly something you'd want to avoid due to the function returning the qid of the item, rather than property values, when no property value exists. The caller therefore has to perform the complex task of figuring out whether the qid(s) returned by the function are that of the property value or that of the original item.

Can the function be changed to only return qid(s) if there is a property value found, otherwise return null/nothing? Dhx1 (talk) 17:41, 15 June 2021 (UTC)

Drop coordinates rounding

{{Edit protected}}

I propose the following change: Special:Diff/593256463. As previously commented in Template talk:Wikidata Infobox#Odd coordinates, there doesn't seem to be any good reason to round coordinates the way it's currently done. For instance page Category:Aarhus Universitetshospital currently uses sandbox template and on this page given change moved map marker about 300 m to the southwest, matching the marker location displayed on Wikidata (d:Q12300343#P625). 2001:7D0:81DA:F780:D52:CBA1:A8AF:806A 06:55, 29 September 2021 (UTC)

•  Support, if it fixes the issue MSGJ (talk) 13:20, 19 October 2021 (UTC)

Also, recently it was reported that {{Object location}} and {{Wikidata Infobox}} link different coordinates' value if both use Wikidata (Template talk:Wikidata Infobox#weird coordinates behavior). Proposed change would also remove this discrepancy. 2001:7D0:81DA:F780:7DF4:FF2B:3016:C556 20:46, 11 November 2021 (UTC)

@MSGJ and 2001:7D0:81DA:F780:7DF4:FF2B:3016:C556: Seems appropriate. [OK] Done. NguoiDungKhongDinhDanh ^{Name me} 16:07, 18 November 2021 (UTC)

Most qualifiers (but not all)

In response to a request at Template talk:Wikidata Infobox I have made some changes at Module:WikidataIB/sandbox to support |qual=MOST. This will fetch all qualifiers except reason for preferred rank (P7452) and reason for deprecated rank (P2241). Please copy to the live module. Thanks MSGJ (talk) 13:19, 15 March 2022 (UTC)

 Done — Martin (MSGJ · talk) 12:50, 18 March 2022 (UTC)

Return the QID

Is it possible, when using functions such as getValue and getValuebyQual, to return the Qid (similar to displayformat=raw on Module:Wikidata)? I seem to only be able to produce a plain-text label or a linked label, when the value is an item—but a Qid would be very useful to be able to use in templates. Dominic (talk) 18:52, 28 July 2023 (UTC)

Ping Mike Peel. Dominic (talk) 02:45, 30 July 2023 (UTC)

@LennardHofmann: Something you might be able to help with? Thanks. Mike Peel (talk) 20:45, 31 July 2023 (UTC)

@Dominic: I don't think this is possible and WikidataIB is probably not the right tool for your use case. Do you want to perform a nested query? LennardHofmann (talk) 08:20, 1 August 2023 (UTC)

@LennardHofmann: What I'd like is to get a the Qid of the value of particular statements, if they have a specific qualifier claim (e.g., using determination method or standard (P459) or object of statement has role (P3831)). I need the Qid returned so that I can look up a statement on that Qid. What I have tried so far:

• {{#invoke:WikidataIB | getValueByQual | P9126 | qualID=P3831 | fwd = ALL | qvalue=Q393351 | linked=no | noicon = yes}}

  This gets me the values I want, but only their labels, not the Qids. The limitation here is that Module:WikidataIB doesn't return Qids of item values.

• {{#ifeq:{{#invoke:Statement|entityIdQualifier|P9126|P3831}}|Q393351|{{#invoke:Statement|entityId|P9126}}}}

  This hack gets me a Qid I want, but only works if the qualifier I am looking for is in the first statement of that property, and will only return the first match if so. The limitation here is that Module:Statement doesn't check/return more than one value. Also, you can't really look up a statement's value by the qualifier value, which is why I have to use an #ifeq to make it work.

I was hoping maybe there was just already an undocumented/advanced way to do this with the existing modules, but it's become more complicated than I thought. Dominic (talk) 20:33, 1 August 2023 (UTC)

@Dominic: Module:Wd is great for this: {{#invoke:Wd|property|raw|P9126|P3831=Q393351}} gives you the raw value of the first best-ranked P9126 statement whose P3831 qualifier is Q393351. LennardHofmann (talk) 07:53, 2 August 2023 (UTC)

@LennardHofmann: Thanks, I think this would also do what I need, based on the documentation, but it doesn't seem to fully support SDC yet. For example, the {{#invoke:Wd|property|eid=M134662834|raw|P9126|P3831=Q393351}} (your example, but with a MID that should have a matching statement), gives no output. Also, just trying to get all values regardless of qualifier ({{#invoke:Wd|property|eid=M134662834|raw|P9126}}), gives this error: Q2944483. Dominic (talk) 17:24, 3 August 2023 (UTC)

@Dominic: I fixed this error in Module:Wd/sandbox. Try {{#invoke:Wd/sandbox|property|eid=M134662834|raw|P9126|P3831=Q393351}} and when everything works, tell Mike Peel to copy Module:Wd/sandbox and its subpage to Module:Wd. --LennardHofmann (talk) 19:37, 3 August 2023 (UTC)

@LennardHofmann: Thank you so much! I incorporated this into {{DPLA metadata}} (using "/sandbox"), which I would like to begin sometime soon using ona. large number of files. Everything seems to work as intended, as far as I can tell. (I already put it in all the files in Category:Media contributed by Whitman County Library for testing purposes.) @Mike Peel: What do you think? Should Lennard's changes be incorprated in Module:Wd? Thanks! Dominic (talk) 19:20, 7 August 2023 (UTC)

@Dominic and LennardHofmann: This change looks great! I hesitate to make it live for a couple of reasons. There are a lot of changes beyond this one, see [2] - are they all OK / have they been tested to make sure they won't break anything here? This should also be mentioned at Module talk:Wd in case anyone using the template isn't also watching this page. It's also good in the long term to stay in sync with the enwiki copy (so we only have one version being changed, and don't need to retroactively merge versions), could this change also be made there without causing issues? Thanks. Mike Peel (talk) 13:37, 13 August 2023 (UTC)

Let's continue this at Module_talk:Wd#Syncing_with_enwiki. --LennardHofmann (talk) 09:30, 14 August 2023 (UTC)

@Dominic: This is "WikidataIB" and not "SDCIB" or similar. If you want something that supports MediaInfo entities it should probably be using its API (documented at mw:Extension:WikibaseMediaInfo/Lua) then. This module does not support that at all. I recommend you use a different one when accessing SDC MediaInfo. —Uzume (talk) 11:48, 17 April 2024 (UTC)

Update to 2023-07-10

{{Edit request}} Can this be updated to version "2023-07-10" at enwiki:Module:WikidataIB? I realize this does not really handle MediaInfo serializations caused by things like phab:T149410 but this is "WikidataIB" and not "SDCIB" or "WikibaseIB". Thank you, —Uzume (talk) 18:13, 16 April 2024 (UTC)

No, enwiki needs to be updated from here at some point, not the other way around. Thanks. Mike Peel (talk) 20:23, 17 April 2024 (UTC)

@Mike Peel: And why exactly would enwiki need to be updated from here? There is no need for this module to support SDC MediaInfo. Wikidata contains no MediaInfo entities and this module is named "WikidataIB". If anything it should probably be updated to support Lexeme entities as those do exist on Wikidata (although I believe most WMF wikis still have the Lua interfaces disabled). If someone needs MediaInfo entity support, it should be developed and provided in a different module, not jammed into this one for someone's convenience. I do appreciate you at least merging in the updates from enwiki though, Thank you, —Uzume (talk) 09:40, 21 April 2024 (UTC)