Use of disambiguations to store old Place names

So recently someone added a duplicate Place entity for an old name of a particular Place. I merged them back together and lo and behold, the same editor who created the duplicate added a lengthy disambiguation with all of that Place’s former names. In my opinion, these “disambiguations” are nothing more than clutter; we already have an alias field containing all these names, and there’s no risk of mixing this Place up with another, so why do we need to reiterate all this data? If I don’t see the name of a Place I plan to use, I check the alias field of the first result that comes up to see if it’s the Place I need.
I did not make this thread to name and shame a particular editor; I made this thread so we can put this matter to bed once and for all. This is not the first time someone has done this, and I am not aware that it has been discussed at length in recent memory (I think I or someone else made a thread about it on the old forums, but that discussion is now lost).

3 Likes

I think it could be useful for instance for AccorHotels Arena
that most of us will always call Bercy.

That’s another aspect of this I take issue with: people get hung up on/emotionally attached to old names. Just because that’s what everyone remembers a Place as does not mean that that’s its official name anymore.

Emotion yes but not only that, now I know but I could not recognise AccorHotels Arena if I was looking for Bercy as usual.
And maybe AccorHotels Arena sounds very generic as well that it needs Bercy in comment.
What was your example?

My example was the Eventim Apollo, which is commonly referred to as Hammersmith Odeon (a name it hasn’t held since 1992). I didn’t mention it earlier because I first brought this scenario up in another thread.

As an opponent of unnecessary disambiguation comments, I agree that this isn’t very useful. And isn’t the searched alias already mentioned in the inline search?

1 Like

Yes, but only because I set it to Primary in edit #51453928.

That is a rather odd requirement. Could someone shed a light on why that is?

1 Like

What exactly do you mean by “requirement”? Do you mean a mechanical requirement (i.e. the system will lock up if you don’t do X) or a stylistic one?

The requirement to be set as primary alias to be displayed in the inline search results along with an entity’s main name. Whether that’s stylistic or technical I don’t know.

1 Like

It wouldn’t show up that way if it were merely stylistic. It’s built into the system, its original intent I admittedly do not know.
This primary alias trick is one I’ve suggested many times as an alternative to adding otherwise unnecessary disambiguations.

The primary alias should ALWAYS be the current alias, in the appropriate language. It being displayed is supposed to be a help for users using MB, say, in English, when the entities have a main name in a different language (like the Russian composers), and it shouldn’t be hijacked as a way to show older names or anything like that. In most cases, if the place name is in English, it should be the same as the primary alias and as such the alias won’t be shown.

I think what you want is MBS-7483. Which would make a lot of sense, but doesn’t exist yet in MB.

4 Likes

I would also want that in non‐inline search (search pages).

1 Like

If that is technically difficult, perhaps simply a checkbox on aliases for “Include in (inline) search results”?
That would allow explcit flagging of the more notable (and distinct) aliases.

1 Like