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.

I've added a new function to the sandbox to get the aliases for an entity. This is an expensive call if arbitrary access is used.

The function getAliases has the qid of a Wikidata entity passed as |qid= (it defaults to the associated qid of the current article if omitted), and a local parameter passed as the first unnamed parameter. It implements blacklisting and whitelisting with a field name of "alias" by default. Any local parameter passed becomes the return value, subject to the blacklisting of "alias".

It returns the aliases for the Wikidata entity with the usual list options, and nothing is returned if the aliases do not exist.

Examples and test cases are at Module talk:WikidataIB/sandbox/testing #getAliases. It may be useful for infoboxes that have an "alternative names" field. -- RexxS ( talk) 19:51, 14 November 2018 (UTC)

@ RexxS: It definitely sounds useful! I have two requests: would it be possible to also include results from short name (P1813); and would it be possible to filter out very similar names, such as ones that differ by an accent (e.g., see Telescopio Carlos Sánchez (Q7696819)) Thanks. Mike Peel ( talk) 20:30, 14 November 2018 (UTC)

@ Mike Peel: At present, I've only written general calls that would be usable in any circumstance, like get a property value, get a label, or get a description, etc. I think what you're moving toward is more specialised calls that are very specific to particular purposes. I don't have a problem with that, but it will take a little more time to create something usable. What I think we will produce is larger "building blocks" for templates that will do more than just return a simple set of values. Module:WikidataIB has the routines now to create these bigger blocks while retaining the functionality that we're used to in terms of black/white-listing, sourcing, output formatting and internationalisation, so most of it is already there.

I'll have a look at the issue of filtering out "similar" names, because that's new to me, and I'm not sure what is the best algorithm to use. The question it raises is which of two similar values do we filter out? the second one we come across? or the one with diacritics? or the one without diacritics? And how should that be handled for other languages? Take an example: if we have Buhlmann, Bühlmann, and Buehmann, which one(s) do we keep? Would we make the same decision if language is set to German? -- RexxS ( talk) 20:58, 14 November 2018 (UTC)

Sorry, I was trying to stay general! However, there does seem to be some overlap between the aliases and the short name... With similar names, I'd go by the order that they appear on Wikidata if possible, since they seem to have a special order there (which is a lot easier to change than the property values), and they are language-specific. Thanks. Mike Peel ( talk) 21:02, 14 November 2018 (UTC)

@ Mike Peel: I've made Module:Diacritics containing some utility functions that can be used via #invoke or imported into other modules. It can strip diacritics from phrases or compare two phrases returning true if they are the same or differ only in diacritics (what we might call "similar"). I can use that in WikidataIB to write a new function that collects aliases and short names, then removes identical or similar names before outputting them. The question remaining is, are there any other "similar" words besides those which differ only in diacritics? Do you know of any examples? -- RexxS ( talk) 13:54, 17 November 2018 (UTC)

Would it be possible to generate citations (i.e. <ref name="-wd-Q56813023">[transcluded data]</ref>) using this module? I think this would be useful in infoboxes since Wikidata references are usually different to the sources used directly in articles. The French Wikipedia has something similar but it seems to be somewhat less developed and creates duplicates where the same source is used multiple times. {{ Cite Q}} exists but it's not entirely Lua-based. Jc86035 ( talk) 15:58, 17 November 2018 (UTC)

I've stayed clear of trying to generate references from Wikidata because there is simply no way of knowing what format the references in an article should be. An editor can make up their own style of reference formatting, and then CITEVAR forbids any other style of formatting. I'm simply not prepared to give more ammunition to the Wikidata-haters and infobox-haters to complain about the code that I write. You can get references using {{ wd}}, of course, but I have no plans to do that in WikidataIB. -- RexxS ( talk) 16:55, 17 November 2018 (UTC)

I have also noted that French WP automatically creates archive links. It would help reducing the problem of linkrot here, and simplify the referencing work of en.wp editors. --  Ohc  ^¡digame! 11:22, 18 November 2018 (UTC)

How can the multipliers like "million" been localized? Do I have to translate something for that or create a file in the directory I18n if I want to use it in another language than English?

For example

{{#invoke:WikidataIB |getValue |qid=Q684773 |P1436 |rank=b |fwd=ALL |osd=n |scale=6 |uabbr=y}}

results (independently of the language) into "9.444 million  ", see als:ETH-Bibliothek. -- Zuphilip ( talk) 12:17, 31 December 2018 (UTC)

@ Zuphilip: The multipliers are currently defined (in lines 74–79) like this:

local i18n =
{
...
	"multipliers" = {
		0  = "",
		3  = " thousand",
		6  = " million",
		9  = " billion",
		12 = " trillion",
	}
}

You can either:

1. modify those lines directly in the local copy of the module; or
2. create Module:WikidataIB/i18n locally containing the definitions you require. Those will then overwrite the English definitions in the main module.

Let me know if you need more help or if you want me to make the changes to als:Modul:WikidataIB for you. Cheers -- RexxS ( talk) 14:23, 31 December 2018 (UTC)

Okay, since I don't want to mess up with the template and make future updates easier, I chose the second option. After some attempts I have now the correct syntax for the translation and created the file als:Modul:WikidataIB/i18n which seems to work fine. Thank you RexxS for your help! -- Zuphilip ( talk) 15:20, 31 December 2018 (UTC)

Nice work, Zuphilip. I'll try to remember als:Modul:WikidataIB/i18n as an example to show to anybody else who wants to do some localisation on other Wikipedias. Cheers -- RexxS ( talk) 15:34, 31 December 2018 (UTC)

@ RexxS: In the short-to-medium term, would it be possible/desirable to enable calling this module from other Lua modules? I've tried making a Lua/Wikidata infobox ( code, test) which calls data from multiple items, and presumably this would be quite difficult in wikitext. I don't really know how this module works so I haven't tried to touch it. I'm not anticipating actually making use of this just yet, but maybe in a few months to a few years.

For context on why I would want to call multiple items: Other music databases tend to indicate music releases, compositions and tracks as separate entities, but Wikidata has lumped them all together through infobox imports. There are a few thousand items which aren't lumped together like this (so this infobox would only work with those items). There is no real consensus for using either method in Wikidata. (Related: draft RfC (by me); most recent discussion.) Presumably this would also be useful for things like going up an administrative subdivision tree. Jc86035 ( talk) 09:39, 30 December 2018 (UTC)

@ Jc86035: All of the work in fetching the objects representing statements and translating each data type into wikitext is done inside separate functions that could easily be adapted to be available to another module via the require() function. So it should not be much of a problem to write a bespoke module that picks up several properties and/or qualifiers and assembles them internally into an infobox (or any other wikitext).

However, there is little to gain from trying to fetch multiple statements in one call, because the getEntity function is resource-heavy compared to getBestStatements/getAllStatements. It also tells the system that it is loading every statement, alias, description and sitelink into the page where it's called, which then makes it very difficult to filter most of the irrelevant changes from any en-wp watchlists that enable Wikidata tracking.

The present problem with writing all or most of the code in Lua is that we would restrict maintainers to the relatively small number who are comfortable writing in Lua, compared with the seemingly much larger number of editors who are happy to write template code using the MediaWiki functions. That prompted me to develop WikidataIB as a way that they could adapt existing infobox code on a field-by-field basis to draw data from Wikidata under carefully prescribed circumstances. You can see an example at the unfinished Template:Infobox person/Wikidata for example. It would be much cleaner to write the whole infobox in Lua, of course, as the French and others do, but then it would need the same one or two editors to do maintenance and implement agreed changes, a situation that I wouldn't be happy with. I much prefer to maximise the number of editors able to service or create the code, even if they don't know Lua. Most of the time, it's easy to create what folks want using wikitext like this:

{{infobox
| above      = {{#invoke:WikidataIB |getLabel |qid={{{qid|}}} }}

| label1     = Language
| data1      = {{#invoke:WikidataIB |getValue |rank=best |P407 |name=language |qid={{{qid|}}} |fetchwikidata={{{fetchwikidata|}}} |onlysourced={{{onlysourced|}}} |{{{lang|}}} }}

| label2     = Artist
| data2      = {{#invoke:WikidataIB |getValue |rank=best |P175 |name=artist |qid={{{qid|}}} |fetchwikidata={{{fetchwikidata|}}} |onlysourced={{{onlysourced|}}} |{{{artist|}}} }}

| label3     = ISWC
| data3      = {{#invoke:WikidataIB |getValue |rank=best |P1827 |name=iswc |qid={{{qid|}}} |fetchwikidata={{{fetchwikidata|}}} |onlysourced={{{onlysourced|}}} |{{{iswc|}}} }}
}}

But you're also looking to fetch a value indirectly by looking for the performer's version of the song as the value of the qualifier statement is subject of (P805), then finding the ISRC (P1243) of that entity. If you use getEntity, that's automatically an expensive function, so again you're much better off using getBestStatements/getAllStatements. If you look in Module:WikidataIB, you'll see there is a function called getPropOfProp, which gets a property of a property. It wouldn't be too difficult to write an analogous call that gets a property of a qualifier.

Nevertheless, you might want to experiment with the code that you're writing, and use some code from WikidataIB. WikidataIB contains all the code needed to create linked items from sitelinks, to resolve datatypes and make a table of multiple values, as well as formatting that table into wikitext in different ways, so feel free to take whatever you need. I'm sorry the code has grown so difficult to follow, but I had to implement whitelists and blacklists in order to give infobox designers the opportunity to make their infoboxes "opt-in" at the article level, and I had to create filters that only return sourced information by default. The parameters |fetchwikidata=, |suppressfields= and |onlysourced= control that behaviour.

Let me know if you want any specific functions added to WikidataIB, and I'll do my best to help out. Cheers -- RexxS ( talk) 15:49, 30 December 2018 (UTC)

@ RexxS: The main issue that I was getting stuck on (which I thought would necessitate Lua) was that for every statement from the single release of a song, the same function has to be done:

• find performer (P175) preferred statement(s) on composition
• for each, check for statement is subject of (P805) qualifier to find recordings (this is mainly because recording or performance of (P2550) doesn't have an inverse)
• on recording item, find preferred published in (P1433) statement(s) to get release items
• for each release, check if instance of (P31) includes single (Q134556), promotional single (Q56599584) or digital promotional single (Q59847891)
• and then find the appropriate data

Is this something I should worry about if I decide to make {{ Infobox song/Wikidata}} at some point in the medium term? I've realized that it would be possible to find the appropriate items once and then use a subtemplate for the actual infobox (with the relevant QIDs passed to the subtemplate), but presumably this would also have some performance drawbacks. Jc86035 ( talk) 12:00, 2 January 2019 (UTC)

@ Jc86035: Lua is an astonishingly fast scripting language, as well as being lightweight (or perhaps as a result of that). So, generally speaking, you don't have to worry about performance. If you read half-a-dozen property values separately using getBestStatements/getAllStatements, you won't see any difference over using getEntity once and picking out the half-a-dozen values from that. Using getEntity is really to be avoided because it loads the entire Wikidata entity, which will include aliases, descriptions, sitelinks and labels, as well as all of the properties. That's why calling a different entity from the one associated with the current page is marked as an expensive call. As I indicated previously, it also means that the page here then effectively transcludes every single Wikidata value and English watchlists will show any changes to that item on Wikidata (when enabled), even if we're only interested in changes that would affect the values we're actually using.

I suggest that when you make your test infobox, you should go with whatever scheme you find easiest to get working using getBestStatements/getAllStatements (or the functions from WikidataIB), and don't worry about performance. You can always check with the 'parser profiling data' you see every time you preview a page, and then worry about optimising performance afterwards if needed. One complicated template will use more resources and server time than dozens of "lean" Lua calls, so your code is almost certainly not going to be the performance bottleneck on an average page.

When you have some code to test, give me a call and I'll help you with anything you need. Cheers -- RexxS ( talk) 14:22, 2 January 2019 (UTC)

I integrated the module in Template:Infobox_library and now an Lua-error occur when the qual-parameter is used in combination with osd=yes for not sourced statements, e.g.:

{{#invoke:WikidataIB |getValue |qid=Q1200925 |P1436 |rank=b |qual=P585 |fwd=ALL |osd=yes |{{{collection_size|}}} }}

← [edit: was giving an error]

Can someone fix this? Ping User:RexxS (I would expect that for the case that only sourced statements are allowed and the current statement is not sourced around line 1087 we would "continue" the loop with the next possible statement and not just leave out one assignment, but I haven't look closer...) -- Zuphilip ( talk) 07:26, 2 January 2019 (UTC)

Hi Zuphilip thanks for catching that. You're right: when the requested statement is unsourced but has a qualifier that is requested, the code was attempting to concatenate the nil value for the statement with the qualifier value. I've caught the unsourced condition and skipped the part that gets the qualifier. Here are some tests to check that it's working for National Library of Catalonia (Q1200925) collection or exhibition size (P1436) point in time (P585) :

• {{#invoke:WikidataIB |getValue |qid=Q1200925 |P1436 |rank=b |fwd=ALL |osd=no |{{{collection_size|}}} }} → 4,401,625 unit, 72 terabyte, 63,800 linear metre 
• {{#invoke:WikidataIB |getValue |qid=Q1200925 |P1436 |rank=b |qual=P585 |fwd=ALL |osd=no |{{{collection_size|}}} }} → 4,401,625 unit (2020), 72 terabyte (2019), 63,800 linear metre (2019) 
• {{#invoke:WikidataIB |getValue |qid=Q1200925 |P1436 |rank=b |qual=P585 |fwd=ALL |osd=no |qualsonly=yes |{{{collection_size|}}} }} → 2020, 2019, 2019 
• {{#invoke:WikidataIB |getValue |qid=Q1200925 |P1436 |rank=b |qual=P585 |fwd=ALL |osd=yes |{{{collection_size|}}} }} →
• {{#invoke:WikidataIB |getValue |qid=Q1200925 |P1436 |rank=b |qual=P585 |fwd=ALL |osd=yes |qualsonly=yes |{{{collection_size|}}} }} →

Let me know if you spot any further problems. Cheers -- RexxS ( talk) 10:02, 2 January 2019 (UTC)

Great, thank you very much RexxS for the fast fix! -- Zuphilip ( talk) 20:43, 2 January 2019 (UTC)

Would it be technically possible to automatically not link some common pages (e.g. Painting, Canada) based on a list of articles or a list of QIDs? I think it would be possible but I'm not sure how it would be implemented in this module. Tony1 seems to have asked for something like this on Meta. Jc86035 ( talk) 10:41, 17 November 2018 (UTC)

Thanks for raising this, Jc. I realise this is a particularly English WP issue, since other WPs don't apply rules for strategically rationing hyperlinking as we do. And because so many articles are translated/imported from other WPs, we have a hard time keeping up with semi-automated treatment (of quite a few things, actually, but overlinking of common terms is an important part of it). We do rely on these "lists of articles that link to X". But my intention was only to ask if it's reasonably practical and easy to implement a solution. My best. Tony (talk) 14:25, 17 November 2018 (UTC)

@ Jc86035 and Tony1: All of the linking creation goes through a single subroutine called "linkedItem", so it would not be difficult to test whether the item was on a "do-not-link list" and then not link it, as long as it's a hard cut-off – no items that might-or-might-not need to be linked. I presume this would only be applicable to enwiki so I could make sure it only took effect here.

My only problem would be compiling the "do-not-link list". Let me know if you think it would be possible to put together a rough list of items that never (or almost never) should be linked and I'll do the coding to test it out in the sandbox. -- RexxS ( talk) 14:40, 17 November 2018 (UTC)

I wonder if there should be a hidden maintenance category for articles which should not normally be linked. MOS:OVERLINK has a short and far from exhaustive list, and there are some places where London does deserve a link, but I think we know an unhelpful link when we see it. Certes ( talk) 16:06, 17 November 2018 (UTC)

Thanks heaps, RexxS. It might take a week—I'll need to consult a few people. Tony (talk) 23:32, 17 November 2018 (UTC)

Tony asked me to come forth here, and I do so with limited understanding as to what WIkimedia developers want the tool to do. While it may appear to be a good idea to automatically link certain fields, and it may be desirable in other language Wikipedias, I remain generally unconvinced about the appropriateness of these technological solutions in our case. There was sound community consensus to eschew many policies that are generally accepted elsewhere, such as date autoformatting, date linking. Our policies on Wikilinking are also more restrained than on other language Wikis, and I would really hate to see adoption of systematic links on a default opt-out basis, that would lead us back to the sea of blue of yesteryear. I have a list of terms that are frequently overlinked, and my script removes these semi-automatically. It could form the basis of a list of opted out terms should the default use of the tool be adopted. But I would oppose it, for the record. --  Ohc  ^¡digame! 11:19, 18 November 2018 (UTC)

To clarify, when I said I would oppose it, "it" means the automatic linking functionality, for the reasons I gave above. In addtion, I am concerned that the code put in place in these infoboxes "confuses" the What links here button in the sidebar. For me, that facility ought to reflect the true state of linking within articles, and not be hidden within some boolean code that is switched not to show the link even though one exists. --  Ohc  ^¡digame! 20:07, 20 November 2018 (UTC)

Whether a link is made manually or via this module shouldn't matter: the article should appear in the "What links here" list of the target. That is the true state of linking for the article, and the code in this module does not confuse it. Making a link to a relevant article in an infobox is a normal feature of infoboxes and the cases where an item should not be linked are the exceptions, not the rule, per WP:BTW. -- RexxS ( talk) 21:38, 20 November 2018 (UTC)

@ Tony1 and Ohconfucius: Is it still desirable to implement this? Would User:Ohconfucius/script/Common Terms.js be an appropriate base for the module code? Jc86035 ( talk) 16:32, 30 December 2018 (UTC)

My personal feeling is that such automatic linking scheme would be retrograde, and as Tony has said would also create false positives with 'what links here' even if there were to be whitelisting. However, if the project were to go ahead with this linking scheme, the terms in the CT script would for me be a good starting point for terms that would de facto not be linked. --  Ohc  ^¡digame! 16:58, 30 December 2018 (UTC)

Automatic linking of items that have articles has been implemented in all of the modules that fetch information from Wikidata since 2013, so it's a bit late to call it "retrograde".

You're quite wrong about "What links here": any entries there would be true positives, because links are exactly the same in the infobox whether they are created manually or from Wikidata. Take a look at Marcel Achard; his occupation is playwright and that's linked in the infobox. If you check at Special:WhatLinksHere/Playwright you find 'Marcel Achard'. In what sense is that a "false positive"? How should that be any different from the link in the infobox at Avery Hopwood? -- RexxS ( talk) 17:47, 30 December 2018 (UTC)

RexxS, I understand your point about links being a "normal feature of infoboxes", but en.WP's guidelines recommend against linking common terms ... like "artist", "writer", "politician", and dozens more. This is the problem we currently face: we clean away those useless "dictionary" links by going to the "what links here" lists. Eating away at that function is making it increasingly difficult to perform such housework. The problem is most noticeable in articles imported from other WPs, where people seem to link everything in sight, still. We do not do that, and have a better linking system for it, which is the dominant view of the community. Tony (talk) 11:57, 31 December 2018 (UTC)

I absolutely agree, Tony, and I apologise for not being clearer. I'm keen to amend the code that fetches data from Wikipedia so that it will not create links to items that are not normally linked in infoboxes. Nevertheless, I find it quite common to see occupations linked from infoboxes on English Wikipedia, and quite often other terms that we might consider sufficiently well-known not to link in running prose, but the opposite sometimes occurs, and I have difficulty divining a common policy in many cases. Just to take one example, Lynda Carter has no occupations linked in her infobox, but has this in running prose: ... American [[psychologist]] and [[writer]] [[William Moulton Marston]] and [[artist]] [[Harry G. Peter]] .... Whatever scheme I create, I expect there to be some push-back over either linking or not linking any particular item.

Anyway, I'll make a start by creating a list of places that should not be linked to try out in the sandbox as a proof-of-concept. It should be easy to add or remove from that list later as consensus decrees. -- RexxS ( talk) 13:54, 31 December 2018 (UTC)

Thank you, Rex. Ohconfucius's script lists the geographical place-names that are to be unlinked, though we do need to keep an eye on anything that ends up not looking right (for example, in an inline list of cities, linked–unlinked, since one might not be in the script and one might be; but in an infobox that's not an issue, I think. I found these pages, which might be useful to you (I'm a tech dummy, so it's rather opaque to me). Naturally, these are far more comprehensive than we need for Wikidata-infobox purposes: User:Ohconfucius/AWB_modules/Unlinking and User:Ohconfucius/test/Common_Terms.js. And here's a list of Ohconfucius's pages with prefix. I haven't noticed years, months, or dates popping up in Wikidata-processed infoboxes—thank heavens, since those what-links-to lists are important to that significant part of house-cleaning. @ RexxS and Ohconfucius: Tony (talk) 05:23, 1 January 2019 (UTC)

@ Tony and Jc86035: I've made a demo of automatic unlinking in Module:WikidataIB/sandbox. This relies on Module:WikidataIB/nolinks for a list of article titles that won't be linked. It should be simple enough to add or remove items from that list, even for someone who has no knowledge of Lua (the items are just like comma-separated values in quotes). Here's a demonstration:

• country (P17)

Article	Code	Result
Paris (Q90)	{{#invoke:WikidataIB/sandbox |getValue |qid=Q90 |P17 |fwd=ALL |osd=n |rank=b}}	France
London (Q84)	{{#invoke:WikidataIB/sandbox |getValue |qid=Q84 |P17 |fwd=ALL |osd=n |rank=b}}	United Kingdom
Ouagadougou (Q3777)	{{#invoke:WikidataIB/sandbox |getValue |qid=Q3777 |P17 |fwd=ALL |osd=n |rank=b}}	Burkina Faso

The list of items that are not to be linked can be displayed like this:

• {{#invoke:WikidataIB/sandbox |showNoLinks}} → Australia; Austria; Belgium; Canada; China; Denmark; England; France; Germany; Greece; Hungary; Iceland; India; Israel; Italy; Jamaica; Japan; Luxembourg; Mexico; Netherlands; New Zealand; Northern Ireland; Norway; Poland; Portugal; Republic of Ireland; Russia; Scotland; South Africa; Spain; Sweden; Switzerland; Turkey; UK; USA; United Kingdom; United States; Wales

I've only included a few dozen common countries in the list for demonstration purposes, but it can be expanded essentially as large as folks want, and doesn't have to be limited to any particular topic. The module WikidataIB does process dates as needed, but never links them. We didn't fight all those battles in the date-delinking wars just to see date linking return by the back-door! -- RexxS ( talk) 19:13, 1 January 2019 (UTC)

• • User:RexxS, thank you so much! Tony (talk) 12:01, 3 January 2019 (UTC)

This edit request to Module:WikidataIB has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Please change,

local _getSitelink = function(qid, wiki)
	qid = (qid or ""):upper()
	if qid == "" then return nil end
	wiki = wiki or ""
	local sitelink

to

local _getSitelink = function(qid, wiki)
	qid = (qid or ""):upper()
	if qid == "" then qid = mw.wikibase.getEntityIdForCurrentPage() end
	if not qid then return nil end
	wiki = wiki or ""
	local sitelink

It is useful for local wiki in other language to check if the current page in local wiki has sitelink on enwiki or not.

PS. I also need to get all sitelinks of the page, but don't know how. -- Ans ( talk) 14:42, 14 February 2019 (UTC)

 Done

@ Ans: Thanks for that very useful suggestion - it makes eminent sense to use the entity-id of the connected page if it is not supplied or is blank.

The issue of getting the complete set of sitelinks is still something I've been asking for. I would really like a non-expensive call that just loaded the table of sitelinks, but that's not available yet. What you have to do at present is to load the entire entity (an expensive call if you're not accessing the current page) and get the sitelinks from that. If you look at the function p.getAllAliases in Module:WikidataIB, you'll see how we get all of the aliases. For sitelinks it would be something like:

	local entity = mw.wikibase.getEntity(qid)
	if not entity then return i18n"entity-not-found" end

	local sitelinks = entity.sitelinks
	if not sitelinks then return i18n"sitelinks-not-found" end

	for k, v in pairs(sitelinks) do
		-- do some processing here
    end

The structure of the sitelinks looks like this (from Allison Guyot (Q60747601), which only has one sitelink):

  "sitelinks" = table#6 {
    metatable = table#7
    "enwiki" = table#8 {
      "badges" = table#9 {
      },
      "site" = "enwiki",
      "title" = "Allison Guyot",
    },
  },

Hope that helps. -- RexxS ( talk) 00:12, 15 February 2019 (UTC)

Thank you. But why is it NOT expensive in getting all sitelinks of the current page? -- Ans ( talk) 05:34, 15 February 2019 (UTC)

I've already got the answer at mw:Extension:Wikibase Client/Lua#mw.wikibase.getEntity. However, thank you for your help -- Ans ( talk)

Hi. As it seems like Wikidata doesn't support Alt Text yet (please correct me if I'm wrong), is it possible to set ImageLegend as alt text on this module? So that infobox images from wikidata show some alt text (even though it may not be entirely in context)? Kind regards, Reh man 11:57, 7 March 2019 (UTC)

After importing to tewiki, the module page has the following problems 1) Documentation does not get transcluded (Whereas for Module:Wikidata, there is no such error) 2) Hidden category: Pages with script errors is added. 3) The pages/templates/modules being used, when trying to edit shows some pages of English and some modules which do not exist in enwiki. 4) Category included in Telugu shows that the template size is exceeded.Is it that Telugu script requiring more bytes per character/glyph, is causing the limits to be exceeded? Request help, as we plan to increase usage of wikidata. Arjunaraoc ( talk) 09:51, 4 May 2019 (UTC)

@ Arjunaraoc: The current version of WikidataIB uses an external module, Module:Complex date developed on Commons by Jarekt which handles a lot of the localisation. That module itself calls eight sub-modules (listed at lines 16 and 17) and you'll need all of those for the module to be guaranteed to work properly. I'm sorry that there is so much installation required, but that is outside of my control. I'd strongly suggest you get these modules from Commons, rather than enwiki as they are more likely to be up-to-date there:

Module:I18n/complex date, Module:ISOdate, Module:Date, Module:Formatnum, Module:I18n/date, Module:Yesno, Module:Linguistic, Module:Calendar

Unfortunately if your Wikipedia already has a module using any of these names, you'll have to rename the module from Commons and change where it's called from to match (I had to do that for Module:Date on enwiki).

Can you confirm you have imported all of these (as well as Module:WikidataIB/doc)? If you haven't, then it is quite possible that some of the errors you are encountering may be due to the lack of these modules and importing them may solve most, if not all, of your problems.

I also recommend copying Module talk:WikidataIB/testing which contains tests for many of the functions available and it will give you a good idea of the location of any errors. -- RexxS ( talk) 11:30, 4 May 2019 (UTC)

RexxS, looking through your list and unfortunately there are more modules used:

• c:Module:Complex date uses

• c:Module:i18n/complex date

• c:Module:Linguistic
• c:Module:Roman
• c:Module:Ordinal

• c:Module:I18n/ordinal
• c:Module:Yesno
• c:Module:LangSwitch

• c:Module:ISOdate

• c:Module:DateI18n (previously called c:Module:Date on commons but renamed since all the other projects called it "DateI18n")

• c:Module:I18n/date

• c:Module:Formatnum
• c:Module:Calendar

Commons is multi-language project where almost every text has to be internationalized, so over the decades we developed large echo-system of templates, which in last few years were moved to modules. Large number of modules is easier to test individually, but it complicates export to other projects. Name conflicts are also an issue. Recently I renamed c:Module:Date to c:Module:DateI18n since that is what everybody else called it. Also c:Module:Calendar should not be confused with Module:Calendar. Module:Complex date seem to call the incorrect "Module:Calendar". Perhaps I should rename mine it to avoid confusion. -- Jarekt ( talk) 18:19, 4 May 2019 (UTC)

Don't bother renaming c:Module:Calendar because (1). Module:Calendar (the local version) is completely unused except for mistaken transclusions through complex date ( Mr. Stradivarius, does that unused module serve any purpose)? (2). Module:WikidataIB does not use the APIs of Module:Complex date that use Module:Calendar, so a module with than title has no possibility of being used, and therefore if a commons version were to be imported I would TfD it. * Pppery * _DELETE 23:08, 4 May 2019 (UTC)

@ Pppery: No, as you said, it's unused right now. I think it was meant to be a generalisation of Module:Current events calendar; I seem to remember that the same basic calendar pattern cropping up in several different templates surrounding Portal:Current events, and that there was a lot of duplicated code that the module was going to fix. I never got around to actually generalising it, though. It looks like it was protected by Ferret after this AN thread, but I don't remember it ever having any transclusions. — Mr. Stradivarius ^{♪ talk ♪} 14:23, 6 May 2019 (UTC)

These module sets have been imported/deleted/reimported several times. At the time of that ANI thread, Module:Complex date was in use on 700K+ pages because it had been added somewhere in the Commons-category template (I would assume via Module:Calendar at the time, due to a fresh reimport from Commons, but I don't recall the details). I only got involved as vandalism to it (Complex Date) broke WikidataIB at the time. The current transclusion count appears to be only 1700ish, so I assume that's due to Commons category changing again since. -- ferret ( talk) 14:31, 6 May 2019 (UTC)

@ Mr. Stradivarius and Ferret: Allow me to tell the tale of the transclusion counts ...

1. Template:Commons category, where most of the transclusions come from, has called Module:WikidataIB since November 2018.
2. From November 2018 to February 2019, Module:WikidataIB unconditionally loaded Module:Complex date, which unconditionally loaded Module:Calendar, even though most uses of WikidataIB did not execute any code from Module:Complex date and the local version of Module:Calendar did not export the API that Module:Complex date expected
3. Module:Calendar was vandalized during this period in January 2019, which led to its protection
4. In February 2019, I edited Module:WikidataIB and Module:Complex date to only require their dependencies when necessary, bringing the transclusion count of Complex date down to 1500 and completely orphaning Module:Calendar.

* Pppery * _survives 19:08, 6 May 2019 (UTC)

@ RexxS, Jarekt, User:Pppery Thanks for your feedback. We would like to keep importing from enwiki only for ease of future maintenance. Module:WikidataIB/doc was already imported. I have imported and checked te:మాడ్యూల్ చర్చ:WikidataIB/sandbox/testing, and found no errors, except the dates presentation in English. My experiments with WikidataIB so far seem to be working, as I have not yet used the month names. All the modules referred above are present in tewiki.If you have any other inputs to resolve the issue, let me know. Arjunaraoc ( talk) 06:53, 6 May 2019 (UTC)

I filed a bug in Phabricator. The responses indicate that tewiki Post‐expand include size is 2014248/2097152 bytes as against 145973/2097152 on enwiki, which indicates a bloating of 1279%. Hope this helps in improving this module, so that module can be used without issues in other language projects.-- Arjunaraoc ( talk) 04:30, 7 May 2019 (UTC)

Module:Calendar has been nominated for deletion. You are invited to comment on the discussion at the module's entry on the Templates for discussion page. * Pppery * _{it has begun...} 21:09, 28 May 2019 (UTC)

iPadOS is in Category:Pages with script errors due to "Lua error in Module:WikidataIB at line 476: attempt to index field 'datavalue' (a nil value)" which can only be seen by parsing the HTML source. It looks the cause is the fact that the article has an incomplete topic's main category (P910) with no datavalue. However, yet another test in the module might be in order to avoid the error? Johnuniq ( talk) 08:06, 9 June 2019 (UTC)

Thanks, Johnuniq. I considered the possibility that someone would set "no value" for an topic's main category, but then dismissed the thought as too far-fetched. I mean, what would be the point of anybody doing that? However, it looks like my faith in the inherent sense of some contributors was misplaced. I've now amended lines 476 (and similarly for line 484) as I should have done in the first place:

• local tmcid = prop910.mainsnak.datavalue.value.id to
• local tmcid = prop910.mainsnak.datavalue and prop910.mainsnak.datavalue.value.id

That will give a nil value for "no value" just as if the property wasn't set. iPadOS is now no longer giving a script error. Cheers. -- RexxS ( talk) 17:12, 10 June 2019 (UTC)

Thanks. We probably need bullet-proof functions to access anything from Wikidata. I believe I have ranted about their who cares approach to data before. Johnuniq ( talk) 01:24, 11 June 2019 (UTC)

I'm guessing that the module maintainers might be unaware of this? The WMDE developers have been working on mw:Wikidata Bridge, which will allow some Wikidata statements to be edited directly through infoboxes and other templates. There's currently a semi-interactive prototype. I think it would be useful for the module maintainers to provide feedback, if there are any issues that haven't already been addressed.

There's an early draft of a documentation page that might help explain how the software's supposed to be enabled inside template code. Jc86035 ( talk) 08:31, 3 July 2019 (UTC)

@ Jc86035: Thanks for the pointers. I've already promised to find some time at Wikimania to talk through some of the issues with Lea & co. The implementation of the bridge is likely to be trivial for WikidataIB as I separated out the generation of the pen icon into the createicon function which is called for each use of the pen icon. Unless they change their minds, it should be trivial to add the necessary <span>...</span> in that function. Cheers -- RexxS ( talk) 23:21, 3 July 2019 (UTC)

The use of #invoke:String2 | sentence to convert #invoke:WikidataIB also has the effect of converting the image filename to lowercase, so causing mis-formatting.

{{#invoke:String2 | sentence | {{#invoke:WikidataIB |getValue |P136 |name=genre |fetchwikidata=ALL |onlysourced=false}} }}

Roman à clef, satirical fiction, fable, dystopian fiction 

i.e. File:OOjs UI icon edit-ltr-progressive.svg not File:Oojs_ui_icon_edit-ltr-progressive.svg

As there a way to fix this? It's showing up throughout infoboxes currently. T.Shafee(Evo&Evo) ^talk 04:58, 20 June 2019 (UTC)

Yes. I've made a redirect from File:OOjs UI icon edit-ltr-progressive.svg to File:OOjs UI icon edit-ltr-progressive.svg. I supposed I should recommend using String2|ucfirst in cases where you can't be sure that the text won't contain other necessary upper case characters (the sentence function forces all of the characters beyond the first into lower case). Thanks for spotting this. -- RexxS ( talk) 09:31, 20 June 2019 (UTC)

[Update]: I've fixed an issue where using the sitelink in place of the label as display text (to reduce the effects of vandalism) was capitalising the first letter of many returned items. The call will now use the same case as the label for the first character, so distinguishing (hopefully) between proper and common nouns. That means we definitely should not be using String2 | sentence but String2 | ucfirst instead if we want the first letter capitalised. -- RexxS ( talk) 17:02, 7 August 2019 (UTC)

@ RexxS: noticed your recent edit mentioned date formatting. Do you think you might ever implement "automatic date formatting" like CS1 templates now do when date format maintenance templates are present? -- ferret ( talk) 16:37, 7 August 2019 (UTC)

@ Ferret: The only reason I can think of not to do it is the likely cost of loading the whole text of the page in order to extract the format from the maintenance template. At present, it should be relatively trivial to just add a single | df = mdy parameter to a Wikidata-aware infobox to get US-format dates, as long as the infobox coder has used something like {{#invoke:WikidataIB | ... |df={{{df|}}} ... }}} when coding each Wikidata call that might return a date. I'll take a harder look at Module:Citation and see if there are any tricks to reduce the cost. Cheers -- RexxS ( talk) 16:52, 7 August 2019 (UTC)

[Update:] I made a test module at Module:Sandbox/RexxS/Getdateformat. The tests at Module talk:Sandbox/RexxS/Getdateformat run surprisingly quickly and don't use much memory. I also tested it out by editing Abraham Lincoln, which is a bit of a monster and uses {{ Use mdy dates}}. The extra overhead from the tests was swamped by the poorly optimised Lua already in there, but it's nowhere near the limits anyway. it looks like it's feasible to add to WikidataIB, so I'll try and work on it in the WikidataIB/sandbox while I'm at the hackathon at Wikimania next week. Cheers -- RexxS ( talk) 20:36, 7 August 2019 (UTC)

Excellent! I believe this type of automated consistently really helps out, especially if CS1 already does it. :) -- ferret ( talk) 20:46, 7 August 2019 (UTC)

Recent code change returns incorrect disambiguated sitelink for example the code below returns

{{#invoke:WikidataIB|getValue|P102|fetchwikidata=ALL|name=party|maxvals=1|onlysourced=false|qid=Q6294|noicon=yes}} → Democratic Party

instead of

{{#invoke:WikidataIB|getValue|P102|fetchwikidata=ALL|name=party|maxvals=1|onlysourced=false|qid=Q6294|noicon=yes}} → Democratic Party

An example of a testcase from another wiki can be found here (with the sandbox using the current version of the module).-- Lam-ang ( talk) 14:30, 8 August 2019 (UTC)

@ Lam-ang: Thanks for spotting that. I was allowing the sitelink to be stripped of its disambiguators in order to create the display text, but I've now retained the full text of the sitelink as the target for the link. Check that works now:

• {{#invoke:WikidataIB |getValue |P102 |fwd=ALL |name=party |maxvals=1 |osd=f |qid=Q6294 |noicon=y}} → Democratic Party

Cheers -- RexxS ( talk) 17:16, 8 August 2019 (UTC)

Thanks-- Lam-ang ( talk) 17:18, 8 August 2019 (UTC)

Would it be possible to make the getValue function be accessible from module calls? -- Gonnym ( talk) 15:54, 9 August 2019 (UTC)

@ Gonnym: Anything's possible, but the getValue(frame) function does a fair amount of validating and cleaning of several parameters before it calls the main processing functions, propertyvalueandquals() and assembleoutput(). It used to have an entry point that didn't require a frame object as argument, but that was removed. I'll have a go at reinstating that in the sandbox. -- RexxS ( talk) 20:49, 9 August 2019 (UTC)

@ Gonnym: Okay, that seems to work in Module:WikidataIB/sandbox. One way of calling it is like this:

• local getValue = require("Module:WikidataIB/sandbox")._getValue

You can then use getValue as a function in your module. It takes a single parameter, a table of arguments that are the parameters used in getValue as in the documentation. You might construct the table like this:

• args = { "P31", fwd="ALL", osd="no" }

which would return a string as the value for instance of (P31) from the Wikidata entity associated with the current page. Beware that the string returned might be empty and may even be nil (instead of a string). You might call like this to ensure you always have a string value:

• str = getValue(args) or ""

Try it out and let me know if you run into problems. Cheers -- RexxS ( talk) 21:31, 9 August 2019 (UTC)

Thanks for that! Initial validation of the code seems to be working. Two examples:

• Lua error in Module:Sandbox/Gonnym/episodewikidata at line 4: assign to undeclared variable 'p'.
• Lua error in Module:Sandbox/Gonnym/episodewikidata at line 4: assign to undeclared variable 'p'.

I'll continue to work on my code and if I run into any issues I'll let you know. -- Gonnym ( talk) 21:56, 9 August 2019 (UTC)

Could this new function also be made accessible from module calls? -- Gonnym ( talk) 17:59, 12 August 2019 (UTC)

Is it possible to display references for properties obtained from Wikidata? It seems a waste to have the references there unless they can be used on Wikipedia. If this is possible, please point me to the appropriate documentation. Thanks — Martin ( MSGJ ·  talk) 07:20, 4 October 2019 (UTC)

It is possible to retrieve references, but impossible to format them to match the formatting used in any arbitrary article because editors are free to create any arbitrary style they choose and there is no way to enumerate all of those in order to match them. I'm not willing to spend time implementing references from Wikidata, only to spend far more time defending them when the complaints arrive that they are in the "wrong format and l can't edit them to look like all my others". Sorry. -- RexxS ( talk) 10:59, 4 October 2019 (UTC)

I understand the concern. I guess we could support a few of the most common formats? Or else is there a nice way we could indicate that the information is referenced and provide a quick link to the reference on Wikidata? In the meantime, what is the method to retrieve reference URL (P854) for a particular claim? — Martin ( MSGJ ·  talk) 14:14, 4 October 2019 (UTC)

Module:Wd will retrieve references for you. -- RexxS ( talk) 17:51, 4 October 2019 (UTC)

Most infobox invocations don't set qid, which makes it default to the associated Wikidata entry of the current page. There are cases when a child infobox must use a different Wikidata entry; this is done by setting qid=CHILD_ENTITY_ID in the child infobox. However, sometimes the child infobox does not yet have a corresponding Wikidata entry, so there's no CHILD_ENTITY_ID to use. Leaving qid empty in this case is wrong, as the child infobox gets erroneously populated by values from the wrong Wikidata entry. We can specify fetchwikidata=NONE to prevent it from fetching anything, but it will still display an "[edit on Wikidata]" link to the wrong Wikidata entry.

Consider Gennadiy Borisov, an article about an amateur astronomer. His one-man personal observatory is not notable enough to warrant a separate article, so {{infobox observatory}} is embedded inside {{infobox person}}. The observatory does not have a Wikidata entry either, so there's no qid to set. Setting fetchwikidata=NONE does not remove the erroneous "[edit on Wikidata]" link to Gennady Borisov (Q67389917) under the observatory data. Plus, if {{infobox person}} ever gets its own Wikidata link, there will be two links to the same Wikidata entry. Mike Peel has solved the problem for {{infobox observatory}} by making it hide the "[edit on Wikidata]" link when fetchwikidata=NONE (see diff). However, the problem has to be solved in the general case.

I propose a new setting, qid=none, to completely disable Wikidata for a specific infobox invocation. With qid=none, getValue will return the second unnamed parameter (even if it's empty), {{EditOnWikidata}} will return an empty string, Module:Wikidata's ViewSomething will return an empty string, and so on. —  UnladenSwallow ( talk) 20:23, 8 October 2019 (UTC)

Would there ever be a case where an entity is worthy of an English Wikipedia infobox (on some other article), but not noteworthy enough for a Wikidata item? I would think a better solution is to take the few minutes to create a Wikidata item for the entity (in this case for MARGO Observatory) at the same time as deciding to create/populate an infobox. Once it's created, there is a target for the qid, and a value for use in location of discovery (P189) in the things he has discovered. -- Scott Davis ^Talk 13:52, 10 October 2019 (UTC)

1. We can't force Wikipedia editors to edit Wikidata. They may not have the time or willingness to learn how to do it. It is always incorrect to put associated Wikidata entry's values into a child infobox that has an entity type different from its parent. We can't allow incorrect values showing up in an infobox just because a user forgot / did not want / did not know how to create the corresponding Wikidata entry.

2. Another issue is infobox examples. Consider the infobox example on the right in Template:Infobox observatory § Full. It is automatically linked to the Wikidata entry Template:Infobox observatory (Q5613278) (see the "[edit on Wikidata]" link). What would happen if "Template:Infobox obs" was added to the "Also known as" field of this Wikidata entry? The infobox example would then erroneously display an extra line:

Alternative names  Template:Infobox obs 

How would you get rid of these? By creating a separate Wikidata entry for each infobox example? (There may be a few on a template page.) That would be a needlessly complicated procedure and would fill Wikidata with unnecessary junk. While setting qid=none would be a very simple and intuitive way to unlink an infobox example from a template's Wikidata entry. (In case you're wondering, this is not a crazy scenario: Template:Clear (Q5411705)'s "Also known as" field is set to "Template:Clr".) —  UnladenSwallow ( talk) 19:04, 11 October 2019 (UTC)

@ UnladenSwallow: This module is not responsible for the [edit at Wikidata] link. If I were to implement qid=none in the module, it would function exactly as fetchwikidata=NONE and the template would still display [edit on Wikidata]. That is all down to how the template is coded and there is no "general case", sorry. -- RexxS ( talk) 03:00, 12 October 2019 (UTC)