New plugin: standardise "featuring" to "feat." about picard-plugins HOT 9 CLOSED

That's interesting! Maybe an even simpler strategy would be to ignore the join phrase entirely and replace it with "feat."? Or would that be too broad, since it would also muck up just plain "and", which isn't quite the same thing?

from picard-plugins.

I'd like to ask people who will eventually create this plugin, how would the regex interact with the mb data? For example, what happens if the artist has a word "featuring" in their name? Would it be standardized to feat. as well?

As far as am I aware, there is no way to directly interact with only join phrases, you interact with the whole tag field, such as artist, title, etc. Technically, you could compare artist(s) to album artist and then strip the join phrases, but it would only work with one additional artist and would need an exception for VA, so I guess it's not really a reliable way to do it this way.

So I was wondering if there could be a way to interact directly with the join phrases, because it seems like they are stored separately (I get that impression looking at AC in MB). With the current task at hand, I think it could be beneficial to introduce own field for the join phrases so one could manipulate them easily (assuming there isn't a method for this currently). I would like to interact with join phrases mainly because of the capitalization issue I ran into recently (as mentioned in my post here: https://community.metabrainz.org/t/request-for-feat-standardising-plugin/215957/2?u=culinko).

from picard-plugins.

The plugin would be able to access the raw data sent my musicbrainz server which includes a list of both artist names and joining strings.

So the plugin would look only for (say) [" featuring ", " feat. ", " ft. ", " f. "] in the join string and replace these with a standardised string " feat. " (which could be chosen by the user).

So if there was an artist called "Peter Featuring" that would not be changed.

I know we have this issue, and the community thread, but what we really need is a JIRA enhancement request or two. Perhaps @Freso could raise one for the Standardise Featuring plugin and allocated it to me, and perhaps @culinko could create one for making Title Case plugin respect join phrases for Artist.

(As an aside, I note that Title Case plugin acts on track name, album name and track artist but not album artist or sorted versions etc. So a bit more analysis needed to decide which metadata needs title casing. It also registers as both an Album and Track processor - not sure if this is correct either.)

from picard-plugins.

@sampsyo That wouldn't work, no. Keep in mind that for "{Artist 1}, {Artist 2} & {Artist 3} plus friends" all of ", ", "&", and " plus friends" are 'join phrases', so your suggestion would end up with "{Artist 1} feat. {Artist 2} feat. {Artist 3} feat. ".

@Sophist-UK You're very welcome to open tickets in Jira yourself, esp. since I'm not 100% sure what you want to open a ticket for. :) (Note that "tickets" for Picard plugins do not really belong in Jira, which is why I made an issue here instead of a ticket there. If you need some feature in Picard itself to make it easier to handle these plugins, then yes, Jira is the place to be.)

from picard-plugins.

I created a ticket in JIRA for the Title Case plugin improvements and while I was writing it, I thought of a something that could help with the upcoming feat. standardization plugin as well. What if plugins had options inside Picard so you could customize them according to your needs? Each plugin would just get a settings page where there would be some checkboxes, true/false radio buttons or text boxes which would then change the plugin contents accordingly. The plugin would just list how many buttons/checkboxes/text boxes to display, the text to be displayed alongside them and what would they change about the plugin if you modified them, and so on. For example feat. standardization plugin would list all the join phrases and you would tick which ones you'd like to convert to "feat." and which ones would be left as-is. I am not sure how to write such plugin and the groundwork might not be there yet in Picard, but I'm pretty confident it can be done and that it would greatly benefit advanced users with customization and smoothen the workflow.

from picard-plugins.

@Freso Hmmm ... I accept that JIRA is not currently used for plugins, but perhaps it should. Picard plugins is AFAIK the only exception to this at the moment. But JIRA is (IMO) the best place to log to-do items.

from picard-plugins.

@culinko It is possible to write plugins which have options pages - lastFm for example. But it is much more difficult and time consuming to do this. So the philosophy for plugins is somewhat Unix like - they do a single job and users can pick and choose which plugins they want.

from picard-plugins.

@Sophist-UK I think it makes more sense to track picard-plugins issues here, but I've put the topic on next Monday's meeting schedule. If you can make it to the meeting, that would be great.

from picard-plugins.

I will try to make it on IRC.

My thinking around this is based on the following:

Originally plugins were for enthusiasts - the was a wiki page and you could add your own plugins to it, but largely you had to host your own downloads and it was all pretty informal. And users had to download and install the plugins themselves, which required some technical knowledge but still informal. And if the plugin didn't work the user could try to fix it themselves or contact the author or just forget using it - and this didn't impact on Picard's own reputation.

Then we added better plugin functionality in Picard for downloads and installs and updates, and a Github repository with workflow for hosting the plugins and a formal web page for listing them - and suddenly it was easier for every user to install plugins and a greater need for the plugins to work reliably (or impact Picard's reputation) and now there is a greater need to manage this process just like Picard itself. So I believe that it makes sense to use Jira as a common repository of what needs to be worked on - and I can see the whole list of my own To-Dos in one place.

That said, Github issues would still work, so I am not wedded to using Jira.

from picard-plugins.