I’m wondering what is the benefit of using names with non-latin characters (like cyrillic names for Russian composers). Translations for different languages could use aliases when necessary. It’s just too confusing to edit releases which are full of Russian artists. I might have edited hundreds of releases by the same artist but never seen the name on a same format as we store it in MB. It’s silly that every other site including libraries, music stores and databases seem to be using transliterated names.
Related: MBS-972 Display localised names
3 Likes
Thanks for the link! Seems this has been having status “Decision Required” over 10 years if we count earlier Trac tickets. First ticket starts with the words “this should be implemented soon” 
1 Like
The benefit is that these people have their proper name.
5 Likes
They have their proper names while most of the people aren’t able to read or write their names. Because of this in English language people commonly use transliterated names. No one would type “Чайко́вский composed his first symphony” when you could see “Tchaikovsky composed…”. People would go totally mad if I would propose that Wikipedia would start using native script for person names.
I’m not saying we shouldn’t store this information. I just believe the current way isn’t the best way to do it. For example we have legal name type for alias which could have names in native script. We could also consider adding a new alias type for “native name”.
I can understand how that’s a benefit to artists who care deeply about their “brand”, how their name is presented exactly, etc.—but mostly here we’re talking about folks long dead, who even when alive happily published their music with transliterations of their name. They don’t care what we call them.
I suppose our Russian-speaking users benefit, but our presumably much-larger English-speaking user base is harmed.
2 Likes
And that’s generally fine (though it does cause a number of problems because there are different transliteration schemes, and even more transcription schemes, which is what people actually use). If we had an “English MusicBrainz”, just like there is an English Wikipedia, then we would probably use English transcriptions for the names. But we don’t; MusicBrainz is international. Russian or Japanese or … people have just the same right to their correct names as English or Finnish or … people do.
You are entitled to believe so, and you are certainly not alone, which is why MBS-972 exists (as @CallerNo6 said above) and also MBS-7830 and some related ones.
7 Likes
Also related:
2 Likes
Work to translate MB has already started for 63 languages and 10 of them can already be accessed on our beta site. We currently store info about languages on aliases but aren’t really using it for anything useful. I think Japanese people could use Japanese names on Japanese version of MusicBrainz and don’t see a reason why everyone else would be forced to use these same names. We could still show native names with translated names like Wikipedia does “Dmitri Dmitriyevich Shostakovich (Russian: Дми́трий Дми́триевич Шостако́вич)”.
I think it would make sense to display the English alias for an artist (or label or whatever) on the artist page or in the search results if you’re browsing the English-language MusicBrainz, and the Japanese alias if you’re using the Japanese version of the site etc. But there needs to be some kind of fall back in case there is no alias for the site language (like a user-defined list in order of preference). And artist credits should always display the actual credit.
But all of this looks like something that can be done with a userscript too. Maybe that way it would be easier to figure out what works and what doesn’t before big changes are made to the site itself.
3 Likes
We are not writing articles, we are collecting discographies. We would not translate everything to English. And why English? Why not Korean? 
6 Likes
I think more and more that we should give up the idea of automatic in context alias display.
Now that we have artist credits, we can just type what is appropriate in each tracklist and only care about language and script on tracklists. Which is what we already do btw.
Oh but, I see. I mean give up for tracklists where we already have a good system but it may be useful for people who would prefer seeing transcriptions elsewhere!
For automatic display (of course it should be possible to disable to stay as today) of a transcription everywhere except releases and except pen name artist credits on works as well.
There’s no need to translate everything for every language. We all know that’s impossible. But if we have a transliterated name which is more common than the name in original script… why not to use it? What is the point of forcing everyone to use name which is uncommon for most of us? Wouldn’t it make sense to use name which is the most known? Still the native name would be stored and no data would be lost.
1 Like
All I’ll say is that I heavily disagree with the idea of trying to turn MB into more of an english-centric database.
6 Likes
We will not turn it into an English centric database, please, for whatever’s sake!
The GUI is in English but not the data, and it should never be.
4 Likes
This is where a catch all Latin alias would come in helpful.
It might be most common to you but it might not be most common for everyone, especially not for genuine audience.
5 Likes
I think what @chirlu means by “English MusicBrainz” is “a MusicBrainz which serves only English-speaking users and presents only the content those users expect”. I agree that “MusicBrainz is international”, and delivering only content the English-speaking user expects is an unacceptable retreat.
However, a good way for MusicBrainz to be international is to serve each user in the language they prefer, and generating the content which that user expects. That means the user interface must be translated, of course, and it’s great to see that work under way.
But also, all the human-readable data in MusicBrainz must be translated. For example, MB stores machine-readable data about an Artist, including an MBID 9ddd7abc-9e1b-471d-8031-583bc6bc8be9. MB also stores text of a human-readable name, “Чайковский”. MusicBrainz does not store the data that this text is of a name in the Russian-language characters and conventions, but it should. MusicBrainz does not have a way to store a translation of that name into English-language characters and conventions, e.g. “Tchaikovsky”, but it should. It should also have a way to store translations of that name into German-language conventions, “Tschaikowski”, and Korean-language, “차이콥스키”. It should also have a way of transcribing text from any language to any other language, for the case where no translation is explicitly stored in the database.
MusicBrainz does have a hack for English-language translations of non-Latin-script data: the sortname. That works only because the convention is for the sortname to be expressed according to English-laguage characters and conventions. It doesn’t give the Korean-speaking MusicBrainz user the translation they should expect. Nor, for that matter, does it give correct sorting to anyone but the English-speaking user.
I think making MusicBrainz able to serve each user in the language they prefer is a monumental project. It will require a big database schema change, so that every bit of translatable data is tagged with a language code, and can be joined by translations of that data. It will require functionality to take the target language into account when retrieving data, to look for translations, and to do transliteration when no translation is available. And, it will require the UI localisation already under way. I think it would be a fantastic project to work on.
In the meantime, while I don’t want “Чайковский” to be the name in the English-language metadata for my own music files, I agree that it’s the best choice for an international database with its present structure.
9 Likes
It absolutely does, you can find all of that on the artist’s alias page. What it’s missing is a way to display that information localized to the user’s preferences (and some users’ preferences might not be what you expect)
2 Likes
And I (re-)add above that, that those aliases may be used (if enabled in user settings) for browsing entity pages in general but should never replace track, work and release Artist Credits when looking at a particular edition (release) — well, unless there is another separate user setting that says so.
2 Likes
You are right about aliases. My thinking on the MusicBrainz data model was out of date by a few years. Looking at the current MusicBrainz database schema, I have to concede that it probably stores 80% of what I would want an internationalized MusicBrainz to store. There are aliases for Artist, Place, Area, and Work. We can quibble about the lack of an obvious way to translate recording names, track names, medium types, and work attribute type names.
User preferences for translations will indeed have some unexpected twists. I would happily take originally-German track titles in the original, even though my primary language is English; but I’d rather not get anything in Russian. And to make MusicBrainz really translated, the “localization” aliases need to be better integrated into display and data entry.