Module talk:WikidataIB

Module:WikidataIB is permanently protected from editing as it is a heavily used or highly visible module. Substantial changes should first be proposed and discussed here on this page. If the proposal is uncontroversial or has been discussed and is supported by consensus, editors may use {{edit template-protected}} to notify an administrator or template editor to make the requested edit.

Archives

This page has archives. Sections older than 60 days may be auto-archived by if there are more than 3.

open and close quotation mark

Many of Quotation marks have opening and closing, so both open and close quotation mark should be able to specified in /titleformats. FlatLanguage (talk) 18:54, 26 March 2025 (UTC)[reply]

Please see MOS:CURLY. – Jonesey95 (talk) 01:57, 27 March 2025 (UTC)[reply]

/titleformats is for i18n, so projects other than enwiki should be considered. --FlatLanguage (talk) 01:59, 27 March 2025 (UTC)[reply]

getValueByRefSource

There are no examples for getValueByRefSource... What I'm after is the population (P1082) of Toronto (Q172), as given by the 2021 Canadian Census (Q42317745). The data is there, and I'm trying to access it with the following:

{{#invoke:WikidataIB |getValueByRefSource |qid=Q172 | P1082 |match=Q42317745 |fwd=ALL}}

... which doesn't return anything, not even an error message. What am I missing here? Tompw (talk) 19:14, 11 November 2025 (UTC)[reply]

Edit request 14 November 2025

This edit request has been answered. Set the |answered= parameter to no to reactivate your request.

Description of suggested change: Please apply c:Special:Diff/1115600336 to fix the order of "mul" in the language fallback sequence for labels (should be after all explicit fallbacks, but just before the implicit fallback to "en").

Diff:

Lucas Werkmeister (talk) 19:59, 14 November 2025 (UTC)[reply]

Lucas Werkmeister, this change is now in the sandbox: Special:Diff/1317055591/1325225748. I'm not familiar with this module. Which templates use it? Is there a good way to test it? What problem visible in usages of this module does it solve? —⁠andrybak (talk) 22:06, 1 December 2025 (UTC)[reply]

@Andrybak: It took a while to put together a working demo (because only such a small part of the module actually uses mul labels at the moment – it should probably be used in more places, using the correct version of the fallback code), but here’s one: User:Lucas Werkmeister/sandbox (Special:Permalink/1325240674). The statement shown is Prime Minister of Afghanistan (Q532240) | base salary (P3618), which is a quantity with the unit afghani (Q199471), and that unit has two unit symbols: Afs in English and ؋ in mul (the Pashto sign). The old code is incorrectly displaying the mul symbol rather than the English symbol. Lucas Werkmeister (talk) 23:45, 1 December 2025 (UTC)[reply]

Done—Please report any issues. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:19, 8 December 2025 (UTC)[reply]

@Pigsonthewing and Lucas Werkmeister: I might have found a bug in this recent change. Two lighthouse pages had units of type M showing up. See these permalinks:

And look specifically at the Range values in the infobox. I went down the rabbit hole for both pages (which showed up in Category:Convert errors) and the ONLY relevant change I could find was to this module (no updates to wikidata, the articles themselves, {{Infobox lighthouse}}, etc.)

Now the temporary fix was to manually use {{convert}} on those pages... But that removes the call to wikidata and seems to be indicative of a larger problem. I would encourage a revert of the recent change that was made. Zackmann (^{Talk to me}/_{What I been doing}) 17:34, 8 December 2025 (UTC)[reply]

Thank you. Reverted. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:36, 8 December 2025 (UTC)[reply]

Well that was insanely quick... Thanks Andy! Zackmann (^{Talk to me}/_{What I been doing}) 17:37, 8 December 2025 (UTC)[reply]

@Zackmann08, @Pigsonthewing: I don’t think that was a bug? nautical mile (Q93318) has three English “unit symbol” statements and they all have the same rank. Lucas Werkmeister (talk) 19:32, 8 December 2025 (UTC)[reply]

@Lucas Werkmeister: I'm not very good with Wikidata... All I know is that the 2 pages I linked to above were displaying an error because {{convert}} was trying to convert with unit type M as shown here:

4 M^{[convert: unknown unit]}

Exactly why this is happening, I'm not sure... But it was pretty clearly directly related to the change that was implemented. Zackmann (^{Talk to me}/_{What I been doing}) 19:42, 8 December 2025 (UTC)[reply]

I see, that sounds like a more serious error than what I expected, at least (I thought it just displayed the symbol as M instead). Plugging a Wikidata unit symbol into {{convert}} doesn’t sound like the greatest idea to me (the item ID of the unit would be a much more stable identifier), but that would be a larger change.

Looking at the code more closely… I think it’s badly broken anyway? I assume the intention is to follow the language fallback chain and find the first unit symbol statement with a language code matching the target language, or the target language’s first fallback, or its second fallback, and so on. But in fact, the structure of the loops means that, for the most part, it’ll find the first unit symbol statement whose language code appears anywhere in the language fallback chain? Except that there’s also another bug where the if found then break end is, if I’m not mistaken, placed one line above where it should be, with the result that it never breaks out of the outer loop, and therefore it actually returns the last statement where the language code appears anywhere in the fallback chain?

I still haven’t worked out why the requested edit made a difference, though. I think it would’ve changed the fbtbl from {"mul", "en", "en"} to {"en", "mul", "en"} (assuming that, in the context of those pages, args.lang is "en"), but why did that change the result… Lucas Werkmeister (talk) 20:15, 8 December 2025 (UTC)[reply]

Oh, apparently the old code resulted in {"mul", "en"} instead (no second "en" as I expected). Lucas Werkmeister (talk) 20:21, 8 December 2025 (UTC)[reply]

@Pigsonthewing: Please consider retrying the edit request with Special:Diff/1326419389 applied on top; as far as I can tell from trying out the Lua snippets at Special:Permalink/1326419901 in the debug console, that should work better. (But you, unlike me, should be able to try it out using the “preview page with this template” feature, to make sure that Abu Musa and Lindisfarne don’t regress again.) --Lucas Werkmeister (talk) 22:08, 8 December 2025 (UTC)[reply]

I suggest sandboxing your code and use some test cases to verify it works — Martin (MSGJ · talk) 15:10, 9 December 2025 (UTC)[reply]

Agree. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:36, 9 December 2025 (UTC)[reply]

What do you mean, “my code”? This isn’t my module. And I did extract the code as far as possible and tested it, that’s what you’re seeing on Special:Permalink/1326419901. Lucas Werkmeister (talk) 17:44, 9 December 2025 (UTC)[reply]

Sorry, I think I misunderstood what you meant and overreacted… I thought “sandboxing” meant you were expecting me to refactor the whole module (some 3500 lines long) to make it more testable in isolation. I’m now guessing you meant putting the code into the /sandbox subpage (I wasn’t aware of such a meaning of “sandbox” as a verb before, but then I don’t move around much in the technical namespaces of enwiki).

But I’ve done that, haven’t I? I’ve updated the /sandbox page again, and my previous test case at Special:Permalink/1325240674 still behaves correctly with the improved sandbox code; it’s unclear to me how I’m supposed to test the error reported at Abu Mus and Lindisfarne (how do you “thread” the /sandbox usage through X layers of intermediate templates?), but I tested that situation in isolation at Special:Permalink/1326419901 and as far as I can tell the new version ought to behave correctly there. I don’t know what else I’m supposed to test without having access to the “preview page with this template” feature, which ought to make it trivial for the person fulfilling the edit request to check how Abu Mus and Lindisfarne behave with the new version. Lucas Werkmeister (talk) 18:10, 9 December 2025 (UTC)[reply]

I assume Martin was referring to your comment: "But you, unlike me, should be able to try it out using the “preview page with this template” feature, to make sure that Abu Musa and Lindisfarne don’t regress again."

It's normal that the person requesting the change tests it before-hand. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:16, 9 December 2025 (UTC)[reply]

I understand that, but what I keep trying to say is that I believe I’ve tested the change as much as I reasonably can, and you ought to be able to further test it in a way that I’m simply unable to. Lucas Werkmeister (talk) 20:59, 9 December 2025 (UTC)[reply]