User talk:Dcljr
For the record, the user leaving this comment (ajwikiadmin) and the user whose talk page this is (dcljr) are the same person. - ajwikiadmin (talk) 01:25, 12 August 2025 (UTC)
Feedback on new Performances prototype requested
Please have a look at User:Most2dot0/Performances-devel. I added a section describing the new features/solutions, and then there's the actual prototype after that. I'd like to know if you think this is a move in the right direction.
Please note, that the view/edit link to the JSON data are likely not correct (they would be for the final location of the table). The data used is here: User:Most2dot0/Performances.json-devel. --Most2dot0 (talk) 17:11, 1 September 2025 (UTC)
- Looks OK on first glance. I'm "very close" to fixing the underlying database problems that happened when I created the "Data" namespace before the job queue was empty (the redlinks issue is not just "cosmetic"). I'll look at what you've done more closely (and reply to other relevant talk page comments) after I've finished that. As usual, the wiki will be uneditable for some time while I'm actually working on that. Will give the usual prior notice, hopefully far enough in advance that I won't cause you any problems while you're actively working on something. - dcljr (talk) 14:41, 2 September 2025 (UTC)
- This version now uses the production data file Data:Performances.json, so my remark in the 2nd paragraph is no longer valid. I would still like your feedback on the "context" structure. --Most2dot0 (talk) 22:32, 17 September 2025 (UTC)
- I don't understand why things like "oc Kongsberg Jazz Festival 2022" are mixed in with the songs. I mean, in another field, sure, but not as a "song". (See, e.g., Performances#2014. [??]) Apart from that — and, again, at first glance — the context field seems OK. Although I would lower-case things like "concert", "cover", "guest appearance", etc., which aren't proper nouns (they can be capitalized in the output using ucfirst↗, if necessary — and, of course, if used as a page title, the capitalization of the first letter doesn't matter). I'm not seeing how the new "context" is behaving "in the wild", though. Can you point to a page where the effect of "context" is being seen? - dcljr (talk) 19:43, 18 September 2025 (UTC)
- Please have a look at User:Most2dot0/Performances-devel. I added a section describing the new features/solutions, and then there's the actual prototype after that. The context aliase was a quick hack, to see how pointing to a different context could work, the final solution could certainly be different. --Most2dot0 (talk) 20:43, 18 September 2025 (UTC)
- Ah, yes, of course: User:Most2dot0/Performances-devel. I'm afraid it's a bit overwhelming. Did you have specific questions? I would say it's going in the right direction, if that helps at all. There are some minor wording issues, like I would prefer "on set" to "at set" (sounds better to American ears, at least), and "with X" when she's not playing an instrument rather than "to X", and "on X" (or the more explicit "playing X") when she is playing the instrument. And I think many of these "5th-level" contexts would be better separated from the previous level(s) by a comma rather than just a space. Maybe all three of the "deeper" context levels should be separated by commas? Or would that be too difficult to avoid multiple commas in a row? (I guess a template or module could take care of that.) As for the actual structure you've chosen… I mean… OK. I might have some more ideas later on, but for now… sure. - dcljr (talk) 06:59, 19 September 2025 (UTC)
- I implemented the commas before the 5th level contexts. It would be no problem to do it before the 4th level as well. The ucfirst did not work, might be again the question when exactly that is applied --- it might work on the "<" of the computed field <context[5]> instead on its result. It should be easy to add that conversion to the computed field transformations instead, though. I substituted "with->playing" and "to->with". In regards to specific questions,e.g: (1) We have like before three tables, it's just that the first one is now covering all events instead of just those which span years. I still think that the "Events by year" table is in most cases more useful. Currently the songs table jumps to the "All events" table, though. It might make sense to jump to the "Events by year" table instead, then there is the escape via the "◁" to the "All events" table to find possible occurances in other years, would you agree? (2) Do we need external (page) links to the 5th level at all? Possibly we could also use that as an in-page anchor instead, e.g. "Kongsberg Jazz Festival 2016, Gulljazz" (
[[Kongsberg Jazz Festival]] [[Kongsberg Jazz Festival 2016|2016]], [[Kongsberg Jazz Festival 2016#Gulljazz|Gulljazz]]). Though in this case this wouldn't work properly, as the 2016 is already a redirect to an anchor. It would work well for like "7th Heaven" or "Million Miles if the page headings macht the database entries. (3) Should we try to add/integrate a "Songs by year" table in the jump sequence? BTW, there's a good reason to have it all on one page: if the embedded YouTube Player is used, it keeps playing when all the jumps are within the same page. — The preceding unsigned comment was posted by User:Most2dot0 at 19:56, 19 September 2025 (UTC)- Specific answers: (1) "Events by year" won't be useful if someone is looking for an event (or a kind of event) and doesn't know the year for it; "would you agree?": see third answer; (2) "do we need": probably not, especially if that makes things easier [grin]; (3) I'm not sure I see the great benefit to having all these tables on the same page. Why not put them on separate pages titled "Events" (where the song titles are linked to our song articles), "Events by year" (same), and "Performances by song title" (where the events are linked to event articles)? We could use one or more icons to provide "jump" links to other tables rather than using the text of the song title or event name. That would have the benefit of maintaining the idea that "linked text" = "go to article about this thing" (unless the link is marked as an external one↗). BTW, how often will someone be jumping between tables and want to keep playing a video? Would that really be so useful? - dcljr (talk) 07:21, 28 September 2025 (UTC)
- Luckily, we don't need to choose, we can have both separate and combinded listings. While the pages are big when rendered, they have small sources. So there is little issue with wasting space, as only the latest rendered version is stored. In regards to keeping a video playing, I have used this a lot when like researching similar performances or performances played at the same event, as it's a treat to listen to Angelina, so having a playlist keep playing until a new song is actively selected, is a blessing. In regards to context hierarchies, I also started to think about how they relate to wiki categories, and put down some ideas here. --Most2dot0 (talk) 18:21, 29 September 2025 (UTC)
- My concern is not with storage space but user expectations/experience. There are two issues here: the placement of the tables and the linking between them. I guess my primary concern is how we are linking between them. I don't think anyone would expect links on song titles and event names in one table to go to another table on the same page, especially when not all such links do that (links in the main tables, before any subtables are expanded, go to articles). Yes, people can learn which links do what, but they really shouldn't have to. Using an icon for inter-table links, like ↕ (if the tables are on the same page) or maybe something like ▤ (which would "work" wherever the tables are) ["hover" on the icons to see the explanation], would lessen the "cognitive cost" of using the tables (for users who can "hover") and, like I was saying, would preserve the expected behavior of normal text links. (Of course, the use of "title" attributes gives rise to accessibility/usability issues, but there may be a solution to that problem↗.) - dcljr (talk) 22:28, 29 September 2025 (UTC)
- Luckily, we don't need to choose, we can have both separate and combinded listings. While the pages are big when rendered, they have small sources. So there is little issue with wasting space, as only the latest rendered version is stored. In regards to keeping a video playing, I have used this a lot when like researching similar performances or performances played at the same event, as it's a treat to listen to Angelina, so having a playlist keep playing until a new song is actively selected, is a blessing. In regards to context hierarchies, I also started to think about how they relate to wiki categories, and put down some ideas here. --Most2dot0 (talk) 18:21, 29 September 2025 (UTC)
- Specific answers: (1) "Events by year" won't be useful if someone is looking for an event (or a kind of event) and doesn't know the year for it; "would you agree?": see third answer; (2) "do we need": probably not, especially if that makes things easier [grin]; (3) I'm not sure I see the great benefit to having all these tables on the same page. Why not put them on separate pages titled "Events" (where the song titles are linked to our song articles), "Events by year" (same), and "Performances by song title" (where the events are linked to event articles)? We could use one or more icons to provide "jump" links to other tables rather than using the text of the song title or event name. That would have the benefit of maintaining the idea that "linked text" = "go to article about this thing" (unless the link is marked as an external one↗). BTW, how often will someone be jumping between tables and want to keep playing a video? Would that really be so useful? - dcljr (talk) 07:21, 28 September 2025 (UTC)
- I implemented the commas before the 5th level contexts. It would be no problem to do it before the 4th level as well. The ucfirst did not work, might be again the question when exactly that is applied --- it might work on the "<" of the computed field <context[5]> instead on its result. It should be easy to add that conversion to the computed field transformations instead, though. I substituted "with->playing" and "to->with". In regards to specific questions,e.g: (1) We have like before three tables, it's just that the first one is now covering all events instead of just those which span years. I still think that the "Events by year" table is in most cases more useful. Currently the songs table jumps to the "All events" table, though. It might make sense to jump to the "Events by year" table instead, then there is the escape via the "◁" to the "All events" table to find possible occurances in other years, would you agree? (2) Do we need external (page) links to the 5th level at all? Possibly we could also use that as an in-page anchor instead, e.g. "Kongsberg Jazz Festival 2016, Gulljazz" (
- Ah, yes, of course: User:Most2dot0/Performances-devel. I'm afraid it's a bit overwhelming. Did you have specific questions? I would say it's going in the right direction, if that helps at all. There are some minor wording issues, like I would prefer "on set" to "at set" (sounds better to American ears, at least), and "with X" when she's not playing an instrument rather than "to X", and "on X" (or the more explicit "playing X") when she is playing the instrument. And I think many of these "5th-level" contexts would be better separated from the previous level(s) by a comma rather than just a space. Maybe all three of the "deeper" context levels should be separated by commas? Or would that be too difficult to avoid multiple commas in a row? (I guess a template or module could take care of that.) As for the actual structure you've chosen… I mean… OK. I might have some more ideas later on, but for now… sure. - dcljr (talk) 06:59, 19 September 2025 (UTC)
- Please have a look at User:Most2dot0/Performances-devel. I added a section describing the new features/solutions, and then there's the actual prototype after that. The context aliase was a quick hack, to see how pointing to a different context could work, the final solution could certainly be different. --Most2dot0 (talk) 20:43, 18 September 2025 (UTC)
- I don't understand why things like "oc Kongsberg Jazz Festival 2022" are mixed in with the songs. I mean, in another field, sure, but not as a "song". (See, e.g., Performances#2014. [??]) Apart from that — and, again, at first glance — the context field seems OK. Although I would lower-case things like "concert", "cover", "guest appearance", etc., which aren't proper nouns (they can be capitalized in the output using ucfirst↗, if necessary — and, of course, if used as a page title, the capitalization of the first letter doesn't matter). I'm not seeing how the new "context" is behaving "in the wild", though. Can you point to a page where the effect of "context" is being seen? - dcljr (talk) 19:43, 18 September 2025 (UTC)
- (continue above discussion with reduced indent level, to better work on mobile devices) I do understand the idea of "linked text" = "go to article about this thing"'. However, I don't think that is entirely true, even in the rest of the wiki, with links going (possibly with redirects) to specific sections of other articles or even within the same article. So I think the general idea is just "linked text" = "go somewhere where there is more related information about this", and that is valid for these tables, which list either other performances of the song, or other songs played at the event. But I don't have a big issue with doing it with some icons instead of full text links, though it might be slightly more difficult to hit those, which could also be a usibility concern. If we do with a two table setup, the 2nd table could be seen as sort of a footnote section, just with special formatting. I think I can showcase icons in the prototype within the next couple days. Also, when we move to Cargo we will have articles for all songs, which then hopefully even as a stub list (possibly with the help of Cargo, or simply because we use templates that both display and store the song information, it might not be an issue, because the song article would then contain the same basic information. You might have seen that I started to experiment with Ajax to realize an floating player that survives inter page jumps, which from my point of view would mitigate the negative effects of going to a different page. But that seems to be quite a complex effort, which would need a lot of careful testing. --Most2dot0 (talk) 12:03, 30 September 2025 (UTC)
- PS: I now edited the "All Events" table to point both to the article (via text) and to the other table (via icon). It seem like the tooltip does not work when uses in a linked text, though: possibly it gets overriden by the link placing the URL into the lower left of the window in toolip format. I didn't touch the Event/Context entries in the "All Songs" table, as this needs some more consideration how to treat the different levels. --Most2dot0 (talk) 20:10, 1 October 2025 (UTC)
- I created the three singular table pages you proposed, but for now in my "User:Most2dot0" namespace: User:Most2dot0/Events, User:Most2dot0/Events by year, and User:Most2dot0/Performances by song title. They are linked the same way together as the table combination on the User:Most2dot0/Performances-devel page. I am open for simplifications here, especially, if going forward, we will have song articles for each title soon. I don't see that for the events happening in the same pace, so the songs table should retain links to at least on of the events or events by year tables. --Most2dot0 (talk) 21:29, 5 October 2025 (UTC)
- This version now uses the production data file Data:Performances.json, so my remark in the 2nd paragraph is no longer valid. I would still like your feedback on the "context" structure. --Most2dot0 (talk) 22:32, 17 September 2025 (UTC)
Storing timeline events in Cargo
It's likely beneficial to also have access to timeline entries via Cargo. To get a feel for it, I created the de Cargo template (DatedEvents), which converts it's input also back into the current timeline format. I created User:Most2dot0/2014 to test this. So basically, instead of ; {{da|2014-02-07}} : event description, one would now write {{de|2014-02-07|event description}}. If there are more events on the same date, they get seperated with "§§" instead of "\n:" This gets stored in Cargo as a "List(§§) of Events", which unfortunately seems to cause some issues in Cargo's display functions (look here to see what I mean) for all entries but the first of the same day. In terms of Cargo it would likely be beneficial to have separate entries of events on the same date, but it would not have been that straightforward easy to reconstruct the existing timeline 2014 page. I also provided a calender view of the data, but that didn't work to well so far either, because the FullCalenar library used by Cargo apparently strips the in-page anchors, like "#2014-07-02" for the link. And we also would need to come up with better constrution of the event name (currently I'm using the date) and its description (that currently displays the raw html format of the descriptions, when the mouse is hovering over the event). So, what are your thoughts on this? --Most2dot0 (talk) 14:51, 27 September 2025 (UTC)
PS: I now implemented the calendar with Lua to use in the timeline. The styling is not 100% yet, but you'll get the idea how it utilizes the DatedEvents Cargo table.--Most2dot0 (talk) 22:10, 27 September 2025 (UTC)
- I've seen this, obviously. Don't have time to reply to it right now, though. Hopefully tomorrow… - dcljr (talk) 07:37, 28 September 2025 (UTC)
- I guess I don't really have anything to say about this at this point. It's certainly interesting. BTW, where are the month headings in the calendars at User:Most2dot0/2014 (e.g., "January 2014")? [grin] - dcljr (talk) 23:03, 29 September 2025 (UTC)
- Realization of all the details is sort of pending a decision, if this concept should go intro production use. Some other things are not sorted out yet: so the remarks that are listed at the beginning of a month or year where did not yet covered by Cargo storage. And some slight modification was needed, where there was a qualification behind the date but before the colon. E.g. at 2014-06-13, where I moved the qualification inside the description (which would be required if the would have been a 2nd event at the same date anyhow, I think). I think the concept has a lot of future potential. E.g. we could add tags, if the event described was a performance, or a release, or something else, and use that for color markings and filtering, both in the calenders and elsewhere. --Most2dot0 (talk) 12:15, 30 September 2025 (UTC)
- Just to clarify, in case you misunderstood, I was referring to the right-floated calendars at User:Most2dot0/2014 lacking any indication of what months they are for. - dcljr (talk) 03:17, 20 October 2025 (UTC)
- That was clear, and it's certainly easy to fix. My point was that it's not worth fixing unless we decicde to actually use it.
- — The preceding unsigned comment was posted by User:Most2dot0 at 08:55, 20 October 2025 (UTC)
- Just to clarify, in case you misunderstood, I was referring to the right-floated calendars at User:Most2dot0/2014 lacking any indication of what months they are for. - dcljr (talk) 03:17, 20 October 2025 (UTC)
- Realization of all the details is sort of pending a decision, if this concept should go intro production use. Some other things are not sorted out yet: so the remarks that are listed at the beginning of a month or year where did not yet covered by Cargo storage. And some slight modification was needed, where there was a qualification behind the date but before the colon. E.g. at 2014-06-13, where I moved the qualification inside the description (which would be required if the would have been a 2nd event at the same date anyhow, I think). I think the concept has a lot of future potential. E.g. we could add tags, if the event described was a performance, or a release, or something else, and use that for color markings and filtering, both in the calenders and elsewhere. --Most2dot0 (talk) 12:15, 30 September 2025 (UTC)
- I guess I don't really have anything to say about this at this point. It's certainly interesting. BTW, where are the month headings in the calendars at User:Most2dot0/2014 (e.g., "January 2014")? [grin] - dcljr (talk) 23:03, 29 September 2025 (UTC)
Feedback on Cargo production database rollout / Cargo templates in song articles requested
I've been making good progress on the rollout of the Cargo version of the performance database. If you have not done so yet, please have a look at the transition ideas, open discussion points regarding articles created and the Current Status describing the progress. And of course please have a look at the newly created or expanded articles, and let me know if you see the need for adjustments. My plan ist to next append the other existing articles with Cargo templates. I will sort these into existing sections, but for article stubs that so far don't list performances, I will likely leave them unsorted. Then I will continue with the creation of new, so far missing song articles, also leaving the performances mostly unsorted (they will be listed according to their date, so are somewhat sorted already, just not explicitly grouped). Possibly I'll create the template for orignals on they way, to do those as well. As an alternative to mass-creation of all new songs articles with the performance template calls right away, we couldn't have those in several files e.g. split by starting letter. This way, the file size would be smaller, and changes would have less overhead. We could then delete entries from these files, one they have been copied to new song articles. So what do you think? --Most2dot0 (talk) 21:47, 9 October 2025 (UTC)
- No more stopgap measures. Let's just do this (pending ongoing discussions elsewhere). As I have mentioned before, there's quite a lot to look through, so I haven't seen everything you've done. If I want things done differently in the future, I'll just have to bite the bullet and make the changes "manually" (see also User talk:Most2dot0#Mass changes in the future). - dcljr (talk) 03:17, 20 October 2025 (UTC)
- Ok, thanks for all the feedback, I'm looking forward to bringing this on... --Most2dot0 (talk) 08:57, 20 October 2025 (UTC)
- I now updated the documentation for the
{{Performance}}and{{Video}}Cargo templates, and included a new section of how to include them in the Articles about songs article. Please let me now if you'd see the need for further clarifications. --Most2dot0 (talk) 10:06, 21 October 2025 (UTC) - I'm done with creating all misssing cover song articles. To quickly complete the production Cargo database rollout, I will next create the ones missing for the originals, but only via the dynamic preload, not doing any edits for the intros. --Most2dot0 (talk) 12:07, 25 October 2025 (UTC)
- OK. It's just been one thing after another preventing me from devoting time to help with any of this. Just to hint at what I mean, in the last 4 weeks I have bought a car tire, three hard drives (two of which had to be returned), and a replacement remote control for my DVR. I'm wondering if I can make it out of October without something else going wrong. - dcljr (talk) 09:08, 26 October 2025 (UTC)
- I now updated the documentation for the
- Ok, thanks for all the feedback, I'm looking forward to bringing this on... --Most2dot0 (talk) 08:57, 20 October 2025 (UTC)
