Module talk:Wd/Archive 1

Archive 1

Bug

I tried to use the template on the Sandbox, and it had a bug. It said Code Error. The command "command1" does not work David Dylan (talk) 23:04, 22 January 2017 (UTC)

The problem appears to be that previewing {{#invoke:wd|label}} gives error "The time allocated for running scripts has expired." The documentation at {{wikidata}} says that {{wikidata|label}} should work, but it gives the same error. If you see some other error, please post the wikitext that was used and a copy of the resulting message. Johnuniq (talk) 00:23, 23 January 2017 (UTC)

The problem is the following code:

function p._label(args, _)
    -- ...
    while _:processFlag(nextArg) do
        nextArg = mw.text.trim(args[nextIndex] or "")
        nextIndex = nextIndex + 1
    end
    -- ...
end

The processFlag function returns true if nextArg is an empty string, and that gives an infinite loop. A cleaner way of processing the arguments is needed.

While finding this, I noticed

frame = frame:getParent() or frame

in p.main(frame). Possibly the intention is that a module could call main and pass a table of arguments, but if that occurred, the above would give a run time error because getParent would very likely be nil, so calling it would fail. Using Module:Arguments might be easiest, although I find it confusing—see Module talk:Arguments#Using ipairs. Johnuniq (talk) 01:26, 23 January 2017 (UTC)

Thank you for reporting this bug. I've created a fix for it. The problem was introduced when I started allowing empty flags, without thinking about what this would do with the call to processFlag. Needless to say, it was not thoroughly tested.

Regarding frame = frame:getParent() or frame: if frame:getParent() returns nil, then the or will assign the current frame instead, so I don't think this is an issue. I've copied this piece from another module. Nevertheless, I will have a look at Module:Arguments as you suggested. Thank you. Thayts ••• 21:15, 2 February 2017 (UTC)

The point is that another module might call main(args) in this module, and the other module would pass args which is a table of arguments to specify what is wanted. Because it is just a standard table, it will have no getParent member so when this module tries to execute getParent() it will be trying to call a nil value, and that will result in a crash. Module:Arguments does a bunch of tricky stuff so it works with a frame or a table. Unfortunately it requires rather unappealing procedures. Johnuniq (talk) 05:00, 3 February 2017 (UTC)

I see. The main function is not meant to be called by other modules, however, but by templates. Modules should call the functions beginning with underscores _ directly. Thayts ••• 05:59, 3 February 2017 (UTC)

OK, I was just guessing about the intention of using frame:getParent() or frame. If it is assumed main(frame) is called as the result of using {{#invoke:...}} (either directly or via a template), there is no way frame:getParent() can be nil. The nil result only occurs if a module calls getParent twice (that is, if a module attempts to get the parent of the parent). I would have to set up a sandbox with a test to prove that but I believe I convinced myself that is how it works when starting on Lua. Johnuniq (talk) 07:01, 3 February 2017 (UTC)

Without the getParent I have had situations where it didn't work. But the module has changed a lot since then so I'm not sure if it is really necessary. I think I will test a bit again without it.

By the way, even if the parent of the parent is nil, then the or frame will always assure that that nil value is never assigned. Thayts ••• 16:04, 3 February 2017 (UTC)

I haven't looked at frame/parent stuff for a while so I made some tests. See User talk:Johnuniq/temp which displays the results of calling a template which invokes a module, and directly invoking the module. frame:getParent() is only nil when trying to get the parent of the parent. Johnuniq (talk) 05:54, 4 February 2017 (UTC)

Your example helped me understand how it works. So yeah, I definitely need the getParent. The main function is just nothing more than a necessary evil, so that things like templates can actually call the other functions. If you are able to call one of the other functions directly, then you should. Only use main if you have to. The only use case I currently see is the {{wikidata}} template, for which one would expect that arguments passed to that template are the actual arguments that will be used. Since a regular template does not take any arguments from any parents either, I'd like to keep it simple and mimic that behaviour, not worrying about arguments passed by other parents. Thayts ••• 15:58, 5 February 2017 (UTC)

Reference names

Hi there. Is there a way to define the names (as in <ref name="blah" />) for the references imported from Wikidata, so that we can avoid having duplicate refs in articles where they have been locally defined and defined on Wikidata? Thanks. Mike Peel (talk) 15:08, 29 January 2017 (UTC)

Hi Mike Peel. No, not at the moment. However, references that have been imported from Wikidata using this module more than once on the same page do have a common name and will not be duplicated. Thayts ••• 21:23, 2 February 2017 (UTC)

Hi @Thayts: I've been testing this at Juana Rosa Aguirre, and it seems to be working nicely. However, in most cases the reference will already exist in the article, and it's not good to have duplicate refs. I don't suppose something like short name (P1813) could be used to define the names of the refs so that we can avoid those duplications? Thanks. Mike Peel (talk) 21:40, 3 February 2017 (UTC)

The problem with that is that there is no reliable way to say which reference imported from Wikidata should get that name. A claim in Wikidata can have more than one reference, even stored in arbitrary order, namely. The names this module is currently assigning to references are hash values that are (or are supposed to be) unique per set of properties that make up one reference. You could perhaps propose to make it possible to replace a particular hash value by a custom value in this module's output. You could also do it the other way around: hovering over the footnote number of a reference returned by this module to see its name (in this module's case it starts with "wikidata" followed by a hash value) and then assigning that name to the already existing reference. Yet this still isn't reliable, since details of references on Wikidata are subject to change and will cause the hash value to change too as a result. What is reliable is to replace the already existing references with the ones imported from Wikidata using {{wikidata|references|Pxxx}}. Would that work for you? Thayts ••• 16:54, 5 February 2017 (UTC)

Substing {{Wikidata}}

How would one go about using subst: functionality with {{Wikidata}}?--Pharos (talk) 04:44, 10 April 2017 (UTC)

See Template:Convert for what is needed in the template. Johnuniq (talk) 05:52, 10 April 2017 (UTC)

{{Convert}} uses subst technically, yes, but what I want to do is actually substitute the output in plain wikitext, like have "Douglas Adams" be viewable under 'edit source' on User:Pharos/sandbox.--Pharos (talk) 15:13, 10 April 2017 (UTC)

user:Pharos, that's what he meant too... diff. --Jeremyb (talk) 18:06, 10 April 2017 (UTC)

Oh, thanks for that diff which shows that {{subst:wikidata|property|Q55|P1549}} → Dutch (and two other examples). It seems it is possible to subst {{wikidata}} but I assumed from the OP that something bad happened if you tried. Convert used to be broken when substituted before the magic {{{♥|safesubst:}}} was inserted into the template. Historians can see the addition in the history of {{Convert/sandboxlua}} which followed this VPT request. Johnuniq (talk) 01:45, 11 April 2017 (UTC)

Merge duplicate refs?

E.g. at Liverpool Maritime Mercantile City, the references for the criteria in the infobox are duplicated three times, since there are three entries for the property on Wikidata each with the same reference. Can the three be merged together rather than appearing separately, please? Thanks. Mike Peel (talk) 00:18, 1 May 2017 (UTC)

@Mike Peel: Nice catch! I've created a fix for it. Thanks, Thayts ••• 12:55, 1 May 2017 (UTC)

That's perfect, thanks! Mike Peel (talk) 19:19, 1 May 2017 (UTC)

Returning just the unit of measurement?

@Thayts: Using the example provided in the documentation, is it possible to return just volt instead of 230 volt or 230 volt? This would be helpful for the template Wikidata revenue I'm working on. Thanks, --eh bien mon prince (talk) 02:11, 27 August 2017 (UTC)

@Underlying lk: I've added the unit flag which gives you exactly what you need. :) Thayts ••• 13:23, 28 August 2017 (UTC)

@Thayts: That's great, thanks. Now I'm trying to get the output to go from United States dollar 1.5 billion to $ 1.5 billion. The easiest way is probably to reach United States dollar (Q4917) and fetch currency symbol description (P489) - would it be possible to return the Q-identifier of the unit?--eh bien mon prince (talk) 13:50, 28 August 2017 (UTC)

@Underlying lk: The raw flag now also works in combination with the unit flag:

{{wd|property| {{wd|property|unit|raw|Q312|P2139}} |P489}} → dollar sign

Thayts ••• 14:31, 28 August 2017 (UTC)

Awesome, thanks again.--eh bien mon prince (talk) 14:43, 28 August 2017 (UTC)

Is it possible to include vertical bar in format text?

I'm now trying to shorten the very lengthy template Module:Infobox gene by using this Wd template, at my personal space. This is very useful. Thank for your great code! My question is as follows. When I try to include vertical bar "|" in format-defining text, it doesn't work well. Even when I add escape "\", it is simply recognized as a separator (sample diff). If it worked well in that diff, I could get three "RNA expression pattern" graph images just like that in the infobox at the right, but it didn't work. Is there any special way to include vertical bar? --Was a bee (talk) 03:03, 3 September 2017 (UTC)

@Was a bee: Try using {{!}}. Thanks. Mike Peel (talk) 10:56, 3 September 2017 (UTC)

@Mike Peel: Oh, That works! Thank you very much! --Was a bee (talk) 14:43, 3 September 2017 (UTC)

@Was a bee: Thanks for the compliment! Thayts ••• 15:30, 3 September 2017 (UTC)

Using {{Cite Q}}?

@Thayts: In cases where the reference is stated in (P248) pointing to a separate Wikidata entry with bibliographic information, would it be possible to fetch the reference info from that separate Q-number? Something like {{Cite Q}} does, e.g., Keith Christiansen; Elizabeth Cropper; Alessandro Zuccari; et al. (2001). "Orazio and Artemisia Gentileschi". New York City. Metropolitan Museum of Art. JSTOR 1358795. Wikidata Q29017598.. Is it possible to detect when only a Q-number is returned, and auto-call Cite Q in those cases? Thanks. Mike Peel (talk) 23:12, 7 July 2017 (UTC)

@Mike Peel: I've implemented a call to {{Cite Q}}. It is only used if stated in (P248) is the only bit of information in the reference statement. {{Cite Q}} seems to be in beta itself and I think in the future both calls to {{Cite Q}} and {{Cite web}} should be replaced by a call to {{Citation}}. Thayts ••• 20:11, 8 July 2017 (UTC)

@Thayts: That's fantastic, thanks! There are some errors coming up, but I think those are issues with the cite Q template so I'll report them on that talk page. I'm not fussed about the citation style so much as getting the data shown, but I'm sure other editors will start discussions on those at some point in the future. ;-) Thanks. Mike Peel (talk) 20:58, 8 July 2017 (UTC)

@Mike Peel: I've made some improvements. Next to stated in (P248), properties like page(s) (P304) and chapter (P792) may now also be present and will be taken along in the call to {{Cite Q}}. Thayts ••• 21:39, 12 July 2017 (UTC)

@Mike Peel and Thayts: Instead of hard-coding the template names for {{Cite web}} and {{Cite Q}} into Module:Wd/i18n, would it not be better to just use Wikidata for this? For example using mw.wikibase.sitelink() on Template:Cite web (Q5637226) and Template:Cite Q (Q22321052). Then there is less to localize. 50.53.1.33 (talk) 17:16, 5 September 2017 (UTC)

That's a nice suggestion. However, the parameters may be called differently on other wiki's as well and would still need to be localized. Thayts ••• 19:07, 5 September 2017 (UTC)

I was not suggesting there would be nothing to localize—just less. I do not like maintaining multiple sets of the same data. When possible, I find it better if there is one origin for data and everything uses that. 50.53.1.33 (talk) 21:36, 5 September 2017 (UTC)

Yes I agree. Therefore, I've implemented it as you suggested. Thayts ••• 15:00, 9 September 2017 (UTC)

Aliases and format

Hello again! I’m sorry to bother you, but I would be grateful if you could think about these 2 things.

1. Alias fetch command (d:Help:Aliases). For example, {{wikidata|alias}} and {{wikidata|aliases}} like "property" and "properties" commands.

2. Processing the output from "format" as wikitext. If evaluating "format" text as wikitext just after the replace of %p by value, I suppose it would make possible to use template, magicword or #if-text in "format" text.

I don't even know whether these things are possible or not, whether Lua thing or Mediawiki thing. If I am pointless, please forget about this! Thanks! --Was a bee (talk) 10:35, 17 September 2017 (UTC)

I think my explanation about second part was not enough. So I put example. Although this is just an example, if getting data from d:Q21117967#P680 by the following code, it works very well.

{{wikidata|properties|Q21117967|P680|format=• %p|sep =<br/>}}

• misfolded protein binding
• protein binding
• Hsp70 protein binding
• chaperone binding

But if editor wants to modify the retrieved each values with template (for example {{Fixcaps}}), result is correct, but sad.

{{wikidata|properties|Q21117967|P680|format=• \{\{Fixcaps{{!}}%p\}\}|sep =<br/>}}

• {{Fixcaps|misfolded protein binding}}
• {{Fixcaps|protein binding}}
• {{Fixcaps|Hsp70 protein binding}}
• {{Fixcaps|chaperone binding}}

--Was a bee (talk) 10:50, 17 September 2017 (UTC)

Hi Was a bee! Not a problem at all, I'm glad to help out wherever I can. :)

About your request number 1: I have added the alias/aliases command now. That was a nice suggestion.

Request number 2 is a nice suggestion as well. It is possible, but I'm still figuring out what the best way to do this is. Expect another update soon!

Thayts ••• 19:52, 20 September 2017 (UTC)

@Thayts: I tested your new aliase command and that works nicely! It helps a lot. Thank you so much! On part '2, although I personally can't even imagine what kind of technology makes it possible, but I wait your coding! --Was a bee (talk) 02:45, 23 September 2017 (UTC)

@Was a bee: Request number 2 has also been fulfilled now. You can see your example now works as expected. :) Thayts ••• 16:09, 29 September 2017 (UTC)

@Thayts: Sorry to intrude, but since this last edit was implemented I'm unable to use wikidata quantities in parser functions; for an example, try pasting {{#ifexpr: {{Wikidata|property|raw|P3362}} < 0 | yes | no}} in the ZiL article.--eh bien mon prince (talk) 16:58, 29 September 2017 (UTC)

@Underlying lk: Yes, unfortunately it is a breaking change for some use cases. But I believe encoding the output by default is something I should have done from the start. In cases where this is undesired, you can actually prevent it by using the new plain flag: {{#ifexpr: {{Wikidata|property|raw|plain|P3362}} < 0 | yes | no}}. Does that help? Thayts ••• 17:03, 29 September 2017 (UTC)

It does, thank you!--eh bien mon prince (talk) 17:11, 29 September 2017 (UTC)

@Underlying lk: You did give me something to improve. If there is a single dash as with negative numbers, then this will normally have no effect. Only if there are four dashes at the start of a line ----, a horizontal rule will be placed. I have edited the module again so that it matches those four dashes exactly. In case of your template, you could now remove the plain flags again, or you could just leave them in there to be safe. Thayts ••• 17:40, 29 September 2017 (UTC)

@Was a bee & @Underlying lk: I have reverted the change for request number 2 since there were more problems than I anticipated (e.g. raw value comparison stopped working). I will have to think this over more thoroughly... Thayts ••• 19:27, 29 September 2017 (UTC)

Edit links on references

@Thayts: This change seems to cause some issues whenever the same reference is invoked more than once, as in the Transneft#References article.--eh bien mon prince (talk) 21:56, 8 October 2017 (UTC)

I see. Thanks for intervening, I'll see what I can do! Thayts ••• 16:16, 9 October 2017 (UTC)

Pages in references

@Thayts: Any chance of showing page numbers (P304) in references, please? Thanks. Mike Peel (talk) 21:30, 29 September 2017 (UTC)

@Mike Peel: They should be shown already. Do you have an example where that's not the case? Thayts ••• 21:35, 29 September 2017 (UTC)

@Thayts: Try {{wikidata|property|references|normal+|Q82941|P1174}} which should also return a page number in the reference. Thanks. Mike Peel (talk) 21:40, 29 September 2017 (UTC)

@Mike Peel: Initially, I was following the page at https://www.wikidata.org/wiki/Help:Sources to determine valid parameters for a web reference. However, I have simply added "pages" so it should work now.

(The "pages" parameter no longer works in {{Cite Q}}, though?) Thayts ••• 09:58, 30 September 2017 (UTC)

Thanks, that's working nicely now. :-) With Cite Q, does this edit fix it? Thanks. Mike Peel (talk) 14:47, 30 September 2017 (UTC)

I think so, yes. Thank you. Thayts ••• 16:28, 9 October 2017 (UTC)

Recent edits

@Pppery: A lot of edits to Module:Wd are occurring. I see some also in Module:Wd/sandbox. Shouldn't pretty well all the edits be in the sandbox? The script errors tracking category (articles) is showing hundreds of pages, and I think that is from the recent edit which Thayts fixed (I'm currently purging the category so genuine errors can be found). At any rate, the module has 5811 transclusions so tweaks definitely should happen in the sandbox to avoid unnecessary overhead regardless of whether another glitch might occur. If wanted, I would be happy to remove the many global variables which are currently in the module. Johnuniq (talk) 04:41, 12 October 2017 (UTC)

P of Q

Not really sure whether this is the right place to ask, but here goes: I'd like a (simple) template that returns Wikidata claims given a Q number and a P number. For instance, the publisher of A Haunted House and Other Short Stories (A Haunted House and Other Short Stories (Q4004168)) is Hogarth Press. The property number of "publisher" is P123. For the sake of this example, let's call the proposed template {{Wikidata/P of Q}} (other names are possible), then:

• {{Wikidata/P of Q|P123|Q4004168}}

or

• {{Wikidata/P of Q|publisher|Q4004168}}

would return:

• Hogarth Press

Then, additionally, if no Q number is given, the template takes the Q number of the page on which it is, thus if the {{Wikidata/P of Q}} template is placed on the A Haunted House and Other Short Stories page, with only the first parameter (the P parameter) added, thus:

• {{Wikidata/P of Q|P123}}

or

• {{Wikidata/P of Q|publisher}}

it gives the same return as mentioned above.

I suppose this could be done with the current {{Wikidata}} template, with the correct parameters — maybe such simplified template already exists, and I just didn't find it. Could someone help out here? Tx. --Francis Schonken (talk) 09:06, 5 November 2017 (UTC)

Oops, just looked above #Substing_.7B.7BWikidata.7D.7D, seems like I can find at least part of the answer there. --Francis Schonken (talk) 09:16, 5 November 2017 (UTC)

Propose to continue talk about this at Template talk:Wikidata/P of Q. --Francis Schonken (talk) 09:26, 5 November 2017 (UTC)

@Francis Schonken: This is exactly what can be achieved with the {{Wikidata}} template as follows:

• {{Wikidata|property|Q4004168|P123}}

returns:

• Hogarth Press

or have it linked:

• {{Wikidata|property|linked|Q4004168|P123}}

returns:

• Hogarth Press

Included on the page you can simply do:

• {{Wikidata|property|P123}}

or:

• {{Wikidata|property|linked|P123}}

Thayts ••• 13:26, 5 November 2017 (UTC)

Thanks! --Francis Schonken (talk) 13:34, 5 November 2017 (UTC)

References for 11×58mmR bullet diameter {{wd|property|raw|P2386|P518=Q174583}}?

Hi! Can you help slovenian wikipedians with template usage?

We have just copied your Template:Wikidata (into sl:Predloga:Wd) and sl:Modul:Wikidata. With just a few small changes, it works great. But ... there is always but ;) .. How can I get reference from Wikidata item 11×58mmR (11x58mmR (Q17560835)) -> diameter (P2386): bullet diameter or neck diameter or shoulder diameter? --Pinky sl (talk) 12:59, 5 November 2017 (UTC)

@Pinky sl: I suppose you mean sl:Modul:Wd. Please refer to the documentation. For example, to get the shoulder (Q29841352) diameter, use:

• {{Wd|property|Q17560835|P2386|P518=Q29841352}}

output:

• 13.61 millimetre

Thayts ••• 13:40, 5 November 2017 (UTC)

The problem is not to extract quantity 13.61 millimetre for shoulder diameter (with or without unit). The problem is to get its reference (title - Cartridges of the World; creator - Frank Barnes; date of publication - 1972; ... -Pinky sl (talk) 15:18, 5 November 2017 (UTC)

@Pinky sl: This module/template determines if a reference is valid based on the Wikidata guideline on sources and only includes it when that's the case. A reference on Wikidata is valid if it contains at least the property stated in (P248) or reference URL (P854). In this case, you can replace the whole reference with one that has a single stated in (P248) equal to Cartridges of the World (Q5047440). I've done this with the shoulder diameter as an example:

• {{Wd|property|references|Q17560835|P2386|P518=Q29841352}}

output:

• 13.61 millimetre

Thayts ••• 15:30, 5 November 2017 (UTC)

Thank you ... it works now. Is it possible:

• to get reference for raw value (without unit) - my solution is like this {{Wd|property|raw|Q17560835|P2386|P518=Q29841352}}{{Wd|references|Q17560835|P2386|P518=Q29841352}} 13.61
• to get label Cartridges of the World in other language not just the current wiki's language? -Pinky sl (talk) 15:56, 5 November 2017 (UTC)

@Pinky sl:

• Yes: {{Wd|property|raw|references|Q17560835|P2386|P518=Q29841352}} → 13.61
• No, that is currently not possible.

(I'm sorry about my first reply, I didn't see the section title entirely.) Thayts ••• 16:09, 5 November 2017 (UTC)

Thank you for your help. Now I have to figure it out how to get the same output, because our reference looks something like this: "Cartridges of the World; stran: 178", without author and OCLC. --Pinky sl (talk) 17:21, 5 November 2017 (UTC)

This module/template uses {{Cite Q}} to retrieve that information. If that template is not available on your wiki, then it will only show what is in the reference indeed. You could add author etc. manually to the references on Wikidata, which should work in that case (although you will be duplicating information in Wikidata then). Thayts ••• 18:13, 5 November 2017 (UTC)

I thought that was the case. I will create {{Cite Q}}, I do not like to duplicate data. So thank you again. --Pinky sl (talk) 19:06, 5 November 2017 (UTC)

Unit symbols

@Thayts: I'm thinking about using unit symbols instead of unit labels (singular form of the label not appropriate for direct use + too long for infoboxes). Could you take a look: [1]? (It could be made optional and further optimized by saving wikidata calls via local array with the most common units.) --Nk (talk) 11:46, 12 January 2018 (UTC)

@Nk: Yeah, I've been thinking about it as well. But the problem I saw was that you cannot know from the unit's Wikidata item if the symbol should normally be added in front of the value or behind it, and if there should be a space between it or not. And that might also differ per language. So I'm not confident enough yet that this can be done the right way in all cases. Thayts ••• 20:23, 12 January 2018 (UTC)

Badges

How can we pipe in badges from wikidata. Capankajsmilyo (talk) 07:57, 13 March 2018 (UTC)

@Capankajsmilyo: Voilà: Template:Wikidata#General class. Thayts ••• 10:26, 18 March 2018 (UTC)

@Thayts: Thanks, but it only gives text name of badge, can we have star instead of featured and plus instead of Good? Capankajsmilyo (talk) 11:28, 18 March 2018 (UTC)

Not sure if I should put that in the module, also because the logic is internationalized for use on different Wikipedia's. However, you could create a template that selects the right icon based on the returned value. Thayts ••• 12:47, 18 March 2018 (UTC)

raw date format?

This returns a date in a format that does not accord with MOS:DATE:

{{wikidata|property|raw|Q19858624|P577}} → 2015-04-29 (P577 is publication date for: A higher level classification of all living organisms (Q19858624))

Is there a reason that month and day values in raw returns are rendered as single digit when less than 10? Technically this occurs because parseDate() returns numbers, not strings for year, month, day so leading zeros in the source from the wikidata raw time data are lost. If leading zeros are not omitted for a specific reason, one might rewrite line 1035:

value = value .. "-" .. (((m<10) and '0') or '') .. m

and line 1038:

value = value .. "-" .. (((d<10) and '0') or '') .. d

—Trappist the monk (talk) 19:06, 23 March 2018 (UTC)

@Trappist the monk: I wasn't aware of MOS:DATE or that the current format would cause any problems. I think your solution is simplest to implement, but maybe we need to do the same for the year (although the MOS says yyyy-mm-dd should only be used with Gregorian dates; not sure what to do with Julian dates). Also, if the precision is for example "month" then in this case "2015-04" would be returned (if the leading zero is added). Is that sufficient, or should the digits for the day also be filled like "2015-04-00" in your opinion? (This is also how Wikidata returns it in string format, but I'm not sure if this is considered a valid date.) Thayts ••• 22:07, 23 March 2018 (UTC)

Perhaps I should do it like decades, centuries and millenniums, and return "2015-04-01" in that case. Thayts ••• 22:32, 23 March 2018 (UTC)

I'm presently wondering about a request to migrate the cs1|2 module suite and {{cite Q}} to Wikidata which rewrites dates according to the user's interface language setting before they are passed to the template and module. Changing the interface away from English causes the date validation code to emit errors. For example, 29 April 2015 becomes 29 abr 2015 when the interface is changed to Spanish (made stranger by abbreviating the month name; why?) Example at d:Wikidata:Sandbox.

I'm not really sure what the answer is. MOS doesn't like YYYY-MM dates because they can be too easily confused with YYYY–YY. There was a time when cs1|2 considered adopting parts of EDTF to handle machine generated dates (citoid was the machine we were thinking about). ISO BIS 8601:2016 part 2 (still underdevelopment) suggests a method for handling uncertain or unspecified date parts (2014-04-XX is one way it might be done). At cs1|2 we did an experiment with a similar form that would correctly render incomplete dates. Something similar could be done here. Alternately, I suppose that the date precision from the raw wikidata timestamp could be applied so: 2015-04-29/11, 2015-04/10, and 2015/9. Yet another alternately, the function could return precision as a second value:

value, precision = value .. calendar, precision

where value for month precision dates would be YYYY-MM-00 (just like wikidata) or maybe, for compatibility with existing use (if there is any), return YYYY-MM. Users can choose to ignore the second return.

—Trappist the monk (talk) 00:55, 24 March 2018 (UTC)

If it is relevant for the citation module at all, then it should accept some format for dates of lesser precision than days. Currently it doesn't accept "2014-04-XX", nor "2014-04-00", nor "2014-04". However, from "2014-04" it can be deduced that only the month of the year is known (provided that such a date format returned by this module will always mean YYYY-MM). Returning multiple values, either concatenated or separately, would be another possibility indeed, but that requires to do some deducing too. Returning them separately is certainly not compatible with templates that can only receive one value. I could of course work around that if necessary, returning single, concatenated values when called by a template and multiple otherwise, but that would require an overhaul of the current module. This is something we can discuss about, but for now I have made a change so that day-precision dates are always returned as YYYY-MM-DD as you suggested. Thayts ••• 12:37, 24 March 2018 (UTC)

Point. I was thinking 'module' so didn't think 'template' when I suggested multiple return values (and I was pressed for time).

Yeah, cs1|2 does not accept incomplete ymd dates any longer. That experiment did not gain sufficient traction (the form was YYYY-MM-uu from the edtf preliminary standard). cs1|2 could probably support YYyy-MM dates where the values in yy and MM are, in combination, clearly unambiguous. But, since MOS prohibits the YYYY-MM date form, it is easier to simply reject that date style.

I have implemented a stopgap 'fix' to the wikidata version of d:Template:cite Q that uses code suggested to me at d:Help_talk:Dates#How to get raw date/time value. I had been hoping for a more generic solution; something that would be usable regardless of where the template existed; perhaps something like {{#raw_property:R...|from=...}}. That functionality, I would think, should be available. Apparently not.

—Trappist the monk (talk) 13:27, 24 March 2018 (UTC)

Code for i18n

@Thayts: On 9 May 2017 local arg = ... was introduced. Do you have a reason to use that off-wiki? I believe it would never do anything useful in a Scribunto module (arg would always be nil). Is the code used anywhere? That is, does Module:Wd ever get "included by other module" which passes the title in arg?

The background to my question is that a discussion at VPT is questioning the use of red-linked /i18n pages. I haven't looked at whether this module is part of that but it is the earliest form of the code that I have seen, and its procedure was copied to Module:Wikidata in October 2017. In this October 2017 comment I mentioned "two really puzzling aspects of the code"—that is, two things which I believe would never work.

It is irritating to edit an article at enwiki and see a red-linked /i18n page. I was hoping to investigate whether there was some workaround that might disable that for enwiki while leaving it available for other projects. I'll look at that later but first I would like to understand the above. Johnuniq (talk) 03:36, 28 June 2018 (UTC)

@Johnuniq: First of all, the split between the module's logic and the i18n submodule was made to make it easy to copy over the logic to other wikis and to keep it updated without the need to tweak it for locality all the time. Since the module on other wikis might have a different title, especially in the namespace part 'Module:' (which is written differently in different languages), I was looking for a way to determine the local title (so that this doesn't need to be hardcoded and tweaked either). This is needed to actually locate the i18n submodule (the title "/i18n" is indeed a hardcoded convention).

For template inclusions this is easy, since you can get it from the frame. The problem is indeed when the module is included by another module, which I wanted to be possible (not sure if there is any module doing that with Module:Wd right now, but that doesn't really matter). In that case, the title contained by the frame will be the title of the module that is including Module:Wd, and so not actually the title of the included module "Module:Wd" which is needed to construct "Module:Wd/i18n". After some googling I found out that there is a triple-dot argument ... that on Wikipedia, for reasons unknown to me, contains the title of the called module (this was the only solution I could find after also consulting the Wikipedia Lua community). But it only contains that title when the module is included by another module. Here is an example, where module number 2 includes module number 1 and calls test(frame) in module number 1:

{{#invoke:Sandbox/Thayts/1|test}}	... => nil frame:getTitle() => Module:Sandbox/Thayts/1
{{#invoke:Sandbox/Thayts/2|test}}	... => Module:Sandbox/Thayts/1 frame:getTitle() => Module:Sandbox/Thayts/2

As you can see on the bottom row, the ... contains the title of the module that was included, which differs from the title of the module that was including it. I hope this clarifies things.

Regarding the red links, I'm not sure what causes it in the Infobox module and if it the ... is part of the cause at all. Obviously, a /i18n submodule should only be called if there actually is one. Thayts ••• 10:52, 30 June 2018 (UTC)

Amazing! Thanks for the comprehensive reply. It is reasonable as ... provides the command-line arguments in a stand-alone Lua program (that is, not a module running in Scribunto), and those arguments include the name of the program being run. I do not see ... documented anywhere as being available in Scribunto to get the name of a module called by another module with require. I will have to think some more and may ask for information somewhere.

Re "Module:" possibly being different at other projects, it's not relevant but in case you were not aware, "Module:" works everywhere, for example bn:Module:Convert and bn:Module:ট্র্যাক তালিকায়ন.

In a couple of days I hope also to think about the /i18n issue and see whether some trick might be used to disable the red link at enwiki (perhaps do not look for a subpage if the start of the ... name is "Module:"?). Johnuniq (talk) 11:57, 30 June 2018 (UTC)

You're welcome. I do remember that I expected ... to be a table and that it turned out to be a string instead (actually the string I needed). I did not know about the English namespace working on other wikis, good to know! Still, the name of the module might differ from "Wd", so it's good to leave it in there. Thayts ••• 12:35, 30 June 2018 (UTC)

Some checking shows a slightly different picture from what I said earlier. In stand-alone Lua 5.1, the global variable arg is a table containing the command-line arguments and a little bit more. The name of the script being run is arg[0] and any arguments are in arg[1], arg[2], etc. If used outside a function, ... unpacks arg which would generate arg[1], arg[2], etc (but would omit the name of the script in arg[0]).

It looks like the place where Scribunto sets arg is package.lua (that applies when one module uses require to access a second module). That sets arg[1] to the name of the second module.

Using local arg = ... puts global arg[1] into local arg which gets the desired result. Using ... is convenient because it will give nil (if global arg is nil) or arg[1].

@Anomie: Is what I've said correct? Can we rely on arg being nil (if a module is directly called with #invoke) or being a table with arg[1] being the name of the required module? Johnuniq (talk) 07:24, 1 July 2018 (UTC)

@Johnuniq: You seem to be right. I've replaced ... with arg[1] and it does contain the same string:

{{#invoke:Sandbox/Thayts/1|test}}
{{#invoke:Sandbox/Thayts/2|test}}	arg[1] => Module:Sandbox/Thayts/1 frame:getTitle() => Module:Sandbox/Thayts/2

As the error shows, you would need to do an extra check to see if the global arg is set, so ... is indeed more convenient to use. Thanks for checking this out! Thayts ••• 07:58, 1 July 2018 (UTC)

@Johnuniq: As far as existing behavior goes, you're effectively correct. _G.arg will be nil from an #invoke and ... will be empty, and from require() _G.arg will be a table having one element (the module name loaded) and ... will be a list as described.

If you want to get technical, note that ... doesn't actually unpack _G.arg. It's just that the two contain the same values.

I'm also not sure why Scribunto's package library sets _G.arg in require(), it doesn't seem that standard Lua 5.1's package library does that. I guess it's because Scribunto's package library was originally copied from a compat-5.1 library for 5.0 and 5.0 doesn't seem to have any other way to pass the module name parameter in a 5.1-like manner. Anomie⚔ 14:49, 1 July 2018 (UTC)

Property

I've struck through "{{Property}}, used to add a Wikidata property link in text" because clearly {{Property}} is something else entirely, but I have no idea what it should list here; I assume there is some template for that purpose. - Jmabel | Talk 23:43, 13 June 2018 (UTC)

@Jmabel: Two templates can do that: {{Wikidata entity link}} (which requires the leading "P") and {{Wikidata property link}} (which works with or without the "P" and has additional display options). Also, {{Property}} is now a redirect to the second template (similar to d:Template:Property). I updated the list at Template:Wd/doc § See also. -- Zyxw (talk) 19:43, 1 August 2018 (UTC)

label in "references" with no slovenian language available

Hi from Slovenian Wikipedia! Can you help me with a problem?

Example: {{#invoke:wd|properties|qualifier|references|normal+|Q55|P1082|P585}} displays 17,942,942 (1 January 2024), 17,590,672 (1 January 2022), 17,407,585 (1 January 2020), 17,282,163 (1 January 2019), 17,181,084 (1 January 2018), 17,081,507 (1 January 2017), 17,000,000 (21 March 2016), 16,829,289 (26 August 2014), 16,779,575 (2013), 10,026,773 (1950)

Problem: The publisher "Statistics Netherlands (Q167086)" does not have a label in Slovenian language, so text "publisher: Statistics Netherlands" is not displayed in Slovenian articles. Is it possible to display the label in any available language? You can see how it works at sl:Uporabnik:Pinky sl/PeskovnikW

--Pinky sl (talk) 19:22, 4 January 2019 (UTC)

Hi, you can set a Slovenian label yourself at https://www.wikidata.org/wiki/Q167086?setlang=sl&uselang=sl. That label should then be displayed. Thayts ••• 12:20, 5 January 2019 (UTC)

Thanks for your answer. Yes, I can set it. But I am in charge for importing data from Wikidata into our infoboxes. I am preparing the first infobox that will be filled completely from wd. And references are important. I cannot set all the missing sl labels; and labels keeps updating. And it is not just about publishers. --Pinky sl (talk) 07:44, 6 January 2019 (UTC)

Well, do you have a suggestion what should be displayed if a Slovenian label is not available? We could perhaps use English as default, but there is also no guarantee that an English label is always available. Thayts ••• 12:45, 6 January 2019 (UTC)

I guess, the best way to do this is: if local language label is not available, then substitute language shoud be used (maybe this can be set in /i18). If there is no local or substitute language, you can display just link to Wikidata object - example: Q167086? with an error category. It is better that way then leave it empty.

[[:d:' .. entityId .. '|' .. entityId .. ']]<span style="border-bottom: 1px dotted; cursor: help; white-space: nowrap" title="No label ..... . You can help us to translate it to local language.">?</span>' .. categoryLinksToEntitiesWithMissingLabel

Pinky sl (talk) 15:59, 6 January 2019 (UTC)

It is possible and I've played around with it in a sandbox, but I'm still figuring out what the best default would be if I would be implementing this. Thayts ••• 10:42, 18 January 2019 (UTC)

Most recent claim regardless of rank

Hi @Thayts:, I have another question: is there a way to return the claim with the most recent point in time (P585), even when a less recent claim has a higher rank? For instance, using population (P1082) on Basel (Q78) returns the population as of 2024-12-31, even though there are population figures for 2018 stored in the entity page. Is there a way to get the latest figures, without having to change all the ranks? Thank you for your excellent work, as always.--eh bien mon prince (talk) 21:29, 30 January 2019 (UTC)

@Thayts:, when you have the time, this issue is more current than ever after the deletion of several wrappers of {{Infobox settlement}}.--eh bien mon prince (talk) 03:27, 19 March 2019 (UTC)

Although I think the ranking system is most suitable for this and it is simply the data in Wikidata that is not up to date, I do see this can have added value. However, to make this as generic as possible I would like to add a sort function, but that's not trivial to implement. But I will see what I can do. Thayts ••• 11:40, 24 March 2019 (UTC)

Returning the top-level administrative division

@Thayts:I'm trying to use this template to fill the subdivision_type fields of {{Infobox settlement}}, but I have trouble with it because of the way located in the administrative territorial entity (P131) works up backwards from the lowest level division to the top.

So {{wikidata|property|P131}} is the lowest level division, {{wikidata|property|eid={{wikidata|property|raw|P131}}|P131}} is the second lowest, and so on. But is there a way to reliably retrieve the top-level division for the entity (or second-level, etc.), no matter how many divisions are below it?

For instance, the template would need to find the top level division canton of Ticino (Q12724) on both Brè (Q3646180) and Lugano District (Q660612), without changing the syntax. Can this be achieved? --eh bien mon prince (talk) 20:30, 16 January 2019 (UTC)

I don't think there is, unless there is a library feature for it that I don't know of. Note however that canton of Ticino (Q12724) is not the top level division, because it itself is located in the administrative territorial entity (P131) of Switzerland (Q39). Thayts ••• 10:40, 18 January 2019 (UTC)

It would of course be possible to implement this with a dedicated command or so, but then when do you stop while working the way up? Also, an entity can have multiple located in the administrative territorial entity (P131) properties, so which do you choose? Thayts ••• 10:44, 18 January 2019 (UTC)

Thanks for the reply. This is some sort of 'solution' I adopted. Basically, called on a page like Lugano District, it checks whether the entity in located in the administrative territorial entity (P131) is an instance of (P31) canton of Switzerland (Q23058), and if it's not, it moves up to the next administrative level. But it is extremely wasteful in terms of resources, and it cannot be scaled up to more than two or three administrative levels.

{{#ifeq: {{wikidata|property|raw|eid={{wikidata|property|raw|P131}}|P31}} | Q23058 | {{wikidata|property|raw|P131}} | {{#ifeq: {{wikidata|property|raw|eid={{wikidata|property|raw|eid={{wikidata|property|raw|P131}}|P131}}|P31}} | Q23058 | {{wikidata|property|raw|eid={{wikidata|property|raw|P131}}|P131}} | {{wikidata|property|raw|eid={{wikidata|property|raw|eid={{wikidata|property|raw|P131}}|P131}}|P131}} }} }}

--eh bien mon prince (talk) 03:22, 19 January 2019 (UTC)

As I'd like to keep this module as generic as possible, I think this doesn't fit the module very well because is hard to implement in a generic way. What's still a possibility though is to create a template that uses this module and that is specifically designed for the task at hand. Thayts ••• 11:44, 24 March 2019 (UTC)

ucfirst

ucfirst don't work : how can I capitalize the first letter in {{ucfirst:<ul>{{wikidata|properties|normal+|current|linked|Q870899|P1885|P1013=Q2577114|format=<br>%p[%r][<ul><li>%q</li></ul>]}}</ul>}} :

Saintes cathedral
Saint-Pierre Cathedral

 ?

In french, the result is :

• cathédrale Saint Pierre
• cathédrale Saint Paul

and I want not cathédrale but Cathédrale (c->C) :

• Cathédrale Saint Pierre
• Cathédrale Saint Paul

cdt, Speltdecca (talk) 17:55, 8 June 2019 (UTC)

@Speltdecca: Transforming formatted text is currently not possible with this module. However, using CSS you can make each list item appear to start with a capital like this:

<ul>{{wikidata|properties|normal+|current|linked|Q870899|P1885|P1013=Q2577114|format=<li style="text-transform:capitalize">%p[%r]</li>}}</ul>

or

<ul style="text-transform:capitalize">{{wikidata|properties|normal+|current|linked|Q870899|P1885|P1013=Q2577114|format=<li>%p[%r]</li>}}</ul>

You'll only notice that each item doesn't actually start with a capital when you copy it and paste it elsewhere, but I hope this is acceptable for you. Thayts ••• 15:35, 18 July 2019 (UTC)

Template-protected edit request on 11 October 2019

As this module is now edit protected and I can't edit it myself anymore, please copy and implement the current contents of the sandbox to here. This is a small uncontroversial change as the code comparison shows, which replaces a hacky solution to get the global site ID with a call to a recently added dedicated function. I have added 4 testcases with a call to the badges function, which is the only function that relies on the site ID. The testcases show the same results for the current version of the module and the sandbox version. Thayts ••• 08:58, 11 October 2019 (UTC)

@Thayts: I have temporarily disabled the edit request while we sort something out. Do you want the Wikipedia:Template editor right? If so, please confirm you have examined that page and understand the requirements. In particular, while edit warring is always undesirable, it is particularly prohibited when using an advanced right. So, for example, if you edited this module using the TE right and someone reverted you (they would need the TE right to do that), there must be no further edits until the issue is sorted out on a talk page. I'll be away and won't see any reply for the best part of a day but I don't see a reason why you wouldn't just be given the right so you can continue to edit this module. In principle, requests should be made here but I'm happy to skip that if you don't mind waiting until I return. Or, re-activate the edit request if you want. Johnuniq (talk) 09:25, 11 October 2019 (UTC)

@Johnuniq: Thank you, I would very much like to receive the right. I have read the page and understand my obligations. I'm also familiar with the edit warring policy and understand to avoid it and go into discussion first. Thank you for your confidence! Thayts ••• 10:05, 11 October 2019 (UTC)

 Done — Martin (MSGJ · talk) 10:50, 11 October 2019 (UTC)

Wikidata Bridge

(Reposted from Module talk:WikidataIB § Wikidata Bridge.)

I'm guessing that the module maintainers might be unaware of this? The WMDE developers have been working on mw:Wikidata Bridge, which will allow some Wikidata statements to be edited directly through infoboxes and other templates. There's currently a semi-interactive prototype. I think it would be useful for the module maintainers to provide feedback, if there are any issues that haven't already been addressed.

There's an early draft of a documentation page that might help explain how the software's supposed to be enabled inside template code. Jc86035 (talk) 08:32, 3 July 2019 (UTC)

@Jc86035: Thanks for telling. I was indeed unaware of this, but it is a great initiative that brings a lot of convenience! It would be easy to implement in this module too. Please keep us posted! By the way, will it also be possible to edit e.g. qualifier values? Thayts ••• 15:59, 18 July 2019 (UTC)

@Thayts: I don't think there is a definite answer yet. There has been a fair amount of discussion at mw:Talk:Wikidata Bridge about what the software is actually going to be like, so you might want to follow the discussions on that page if you're interested in the software's development. Jc86035 (talk) 16:04, 18 July 2019 (UTC)

Note that WikidataBridge might allow editing of entries in ways that will not be shown due to formatting done by this module. Jeblad (talk) 01:39, 6 November 2019 (UTC)

Date parameter

You may be interested to add a date parameter like the one we have implemented in bgwiki [2]. Use cases are flags, countries, etc. at specific past dates. --Nk (talk) 07:10, 17 September 2019 (UTC)

@Nk: Thanks for the suggestion. However, you can already achieve this by filtering on qualifier by supplying an (exact) date like {{#invoke:wd|property|Qxxx|Pxxx|P580=yyyy-mm-dd}}. Or do you want to be able to supply a less exact date that falls within the start-end time range? Thayts ••• 07:20, 14 October 2019 (UTC)

@Thayts: I want to supply a date and match it against the entire start/end range. It works like that: [3]. --Nk (talk) 11:54, 14 October 2019 (UTC)

@Nk:  Done; it has been implemented. Thayts ••• 17:14, 9 November 2019 (UTC)

Errors after recent edit

@Thayts: Something in the edit of 11:10, 9 November 2019 broke a few articles. I don't have time to investigate further atm. For example, see Shovana Narayan#External links where {{Scholia}} is generating The ID "{{{ID}}}" is unknown to the system. Please use a valid entity ID. Johnuniq (talk) 03:10, 10 November 2019 (UTC)

I think I fixed the problem with this edit at {{Scholia}}. I don't know how the change to the module revealed that, however it seems ok. Johnuniq (talk) 09:21, 10 November 2019 (UTC)

(I've moved this discussion to a new section) @Johnuniq: That edit indeed introduced a generic check on the existence of an entity to mitigate error conditions with the title and description commands. I was not aware that it would introduce a new error condition, yet I found that this condition already existed for the claim commands and the edit made the module's behaviour therefore more consistent (but not completely). However, I think that an invalid ID should not result in an error, so I made another edit to check its validity and prevent the error condition. The template should have given valid input nonetheless, so thanks for fixing that. Thayts ••• 20:56, 11 November 2019 (UTC)

The reported error comes from Wikibase because it is given an incorrect identifier. Same error as in #Failing verification. Jeblad (talk) 00:42, 12 November 2019 (UTC)

Failing verification

Somewhere in the code path for rendering reference there are probably one or more missing verification of existence of some substructure. In short a nil-value is passed where you are assuming a table, most likely because the table is empty in the statement, and it is thus removed. Always check whether the table exist, or fallback to an empty table. Also make sure that the code holds for empty tables, the code isn't totally consistent on empty structures. Or at least it wasn't.

I don't have any example, as all examples have been promptly fixed by changing statements. Jeblad (talk) 01:33, 6 November 2019 (UTC)

@Jeblad: A concrete example would help. Thayts ••• 21:26, 11 November 2019 (UTC)

As I said; “I don't have any example, as all examples have been promptly fixed by changing statements.” But fixed, users work around the issue by changing the references. Jeblad (talk) 00:43, 12 November 2019 (UTC)

Can't you recall a page where the problem was seen and a rough time when that occurred? Perhaps then the edit which fixed the issue might be found and any underlying problem identified. Johnuniq (talk) 00:49, 12 November 2019 (UTC)

Use of underscore

Use of undersore (local _ = Config.new()) as a variable name breaks several tools for Lua, as it is assumed to be used for unassigned values. Or breaks, some of them silently fails as statements involving an underscore are simply neglected. (Not sure if complete code paths involving a neglected statement are neglected.) Jeblad (talk) 01:24, 6 November 2019 (UTC)

@Jeblad: The underscore is currently used in a very limited and controlled way, within a local scope. It's not used with Lua tools, so I don't think there is an issue really. Thayts ••• 21:25, 11 November 2019 (UTC)

Yes, but it is true that Lua convention is to use underscore to mean an unused variable. The code in the module is very clean and sophisticated but I was going to suggest that the global variables be cleaned up. I'll post a list and have a look at that later if wanted. Johnuniq (talk) 23:31, 11 November 2019 (UTC)

The statement “I don't think there is an issue really” does not hold when the issue breaks code verification. I would say “fix it”. Jeblad (talk) 00:52, 12 November 2019 (UTC)

That would be more convincing if there were an explanation about what breaking code verification refers to: what is the tool and how it is used? Johnuniq (talk) 02:47, 12 November 2019 (UTC)

Don't fix it if it isn't broken I would say, and it doesn't seem to be broken. However, if we're going to make a list of improvements anyway then I don't mind to put it on there. It's a good thing there are testcases now (although they cannot cover everything like defaulting to the current page's entity ID), so we should be more confident to make such changes.

By the way, the module is performing quite poorly (i.e. slow) so I will also be seeing what can be done about that. Thayts ••• 08:04, 12 November 2019 (UTC)

Any reference to a variable name consisting of a single underscore will lead to all errors involving this name being rejected. This happens with most of the tools for static analysis for Lua. If you don't want to fix it, fine, but then don't expect anyone to use time trying to track down errors within this module. Jeblad (talk) 00:56, 19 November 2019 (UTC)

@Jeblad: Ok, I get what you mean: there might be errors that we don't know about because there might be tools running on this Wikipedia that suppress them. I'm also not necessarily against fixing it, so I just did that. Thanks for your input! Thayts ••• 21:58, 20 November 2019 (UTC)

@Thayts: Thanks, although I don't see why Jeblad is unwilling to identify the tool. Please check my recent edits to Module:Wd/sandbox. They are just style changes. Let me know if anything is a problem or unwanted. Once you have had a chance to examine the edits, I have some more minor points to discuss if wanted. Johnuniq (talk) 04:29, 21 November 2019 (UTC)

An example from Lua users: The variable consisting of only an underscore "_" is commonly used as a placeholder when you want to ignore the variable [4] and more

Note: This resembles the use of "_" in Haskell, Erlang, Ocaml, and Prolog languages, where "_" takes the special meaning of anonymous (ignored) variables in pattern matches. In Lua, "_" is only a convention with no inherent special meaning though. Semantic editors that normally flag unused variables may avoid doing so for variables named "_"(e.g. LuaInspect is such a case) [LuaLint and LuaCheck also comes to mind, but there are several others…].

I guess it is fairly obvious why this naming scheme is a bad idea. Jeblad (talk) 13:28, 21 November 2019 (UTC)

Thanks but no one needs convincing about the Lua convention, and thanks for the LuaInspect link. Johnuniq (talk) 03:07, 22 November 2019 (UTC)

@Johnuniq: Looks fine to me, I've published it. Thayts ••• 12:59, 23 November 2019 (UTC)

Can this template produce links in the form d:Q12345#P360

I have a requirement on pages such as Wikipedia:WikiProject Women in Red/Missing articles by occupation/Conductors to provide a link for the user to the P360 property for the page's item. Can this template produce a link in the form d:Q76380272#P360? thx --Tagishsimon (talk) 13:19, 24 November 2019 (UTC)

Not out of the box, but you could construct it like this (and e.g. make a template out of it): {{#if:{{wd|label|raw}}|[[d:{{wd|label|raw}}#P360]]}} Thayts ••• 08:10, 25 November 2019 (UTC)

Thank you, Thayts; that'll do very nicely indeed. Very grateful. --Tagishsimon (talk) 12:42, 25 November 2019 (UTC)

The ID of the given page

How do I get the page ID for a given page? I'm trying to convert a usage of {{#invoke:Wikidata|pageId}} but can't seem to find in the doc here. The usage is in {{Birth date}} where it seems just to check if the item exists, so if there is a different check that gives the same result, that could also work. --Gonnym (talk) 19:11, 2 January 2020 (UTC)

I see that {{Q}} uses {{#invoke:Wikibase|id}} which gives "Q123" on a page with that id, but unwisely gives "no entity" rather than an empty string if none. Johnuniq (talk) 22:51, 2 January 2020 (UTC)

Thanks for that. While I appreciate all the work that has gone into this module, I have to say, that for a module that is intended to replace Module:Wikidata, the lack of editor-friendly functions and clear documentation makes this module really hard to use. I found that this module has {{#invoke:wd|label|raw|linked}} that returns the ID, but why can't it provide direct access to the wikibase version? --Gonnym (talk) 09:51, 5 January 2020 (UTC)

@Gonnym: Thanks for the feedback. Note that this is just another module that was not intended to replace Module:Wikidata. Indeed, {{wd|label|raw}} is the way to get the ID. I will look into improving the documentation. But what do you mean with the Wikibase version? Thayts ••• 08:16, 6 January 2020 (UTC)

Hey Thayts, thanks for the reply and again, thanks for the hard work. Module:Wikidata is marked as deprecated and notes that it should be replaced with this and the infobox module version. A template I was fixing used the mw.wikibase.getEntityObject() result which I couldn't replicate here (it gives name and id in a linked version). --Gonnym (talk) 08:23, 6 January 2020 (UTC)

@Gonnym: Have you tried it without the 'linked' flag as I suggested? {{wd|label|raw}} Thayts ••• 17:28, 6 January 2020 (UTC)

Yeah, that gives me just the QID, unlinked. I need the name + QID linked in the same link. --Gonnym (talk) 17:37, 6 January 2020 (UTC)

So with a link to Wikidata? This module provides some basic functions, but you can make many combinations like [[:d:{{wd|label|raw}}|{{wd|label}} ({{wd|label|raw}})]]. It is recommended to also perform a check to see if an entity exists like so: {{#if:{{wd|label|raw}}|[[:d:{{wd|label|raw}}|{{wd|label}} ({{wd|label|raw}})]]}}. Hope that helps! Thayts ••• 19:04, 6 January 2020 (UTC)

Example on math

I wanted to add an example for math like this one. However, the documentation on how to add new samples to the module documentation was somehow scary. Can someone help me? I think adding

to ${\frac {n^{2}-1}{n^{2}+2}}={\frac {4\pi }{3}}N\alpha$ would help to better understand the example.

--Physikerwelt (talk) 15:28, 2 January 2020 (UTC)

@Physikerwelt: Yes, it's a bit complicated. I've added a new example, does that look like what you wanted? Thayts ••• 18:51, 6 January 2020 (UTC)

@Thayts: Thank you soo much. This way the formula is easier to understand.--Physikerwelt (talk) 16:22, 12 January 2020 (UTC)

Add link to Wikibase for math formulae

I suggest to add the qID attribute to the math tag generated by the wd for properties with data type math. I implemented for a similar datatzype content math on the drmf wiki. I suggest to change the current code

return mw.getCurrentFrame():extensionTag("math", datavalue)

to

return mw.getCurrentFrame():extensionTag{
	name="math",
    content= datavalue, 
	args={qid=mw.wikibase.getEntityIdForCurrentPage()} //here I am not sure if this is correct. I guess it will not pick up the item id if the property is specified.
}

The qid attribute will be picked up by the mw:Extension:Math which will generate a hyperlink to specialpage which will show additional information regarding the formula including its source on wikidata. --Physikerwelt (talk) 18:19, 13 January 2020 (UTC)

@Physikerwelt:  Done. Thayts ••• 14:59, 17 January 2020 (UTC)