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)
- 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)
- 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, the 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)
