Batch edit recordings from an artist page

[ROpdebee]

https://musicbrainz.org/edit/91630721

What I'm thinking is a script that makes recording names and comments editable on the artist's recordings page. User can then edit the names and comments, either manually or by hitting a "Guess punctuation" button. Edits should be highlighted, and a button to submit the edits. Probably possible to get inspiration from bitmap's Edit recording comments script, should also look into somehow reusing kellnerd's guess punctuation code.

"Search & replace" could be added later, depending on use and use cases. Could also possibly be extended to some other pages (e.g. from works). We should probably use title/comment as displayed on the page rather than making API requests to get that information, but if API requests are necessary, we can use a similar strategy as my script that shows linked releases on recordings in the tracklist.

[vzell]

Hopefully it could be extended to "Events" too ... I have more than 3500 Springsteen events where the event name also consists of dates and additional info - https://musicbrainz.org/artist/70248960-cb53-4ea4-943a-edb18f7d336f/events

[ROpdebee]

Springsteen must be one of the best-documented artists on MB… 422 pages of recordings and 35 pages of events, 🤯

Events are probably possible, I'd say as long as it's a "simple" edit (names, disambiguation comments, etc.) and the information that needs to be edited is displayed on the page, the process to batch-edit them should be more or less the same. On the other hand, editing recordings' artists, events' places, etc. would be much trickier, since that requires linking separate entities together, some way of searching those entities, potential "credited as" things, etc.

Off-topic: Did you manage to score tickets for the upcoming tour?

[vzell]

I'm editing Bruce stuff now since more than 10 years ... and yes I have tickets for 6 shows ... 4 in Germany and 2 in Netherlands between 110 and 150 Euro
I'm living in Germany btw

[vzell]

I forgot .. you mentioned "simple edits" .. would be fine for me

[kellnerd]

I don't know if you are aware of it, but I have already implemented a userscript to batch edit release groups last year, but it still lacks a proper UI and some additional safety measures. That's why it is hidden in a feature branch and not mentioned in the README (and only chaban has already been using and testing it AFAIK).
The plan was to extend this to batch editing for all entity types once there is a better UI (including advanced features such as search & replace), but I haven't really pursued the idea so far. Maybe I should finally continue working on it this summer...

Edit: I have finally created a GH issue with my unstructured notes/ideas for the script.

[ROpdebee]

I was aware of it, but I didn't know you were planning on extending it to other entities. It seems like quite an ambitious project, with a much broader scope than what I "envisioned" for this one. My idea for this was to limit it to simple free-text attributes (mainly title and disambiguation comments) and some established bulk-editing tools (search & replace, guess case, guess punctuation) to quickly perform some otherwise cumbersome edits. Your ideas seem to go far beyond that, with multiple choice fields (dropdowns, checkboxes, etc.) and rule-based transformations.

A userscript that implements your ideas would clearly be a superset of mine, and vastly superior, so co-existence probably wouldn't make sense. On the other hand, mine would probably be substantially easier to implement (but still not easy!). Perhaps it'd also be a bit easier to use because of the limited scope, your advanced batch editor could have somewhat of a steep learning curve (although it's impossible to tell until it's fully implemented).

I'm not invested into this yet, I've only done a bit of investigation and wrote down a couple of declarations to get a basic skeleton going. So I have no problem in transferring this to you if you want. But if you'd be OK with it, I also wouldn't mind implementing the limited scope script and eventually deprecating it and pointing users towards your script once it's released. Just let me know what you'd be more comfortable with, as I really wouldn't want to be treading on someone else's prior efforts.

[kellnerd]

A few thoughts given that I still have to refactor/generalise the code a bit before I can continue with my roadmap and that you are usually faster than me writing new code. Somehow I have the feeling that this might end up one of the following ways:

1. I will take over this issue as a feature request for my userscript and it will potentially take longer until it will be addressed. Feels like thwarting you and raises the expectations for me to finally deliver something "usable"...
2. You are going to pick the useful parts from my current proof-of-concept implementation and rewrite them in TypeScript. Later I will then pick the useful parts from your subsequent work and port them back to JavaScript. Does neither feel efficient nor satisfying from a developer perspective...

Since I'm not really a fan of both options (but I have a slight preference for option 2 as I'm lazy): Maybe the time for more collaboration and/or a shared toolbox has finally arrived?

I would be happy to give you access to my repo, but I don't want to force you to abandon the whole toolchain which you have set up for your repo and to go back to writing JavaScript.
On the other hand I'm (currently) not very motivated to set up the whole Babel, Jest and CI/CD stuff for my repo (except for TypeScript itself, which is kind of overdue given the amount of JSDoc type annotations which I've written so far).
So I can totally understand it if you would prefer to start with a clean slate in TypeScript, which would probably be the quickest way to adress this specific issue.

Or should we finally try to set up a new repository with common utility functions for MB (and userscripts/ECMAScript in general) which we then would maintain together and install via npm?

[ROpdebee]

I don't have much time to reply, but I just want to say a couple of things off the top of my head before I forget them. I'll try to remember to post a proper response later.

shared toolbox

One thing that'd definitely fit in a shared toolbox is the edit submission part. Installation via npm would theoretically enable developing it in Typescript and doing the Babel stuff separately, so that you can use it as plain JS and I can use it in TS. You'd also have the type declarations in a .d.ts file so type-checking the JS could would still work.

thwarting you

I've got loads of open issues and (un)documented ideas for other scripts. guess lang hasn't seen any progress in a month, the TS rewrite of the rest of the scripts is broken in its current state and I haven't found the motivation to work on it, not to mention the new script that's in a local branch somewhere which I've been "secretly" using for the past month that I have yet to clean up and extend for a potential release. Add to that all the non-userscript projects that I'd like to start some time before the end of this decade, and you'd honestly be doing me a favour in taking the lead on this one 😅 I'd be happy to lend a hand if necessary though.

more collaboration

I'm always down for more collaboration. Developing MB userscripts currently feels like a very lonely/individual activity, and that's a shame. But I'd have a hard time giving up the toolchain I've set up. Perhaps I should generalise it and put it into a separate repo so that people can pick and choose which things they want enabled (ESLint, Typescript support, Babel transpilation, etc.).

[kellnerd]

Add to that all the non-userscript projects that I'd like to start some time before the end of this decade, and you'd honestly be doing me a favour in taking the lead on this one

Well, that sounds exactly like me 😂 I also have an ever-growing list of things I'd like to code, especially since I've discovered MusicBrainz and BookBrainz, so I'm always happy to see other people having (had) the same ideas as me.

I'd be happy to lend a hand if necessary though.

Deal! Maybe the necessary changes to support recordings in my script will be trivial after all (I don't know for sure, it's been a year since I dealt with the raw edit data stuff), but if they aren't and I need help or more eyes, I'll ping you. Today it's too hot in my room to do serious work, but I'll probably give it a try during the next days.

But I'd have a hard time giving up the toolchain I've set up. Perhaps I should generalise it and put it into a separate repo so that people can pick and choose which things they want enabled (ESLint, Typescript support, Babel transpilation, etc.).

I definitely support the idea, just let me know when I can help with that. Having one repo for the toolchain and one for utility modules which can be used inside (MB) userscripts should lower the barriers (for both old and new developers) to create new scripts together.