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.
1 Like
Track level artist credits are “local” to the pseudo-release/tracklist they’re given for. E.g., compare
and
1 Like
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.
3 Likes
But they are.
Yes, but not as aliases. E.g., 崎元仁 - Aliases - MusicBrainz 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.
1 Like
Following up on last night’s meeting, I’ve now filed two issues with picard-plugins related to this STYLE proposal:
1 Like
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.”.
1 Like
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.
1 Like
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 
1 Like
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?
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.