Angelina Jordan Wiki talk:Namespaces

Non-JSON data

@dcljr: I likely will soon be able to use the embedded YouTube player gadget to gather the most often used meta-data (title, channel-name, length) of YouTube videos. The question is, where to store those in the form of Cargo data template calls? The description of the "Data" name space says it's for JSON only, but I do not think that's technically enforced. So unless you oppose, I will add them here.
These will go to a certain article, which we could move over to versions with a suffix (-1, -2, etc.) once in a while, so that adding new entries will not cause the rewrite of a huge file. I would also likely extract the existent data in Data:VideoMetaData.json (which I think so far only has YouTube entries anyhow) to that Cargo format, to have all available data in one Cargo table. --Most2dot0 (talk) 06:28, 1 August 2026 (UTC)

Well, there is the "YouTube:" namespace, which hasn't really found a good use. How exactly is the gadget going to obtain this information? Will it query YT for it every time someone views a video through the gadget? Or will it take what YT already returns anyway, and just put it to better use? And how will the information get updated on-wiki (and how often)?
If this collection and updating of info is going to be automated (at least to some extent), then I assume one wiki page per YT video is the way to go, as far as storage of the template calls, right? (Just like one page per song.) As we were discussing elsewhere, the idea has always been one-page-per-thing, and that's pretty much the Cargo philosophy, as well: the information is maintained on-wiki in separate pages but stored centrally in one Cargo database. We shouldn't be trying to store the info centrally on-wiki in a single page, right? - dcljr (talk) 00:04, 2 August 2026 (UTC)

In my current development version on my User:Most2dot0/common.js (starts at line 50), there is a new "Info" button besides the existing "Prev"/"Next" ones, which is initally disabled. Shortly after the video play is started, all the information gets available (I believe it is the duration, that takes the longest), and that is noticed by a signal/call-back-function from the API, which then enables that "Info" button. If the user clicks on that, the player's API is queried. ChatGPT says that's local in the browser, which makes sense, as I know that the browsers iframe content changes independently of that when a new video is loaded, and shows e.g. the title and channel name in its html. And of course it knows the runtime, too (once it started to play). Once the info is received by the gadget, it gets checked whether it already has an entry in the Special:CargoTables/MetaData table. Then the info is in any case displayed in a dialog, which has the option to save it to the Wiki only if it didn't have an entry yet.
This could of course be be more automated, e.g. once the data get's available, it automatically get's queried, then it's checked if a Cargo entry already exists, and if doesn't yet, it could trigger the dialog automatically, or even (silently) just add the new data to the wiki. The latter option likely requires a strong confidence that the prior checks really do work, so the former might be prefered for now.
I'm open for one page per video, though that makes converting the existing data of data:VideoMetaData.json more complicated, but I guess I can write another javascript piece to do just that, directly reading the JSON, and doing those same API calls for writing. The effort proably actually isn't higher compared to doing it with Lua (which was my first thougth, as I did it that way when initally converting the performance database to Cargo). The benefit is certainly, that later updates are much easier and take less overhead per update. The current data:VideoMetaData.json was derived form Open Graph data, and contains more fields. We could add a relevant set of those to the new Cargo table right away, e.g. upload date, and then maybe we later get a bot that can add that data where it wasn't initally included.
To make it easier for those updates, I would recommend though to have this meta data in seperate articles from any user generated content. So if the latter would go to YouTube:VIDEO-ID, the meta data could go to e.g YouTube:VIDEO-ID meta data. --Most2dot0 (talk) 13:28, 2 August 2026 (UTC)

I now made the neccessary adoptions, there are now 6 entries in the YouTube namespace as proposed, the last 5 created with the import from Date:VideoMetaData.json. I am ready to import that completely, which would create another 708 pages like that (that file was created on 2024-09-06 with data I scrapped from Open Graph entries on YouTube videos that where in the performances database at the time).
Once that is done, I would then go forward to try to add more entries with the embedded YouTube player, i.e. for more recent entries in the performance database, and for videos used in the Thematic chronicle (which are sometimes different ones).
I would like to do that ASAP, because currently more and more videos get blocked from usage in the embedded YouTube player (by "bryhuangpub", probably somebody who owns parts of rights to the melody, and decided to block all embedded player usage, at least if the video contains only the song), which then blocks also the access to the meta data by the player. --Most2dot0 (talk) 16:12, 4 August 2026 (UTC)

I did it a little different as planned, as I started with adding videos that were uploaded added after 2024-09-06 with the YouTube player. Then I imported the existing JSON data this morning. There are now, as I write this, 745 entries in the MetaData table, and thus the same pages for that in the "YouTube:" namespace. 650 of those were imported from Data:VideoMetaData.json. It wasn't the initally expected 713 entries, as that file contained duplicate entries for videos that were referenced in several performance entries, if it contained more than one song. There are a lot of videos like that from Mery, like for the 2017 Christmas tour and the Hemnes Boat & Fjord Festival. From what I have seen it went quite well.
I will now continue to add missing meta data with the YouTube player. --Most2dot0 (talk) 10:25, 6 August 2026 (UTC)

PS: Another 90 added. To see what else was changed, excempt the "YouTube" namespace from the recent changes display, this link should do that. --Most2dot0 (talk) 14:08, 6 August 2026 (UTC)

In case you haven't noticed yet, pages like YouTube:3f0QL4yJ2g meta data have the wrong number of characters in the YT ID part of the title (here 10 instead of 11) because their IDs begin with an underscore, which is ignored when the wiki page is created. (In this case, the actual ID is "_3f0QL4yJ2g".) This is why when I created redirects in the "YT" namespace lo those many years ago, I used an initial "v" in the titles (e.g., YouTube:V 5bs 6Nk2ic for a video with ID "_5bs_6Nk2ic"). I didn't worry about IDs ending with an underscore, but apparently that is also possible (and are probably among the pages you created, I just didn't find them). And then there are things like YouTube:Od3 - RBl4 meta data, where two underscores in a row were turned into a single underscore/space (the actual ID: "od3_-__RBl4"). The only way to deal with that kind of thing would be to translate underscores into different characters ("+" seems like a good choice), although I'm not sure how practical that solution is. Have you checked to see if these abbreviated page titles are causing problems when the data is used? (I have not.) - dcljr (talk) 02:20, 24 August 2026 (UTC)

The normal use of the data is via Cargo, and that isn't affected as the id is stored unaltered there. The page title is only used for checking if an entry already exists (originally that was also done with Cargo, but ChatGPT suggested doing it with page access as being more efficient), and that works as the same conversion is used (checked for YouTube video^↗) used at thematic chronicle#Christmas concert tour).
So what can happen in the worst case is that data is not added for a video that has the identical order of non-space characters and omitting causing spaces in different places to an existing one. As this is very unlikely to occur (as there are (64^11) random ids, I believe), and the effect would just be that the 2nd data would not be stored (but not a wrong lookup), I think we can ignore it.
We could further reduce the risk by enclosing the ID e.g. in brackets, so that only consecutive spaces could be the cause, not the ones at the beginning and end. But I doubt that's worth the effort. Also, replacing the space with some other character would risk that that conversion might be eventually be done wrong somewhere, e.g. by manual access. --Most2dot0 (talk) 08:58, 24 August 2026 (UTC)

PS: maybe there is still an issue, because while the existence check did work for above id, the lookup, though via Cargo, unexpectedly seems to fail: Angelina Jordan - Mary's Boy Child (NRK Radio "Spillerom" Dec 15, 2017)^↗ I'll have a look into that... --- that was false alarm, there was an unnoticed line break in the url. --Most2dot0 (talk) 09:32, 24 August 2026 (UTC)