This is by design, so it should probably be a won't fix.

The locales are supposed to represent the primary name for the artist/label/work in another language, so just like we only have one artist or work name, we only have one primary artist or work alias for a language. At some point we would like to display localised names on the website, so that instead of seeing a bunch of squiggles, the system can automatically display the English name for people who can't read Russian for example. Other things using the data such as Picard would be able to do similar things too.

I understand the intention but IMHO it is a bad approach to the problem.

• Instead of marking that an alias is a canonical name by specifying a locale there should be a true / false flag indicating whether the alias is a canonical name in the specified locale or not.

• It is really a pity not to be able to mark locale of aliases. They could be used in the future to prefer certain locales in search results.

• List of large number of aliases could be displayed well-arranged (sorted or grouped by locale) if the locale is specified for every alias.

• It is really confusing for the contributors that they cannot specify the locale in every situation and that specifying the locale has an additional hidden meaning.

I noticed that there is already the issue MBS-1485 which suggests to add type to alias. This would of course be better and more general than adding just a flag for canonical translation/transliteration as I suggested above.

I think that partial workaround should be to allow freely specifying locales and implement alias type later as it requires database schema change.

Adding a flag marking the primary name is also a schema change.

I'm not sure what you mean freely specifying locales, nor what you mean by "prefer certain locales in search results"...

> Adding a flag marking the primary name is also a schema change.
I meant not changing the schema at all for now neither by adding the type nor by adding the flag.

As I understand it the translation/transliteration is not used yet anyhow so the limitation of one occurrence of certain locale in one alias list could be simply removed. (This is what I meant by "allow freely specifying locales".) Later the alias type attribute could be implemented together with translations/transliterations of canonical titles.

> "prefer certain locales in search results"
For example user selects that he would like to prefer Spanish titles in searches then search results would be sorted so that Spanish titles are listed close to the beginning of the results list.

By design; any changes would be an improvement, but it's not a bug at the moment.