Re: [mb-style] RFC: Dealing with translations and transliterations
On 7/19/06, Alex Dupuy [EMAIL PROTECTED] wrote: Dustin B. wrote: In reference to the previous RFC, it sounds like everybody is fine with an AdvancedRelationship that binds translated and transliterated editions of a release together. Besides linking the two we need to define which is an official trans...ation and which is a virtual one. 3. Question of transcoded releases (Unicode - ASCII) and whether these should be encouraged or deprecated. I vote for deprecation :) I would raise another one, somewhat parallel to my previous comments [...] I would argue that the distinction between translation and transliteration should not be a property of the AR, since it is evident from the language attributes of the two releases. If the languages are the same (e.g. Russian/Cyrillic Russian/Latin), then it is a transliteration; if they are different (e.g. Chinese/Han English/Latin) then it is a translation. Making it a property of the AR just creates additional possibilities for inconsistencies in the data. Very good point! I forgot about this. Something I wanted to ask: would it be very hard to rig the server to actually change the wording according to the language attribute of the albums? That is, it would look at what the language/script is and pick translation/transliteration automatically. This is a bit more complex than it looks at first: among other things it requires that the two attributes actually be set; we could force the users to add them (by making a custom AR-editing page), but it won't be easy, I guess. We also need to make sure that we cross-check for the AR when anyone tries to change the language/script. So... can it be done? A similar argument can be made for official/unofficial status. [...] This sort of makes sense, but the problem is that you actually have to look at the two albums to find out what's it about. Also, it's not immediatelly obvious what you should look at, and it's harder when the album attributes are not set. This could be solved by hacking the server to take care about this (see above), but I have a feeling that's really hard to do. Taking this into account, I would propose the following as the link text: [Release A] is an alternate language version of the titles of [Release B] [Release B] is an alternate language version of the titles of [Release A] alternate language suggests the language is changed, which is not true for transliterations. I can't think of any better formula though. Separately from the creation of this new AR, I would propose that the next server release contain a new Release Type category, Virtual (or perhaps better, Alternate Titles) that can be used for releases with transl(iter)ated titles that have never appeared on any actual release (whether as CD or other physical media, or as internet downloads). This is intriguing: I like the virtual thing better: we could use it for lots of other things that aren't really released: there is a parallel thread right now on [users] about a CD that has all song on a single track, we could use a virtual release to list all tracks. The DVD-rip problem we had some time ago may work with this too. -- Bogdan Butnaru — [EMAIL PROTECTED] I think I am a fallen star, I should wish on myself. – O. ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Dealing with translations and transliterations
On 18/06/06, Don Redman [EMAIL PROTECTED] wrote: On Fri, 16 Jun 2006 10:11:36 +0200, Nikki wrote: * We should have an 'official' and 'unofficial' attribute because some transliterations/translations are officially released, and therefore deserve separate entries. What does official mean in this case? Is this the same as I proposed, namely the distinction whether the trans...tion refers to an actual existing releas or is just a virtual release? yes, see my first reply. i would also like to reflect schika's experience of titles with both the JP (or other) and English translation on the tracklisting. I imagine there's probably cases of the tracklist appearing like: JP Version: 1) [Japanese Text] - [English Translation] 2) ... US Version: 1) [English Translation] 2) ... or various combinations of the above. i think we should probably still say that [JP Version] is an [official] trans...tion of [JP Version], as it's true, but it's just that the JP version also included this trans...tions, if that makes sense :) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Dealing with translations and transliterations
On 6/16/06, Simon Reinhardt [EMAIL PROTECTED] wrote: I would like to hear more about those tricky examples. :)I guess they have been discussed to death before... sorry, didn't read the other threads. Simon (Shepard) Examples? Maybe like this one: An official release comes in both languages. I've had one with an cover and inlay you can turn - one side with titles and credits in Russian/Cyrillic and the other side with everything in English/Latin. That CD was (mabe still is) in local stores - here in germany - with the english version outside and the russian version outside available (same label and cat number for sure). Another one had both versions on the back cover like this way: 1 - Japanese Track Title - [duration] - English Track Title - 1 -- .: 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: Dealing with translations and transliterations
On Fri, 16 Jun 2006 10:11:36 +0200, Nikki wrote: * We should have an 'official' and 'unofficial' attribute because some transliterations/translations are officially released, and therefore deserve separate entries. What does official mean in this case? Is this the same as I proposed, namely the distinction whether the trans...tion refers to an actual existing releas or is just a virtual release? IMO this is the most important distinction we should make. I do not care that much, wheter a trans...ion is officially sancitioned (and if by whom?). DonRedman -- Words that are written in CamelCase refer to WikiPages: Visit http://wiki.musicbrainz.org/ the best MusicBrainz documentation around! :-) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Dealing with translations and transliterations
On Fri, Jun 16, 2006 at 01:23:00AM +0200, derGraph wrote: So could anyone please summarize this? Is there more than a request for a transliteration AR (which by the proposed guidelines doesn't create clusters) and a comment on a roadmap? Basically, yes. The overall thread so far has been that: * We should create a transliteration/translation relationship so that we have the ability to link 'virtual' releases together. * We should have an 'official' and 'unofficial' attribute because some transliterations/translations are officially released, and therefore deserve separate entries. * We can avoid the majority of relationship clusters by linking to the official release in the artist's native language (presumably in their usual country of release). Expanding on the last point, there will still be some cases where clusters would be possible, but focusing on those is silly. We currently have thousands of transliterations which are lacking a relationship because a handful of examples (which, in some cases, are just theoretical) are tricky to handle. --Nikki ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Dealing with translations and transliterations
Nikki wrote: Basically, yes. The overall thread so far has been that: Some points to add: Dustin exhaustively tried to state why we *should* allow virtual duplicates - which I think was unnecessary because everyone who still wants to argue against that is a bit out of reality. ;) Also it was said that we might want to make use of this relationship for displaying duplicate releases together with the official ones (?) and let all changes to one of the releases (except the titles) reflect on the other ones automatically. I'd like to see more concrete plans for that. * We can avoid the majority of relationship clusters by linking to the official release in the artist's native language (presumably in their usual country of release). This point is a bit hazy to me. What about cases where the official release of a Japanese band is in English/Latin and someone creates a virtual Japanese/Kana duplicate? Artist's native language is problematic in my eyes. Of course you could say the English/Latin one is the official release and therefore everything links there. But what if there are several official ones of which none can be seen as most native? This might sound theoretically but I think identifying the main release can be problematic. Expanding on the last point, there will still be some cases where clusters would be possible, but focusing on those is silly. We currently have thousands of transliterations which are lacking a relationship because a handful of examples (which, in some cases, are just theoretical) are tricky to handle. I would like to hear more about those tricky examples. :) I guess they have been discussed to death before... sorry, didn't read the other threads. Simon (Shepard) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Dealing with translations and transliterations
On Fri, Jun 16, 2006 at 02:01:29PM +0200, Simon Reinhardt wrote: This point is a bit hazy to me. Feel free to rephrase it. What about cases where the official release of a Japanese band is in English/Latin and someone creates a virtual Japanese/Kana duplicate? Then the Japanese/Kana version isn't an official track listing and thus doesn't count in the versions we can choose from! But what if there are several official ones of which none can be seen as most native? Example? Last time the discussion died because people brought up theoretical problems which, as I said, doesn't do anything for the *real* cases we have. Anyway, these are only guidelines. We can't possibly cater for every single case. If someone comes along and finds it hard to apply the guideline to the data, they're free to work out what *does* work (and that applies to all of the guidelines). I'm merely giving something which works for nearly all the cases we have already. I would like to hear more about those tricky examples. :) The only one I'm really at all familiar with is China Dolls [1]. They're a duo from Thailand, one is half Chinese, one is half Taiwanese. They have official releases in Thai, Chinese and Japanese. If two of these happen to share the same songs in the same order, there would be two official versions which the transliterations and translations could link to. It's all theoretical because I don't even know if two releases share the exact same songs in the same order. We only have 4 distinct albums (plus 1 transliteration) for them anyway, so all the possible transliterations and translations are just some sort of straw man or something. --Nikki 1 http://musicbrainz.org/artist/db695488-b587-4349-8aa1-da3ab8a5f0ff.html ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Dealing with translations and transliterations
Nikki wrote: Expanding on the last point, there will still be some cases where clusters would be possible, but focusing on those is silly. We currently have thousands of transliterations which are lacking a relationship because a handful of examples (which, in some cases, are just theoretical) are tricky to handle. If it works for the majority of cases, or maybe even for all but very few, I'd say we should go ahead! -- derGraph PS: Thanks for the summary! ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Dealing with translations and transliterations
On 14/06/06, Dustin B [EMAIL PROTECTED] wrote: There's no reason to throw away good info right now just because we're confused with what to do with it, or worse disagree with it because it doesn't make the database pretty. Remember the goal is the ultimate repository of music releases my concern is that these *aren't* music releases. infact i've never really seen the point of transliterations, as i feel the english (or other) version of the trackname is trivia, rather than something you'd want to look at. after all, all other aspects of the release (lyrics etc) will presumably be in the offending language, so i'm not sure it's worth doing. plus i prefer seeing things in the language of origin, even if it is all squiggles to me :) but i appreciate that other people want them, so fair enough in them being added, and i agree that the next steps need to be to make an AR to link them to the original, and then hide, or otherwise seperate unofficial transliterations from official releases. also i think the transliteration AR should have an 'official' or 'unofficial' attribute, to seperate releases that have different titles on the sleeve depending on what market they are in. 'official' transliterations shouldn't be hidden/seperated from the official releases. chris / gecks ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Dealing with translations and transliterations
On Tue, Jun 13, 2006 at 08:17:05PM -0600, Dustin B wrote: I think we need an AR to bind transliterations and translations of the same album together currently so we can more easily combine them when we have full solution for multiple languages. I fully agree, which is why I bugged you to send an email about it! ;) An example I bought up, which I think illustrates the problem well, is Faye Wong [1]. The majority of her albums are listed in MusicBrainz as English/Latin, Chinese/Latin and Chinese/Han (Traditional). There's no way to work out which album is a transliteration or translation of another, you just have to compare release dates and the number of tracks and hope it's right. With a relationship, [2] in Chinese/Han (Traditional) would become the official tracklist. [3] would become a Chinese (Mandarin)/Latin transliteration and [4] would become a Chinese (Cantonese)/Latin transliteration. [5] would be an English translation. One advantage of it is that when we eventually have support for album/track transliterations or translations (which I've been told will be part of NGS), the unofficial translations can be automatically merged into the official tracklist without the need for hundreds of manual merges. I also agree with Gecks (regarding 'official' or 'unofficial') and Don (regarding being able to avoid clusters). Does anyone disagree with adding it? --Nikki 1 http://musicbrainz.org/artist/692e367d-2846-442d-b13d-1177c3681c65.html 2 http://musicbrainz.org/album/d95466e6-d38c-4577-b6dd-894e1b8faa57.html 3 http://musicbrainz.org/album/c2130588-5c1d-4c22-bec2-63445cb0c849.html 4 http://musicbrainz.org/album/94e3c79b-2908-4a7e-9443-777d800475fa.html 5 http://musicbrainz.org/album/1d3f1239-73c1-46eb-b961-86536a189026.html P.S. Perhaps we can debate the issue of whether MB should have trans... albums, but on another thread. It's not even worth the effort of a debate, it's far too late to even attempt to stop the flow of transliterations into the database. ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
[mb-style] RFC: Dealing with translations and transliterations
Apparently this didnt make it onto the list the first time I sent it. Forgive, the book. I try not to post too much because it ends up being a bit long, but as a lot of the transliterations recently have been mine I think I should chime in. I think we need an AR to bind transliterations and translations of the same album together currently so we can more easily combine them when we have full solution for multiple languages. Transliterations and Translations (trans... albums) have been cropping up a lot on the edits recently. And while many are mine even more are from new moderators wanting to flesh out the database with useful information. Ive seen first hand by adding an official album and a transliterated version that the transliterated version gets more attention and editing; considering MB is an English site, go figure. And with a bit of quick scanning through these edits youll see that theres a bit of confusion and debate as to how these should be handled. Partly because a lot of the people voting and editing are new, but mostly because theres no documentation and almost no official way to tie these together. Examples. http://musicbrainz.org/album/08229f60-a117-4d7f-b3a7-03533267eeb2.html http://musicbrainz.org/album/1a18e14a-de59-415e-9abd-1e644cd58dc6.html The issue has already been brought up on the mailing list a few times but nothing has ever come of it; so now that this is growing I think we need to come up with a solution. The following threads are some of the best discussions thus far about the issue but are 6-12 months out of date. http://lists.musicbrainz.org/pipermail/musicbrainz-style/2005-July/000254.html http://lists.musicbrainz.org/pipermail/musicbrainz-style/2005-July/000252.html http://lists.musicbrainz.org/pipermail/musicbrainz-users/2005-December/010426.html Long and short of it is that there are more and more trans... albums going up, and under the current wiki rules for VirtualDuplicateRelease they are to be kept in the database. This creates a lot of duplicate albums that need to be tracked and edited because if they are the same a change on one album should affect the others. Some peoples answer to this is to eliminate trans... albums completely but I dont think theyll go away considering that: 1. The wiki currently approves or it B. The database is already full of them III. MB has a stated goal to have further internationalization so its not an English Speaker Only club. Perhaps we can debate the issue of whether MB should have trans... albums, but on another thread. This tread is about a solution to bring a little more order to the database rather than throwing it into further chaos. Alexander Dupuy came up with an excellent summary of the issue and how to deal with it in on of the previous threads: In general, I see the roadmap for this aspect of i18n as follows 0. entry of transliterations - as Orion notes, there are a lot of these already for Asian artists, where they are the most useful/needed, and they will continue to be entered on an ongoing basis 1. addition of AR linktype for transliterations - the issues with clusters are tricky, but this seems the best way to go; some design is needed to coordinate with other same as type relationships (e.g. re-release, remaster, etc.) 2. elaboration of style guidelines for transliterations - there are some best practices, but it's true they haven't really been well codified 3. enhancement of album display to hide unwanted transliterations - this is part of a much larger project, which would be the follow-on to the artist page redesign, adding special display support for album-album AR links I anticipate a lot of griping from people who find transliterated entries unreadable and simply wrong until the final roll-out of step 3, but I'm convinced that this is the right direction for us to go. #3 is the best and final solution but will take time to get something running; banning good information till then just creates a bigger workload later when we have a solution and MB becomes a truly international site. Theres no reason to throw away good info right now just because were confused with what to do with it, or worse disagree with it because it doesnt make the database pretty. Remember the goal is the ultimate repository of music releases, not the most uniform but lacking site on the net. #2 is really an ongoing process as we refine a standard for transliterations (which we desperately need). Getting started now is great, but its more of an evolving side issue rather than a solution in itself. We need guidelines for how trans... albums are represented if the official label doesnt provide them; considering we still debate the language of foreign releases theres obviously a lot of work to do but thats a different discussion and a different issue. #0 is happening no matter what and will continue to do so, its not so much a solution to
