The problem with this proposal is that it is _extremely_ Anglo-centric, because the recording and release group guidelines are extremely Anglo-centric.
If this proposal is to pass, I'd like to see... 1) Abbreviations should _not_ be expanded by default for countries where English is not the primary language, not least because it is sometimes hard to determine what the abbreviation actually stands for. (e.g., "fw", which I've seen converted to a generic "feat."). Ideally, I'd like see a stop to expanding "Vol." by default for non-English releases as well (I still support separating it from the main title with a comma, since the indication of a vol* number is usually a font/size/color change) 2) Extra title information should _not_ always use parentheses. This is only bringing this bullet point of the recording guideline in line with the "subtitles" bullet point: If there is an alternative dividing punctuation mark such as the question mark (?) or exclamation point (!), use that mark instead of the colon. (The specific punctuation marks I have in mind here are the wavedash; hyphen; full-width space in languages which don't normally use spaces.) Basically, if the passage of this proposal would in any way change the following: http://musicbrainz.org/recording/26089c8d-00d0-416c-95c2-ffc80b46ae3f ("feat. Artist" in this title essentially means "Artist version". There is no artist "featured" besides the primary artist, which is credited in the artist field.) http://musicbrainz.org/recording/a6f86c39-839b-4b24-b430-250a60832711 (ETI punctuation) http://musicbrainz.org/recording/7a98b745-cb1b-43f3-b95b-5207ed4f4adf (ETI punctuation) http://musicbrainz.org/recording/3dc62741-2e50-4489-86eb-b0de9d3d3242 (Japanese track, consistent original data, etc.) http://musicbrainz.org/recording/1b3e1dc6-c3f8-4931-82e2-f5b3cbb7d224 (Japanese track, consistent original data, etc.) http://musicbrainz.org/recording/4c144e39-be2e-488d-b10d-d7c4b93c53cd (Japanese track, spacing) Then I veto this, and will of course support any revisions which preserve the above examples. (this isn't a comprehensive list by any means - they were merely the first things I could think of quickly) And yes, Musicbrainz is a database and "normalized" or "standardized" data is a good thing - but if you change the data such that it is useless to its intended audience (e.g., a customer who actually has the CD in-hand), or spelling differences so huge that someone searching for the data using text readily/commonly seen on the internet and in stores has difficulty getting results in a Musicbrainz search, then you've made the database useless through guidelines which are too aggressive in scope. This isn't "user preference", it's about _maintaining_ consistent data in the given examples. On Mon, Aug 8, 2011 at 10:21 AM, Andii Hughes <gnu_and...@member.fsf.org>wrote: > 2011/8/8 Lukáš Lalinský <lalin...@gmail.com>: > > On Mon, Aug 8, 2011 at 3:21 PM, jesus2099 <hta3s836gzac...@jetable.org> > wrote: > >> LL> It's been more than a week since the RFC and to my surprise there > has > >> LL> been only one negative feedback, which I don't think is justifiable, > >> LL> because it ignores the basic problems that motivated me to propose > >> LL> these changes, which I mentioned in the initial email. All MB > editors > >> LL> I know, except for jesus2099, agree with these changes. So, > >> LL> considering the +1s I got on the ML, here is the RFV. > >> > >> -1 > >> VETO ← WCBI. > >> > >> ☞ Please tell me what were your « basic problems » that I « ignored » . > >> The gmane links given give me a big text I thought I answered but please > >> extract the points that I did not. > > > > 1) You did not understand why is having two style guidelines for > > track/recording is more difficult. You argued that if somebody enters > > normalized track titles, somebody would have to fix them to match the > > cover, which totally misses the point. > > > > 2) In the first post I explained how using as-on-cover track titles > > effectively removes an important feature that MusicBrainz had since > > the beginning. Normalized track titles are THE feature that brought me > > to MusicBrainz and I believe the same is true for many people. With > > as-on-cover track titles we lose this feature, because recording > > titles have no direct relation to the release, and so they miss the > > release context. > > > > It certainly is for me, and pretty much the point of a database is to > store consistent normalised > data so it can be used for interesting retrieval purposes. > > >> Here I recall my basic problems : > >> > >> I’m against this merge that appears to make us loosing titles as they > are on > >> φ releases and we’ll end up with altered titles (inserting foreign > >> abbreviations like “feat.” in our titles, Using Funny Caps etc.) which > is > >> bad when we know a title is being *consistently* in a certain different > way > >> that is not matching some people’s personal preferences. > > > > It's not about personal preferences, it's about having consistent data > > in the database. > > > >> We are also setting informative text in recordings that will have now to > go > >> down to tracklists and that’s a real pity IMO : “がいながてや (live, > 2009-12-29: > >> Tōkyō JCB Hall, Japan)” ← we don’t want to alter the tracklist this way, > >> it’s totally different from φ release. > > > > There is no style guideline that says to do this. > > > >> This is why I VETO this RFV-333, maybe I didn’t understand anything when > I’m > >> flooded with tons of emails though. > > > > Then you should read only the two mails starting each thread, they > > explain every reason why I believe this change is necessary. > > > > Is there anything more to this veto than just personal taste? > > > Lukas > > > > _______________________________________________ > > MusicBrainz-style mailing list > > MusicBrainz-style@lists.musicbrainz.org > > http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style > > > > -- > Andii :-) > > _______________________________________________ > MusicBrainz-style mailing list > MusicBrainz-style@lists.musicbrainz.org > http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style >
_______________________________________________ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
