Guidelines on "feat." join phrase [STYLE-671]

Tags: #<Tag:0x00007f0508779b88> #<Tag:0x00007f0508779a48>


If the title has a possibility of changing when being entered into the Musicbrainz database, would it not be better to add a recording/track alias type that is specifically what was on the released material/CD-Text/online-webpage? I agree that the having the original track name would be helpful, but this seems the responsibility of some other field, something that is explicitly there to preserve the original formatting.


This feat. guidance never made sense to me. Why just this one word in this one language? There are synonyms in English and God knows the French (etc.) have a word for everyone of ours. Anyway, I say as on the cover like every other word/language.


I think that part of the reasoning was based on pre-NGS logic, when people were thinking

  1. If we standardize it, it will be machine-readable later, or
  2. At least we’ll be able to find them easily later (for conversion to Artist Credits).

(edit: Of course, there are also people who simply liked the standardization.)


I’m sure you are right. I have heard that defense before. It didn’t make sense to me then either. The English language wasn’t different then (many similar words with like meaning) but, IIRC, editors did apply feat. more liberally (e.g. replacing synonyms like “with” with “feat.”). Since MB AC, it seems that the rule is applied more/most strictly. I think, to get around this rule! That makes even less sense to me. Why just this one word in this one language? If there is some important concept here that should be modeled, it should be done in a language independent way.

MB should just model the truth and let consumers adapt. Picard seems malleable enough to be able to bend the truth, in this regard, to individual likings.


Yup! That was quite useful for stuff like this report (since I’d say being able to find them and move them to the artist credit is more useful than knowing the exact phrase used). But I’d definitely agree that now it’s lost its uses since any new additions can be linked as artists already.


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., 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 :slight_smile:


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 :slight_smile:


The blog post is out and this is now official.


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.