Is the Style Guideline № 3:
The main artist sort name should be in Latin script for compatibility reasons.
still actual?
It is quite inconvenient having Latin sort names for artists which primary name is not Latin.
See this comment in English Spelling Vs Japanese Spelling
So, I would not waste much time thinking about this particular guideline.
It is still actual, yes. That might change if it becomes possible to add aliases while adding the artist (but in that case it’s more likely that the sort name field will just get dropped, since it’s basically a legacy field as mentioned by @yindesu). In the meantime, please use Latin (but add aliases).
2 Likes
See this comment in English Spelling Vs Japanese Spelling
So, I would not waste much time thinking about this particular guideline.
Thanks. I know about aliases and intensively use them. For all artists I am interested in I have added “artist name” and “legal name” aliases with proper locale.
However, I still have a problem.
Shortly, I can easily read names/titles written in Latin, Cyrillic, and Greek scripts. So, I do not want all artist names are transliterated to one language. Instead, I want all artist names written in scripts I understand are left intact, and only names written in scripts I cannot read (Japanese, Armenian, Hebrew, etc) are translated/transliterated to English.
Currently Picard tagger does not have such functionality, so I am working on Picard plugin. For a given artist, I have id, name, sortname, and list of aliases. If name is not in script I can read, then I search the list of aliases for a primary alias for desired locale and take name and sortname from it. If name is in script I can read, it sounds good — I have artist name without any searching, but actually I am in a trouble: I have sortname without any searching, but in case of non-Latin name sortname is Latin and so useless. Oops.
Let me think on a workaround. For the artist, I have a list of aliases for bunch of locales. There is (not more than) one primary alias for a locale. But it is not clear which locale is primary. Oops.
You wrote:
…“Sort Name” in the database. This is a useless column…
Artist’s sortname would be useful if it match name (i. e. written in the same script). Alternatively, one of primary aliases should be marked as “super primary”.
That is indeed a problem… A couple of things you could try. Look for an alias which matches the artist name—hopefully there is only one. That seems like the best way to enter in a non-Latin sort name. Works for Tchaikovsky at least. You could also look for an alias matching the artist’s “Area” field.
Presumably, if we ever get rid of the artist name (and only use aliases), we’d add a way to mark one of the aliases as the “super primary” as you put it. It’d make a for a cleaner/more normalized schema, but no idea if it’ll ever happen.
Of course, some artists worked in different areas over their lives and used several different names localized to wherever they were working at the time—there isn’t always a “super primary” alias.
1 Like
Looking at Tchaikovsky, he has one alias marked as primary without any locale. It’s currently not the Cyrillic we’d want, but that might be a good way to indicate “native” aliases, perhaps with a UI update to make the semantics clearer. It does mean we’d wind up duplicating data (which anyone who remembers my stance on inheritance of work relationships will know I hate) and we’d definitely need to add something to the reports for cleanup, but it wouldn’t need any change to the schema. Alternately, we might be able to update aliases to allow multiple locales, to help keep things in sync without having to select which alias to use manually.
I do have two concerns/things to consider: first, how do we handle country locales? Aliases are obviously supposed to be location-agnostic, but until we start actually using them somewhere, there’s very little reason for reviewing editors to have paid much attention to enforcing that, and there’s probably a number currently out there that are overly-specific. It does make sense to select “English (United States)” in Picard, but what happens if the only English alias is marked “United Kingdom”?
Second, the order of preference is going to be different between artist and artist sort: if I were to standardize artist names, I’d want the primary native alias chosen rather than the English translation, but I want the sort order to use the native alias only after working through each of the locales I explicitly specify.
Either way, I’m really hoping this finally makes its way into MB and Picard, because the release sort order won’t be far behind. I do still advocate using aliases for translating/transliterating track titles as well, replacing pseudo-releases, but that can be the next step once we get the simpler ones implemented
… I didn’t know that could happen and I think that’s a bug. @Bitmap / @yvanzo, is it or is this supposed to happen?
A way to get rid of pseudoreleases has been in the works for a while, @Bitmap could tell you more about how ready it is, but it’s definitely happening.
Actually, it is the primary alias for Norwegian, but the locale name is not displayed because the locale code is not recognized anymore. It affects every alias with locale code no (for Norwegian), whereas currently accepted codes are nb (for Norwegian Bokmål) and nn (for Norwegian Nynorsk). Native speakers are welcome to help out with sorting this bug, see MBS-9441.
To get back to the topic: aliases can be marked as primary for a specified locale only.
2 Likes
As @reosarevok says, it is being worked on (alternative tracklists, cf. link below). But please be patient as I can only imagine how difficult this change must be.
And we still have the pseudo releases (work around) so no big hurry.
Good luck, @Bitmap.
1 Like
A couple of things you could try.
Thanks, I already thought about these two approaches, but I did not yet decide which one is better for my needs. The first approach looks working. “Area” looks less reliable. Sometimes it is a country, sometimes city, and frequently it is not set at all. I am still experimenting.