This was prompted by a couple edits I did today, but also based on this ticket.
For many years, we’ve standardised “ft”, “featuring” and similar join phrases into “feat.”. This made a lot of sense when we were placing them all on the title for the time when we could do better (and it’s what powers this very useful report to allow us to migrate them now!). But does it make sense now, when we have proper artist credits and join phrases? We’re already not standardising any others (“con”, “with”, “avec” and the like). So why have a specific exception for “featuring” variants?
I don’t think there’s any reason inside MusicBrainz proper to do this anymore. I can see how having “feat.” only makes it easier for external users like Picard to manipulate the artist entry, but this isn’t ideal already as it is (since it’ll miss the aforementioned versions in other languages) and sounds like it would be fixable by just making the regular expressions a bit more open (@Fresosuggested something like /f(ea)?t(\.|uring)?/ might work).
Is there a good reason not to deprecate the requirement to standardise “featuring” variations to “feat.”?
Last time this was discussed (in 2013, by mail archive logs on Nabble), your (@reosarevok’s) argument was this:
However, since this “expand abbreviations” guideline was removed recently (in the last 1–2 years), that argument for special casing “feat.” isn’t valid anymore.
I feel like it’s been discussed since/more recently too, but I can’t seem to find this discussion (maybe it was on the old forums?). Anyway, I’ll not object to this change.
The standardization for picard tagging was a big part of that, but the other big part that wasn’t mentioned, is that often those terms are used interchangeably within the same release.
I have hip-hop releases for example that use “feat.” on the back cover; “ft.” on the CD and “featuring” in the booklet. This is probably more common than you think and also a major reason we picked the standardization.
I can see that being an issue, although I’d expect us to do the same as we would if a release had titles written differently in different places: just pick one.
This has been discussed many times in the past on the forums.
I am strongly opposed to this change.
Again it seems to be down to those that want to use Musicbrainz to help tag their collection versus those that want a database. That has been discussed before.
There are bigger issues there. I am aware that many of you seldom edit releases that have feat. artists but the big issue and only go after the low hanging fruit but the majority of releases I change it is all to do with feat. artist often releases that have every track with multiple feat. artists.
Last time a looked extensively at new content that needed featured artists added to musicbrainz about 70% were wrong. By wrong I mean feat. artist in the title. Featured artist in the artist! e.g. the artist was called “artist a feat. artist b”, etc, etc.
That is the thing to address reducing those numbers down. Prompting when they are entered in this way, etc.
For style there are other larger issues I see at play Anthology/2 in 1 releases, etc.
Like you say you are only interested in the later and that is the only reason it make sense for you. It makes little sense if you want a consistent music collection.We change many, many thing from the cover art before we put them into Musicbrainz as I sure you are aware. dumbing down to the inconsistent cover art makes no sense. Often digital releases have completely different versions to again it makes no sense to have these different through teh release group. I listed many reasons when this came up before but that was before your time on the forums.
Well with any change you have to go back and change all the other things and this takes resources away from other activities. This makes a ridiculous amount of work where it is not needed.
Maybe, just maybe some of those resources could be done in a more efficient manner hence the relevance.
How? It wouldn’t be particularly hard to tell Picard (assuming you’re using Picard) to change all cases of “ft.” etc to “feat.”. I’m sure there’d be a plugin made for it quite quickly if the decision was made. So we get to store what the release has and everyone gets to decide whether they want to tag like that or with “feat.”
Sure, but that’s also true of anything else on the titles or the artist credits, and we’re already supposed to enter them differently in that case. And it’s also true right now for different languages (a fair amount of Spanish rap prints “con” on the CD, but has “feat.” on iTunes, probably because it’s a more international marketplace). So why not make it fully consistent and not change this bit of the join phrase either?
Nobody would expect people to just go around and change every release. It’d work exactly as it does now: if you stumble upon a release that isn’t perfect and you have extra info, you can improve it. If you don’t care about changing it to “ft.” when it has “feat.”, you don’t have to, and that’s fine. If you’re not sure what’s printed, but it has “feat.” on the track title, just move it to the artist as “feat.” and nobody should complain, since it’s a very obvious improvement.
I didn’t say I’m “only interested in the later”. But it is definitely where my primary concern is, as you can relatively easily convert from various “feat.” variations back to “feat.” (e.g., doing s/f(ea)?t(\.|uring)?/feat\./, using the regular expression from the first post), but it is impossible to have a computer turn the “feat.” into whatever is actually written on the cover. (It could theoretically done by scanning uploaded cover art, but then it might have to decide between two different versions, e.g. between “ft.” or “featuring”, or it might read it as “tf” (f and t are some of the harder ones for computers to tell apart), or a range of other issues. And we’d have to have the cover art, in a good resolution and quality, first too.)
Anyway. Any points you may have stated in the past are irrelevant if they’re not brought up now. You and I may have been around for years, but new members of the community have just as much to say about this, and they should not be expected to memorise arguments they have never even seen.
Just noticed this bit. We already changed the bit where 2-in-1 are now compilations and have a relationship to link them to the separate albums (Anthology isn’t in because there wasn’t any sort of clear agreement on when to use it). Anything further than that on this topic would require (a fairly large amount of) code, and if we’re going to write a lot of new code, we have bigger things to deal with (e.g. finally implementing genres).
(since this is basically OT, let’s split it into a separate topic if you want to specifically talk Style priorities further though )
Join phrases are tricky. On the one hand, I favour following the release, so this change is good. For cases where a single release uses different forms, perhaps we should use a priority instead of “pick one” (whether that’s “prefer info from the booklet” or “prefer feat.” is a separate discussion).
On the other hand, join phrases (other than “,” and “&” anyway) are a problem for i18n. I feel like that should be addressed before opening up the most common one to all possible forms.
I don’t see how join phrases are a problem for localisation. If you want to localise release data, you should use a pseudo-release (and hopefully soon alternative track lists). Why localise only the join phrase?
Another example I just remembered for this (which shows these minor changes aren’t necessarily always about style):
This will mean we’ll have potential to improve a lot of “recorded in” relationships to show the actual credit (especially relevant when places change names). Do we expect people to immediately go change as many of those as they can find? Not really (although knowing some editors, I bet a few will!). Does it make it possible for future edits to store what the release actually has? Yup, and that’s more than enough IMO
We’re never going to have complete perfect consistency, but that’s also not the goal - it’s to store as much info as possible, in the most useful way (and I think Freso has already clarified why not standardising here stores more info than standardising without real loss).
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’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.
(Anthology isn’t in because there wasn’t any sort of clear agreement on when to use it). Anything further than that on this topic would require (a fairly large amount of) code, and if we’re going to write a lot of new code, we have bigger things to deal with (e.g. finally implementing genres).