Today we’ve released several changes decided at the recent MusicBrainz Summit:
- German, French, and Dutch translations are now usable on the main server, via the language menu at the top right of any page. Previously these were only accessible on the beta server. Don’t forget to help contribute on Transifex if you find any issues in the translations. You can also help translate some of the less-complete languages over there.
- “Add relationship” edits have been made auto-edits for everyone. By a recent calculation, only 0.78% of these have been canceled or voted down, yet they make up a large percentage of our open edits and are easy to remove.
- “Add release” edits have been made auto-edits for everyone. Since releases added to MusicBrainz are available immediately through the website and web services, there’s no telling where the MBIDs are being used. Permanent and reliable IDs are a core tenet of MusicBrainz, so duplicate releases should always be merged to avoid MBID loss, not voted down or deleted. I’ll be looking at ways to better detect duplicates during the add-release process, though.
- “Add release label” and “Remove release label” edits have been made auto-edits for everyone. Like the previous two edit types, release label additions are among the most common types of open edits, and are rarely canceled or voted down. Release label removals are also easy to revert because all of the removed data is contained in the edit.
- UPDATE 2015-12-03: It was neglected to mention here that “Edit release label” edits were also made auto-edits, since they are equivalent to a removal plus an addition. For statistics, see the comments at MBS-8666.
In addition to the above changes, Roman Tsukanov has added some new reports, and we’ve fixed a few editing bugs.
The git tag today is v-2015-11-16 and the complete changelog is below.
Bug
- [MBS-8607] – JSON-LD has bugs
- [MBS-8612] – 404 page has incorrect/outdated menus
- [MBS-8614] – Release merges can fail if a recording is both a merge source and merge target
- [MBS-8615] – Non-conflicting mediums appended after a release merge is entered block the merge
- [MBS-8620] – Can’t add an example to an Artist-Series relationship
- [MBS-8623] – Duplicate checker entity list lacks a space between name and disambiguation
Improvement
New Feature
- [MBS-8489] – Report for all entity.disambiguation = entity.name
MetaBrainz Blog 
Nice! Glad to see some auto edits coming in. And definitely +1 on the checking for duplicates thing.
I’m glad to see that the translations are finally live on the main server. I really hope other Dutch-speaking users like my Dutch translation, though I’m sure there’s a lot of room for improvement.
However, I’m a bit reluctant to tell users to just sign up for Transifex and start fixing things. Transifex doesn’t seem to have any way to see which strings a user has changed, and many seemingly obvious improvements might not work in the wild. In short, I’m a bit afraid that many well-intentioned cooks will spoil my broth without me noticing. That may sound a bit petty, but I’ve been cooking this for the past three years!
So if you see anything wrong with the Dutch translation, please post about it on the forum first. I read it almost every day, and often more than once per day.
Thanks for the internationalisation online !
I had the same thoughts as **mfmeulenbelt** for french translation.
Transifex seems hard to me to get consensus and discussions on.
I have suggested a french forum topic, I think it’s up to me to create it if nobody does it beforehand.
http://tickets.musicbrainz.org/browse/MBS-6759?focusedCommentId=37575&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_37575
I will do as soon as I have at least a few remarks but please do it before me if you already have something to submit to the discussion : **Lâchez‐vous, faites péter les remarques.**
Here is for a start : MusicBrainz en français (internationalisation / Transifex) http://forums.musicbrainz.org/viewtopic.php?id=6081
I’m not against more auto-edits, but making ‘add release’ one seems extreme.
In my personal case it means I’m no longer going to be checking over some new editors edits. In the past I would fix their mistakes and give advice, maybe up to 5 hours worth of unnecessary fixing and work on my part (to avoid discouraging with no votes), and then if they still wouldn’t change habits, start voting no. That would force them to clean up their act and then they’d eventually catch on/ do better on their own. Now I’m expected to have to merge and then fix things indefinitely, largely on releases and artists I don’t care about… It’s too much workload and since there’s nothing else I can do, I’ll probably just unsubscribe from these harmful editors instead.
This isn’t something that happens that often but I thought I should mention it anyway 🙂
And cancelling release re add was the immediate way for fixing for us non auto mods. We have lost that now, our power decreases. 🙂
I hope nothing’s changed regarding the ability to help newbies, or the amount of work you are/aren’t expected to do on any releases other people submit. But I’ll be attentive to any issues people think have cropped up as a result of this.
Editors who consistently submit bad data can still be reported to the admins to have their auto-editing privileges disabled (and the next server release will make it easier to report users), but I’d only expect that to be done in cases where they’re making the data worse.
Regarding it being faster to cancel and re-add botched releases, I plan to (hopefully) work on http://tickets.musicbrainz.org/browse/MBS-1880 soon.
After fixing 23 pages worth of bad additions from here over the weekend:
https://musicbrainz.org/user/pheonyx74/edits?page=23
I had just applied the “you haven’t listened to me or others, from now on just at least give a source and title things correctly, or it’s a no vote” clout, when this change came through.
I’m not sure what’s meant to happen in this situation now. I’m probably done fixing or merging his releases though (once I’ve finished the ones I’ve started, see https://musicbrainz.org/user/aerozol/tags )
This blurry line is the case with most new editors, it’s pretty hard to actively ruin data, but more than easy enough to just put in things following personal convention and ignore emails.
Honestly, I don’t run into this much, most editors either aren’t prolific enough to worry about, or more than happy to follow guidelines, but in this case I’m going to just unsubscribe, all I’m voting on is album art additions anyway.
In any case, if we’re interested in having a database with high quality data in it, these kind of edits represent a ton of future work and research for someone else.
This doesn’t mean I’m hyper critical of this change, but it definitely changes how I’m going to interact with MB so that’s a current user case for you 🙂
**Allow an editor to apply edits without voting within a short timeframe after his/her ‘add release’** (MBS-1880) : great.
Thanks Bitmap ! 🙂
I’m in the same position as aerozol is.
I’ve stopped using subscriptions a few years ago. My main investment in review/vote was to monitor all new releases in my subscribed artists. This activity was requiring quite some time: checking, asking for more information, fixing, merging duplicates release-group, completing missing information, rejecting unidentifiable release added by editor who don’t care about replying to request for more information, …
Now all this activity is not possible anymore, and I really fear that it will end in lowering the quality of the database.
What also really bothers me, is that this decision, that has a lot of consequences, has been made without consulting the community (I mean the community that is actually editing, not the one present on IRC). A survey would have been great…
I agree with the comments above. Since I opted out of receiving subscription emails in an effort to reduce the amount of emails I get from MB, MBS-8387, MBS-8389, MBS-8596 mean that I will see and fix many more bad edits. I don’t really see how that can be positive for data quality and I wouldn’t have applied these 3 controversial changes at the same time and without consultation.
Me too. (Is that still a thing, now that AOL is ancient history?) I was having that same experience with a lot of new releases for Various Artists. I doubt that this will improve quality or communication there.
For what it’s worth, bitmap is working on a toggle for http://musicbrainz.org/edit/subscribed so that you can choose to show only open edits, or all recent edits. For people who mostly check their subscriptions from there, that should make stuff visible again.
Murdos: “My main investment in review/vote was to monitor all new releases in my subscribed artists” That’s definitely possible still 🙂 Edit search: “Type Add release, Created after n days ago depending how recent you want them, Artist is in my subscriptions” should show them all.
@reosarevok: Yeah, but how can I make the releases I’ve already reviewed disappear from the list? In the end it just makes reviewing harder.
We had not enough votes in MusicBrainz? Soon you’ll have even less votes.
I’m not sure exactly what problem you’re trying to solve, but it seems that it will generate other problems (like lowering data quality of database).
I also think that making “add release” an auto-edit is a bad idea. This was a way to get users to improve their entered data and also to block clearly bogus releases from being added to MB. How is this a good thing, that edits like these get automatically a pass: https://musicbrainz.org/user/jimbo1954/edits?
I can’t actually believe MBS-8387 passed, seeing there were only 2 votes for and all of the comments (also 2) against.
@sults, I don’t think it was actually possible for users to “vote against” MBS-8387, unless I’m mistaken. I’d classify that as regrettable.
Apparently it was neglected to announce that voting was also removed from “edit release label” because it was deemed “equivalent” to add and remove release labels. Have we not lost transparency with the community?
It was left out by mistake. I’ve updated the blog post to mention it now. If you’d like to see the rejection/cancelation ratios for those edit types, see http://tickets.musicbrainz.org/browse/MBS-8666