Jump to content

Module talk:European and national party data/Archive 2

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

Roadmap for national party composition bar function

[edit]
Task Completion Comments
1.1 Create the module "EU party seats lower upper houses" to give out the number of seats in lower/upper houses held by all the national member parties of a given European political party; the module should also give the associated composition bar ✅ Test cases for the module: main function and composition bars; and for the sandbox: main function and composition bars
1.2 Integrate module above into EUPP seats module ✅ Module:EUPP seats is now the reference
1.3 Ensure comments are all in the code ✅
1.4 Update documentation of EUPP seats module and its two templates ✅ Template:EUPP seats, Template:EUPP composition bar
2.1 Update membership of European parties' national member parties based on APPF data ✅
2.2 Make a table of lower and upper houses and their qID for each EU member state ✅ Lower/upper houses per MS
2.3 Find qIDs of all national member parties and update Wikimedia Commons table ✅ National party seats in lower/upper houses
2.4 Update Wikidata for seats in lower/upper houses for all relevant national member parties ✅
2.5 Update infoboxes of EUPPs on Wikipedia to use templates ✅
3.1 Create the national_party_composition_bar function (in EUPP seats module) to give out a political party's composition bar in its relevant national lower or upper house (called from national party infobox, takes "lower house" or "upper house" as argument) ✅ Deployed
3.2 Create a template for the above function and add documentation (to module and template) ✅ Template:EUPP national party
3.3 Check/update the EUPP membership, country, and hex value of national parties on Wikidata ✅
3.4 Add option to query EP seats in national_party_composition_bar(), then update document for module and template ✅
3.5 Check/update the EP seats of national parties on Wikidata ✅
3.6 Update national member parties' infoboxes to use the above template (including a comment with the URL of the party's page on Wikidata to make updates easier) ⚠️ Resuming after addition of EP data

Discussion

[edit]
@Trappist the monk, wanna have some more Lua, party-related fun? ;) Julius Schwarz (talk) 21:03, 29 March 2025 (UTC)[reply]
Perhaps. The above isn't sufficiently clear to give me an understanding of what needs to be done. In our last venture there was a template that served as an armature upon which a module could be hung. That doesn't appear to be the case this go round.
—Trappist the monk (talk) 22:03, 29 March 2025 (UTC)[reply]
I see what you mean. Obviously only points 1 and 7 need some Lua, and I think I can do most of point 1 by myself. As for point 7, it's actually just a simplified version of the EUPP seats module, except we do not need to indicate the party (it should be always use the party from which page it is called -- except for testing purposes, of course, and in this case we can give the qID of a specific national party) and we just use lower house or upper house for the institution (and the table in point 6 will make the link between the party's country and the qID of the lower or upper house). The way I see it, it's mostly a trimmed-down version of our previous module. Julius Schwarz (talk) 07:46, 30 March 2025 (UTC)[reply]
Do these templates/module in point 7 have a name? Point 7 mention a table from point 6. Is the table in point 6 something that exists on commons (Data:Seats_of_EU_national_parties_in_lower_and_upper_houses.tab or some other) or is the table something that is maintained in a lua ~/config module? Is such table necessary for the purposes of point 7?
I futzed about and hacked Module:Sandbox/Trappist the monk/party which seems to be a way to get all of the (so far) required data. Using the NEOS qid (NEOS – The New Austria (Q13564543)) for an example:
{{#invoke:Sandbox/Trappist the monk/party|main|Q13564543}} →
The only thing that is obviously missing is a way to distinguish 'upper' from 'lower'.
—Trappist the monk (talk) 16:56, 30 March 2025 (UTC)[reply]
That's a really good point, @Trappist the monk. My idea, since I am already using a Wikimedia Commons table for the module in point 1, was to also use a similar table that would just have six columns: country name, country_qid, lower house name, lower house qid, upper house name, upper house qid. Admittedly, only the qid are relevant, but that would make the table more readable to humans. As you indicate, that could probably also be in a config file. I guess the commons table might make it easier to amend if need be, but these are hardly things that are likely to change often. Come to think about it, we could even do without an extra table, as that information could be extracted from the commons table created for the module of point 1, which already links the qid of a national party with the qids of its lower and upper houses. The only issue with this is if someone tries to use the module (or its subsequent template) for a national party that is not a member of a European party; then it would not be included in the table made for the module of point 1 and the module/template would not work. By contrast, assume the party has a Wikidata page, this would most likely tie it to a jurisdiction and then we could tie it to a lower/upper house via either the commons table or the config file.
As for your code, that is really useful. The way that I see it, a normal call would be invoke: nameofmodule | main | house=lower-house or something similar. A qid would only be added for testing purposes and, in the absence of one, it would just take the one from the page in question (as when we used "thisparty" before). And then invoke: nameofmodule | composition_bar | house=lower-house would give the related composition bar. The related template would be "name of template | house=lower-house" and "name of template for composition bar | house=upper-house". Julius Schwarz (talk) 18:03, 30 March 2025 (UTC)[reply]
Here is the table I had in mind for point 6: https://commons.wikimedia.org/wiki/Data:Lower_and_upper_houses_of_eu_member_states.tab Julius Schwarz (talk) 18:45, 30 March 2025 (UTC)[reply]
In real life, are you a politician? You just spent a lot of words in saying relatively little. So let me ask specific questions:
If there is no wikidata mechanism to determine which house is upper and which house is lower, choose one of these:
  1. we require |house=<house name>
    + this method does not require a separate tabular data file
    − we must error check against the house names that wikidata knows about
  2. we fetch upper/lower qids from Data:Seats_of_EU_national_parties_in_lower_and_upper_houses.tab
    + if that table is required elsewhere, no need to error check
    − if that commons .tab file is not required elsewhere, it now becomes required here
It seems to me that these modules should not rely on multiple data sources if at all possible. So, if point 7 can be satisfied by fetching its data from wikidata and requiring |house=<house name>, that would be best.
You assiduously avoided the Do these templates/module in point 7 have a name? question. What is the answer to that question?
You haven't actually said: for the composition bar, is it the number of party seats against the number of house seats?
Is the table in point 6 complete? Are there countries that have only one house? How do we distinguish between a unicameral country and missing data?
—Trappist the monk (talk) 19:13, 30 March 2025 (UTC)[reply]
Argh! On the other hand... a commons table like Data:Seats_of_EU_national_parties_in_lower_and_upper_houses.tab that holds all of the necessary data avoids the issue of inconsistency at wikidata. For example, Independent Democratic Serb Party (Q1261401) doesn't have color (P462) but instead has sRGB color hex triplet (P465). No doubt there are other inconsistencies. Like Denmark Democrats - Inger Støjberg (Q112677506) which lists two hex colors... Which of those do we use?
Given that, I'm thinking that I might change my position to: both the point 1 and point 7 modules shall require the commons tabular data file that shall hold verified qids for those items that should be held in wikidata: seats occupied, number of seats in the party, etc – the periodically changing stuff. House names, party color, etc, stuff that rarely changes can be held in the tabular data file so that wikidata inconsistencies are avoided.
—Trappist the monk (talk) 19:49, 30 March 2025 (UTC)[reply]
Hmm, I am reluctant to put too much in tabular data file, specifically to avoid things changing that would then need to be updated in that table, and I keep all that information updated: what if a party changes its colour? what if the name of a house changes? What I want to keep in that table (and what I can keep updated) is what national parties belongs to which European party (and locally, I have an easy was to assign the lower/upper house and their qid based on the country in question).
As to having a way to determine which house is lower and which is upper, I am sure I understand what this is for. Say you have the template in the infobox of a party; you call that template saying "lower-house". From the page of the party, you derive the party's qid, from that qid you vlookup the table to find the qid of the lower house in the tabular data, then you can place a call to wikidata to get the number of seats of that party in the lower house, and to get the total number of seats of that house. I am actively avoiding needing to add arguments in order to make the template copy-pastable, and I am not sure we can directly derive the lower house and the upper house just from the wikidata page of a country (as some will directly list upper/house, while other will point to the name of the bicameral parliament, which in turn will point to both houses).
Inconsistencies? I will go through all relevant parties, as indicated in point 5 (had not thought of missing P465, but I can make sure they exist) for all relevant parties. Likewise, I made the table of upper/lower houses and made sure it is complete and accurate; where this is no upper house, the legislative is unicameral.
Names of the modules in point 7 and 8? I don't know. Module: "Seats of EU national parties", something to that affect? Julius Schwarz (talk) 20:52, 30 March 2025 (UTC)[reply]

There may be a way to distinguish upper from lower in wikidata if the descriptions can be more-or-less normalized. Here is a list taken from the point 6 tabular data file. You can see that there is rather a large amount of variation amongst these descriptions – more of what I was saying about wikidata inconsistency. Of course these could all be normalized to some degree and then along comes Joe Editor who tweaks his country's description and the whole mess falls apart.

description from wikidata

I have, I think noodled out how to get colors. Some parties list both color (P462) and sRGB color hex triplet (P465) so when that occurs, I have elected to use the P465 triplet because that seems more 'precise'?

—Trappist the monk (talk) 00:59, 31 March 2025 (UTC)[reply]

I would agree with your assessment, whenever P465 is there, that's the better choice. As I said, I will try and ensure that it is there wherever possible.
As for the upper/lower house distinction from Wikidata, I am still unsure as to why you think you need this. Take Christian Social Union in Bavaria, for instance. Currently, the infobox contains reads, for the Bundestag, currently, the infobox, for the Bundestag seats, reads as follows: {{composition bar|44|100|hex={{party color|Christian Social Union of Bavaria}}|border=silver}}. I am suggesting to replace this with {{Seats of EU national parties|house=lower-house}}. The template would grab the CSU's qID, look up its jurisdiction, and then, from the tabular data from point 6 or from the config file, would derive the qID of the Bundestag and give out the composition bar. I understand your point of limiting the use of multiple data sources, but as you point out Wikidata is not consistent in its descriptions. And, at any rate, we would still need the template to be told whether we need upper or lower house seats, so I am unsure why you are trying to grab that information from Wikidata when we have an easy way to get the house's qid easily. Julius Schwarz (talk) 07:13, 31 March 2025 (UTC)[reply]
To limit the number of data sources. Since it is necessary to fetch total number of seats in a house and the numbers of seats occupied by the various parties from wikidata, it seems to me that we should fetch as much data as possible from wikidata rather than have two separate sources. Other editors are going to maintain the wikidata data but who will maintain the commons tabular data? You? What happens when you open your door, step out, and are suddenly flattened by a steamroller?
Currently there are four sources of data for Module:Sandbox/Julius Schwarz/EU party seats lower upper houses: wikidata, the wide tab file, the narrow tab file, and ~/config. Are all four really required? Numbers of seat and the numbers of the various occupants will periodically change so wikidata is required. Do we really need both the wide and the narrow tab files? It seems that all of the data in the narrow tab file is or in a future incarnation will exist in the wide tab file, so if a tab file is required, only one will be needed. Because data for these modules will be sourced from wikidata and perhaps a tab file, ~/config should not hold anything more than whatever is required for i18n.
Looking at what the point 1 module already does, tell me again what it is the the point 7 module will do differently?
—Trappist the monk (talk) 17:20, 31 March 2025 (UTC)[reply]
In the meantime, I managed to make substantial progress on the module of point 1. I can now get the number of seats of European parties' member parties, both for an actual party and using "all" -- at least based on this small test table.
However, the composition_bar function, which used to work when only grabbing the data from the test table, no longer works when trying to get the total number of seats of all lower houses (for instance) using the table made in point 6. Somehow get_house_seats returns a string, but I cannot see why.
Looking forward, I am not quite sure how to grab the qID of the relevant European party when the module is called with "this party" instead of a party name.
Any ideas? Julius Schwarz (talk) 12:09, 31 March 2025 (UTC)[reply]
The call to sum_house_seats() looked like this:
local sum_house_seats = sum_house_seats(frame, european_party_name, house_type);
but the function definition looked like this:
local function sum_house_seats(frame, house_type)
house_type was getting its value from european_party_name so the code to get house_qid was bypassed. The default state of house_qid was empty string. When given an empty-string qid, {{wikidata}} returns an empty string; you can't add an empty string to a number.
The third entry in c:Data:Lower and upper houses of eu member states.tab does not have an upper house so the code at lines 126–131 returns a nil value for house_qid. When given a nil qid, {{wikidata}} returns an empty string; you can't add an empty string to a number.
I changed that function so that any nil house_qid skips the call to {{wikidata}} and the function returns the number zero.
To get the qid for the current page:
local this_page_qid = mw.wikibase.getEntityIdForCurrentPage();
—Trappist the monk (talk) 17:20, 31 March 2025 (UTC)[reply]
Aaaaahhhhh, thanks, I had missed that. Made some changes and I must have forgotten to remove that argument. And thanks for the qID of the current page, I will try and add that tomorrow and then work on some test cases and validation. Julius Schwarz (talk) 20:11, 31 March 2025 (UTC)[reply]
Aaaand once again, made progress, even added support for "thisparty" which works when called from page of a European party, but I get an error in the test cases and I am not finding it... Julius Schwarz (talk) 14:16, 1 April 2025 (UTC)[reply]
Aaand I just broke it even further before having to stop working... Julius Schwarz (talk) 16:29, 1 April 2025 (UTC)[reply]
(edit conflict)
You've changed the module (and this page) since I began writing this response.
This is the first failure that I see saw listed under Module talk:Sandbox/Julius Schwarz/EU party seats lower upper houses/testcases § test main:
{{#invoke:Sandbox/Julius Schwarz/EU party seats lower upper houses|main|ALL|lower-house}} → Script error: No such module "Sandbox/Julius Schwarz/EU party seats lower upper houses".
Clearly, that works worked (it returned 406). There are four of these tests that differ only in the casing of the ALL, All, all (2×). At the bottom of ~/testcases is the hidden category Category:Pages with too many expensive parser function calls. When the expensive error counter exceeds the limit (500), get_party_seats() returns this error message (a string) instead of a numeric value:
Lua error in Module:Sandbox/Julius_Schwarz/EU_party_seats_lower_upper_ho at line 185: <strong class="error"><span class="scribunto-error mw-scribunto-error-449e5552">Lua error: too many expensive function calls.</span></strong>
The simple fix then ought to be the removal of test cases that are substantially the same.
—Trappist the monk (talk) 17:00, 1 April 2025 (UTC)[reply]
Thanks and, indeed, it used to work. However, I removed a whole bunch of test cases (had not considered the load, and actually maybe we can remove the option to quiz all, that might just be too much when the table is complete). However, the error is still there, it would seem. The last thing I did was to introduce to that "error house name" to try and figure out where things broke, but did not find the solution. Julius Schwarz (talk) 21:02, 1 April 2025 (UTC)[reply]
Preview ~/testcases with this version of the module. The expensive parser function count no longer exceeds the limit (371/500).
Are ms-lower-house and ms-upper-house accepted parameter values but lower-house and upper-house are not? You are not checking for those so the tests that set the 'house' parameter to either of those values fail with 'error house name'. If the test for house_type is supposed to be the same for both main() and composition_bar(), you should probably make that test a simple function.
—Trappist the monk (talk) 22:04, 1 April 2025 (UTC)[reply]
The idea was as follows: since the testing on whether the house type is lower or upper house is always done with "lower-house" or "upper-house", I would not touch them and instead just to rename house_type to, for instance, "lower-house" if "lower" or "ms-lower-house" was entered. This way all three values would be accepted. I am actually not sure I understand what does not work with the present code (just like I don't really get why it impact main and not composition_bar even though it's the same code in both), but I try and make this a separate function indeed. Julius Schwarz (talk) 06:23, 2 April 2025 (UTC)[reply]
Seems fixed. I guess the issue was not to have an "else". Julius Schwarz (talk) 07:53, 2 April 2025 (UTC)[reply]
Important note, the module is now integrated into Module:EUPP seats/sandbox, which is were further changes should be made.
@Trappist the monk, I will add missing comments in the code. Could you kindly have a look to see whether things are well done and/or whether anything can make the code more efficient? Julius Schwarz (talk) 12:12, 2 April 2025 (UTC)[reply]
I have done some rewriting:
  • Module:Tabular data no longer used in favor of fetching data directly from tab_data_t and ms_data_t. Those sequences were previously used only as loop counters. See get_house_seats(), get_national_party_seats(), and sum_national_party_seats().
  • to support direct access of data in tab_data_t and ms_data_t, I created a function build_tab_data() in Module:EUPP_seats/config. This function creates a sequence of associative arrays where the appropriate column name indexes the row's data field.
  • I deleted the function table.find(). Its functionality is replaced by invert_party_qid_map() in Module:EUPP_seats/config. This avoids repeatedly looping through cfg.parties_t looking for 'this whatever's qid'. See validate_party_house_type() and sum_national_party_seats().
—Trappist the monk (talk) 20:03, 2 April 2025 (UTC)[reply]
Fantastic! I was really glad it worked, but I did have a hunch things could be done better :) Thank you! Julius Schwarz (talk) 20:17, 2 April 2025 (UTC)[reply]

Point 3 (ex-point 7)

[edit]

I see that the discussion on the second module got lost in the error corrections of the first module. Now that the first module is nearing completion (and is integrated in Module:EUPP seats/sandbox), I would be happy to re-open this discussion, @Trappist the monk.

One of your last question (that I left unanswered) was what the second module (now point 3.1) would do differently from the first. Both actually have a different focus:

  • the first module aims at being called from the page of a European political party and to sum the members on lower/upper houses of its national member parties; since the calculation is different from our previous Module:EUPP seats, I thought of keeping both separate, but then I figured it might make more sense to merge them;
  • the second module aims at being called from the page of a national political parties and just grab its number of seats on lower/upper houses from Wikidata (a bit what Module:EUPP seats initially did for European parties, but at the national level); to me the idea of this is to try and move as much data to Wikidata and to encourage anyone seeking to update data on Wikipedia to actually do so on Wikidata instead.

Is that clearer like this?

PS: I added a function in the roadmap -- sometimes it would be useful to override the total number of seats in the composition bar (for cases where we would want to give out the number of seats of sub-group of the house, instead of the whole house). Julius Schwarz (talk) 14:01, 2 April 2025 (UTC)[reply]

Also, @Trappist the monk do you confirm that you wish to discontinue the use of the "narrow" tab file and only extract data from the "wide" tab file? I can see how this limits the number of files we use, but is that efficient? It's a genuine question. The narrow one makes it straightfoward to count the total number of seats on lower or upper houses (without counting anything twice). If there is a way to make it as efficient (or nearly) with one file, that is of course fine by me. And, indeed, it is likely that the information from the narrow one will be in the wide one -- this would not be the case if, for instance, a member state had none of its national parties that a is a member of a European party; it could happen, but in practice it doesn't. Julius Schwarz (talk) 07:40, 3 April 2025 (UTC)[reply]
The narrow commons file is no longer required. I have added a function to Module:EUPP seats/config, extract_ms_data(), that extracts the necessary data from the data extracted from the wide tab file. So long as the multiple copies of each member_state row in the wide tab are all the same, the data for lower_house, lower_house_qid, upper_house, and upper_house_qid in the new ms_tab_t sequence should be correct (the new function takes only the row of data from the first encounter of a member state). Some of those data are not currently used: member_state, lower_house, and upper_house could be excluded from the new ms_tab_t sequence.
—Trappist the monk (talk) 01:04, 4 April 2025 (UTC)[reply]
This last point means removing member_state = row_t.member_state, and the two other similar lines from extract_ms_data in the config file, right? Julius Schwarz (talk) 09:12, 4 April 2025 (UTC)[reply]
Or not. If there will be a need for those then you should leave them in; if not, delete of comment out.
—Trappist the monk (talk) 13:58, 4 April 2025 (UTC)[reply]
I will try and get started on this module tomorrow or the day after. Julius Schwarz (talk) 15:51, 6 April 2025 (UTC)[reply]
@Trappist the monk I have done some work on the national_party_composition_bar function and it seems to be working (although test cases are tricky because it is always called from the page of a national party). Would you mind having a look and checking whether the code is sound? I have tried it successfully on The Ecologists and on a non-party page where, expectedly, it gives an error message. Julius Schwarz (talk) 19:48, 7 April 2025 (UTC)[reply]
Seems like there is some commonality between composition_bar() and national_party_composition_bar(). Perhaps parts of those function that can be shared ought to be shared as separate functions.
—Trappist the monk (talk) 22:07, 7 April 2025 (UTC)[reply]
They are close and do related things, but they operate differently, as the first one applies to all institutions but only for the European parties/alliances listed in the config file, while the other only works for lower/upper houses (therefore a different validation mechanism) and for all parties listed in the wide table. It's close, but, given the differences, I do not know whether we truly gain from trying to force a unique function that would have to be implemented in different ways. Just my two cents as things stand and happy to be proven wrong :) Julius Schwarz (talk) 07:17, 8 April 2025 (UTC)[reply]
@Trappist the monk Anything else to consider before we deploy the sandbox to the main module? Julius Schwarz (talk) 14:00, 8 April 2025 (UTC)[reply]
Almost always. The problem is in knowing what to consider. That lack of knowledge hasn't stopped you from deploying this module in the past, why worry about it now? If doing so breaks stuff, you'll know it soon enough.
—Trappist the monk (talk) 14:16, 8 April 2025 (UTC)[reply]
Maybe I'm trying to learn from my mistakes and referring to a higher authority to be more careful? Julius Schwarz (talk) 14:38, 8 April 2025 (UTC)[reply]

Adding support for European political alliances

[edit]

Hi @Trappist the monk, I added European political alliances in the config file. However, I then made changes to the module (seemed like a quick fix) but, I must have forgotten something, because it broke the non-party calls (misc_parties_t and keywords_t). Basically, European political alliances should work just like European political parties but should not count in the sum of seats occupied by all European parties ('all') and therefore also not in the sum of seats occupied by no European party ('none'); but should be able to get their number of seats and derive a composition bar. Julius Schwarz (talk) 15:20, 3 April 2025 (UTC)[reply]

Some of the problem was resolved by exporting alliances_t from ~/config. I fixed most of the other glaring red error messages. One that I didn't fix was this from one of the testcases pages:
{{#invoke:EUPP seats/sandbox|main|EP||%}} → Script error: No such module "EUPP seats/sandbox".
That used to work (produced the 'party is required for share' error message). I leave it to you to figure out what it is that you did to break it.
—Trappist the monk (talk) 17:05, 3 April 2025 (UTC)[reply]
Oh, and, I first made these changes to the live module; I should not have done that. I have reverted the changes in the live module and made them in the sandbox because that is what sandboxen are for.
—Trappist the monk (talk) 17:15, 3 April 2025 (UTC)[reply]
Thanks @Trappist the monk; is it perhaps possible that I changed an "if ... else..." into an "if ... elseif ... elseif..." (where the double elseif was aimed at separating cfg.parties_t from cfg.alliances_t) but that, in doing so, the other cases (everything else caught by "else") was not accounted for? I am having a look here and am looking at line 160 (old version). Julius Schwarz (talk) 20:35, 3 April 2025 (UTC)[reply]
Could well be. In the current live version, args_t ends up as {'property', nil, 'P1410'} which causes the call to expand {{wikidata}} to return an empty string. Perhaps the thing to do is to add this at line 154: 
	elseif not party then														-- <party> missing
		return	make_error_msg (substitute (cfg.error_messages_t.party_req_share));
	else																		-- <party> unknown
		return  make_error_msg (substitute (cfg.error_messages_t.inst_unknown_party, {institution, party}));
Current lines 161–164 go away as redundant.
I gotta wonder: is that the correct error message? single() is called twice: from seats() (currently line 222) and from seats_share() (currently line 260). Certainly the ...required for share bit is required for seats_share() but for seats()?
—Trappist the monk (talk) 22:03, 3 April 2025 (UTC)[reply]
It would seem like the errors are just due to too many calls, maybe? I made a separate testcase page just for composition bars and it all seems to work well. Julius Schwarz (talk) 08:19, 4 April 2025 (UTC)[reply]
As for the error message, it is to cover calls like this one {{#invoke:EUPP seats/sandbox|main|EP||%}}. Julius Schwarz (talk) 08:27, 4 April 2025 (UTC)[reply]
Really, just that? Then perhaps that error message should be moved to seats_share() right at the top; something like this: 
	if not party then															-- party not specified, abandon with error message
		return	make_error_msg (substitute (cfg.error_messages_t.party_req_share));
	end
no point in doing all of the work in seats_share() only to have single() return an error message because a required element was missing.
—Trappist the monk (talk) 14:40, 4 April 2025 (UTC)[reply]
At Module talk:EUPP seats/sandbox/testcases composition bar, not a single test passes. I gotta wonder if there is sommat wrong with Module:UnitTests. If I tweak the first test so that the numbers match (which in itself suggests that Module:EUPP seats/sandbox isn't working correctly). Then if the two outputs match I should get 'same':
{{#ifeq:{{#invoke:EUPP seats/sandbox|composition_bar|EP|ALDE}}|{{Composition bar|49|720|hex=#FFD700}}|same|not same}} → not same
and I do. Something about Module:UnitTests is not working correctly. That still leaves questions about the testcases:
  • is Module:EUPP seats/sandbox working correctly when it produces numbers that are different from the expected numbers?
  • are the expected numbers correct?
  • what about the tests that show different colors? which is correct?
As an experiment, I edited Module:EUPP seats/sandbox/testcases composition bar so that the first test expected and actual were the same:
self:preprocess_equals('{{#invoke:EUPP seats/sandbox|composition_bar|EP|ALDE}}', '{{#invoke:EUPP seats/sandbox|composition_bar|EP|ALDE}}')
Module:UnitTests still thinks that the test fails.
—Trappist the monk (talk) 14:40, 4 April 2025 (UTC)[reply]
I made changes here and there to the test, varying the party, etc., without always warying the colour for instance, so there are normal discrepancies. However, even when the bars exactly match the result of the test is shown as negative, it's always been like this for me.
More worryingly, though, all the composition bars are broken, even in the main module, the one that worked an hour ago (haven't touched it since). Check European Green Party for instance Julius Schwarz (talk) 14:52, 4 April 2025 (UTC)[reply]
The error is always "Lua error in Module:EUPP_seats/config at line 151: table index is nil." Julius Schwarz (talk) 14:54, 4 April 2025 (UTC)[reply]
Why does the last row of c:Data:Seats of EU national parties in lower and upper houses.tab hold only 'null' values. Delete that row and I expect that European Green Party will stop showing the glaring red error messages. You did just edit that table, right?
—Trappist the monk (talk) 15:15, 4 April 2025 (UTC)[reply]
You were right, that was the issues. Turns out it's something that is added when importing a csv file. Would it be possible for the function to account for that and to simply ignore a line that has no european_party? Julius Schwarz (talk) 18:41, 4 April 2025 (UTC)[reply]
When testing the output of a template or module against the output of another template or module, you need to use preprocess_equals_preprocess. When that test is used, this test passes:
self:preprocess_equals_preprocess('{{#invoke:EUPP seats/sandbox|composition_bar|EP|ALDE}}', '{{#invoke:EUPP seats/sandbox|composition_bar|EP|ALDE}}')
preprocess_equals fails because the test is comparing the preprocessed output of the #invoke against the plain wikitext of the expected template. This:
<strong class="error"><span class="scribunto-error mw-scribunto-error-24c2d55e">Script error: No such module &quot;EUPP seats/sandbox&quot;.</span></strong>
does not equal this:
{{#invoke:EUPP seats/sandbox|composition_bar|EP|ALDE}}
—Trappist the monk (talk) 17:03, 4 April 2025 (UTC)[reply]
Just changed it, thanks! Julius Schwarz (talk) 17:53, 4 April 2025 (UTC)[reply]

Error for two European parties

[edit]

As I add data to the wide table, I implement the "EUPP composition bar" template on the relevant pages of European parties, by adding {{EUPP composition bar|ms-upper-house|thisparty|width=80%|percent=yes}} in the infobox (see European Green Party for instance).

So far, it has been very smooth. However, for the Party of the European Left and European People's Party, it gives out "Lua error in Module:EUPP_seats at line 437: attempt to perform arithmetic on a string value", in both cases just for the upper house. Any ideas? I checked the data and it seems in order. Julius Schwarz (talk) 12:43, 4 April 2025 (UTC)[reply]

Ok, the other issue is fixed. Any clue about this, @Trappist the monk? Julius Schwarz (talk) 17:55, 4 April 2025 (UTC)[reply]
I think that I have tracked it to Levice (Q1315362). If I write these templates (takes Module:EUPP_seats/sandbox out of the loop) I get unexpected results for the upper house:
lower house: {{wikidata|property|Q1315362|P1410|P194=Q320265}} → 0 – a number so that's ok
upper house: {{wikidata|property|Q1315362|P1410|P194=Q389423}} → 0 – (apparently empty string) not a number so not ok
Q1315362 property number of seats in assembly (P1410) has 'issues' so perhaps fixing those will fix the problem.
—Trappist the monk (talk) 19:03, 4 April 2025 (UTC)[reply]
Yes, I also commented out and back in some entries for the ESN and identified the AfD as the one responsible. But in that case, it's because the entry was indeed empty. I fixed it and it works. Would there be a way to replace a missing entry with a zero but to record that somewhere? The issue here is that the Bundesrat is filled by State-level coalitions and the coalition seemingly decides together, meaning the seats aren't directly attributed to specific parties. So, on the one hand we would need to account for the Bundesrat, but on the other we can't directly link one seat to a party. It's easy for parties that are not in present at all in the coalitions (then it's 0), but not for the rest. Julius Schwarz (talk) 20:43, 4 April 2025 (UTC)[reply]
Turns out Levice was also just simply missing its upper house entry, but for no good reason. Currently, the reason above only affects the EPP (so my changes are pending), but that's because other German parties have 0 as a number of seats for the Bundesrat, but erroneously so. A proposal: we mute the error by replacing a missing value with 0, but we make a test function that would allow me to keep an eye on missing issue and that would report the parties with missing values. Julius Schwarz (talk) 20:51, 4 April 2025 (UTC)[reply]
Created {{#invoke:EUPP seats|test_wikidata_entries}} for this purpose. Seems to work.
Currently: {{#invoke:EUPP seats|test_wikidata_entries}} -> Script error: No such module "EUPP seats". Julius Schwarz (talk) 11:57, 6 April 2025 (UTC)[reply]

Capitalisation

[edit]

Since it may be that some party/alliance names are not capitalised in the table (and I do not want to force this), I wanted to make sure that, when we compare a requested European party (from the argument) with the entries of the first column, we compare to the capitalised version of the entries (because we force the capitalisation of the arguments.

I tried changing:

if european_party == cfg.tab_data_t[row]['european_party'] then

into:

if european_party == cfg.tab_data_t[row]['european_party']:upper() then

or

if european_party == string.upper(cfg.tab_data_t[row]['european_party']) then

but that did not work. Any idea why? Julius Schwarz (talk) 08:28, 6 April 2025 (UTC)[reply]

I thought I had fixed it -- see latest changes to Module:EUPP seats/sandbox, also deployed to Module:EUPP seats. And when I test both on my own sandbox (User:Julius Schwarz/sandbox), it works. But from Patriots.eu, it doens't work. What am I missing, @Trappist the monk? Julius Schwarz (talk) 11:55, 6 April 2025 (UTC)[reply]
Not obvious that lines 444–447 execute when the module is called from Patriots.eu.
Both of cfg.tab_data_t[row]['european_party']:upper() and string.upper(cfg.tab_data_t[row]['european_party'] work to upcase the value assigned to european_party. But is that code necessary or appropriate? Oughtn't you to be checking that with test_wikidata_entries() rather than upcasing cfg.tab_data_t[row]['european_party'] for every row in the loop?
—Trappist the monk (talk) 12:47, 6 April 2025 (UTC)[reply]
Not sure how test_wikidata_entries can help here -- it is just supposed to find issues in Wikidata itself. Here I just want the european_party under consideration to match the tabular data, whether the table has "PATRIOTS" or "Patriots" in the first column. Since the european_party is always capitalised, I was thinking of doing the if test with the capitalised version of the table cell value. And it does work well in the test (I added a non-capitalised version line at the bottom of the tabular data). Julius Schwarz (talk) 13:02, 6 April 2025 (UTC)[reply]
test_wikidata_entries() can ensure that all of the names listed under the european_party heading in the wide table are written using the correct case. That way you don't have to upcase cfg.tab_data_t[row]['european_party'] every time you need that name. test_wikidata_entries() is really a cross-checking function; if there is an error in tested qids in the wide table, there is some chance that the function will catch that error. If you are going to establish a requirement that all parties named in the european_party column are uppercase, it makes sense to test those party names to ensure compliance with the requirement. The user should be able to write patriots, PATRIOTS, or anything in between; Module:EUPP seats will accommodate those variations because it only needs to do it once per template. That is better than doing it 265 times per template.
it does work well in the test but from Patriots.eu, it doens't work. What was the test? How do you know that from Patriots.eu, it doens't work? These seem contradictory to me.
—Trappist the monk (talk) 14:04, 6 April 2025 (UTC)[reply]
But I am not establishing a requirement that all names in the first column be capitalised. Most are because they are acronyms, but others (Patriots, DiEM25, Volt, etc.) are not -- well, I capitalised them temporarily so that it would work, but that is just a temporary fix. We all people to call the module/templates with "Patriots" or "PaTrIoTs" and I think we should keep that fleibility in the table, because someone is bound not to respect the capitalisation, starting with me, since the initial table that I have should not have everything capitalised.
As for the last question, when I call {{#invoke:EUPP seats|composition_bar|ms-lower-house|Patriots}} or {{EUPP composition bar|ms-lower-house|Patriots}} from my user sandbox, it works (it finds 734 seats (which accounts for the redundant last line of the table). However, when calling {{EUPP composition bar|ms-lower-house|thisparty}} from the page Patriots.eu, it gives 608 (which does not include the last line of the table, which is not capitalised. Julius Schwarz (talk) 14:30, 6 April 2025 (UTC)[reply]
OR maybe we can force uppercase for the first column when we import the table via the config function? Julius Schwarz (talk) 14:55, 6 April 2025 (UTC)[reply]
(edit conflict)
As you wish.
{{EUPP composition bar|ms-lower-house|Patriots}} doesn't 'work' because in lines 436–442, you do not do the upcasing thing.
Alternate solution: Because we copy the tabular data file into a lua sequence, we can, as we read the data, upcase european_party. Add this at line 123:
row_data_t.european_party = row_data_t.european_party:upper(); -- ensure <european_party> values are always uppercase
Do nothing else; then look at Patriots.eu.
—Trappist the monk (talk) 14:59, 6 April 2025 (UTC)[reply]
That's perfect! And I guess in the same way, we would skip an empty line (perhaps by just testing on whether the first column is empty, which it should never be)? Julius Schwarz (talk) 15:46, 6 April 2025 (UTC)[reply]
If the first column is empty, which it should never be, I don't think you want to skip it. You should allow the module to shout an error (as it did when the whole bottom row was empty) because sommat is seriously wrong and needs urgent attention.
—Trappist the monk (talk) 16:02, 6 April 2025 (UTC)[reply]
Yeah, that's a good point. Any recommendation for an entirely empty line? Julius Schwarz (talk) 16:44, 6 April 2025 (UTC)[reply]
I would like to avoid that crashing all the pages where the module is used.. Julius Schwarz (talk) 16:44, 6 April 2025 (UTC)[reply]
You could add a null_row export and then as part of build_tab_data(), test each row for all-nil values. If any whole row is nil, set null_row to some value – boolean true, the row number, an error message, etc. Then, in Module:EUPP seats, look at cfg.null_row. If set do something about it.
This idea not tested.
—Trappist the monk (talk) 18:00, 6 April 2025 (UTC)[reply]

Error in mobile app

[edit]

@Trappist the monk, in my browser, all the composition bars on the pages of European parties work. On the Android mobile app, however, several pages show error messages relating to the config file (for instance, Animal Politics EU and European Green Party, but not the European People's Party).

Screenshot error module EUPP seats in Android mobile app

Julius Schwarz (talk) 07:47, 7 April 2025 (UTC)[reply]

Caching problem? What happens if you purge the page? Does that android device have a browser option? Do the errors appear when viewed with the device's browser? That's about all the help that I can offer because I don't have an android device. I don't see the errors when viewing Animal Politics EU and European Green Party on my iphone.
—Trappist the monk (talk) 11:31, 7 April 2025 (UTC)[reply]
Thanks @Trappist the monk. I will check the cache and yes it does work from the browser of the same phone. On a separately topic, I note that the module does not work for European political alliances when called with "thisparty", I guess the check is only done on the party table. Unfortunately, I can't check this now, would it be possible for you to have a quick look? PS: data gathering on all national parties is now done and I am working on the "second module". Julius Schwarz (talk) 12:43, 7 April 2025 (UTC)[reply]
Link to someplace that doesn't work? What template specifically doesn't work?
—Trappist the monk (talk) 12:55, 7 April 2025 (UTC)[reply]
Sorry, you can take European Pirate Party as an example. You will see in the infobox that figures for upper and lower houses are 0 -- this is not in line with the same calls (but using "PPEU" instead of "thisparty" on my own sandbox. Same for ECA or Volt. Julius Schwarz (talk) 14:23, 7 April 2025 (UTC)[reply]
Maybe line 438; it seems like we try and find "thisparty" only in the list of parties, but not in the list of alliances. Julius Schwarz (talk) 14:30, 7 April 2025 (UTC)[reply]
Dunno whether that was the best way, but I found a quick fix. Julius Schwarz (talk) 14:42, 7 April 2025 (UTC)[reply]
Thanks, I actually almost tried that but wasn't sure it'd work :) Julius Schwarz (talk) 14:58, 7 April 2025 (UTC)[reply]
(edit conflict)
Simplified some. That code should work. Will sum_national_party_seats() ever be called without a party? If so, some sort of error trapping or default value will be needed.
—Trappist the monk (talk) 15:02, 7 April 2025 (UTC)[reply]
It should not, no. Because it is only called internally, and it seems always after one of the two party validations functions are called. So if the party given in argument is not really a party, then there should be an error message before it reached that function. Julius Schwarz (talk) 18:44, 7 April 2025 (UTC)[reply]

Double error message

[edit]

@Trappist the monk, error messages in the two testcases pages (Module talk:EUPP seats/sandbox/testcases and Module talk:EUPP seats/sandbox/testcases composition bar) seem to nest two error messages. For instance 

Error: Error: {{EUPP composition bar}}: institution is required (help): unknown party: TEST (help)

where the "institution is required" message seems nested between the first "error" and "unknown party: TEST". Julius Schwarz (talk) 16:11, 8 April 2025 (UTC)[reply]

Doesn't seem to happen in the examples of Module:EUPP seats/sandbox, though. Julius Schwarz (talk) 16:31, 8 April 2025 (UTC)[reply]
The institution is required bit suggests that an empty template is processed by mediawiki after the error message is created by the module which would explain why the institution is required error appears within the unknown party: TEST error message. I'm not sure of the exact mechanism, nor if the issue has something to do with Module:UnitTests or with MediaWiki
{{EUPP seats}} → Template:EUPP seats
A fix might be made to the {{$1}} bit of the error message at line 29. Perhaps change one of the { to &#x7B;:
return substitute ('<span style="color:#d33">Error: &#x7B;{$1}}: $2 ([[:Template:$1|$3]])</span>$4',
—Trappist the monk (talk) 17:44, 8 April 2025 (UTC)[reply]
Thanks. I can't say that I would have ever figured that one out... Julius Schwarz (talk) 19:10, 8 April 2025 (UTC)[reply]

SPARQL query

[edit]

Any chance you are also familiar with Sparql queries, @Trappist the monk? ;)

I am trying to list all national parties that are members of a European party and whose country is a member of the European Union. That much I have. However, I also want to display their number of seats in the European Parliament (but it should not be a requirement to have such an entry).

So far, I have: 

SELECT ?item ?itemLabel ?countryLabel ?seats
WHERE {
  ?item wdt:P463 [wdt:P31 wd:Q24649]; #member of an instance of European party
        wdt:P17 [wdt:P463 wd:Q458]; #from a country that is a member of the European Union
        wdt:P17 ?country;
        OPTIONAL { ?item p:P1410 [ps:P1410 ?seats; pq:P1410 wdt:Q8889]. }
  SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en-gb". }  } 
ORDER BY ?countryLabel ?itemLabel

The OPTIONAL line is what doesn't work as it yields an empty column. Julius Schwarz (talk) 12:02, 9 April 2025 (UTC)[reply]

No experience with database queries. Does the dot after wdt:Q8889] have meaning? What about the dot after en-gb"? For that matter, what about the semicolons?
I see that you have also asked this question at WP:VPT § SPARQL query. If you don't get an answer there, surely someone at Wikidata will know the answer.
—Trappist the monk (talk) 13:40, 9 April 2025 (UTC)[reply]
Thanks, and fingers crossed! Julius Schwarz (talk) 14:39, 9 April 2025 (UTC)[reply]

The time allocated for running scripts has expired

[edit]

You should probably archive some of this page since it now exceeds the Expensive parser function count (886/500) and sometimes exceeds the Lua time usage limit (10 seconds).

—Trappist the monk (talk) 13:47, 9 April 2025 (UTC)[reply]

Done! Julius Schwarz (talk) 14:41, 9 April 2025 (UTC)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Module_talk:European_and_national_party_data/Archive_2&oldid=1286997190"