User:Reosarevok/Abbreviations vote

From MusicBrainz Wiki
Jump to navigationJump to search

Hi! Since there seem to be opinions on all sides for the "should we keep expanding abbreviations" debate, I'm going to run a wider vote to see what people think. I'll take a look at the results at the end of January or start of February and take a decision with the info :)

Please choose one of the options below for each pair, and "vote" by signing under it (using the "your signature" icon). If you only have an opinion on one of the two issues, then feel free to vote just once! Feel free to add any comment with your vote, but please use either the mailing list or the forum for any discussion longer than just a vote comment.

Discussion: http://comments.gmane.org/gmane.comp.audio.musicbrainz.style/19445 / http://forums.musicbrainz.org/viewtopic.php?id=5469

There are two related, but independent, discussions here:


Expand all abbreviations

Keep all as is. "Pt." should be expanded to "Part", "Vol." should be expanded to "Volume" (or its language equivalents), etc.

  1. Murdos (talk) 06:45, 23 January 2015 (UTC)
  2. Sc-content (talk) 08:22, 23 January 2015 (UTC)
  3. There's more to abbreviations than just part numbers. It also applies to things like "inst.", "RMX", or "alt. take" – which didn't turn up in the discussion – where consistency is king. KRSCuan (talk) 08:13, 23 January 2015 (UTC)
  4. Dainis (talk) 09:52, 23 January 2015 (UTC)
  5. mr_maxis 15:25, 23 January 2015 (UTC)
  6. Consistency for clean data, although I'd prefer keeping everything unexpanded. Leo Verto (talk) 16:00, 23 January 2015 (UTC)
  7. Rovastar (talk) 16:28, 23 January 2015 (UTC)

Don't expand abbreviations

Keep things like "Pt." and "Vol.", if that's what the cover says.

  1. --Reosarevok (talk) 19:46, 22 January 2015 (UTC)
  2. JesseW (talk) 05:56, 23 January 2015 (UTC)
  3. -- abbreviations should be like they are on the release, but on the recording we should use mb-style, further I think that all this should apply to feat." as well (ie if it says "featuring" don't change it to "feat.") ~猫猫~~何? 11:13, 23 January 2015 (UTC)
    • Regarding "feat.", see [1] -- Nikki (talk) 04:47, 24 January 2015 (UTC)
  4. ListMyCDs.com (talk) 12:58, 23 January 2015 (UTC)
  5. — jesus2099 ♬ 14:24, 23 January 2015 (UTC)
  6. bflaminio
  7. Kepstin (talk) 15:50, 23 January 2015 (UTC)
  8. -- I think abbreviations should follow the booklet on releases and be expanded on recordings/works D4RK-PH0ENiX
  9. Follow the release. The guideline should only cover cases where a release is inconsistent itself (e.g. “Volume” on front, “Vol.” on spine. — Hawke (talk) 16:36, 23 January 2015 (UTC)
  10. Practik (talk) 16:44, 23 January 2015 (UTC)
  11. Freso (talk) 19:17, 23 January 2015 (UTC) — What 猫猫/D4RK-PH0ENiX and Hawke said.
  12. bgibbard voted for this at http://forums.musicbrainz.org/viewtopic.php?pid=29306#p29306
  13. I think we should treat them like all the other types of spelling variations we already don't standardise (more or less what I said in [2]). -- Nikki (talk) 04:47, 24 January 2015 (UTC)
    • You drew a lot of bad comparisons in that post (the paragraph beginning with 'We don't standardise "1" to "one"' – which is actually part of this discussion. Also, we (or at least some editors) do standardise "&" and "and" in artist credits, sometimes also in part numbers.

      But nobody would expand "The C.I.A. Is Trying to Kill Me" to "The Central Intelligence Agency Is Trying to Kill Me" because of that guideline. What it deals with are almost always Extra Title Information and Part Numbers. The one thing I could get behind would be getting rid of abbreviation style on the general level, but re-add it specifically to the guidelines on ETI and part numbers. There is merit to keeping those standardized to a degree.

      Also, I think that applying different naming rules for tracks and recordings (as per CatCat's suggestion) is a terrible idea and hardly workable in practice. KRSCuan (talk) 06:23, 24 January 2015 (UTC)

      • I guess "C.I.A." counts as an acronym, so I'll go with Lou Reed's "Dirty Blvd." as a secondary example that we wouldn't expand despite being an abbreviation. KRSCuan (talk) 06:32, 24 January 2015 (UTC)
  14. And continue to abbreviate 'opus' and 'number', regardless of what the track list, cover, or spine says. — derobert (talk) 09:19, 24 January 2015 (UTC)

Standardise titles for series

Allow keeping series standardised if inconsistent. If most say "Volume" then use "Volume" for all (same for "Vol." or "Tome" or whatever). So, in a series labeled as "Vol. 1", "Vol. 2", "Vol. III", "Vol. 4", "Vol. III" could be changed to "Vol. 3" (or Volume 3, if you voted to expand abbreviations, anyway).

  1. Murdos (talk) 06:45, 23 January 2015 (UTC)
  2. Dainis (talk) 09:52, 23 January 2015 (UTC)
  3. bflaminio
  4. Kepstin (talk) 15:49, 23 January 2015 (UTC) —although if the series makes a clean break between different formats at some point, the parts before and after the break should be standardized separately.
  5. Practik (talk) 16:44, 23 January 2015 (UTC)
  6. derobert (talk) 09:20, 24 January 2015 (UTC)

Keep titles as per the release

Keep the actual numbering and titling, even if their style changes through a series - series entities and series numbers already do all that's needed.

  1. JesseW (talk) 05:56, 23 January 2015 (UTC)
  2. — jesus2099 ♬ 14:24, 23 January 2015 (UTC)
  3. mr_maxis 15:25, 23 January 2015 (UTC)
  4. Hawke (talk) 16:35, 23 January 2015 (UTC)
  5. Freso (talk) 19:17, 23 January 2015 (UTC) ­— But use standardisation on release groups/recordings/works (incl. comment by Kepstin).
    • I think you're asking for a third option which standardises titles for series for some entities and keeps the original titles for others. If it's a release group series and you want to standardise release group names, you're standardising titles for the series. It was probably a mistake to say "release" in the section title. -- Nikki (talk) 04:47, 24 January 2015 (UTC)
  6. drsaunde (talk) 20:20, 23 January 2015 (UTC) - agree with Freso's caveats and would add standardise when there's inconsistency within the same release also
  7. Tentatively voting for this option, but open to some standardisation on a case by case (series by series? :P) basis. I could imagine some scenarios where it might make sense, but the real examples I can think of are already not standardised in the database. Nikki (talk) 04:47, 24 January 2015 (UTC)