2 posts were split to a new topic: Request for “feat.” standardising plugin
Mainly because they are not local to the pseudo-release/tracklist, and unlike aliases, you cannot set a locale or primary flag on them.
So there currently is no way to localise an artist credit in a way that links the various localisations.
Making Artist Credits more like first-class entities, with their own aliases, would allow proper i18n.
Track level artist credits are “local” to the pseudo-release/tracklist they’re given for. E.g., compare
That’s not what I meant. I meant that they’re not a property of the pseudo-release, but global values. They’re found on the involved artist’s alias tab.
If they were specifically tied to a pseudo-release, their locale could be inferred from that.
The other elent to my point is that when you configure Picard to use English artist names, that gets applied to ACs by using the component artists’ aliases. That leaves join phrases untranslated. Enabling artist credit aliases would allow for that to be set up properly.
But they are.
Yes, but not as aliases. E.g., https://musicbrainz.org/artist/53a2cda4-31d0-405e-8a9d-5027c2479ebb/aliases has one list for aliases and another for artist credits. The artist credits are properties of the Release Groups, Releases, Recordings, and Tracks that the Artist has artist credits on.
Look at the two releases I linked again. One is a pseudo-releases for/of the other release—and they have different artist credits given for the tracks, incl. join phrases.
Following up on last night’s meeting, I’ve now filed two issues with picard-plugins related to this STYLE proposal:
We actually have a plugin now! Thanks @samj1912
So expect changes here relatively soon
I dont quite understand the significance of this since I thought featured artist were now always meant to go into the artist credit rather than the title, so I wouldn’t think it was an issue for any new releases just old old ones that should be converted so that featured artists should be moved from title into artist credit anyway.
However, if it is an issue is it really enough to say we can change it now because we have a Picard plugin, what about MusicBrainz users/customers using different applications, there may be all kinds of code out there that rely on how it currently works. I would think it would be worthy of a blog post to make people aware of this pending change before it happens.
They are. The only change is to stop standardising stuff like “ft.” and “featuring” into “feat.”.
On artist credits, if thats the case then I agree it does make sense. But I have an option in my tagger to move featuredArtistsToTitle and this change doesn’t break that but it may break similar implementations, although it is not that major personally I think on balance that a blog post would be the right thing to do.
I was planning to do a blog post to notify people of the change (both data users and site users). That said, I’m not currently planning to do a pre-notice, just a “this has changed” notice. It seems like a minor enough change that we don’t need to tell people a month in advance, but not that minor that we shouldn’t post about it
What’s the guideline for capitalization? I’ve just started going through that report, and came across this release, where the join phrase on the cover is “Feat” – to me that looks like a style decision on the part of the graphic designer, but given that’s the only place join phrases appear (in contrast to artist names), do we still apply the same de-stylization rules and use “feat” instead? For that matter, we are still decapitalizing all-caps covers, right?
I’d lowercase it, because the artist credit is not a title.
Thanks! I knew some pages in the docs were getting a bit out of date, and I wasn’t sure if that was one of them.