When tagging a Japanese album, it’s crucial to have a sort title for each track. Is a track named “辛い” read as “カライ” (karai) or “ツライ” (tsurai)?[1] Only with a sort title tagged will this be handled correctly. In fact, software can’t sort Japanese titles at all without this set.
Judging by an earlier thread, the suggested method appears to be to tag the recording with a Japanese alias. This would work for, for example, a Japanese release of a Michael Jackson album, where one can add a Japanese alias to “Want You Back” with the title “帰ってほしいの” and the sort title “カエッテホシイノ”.[2] Even in this case, however, this becomes problematic, as a later Japanese release might simply title the track “Want You Back”, in which case getting a katakana sort title would make life hard for the user.
The issue becomes more apparent, however, in the case of a Japanese recording having different names on different releases. Take “Sukiyaki”, née “上を向いて歩こう” (Ue o Muite Arukō). This recording is named as-is on multiple releases, which need the sort title “ウエオムイテアルコウ”. But then it’s featured on a Studio Ghibli soundtrack, in the track listing of which it contains a parenthetical – and thus needs a different sort title; “ウエオムイテアルコウ (コクリコザカカラ)”
Is there currently a way to assign a sort title on a per-track basis? If not, how does one go about proposing an addition to the schema?
By common Japanese convention (and JASRAC standard), sort titles are rendered in katakana. ↩︎
Though in my experience, it appears that no tagging software developers implement a way to get this alias – which makes sense, as the alias isn’t tied to that particular release in any way, making it prone to errors or inconsistencies. This is perhaps the real issue at hand here, really: The “alias” system is unusable for tagging. ↩︎
Thank you for being diligent about getting track titles entered correctly. And thank you for bring your expertise about Japanese releases and Japanese language complexities to the project. I know a little about the Japanese language myself.
I am sorry to tell you that you are uncovering the surface manifestation of a very deep deficiency in the MusicBrainz data design. MusicBrainz started a long time ago, with design assumptions centred on the Latin script, Western European languages, and not much attention to supporting all the world’s writing systems in the data model. Over time, improvements have been tacked on. MusicBrainz now is much better able to support a wide range of languages than it was. However, weaknesses remain, and one of those is supporting the less simple cases of sorting.
My general workaround for limitations in the MusicBrainz data model is to put comments in the Release’s Annotation, recording for future editors any facts I think are important but which don’t have a home in the current data model. Someday the data model may improve to the point where future editors can read my Annotation and fill in the improved data. And in the meantime, editors who care can read the Annotations and perhaps get their goals met despite the data model.
So, the most practical advice I offer is to make a section in the Annotation with a listing of Track titles, and for each title, the sort string. Format it clearly and consistently, so that a future editor can figure out what the strings mean and where they start and stop.
Trying to fit the sort strings into the existing data model will be a lot of work and won’t help users much, because of the poor tagger support for sort aliases as you rightly point out. Proposing improvements to the data model is noble, but it will not yield results quickly. Partly because those changes don’t happen quickly, and partly because bringing up this deficiency will bring up many others, and a larger redesign may be the better way to handle them all.
In the meantime, I am glad to have you here, improving the database. Thank you!
I don’t understand why sort names would be needed on tracks?
Here is the ウエオ ムイテ アルコウ sortname for 上を向いて歩こう , in work aliases, where sortnames are, in general.
There is no English sortname there, yet, by the way.
I think it would be possible to do this with recording aliases, tho current support from taggers and whatnot is likely quite limited. in theory tho, you could match the track title to a recording alias to get a track sort name. doing it that way also accounts for different releases with the same track title
as said tho, I don’t know of any program that currently supports this. it could likely be done with a Picard plugin? @rdswift or @outsidecontext?
I would prolly also do the annotation thing as mentioned above
For Picard 2 there is the “Enhanced Titles” plugin, which sets titlesort based on aliases. But for this to work there needs to be an alias that matches the track title exactly, but has a different sort name.
Picard 3 (currently available as an alpha version) allows track title translation from aliases. But I think we don’t handle the titlesort at all, yet. It is a supported tag, but due to a sort name not available on track level this was never implemented to be written.
I think we should add the functionality to set titlesort from aliases to Picard. In the case when track title translation is activated that would be simple, we would just use the sort name from the alias that was also used for translation.
But I’m unsure how exactly the case in this discussion needs to be handled. It doesn’t sound to me that @obskyr wants to generally translate titles to e.g. Japanese. Rather if the track title is Japanese the appropriate sort name should be sellected, right?
As track titles don’t indicate the script, this can’t be made for sure. But we do have some script guessing code that could be used here maybe.
Ah! You’re right about that, now that you mention it: In the case of Sukiyaki, I suppose you could give the recording the aliases “上を向いて歩こう” with the sort title “ウエオムイテアルコウ”, as well as “上を向いて歩こう（コクリコ坂から）” with the sort title “ウエオムイテアルコウ (コクリコザカカラ)”, and software could then match the track title to an alias.
This does, however, feel fragile, as changing the track list after the fact might silently disconnect it from an alias. I think this could still be workable (and even quite pleasant!), however, if aliases were added to the release add/edit interface – see this mockup:
@Jim_DeLaHunt Do you know whether a frontend addition like this might be easier to get support for than a schema change? And if so, who might be the person to talk to? I work as a Japanese translator – and used to work as a full-stack web developer – so I’m champing at the bit to lend my knowledge and effort in any way I can.
I don’t know for sure whether that would make it in to the main website, but it would make an excellent userscript, methinks. I know a lot of power editors use quite a few of those (I most certainly would use such a userscript, as I do a good bit of work on Japanese video game and anime soundtracks and their English translations here and there, lol)
If by “frontend addition” you mean, changing the MusicBrainz web app UI which everyone sees, then I imagine it is almost as hard as getting a database schema change implemented. In both cases, you have to articulate the change, make a case which persuades the people with their hands on the code to agree with you, wait for them to get to your feature in their priority lists, then wait for the change to propagate out to public use.
I don’t know, off the top of my head, where the process for proposing UI changes is written down. However, reading the Development page would give you an idea of the landscape. And the process for proposing changes certainly flows through issues posted to the Musicbrainz bug tracker, so getting access to that is a useful step.
If, however, by “frontend addition” you mean a userscript which runs on your own web browser, and changes the web app UI locally for you only, that is much easier. And userscripts can do a lot. Are you familiar with userscripts (or “GreaseMonkey scripts”)? You can read forum discussion of existing userscripts at the userscripts tag. You could post your idea with that tag, and developers familiar with how to write userscripts will see it.
Overall, my suggestion is to start with defining a userscript and recruiting help to write it. (Or write it yourself, you will learn a ton about the full MusicBrainz stack in doing so.)
