Talk:Performances
Items links
I'm wondering whether the "[… items]" links shouldn't say "[view … items]" instead, to make it more clear at-a-glance that you need to click on them to see more information. - dcljr (talk) 17:02, 14 August 2025 (UTC)
- I don't know: That would add a lot of dead text, but is a hint any user only needs to see once. It would cause more clutter, and on mobiles more lines to break. The blue color was chosen to represent a link, so I'd expect that most users would get that without further help. I did try different versions back then, also with added +/- signs in closed/open status, but in my mind that all made it look worse. How about adding a sentence of explanation in the introduction section instead? Like "The data rows are shown after clicking/touching the number of items indications."? Also, I consider to add an option that small tables, like the setlist in the [Christmas tour 2017] article, could by default be expanded. Observing those open tables could act as a further hint that these header lines top collapsed sections. -Most2dot0 (talk) 19:35, 14 August 2025 (UTC)
Case in article titles
As you can see in this edit, I've started to change the event names in Data:Performances.json to sentence case, as opposed to title case, since those are being used as article titles in the tables, and the convention is to use sentence case for that (and section headings, too, BTW). Even though technically any title (within technical limitations) can be redirected to a preferred version, we might as well keep them as close to acceptable page titles as possible in the data itself. - dcljr (talk) 00:16, 15 August 2025 (UTC)
- ok, I wasn't aware of that (sentence case for article items) -Most2dot0 (talk) 07:18, 15 August 2025 (UTC)
Repeated 'id's
The way ids are being formed in the tables is resulting in multiple instances of many of them. For example, id="Allsang_på_Grensen" appears 5 times on the rendered page (the HTML), once in the first table and 4 times in the "Events by year" table. This is not valid HTML. (There's also a blank table row in the first table, with id="". I'm pretty sure this isn't kosher, either. This is apparently being caused by char_limit1 not being specified.) Perhaps we should abandon the idea of having these three tables all on the same page, and instead put only "By event" and "By song" tables here (with the first formatted like the current first table but not limited to events that span multiple years, and the second exactly like the current third table — these can stay interlinked but with only a single target for each linked song title or event name). Then we can put tables like "Events by year" or "Songs by year", or whatever, on different pages, with the relevant sub-table links targeted to articles instead of anchors within the same page. Opinions? - dcljr (talk) 01:39, 15 August 2025 (UTC)
- Yes, that should work. But on the other hand, I think it's more beneficial to the users if a jump from the by-title listing leads to a events-by-year table, because it gives a better understanding of the context. The whole point of the events spanning multiple years page was to have in this case a jump target from the songs page to lead to a listing of all those songs to the events, not just the ones in the first year. I was fully aware that this was creating multiple identical IDs, I guess I just was not as concerned about that... So I guess the problem is, to come up with something that is both user friendly, and valid, not just working, html. BTW, r current version is lacking the contents section, making it combined with the longer intro less straightforward to reach the table. -Most2dot0 (talk) 07:37, 15 August 2025 (UTC)
- An idea would be, to include the year in the IDs of an Event in the event-by-year table, and of course in the by-title table linking to it, and generate in case of an event spanning multiple years either a navigation bar with entries for these other years, or a link to a table of(all) events-by-name. -Most2dot0 (talk) 07:55, 15 August 2025 (UTC)
- Since I don't do Lua coding, I don't really know what kinds of things are realistic to hope for. BTW, if you didn't already know, MediaWiki automatically numbers the ids of non-unique section headings — for example, duplicate "Events" sections would get ids "Events" and "Events_2" — but AFAIK that is only done with sections marked up in == the usual way ==.)
Regardless of what solution we come up with for this particular page, there are larger issues at play here (which I'm sure you are well aware of). Since they have more to do with how the data is stored than how it's displayed here, I will start that discussion at Data talk:Performances.json. - dcljr (talk) 18:50, 16 August 2025 (UTC)- Lua is quite a capable programming language. Restrictions come rather from the wish to keep things modular, general purpose, and reusable. So while the module used is called "Performances", it in reality holds what I described in my database ideas as a "common generic list generator". I would prefer to keep it that way. What is configured as part of the configuration of the module function call inclucde are the data and headings displayed, see Module:Performances/doc for explainations. And basically, what is created is WikiMedia source text (not sure if there is a better term for that), so WikiMedia templates can be used there. As with [[<song>]] and {{d|<date>}} in the overview example for inner wiki links and dates. What is in the angle brackets ('<','>') is the field name of the data used in the JSON data file. The list (or actually table) generator also constructs a Wikimedia text table. I need to check exactly how it's being done (It's been a year...), but I think the ids are currently derived from the header lines content. At this place I do use some html (<nowiki></nowi>, but it might be possible to transfer that to Wikimedia text, if that would avoid id duplication in tables same as it does in section titles. However, that would only help with avoiding "illegal" html, it would not help in creatiing the correct id elsewhere to form a link. --Most2dot0 (talk) 09:01, 17 August 2025 (UTC)
- Since I don't do Lua coding, I don't really know what kinds of things are realistic to hope for. BTW, if you didn't already know, MediaWiki automatically numbers the ids of non-unique section headings — for example, duplicate "Events" sections would get ids "Events" and "Events_2" — but AFAIK that is only done with sections marked up in == the usual way ==.)
- An idea would be, to include the year in the IDs of an Event in the event-by-year table, and of course in the by-title table linking to it, and generate in case of an event spanning multiple years either a navigation bar with entries for these other years, or a link to a table of(all) events-by-name. -Most2dot0 (talk) 07:55, 15 August 2025 (UTC)
