Re: [mb-style] Is french silly? :p (French capitalization rules)
2006/8/9, Jan van Thiel [EMAIL PROTECTED]: Hi, I've read al 82 (!) previous messages with this subject, and came to the conclusion that a) we need a simpler guideline for French capitalization; b) Sentence Case is more in line with the general idea on French capitalization. This is all my personal opinion, as a Dutch native who can read and write some French. Regards, -- Jan (zout) Well, at least, it doesn't really hurt my eyes. And I feel it has a simple logic that I like. But I am a french working with computers, so do I like it because I am french (remember Descartes and Boileau) or because I work with computers? -- Frederic Da Vitoria ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
RE: [mb-style] Is french silly? :p (French capitalization rules)
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Frederic Da Vitoria Sent: Wednesday, August 09, 2006 2:05 PM To: MusicBrainz style discussion Subject: Re: [mb-style] Is french silly? :p (French capitalization rules) mll, please, let us try to keep these kind of highly subjective and arguable considerations out of this list. I feel this is exactly the kind of remarks that could lead to flames, which seldom lead anywhere useful. OK, sorry about the tone. I just meant that some things told like evidences are not such. ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Is french silly? :p (French capitalization rules)
2006/8/9, MLL [EMAIL PROTECTED]: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Frederic Da Vitoria Sent: Wednesday, August 09, 2006 2:05 PM To: MusicBrainz style discussion Subject: Re: [mb-style] Is french silly? :p (French capitalization rules) mll, please, let us try to keep these kind of highly subjective and arguable considerations out of this list. I feel this is exactly the kind of remarks that could lead to flames, which seldom lead anywhere useful. OK, sorry about the tone. I just meant that some things told like evidences are not such. I understand and you are right about this. But still, I believe Olivier has a point: let us from now on forget about existing rules (we will never agree on wether these rules exist or not) and concentrate on what we should do for MB. But I suggest we wait until the beginning of september. All of know that France forgets all about technology in summer, especially during august's first fortnight. You won't see many laptops on the beaches ;-) So I suggest (but I believe this was already suggested by you a few days ago) we let this sleep until the beginning of september. The vote will be more meaningful then. -- Frederic Da Vitoria ___ 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
[mb-style] Unicode tagging issues?
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? -- View this message in context: http://www.nabble.com/-mb-style--RFC%3A-Transliterations-translations%2C-again%21-tf2068565s2885.html#a5732621 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, 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] Unicode tagging issues?
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 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#a5733181 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!
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] Unicode tagging issues?
On Wed, Aug 09, 2006 at 01:22:32PM -0700, Brian G. wrote: 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 Just removing all Unicode characters doesn't work for albums completely in other scripts (e.g. Greek, Chinese). Yes, Picard can remove all the bad characters, but it can't do so in a way which leaves the data in a usuable state. I'm not entirely sure what happens if you set Picard to write Latin1 tags, but I'm sure it doesn't leave people with usable metadata for Chinese releases. --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
[mb-style] Re: RFC: Transliterations/translations, again
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
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] Re: RFC: Transliterations/translations, again
Alexander Dupuy wrote: 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). I have a tricky case for you: in my shelf there's a classical CD which I didn't dare adding to MB yet. Reason: it has both German and English titles in the tracklisting... Anyways, an important example for when we have transl(iter)ations but not the original titles in the db: Since CDs are expensive in Japan, western artists often produce special releases for it with bonus tracks on them. I don't own such a Japanese edition but I'm pretty sure the titles are not in latin on the covers most of the time. Yet, I haven't come across editors from Japan for the rock bands I edit. And apart from amazon.co.jp, where I wouldn't copy tracklists from, I don't know where I could find reliable resources for tracklists how they are printed on the covers of such Japanese editions. But what I can find out is how the tracks are called in English/Latin. I have the tracklisting for the European/US release and the artist websites often list the titles of the bonus tracks for Japan. So what can I do much but enter the Japanese edition in English/Latin? And I can't even find out, if the Japanese release really has the titles in latin or not, so probably I'm enterin g the official release, probably the virtual release. God knows, but you can't blame me for it, it's common practice. ;) There are lots and lots of those just in the metal section. I haven't seen anyone complaining about them yet. Simon (Shepard) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
