I'd like to second Nikki's arguments in favor of this AR type and the
new release type (Virtual, or whatever alternative name we end up
with). The data is there already, we want to use it eventually,
forbidding it won't work, and we'll just end up having to re-enter the
data if we start encouraging editors to delete it.
The difference between these transl(iter)ation "releases" and the
Billboard and other playlists, is that these are an attempt to describe
releases that actually do exist (within the limitations of the current
DB schema). I won't belabor this point, I think Nikki has done an
admirable job of arguing for it.
As for the "worst possible solution" of having PUIDs, DiscIDs, etcetera,
scattered across multiple real or translated releases; I agree that this
is not ideal, but until the NGS is actually implemented, it seems better
to capture the additional (and difficult to generate) data on
transl(iter)ations this way than to throw it away entirely. I will note
that there is clearly significant editor interest in creating and
maintaining these trans(liter)ations, especially for Asian releases, and
I'm sure that Nikki's estimate of thousands of entries is not far off
the mark. Once we have NGS, we can simply merge the virtual entries
into the real releases (although there will be some cases where there
are multiple physical releases that are translations of each others
titles, not sure how NGS deals with this, although I'm sure it is
effectively addressed). I know that it's hard to argue against both of
the two most significant developers when they think something is a bad
idea, but I'm 100% with Nikki on this, and there are definitely other
automods (Orion for sure, probably others) who have strong feelings on this.
To address the specifics of the proposal:
A prior iteration of this discussion had proposed an "official" link
attribute, and I pointed out that this was a property of the release(s)
in question, and not the trans(liter)ation AR; once this was removed,
there wasn't much difference between the two directions, and I suggested
symmetric relationship names for the two directions since for the
purpose of internationalization, it doesn't actually matter which one is
original and which is a translation - you just want to display the one
that best matches the languages/scripts the user is willing to accept.
However, given the number of MB editors who seem to prefer "original
titles, no matter whether I can read or even display them" I can see
some benefit to having an "original" directionality.
Deciding which are the "original" titles when there are simultaneous
official releases with titles in different languages will be tricky, but
I guess that's what we have editors and voting for. Chris B's
suggestion to use the actual language of the songs is a reasonable
guideline for songs, although it doesn't help for musical works without
words (instrumentals). There are also probably some cases where there
are multiple different translations entered in the DB, but the originals
have not actually been entered (e.g. a release with Amharic (Ethiopian)
and (translated) English titles on the cover, where only the English has
been entered, the English titles are not really the "original" for a
French translation). [Note for Nikki - do we actually have any Amharic
script entries?] The "song language" guideline doesn't help settle the
originality of different script versions for the same language (e.g. a
Serbian album with Cyrillic and Latin script versions). However,
regardless of what obscure corner cases I can come up with, I am
convinced that having an "original" directionality is, on balance, the
better solution (especially since it makes it explicit how one should
avoid relationship clusters).
So I would second Jason Salaz's improvement of:
<a> is the original language/script track listing of <b>
<b> is an alternate language/script track listing of <a>
As for the need for a "Virtual" release type attribute - the original
purpose of this was to avoid overloading the "Bootleg" (or "Unknown")
release type for user-provided transl(iter)ations - my original mail at
http://lists.musicbrainz.org/pipermail/musicbrainz-style/2006-July/003380.html
has other ones as well: to segregate this information in a different
part of the discography, and to identify cases where there is actually
only one real release; in many cases there are multiple official
releases (possibly with different DiscIDs, even though the track order
and audio data are identical) which contain transl(iter)ated titles that
can be used for internationalization.
As for the name of the release type, "Virtual" is not ideal (and
probably encourages entry of things like playlists that we don't want).
However, "Translation/Transliteration" or "Trans(liter)ation" is rather
confusing, and having separate release types for "Translation" and
"Transliteration" creates redundancy and the possibility of
inconsistency, since whether it is a translation or transliteration is
already determined by the languages/scripts of the two releases: if the
languages are different, it is a translation, if the languages are the
same but the scripts are different, it is a transliteration, and if both
the languages and scripts are the same it is a "transcoding" to work
around Unicode issues or something similar.
As a least worst alternative, I would propose that the new release type
be named "Alternate language/script titles" - this makes it clear that
it is only to be used for this purpose, and while verbose, at least
matches the wording in the AR links where it is intended to be used.
Finally, on the subject of using the AR and release type for transcoded
titles to work around Unicode issues and so forth, Nikki suggested that
we accept, but not encourage these until we have tagger script support.
I agree entirely with Nikki's suggestion, but given the strong opinions
of the lead developers about this I am perfectly willing to exclude this
type of alternate title explicitly, since the information that is lost
by deleting such entries is easily recreated by practically any editor
(unlike the information lost by deleting transl(iter)ations, which
require editors with specific language skills to recreate).
@alex
--
mailto:[EMAIL PROTECTED]
_______________________________________________
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
