I happened to discover that the special Label [no label] “(Special purpose label - white labels, self-published releases and other “no label” releases)” has no less than 40 aliases. In the list are such gems as “℗ 2012 Jungle Doctors” and “INDIPENDANT”.
It looks like 16 of the aliases were intentionally added. Some (like “N/A”) appear to be search hints to improve the discoverability of [no label]. Some (like “[самиздат]”, i.e. “samizdat”) appear to be back-door translation of the MusicBrainz application.
Many of the aliases seem to have come when bogus Label entries were merged into [no label]. It seems various editors (and maybe an iTunes import script) created a new bogus Labels in the course of adding self-published Release, instead of discovering and using [no label].
How did I discover this? When I downloaded the XML file of metadata for a [no label] Release, MusicBrainz supplied an XML entity for each alias. Probably correct behaviour, but it is a respect in which these aliases are a little annoying.
Would it be reasonable for me to delete, say, 20 of the aliases which resulted from merging bogus labels? I don’t know enough about the workings of MusicBrainz and of merging to know if deleting a post-merge alias would hurt something.
Or is it wiser to leave this pile of debris untouched, because it only rarely becomes visible and annoying, and because we can’t be sure that deleting it is benign?
That seems too much to me. I would remove the five ℗ aliases, [no label without the closing bracket, and probably demo and the one mentioning George Harrison. The others seem fine to me as either translations (don’t know what you mean by “back-door”?) or search hints.
Oh ok, I think I just caught on!
Because they’re added as search hints it means that someone actively added it as a hint, rather than a lazy typo that just got merged in… makes sense
It’s not correct that, if an alias of type=“search hint” is present, it means that someone “actively added it as a hint”. Looking at the merge release edits for [no label], it’s clear that most of these search hints were “a lazy typo that just got merged in”.
I respect what @reosarevok says, [quote=“reosarevok, post:9, topic:5788”]
typos that got merged in are more useful search hints: they mean the mistake already happened at least once!
[/quote]
But if “at least once” means “only once”, then it isn’t really a big problem. Having excess aliases is an enduring — small, but enduring — cost. The metric that really would help us make this decision is the log of what label names users searched for and couldn’t find, and the log of how often each alias helped a user get to the right label name.
But looking at the alias list now, I think @chirlu 's cleanup is good enough. I’m satisfied.
