Yes, its a total pain removing the wikipedia links. I am going to have to go through the whole MusicBrainz database and recreate the wikipedia links from the wikidata links. My customers dont want to see wikidata in their tags and making additional calls to wikipedia to convert these links on the fly is too expensive slowing down the tagging.
5 Likes
Because WP pages are often removed or renamed, in long term.
2 Likes
Are they really, where is your evidence ?
There is no easy way to find all the URL I had to fix in the past.
The most often case is that your page (album, artist, song) is turned into a disambiguation page someday.
Then some bands are deleted as being not notable enough for WP, but that’s not as frequent as first case.
Sometimes also, they fix the page title → URL
But there is no easy way to find those edits back…
WD is made exactly to avoid this.
4 Likes
Well Im not advocating removing the wikidata, but I dont think the fact that a wikipedia link may change is a good reason to not have wikipedia links, most dont change, you could apply that logic to any url from any source
Regarding bands being deleted for not being notable enough, are you saying that their wikidata is never removed even if there are now no pages actually referring to the wikidata.
WD is made exactly to avoid this.
I don’t that is the reason it was created, I think it was created to allow data to be shared on multiple pages rather than having multiple copies.
1 Like
At least one of the purposes of WD is to have a permanent link that collects all the temporary links to WP, Wikimedia, Wikiquote, … That’s why the WD urls contain numeral IDs (like we do with MBIDs) and not names (like WP does).
If a Wikipedia page gets removed, renamed, redirected or whatever the Wiki editors will edit the WD page. So it makes no sense for us to keep our own - always out of date - collection of temporary links if we can simply link to the permanent collection of links provided by the project themselves.
Sure it’s neat to optionally display direct links to WP, but that should be achieved by integrating the script mentioned multiple times before which will almost always supply correct links and not by manually adding temporary links to WP articles in arbitrarily chosen languages that will be displayed to everybody.
This discussion is going in cycles btw.
9 Likes
All of this can be achieved with a WD to WP feature MBS-9771 in the sidebar.
And WD pages will always be maintained remotely.
I have had enough WP page rot in my MB editing life to fully support the move to WD while keeping up to date WP links dynamically displayed in the sidebar.
5 Likes
My point is about the MusicBrainz database rather than the MusicBrainz website, it would be useful if the wikipedia urls were stored in the database.
Otherwise
- I have to use the wikipedia script as user requires meaning which can cause unacceptable lookup delays similar to the problems with the AcousticBrainz Api.
or
- I have to run script over complete database and store the results, however log that will take.
That is just my situation, but my point is that MusicBrainz decision causes hassle for most using Musicbrainz and interested in Wikipedia, it only benefits MusicBrainz editors who have the occasional dead wikipedia link. Therefore it seems to have been done mainly for the benefit of MusicBrainz editors rather than MusicBrainz users.
1 Like
I’m a MB editor because I’m a MB user.
I’m here to manage my humble collection, mostly and to discover stuff that could be linked to what I like.
So I’m an editor just because I want to add my CD in my collection, add missing things and fix things.
The links in the sidebar, I am glad to have them dynamically up to date as a user.
I am glad to have all available WP pages in languages I want rather than only those added by editors (in most cases, only English).
(update)
Oh but I see, you mean users as in remote users, taggers, etc.
In that perspective, yes indeed, MB will give them the best available reference: WD.
From that reference, you will, as @paulakreuzer explained, retrieve all the current WP pages, that are available at that time.
4 Likes
As I explained, it is too slow having to make these extra calls to wikipedia really.
It’s “only” one extra call to Wikidata that gives you all WP pages at once.
But I understand that it still takes more time…
But moreover, having scripts in all possible ways making various parallel calls to this and that when I browse pages, it doesn’t change much and I think WD is built strong to be able to handle lots of calls to its API. Probably stronger than MB.
(update)
To illustrate that it is fast, when I load an MB artist page, the artist photo (that also comes from Wikidata or something like that) usually finishes loading after my WD to WP feature in the sidebar.
1 Like
Its fine if you are just looking up one thing, but if fixing thousands of files it does have an impact or total time, especially if have slow internet connection.
1 Like
My evidence is fixing multiple thousands of these over a one year period a few years back, before we decided that it was way too annoying and Wikidata is better.
Wikidata has a lower requirement for notability, so if the Wikidata page still links to, say, entries in library catalogs and has some extra info, it’s more likely to not get removed. If there’s no info though I would expect the page to get removed too 
Anyway, I do see the issues with the Wikidata extra query - I wonder if there’d be some way to at least cache a link MB-side and serve it when requested, since we’re already loading them for page loads as it is…
6 Likes
THIS ^^^
The Wikipedia info is being loaded for the Artist page. So please just sneak it into the right hand side links for the noobie idiots like me who have never heard of Wikidata.
Make this place as inclusive as possible.
1 Like
I agree. 
I don’t think this kind of language is the way to achieve that. 
3 Likes
I was meaning people like me who had never heard of WD before this conversation (even though I am an old git on the interwebs).
I’ll tweak the words to be more accurate - lolz.
2 Likes
Who gave you the OK to delete Wikipedia-URLs including the english one?
You start a topic here and don’t wait to reach an concensus?
Actually you have over 2’270 open “remove relationsship edits”.
Do I really have to down-vote them all manually until we reach an acceptable solution? With acceptable I mean, a solution that doesn’t only fits your idea?
Of course you can add as much Wikidata links you like, but there is no official policy so far that prohibits Wikipedia-Links. So please stop deleting them!
1 Like
There’s no consensus to reach - removing Wikipedia links is fine (that’s the official MusicBrainz position), and these edits should not be voted down.
If we want those links in the sidebar they should be autogenerated from Wikidata. That’s something that can be talked about and we can ask the dev team to implement it. They should not be stored separately risking them to become outdated.
That said, I feel removing them by hand is kind of a waste of time, honestly, since eventually they’ll just be bot-removed anyway.
6 Likes
You say: First we delete all Wikipedia-Links (“risking them to become outdated”) and maybe - in 5 years or never - we will autogenerate them from Wikidata?
Is this the new way on MB? First to delete visible data (which at least some of us like to see) and hope that no one will ever insists?
And BTW: If that’s the (new) official MusicBrainz position please adjust all the style guides accordingly and
as fast as possible.
2 Likes
The position is that people can add them, but if there’s a Wikidata link present there’s no reason they need to be kept. So nobody should vote No if someone adds one, but if someone has checked the WD link is present, they can be removed.
The only reason we haven’t done much in the way of guidelines about this interim period is that originally the idea was to get rid of all of them automatically in around 6 months (from the blog post announcement) - when that didn’t happen because nobody had the time, we got stuck with this in-between situation. But the goal is still very much to remove them.
The links are already being generated, and already linked from the overview page. If we want to show them on the sidebar too, that takes a developer around 20 minutes of coding max, and it’s not a reason to block the already decided removal - because no data is being lost with it.
7 Likes