Module talk:WikidataIB/Archive 7

Archive 1

←

Archive 5

Archive 6

Archive 7

Archive 8

Add more wbr in URLs

{{edit template-protected}} The current url2 function only adds soft line-breaks after dots in the URL. This is insufficient for things as simple as http://opensource.org/licenses/HPND when put in an infobox.

Since the function already references Module:URL, a much better way to do it would be to just reuse what the Module exports. The block starting with p.url2 should be rewritten as:

local fmt_url = require([[Module:URL]])._url           -- put this near the top

-------------------------------------------------------------------------------
-- url2 takes a parameter url= that is a proper url potentially followed by an edit icon
-- It returns a wikitext representation with line-wraps for infobox use.
-- If no parameter is supplied, it returns nothing.
-- This is the equivalent of Template:URL
-- but it keeps the "edit at Wikidata" pen icon out of the microformat.
-- Usually it will take its url parameter directly from a Wikidata call:
-- e.g. {{#invoke:WikidataIB |url2 |url={{wdib |P856 |qid=Q23317 |fwd=ALL |osd=no}}
-------------------------------------------------------------------------------
-- Dependencies: Module:URL
-------------------------------------------------------------------------------
p.url2 = function(frame)
	local txt = frame.args.url or ""
	if txt == "" then return nil end
	local url, icon = txt:match("(.+) (.+)")
	return fmt_url(url or txt) .. (icon and ' ' .. icon or "")
end

Artoria2e5 🌉 12:37, 15 July 2020 (UTC)

The module doesn't currently reference Module:URL and it's preferable to reduce the number of external dependencies, rather than increase them unnecessarily. One of the issues with using {{URL}} which prompted the fork to {{URL2}} was that passing a blank url causes an error message by default in URL, but not in URL2:

• {{#invoke:URL |url | }} → {{URL|example.com|optional display text}}
• {{#invoke:WikidataIB |url2 |url= }} →

There is little point in re-using the code from Module:URL if it's going to reintroduce the problem that the fork was intended to fix. If the extra functionality required is simply to add word break opportunities at forward-slashes, then simplistically, changing to

• local disp, _ = addr:gsub("%.", "<wbr>."):gsub("/", "<wbr>/")
  

would seem to me to achieve the desired result. Similarly, fragments could be accommodated, but I don't see the use-case for that in infoboxes. --RexxS (talk) 20:10, 15 July 2020 (UTC)

Infoboxes still using Module:Wikidata directly

And here are 97 more that are using Module:Wikidata directly:

I have noted infoboxes with 2,000 or more transclusions; I may have missed a couple, made an error or two, or both. All of the above need to be checked manually to see if they really do transclude Module:Wikidata and if they are convertible to WikidataIB; I didn't do any checking myself.

Any editor here is welcome to annotate, strike out, or otherwise fix or update either of the lists above. – Jonesey95 (talk) 19:43, 2 July 2020 (UTC)

I am not sure if all of those are directly transcluded invocations or not. I would start with a source search like searching template source for "FETCH_WIKIDATA" (Module:Wikidata seems to be the only thing that uses the "FETCH_WIKIDATA" sentinel value; after we get rid of those we can look harder for every transcluded invocation) instead of Special:WhatLinksHere/Module:Wikidata. There is also some more useful information at Module talk:Wikidata#Porting Guide. —Uzume (talk) 15:31, 13 September 2020 (UTC)

I am not sure either, hence my disclaimers above, but they are easy to check by looking at the template code. Infobox AFL biography, for example, contains "invoke:Wikidata|claim|P18" in its template code. The search result linked above contains 100 infobox templates (excluding sandboxes) and overlaps pretty well with the list I made above. If you want to add to the list above, please do so. If you find that a template in the list above does not need modification, feel free to strike it out, as I have done with Infobox Tibetan Buddhist monastery. – Jonesey95 (talk) 15:46, 13 September 2020 (UTC)

Uppercase first letter

Is there an easy way to make the first character uppercase (which is the usual format for parameters in an infobox) apart from stripping off the icon and using the ucfirst magic word? — Martin (MSGJ · talk) 13:41, 23 September 2020 (UTC)

Instead of the magic word, you could try this. Rehman 15:24, 23 September 2020 (UTC)

Perfect, thank you — Martin (MSGJ · talk) 15:58, 23 September 2020 (UTC)

Convert units

I know {{convert}} contains from clever functions to get quantities from wikidata and convert them. I wondered if it possible to use this module, so that the parameters |fwd= and |osd= can be used to match the other fields in the infobox. But I don't if/how I can put the output of this module through the convert template. Any advice please? — Martin (MSGJ · talk) 13:29, 23 September 2020 (UTC)

Have you looked at the (extensive!) documentation for Module:Wikidata or Module:Wd? Do a Find for "unit" on those pages. – Jonesey95 (talk) 15:20, 23 September 2020 (UTC)

@Martin: If you want to stick with WikidataIB, you can use the |convert= parameter (alias conv) which pipes the output directly through Template:Cvt:

• for Wearmouth Bridge (Q940078), length (P2043)
• {{#invoke:WikidataIB |getValue |P2043 |qid=Q940078 |fwd=ALL |osd=n |conv=y}} → 375 ft (114 m) 

It's documented at Module:WikidataIB #Parameters to getValue. Hope that helps. --RexxS (talk) 16:47, 23 September 2020 (UTC)

That's just what I'm looking for, thanks. I looked through that table twice so no idea why I didn't spot that option. — Martin (MSGJ · talk) 17:50, 23 September 2020 (UTC)

Label truncated

{{#invoke:WikidataIB|getLabel|qid=Q6918608}}

gives Mott, Hay and Anderson

{{#invoke:WikidataIB|getValue|qid=Q940078|P287|fwd=ALL|osd=0}}

gives Mott, Hay and Anderson  (now fixed, was just Mott)

For some reason the label is truncated, presumably because of the comma. How can I override this? — Martin (MSGJ · talk) 13:10, 23 September 2020 (UTC)

@Martin: That's a tough one, because the module prefers the local sitename (where it exists) to avoid using the label because of vandalism. Unfortunately, enwiki article titles commonly contain parenthetical or comma separated disambiguators, so it strips anything in parentheses or after a comma, e.g. John Smith (cricketer) → John Smith and Hayes, Middlesex → Hayes. I could create another parameter to switch to using the label instead of the sitename, but it would leave the field much more vulnerable to vandalism. I'll knock up some code in the sandbox to check it out. --RexxS (talk) 17:09, 23 September 2020 (UTC)

@Martin: In the sandbox, I've implemented a new parameter |uselabel= (alias uselbl, defaults to false) that forces the call to display the label instead of displaying the disambiguated sitelink:

• {{#invoke:WikidataIB/sandbox|getValue|qid=Q940078|P287|fwd=ALL|osd=n}} → Mott, Hay and Anderson  (now fixed, was just Mott)
• {{#invoke:WikidataIB/sandbox|getValue|qid=Q940078|P287|fwd=ALL|osd=n |uselbl=y}} → Mott, Hay and Anderson 

See if that does the job for you and we can update the main module if so. --RexxS (talk) 17:43, 23 September 2020 (UTC)

That would be perfect. I think using the label would be better in most cases, although if vandalism is a real problem then I can understand reluctance. — Martin (MSGJ · talk) 17:47, 23 September 2020 (UTC)

@Martin: I'm afraid that vandalism of labels on Wikidata is a huge problem, while it's near impossible to vandalise a sitelink – hence the effort I put in to using the sitelink by default. I often look at the Wikidata vandalism dashboard and remain discouraged by the amount of vandalism that occurs. The root cause is that there are only about 46 articles per active user on the English Wikipedia, while there are 3747 articles per active user on Wikidata. I've updated the main module now. --RexxS (talk) 18:45, 23 September 2020 (UTC)

• {{#invoke:WikidataIB|getValue|qid=Q940078|P287|fwd=ALL|osd=n}} → Mott, Hay and Anderson  (now fixed, was just Mott)
• {{#invoke:WikidataIB|getValue|qid=Q940078|P287|fwd=ALL|osd=n |uselbl=y}} → Mott, Hay and Anderson 

Thanks, I have used it for that particular property to avoid the original problem. But unless I use |uselbl=y for every property, there is no way to ensure it won't happen with another property. How about the following: if the sitelink equals the label or one of the aliases (up to case differences) then do not truncate the commas. — Martin (MSGJ · talk) 19:52, 23 September 2020 (UTC)

@Martin: That's looks like a good improvement. Aliases are another can of worms, so I've left that out for the moment, but skipping the sitelink processing altogether if the the label and sitelink are the same (apart from case) should clearly be more efficient. The implementation in the sandbox looks good enough and simple enough for me to be confident in updating the main module. It should all work now without using the |uselbl= parameter. Thank you. --RexxS (talk) 14:22, 24 September 2020 (UTC)

Wrapping of pencil icon

Would it be possible to prevent a line break just before the pencil icon because it looks a little unsightly? — Martin (MSGJ · talk) 09:39, 22 September 2020 (UTC)

@Martin: I thought I had done that. The pen icon is separated from the preceding text by a non-breaking space, as you can see if you inspect this:

• {{wdib|fwd=ALL|qid=Q42|P26}} → Jane Belson 

If I experiment by forcing a narrow column, we get:

• 6em gives:
  Jane Belson 
• 5em gives:
  Jane Belson 

That's a nuisance. My browser prefers to break the line after the non-breaking space for certain column widths! and I assume yours does too. It makes you wonder what the point of the nbsp is. In the module sandbox I tried moving the non-breaking space inside the span that encloses the pen image and it gives the same problem:

• 6em gives:
  Jane Belson 

In the module sandbox1, I've even tried removing the span altogether with no luck. It looks like browsers treat the image as a reason to ignore the non-breaking nature of the nbsp.

• With image gives:
  Jane Belson 
• With  text gives:
  Jane Belson P

At that point, I'm out of ideas. I'll head over to Stack Overflow and see if there are any solutions there. --RexxS (talk) 11:09, 22 September 2020 (UTC)

Thanks for the answer and confirming that you are seeing the same issue as I — Martin (MSGJ · talk) 11:58, 22 September 2020 (UTC)

You might have to wrap the whole thing in a div or a span with class="nowrap". I don't know how to do that in Lua. – Jonesey95 (talk) 15:21, 22 September 2020 (UTC)

@Jonesey95: we can't do that. The text returned from Wikidata can be sizeable and has to fit inside an infobox. The result of nowrapping the entire field could be an infobox as wide as the screen. --RexxS (talk) 19:08, 22 September 2020 (UTC)

"It looks like browsers treat the image as a reason..." caught my eye. I haven't checked, but is that icon actually an image file? What about changing that to a Unicode character (I could think of U+21C5: ⇅), or maybe a Wingdings character (1F589: 🖉). There are more options in those links. Rehman 04:14, 23 September 2020 (UTC)

It's File:OOjs UI icon edit-ltr-progressive.svg. Maybe using a character would be better - good idea! That Wingdings character in blue might be nice — Martin (MSGJ · talk) 08:25, 23 September 2020 (UTC)

Using the unicode character for an "upper right pencil" gives:

Jane Belson ✐

That might be a possibility if everybody can see it. I would need to check it across different operating systems. --RexxS (talk) 16:44, 24 September 2020 (UTC)

That one looks good. Can the underline be suppressed? — Martin (MSGJ · talk) 16:57, 24 September 2020 (UTC)

I don't see an underline (working on Windows, latest Chrome browser). But underlining of text can always be suppressed by enclosing the text in <span style="text-decoration: none;"> ... </span> or incorporating that style in an existing tag or class. --RexxS (talk) 17:46, 24 September 2020 (UTC)

Weird that I still see the underline on my browser (Windows/Chrome) even with text-decoration: none — Martin (MSGJ · talk) 18:48, 24 September 2020 (UTC)

Jane Belson ✐

I'm obviously not understanding how to use the CSS properly — Martin (MSGJ · talk) 20:36, 26 September 2020 (UTC)

Strip slash from the end of domain-only URLs

In the second and third infobox of Microsoft Office, Wikidata value of https://office.com/ is displayed as office.com/. {{URL|https://office.com/}} is displayed as office.com (without a trailing slash), and I think the template got it right. Can someone change this module so that it removes the trailing slash if (and only if) the URL consists of only a domain name? (So e.g. https://example.org/page/ would still display the trailing slash.) Thanks in advance! —Tacsipacsi (talk) 20:34, 23 September 2020 (UTC)

I removed the slash on Wikidata. Problem solved? — Martin (MSGJ · talk) 08:18, 24 September 2020 (UTC)

@Tacsipacsi: I've fixed the code:

• {{#invoke:WikidataIB |url2 |url=https://office.com}} → office.com 
• {{#invoke:WikidataIB |url2 |url=https://office.com/}} → office.com 
• {{#invoke:WikidataIB |url2 |url=https://example.org/page/}} → example.org/page/ 

Let me know if you find any more problems. --RexxS (talk) 15:58, 24 September 2020 (UTC)

@MSGJ: No, that only hides the issue—there may be tens of thousands of Wikidata items (or even more) that still have trailing slash, and new ones can be created any time.

@RexxS: Your approach of “everything that contains a period is a domain name” is not 100% correct, see e.g. {{#invoke:WikidataIB |url2 |url=https://example.org/wiki/index.php/}} → example.org/wiki/index.php/ ; it actually fails for internationalized domain names like .рф as well ({{#invoke:WikidataIB |url2 |url=http://кц.рф/} → кц.рф ), although those are probably not that common. ^([^/]+)/$ (i.e. anything that contains no slash except for the trailing one) looks better. —Tacsipacsi (talk) 20:34, 25 September 2020 (UTC)

@Tacsipacsi: I think that https://example.org/wiki/index.php/ is an invalid url. As far as I know, it doesn't actually hurt to strip a trailing / from any url, but perhaps you can think of a counter-example? I agree about the non-ascii tlds, but I think I'll wait for an actual example to crop up so that I can see what might arise before I hammer the server with yet another code change. It had a tough day yesterday. --RexxS (talk) 22:58, 25 September 2020 (UTC)

@RexxS: I don’t know where the structure of URLs is defined, but I’m pretty sure it’s valid—why would it not be? Actually, I’ve seen MediaWiki wikis with such URL scheme (e.g. the main page would be https://example.org/wiki/index.php/Main_Page), although unfortunately I don’t remember which ones. In the index.php/ case, the trailing slash probably doesn’t matter, but https://en.wikipedia.org/wiki/Module_talk:WikidataIB is quite different from https://en.wikipedia.org/wiki/Module_talk:WikidataIB/. I could create a page named https://en.wikipedia.org/wiki/Module:WikidataIB.lua/, where dropping trailing slash would change the link to point to something entirely different (even though this actual example doesn’t seem to make much sense, but I hope you get the idea). —Tacsipacsi (talk) 23:35, 25 September 2020 (UTC)

@Tacsipacsi: The point is that a webserver will try to match the final segment with a file in the directory pointed to by the preceding part; if that does not exist, it will then attempt to treat the final segment as a directory and look inside that for index.htm, index.php, default.asp, etc. depending on its configuration. That means that http://www.metropolis2.co.uk/StRexx, http://www.metropolis2.co.uk/StRexx/ and http://www.metropolis2.co.uk/StRexx/index.htm all return the same file. You'll find that MediaWiki servers respond to urls of the form https://example.org/w/index.php?title=Main_Page, but that requests the index.php file and uses it to read the name of the required page from the title parameter. The "Main_Page" part isn't actually part of the path to the executable file. Because MediaWiki servers process the segment after /wiki/ internally, we are allowed to create pages whose titles contain characters that would not normally be allowed in names of parts of urls. You can see the issue when you try to construct the sandbox or doc page for https://en.wikipedia.org/wiki/Module:WikidataIB.lua/ – but that issue does not generally arise on normal webservers and is very unlikely to present a problem for the external websites found in our infoboxes. --RexxS (talk) 00:13, 26 September 2020 (UTC)

@RexxS: What do you mean by “normal webservers”? If an Apache server serving static HTML files from the /var/www/html directory, then yes, those don’t mind whether there’s a trailing slash after the final directory name. But I’m pretty sure these are quite a minority of today’s web traffic; it’s dominated with dynamic websites ranging from MediaWiki/Drupal/Joomla! running on LAMP, to Java application servers that do even TCP socket management on their own. Application servers process path information on their own and are free to decide whether the trailing slash is significant. (Probably most of the time it isn’t, but there’s no guarantee; I’ve seen websites that annoyingly consider trailing slash significant.) Yes, it’s unlikely that this causes problems, but it may. (By the way, I like the way c:Template:Wikidata Infobox is developed: active development takes place in the sandbox, and the main version is updated roughly monthly, so that the servers don’t need to reparse 3.1M pages too often. I also don’t see what’s the issue with creating Module:WikidataIB.lua//doc. Yes, its title looks ugly, but my point was that it’s possible, not that it’s nice.) —Tacsipacsi (talk) 18:40, 26 September 2020 (UTC)

@Tacsipacsi: you assert "I’m pretty sure these are quite a minority of today’s web traffic". I disagree completely. I just tried out the first dozen or so articles from "What links here" for Template:Url and couldn't find one where adding a final slash didn't return exactly the same site. No sensible website admin would configure their webserver to give different results for the two cases. There's just too much room for visitors to add or omit a trailing slash. You need to show some concrete examples of where an official website shows the difference you claim occurs before I'll be convinced you're not worrying about a problem that doesn't exist. --RexxS (talk) 22:21, 26 September 2020 (UTC)

@RexxS: No, I state that dynamic websites are the majority. These dynamic websites may, or may not, consider trailing slashes significant. For example, on the official website of the Eötvös Loránd University, https://www.elte.hu/en/equalaccess is a live link, while https://www.elte.hu/en/equalaccess/ is 404. —Tacsipacsi (talk) 23:24, 26 September 2020 (UTC)

@Tacsipacsi: that's odd. The official website in the infobox of Eötvös Loránd University is given as https://www.elte.hu/en/ which works with or without the trailing slash. The official website in the External links section is fetched from Wikidata and is the Hungarian version at https://www.elte.hu/ (which also works with or without the trailing /). I think you've just got a misconfigured subpage in your example. --RexxS (talk) 23:41, 26 September 2020 (UTC)

@RexxS: This is the official website of the ELTE. Not its homepage, but an official website, which is what you asked for. If you want a official website (P856) value, here you are: ELTE Faculty of Socal Sciences Department of Cultural Anthropology (Q31093231)’s homepage runs on the same buggy software. By the way, I honestly don’t understand why you fight so much over this for the sake of fighting—except for not wanting to change, you haven’t shown any reason not to change to this more robust yet just as simple regexp. —Tacsipacsi (talk) 17:35, 27 September 2020 (UTC)

@Tacsipacsi: I'm talking about how the call is used - in an infobox for an official website. I'm not trying to fight you, but I want to tease out the issues here. Before I retired I set up a lot of websites both dynamic and static for clients and I'm not used to finding customer-facing websites where mistyping a '/' would give them a 404. Nevertheless, it's been eight years since I retired and things change: I'm merely interested in the change so I don't make mis-assumptions in future. I've already changed the regex to your version in my master copy of the module, but I haven't updated the live version yet. Did you miss my comment "I agree about the non-ascii tlds, but I think I'll wait for an actual example to crop up so that I can see what might arise before I hammer the server with yet another code change"? If you think we've thrashed out all the issues, then I can make the new version live, but I didn't think there was any rush. --RexxS (talk) 21:55, 27 September 2020 (UTC)

@RexxS: There’s no rush, but I felt you don’t want to implement this change at all. I haven’t missed that comment, but probably misunderstood it. I’ve always been confident with my approach (and don’t even think retrospectively that this confidence was unjustified at any point), so it’s not me who’s yet to come to the conclusion that everything is fine. —Tacsipacsi (talk) 21:00, 28 September 2020 (UTC)

@Tacsipacsi: I've had to fix some errors caused by trying to solve the #Wrapping of pencil icon thread above, so I took the opportunity to implement your regex for url2 at the same time. Please let me know if you spot any problems now. Thanks --RexxS (talk) 14:36, 29 September 2020 (UTC)

Add wbr for /

Slightly related to the above. The {{url}} template seems to cause the url to line break nicely so it takes up less horizontal space. But when I used this module, the amount of space taken up by the infobox increased (on my browser) and it now looks quite ugly. Please compare this version to this version — Martin (MSGJ · talk) 14:16, 24 September 2020 (UTC)

@Martin: That's odd. I gave a solution for that in response to Module talk:WikidataIB/Archive 7 #Add more wbr in URLs, but either I never implemented it, or it was lost in the sandbox shuffling. Just put it down to senility. I've implemented the fix:

• {{#invoke:WikidataIB |url2 |url=https://www.sunderland.gov.uk/article/14608/Northern-Spire}} in a 14em column gives:
  www.sunderland.gov.uk/article/14608/Northern-Spire 

Let me know if that doesn't solve the problem for you. Cheers --RexxS (talk) 14:53, 24 September 2020 (UTC)

I was using getValue|P856. Should I change to use url2? — Martin (MSGJ · talk) 16:55, 24 September 2020 (UTC)

I wrote url2 specifically to format values fetched from Wikidata (they could be blank, of course, which trips up {{url}}). I would expect it to be used something like this in an infobox:

• |data99 = {{#invoke:WikidataIB |url2 |url={{wdib |P586 |qid={{{qid|}}} |fwd=ALL |osd=n |{{{website|}}} }} }}

where |website= is a local parameter that will override fetching from Wikidata. The template {{wdib}} is just a convenience wrapper for {{#invoke:WikidataIB |getValue}} --RexxS (talk) 17:39, 24 September 2020 (UTC)

Thanks - that's working well now — Martin (MSGJ · talk) 13:43, 25 September 2020 (UTC)

Caption

What is the easiest way to retrieve the media legend (P2096) (caption) of an image? This should be a qualifier of image (P18). Thanks — Martin (MSGJ · talk) 08:26, 30 September 2020 (UTC)

@Martin: it's relatively straightforward to use getValue from WikidataIB to return just a qualifier:

For Tower Bridge (Q83125)

• {{wdib |fwd=ALL |osd=n |P18 |qual=P2096 |qualsonly=y |qid=Q83125}} → Tower Bridge in 2014 

The only complication is that the media legend (P2096) is monolingual text, so there may be versions in other languages. The code should recognise the site language, so you should get the English version automatically.

The only problem might occur if there is a media legend in another language, but not one in English. If you get something like this:

• Le Tower Bridge depuis le bord de la Tamise. 

you'll need to decide on whether to keep the code unchanged, but then follow the pen icon link to Wikidata and add a media legend in English; or to explicitly specify the language in the call (but then you should get nothing if there's no English version on Wikidata):

• {{wdib |fwd=ALL |osd=n |P18 |qual=P2096 |qualsonly=y |lang=en |qid=Q83125}} → Tower Bridge in 2014 

Obviously you use |qid={{{qid|}}} in the actual template. Sorry it wasn't quite as short an answer as I would have wished. Cheers --RexxS (talk) 12:30, 30 September 2020 (UTC)

That's great, it's always better to have the long answer! The only issue I can think of, is if an image is supplied locally but without a caption. Then a caption may be taken from an image on wikidata but it would then be incorrect. Or what if two images are on wikidata, how would it choose between the captions? — Martin (MSGJ · talk) 13:44, 30 September 2020 (UTC)

I think Mike Peel wrestled with those problems and might be able to relate his experiences.

I think the solution to the locally supplied image is to wrap the wikidata call for the caption in something like {{#if:{{{image|}}} |{{caption|}} |{{wdib |fwd=ALL |osd=n |P18 |qual=P2096 |qualsonly=y |qid={{{qid|}}} }} which would only use a locally supplied caption with a locally supplied image.

There's a constraint on Wikidata that image (P18) should have a single-value, but it does get ignored. You should always limit the number of images returned by setting |maxvals=1 if you're using the usual image syntax. That will return the first image and the first media legend, so it should avoid the potential for having a caption not associated with the image (probably!). --RexxS (talk) 20:40, 30 September 2020 (UTC)

Help!

There are a problem, I can't work it out. Maybe I need getPropOfProp, or perhaps getQualifierValue or getValueByQual or even getSumOfParts. The trouble there is that doesn't seem to be much in the way of documentation.

The problems is of a (Philippine) place, say Cebu (Q13786) with property highest point (P610) with one or more instances of places as qualifier, for instance Mount Manunggal (Q6922008) which will each have a qualifier of elevation above sea level (P2044). So how can I show direct elevation? → Cebu 1097 m

Not Samuel Pepys (talk) 14:16, 23 October 2020 (UTC)

@Not Samuel Pepys: For Cebu (Q13786) with property highest point (P610), you can find the value of the qualifier elevation above sea level (P2044) like this:

• {{#invoke:WikidataIB |getValue |P610 |fwd=ALL |osd=n |noicon=t |qual=P2044 |qid=Q13786}} → Mount Manunggal (1,097 metre)

If you just want the value of of the qualifier without the property value, then add the |qualsonly=true parameter:

• {{#invoke:WikidataIB |getValue |P610 |fwd=ALL |osd=n |noicon=t |qual=P2044 |qualsonly=t |qid=Q13786}} → 1,097 metre

If you want the unit abbreviated or conversions, let me know as that will require a small patch to enable abbreviations and conversions for qualifiers using getValue.

Optionally, you can fetch the values of properties of Mount Manunggal (Q6922008) by using getPropOfProp from Cebu (Q13786) like this:

• {{#invoke:WikidataIB |getPropOfProp |prop1=P610 |fwd=ALL |osd=n |noicon=t |prop2=P2044 |qid=Q13786}} → 1,097 metre

That works because highest point (P610) is stored in Wikidata both as a qualifier in the Cebu (Q13786) entry and as a property in the Mount Manunggal (Q6922008) entry.

Unit abbreviations and conversions already work for getPropOfProp:

• {{#invoke:WikidataIB |getPropOfProp |prop1=P610 |fwd=ALL |osd=n |noicon=t |prop2=P2044 |uabbr=t |qid=Q13786}} → 1,097 m
• {{#invoke:WikidataIB |getPropOfProp |prop1=P610 |fwd=ALL |osd=n |noicon=t |prop2=P2044 |conv=y |qid=Q13786}} → 1,097 m (3,599 ft)

I don't come here often. Is it me, or are there a couple of problemettes?

1 Minor problem in climate

A1 {{safesubst:#invoke:WikidataIB |getValue |P2564|qid=Q315703|fwd=ALL|sn=true|osd=no|noicon=true}}

gives the right answer Af

except that I want it unlink ...

A2 {{safesubst:#invoke:WikidataIB |getValue |P2564|qid=Q315703|fwd=ALL|sn=true|osd=no|noicon=true|linked=no}}

tropical rainforest climate

but it no longer gives the shortname.

short name (sn) has not enough description in main document, and none at all in the sandboxes.

2 Minor problem in scaling money

B1 ₱{{safesubst:#invoke:WikidataIB |getValue |P3087|qid=Q315771|fwd=ALL|rank=b|osd=no|noicon=true|su=false}}

unscaled→ ₱171,234,667.17

B2 ₱{{safesubst:#invoke:WikidataIB |getValue |P3087|qid=Q315771|fwd=ALL|rank=b|osd=no|noicon=true|scale=3|su=false}}

thousands→ ₱171,235 thousand

integer only

B3 ₱{{safesubst:#invoke:WikidataIB |getValue |P3087|qid=Q315771|fwd=ALL|rank=b|osd=no|noicon=true|scale=6|su=false}}

millions→ ₱171.2 million

has one decimal, not integer

B4 ₱{{safesubst:#invoke:WikidataIB |getValue |P3087|qid=Q315771|fwd=ALL|rank=b|osd=no|noicon=true|scale=9|su=false}}

billions→ ₱0.1712 billion

has four decimals, not integer

BY ₱{{safesubst:#invoke:WikidataIB |getValue |P3087|qid=Q315771|fwd=ALL|rank=b|osd=no|noicon=true|scale=a|su=false}}

auto scaling→ ₱171,235 thousand

it doesn't seem correct - scaling here should be scale=6

BZ ₱{{safesubst:#invoke:WikidataIB |getValue |P3087|qid=Q1889017|fwd=ALL|rank=b|osd=no|noicon=true|scale=a|su=false}}

auto scaling→ ₱1,590 million

it doesn't seem correct - scaling here should be scale=9

46.69.62.85 (talk) 12:24, 16 October 2020 (UTC)

2

2a rounding
I think it's trying to be too clever. See James Thurber – The Bear Who Let lt Alone	-- round scaled numbers to integers or 4 sig fig if (scale > 0 or sc == "a") then if amount < 1e4 then amount = roundto(amount, 4) else amount = math.floor(amount + 0.5) end end
I think it should all end up with 1D except scale 0, nothing to do with sig figs
2b auto scale
It seems wrong – this is the part:	if sc == "a" then -- automatic scaling if amount > 1e15 then scale = 12 elseif amount > 1e12 then scale = 9 elseif amount > 1e9 then scale = 6 elseif amount > 1e6 then scale = 3 else scale = 0 end else scale = tonumber(args.scale) or 0 if scale < 0 or scale > 12 then scale = 0 end scale = math.floor(scale/3) * 3 end local factor = 10^scale amount = amount / factor
I think it should be changing along	if sc == "a" then -- automatic scaling if amount > 1e12 then scale = 12 elseif amount > 1e9 then scale = 9 elseif amount > 1e6 then scale = 6 elseif amount > 1e3 then scale = 3 else scale = 0 end else scale = tonumber(args.scale) or 0 if scale < 0 or scale > 12 then scale = 0 end scale = math.floor(scale/3) * 3 end local factor = 10^scale amount = amount / factor
although I don't know why very large numbers are not given any scaling. See Long and short scales. And the coding is very slow.

1 A1: There is no use-case for an unlinked short name. Displaying something like Climate Af is nonsensical to most readers, whereas Climate Af allows the reader a chance to learn what the classification is. Your desire for unlinked text is not helpful.

1 A2: because there is no use-case for an unlinked short name, I only coded fetching a short name when the item is linked.

If you don't think there's enough documentation on short name, please feel free to add something to Module:WikidataIB/doc which is not protected.

2 B1 to B4 and 2a: Because these values are for use in infoboxes, the space is constrained. What is the point in quoting cents when we have values in the millions of dollars? I simply disagree with your suggestion that we should normally be placing values into infoboxes with 11 significant figures. I think 171.2 billion is far superior in an infobox to 171,234,667.17 in 99.9% of cases. Rounding these values to four sig fig is a good compromise between precision and use of available space. I completely reject your suggestion to round to 1 decimal place. If we scale 1,149 on my scheme to scale=3, we get 1.149 thousand. On your scheme, we get 1.1 thousand - that's a relatively big error.

2 BY, BZ and 2b: If we use autoscaling, I would expect 1,149 to display as 1,149, not as 1.149 thousand, which takes up far more space and is not in line with common usage. I disagree that is being "too clever". I'm ambivalent about bigger values, so I don't have a problem with displaying 1,149,000 as either 1.149 million or 1,149 thousand. In any given case, the autoscaling can be overriden by setting a scale value anyway.

Very big numbers are ambiguous when using trillion, etc. and who understands quadrillion, quintillion and so on? They could easily be implemented, but how much use would they get? Do you have examples of their use in infoboxes?

As for the coding being very slow, please feel free to re-write the module in faster code. There are several sandboxes you can use to demonstrate your improvements. --RexxS (talk) 22:38, 11 November 2020 (UTC)

Another problem

{{#invoke:WikidataIB |getValue |P1082||qid=Q2673519|fwd=ALL|rank=p n|osd=no|noicon=true|sorted=yes|qsorted=yes|maxvals=2|list=p-1|qo=true|qual=P585}} gives 1 May 2010 which is what I want. But giving full date {{#invoke:WikidataIB |getValue |P1082||qid=Q2673519|fwd=ALL|rank=p n|osd=no|noicon=true|sorted=yes|qsorted=yes|maxvals=2|list=p-1|qo=true|qual=P585|qdf=dmy}} (and / or |df=dmy) changes the date: 1 May 2010
Help! Not Samuel Pepys (talk) 17:27, 11 November 2020 (UTC)

@Not Samuel Pepys: WikidataIB uses the default sorting in Lua for property and qualifier values, so if you set |sorted=yes, it will sort the output values alphanumerically. The setting of |qsorted= is irrelevant because there is not more than one qualifier value in each case.

If we go through the steps in refining the values from Luzon (Q2673519), you can see what's happening. This is with |df=y (because the default for qualifiers is year-only):

• {#invoke:WikidataIB |getValue |P1082 |qid=Q2673519 |fwd=ALL |rank=p n |osd=no |noicon=true |qual=P585}} → 52,362,999 (2010), 57,470,092 (2015), 62,196,942 (2020)
• {#invoke:WikidataIB |getValue |P1082 |qid=Q2673519 |fwd=ALL |rank=p n |osd=no |noicon=true |sorted=yes |qual=P585}} → 52,362,999 (2010), 57,470,092 (2015), 62,196,942 (2020)
• {#invoke:WikidataIB |getValue |P1082 |qid=Q2673519 |fwd=ALL |rank=p n |osd=no |noicon=true |sorted=yes |qual=P585 |qo=y}} → 1 August 2015, 1 May 2010, 1 May 2020
• {#invoke:WikidataIB |getValue |P1082 |qid=Q2673519 |fwd=ALL |rank=p n |osd=no |noicon=true |sorted=yes |qual=P585 |qo=y |list=p-1}} → 1 May 2020

This is with |df=dmy:

• {#invoke:WikidataIB |getValue |P1082 |qid=Q2673519 |fwd=ALL |rank=p n |osd=no |noicon=true |qual=P585 |qdf=dmy}} → 52,362,999 (1 May 2010), 57,470,092 (1 August 2015), 62,196,942 (1 May 2020)
• {#invoke:WikidataIB |getValue |P1082 |qid=Q2673519 |fwd=ALL |rank=p n |osd=no |noicon=true |sorted=yes |qual=P585 |qdf=dmy}} → 52,362,999 (1 May 2010), 57,470,092 (1 August 2015), 62,196,942 (1 May 2020)
• {#invoke:WikidataIB |getValue |P1082 |qid=Q2673519 |fwd=ALL |rank=p n |osd=no |noicon=true |sorted=yes |qual=P585 |qo=y |qdf=dmy}} → 1 August 2015, 1 May 2010, 1 May 2020
• {#invoke:WikidataIB |getValue |P1082 |qid=Q2673519 |fwd=ALL |rank=p n |osd=no |noicon=true |sorted=yes |qual=P585 |qo=y |list=p-1 |qdf=dmy}} → 1 May 2020

As you can see, 2010 sorts before 2015, but 1 August 2015 sorts before 1 May 2010. I need to write a new sorting routine to replace the default for use when the values are dates. Sorry, but that's a bit more of a job and may take me a while to implement. For now, I'd recommend using the preferred value from Wikidata:

• {#invoke:WikidataIB |getValue |P1082 |qid=Q2673519 |fwd=ALL |rank=best |osd=no |noicon=true |qual=P585 |qdf=dmy}} → 62,196,942 (1 May 2020)
• {#invoke:WikidataIB |getValue |P1082 |qid=Q2673519 |fwd=ALL |rank=best |osd=no |noicon=true |sorted=yes |qual=P585 |qdf=dmy}} → 62,196,942 (1 May 2020)
• {#invoke:WikidataIB |getValue |P1082 |qid=Q2673519 |fwd=ALL |rank=best |osd=no |noicon=true |sorted=yes |qual=P585 |qo=y |qdf=dmy}} → 1 May 2020
• {#invoke:WikidataIB |getValue |P1082 |qid=Q2673519 |fwd=ALL |rank=best |osd=no |noicon=true |sorted=yes |qual=P585 |qo=y |list=p-1 |qdf=dmy}} → 1 May 2020

I'll make sure it's on the to-do list. --RexxS (talk) 21:58, 11 November 2020 (UTC)

I think the "easiest" would be using Y F d (in #time: syntax). As long as it was the right date, #time: would use what parts it needs without knowing which order the parts are. All my questions are connected with {{PH wikidata}} – Not Samuel Pepys (talk) 23:33, 11 November 2020 (UTC)

The module uses Module:Complex date to render dates in whatever language is required, and using mw.language:formatDate (the Scribunto implementation of the #time parser function) would break that functionality as well as failing when qualifiers like 'circa' are added. If I still had the value of the timestamp available when doing the sorting, I could sort that alphanumerically and that would be easiest way. I'm considering prepending the timestamp to the formatted date and then stripping it off after sorting as a solution to the problem. --RexxS (talk) 00:21, 12 November 2020 (UTC)

Wrong default for display parameter passed to Coord template by getCoords

Right now if you use the getCoords function and don't explicitly provide a display parameter, it sets a default of "inline, title". This is unexpected and unnecessary since {{Coord}} has a pre-existing default for display which is "inline". Thus, getCoords doesn't need to pass its own default display parameter. And even if it did, it should be "inline", not "inline, title". This is causing confusion for people who are migrating templates to use WikidataIB instead of {{Coord}} directly: [1][2]. Kaldari (talk) 04:10, 8 December 2020 (UTC)

@Kaldari: thanks for the bug report. In the sandbox I checked the result of not providing a default from getCoords and it looks fine - see Module talk:WikidataIB/sandbox/testing #Coordinates. I've now made that version live, so please ping me if any errors show up. Cheers --RexxS (talk) 20:43, 8 December 2020 (UTC)

Visibility of pen icon

It seems Wikidata has a bit of a problem with drive-by vandalism, and the prominent pen icon may be contributing to that. (I know Tower Bridge (Q83125) was suffering badly after the pen icons were added, to the extent that this item is now protected.) I was going to suggest suppressing these icons for non-confirmed users, if this is possible. — Martin (MSGJ · talk) 12:03, 15 December 2020 (UTC)

@MSGJ: I added the class "autoconfirmed-show" to the pen icon in the sandbox and tested it by checking against an unconfirmed alt account and when not logged in. It looked fine, so I've made the edit live. It works for Tower Bridge, so I guess we just have to wait to see if there are objections from elsewhere. --RexxS (talk) 17:46, 15 December 2020 (UTC)

Thanks. It's seems a reasonable precaution, and readers don't want to see all those icons anyway. — Martin (MSGJ · talk) 19:23, 15 December 2020 (UTC)

Returning a qualifier only for values where a second qualifier matches a given qval?

Currently if a statement has multiple values, getQualifierValue will return the requested qualifier for each of those values. Could a variant be made that only returns a the qualifier for one the values where a second qualifier matches a given qval. For example, Thomas Shafee (Q38382414) is an editor (Q1607826) for multiple journals. I would like to retrieve only the start time (P580) for the journal WikiJournal of Medicine (Q24657325).

Extended content

{{#invoke:WikidataIB |getQualifierValue |qid=Q38382414 |P39 |pval=Q1607826 |qual=P580 |fetchwikidata=ALL |onlysourced=no |noicon=true}} returns: June 2018, 2017, 24 July 2016, 26 November 2017, 24 May 2023 Ideally, would like: {{#invoke:WikidataIB |getQualifierValue |qid=Q38382414 |P39 |pval=Q1607826 |qual=P580 |qualtocheck=P642 |qualtocheckval=Q24657325 |fetchwikidata=ALL |onlysourced=no |noicon=true}} returns: 24 July 2016

Would that be possible to implement? T.Shafee(Evo&Evo)^talk 07:24, 3 December 2020 (UTC)

@Evolution and evolvability: it would be possible, I think, but I'll need an uninterrupted session to work up the code. I try to find a slot in the next week or so. --RexxS (talk) 20:46, 8 December 2020 (UTC)

@RexxS: Thank you so much in advance! Appreciated as always. T.Shafee(Evo&Evo)^talk 22:56, 8 December 2020 (UTC)

@Evolution and evolvability: I'm loathe to implement two more parameters, so I've implemented a filter parameter that looks like this: |filter = P642==Q22674854. It seems to work, but I'd prefer to see if it fits your needs and doesn't have bugs before I incorporate it into the main module.

In Thomas Shafee (Q38382414): property position held (P39) equal to editor (Q1607826) has multiple start time (P580) qualifiers. A filter can pick one of them.

Examples 2 and 3 filter on: (2) editor (Q1607826) of (P642) WikiJournal of Science (Q22674854), and (3) editor (Q1607826) of (P642) The Lancet (Q939416), returning the start time (P580) where the filter matches.

Demo of filter

Code	Result
{{#invoke:WikidataIB/sandbox |getQualifierValue |fwd=ALL |osd=n |qid=Q38382414 |P39 |pval=Q1607826 |qual=P580}}	June 2018, 2017, 24 July 2016, 26 November 2017, 24 May 2023
{{#invoke:WikidataIB/sandbox |getQualifierValue |fwd=ALL |osd=n |qid=Q38382414 |P39 |pval=Q1607826 |qual=P580 |filter=P642==Q22674854}}}	June 2018, 24 May 2023

If you get a chance, please test it out. I know you can provoke errors if you give nonsensical values for the filter, and I've tried to catch them, but I can't guarantee I've found them all. Cheers --RexxS (talk) 20:42, 15 December 2020 (UTC)

Excellent! I can completely understand the want to avoid additional parameters where possible. For the uses I've tried, it out for it seems to work well. The only case it couldn't handle have been:

• using a filter to try to find missing fields via their empty string return (could be very useful for omitting things with end dates to include only current items):

{{#invoke:WikidataIB/sandbox |getQualifierValue |fwd=ALL |osd=n |qid=Q38382414 |P39 |pval=Q1607826 |qual=P580 |filter=P582==}}

• using a date as the filter and a 'greater than' <= or 'less than' >= comparator (useful for uncluding things that were the start and end dates are outside a given period:

{{#invoke:WikidataIB/sandbox |getQualifierValue |fwd=ALL |osd=n |qid=Q38382414 |P39 |pval=Q1607826 |qual=P642 |filter=P580>=2016-01-01}}

• Could be useful to have an antifilter implemented !=

{{#invoke:WikidataIB/sandbox |getQualifierValue |fwd=ALL |osd=n |qid=Q38382414 |P39 |pval=Q1607826 |qual=P580 |filter=P642!=Q22674854}}

However, already very useful for the sort of filtering I'm lookng to start with. T.Shafee(Evo&Evo)^talk 06:03, 16 December 2020 (UTC)

@Evolution and evolvability: There comes a point where I end up writing a query language instead of a module to return data for use in infoboxes. The first use you suggest really is best solved by a query using the WDQS. We don't put missing fields in infoboxes.

I considered the possibility of using operators other than equality and I deliberately coded the filter parsing to allow easy expansion in the future. However, dates are a much less structured datatype because we may have to accept inputs of dmy, mdy, ymd, and others, and Wikidata stores a timestamp, so there's a fair bit of processing to get a comparison. I have most of the code already elsewhere in the module, so it's not too bad, but it won't be high on my to-do list. Cheers --RexxS (talk) 22:25, 16 December 2020 (UTC)

URL handling

In Grapette, {{Infobox drink}} is fetching URLs that end up formatted not quite right. Here's one of them:

<tr><th scope="row">Website</th><td><span class="url">[http://www.grapette.com<span class='penicon'> www<wbr/>.grapette<wbr/>.com<span class='penicon'>]</span> [[File:OOjs UI icon edit-ltr-progressive.svg |frameless |text-top |10px |alt=Edit this on Wikidata|link=https://www.wikidata.org/wiki/Q5597031?uselang=en#P856|Edit this on Wikidata]]</span></td></tr>

Note the two opening span tags with class=penicon being opened inside the URL brackets, which are already wrapped in a span tag. One of those misplaced span tags is never closed. I think the URL needs a span tag and the penicon needs a span tag, but something appears to be going wrong here. I think it should look like this:

<tr><th scope="row">Website</th><td><span class="url">[http://www.grapette.com www<wbr/>.grapette<wbr/>.com]</span> <span class='penicon'>[[File:OOjs UI icon edit-ltr-progressive.svg |frameless |text-top |10px |alt=Edit this on Wikidata|link=https://www.wikidata.org/wiki/Q5597031?uselang=en#P856|Edit this on Wikidata]]</span></td></tr>

Or something close to that. – Jonesey95 (talk) 03:20, 29 September 2020 (UTC)

This is also happening with {{Infobox software}} at SLinCA@Home. The invalid wikitext is also visible in the example at Module:WikidataIB#Function url2. – Jonesey95 (talk) 13:27, 29 September 2020 (UTC)

Hi Jonesey95. Thanks for spotting that. It's caused by my attempts to resolve the #Wrapping of pencil icon thread above. The code in url2 assumed that the text and the pen-icon were separated by a non-breaking space, so went south when I moved the nbsp inside the span. I've restored the code that generates the pen icon to its previous state. Let me know if that doesn't fix it. --RexxS (talk) 14:33, 29 September 2020 (UTC)

Those two articles are fixed now, so it looks like you did something good in the most recent edits. Thanks. – Jonesey95 (talk) 14:50, 29 September 2020 (UTC)

More problems at Swing Bridge, River Tyne via {{Infobox bridge}}. – Jonesey95 (talk) 22:47, 28 October 2020 (UTC)

Yes, one can see the issue with example 4 at Module:WikidataIB#Function url2 — Martin (MSGJ · talk) 15:16, 29 October 2020 (UTC)

@Jonesey95: do you know which edit caused this, and can it be reverted? — Martin (MSGJ · talk) 19:02, 31 October 2020 (UTC)

I think it was one of these five edits by RexxS. – Jonesey95 (talk) 21:53, 31 October 2020 (UTC)

I suspect the later two edits on 24 Sep. I've put the prior version in Module:WikidataIB/sandbox and will do some testing — Martin (MSGJ · talk) 10:38, 1 November 2020 (UTC)

Gentle poke to prevent archiving. As far as I know this is still an error, and I haven't had time to look into it — Martin (MSGJ · talk) 10:41, 17 November 2020 (UTC)

@MSGJ: I think the function now adds the extra <wbr> tags, so the concerns in articles should be met. Can you confirm that, Martin?

Example 4 at Module:WikidataIB#Function url2 is a test of the case where an editor supplies {{url|http://www.example.com/}} as the local parameter in an infobox, instead of http://www.example.com/. That's an error on the part of the editor, and I was trying to catch that and rectify in the url2 code. I need to have another look at how best to fix that now, but it's not what I'd consider a "breaking case" if an erroneous input produces an erroneous output. --RexxS (talk) 20:15, 26 November 2020 (UTC)

Thanks for looking into this. I think the problems on Infobox bridge were caused by the parameters being enclosed with {{url}}. For example

{{#invoke:WikidataIB|url2|url={{url|https://www.portoftyne.co.uk/about-us/history/heritage-sites/heritage-sites}}}}

produces

www.portoftyne.co.uk/about-us/history/heritage-sites/heritage-sites www.portoftyne.co.uk/about-us/history/heritage-sites/heritage-sites www<wbr/>.portoftyne<wbr/>.co<wbr/>.uk<wbr/>/about-us<wbr/>/history<wbr/>/heritage-sites<wbr/>/heritage-sites]</span>] 

which is what we were seeing on Swing Bridge, River Tyne. I believe it is quite common for this template to be used in infoboxes, so unless there is a reliable way of detecting it, I could not use url2 in the way I was previously. Would it be better if only the value from wikidata were put through url2, and the fallback value just displayed raw? — Martin (MSGJ · talk) 21:05, 26 November 2020 (UTC)

@MSGJ: I finally remembered what I'd been doing. The call to ur2 in WikidataIB was the prototype for an alternative function that I developed in Module:URL. I recommend using Template:URL2. It uses a lot of the code used by {{url}} but doesn't give error messages with a nil input (useful for Wikidata) and can take the output of {{url}} as its input if an editor uses that as the local parameter.

• {{URL2|}} →
• {{URL2|www.portoftyne.co.uk/about-us/history/heritage-sites/heritage-sites}} → www.portoftyne.co.uk/about-us/history/heritage-sites/heritage-sites
• {{URL2|https://www.portoftyne.co.uk/about-us/history/heritage-sites/heritage-sites}} → www.portoftyne.co.uk/about-us/history/heritage-sites/heritage-sites
• {{URL2|{{url|https://www.portoftyne.co.uk/about-us/history/heritage-sites/heritage-sites}}}} → www.portoftyne.co.uk/about-us/history/heritage-sites/heritage-sites

The point is to use it when designing infoboxes, so in Template:Infobox bridge I would code the Website data like this:

• | data15 = {{URL2|{{{website|}}}}}

To use the official website (P856) property from Wikidata, you could write:

• | data15 = {{URL2|{{#invoke:WikidataIB|getValue|P856|name=website|fetchwikidata={{{fetchwikidata|}}}|onlysourced={{{onlysourced|no}}}|{{{website|}}}}}}}

or the equivalent short-form:

• | data15 = {{URL2|{{wdib|P856|name=website|fwd={{{fetchwikidata|}}}|osd={{{onlysourced|no}}}|{{{website|}}}}}}}

I probably should deprecate the url2 function in WikidataIB, as its only advantage is keeping the penicon from Wikidata out of the microformat that is created and I could replicate that in Module:URL. --RexxS (talk) 02:14, 27 November 2020 (UTC)

Just to confirm that {{URL2}} was deployed successfully and seems to be working correctly. Thanks for looking into this — Martin (MSGJ · talk) 14:19, 9 December 2020 (UTC)

Follow-up

I've come across a problem:

• {{wdib|P856|qid=Q7123825|fwd=ALL|osd=no}} → http://www.padmabridge.gov.bd 
• But {{URL2|{{wdib|P856|qid=Q7123825|fwd=ALL|osd=no}}}} → www.padmabridge.gov.bd 

The File:OOjs should not be there — Martin (MSGJ · talk) 20:29, 2 January 2021 (UTC)

I've removed URL2 from Template:Infobox bridge until this error is resolved — Martin (MSGJ · talk) 06:35, 3 January 2021 (UTC)

I can't help but feel this could be coded more sensibly. Currently {{wdib}} adds a pencil icon, then URL2 (I think) is trying to remove it again (and failing), and in the end we want a pencil icon. Would it not be better to read the data, then format it, then add the pencil icon on at the end? — Martin (MSGJ · talk) 07:03, 3 January 2021 (UTC)

I've noticed that {{#invoke:WikidataIB |url2|... seems to be doing the job correctly — Martin (MSGJ · talk) 07:12, 3 January 2021 (UTC)

• {{#invoke:WikidataIB |url2 |url={{wdib|P856|qid=Q7123825|fwd=ALL|osd=no}}}} → www.padmabridge.gov.bd 

@Martin: yes, the url2 code in WikidataIB is more likely to handle the data from Wikidata correctly, but does a worse job with values entered locally. The problems I've been having is that I wanted to use the functionality of the tried and tested Module:URL to handle the potential input from WikidataIB, and I didn't write that module, so it doesn't perform exactly as I would have wished. I also assumed that I could take shortcuts and leave the pen icon code in place while Module:URL processed it. I've now done as you suggested, and stripped off the pen icon before passing the url to the main part of Module:URL, then adding it back when it is returned. The updated code is in Module:URL/sandbox (which is called from {{URL2/sandbox}}}:

• {{URL2|{{wdib|P856|qid=Q7123825|fwd=ALL|osd=no}}}} → www.padmabridge.gov.bd 
• {{URL2/sandbox|{{wdib|P856|qid=Q7123825|fwd=ALL|osd=no}}}} → www.padmabridge.gov.bd 

If you have a chance to test it, that would be helpful, but I think it should be fine to implement in the main Module:URL as it only affects the call from {{URL2}}. Please let me know if that doesn't fix the problem now. Cheers --RexxS (talk) 13:54, 3 January 2021 (UTC)

That seems to be working fine, thank you. If you don't mind me saying, it still seems rather cumbersome. Rather than

Read URL → add pen → remove pen → format URL → add pen

would it not be possible to

Read URL → format URL → add pen

I appreciate it would require another function in this module, but I think it would be more robust and less likely to break again in the future — Martin (MSGJ · talk) 08:11, 5 January 2021 (UTC)

One thing I still don't understand is what caused it to break this time, because it was definitely working on 9 December when I followed your advice above — Martin (MSGJ · talk) 08:13, 5 January 2021 (UTC)

@MSGJ:. The problem is that "Read URL → add pen" takes place in Module:WikidataIB and "format URL" takes place in Module:URL. There is an intermediate step of "return wikitext from first module → pass wikitext to second module" that takes place in a template, outside of the modules. I don't want to duplicate all of the code in Module:URL here, nor does anyone want to duplicate getValue in Module:URL, so we work with a two-module solution. The way it currently works may appear cumbersome, but the pen icon requires not only the image used, but also the Wikidata link, which needs the item-ID and the property-ID. So it is actually quite elegant in passing not only the url itself, but also all of the other pieces of information from one module to another in a single piece of text. Of course, it requires a bit of unpacking on entry to the second module, but as you saw, that's not a big deal. --RexxS (talk) 16:21, 5 January 2021 (UTC)

Okay. I was assuming that this module could call that module to do the bits it needs. — Martin (MSGJ · talk) 16:28, 8 January 2021 (UTC)