On Wed, Jan 14, 2015 at 7:42 AM, KRSCuan <donc...@gmx.de> wrote: > On 14.01.2015 01:00 Jim Duke wrote: > > Ok. I see that now. My brain just doesn't seem to want to absorb the > > concept of "psuedo-release". Not sure why. I must have read that a > > zillion times and it just doesn't stick. > You're not the only one. A lot of users seem to have problems with it. >
That helps me feel better, then. > > Incidentally, we just recently had a style discussion about > pseudo-releases, where I also argued that we properly support multiple > tracklists and then get rid of pseudos instead. > Something seems off about using the term "Multiple Track Lists". There is, in fact, only one list of tracks. It's just that when viewing that track list you want to be able to view it using different locale settings (language, time/date, etc.). If there were in reality more than one list of tracks - where the difference is more than just locale based - then you have separate releases - wouldn't you? Probably as part of the same Release Group. I don't see why we view it differently than how we view multi-locale web page viewing. There is only one web page. But the user can choose what locale settings should be used when the web page is pulled and rendered. It seems to me that the difference should be at the lowest level: the actual entries that contain text. Textual entries should provide multi-lingual support; meaning that for a particular textual attribute; you have the means to store multiple versions of that text in different languages. So (and I'm making this up as an example - don't skewer me for getting the schema wrong); you might have a table describing tracks. Each track would have something like the following attributes: * TrackID (one or more attributes that uniquely identify this track) * ReleaseID (the Release this track is a part of) * Language * Script * TrackName (unicode string; name of the track in the language and script specified) * Duration (time) * Track Number * and so on. There are a few ways multilingual support is typically added in this case. You could add a supporting table that provides alternate track names. Call it the AlternateTrackNameTable. It would link to the primary track table; and provide alternate translations. The track name in the main table would be the default name. It would have a structure like: * TrackID * Language * Script * TrackName Or, you could not have TrackName in the main table; and have a TrackNameID instead; that references a TrackNameTable, or even a general, NameTable that could be used for more than just tracks. That table would have a structure like: * TrackNameID (the ID of the track name) * Language (one of a finite list of languages supported) * Script (one of a finite list of scripts supported) * Name (the Track Name in the Language and Script specified) Sorry for going so far down an implementation path. I only added that last bit to help illustrate my point. Obviously there would be a bunch of work associated with this change - schema work, GUI work, etc. etc.
_______________________________________________ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
