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)