Re: [mb-users] Should "vol." always be expanded? -- intent?

Frederic Da Vitoria <[email protected]> Fri, 5 Sep 2014 10:13:41 +0200
Newsgroups gmane.comp.audio.musicbrainz.user
Message-ID <CANe_y9ReiNQcHKZe_BNAGX3-Cbt-u5YBUejzpDrQBvVi-OqCHQ@mail.gmail.com>
--===============0242676321==
Content-Type: multipart/alternative; boundary=001a1134d11404f52505024d0dcf

--001a1134d11404f52505024d0dcf
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

2014-08-28 14:28 GMT+02:00 lixobix <[email protected]>:

> I accept that these are established style principles. I'm just not so sur=
e
> why the notion of standardising the actual text on the release cover etc.
> came to be. I can accept that in a proper series, it could be more
> satisfying to have the ", volume" part the same for all, but not so much =
in
> cases such as "Greatest Hits" "vol. 1" and "vol. 2". I'm particularly
> against it when there is only one release, such as the one at hand here,
> which nevertheless contains "vol." or "pt.". There's no real justificatio=
n
> for standardisation in that case, other than wanting one standard across
> the
> entire database, which is not necessarily desirable to everyone. Moreover=
,
> if a user wants such abbreviations expanded, I'm pretty sure that can be
> achieved in Picard through scripting; but once the data is entered to MB =
in
> a standardised form, the opposite can not be achieved for those who want
> it.
> So in that respect certainly, there is an argument for "as on the cover"
> data entry, which highlights one of the negative aspects of
> standardisation.
>

It may be for sorting reasons: if there is a "vol. 2", then there is a 1
and if 1 is printed as "volume 1", it would end up sorted after 2. Minor,
but I can understand some users wanting a properly sorted display. Of
course, for correct sorting, the standardization needs only be at the level
of the series, but if we wanted to allow a different standard for each
series, it would make the style guide probably much more complicated.

--=20
Frederic Da Vitoria
(davitof)

Membre de l'April - =C2=AB promouvoir et d=C3=A9fendre le logiciel libre =
=C2=BB -
http://www.april.org

--001a1134d11404f52505024d0dcf
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">2014=
-08-28 14:28 GMT+02:00 lixobix <span dir=3D"ltr">&lt;<a href=3D"mailto:arjt=
[email protected]" target=3D"_blank">[email protected]</a>&gt;</span>:<br><=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
 #ccc solid;padding-left:1ex">I accept that these are established style pri=
nciples. I&#39;m just not so sure<br>
why the notion of standardising the actual text on the release cover etc.<b=
r>
came to be. I can accept that in a proper series, it could be more<br>
satisfying to have the &quot;, volume&quot; part the same for all, but not =
so much in<br>
cases such as &quot;Greatest Hits&quot; &quot;vol. 1&quot; and &quot;vol. 2=
&quot;. I&#39;m particularly<br>
against it when there is only one release, such as the one at hand here,<br=
>
which nevertheless contains &quot;vol.&quot; or &quot;pt.&quot;. There&#39;=
s no real justification<br>
for standardisation in that case, other than wanting one standard across th=
e<br>
entire database, which is not necessarily desirable to everyone. Moreover,<=
br>
if a user wants such abbreviations expanded, I&#39;m pretty sure that can b=
e<br>
achieved in Picard through scripting; but once the data is entered to MB in=
<br>
a standardised form, the opposite can not be achieved for those who want it=
.<br>
So in that respect certainly, there is an argument for &quot;as on the cove=
r&quot;<br>
data entry, which highlights one of the negative aspects of standardisation=
.<br></blockquote><div><br></div><div>It may be for sorting reasons: if the=
re is a &quot;vol. 2&quot;, then there is a 1 and if 1 is printed as &quot;=
volume 1&quot;, it would end up sorted after 2. Minor, but I can understand=
 some users wanting a properly sorted display. Of course, for correct sorti=
ng, the standardization needs only be at the level of the series, but if we=
 wanted to allow a different standard for each series, it would make the st=
yle guide probably much more complicated.</div></div><div><br></div>-- <br>=
Frederic Da Vitoria<br>(davitof)<br><br>Membre de l&#39;April - =C2=AB prom=
ouvoir et d=C3=A9fendre le logiciel libre =C2=BB - <a href=3D"http://www.ap=
ril.org" target=3D"_blank">http://www.april.org</a><br>
</div></div>

--001a1134d11404f52505024d0dcf--


--===============0242676321==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
MusicBrainz-users mailing list
[email protected]
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-users
--===============0242676321==--