[mb-style] RFC: Transliterations/translations, again!

[Nikki-12]

Hi,

I'd like some final comments on this relationship type's link phrases and
the general plan of action before I do a RFV.

Firstly, implement the relationship:
<a> is an alternate language/script track listing of <b>
<b> is an alternate language/script track listing of <a>

This relationship describes two track listings which are the same, but are
represented using different languages and/or scripts. It should not be used
for linking translated performances. Transliterations and translations
should be linked to the earliest official release to avoid clusters.

Once we have this, we should add the type 'virtual' to the release
attributes. I've already spoken to mo about this and he said he'll add it
to his restructuring proposal.

Some time in the future when we have NGS, these track listings can then be
grouped together.

-----

Quoting an email from dupuy last time this came up:
> 3. Question of transcoded releases (Unicode -> ASCII) and whether these
> should be encouraged or deprecated..

I think we should accept, but not encourage, these until we have tagger
script available. I suspect that many cases of "exotic" characters can be
easily automatically substituted with more acceptable ASCII versions by the
tagger itelf then.

--Nikki

_______________________________________________
Musicbrainz-style mailing list
Musicbrainz-style@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

[Jason Salaz]

On 8/7/06, Nikki <nikki@...> wrote:
> Firstly, implement the relationship:
> <a> is an alternate language/script track listing of <b>
> <b> is an alternate language/script track listing of <a>

Just curious, did you mean:
<a> is the original language/script track listing of <b>
<b> is an alternate language/script track listing of <a>
?

That would be the best pairing in my mind, because there /can/
potentially be any number of alternates.

> Once we have this, we should add the type 'virtual' to the release
> attributes. I've already spoken to mo about this and he said he'll add it
> to his restructuring proposal.

+1, sounds good.

> Some time in the future when we have NGS, these track listings can then be
> grouped together.

+1, again.  Ideally, all this data should be in the same release, and
a preference will dictate which language you view in.
I'm an original language purist, regardless of whether or not I can read it.
Some people are readability purists, or can use none latin characters.

I understand that it's a significant change, and will take time.  So
virtual releases are nice *in the interim* (and I already have my eye
on a TON of releases I can tag as virtual).

_______________________________________________
Musicbrainz-style mailing list
Musicbrainz-style@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

[Oleg Volkov]

Greetings.

Monday, August 7, 2006, 11:43:47 PM Nikki. wrote:
> I'd like some final comments on this relationship type's link phrases and
> the general plan of action before I do a RFV.
> Firstly, implement the relationship:
> <a> is an alternate language/script track listing of <b>
> <b> is an alternate language/script track listing of <a>

> This relationship describes two track listings which are the same, but are
> represented using different languages and/or scripts. It should not be used
> for linking translated performances. Transliterations and translations
> should be linked to the earliest official release to avoid clusters.

Just to make sure: am I correct that it also should not be used between real
albums, even if they are translations and should only link real and virtual
releases together?

--
Oleg "Rowaa[SR13]" V. Volkov // MB ID @gmail.com


_______________________________________________
Musicbrainz-style mailing list
Musicbrainz-style@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

[Nikki-12]

On Tue, Aug 08, 2006 at 01:03:40PM +0400, Oleg Rowaa[SR13] V. Volkov wrote:
> Just to make sure: am I correct that it also should not be used between
> real albums, even if they are translations and should only link real and
> virtual releases together?

I think it should still be used between real translations if the audio is
still the same. If the audio is different, the difference between the
releases is no longer just the track listing. :)

--Nikki

_______________________________________________
Musicbrainz-style mailing list
Musicbrainz-style@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

[Nikki-12]

On Mon, Aug 07, 2006 at 11:35:27PM -0700, Jason Salaz wrote:
> On 8/7/06, Nikki <nikki@...> wrote:
> >Firstly, implement the relationship:
> ><a> is an alternate language/script track listing of <b>
> ><b> is an alternate language/script track listing of <a>
>
> Just curious, did you mean:
> <a> is the original language/script track listing of <b>
> <b> is an alternate language/script track listing of <a>

I was using dupuy's proposal to have identical forwards and backwards link
phrases. Perhaps he would like to comment on it. :)

--Nikki

_______________________________________________
Musicbrainz-style mailing list
Musicbrainz-style@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

[Arturus Magi]

On 8/8/06, Oleg Rowaa[SR13] V. Volkov <mb.rowaasr13@...> wrote:
> Greetings.
>
> Just to make sure: am I correct that it also should not be used between real
> albums, even if they are translations and should only link real and virtual
> releases together?
>

I think we may want two sets of these: one for virtuals and one for
'real's.  Real translations may be released simultaneously, and might
not have a distinct 'original' version.

(I can only think of one particular instance of this, myself: a song
by a local band called Da Yoopers, who wrote a particular song
simultaneously in English and Finnish.)

_______________________________________________
Musicbrainz-style mailing list
Musicbrainz-style@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

[Gecks]

On 09/08/06, Arturus Magi <sailorleo@...> wrote:
> On 8/8/06, Oleg Rowaa[SR13] V. Volkov <mb.rowaasr13@...> wrote:
> I think we may want two sets of these: one for virtuals and one for
> 'real's.  Real translations may be released simultaneously, and might
> not have a distinct 'original' version.
>
> (I can only think of one particular instance of this, myself: a song
> by a local band called Da Yoopers, who wrote a particular song
> simultaneously in English and Finnish.)

unless i'm mistaken, this is relationship is not for actual
translations of the tracks/releases themselves, but the track/release
*tracklistings* only.

however your problem still stands. perhaps best to use the language
the songs are sung in as the 'original' language, where possible.
failing that you could use the language of the country of origin.
probably will still be some grey areas...

_______________________________________________
Musicbrainz-style mailing list
Musicbrainz-style@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

[keschte]

> unless i'm mistaken, this is relationship is not for actual
> translations of the tracks/releases themselves, but the track/release
> *tracklistings* only.

Please answer me this: What is the legimation of a user translated entries
in the database, if it wasn't released in this form? I have seen no
objections against the ideas of creating translations in the database, I
think this should be adressed first.

Given the recent decision to not allow "Top whatever" listing of tracks into
the database, because they are not legitimate, I can't help but wonder what
the difference is, that these kind of translations/transliterations should
be added as separate entries. I gather it is an effort to make MusicBrainz
more accessible from a internationalisation point, but is this the way to
go? Couldn't the translations be added to the annotations, without creating
entries that are in fact as non-existent as the "top whatever" entries?

The system thought up in the NextGenerationSchema would feature different
track titles attached to the *same* release entry in the database, which
will be a useful tool to provide track titles in the language the user likes
to see them.  The creation of distinct entries (even if linked using ARs) is
not really the way to go, IMHO.

Regards, keschte




_______________________________________________
Musicbrainz-style mailing list
Musicbrainz-style@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

[Brian G]

is "virtual" really the best name for the release type?
rather than using a word and forcing a new meaning why not call it what it really is.. a translation.
i don't think mb needs anymore confusing BadTerminology
if there are reasons to not call it something besides "virtual", i'd love to hear them.
to me something like Billboard Top 100 sounds more like a release that would be "virtual" .. where as "blah" is a translation of "blah" would be more like a (*looks at thread subject title*) Translation
-Brian

[Rod Begbie]

On 8/9/06, Brian G. <brian@...> wrote:
> is "virtual" really the best name for the release type?
> rather than using a word and forcing a new meaning why not call it what it
> really is.. a translation.
> i don't think mb needs anymore confusing BadTerminology

Agreed, agreed and agreed.

I'm uneasy about this proposal, because it splits the data about the
exact same release.  PUIDs, ARs, DiscIDs etc are tied to one release.

Compare the metadata surrounding
http://musicbrainz.org/album/0900aa86-9bbd-4424-b0dd-bfd2942ea02f.html
and http://musicbrainz.org/album/f470c26b-0beb-44d0-b49e-4caa02379b76.html.

They've got different DiscIDs associated (10 on one, 2 on the other,
no cross-over), so which titles you get when you lookup a disk are,
essentially, random.  One has an album AR.  The other has a track AR.
And the associated PUIDs on tracks differ.

It's a mess, and all because music geeks want their MP3s tagged in
different ways.

Encouraging this kind of split is A Bad Idea, in my eyes.  Either do
this with a DB schema-change, or not at all, IMO.

Rod.

--
:: Rod Begbie :: http://groovymother.com/ ::

_______________________________________________
Musicbrainz-style mailing list
Musicbrainz-style@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

[Brian G]

i'm reading http://wiki.musicbrainz.org/VirtualDuplicateRelease
if a release has a track with a pi symbol in it's title than the release needs to be entered into MB twice? (once for the symbol, and once as a translation that read "pi")
i can sort of understand entering a new release for a translation, but an entire additional release for track title unicode (which picard can correct via prefs > encodings) seems a bit much.
if the track is titled Π than it's titled Π

with Picard 0.7.0 is "Unicode tagging" really an issue at all?

[Nikki-12]

On Wed, Aug 09, 2006 at 09:20:53PM +0200, Stefan Kestenholz wrote:

> Please answer me this: What is the legimation of a user translated
> entries in the database, if it wasn't released in this form? I have seen
> no objections against the ideas of creating translations in the database,
> I think this should be adressed first.
>
> Given the recent decision to not allow "Top whatever" listing of tracks
> into the database, because they are not legitimate, I can't help but
> wonder what the difference is, that these kind of
> translations/transliterations should be added as separate entries. I
> gather it is an effort to make MusicBrainz more accessible from a
> internationalisation point, but is this the way to go? Couldn't the
> translations be added to the annotations, without creating entries that
> are in fact as non-existent as the "top whatever" entries?
>
> The system thought up in the NextGenerationSchema would feature different
> track titles attached to the *same* release entry in the database, which
> will be a useful tool to provide track titles in the language the user
> likes to see them.  The creation of distinct entries (even if linked
> using ARs) is not really the way to go, IMHO.

We already have thousands and thousands of transliterations and
translations. Telling people that artist names shouldn't be converted to
Latin has not stopped people entering edits to convert them back and
telling people they can't add transliterations won't stop people trying to
add them. Furthermore, adding separate entries has been the norm for quite
some time now, even if they were to be forbidden, a lot of less devoted
editors won't even realise that we've decided to ban them and add them
anyway.

Before there was an acceptable solution for using Latin artist names, many
people were very angry about being forced to use scripts they couldn't read
and I'm sure they would just leave MusicBrainz altogether if we refuse to
allow them to have release and track titles they can use.

Then there's problems like Kate Bush's "π" and Billy Joel's "Концерт". I
hope that's enough said on those issues.

I would say that the difference between "Top Whatever" lists and
transliterations and translations is that transliterations and translations
are *representations* of real releases whereas the "Top Whatever" lists
have no official release with the tracks in that order.

Another reason is that not everyone has Unicode support, and not everyone
wants lots of unreadable filenames. Even Picard doesn't and can't support
automatic transliteration of all scripts. If you'd like to attempt
automatic transliteration of Japanese, please be my guest, it's too
difficult for me. :)

I personally hate that we have to have separate releases with separate IDs
and so on, but it's really the only solution which keeps the people wanting
to *use* this data happy. That's why I want to be able to link these
together, so that once we're able to have more than one set of titles per
release, we can either automatically merge appropriate releases or create
reports for them. Lukáš has implemented permanent MBIDs, I believe, so once
we have NGS, the IDs will just become links to the real entry. Plus, what's
the point in deleting lots of data just so that people can add it again
later?

--Nikki

_______________________________________________
Musicbrainz-style mailing list
Musicbrainz-style@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

[Nikki-12]

On Wed, Aug 09, 2006 at 03:43:51PM -0400, Rod Begbie wrote:
> Encouraging this kind of split is A Bad Idea, in my eyes.  Either do
> this with a DB schema-change, or not at all, IMO.

What's your suggestion for all the people who want transliterations of
Asian albums? Do you even have any experience with what people want from
this area of the database?

--Nikki

_______________________________________________
Musicbrainz-style mailing list
Musicbrainz-style@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

[Nikki-12]

On Wed, Aug 09, 2006 at 12:48:23PM -0700, Brian G. wrote:
> i'm reading http://wiki.musicbrainz.org/VirtualDuplicateRelease if a
> release has a track with a pi symbol in it's title than the release needs
> to be entered into MB twice? (once for the symbol, and once as a
> translation that read "pi") i can sort of understand entering a new
> release for a translation, but an entire additional release for track
> title unicode (which picard can correct via prefs > encodings) seems a
> bit much.  if the track is titled Π than it's titled Π

Picard can't (yet) convert Π to "Pi" though, which is what users want. With
tagger script, I hope a lot of these cases can be resolved by automatic
transliteration, which is why I said that I think they should be allowed,
but not encouraged.

This proposal, however, largely deals with cases of Japanese, Chinese,
Korean, Greek, Thai, Russian, Hebrew, etc. releases where people want a
transliteration of the text.

--Nikki

_______________________________________________
Musicbrainz-style mailing list
Musicbrainz-style@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

[Nikki-12]

On Wed, Aug 09, 2006 at 03:43:51PM -0400, Rod Begbie wrote:
> I'm uneasy about this proposal, because it splits the data about the
> exact same release.  PUIDs, ARs, DiscIDs etc are tied to one release.

Also, this proposal doesn't split the releases, the releases are already
split. This proposal links them back together (although until the NGS, we
can't link all the IDs together, but we'll have a much easier job in doing
so with this relationship).

--Nikki, who is trying to communicate in a calm manner and may not be
succeeding.

_______________________________________________
Musicbrainz-style mailing list
Musicbrainz-style@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

[Gecks]

On 09/08/06, Stefan Kestenholz <keschte@...> wrote:
> > unless i'm mistaken, this is relationship is not for actual
> > translations of the tracks/releases themselves, but the track/release
> > *tracklistings* only.
>
> Please answer me this: What is the legimation of a user translated entries
> in the database, if it wasn't released in this form? I have seen no
> objections against the ideas of creating translations in the database, I
> think this should be adressed first.

IMO this AR is needed regardless. there are plenty of albums that have
one tracklisting in one country, and another in another - note I am
talking about the *text* on the tracklisitng, nothing else.

what i was saying is I don't think it's intended for actual
translations of the *songs* themselves (eg a band doing a song in
their native german, and then releasing an version with re-recorded
english lyrics).

_______________________________________________
Musicbrainz-style mailing list
Musicbrainz-style@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

[Gecks]

On 09/08/06, Rod Begbie <rodbegbie@...> wrote:

> On 8/9/06, Brian G. <brian@...> wrote:
> > is "virtual" really the best name for the release type?
> > rather than using a word and forcing a new meaning why not call it what it
> > really is.. a translation.
> > i don't think mb needs anymore confusing BadTerminology
>
> Compare the metadata surrounding
> http://musicbrainz.org/album/0900aa86-9bbd-4424-b0dd-bfd2942ea02f.html
> and http://musicbrainz.org/album/f470c26b-0beb-44d0-b49e-4caa02379b76.html.
>
> They've got different DiscIDs associated (10 on one, 2 on the other,
> no cross-over), so which titles you get when you lookup a disk are,
> essentially, random.  One has an album AR.  The other has a track AR.
> And the associated PUIDs on tracks differ.
>
> It's a mess, and all because music geeks want their MP3s tagged in
> different ways.

no, it reflects actual differences between the tracklisting on
different versions of this album.

personally i agree it should be merged, but it is not an analogous
situation to these "virtual" releases.

_______________________________________________
Musicbrainz-style mailing list
Musicbrainz-style@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

[Brian G]

BadTerminology", again!"

that seems to me like a translation problem, not a unicode problem.
you want Picard to translate. ok.
it's not a "Unicode tagging issues" it's a lack of translation feature
Picard (which tags - hence "tagging") can currently deal with unicode just fine AFAICT

-Brian

Nikki wrote:

On Wed, Aug 09, 2006 at 12:48:23PM -0700, Brian G. wrote:
> i'm reading http://wiki.musicbrainz.org/VirtualDuplicateRelease if a
> release has a track with a pi symbol in it's title than the release needs
> to be entered into MB twice? (once for the symbol, and once as a
> translation that read "pi") i can sort of understand entering a new
> release for a translation, but an entire additional release for track
> title unicode (which picard can correct via prefs > encodings) seems a
> bit much.  if the track is titled Π than it's titled Π

Picard can't (yet) convert Π to "Pi" though, which is what users want. With
tagger script, I hope a lot of these cases can be resolved by automatic
transliteration, which is why I said that I think they should be allowed,
but not encouraged.

This proposal, however, largely deals with cases of Japanese, Chinese,
Korean, Greek, Thai, Russian, Hebrew, etc. releases where people want a
transliteration of the text.

--Nikki

_______________________________________________
Musicbrainz-style mailing list
[e-mail]
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

[Simon Reinhardt]

Brian G. wrote:
> is "virtual" really the best name for the release type?
> rather than using a word and forcing a new meaning why not call it what it
> really is.. a translation.

We have translations and transliterations.

Simon (Shepard)

_______________________________________________
Musicbrainz-style mailing list
Musicbrainz-style@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

[Simon Reinhardt]

Stefan Kestenholz wrote:
>> unless i'm mistaken, this is relationship is not for actual
>> translations of the tracks/releases themselves, but the track/release
>> *tracklistings* only.
>
> Please answer me this: What is the legimation of a user translated entries
> in the database, if it wasn't released in this form? I have seen no
> objections against the ideas of creating translations in the database, I
> think this should be adressed first.

Listen to Don: rules follow practice. With tons and tons of translations and transliterations already being in the database you cannot just go and make a guideline not to allow that. It's unrealistic.

So instead of discussing this question *again* I think Nikki would be pleased if you all stay on topic and discuss the proposed relationship types and the release attribute.

Simon (Shepard)

_______________________________________________
Musicbrainz-style mailing list
Musicbrainz-style@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style