Wikidata
This module is within the scope of WikiProject Wikidata, a collaborative effort to improve Wikipedia's integration with Wikidata. If you would like to participate, please visit the project page.WikidataWikipedia:WikiProject WikidataTemplate:WikiProject WikidataWikidata articles

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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

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

{{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)[reply]

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

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)[reply]

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)[reply]

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

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

@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)[reply]

@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)[reply]

@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)[reply]

@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)[reply]

@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)[reply]

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)[reply]

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)[reply]

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

@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)[reply]

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

@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)[reply]

@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)[reply]

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

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)[reply]

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

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

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

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)[reply]

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)[reply]

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)[reply]

@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)[reply]

@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)[reply]

@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)[reply]

@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)[reply]

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

@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)[reply]

@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)[reply]

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

@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)[reply]

@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)[reply]

@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)[reply]

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

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

@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)[reply]

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

@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)[reply]

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)[reply]

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)[reply]

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

@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)[reply]

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

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)[reply]

@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)[reply]

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)[reply]

@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^[1]

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

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^[1]
• 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)[reply]

@Pinky sl:

• Yes: {{Wd|property|raw|references|Q17560835|P2386|P518=Q29841352}} → 13.61^[1]
• 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)[reply]

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)[reply]

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)[reply]

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)[reply]

@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)[reply]

@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)[reply]

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

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

@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)[reply]

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)[reply]

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)[reply]

@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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

@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)[reply]

@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)[reply]

@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:

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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

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)[reply]

@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)[reply]

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

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

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

@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 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)[reply]

I don't think there is, unless there is a library feature for it that I don't know of. Note however that 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)[reply]

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)[reply]

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)[reply]

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 2022-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)[reply]

@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)[reply]