Module talk:WikidataIB/Archive 7

Add more wbr in URLs
Module:WikidataIB 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:

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


 * Template:Infobox AFL biography (14,000 transclusions)
 * Template:Infobox CFL biography (6,000 transclusions)
 * Template:Infobox GAA manager
 * Template:Infobox Hindu temple (2,000 transclusions)
 * Template:Infobox NCAA athlete
 * Template:Infobox National Hockey League coach
 * Template:Infobox Tibetan Buddhist monastery (wrapper of Infobox religious building)
 * Template:Infobox alpine ski racer
 * Template:Infobox amateur wrestler
 * Template:Infobox anatomy (4,000 transclusions)
 * Template:Infobox ancient site (4,000 transclusions)
 * Template:Infobox archives
 * Template:Infobox artery
 * Template:Infobox artwork/wikidata
 * Template:Infobox astronomical event
 * Template:Infobox astronomical object
 * Template:Infobox astronomical survey
 * Template:Infobox badminton player (3,000 transclusions)
 * Template:Infobox bandy biography
 * Template:Infobox bandy team
 * Template:Infobox bone
 * Template:Infobox book (45,000 transclusions)
 * Template:Infobox book/wikidata
 * Template:Infobox brain
 * Template:Infobox cell
 * Template:Infobox central bank
 * Template:Infobox checkers biography
 * Template:Infobox cheese
 * Template:Infobox chemical/identifiers
 * Template:Infobox chess biography (3,000 transclusions)
 * Template:Infobox college coach (10,000 transclusions)
 * Template:Infobox college football player
 * Template:Infobox crater
 * Template:Infobox cricketer (27,000 transclusions)
 * Template:Infobox curler (2,000 transclusions)
 * Template:Infobox curler/Wikidata
 * Template:Infobox cyclist (14,000 transclusions)
 * Template:Infobox darts player
 * Template:Infobox deity/Wikidata
 * Template:Infobox disc golfer
 * Template:Infobox drug class
 * Template:Infobox drug mechanism
 * Template:Infobox embryology
 * Template:Infobox fencer
 * Template:Infobox field hockey player
 * Template:Infobox figure skater (4,000 transclusions)
 * Template:Infobox film/Wikidata
 * Template:Infobox football official
 * Template:Infobox golfer (4,000 transclusions)
 * Template:Infobox gymnast (3,000 transclusions)
 * Template:Infobox handball biography (4,000 transclusions)
 * Template:Infobox historic site/Wikidata
 * Template:Infobox horse person
 * Template:Infobox horseracing personality
 * Template:Infobox lacrosse player
 * Template:Infobox library classification
 * Template:Infobox ligament
 * Template:Infobox lighthouse (3,000 transclusions)
 * Template:Infobox lunar crater or mare
 * Template:Infobox lymph
 * Template:Infobox martial artist (5,000 transclusions)
 * Template:Infobox medical condition (old)/Wikidata
 * Template:Infobox medical equipment
 * Template:Infobox medical intervention
 * Template:Infobox meteorite
 * Template:Infobox microanatomy
 * Template:Infobox motorcycle
 * Template:Infobox mountaineer
 * Template:Infobox muscle
 * Template:Infobox museum/wikidata
 * Template:Infobox nerve
 * Template:Infobox netball biography
 * Template:Infobox neuron
 * Template:Infobox observatory
 * Template:Infobox officeholder/Wikidata
 * Template:Infobox organization/Wikidata
 * Template:Infobox player of English billiards
 * Template:Infobox pool player
 * Template:Infobox professional wrestling team
 * Template:Infobox project
 * Template:Infobox recurring event/Wikidata
 * Template:Infobox religious biography/Wikidata
 * Template:Infobox religious building (10,000 transclusions)
 * Template:Infobox religious building/Wikidata
 * Template:Infobox skier (2,000 transclusions)
 * Template:Infobox snooker player
 * Template:Infobox snooker player season
 * Template:Infobox squash player
 * Template:Infobox sumo wrestler
 * Template:Infobox surfer
 * Template:Infobox telescope
 * Template:Infobox tennis biography (8,000 transclusions)
 * Template:Infobox tennis player season
 * Template:Infobox tract
 * Template:Infobox vein
 * Template:Infobox volleyball biography (5,000 transclusions)
 * Template:Infobox water polo biography

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 (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. —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? &mdash; Martin (MSGJ · talk) 13:41, 23 September 2020 (UTC)
 * Instead of the magic word, you could try this. Reh  man  15:24, 23 September 2020 (UTC)
 * Perfect, thank you &mdash; 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? &mdash; 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)
 * If you want to stick with WikidataIB, you can use the convert parameter (alias ) which pipes the output directly through Template:Cvt:
 * for ,
 * It's documented at Module:WikidataIB . 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. &mdash; Martin (MSGJ · talk) 17:50, 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. &mdash; Martin (MSGJ · talk) 17:50, 23 September 2020 (UTC)

Label truncated
gives

gives (now fixed, was just Mott)

For some reason the label is truncated, presumably because of the comma. How can I override this? &mdash; Martin (MSGJ · talk) 13:10, 23 September 2020 (UTC)
 * 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.  →   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)
 * In the sandbox, I've implemented a new parameter uselabel (alias, defaults to false) that forces the call to display the label instead of displaying the disambiguated sitelink:
 * → (now fixed, was just Mott)
 * 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. &mdash; Martin (MSGJ · talk) 17:47, 23 September 2020 (UTC)
 * 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)
 * → (now fixed, was just Mott)
 * Thanks, I have used it for that particular property to avoid the original problem. But unless I use 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. &mdash; Martin (MSGJ · talk) 19:52, 23 September 2020 (UTC)
 * 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)
 * Thanks, I have used it for that particular property to avoid the original problem. But unless I use 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. &mdash; Martin (MSGJ · talk) 19:52, 23 September 2020 (UTC)
 * 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)
 * 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? &mdash; Martin (MSGJ · talk) 09:39, 22 September 2020 (UTC)
 * 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:
 * If I experiment by forcing a narrow column, we get:
 * 6em gives:
 * 5em gives:
 * 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:
 * 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.
 * 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 &mdash; 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)
 * 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)
 * Thanks for the answer and confirming that you are seeing the same issue as I &mdash; 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)
 * 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. Reh man  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 &mdash; Martin (MSGJ · talk) 08:25, 23 September 2020 (UTC)
 * Using the unicode character for an "upper right pencil" gives: Jane Belson &#10000;
 * 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? &mdash; 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  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 &mdash; Martin (MSGJ · talk) 18:48, 24 September 2020 (UTC) Jane Belson &#10000;
 * I'm obviously not understanding how to use the CSS properly &mdash; 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  is displayed as office.com/. is displayed as https://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.  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? &mdash; Martin (MSGJ · talk) 08:18, 24 September 2020 (UTC)
 * I've fixed the code:
 * Let me know if you find any more problems. --RexxS (talk) 15:58, 24 September 2020 (UTC)
 * 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.
 * Your approach of “everything that contains a period is a domain name” is not 100% correct, see e.g.  → ; it actually fails for internationalized domain names like .рф as well (  → ), 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)
 * 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)
 * 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 ), although unfortunately I don’t remember which ones. In the   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)
 * 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, 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)
 * What do you mean by “normal webservers”? If an Apache server serving static HTML files from the  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)
 * 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)
 * 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)
 * 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)
 * 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 value, here you are: ’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)
 * 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)
 * 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)
 * I've had to fix some errors caused by trying to solve the 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)
 * 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)
 * 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)
 * I've had to fix some errors caused by trying to solve the 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 &mdash; Martin (MSGJ · talk) 14:16, 24 September 2020 (UTC)
 * That's odd. I gave a solution for that in response to Module talk:WikidataIB/Archive 7, 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:
 * in a 14em column gives:
 * 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? &mdash; 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:
 * where website is a local parameter that will override fetching from Wikidata. The template wdib is just a convenience wrapper for  --RexxS (talk) 17:39, 24 September 2020 (UTC)
 * Thanks - that's working well now &mdash; Martin (MSGJ · talk) 13:43, 25 September 2020 (UTC)
 * where website is a local parameter that will override fetching from Wikidata. The template wdib is just a convenience wrapper for  --RexxS (talk) 17:39, 24 September 2020 (UTC)
 * Thanks - that's working well now &mdash; Martin (MSGJ · talk) 13:43, 25 September 2020 (UTC)
 * Thanks - that's working well now &mdash; Martin (MSGJ · talk) 13:43, 25 September 2020 (UTC)

Caption
What is the easiest way to retrieve the (caption) of an image? This should be a qualifier of. Thanks &mdash; Martin (MSGJ · talk) 08:26, 30 September 2020 (UTC)
 * it's relatively straightforward to use getValue from WikidataIB to return just a qualifier:
 * For
 * The only complication is that the 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:
 * 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):
 * Obviously you use  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? &mdash; Martin (MSGJ · talk) 13:44, 30 September 2020 (UTC)
 * I think 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  which would only use a locally supplied caption with a locally supplied image.
 * There's a constraint on Wikidata that should have a single-value, but it does get ignored. You should always limit the number of images returned by setting 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)
 * I think 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  which would only use a locally supplied caption with a locally supplied image.
 * There's a constraint on Wikidata that should have a single-value, but it does get ignored. You should always limit the number of images returned by setting 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, or perhaps   or   or even. The trouble there is that doesn't seem to be much in the way of documentation.

The problems is of a (Philippine) place, say with property  with one or more instances of places as qualifier, for instance  which will each have a qualifier of. So how can I show direct elevation? → Cebu 1097 m

Not Samuel Pepys (talk) 14:16, 23 October 2020 (UTC)
 * For with property, you can find the value of the qualifier  like this:
 * If you just want the value of of the qualifier without the property value, then add the true parameter:
 * 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 by using getPropOfProp from  like this:
 * That works because is stored in Wikidata both as a qualifier in the  entry and as a property in the  entry.
 * Unit abbreviations and conversions already work for getPropOfProp:
 * Optionally, you can fetch the values of properties of by using getPropOfProp from  like this:
 * That works because is stored in Wikidata both as a qualifier in the  entry and as a property in the  entry.
 * Unit abbreviations and conversions already work for getPropOfProp:
 * Unit abbreviations and conversions already work for getPropOfProp:

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


 * A1


 * gives the right answer Af


 * except that I want it unlink ...


 * A2


 * 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 ₱


 * unscaled→ ₱171,234,667.17


 * B2 ₱


 * thousands→ ₱171,235 thousand


 * integer only


 * B3 ₱


 * millions→ ₱171.2 million


 * has one decimal, not integer


 * B4 ₱


 * billions→ ₱0.1712 billion


 * has four decimals, not integer


 * BY ₱


 * auto scaling→ ₱171,235 thousand


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


 * 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


 * 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
gives which is what I want. But giving full date (and / or |df=dmy) changes the date: Help! Not Samuel Pepys (talk) 17:27, 11 November 2020 (UTC)
 * WikidataIB uses the default sorting in Lua for property and qualifier values, so if you set 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, you can see what's happening. This is with y (because the default for qualifiers is year-only):
 * This is with dmy:
 * 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:
 * 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  – 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  (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)
 * This is with dmy:
 * 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:
 * 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  – 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  (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)
 * 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:
 * 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  – 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  (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)
 * 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  – 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  (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)
 * The module uses Module:Complex date to render dates in whatever language is required, and using  (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:. Kaldari (talk) 04:10, 8 December 2020 (UTC)
 * 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 . 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)
 * 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 . 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 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. &mdash; Martin (MSGJ · talk) 12:03, 15 December 2020 (UTC)
 * 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. &mdash; 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, is an for multiple journals. I would like to retrieve only the for the journal.

Would that be possible to implement? T.Shafee(Evo &#38; Evo)talk 07:24, 3 December 2020 (UTC)
 * 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)
 * Thank you so much in advance! Appreciated as always. T.Shafee(Evo &#38; Evo)talk 22:56, 8 December 2020 (UTC)
 * Thank you so much in advance! Appreciated as always. T.Shafee(Evo &#38; Evo)talk 22:56, 8 December 2020 (UTC)

I'm loathe to implement two more parameters, so I've implemented a filter parameter that looks like this:. 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 : property equal to  has multiple  qualifiers. A filter can pick one of them.

Examples 2 and 3 filter on: (2) , and (3)   , returning the  where the filter matches.

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):
 * 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:
 * Could be useful to have an antifilter implemented
 * However, already very useful for the sort of filtering I'm lookng to start with. T.Shafee(Evo &#38; Evo)talk 06:03, 16 December 2020 (UTC)
 * 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)
 * However, already very useful for the sort of filtering I'm lookng to start with. T.Shafee(Evo &#38; Evo)talk 06:03, 16 December 2020 (UTC)
 * 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)
 * 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:

Website www .grapette .com

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:

Website www .grapette .com

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. – Jonesey95 (talk) 13:27, 29 September 2020 (UTC)
 * Hi . Thanks for spotting that. It's caused by my attempts to resolve the 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 &mdash; Martin (MSGJ · talk) 15:16, 29 October 2020 (UTC)
 * Yes, one can see the issue with example 4 at Module:WikidataIB &mdash; Martin (MSGJ · talk) 15:16, 29 October 2020 (UTC)

do you know which edit caused this, and can it be reverted? &mdash; Martin (MSGJ · talk) 19:02, 31 October 2020 (UTC)
 * I think it was one of these five edits by . – 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 &mdash; 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 &mdash; Martin (MSGJ · talk) 10:41, 17 November 2020 (UTC)
 * I think the function now adds the extra tags, so the concerns in articles should be met. Can you confirm that, Martin?
 * Example 4 at Module:WikidataIB is a test of the case where an editor supplies  as the local parameter in an infobox, instead of  . 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


 * produces


 * 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? &mdash; Martin (MSGJ · talk) 21:05, 26 November 2020 (UTC)
 * 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.
 * The point is to use it when designing infoboxes, so in Template:Infobox bridge I would code the Website data like this:
 * To use the property from Wikidata, you could write:
 * or the equivalent short-form:
 * 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 &mdash; Martin (MSGJ · talk) 14:19, 9 December 2020 (UTC)
 * To use the property from Wikidata, you could write:
 * or the equivalent short-form:
 * 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 &mdash; Martin (MSGJ · talk) 14:19, 9 December 2020 (UTC)
 * 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 &mdash; Martin (MSGJ · talk) 14:19, 9 December 2020 (UTC)
 * Just to confirm that URL2 was deployed successfully and seems to be working correctly. Thanks for looking into this &mdash; Martin (MSGJ · talk) 14:19, 9 December 2020 (UTC)

Follow-up
I've come across a problem: The File:OOjs should not be there &mdash; Martin (MSGJ · talk) 20:29, 2 January 2021 (UTC)
 * But  →
 * But  →
 * I've removed URL2 from Template:Infobox bridge until this error is resolved &mdash; 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? &mdash; Martin (MSGJ · talk) 07:03, 3 January 2021 (UTC)
 * I've noticed that  seems to be doing the job correctly &mdash; Martin (MSGJ · talk) 07:12, 3 January 2021 (UTC)
 * 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}:
 * 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)
 * 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}:
 * 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)
 * 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)
 * 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 &mdash; 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 &mdash; Martin (MSGJ · talk) 08:13, 5 January 2021 (UTC)
 * . 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. &mdash; Martin (MSGJ · talk) 16:28, 8 January 2021 (UTC)
 * Okay. I was assuming that this module could call that module to do the bits it needs. &mdash; Martin (MSGJ · talk) 16:28, 8 January 2021 (UTC)