This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

if not ref:find("Wikipedia") then refs = refs + 1 end

I believe you also have to check and exclude "wmflabs". It appears that a lot Wikidata items are sourced to wmflabs urls which appear to contain information from Wikipedia. Some of these URLs do contain the string "Wikipedia", but not all of them.

Oh crap. I think I just found a bigger problem. Let's say someone goes to one Wikidata item (United States of America), and they find an unsourced claim of relationship to a second wikidata item (capital: New York City, start time 1785, end time 1790). In this case the claim appears to be a true, but let's set that aside. Let's say they then go that second Wikidata item (New York City) and copy the claim (capital of: United States of America, start time 1785, end time 1790).

That's great - so far. However let's say they then add a reference. Stated in: United States of America.

That second claim is "sourced", but it's citing another wikidata item as a reference.

Would I be correct in guessing that attempting to filter out references from one wikidata item to another wikidata item is going to go "boom"?

And no, you can't fix it by deleting this one junk reference. I don't know how widespread the problem is, but I see a pile of references like this. Alsee ( talk) 07:06, 9 October 2017 (UTC)

@ Alsee: Can you point to an example of a link to wmflabs please? In the second case, that's an editor mistake that would need to be manually corrected, since you can do things like "Stated in: Keplerian elements for approximate positions of the major planets (Q21128615)" (this is then what {{ Cite Q}} develops into a full reference), but that's the kind of thing that can be caught by property contraints (e.g., checking if the Wikidata item is a book/journal/etc. and not a country). Thanks. Mike Peel ( talk) 11:22, 9 October 2017 (UTC)

Mike Peel given Wikidata's standards, I'm not sure why refs to other Wikidata items would be fundamentally any less legitimate than refs to Wikipedia. In any case there appear to be a lot of them. In just a matter of minutes randomly clicking through WorldHeritage Wikidata items I ran into four pages containing refs to other wikidata items. In any case, it appears I was right in my oh-crap interpretation. You're basically saying you're unwilling/unable to filter out circular Wikidata refs.

Regarding wmflabs refs: I spent a long time trying to figure out how to use the regular search box to search for wmflabs in wikidata refs, but I couldn't find any way to do so. Am I missing something simple, or is this content really not indexed?!? I finally resorted to teaching myself the wikidata database query language to search refs that way. That's crazy. Here's a query that pulls out some wmflabs refs. Anyway, the large majority of wmflabs hits go to tools.wmflabs.org/heritage. Those are all refs to content extracted from Wikipedia. I also found isolated instances of circular refs to wikidata itself via tools.wmflabs.org/reasonator and tools.wmflabs.org/scholia. There's also tools.wmflabs.org/whois and tools.wmflabs.org/geohack which are god-awful ways to effectively ref external sources. Alsee ( talk) 20:50, 10 October 2017 (UTC)

@ Alsee: On the first point: you misunderstand. There are Wikidata items holding information about topics, and Wikidata items holding information about references (which, in the case of notable books for example, are the same thing). So by saying "Stated in: Keplerian elements for approximate positions of the major planets (Q21128615)", you aren't referencing the info in that Wikidata item, you are referencing the item that the Wikidata item is *on* (which in this case is a journal article). Wikidata references to info *in* Wikidata entries should be removed - and property constraints is the way this can be done. On the wmflabs refs, I'll have to dig into that, but I suspect it's something to do with Wiki Loves Monuments data (and yes, the search box on Wikidata sadly sucks). Thanks. Mike Peel ( talk) 23:05, 10 October 2017 (UTC)

Mike Peel, yep wmflabs.org/heritage is Wiki_Loves_Monuments data pulled from Wikipedia.

Regarding refs to Wikidata items, I fully understood. As a programmer it never crossed my mind anyone would create those kinds of refs, until I saw them. We're addressing practical reality, not conceptual theory. We're discussing machine-readable-data being crowdsourced by non-programmers. Wikidata's design invites the creation of a "Stated in: OtherWikidataItem" type ref. For an average non-programmer, a "Stated in: OtherWikidataItem" ref is about as reasonable as a "Stated in: Wikipedia" ref. For a number of reasons the Wikidata community doesn't seem to have been spotting these refs.

If we want to examine these refs from a pure theory standpoint: <satire>These refs should not be removed, they should just be fixed. The correct ref is "Stated in: Wikidata (Q2013)".</satire> Aside from the ironic Q number, that is a dead-standard Wikidata ref. It correctly identifies the source and it has the expected level detail, reliability, and verifiability.

It looks like there are 22,308 instances of (?X Capitol ?Y) lacking a matching (?Y Capitol of ?X). 22,308 entries I can add, all appropriately referenced as "Stated in: Wikidata (Q2013)". Weee! This is exactly why Wikipedia and Wikidata can't be considered usable sources - you just end up with a citogenesis machine.

Saying these refs should be removed doesn't actually fix anything. I don't have deep knowledge of the property constraint system, but this seems like an intractable problem. Sure you can hunt down countries used in this kind of ref, but a general solution seems infeasible. Even if you try to define a constraint, software still can't detect the difference between information found on Grant's Tomb (Q1025105) and information found in the wikidata item for Grant's Tomb (Q1025105).

If I am overlooking a concrete plan to fix this, let me know. If not, can you admit the "only include sourced Wikidata items" can't/won't be expanded to "source other than Wikipedia or Wikidata"? Alsee ( talk) 17:02, 11 October 2017 (UTC)

@ Alsee: You're still missing the point, I'm afraid. It's like saying that Wikipedia articles only reference Wikipedia since all of the reference information is stored in the article itself. On Wikidata you can either provide a basic citation for e.g. a news article, in the same Wikidata entry as the information. Or if it's a notable source in itself (say, a book), then you can say "stated in X, page Y", where X is a link to the Wikidata entry with the information about that book - and then you can use it to reference different statements in different entries as appropriate. It's not a "stated in: wikidata" reference any more than a reference here is "stated in: cite web". And note that it is different from "Imported from: English Wikipedia", which I agree is circular and should not be viewed as a proper reference. Thanks. Mike Peel ( talk) 20:19, 11 October 2017 (UTC)

@ Alsee: Some useful background info (although not as much as would be ideal) is at d:Help:Sources. Thanks. Mike Peel ( talk) 20:23, 11 October 2017 (UTC)

@ Alsee: On the wmflabs references, I've forwarded your question to d:Wikidata:Project_chat#References_to_wmflabs.3F, as I'm stumped. Thanks. Mike Peel ( talk) 20:31, 11 October 2017 (UTC)

Mike Peel I believe I understand your point just fine. I'm not a fan of Wikidata-on-Wikipedia, so I find the problem amusing. Are there any points below where we fundamentally disagree:

1. These refs do exist.
2. They were created with the contributor intention of citing information in the Wikidata item.
3. As programmers, you and I agree that these refs represent a logic-error by the contributor.
4. As programmers, you and I can understand why random non-programmers might easily make this logic-error.
5. Most EnWiki editors would like these items filtered out, just like items sourced to Wikipedia are filtered out.
6. You're unable to filter out these cases without heavily nuking Wikidata-on-Wikipedia.
7. And just for amusement: Changing them all to "Stated in: Wikidata (Q2013)" would correct the logic-error by the contributor, and it would be roughly consistent with the level of detail and verifiability of countless other "Stated in: Q######" Wikidata refs. Alsee ( talk) 23:15, 11 October 2017 (UTC)

The logic-error is essentially a user providing a pointer-to-object when a pointer-to-pointer-to-object is expected. You can hardly be surprised when non-programmers lose track of double indirection. Alsee ( talk) 23:51, 11 October 2017 (UTC)

No, the logic error is not that the user has the wrong number of layers of indirection, it is that they are using the wrong property. They should be using inferred from (P3452). And one could easily (I'm not very familiar with the Wikibase lua API) write code that excluded references with that property. {{repeat|p|3}}ery ( talk) 00:01, 12 October 2017 (UTC)

{{repeat|p|3}}ery "inferred from" implies a different level of indirection from "stated in". By saying they used the wrong property, you did an even better job than I did of establishing that the logic error was losing track of levels of indirection. Alsee ( talk) 14:54, 12 October 2017 (UTC)

P.S. It appears that "Inferred from" didn't even exist [1] until recently. So it was physically impossible for the edits I've seen to have used it. Alsee ( talk) 15:59, 12 October 2017 (UTC)

@ Alsee: No, your argument is wrong from your second point onwards - the contributor intention at that point is to reference the source that the Wikidata item describes, not to reference the information in the Wikidata entry. You are missing the point I'm trying to make, and you are fundamentally misunderstanding how referencing works on Wikidata. Please, forget your preconceptions, re-read what I've said above, and look at the help pages. Would it help if we talked through Skype or some other communication method at some point? Mike Peel ( talk) 00:25, 12 October 2017 (UTC)

Per below, I correct on the second point. Hopefully this fully clears up our misunderstanding, and there's no need to debate 3 through 7? Alsee ( talk) 21:38, 12 October 2017 (UTC)

@ Alsee: If you are solely meaning a Wikidata editor saying "this information is stated in this wikidata entry" ("stated in: USA wikidata entry"), then I agree. However, if you are referring to a Wikidata editor saying "this information is in the source described at this Wikidata entry" ("stated in: X journal article, page Y"), then I still disagree... Thanks. Mike Peel ( talk) 01:59, 13 October 2017 (UTC)

Mike Peel I agree. To really nail the point, I am talking about a ref where a human or a bot copied information from Q1 to Q2. If the information in Q1 is unsourced or was imported from Wikipedia, then the information in Q2 is equally unsourced or equally imported from Wikipedia. Q2 is bypassing your Only sourced filter. My first thought was obviously to expand the filter to block Q2. My second thought was holy crap, that will hit every ref consisting of a bare "Stated in: Q#". (A case like "stated in: X, page Y" is not a problem because it has a qualifier attached.) I think you're stuck. Either you don't filter Q2 and you admit the Only sourced filter is a joke, or you do filter Q2 and drop a huge nuke on importing Wikidata. Alsee ( talk) 11:22, 13 October 2017 (UTC)

I think the solution to this is on Wikidata - where such references exist in your Q1/Q2 example, the reference should be removed on sight, and things like property constraints can be used to find them. I think you're arguing about <0.1% of cases of 'stated in', and trying to do so through this module would remove a huge amount of perfectly well-sourced material. Thanks. Mike Peel ( talk) 12:20, 13 October 2017 (UTC)

"...a 'Stated in: OtherWikidataItem' ref is about as reasonable as a 'Stated in: Wikipedia' ref." False equivalence. It's more like including in a citation the link A History of the English-Speaking Peoples or The Guardian. That happens all the time on Wikipedia. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:31, 12 October 2017 (UTC)

Mike Peel and Andy Mabbett: I asked the editor who created one of references. [2] They confirmed that I was right. The ref was created with the intention: sourced from OtherWikidataItem. Furthermore the proposal page for creating "Inferred from" states that bot-operators were using "Stated in" in references intended to mean: sourced from OtherWikidataItem. So apparently there are a massive number of bot-created references of this type. No wonder I found so many of them when I randomly flipped through Wikidata items. Alsee ( talk) 16:10, 12 October 2017 (UTC)

I'm not clear how that relates to what I wrote, above. Do you dispute that we include links like A History of the English-Speaking Peoples or The Guardian in a citations in Wikipedia? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:29, 12 October 2017 (UTC)

Andy Mabbett, we're not discussing unverifiably vague references to information found somehere-but-I'm-not-telling-you-where in The Guardian.

We are discussing circular refs. We are discussing a Wikidata ref stated in (P248) The Guardian (Q11148) which is not citing The Guardian, a ref citing information found in Wikidata Q11148. The Wikipedia equivalent would be a <ref>[[The Guardian]]</ref> which was citing English Wikipedia's The Guardian article - NOT The Guardian itself.

If someone adds unsourced information to one Wikidata item, and that information is copied to a second Wikidata item with a reference "Stated in: first Wikidata item", no Wikipedia Editor is going to buy Wikidata's claim that the information is now sourced. Alsee ( talk) 16:56, 12 October 2017 (UTC)

I think "Stated in: United States of America" is not how the Wikidata property is supposed to be used. Internal Wikidata references are supposed to use "inferred from". Then Wikipedia can decide not to import data with "inferred from" the same way it doesn't import data with "imported from". ChristianKl ( talk) 23:46, 13 October 2017 (UTC)

ChristianKl I agree with the theory that "Stated in: other wikidata item" shouldn't be done. However the issue here is reality. Not only have humans been creating these refs, various bots have been creating them en-mass. They appear to be unbelievably common. I ran into about a dozen of them, in just a few minutes of browsing an arbitrary list of wikidata items.

Either we accept that we're using Wikidata and drop the pretense of filtering, or we actually manage that filter properly. Managing the filter would mean expanding it to cover problem-cases as they turn up. That would mean expanding the filter to cover Inferred_from, expanding it top cover upwards-of-a-million Wikipedia-sourced wflabs/heritage refs I found, expanding it to cover circular refs to wikidata items, and expanding it to filter other cases as they are identified. Alsee ( talk) 04:40, 22 October 2017 (UTC)

From the documentation:

• |list=<hlist|ubl> allows multiple returned values to be displayed as a horizontal list (|list=hlist), or a vertical unbulleted list (|list=ubl). These override the separator and do not display the 'pen icon' linked to "Edit at Wikidata"

Why not display the pen icon in these cases, it looks odd without it, e.g. at Trudi Canavan you can't easily tell that 'works' is from Wikidata while 'Awards' is locally defined. Thanks. Mike Peel ( talk) 11:26, 25 October 2017 (UTC)

Would it be possible to optionally specify a maximum number of values to retrieve? It would be particularly useful when fetching images and coordinates, where we want a maximum of 1 value to be returned as otherwise redlinks appear or values appear over the top of each other. Although we can use PreferredValue, there's no guarantee that this will only return one value. I don't think it matters *which* value is returned, so long as preferred values are chosen over normal rank ones. Thanks. Mike Peel ( talk) 21:52, 29 September 2017 (UTC)

That might need to be more tightly specified, Mike. However, I've set up a test in the sandbox just for values that are wikibase-items, using yet another new parameter |maxvals=, which should do nothing if omitted, or blank or less than 1. See how it works with the country (P17) for Geneva (Q71):

• {{#invoke:WikidataIB/sandbox |getValue |P17 |fetchwikidata=ALL |qid=Q71 |onlysourced=no}} → Switzerland, First French Empire, Republic of Geneva, Republic of Geneva, French First Republic 
• {{#invoke:WikidataIB/sandbox |getValue |P17 |fetchwikidata=ALL |qid=Q71 |onlysourced=no |maxvals=}} → Switzerland, First French Empire, Republic of Geneva, Republic of Geneva, French First Republic 
• {{#invoke:WikidataIB/sandbox |getValue |P17 |fetchwikidata=ALL |qid=Q71 |onlysourced=no |maxvals=0}} → Switzerland, First French Empire, Republic of Geneva, Republic of Geneva, French First Republic 
• {{#invoke:WikidataIB/sandbox |getValue |P17 |fetchwikidata=ALL |qid=Q71 |onlysourced=no |maxvals=1}} → Switzerland 
• {{#invoke:WikidataIB/sandbox |getValue |P17 |fetchwikidata=ALL |qid=Q71 |onlysourced=no |maxvals=2}} → Switzerland, First French Empire 
• {{#invoke:WikidataIB/sandbox |getValue |P17 |fetchwikidata=ALL |qid=Q71 |onlysourced=no |maxvals=3}} → Switzerland, First French Empire, Republic of Geneva 
• {{#invoke:WikidataIB/sandbox |getValue |P17 |fetchwikidata=ALL |qid=Q71 |onlysourced=no |maxvals=4}} → Switzerland, First French Empire, Republic of Geneva, Republic of Geneva 
• {{#invoke:WikidataIB/sandbox |getValue |P17 |fetchwikidata=ALL |qid=Q71 |onlysourced=no |maxvals=5}} → Switzerland, First French Empire, Republic of Geneva, Republic of Geneva, French First Republic 

And with getPreferredValue:

• {{#invoke:WikidataIB/sandbox |getPreferredValue |P17 |fetchwikidata=ALL |qid=Q71 |onlysourced=no}} → Switzerland 
• {{#invoke:WikidataIB/sandbox |getPreferredValue |P17 |fetchwikidata=ALL |qid=Q71 |onlysourced=no |maxvals=}} → Switzerland 
• {{#invoke:WikidataIB/sandbox |getPreferredValue |P17 |fetchwikidata=ALL |qid=Q71 |onlysourced=no |maxvals=0}} → Switzerland 
• {{#invoke:WikidataIB/sandbox |getPreferredValue |P17 |fetchwikidata=ALL |qid=Q71 |onlysourced=no |maxvals=1}} → Switzerland 
• {{#invoke:WikidataIB/sandbox |getPreferredValue |P17 |fetchwikidata=ALL |qid=Q71 |onlysourced=no |maxvals=2}} → Switzerland 

Can you think of some edge cases to test it with? I'd rather leave it in the sandbox while we check it works and decide whether to implement it for all data types (while we still can). Cheers -- RexxS ( talk) 23:03, 29 September 2017 (UTC)

Thanks @ RexxS, that's exactly what I was hoping for. :-) {{#invoke:WikidataIB/sandbox |getValue |P18 |fetchwikidata=ALL |qid=Q618630 |onlysourced=no |maxvals=1}} doesn't seem to work though - it returns Goldstone Deep Space Communication Complex - GPN-2000-000506.jpg  - perhaps because it's a different datatype? Thanks. Mike Peel ( talk) 14:39, 30 September 2017 (UTC)

I've implemented the functionality for images as well in the sandbox now, Mike (so your comment above no longer fits what you saw earlier). Would you have time to test some cases, please? Do you have any opinion on whether we should enable this feature for: (1) all data types; (2) all data types that have handlers written; (3) just specified data types, e.g. images - if so which ones? -- RexxS ( talk) 15:47, 30 September 2017 (UTC)

Thanks RexxS. I'd suggest that it works for all datatypes if possible, that way it's simpler to document and use. I'll try it out in more cases this afternoon, but so far it seems to be working as expected. Thanks. Mike Peel ( talk) 15:58, 30 September 2017 (UTC)

@ Pppery: It looks like you've deleted this from the sandbox. :-( Can you add it back please, and/or merge it into the main version? Thanks. Mike Peel ( talk) 10:24, 27 October 2017 (UTC)

I am trying to enable the "bishop 1" through "bishop 180" parameters on Template:Ordination to call values from Wikidata. The current structure that I've been experimenting with on Wikidata can be found on Francis (Q450675) under the standaolne property "subject has role". I would like to make it such that the "bishop 1" parameter uses getQualifierValue to call Horacio Ernesto Benites Astoul from the first "principal consecrator" value. Then, "bishop 2" would call Jorge Rubén Lugones from the second "principal consecrator" value. This would continue up to "bishop 180". Can this be done using the module? Also, is there a way so that the values called from WD are called chronologically according to the date entered as qualifiers. @ RexxS: Do you know if this is possible? Ergo Sum 18:15, 25 November 2017 (UTC)

@ Ergo Sum: Unfortunately, not with the current module if the data is arranged as in Pope Francis (Q450675), because the original request for the function only envisaged just one value for the property, so while getValue() would return all three identical values:

• {{#invoke:WikidataIB |getValue |P2868 |onlysourced=false |fetchwikidata=ALL}} → principal consecrator, principal consecrator, principal consecrator

the call to getQualifierValue() would only return a single value:

• {{#invoke:WikidataIB |getQualifierValue |P2868 |pval=Q18442817 |qual=P642 |onlysourced=false |fetchwikidata=ALL}} → Horacio Ernesto Benites Astoul

If there was just one subject has role (P2868) with value principal consecrator (Q18442817), but three qualifiers of (P642), then I think we would get all three values, but unfortunately, we can't guarantee how Wikidata arranges data like this. It's a fundamental problem with the lack of constraint on how data is entered making problems for anyone wanting to actually use that data.

I've been able to modify the code in the sandbox to return all the values with options on how to display the list:

• {{#invoke:WikidataIB/sandbox |getQualifierValue |P2868 |pval=Q18442817 |qual=P642 |onlysourced=false |fetchwikidata=ALL}} →
• {{#invoke:WikidataIB/sandbox |getQualifierValue |P2868 |pval=Q18442817 |qual=P642 |onlysourced=false |list=hlist |fetchwikidata=ALL}} →
• {{#invoke:WikidataIB/sandbox |getQualifierValue |P2868 |pval=Q18442817 |qual=P642 |onlysourced=false |list=ubl |fetchwikidata=ALL}} →

Would that meet your requirements?

P.S. I forgot about the chronological bit. That would definitely need a new function to be written for your application. -- RexxS ( talk) 19:41, 25 November 2017 (UTC)

@ RexxS: Thanks for the help. I see that the module was not designed with this particular implementation in mind. Too bad there's not a more robust interwiki coordination of such things. Your solution would work if it were able to associate the called values with the other qualifiers (i.e. point in time). For instance, Horacio Ernesto Benites Astoul would have to be paired with 1 May 1999, as the template associates the two together by listing them side-by-side. And, if there were a point in time missing from Wikidata, the template would need to skip a spot and associate the date with the next value. Do you think the module is able to do this? Ergo Sum 02:43, 26 November 2017 (UTC)

@ RexxS: It might be useful for additional future applications to have the ability to deal with situations like these, e.g. logic along the lines of |data1 = [syntax to call first WD item], |data2 = [syntax to call second WD item], as well as the ability to sort them chronologically, alphabetically, etc. Ergo Sum 20:16, 3 December 2017 (UTC)

@ Ergo Sum: the module can't associate a qualifier with another qualifier unless they are actually linked in the Wikidata. Remember that when you view an item on Wikidata, you're seeing a UI which is one representation of the underlying data, and there's no such thing as "next to" or "the one after" – there's no guarantee that looping through multiple properties or qualifiers will return them in any particular order. One thing that I regularly do is to paste {{#invoke:Wikidata|Dump}} into an article section and preview it. If you do that in a section of Pope Francis, you'll see that there are three entries in the property table for ["P2868"] (i.e. subject has role (P2868)). These represent the three consecrations, and each one has a point in time (P585) associated with it. So, in this case, it would be perfectly possible to to modify the code so that the point in time was read along with the name of the consecratee, but you're not telling me what you want to do with the date that is read (apart from possibly using it to sort the names). The code in the sandbox returns the names at present, but if you wanted it to do more, you'd have to be more specific about exactly what you want returned from the module. -- RexxS ( talk) 21:32, 3 December 2017 (UTC)

I'm trying to set up a new Scientist Infobox. I'd like have have the thesis title linked and with a date like in the normal infoboxes. I managed to get something working in the testcases using getQualifierValue when the url and data is in the qualifier information (e.g. this WikiData entry), but it requires hardcoding the pval. Actually in many cases the information won't be in the qualifying section but in the wikidata entry for the thesis itself (e.g. this WikiData entry). Is there a way to access the URL & date values of a different wikidata entry which is the value of a property? Or to avoid hardcoding the pval? Or to make a link to the WD entry for the property value? D Wells ( talk) 19:51, 9 December 2017 (UTC)

All of that is possible, but raise problems when you consider the different ways that Wikidata allows editors to store the same information. You also need to consider the possibility that the property you want might have multiple values (e.g. a scientist may have multiple PhDs with multiple theses). If you want to have all the names of the academic thesis (P1026) of Simon Myers (Q32653353) (linked to a Wikipedia article if possible), then you can get them with getValue like this:

• {{#invoke:WikidataIB |getValue |P1026 |fetchwikidata=ALL}} →

In this case, that gives only one thesis and there's no Wikipedia article to link, so if you fetched the url, you could make an external link (which is what I'm guessing you actually want). How would you want to deal with the possibility of multiple theses? If we know the name of the thesis, we can then pick the publication date and url using getQualifierValue, but that's why that call needs to already know the name of the thesis.

Rather than trying to use the general functions that weren't written for your scenario, someone could write a special function that would return all three values in the format [url-of-thesis thesis-name] (thesis-date), which is what I guess you want.

Then when you look at Gilean McVean (Q5561586), somebody would have to write another special function to fetch the url and date from a different Wikidata item, which would be an expensive call because it would have to use arbitrary access. That would mean there would be a hard limit on how many of those calls could exist in one article. Frankly I'd recommend that you try to get some consistency in how the url and date are stored in Wikidata, preferably as qualifiers to academic thesis (P1026) first. -- RexxS ( talk) 23:36, 10 December 2017 (UTC)

See the documentation at Template:Emptyor and discussion at Template talk:Infobox scientist/Wikidata #Thesis. -- RexxS ( talk) 02:38, 4 January 2018 (UTC)

And I've provided a perfectly valid implementation of {{ Emptyor}} without using this function that you are rejecting because ... {{3x|p}}ery ( talk) 02:40, 4 January 2018 (UTC)

><

><

Now revert, please. -- RexxS ( talk) 03:20, 4 January 2018 (UTC)

<{{#invoke:WikidataIB|emptyor| ==foo==}}> gives <> -- that case is broken in the module-based version too. What you're effectively doing is not passing a parameter to the template, which has no reason to be supported in the first place. {{3x|p}}ery ( talk) 03:26, 4 January 2018 (UTC)

Explicitly pass the parameter then:

><

><

>==foo==<

>==foo==<

Your implementation is still broken. The point of the template is to pass "==foo==" but not "====". Why am I having to explain all this to you? -- RexxS ( talk) 03:44, 4 January 2018 (UTC)

You've just discovered a bug in the Scribunto; the native string:gsub function considers = to be a punctuation character, and yet mw.ustring doesn't. {{3x|p}}ery ( talk) 03:57, 4 January 2018 (UTC)

Yet, that still doesn't mean I'll revert when I can just fix my implementation to handle equals signs correctly. {{3x|p}}ery ( talk) 04:02, 4 January 2018 (UTC)

I haven't "just discovered" anything. In this case, for en-wp we don't have much need for ustring.

The version you provided also suffers from the problem that it would give a blank infobox field if there were two calls that were inside the markup.

> firstval secondval <

> firstval secondval <

><

><

Now, can we go back to the simple solution that I had working as I intended, please? -- RexxS ( talk) 04:07, 4 January 2018 (UTC)

The first example is even against the documentation, as the template isn't "return[ing] the parameter unchanged". And the second example was literally a bug that would just require one character to fix. {{3x|p}}ery ( talk) 04:35, 4 January 2018 (UTC)

Sorry, it looks like I was somewhat confused there. However, those cases you brought up cost a total of four characters to fix. Now, why can't we go back to not having pointless specific lua functions with no obvious connection to the module they're in when more general lua functions in pre-existing modules can do the same thing? {{3x|p}}ery ( talk) 14:54, 4 January 2018 (UTC)

I restored the original version of {{ emptyor}}. Battling over, for example, a BLP article is good, but battling over a module or template is unhelpful. If the original version has a bug, please identify it. Otherwise, this is pointless drama. Johnuniq ( talk) 04:23, 4 January 2018 (UTC)

@ RexxS: Here's a fun one: trying something like {{#invoke:WikidataIB|getValue|P170|linkprefix=:|name=creator|qid={{{qid|}}}|suppressfields={{{suppressfields|}}}|fetchwikidata={{{fetchwikidata|ALL}}}|onlysourced={{{onlysourced|}}}}} at commons:Category:Roman Slave to show a creator link adds the category to another category, rather than creating a link. As cool as that is, is there a way to enforce showing a link, rather than including a category? Thanks. Mike Peel ( talk) 21:17, 22 January 2018 (UTC)

I checked Module:WikidataIB and c:Module:WikidataIB and found they were identical. Then I edited the latter and fixed a couple of issues. However, it is still not working for the above case because the datatype is "wikibase-item" and that means the logic for lprefix (linkprefix) is not used. That's over my head. Johnuniq ( talk) 00:03, 23 January 2018 (UTC)

@ Johnuniq: Thanks, do any of those edits need porting back here? I was hoping to keep the two copies in sync so that commons can benefit from the future development of the module here. Thanks. Mike Peel ( talk) 09:19, 23 January 2018 (UTC)

Sure, IMHO the edits I did should be used here. However, let's wait for RexxS to have a look. Johnuniq ( talk) 09:24, 23 January 2018 (UTC)

@ Johnuniq: OK, it might be worth adding them to Module:WikidataIB/sandbox - I think that's a bit ahead of the main version of the template at the moment, so it will make it easier when it's next synced back into this version. Thanks. Mike Peel ( talk) 09:43, 23 January 2018 (UTC)

@ Mike Peel and Johnuniq: All looks good to me, John. Since lprefix is forced to contain a string value, I think that ~= "" is logically equivalent to > "" (as a string value can't be less than the empty string). I agree that the the else clauses on success are redundant. I think that errorOrEntity is the right variable to pass at that point. Was there anything I missed? Thanks for that. -- RexxS ( talk) 19:34, 23 January 2018 (UTC)

@ RexxS: well, there's the original issue, please? ;-) Thanks. Mike Peel ( talk) 20:04, 23 January 2018 (UTC)

@ Mike: I'm really not sure what you're trying to do. In this page, we get

{{#invoke:WikidataIB|getValue|P170|fetchwikidata=ALL|onlysourced=no|qid=Q28796962}} → Oscar Pereira da Silva 

as expected (no link because en-wp has no article: Oscar Pereira da Silva, even though Oscar Pereira da Silva (Q3357022) is a wiki-base item, which means that WikidataIB will try to link it when used in other projects if it can).

In c:Category:Roman Slave the same call simply adds the page to the commons category c:Category:Oscar Pereira da Silva. Is that the issue? You know that on commons, the link to c:Oscar Pereira da Silva is just a redirect to c:Category:Oscar Pereira da Silva. That means the wiki-parser is just relocating a category link to the bottom, which is kind of what I'd expect it to. I'm not getting why you want to create on commons a link to a category on a page if you don't want the page in that category? -- RexxS ( talk) 21:55, 23 January 2018 (UTC)

@ RexxS: I'm trying to display the name of the artist, not include it in the category on that artist. A link to that category is a bonus... As an example of what I'm trying to do and the issue, see [3]. Thanks. Mike Peel ( talk) 22:10, 23 January 2018 (UTC)

Ah, ok. I haven't included any way of creating a link with a colon prefix in WikidataIB. As Johnuniq pointed out, the link pre/post-fix logic is only included for string-type entities. Maybe if I just finesse that in c:Module:WikidataIB for linked wikibase-entities? ... Yer, that does it. See this version. I'll leave you with the fun of fixing the other fields. I wrote lprefix=":", not because it needs quotes, but it makes it easier for my old eyes to see. I strip double quotes in the module, so they can be used freely for the pre/post-fixes. -- RexxS ( talk) 22:48, 23 January 2018 (UTC)

@ RexxS: That works perfectly, thanks! Mike Peel ( talk) 22:55, 23 January 2018 (UTC)

Hmm, RexxS is correct about the logical equivalence of > and ~= when comparing with an empty string, and I see that RexxS has fixed c:Module:WikidataIB. However, I'll explain what I did. First, I cleaned the whitespace. That was probably a mistake because it complicates diffs. Second, I cleaned the unintended global variables because they often hide typos. The reason I fiddled with the two entity = errorOrEntity lines is that entity was a global variable. That was cleaning and would not affect results. The change of property_id to propertyID was, I guess, fixing a typo that would affect results if that variable is used. The last global variable was sx and when I made it local I couldn't resist removing the trick of using #sx == 0 to test for an empty string. That trick was good for certain languages but pylint has broken my habit of using it, and in fact the straightforward sx == "" is better in Lua because it only checks if sx is the same object as the object representing an empty string. Johnuniq ( talk) 03:13, 24 January 2018 (UTC)

Thanks John, I'd spotted each of your changes and agreed with all of them. I like having the whitespace clean, but Brackets (my usual external editor) has a habit of indenting blank lines to the same level as the current indentation (which is fair enough). Cleaning out the globals is a real improvement; it makes the code more self-contained and portable. I don't know where property_id came from, but I hope it wasn't me . I was to blame for sx. As for the testing, it's usually a matter of personal choice, but I suppose that whatever is the simplest for others to understand ought to be preferred, so thank you for your cleanup. -- RexxS ( talk) 12:51, 24 January 2018 (UTC)

I'm going to merge all the changes in c:Module:WikidataIB and Module:WikidataIB/sandbox into Module:WikidataIB/sandbox2. Once that's checked, I'll make that the trunk and copy it into the main modules here and on Commons. -- RexxS ( talk) 13:33, 24 January 2018 (UTC)

Or maybe not. I've incorporated the getDescription function and maxvalues, but I can't remember where we discussed the century/BCE date formatting and any other stuff, so that will be lost for the moment because the main module has diverged too far from /sandbox for me to easily spot subtle changes. -- RexxS ( talk) 14:27, 24 January 2018 (UTC)

I had a look at the diffs and agree that if you are not fully aware of the purpose and reliability of the extra code in the sandbox then it should be skipped until someone provides explanations with examples and tests.

I replaced more #s tests in Module:WikidataIB/sandbox2. Feel free to revert if the turmoil does not appeal. I like using the stripToNil function in Module:Age/sandbox (that is my most current version). Instead of

local input_parm = mw.text.trim(input_parm or "")

if input_parm and (#input_parm == 0) then input_parm = nil end

you would use

local input_parm = stripToNil(input_parm)

There is a "got idea from w:Module:Wd" section that needs cleaning. It uses ... which I think I ranted about before although I can't find it now. In a stand-alone Lua program, ... would be set from command-line arguments. However, that does not happen with modules and the attempts to use ... are misguided. The section could be replaced with the equivalent:

require('Module:i18n').loadI18n(mw.getCurrentFrame():getTitle()..'/i18n', i18n)

At enwiki, I believe that is always equivalent to:

require('Module:i18n').loadI18n('Module:WikidataIB/i18n', i18n)

Is the idea that if the module were copied to a different title at another wiki that this line would still work without a change to the built-in title? I'm not sure the tricky code is warranted.

Module:WikidataIB/sandbox uses if next(out) then where Module:WikidataIB/sandbox2 uses if #out > 0 then. The former is the standard Lua method for determining whether a table is empty. Efficiency does not matter in this case, but in general #out involves significant effort because Lua has to count the numbered items in the table.

Johnuniq ( talk) 07:11, 25 January 2018 (UTC)

Thanks John for all your help here. The problem with minor changes is that they were almost certainly due to a request for a new feature or bug-fix on a template talk page, and I can't remember what the trigger was, so I'm now unsure about what had to be solved. Anyway, the diffs are in the history if the problems re-surface.

No problem at all with any of the changes you made. I like the idea of a stripToNil function because parameters passed can always be nil, empty-string or string; although sometimes it will be more convenient to convert nil to empty-string, rather than the other way. Maybe a stripToEmpty( s ) -> if not s then s = "" end would also be generally useful for parameter handling?

I'm used to working with programmers who have a "house-style", so I'm more than happy to switch to using if s == "" then, as I'm pretty sure coders coming from other languages are likely to find that more obvious than if #s == 0 then. Maybe we should be writing a Module Manual of Style ?

You're right about the internationalisation. I'm rather agnostic about how useful that code you highlight really is – I don't think I wrote it, so it's hard to judge. I guess my view would be to put it in the "not worth the effort of changing if it's working" category. There's potentially a load of other stuff that needs internationalisation (I try to leave comments where I remember), but for me it's a job for later (or for somebody else!).

Using next(t) is the standard Lua method to see whether a table is empty or not, because – as you know – #t returns the value of the highest index in the sequence t. If a table is a simple sequence, then #t will also be the number of elements in the table (as it is with the out table), but if t[1] is nil then #t will be zero, regardless of other indices. I was surprised to see, after a bit of testing, that my pc can do a billion evaluations of #t in Lua in 22 sec, but a billion evaluations of next(t) takes 62 sec. None of that is meaningful in this module, of course, but it does show how efficiently Lua deals with table indexes compared with how it handles even its built-in functions. Cheers -- RexxS ( talk) 21:12, 25 January 2018 (UTC)

I've never needed stripToEmpty. Many templates are coded to call another template with, for example, |parm=value and they check various things to determine value which might end up being blank. I've therefore treated blank values as nil and don't recall needing any exceptions for named parameters.

There is a very weak guide reachable at the soft redirect WP:Lua style guide. A proper guide and proper how-to tutorials would be desirable but there are three problems. First, writing quality guides takes a lot of time. Second, the people who should read such documentation mostly won't, even if they knew it existed. Third, there are already a number of how-to guides which have never been finished by someone familiar with the topic. Try Help:Lua debugging (found at Help:Lua) for example.

I'll try your timing test for #t versus next(t) in due course. If t is empty then #t is probably extremely fast. I once did some timing of Lua handling megabyte-long strings. It's astoundingly fast. I do think that next(t) is very opaque for general module editors, and that's probably a good reason to prefer #t.

Re the i18n code, I refactored it to the simplest form above because using ... is irritating as it will become secret lore as the way things should be done. In fact, it probably originated from a module where the author tested on a stand-alone system where ... made sense. If ever wanted, I have better ways of doing that but meanwhile I checked Module:WikidataIB (Q25714577) to see that the module title is WikidataIB everywhere it is currently used so I removed the complexity. Revert if wanted. Johnuniq ( talk) 08:19, 26 January 2018 (UTC)

Those changes are all good, John. Having thought about it, I never use a stripToEmpty function because s = frame.args.parm or "" does that job more simply. It's useful for parameters like lprefix where I can concatenate it without having to test, as long as I know that it can't be nil. Some of the string-handling functions also give errors when used on a nil argument, so in those sort of cases my instinct is to use "" as the null value.

If you're interested, the test code I used was

t  =  { "alpha", "bravo", "charlie", "delta", "echo"}
n = 0
now = os.time()
for i = 1, 1e9 do
	n = next(t)
end
print( os.time() - now )
-- n = 1 -> 13 sec
-- n = #t -> 35 sec
-- n = next(t) -> 75 sec

There may be caching and other effects at work, of course, but in practical terms, it seems to me that there's no likely advantage in using next(t) if we know we're dealing with sequences.

I like your "secret lore" appellation. My equivalent peeve is programmers who use unnecessary complexity and opaque techniques to maintain a mystique around their work, in an effort to make themselves indispensable. I call it the "Wizard of Oz" syndrome. -- RexxS ( talk) 09:11, 26 January 2018 (UTC)

Damn, I'm going to have to update my computer now—it's 10% slower than yours! Johnuniq ( talk) 09:47, 26 January 2018 (UTC)

@ RexxS: Just to let you know, I've included this in the Commons version of the module, and it seems to be working nicely! Thanks. Mike Peel ( talk) 22:44, 28 January 2018 (UTC)

What I need is a merge of getPreferredValue and getQualifierValue, i.e. the qualifier of a preferred value. Kangaroo caught ( talk) 03:05, 4 February 2018 (UTC)

Can you give an example of a Wikidata item that you want to retrieve the qualifier value(s) from? You may be able to use Module:Wd if you don't need all the infobox functionality of WikidataIB. -- RexxS ( talk) 17:06, 4 February 2018 (UTC)

Following the discussions at Module talk:WikidataIB/Archive 2 #links to categories, I've updated this module from Module:WikidataIB/sandbox2 to include: John's cleanup and error fixes; implementation of maxvalues; addition of getDescription(); and extending link-pre/postfixes for all values. Please let me know if you spot any problems. -- RexxS ( talk) 13:45, 28 February 2018 (UTC)

I wonder if it's possible to add the capability to call a value of arbitrary rank, e.g. getNormal, and getDeprecated, which would call only values ranked as normal and deprecated, respectively. This would be very helpful in allowing me to make the co-consecrator parameter on {{ Ordination}} Wikidata-enabled. I'd like it to call only values of normal rank, not preferred. Ergo Sum 22:22, 23 February 2018 (UTC)

@ RexxS: Wondering what your opinion on this is. Ergo Sum 17:41, 28 February 2018 (UTC)

@ Ergo Sum: I've knocked up a version in the sandbox. It returns just normal values if they exist, otherwise it returns all values.

Looking at given name (P735) in Douglas Adams (Q42):

• {{#invoke:WikidataIB/sandbox |getNormalValue |P735 |fetchwikidata=ALL |onlysourced=no |qid=Q42}} → Script error: The function "getNormalValue" does not exist.

Compare with:

• {{#invoke:WikidataIB |getPreferredValue |P735 |fetchwikidata=ALL |onlysourced=no |qid=Q42}} → Douglas, Noël 
• {{#invoke:WikidataIB |getValue |P735 |fetchwikidata=ALL |onlysourced=no |qid=Q42 |sep=" "}} → Douglas Noël 

Perhaps you could test it and see if performs as required for your application (especially if no normal values exist). Let me know. -- RexxS ( talk) 18:58, 28 February 2018 (UTC)

I tried using this module on sawiki, but age is giving some error. It says "वाचनिकदोषः : अनपेक्षितम् उद्गारचिह्नम २" which translates somewhat to "Script error: unexpected symbol thrown 2". Can someone please help? @ RexxS: Error cn be viewed at sa:दिशा पटानी Capankajsmilyo ( talk) 00:22, 1 April 2018 (UTC)

@ Capankajsmilyo: The way I debug these problems is to check that each call to an external template or module returns something sensible. So I build a set of calls that I can try out by previewing them in the article. I pasted and previewed the following into sa:दिशा पटानी:

* 1>{{#invoke:WikidataIB |getPreferredValue |P569 |name=birth_date |qid={{{qid|}}} |suppressfields={{{suppressfields|}}} |fetchwikidata={{{fetchwikidata|ALL}}} |onlysourced={{{onlysourced|}}} |noicon={{{noicon|}}}|{{{birth_date|}}} |df={{{dateformat|dmy}}} }}
* 2>{{#invoke:WikidataIB |getPreferredValue |P570 |name=death_date |qid={{{qid|}}} |suppressfields={{{suppressfields|}}} |fetchwikidata={{{fetchwikidata|ALL}}} |onlysourced={{{onlysourced|}}} |noicon={{{noicon|}}} |{{{death_date|}}}  | df={{{dateformat|dmy}}} }}
* 3>{{str len|{{wikidata|property||{{{qid|}}}|P569}}}}
* 4>{{wikidata|property|raw|{{{qid|}}}|P569}}

which are the first 4 calls in the |data10 ("Born") line of sa:फलकम्:Infobox person. The fourth line gives me the error फलकम्: Wikidata - with "Template:Wikidata pages not live" on hover.

The same four calls on en-wiki at Disha Patani give me:

• 1>13 June 1992 
• 2>
• 3>12
• 4>1992-06-13

This leads me to believe that template {{ wikidata}} and its associated module(s) are not installed in sa-wiki. It's beyond my translational skills to check that, so perhaps you could have a look? -- RexxS ( talk) 01:39, 1 April 2018 (UTC)

Hey thanks for the info. I have added the modules and now the 4 calls give the same results as enwiki. But the error is still there. How to resolve this? Capankajsmilyo ( talk) 05:23, 1 April 2018 (UTC)

• 1>0

The problem is shown with the following wikitext from sa:Template:Infobox person under data10:

आयुः {{#expr: trunc ({{#time: Y.md}}-{{#time: Y.md|{{#titleparts:{{wikidata|property|raw|{{{qid|}}}|P569}}|1}}}})}}

Replacing the wikitext in sa:दिशा पटानी with the above shows (under preview) the error. That's all I have time for at the moment. I see the same wikitext just above but don't know what it was intended to show. Johnuniq ( talk) 06:08, 1 April 2018 (UTC)

Thanks Johnuniq. Its intended to show the age of person I guess. I copied the code frm enwiki {{ Infobox person/Wikidata}} Capankajsmilyo ( talk) 06:42, 1 April 2018 (UTC)

I looked at it a bit more. The problem is seen in the following results from the article:

• {{#time: Y.md}} → २०१८.०४०१
• {{#time: Y.md|1992-06-13}} → १९९२.०६१३
• {{#expr: {{#time: Y.md}}-{{#time: Y.md|1992-06-13}} }} → Expression error: Unrecognized punctuation character "२".

At bnwiki, Aftabuzzaman edits templates to insert code to translate local digits to English so expressions like this work. Perhaps he has encountered this particular issue with {{ Infobox person}}. Johnuniq ( talk) 07:27, 1 April 2018 (UTC)

@ Capankajsmilyo: I resorted to reading the docs and see that the problem can be fixed in this case by adding |en to get the values in English digits. That would give:

{{#expr: {{#time: Y.md||en}}-{{#time: Y.md|1992-06-13|en}} }}

I was going to put that in the infobox but it has just been edited to remove a lot of stuff including the above. Johnuniq ( talk) 10:47, 1 April 2018 (UTC)

Thanks I found the solution in phabricator comments and implemented the same in sandbox of that template. Soln is to use {{formatnumber:input|R}} Capankajsmilyo ( talk) 10:50, 1 April 2018 (UTC)

I think getQualifierValue should have same capabilities as getValue, i.e., the ability of formatting multiple returned values. In my proposal wikidata:Wikidata:Property proposal/hearing date, it was my understanding that instead of creating a new property taking a date value, I could push these dates into property-qualifier-value tuples. How else can I deal with multiple Item-Property-Qualifier-Value tuples where only the value is different? esbranson ( talk) 00:49, 4 April 2018 (UTC)

@ Esbranson: I agree with your suggestion to upgrade getQualifierValue. Perhaps I don't understand what you mean by "multiple Item-Property-Qualifier-Value tuples where only the value is different", but I'm guessing that you want to add the ability to getQualifierValue to return other datatypes than wikibase-items. So you might want to use getQualifierValue|P793|pval=Q545861|qual=P580 to get the start time(s) of a court hearing (or series of them)? -- RexxS ( talk) 18:58, 4 April 2018 (UTC)

Perhaps bad wording on my part. I meant the ability to return, and format, multiple qualifier values. The formatting keyword appears to be unavailable. esbranson ( talk) 23:39, 4 April 2018 (UTC)

@ Esbranson: Today I've done a major re-write of the getValue() function in the sandbox Module:WikidataIB/sandbox. I've now extracted the processing of the different types of property values (linked article, date, url, etc.) into a separate sub-function and I've also extracted the formatting of the output as lists, etc. into another sub-function. That will allow me to reuse those functions to process and format the return values for getQualifierValue() with less effort. That will give getQualifierValue() all the capabilities of getValue(). I need to test the sandbox thoroughly to make sure I've not introduced any errors before updating getQualifierValue(), but I imagine I'll manage that within the next few days. -- RexxS ( talk) 21:57, 6 April 2018 (UTC)

Excellent!! Your work is (probably under-) appreciated! Thank you for creating this module, we are in your debt. esbranson ( talk) 17:49, 7 April 2018 (UTC)

@ Esbranson: I now have a version working, I think, in Module:WikidataIB/sandbox

start time (P580) qualifier for significant event (P793) equals construction (Q385378) in South Pole Telescope (Q1513315)

• {{#invoke:WikidataIB/sandbox |getQualifierValue |P793 |pval=Q385378 |qual=P580 |fetchwikidata=ALL |onlysourced=no |qid=Q1513315}} → November 2006 

start time (P580) qualifier for spouse (P26) equals Sally Burton (Q3469983) in Richard Burton (Q151973)

• {{#invoke:WikidataIB/sandbox |getQualifierValue |P26 |pval=Q3469983 |qual=P580 |fetchwikidata=ALL |onlysourced=no |qid=Q151973}} → 3 July 1983 
• {{#invoke:WikidataIB/sandbox |getQualifierValue |P26 |pval=Q3469983 |qual=P580 |fetchwikidata=ALL |onlysourced=no |qid=Q151973 |df=mdy}}} → July 3, 1983 

start time (P580) qualifier for spouse (P26) equals Elizabeth Taylor (Q34851) in Richard Burton (Q151973)

• {{#invoke:WikidataIB/sandbox |getQualifierValue |P26 |pval=Q34851 |qual=P580 |fetchwikidata=ALL |onlysourced=no |qid=Q151973}} → 15 March 1964, 10 October 1975 
• {{#invoke:WikidataIB/sandbox |getQualifierValue |P26 |pval=Q34851 |qual=P580 |fetchwikidata=ALL |onlysourced=no |qid=Q151973 |df=mdy}}} → March 15, 1964, October 10, 1975 

instance of (P31) qualifier for has part(s) of the class (P2670) equals telescope mount (Q1205231) in South Pole Telescope (Q1513315)

• {{#invoke:WikidataIB/sandbox |getQualifierValue |P2670 |pval=Q1205231 |qual=P31 |fetchwikidata=ALL |onlysourced=no |qid=Q1513315}} → altazimuth mount 

I haven't got the handling of multiple values right yet, so I could use some more examples to test on. Do you have any for me? Cheers -- RexxS ( talk) 23:09, 8 April 2018 (UTC)

A major re-write of the module is currently under testing in Module:WikidataIB/sandbox. The main purpose is to reproduce the functionality of other calls in getValue(). Some test cases are in Module talk:WikidataIB/sandbox/testing. In addition, a template {{ wdib}} is available as a wrapper for the getValue function.

Changes include:

• Several parameters now have short aliases:
  • fwd = fetchwikidata
  • spf = suppressfields
  • osd = onlysourced
  • wdl = wdlinks
• getValue now takes a parameter |qual=. This is the property-id of a qualifier that is to be returned in parentheses after the property, if any qualifiers exist for the property. Setting qual=ALL returns all qualifiers. Setting qual=DATES returns start time (P580) and end time (P582) with a date separator.
• getValue now takes a parameter |qsorted=. This is a true/false switch that enables the sorting of multiple qualifier values within each item. Values no, false and 0 are all false; anything else is true. Default is false.
• getValue now takes a parameter |qsep=. This customises the string that is used to separate multiple returned qualifier values. Any double-quotes " are stripped out, so that spaces may be passed. Default is ", ".
• getValue now takes a parameter |linked=. This is a true/false switch that enables the showing of links to articles. Values no, false and 0 are all false; anything else is true. Default is true.
• getValue now takes a parameter |rank=. When set to "preferred", it returns only preferred values if present, otherwise returns all. When set to "normal", it returns only normal values if present, otherwise returns all. Any parameter value beginning with "p" is "preferred". Any parameter value beginning with "n" is "normal". Default is to return all ranks. This allows getValue to duplicate the functionality of getPreferredValue and getNormalValue which may now be deprecated.

Here's an example of (1) all and (2) the preferred values of creator (P170) from Corisca and the Satyr (Q29016906):

1. {{wdib |P170 |qid=Q29016906 |fwd=ALL |osd=no}} → Artemisia Gentileschi, Aniella di Beltrano, Massimo Stanzione 
2. {{wdib |P170 |qid=Q29016906 |fwd=ALL |osd=no |rank=p}} → Artemisia Gentileschi 

The values and date qualifiers for what Geneva was the capital of:

• {{wdib |P1376 |fwd=ALL |osd=no |qid=Q71 |qual=DATES}} → Canton of Geneva (1815–), Léman (1798–1813), Republic of Geneva (1534–1798), Republic of Geneva (1813–1815) 
• {{wdib |P1376 |fwd=ALL |osd=no |qid=Q71 |qual=ALL |sep="; also " |qsep=" to "}} → Canton of Geneva (1815–); also Léman (1798–1813); also Republic of Geneva (1534–1798); also Republic of Geneva (1813–1815) 

-- RexxS ( talk) 18:34, 14 April 2018 (UTC)

Hello I was trying to use Wikidata coordinates in sa:Template:Infobox settlement, but it's getting a lil confusing. I tried the Wikidata code used in {{ Infobox telescope}} but the sa:Template:Infobox settlement has more than 1 requirement of |coordinates=. Please help... Capankajsmilyo ( talk) 09:18, 15 April 2018 (UTC)

@ RexxS: can you please make this module language independent. I mean as we give params like |suppressfield=, etc, we give language code and output is in that particular language. hi:Module:अंक परिवर्तन is not a good option to use when output of this module involves pencil and other extra text. And if possible, making the language selection automatic (via looking up which Wikipedia is it) would be an ideal solution. Capankajsmilyo ( talk) 06:08, 16 April 2018 (UTC)

Somehow it gives text output in local wiki language but numbers in English format. Capankajsmilyo ( talk) 06:21, 16 April 2018 (UTC)

Further, can the i18n be shifted to subpage, that would make the translation work easier. Capankajsmilyo ( talk) 06:36, 16 April 2018 (UTC)

@ Capankajsmilyo: both suppressfield and fetchwikidata simply search for whatever you supply in |name=, so unless the string.find() function isn't coping with your character set, it should not matter what language you're in for those parameter values. Making a module completely language independent is a difficult task and it's not something I'm keen to try until I'm sure the code is completely stable, and given the major re-write I noted above, that may take some time to be certain of. In the meantime, I'm loathe to take the internationalisation out of the main module because it's simply not necessary. All of the available internationalisation is done in the first 85 lines, so adapting that to a local Wikipedia is the same job, regardless of whether it's in a separate module or not.

The pen icon can be turned off with |noicon= or the code could be modified for rtl usage, but we'd need an example of what the desired output would be, rather than simply asserting it's "not a good option". As I don't speak Arabic or Hindi, etc. I have no idea of what a "good option" might look like.

Because the module can be used in multi-lingual projects like Commons, it's not true that looking up which "Wikipedia" it is in will always give sensible results. In addition, even on a monolingual project, it would need all of the internationalisation lookups for every language (280+) available in the module all of the time - either that or potentially 280+ sub-modules would be required just so that the main module can select which one to use or load.

Text is mainly output via the Wikidata sitelink or label, which match the local language automatically, but numbers are retrieved from Wikidata in western style – fixing that is an improvement that really needs to be done at the Wikidata end of things, in my opinion, otherwise every single module that uses numbers will end up duplicating the same conversion task.

Nevertheless, you are more than welcome to try out any changes you think might be improvements in Module:WikidataIB/sandbox1 or Module:WikidataIB/sandbox2. I'd like to keep Module:WikidataIB/sandbox stable for a while, please, until I'm sure it can be merged into the main module. Cheers -- RexxS ( talk) 12:51, 16 April 2018 (UTC)

In this comment on Wikidata, I was informed that this has to be done in the module. Kindly help. User:Capankajsmilyo^{( Talk | Infobox assistance)} 02:25, 19 April 2018 (UTC)

Hi, I'm struggling with some infobox at ptwiki and need some help in thinking in a solution. See pt:Monumento a Luiz Pereira Barreto. The field "Dimensões" has 4 values (2 for height and 2 for width), but one measure of each is for the sculpture and the remaining are for the pedestal. So, my question is, similar to getQualifierValue, where I can get the value of the qualifier when I know the value for the property, is it possible to make the other way? I mean getting the property value only if they have a "pqal" qualifier. Ping to RexxS because you are a god! Ederporto ( talk) 23:49, 18 April 2018 (UTC)

@ Ederporto: Aergia, perhaps? Sorry I'm so slow, but I was away in Berlin for WMCON18 when you wrote, and I'm only just catching up. We can use the latest sandbox version to see what's in Monument to Luiz Pereira Barreto (Q44994007) like this:

• {{wdib |P2043 |qid=Q44994007 |fwd=ALL |qual=ALL}} → 1.42 metre (sculpture), 6.77 metre ( pedestal) 
• {{wdib |P2043 |qid=Q44994007 |fwd=ALL |qual=ALL |list=ubl}} →
  • 1.42 metre (sculpture)
  • 6.77 metre ( pedestal) 

and you could perhaps use that temporarily; but that's not exactly what you want, I guess? I can write a specific call to return the property value only when the qualifier applies to part (P518) contains a q-value that is passed via a parameter, but it would take me a while. Can I put it on the "to-do" list for a week or two, please? -- RexxS ( talk) 22:32, 29 April 2018 (UTC)