User talk:Most2dot0

From Angelina Jordan Wiki
Revision as of 11:50, 12 January 2026 by Most2dot0 (talk | contribs) (→Another page to be moved?: can be deleted)

Scribunto

We now have Lua modules (output of example module: Hello World!) with syntax highlighting and a special code editor for editing the module pages (and user CSS and JS pages — see, "Appearance" in your Preferences). To use the code editor, you have to have "Enable the editing toolbar" selected in your preferences (under "Editing"). Unfortunately, the font used in the code editor is hardcoded to a tiny size (for me, anyway), and user CSS cannot override that (and almost certainly not sitewide CSS either, although I have not tried that). Note that you can toggle between the code editor and the normal "source" editor (i.e., the one used for normal wikitext) using the "<>" icon in the upper-left corner of the code editor (the icon is not shown when editing normal wiki pages). Happy coding… (BTW, if you reply, please do so here and not on my user page, so the discussion stays in one place.) - dcljr (talk) 00:59, 24 July 2024 (UTC)

Thanks, Lua seems to work fine. Though I wonder, if this is a different editor than the one on Wikipedia, or if it is differently configured? One thing I noticed is that there is no special support for JSON files, whereas on Wikipedia, there is a syntax check that is helpful. They also have a special view for them outside of the editor (but that's less important, thought it can be convinient to understand the content). ~ Most2dot0 (talk) 23:16, 28 July 2024 (UTC)
Not surprising that it's different on Wikimedia sites. If you can find out what is causing the differences, I can look into maybe enabling/installing those things here. Speaking of differences, do you see OK font sizes in both the Code Editor and the regular source editor? For me, it's very much smaller in the Code Editor. I have been reminded that I set up a site-wide override for the editor font size in MediaWiki:vector.css back when I first started using the wiki. That has no effect in the Code Editor, though. If you'd like, I can delete that and instead use my own per-user "vector.css" or "common.css" for myself. I have also been reminded that I have my own User:Dcljr/common.js that provides syntax highlighting in the regular "source" editor, which is very helpful when editing templates. I can try to set that up site-wide through the CodeMirror extension (which allows you to turn it on and off in the editor). Or you can copy the code in my "common.js" to yours (accessible through your preferences), if you'd like to try it out. - dcljr (talk) 06:29, 30 July 2024 (UTC)
I'd say the size in the code editor is indeed very small, and I usually enlarge it using the zoom feature of the browser. However, it's not smaller than e.g. the Wiki menu on the left (below your Wiki's logo), or like text in article pages. So it's more a general problem. The one in the normal editor is indeed larger, maybe a nod larger than needed. But I have no issue with that. For the syntax highlighting, I copied your .js file. It looks like a help indeed, though the highlighting of the background instead of the font is somewhat unusual. ~ Most2dot0 (talk) 16:36, 30 July 2024 (UTC)
I just got a new computer (and thus a fresh Firefox install) and have found that the font-size settings I was using here are not working for me. (I guess I should have paid more attention when you said, "it's more a general problem"!) So I've decided to ditch the site-wide hardcoding of the editor font size (not sure why I elected to do that in the first place, apart from just that I was the only user on the wiki at the time, so it didn't matter) and move those settings into my skin-specific user CSS. Please adjust your own settings as appropriate. I'm hoping that the next MediaWiki update (which is already available and needs to be done sometime "soon") will make this wiki look/behave a little more like Wikipedia currently does. Will comment elsewhere (later) about the CodeEditor, etc. - dcljr (talk) 03:03, 21 January 2025 (UTC)
The common.js mention brought some whole new ideas up. I will describe them below ~ Most2dot0 (talk) 16:57, 3 August 2024 (UTC)

Embedded YouTube player

I implemented (again curtesy of ChatGPT) an embedded YouTube player, that through some additional scripting now support dynamic playlists of videos with start and end times (the YT player itself can do either, but not combined). I also implemented two ways to provide the video IDs: one via a list of IDs with optional start/end times added, the other via enclosing a text that contains youtube urls, that will be used for the playlist, also for start and end times (EDIT, solved --Most2dot0 (talk) 12:11, 4 August 2024 (UTC): though the current implentation does not work when both are provided for an url). Have a look at User:Most2dot0/Test to see how it is being used. Now, to see the magic in action, you need to copy from my [[User:Most2dot0/common.js to your's. As I started with a copy of your's, I assume you could just copy the whole content. But before you do that, also have a look at the next section, where I use it in an auto-generated songs-list. As for the players functionality, you have the skip back/forward buttons below the video, and you can click on the urls that initilized it, to play that video in the player (you can go from there to the original via the players (watch on) YouTube button. ~ Most2dot0 (talk) 16:58, 3 August 2024 (UTC)

Have looked at this (last year and again today) without any additional configuration on my part, and was suitably impressed. Have not yet gotten The Full Effect (i.e., the "magic"), but maybe soon… [grin] - dcljr (talk) 06:58, 21 January 2025 (UTC)
The performance database has it's main page on Performances. I also in the meantime added more examples/test in User:Most2dot0/Test. And the common.cs code really makes a difference [grin]! It will also give you a new look on some existing pages, like from the Kongsberg Jazz Festival. I'm keen on your feedback if you are ok with turning the Wiki into a more multimedia type of experiance... -Most2dot0 (talk) 17:50, 21 January 2025 (UTC)

Module:SongsToVideos

At the buttom of that page you also find a render of the Data:SongsToVideos.json content to a songlist with example videos via Module:SongsTable. I took the videos from my YouTube A-Z index playlists (or from the references of the Songs page). Also the Songs themself were taken from that page. The data still needs some clean-up. I saved comments and refs (though I probably need to redo that), but they currently get not rendered yet, and there are also some other things that need to be clarified, for which I will put a comment on the Talk:Songs page. Anyway, once you enable the substitution of the div tags via common.js, you will also see an embedded YouTube player in each of the expandable video lists. If the players are not loaded, the original links will work, calling the video on YouTube directly. ~ Most2dot0 (talk) 16:58, 3 August 2024 (UTC)

Sorry I didn't research this stuff more last year. I started to, but Things Happened. As you surely already know, since "Data" is not a real namespace on this wiki, those JSON pages are in the main (article) namespace. I guess this kind of page at Commons is what you meant by Wikipedia having a "special view" for JSON data? I also assume that I need to install mw:Extension:JsonConfig to make that happen here. Yes? - dcljr (talk) 05:30, 21 January 2025 (UTC)
I think the first link you gave is something else. However, the visualization example in the JsonConfig extension looks a lot like what I have seen on Wikipedia, e.g. at wikipedia:User:Most2dot0/sandbox/Data:VideoMetaData2.json. From what I read, that seems to provide more than just providing the visulization and context aware editing, which would not be required for my purposes. And I think the visualization is not needed, so if there would be a way to get the code editor being aware of JSON without this extension, it would be fine as well. BTW, it would also be good to have doc sublinks in that namespace working, but that's not the case in WP either. Most2dot0 (talk) 17:29, 21 January 2025 (UTC)
OK, JsonConfig is something else. I'm wondering whether the "content model" of the JSON page(s) just needs to be changed from "wikitext" to "JSON". I think only an admin can do this, but you can try it yourself by going to the page you want to change the content model of, selecting "Page information" in the sidebar, looking for "Page content model" in the "Basic information" table, selecting the "(change)" link, and choosing "JSON" from the "New content model" dropdown menu. Obviously, you should have a copy of the page content squirreled away, just in case something goes wrong. Hopefully the Code Editor will "magically" understand JSON after this is done. If you can't change the content model yourself, let me know and I'll change it (for whatever pages you want) in my guise of wiki administrator. - dcljr (talk) 06:12, 9 February 2025 (UTC)
I was able to change the content model as you described, and that indeed enabled both the WP like visulization, as well as the code editor. Thanks for figuring that out! It does automatic "pretty printing", introducing a lot of whitespace compared to the compact form in which I saved the bigger models so far, so it will introduce a lot of change uponn first edit, but I guess that's ok. - Most2dot0 (talk) 09:58, 9 February 2025 (UTC)
Hmm, seems that (possiblyafter a short delay, or I likely just overlooked it before) the json files did get an automatic whitespace update automatically. - Most2dot0 (talk) 10:13, 9 February 2025 (UTC)

Upgrading the wiki

I never enabled mw:Extension:Echo because: (1) I didn't need it when working on the wiki alone; (2) it increases the resource usage of the wiki; (3) as more users join the wiki, there is increased potential for its abuse [i.e., spamming]; and (4) the installation and configuration of the extension itself is nontrivial, and requires me to do more research to make sure I don't break something. But it is undeniable that it would make collaboration here much more efficient and effective. As you have experienced, I often have no idea that you have posted to a talk page because I never check my watchlist or Recent Changes for such things. (I'm not even "watching" most pages here.) I would definitely see emails and on-wiki notifications. So, what are your thoughts about this? (Basically, I'm just asking you to ask me to install it. [grin]) What other extensions do you need? - dcljr (talk) 07:48, 21 January 2025 (UTC)

I have to say, that would not be one of my priorities right away, but I do check about every time im in the Wiki the updates. I have a browser tab open for the "Recent Changes" page, and that has a notification without reloading the page if something did change from the last time reloading it. -Most2dot0 (talk) 17:41, 21 January 2025 (UTC)
For other extensions, I'd recommend the Gadgets mw:extension:Gadgets as a means to share such features as the embedded YoutTube player easily, i.e. without the need for each user to copy those things into his commen.cs. -Most2dot0 (talk) 17:41, 21 January 2025 (UTC)
Just FYI: I've decided to hold off of any other work on extensions until the wiki gets upgraded to the next major version, 1.43, which is a "long-term support" (LTS) version. We're currently on 1.42.5, probably the last subversion of 1.42, which goes "end-of-life" in June 2025. Version 1.43 has actually been available since December 2024, but not through the cPanel application I have to use to upgrade the wiki. In the past, major versions have "hit" cPanel anywhere from 3 days to 3 months after they were officially released, but typically it has taken around a month. So, I assume 1.43 will be showing up in cPanel pretty soon. - dcljr (talk) 05:23, 9 February 2025 (UTC)
Well, somehow 1.43 showed up in cPanel without me noticing. Not sure when that happened. I usually get an e-mail about that, but I didn't this time. [grumble] In fact, as alluded to in my previous comment, the current version of the wiki is now deprecated (presumably since June), and cPanel is complaining that I need to upgrade. So, I'll be doing that "soon". I might enable the Echo extension at that time. - ajwikiadmin (talk) 01:41, 12 August 2025 (UTC) [Note: I meant to leave this comment as me. - dcljr (talk) 05:15, 12 August 2025 (UTC)]

Skins and floating

Which skin do you use on this wiki? I just switched from "legacy" Vector to Vector 2022, because the version of Vector 2022 provided in the latest upgrade includes an "Appearance" menu where you can adjust the text size (that didn't seem to be the case before the upgrade). I've noticed that in our Timeline, the floating (or not) of the monthly calendars should be different depending on whether the Table of Contents is floated to the right (legacy Vector) or appears in the left sidebar (Vector 2022). The current floating is based on legacy Vector (the calendars up through 2010-03 are not floated because that didn't look good with the right-floated ToC). Would you happen to know how to detect which skin a user is using (inside a template, I mean)? Google's AI Overview seems to be hallucinating a {#var:…}} function (specifically, {#var:skin}}). That doesn't seem to be a thing on any MediaWiki wiki I've tried it on (this one, the English Wikipedia, the MediaWiki.org wiki). Anyway, for future reference, which skin are you using? - dcljr (talk) 07:35, 14 August 2025 (UTC)

I'm using the "Monoblock" skin, for a couple months already. At the time I decided that based on which was the best compromise between how it works/looks on both desktop and mobile devices. I recall that it was easier on Wikipedia to get good looks on both, presumedly because they have different rendered pages for mobiles. In regards to detection, I had asked ChatGPT before how it's possible to detect if a user uses a Gadget or not, and the answer was, that's possible via JavaScript. I think, I did actually try that via the browser console for debugging purposes, and it worked. So a system wide JavaScript could likely also detect the skin used, and make changes to the html of the rendered page. I now asked about the skin, and it confirms that this possible. It also showed a separate way via a Scribunto/Lua module:
local p = {}

function p.skinDependent(frame)
    local skin = mw.getCurrentFrame():getParent().args.skin or mw.getConfig().currentSkin
    if skin == "vector" then
        return "This is Vector"
    else
        return "This is not Vector"
    end
end

return p
I did not try that yet, though. -Most2dot0 (talk) 08:55, 14 August 2025 (UTC)
But can it distinguish between legacy Vector and Vector 2022 (i.e., does "vector" in that code refer to only legacy Vector, or either version)? Anyway, if we're gonna go editing system-wide files, we might as well try to do this with CSS (note that MediaWiki:Vector-2022.css does not currenty exist, but apparently that's where style specifically for that skin would go). That seems like the most obvious solution (using special classes for things that should be rendered differently in different skins). FYI, in the latest upgrade I enabled MinervaNeue, which is supposed to be a skin for mobile devices. Apparently Timeless is a good choice, too. You might want to try out all the skins again, just in case something has changed (like the improvements to Vector 2022). Also, there are MobileFrontend↗ and TemplateStyles↗ extensions, which seem to be relevant to mobile rendering. - dcljr (talk) 10:38, 14 August 2025 (UTC)
BTW, MediaWiki:Vector-2022.css now exists, but only as a blank page. I was trying to see whether the lack of that page was causing a certain error I observed in "the console". I think it was. - dcljr (talk) 14:06, 14 August 2025 (UTC)
The Lua solution would not be system-wide, it's rather comparable to a Template solution. But it didn't seem to work: the 2nd part of the or caused an error, she the first apparently just returned "skin". Possibly I made a syntax error, but I agree that CSS makes more sense, also to better separate presentation from data, so I won't investigate further for now. Both "Vector" skins make no sense on a phone, the others use a bigger font in mobile mode than the "Monoblock". Since I can always zoom further in, but not out, the "Monoblock" is more flexible. I haven't tried them in desktop mode yet. -Most2dot0 (talk) 14:46, 14 August 2025 (UTC)
I have now tried the others one the desktop, and they don't adopt well, using to big fonts as well. Might be appropriate on tablets, but not on a desktop IMHO. So I'll stick with "MonoBook" (I misspelled that above). -Most2dot0 (talk) 19:59, 14 August 2025 (UTC)
I thought maybe "Monoblock" was a humorous nickname for the Monobook skin.[grin] - dcljr (talk) 12:37, 16 August 2025 (UTC)
Just for the record, after this conversation I added AJW:Skins#Sample page views to make it easier to compare different skins. - dcljr (talk) 02:20, 20 October 2025 (UTC)

TikTok

Looks like TikTok supports embedding videos↗ just like YouTube. Do you plan to write a gadget for that, too? - dcljr (talk) 15:39, 14 August 2025 (UTC)

So do Facebook and Instagram. However, when I looked into that last year, no one offered an open API like YouTube does, it's s rather static embedding. So doing the same things I implemented for the YouTube player (start and end time codes, play automatically the next video when the previous one reaches its end time, etc.) would not be possible. They would always play the whole video, and the user would need to start the next one manually. I did also try that for I think Facebook, and another issue was that the embedded size was dependent on the loaded video, which also made no good visual experience. So that was when I decided to not investigate the idea of s multi-source-player further for the time being. It might make sense, though, to better indicate which videos are covered by the player, and which are not, e.g. by color coding of the urls. -Most2dot0 (talk) 16:22, 14 August 2025 (UTC)

VideoMetaData and the Data namespace

Any particular reason you never changed the content model of Data:VideoMetaData.json from wikitext to JSON? Also, I plan to (finally!) create a dedicated "Data:" namespace. I'll probably be moving the pages to different titles temporarily when I do that, so I can avoid having to run a special script to recover them after the namespace gets created. (Creating a new namespace prefix makes any page titles already using that prefix inaccessible. Fortunately I already knew that and didn't have to find out by making the change and having the pages disappear!) - dcljr (talk) 16:24, 14 August 2025 (UTC)

I don't recall exactly, but I guess since that's typically generated and replaced as a whole, instead of being manually edited, it would have been just extra work with no immediate benefit. So there's no reason not to change it for consistency, I guess. -Most2dot0 (talk) 16:47, 14 August 2025 (UTC)
Done. - dcljr (talk) 18:09, 14 August 2025 (UTC)

A minute or so

Well, it would have only taken a minute or so, if I didn't confuse myself halfway through the process! [sigh…] - ajwikiadmin (talk) 11:25, 16 August 2025 (UTC)

No issue! Will this new "Data" namespace now allow for documentation articles, same as on Templates, Modules, etc? --Most2dot0 (talk) 11:31, 16 August 2025 (UTC)
I don't know. Try it. BTW, somehow Data:VideoMetaTestData.json got left behind in the main namespace. I'm not sure how, because it's also showing up in the Data namespace. Weird. Oh, well… the redirect works, anyway. - ajwikiadmin (talk) 11:38, 16 August 2025 (UTC)
Apparently does not work the same (yet). May it can be configured to do that? --Most2dot0 (talk) 11:48, 16 August 2025 (UTC)
[shrug] I don't know. I kinda figured it wouldn't "just work", since the namespace was created manually and not provided by an extension. Maybe just use the talk page? (BTW, template documentation is not automatic; it needs to be manually set up for every page.) Maybe you could transclude Data:Performances.json/doc (a normal wikitext page) onto Data talk:Performances.json (i.e., using {{Data:Performances.json/doc}})? At least that wouldn't pollute the talk page "source" too much. - ajwikiadmin (talk) 12:04, 16 August 2025 (UTC)
Of course, there still wouldn't be any visual indication on the .json page that it is documented on the talk page. - ajwikiadmin (talk) 12:07, 16 August 2025 (UTC)
I send you an email with a suggested solution ChatGPT came up with. Even if it doesn't work right out of the box, it might give hints for a solution, that could be simpler, e.g. just displaying a hint towards the /doc sub-page. --Most2dot0 (talk) 12:30, 16 August 2025 (UTC)
I just realized that one reason the "/doc" experiment wasn't working is that I didn't configure the "Data" mamespace to use subpages, so MediaWiki didn't know there was any kind of relationship between Data:Performances.json and Data:Performances.json/doc. [sigh…] Now it knows that the latter is a subpage of the former. Still doesn't recognize it as documentation, though. BTW, the extension solution I was alluding to above didn't pan out. It couldn't do what we wanted. - ajwikiadmin (talk) 12:25, 17 August 2025 (UTC)
Can you possibly create top page notices that are only shown in certain namesspaces, with a hint that there might be documentaiton in the /doc subpage? --Most2dot0 (talk) 12:45, 17 August 2025 (UTC)
Yes. Just realized that the sitenotice can be used for this. And for non-logged-in readers, as well. Trivial. [eye roll] You should be able to edit those pages if you want a different message. (Keep in mind that the doc subpage may or may not exist. I'd really rather not check for its existence with a parser function, so choose a wording that makes sense whether the documentation exists or not.) - ajwikiadmin (talk) 02:21, 18 August 2025 (UTC)
I now observe a weird behavoiur in the Recent Changes log after editing Data:Performances.json: it's marked there as not existent! But when being clicked, it's there. --Most2dot0 (talk) 17:54, 17 August 2025 (UTC)
Yeah. I thought that was a one-time thing with the "move" entries right before and after I created the namespace, but apparently it's a persistent problem. Will try to fix this soon. I'll warn, as usual, about locking the wiki before I do that. - ajwikiadmin (talk) 02:21, 18 August 2025 (UTC)
OK, I am really confused now. I just came to the wiki to start trying to fix this redlinks issue (I now have "shell" access, so I can run maintenance scripts, which was never really necessary before), and I didn't see redlinks at Special:RecentChanges! (Except, of course, for pages that really don't exitst, like Data Performance.json/doc.) At the time I wasn't logged in because I usually don't check the "stay logged in" box when I log in as the wiki admin. So I logged in as the admin and then I saw redlinks there. But then I went to a different browser tab where I just happened to be viewing RecentChanges while not logged in (for whatever reason, I had two such tabs open before I logged in on one of them), and it suddenly updated automatically to show me as logged in but it didn't show the redlinks. Then I logged out and back in as dcljr, and… well, I don't remember whether there were redlinks there or not. Suffice it to say, I have logged in as both the admin and as dcljr repeatedly, and sometimes I see the redlinks and sometimes not. FWIW, I am seeing the redlinks right now in a new tab I just opened while typing up this comment. This is all very weird. It's almost like there's some kind of caching issue at play here. I can't tell if bypassing the browser cache [shift-reload] makes any difference or not, but I suspect MediaWiki's caching behavior (which I don't really know anything about) is at least partly responsible for this. The typical state of affairs, though, seems to be that logged-in users see redlinks and logged out users don't. Could you try logging out and in a few times in different ways (i.e., while on the RecentChanges page vs. while on a different page, and bypassing the browser cache vs. not) to see if you experience the same inconsistent behavior? (BTW, I don't think I'll be locking down the wiki anytime soon, if you want to continue editing for the next few hours.) - ajwikiadmin (talk) 16:12, 20 August 2025 (UTC)
BTW, bypassing the browser cache might not have an immediate effect but might make a difference if you then visit a random page and return to RecentChanges via the sidebar link. - ajwikiadmin (talk) 16:21, 20 August 2025 (UTC)
I can reproduce red/blue links by choosing between the number of changes shown to be 50, or more. It looks, that 50 changes don't include the creation of the namespace, then the links are blue. That's the same for both logged in and looged out, it just seaemed as if the log-out default is 50 changes. So the change in namespace during the report-period as causing the issue, so it will sort of grow out by itself. --Most2dot0 (talk) 16:32, 20 August 2025 (UTC)
Ah, that's it! I could not for the life of me figure out why it looked different on different logins. Apparently sometimes my preferences for the number of changes to show were being honored (presumably, when I went there through a link) and sometimes they weren't (presumably, when I was just being redirected there after logging in from the Special:RecentPages page). What I just said might not actually be accurate, but I'm going to just drop the matter. I still plan to see if I can fix the underlying problem, but perhaps not today. (I just made some template changes that added a lot of jobs to the queue.) BTW, the same effect can be seen when you transclude Special:RecentChanges into another page (see the result). If you were wondering. [grin] - dcljr (talk) 00:30, 21 August 2025 (UTC)
Oh, I see the job queue is back down to 0. Hmm… let's try a simple fix first. - dcljr (talk) 00:32, 21 August 2025 (UTC)

Fix attempts

So, the first thing I tried didn't work. It was to run a script called namespaceDupes.php to try to make MediaWiki forget (/fix) any references to those titles in the main namespace. I figured it wouldn't work for the pages like Data:Performances.json, since they weren't actually in the main namespace anymore, anyway. But I thought it was worth a shot, since the database information has obviously been left in an inconsistent state, and I thought the script might detect and fix that. (The subsequent moving of Data:Performances.json to Data:PerformancesNew.json and back to Data:Performances.json was just a random idea I had. I figured it couldn't hurt — well, except that now there are even more redlinks in Special:RecentChanges… oh, well). Unfortunately, the script didn't even fix the one thing it definitely should have: the Data:VideoMetaTestData.json redirect is still showing up in the main namespace with the prefix "Data:". (!) That's exactly the kind of thing the script is supposed to fix. Sigh… Back to the drawing board. - dcljr (talk) 09:42, 21 August 2025 (UTC)

The last problem mentioned above is now fixed, but not the Special:RecentChanges issue. The relevant changes that were causing the redlinks can't even be seen there anymore because there have been more than 500 changes made to the wiki since the problem started, so I'm giving up on that for now. (The problem can still be seen in the log, though.) You're not still seeing redlinks where they shouldn't be in your day-to-day work on the wiki, are you? - ajwikiadmin (talk) 11:29, 5 September 2025 (UTC)
No, have not. Though I don't recall to have seen this anywhere outside of the Special:RecentChanges page at all, anyhow. Which might be an issue with perception, as I likely don't closely look at red links, and don't try to open them, unless I intend to create that missing page. --Most2dot0 (talk) 11:45, 5 September 2025 (UTC)

Different styling for dd element

I've tried styling the dd element differently, so that multiple items in a row can be distinguished from multiple-line single items. This affects mainly our Timeline and talk pages (see indented comments above). What do you think? (If you don't see any difference, reload the page while bypassing your browser cache. On my browser, that's clicking on the reload icon while holding the Shift key.) I can make the size and color of the markers different, but the shapes are limited to solid squares (like now), solid discs (like normal unordered list items), and open circles (which I thought didn't look as good). I initially wanted something flatter like a hyphen, but that wouldn't be supported by nearly as many browsers as the standard shapes. In fact, Safari apparently doesn't even support coloring the marker (which is gray, in case you're not seeing that). - ajwikiadmin (talk) 14:33, 5 September 2025 (UTC) [Note: The feature being discussed here is no longer visible on this page. - dcljr (talk) 22:19, 6 September 2025 (UTC)]

I have no issue with the looks. It's similar, but looks better, as using the item list (*). The question is then, why not just use that in the timeline (and possibly style it better? For the dd, looks like it now also increases the line distance. How about making just that a little bigger, and do without the square. Since at the end, we'd be losing the possibility the simple indent (without any symbol) otherwise? --Most2dot0 (talk) 14:54, 5 September 2025 (UTC)
I chose to use : for the timeline (sub-)items rather than * mainly because I wanted to use "description list" formatting (<dt> and <dd> in HTML, corresponding to ; and : in wiki markup). If * is used for the sub-items, then the ; opens a description list (<dl>) and adds a term (<dt>) only to have the first * under it close that list (</dl>) and start a new unordered list (<ul><li>). This is just "ugly". It bothers me. And if ; is not used for the dates because * is being used for the items, then there is no "semantic" meaning to the dates in the monthly lists. That is, each month would be a collection of alternating raw text (or perhaps tiny paragraphs) — the dates — and mostly one-item (unordered) lists, rather than being a single list containing multiple items (the dates as "terms" or "names" and sub-items as "descriptions" or "values"). An alternative approach would be to make them two-level lists, with the date marked up with * and the sub-items with **, but that formatting bugs me. I just don't like it. Now, admittedly, some people would object to using description-list formatting in this context because historically <dl> was understood to be for "definition lists", and a list of dates and corresponding sub-items is not a list of definitions. (Wikipedia editors still tend to enforce this bias.) To be fair, apparently some screen readers render — or have rendered, in the past — such lists in ways that assumed they were definitions. I don't know the details, but IMO, this would be a bug in those screen readers. Whatever… Officially↗ <dl> may be used for many different kinds of "association lists", and I say this case qualifies.[grin]
As for the line distance issue, I'm having trouble seeing any difference, even if I use the MonoBook skin. Must be differences in our browsers. Because of such differences, it's probably not sufficient to just adjust the spacing between the lines (for some people that might be like we didn't change anything). You can copy MediaWiki:Common.css to your own User:Most2dot0/custom.css or User:Most2dot0/monobook.css and play around with it (maybe adjusting the size of the marker with font-size and/or the line spacing with line-height) till you find something that works for you. Then I can try it and see how it looks for me. (Or I guess you can edit the sitewide CSS, too. I just remembered you can do that.)
Oh, and finally, can you think, off the top of your head, of a context where we only would want : to indent, but not look like a list item? I guess there could be certain uses on talk pages, and I know there's probably cases in some current template documentation, but I can't think of which ones. One way to deal with this is to use a special class to either show or suppress the marker, depending on which case is considered standard and which the exception (i.e., the exceptions could be wrapped in <div> tags having that class). It can also depend, at least to some extent, on which namespace we're in, but that starts to raise the specter of some template output looking different depending on where it's used — which would Not Be Good.) - ajwikiadmin (talk) 18:31, 5 September 2025 (UTC)
No, I don't have an idea where to use it elsewhere right now. The line difference is only tiny indeed, like 22 to 21 pixels or so on my screen with Monoblock. Its huge in Timeless, though, and it would probalby be possible to make it a little bigger in the others, too. I regards to structure, I was thinking to use a level 4 header for the date when combining it with a *-list, but then it ends up in the contents (though that might be adjustable), and a bigger font is used (which I don't like either). But anyway, I'm not invested in this. Your explaination makes sencse, and If you feel compfortable with the square with <dd>, just go ahead!
BTW, speaking of skins, Timeless is one that works well on both desktop and mobile devices and might be a good choice for the default skin. Monoblock also does it for me, but Timeless might be a better choice for most users due to its larger font sizes --Most2dot0 (talk) 19:20, 5 September 2025 (UTC)
I realized that : is commonly used purely for indenting on Wikimedia wikis in do-it-yourself "hatnotes" at the top of articles or sections to provide notes to readers. There may be some cases of this left on this wiki from its early days before I created {{hatnote}} and the other templates that call it. Preventing new users from using : directly in cases like this might be difficult. Not looking for a response about this, necessarily. Just thinking out loud. - dcljr (talk) 21:58, 6 September 2025 (UTC)
Have decided to abandon the "universal" nature of this feature, and have re-implemented it as on opt-in using the class "dd-markers". I'll look into formatting issues in different skins more "soon". - dcljr (talk) 22:20, 6 September 2025 (UTC)

Module:VideoMetaTestData.json

Can I move Module:VideoMetaTestData.json back to Data:VideoMetaTestData.json, since it really is just data and not a module? - dcljr (talk) 01:48, 7 September 2025 (UTC)

Yes, but I'd suggest to delete it and its doc page instead. It's nowhere linked at the moment, so it probably has served it's purpose. --Most2dot0 (talk) 17:03, 7 September 2025 (UTC)
Done. Thanks. - dcljr (talk) 18:35, 7 September 2025 (UTC)

Text database is getting large

Every time a new revision of a page is saved, the complete source text of that page is saved in the "text" database (even for the most minor change). That database is currently 38 MB, which doesn't sound too bad, but constitutes half of the space taken up by all 65 databases MediaWiki uses to operate. This will, of course, grow to a much larger fraction of the whole over time, as we have some very large pages, some of which are heavily edited (Timeline = 138 KB, Data:SongsToVideos.json = 146 KB, Data:Performances.json = 211 KB, User:Most2dot0/Performances.json-devel = 333 KB, Data:VideoMetaData.json = 611 KB). This doesn't appear to be sustainable long-term. (I think I've mentioned this before: we currently stand at about 75% of our 1 GB disk quota on the hosting server, and growing beyond that — to the next level of 2.5 GB — will mean a 36% increase in yearly cost.)
We might have to reconsider how we're doing things here. In particular, the Timeline could be broken up into subpages by year, so that the most any single edit would store in the database is "one year's worth" of timeline entries, and (prepare yourself…) we could consider switching to a dedicated data-management extension↗ like Cargo↗ (it looks like the best choice, IMO), in which the individual pieces of data are stored in template calls in articles, much like we're already doing on pages like Angelina Jordan Fanclub Mosarz and, say, "Love Don't Let Me Go" (these template calls would require a lot of modifications, of course, and I'm not sure how flexible the wikilinking would be, but it looks like a relatively straightforward process to adapt to the new way of doing things). The benefits would include much smaller page content being stored in the text database with each addition or change to the data, and potentially more user involvement with creating and maintaining the data (although there is a learning curve, it would be less daunting for most people than working with 300-KB JSON files). Disadvantages include balkanization of the data (no longer in "one place") and, of course, having to learn a new way of doing things (which new users will experience anyway, regardless of what we do). The good news is that the work you have done up to this point with the JSON files and modules can be leveraged to help create the necessary pages. (Not just following the redlinks already being shown in the generated tables to create the necessary pages, but possibly using a function in the module to generate a "stub" version of each new page with the information from the JSON data already in place. I'm not sure how this would work, exactly, but there's got to be a way of reducing the amount of work required to create the hundreds of pages we are lacking for songs, especially, as well as locations, venues, and whatever else.) - dcljr (talk) 01:56, 8 September 2025 (UTC)

Oh, and I did sometimes feel bad, because I was just correcting a missing comma, and thought of all the overhead caused by that in terms of change log entries... It really suprises me, as I was assuming it would work with differential encodings, like revisions systems and backups usually do.
Anyway, to mitigate, if not done yet, you could at least use compression on the revisions, see mw:Manual:$wgCompressRevisions. Also older revisions could be deleted for the big JSON files, there's likely litte point in keeping them. We could backup snapshots from while to while, if desired. When moving to the new format that's currently being prototyped, we could delete the original. We could make a copy without the video listings of Data:SongsToVideos.json, copy that to Data:Songs.json, and delete the old one.
But long term, I aggree that moving to smaller pieces is the right thing to do. I had looked briefly into Cargo before, but decided at the time I'd prefer to keep it to JSON. And that was the right choice, in terms of ease of importing large amount of data. And even now, where I base a lot of the categorization choices on existing entries, processed with regular expression on the whole page, I believe it is still much more efficient to get major changes applied compared to any distributed storage. So before moving to a distributed template based Cargo scheme as the primary source, we should have a clear understanding what fields we need to support, and the overall structure.
Anyway, I propose you install/enable the Cargo extension soon to get started, then we can get a feel what's possible, what works and what might not work as well.
Creating a stub based on JSON data should be easy, there's the "preload" action, see mw:Manual:Creating_pages_with_preloaded_text. It is my understanding that if a template is provided it will be evaluated, thus that could contain an call to a Lua function, that populates the preload with contents from the JSON database. We could e.g. generate those links in the User:Most2dot0/Performances-devel page for the red links. --Most2dot0 (talk) 11:55, 8 September 2025 (UTC)
My first test with preloading did fail to some extend: the template was neiter expanded at preload, nor at save of the page. So I will look into the method described in mw:Manual:Creating_pages_with_preloaded_text#Using_parameters next. This means that the details of the Song would need to be generated upfront and included in the red link. --Most2dot0 (talk) 18:54, 8 September 2025 (UTC)
I gave the first idea another try, when I read something about substitutions in the other docu. And now it somewhat works. It's a little ugly, as the preloaded template gets only executed when the new page is saved the first time, but I think this is ok, when considering the likely much higher effort that would be needed to do it with parameters in the preload link. One can use "Show Preview" or "Show Changes" to see the results before saving. You can try it here! The "section=new" is in there, so that it works on the already existing, though currently empty, page. --Most2dot0 (talk) 19:50, 8 September 2025 (UTC)
I'm just about to pull the trigger on splitting up the Timeline by year (and transcluding the year pages back into the Timeline page — they will be at, e.g., 2014 and not subpages like Timeline/2014, so they can be full-fledged articles, with the timeline portion enclosed by <onlyinclude>…</onlyinclude> so only those portions get transcluded).
I also thought maybe MW worked off of diffs directly. But no: it stores the complete text and generates the diffs as needed, instead of the other way 'round. Would be nice if it was designed to use diffs for small changes and complete text for large ones, but that's probably a pipe dream.
As for deleting old revisions, I might consider that for the huge Data pages once things have "settled down" a bit, but we will have to be careful about losing authorship information that's required by our license. (The "quick and dirty" solution is to just copy the page history information to the talk page before deleting the old revisions, but that's quite inelegant.)
I had already been considering switching to compressed revisions, but was a little concerned about how it actually worked (and, of course, I have to make sure the host's PHP supports it — I'm sure it does). It is encouraging that a mix of compressed and uncompressed revisions is possible. Maybe I can just try compressing only some old revisions of the huge pages, and see how that goes. OTOH, it doesn't sound like something we can gracefully back out of if it causes problems. (I mean, we can always revert to a saved image of the entire site, which I will create before applying any compression, in an emergency, but I don't want to potentially lose changes to the wiki like that if I can avoid it.) - dcljr (talk) 23:44, 8 September 2025 (UTC)

Months

General discussion about the wiki will have to move to some central location soon, but since you're still the only other active user here…
I've grown increasingly uncomfortable with my decision to link months to the timeline using {{d}} (or leave them unlinked using {{du}}) — mainly because {{#formatdate}}, which those templates use, doesn't actually understand months, whether they are given like 2025-09 or September 2025 (note how "hovering" on these month identifiers doesn't do the same thing as hovering on a day-date: 2025-09-09 / 09 September 2025). So, I've decided to abandon that convention and just create redirects to our timeline from every month, so we can link to them directly. My question is, should a link like 2025-09 be directed to Timeline#2025-09, as it is now, or to 2025#2025-09? (Notice how very different the "hover" experience is for the last two links.) The former approach keeps things simpler (any "dumb" template can easily do the linking), but I kinda like the latter because the hover text is (or will be) more informative. (And that's basically why I've decided to go with a bunch of redirects. Otherwise, we would need to use template calls like {{month|2025|09}} or process {{month|2025-09}} through a module (or fancy parser functions that we don't currently have.) Opinions? - dcljr (talk) 01:31, 10 September 2025 (UTC)

I would much prefer that links to years (2025), months (2025-09), and days (2025-09-09) can be treated the same where being linked, so with the same macro like now. Also, I don't see that the user experiance should be different between them, i.e. I would think if one of them is linking to the specific year pages, then all of them should as well, because I think the difference in specific preview is common to all of them.
Then the question basically is, if the added value of that preview summary exceeds the loss of the ability to seamlessly scroll between years after following a date-link. I would say no for month and day links. For links to years, it would make sense, but even if the value is there compared to the loss, I would likely go for the common user experiance, i.e. link everything to the complete timeline. --Most2dot0 (talk) 08:20, 10 September 2025 (UTC)

Latest discussion

I know there are things I still have to respond to. Hang on… - dcljr (talk) 10:43, 10 October 2025 (UTC)

The current transient state is not good. Please have a look at User:Most2dot0/Ideas#2025-10-19 why, and what I suggest to do about it. In lack of feedback, I would go with option 2 very soon, likely starting Monday. --Most2dot0 (talk) 10:46, 19 October 2025 (UTC)
I can help implement option 1. I just need to get used to how it works. I'm trying to address your questions posed elsewhere, but I'm finding it a bit difficult. I'm not always sure what is still relevant and what is not because the implementation has changed or will be changing soon.
BTW, I'd like to move the following pages into other namespaces, since they're not really proper articles:
Can all of these go into the project namespace ("Angelina Jordan Wiki:", with the abbreviation "AJW:")? If so, you should probably do the moving yourself, so you can make any adjustments to pages elsewhere that might be required to avoid things breaking. - dcljr (talk) 01:11, 20 October 2025 (UTC)
I'll looking into setting up some help and examples pages for applying the Cargo database templates.
I would propose to leave the .cargo pages for now (while not being article pages, the provide currently the source of information about Angelina's performances, so they would be misplaced in the "AJW:" namespace in my opinion). They could then be deleted or moved later once we copied their info to the songs articles, and they no longer provide the info for the Cargo database in use. For the other three, I will move them. --Most2dot0 (talk) 08:40, 20 October 2025 (UTC)
PS: I'm also concerned that moving Performances-devel.cargo will cause a lot of churn on the system, as basically every table entry would need to be recreated in the Cargo database. --Most2dot0 (talk) 09:06, 20 October 2025 (UTC)
Should I create a new namespace for cases like this? (If not for use with these exact pages, then for future use?) - dcljr (talk) 10:10, 20 October 2025 (UTC)
I don't see the need for it, as our strategy is in general do distribute such entries on article pages. These .cargo pages were really there for the transition, I don't see a similar use coming up. --Most2dot0 (talk) 10:54, 20 October 2025 (UTC)
Regarding you helping with the rollout, I am aware I need to set up some help how everything fits together. However, I think the first inital stage it to add the cargo entries to all allready existing articles. Because currently existings articles of those I have not worked on yet (and I wen by alphabet) tells us which articles still need performances added. If we'd create new ones in parallel, that would make this more difficult. Now, my suggestion if you want to help here is to start adding to articles from the other side, starting at letter "Z" (or "Y", actually...) going back. When we both keep the Special:RecentChanges in view, we'll see when we approach each other. Adding the performances is easy: First call the "(+)" link in Angelina_Jordan_Wiki:Preload-links_with_performances_listings_per_song#Songs_by_title. I then usually remove the first line in the comment saying to save it first and the remove that comment part right away. Check if there is something to fix/add from the song infos (w-title must be interpreted manually while still a comment), if not, those can also be removed right away. If unsure, just leave them untouched in. If there's only one song, I guess the "unsorted" parts could be removed (in the section title, plus the category entry for it), though I forget that sometimes myself. Then save it. Now, if the previous article was a stub with no performance content yet, the next step could be to move the added section up (or, easier, things like, stub, references, category, etc. down). Possibly the intro text could be extended already if more performances were added then mentioned there. If the previous article did already contain performances and embedded text, I would instead just leave it in the inital state, until I have some more help available. I introduced already Template:cytv by which Template:ytv links could easily transformed into Cargo entries, and I plan to add the same for Facebook, IG, and TikTok video links.--Most2dot0 (talk) 11:38, 20 October 2025 (UTC)
My previous comment is somewhat obsolete, as I now added the Cargo entries to all already existing articles. Basically, using the preloads for newly created orignal or cover song articles will leave them initally in that stub phase, I discussed later, and the same applies here. I have set up a ChatGPT pipeline to create song article intros for cover songs, lacking of course the summary of what Angelina did with it. But as I have seen that many existing article stubs have been in a similar state, I guess that would be not a problem. And of course I proof-read and check the auto-created intros for plausiblity and their given references. I have removed the "(+)" add preload option of AJW:Preload-links_with_performances_listings_per_song, and moved the "(C)reate" one to the front. I plan to go through the cover songs next as described. Working in parallel should not be much of an issue, as the preload automatically detects if an article already exists, and will then go to an edit page instead of a create page. --Most2dot0 (talk) 14:48, 21 October 2025 (UTC)
Real Life intruded almost immediately after I said I could help, and I couldn't do anything until "now". I am starting to review what you have done since we last spoke, while also being distracted by other things I'm noticing that need improving (grrr…), so I will get to actually helping create the missing articles "soon". (Note: I meant to leave this message hours ago, even before the last comment I left about curly quotes, but I got distracted and never saved it. Sigh…) - dcljr (talk) 03:56, 22 October 2025 (UTC)

Mass changes in the future

Extension:ReplaceText↗, which comes bundled with MW, allows for global (wiki-wide) regex-based find-and-replace. This would partially address the issues raised at User:Most2dot0/Ideas#Bulk edits. Of course, extreme care would have to be taken to perform the correct changes. I could see this potentially causing more problems than it solves.[grin] - dcljr (talk) 03:06, 20 October 2025 (UTC)

This looks quite helpful, indeed. E.g. if we'd decide to change a certain context entry for an event, this could be very helpful, and the risks are limited in that case.--Most2dot0 (talk) 08:50, 20 October 2025 (UTC)

Please avoid curly quotes

I've noticed curly quotes (“ ” ‘ ’) in the text you're adding. Please avoid those types of quote characters and use the straight versions (" " ' ') instead. - dcljr (talk) 23:07, 21 October 2025 (UTC)

I'm certainly was not doing that on purpose. And as I wouldn't even know how to reach those on my keyboard, I assume this did come in either from copying text from elsewhere, or more likely, by the text I had ChatGPT help me. I looked through the recently added documentation, and didn't find any example, though. So it would be good if you can point that out more detailed where you have seen those, than I can easier fix the source of the issue. BTW, I just noticed that the songs title is to be set in bold + quotes in the intro textes, so I advised ChatGPT to follow that, and I try to also watch that for future additons. --Most2dot0 (talk) 09:17, 22 October 2025 (UTC)
Yeah, it was in some of the intros on the new song articles. I figured it was a ChatGPT issue. I can catch most of those when I review each song article later. BTW, thanks for this. I forgot to follow up on that after the initial page-save. Like I said, I kept getting distracted by other things. - dcljr (talk) 03:30, 23 October 2025 (UTC)

Partners info

Regarding this, can you create a report of what needs to be added to the song articles? I'm sure it's very easy to do, but I still haven't taken the time to learn how to do anything with the Cargo data. - dcljr (talk) 09:14, 26 October 2025 (UTC)

Oh, wait… You're saying that the info didn't make it into the Cargo database. Duh. OK, so, I guess maybe a basic 'grep' of the JSON text would be sufficient (if a little ugly) to see what information is missing. Obviously, it will take more work to actually add it (whether via some semi-automated mechanism or not) to the articles. - dcljr (talk) 09:31, 26 October 2025 (UTC)
Well, the data made it to the PerformancesDevel table, but not in the production one. I just changed the partners entry from "List of (#) String" to "Strings" to make it easier to query (the fields where not split anyhow yet). So i can be queried, her you see the extend of the problem, but that query does not yet contain the best info to fix it: [1]. If you add a "Group by: PerformancesDevel.songs", you'll see that 95 song articles are affected. Anyway, I still have the hope to be able fix it with some level automation, let me think about it. The mos basic thing would be to put the filter in the ImportPerformances function to have new template calls generated for these. --Most2dot0 (talk) 10:02, 26 October 2025 (UTC)
I'll leave you to it (as usual). - dcljr (talk) 10:06, 26 October 2025 (UTC)
As far as I understood you in the past, you intend to proof-read all the generated articles, which is a good thing. My proposal would be that you postpone that a little, and instead start with work on the added orginal song articles, to add some basic intro (or even more) information to them. In the meantime, I'll setup a modified import function that only generates {{Performance}} template calls for entries with partners infos, and a modified [AJW:Preload-links with performances listings per song] table, that only contains the effeted 95 song articles. We can then add the corrections at the bottom via the preload feature (with some prefix, disabling them), and you could eventually help in replacing them for the original ones. How does that sound? --Most2dot0 (talk) 10:43, 26 October 2025 (UTC)
PS: I did this as planned, and appended new {{no_Performance}} template calls for all instances were the had not been transfered yet. Now, in some cases, where there are many replacements to make, but the auto-added performances were not yet edited, it might be easier to again append the complete listings including {{Video}} calls, and replace the whole section. I just did this for "Fly Me to the Moon", and it went very well. I changed the helper tools back to support that (except that the new section will still hint towards fixing partner entries). --Most2dot0 (talk) 16:43, 26 October 2025 (UTC)

Another page to be moved?

I just noticed Performances-devel.cargo, which is currently the largest page in the main namespace. Is that page still needed? If so, could you move it into the "Angelina Jordan Wiki" namespace, like you did with Performances - JSON import to Cargo? If it is no longer needed, let me know by placing a call to {{delete}} on it. (Same for Performances - JSON import to Cargo, if that isn't needed either.) - dcljr (talk) 11:29, 12 January 2026 (UTC)

It's no longer needed, I marked it and some related or similar data pages for deletion
Retrieved from "https://www.angelina-jordan.net/w/index.php?title=User_talk:Most2dot0&oldid=12405"