Jump to content

Module talk:WikidataIB/Archive 4

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
< Module talk:WikidataIB
This is an old revision of this page, as edited by Lowercase sigmabot III (talk | contribs) at 05:49, 10 August 2019 (Archiving 1 discussion(s) from Module talk:WikidataIB) (bot). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.
Archive 1Archive 2Archive 3Archive 4Archive 5Archive 6→Archive 8

getAliases

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)

References

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)

Localize multipliers like "million"

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 Edit this on Wikidata", 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)

Lua

@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:
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)

Lua error when qual-parameter and osd=yes are used for not sourced statements

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 Edit this on Wikidata
  • {{#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) Edit this on Wikidata
  • {{#invoke:WikidataIB |getValue |qid=Q1200925 |P1436 |rank=b |qual=P585 |fwd=ALL |osd=no |qualsonly=yes |{{{collection_size|}}} }} → 2020, 2019, 2019 Edit this on Wikidata
  • {{#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)

Listing pages which shouldn't be linked

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:

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

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)

Template-protected edit request on 14 February 2019

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)

Alternative text for images

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, Rehman 11:57, 7 March 2019 (UTC)

Lua script error and other errors on tewiki

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:
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)

Nomination for deletion of Module:Calendar

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)

Property 910

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)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Module_talk:WikidataIB/Archive_4&oldid=910174815"