Esta página es para solicitar modificaciones a las URL, como marcar como muertas o cambiar a un nuevo dominio. Algunos bots están diseñados para corregir la rotura de enlaces, pueden ser notificados aquí, estos incluyen InternetArchiveBot y WaybackMedic . Esta página puede ser monitoreada por operadores de bots desde wikis en otros idiomas, ya que los cambios de URL son de aplicación universal.
![]() Archivos ( índice ) |
|
Esta página está archivada por ClueBot III . |
¿El bot podría convertir enlaces a httpS?
Hay varios miles de enlaces "http" en la WP a diferentes páginas de mi sitio (cuya página web es http://penelope.uchicago.edu/Thayer/E/home.html ) que en realidad debería ser http S . El sitio es seguro con certificados válidos, etc. ¿Es esto algo de lo que un bot puede encargarse rápidamente?
24.136.4.218 ( conversación ) 19:20, 11 de febrero de 2021 (UTC)
- En general, creo que un bot podría reemplazar http con https para todas las páginas web, después de algunas comprobaciones. (Las pautas prefieren https sobre http, WP: Enlaces externos # Specifying_protocols .) Mi idea ingenua es crear un bot que pase por enlaces http y compruebe si también son válidos con https. Si es así, entonces el bot puede reemplazar el enlace http con el enlace https. Aparte de la pregunta de si existe un problema general con la idea, quedan algunas preguntas:
- ¿Debería el bot reemplazar todos los enlaces o solo los principales (página web oficial, cuadros de información, ...)?
- ¿Debería el bot comprobar solo si https funciona o si http y https proporcionan la misma página?
- Me encantaría escuchar lo que otros piensan sobre la idea. Nuretok ( charla ) 11:43, 5 de abril de 2021 (UTC)
- Un argumento en contra es que muchos sitios web implementan una redirección http -> https. Por lo tanto, si uno accede al enlace con http, será redirigido a https. En este caso, no importaría qué protocolo sea el enlace en WP, el usuario siempre terminaría en https. Incluso el ejemplo citado anteriormente se redirige. - Srihari Thalla ( charla ) 19:09, 8 de abril de 2021 (UTC)
- Tiene razón, muchos sitios web reenvían http a https, pero esto aún permite un ataque Man-in-the-middle cuando alguien evita esta redirección. Esta es una de las razones por las que las directrices de Wikipedia recomiendan el uso de https y existen complementos de navegador como HTTPS Everywhere . Por supuesto, todos son libres de usar https en todas partes, pero proporcionar buenos valores predeterminados (https en este caso) generalmente se considera una buena práctica. Por cierto, en lugar de verificar cada sitio individualmente, hay una lista de servidores que admiten https que el bot podría verificar para ver si quiere pasar de http a https. Nuretok ( charla ) 08:20, 17 de abril de 2021 (UTC)
- Un argumento en contra es que muchos sitios web implementan una redirección http -> https. Por lo tanto, si uno accede al enlace con http, será redirigido a https. En este caso, no importaría qué protocolo sea el enlace en WP, el usuario siempre terminaría en https. Incluso el ejemplo citado anteriormente se redirige. - Srihari Thalla ( charla ) 19:09, 8 de abril de 2021 (UTC)
observer.com
Encontré muchos enlaces rotos a www.observer.com: algunos (pero no todos) de estos enlaces ya no conducen a los artículos que se citaron originalmente. Jarble ( charla ) 21:04, 13 de febrero de 2021 (UTC)
- Dado que se trata de una mezcla de vivos y muertos, probablemente sea mejor dejarlo para IABot, que debería poder detectar a los muertos. - Green C 03:19, 14 de febrero de 2021 (UTC)
- @ GreenC : IABot no los detectará. Intenté ejecutar IABot en esta página , pero el enlace sigue siendo incorrecto. Jarble ( charla ) 21:35, 11 de marzo de 2021 (UTC)
IABot no funcionará. Es bastante complejo. La primera impresión es cualquier cosa que "https" esté bien. Cualquier cosa "http" sin un nombre de host también está bien. Eso lo reduce a alrededor de mil posibles problemas de URL . De estos, algunos funcionan y otros no. Algunos también están redireccionando a la necesidad de enlaces de spam |url-status=unfit
. Hay patrones, pero también excepciones. Es posible que necesite hacer una prueba, registrar lo que hace, crear reglas para tener en cuenta los errores y luego hacer una prueba en vivo. Es difícil decir de antemano cuáles deberían ser las reglas. Tomará algún tiempo averiguarlo, hay muchas variables. - Green C 01:45, 12 de marzo de 2021 (UTC)
Resultados
- 121 URL modificadas ( ejemplo )
- 412 URL archivadas ( ejemplo )
El resto ya estaba archivado o todavía funcionaba o ahora estaba etiquetado con . Una vez que se identificaron las redirecciones soft404, no fue demasiado difícil. Si ve algún problema, hágamelo saber. @ Jarble : - Green C 21:39, 13 de marzo de 2021 (UTC){{dead link}}
whitehouse.gov
Muchos enlaces de whitehouse.gov han muerto después de que el dominio "cambiara de propietario" recientemente. Una rara ocasión en la que muchos wikipedistas pueden alegrarse de que las fuentes mueran. Hay un archivo en https://trumpwhitehouse.archives.gov . Ejemplo de URL de trabajo nueva y vieja rota:
- https://www.whitehouse.gov/briefings-statements/president-donald-j-trump-award-national-medal-arts-national-humanities-medal/ ( archive.org 7 de enero de 2021 )
- https://trumpwhitehouse.archives.gov/briefings-statements/president-donald-j-trump-award-national-medal-arts-national-humanities-medal/
Existe una pequeña posibilidad / riesgo de que algunos de los enlaces rotos vuelvan a funcionar en unos cuatro años. Algunos enlaces de whitehouse.gov funcionan y no se deben cambiar. ¿Puede un bot solucionarlo? PrimeHunter ( charla ) 13:09, 25 de febrero de 2021 (UTC)
- Algunos enlaces de fuentes más antiguos se encuentran archivados en https://obamawhitehouse.archives.gov o https://georgewbush-whitehouse.archives.gov .
- Ejemplo de Obama de vínculo roto y funcional:
- https://www.whitehouse.gov/the-press-office/statement-press-secretary-sjres-33
- https://obamawhitehouse.archives.gov/the-press-office/statement-press-secretary-sjres-33
- Ejemplo de Bush de enlace roto y funcionando:
- https://www.whitehouse.gov/nsc/nss/2006/intro.html
- https://georgewbush-whitehouse.archives.gov/nsc/nss/2006/intro.html
- Algunos enlaces funcionan mediante redireccionamientos:
- redirecciona a
- https://www.archives.gov/presidential-libraries/archived-websites también menciona los archivos de Clinton. El más nuevo es https://clintonwhitehouse5.archives.gov/ de enero de 2001. No sé si tenemos enlaces rotos que podría arreglar.
- Un bot podría probar todos los enlaces de whitehouse.gov para ver si funcionan ahora o en alguno de los archivos. PrimeHunter ( charla ) 14:02, 25 de febrero de 2021 (UTC)
- De acuerdo, según su investigación, estoy de acuerdo en que vale la pena explorarlo para ver qué tan bien funciona. Echaremos un vistazo. - Green C 14:25, 25 de febrero de 2021 (UTC)
- Resultados : se modificaron 8.263 URL en 5.060 artículos. Información de metadatos modificada como
|work=whitehouse.gov
. Además de otras correcciones generales de WaybackMedic. Cuestión de curiosidad: el 67% se encontró mediante el método de escaneo descrito anteriormente y el resto tenía redireccionamientos funcionales en el encabezado. La mayoría de las redirecciones de trabajo eran Obama, Trump tenía una alta proporción de 404 y ninguna redirección, quizás mal mantenidas y / o demasiado pronto después de dejar el cargo. Además, algunas páginas (¿10%?) No pueden ser archivadas por ningún servicio de archivo web, simplemente no funcionan, hay algo en la página que impide el archivo web por parte de terceros, pero independientemente de que sigan funcionando en el Archivo Nacional. @ PrimeHunter : - Green C 16:46, 3 de marzo de 2021 (UTC)
- @ GreenC : ¡Genial! Muchas gracias. ¿Tiene una lista de enlaces rotos que no se pudieron arreglar? Noté uno en [1] : https://www.whitehouse.gov/the-press-office/2013/05/20/president-obama-announces-sally-ride-recipient-presidential-medal-freedom . Redirige pero el objetivo no funciona. Gracias por comprobar la redirección no ayudó. Resultó ser culpa nuestra. El enlace real [2] no tenía una m final que fue agregada por un editor descuidado en [3] , por lo que no hay una solución general que podamos aprender de eso. PrimeHunter ( charla ) 22:30, 3 de marzo de 2021 (UTC)
- Hubo 30: Wikipedia: Link rot / cases / whitehouse.gov - Green C 22:55, 3 de marzo de 2021 (UTC)
- @ GreenC : Gracias. Ese es un buen número bajo. He arreglado muchos de ellos adivinando o buscando en Google sin encontrar un sistema. Algunos fueron claramente culpa nuestra con las URL que nunca hubieran funcionado. ¿Debo eliminar los arreglados de Wikipedia: Link rot / cases / whitehouse.gov ? PrimeHunter ( charla ) 02:21, 4 de marzo de 2021 (UTC)
- Sí, aproximadamente el 0,5% de las URL de la casa blanca se puede explicar mediante la entrada de datos locales o los errores del sitio remoto, probablemente sea mejor de lo que cabría esperar. Es una buena idea comprobarlo y es genial que hayas podido arreglar algunos. Utilice la página como desee, marque o elimine las entradas. - Green C 03:12, 4 de marzo de 2021 (UTC)
- @ GreenC : Gracias. Ese es un buen número bajo. He arreglado muchos de ellos adivinando o buscando en Google sin encontrar un sistema. Algunos fueron claramente culpa nuestra con las URL que nunca hubieran funcionado. ¿Debo eliminar los arreglados de Wikipedia: Link rot / cases / whitehouse.gov ? PrimeHunter ( charla ) 02:21, 4 de marzo de 2021 (UTC)
- Hubo 30: Wikipedia: Link rot / cases / whitehouse.gov - Green C 22:55, 3 de marzo de 2021 (UTC)
- @ GreenC : ¡Genial! Muchas gracias. ¿Tiene una lista de enlaces rotos que no se pudieron arreglar? Noté uno en [1] : https://www.whitehouse.gov/the-press-office/2013/05/20/president-obama-announces-sally-ride-recipient-presidential-medal-freedom . Redirige pero el objetivo no funciona. Gracias por comprobar la redirección no ayudó. Resultó ser culpa nuestra. El enlace real [2] no tenía una m final que fue agregada por un editor descuidado en [3] , por lo que no hay una solución general que podamos aprender de eso. PrimeHunter ( charla ) 22:30, 3 de marzo de 2021 (UTC)
StarWars.com
Cualquier cosa con http://www.starwars.com debe cambiarse a https . Gracias. JediMasterMacaroni (Discusión) 18:20, 25 de febrero de 2021 (UTC)
- Reenviado a User_talk: Bender235 # StarWars.com - Green C 19:04, 25 de febrero de 2021 (UTC)
- Servirá. - bender235 ( charla ) 19:33, 25 de febrero de 2021 (UTC)
- Gracias. JediMasterMacaroni (Discusión) 19:34, 25 de febrero de 2021 (UTC)
- Servirá. - bender235 ( charla ) 19:33, 25 de febrero de 2021 (UTC)
Reemplazar atimes.com
enlaces
Reemplace todas las instancias de atimes.com
y sus subdominios por asiatimes.com
. El sitio web antiguo se reemplaza por un sitio de publicidad. ~ Ase1este c harge paridad t iempo 10:11, 28 de Febrero 2021 (UTC)
- Además, si la página correspondiente con el nuevo dominio no se encuentra, no se archiva, y hay un archivo con el dominio anterior, no reemplace la URL, agregue el enlace del archivo y marque el estado de la URL como
unfit
. Gracias. ~ Ase1este c harge paridad t iempo 10:26, 28 de Febrero 2021 (UTC)- Está bien. Es posible que se necesiten un par de pasos, primero para mover el dominio cuando sea posible y, en segundo lugar, agregar los archivos + no aptos para el resto. Aún trabajando en whitehouse.gov arriba, podría tardar al menos unos días. - Green C 15:46, 28 de febrero de 2021 (UTC)
- Ok, gracias, puedo esperar. ~ Ase1este c harge paridad t iempo 17:42, 28 de Febrero 2021 (UTC)
- Está bien. Es posible que se necesiten un par de pasos, primero para mover el dominio cuando sea posible y, en segundo lugar, agregar los archivos + no aptos para el resto. Aún trabajando en whitehouse.gov arriba, podría tardar al menos unos días. - Green C 15:46, 28 de febrero de 2021 (UTC)
Resultados :
- 287 URL cambiaron de atimes.com a asiatimes.com
- 1.995 URL convertidas en archivos, incluidos
|url-status=unfit
. Incluye enlaces CS1 | 2, cuadrados y desnudos - 3 URL no tenían archivos (en las relaciones entre Peter Heehs , Thaksin Shinawatra , Irán y Arabia Saudita ). Agregado . Necesita atención manual.
{{dead link}}
- 11 citas convertidas de [enlace cuadrado] a con .
{{webarchive}}
{{cite web}}
|url-status=unfit
- 1 URL en Archivo: espacio
- El estado del dominio se estableció en 'Lista negra' en la base de datos de IABot.
@ Aseleste : Creo que eso es todo, si ves algo más házmelo saber. - Green C 04:23, 6 de marzo de 2021 (UTC)
- ¡Se ve bien, gracias! ~ Ase1este c harge paridad t iempo 04:28 6 de marzo 2021 (UTC)
www.geek.com
Encontré muchos enlaces rotos en este dominio: ¿es posible arreglarlos automáticamente? Jarble ( charla ) 21:30, 11 de marzo de 2021 (UTC)
- Esta es la misma situación que observer.com: en la base de datos de IABot, el dominio está configurado en Lista blanca, por lo que el bot no está verificando / arreglando enlaces muertos. Mi bot puede intentarlo, es mucho más fácil que el observador, ya que los números son pequeños y solo requiere verificar los 404. - Green C 01:51, 12 de marzo de 2021 (UTC)
unc.edu
- Hilo copiado de WP: BOTREQ # Replace_dead_links
¿Podría alguien reemplazar los EL del formulario?
- https://www.unc.edu/~rowlett/lighthouse/bhs.htm (un enlace muerto)
con
{{Cite rowlett|bhs}}
que produce
- Rowlett, Russ. "Faros de las Bahamas" . El directorio del faro . Universidad de Carolina del Norte en Chapel Hill .
Gracias - Martin ( MSGJ · charla ) 05:38, 19 de marzo de 2021 (UTC)
- ¿De qué tipo de escala de ediciones estamos hablando (decenas, cientos, miles)? Primefac ( charla ) 14:37, 19 de marzo de 2021 (UTC)
- Especial: LinkSearch dice 1054 para " https://www.unc.edu/~rowlett/lighthouse " y 483 para la variante "http: //". DMacks ( charla ) 14:43, 19 de marzo de 2021 (UTC)
- Pero la verificación al azar, es una combinación de enlaces simples y enlaces con texto entubado, y con / sin notas bibliográficas simples adicionales. Por ejemplo, 165 del formulario https: // están en un contexto "url = ...". Creo que hay demasiadas variaciones para hacerlas automáticamente. DMacks ( charla ) 15:06, 19 de marzo de 2021 (UTC)
{{cite web}}
- Pero la verificación al azar, es una combinación de enlaces simples y enlaces con texto entubado, y con / sin notas bibliográficas simples adicionales. Por ejemplo, 165 del formulario https: // están en un contexto "url = ...". Creo que hay demasiadas variaciones para hacerlas automáticamente. DMacks ( charla ) 15:06, 19 de marzo de 2021 (UTC)
- Especial: LinkSearch dice 1054 para " https://www.unc.edu/~rowlett/lighthouse " y 483 para la variante "http: //". DMacks ( charla ) 14:43, 19 de marzo de 2021 (UTC)
MSGJ , el único tipo que se puede convertir es el que indica el Usuario: DMacks es demasiado complicado determinar los enlaces cuadrados y desnudos debido al texto de forma libre que podría estar rodeando la URL, a menos que haya algún patrón discernible. Hay 334 artículos que contienen un "url =" anterior. Preguntas de pareja:{{cite web}}
- ¿Sabe si el contenido de
http://www.ibiblio.org/lighthouse/*
es el mismohttps://www.unc.edu/~rowlett/*
que se citó originalmente? es decir. ¿Cuáles son las posibilidades de que se haya producido un cambio de contenido en estas páginas? - ¿Qué haría usted si la cita anterior tiene un
|archiveurl=
.. eliminar el archivo o dejar la cita en paz?
- Green C 19:19, 19 de marzo de 2021 (UTC)
- Gracias por investigar este GreenC . Pregunté en Template talk: Cite Rowlett y los enlaces de trabajo de ibiblio.org corresponden casi exactamente a los antiguos enlaces unc.edu/~rowlett. No estoy seguro de qué hacer con los enlaces de archivos. ¿Conservarlos si están funcionando? El uso de sería preferible, siempre que sea posible, pero si no, entonces los enlaces desnudos pueden ser reemplazados. Gracias - Martin ( MSGJ · charla ) 21:49, 22 de marzo de 2021 (UTC)
{{Cite rowlett}}
nytimes.com enlaces a todo el contenido de la Guía de películas
Los enlaces a https://www.nytimes.com/movies/person/* están muertos y se reportan como un soft-404, por lo que no los recogen los bots de archivo. Hay alrededor de 1300 artículos con enlaces en https y alrededor de 150 en http. Las URL son para The New York Times , pero el contenido tiene licencia para All Movie Guide, por lo tanto, si en una cita CS1 | 2 se convertiría en y . Además, una URL de archivo si está disponible, de lo contrario, marcada como muerta. Crédito adicional: podría intentar determinar la fecha y el autor raspando la página del archivo. Ejemplo . - Green C 18:00, 6 de abril de 2021 (UTC)|work=All Movie Guide
|via=The New York Times
- Lo mismo ocurre con https://www.nytimes.com/movies/movie/*, de los cuales hay alrededor de 3000 en https y alrededor de 170 en http. - Green C 18:10, 6 de abril de 2021 (UTC)
- Encontrado mucho más en movies.nytimes.com - Green C 20:41, 10 de abril de 2021 (UTC)
Resultados
- 11.160 artículos editados
- Agregar 14,871 nuevas URL de archivo
- Cambiar metadatos en 12,855 citas (p. Ej.
|work=
) - Alternar 704 archivos existentes con
|url-status=live
->|url-status=dead
- Agregar 208
{{dead link}}
- Varias otras correcciones generales
- Green C 00:25, 15 de abril de 2021 (UTC)
Articles.timesofindia.indiatimes.com enlaces a timesofindia.indiatimes.com
Hace varios años, todo el contenido de este subdominio se movió a timesofindia.indiatimes.com. Sin embargo, los enlaces no son los mismos y no tienen redirecciones y tampoco se pueden reconstruir o adivinar usando algoritmos. Hay que buscar en Google con el título del enlace con el dominio anterior y actualizar el enlace con el nuevo dominio.
LinkSearch
URL antigua: http://articles.timesofindia.indiatimes.com/2001-06-28/pune/27238747_1_lagaan-gadar-ticket-sales ( archivado )
¿Existe la posibilidad de un bot WP: SEMIAUTOMATED con entradas del usuario sobre la nueva URL y actualización de WP? ¿Existe un bot? De lo contrario, creé un pequeño script semiautomático ( aquí ) para ayudarme con la misma funcionalidad. ¿Necesito obtener una aprobación para este bot, si incluso se considera un bot? - Srihari Thalla ( charla ) 19:20, 8 de abril de 2021 (UTC)
- ¿Tiene problemas con la deriva del contenido (el contenido de la nueva página es diferente del anterior)? Deberá manejar el existente
|archive-url=
,|archive-date=
y|url-status=
dado que no se puede cambiar|url=
y no|archive-url=
, que si se cambia debe verificarse que funcione. Hay que a veces seguir enlaces desnudos y cuadrados puede ser necesario eliminar o cambiar. El debe actualizarse de muertos para vivir. Hay que podrían necesitar ser agregados o eliminados. Debe verificar que la nueva URL está funcionando, no asuma que lo hace; y si hay redireccionamientos en los encabezados, captúrelos y cambie la URL para reflejarlos. Esos son los fundamentos para este tipo de trabajo, no es fácil. Tenga en cuenta que hay 3 tipos básicos de citas: las que están dentro de una plantilla de citas, las que están en un enlace cuadrado y las que están desnudas. De esos tres tipos, el cuadrado y el desnudo pueden tener un final . Todos los tipos pueden tener un final .{{webarchive}}
|url-status=
{{dead link}}
{{webarchive}}
{{dead link}}
- O, mi bot está listo y puede hacer todo esto. Todo lo que se necesitaría es un mapa de URL antiguas y nuevas. ¿Propones buscar manualmente hasta 20.000 URL para cada una? Quizás sea mejor dejarlo sin cambios y agregar URL de archivo. Aquellos que no tienen URL de archivo (es decir,
{{dead link}}
) buscan manualmente para comenzar. Podría generar una lista de esas URL{{dead link}}
mientras me aseguraba de que todo lo demás esté archivado. - Green C 20:24, 8 de abril de 2021 (UTC)- Si ya tiene el bot listo, entonces podemos comenzar con aquellos que no tienen URL de archivo. Si pudiera generar la lista, también podría publicar en WP: INDIA pidiendo voluntarios.
- Sugeriría hacer este trabajo, usando un script semiautomático, es decir, el script leería la página con la lista y analizaría cada fila y la imprimirá en la terminal (todos los detalles del enlace son posibles, cita completa / título del enlace / etc.) para que sea fácil para el usuario buscar y una vez que se encuentra la nueva URL, el script toma la entrada y la guarda en la página. ¿Crees que esto sería más rápido y conveniente?
- También sugeriría formar la lista usando las columnas: número de serie, enlace, cite / bare / square link, título (si es posible), nueva URL, nuevo estado de URL, nueva URL de archivo, nueva fecha de URL de archivo. Los últimos nuevos están en blanco para ser llenados una vez investigados. ¿Se ven bien estas columnas?
- ¿Tiene un enlace a su bot? - DaxServer ( conversación ) 07:45, 9 de abril de 2021 (UTC)
- ¿Qué tal si le proporcionamos la mayor cantidad de datos posible en un formato analizable regular? Preferiría no crear la tabla final, ya que debería hacerlo el autor del script semiautomático en función de sus requisitos y ubicación. ¿Suena eso bien? La página del bot es User: GreenC / WaybackMedic_2.5, sin embargo, tiene 3 años de desactualización, al igual que el repositorio de GitHub, ha habido muchos cambios desde 2018. El bot principal tiene casi 20k líneas, pero cada solicitud de movimiento URLREQ tiene su propia costumbre. módulo que es más pequeño. Puedo publicar un módulo de esqueleto de ejemplo si está interesado, está en Nim (lenguaje de programación) que es similar a la sintaxis de Python. - Green C 18:24, 9 de abril de 2021 (UTC)
- Los datos en un formato analizable son buenos para empezar. En base a esto, se puede establecer un flujo de trabajo adecuado a lo largo del tiempo. La mesa final se puede hacer más tarde, como dijiste.
- Lamentablemente, nunca oí hablar de Nim. Sé un poco de Python y podría haber mirado a Nim, pero no tengo tiempo hasta mediados de mayo. ¿Sería este un ejemplo de un módulo, citeaddl ? Pero esto es Medic 2.1 y no 2.5. Quizás podrías compartir el ejemplo. Si parece que puedo lidiar con eso sin mucha curva de aprendizaje, podría entrenar algo. Si no es así, ¡tendría que esperar hasta finales de mayo y luego evaluar nuevamente! - DaxServer ( conversación ) 20:24, 9 de abril de 2021 (UTC)
- ¿Qué tal si le proporcionamos la mayor cantidad de datos posible en un formato analizable regular? Preferiría no crear la tabla final, ya que debería hacerlo el autor del script semiautomático en función de sus requisitos y ubicación. ¿Suena eso bien? La página del bot es User: GreenC / WaybackMedic_2.5, sin embargo, tiene 3 años de desactualización, al igual que el repositorio de GitHub, ha habido muchos cambios desde 2018. El bot principal tiene casi 20k líneas, pero cada solicitud de movimiento URLREQ tiene su propia costumbre. módulo que es más pequeño. Puedo publicar un módulo de esqueleto de ejemplo si está interesado, está en Nim (lenguaje de programación) que es similar a la sintaxis de Python. - Green C 18:24, 9 de abril de 2021 (UTC)
Usuario: GreenC / software / urlchanger-skeleton-easy.nim es un archivo fuente de esqueleto genérico. Para dar una idea de lo que está involucrado. Solo necesita modificar alguna variable en la parte superior que define los dominios antiguos y nuevos. Hay un esqueleto "duro" para necesidades más personalizadas donde se realizan modificaciones en todo el archivo cuando la versión fácil no es suficiente. El archivo es parte del bot principal y aísla los cambios específicos del dominio en este archivo. Comenzaré con lo anterior, tomará unos días probablemente dependiendo de cuántas URL se encuentren. - Green C 01:42, 11 de abril de 2021 (UTC)
@ DaxServer : El bot terminó. Las citas con están registradas en Wikipedia: Link rot / cases / Times of India (sin procesar) alrededor de 150. - Green C 20:57, 16 de abril de 2021 (UTC){{dead link}}
- ¡Qué bueno escuchar! Gracias @ GreenC - DaxServer ( charla ) 11:16, 17 de abril de 2021 (UTC)
Resultados
- Ediciones de 9,509 artículos
- Se agregaron nuevas URL de archivo 15,269
- Cambió 1,167
|url-status=live
a|url-status=dead
{{dead link}}
añadido alrededor de 100- 11,941 citas metadatos modificados (p. Ej.
|work=
, Normalizados , eliminado "Times of India" de|title=
)
odiseos.net ahora es un sitio web de juegos de apuestas
Hubo dos referencias a este sitio web. He eliminado uno. La URL archivada tiene el contenido. ¿Debe conservarse o eliminarse esta cita?
Mi edición y cita existente - DaxServer ( charla ) 07:50, 9 de abril de 2021 (UTC)
- Este es un dominio usurpado. Normalmente se cambiarían a
|url-status=usurped
. La instancia de la página de discusión se elimina porque la sección "Enlaces externos modificados" se puede eliminar porque es un sistema antiguo que ya no se usa. Necesitaré actualizar la base de datos de InternetArchiveBot para indicar que este dominio debería estar en la lista negra, pero el servicio está actualmente fuera de servicio por mantenimiento. https://iabot.toolforge.org/ - Green C 17:10, 9 de abril de 2021 (UTC)- También he revertido mi edición para incluir la
|url-status=usurped
( nueva edición ). - DaxServer ( conversación ) 20:33, 9 de abril de 2021 (UTC)
- También he revertido mi edición para incluir la
Migrar URL antiguas de "thehindu.com"
Las URL antiguas de algún momento antes de 2010 tienen una estructura de URL diferente. El contenido se mueve a una nueva URL, pero no está disponible un redireccionamiento directo. La URL anterior se redirige a la página de la lista que está categorizada por la fecha de publicación del artículo. Hay que buscar el título del artículo y seguir el enlace. Sorprendentemente, algunas URL archivadas que probé fueron redirigidas a la nueva URL archivada. Supongo que la redirección funcionó en el pasado, pero se interrumpió en algún momento.
URL anterior: http://hindu.com/2001/09/06/stories/0406201n.htm ( archivado en 2020 ; redirigido automáticamente a la nueva URL archivada; archivo antiguo de 2013 )
Redirigido a la página de la lista: https://www.thehindu.com/archive/print/2001/09/06/
Título: gigante de TI derrotado por Naidu
Nueva URL de la página de la lista: https://www.thehindu.com/todays-paper/tp-mis Miscellaneous / tp - others / it - giant - bowled - over - by - naidu / article27975551.ece
No hay cambio de contenido de la antigua URL (archivo de 2013) y la nueva URL.
Ejemplo de N. Chandrababu Naidu - PS. Esta cita se utiliza dos veces (según se busca por el título), una con la URL antigua y la otra con la nueva. - DaxServer ( conversación ) 14:18, 9 de abril de 2021 (UTC)
- La nueva URL [4] está detrás de un muro de pago y es ilegible, mientras que el archivo de la antigua URL [5] es completamente legible. Creo que sería preferible mantener archivos de las URL antiguas, ya que no tienen un muro de pago y no habría problemas de deriva de contenido. Quizás similar al intento anterior de migrar cuando un soft-404 que redirige a una página de lista cuando no hay ningún archivo disponible. - Green C 17:37, 9 de abril de 2021 (UTC)
- En ese caso, ¿quizás WaybackMedic o el bot de IA puedan agregar URL archivadas a todos estos enlaces? Si desea ser más específico, aquí está la expresión regular de las URL que he encontrado hasta ahora. Puede haber otros con los que todavía no me he encontrado.
https?\:\/\/(www\.)?(the)?hindu\.com\/(thehindu\/(fr|yw|mp|pp|mag)\/)?\d{4}\/[01]\d\/[0-3][0-9]\/stories\/[0-9a-z]+\.htm
- - DaxServer ( conversación ) 20:39, 9 de abril de 2021 (UTC)
- ¿Puede verificar la expresión regular porque no creo que coincida con la "URL anterior" anterior en el segmento
\d{4}\/[01]\d\/[0-3][0-9]\/
... tal vez sea una variación de URL diferente? - Green C 21:52, 9 de abril de 2021 (UTC)- Concuerda. Lo verifiqué en regex101 y también en Python cli. Quizás, aquí hay una expresión regular más simple.
https?\:\/\/(www\.)?(the)?hindu\.com\/(thehindu\/(fr|yw|mp|pp|mag)\/)?\d{4}\/\d{2}\/\d{2}\/stories\/[0-9a-z]+\.htm
- DaxServer ( conversación ) 12:02, 10 de abril de 2021 (UTC)- Ahh lo siento mal leído gracias. - Green C 13:33, 10 de abril de 2021 (UTC)
- Regex modificado para trabajar con Elasticsearch
insource:
y algunas coincidencias adicionales. 12,229insource:/\/{2}(www[.])?(the)?hindu[.]com\/(thehindu\/)?((cp|edu|fr|lf|lr|mag|mp|ms|op|pp|seta|yw)\/)?[0-9]{4}\/[0-9]{2}\/[0-9]{2}\/stories\/[^.]+[.]html?/
- - Green C 04:27, 17 de abril de 2021 (UTC)
- Regex modificado para trabajar con Elasticsearch
- Ahh lo siento mal leído gracias. - Green C 13:33, 10 de abril de 2021 (UTC)
- ¿Puede verificar la expresión regular porque no creo que coincida con la "URL anterior" anterior en el segmento
DaxServer , el hindú está hecho. Lista de enlaces muertos: Wikipedia: Link rot / cases / The Hindu (crudo) . - Green C 13:24, 23 de abril de 2021 (UTC)
- ¡ ¡ Buen trabajo en GreenC !! - DaxServer ( conversación ) 16:58, 23 de abril de 2021 (UTC)
- Ediciones de 11,985 artículos
- Se agregaron nuevas URL de archivo 15.954
- Toggled 2412
|url-status=live
a muertos - Añadido 1.244
{{dead link}}
- 12.234 citas metadatos modificados (por ejemplo
|work=
, normalizados , eliminado "El hindú" de|title=
, etc.) - Se actualizó la base de datos de IABot, cada enlace establecido individualmente en la lista negra.
sify.com
Cualquier enlace que redirija a la página de inicio. Ejemplo . Ejemplo .-- verde C 14:27, 17 de Abril 2021 (UTC)
Resultados
- Agregar 4,132 nuevos enlaces a archivos ( ejemplo )
- Agregar o modificar 1,149
|url-status=dead
( ejemplo ) - Establecer enlaces "incluidos en la lista negra" en la base de datos de IABot
ancient.eu
Enciclopedia de Historia Antigua ha cambiado de nombre a Enciclopedia de Historia Mundial y ha trasladado el dominio a worldhistory.org . Hay muchas referencias al sitio en Wikipedia. Todas las referencias que apunten a ancient.eu deberían apuntar a worldhistory.org . De lo contrario, la estructura de la URL es la misma (es decir, https://www.ancient.eu/Rome/ ahora es https://www.worldhistory.org/Rome/ ). - Comentario anterior sin firmar agregado por Thamis ( charla • contribuciones )
- Hola @ Thamis :, gracias por el cliente potencial / información, sin duda es posible hacerlo. ¿Crees que hay una razón para considerar Content Drift, es decir. la página en el nuevo sitio es diferente de la original (en esencia), o en gran parte una copia 1: 1 del contenido principal? Al comparar esta página con esta página , parece que se trata de un cambio administrativo y no de contenido. - Green C 23:40, 20 de abril de 2021 (UTC)
- Gracias por mirar en esto, @ GreenC : . No hay deriva de contenido, es una copia 1: 1 del contenido con exactamente las mismas URL (solo el dominio es diferente). Cuando comparo las dos páginas de Roma del archivo y el nuevo dominio que vinculó, veo exactamente la misma página. Lo mismo ocurre con cualquier otra página que desee consultar. :-)
@ Thamis : , esta url funciona, pero esta URL no lo hace. El subdominio etc.ancient.eu no se transfirió, pero aún funciona en el sitio anterior. Para estos, se omitirá ya que el enlace aún funciona y no quiero agregar una URL de archivo a los enlaces activos si se transferirá en el futuro a worldhistory.org. Se puede volver a visitar más tarde. - Green C 16:03, 23 de abril de 2021 (UTC)
- @ GreenC : De hecho, ese subdominio etc.ancient.eu no se transfirió. Es el dominio www.ancient.eu que se convirtió en www.worldhistory.org; los subdominios que no sean "www" deben ignorarse.
@ Thamis : ya está. Además de las URL, también cambió / agregó |work=
, etc., a World History Encyclopedia . Obtuvo alrededor del 90%, pero la cadena "Enciclopedia de Historia Antigua" todavía existe en 89 páginas / citas , requerirán trabajo manual para convertir (las URL se convierten solo la cadena no). En su mayoría son citas de forma libre con un formato inusual y se beneficiarían de la limpieza manual, probablemente idealmente, la conversión a . - Green C 01:07, 24 de abril de 2021 (UTC){{cite encyclopedia}}
Resultados
- 759 artículos editados
- URL 917 convertidas ( ejemplo )
@ GreenC : ¡ Muchas gracias por solucionar este problema! Apreciado enormemente. :-) - Comentario anterior sin firmar agregado por Thamis ( charla • contribuciones )
- De nada. Si está buscando más ideas sobre cómo mejorar ... convertir todo en una plantilla de citas hará que el mantenimiento futuro sea más fácil y menos propenso a errores. Sin embargo, no recomendaría crear una plantilla personalizada, ya que son propensas a romperse, ya que requieren un código personalizado especial para que las herramientas funcionen en comparación con las plantillas de citas estándar que son mejor compatibles con las herramientas. - Green C 18:01, 6 de mayo de 2021 (UTC)
* .in.com
Todo muerto. Algunos redireccionan a una nueva página de inicio de dominio que no está relacionada con el sitio anterior. Algunos tienen subdominios profundos de 2 niveles. Ahora todo está configurado en "Lista negra" en IABot para el uso global de wiki, un pase de Medic en enwiki también ayudará. - Green C 04:13, 25 de abril de 2021 (UTC)
Resultados
- 3.803 artículos editados
- Se agregaron 3863 nuevas URL de archivo
- Se modificó / agregó 732
|url-status=dead
a las URL de archivo existentes - Añadido 104
{{dead link}}
- Establecer enlaces individuales en "lista negra" en la base de datos de IABot
Eliminar oxfordjournals.org
Hola, creo que todos los enlaces a los subdominios oxfordjournals.org en el parámetro url de {{ cite journal }} deberían eliminarse, siempre que haya al menos un conjunto de parámetros doi, pmid, pmc o hdl. Todos esos enlaces están rotos, porque redirigen a una versión HTTPS que usa un certificado válido solo para silverchair.com (ejemplo: http://jah.oxfordjournals.org/content/99/1/24.full.pdf ).
El DOI redirige a la URL de destino real, que hoy en día está en algún lugar de academic.oup.com, por lo que no tiene sentido mantener o agregar URL archivadas o parámetros de estado de URL. Estas URL se han roto durante años, por lo que es probable que nunca se solucionen. Nemo 07:13, 25 de abril de 2021 (UTC)
- Aproximadamente 15.000 . Me han amonestado por eliminar las URL de archivo debido a la deriva del contenido, es decir. la página en el momento de la cita contiene un contenido diferente al actual (academic.oup.com), por lo tanto, la URL del archivo es útil para mostrar la página en el momento de la cita con fines de verificación. OTOH, si hay razones para creer que la deriva del contenido no es una preocupación para un dominio en particular, esa no es mi llamada para hacer que alguien más deba hacer esa investigación y determinar si esto debería ser motivo de preocupación. @ Nemo bis : - Green C 16:03, 25 de abril de 2021 (UTC)
- La "versión del registro" es la misma, por lo que el PDF del nuevo sitio web debe ser idéntico al anterior. La copia de PubMed Central generalmente también la proporciona el editor. Por lo tanto, el DOI y el ID de PMC, si están presentes, eliminan cualquier riesgo de desviación del contenido. Por otro lado, estoy bastante seguro de que quien agregó esas URL no quiso citar una página de error de TLS. :) Nemo 18:21, 25 de abril de 2021 (UTC)
- Puedo hacer esto, solo necesitaré algo de tiempo gracias. - Verde C
- La "versión del registro" es la misma, por lo que el PDF del nuevo sitio web debe ser idéntico al anterior. La copia de PubMed Central generalmente también la proporciona el editor. Por lo tanto, el DOI y el ID de PMC, si están presentes, eliminan cualquier riesgo de desviación del contenido. Por otro lado, estoy bastante seguro de que quien agregó esas URL no quiso citar una página de error de TLS. :) Nemo 18:21, 25 de abril de 2021 (UTC)
@ Nemo bis : 20 artículos editados: 1 2 3 4 5 - Olvidé eliminar |access-date=
en algunos casos. ¿Ves algún otro problema? - Green C 00:50, 6 de mayo de 2021 (UTC)
- Se ve bien a primera vista. No recuerdo si Citoid o el bot de Citation pueden extraer el DOI del HTML en etapas posteriores una vez que pueden obtener el HTML de la máquina de retorno, pero de cualquier manera es bueno tenerlo. Nemo 06:01, 6 de mayo de 2021 (UTC)
@ GreenC y Nemo bis : ¿ Acabo de ver una edición sobre esto, pero los enlaces parecen funcionar bien ahora? Gracias. Mike Peel ( charla ) 18:39, 7 de mayo de 2021 (UTC)
- ¿Qué enlace de ejemplo te funciona? - Green C 18:47, 7 de mayo de 2021 (UTC)
- @ GreenC : Probé el enlace de ejemplo anterior y el que revirtí en [6] (¿supongo que recibió una notificación sobre eso?). Ambos redirigen bien. Gracias. Mike Peel ( charla ) 18:54, 7 de mayo de 2021 (UTC)
- No se que esta pasando. El mensaje que Nemo y yo recibimos fue:
- Firefox no confía en este sitio porque utiliza un certificado que no es válido para jah.oxfordjournals.org. El certificado solo es válido para los siguientes nombres: * .silverchair.com, silverchair.com, gsw.contentapi.silverchair.com, dup.contentapi.silverchair.com - Código de error: SSL_ERROR_BAD_CERT_DOMAIN
- Esto es Windows 7 Firefox 88.01: cuando se prueba con Chrome, funciona yendo a un captcha del tipo "haga clic en todos los cuadrados con un bus" 4 o 5 veces, luego pasa al contenido. Nemo, ¿también usas Firefox en Windows? - Green C 20:25, 7 de mayo de 2021 (UTC)
- @ GreenC : Estoy usando Firefox en una Mac. Por favor, ¿podría detener las ediciones hasta que podamos averiguar qué está pasando? Gracias. Mike Peel ( charla ) 20:27, 7 de mayo de 2021 (UTC)
- Hecho. - Green C 20:28, 7 de mayo de 2021 (UTC)
- Mike, la http://jah.oxfordjournals.org/content/99/1/24.full.pdf URL no redirecciona a https://jah.oxfordjournals.org/content/99/1/24.full. pdf y le da un error TLS? Nemo 20:32, 7 de mayo de 2021 (UTC)
- Recibo un PDF. Sin embargo, el enlace de descarga comienza con watermark.silverchair.com. Gracias. Mike Peel ( charla ) 20:35, 7 de mayo de 2021 (UTC)
- ¿Lo has probado con otro navegador? ¿Está seguro de que no ha permitido que ese dominio eluda la seguridad de TLS? Nemo 20:40, 7 de mayo de 2021 (UTC)
- Vea mi comentario al final de esta sección. Podría haber agregado una excepción, ya que uso mucho los artículos de revistas, pero creo que eso solo debería afectar a un navegador. ¿Has intentado hacer eso? Gracias. Mike Peel ( charla ) 20:42, 7 de mayo de 2021 (UTC)
- ¿Lo has probado con otro navegador? ¿Está seguro de que no ha permitido que ese dominio eluda la seguridad de TLS? Nemo 20:40, 7 de mayo de 2021 (UTC)
- Recibo un PDF. Sin embargo, el enlace de descarga comienza con watermark.silverchair.com. Gracias. Mike Peel ( charla ) 20:35, 7 de mayo de 2021 (UTC)
- Mike, la http://jah.oxfordjournals.org/content/99/1/24.full.pdf URL no redirecciona a https://jah.oxfordjournals.org/content/99/1/24.full. pdf y le da un error TLS? Nemo 20:32, 7 de mayo de 2021 (UTC)
- Hecho. - Green C 20:28, 7 de mayo de 2021 (UTC)
- @ GreenC : Estoy usando Firefox en una Mac. Por favor, ¿podría detener las ediciones hasta que podamos averiguar qué está pasando? Gracias. Mike Peel ( charla ) 20:27, 7 de mayo de 2021 (UTC)
- (Editar conflicto) Supongo que es un caso raro de un dominio que no estaba roto, pero todos los subdominios habituales de las revistas están rotos. Esa edición estuvo bien de todos modos porque el nuevo enlace (a doi.org) va al mismo lugar y es más estable. No sabemos cuánto tiempo existirán los dominios OUP heredados. Nemo 20:30, 7 de mayo de 2021 (UTC)
- No se que esta pasando. El mensaje que Nemo y yo recibimos fue:
- @ GreenC : Probé el enlace de ejemplo anterior y el que revirtí en [6] (¿supongo que recibió una notificación sobre eso?). Ambos redirigen bien. Gracias. Mike Peel ( charla ) 18:54, 7 de mayo de 2021 (UTC)
@ Nemo bis : La primera pasada está hecha, algunos problemas. Hay casos de no que contienen DOI, etc. Ejemplo . El bot fue programado solo para diario + alias. Y me perdí . [7] Hay casos en los que no está configurado para detectar [8] . Se agregaron 1.750 URL de archivo, por lo que estos problemas estarían en ese grupo, aunque la mayoría de ellos están bien. - Green C 18:45, 7 de mayo de 2021 (UTC){{cite journal}}
{{vcite journal}}
{{doi}}
- ¡Buena cooperación de bots ! Cuando se elimina la URL, doi-access = free puede hacer su trabajo correctamente. Los enlaces directos a archivos PDF en wayback son agradables, enlaces a archive.today que solo me sirven un captcha que no conozco. Veo que todavía tenemos 4000 artículos con oxfordjournals.org, probablemente podamos reducir eso.
- Los casos de {{ doi }} sobre los que no podemos hacer mucho, necesitan esperar a que el bot de citas u otros los transformen en citas estructuradas. Lo mismo ocurre con las plantillas no estándar: a veces las personas que las usan son muy obstinadas.
- Creo que la victoria más fácil ahora es reemplazar algunas de las citas más utilizadas, que a menudo son el resultado de la creación masiva de artículos sobre especies hace una década. Por ejemplo, un reemplazo similar a este ayudaría a unos 300 artículos:
[http://mollus.oxfordjournals.org/content/77/3/273.full Bouchet P., Kantor Yu.I., Sysoev A. & Puillandre N. (2011) Una nueva clasificación operativa de Conoidea. Journal of Molluscan Studies 77: 273-308.]→{{cite journal | first1 = P. | last1 = Bouchet | first2 = YI | last2 = Kantor | first3 = A. | last3 = Sysoev | first4 = N. | last4 = Puillandre | title = Una nueva clasificación operativa de la Conoidea ( Gastropoda) | journal = Journal of Molluscan Studies | fecha = 1 de agosto de 2011 | páginas = 273–308 | volumen = 77 | número = 3 | doi = 10.1093 / mollus / eyr017 | url = https: //archimer.ifremer.fr/ doc / 00144/25544 / 23686.pdf}}
- (Probablemente pueda hacer coincidir cualquier texto entre dos etiquetas de referencia o entre una viñeta y una nueva línea que coincida con / content / 77/3/273 .) Acabo de convertir el DOI a una sintaxis {{ cite journal }} con VisualEditor / Citoid y agregué lo que habría hecho OAbot . Hay algunos casos como este, probablemente pueda encontrarlos en la base de datos de IAbot o en una consulta de los enlaces restantes . Estos son los ID más comunes entre ellos:
$ curl -s https://quarry.wmflabs.org/run/550945/output/1/tsv | grep -Eo "(/ [0-9] +) {3}" | ordenar | uniq -c | sort -nr | cabeza69/21/7/136160/22/10/196451/77/3/27329/24/6/130028/19/7/100825/24/20/233921/55/6/91217/22/2/18916/19/1/215/11/3/257
- Nemo 20:30, 7 de mayo de 2021 (UTC)
- Probando [9] en Safari, Chrome y Firefox en una Mac, no hay problemas, redirecciona bien ... Gracias. Mike Peel ( charla ) 20:32, 7 de mayo de 2021 (UTC)
- Definitivamente podemos replicar el problema en dos computadoras (la mía y la Nemo), por lo que es muy probable que les esté sucediendo a otras. También hay, ¿cuál es mejor, con la URL o sin ella? Con la URL (suponiendo que la atraviese), solicita un captcha que es algo difícil de superar, y es un enlace a un sitio que es específico del proveedor. Sin la URL, va a doi.org (confiable a largo plazo) y abre el PDF sin captcha ni problemas potenciales de SSL. Comparando antes y después de la eliminación, la cita se ha mejorado en mi opinión. - Green C 20:47, 7 de mayo de 2021 (UTC)
- ¿Tiene HTTPS en todas partes? Veo el http://mollus.oxfordjournals.org/content/77/3/273.full redirecciona directamente https://academic.oup.com/mollus/article/77/3/273/1211552 sin, pero si el La redirección es a https://mollus.oxfordjournals.org/content/77/3/273.full, entonces nada funciona porque esta URL se sirve incorrectamente.
- De todos modos, este fue solo uno de los muchos problemas con esas antiguas URL de oxfordjournals.org: también hay URL de pmid que no van a ninguna parte, URL que redirigen a la página principal de la revista respectiva, etc. Cuando tenemos un DOI no hay razón para mantenerlos, están haciendo tictac incluso si funcionan por ahora. Nemo 20:53, 7 de mayo de 2021 (UTC)
- Tengo HTTPS en todas partes, apagarlo pasó (a un captcha). Eso no debería suceder. Sería una mejora reemplazar con las URL DOI cuando estén disponibles. - Green C 21:14, 7 de mayo de 2021 (UTC)
- Ok, he enviado un parche para el conjunto de reglas . Sin embargo, recomiendo continuar con la limpieza porque nunca podremos cuidar el destino de 390 dominios heredados. Estoy enumerando en Usuario: Nemo bis / Sandbox algunas sugerencias para reemplazos más específicos. (Algunas URL deben buscarse en todas sus variantes, especialmente la primera "77/3/273"). Nemo 21:38, 7 de mayo de 2021 (UTC)
- ( editar conflicto ) GreenC , ¿podría evitar que su bot haga esto? Estás eliminando enlaces que funcionan sin ningún motivo. Aquí eliminó http://jhered.oxfordjournals.org/content/30/12/549.extract , pero ese enlace funciona bien y redirige sin esfuerzo a https://academic.oup.com/jhered/article-abstract/ 30/12/549/911170 . Si no está roto, (¡de verdad!) No hay necesidad de repararlo (y menos aún de romperlo). Si desea reemplazar el enlace anterior por el nuevo, me parece bien (ya he hecho algunos), pero deje de eliminar los enlaces que funcionan. Gracias, Justlettersandnumbers ( charla ) 21:44, 7 de mayo de 2021 (UTC)
- Bueno, esa URL está rota para algunos millones de usuarios en este momento, por lo que hay una razón para eliminarla. Una alternativa es reemplazarlo con una URL de doi.org si todavía no hay un parámetro doi-access = free o PMC. Nemo 21:57, 7 de mayo de 2021 (UTC)
- ( editar conflicto ) GreenC , ¿podría evitar que su bot haga esto? Estás eliminando enlaces que funcionan sin ningún motivo. Aquí eliminó http://jhered.oxfordjournals.org/content/30/12/549.extract , pero ese enlace funciona bien y redirige sin esfuerzo a https://academic.oup.com/jhered/article-abstract/ 30/12/549/911170 . Si no está roto, (¡de verdad!) No hay necesidad de repararlo (y menos aún de romperlo). Si desea reemplazar el enlace anterior por el nuevo, me parece bien (ya he hecho algunos), pero deje de eliminar los enlaces que funcionan. Gracias, Justlettersandnumbers ( charla ) 21:44, 7 de mayo de 2021 (UTC)
- Ok, he enviado un parche para el conjunto de reglas . Sin embargo, recomiendo continuar con la limpieza porque nunca podremos cuidar el destino de 390 dominios heredados. Estoy enumerando en Usuario: Nemo bis / Sandbox algunas sugerencias para reemplazos más específicos. (Algunas URL deben buscarse en todas sus variantes, especialmente la primera "77/3/273"). Nemo 21:38, 7 de mayo de 2021 (UTC)
- Tengo HTTPS en todas partes, apagarlo pasó (a un captcha). Eso no debería suceder. Sería una mejora reemplazar con las URL DOI cuando estén disponibles. - Green C 21:14, 7 de mayo de 2021 (UTC)
- Definitivamente podemos replicar el problema en dos computadoras (la mía y la Nemo), por lo que es muy probable que les esté sucediendo a otras. También hay, ¿cuál es mejor, con la URL o sin ella? Con la URL (suponiendo que la atraviese), solicita un captcha que es algo difícil de superar, y es un enlace a un sitio que es específico del proveedor. Sin la URL, va a doi.org (confiable a largo plazo) y abre el PDF sin captcha ni problemas potenciales de SSL. Comparando antes y después de la eliminación, la cita se ha mejorado en mi opinión. - Green C 20:47, 7 de mayo de 2021 (UTC)
- Probando [9] en Safari, Chrome y Firefox en una Mac, no hay problemas, redirecciona bien ... Gracias. Mike Peel ( charla ) 20:32, 7 de mayo de 2021 (UTC)
¿Ha intentado ponerse en contacto con la revista sobre estos temas? Dado que los enlaces * sí * funcionan (posiblemente a menos que apliques restricciones adicionales), no creo que estas eliminaciones deban ocurrir sin preguntar primero a la comunidad en general. Gracias. Mike Peel ( charla ) 08:28, 8 de mayo de 2021 (UTC)
- OUP es notoriamente impermeable a las peticiones de que corrijan URL o incluso DOI. No tiene sentido intentarlo. Nemo 09:55, 8 de mayo de 2021 (UTC)
Corregir enlaces pdfs.semanticscholar.org
Los pdfs.semanticscholar.org que HTTP 301 redirigen a las URL de www.semanticscholar.org son en realidad enlaces inactivos. Hay bastantes ahora. Es posible un enlace a la máquina de retorno, pero creo que InternetArchiveBot normalmente no lo agregaría. Nemo 21:15, 28 de abril de 2021 (UTC)
- Son 404 suaves en el sentido de que la página de destino es 200 y ofrece contenido relacionado, pero no lo que se espera de la URL original (es decir, un PDF). Podemos restaurar el PDF a través de WaybackMachine y otros proveedores de archivos como URL de archivo. Siendo enlaces 404ish, deben ser guardados como estaba previsto originalmente para WP: V propósitos. Si la cita ya tiene un enlace de archivo, se omitirá. Si no se puede encontrar un enlace de archivo, dejará la URL en su lugar y dejará que el bot de Citation la maneje; puede generar una lista de estos, probablemente no habrá muchos. - Green C 21:29, 28 de abril de 2021 (UTC)
- ¡Tiene sentido, gracias! Nemo 06:42, 29 de abril de 2021 (UTC)
- Nemo, las pruebas van bien y están listas para la carrera completa. Se han encontrado varios tipos de estuches de borde que requieren un manejo especial, por lo que es bueno que esto sea personalizado. Pregunta: ¿sabe si con esta diferencia el bot de Citation mantendría la URL del archivo o la eliminaría? - Green C 16:51, 29 de abril de 2021 (UTC)
- Esas diferencias se ven bien. Hasta donde yo sé, en este momento el bot de Citation no está eliminando esas URL; Probé en algunos artículos después de las ediciones de su bot y se quedaron solos. Nemo 04:38, 30 de abril de 2021 (UTC)
- Nemo, las pruebas van bien y están listas para la carrera completa. Se han encontrado varios tipos de estuches de borde que requieren un manejo especial, por lo que es bueno que esto sea personalizado. Pregunta: ¿sabe si con esta diferencia el bot de Citation mantendría la URL del archivo o la eliminaría? - Green C 16:51, 29 de abril de 2021 (UTC)
- ¡Tiene sentido, gracias! Nemo 06:42, 29 de abril de 2021 (UTC)
Nemo , parece hecho, avísame si ves algún problema. - Green C 16:43, 30 de abril de 2021 (UTC)
- ¡Gracias! Wikipedia: Link rot / cases / pdfs.semanticscholar.org es muy útil. Noté que OAbot puede encontrar más URL para agregar cuando un DOI está disponible y el parámetro de URL está borrado. Así que creo que haré otra pasada con OAbot diciéndole que ignore las URL de SemanticScholar, y luego eliminaré manualmente las redundantes. Nemo 20:48, 1 de mayo de 2021 (UTC)
- De hecho, lo rastrearé en phabricator: T281631 para una mejor visibilidad. Nemo 21:51, 1 de mayo de 2021 (UTC)
Resultados
- 2.754 artículos editados
- Se agregaron 3.204 nuevas URL de archivo para pdfs.semanticscholar.org
- Agregar / cambiar 74
|url-status=dead
en URL de archivo preexistentes - 485 URL no se han encontrado archivos: Wikipedia: Link rot / cases / pdfs.semanticscholar.org
- Base de datos IABot actualizada. Incluido en la lista negra arriba de las URL archivadas, mientras que conserva la lista blanca para las URL restantes en el dominio.
Actualización de citas de TracesOfWar
Wikipedia contiene actualmente citas y referencias de fuentes a los sitios web TracesOfWar.com y .nl (EN-NL bilingüe), pero también a los sitios web anteriores ww2awards.com, go2war2.nl y oorlogsmusea.nl. Sin embargo, estos sitios web se han integrado en TracesOfWar en los últimos años, por lo que la referencia de la fuente ahora es incorrecta en cientos de páginas y un múltiplo de eso en términos de las referencias de la fuente. Afortunadamente, actualmente existe una situación en la que ww2awards y go2war2 todavía redirigen a la página correcta en TracesOfWar, pero este ya no es el caso de oorlogsmusea.nl. He podido corregir todas las fuentes de oorlogsmusea.nl manualmente. Para ww2awards y go2war2, las redirecciones se detendrán a corto plazo, lo que dará como resultado miles de enlaces muertos, mientras que se puede dirigir correctamente hacia la misma fuente. Un breve ejemplo: la persona Llewellyn Chilson (en Tracesofwar persons id 35010) ahora tiene una referencia de fuente a http://en.ww2awards.com/person/35010 , pero debe ser https://www.tracesofwar.com/persons/ 35010 / . En resumen, formato antiguo a formato nuevo en términos de URL, pero el mismo ID.
En mi opinión, eso debería permitir convertir todo con el formato ' http://en.ww2awards.com/person/ [id]' (inglés antiguo) o ' http://nl.ww2awards.com/person/ [ id] '(holandés antiguo) a' https://www.tracesofwar.com/persons/ [id] '(nuevo inglés) o' https://www.tracesofwar.nl/persons/ [id] '(nuevo holandés ) respectivamente. Lo mismo se aplica a go2war2.nl, pero con un formato ligeramente diferente. http://www.go2war2.nl/artikel/ [id] se convierte en https://www.tracesofwar.nl/articles/ [id]. Lo mismo ya se ha hecho en la Wikipedia holandesa, a través de una solicitud de bot similar. Lennard87 ( charla ) 18:50, 29 de abril de 2021 (UTC)
@ Lennard87 :, viendo alrededor de 500 URL de espacio principal en enwiki para todos los dominios combinados. ¿Puedes verificar que no falte ninguno? - Green C 22:18, 1 de mayo de 2021 (UTC)
- go2war2.nl <50
- ww2awards.com <300
- tracesofwar.com <150
- tracesofwar.nl <30
- @ GreenC :, eso es muy posible, sí, pero no tengo números exactos. En cualquier caso, esos aproximadamente 350 (go2war2 + ww2awards) deben cambiarse luego a tracesofwar.com o .nl.
@ Lennard87 : resultados de www2awards movieron 251 URL. Cinco ejemplos muestran diferentes tipos de problemas: [10] [11] [12] [13] [14] .. las variaciones de los "Premios de la Segunda Guerra Mundial" y la ubicación en la cita son difíciles. (Por cierto, en lugar de / persona / algunos tienen / premio / que en el nuevo sitio es / premios / Ejemplo ) - Green C 18:43, 2 de mayo de 2021 (UTC)
Los resultados de go2war son similares: movió 48 URL: [15] [16] - Green C 19:26, 2 de mayo de 2021 (UTC)
- @ GreenC : Gracias. Vi las situaciones, que son difíciles, pero los cambios propuestos son correctos. También sí, me olvidé del / premio / cambio; que también se puede aplicar por favor. Solo el último con Gunther Josten es difícil, ya que la identificación de la imagen también ha cambiado: https://www.mystiwot.nl/myst/upload/persons/9546061207115933p.jpg . No hay relación entre los dos, así que es mejor dejar en paz a 'imágenes-persona' o utilizar el truco del archivo web.
Reuters
El nuevo sitio web de Reuters redirigió todos los subdominios a www.reuters.com y rompió todos los enlaces. Eso es alrededor de 50 mil artículos solo en la Wikipedia en inglés, creo. Veo que el dominio está incluido en la lista blanca en InternetArchiveBot, no estoy seguro de si eso es lo que se pretendía. Nemo 20:13, 1 de mayo de 2021 (UTC)
Vaya, eso es importante. Los dominios se pueden incluir automáticamente en la lista blanca si el bot recibe mensajes confusos por medio de reversiones del usuario (del bot). Parece que algunos subdominios todavía funcionan [17] . O devuelva correctamente el 404 y IABot lo recogerá, a excepción de la lista blanca [18] . O 404'ing suave [19] . Cómo determinar un soft404 es un arte, en este caso es bastante fácil que redireccione a una página con un título "Página de inicio", pero probablemente haya otras ubicaciones de aterrizaje desconocidas. WaybackMedic debería poder hacer esto, tiene un buen código para seguir redireccionamientos, verificar encabezados y verificar soft404s (conocidos). No podrá comenzar durante al menos una semana para ponerse al día con otras cosas. Luego tomará un tiempo debido al tamaño. - Green C 21:59, 1 de mayo de 2021 (UTC)
- Gracias. Cuento 249299 enlaces a reuters.com en ~ todos los wikis en este momento ( phabricator: P15671 ). Nemo 08:06, 2 de mayo de 2021 (UTC)
- Es interesante lo dispersos que están, excepto enwiki. Probablemente haya una regla similar a 80/40 pero más como 40/60 o 33/66 (enwiki / todo lo demás) - Green C 15:13, 2 de mayo de 2021 (UTC)
- LSE y Reuters en conversaciones tras la disputa sobre el muro de pago del sitio web de noticias . Oh mi. Nemo 17:17, 20 de mayo de 2021 (UTC)
Reuters está completo. Entrada típica en la base de datos IABot: [20] es decir. El bot de GreenC detectó que la URL está muerta y se estableció en la lista negra. Caso diferente: [21] - establecer en lista negra, agregar una URL de archivo cuando esté disponible. Tercer tipo, elimina la URL del archivo si no funciona y no se reemplaza. En total, verificó 165k URL únicas y editó alrededor de 69k o aproximadamente el 42% ahora están en la lista negra, el resto aún funciona ( Ejemplo ). El siguiente paso sería ejecutar IABot en todas las páginas con una URL de reuters (cualquier nombre de host y .com y .co.uk) en cualquier sitio de idioma wiki compatible; o IABot los encontrará a tiempo. - Green C 01:52, 21 de mayo de 2021 (UTC)
Enlaces muertos redundantes con enlaces permanentes
En relación con los enlaces #Fix pdfs.semanticscholar.org , o más bien el trabajo que le siguió en phabricator: T281631 , hay algunos cientos de avisos {{ dead link }} que pueden eliminarse (junto con la URL asociada) porque el DOI o Se puede esperar que HDL proporcione el enlace permanente canónico. Vea una búsqueda simple en:
- Especial: Búsqueda / fuente interna: "doi-access = enlace muerto gratuito" (~ 550)
- Especial: Búsqueda / fuente interna: "hdl-access = enlace muerto gratuito" (~ 40)
Esto no es tan urgente como el problema de OUP anterior, y si es complicado, también puedo hacerlo manualmente, pero parece lo suficientemente grande como para beneficiarse de la ejecución de un bot en algún momento. Nemo 16:26, 5 de mayo de 2021 (UTC)
- Para confirmar, si una plantilla de cita contiene
|doi-access=free
o|hdl-access=free
y tiene un adjunto, elimine el (más ) y el - Verde C 20:11, 5 de mayo de 2021 (UTC){{dead link}}
{{dead link}}
{{cbignore}}
|url=
- Si. También un pmc. Nemo 20:58, 5 de mayo de 2021 (UTC)
|pmid=
? - Green C 18:03, 6 de mayo de 2021 (UTC)- En mi humilde opinión no, porque el PMID por sí solo no proporciona el texto completo, por lo que la URL original podría haber tenido algo diferente. La razón por la que PMID es suficiente con los enlaces de OUP anteriores es que PubMed enlaza la misma página de destino del editor que la URL original. Nemo 05:54, 7 de mayo de 2021 (UTC)
- Si. También un pmc. Nemo 20:58, 5 de mayo de 2021 (UTC)
Plantillas de SR / Olimpiadas
Hola. Como SR / Olympics se ha cerrado, varias plantillas de SR / Olympics están rotas. Son Plantilla: SR / país olímpico en juegos (250 usos), Plantilla: SR / deporte olímpico en juegos y Plantilla: SR / deporte olímpico en juegos / url (ambos 63 usos). Véase, por ejemplo, Argelia en los Juegos Olímpicos de verano de 2012 y Fútbol en los Juegos Olímpicos de verano de 2012 . No estoy seguro de si InternetArchiveBot puede funcionar con estas plantillas. Me preguntaba cómo se podrían arreglar estos enlaces con URL archivadas como en Plantilla: referencia deportiva . ¡Gracias! - MrLinkinPark333 ( charla ) 19:35, 10 de mayo de 2021 (UTC)
- Los dos primeros ya tienen un
|archive=
argumento, por lo que es solo una cuestión de actualizar cada instancia con una marca de tiempo de 14 dígitos, por ejemplo.|archive=20161204010101
. El último es usado por el segundo, por eso tiene el mismo recuento, no hay nada que hacer allí. Para los dos primeros, supongo que se necesitaría un código personalizado para encontrar una marca de tiempo de trabajo y agregarla. Es por eso que no me gustan las plantillas personalizadas, no funcionan con herramientas estándar, cada instancia es un trabajo de programación personalizado. Veré lo que puedo hacer. - Green C 20:04, 10 de mayo de 2021 (UTC)
Enlaces de amazonaws rotos
Con frecuencia encuentro enlaces "caducados" a amazonaws en Wikipedia: ¿es posible repararlos automáticamente? Jarble ( charla ) 18:31, 21 de mayo de 2021 (UTC)
- @ Jarble : La búsqueda muestra alrededor de 370. Los pocos que miré manualmente no tienen un archivo disponible. Por ejemplo, [22] del idioma sardo contiene
Expires=1612051241
parece ser una fecha de Unix que se puede convertir aquí a enero de 2021. Y, efectivamente, el archivo es posterior a abril y no funciona, devolviendo un código 4xx. Entonces necesitaría un . De hecho, incluso si aún no hubiera caducado, probablemente lo hará pronto, por lo que debe tratarse como "muerto" y debe encontrarse un archivo y agregarlo lo antes posible. Actualmente no tenemos ningún mecanismo para automatizar los procesos de búsqueda + archivo en ciertas URL de forma recurrente. No sería difícil procesar estos 370, pero en el futuro a medida que se agreguen nuevos, tendré que pensarlo. - Green C 19:02, 21 de mayo de 2021 (UTC){{dead link}}
Ok, creé un bot que buscará las URL a diario, y si encuentra una URL que no se ve antes, emite una página Guardar ahora en Wayback. Esto debería garantizar que las nuevas incorporaciones se archiven de inmediato. Suponiendo que Wayback sea incluso capaz de archivarlos. El bot tiene registros públicos https://tools-static.wmflabs.org/botwikiawk/awsexp/ y la fuente también está allí. Una vez que se archivan las URL, es solo una cuestión de IABot o algún otro proceso para agregar los archivos a Wiki en nuestro tiempo libre, independientemente de si ha pasado la fecha de vencimiento. - Green C 20:26, 21 de mayo de 2021 (UTC)
Se agregó un enlace de AWS a las 12:31 p. M. Del 17 de mayo de 2021 con una marca de tiempo & Expires = de 13:30:53 p. M. O aproximadamente 1 hora después. Santo cielo que es un período de caducidad corto. No es de extrañar que estos enlaces estén rotos y no tengan URL de archivo disponibles. El bot necesitaría ejecutarse cada 50 minutos aproximadamente, asumiendo que no hay ninguno con una expiración aún más corta. - Green C 21:17, 21 de mayo de 2021 (UTC)
- El bot ahora se ejecuta dos veces por hora. Vigilar los registros para ver si se puede guardar correctamente la página antes de que caduque. - Green C 21:53, 21 de mayo de 2021 (UTC)
- Otro vino, se movió a main desde Draft, por lo que ya había expirado. Se agregaron Borrador: y Archivo: a la búsqueda. - Green C 02:59, 22 de mayo de 2021 (UTC)