Re: [mb-style] RFC: Transliterations/translations, again! (now on test.m
It doesn't seem to be active anymore. It was just the AR anyway, there wasn't a release status change yet. -Dustin (Kernesky97) chidade wrote: I know it's been a few months since this thread was active, but I'm a bit of a newbie at MB and definitely at this mailing list... Is the AR mentioned still active on the test server? Looking at all the links that everyone gave of their apparently successful attempts - I can't see any difference between them and the original server. Also, trying to make my own AR examples gave me only the Official, Promotion and Bootleg release types. Help? -- View this message in context: http://www.nabble.com/-mb-style--RFC%3A-Transliterations-translations%2C-again%21-%28now-on-test.musicbrainz.org%29-tf2084745s2885.html#a6780696 Sent from the Musicbrainz - Style mailing list archive at Nabble.com. ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Transliterations/translations, again! (now on test.m
I still think alternate would be best but I never had a problem with virtual either. Fits the existing wiki entry and everything related to it too. Simon Reinhardt wrote: Brian G wrote: again i point out that we need to call things what they are or else we will continue to create confusing BadTermonology which creates communication issues in the long run. call things what they are rather than coming up with some new meaning for an incorrect term. This is intended to be a release _status_ if I understood it correctly. So yes, the release may be a transliteration/translation mainly. But the release _status_ is not. There it just doesn't fit. In my eyes virtual would be the best description for a status. But I'm fine with other things, just your argument that it's a translation doesn't work any more then, so you can't put a preference on this. translation -- i don't see how it can become any more concise without losing meaning of what's actually going on. and that can include transliterations because transliteration is a translation that is literal. I'm quite sure this is wrong but I let the linguists elaborate on this. Simon (Shepard) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style -- View this message in context: http://www.nabble.com/-mb-style--RFC%3A-Transliterations-translations%2C-again%21-%28now-on-test.musicbrainz.org%29-tf2084745s2885.html#a5821038 Sent from the Musicbrainz - Style forum at Nabble.com. ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Transliterations/translations, again! (now on test.m
We've come full circle. :P I like alternate because it leaves it open enough we can use it for other things we may think of later down the line that are similar enough to be grouped in the same area (the unicode versions for example). All of the different things that can be classified as alternate can be listed as verbose as you want in the help button next to the dropdown menu when editing so we can keep the actual classification down to a word or two. Nikki wrote: On Sun, Aug 13, 2006 at 03:27:28AM +0200, Schika wrote: How about transliterated/translated titles ? We were trying to come up with a short, concise way of saying it. :P --Nikki ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style -- View this message in context: http://www.nabble.com/-mb-style--RFC%3A-Transliterations-translations%2C-again%21-%28now-on-test.musicbrainz.org%29-tf2084745s2885.html#a5801291 Sent from the Musicbrainz - Style forum at Nabble.com. ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Transliterations/translations, again! (now on test.m
i like your suggestion more than alternative or whatever square peg people are trying to pound into a round hole. again i point out that we need to call things what they are or else we will continue to create confusing BadTermonology which creates communication issues in the long run. call things what they are rather than coming up with some new meaning for an incorrect term. translation -- i don't see how it can become any more concise without losing meaning of what's actually going on. and that can include transliterations because transliteration is a translation that is literal. -Brian Schika-2 wrote: How about transliterated/translated titles ? On 8/12/06, Nikki [EMAIL PROTECTED] wrote: On Sat, Aug 12, 2006 at 06:40:22PM +0200, Jan van Thiel wrote: Of course, people can also misunderstand 'alternate text' as 'alternate lyrics'... Alternate titles? --Nikki ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style -- .: NOP AND NIL :. .: Schika :. ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style -- View this message in context: http://www.nabble.com/-mb-style--RFC%3A-Transliterations-translations%2C-again%21-%28now-on-test.musicbrainz.org%29-tf2084745s2885.html#a5803701 Sent from the Musicbrainz - Style forum at Nabble.com. ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Transliterations/translations, again! (now on test.m
Brian G wrote: again i point out that we need to call things what they are or else we will continue to create confusing BadTermonology which creates communication issues in the long run. call things what they are rather than coming up with some new meaning for an incorrect term. This is intended to be a release _status_ if I understood it correctly. So yes, the release may be a transliteration/translation mainly. But the release _status_ is not. There it just doesn't fit. In my eyes virtual would be the best description for a status. But I'm fine with other things, just your argument that it's a translation doesn't work any more then, so you can't put a preference on this. translation -- i don't see how it can become any more concise without losing meaning of what's actually going on. and that can include transliterations because transliteration is a translation that is literal. I'm quite sure this is wrong but I let the linguists elaborate on this. Simon (Shepard) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Transliterations/translations, again! (now on test.m
On 8/14/06, Brian G [EMAIL PROTECTED] wrote: translation -- i don't see how it can become any more concise without losing meaning of what's actually going on. and that can include transliterations because transliteration is a translation that is literal. Transliteration is the transscribing of text from one script to another, and has nothing to do with translation whatsoever. And this release status, from what I understand of the proposal, is also intended for things like transcoding (the process of transferring text from one code or cypher to another: in this case, from computer codepages a theoretical client computer cannot use into one that it can [the cannoical example in this thread is Unicode to ISO-Latin-1]). ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Transliterations/translations, again! (now on test.m
How about transliterated/translated titles ? On 8/12/06, Nikki [EMAIL PROTECTED] wrote: On Sat, Aug 12, 2006 at 06:40:22PM +0200, Jan van Thiel wrote: Of course, people can also misunderstand 'alternate text' as 'alternate lyrics'... Alternate titles? --Nikki ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style -- .: NOP AND NIL :. .: Schika :. ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Transliterations/translations, again! (now on test.m
Kerensky97 wrote: And I agree with Gecks that that disclamier might be a little more than is needed; hopefully people realize that as a transl(iter)ation it should be identical to the other release just with different words in the tracks and title. I don't think that's what Gecks meant. He said it should not only be allowed for identical tracklistings (apart from transl(iter)ation), but also for tracklistings with bonus tracks or another track order. Here we have to be careful. How will NGS use this relationship and how will it use remaster relationships? Well, when we run the initial conversion to a new schema, it will observe relationships such as remaster and automatically create a release group in which it puts both. Apart from that, the relationships and releases stay untouched. When it encounters a transl-AR, it should check the release status: if both are official, put them in one release group and leave them as they are. If one is virtual/alternate/... and the other official, and the relationship points in the right direction (else someone made a mistake :)), then merge the virtual one into the official one and append the tracklisting as alternate titles. So if we allow this AR to be used for tracklistings which are different in the track order or have bonus tracks, then only for linking two official releases. A virtual release which is not about the exact same tracks should never be linked to an official release, because that can create wrong merging results when transforming the data to NGS! You might say, why should someone create a virtual release with a different track order? Well that perhaps not but consider this case: There's album A with 10 tracks and there's album B with 13 tracks which is just another edition of A with bonus tracks. Now you can have a transliteration A* of A and a transliteration B* of B. Imagine we just have A and B* in the database (because noone could find the original tracklisting of B yet but only a transliteration). Someone might think: oh, it's surely ok to create a relationship A is the original language/script track listing of B*, one is official, one is virtual, they are almost about the same tracks, can't be bad. But that would be a big mistake. So I think a disclaimer for that case is needed. Simon (Shepard) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Transliterations/translations, again! (now on test.m
Ah I see, if that's the case I fall back to what I said in one of the other threads, the virtual/alternate versions linked by AR should be identical, basically for the reasons you mentioned. This virtual/alternate release AR is basically tying stuff together that would usually be merged except that the alternate provides useful text translations and we don't want huge album annotations full of translations. Simon Reinhardt wrote: Kerensky97 wrote: And I agree with Gecks that that disclamier might be a little more than is needed; hopefully people realize that as a transl(iter)ation it should be identical to the other release just with different words in the tracks and title. I don't think that's what Gecks meant. He said it should not only be allowed for identical tracklistings (apart from transl(iter)ation), but also for tracklistings with bonus tracks or another track order. Here we have to be careful. How will NGS use this relationship and how will it use remaster relationships? Well, when we run the initial conversion to a new schema, it will observe relationships such as remaster and automatically create a release group in which it puts both. Apart from that, the relationships and releases stay untouched. -- View this message in context: http://www.nabble.com/-mb-style--RFC%3A-Transliterations-translations%2C-again%21-%28now-on-test.musicbrainz.org%29-tf2084745s2885.html#a5767419 Sent from the Musicbrainz - Style forum at Nabble.com. ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Transliterations/translations, again! (now on test.m
Yeah I just wanted to see what it would be like in a test run. I like Alternate text too; I was thinking Alternate, or Alternate Version but text helps people from getting confused with track name changes vs. actual lyric changes. Nikki wrote: Like I said, it will become part of mo's release attribute restructuring. I don't know when that will be polished and implemented, but I can't see why it won't be. How about Alternate text? --Nikki -- View this message in context: http://www.nabble.com/-mb-style--RFC%3A-Transliterations-translations%2C-again%21-%28now-on-test.musicbrainz.org%29-tf2084745s2885.html#a5767519 Sent from the Musicbrainz - Style forum at Nabble.com. ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
[mb-style] RFC: Transliterations/translations, again! (now on test.musicbrainz.org)
In the spirit of beta testing, and moving this proposal beyond the stage of endless discussion, I have created a transl-tracklisting AR on test.musicbrainz.org, and used it to link various releases of the artist 女子十二乐坊 (Twelve Girls Band) http://test.musicbrainz.org/show/artist/?artistid=175461 (specifically, the different Shining Energy and Beautiful Energy releases). While this may not be the best artist to demonstrate all the corner cases, I chose them because they were the first one to come to mind with transl(iter)ated tracklistings, and they are a Chinese group that releases also in Japanese and English, so that there are at least some issues about "original" and "official" that can be beta tested. And, they are not so wildly prolific as some of the Japanese groups, although the twelve girls certainly had a period of significant popularity worldwide, so that the number of releases is fairly modest. If you can think of other artists/examples that can be used, feel free to apply the new AR on the test server to them as well, and post links here. I hope that this will inform and enlighten our discussion of this proposal. If you think that changes should be made, feel free to tweak the name/link phrases/description of the new AR as you see fit. The current text of these is: transl-tracklisting (2) forward: is the original language/script track listing of reverse: is an alternate language/script track listing of description: Indicates that an album has translated or transliterated titles on another album release. This relationship does not indicate a cover where the lyrics have been translated (that should be indicated with "cover" instead, although both relationships could apply in some cases). This relationship should only be used when the number and order of tracks on the two albums are identical, and each of the titles corresponds in meaning. (hmmm. perhaps that last bit should be "corresponds in meaning or pronunciation" instead?) @alex -- mailto:[EMAIL PROTECTED] ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Transliterations/translations, again! (now on test.musicbrainz.org)
On 10/08/06, Alexander Dupuy [EMAIL PROTECTED] wrote: This relationship should only be used when the number and order of tracks on the two albums are identical, and each of the titles corresponds in meaning. IMO, like a similar disclaimer in the 'mastered by' relationship, this isn't really neccesary. it's useful to see that album a is a remaster/translation of album b, even if the content is slightly different (as they often are with seperate releases - bonus tracks, etc). unless there's a compelling reason i've missed, of course! i've definitely seen people doing the remastered relationship between 2 slightly different tracklistings and no one seems to care about it. i did an test relationship - http://test.musicbrainz.org/show/release/relationships.html?releaseid=458471 - all seems fine :) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Transliterations/translations, again! (now on test.m
I like it, works great. How hard would it be to get “Alternate” or whatever listed in release type so we could also move these alternates into a separate group in the artist discog list? And I agree with Gecks that that disclamier might be a little more than is needed; hopefully people realize that as a transl(iter)ation it should be identical to the other release just with different words in the tracks and title. My test - http://test.musicbrainz.org/show/release/?releaseid=514127 Gecks wrote: On 10/08/06, Alexander Dupuy [EMAIL PROTECTED] wrote: This relationship should only be used when the number and order of tracks on the two albums are identical, and each of the titles corresponds in meaning. IMO, like a similar disclaimer in the 'mastered by' relationship, this isn't really neccesary. it's useful to see that album a is a remaster/translation of album b, even if the content is slightly different (as they often are with seperate releases - bonus tracks, etc). unless there's a compelling reason i've missed, of course! i've definitely seen people doing the remastered relationship between 2 slightly different tracklistings and no one seems to care about it. i did an test relationship - http://test.musicbrainz.org/show/release/relationships.html?releaseid=458471 - all seems fine :) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style -- View this message in context: http://www.nabble.com/-mb-style--RFC%3A-Transliterations-translations%2C-again%21-%28now-on-test.musicbrainz.org%29-tf2084745s2885.html#a5753739 Sent from the Musicbrainz - Style forum at Nabble.com. ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Transliterations/translations, again! (now on test.m
On Thu, Aug 10, 2006 at 03:23:34PM -0700, Kerensky97 wrote: I like it, works great. For me too: http://test.musicbrainz.org/release/d95466e6-d38c-4577-b6dd-894e1b8faa57.html How hard would it be to get “Alternate” or whatever listed in release type so we could also move these alternates into a separate group in the artist discog list? Like I said, it will become part of mo's release attribute restructuring. I don't know when that will be polished and implemented, but I can't see why it won't be. How about Alternate text? --Nikki ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Transliterations/translations, again! (now on test.m
On 8/11/06, Kerensky97 [EMAIL PROTECTED] wrote: I like it, works great. How hard would it be to get Alternate or whatever listed in release type so we could also move these alternates into a separate group in the artist discog list? And I agree with Gecks that that disclamier might be a little more than is needed; hopefully people realize that as a transl(iter)ation it should be identical to the other release just with different words in the tracks and title. My test - http://test.musicbrainz.org/show/release/?releaseid=514127 Gecks wrote: i did an test relationship - http://test.musicbrainz.org/show/release/relationships.html?releaseid=458471 - all seems fine :) Works fine for me: http://test.musicbrainz.org/release/e8ed760c-0aa7-44a5-9a8d-66a60edc9a74.html and now album annotations as in my exacmple are no longer needed. :) -- .: NOP AND NIL :. .: Schika :. ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
RE: [mb-style] RFC: Transliterations/translations, again!
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@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Transliterations/translations, again!
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 -- View this message in context: http://www.nabble.com/-mb-style--RFC%3A-Transliterations-translations%2C-again%21-tf2068565s2885.html#a5732193 Sent from the Musicbrainz - Style forum at Nabble.com. ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Transliterations/translations, again!
On 8/9/06, Brian G. [EMAIL PROTECTED] 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@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Transliterations/translations, again!
On 09/08/06, Rod Begbie [EMAIL PROTECTED] wrote: On 8/9/06, Brian G. [EMAIL PROTECTED] 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@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Transliterations/translations, again!
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@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Transliterations/translations, again!
On 8/9/06, Nikki [EMAIL PROTECTED] wrote: 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). Fairynuff. If they're already there, then you're right, linking them with ARs is the best way to go to help us clean up in the future. Virtual is still a bad name for the release type, though. In fact, can you explain the reason for the new release type, because I'm not sure I've seen it. Thanks, Rod. -- :: Rod Begbie :: http://groovymother.com/ :: ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Transliterations/translations, again!
Chris Bransden wrote: On 09/08/06, Stefan Kestenholz [EMAIL PROTECTED] 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. Thanks for being realistic. :) Although you seem to be for merging them, you understand that, since we have them and they won't just go away, we need to handle them somehow. And to everyone: when discussing relationship types, please always keep in mind that they are essential for NGS. The AR data will be used excessively to do the initial data transformation to the next schema [1]. 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). Which is exactly what Nikki's initial mail said. :) Simon (Shepard) [1] for details see http://wiki.musicbrainz.org/NextGenerationSchema#head-8b940439575ebe5f8daf3203383111a73f29f6ba ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Transliterations/translations, again!
so? they're basically the same thing where one is literal and one isn't. if they're two different things than why even lump them together under a word that is Bad? why not (again) call things what they are rather than forcing new meanings to words that don't apply.. create translation and transliteration -- View this message in context: http://www.nabble.com/-mb-style--RFC%3A-Transliterations-translations%2C-again%21-tf2068565s2885.html#a5733411 Sent from the Musicbrainz - Style forum at Nabble.com. ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Transliterations/translations, again!
On 09/08/06, Simon Reinhardt [EMAIL PROTECTED] wrote: Chris Bransden wrote: 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. Thanks for being realistic. :) Although you seem to be for merging them, you understand that, since we have them and they won't just go away, we need to handle them somehow. well, i still don't think i'm being understood so i will re-iterate :) there are in existance releases which have different translations of the tracklistings - nothing virtual about them. eg: http://www.discogs.com/release/656463 (original release) http://www.discogs.com/release/683846 (US version with translated titles) note that the lyrical content on both is exactly the same. regarding 'virtual' translations (ie done by users, not printed on sleeves) - i do agree they should be linked, as they're obviously in the DB, however i don't think they fit here under the current system, as they're not physical releases. if there was a 'virtual' release type, then yes that would make them much more acceptable. however, i don't think this affects the need for this AR, as there are legit printed releases that need the relationship, nevermind 'virtual' ones :) 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). Which is exactly what Nikki's initial mail said. :) i know, see the post i was replying to original to see why i went down that route :) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Transliterations/translations, again!
On Wed, Aug 09, 2006 at 04:34:13PM -0400, Rod Begbie wrote: Virtual is still a bad name for the release type, though. In fact, can you explain the reason for the new release type, because I'm not sure I've seen it. It's a way of splitting real track listings from virtual ones (i.e. unofficial translations and transliterations, etc.). When we have greater control over what's shown on the artist page (artist page redesign) we'll then be able to hide these, and just see the *real* discography. Also, when we can merge track listings, virtual ones can be merged or proposed for a merge automatically. --Nikki ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Transliterations/translations, again!
On Wed, Aug 09, 2006 at 09:47:26PM +0100, Chris Bransden wrote: regarding 'virtual' translations (ie done by users, not printed on sleeves) - i do agree they should be linked, as they're obviously in the DB, however i don't think they fit here under the current system, as they're not physical releases. if there was a 'virtual' release type, then yes that would make them much more acceptable. however, i don't think this affects the need for this AR, as there are legit printed releases that need the relationship, nevermind 'virtual' ones And since mo has agreed to add the 'virtual' type to his attribute restructuring anyway, that's taken care of too. --Nikki ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Transliterations/translations, again!
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.Thanks for being realistic. :) yep, but he talks about a different issue. Since we talked with donredman about the camps that are created, this is exactly such a statement. You thank him for being realistic, what does this tell how you think about people who think this isn't the right solution? Please try not to communicate on this level, it doesn't help. regards, keschte ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Transliterations/translations, again!
On Aug 9, 2006, at 1:56 PM, Simon Reinhardt wrote: Robert Kaye wrote: Shepard says: 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. Rules that follow from bad practices are bad rules. Well then we need to change them into good practices. But you cannot just create a rule to forbid transliterations and translations, that won't work. Whether the current practices are good or not and how to change them is one topic that surely needs to be addressed and that needs long-term solutions. But that's not what this thread is about. This thread is about providing means that will help to transform the current solution into a long-term solution later. And it's not even hard to implement. I think this can't be bad. Fair enough, I can appreciate that. What rules to we adopt for having people attach PUIDs/TRMs/discids to these duplicate releases? -- --ruaok Somewhere in Texas a village is *still* missing its idiot. Robert Kaye -- [EMAIL PROTECTED] --http://mayhem-chaos.net ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Transliterations/translations, again!
On Wed, Aug 09, 2006 at 01:38:12PM -0700, Robert Kaye 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. Agreed -- we'd be adding tons of confusing duplication if we started adding these to BOTH releases. No good. Too late. It's been happening for ages (over 2000 albums marked as Japanese, Latin alone). I am not proposing a way of doing transliterations and translations here, I'm trying to provide the links between our current data which will benefit us later when we have schema support for these. We recently agreed that MusicBrainz' primary focus is to create a database of music information. Tagger users desires are secondary and tools should tweak the data to suit the tagger users. Its is not ok for tagger users to dictate the DB structure. This fits issue falls into the same category. While I do agree with this, I feel that if we ban transliterations and translations, we're not doing ourselves any favours. Firstly, we'll be alienating a large proportion of the users who listen to foreign music, and they aren't going to contribute, come back or recommend us to their friends if all we do is piss them off -- and that's exactly what we will do if we force everyone to use scripts they can't read. I would *love* to do automatic transliteration, but for many languages it's anywhere from not easy to impossible. Secondly, all of this data can be used later with NGS. We would be *stupid* to delete all the transliterations and translations right now. Transliterations/translations must be done RIGHT at the schema level. I'm currently trying to raise some money to get started working on NGS... I agree that the proper way to do it is at the schema level, but with no current support, people have done the only thing they feel they can. ...didn't you say the tagger users pay the bills? Rules that follow from bad practices are bad rules. Maybe so, but rules that go completely against current practise will be hard to enforce. --Nikki ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Transliterations/translations, again!
if you didn't want discussion on your proposal (which indeed contains the creation of virtual as a release type) than you perhaps should not have requested comments. measure twice, cut once -Brian Nikki wrote: On Wed, Aug 09, 2006 at 01:37:00PM -0700, Brian G. wrote: so? they're basically the same thing where one is literal and one isn't. if they're two different things than why even lump them together under a word that is Bad? why not (again) call things what they are rather than forcing new meanings to words that don't apply.. create translation and transliteration My proposal is about the relationship, it's not really concerned with the wording used for the release attribute for the translations and transliterations -- that's just the direction I feel we should go after this. If that's your only complaint, could it at least wait until we reach the step where we talk about actually adding this attribute? --Nikki ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style -- View this message in context: http://www.nabble.com/-mb-style--RFC%3A-Transliterations-translations%2C-again%21-tf2068565s2885.html#a5734960 Sent from the Musicbrainz - Style forum at Nabble.com. ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Transliterations/translations, again!
On Wed, Aug 09, 2006 at 03:22:06PM -0700, Brian G. wrote: if you didn't want discussion on your proposal (which indeed contains the creation of virtual as a release type) than you perhaps should not have requested comments. I'm not saying that you shouldn't comment, but I'm trying to keep this moving along as the idea has been being tossed around for over a year. The exact naming of the attribute doesn't need to be decided before we implement the relationship, so I would appreciate it if we can discuss that further when we get to it. --Nikki ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Transliterations/translations, again!
we're here. -- View this message in context: http://www.nabble.com/-mb-style--RFC%3A-Transliterations-translations%2C-again%21-tf2068565s2885.html#a5735295 Sent from the Musicbrainz - Style forum at Nabble.com. ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Transliterations/translations, again!
On Aug 9, 2006, at 2:50 PM, Nikki wrote: While I do agree with this, I feel that if we ban transliterations and translations, we're not doing ourselves any favours. Secondly, all of this data can be used later with NGS. We would be *stupid* to delete all the transliterations and translations right now. I never suggested that we ought to get rid of them. I am mainly concerned about making this an approved practice. ...didn't you say the tagger users pay the bills? They do, and I want to support them. But that does not change the fact that our primary purpose is a music encyclopedia and a tagging system second. But, income is increasingly coming from other sources these days -- which I welcome wholeheartedly. Rules that follow from bad practices are bad rules. Maybe so, but rules that go completely against current practise will be hard to enforce. Can't argue that either. -- --ruaok Somewhere in Texas a village is *still* missing its idiot. Robert Kaye -- [EMAIL PROTECTED] --http://mayhem-chaos.net ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Transliterations/translations, again!
On 8/9/06, Chris Bransden [EMAIL PROTECTED] wrote: On 09/08/06, Arturus Magi [EMAIL PROTECTED] wrote: On 8/8/06, Oleg Rowaa[SR13] V. Volkov [EMAIL PROTECTED] 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. The song is literally both English and Finnish, one right after the other.. The discs were released with one name or the other on the label, with no actual distinction between them...including in the process of ordering them (although I think the Finnish prints were only released for the first few months, or so). ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Transliterations/translations, again!
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@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Transliterations/translations, again!
On 8/8/06, Oleg Rowaa[SR13] V. Volkov [EMAIL PROTECTED] 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@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
[mb-style] RFC: Transliterations/translations, again!
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@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
