Module talk:WikidataIB/Archive 5

Need some help with lua errors and other issues
Hello. I've been working on a [large] wikidata-enabled infobox for some months now, and I plan on getting that over with soon. I have a few questions, and I hope it's fine if I mention them here as I progress... I appreciate any help that comes this way :)

Total qualifier value of all subclasses
First question. Running the below code in edit-preview mode in Bruce Nuclear Generating Station: ...will output the value  (the number of  in that power station). Which is perfect. Is there a way to set  in such a way, that is checks the  qualifiers of all subclasses of, instead of only , and thus outputs the total value? Reh man  03:44, 7 March 2019 (UTC)
 * It does not seems possible with this module but it's definitely possible with some Scribunto Lua code. Tpt (talk) 10:18, 7 March 2019 (UTC)
 * Well that is extremely unfortunate :-( If anyone has a workaround to this, please do let me know! Cheers, Reh  man  15:14, 7 March 2019 (UTC)
 * Hi, I'm not sure I understand the request. Can you give me a concrete example and I'll see if can work it out.
 * Let me explain what I'm thinking. For, let's get the value of :
 * Then request all of the qualifiers and suppress the pen icon:
 * Request a subset of the qualifiers, like (this could be a list):
 * Request to display only the qualifier:
 * Now if I had an example of a Wikidata entity that gave multiple qualifiers, I could set +, which would give all of the numbers separated by the plus sign. I think that the parser function  could add those together to give you a total, like   →.
 * Of course, if I've misunderstood, then let me know and I'll see if I can write some code for you. The thing I can't do is scan through the Wikidata database to look for matches; I have to start at one one entry and use that or entities that are found from that (as in the getPropOfProp function). Cheers --RexxS (talk) 17:07, 7 March 2019 (UTC)
 * Hi RexxS. Basically, there is a  parameter at infobox power station, which should list the total number of reactors in the given nuclear power station. There could be a number of different types of reactors the power station could use (scroll down to  ), and CANDU is one such type.
 * And hence, I need  to check all instances of the quantity qualifier values of all the particular types of nuclear reactors (while thus simultaneously also allowing the possibility of a nuclear plant having more than one reactor type). This can be done either by manually stating the entities/"has part" (i.e. reactor types) to look for, or if possible, by getting the infobox to scan  and all it's subclasses for the quantity qualifier.
 * Does this make sense? Thank you for helping. Reh  man  01:32, 8 March 2019 (UTC)
 * It does make sense, but I really need an example of a power station with multiple types of nuclear reactors, so I can test the code. I can only read the properties. If you look at, there's nothing there that links to its subclasses, so I can't find them from there. You can run this WDQS query to get the 35 subclasses of nuclear reactor currently on Wikidata, but I can't do that in Lua. Even if I could, looking at , for example, doesn't lead to any quantity qualifiers as you were hoping. --RexxS (talk) 02:53, 8 March 2019 (UTC)
 * , I understand. Here are two examples: Olkiluoto Nuclear Power Plant, Leningrad Nuclear Power Plant. Reh  man  10:22, 8 March 2019 (UTC)
 * it looks like my suggestion should work:
 * For if we ask for just the qualifiers for the values of, and specify '+' as the separator, we get:
 * So we can do this to add them up:
 * same for :
 * How's that for a work-around? --RexxS (talk) 20:36, 8 March 2019 (UTC)
 * That's perfect, RexxS. Does exactly what is needed. But is there a way to limit the code to adding values only belonging to nuclear reactors types? We could manually "whitelist" the item codes to read from... The reason for this is because the template will be used for other power station types as well. And that particular parameter shouldn't process values not belonging to nuclear plants (i.e. solar farms would also use "has part" with the quantity qualifier for number of solar panels). Reh  man  11:28, 9 March 2019 (UTC)
 * That's we run into the problem. I can't see a way of Lua code being able to select just the values that belong to nuclear reactors types without manually specifying the types. We could compile a whitelist, but that would be fixed and wouldn't change dynamically if another type were added to Wikidata. I would write a function for you if were able to give me the list of Q-numbers for the types you want to include. You'd need to let me know whether you wanted the list to be supplied as a parameter to the #invoke call, or as a text list in a sub-page of a module. Cheers --RexxS (talk) 22:17, 9 March 2019 (UTC)
 * Yes RexxS, manually listing a static whitelist in #invoke is perfect. It is very unlikely that the reactor types would change so frequently, and if it ever does, a simple infobox edit would solve the issue. The list of reactors are mentioned here, under the  parameter.  Reh  man  02:37, 10 March 2019 (UTC)
 * For if we ask for just the qualifiers for the values of, and specify '+' as the separator, we get:
 * So we can do this to add them up:
 * same for :
 * How's that for a work-around? --RexxS (talk) 20:36, 8 March 2019 (UTC)
 * That's perfect, RexxS. Does exactly what is needed. But is there a way to limit the code to adding values only belonging to nuclear reactors types? We could manually "whitelist" the item codes to read from... The reason for this is because the template will be used for other power station types as well. And that particular parameter shouldn't process values not belonging to nuclear plants (i.e. solar farms would also use "has part" with the quantity qualifier for number of solar panels). Reh  man  11:28, 9 March 2019 (UTC)
 * That's we run into the problem. I can't see a way of Lua code being able to select just the values that belong to nuclear reactors types without manually specifying the types. We could compile a whitelist, but that would be fixed and wouldn't change dynamically if another type were added to Wikidata. I would write a function for you if were able to give me the list of Q-numbers for the types you want to include. You'd need to let me know whether you wanted the list to be supplied as a parameter to the #invoke call, or as a text list in a sub-page of a module. Cheers --RexxS (talk) 22:17, 9 March 2019 (UTC)
 * Yes RexxS, manually listing a static whitelist in #invoke is perfect. It is very unlikely that the reactor types would change so frequently, and if it ever does, a simple infobox edit would solve the issue. The list of reactors are mentioned here, under the  parameter.  Reh  man  02:37, 10 March 2019 (UTC)
 * That's perfect, RexxS. Does exactly what is needed. But is there a way to limit the code to adding values only belonging to nuclear reactors types? We could manually "whitelist" the item codes to read from... The reason for this is because the template will be used for other power station types as well. And that particular parameter shouldn't process values not belonging to nuclear plants (i.e. solar farms would also use "has part" with the quantity qualifier for number of solar panels). Reh  man  11:28, 9 March 2019 (UTC)
 * That's we run into the problem. I can't see a way of Lua code being able to select just the values that belong to nuclear reactors types without manually specifying the types. We could compile a whitelist, but that would be fixed and wouldn't change dynamically if another type were added to Wikidata. I would write a function for you if were able to give me the list of Q-numbers for the types you want to include. You'd need to let me know whether you wanted the list to be supplied as a parameter to the #invoke call, or as a text list in a sub-page of a module. Cheers --RexxS (talk) 22:17, 9 March 2019 (UTC)
 * Yes RexxS, manually listing a static whitelist in #invoke is perfect. It is very unlikely that the reactor types would change so frequently, and if it ever does, a simple infobox edit would solve the issue. The list of reactors are mentioned here, under the  parameter.  Reh  man  02:37, 10 March 2019 (UTC)

Okay, I've created a function called getSumOfParts: For (which has 4 RBMK + 4 water-water energetic reactors): For (which has 1 PWR + 2 boiling water reactors): For (which has 8 CANDU reactors): For (which doesn't seem to have any reactors, according to Wikidata): I've deliberately suppressed zero as a result so that the infobox should ignore that field without need for any further testing in the template. Does that work for you? Perhaps try some tests and let me know if you find problems. Cheers --RexxS (talk) 18:19, 10 March 2019 (UTC)
 * getSumOfParts scans the property 'has part' (P527) for values matching a list.
 * The list is passed in parameter vlist.
 * It consists of a string of Qids separated by spaces or any usual punctuation.
 * If the matched values have a qualifier 'quantity' (P1114), those quantities are summed.
 * The sum is returned as a number or nothing if it's zero.


 * Million thanks, RexxS. I will test this now and update again. Reh  man  18:24, 10 March 2019 (UTC)
 * Resolved. Works wonderfully, RexxS. Thank you again. Reh  man  18:53, 10 March 2019 (UTC)

Unexpected lua error
Second question. Why does the below code work well (run code in edit-preview mode in Nesjavellir Geothermal Power Station): And this doesn't (only difference is the qualifier): -- Reh man  03:50, 7 March 2019 (UTC)
 * You need to set the |lang=en parameter of the WikidataIB module to give the language in which the quantity unit should be displayed. Tpt (talk) 10:18, 7 March 2019 (UTC)
 * = 2000 metre
 * Many thanks Tpt! Deeply appreciate your help. I thought that was automatic (based on English wiki). Reh  man  10:35, 7 March 2019 (UTC)
 * Hi and : It was a genuine bug. I had set a language object in the args of getQualifierValue, but hadn't set the corresponding language code (as I do in getValue). That's fixed now. The language used should always be (in order of preference): (1) a valid language code set by lang; (2) the user's preferred language (on multi-lingual wikis); (3) the default site language. On English Wikipedia, that means it should now automatically default to English, as you expected.
 * So, for :
 * Please let me know if you find any more errors. Cheers --RexxS (talk) 15:03, 7 March 2019 (UTC)
 * Resolved. Thank you very much RexxS. It is only when someone truly digs in to these modules/templates, that they start to realise what godly/almost-impossible work people like you accomplish outside the spotlight. Brilliant work, RexxS. Best wishes, Reh  man  15:12, 7 March 2019 (UTC)
 * Please let me know if you find any more errors. Cheers --RexxS (talk) 15:03, 7 March 2019 (UTC)
 * Resolved. Thank you very much RexxS. It is only when someone truly digs in to these modules/templates, that they start to realise what godly/almost-impossible work people like you accomplish outside the spotlight. Brilliant work, RexxS. Best wishes, Reh  man  15:12, 7 March 2019 (UTC)

Check for a specific property value
Third question. Not too sure if this one is relevant to this talkpage though. Taking as example again, we can see it has two values as. How do I get WikidataIB to check all P31 values, and IF it matches any one of the given property values (i.e. Q41722964, Q41722780, or Q4086827), it should display specific text. For example: Is this possible here? Or is it more ParserFunctions related? Reh man  04:59, 7 March 2019 (UTC)
 * If one of the item's P31 matches Q41722964, it should output the plain text "Flash steam".
 * Resolved. Found a workaround: .  Reh  man  09:05, 7 March 2019 (UTC)
 * I don't know whether you want to display all of, , , or just one of them.
 * However, using WikidataIB, you can also get an ID from a list of properties - this can either return all of the IDs (yes) or just the first ID it encounters (default). In this case, just P31 is checked.
 * So, using String|find (which returns 0 if it can't find the target in the source), you could check:
 * That allows you to use, for :
 * Anyway, it's good that you have a solution. Cheers --RexxS (talk) 16:35, 7 March 2019 (UTC)
 * That allows you to use, for :
 * Anyway, it's good that you have a solution. Cheers --RexxS (talk) 16:35, 7 March 2019 (UTC)
 * Anyway, it's good that you have a solution. Cheers --RexxS (talk) 16:35, 7 March 2019 (UTC)
 * Anyway, it's good that you have a solution. Cheers --RexxS (talk) 16:35, 7 March 2019 (UTC)
 * Anyway, it's good that you have a solution. Cheers --RexxS (talk) 16:35, 7 March 2019 (UTC)

Information of individual generation units of power stations
Fourth problem, and probably the final big one before completing this infobox. Here, I'm trying to structure data in a way where we could auto-fill these four parameters in Infobox power station/sandbox:
 * 1)   → The number of generation units operational and [if possible] their nameplate capacity → Example:
 * 2)   → The manufacturer and model of the generation units → Example:     (model doesn't necessarily have to be linked (i.e. have a wikidata item))
 * 3)   → The number of generation units under construction →  Example:
 * 4)   → The number of generation units decommissioned →  Example:

I'm considering structuring the data in the following format (better suggestions are most welcome):


 * Power station item (e.g. )
 * Manufacturer of Unit 1 (e.g. )
 * (model number of generating unit)
 * (installed capacity of this unit)
 * (date construction began)
 * (date commissioned)
 * (date decommissioned)
 * Manufacturer of Unit 2 (e.g. )
 * (and so on, for each unit...)
 * (and so on, for each unit...)

But based on the above, it seems like only part of the requirement could be met. For instance:
 * Number of units under construction:
 * Number of operational units:
 * Number of decommissioned units:

Any suggestions on how this could be done? Of course, structuring the data differently is not an issue, if it helps make things easier... Reh man  13:35, 15 March 2019 (UTC)
 * I'm going to have to write custom code for this problem, so the way that the data is structured doesn't matter too much, as long as it's consistent. The problems will be more about how to return four values into separate fields without having to make four separate calls and duplicating a lot of calls to Wikidata. Would you be willing to call these as a sub-template? I've added a parameter to your sandbox as a placeholder (obviously you can move it to wherever you want by changing the data number). I'll try and write some code today for you. --RexxS (talk) 14:26, 15 March 2019 (UTC)
 * I'm going to need some examples to test on. I've started making a made-up power station using – it's best not to add made-up statements to real entities, but perhaps you could put some statements into the Wikidata Sandbox to give me an idea of what I might have to deal with. It looks like there's a problem with, as a constraint doesn't like it being used as a qualifier, but I can code with that for now. Do you have more power stations with these details in Wikidata that I can test on? --RexxS (talk) 15:40, 15 March 2019 (UTC)
 * Update: I have some preliminary code running in Module:Sandbox/RexxS/PSunits, with some testing in Module talk:Sandbox/RexxS/PSunits. --RexxS (talk) 17:53, 15 March 2019 (UTC)
 * Update: I have some preliminary code running in Module:Sandbox/RexxS/PSunits, with some testing in Module talk:Sandbox/RexxS/PSunits. --RexxS (talk) 17:53, 15 March 2019 (UTC)


 * Thanks RexxS. I'm not too sure what impact a sub-template would have, but of course, if there is an issue later, we could always make adjustments. Hence please do feel free to go ahead with the subtemplate. :) I've added more parallel units to, so that it allows more complex testing.
 * The results at Module talk:Sandbox/RexxS/PSunits is a great start! These are the next functions that is needed based on those results:
 * → After scanning the number of active units (i.e. no P730 value), it should check those units for identical installed capacities (i.e. 130MW) and display the higher occurrences as a multiplier, with the non-identical capacities in following lines (i.e. → [  ×  ]   [  ×  ]   [  ×  ])
 * The same principle can be applied to  and.
 * → For those active units which were filtered (above), it should check occurrences of  sets, and only display unique values. For example, four active units such as below would display as:
 * [  ], [   ], [   ] → [ ]   [ ]
 * Does this make sense? Do let me know if you require real examples. It would be difficult to find a single article which has all these situations present, but there would be separate situations spread across a bunch of articles. Reh  man  07:05, 16 March 2019 (UTC)
 * How does Module talk:Sandbox/RexxS/PSunits look now? It has sorting of display values and it will eventually implement accessibility fixes to produce proper lists. Ignore the debug info. Can you test it with some more qids? Tell me when you're ready to try it inside your Infobox power station/sandbox. Cheers --RexxS (talk) 22:03, 16 March 2019 (UTC)
 * . It's hard not to call this magic, thank you! So far it seems to work seamlessly. Just a few minor adjustments:
 * Is it possible to switch from  to  ?
 * For the manufacturer name, can we use the standard label if is missing, and link it? Such that   would be
 * -- Reh man  08:39, 17 March 2019 (UTC)
 * I think I've managed those changes: Module talk:Sandbox/RexxS/PSunits.
 * I prefer to only link where the sitelink exists on Wikidata, as that should make the code more portable for use on other language wikis, and it avoids accidentally linking to dab pages if you try to link to the label. There may be problems where the label and sitelink are both missing, but they will hopefully be rare. --RexxS (talk) 18:27, 17 March 2019 (UTC)
 * I've now added the module call directly to Template:Infobox power station/sandbox for testing. See the bottom of the page Wikidata/Wikidata Sandbox for a working example. You can preview it in real power station infoboxes if the Wikidata exists for that power station, but bear in mind that a local parameter in the infobox should override the Wikidata. --RexxS (talk) 21:24, 17 March 2019 (UTC)
 * I've now added the module call directly to Template:Infobox power station/sandbox for testing. See the bottom of the page Wikidata/Wikidata Sandbox for a working example. You can preview it in real power station infoboxes if the Wikidata exists for that power station, but bear in mind that a local parameter in the infobox should override the Wikidata. --RexxS (talk) 21:24, 17 March 2019 (UTC)


 * Nice, I will do some thorough testing and update here again. Regarding the linking, yes I meant sitelink :). So far, these are my findings:
 * Can we replace  with the standard multiplication sign  ?
 * When the total infobox width changes (i.e. preview with ) the generation units sections seems to be static. Will we be able to display the values within the existing template label/data structure? This is probably because of the subtemplate-ing? I think this would also make it easier to allow individual parameter-based local overrides?
 * For situations like (where inception/commissioned dates are set as unknown [i.e. not blank]), can we also count such values for number of units uc/commissioned/decommissioned?
 * -- Reh man  06:03, 18 March 2019 (UTC)
 * I think we need to stop testing on Lakvijaya Power Station ;) Reh  man  12:43, 18 March 2019 (UTC)
 * I've replaced the multiplication sign
 * The module was producing a self-contained table, and I'd fixed the label width inside that. I've now amended the code to tap into what Module:Infobox is wrapping around the data, so that it produces rows that are now an integral part of the infobox table. Unfortunately, the price we pay is that we have to have something in the first line of data. I've used the word "Generators" so that it looks like a sub-sub-heading. We can play with that later.
 * In order to create the displayed output, I create arrays of data for each set of statements in If we have dates set as unknown, it's more difficult to create them. Nevertheless, I think I can do it. I'll ping you later when I have a solution. Cheers --RexxS (talk) 19:26, 18 March 2019 (UTC)
 * It wasn't as hard as I expected. Should be done now - I changed the Harbin Electric service entry to unknown value and it initially logged as 'under construction'. I updated the code to accept 'somevalue' and now the Harbin Electric shows as 'operational'. Cheers --RexxS (talk) 22:33, 18 March 2019 (UTC)
 * I've suppressed the sub-sub-heading "Generators" as a test. That leaves a couple of pixels of extra space before the first text from the module. That might be okay. --RexxS (talk) 00:02, 20 March 2019 (UTC)
 * Sorry for the late reply RexxS. We were experiencing countrywide blackouts after a unit2 of Lakvijaya malfunctioned. I did some tests at Template:Infobox power station/sandbox/doc for the extra leading space; I too think it should be fine, since we have a header immediately above it (it camouflages the extra space). I will continue with a bit more tests, and if all is good, I think we could go live with that section.
 * Where do you think we should store the lua code though? Does it make sense to add it within WikidataIB, or as a WikidataIB subpage, a template subpage, or even maybe something like Module:Infobox power station? Reh  man  03:20, 20 March 2019 (UTC)
 * I wrote the code as a self-contained module so that we could put it where we want. I've moved it to Module:Infobox power station and tidied up the calls in your sandbox. That has the advantage that we could add further functions as needed in the same module. Cheers --RexxS (talk) 17:59, 20 March 2019 (UTC)
 * Thanks for that RexxS. Sorry for the late reply, we're facing regular *very annoying* countrywide blackouts after that RL power plant problem :( Is it possible to split the output into separate calls/parameters (i.e. "Units operational", "Make and model", "Units under const", "Units decommissioned")? I'm trying to figure out how to create the option of local override for each section. Splitting the output is not necessary, if there is a better method? Reh  man  14:20, 25 March 2019 (UTC)
 * I'm sorry, I don't understand what you're trying to do, . The whole point of the module was to deliver four related items. Why do you want to split it into four separate calls at this stage? You don't have to create an option for local overrides; I already built that into the code so that it recognises the same parameter names. Just use the local parameter in the #invoke and that's what you get instead of what's on Wikidata. I've modified your sandbox to move the four parameters to the module #invoke. Try adding some values for them in Wikidata/Wikidata Sandbox and see the results. --RexxS (talk) 23:32, 25 March 2019 (UTC)

You're right RexxS, I forgot that you already added the local overrides, sorry. I'll test those now. Best regards, Reh  man  01:59, 26 March 2019 (UTC)
 * Hi RexxS. Apologies for the my oversight; can we include two more similar parameters  and   to Module:Infobox power station please? I initially planned to remove it, but the community has come up with valid reasons to retain it. The two parameters functions very similar to the existing ones, as documented here. And there is no changes to   as that is only based on  .  Reh  man  09:16, 18 April 2019 (UTC)
 * sorry, it took me a little while to find a stretch of uninterrupted time so that I could do the update. It wasn't too difficult as I'd arranged the processing of the present four fields in blocks and it was just a matter of copying and amending the code for the "planned" and "cancelled" fields. You can see an example result in Wikidata/Wikidata Sandbox . The data for it is at . Let me know if you spot any problems. Cheers --RexxS (talk) 13:15, 20 April 2019 (UTC)
 * No worries at all, RexxS. So I did a thorough test of all the parameters using custom and unknown values. These are the only necessary adjustments left:
 * "Make and model" to state  for manufacturers entered as unknown values. For example, there is a fourth 100-gigawatt operational unit stated in the Wikidata sandbox, but it doesn't match the number in "make and model". Hence this will avoid the confusion.
 * In "Make and model", currently is not shown as a suffix of manufacturer if the value is not set in English on Wikidata. Can we also have 'unknown values' function this way? Right now, unknown values cause the whole parameter to not display (instead of only the codename part).
 * If "Units operational" or "Make and model" uses local value, both should only display local values. I.e. If "Units operational" uses local parameters, "Make and model" should not fetch content from Wikidata as well, and vice versa.
 * Move the whole "Units under const." section after "Units cancelled"
 * And finally, can we include hard spaces between all the words in the parameter labels? For example, between  and   and  . In some articles, the words moves to the next line, creating a confusing empty space.
 * Thank you so much for your help in this! -- Reh man  09:15, 28 April 2019 (UTC)
 * Hi RexxS. Pinging you in case you missed the earlier ping (no rush). Cheers, Reh  man  11:39, 16 May 2019 (UTC)
 * Sorry I've been so busy and I need an extended period to do the next lot of programming. I'll try to reserve enough time this week. --RexxS (talk) 22:51, 19 May 2019 (UTC)
 * No need to apologise, RexxS. I completely understand, there is no rush. Thanks for the update :-) Reh  man  00:05, 20 May 2019 (UTC)
 * RexxS, I created a complex test case for testing at the sandbox, but that keeps getting removed. Do you know of an easy way to restore parts from history without messing other entries? If not, it's alright, I'll do it again once you're ready. Reh  man  09:50, 10 June 2019 (UTC)
 * Well, I didn't find the time last week; let's try again this week. I looked at the problem with the and realised that there is a, so I considered using that instead because it seemed less used. Then I had a brainwave and created the . We're the only ones who know about it for now, so we can probably use it for a week or so without being disturbed. Would you like to set up the test environment that you want there? and I'll start work on updating the code in Module:Infobox power station to make the fixes you want. I've linked it to Wikidata/Wikidata Sandbox 3 so we can perform tests in there. --RexxS (talk) 12:38, 22 June 2019 (UTC)
 * Thank you, RexxS. I will create the test environment at, and update here again. Cheers, Reh  man  05:03, 23 June 2019 (UTC)

Section break
Hi RexxS. I've populated the test cases at. After going through the functions again, I've noticed that I had made some bad choices (such as using codename, when that is for temporary names), hence I had slightly tweaked how things should work. Basically, the generation unit model replaced the manufacturer, in. That way, the Q-item of the generation unit can host the manufacturer name and installed capacity, although the latter can be modified by the power station.

Please have a look at the related template parameters (scroll down to "Power generation" within the table), and do let me know if anything is confusing. Please let me know if any part is confusing, or if anything is missing to get this done. Thank you again for helping with this. Reh man  17:50, 30 June 2019 (UTC)
 * Installed capacity should be derived from qualifier . Only if that is blank, then the value should be obtained from the Q-item of the respective generation unit.
 * should display the values based on the properties stated in the Q-item of the respective generation unit:
 * for, and  for  . If no short name is stated, then the label should be displayed.
 * If is not stated in the Q-item of the generation unit, then only the   should be stated.
 * As before, for power station with multiple listed models, the separate models should be displayed in an unbulleted list format
 * As before,  should only display values for those units which are currently operational. Others should be ignored.


 * Hi Thanks for setting that up. Even if it gets overwritten, we can easily restore it from the page history, so it should give us a little more time to do these updates. Would it be worth making a second sandbox for Template:Infobox power station, just for the wikidata version? Template:Infobox power station/wikidata would allow us to work on that while you develop other changes in the normal sandbox version. I couldn't do any checking last week because you had taken out the #invoke from the current sandbox a couple of weeks ago, and I didn't want to disturb what you were doing.
 * I'm happy to get away from codename and I can do the rest of the changes when I get a few uninterrupted hours. This week is going to be tough as I'm at a WMUK Board meeting tomorrow, and then in Cornwall for the Celtic Knot Conference from Wednesday to Friday. I'll probably find some time next weekend, though. Cheers --RexxS (talk) 18:14, 30 June 2019 (UTC)
 * No worries RexxS, next weekend is completely fine. Sorry about the module removal from the sandbox, that was unintentional. I have restored it now. A second sandbox may not be required at this point, as it is just us who are using it :) Best regards, Reh  man  01:36, 1 July 2019 (UTC)
 * Hi RexxS! Hope you are well. Just a gentle ping, if we can get this completed... :) Reh  man  13:06, 10 August 2019 (UTC)
 * Hi . Sorry I've been distracted with a lot of other things in the lead-up to Wikimania, but I've not forgotten you. I'm hoping that during the Hackathon I'll get some uninterrupted time to work on the re-write of the module. Cheers --RexxS (talk) 14:25, 10 August 2019 (UTC)
 * Hi . At last I've managed to do some more work on the module. I've re-written the handling of the model and manufacturer, taken into account the possibility that some entries for P516 might not have any useful information, and incorporated the qualifier . I have three questions:
 * What do you want to do with engines that have no date info? Should we assume they are "planned" as previously? or might they be they operational? If the latter, how would we distinguish "planned"?
 * Am I handling the qualifier properly?
 * What's missing, if anything?
 * Could you play around with the statements in and see in Wikidata/Wikidata Sandbox 3 if they results look like what you want, please? Any further testing is good at this stage. Please let me know what else needs to be done and I'll try to put some more time in this week while it's still fresh in my mind. Cheers --RexxS (talk) 20:28, 22 September 2019 (UTC)
 * Many thanks, RexxS. I will test it and update here again. Cheers, Reh  man  03:35, 25 September 2019 (UTC)
 * RexxS, I did some tests from office a few days back, and also went through the outputs from the sandbox, it seems to be working fantastic. Thank you so much for all your help, and hard work. I will do further tests with more complex plant configurations in the next few days, but I doubt there would be anything significant. The sandbox configuration is insanely complex, and it works great. I believe we should be able to move the code to the live template over the next week. Yay! Reh  man  15:59, 29 September 2019 (UTC)
 * I'm glad it seems to be okay, and sorry it's taken me so long to find an uninterrupted session to get to grips with the code again. It was a significant re-write, but worth it, as I'm much more confident of the code's robustness now. I'll be away on holiday for the next couple of weeks, but I'll try to check my notifications even while I'm away. Cheers --RexxS (talk) 19:00, 29 September 2019 (UTC)
 * Many thanks, RexxS. I will test it and update here again. Cheers, Reh  man  03:35, 25 September 2019 (UTC)
 * RexxS, I did some tests from office a few days back, and also went through the outputs from the sandbox, it seems to be working fantastic. Thank you so much for all your help, and hard work. I will do further tests with more complex plant configurations in the next few days, but I doubt there would be anything significant. The sandbox configuration is insanely complex, and it works great. I believe we should be able to move the code to the live template over the next week. Yay! Reh  man  15:59, 29 September 2019 (UTC)
 * I'm glad it seems to be okay, and sorry it's taken me so long to find an uninterrupted session to get to grips with the code again. It was a significant re-write, but worth it, as I'm much more confident of the code's robustness now. I'll be away on holiday for the next couple of weeks, but I'll try to check my notifications even while I'm away. Cheers --RexxS (talk) 19:00, 29 September 2019 (UTC)
 * RexxS, I did some tests from office a few days back, and also went through the outputs from the sandbox, it seems to be working fantastic. Thank you so much for all your help, and hard work. I will do further tests with more complex plant configurations in the next few days, but I doubt there would be anything significant. The sandbox configuration is insanely complex, and it works great. I believe we should be able to move the code to the live template over the next week. Yay! Reh  man  15:59, 29 September 2019 (UTC)
 * I'm glad it seems to be okay, and sorry it's taken me so long to find an uninterrupted session to get to grips with the code again. It was a significant re-write, but worth it, as I'm much more confident of the code's robustness now. I'll be away on holiday for the next couple of weeks, but I'll try to check my notifications even while I'm away. Cheers --RexxS (talk) 19:00, 29 September 2019 (UTC)
 * I'm glad it seems to be okay, and sorry it's taken me so long to find an uninterrupted session to get to grips with the code again. It was a significant re-write, but worth it, as I'm much more confident of the code's robustness now. I'll be away on holiday for the next couple of weeks, but I'll try to check my notifications even while I'm away. Cheers --RexxS (talk) 19:00, 29 September 2019 (UTC)

Hi RexxS. No need to apologise, we are all volunteers. :) I did further tests, and everything seems good other than a small adjustment in how  and   fetches data. Previously when  is set as unknown value,   and   generates a valid output based on the available information, but it now generates an error (preview this by changing the template to /sandbox). Maybe a part of the code with mistakenly over written?

Another example, for instance in Pawan Danavi Wind Farm, if the editor adds the manufacturer Q-item in instead of the engine model Q-item, an error is generated. Whereas I believe earlier a short name/available name of would have been displayed in , along with the relevant counters in both   and. Reh man  04:43, 6 October 2019 (UTC)


 * @RexxS, I did more tests and confirm that the last issue in this area is in . The issue wasn't there before though. Maybe something was accidentally altered?  Reh  man  02:40, 14 October 2019 (UTC)
 * The changes made were because you used model instead of manufacturer for P516, so it's natural that putting manufacturer into that field wouldn't work as it did previously. I've now trapped any issues with the value of P516 being something that isn't a model and also accounted for the possibility that someone sets it to "unknown value". The errors no longer exist when using Infobox power station/sandbox in Pawan Danavi Wind Farm as far as I can see. Also the Wikidata/Wikidata Sandbox 3 is showing that it can cope with "unknown values". Let me know if you find anything else. Cheers --RexxS (talk) 10:38, 14 October 2019 (UTC)
 * Resolved. Thank you, RexxS. Works perfect! The only final adjustment needed was to change the unknown output from lowercase to sentence-case. I think I managed to do that myself :) Thank you again for all the help over the past 6+ months! Reh  man  13:10, 14 October 2019 (UTC)
 * A quick question, when adding  on Yugadanavi Power Station, the locally-set parameter value ("test") is shown. But for an article with minimal data on Wikidata such as Aggreko Power Station, the locally-set parameter does not work. Any idea what is causing this? I cannot seem to be able to trace the cause...  Reh  man  15:09, 14 October 2019 (UTC)
 * I had set up the module to return nothing if there was no Wikidata information available. but I can see that you still might want to use the template, supplying local values for those cases. I've modified the code so that it just skips over the data collection part when there is nothing on Wikidata, but still renders the rest. That should give you the ability to supply local parameters in those cases. Cheers --RexxS (talk) 16:13, 14 October 2019 (UTC)
 * Thank you! Reh  man  16:18, 14 October 2019 (UTC)

Official name based on the country of subject
The  parameter should only display the name of the power station in the official language(s) of the country in which the power station is located in. So for example: Any suggestions on an efficient way to do this? I think this could be manually achieved by using a bunch of  and   or the similar functions, but I'm not sure if that is the best way, as that would mean first unnecessarily calling all  values, and then filtering it locally. Reh man  07:08, 29 March 2019 (UTC)
 * For, there may be many entries for various languages under
 * Considering the power station is located in Sri Lanka, and and  is entered under  in :
 * The infobox should only show entries in Sinhala and Tamil for Lakvijaya PS (as the power station is located in Sri Lanka).
 * I really don't think this is a good idea. I've already seen more than enough criticism of importing Wikidata into infoboxes to want to be involved with displaying foreign script in the English Wikipedia – especially when there's an official name in English. Anyway, these calls are available:
 * Is there a good reason to deprecate the for  in English? Wikidata usually reserves deprecated values for values that are somehow "wrong". I'd advise leaving English as normal in, and then asking for "best" ranks when calling WikidataIB, so you get only the preferred values where they exist.
 * It's difficult to code a way of making a guess at the official language from the location of the power station, so I think you're going to have to supply a language parameter to the infobox and then explicitly make use of that in the call to WikidataIB for the official name. --RexxS (talk) 16:57, 29 March 2019 (UTC)
 * RexxS, I understand regarding the foreign scripts. Maybe that could be separately raised in the respective infoboxe(s) in the future? I'm currently only trying to implement Wikidata functions for already existing parameters, hence I am not in a position to remove the parameter at this point. Also, thank you for letting me know about the deprecated values. I didn't know that deprecated values were treated that way (I thought they were more used to order things). I will do the changes as you suggested.
 * I've managed to find a way to get the country's official language IDs as per below:
 * → Q13267, Q5885
 * → Q294
 * I'm rather stuck on how we can use the generated IDs, such that it can be used as a filter to block out the entries that are not of the matching language IDs. I guess this is not possible at the moment? Reh  man  13:02, 30 March 2019 (UTC)
 * We can use WikidataIB to fetch Qids in a similar way. For and :
 * But we also have a call that would fetch the of the, so we can use that once we've found the Qid of the  that the power station belongs to:
 * So could use that as the value of the language parameter.
 * Of course, has no, so there's nothing to see in the second example (although it is in the Icelandic language!).
 * There is a problem with countries that have multiple values for . The code above will take the first one it finds, unless one is "preferred". I don't think you can do that for si and ta, so we will get one or the other simply depending on how they are stored in Wikidata. I can make code to deal with particular cases, but have no suggestions how to make a decision in the general case.
 * I really ought to just write a function that takes a qid (or uses the one for the page) and returns the language code to simplify all that code above. --RexxS (talk) 15:30, 30 March 2019 (UTC)
 * Update: So I did that. There's a new function getItemLangCode and a wrapper template for it called ItemLC. The code above can now be simplified to:
 * If it's being used only for the current page, then you can simply omit the qid. --RexxS (talk) 19:16, 30 March 2019 (UTC)
 * Partially resolved. Thank you RexxS. I went ahead and added the code. It would be nice to have a way to display the official name in more than one official languages in the future though. There are many instances where this could be useful. One random example would be Mount Everest, where the native name is displayed in three different native scripts based on the applicable official languages. Reh  man  06:49, 18 April 2019 (UTC)
 * So could use that as the value of the language parameter.
 * Of course, has no, so there's nothing to see in the second example (although it is in the Icelandic language!).
 * There is a problem with countries that have multiple values for . The code above will take the first one it finds, unless one is "preferred". I don't think you can do that for si and ta, so we will get one or the other simply depending on how they are stored in Wikidata. I can make code to deal with particular cases, but have no suggestions how to make a decision in the general case.
 * I really ought to just write a function that takes a qid (or uses the one for the page) and returns the language code to simplify all that code above. --RexxS (talk) 15:30, 30 March 2019 (UTC)
 * Update: So I did that. There's a new function getItemLangCode and a wrapper template for it called ItemLC. The code above can now be simplified to:
 * If it's being used only for the current page, then you can simply omit the qid. --RexxS (talk) 19:16, 30 March 2019 (UTC)
 * Partially resolved. Thank you RexxS. I went ahead and added the code. It would be nice to have a way to display the official name in more than one official languages in the future though. There are many instances where this could be useful. One random example would be Mount Everest, where the native name is displayed in three different native scripts based on the applicable official languages. Reh  man  06:49, 18 April 2019 (UTC)
 * I really ought to just write a function that takes a qid (or uses the one for the page) and returns the language code to simplify all that code above. --RexxS (talk) 15:30, 30 March 2019 (UTC)
 * Update: So I did that. There's a new function getItemLangCode and a wrapper template for it called ItemLC. The code above can now be simplified to:
 * If it's being used only for the current page, then you can simply omit the qid. --RexxS (talk) 19:16, 30 March 2019 (UTC)
 * Partially resolved. Thank you RexxS. I went ahead and added the code. It would be nice to have a way to display the official name in more than one official languages in the future though. There are many instances where this could be useful. One random example would be Mount Everest, where the native name is displayed in three different native scripts based on the applicable official languages. Reh  man  06:49, 18 April 2019 (UTC)
 * If it's being used only for the current page, then you can simply omit the qid. --RexxS (talk) 19:16, 30 March 2019 (UTC)
 * Partially resolved. Thank you RexxS. I went ahead and added the code. It would be nice to have a way to display the official name in more than one official languages in the future though. There are many instances where this could be useful. One random example would be Mount Everest, where the native name is displayed in three different native scripts based on the applicable official languages. Reh  man  06:49, 18 April 2019 (UTC)

Shortening large numerical values
Apologies in advance if this is already documented somewhere, I've searched, but couldn't find it. Looking at in, the value is   (when generated locally). How do I: -- Reh man  07:08, 29 March 2019 (UTC)
 * 1) Shorten the value to something in like "1.35 billion" or "1,350 million" ?
 * 2) Expand the unit to be more meaningful, for example   or , instead of only
 * 3) Link the unit to the corresponding article. For example,   if the currency is Sri Lankan rupee.
 * I can do the first, but don't have any way of doing the other two at present:
 * I gave up trying to document Module:WikidataIB when another editor repeatedly removed documentation that I had written, . Your best bet for finding functionality is to explore Module talk:WikidataIB/testing which has lots of examples. --RexxS (talk) 17:20, 29 March 2019 (UTC)
 * Resolved. Thank you. The 3rd option seems to be the best way forward currently, although the features of expanding the units and linking the same, would be beneficial in the future. Reh  man  10:42, 30 March 2019 (UTC)
 * I gave up trying to document Module:WikidataIB when another editor repeatedly removed documentation that I had written, . Your best bet for finding functionality is to explore Module talk:WikidataIB/testing which has lots of examples. --RexxS (talk) 17:20, 29 March 2019 (UTC)
 * Resolved. Thank you. The 3rd option seems to be the best way forward currently, although the features of expanding the units and linking the same, would be beneficial in the future. Reh  man  10:42, 30 March 2019 (UTC)
 * I gave up trying to document Module:WikidataIB when another editor repeatedly removed documentation that I had written, . Your best bet for finding functionality is to explore Module talk:WikidataIB/testing which has lots of examples. --RexxS (talk) 17:20, 29 March 2019 (UTC)
 * Resolved. Thank you. The 3rd option seems to be the best way forward currently, although the features of expanding the units and linking the same, would be beneficial in the future. Reh  man  10:42, 30 March 2019 (UTC)

Obtaining property value based on series ordinal number
This isn't a function request, but more of a "how to" question. Looking at this parameter table, power stations can use multiple fuel sources (i.e. primary fuel, secondary fuel, tertiary fuel). How do I use  so that I can, for example, obtain the fuel source stated as  =. In other words, for the article how do I fetch "Coal", which is currently stored as, with the qualifier  =  ? Is this possible, or is this the right way to do it? Reh man  09:29, 28 April 2019 (UTC)
 * At present,  can only match the qualifier value if it's a wikibase-entity (i.e. a Q-number). I need to expand the code to deal with qualifier values that are other types before it can do the job you want. --RexxS (talk) 11:41, 4 May 2019 (UTC)
 * [Update:] I've made the modification:
 * Let me know if you find problems. Cheers --RexxS (talk) 12:50, 4 May 2019 (UTC)
 * Resolved. Thank you, RexxS. It works perfectly. Reh  man  02:39, 7 May 2019 (UTC)
 * Let me know if you find problems. Cheers --RexxS (talk) 12:50, 4 May 2019 (UTC)
 * Resolved. Thank you, RexxS. It works perfectly. Reh  man  02:39, 7 May 2019 (UTC)
 * Resolved. Thank you, RexxS. It works perfectly. Reh  man  02:39, 7 May 2019 (UTC)

Converting qualifier values
For statements like  with qualifier , what is the best way to convert length (i.e. metres to feet)? Template:Convert already supports direct Wikidata-based conversions, but only to main property values (as opposed to qualifier values). Based on the discussion on the template talkpage, Convert does not have this functionality yet. Reh man  06:47, 22 May 2019 (UTC)
 * WikidataIB already has the ability to call cvt internally; you just use the  flag. It's always helpful when requesting solutions to give an example of where it might be used, which saves me having to search for a Wikidata item with those properties, so that I can test it. For the moment, I've created an artificial example in the :
 * Perhaps you can test out the conversions with a real case and see if the default conversions are adequate for your purpose. Cheers --RexxS (talk) 16:37, 22 May 2019 (UTC)
 * Perhaps you can test out the conversions with a real case and see if the default conversions are adequate for your purpose. Cheers --RexxS (talk) 16:37, 22 May 2019 (UTC)


 * Resolved. Thanks RexxS, it works seamlessly. I looked around on the module page but didn't see a documented convert feature, hence resorted to asking at Convert. Sorry for the lack of example; at the moment there isn't a live example yet, as I wanted to know if this is practical before defining the method of storing specific power station details. Cheers, Reh  man  14:36, 23 May 2019 (UTC)

Plural units
When I use this module to obtain a certain property it comes back with "683 week". What is the best way to make it say "683 weeks"? &mdash; Martin (MSGJ · talk) 07:12, 4 October 2019 (UTC)
 * Wikidata only stores unit labels in the singular, so I've been working on a module to convert English nouns to plural in anticipation of this request. I can't do much while I'm on holiday, but I'll be back on 12 October, and I'll get it working asap. Of course, you would be most welcome to try out the module if you can find it, I'm sorry it's really hard to search using my mobile phone. --RexxS (talk) 11:09, 4 October 2019 (UTC)
 * I found the module, Module: Sandbox/RexxS/Plural. --RexxS (talk) 17:45, 4 October 2019 (UTC)
 * Hope you already sorted it, but now I'm back, I've put some work into expanding the sandboxed module. I've now moved it into main module space at Module:UnitPlural.
 * Two sub-functions are also exported for use in other modules. Cheers --RexxS (talk) 15:12, 14 October 2019 (UTC)
 * Great, thanks. I was using a hack of just adding an s, but this looks better &mdash; Martin (MSGJ · talk) 19:01, 14 October 2019 (UTC)
 * What would be the best way to use this module to get better output in the following?
 * Two sub-functions are also exported for use in other modules. Cheers --RexxS (talk) 15:12, 14 October 2019 (UTC)
 * Great, thanks. I was using a hack of just adding an s, but this looks better &mdash; Martin (MSGJ · talk) 19:01, 14 October 2019 (UTC)
 * What would be the best way to use this module to get better output in the following?
 * Two sub-functions are also exported for use in other modules. Cheers --RexxS (talk) 15:12, 14 October 2019 (UTC)
 * Great, thanks. I was using a hack of just adding an s, but this looks better &mdash; Martin (MSGJ · talk) 19:01, 14 October 2019 (UTC)
 * What would be the best way to use this module to get better output in the following?
 * Two sub-functions are also exported for use in other modules. Cheers --RexxS (talk) 15:12, 14 October 2019 (UTC)
 * Great, thanks. I was using a hack of just adding an s, but this looks better &mdash; Martin (MSGJ · talk) 19:01, 14 October 2019 (UTC)
 * What would be the best way to use this module to get better output in the following?
 * What would be the best way to use this module to get better output in the following?


 * which produces &mdash; Martin (MSGJ · talk) 20:08, 14 October 2019 (UTC)
 * Ah, qualifiers – the constant bug-bear. I need to call the plural function inside WikidataIB's renderSnak function, then it will be applied to each quantity retrieved by the module. The only complication is that Wikidata is fully internationalised, and I haven't got any internationalisation in Module:UnitPlural yet (although I've left hooks in place for it). I'll just do a work-around for enwiki for now. I should have some time tomorrow to change and test WikidataIB. Cheers --RexxS (talk) 21:51, 14 October 2019 (UTC)

P1107 and percentages
Hello. uses values 0 to 1, to state proportions (such as shared ownership). When fetched through, the result here is also displayed in decimals. Is it possible to convert the result here, to percentages? Reh man  10:18, 31 October 2019 (UTC)
 * I can see that the information is in qualifiers which are harder to work with:
 * I'll have a look to see if I can cook up a string transform function that can be applied separately and converts those numbers to percentages. --RexxS (talk) 15:57, 31 October 2019 (UTC)
 * This will screw up if the company name contains a number, but it may be okay to experiment with for now:
 * Let me know if you run into a problem with it and I'll try to refine the behaviour. Cheers --RexxS (talk) 17:13, 31 October 2019 (UTC)
 * This will screw up if the company name contains a number, but it may be okay to experiment with for now:
 * Let me know if you run into a problem with it and I'll try to refine the behaviour. Cheers --RexxS (talk) 17:13, 31 October 2019 (UTC)
 * Let me know if you run into a problem with it and I'll try to refine the behaviour. Cheers --RexxS (talk) 17:13, 31 October 2019 (UTC)

WikidataBridge
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:41, 6 November 2019 (UTC)
 * Please elaborate on your concerns. I've been involved from the beginning in making sure that WikidataBridge can be integrated directly into any result that displays the pen icon and I've not been informed of any potential issues so far. I'll be happy to try to resolve any problems that may arise. --RexxS (talk) 13:58, 6 November 2019 (UTC)
 * You have a single link to open an edit interface that is unconstrained in editing the linked statements, but the template and/or module to show the statemenets are constrained. Any module that filter or limit qualifiers or references will have this issue. Jeblad (talk) 14:08, 6 November 2019 (UTC)
 * Well that's going to be the case for any module that retrieves a subset of the entire Wikidata entry, and that is essential in order to reduce the effect on watchlists when other parts of the Wikidata entry are changed. It looks like that's an unavoidable feature. --RexxS (talk) 14:17, 6 November 2019 (UTC)
 * The watchlist entry is not important in this sense, it should reflect what is actually changed, and changes should not be hidden away. The important thing is that users will be editing templates and this module will hide the the same edits. That will lead to confusion and a broken mental model. It is the same for several modules, trying to deny is not very wise. Jeblad (talk) 19:07, 6 November 2019 (UTC)
 * I'm afraid that you're quite misguided about what's important. If editors are getting their watchlists filled with changes on Wikidata unrelated to the articles they watch, they will hide Wikidata changes in their watchlists, and then we will lose any chance of them helping to reduce the severe issues of vandalism prevalent on Wikidata.
 * You claim "users will be editing templates and this module will hide the the same edits" You're mistaken. This module will not hide the edits to those templates. If you think otherwise, please show an example of where that happens. --RexxS (talk) 20:03, 6 November 2019 (UTC)
 * I'm afraid that you're quite misguided about what's important. If editors are getting their watchlists filled with changes on Wikidata unrelated to the articles they watch, they will hide Wikidata changes in their watchlists, and then we will lose any chance of them helping to reduce the severe issues of vandalism prevalent on Wikidata.
 * You claim "users will be editing templates and this module will hide the the same edits" You're mistaken. This module will not hide the edits to those templates. If you think otherwise, please show an example of where that happens. --RexxS (talk) 20:03, 6 November 2019 (UTC)