With PICARD-2277 we now allow selection of scripts to ignore for translation. I think this also fixes this issue.

See code changes in pull request #1885 submitted by vladkar.

The problem here for Picard is that it does not know what locale the artist name is in, so enabling the translation will always attempt using a matching locale. I agree that the best fix for this having a proper alias with locale even for the default name in the database.

Yeah - that'd need to be implemented on MBS side and enforced in the database to be an effective solution, I guess. Do you know if there any MBS tickets that deal with this?

Bitmap commented in IRC that one way for this to work would be to standardize on always having an alias which matches the artist name and get the "native" locale from that one. Since my understanding is that ultimately we would like to move the "main" artist name to just pull from the aliases list itself, that would make sense to do anyway.

It doesn't have anything to do with the fix to PICARD-1 - all that fix did was re-enable the function which was disabled for album artists in some work to clean up the confusing use of albumartist and artist inside metadata (thus a regression from earlier stuff). That function and its fix predated the locale-aware implementation - all it handled was "translation" into latin names via the sort name.

In any case, I think there might be another ticket for this somewhere as I've been aware of it for some time. It's really not clear how this could possibly work inside Picard; I just figured the locale should not be set inside MB for aliases which are of the same locale as the artist. Without there being a locale set on the artist entity that it could compare; there is no way for Picard to know what to do, as far as I can see.