This page is an archive. Do not edit the contents of this page. Please direct any additional comments to the current main page. |
Billboard album and single charts changed their URL. There are some complicated cases which we are still figuring out, but the majority are quite simple, see discussion.
https://www.billboard.com/music/Madonna/chart-history/TLP
https://www.billboard.com/artist/Madonna/chart-history/TLP
Or more generally
https://www.billboard.com/music/*/chart-history/*
https://www.billboard.com/artist/*/chart-history/*
The search times out after 2600 of them, so I am not sure how many there are in total. -- Muhandes ( talk) 14:21, 17 November 2021 (UTC)
|archive-url=
in place, replace the |url=
with the new URL, and toggle |url-status=live
2) Same as 1. except replace |archive-url=
with an archive to the new URL 3) Same as 1. except delete the archive URL. Consider chart history data can be subject to content drift, and citations verify based on page content on the date the citation was made. It actually raises questions if these URLs should just be treated as all dead and archive URLs added for everything, based on the |access-date=
with an archive URL close to that date. Similar issue with the template version. Billboard charts is not an area I am familiar with and will leave to you and others to decide best option. --
Green
C 19:29, 18 November 2021 (UTC)
|archive-url=
. While in many cases this URL can be improved, I would still suggest we
assume this was done by an editor who tested the archive and verified it includes the information. In that case, leave it be.|archive-url=
. Sadly, we know some charts were abandoned in this move. We can recognize them by the code after /chart-history/
.|archive-url=
with date as close as possible to the |access-date=
.|archive-url=
to that. For example instead of an archive to https://www.billboard.com/music/Madonna/chart-history/LUX
we may have an archive to https://www.billboard.com/music/Madonna/chart-history
.canadian-albums
. The chart was either moved to a three letter code (in this case, CNA
) or abandoned. I suggest we have an editor look at these, so just log them./music/
with /artist/
.https://www.billboard.com/music/(artist)/chart-history/(chart)/song/*
. Strip the end: https://www.billboard.com/music/(artist)/chart-history/(chart)
, and treat as case 2.https://www.billboard.com/music/(artist)/chart-history/(chart)/(not "song")/*
. Archive if possible.@ GreenC: Looked at the run, there is one instance I think should have been rule 3 -> 2c:
I thought it should be https://www.billboard.com/artist/Alicia-Keys/chart-history/hsi/
There was also another simple rule I can add for Bill Cosby
https://www.billboard.com/music/*/chart-history/
-> https://www.billboard.com/artist/*/chart-history/
|
|
|
I can add to it when we find more. -- Muhandes ( talk) 08:59, 28 November 2021 (UTC)
{{
dead link}}
is added. --
Green
C 19:11, 28 November 2021 (UTC)
Muhandes, I processed the next 200 articles and more unknown codes appeared, listed at Wikipedia:Link rot/cases/Billboard. -- Green C 20:47, 29 November 2021 (UTC)
rap-song
should be rap
not rsa
), can you please share the logs so I can fix the incorrect replacements? --
Muhandes (
talk) 09:30, 8 December 2021 (UTC)
Results
{{
dead link}}
: 993Muhandes, believe it is done. Really great work finding the new codes and cleaning up errors in the wiki text. I'm going to re-tool the bot for other projects now. Should it be needed can be restored again. Cheers! -- Green C 22:01, 10 December 2021 (UTC)
I found many broken links to this site throughout Wikipedia ( here, for example). Jarble ( talk) 01:33, 27 February 2022 (UTC)
I found several broken links to this site that have not yet been repaired. Jarble ( talk) 19:30, 28 February 2022 (UTC)
I represent an academic journal publisher that has legacy URLs appearing as external links on at least 80,000 Wikipedia pages. Due to a change in both domain name and URL structure, all of these URLs are now deprecated but the citation is still valid and the content is still available. Most URLs result in a 301 or 302 redirect to the correct page. However, redirects are not a permanent solution and may fail in the future.
The affected pages include the most trafficked and most influential pages on Wikipedia including, for example:
What is the best way to inventory and update these external links en masse?
We don't want broken links to be archived. We want the opportunity to fix them before a bot updates the pages. Is there a recommended method for collecting all the current external links from wikipedia before initiating a 'bot to update the citations? — Preceding unsigned comment added by SibeliusHicks ( talk • contribs)
My bot can help. Would need a list of domain names eg. science.org etc.. if redirects already exist it's pretty trivial to migrate the URLs. When there are no redirects, we can discuss other methods based on info available about new URL structure. The goal is to migrate to the new URL, not to add archives, where possible. The bot will attempt to migrate to the new URL and change any existing |url-status=dead
to live, or remove any existing {{dead link}}
. If it can't find a migration destination it will add an archive URL and log. If it can't find an archive URL it will add a {{dead link}}
and log. It will do these things for citations in template format like cite journal, or when square and bare links. --
Green
C 01:29, 4 March 2022 (UTC)
Can we discuss, and possibly develop a "bot tasking" for "real time repair" of internal linkrot caused when page sections are moved by "cut and paste"? Currently, when relisting XFD threads and archiving page sections, the incoming Page#Section links are broken and the backlinks are not subsequently repaired (being left inoperable). In my opinion, this is untenable when corrective measures are within technical capabilities of relative ease. I propose that we undertake correcting the current situation and invite further discussion here (with keen anticipation). Thank you.-- John Cline ( talk) 16:41, 5 March 2022 (UTC)
This website has been hijacked and is now pushing out malware to visitors. It is cited over 250 times in railway articles. Can it be marked as a dead usurped link as a matter of urgency? (Also requested to add to the mediawiki blacklist)
10mmsocket (
talk) 16:38, 26 March 2022 (UTC)
In short the C-Span Template using a numeric ID is more reliable as string changes are not reliably redirected see also the Wikidata P2190 Discussion. Querying the C-Span URL generated by the template will return a response which includes the new ID for resolving links. For the items in Wikidata, this has been done for those string IDs added prior to 26 Feb 2022 (those added after that date haven't been checked and those before with no numeric are broken). The ID values are available to swap and fix the root cause of link rot, but there are 5 or 6 thousand more uses of C-Span templates on EN Wikipedia that may not have been imported to Wikidata and are at risk of breaking or are broken. If a bot could 1. replace existing strings with the numeric matched on P2190 this would be the first step in fixing the issue. 2. Have the bot query and parse the response URL to get the new ID for numeric not in Wikidata. For the Wikidata batch processing I did about 10% needed manual resolving due to the URL changing or there being no clear match after manual search by name variants. Generating a list to review and the associated page/wikidata Q for these would be useful as well to review any manual clean up of broken links. Anyone have a bot that can do this or will take on this fix? Wolfgang8741 says: If not you, then who? ( talk) 16:24, 14 March 2022 (UTC)
This page is an archive. Do not edit the contents of this page. Please direct any additional comments to the current main page. |
Billboard album and single charts changed their URL. There are some complicated cases which we are still figuring out, but the majority are quite simple, see discussion.
https://www.billboard.com/music/Madonna/chart-history/TLP
https://www.billboard.com/artist/Madonna/chart-history/TLP
Or more generally
https://www.billboard.com/music/*/chart-history/*
https://www.billboard.com/artist/*/chart-history/*
The search times out after 2600 of them, so I am not sure how many there are in total. -- Muhandes ( talk) 14:21, 17 November 2021 (UTC)
|archive-url=
in place, replace the |url=
with the new URL, and toggle |url-status=live
2) Same as 1. except replace |archive-url=
with an archive to the new URL 3) Same as 1. except delete the archive URL. Consider chart history data can be subject to content drift, and citations verify based on page content on the date the citation was made. It actually raises questions if these URLs should just be treated as all dead and archive URLs added for everything, based on the |access-date=
with an archive URL close to that date. Similar issue with the template version. Billboard charts is not an area I am familiar with and will leave to you and others to decide best option. --
Green
C 19:29, 18 November 2021 (UTC)
|archive-url=
. While in many cases this URL can be improved, I would still suggest we
assume this was done by an editor who tested the archive and verified it includes the information. In that case, leave it be.|archive-url=
. Sadly, we know some charts were abandoned in this move. We can recognize them by the code after /chart-history/
.|archive-url=
with date as close as possible to the |access-date=
.|archive-url=
to that. For example instead of an archive to https://www.billboard.com/music/Madonna/chart-history/LUX
we may have an archive to https://www.billboard.com/music/Madonna/chart-history
.canadian-albums
. The chart was either moved to a three letter code (in this case, CNA
) or abandoned. I suggest we have an editor look at these, so just log them./music/
with /artist/
.https://www.billboard.com/music/(artist)/chart-history/(chart)/song/*
. Strip the end: https://www.billboard.com/music/(artist)/chart-history/(chart)
, and treat as case 2.https://www.billboard.com/music/(artist)/chart-history/(chart)/(not "song")/*
. Archive if possible.@ GreenC: Looked at the run, there is one instance I think should have been rule 3 -> 2c:
I thought it should be https://www.billboard.com/artist/Alicia-Keys/chart-history/hsi/
There was also another simple rule I can add for Bill Cosby
https://www.billboard.com/music/*/chart-history/
-> https://www.billboard.com/artist/*/chart-history/
|
|
|
I can add to it when we find more. -- Muhandes ( talk) 08:59, 28 November 2021 (UTC)
{{
dead link}}
is added. --
Green
C 19:11, 28 November 2021 (UTC)
Muhandes, I processed the next 200 articles and more unknown codes appeared, listed at Wikipedia:Link rot/cases/Billboard. -- Green C 20:47, 29 November 2021 (UTC)
rap-song
should be rap
not rsa
), can you please share the logs so I can fix the incorrect replacements? --
Muhandes (
talk) 09:30, 8 December 2021 (UTC)
Results
{{
dead link}}
: 993Muhandes, believe it is done. Really great work finding the new codes and cleaning up errors in the wiki text. I'm going to re-tool the bot for other projects now. Should it be needed can be restored again. Cheers! -- Green C 22:01, 10 December 2021 (UTC)
I found many broken links to this site throughout Wikipedia ( here, for example). Jarble ( talk) 01:33, 27 February 2022 (UTC)
I found several broken links to this site that have not yet been repaired. Jarble ( talk) 19:30, 28 February 2022 (UTC)
I represent an academic journal publisher that has legacy URLs appearing as external links on at least 80,000 Wikipedia pages. Due to a change in both domain name and URL structure, all of these URLs are now deprecated but the citation is still valid and the content is still available. Most URLs result in a 301 or 302 redirect to the correct page. However, redirects are not a permanent solution and may fail in the future.
The affected pages include the most trafficked and most influential pages on Wikipedia including, for example:
What is the best way to inventory and update these external links en masse?
We don't want broken links to be archived. We want the opportunity to fix them before a bot updates the pages. Is there a recommended method for collecting all the current external links from wikipedia before initiating a 'bot to update the citations? — Preceding unsigned comment added by SibeliusHicks ( talk • contribs)
My bot can help. Would need a list of domain names eg. science.org etc.. if redirects already exist it's pretty trivial to migrate the URLs. When there are no redirects, we can discuss other methods based on info available about new URL structure. The goal is to migrate to the new URL, not to add archives, where possible. The bot will attempt to migrate to the new URL and change any existing |url-status=dead
to live, or remove any existing {{dead link}}
. If it can't find a migration destination it will add an archive URL and log. If it can't find an archive URL it will add a {{dead link}}
and log. It will do these things for citations in template format like cite journal, or when square and bare links. --
Green
C 01:29, 4 March 2022 (UTC)
Can we discuss, and possibly develop a "bot tasking" for "real time repair" of internal linkrot caused when page sections are moved by "cut and paste"? Currently, when relisting XFD threads and archiving page sections, the incoming Page#Section links are broken and the backlinks are not subsequently repaired (being left inoperable). In my opinion, this is untenable when corrective measures are within technical capabilities of relative ease. I propose that we undertake correcting the current situation and invite further discussion here (with keen anticipation). Thank you.-- John Cline ( talk) 16:41, 5 March 2022 (UTC)
This website has been hijacked and is now pushing out malware to visitors. It is cited over 250 times in railway articles. Can it be marked as a dead usurped link as a matter of urgency? (Also requested to add to the mediawiki blacklist)
10mmsocket (
talk) 16:38, 26 March 2022 (UTC)
In short the C-Span Template using a numeric ID is more reliable as string changes are not reliably redirected see also the Wikidata P2190 Discussion. Querying the C-Span URL generated by the template will return a response which includes the new ID for resolving links. For the items in Wikidata, this has been done for those string IDs added prior to 26 Feb 2022 (those added after that date haven't been checked and those before with no numeric are broken). The ID values are available to swap and fix the root cause of link rot, but there are 5 or 6 thousand more uses of C-Span templates on EN Wikipedia that may not have been imported to Wikidata and are at risk of breaking or are broken. If a bot could 1. replace existing strings with the numeric matched on P2190 this would be the first step in fixing the issue. 2. Have the bot query and parse the response URL to get the new ID for numeric not in Wikidata. For the Wikidata batch processing I did about 10% needed manual resolving due to the URL changing or there being no clear match after manual search by name variants. Generating a list to review and the associated page/wikidata Q for these would be useful as well to review any manual clean up of broken links. Anyone have a bot that can do this or will take on this fix? Wolfgang8741 says: If not you, then who? ( talk) 16:24, 14 March 2022 (UTC)