Alias locales have always been one of the most commonly misunderstood fields (editors may think e.g. “this legal name sounds English, I shall certainly set the English locale on it!”). The choice of not making this field a bit harder to discover never did us many favours there.
Now we display primary aliases much more prominently (1, 2), with excellent intentions. However, this makes the pre-existing issue even more evident; in some cases, the increased visibility of primary aliases even provides a visual reinforcement to unsuspecting editors in perpetuating their incorrect editing patterns, e.g. entering legal names with an unnecessary locale and set as primary for that locale.
In short, I think we ended up in a situation where the documentation/style guidelines tell one story to the initiated and the UI tells a different one to the uninitiated.
Is it time to revisit the UI for alias locales, treating it as an advanced field most editors shouldn’t worry about?
Ccing @aerozol as our design expert and @reosarevok and @derat for their recent work on displaying primary aliases more prominently.
Otherwise, do you have any suggestions? Because (in classic MB style) adding an alias already takes a few steps - I don’t know if we should bury any elements deeper.
I was even thinking about having the field not visible by default (e.g. hidden behind a “locale” icon), so that only editors who know their way around can find it.
Admittedly, I come to it from the frustration of having had to unset these values so many times.
Wouldn’t setting alt text as appropriate take care of the accessibility issue? As for seeding, I imagine that if the field is (being) populated, it could be made always visible. (btw, do we have any scripts seeding these values? I thought they were all being manually set.)
If you think about it, showing advanced options to regular users is user-hostile too. That’s a reason so many UIs have basic & advanced modes.
Do you have some examples of incorrect names for specific locales? In most cases, a name that sounds English is likely to be the primary for the English locale.
Is there any documentation about alias locales beyond what appears in Aliases - MusicBrainz and Style / Aliases - MusicBrainz? If not, a good first step might be to make the docs clearer about when locales should and should not be set.
This is currently in Aliases:
For example, you can set a locale to reflect the area in which an alias is used.
…
In these cases [referring to Чайковский/ vs. Tchaikovsky], an alias locale should be added to indicate the language the alias is written in.
This is currently at the top of Style/Aliases:
The locales should be used to indicate an alias is a name used for an entity in a particular language and/or country. The main alias for each locale (the most recent one, or the most common if otherwise equivalent) should be marked as primary.
The locale should not be more specific than it needs to be, so the country should only be included when necessary, e.g. If an entity’s name is the same in all English speaking countries, “English” with no country is sufficient. If the name is normally the same, but is different (usually for legal reasons) in certain countries, then the country should only be used to identify where the name is different from the usual name for that language.
While it’s arguably already covered by “should not be more specific than it needs to be”, maybe there should be at least one more sentence along the lines of:
Do not set a locale if the entity is not known by multiple names across different languages or countries.
(That’s assuming that my interpretation of the guidelines is correct, which I’m not completely sure of! For example, I think I also typically avoid setting locales for aliases that are in the same locale as the entity’s main name. Old feature requests about entities lacking support for a “default locale”: MBS-7522, MBS-7807, MBS-7830)
Right, I think we are starting to point at the different dimensions of why the current handling of alias locales is not great. Let’s try to go over them one by one and see if we can identify some actionable points. This means broadening the scope of the discussion to issues other than UI, but that might be unavoidable after all.
First, the technical shortcomings: leaving transliterated names aside, we don’t have a way to assign scripts (rather than languages) to aliases (relevant ticket: MBS-5192). A large part of the problem I’m raising stems from editors setting locales for aliases that have no locale-specific content and where the only appropriate locale would be a script.
(By way of example, let’s suppose artist “JD” has legal name “John Doe”, which is undeniably in Latin script. Their legal name will still be “John Doe” well beyond the reach of the English locale, at least for contemporary artists. Or let’s take one of my favourite real life examples and see what locale should be set there.)
Second, the brief and sparse documentation, as highlighted by @derat. In another example, I recently tried to explain the concept of “primary alias” to a fellow editor, but the definition didn’t seem quite clear enough to them. If the definition can’t be expanded, maybe more examples of dos and don’ts could help, if we can find consensus on them.
Third, the UI per se, which exposes locales to less experienced editors who really shouldn’t worry about them until they have mastered more basic MB concepts.
Curious to see if the discussion yields at least some improvements to the status quo. I would be delighted to see progress in any of these areas.
I agree with most of your other issues but I entirely disagree with this. If the name most commonly used in English for an artist is X, then that is its English locale primary alias. It’s not saying it is in English even, it’s saying when localizing into English, that name should be used.
For a kinda stupid example, “Bulbasaur” is not really an English name, nor a Spanish name or an Italian one, but it should still be the primary English, Spanish and Italian alias for that pokemon - while the French one should be “Bulbizarre”.
In cases where a Japanese composer is known in most of the west as “Tōru Takemitsu”, that is a correct English alias (and probably also French, Italian, etc.). Of course, it wouldn’t be a correct Latvian alias, which is also Latin script; that’d be “Toru Takemicu” - which is an example of why the idea that just setting script is enough is dubious anyway.
We would (we should!), and that is okay. It’s how the system is supposed to work. You are of course not required at all to add any aliases other than for your own locale (well, not even that but you know what I mean). Just don’t stop others from entering theirs.
Wouldn’t it be more parsimonious (in terms of editor time, screen space, etc.) to have scripts as default locale setting, with languages overriding them only where warranted and explicitly set? E.g. scripts would be the default locale, unless editors set a language for a specific alias.
Regardless of the technical solution that is chosen, I still think the documentation should be made more comprehensive and prescriptive.
We have locales, the primary setting, as well as types: with the current UI and documentation, editors might be tempted to conflate some of these fields (as apparent from the discussion in one of the edits I linked above). Plus there are relatively common cases where we don’t have guidance (e.g. the one brought up in this discussion).
I’m firmly of the opinion that you can never have too many aliases
that said, some clarity on this might be good. looking at an alias page like for HO-KAGO TEA TIME, it can get a bit confusing (note, I’ve personally done minimal work here)
transliterated, the name is HO-KAGO TEA TIME (with some variation, as there’s several common ways to transliterate Japanese), and translated, the name is After School Tea Time. in this case, the primary alias is pretty clear (and actually used on most of the singles’ cover art while they went by this name), but it does look a bit odd to see a transliterated Japanese name as an English alias
also, determining the difference between a search hint and an artist name is a bit confusing, specifically this line in the docs (emphasis mine):
{Entity} name aliases show how people refer to the entity. Search hints are mainly used for common misspellings, name variants with different encoding and other correct ways of displaying the entity’s name.
it almost sounds like the definitions of search hint and {x} name aliases overlap here
Feel free to discuss the changes - I’m fairly certain of the general direction I want to go with them but there might be things that need to be adjusted and improved before transcluding.
I added these Takemitsu Latin aliases to illustrate the problem of not having a Latin script, or some system like that. Like the Europe and [worldwide] Areas we have.
We have to add many redundant aliases otherwise it only works for English.