artists Reply-To: In-Reply-To: <CAKHWUkYEEL7uN6pfpWDMNnFqPpTMY-6KhAg753rop40TS4M=n...@mail.gmail.com> Errors-To: ianmcorvi...@ianmcorvidae.net X-Operating-System: GNU/Linux x86_64 3.4.4-2-ARCH X-Editor: VIM - Vi IMproved 7.3 (2010 Aug 15, compiled Jun 7 2012 00:47:58) X-Accept-Primary-Language: en X-Accept-Secondary-Language: de X-Accept-Tertiary-Language: eo X-Google-Loop: groups
On Mon, Jul 23, 2012 at 08:03:55PM +0200, Philip Jägenstedt wrote: > On Mon, Jul 23, 2012 at 4:23 AM, Calvin Walton <calvin.wal...@kepstin.ca> > wrote: > > On Sat, 2012-07-21 at 09:07 +0200, Philip Jägenstedt wrote: > >> On Fri, Jul 20, 2012 at 4:02 PM, Calvin Walton <calvin.wal...@kepstin.ca> > >> wrote: > >> > On Fri, 2012-07-20 at 15:07 +0200, Philip Jägenstedt wrote: > >> >> http://musicbrainz.org/doc/Style/Artist/Sort_Name says: > >> >> > >> >> "All artist sort names should be in Latin script. If the artist's name > >> >> is normally written using a non-Latin script, use the Latin script > >> >> translated or transliterated name by which the artist is most commonly > >> >> known." > >> >> > >> >> For Chinese artists, this is problematic in several ways: > >> > > >> > TL;DR: Leave the artist Sort Name as Latin (if possible), and add an > >> > alias marked as Primary with the locale set to Chinese that has the > >> > correct Chinese name and an appropriate Sort Name. > >> > >> What is an appropriate sort name? If it is in Latin script, problems > >> 1-3 would remain. > > > > No, the sort name for a locale alias should be in whatever script > > someone in that locale would expect to use when sorting. > > > > In the Japanese locale the artist name might be in either Latin or > > Chinese characters (Kanji), but in either case the sort name would be in > > Kana (Hiragana or Katakana). > > > > For example, the top two "Primary" aliases shown on > > http://musicbrainz.org/artist/b6c18308-82c7-4ec1-a42d-e8488bce6618/aliases > > demonstrate this. > > Yeah, that looks good to me, assuming that Japanese is conventionally > sorted by kana and that's what people want to see in their music > libraries. It will cause a Japanese artist and a Chinese artist by the > same name to be sorted differently, but that is not a big problem to > me at least. > > >> > Many of these same issues apply to Japanese artists as well, and we've > >> > been dealing with it. Instead of answering your RFC directly, I'm going > >> > to give you a vision of what I'm hoping will come about. (I'm still > >> > working out the details, but I hope to submit a proposal for an upcoming > >> > schema change release regarding the changes.) > >> > > >> > For legacy reasons, we really can't just redefine the artist sort name > >> > field at this point. > >> > >> What legacy reasons are those, that make it impossible to redefine to > >> redefine the artist sort name but possible to remove it completely? > > > > For backwards compatibility, it would probably be necessary for the sort > > name field in the webservice API to return a Latin sort name even if we > > have something better - the real sort names will be in the alias section > > of the response. > > This will likely be done by making the top-level sort name field in the > > API use the sort name from a prioritized list of locales that use latin > > script. (e.g. use the English sort name if there is one, otherwise use > > French, ...) > > > > This might end up not being the case - I'd love it if a Musicbrainz > > developer would hop in with an opinion about whether we can change > > that :) I agree that the latin sortname should probably stay as the default sort name in the base WS response. We don't know what uses this field, unfortunately, which means we shouldn't change the conventions WS users may have come to rely on. > > Clients that actually use the sort name for sorting would seem well > served by getting strings useful for sorting. I guess we're worried > about clients that use the sort name to get an "English" name? Would > it be a problem if they notice that it's not working very well and > that there's a new and better way to do the same thing? > > My motivation for all of this is being able to remove my Picard hack > $set(artistsort,%artist%), so if the web service stays the same then > there's no point, for me. > The other alternative here is for Picard to be the layer where the choice of localized sort name is made. Whatever level it's implemented at, there's a question of how to determine the correct locale to use; I wonder what you'd propose as a general criterion for when to use the sort name from a particular locale over any other locale. There's one more hiccup I feel should be noted: collation algorithms. I believe in general we recommend using libicu-style unicode collation, which may or may not fit with the assumptions you're making; I know there are alternatives to this collation method, and that they're generally along locale lines. So it would be nice to define what collation algorithm we're talking about or recommending for sort names, if there is one, and perhaps exploring further how the choice of algorithm affects sorting, especially in these locale-specific cases. > -- > Philip Jägenstedt > > _______________________________________________ > MusicBrainz-style mailing list > MusicBrainz-style@lists.musicbrainz.org > http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style -- Ian McEwen <ianmcorvi...@ianmcorvidae.net> <ih...@hampshire.edu> A262 D5C4 40CB 0E1C 5F24 C3A1 ABED 1ABD 7131 A76F http://ianmcorvidae.net/
pgp8jxsUS73ru.pgp
Description: PGP signature
_______________________________________________ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
